[IMP] rma: configurable workflow

[sbejaoui]

As explained in #413, having a configurable RMA process helps cover more use cases by allowing the configuration of when the three main actions (reception, delivery, and refund) occur.

This PR adds configuration fields to the RMA operation, which allow managing the visibility of these actions in the RMA form. It also adds the possibility to automatically trigger these actions upon RMA confirmation or reception.

To minimize the impact on current users of this module, default values were set for these settings to maintain the existing workflow unchanged. After making these changes, there was no need to adjust the existing unit tests.

fixes: #413

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

[OCA-git-bot]

Hi @chienandalu, @pedrobaeza,
some modules you are maintaining are being modified, check this out!

[pedrobaeza]

The computation of these fields will mean an overhead on existing installations. Why they are needed? This seems a new feature that is not linked with the configurable workflow.

[sbejaoui]

In the operation, if the user selects 'Automatic Delivery' and 'Different Return Product,' the workflow will trigger the replacement action. Since the replacement action requires user input, the replacement information should be filled in the RMA at the time of its creation.

The computed fields for the replacement warehouse and replacement product UoM are intended to provide default values. A migration script can be added to create these columns, ensuring that their computation does not trigger on existing RMAs.

[pedrobaeza]

Please add the post_init_hook/migration script thus.

[sbejaoui]

done

[sbejaoui]

@pedrobaeza ,

@jbaudoux pointed out that replacing a product with a different one can be handled by processing an RMA reception with a refund and then creating a normal sale. I will remove this part I added to the workflow.

Another use case reported by the customer is receiving a different product than the one ordered. In this case, we need to receive a product that is not listed on the sale order and then redeliver the originally ordered product.

I am considering adding a new field, 'product to return,' which will be used if the operation has 'return a different product' set to True.
In this case, the reception will involve the different product. Otherwise, the standard behavior will apply, and the product_id will be used for both reception and delivery.

What are your thoughts on this?