RMA : configurable workflow

[sbejaoui]

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]

@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]

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

rma/rma_sale/models/rma.py

Line 96 in 3436ec6

def _link_refund_with_reception_move(self):

Is that what you ask for?

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.