mrp_jit leaves procurement with exception

[Don Kirkby]

I can reproduce this in a new database with the demo data when mrp_jit is installed.

I create a sales order for Bank Wealthy and Sons for 1 basic PC [PC1]. I confirm the sales order.
When I look in Stock Management: Outgoing Products: Available Packing, I expect to see the packing list for my order, but it's not there.
When I look at the procurement orders, I see one in exception state.
There are two ways to resolve the exception and make the packing list appear:
1. Open the procurement order and click the retry button.
2. Run the Compute All Schedulers wizard.

However, JIT isn't very useful if I still have to run the scheduler all the time.

Analysis:
When the procurement workflow tries to transition from confirm_mts to make_to_stock, it executes mrp_procurement.check_make_to_stock(). During that method, it calls stock_move.action_assign() on the stock move, but this fails because the stock move is still in the draft state. When you retry the procurement, the stock move has been confirmed and the transition succeeds.

I am running the addons 5.0 branch up to revision 2582 (Feb 15, 2010) on Ubuntu 9.10.

[Vinay Rana (OpenERP) (vra-openerp)]

Hello Don Kirkby ,

If you want this in automatically you need to start the scheduler from Administration/Configuration/Scheduler/Scheduled Actions menu,which is created through mrp_jit module.So You were install the mrp_jit module but did not use its scheduler.

Hope now you will understand the matter, currently i have closed this bug. You are free to reopen this if you will face the problem.

Thanks.

[Don Kirkby (donkirkby)]

Thanks for your response. Are you sure I have to run the scheduler? Here's a quote from the mrp_jit documentation at http://doc.openerp.com/technical_guide/mrp_jit.html

    If you install this module, you will not have to run the schedulers anymore.
    Each document is computed in real time.

I looked at the source code for the mrp_jit module, and all it does is remove the "button_check" signal filter on the procurement workflow transition between the "confirm" and "confirm_wait" activities. It doesn't seem to add any scheduled actions or change the existing one.

[Stephane Wirtel (OpenERP) (stephane-openerp)]

If we can fix this bug during this week, the merge proposal will be accepted and integrated into the 5.0.7 milestone.
Else, in 5.0.8

[Vinay Rana (OpenERP) (vra-openerp)]

Hello Don Kirkby,

Can you apply the attached patch and notify me?

Thanks.

[Don Kirkby (donkirkby)]

Hello vra, thanks for the patch.

Looks like I left out some details in the bug description. Aside from leaving the procurement order in the exception state, the work flow is not generating an available packing list for the sales order I just created. I have now updated the bug description to include that.

Your patch changes the procurement order from the exception state to the running state, but still doesn't generate the available packing list.

Have you looked at my merge proposal? Maybe you know the work flow well enough to see how it can be tweaked and not require the button_restart signal that I used.

[Olivier Dony (Odoo) (odo-openerp)]

This behavior was broken by revision 1634 on openobject-addons, which changed the initial state of the stock.moves created by the sale.order from waiting to draft.
I will find a proper fix which does need the button_restart hack, but before creating the merge proposal I'd like to have a corresponding XML test for mrp-jit.

I'll try to have that ready by tomorrow.

[Olivier Dony (Odoo) (odo-openerp)]

As explained in the merge proposal review:

The workaround I propose instead of this 'button_restart' hack, and short of reverting rev 1634, is to allow mrp.procurement.action_confirm() to also confirm draft stock.moves, not just 'waiting' ones. This change also seems sensible and correct to me.

The patch is trivial but I still need a test case before landing it on stable. Hopefully I will be able to do that tomorrow before 5.0.7.

See attached patch if you can help test it.

[Olivier Dony (Odoo) (odo-openerp)]

Note: sorry, by 'test case' I meant an XML test scenario that can be made part of mrp_jit module.

[Olivier Dony (Odoo) (odo-openerp)]

Bugfix landed in revision 2618, including smoke tests for regressions in sale module and mrp_jit.

And Don, thanks for the bug report, the proposed patch and follow-up!

This one should be in time to be released with 5.0.7 :-)

[Ana Juaristi Olalde (ajuaristio)]

Hi Olivier and every people here:

I think this bug is also related someway to this one.
https://bugs.launchpad.net/openobject-addons/+bug/519034

Is this patch solving the heavily discussed need of runing scheduler shown on this bug????

Thank you!!!

[Don Kirkby (donkirkby)]

The fix works for me. Thanks, Olivier.

[Olivier Dony (Odoo) (odo-openerp)]

On 27/02/10 01:06, Ana Juaristi Olalde wrote:
> Hi Olivier and every people here:
>
> I think this bug is also related someway to this one.
> https://bugs.launchpad.net/openobject-addons/+bug/519034
>
> Is this patch solving the heavily discussed need of runing scheduler
> shown on this bug????

I'm not really sure about that, but I will check both things carefully.

Note that in order to fix this bug I have used regression tests so I
will extend them to cover other issues that I can confirm. (One of them
could be bug 531238, for example)

If we provide a regression test for each of these when we fix them, as I
did with this current one, we should be covered in the future.

--
Olivier Dony