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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.