[11.0][MIG] mrp_auto_assign

[LoisRForgeFlow]

Migration to v11.

cc @florian-dacosta

[LoisRForgeFlow]

I identified a problem with the module mrp_mto_with_stock while migrating this one so I fixed the issue here: 6f2a889

[florian-dacosta]

Useless import

[florian-dacosta]

I see the problem. It would be nice to add a test to show the problem, so we avoid a regression on next migration.

But I don't think this change fixes the problem fully. For instance, if the raw material is purchased instead of manufactured, the system will create a draft PO instead of a MO. In this case, and until the PO is validated, the move.mapped('move_orig_ids.product_uom_qty') will always be 0 (because the incoming shipment is not yet created) and the bug will still happen.

IMHO, after creating the raw material MO or PO, we should :

1. write procure_method = 'make_to_order' on the raw material stock move that need the sub MO/PO
2. Recompute its state so it become 'waiting' (method _recompute_state)
   This way, we have the same data as if the raw material product is configured with route make to order.

Then we can add the procure_method field in the condition :

if move.state in ('partially_available', 'confirmed') \
                         and move.location_id in \
                         move.product_id.mrp_mts_mto_location_ids \
                         and not mto_with_no_move_dest_id and move.procure_method != 'make_to_order':

This way, a raw material move that has already generated a sub MO/PO won't be taken into account anymore and it works for the purchase raw material case.

Indeed, with the present way, what I don't like is that the raw material moves states and procurement method are not coherent with what really happen. (When a stock move waits another move, it has to be in waiting state, not confirmed

For the second case (mto_with_no_move_dest_id checked) I don't think there is any problem. I guess we could also put move.procure_method != 'make_to_order' in the main condition. But for this case, we should not write the procure_method to make_to_order, as there are no link between the sub MOs/POs and the main.

What do you think?
Do you know if the bug is also present in version 10?

[LoisRForgeFlow]

You are right, the issue will still be persistent with POs. I like your approach, to actually manage them as make_to_order it's indeed a improvement , the problem is odoo does allow a easy modification to the procure_method, see.

I will try to play around it and extend the tests.

No, the bug is not present in v10 as there were procurement.orders.

[LoisRForgeFlow]

@florian-dacosta I think it should be good now. I saw that what I did finally was what you were saying on the first place, I guess I misunderstood you a little bit on my previous comment. Anyway, it is ready now!

[florian-dacosta]

Test + code review 👍
Thanks a lot @lreficent

It would be nice to merge this fast as the bug is quite serious. @bodedra @jbeficent @guewen @max3903

[bodedra]

May you review minor improvement at ForgeFlow#4

[LoisRForgeFlow]

Hi @bodedra @florian-dacosta

I've made a rework of mrp_mto_with_stock module here: #278

The fix done here it's not the good one I think. Can you please review?

[florian-dacosta]

Since maybe the fix on mrp_mto_with_stock of this PR won't be applied (if the PR 278 is accepted), can you split this PR in order to only let the mrp_auto_assign migration?

[LoisRForgeFlow]

@florian-dacosta yes, done!

[florian-dacosta]

Thanks!
👍

[LoisRForgeFlow]

Rebased and 🍏 !