You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
Return and exchange of the same product: Customers may want to return a defective item and receive an identical replacement.
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
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.
@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)
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
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:
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
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
rma.operation
model to define whether the product to be returned is different from the ordered product (use case 3).rma.operation
model to define whether the product to be delivered is different from the ordered product (use case 4).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
The text was updated successfully, but these errors were encountered: