Production orders ignore chained location at destination

[Don Kirkby]

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().

[Don Kirkby (donkirkby)]

I assigned this bug to vra since he or she fixed bug lp:428873, and I used a similar fix for this bug. Hope that's OK.

[vrsb (shipilov555)]

Hello. I've tried your fix for production order, but it still doesn't work(

[Don Kirkby (donkirkby)]

Hi @vrsb, can you give me any details about how it doesn't work for you?

[Rucha (Open ERP) (rpa-openerp)]

Hello Don,
It has been fixed in lp:~openerp-dev/openobject-addons/rpa-dev-addons2
revision-id: <email address hidden>
revision-num: 4353.
Thanks for reporting

[Rucha (Open ERP) (rpa-openerp)]

Sorry, the revision-num is 4535...

[Don Kirkby (donkirkby)]

Hi rpa,
Your fix seems very different from mine. Would you be willing to post a brief description of your changes and how they work so I can decide whether I need to replace my fix with yours?
Thanks for the fix.

[Rucha (Open ERP) (rpa-openerp)]

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

[Don Kirkby (donkirkby)]

OK, thanks for the explanation. I guess my fix works in 5.0 and your fix works in 6.0. I'll stick with my fix until I migrate to 6.0.