Extra changes:
- Change reception_move_ids to reception_move_id
- Add test_rma_replace_pick_ship
- Code and method reduction to simplify logic
- Set route_ids (in/out) from procurements
Co-authored-by: Michael Tietz
TT48789
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
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
- Now it's possible to open several RMAs in a sale order from the portal
- A new comment button has been added to allow the portal user to enter
relevant information like serial numbers o issue description.
- If the requested operation isn't set no RMA will be opened
- The RMA product qty is now a numeric control with limits according to
the qty available to return
[FIX] rma,rma_sale: fix linter errors
[UPD] Update rma_sale.pot
rma_sale 12.0.1.4.0
Update translation files
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.
Translation: rma-12.0/rma-12.0-rma_sale
Translate-URL: https://translation.odoo-community.org/projects/rma-12-0/rma-12-0-rma_sale/
- Fix thrown error when trying to download a picking from the portal.
- Add the hook method to prepare RMA values from the return pick wizard.
- Add the access rule for portal users.
- Show the portal 'Request RMAs' button on the sales page only to users
related to the sales order.
[UPD] Update rma_sale.pot
rma_sale 12.0.1.3.0
Update translation files
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.
Translation: rma-12.0/rma-12.0-rma_sale
Translate-URL: https://translation.odoo-community.org/projects/rma-12-0/rma-12-0-rma_sale/
