Odoo Addons (MOVED TO GITHUB)

Procurement stuck in ready state after purchase is completed

  1. Series 5.0
  2. Bug #532148
Bug #532148 reported by Don Kirkby
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Fix Released
Undecided
Unassigned
5.0
Incomplete
High
Unassigned

Bug Description

I am testing with the 5.0 branch of openobject-addons revision 2582.
I will attach a merge proposal with a failing unit test, but here are the steps to reproduce the problem:
- Create a new database with demo data.
- Choose the Manufacturing Industry profile, but leave all the other configuration with the defaults.
- Create a procurement for 3 units of MB1 at location Stock.
- Confirm the procurement.
- Run the procurement.
- Open the purchase order that it generated.
- Confirm the purchase order.
- Approve the purchase order.
- Open the incoming shipment that it generated.
- Receive the shipment.

Expected behaviour:
At this point, I would expect the procurement to be done.

Actual behaviour:
The procurement is still in the ready state. Running the scheduler makes no change. If you open the stock move associated with the procurement and mark it as done, then the procurement is done. You might need to run the scheduler first, I can't remember.

Analysis:
The procurement work flow transition from ready to done requires action_check_finnished() to succeed. That checks that the stock move is complete. I happened to notice that action_done() will mark the stock move as complete if the close_move field is true, but action_done won't trigger until the procurement gets to the done state. Catch-22. Perhaps there's some other code that is supposed to mark the stock move as complete, but the close_move field seems like it would never be useful.

See original description

Related branches

lp://staging/~donkirkby/openobject-addons/complete-procurement
Olivier Dony (Odoo): Approve
OpenERP Core Team: Pending requested
Diff: 164 lines (+135/-2)
3 files modified
mrp/__terp__.py (+1/-1)
mrp/mrp_test.xml (+122/-0)
purchase/purchase.py (+12/-1)
Revision history for this message
gpa(OpenERP) (gpa-openerp) wrote :

Hello Don Kirkby ,

Please use the latest code of the addons and server because currently the revision 2631 and 1999 respectively .I have followed all the steps which you had specified in the bug.But i did not reproduce it at my end.
Can you check again your side after updating your code.If you will face similar problem again attach the proper screen shot.
As I did not faced any problem at my end.

Thanks.

Changed in openobject-addons:
status: New → Incomplete
Don Kirkby (donkirkby)
description: updated
Revision history for this message
Don Kirkby (donkirkby) wrote :

I tried it again with revision 2631 and 1999, but I still see the problem. Have you tried running the unit test in my merge proposal?

I'm attaching a screen shot of the procurement stuck in the ready state. I tried running the scheduler, and it's still in the ready state.

I made a couple of clarifications in the bug description: choose the Manufacturing Industry profile for the demo data, and use the Stock location for the procurement.

Don Kirkby (donkirkby)
Changed in openobject-addons:
status: Incomplete → New
Jay Vora (Serpent Consulting Services) (jayvora)
Changed in openobject-addons:
assignee: nobody → Olivier Dony (OpenERP) (odo)
DBR (OpenERP) (dbr-openerp)
Changed in openobject-addons:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Don Kirkby (donkirkby) wrote :

The merge proposal now contains a fix as well as the test.

Revision history for this message
MarianTheisen (marian-n) wrote :

this problem exists in 6.0 as well and messes up the whole make to stock dispositioning process

Revision history for this message
MarianTheisen (marian-n) wrote :

why isn't this fixed, and why is importance low?
without this patch you simply cannot use 'make_to_stock' procurement, as those procurements stuck in 'ready' state prohibit the procurement of the same product a second time.

Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c)
Changed in openobject-addons:
importance: Low → High
Revision history for this message
Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c) wrote :

Dear OpenERP team,

This is IMHO not a "low" priority bug... That let procurement stuck in open and ready state, preventing the company to order product the next time a customer order it... So they cannot deliver their customer after the first delivery of a product.

I reviewed the priority to "high"...

Moreover, I tested the Don Kirkby branch and it seems to perfectly fix the trouble... So as Olivier Dony agreed on the merge proposal, please merge this ASAP !

Thanks in advance,

Regards,

Joël

Revision history for this message
Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c) wrote :

Just one thing more: Please check that on v6.0 cause as MarianTheisen said, this seems to be also true on v6.0 !!

Thanks !

Joël

Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

Hello,

Sorry, this bug had fallen outside of our bug management radar (due to being assigned to an individual), thanks to Joel for helping dig it out.

Let's have an update on the status:

- in 6.0 and trunk this cannot be reproduced at all - I just tried again in trunk and 6.0.3 with the steps described by Don, and it works fine. I also tried with a minimum stock rule (order point) and it works fine too - it can trigger multiple procurements.

- the reason why it works in 6.0 and trunk is because in 6.0 we changed the procurements to automatically turn on the 'auto_validate' flag of their stock move when the move is created[1]. This happens when it is confirmed, except when the stock move was already created. This last case is important because it allows the make-to-order (MTO) flows: when the procurement is created by a sale order containing an MTO product, you don't want the procurement to complete and the customer delivery to happen automatically when the products are received from the supplier!

Based on the above:

@MarianTheisen: I do not understand your comments for 6.0. Could you be more specific, and perhaps provide some steps to reproduce? The steps in the bug description do not produce the bug in 6.0.3 for me.

@Joel, you confirm that 5.0 still has the problem, but could you be more specific as to why you say that this is "preventing the company to order product the next time a customer order it". Are you talking about minimum stock rules? Can you perhaps provide simple steps to reproduce? Based on that we could accept a high priority to the bug in 5.0 - and assign it to the relevant team (you know the policy)

@Don, I'm terribly sorry I failed to follow-up on the merge proposal - this is probably due to the change of our internal bug management process[2], where verified bugs are now assigned to predefined teams . Luckily we fixed the bug in the mean time in 6.0/trunk, and the test you provided is now converted as a YAML test in the purchase module (please double-check [3], but I think it is the case). Thanks a lot for your excellent contribution, as always!

[1] addons revision <email address hidden> : http://bazaar.launchpad.net/~<email address hidden>
[2] http://bit.ly/openerp-bug-process
[3] http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/view/head:/purchase/test/procurement_buy.yml

Changed in openobject-addons:
assignee: Olivier Dony (OpenERP) (odo) → nobody
importance: High → Undecided
status: Confirmed → Fix Released
Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

*creating a separate target for 5.0, to handle status separately

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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