When a purchase is canceled, the purchase requests related update their states to ‘exception’, but if the purchase state is set back to ‘draft’, the purchase request state does not get updated anymore.
Scenario:
1 - Create a purchase from a purchase request.
2 - Cancel the created purchase.
3 - Set the purchase state back to draft.
Proposal:
One option is to update the purchase request state when the purchase is set to draft as it’s done on ‘cancel’ method.
But on second thought, I’m not sure if the user should be allowed to set the purchase state back to draft, because if it happens and previously someone handled the purchase request exception, it can derive on two equal purchases.
For me, the current behavior is the good one because it is flexible. This is important when dealing with external entities like a supplier.
But I agree that it will be good when resetting to draft a purchase with purchase request in state exception, we could raise a warning to the user.
I do not see any advantage in having the possibility to restore the purchase to draft and at the same time keep the exception of the request. It can only derive on a few scenarios:
The request keeps on exception forever or deleted (and the purchase can ends on any state).
The request exception is managed:
2.1. The request is canceled. So if after that the purchase is set back to draft, it updates again the state from canceled to purchased.
2.2. The request is restored. So the purchase gets unlinked from the request (the history is lost, and also the purchase can finally get purchased) and restored to draft ending on another purchase or not.
I think that it can ends on more inconsistencies than advantages on any of the possibilities.
Which is the difference in real life between a purchase and a shipment? Why in tryton the shipment cannot be restored to draft but purchase can?
My proposal is to don’t allow to restore purchases (at least if it comes from a request) because I think that the exception has to be managed on the request.
But the user who manages the purchase is not necessary allowed to manage the request.
More over restoring to draft the purchase allows to keep references etc. It better reflect what happened.
Preventing the restoration will be against the Tryton rule to have constraint only when necessary for the code.
I agree, but in the case that the purchase is created from a request, wouldn’t it very similar than when a supplier shipment with lines related to a purchase line is canceled? In this case, Tryton do not allow to recreate the shipment because it was created from a purchase and the exception has to be handled there.
As I see, this is an aditional reason to not to allow to restore a cancelled purchase back to draft. If the requester has been said that its request will not be purchased (cancelled) he have to manage the exception and the purchaser has to wait to this management and act consequently, creating a new purchase or doing nothing. I don’t see in what case the original purchase has to be restored to draft.
I don’t understand… The supplier and the purchaser have to be agree when a purchase is cancelled.
That’s okay, but if the request is managed and recreated, the link with the purchase is lost. The purchaser will see another pending request (it is the original one recreated but he doesn’t have now it) and will proceed to create a new purchase. So there will be 2 purchases but just one request.
So, I agree there can be mistake or misunderstood, but the request have to be updated consequently.
I agree we must update the state of the request when the purchase is reset to draft.
I also found that stock_supply in compare_requests should filter on the request state as different of cancel than on the purchase state. Otherwise the ignore exception is pointless.
And what if the exception has already been managed after the purchase is reset to draft? Perhaps then the purchase must be not allowed to change the cancelled state…
As I already said, there should be a warning to reset a purchase to draft linked to a request. But just a warning because if the supplier is going to process the purchase, the user must be able to store that information.