I just made a sale amendment for a sale where the delivery was done (and wrong), but the invoice still in draft.
Now the delivery has not been adapted (which is ok since it was already done), but the draft invoice has been. And when I click on the unmodified line in the delivery, the referenced invoice line is the modified one in the invoice. To make matters worse, the inventory for these products is now of course wrong.
Wouldn’t it be logical in that case to create an expedition of the right product, and a return of the wrong one ? And of course adapt the draft invoice so that the cancelled moves do not appear, but the new expedition relates to a new invoice line ? (the current invoice is ok, but the modified line relates to a wrong stock move)
While we discuss (or not) that modification, how do I correct the inventory ?
Yes that is the right workflow but it should be done manually and not by amendments.
Amendment is for example if the customer wants more products that the ones shipped. You will have two shipments and only one invoice with the right amounts.
This is what amendment does if too much product were sent, it create a return shipment.
So a new one has been created.
This is expected if the previous invoice was still in draft.
What is that?
That does not make sense. The amendment is about correcting the quantities.
Well amending a sale for a different product does not change what was already shipped. You change the product for another one that is equivalent. Otherwise you must request a return from the customer.
I have products A, B, and C in tryton. B and C are very similar.
I deliver to the client products A and C, as he expected.
But in tryton I make a mistake: I created a sale for product A and B, and I do the delivery (in tryton). The invoice is created, and is in draft.
Now I notice my mistake, and create a sale amendment, where I replace product B with C (as was delivered in reality).
Now the draft invoice is modified and corresponds to the reality, but not the delivery. And the wrong delivery line for product B corresponds to an invoice line for product C. And my inventory for products B and C is wrong.
I believe that tryton should have created a return for product B (to cancel the wrong shipment document), and a shipment for product C. And adapt the draft invoice so that the line for product C corresponds to this new shipment.
Now there are two problems:
I think that that workflow should be corrected in tryton
more urgent: I need a way to correct the inventory
I created sale 76 on the demo server to illustrate: the first version of the sale were two packs of 250 sheets (one a4 and one a3), I shipped it, then amended the sale to replace the a3 pack by the same with 500 sheets.
Now the draft invoice is correct, but not the stock moves.
The only difference with my case is that in the demo the invoice lines and outgoing stock moves do not seem to be linked, where in my case they are. I don’t know why, probably a different combination of modules. But still, in the demo the outgoing moves are not right.
mistake or customer change request, that’s not the point. Here I created a perfectly legit amendment, and I end up with an incoherent state: the invoice line for product C correspond to a stock move for product B, and the inventory is wrong.
That’s what I think tryton should have done by itself, to get all the movements in the same sale. Now I can correct my inventory with an individual return and shipment, but they are not linked to the sale (I have not found a way to do that), and the sale itself remains incoherent (shipment line for product B linked to invoice line for product C)
This is the point. Amendments are design to follow change request and not mistakes.
Once delivered the customer can not request to change the product he already received.
What I meant by «this is not the point» is that tryton allows it, but does not handle it. So whatever the reason, if I can amend a sale line that has already been delivered, tryton should handle the case.
Or not allow it. It’s not ideal, I’m perfectly fine with that, I can correct the sale by another sale.
The point is that if the amendment is possible, it should not result in a wrong inventory and incoherent sale/shipment/invoice in the db.
nope, actually the whole sale was shipped before the amendment. If it can’t handle amendments of shipped lines (and I’m perfectly fine with that), it should not permit it. Or just permit the easy cases: augment the quantity (probably the easiest case to handle: just create a new shipping), or modify the quantity,… but anyway, if it permits it, it should handle it.
So in the end I have a sale line with product C, an outgoing stock move line with product B, and an invoice line with product C, plus a wrong inventory for both products, with no warning, but that’s not incoherent ? In what bizarre universe would anyone expect that result ?
Again, I have no problem if the solution is to restrict what is possible with amendments. But the current situation is not what anyone would expect.
It handles but as you shipped all the goods already changing the product does not have effect on the shipment but only on the invoice which was not yet posted.
Yes this is coherent with what you did. You decide to change the product of a sale once it was fully shipped.
If you want to have a return shipment, you must do a return shipment. As I already said amendments are not for mistakes.
The module is working as it is expected to be working. This may not be the way you expected but it is what it is.
But in what situation would «the invoice is different from what was shipped because someone modified the sale after the shipment (possibly without knowledge that the shipment had already happened)» be what anyone expect ? Shouldn’t there at least be a warning ? Something like «you’re modifying a sale for which shipments have already happened, are you sure that you want to do this ? (hint: the answer is probably no)»
I do not think we should put warning for every case where the user may be doing something wrong. Because we will end up raising warning for every actions. More over warning breaks workflow that customization could want. And finally in your example nothing irreversible was made by the system.