[IMP]Separate menus for customer and supplier operations
* Add active field to rma operation
* Added tests
* Fix travis
* Fix create supplier rma from customer rma
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).
