You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[FIX] stock: Fix neg_moves with location_dest taken from rule
Steps to reproduce:
- Install Sales and Stock
- Activate the multi-step routes setting
- Go to a Delivery route in the warehouse
- Change the `location_dest_id` of the operation type set on the rule
- Enable the "Location Dest. Taken from Rule" checkbox
- Ensure `rule.location_dest_id` and `operation_type.location_dest_id`
are different
- Create a Sales Order (SO) for a product with quantity = 5 and confirm
- Change the SO line quantity to 3 and save
Issue:
A second picking is created with a move taking the product from
`rule.operation_type.location_dest_id -> rule.operation_type.
location_src_id` with quantity = -2.
This happens because the decrease in the SO quantity triggers a
negative move, and this move is not merged with the existing
positive move. Instead, a new move is created in the opposite
direction.
In `_merge_moves`:
https://github.com/odoo/odoo/blob/3c4275fb00255e519f01bf5547eff1db3a59d4b5/addons/stock/models/stock_move.py#L1191-L1193
It checks if the negative move has similar characteristics to the
existing positive moves. However, the `neg_key(neg_move)` differs in
`location_dest_id`, so the merge fails. This happens because the
negative move does **not** read the `location_dest_id` from the rule —
unlike the procurement, which **does** use the rule and therefore
creates positive moves with the correct destination.
When the negative move is created with the procurement, it initially
has the correct `location_dest_id`. But then:
https://github.com/odoo/odoo/blob/b984c72df398c4fe942d8894442e4e893ca0660e/addons/stock/models/stock_move.py#L1191
triggers `_compute_location_dest_id`, which doesn't consider the
`rule.location_dest_id` and defaults to `operation_type.
location_dest_id`, causing the merge to fail due to mismatched
destination_locations.
The positive move has read the correct value, because when it
was assigned to a picking, the picking has the correct destination
from the procurement. But for the neg_move it has picking None so
it maps to the operation_type without consdiering the location from
rule checkbox.
opw-4793171
closesodoo#212355
Signed-off-by: Tiffany Chang (tic) <[email protected]>
0 commit comments