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.
Now it's possible to configure if the portal RMA request form is loaded
in a popup or in a single page.
In that page, we can add custom blocks (if the website is installed) a
customize the form text.
In this commit, we also add the possibility to extend the form view to allow
custom fields that will show up in the RMA description.
TT29670
Using move_dest_ids we can easily end in an infinite loop situation as
the return of the return of the return ends with some original moves on
in move_dest_ids. We must ensure to drop them to avoid the infinite
loop.
TT29886
Lesser fix for sale.order.line.rma.wizard methods.
When method '_prepare_rma_values' was called upon records where field 'picking_id' was empty, Odoo raised a CacheError when trying to access field 'move_id'.
That happened because computed method '_compute_move_id' was not assigning a proper value to such field when 'picking_id' was empty.
Once the computed method is fixed (by simply assigning 'False' as 'move_id' value when no picking is set), the CacheError is solved.
Lesser fix for creating RMA from website.
Current values will break any custom behaviour because Many2one fields are set using strings instead of integer (IDs).
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.
