Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RMA : configurable workflow #413

Open
sbejaoui opened this issue Jul 23, 2024 · 2 comments · May be fixed by #417
Open

RMA : configurable workflow #413

sbejaoui opened this issue Jul 23, 2024 · 2 comments · May be fixed by #417

Comments

@sbejaoui
Copy link
Contributor

sbejaoui commented Jul 23, 2024

The RMA operation flow varies from company to company. Each company chooses its own process for managing returns, exchanges, and refunds.

The current version of the RMA base modules covers almost all use cases but lacks flexibility. More advanced use cases require a more configurable workflow.

For instance:

  1. Refund without product return: Some companies may offer refunds without requiring the return of the product, often in cases of low-value items or when the cost of return shipping is prohibitive.
  2. Return and exchange of the same product: Customers may want to return a defective item and receive an identical replacement.
  3. Return of a non-ordered product: Occasionally, customers receive items they did not order and need a process for returning these products. The delivered product don't figure on the sale order
  4. Return and exchange with a different product: In some situations, customers may prefer to exchange the returned product for a different item, rather than receiving a refund or a direct replacement.

In addition to these use cases, when a company manages its own transportation, it may choose to pick up the returned product and deliver the replacement product simultaneously. This approach necessitates the creation of both the delivery order and the receipt order at the same time when the RMA is confirmed

If we summrize

Use Case Need return Need delivery Need refund
Refund without product return No No Yes
Return and exchange same product Yes Yes No
Return of non-ordered product Yes (return for a product different than the SO product) No No
Return and exchange with different product Yes Yes No

One way to manage these different use cases is to review the rigid flow and make it configurable based on the selected operation. We can imagine

  • Add three selection fields to rma.operation model that define when each action should happen:
Action Timing Options Description
Create return - On confirm Initiate the return process as soon as the RMA is confirmed.
- After receipt Create the return order only after the returned product is received.
Create delivery - On confirm Start the delivery process immediately upon RMA confirmation.
- After receipt Wait to create the delivery order until the returned product is received.
Create refund - On confirm Issue the refund as soon as the RMA is confirmed.
- After receipt Process the refund only after the product is received and inspected.
- Update SO delivered quantity Adjust the sales order's delivered quantity based on the returned product. The refund will be generated from the SO.
  • Add a checkbox to the rma.operation model to define whether the product to be returned is different from the ordered product (use case 3).
  • Add a checkbox to the rma.operation model to define whether the product to be delivered is different from the ordered product (use case 4).
  • Add two fields to the rma model to define the product to be returned and the product to be delivered. By default, these two fields are hidden and have the same value as the ordered product. Their visibility depends on the selected operation.

I will appreciate your input and feedback on the proposed implementation.

cc/ @pedrobaeza , @jbaudoux , @lmignon , @rousseldenis , @phschmidt

@lmignon
Copy link

lmignon commented Jul 25, 2024

@sbejaoui All this makes sense. But AFAIK when a 'return' is created from an outgoring picking for a move linked to a SO, the refund is automatically created. How do you plan to prevent this behavior(or I misunderstand the default behavior)

@pedrobaeza
Copy link
Member

Thanks for the excellent summary. Yes, rma.operation can be the enough granular model to reflect that possible workflows.

Then, changing visibility of buttons and triggered flows depending on these values is just a question of being methodical. Eagering to see it.

@lmignon right now, the return is not linked to the SO line while we don't create the refund, for avoiding a change on the invoiceability of the order. Check

def _link_refund_with_reception_move(self):

Is that what you ask for?

@sbejaoui sbejaoui linked a pull request Aug 15, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants