Procurement Simplification Trunk

Bug #556025 reported by Fabien (Open ERP)
8
This bug affects 1 person
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.

Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :
description: updated
Revision history for this message
Grzegorz Grzelak (OpenGLOBE.pl) (grzegorz-og.pl) wrote :

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

Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :

Supply method 'from another location' is already implemented in the stock_location module in trunk.
It also manages multi-company flows (delivery -> reception)

Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :

Sorry, it's not the module stock_location but the module stock_location_pull for what you are looking for.

Revision history for this message
Grzegorz Grzelak (OpenGLOBE.pl) (grzegorz-og.pl) wrote :

Thank you for answer.
When I try to install stock_location_pull (in trunk) I get the message:

"Module stock_location_pull: Invalid Quality Certificate"

How can I fix it?

Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :

remove the quality certificate in __tepr_.py

Changed in openobject-addons:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.