# Update the purchase request state
**URL:** https://discuss.tryton.org/t/update-the-purchase-request-state/1879
**Category:** Developer
**Tags:** purchasing
**Created:** [October 30, 2019, 6:17am UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879 "2019-10-30T06:17:57Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@oscarQ](https://discuss.tryton.org/u/oscarQ)
#### Post date: [October 30, 2019, 6:17am UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879/1 "2019-10-30T06:17:57Z")
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](https://hg.tryton.org/tryton-env/modules/purchase_request/file/tip/purchase.py#l76).
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.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 30, 2019, 8:26am UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879/2 "2019-10-30T08:26:04Z")
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.
---
### Author:  [@oscarQ](https://discuss.tryton.org/u/oscarQ)
#### Post date: [October 30, 2019, 11:58am UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879/3 "2019-10-30T11:58:55Z")
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:
1. The request keeps on exception forever or deleted (and the purchase can ends on any state).
2. 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.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 30, 2019, 12:14pm UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879/4 "2019-10-30T12:14:13Z")
> [@oscarQ](#):
>
> 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.
Because it is what happens in real life.
> [@oscarQ](#):
>
> I think that it can ends on more inconsistencies than advantages on any of the possibilities.
So what is your proposal?
---
### Author:  [@oscarQ](https://discuss.tryton.org/u/oscarQ)
#### Post date: [October 30, 2019, 12:52pm UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879/5 "2019-10-30T12:52:26Z")
> [@ced](#):
>
> Because it is what happens in real life.
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?
> [@ced](#):
>
> So what is your proposal?
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.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 30, 2019, 1:05pm UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879/6 "2019-10-30T13:05:07Z")
> [@oscarQ](#):
>
> 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?
Because cancelled shipment can be recreated.
> [@oscarQ](#):
>
> 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.
---
### Author:  [@oscarQ](https://discuss.tryton.org/u/oscarQ)
#### Post date: [October 30, 2019, 1:46pm UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879/7 "2019-10-30T13:46:04Z")
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.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 30, 2019, 2:00pm UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879/8 "2019-10-30T14:00:38Z")
This is not practical because:
- purchase user may not have access to request
- it is line based which can be too much work to manage
- we must not create a new purchase if it is still active for the supplier.
---
### Author:  [@jaarias](https://discuss.tryton.org/u/jaarias)
#### Post date: [October 31, 2019, 8:27am UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879/9 "2019-10-31T08:27:32Z")
> [@ced](#):
>
> purchase user may not have access to request
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.
> [@ced](#):
>
> we must not create a new purchase if it is still active for the supplier.
I don’t understand… The supplier and the purchaser have to be agree when a purchase is cancelled.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 31, 2019, 8:36am UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879/10 "2019-10-31T08:36:33Z")
> [@jaarias](#):
>
> I don’t see in what case the original purchase has to be restored to draft.
Mistakenly cancel it but the supplier is going anyway to deliver it.
> [@jaarias](#):
>
> The supplier and the purchaser have to be agree when a purchase is cancelled.
Misunderstanding can happen.
---
### Author:  [@jaarias](https://discuss.tryton.org/u/jaarias)
#### Post date: [October 31, 2019, 9:15am UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879/11 "2019-10-31T09:15:11Z")
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.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 31, 2019, 3:00pm UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879/12 "2019-10-31T15:00:22Z")
> [@jaarias](#):
>
> 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.
---
### Author:  [@jaarias](https://discuss.tryton.org/u/jaarias)
#### Post date: [October 31, 2019, 3:09pm UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879/13 "2019-10-31T15:09:05Z")
> [@ced](#):
>
> I agree we must update the state of the request when the purchase is reset to draft.
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…
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 31, 2019, 3:12pm UTC](https://discuss.tryton.org/t/update-the-purchase-request-state/1879/14 "2019-10-31T15:12:56Z")
> [@jaarias](#):
>
> 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.