Procurement Simplification Trunk
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo Addons (MOVED TO GITHUB) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
I think I have a good way to improve all exceptions handling in OpenERP's Make To Order flows.
We should just change a little bit how procurements are handled:
Currently (v5.0)
[1] the procurement is responsible of getting/ordering the products
[2] follow the purchase order (or manufacturing, or task, ...)
[3] check that the final stock.move is done or cancel (the one to deliver the customer)
New Proposition:
[1b] the procurement is responsible of getting/ordering the products
[3b] WAIT that the final stock.move is done or cancel
The first point (1 or 1b) is used for requisitions:
- create tasks, manufacturing order, purchase order, ...
- very useful so that every module can implement procurement workflow to define new kind of products handling
The third point (3 or 3b) is used to know that the products have been delivered/picked
- mainly used by the SO (to trigger invoices or done)
So, I propose to remove the point 2 (the procurement should not follow the created purchase order (or task, or manufacturing, ...), but only wait that the final stock.move (or task) is set to done or cancel. So that you can do anything on the purchase (or manufacturing, ...), the procurement is not changed, it just wait that the status of the final move (not the one of the purchase, but the one to deliver the customer) is done or cancel.
It's already like this on tasks, we must only change for purchases and manufacturing.
As a technical point of view, you just need to change a little bit the workflow so that the procurement do not connect anymore on the purchase order or manufacturing order (no more subflows), but just create these records. (and, instead of waiting for the end of the PO, it waits for the end of the final stock move)
See the attached png file which shows the modification I propose to apply on the workflow for trunk.
With this new proposition, you can easily split/join purchase orders without any trouble. Or, you can change the workflow so that it generates purchase tender instead of purchase order (an intermediate step to handle negociation or the fact that several products must be purchased at different suppliers).
With this modification, you can easily inherit and improve procurements to generate any kind of documents. You do not have to handle how these documents evolves, it's much easier.
Changed in openobject-addons: | |
status: | Confirmed → Fix Released |
Regarding your proposal I have no objection. I am sure you considered all issues for sales, and I see that it would be no problem with internal procurement like Requisition Request in Product (in trunk) which is used in in the same form in my stock_planning module (for trunk). I think it is good idea to leave more sophisticated and specific workflow design to introducing consultants.
But I think it is good moment to remind my blueprint about supply method.
I postulated to improve Supply method which is now in Product (Produce, Buy) by third method "Take from another Warehouse" and place the Supply Method in Orderpoint. So Supply method would be assigned to Product AND warehouse (not only to Product) with indication from which place an orderpoint warehouse should be replenished.
I think now it needs a lot of coding and workflow changes to implement warehouse to warehouse replenishment when customer need it. But it is very common situation that when you order some furnitures in shop they are not produced in Shop. I think it should be much easier to configure OpenERP that customer places SO (even MTO) in Shop and it triggers production in another warehouse (as source of raw materials and destination of finished goods) and get it to the Sales Shop. So I think it is not specific customer requirement but very common functionality which should be available in raw OpenERP test version.
Fabien, can you look at this problem as you are so close to it?
In the link below it is full idea description. It is wider than supply method only. Read it just as idea. Forgive me note about droping of Procurement Orders. I faced to a lot of problems with Procurement exception and didn't know the power of workflow that time.
https:/ /blueprints. launchpad. net/openobject- addons/ +spec/mrp- logistic- power