OK, so we agree we will not cancel and recreate orders, just invoices, the order will always be the same and as the details change, the changes will have to be stored in some form and used to generate multiple invoices representing the multiple versions of the order.
I think we should leave invoice numbering for later. We should first get the invoices generation done with the details we want, with the UX we want and afterwards, add the numbering feature on top.
I would even treat it as a separate initiative. A separate epic on GH for sure.
I think this should be a separate epic on GH as well. To fullfill the original request we dont need to replace PDF with HTML, do we? We can use the same system we have today of generating PDFs but just fetching data from slightly different place.
I think we need to invert the perspective here, forget about the DB for a little bit and focus on the UX. Ideally we would have some mock ups/wireframes to understand what exactly will be required from the user perspective. I’d like to explore this before we get into tech solutions.
If we ignore invoice numbering, what exactly do we need to change? Time to write some user stories.
Order amendments are already reflected on invoices when they are printed.
I see the first user story as: when user prints invoice for an order, if the order was changed, since the last invoice printing OR since checkout, the previous invoices will be accessible in some way.
Shall we create a new order tab next to adjustments and payments called invoices where we list all the invoices for an order?
When user opens that tab, they will see at least one invoice that they can print and an indication if the invoice is up to date with latest order details or if it needs to be re-generated.
@Rachel what do you think should be the process now? Let’s keep the conversation going in this thread or setup a call?