awesome thanks @luisramos0 !
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?
Ok fine by me. I’ve asked because I was wondering if it could help making links between invoices 
This was introduce as a dev need I think 
From memory, I believe we had a discussion on how hard it was to handle PDF, and that it would be cleaner and easier to handle only HTML. While I agree that in the future we maybe want this I agree that it is too much headache for now, let’s introduce minimal changes for our users. So I wouldn’t create anything on that topic and just cancel the idea for now.
I’m totally onboard. I just wanted to check if we could reuse some stuff we did before. Turns out it is really difficult. That’s a good thing to learn: never incept if you are not ready to develop right away. Other topics have already proven that, but that’s just another one
What do you mean by that @luisramos0 ? Recently Steve worked on getting the payments’ history on the invoice, but other amendments are still invisible. Or did I miss something else?
I will work on some user stories / mockups and check up stuff with our accountant. I want to make sure what the second invoice needs to show from the previous one according to french law. Then I will post again here and we can schedule a little call. I really loved having Theresa and Kirsten bounce ideas on my proposal on customer names, but a dev was really missing in the conversation. So even getting a 30 min call with you and maybe @lin_d_hop or @Kirsten if they are up to it would be awesome to move things forward. I will try to get infos ready for next week.
1 Like
I’m just coming to this inception now - hope I"m not too late. Not being able to email PDFs of an invoice would be a significant problem for users in OFN-CAN. Our most popular payment option is ‘pay to invoice’ . Users do this because orders have so many additions and deletions, variable weight items, etc. Few use credit because our stripe fees are so high, and we have bank transfer for payments that is cheap. So - our hubs are not taking any form of pre-payment - so the best feature we have is to automatically send the customer their final invoice. Indeed, I was going to add a wishlist item that allowed us to bulk email PDF invoices. Emailing the pdf invoice is very frequently used here, I wouldn’t want to lose it. Is there another option?
Hello @tschumilas here we are not at all looking at the email. The debate around PDF vs HTML was on the form, not the content. You can always print an HTML page as a PDF, and it is easier to maintain on the tech side of things. This is why it was mentioned as a tech solution in the initial inception.
Anyway we agree in the last post here that we will not change how we display the invoice as part of this work, so for now we keep maintaining the PDF form.
Also, as we are not at all looking at email here, bulk email invoices should be a separate wishlist item.
Can you open the wishlist @tschumilas? Thanks 
I think I already have that as a proposed but rejected ‘welcome new devs’ project - if @tschumilas could make it into a wishlist that would be ace - https://github.com/openfoodfoundation/openfoodnetwork/issues/4436
We’ve had chat on Slack with @luisramos0 on this particular topic. It appears Luis was referring to adjustments. Adjustments are indeed reflected on the invoice. Here we are targeting amendments which are not reflected in the invoice (and thus makes the invoice legally wrong).
We agreed we should define amendments. So here is what I could think of:
Amendments appear when:
- A product is deleted (through BOM or single order edit)
- A product weight or volume has changed through BOM
- A product quantity has changed (through BOM or single order edit)
What I’m unsure of are shipping method and payment method fees: they are reflected as adjustments but if there is a change you don’t see the change on the invoice, just the final result. I think this should be recorded as well.
The result is that any kind of refunds needs to appear on the invoice as well.
@lin_d_hop @Kirsten what do you think?
1 Like
Wouldn’t a product addition also be an amendment (as done on single order edit).
1 Like
Your suggestions seem reasonable to me @Rachel - I am not that familiar with this as I think it is an area where Aus law differs, so I don’t have any real experience of invoices that show all this tracking. It seems sensible to be consistent so that changed shipping and payment fees are also shown. But I am thinking that this invoice is going to be a real mess - by the time all these changes are tracked, along with changed fees and shipping / payment amounts and taxes etc
I also have wondered what they’ll look like. I get invoices from various plant suppliers I use that track all the changes - and they are actually quite tidy. The change are one phrase and the date at the top - above the current invoice. I’ll dig one up and post it. It also might make sense that we share how many and the kinds of changes most OFN invoices undergo. In Canada - the most frequent change to an ORDER is a weight adjustment - would we consider that a ‘change’ on an invoice? After that I suspect is items not available from the supplier and dropped. After that it is a product addition. Be interesting to know how many orders undergo changes before invoices are issued. Is there a way Matamo could tell us that?
This is my next design task 
I reckon the first task is re-reading this thread and then doing some design thinking.
Hey @Rachel I now understand what you meant today in the product curation meeting.
I meant that the tech solution around option FC4 is still valid (“simple invoice data structure in HTML”).
But you meant that with the request to capture order amendments and a possible order edit trail this can become a total different beast. I agree. The conversation from 2 years ago is still valid but there are these new challenges and that’s why we need to go through the discussion again.
I think we can still capture order amendments in invoices with the simple invoice data structure (solution FC4 in the original description) and not with a full edit trail. This is probably the best option because edit trail sounds nice but can become a nightmare to implement.
The simple solution could be, for example, some of the invoice lines can have a flag “amendment” that makes them show differently on the invoice? Or we can detect differences between invoices and show them as different on the invoice. Or something like this.
the next dev will take care of this 
1 Like
Just noting from a user conversation today that they want to be able to put a note with an Order Amendment eg Eggs broken in packing.
They would also like to be able to retrieve this information in a report, alongside the orders screen.
The user was Kate at Slow Food Birmingham and they’d be happy to have conversations during the inception process on this work.
1 Like
I’m in the middle of all the plant ordering for my farm - and these are orders that go through many many changes (Plants are grown to order - so lots happens between a November order and an April delivery) I like how this supplier’s order confirmation system adds a dated change to the top of the confirmation (in addition to actually making the change on the order) As a buyer - I always know exactly where my order is at - just in case this is useful for you @Erioldoesdesign (I re-sell these plants on OFN - so this system also helps me go in and edit the OFN buyer orders with each change.) GAR35 JVK Order 225050 Raker-Robe ShipDate 20210407 November 18.pdf (72.0 KB)
1 Like
Quick note after a chat with a lawyer: I’m dumping here some info regarding FR law, of course once we pick-up this item for inception again I will clean up the notes:
If the invoices were originally issued in paper format and were subsequently digitized for storage, they must be kept in PDF format (cf. 2nd paragraph of the article A.102 B-1 of the tax procedures book (LPF)).
If the invoices only exist in electronic format, they must then be kept in their original computer format, i.e. the one in which they were issued, during the three-year recovery period provided for in the first paragraph of Article L. 169 of the LPF.
Indeed, the change in the computer format of electronic invoices does not guarantee, in accordance with V of article 289 of the code General Tax (CGI), the integrity of the content of electronic invoices.
However, you are free, for management purposes, to modify the computer format of their invoices if hubs keep them, in a parallel, in their original format.
For information, accounting documents and supporting documents, including in particular the order, delivery or receipt forms, as well as customer and supplier invoices must be kept for ten years, in accordance with the requirements of the 2nd paragraph of article L. 123-22 of the Commercial Code.
It is up to the hub to keep his own invoices.
As a result, you should keep your own (B2B) invoices and the hubs must keep their own invoices (B2C).
The shops should either be expressly warned that it is only an ancillary service which does not exempt them from the obligation to keep also the invoices on their side (to see how to denominate it together), or make sure to include a specific exclusion of warranty in your T & Cs.
I see that we are getting close to incepting this… so I wanted to add something. Lately I manage orders for a large hub - and so I am making changes to orders every week. Are we thinking that EVERY change to an order will appear on the invoice as history? I am asking this because in OFN today adding items to an order is tricky and imperfect. When adding an item, I cannot see the price of the item for example, and its hard to search because all items from all producers (even those items with 0 stock) show in the search dropdown. SO - my point is that many times I select an item, add it to the order - only then can I see its price - and then I realize it was the wrong item. So I delete it from the order. Will each incorrect addition and deletion show on the invoice? I agree with having history on invoices - but a user can make a lot of history when they are editing orders that is irrelevant. Is there any option? (I think maybe not - and we just wait for the time when editing orders is easier, and deal with messy history on invoices for now?)
1 Like