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 protected] : http://bazaar.launchpad.net/~openerp/openobject-addons/6.0/revision/[email protected] [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 Importance: High => Undecided ** Changed in: openobject-addons Status: Confirmed => Fix Released ** Changed in: openobject-addons Assignee: Olivier Dony (OpenERP) (odo) => (unassigned) ** Also affects: openobject-addons/5.0 Importance: Undecided Status: New -- You received this bug notification because you are a member of C2C OERPScenario, which is subscribed to the OpenERP Project Group. https://bugs.launchpad.net/bugs/532148 Title: Procurement stuck in ready state after purchase is completed Status in OpenERP Modules (addons): Fix Released Status in OpenERP Addons 5.0 series: Incomplete 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. To manage notifications about this bug go to: https://bugs.launchpad.net/openobject-addons/+bug/532148/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~c2c-oerpscenario Post to : [email protected] Unsubscribe : https://launchpad.net/~c2c-oerpscenario More help : https://help.launchpad.net/ListHelp
