1. Mailing Lists
  2. Contributors
  3. [RFC][9.0] RMA (Return Merchandise Authorization)

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

setuptools-odoo: packaging multiple addons

Re: website manifest key in OCA addons

Avatar

[RFC][9.0] RMA (Return Merchandise Authorization)

by
ForgeFlow, S.L., Aarón Henríquez
- 17/03/2017 18:15:54
Dear Contributors,

Lately, we have been working int a new RMA tool for Odoo9 and newer. 

As you know there's an RMA tool in versions 7 and 8. However we consider that it is not very comfortable to manage a very complex process like RMA from a more simple process like claims:
  • Claims were designed for tracking customer claims and grievances not for a RMA process. Adding an RMA functionality to the claims makes it impossible to use claims for other processes. 
  • Claims will be removed in 10.0
  • We want to align more to the orthogonal design built by Odoo in purchase and sales orders. Remove workflows.

After reviewing the documentation about RMA and evaluating the evolution of Odoo across versions we consider that the RMA tool should:
  • Be easy to use
  • Have full traceability
  • Control all the follow-up processes from the RMA
  • Give the user the proper information to take decisions instead of suggest the next action
According to this we have design a tool based on the following functional approach:
  • We distinguish two basic types of RMA. Customer and Supplier.
  • A Customer RMA can be created either from a sales order or a customer invoice.
  • A Supplier RMA can be created either from a purchase order or a supplier invoice.
  • Simple RMA approval workflow. Can be extended if needed by means of additional modules.
  • Operations (replace, repair, refund) control the flow in each RMA line. They define how much is expected to be received, refunded and delivered. 
  • The company can define default operations for each product category.
  • The user can create the necessary pickings or refunds from the RMA lines.
  • According to the operation requested (replace, repair or refund), the system will calculate key information for the user to make appropriate decisions: Qty to receive, Qty incoming, Qty to deliver, Qty to refund, Qty received, Qty outgoing, Qty delivered.
  • There’s no constraint when creating moves or refunds. It’s possible to refund more quantity than the required or receive/send more quantity than the quantity required. The user will know the state of the RMA by looking at the quantities.
  • When the user considers the process is finished he can set the RMA record to Done manually.
  • From the RMA and RMA lines we have access to the sourced invoices and the sourced SO and PO if any, as well as to the generated refunds, receipts and deliveries.
  • We can search by RMA number in the standard invoices, sale orders and purchase orders view. In the form view of them lines we will see the RMA lines involved.
In order to discuss this approach we have created an Issue on github: https://github.com/OCA/rma/issues/111

We have created a PR to OCA here: https://github.com/OCA/rma/pull/110

Among the found issues we are not sure about the possibility of creating RMA from Sale Order Lines or Purchase Order Lines that have not yet been invoiced.

You can test our approach on runbot and give us some feedback either in the PR or in the Issue. If you like this approach we can schedule a webinar to explain the design to the community.

Best Regards,