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?
Wouldn’t a product addition also be an amendment (as done on single order edit).
I forgot the most obvious 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 
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.
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)
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?)
Hello everyone, here is the latest summary of updates to make to invoices: Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
Seems like the best thing here @tschumilas would be to deal with those 2 things as papercuts rather than complicating the changes to invoice process
@selma: Is the Notion document meant to cover all required changes to have legally compliant invoices or is it just covering the amendments part?
Just asking because there are more open issues, I think. For example
My notes after a brainstorming session with @lin_d_hop on this topic:
-
the previous tech solution would imply to generate invoices at each amendments, which could blow up as users are editing orders heavily (orders are often treated as pre-orders)
-
we need to think about buttons enabling users to generate invoices when they are ready. Invoices would only be generated or re-generated through this action.
-
a new menu would be introduced in the right-hand menu of the edit orders page. Basically a tab listing all invoices for this order (when an invoice is generated and there has been edits to the order, the previous invoice is cancelled and a new one is generated / referencing the old one. If no edits we don’t re-generate an invoice). This menu allows to generate, cancel, view and download.
-
Bulk invoice printing can generate invoices according to the above rules or just read from the stored invoices.
-
Sending invoices per email won’t generate invoice however: we need to simplify and avoid having several places to generate invoices. It’s perhaps out of scope, but if we start storing invoices, maybe we can display them in the customer account and send a link instead of sending them attached in mail. To be confirmed, but this could ease sending the email in bulk.
-
When doing this we need to introduce at some stages a confirm modal (as cancelling a previous invoice e.g. is not a light choice) - just adding this as a reminder
-
Invoice number: perhaps out of scope (dealt in separate feature) but we will need enterprises to be able to choose their invoice prefix (in settings). From there, all invoices from this enterprise have the same prefix and a sequential number.
These ideas will need to be confirmed / checked with a dev when we are ready to pick up new work.
When we will reach this stage I will move this as new issues in github, with the rest of small issues we might tackle at the same time. Note to myself: it could be worth looking into merging both invoice template while we are at it… as it will be a headache to adapt both template if we need to mention some history. But let’s not get too excited about this yet, this will need a deeper analysis.
This sounds so awesome!! Just noting that in Canada our hubs seem to prefer emailing invoices over re-sending order confirmations after editing orders. I don’t know why - will think on that and talk to some hubs on process. (Because this is where the desire to bulk email invoices comes from… maybe I need to better understand how these hubs work.) Second to note - I know that hub customers under-use the customer accounts feature. Again - note to self to ask some users why - because personally I think its a great feature. And I personally like parking access to invoices there… but right now, no one here would use it I’m afraid.
Post Script to this after some discussions with large hubs - the reasons customers often don’t use their customer account to access their invoice, is because they can’t figure out how to print anything from their OFN account. Some use print screen - but many don’t know about that. Many customers want a pdf to store or download -especially wholesale customers (who need these for taxes…). So - longer term option (I know it could be out of scope here) to make it possible for customers to print invoices rather than the hub manager emailing them is a useful long term plan.
My notes after the meeting with @abdellani @jibees and @filipefurtado :
-
The work will be done step by step against a feature-toggle. First step will be to be able to generate an invoice at the edit order level. We want to be able to do this on any completed orders. If the user re-generates the invoice, we issue a new invoice if the order was changed, if not we keep the previous invoice. This means we need to have an accurate updated_at date.
-
What do we consider order changes/amendments? => adding or deleting products, changing weight through BOM, editing quantities, adding adjustment, changing payment method, updating fees,
adding a tracking number, adding a note, capturing payment. See this doc for last update: order attributes (invoices) - Google Sheets -
Invoices are only generated when the user ask for them. No automatic generation. We can even disable the generate button in the order edit page if the order had no changes since the previous generation of invoice
-
Once the edit order page works, we can move on to Bulk invoice printing and after that to the feature that allows to send invoice per email. Once these 3 steps are done, the feature toggle can be removed
-
On these first steps, we will ignore the invoice number, this will be handled in a second release
Let’s move to github from now on. I’ve started this epic in wishlist, we can move to main repo as soon as we are ready to pick up the work:
Slack channel is #legal-invoices
At least we should be able to detect/define that an order has been edited (through the actions you mention below), and then either update the update_date column or update another new field/column.