In the current implementation of Odoo's _assign_picking() method in stock.move, there's a conditional check that looks at whether all the moves associated with a picking have the same partner_id and origin. If any move doesn't align with these conditions, the origin of the picking is set to False.
if any(picking.partner_id.id != m.partner_id.id or
picking.origin != m.origin for m in moves):
# If a picking is found, we'll append `move` to its move list and thus its
# `partner_id` and `ref` field will refer to multiple records. In this
# case, we chose to wipe them.
picking.write({
'partner_id': False,
'origin': False,
})
In the context of RMA when we have multiple moves associated with a picking, each coming from a different RMA order line, we encounter a problem. Each move has its origin set as the name of the RMA orde line (line.name), so as soon as a second move from a different line is appended to the picking, the origin of the picking is wiped, because it doesn't match the origin of the first move.
In order to prevent the partner_id of the picking from being set to False when there are multiple associated moves, I propose that we change the origin of the procurement from the name of the RMA line to the name of the procurement group (group.name). This way, all moves associated with a picking will share the same origin, preserving the origin of the picking and ensuring it doesn't get inadvertently set to False.
We shoul not force reservation on next steps on a multi step
route, oherwise a inconsistency is generated and the transfers
cannot be processed or cancel so the user gets stuck ("it is
not possible to unreserve more products that you have in stock"
error).
The goal is to simplify view defintion and do not duplicate
things, requiring to do view changes in two places.
The same change was done from rma lines some time ago.
Without this, some policies are not being copied from the
operation selected when creating new rma line from a rma group.
In v16 this patch and the usage of such onchange can be removed
in favor of (pre)computed stored editable fields for all policies
and configuration in the RMA operation.
When creating pickings, ensure that the applied stock rule was taken from
the operation's routes. Otherwise, the default procurement rules for a
warehouse may kick in, creating incoming customer goods not from the customer
location but from the resupply warehouse.
