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.
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.
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.
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.
This is false. The purchase requests are the warehouse needs nothing more nothing less.
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.
I think you don’t understand how purchase request works and so you are forseeing issues that do not exist.
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.
The need is to comunicate to another user which purchase request should be purchased now and which can wait.
The now is the Best Purchase Date and there is no reason to change it because it is computed to be the best.
The “Best purchase date” is not relevant because we may have all the products to be purchased in a small delta, but they can not be consumed in a production until a bigger delta so it has no sense to have them in the warehouse waiting to be consumed.
The policy of the company is to have the minimum products in stock in the warehouse.
What I’m trying to explain is: In the same Best Purchase Date we need to chose what has to be purchased and what not. So purchase date is not sufficient to take the decision.
So your production is wrongly configured. Of course you think you need useless feature if you don’t configure correctly your production to request materials at the right time.
And this is what Tryton does by default.
So you mean that your are buying and being delivery faster than 1 day, in that case you need to add time to the “Best Purchase Date” (and in many other places). If this is the case than you should create a new topic for that.
Several comments about the issue:
The way those people work is that they hurry searching which products are most urgent and they will immediately ask the purchase department to start purchasing. They would mark those purchase requests as “purchasable” so the purchase department can start working on them. Note that the purchase department will ask for several quotations to several suppliers so they need to hold the purchase request until a decision is made. So while the decision is being made we think it is better that a supply recalculation does not remove that purchase request.
It may even be possible to help them further by calculating somehow which are those products that need to be purchased ASAP, but it is not clear how to do that right now, at the current point of the project. But even in that case, as it takes some time to decide the supplier, they will need to be able to recalculate the purchase requests (and those are currently removed on the process).
You could probably update/historize the delivery time of the supplier or create a supplier load factor.[quote=“albert, post:26, topic:37”]
there are productions which must be purchased ASAP
[/quote]
I don’t understand. What are you purchasing? For me people purchase products/materials not production.
I think we have here the incomprehension. It sounds like you have, by some means, purchase requests created before the sale order being confirmed. In this case, I think this should not be purchase request but probably a new document requesting quotation, delivery time etc. from the purchase department.
Also I still don’t understand the concept of priority here.
Based on which criteria? Why is a needed product more urgent than another? If they are all requested, it means they are all needed and there is no priority in that except of course the date when they are needed (aka “Best Purchase Date” and “Expected Supply Date”).
I think this another topic and it will probably require a new document that will be generated from the purchase request.
So for now, from what I understand about the problem, you just need to have the “Best Purchase Date” set to None and be editable for the products that you need to manage manually.
And for the deletion such purchase request with a date set manually, I think you should keep somewhere (probably on product-supplier) the date configured and put it back on the new similar purchase request (if there are).