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 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.
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, 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 make on the workflow.
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.
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 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.
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, 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 make on the workflow.
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.