# Pending State on Purchase Requests **URL:** \ **Category:** Feature\ **Tags:** purchasing\ **Created:** [February 11, 2016, 1:02pm UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37 "2016-02-11T13:02:00Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\ **Post date:** [February 11, 2016, 1:02pm UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/1 "2016-02-11T13:02:01Z")
**Rational** We have the scenario where the person go decides which purchase requests is different than the person that creates the purchase for the requests. In order for the purchase user to know what to purchase we need to add a new state tot purchase\_request which indicates what has to be purchased. The _Best Purchase Date_ is not suficient information to decide what has to be purchased as we need to prioritize purchase request depending on the production planification. **Proposal** Currently the purchase\_request state is a functional field, so we propose a to add a boolean field on the purchase requests to indicate the “_approved_” purchase requests and add a new state name “_Pending_” for the purchase request and with the “approved” field set to true. Of course, the pending state will be set with a button like a normal transition. This change will imply that “Pending” request must not be deleted when computing requests. So we must use the state (it has a searcher method) in purchase deletion instead of the current domain. Is anyone else interesed on such feature? Does anyone have better names for the new state? Does anyone have some problem with the proposed change? * * * **Extra proposal** In order to be in concordance with production requests we may rename the purchase requests _Draft_ state into _Request_, so we use the same naming. ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [February 11, 2016, 1:17pm UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/2 "2016-02-11T13:17:12Z")
I don’t really understand the rational. Purchase request is not something you decide to purchase or not. It is something you **have to** purchase because if you don’t the system will create a new one again and again. Indeed purchase requests are there for the user to tell the system how to purchase those requested products. For me, it is on the purchase that the decisions are taken. ---
**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\ **Post date:** [February 11, 2016, 1:24pm UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/3 "2016-02-11T13:24:31Z")
There is the need to **prioritize** purchase requests. So the user decides what has to be purchased **now** , and what can wait some time. Also the user who decides what has to be purchased may not belong to the Purchases Departarment, so he/she doesn’t need to see the full purchase workflow, only the warehouse needs (that are shown as purchase requests). ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [February 11, 2016, 2:36pm UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/4 "2016-02-11T14:36:22Z")
The only possible priority tuning is when grouping requests into one purchase because it will take the minimal purchase date of the requests as purchase date. ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [February 11, 2016, 2:41pm UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/5 "2016-02-11T14:41:05Z")
> [@pokoli](#): > > Also the user who decides what has to be purchased may not belong to the Purchases Department, so he/she doesn’t need to see the full purchase workflow, only the warehouse needs (that are shown as purchase requests). It is not at the purchase request level that the warehouse management is done. It is at the order point and all the rest is done automatically by Tryton. Once a purchase request has been created, it is no more in the responsibility of the warehouse department but of the purchase department. That’s why it is named **purchase** request and the only editable fields are those that affect the purchase creation. ---
**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\ **Post date:** [February 11, 2016, 2:49pm UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/6 "2016-02-11T14:49:19Z")
> [@ced](#): > > > [@pokoli](#): > > > > Also the user who decides what has to be purchased may not belong to the Purchases Department, so he/she doesn’t need to see the full purchase workflow, only the warehouse needs (that are shown as purchase requests). > > It is not at the purchase request level that the warehouse management is done. It is at the order point and all the rest is done automatically by Tryton. > Once a purchase request has been created, it is no more in the responsibility of the warehouse department but of the purchase department. That’s why it is named **purchase** request and the only editable fields are those that affect the purchase creation. So we need that the user can **manually** “review” and “modify” all the process which is done automatically by tryton. On our case the purchase department is only responsible for contacting the suppliers and getting the cuotes/invoices of the goods. BTW, if you think thats it does not fit tryton I open two issues that allows us to customize the workflow: - One for an easy way to override state searcher - One for only deleting draft purchase requests (instead of using the equivalent domain) And then we can implement it on a separate module. ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [February 11, 2016, 3:02pm UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/7 "2016-02-11T15:02:14Z")
I try to understand what the user is reviewing? The purchase is mainly a read-only record so he can not change anything and he can not deny what was computed by the system. If a product need to be supplied, it is because the computation show it. ---
**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\ **Post date:** [February 12, 2016, 10:04am UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/8 "2016-02-12T10:04:54Z")
Of course, you are all right. One use case is to minimize the stock in the warehouse. Let me explain: There is a request of product X that can be supplied in 2 days and that is required for a production. This production is scheduled to be run in 15 days so the user decides not to buy this product until 5 days before the production scheduled date, so the product is not in the warehouse during 10 days without any usage. ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [February 12, 2016, 10:11am UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/9 "2016-02-12T10:11:16Z")
But ‘stock\_supply’ is already doing just-in-time supply. But of course, you need to have correct product - supplier information. So I doubt human will do better than computer on this topic as it is purely computation with simple rules. ---
**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\ **Post date:** [February 12, 2016, 10:17am UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/10 "2016-02-12T10:17:00Z")
We don’t want to replace the compute computation with rules, only to “review” and “aprove” them on a given time. All the calculations will be done by the system. We just want to have a mark that indicates that some purchase request have to be purchased **NOW**. ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [February 12, 2016, 10:23am UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/11 "2016-02-12T10:23:05Z")
There is already a “Best Purchase Date” on purchase request. So I still don’t understand what the user is reviewing? The computer computation? ---
**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\ **Post date:** [February 12, 2016, 10:31am UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/12 "2016-02-12T10:31:03Z")
> [@ced](#): > > There is already a “Best Purchase Date” on purchase request. > So I still don’t understand what the user is reviewing? The computer computation? Not the computation, but it’s reviewing what **has to be purchased now** and what can wait. Imagine the follow purchase request list computed by the system (all in draft state): ``` Product A - 5Units Product B - 15Units Product C - 2Units Product D - 20Units Product E - 2Units ``` The user decides to purchase Product B and Product D today, as they are required for tomorow productions. The other products can wait until they respective productions are scheduled. Of course I’m simplifying this as there will be more purchase requests in the system. As the purchase will be procesed by another user, we need to mark them in order to the purchase user know what has to be pruchased. So with our proposal, the purchase request will be as follow after the “review” process: ``` Product A - 5Units - State: Draft Product B - 15Units - State: **Pending** Product C - 2Units - State: Draft Product D - 20Units - State: **Pending** Product E - 2Units - State: Draft ``` So when the purhcase user opens the Purchase Request list he directly nows (by a filter) that he only need to purchase the Product B and D requests and that the others can wait. ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [February 12, 2016, 10:33am UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/13 "2016-02-12T10:33:43Z")
The user has nothing to decide there is a **Best Purchase Date**. There is only only user that opens the list of purchase request, it is the purchase user. ---
**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\ **Post date:** [February 12, 2016, 10:57am UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/14 "2016-02-12T10:57:41Z")
> [@ced](#): > > The user has nothing to decide there is a **Best Purchase Date**. Yes, the users decided what has to be **purchased now** and what **can wait**. In my previous example the best purchase date is the same (tomorrow) for all the request, so it’s not relevant for the decission. What is relevant is the warehouse needs. As explained earlier: If we purchase all the products we will have 3 products on the warehouse that we won’t use as they productions are not scheduled for tomorrow, so we try to avoid wasting storage. > [@ced](#): > > There is only only user that opens the list of purchase request, it is the purchase user. As I pointed on the first message, this is not our use case. The user who processes the purchases is different than the one that decides what **has to be purchased first.** ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [February 12, 2016, 11:01am UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/15 "2016-02-12T11:01:21Z")
> [@pokoli](#): > > What is relevant is the warehouse needs. This is false. The purchase requests are the warehouse needs nothing more nothing less. > [@pokoli](#): > > As I pointed on the first message, this is not our use case. The user who processes the purchases is different than the one that decides what has to be purchased first. This makes no sense because you are inventing a step that is absolutely not needed. ---
**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\ **Post date:** [February 12, 2016, 11:09am UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/16 "2016-02-12T11:09:41Z")
> [@ced](#): > > This makes no sense because you are inventing a step that is absolutely not needed. No, we are not inventing. We have a need and this step is used to solve it. So all is clear on my side, we will implement it on an external module, but we need to allow to customize the purchase request workflow. ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [February 12, 2016, 11:34am UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/17 "2016-02-12T11:34:43Z")
I think you don’t understand how purchase request works and so you are forseeing issues that do not exist. ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [February 12, 2016, 1:08pm UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/18 "2016-02-12T13:08:02Z")
It is a pity to go to custom module if there is a real need (which must still be identified). I really think you should try to explain exactly what is the need instead of justify your proposal. ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [February 12, 2016, 1:12pm UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/19 "2016-02-12T13:12:05Z")
> [@pokoli](#): > > So when the purhcase user opens the Purchase Request list he directly nows (by a filter) that he only need to purchase the Product B and D requests and that the others can wait. This is done by sorting/filtering on the “Best Purchase Date”. So of course the purchaser should be careful to not purchase too soon before this date but we need to give him some flexibility there to allow grouping purchase to reduce cost. And of course, this will work correctly only if there are correct product-supplier information that allows the system to compute the delivery date. Otherwise the system is blind and it will always ask to purchase directly. ---
**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\ **Post date:** [February 12, 2016, 1:29pm UTC](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37/20 "2016-02-12T13:29:37Z")
> [@ced](#): > > It is a pity to go to custom module if there is a real need (which must still be identified). > I really think you should try to explain exactly what is the need instead of justify your proposal. The need is to comunicate to another user which purchase request should be purchased **now** and which can wait. [Next page](https://discuss.tryton.org/t/pending-state-on-purchase-requests/37.md?page=2)