Trace order amendments through invoice lines and generate legally compliant invoices

Awesome recap @MyriamBoure thank you! I would be happy to be PO on this but maybe it’s best if we re-assigned when we have our priorities?

can I check - when we say this will make invoices legally compliant - does that mean this work will also put the supplier names on the invoices (legally required in Canada I believe - buyer has to fully understand what they purchased, and in an on-line market that means understanding whose product it is.)??
I understand if Canada is the only instance that needs this and that makes it out of scope. BUT I think if we are working towards a global instance - that we need to NOT assume our invoices are legally compliant everywhere. To do that, each country (instance with different taxation and accounting requirements) would need to be able to build their own legally compliant invoice template or something.
But besides the legal issue - given transparency is a key guiding principle of OFN - I don’t see why we wouldn’t want to share the producers name with the consumer.

1 Like

Agree with @Rachel. Awesome summary. This one wasn’t easy at all.

Regarding feature candidates, It’d like to highlight FC4. Avoiding PDF completely and leveraging printing stylesheets would remove a big burden. PDFs tend to consume lots of system resources, but also require quite big dependencies in the app such as wicked_pdf or wkhtmltopdf-binary.

1 Like

@tschumilas I woudl treat both things separatly, adding the supplier name is a super tiny thing that could for me go straightforward to dev… this feature is much bigger and more on some core processes behind invoicing, not linked to the content of the invoice info really. So please vote on Add supplier name into default invoice template ! I’ll be happy to support that we move it quickly to the pipe, I think it’s XS feature we just need to check with a dev, let’s discuss there please :slight_smile:

Cool @sauloperez I added your comment in main post :slight_smile: Would like to hear others feedback of course on this and see if the feature candidate we propose get some consent? @Kirsten @lin_d_hop @Theodore @lauriewayne1 etc.

I agree that b sounds like the best option for the problem stated. Happy for the work to go ahead.

To sanity check, the modifications history will not be captured for an order at all unless the user generates an invoice?

I know I am late to the party so I’m sure this has been discussed at length already and thus sorry for throwing a spanner in and I hope it doesn’t create complications…

To my mind I feel like there might be benefit in having all modification data stored, rather than overwriting the original order data - so there is orders data and a modification data. Then invoices are generated as a snapshot of the current state of the order, including up to date modifications.

This is a common ecommerce problem. I do wonder how spree handles order modifications?
@sauloperez @luisramos0 @maikel @Matt-Yorkley

As a first iteration, this is how will keep track of the modifications. So, we already provide a solution while being legally compliant. Then, in an upcoming iteration we can think of not modifying the order.

This is a common ecommerce problem. I do wonder how spree handles order modifications?

I don’t recall Spree doing anything about it at least in the 2 series, I can’t tell about future versions.

2 Likes

Thanks Pau. Like I say I’m happy with the solution and don’t want to change anything. Just engaging a little. Totally trust you folk :slight_smile:

1 Like

Nice doc Myriam!
I vote FC4 option b to start with.
My estimate is L.

should we check future spree? assuming we’ll go there eventually?

1 Like

Print stylesheets are definitely the way to go. We’ve used that system for CLFC for years now, and when we run the invoices, load the HTML page and save it. In Chrome, that gives you a ‘save as PDF’ option that takes that workload off the server. It’s very flexible and lightweight.

1 Like

I think we asked the devs in Port and it doesn’t seem Spree did something on that direction… check with @sauloperez and @luisramos0 can one of you confirm ?

sorry, I have no clue about invoices in the future spree, would have to investigate.

I haven’t investigated that either but it’s on the list.

there are plugins for invoicing but only in spree 3:


So :slight_smile: The time has come to prepare this one to get it github ready :slight_smile:

Here is a recap of the chosen solution:

  • Each time a modification happens on an order, a new order that cancel and replace the precedent is issued. The new one would contain all info (last state + history of changes)
  • We create a simple invoice data structure with order ID, Invoice ID, status, invoice lines (created from line items), timestamp, etc. And invoices are linked with one another when a new invoice is associated to the same order, cancel and replace the precedent.
  • Each time the new order is generated in a web page (not a PDF).

Now that I’m diving again on this solution, I have a few questions/comments:

  • On the list of orders, do we need to show a link between the previous order and the new one? the previous one will be cancelled. I wonder if it wouldn’t be easier to remove cancelled orders from default completed orders, to avoid a large list of completed orders that you cannot print with a single “select all action”. Anyway that’s a design question, but maybe I don’t recall properly what we mean by creating a new order. So I would like a confirmation that this solution will indeed generate a new line of order in /admin/orders?q[s]=completed_at+desc as a final result
  • Both orders will need to have the same number. Is this possible in the current OFN model?
  • In product curation we decided to release separately order amendments and invoice numbering system. Is that still a valid idea or would the solution benefit from a new numbering system right away?
  • We create a simple invoice data structure with order ID, Invoice ID, status, invoice lines (created from line items), timestamp, etc => is everyone clear on what the “etc” means?
  • invoice generated will not be in PDF anymore. What are the implications on the current bulk invoice PDF: we stop supporting it and instead develop a new bulk printing option within this work?

Thoughts? @luisramos0 @sauloperez

Maybe I miss the last conversations about this topic? I cant remember agreeing on cancelling the previous order. In my mind the agreed solution was to cancel the previous invoice, not the order, and issue a new invoice with the latest data on the order.

Is there a tech lead assigned to this already? I think we need a dev to look at this again with more detail now.

Another point is that although at the time I think we were thinking about having an invoice structure that would hold history (line items, etc), since then we also agreed we need some form of edit trail on the order. I think an edit trail on the order will be useful to build the invoices as the invoices can be associated to a specific version of the order. We need to decide what’s the way forward…

@luisramos0 actually it’s maybe me who got confused reading the notes. I was reading through the comment that we would go to option c (no first invoice automatically generated) and then I didn’t see how we could cancel something that wasn’t generated before. I believe that’s where I ended up believing we would cancel the order, I’m sorry.
But now re-reading again I see that you were in favor of option b (only the first invoice is automatically generated) which makes more sense and allows cancellation of the invoice.

Not yet. Would you be interested in that role?

Yes aligned. But the invoice would still need to reflect the trail to be compliant. But that sounds like a more clear path forward.

ok :+1:
yeah, I can be the tech lead on this one :+1:

I see this is next up in the priorities after T&Cs. I’ll schedule some time this week to go through the details. I’ll post results here. We can then see if we need a call. ok?

awesome thanks @luisramos0 !