Process improvement from order to invoice


#1

Continuing the discussion from Legal conformity: what we need to do
First step of the improvement work we need to do in France to comply with legal obligations.

The problem:

  • today when an order is passed by a customer, the hub admin can modify the order even after a paiment was made, and even after the corresponding invoice was issued (and even after an order was shipped !)
  • so we are in a situation where you can have two invoices (and receipts) with different contents but the same number.
  • also legally if we make any modification to an order (cancel products, or give a void to a user) we need to issue an order that “cancel and replace” the old one and refer to it, but that has a different invoice n°.

Improvement proposal:

1- An order can be modified as long as it is not “shipped” or “collected” (new shipment status proposed). In that case only “return processes” can happen (which would imply for instance a void or reimbursment)
2- While it is still possible to modify the order, if a modification happens on an order, we are legally supposed to track any modification that happens (with + and -) in an “inalterable way”. So given the way spree is organized, I propose to create a new submenu in the order management which we can call “invoices” from where invoices and receipts can be printed, and from where we can see the various invoice versions issued for a given order (if a modification happens a new issue with order n° + -1 or -2 or -3). That enables also to use the last version to make it accessible in the customer account, so the customer, like in any other e-commerce patform would be able to download his invoice (this is also a legal obligation for any distance sale).



3- If an order has been cancelled, it shouldn’t be possible to modify it. An order that has ben paid but not shipped/collected can be cancelled, but then the customer should be refund. If the order has been shipped/collected it cannot be cancelled.
4- It seems ok to be able to cancel a payment (existant behaviour) as it is possible to make a mistake and capture a payment on the wrong order for instance. It would be good to give the possibility to add some comment note if you cancel a payment to explain what happened.

Here is the link to the slides support : https://docs.google.com/presentation/d/18ci_zxamegmH4CI3EyRWEkwc9sI7PEwjjTzHl0InWSU/edit?usp=sharing

I’m trying to get some legal advice to make sure if we do that we are going to be abligned with the law (and especially in France the meet VAT-fraud certification conditions).

Ping @sauloperez @enricostn @lin_d_hop @Kirsten @tschumilas


"Dummy orders" identification
Make OFN invoices legally compliant
Trace order amendments through invoice lines and generate legally compliant invoices
Make info on quantity ordered/delivered/invoiced/voided/paid accurate and improve packing operation efficiency
#2

We have a proposal to cover this, that is actually a standard commercial process. We need to introduce a new document: Delivery Note. Mainly:

1 order > Many shipments
1 shipment > 1 Delivery Note

At that point we can easily use the Delivery Note as a kind of invoice (simple cases) or export Delivery Notes to external ERPs to issue invoices.

In order to understand how this would work we need to understand first how Shipments are going to work starting from Spree 2.0 (more info).

We’ve been talking about this today with @sauloperez and @maxco

EDIT: the introduction of Delivery Notes will solve many issues we do face, including the legal one but mainly opening the road to buying group features.


#3

Yes but @enricostn even hubs who don’t use an ERP are supposed legally to issue invoices for their customers, that’s a basic legal requirement for any e-commerce… I have more an invoicing issue today than a shipment one, but maybe what you suggest will solve that :slight_smile: I will be happy to discuss that further with you in Aus :wink:


#4

I didn’t explained well the proposal, Sorry.

The Delivery Note can be an Invoice by itself. The ERP thing is only an optional thing that comes with same proposal.

EDIT: In any case, you cannot issue an invoice if you don’t have a document stating what of the ordered goods the customer actually received. This info should be stored in a Delivery Note / Simple Invoice.


#5

Sure, I know this is a bit awkward in my proposal. But it also happens a lot in e-commerce that you send the invoice with the product in the parcel. So it’s not a probem to be able to issue an invoice before the products are actually received. The problem is also that today you can have a payment when the order happens, then make modifications on the order, and those modification are not tracked so we can’t match what the payment was for afterward.
I’m curious to see how order modifications are handled in your proposal, but I guess you’ll right down a proposal somehow and explain all that :wink:


#6

Yeah the biggest problem in buying groups is that they don’t work as e-commerce generally does. The payment generally happen after the actual delivery. We’re going to present how this processes work in AUS.

We need to find a way to have the best of both worlds without adding too much complexity.

Regarding the Order modification generally the simplest thing is to issue a new order, without touching the existent one. But how that would work in Spree/OFN? I don’t know, probably from admin.

The real questions IMHO are:

  • why users would need to modify an order?
  • what kind of users? Hub admins or customers directly?

#7

In my proposal I have introduce a proposal to have three status “paid” for payments, and “shipped” and “collected” for shipment, because of buying group needs also. Today en order need to be paid so that it can be shipped, so this needs to be changed so that we can either capture a payment or a shipment or a collection (for buying groups or any hub that doesn’t work on pre-payment).

I thought about “locking” an order when it’s pass, but the problem is especially for buying group ! I have used when I was running a buying group in Oslo the feature “group buy” so the members buy some min / max quantity. Then we need to be able to modify the original order to confirm the actual quantity affected to this member (betwee the min and max depending on the batch size). This is one case where you need to modify an order.
Another for instance is : a member made a mistake when he receives the confirmation, he realizes he has orered 20 instead of 2 of something and he did that just before the order cycle closes, so he can’t modify his order anymore. Those kind of cases happens, I had to deal with some personnaly :wink:
With the subscription feature buyers will be able to modify themselves their order until the OC closes. But for me the orders needs to be modifiable by the hub admin until the products are shipped OR collected.

That’s why I made that proposal. I know you won’t issue an invoice until the products are delivered, but again, I share another case.
We have one user who uses the OFN to manage his POS.
Let’s say he seels a pack of pasta and print a receipt, and while he does that the client say: “wait I forgot to buy avocados !” It’s easier to just add the avocados on the same orders and reprint the receipt with the two products… else he needs to make another order and print the ticket for this second order and get the paiements for the two orders…

Also in my proposal I had in mind the way Spree works today. So for me what I suggested was to have always a “pending invoice” that you can print or send anytime, but if a modificatino happens after, you will have another invoice that cancel and replace the first one… that we an easy way in my mind to find a solution for our problems… but happy to discuss in Aus :wink:


#8

This new wishlist cancel and replace this one Trace order amendments through invoice lines and generate legally compliant invoices and is covering part of the need. The remaining uncovered needs will be exposed in different specific scoped wishlist items that will be prioritized later. Like capturing info that an order has been delivered, review status of order, etc.


#9

#10