[stock_location][7.0][trunk] Pull flows do not create procurement internal moves

[Mohammad Alhashash]

Important note: Reproduction of this bug depends on the order of workflow transition checks. If it does not reproduce, upgrading the 'stock_location' module may change the evaluation order.

Create a make-to-order pull flow for a stockable product A in location X from location Y. Create an order point for product A in X and run the scheduler.

Procurement order state changes to 'Ready' but no move from Y to X is created. Only a move from 'Virtual locations/Procurement' to X.

The problem is caused by the workflow transition 'procurement.trans_confirm_mto_make_done'. It moves the procurement from 'confirm_mto' activity directly to 'ready' using the condition 'not check_produce() and not check_buy()' and will not allow executing 'stock_location.trans_confirm_mto_buy01' trasition which should have moved the procurement to 'move' state to call 'action_move_create()' .

The solution is to change the condition of 'procurement.trans_confirm_mto_make_done' to be 'not check_produce() and not check_buy() and not check_move'.

Regards,

Mohammad Alhashash

[Amit Parik (amit-parik)]

Hello Mohammand,

Internal move from pull flow rule you have to select Shipping Type = Move and Type of Procurement = Move then it will create a internal move and stock move for the pull flow.

I have attached a video which shows you all are working fine with good configuration, So would you please check it and notify us have you still faced the problem or not.

Thanks and waiting for your reply!

[Mohammad Alhashash (alhashash)]

Thanks Amit for your response.

Actually, I used 'Move' type but I did not mention it as I though it is obvious (and it is the default).

Kindly, check the procurement workflow with the module 'stock_location' installed. The problem is that when there is a move pull flow available for MTO procurment, we have two workflow transitions with True conditions at the activity 'confirm_mto'; one with condition 'not check_produce() and not check_buy()' and another with condition 'check_move()'. Both conditions would yield True value but since we have XOR split, the first transition returned by the database will win.

The workflow engine, function _split_test() in workitem.py, reads the transitions with no specific order. So, the order will be arbitrary if the table is small that the database will use sequential scan not the index (usually, last updated last). To check the actual order use this query:

    select * from wkf_transition where act_from=(select id from wkf_activity where name='confirm_mto');

If the transition with the condition='check_move()' is the last one, the bug will reproduce.

To change the order, you can run this query (may be several times):

    update wkf_transition set id=id where condition='check_move()';

Thanks and best regards,

Mohammad Alhashash

[PJ (johne-3)]

Thank you for the video!
I have set up everything the way you propose, yet it does not create the internal move.
I am not that tech savy to understand what you guys were talking about in detail.
Can you please put me to the solution?
I am running openerp 7 and there are no updates for the addons module.
Thanks again!

[Christophe CHAUVET (christophe-chauvet)]

Hi

When i read the first line on this bug report, i think the first problem is a missing "order by id" on method _split_test

http://bazaar.launchpad.net/~openerp/openobject-server/7.0/view/head:/openerp/workflow/workitem.py#L151

the problem disappear when the full vacuum in PostgreSQL is launched.

Regards,

[Martin Trigaux (OpenERP) (mat-openerp)]

Hello guys,

I agree the double validation is a problem. This was fixed with Mohammad's patch in addons 7.0. Thanks for the report

revno: 9581 [merge]
revision-id: <email address hidden>