When canceling a rma order line, it will also cancel the previous (orig) steps.
Following steps (dest) can be managed with the propagate cancel option of the stock rules.
This commit also avoid canceling a whole picking which is problematic in case of the use of RMA groups
When looking at stock moves created from a rma group, it may be confusing knowing who's move is for which RMA line. This improvement should avoid these confusions.
* [14.0][IMP] added default operation on rma group, easy setup before rma lines created
* [IMP] added fields for default route created by wizard on rma group
* fix: get right price after create rma order line
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).
This was not the intended way to add RMA lines to a group.
Users are supposed to use the wizards to do so (add from stock
move, add from serial, etc.). Having the option to use "add
new line" was only leading to errors and confusion.
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.
