[IMP] rma: configurable workflow #417
Conversation
|
Hi @chienandalu, @pedrobaeza, |
sbejaoui
force-pushed
the
16.0-rma_configurable_workflow
branch
2 times, most recently
from
6fcef2e to
387d02c
Compare
rma/models/rma.py
Outdated
| ) | ||
|
|
||
| # Replace fields, used when the delivery is created automatically | ||
| replace_warehouse_id = fields.Many2one( |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Please add the post_init_hook/migration script thus.
There was a problem hiding this comment.
@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?
sbejaoui
force-pushed
the
16.0-rma_configurable_workflow
branch
from
387d02c to
221d30d
Compare
sbejaoui
force-pushed
the
16.0-rma_configurable_workflow
branch
9 times, most recently
from
02b9604 to
5261de6
Compare
sbejaoui
force-pushed
the
16.0-rma_configurable_workflow
branch
2 times, most recently
from
4f00835 to
9737b31
Compare
sbejaoui
force-pushed
the
16.0-rma_configurable_workflow
branch
2 times, most recently
from
a3d5c26 to
0712bb6
Compare
|
This PR has the |
|
There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. |
github-actions
bot
added
the
stale
rousseldenis
removed
the
stale
sbejaoui
force-pushed
the
16.0-rma_configurable_workflow
branch
from
1d5bce5 to
8079bb8
Compare
|
/ocabot merge major |
|
This PR looks fantastic, let's merge it! |
|
Congratulations, your PR was merged at 0b00997. Thanks a lot for contributing to OCA. ❤️ |
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