c2c-oerpscenario team mailing list archive

["rpa \(Open ERP\)" <535401@xxxxxxxxxxxxxxxxxx>]

Hello Don,
thanks for the comment,
I have checked your fix but it doesn't fix the problem, (may be because its very old fix),
The old code was writing state of move directly like:
=== modified file 'mrp/mrp.py'
--- mrp/mrp.py	2010-12-13 04:45:34 +0000
+++ mrp/mrp.py	2010-12-15 11:16:00 +0000
@@ -705,10 +704,7 @@
                             stock_mov_obj.action_consume(cr, uid, [raw_product.id], consumed_qty, production.location_src_id.id, context=context)
 
         if production_mode == 'consume_produce':
-            # To produce remaining qty of final product
-            vals = {'state':'confirmed'}
-            final_product_todo = [x.id for x in production.move_created_ids]
-            stock_mov_obj.write(cr, uid, final_product_todo, vals)
+
             produced_products = {}
             for produced_product in production.move_created_ids2:
                 if produced_product.scrapped:

and the chained picking is created only when action_confirm() is called,
So the goal of the fix was to call proper function of stock.move for state changes,
Hope this helps,
Thanks

-- 
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/535401

Title:
  Production orders ignore chained location at destination

Status in OpenObject Addons Modules:
  Fix Released
Status in OpenObject Addons 5.0 series:
  In Progress
Status in OpenObject Addons trunk series:
  Fix Released

Bug description:
  This bug is very similar to bug lp:428873, but with production orders instead of purchase orders. I have tested it on the 5.0.7 tagged revision.

I will create a merge proposal with a failing unit test and a proposed fix.

Steps to reproduce with the demo data:
1. Create a new location "Holding" that is chained to the "Workshop" location. That is, any stock moves to "Holding" should generate another move from "Holding" to "Workshop". The move type doesn't matter.
2. Create a production order for PC1 with Holding as the destination location. Quantity is 1.
3. Look at the virtual stock of PC1 in the Holding location.
Expected behaviour: virtual stock should be 0 because the stock should be moved on to the Workshop location.
Actual behaviour: virtual stock is 1.

Analysis:
The fix for lp:428873 seems like it can apply here as well: just add a call to stock_move.action_confirm() in mrp_production.action_confirm(). One thing I'm not sure of is why lp:428873 adds a call to stock_move.force_assign().