odoo/odoo#256248

Created by fw-bot

label

odoo-dev:saas-19.2-19.0-opw-6010109-mto_double_update-lase-512334-fw

head

8a3b4c0df1b7295ece45e158300b009ff28fcb68

merged

1 day ago by Bugfix, Lancelot Semal (lase)

[FIX] stock, {sale_,mrp}: update MTO manufacture on move dest cancel

Issues:

Cancelling the move dest of a manufacturing order does not cancel the MO nor log's an activity warning for the responsible to update the manufacturing demand manually.

Additionally, when selling MTO manufactured products, cancelling the delivery and then changing the sol's demand will update the MO for an incorrect amount.

Steps to reproduce:

• In the settings: Enable Multi-Steps Routes
• Inventory > Configuration > Warehouse Management > Routes
• Unarchive the MTO route
• Create an MTO product with BOM
• Create and confirm an SO for 3 units of that product
• Cancel the delivery of 3 units
  > There is no notification on the unrelevant MO linked to the SO
• Adapt the quantity of the SOL from 3 to 10

> A Delivery is created for 8 units and the MO's demand is updated from 3 to 11

Expected behavior:

Since the the SOL demand is updated to 10 units and none are currently delivered, a delivery for 10 units should be created and the MTO behavior should therefore add 10 units to be manufactured.

Cause of the issue:

Adapting the quantity on the sale order from 3 to 10 will launch a call of the _action_launch_stock_rule with a previous_product_uom_qty of 3. The purpose of this call being to create and run a procurement to fulfill the new demand:
https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/sale_order_line.py#L388-L402
The demand of this procurement is therefore matching the new quantity of the sol minus the qty that is already handled by other procurements (determined by the _get_qty_procurement method): https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/sale_order_line.py#L310-L320
Note that this _get_qty_procurement call should determine the qty that is already planned to be delivered to and returned by the customer. In particular, this _get_qty_procurement call should return a value of 0.0 because the entire delivery has been cancelled and nothing is expected to be returned from the customer. However, the call will return an unexpected value of -3.0 units which will in turn provide a procurement to the customer location for 5 - (-3) = 8 units and hence lead to the creation of a delivery for 8 units and adapt the MO by MTO for 8 additional units.

The discrepancy happening in the _get_qty_procurement is due to two recent changes. To begin with, since the 19.0 version the move_finished_ids of the production is linked to the sol (part of its move_ids) because of these lines:
https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/stock.py#L134-L139 This change ensuring that MO created by MTO is linked to the SO see 2713876dbc70d3984e584a9037a2206dcda4e84a for more details.

As such, the move of the produced product can now be part of the moves initially considered in the _get_outgoing_incoming_moves and that should be filtered out to not be accounted in the qty handled by the current sol:
https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/sale_order_line.py#L322-L331

Now, the reason this production move is not excluded from the incoming move pool is because of the change of this other fix: 37f1377344864770cd2a745dd4cb6999af07bbdf https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/sale_stock/models/sale_order_line.py#L353-L358 To be more precise, while the move is not not a refund, it satisfies the second part of the condition that move.rule_id.id in triggering_rule_ids for the incorrect reason that the move has no rule_id so that and that move.rule_id.id is False and the triggering_rule_ids contains the False value but this key is irrelevant and should never have been added as the purpose of the triggering_rule_ids list is to keep track of rules starting a push chain.

Additional Note

The setUpClass of the TestSaleMrpFlowCommon test class fails since 8bbdc99b565b3f678e11cd8889c47dad8944608f because the tracking
field is not present in the product form view if if the user does not have the stock.group_production_lot group:
https://github.com/odoo/odoo/blob/58fb55defee005beb44edb60d2abe044fc99121a/addons/stock/views/product_views.xml#L189
But it is suppose to be reset in the setup:
https://github.com/odoo/odoo/blob/58fb55defee005beb44edb60d2abe044fc99121a/addons/sale_mrp/tests/test_sale_mrp_flow.py#L145-L149

opw-6010109
opw-5885741
runbot-240920

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: #254636