Steps to reproduce:
- Create a sales order with an storable product with invoicing policy
on delivered quantities.
- Confirm it and deliver the product.
- Invoice the order.
- Do an RMA, receive it, and refund it.
Result: the delivered quantity is 1 instead of 0.
This is because the refund generated from the RMA is not linked to
sales order line, nor the RMA reception move. This is done because
other operations are performed:
- Be replaced.
- Be changed by other product.
And we don't also want that meanwhile the RMA is being performed, the
sales order is pending to invoice.
But when the refund has been done, we have it clear, so let's link both
and have sales statistics correct.
FIX: We don't link the refund line with the sales order if the RMA
quantity is not the whole original move quantity. Otherwise, we will
have incoherente delivered/invoiced quantities on the sales order.
TT41645
For avoiding a big list of IDs being transferred when no sales order
is selected on the RMA, we have changed domains to make use of the
possibility of pyjs expressions allowed in the domains.
No ternary operators nor list sums are allowed in pyjs, but using a
combination of allowed IDs with a controlled length of values + and/or
operators to switch domains is enough for having the right performance
and avoid to depend on other modules like web_domain_field.
When a sale line has a phantom product (mrp kits) the RMA would not be
possible as the wizard couldn't pair the components moves with the
product in the line. With this approach, we can at least return the
spare components of the original kit line.
We also need some hooks to intervine in the main methods, like in
invoicing.
- Proper dependency is `sale_stock`, not `sale`, as we are using some fields added
by this module.
- Propagate salesman from sales order when available.
TT25525
rma_sale 12.0.1.4.1
