c2c-oerpscenario team mailing list archive

["Olivier Dony \(OpenERP\)" <532148@xxxxxxxxxxxxxxxxxx>]

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 odo@xxxxxxxxxxx-20101011191613-aw9753wodzb57wq2 : http://bazaar.launchpad.net/~openerp/openobject-addons/6.0/revision/odo@xxxxxxxxxxx-20101011191613-aw9753wodzb57wq2
[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