Porting crm_claim_rma to v8 about rma

[mistotebe]

Porting in progress:

• have not touched the copyrights on product_warranty yet, other than that, it is mostly compatible: #23
• rebased crm_claim_number port on top of current 8.0: #17
• started porting crm_claim_rma, but hit a couple of dead ends

I am not sure how to go about picking creation, whether to set up a route+picking type per warehouse and try to use procurements to drive the entire picking process or just create a picking manually or something in between as I'm not sure what the intent was behind the new stock system and have not seen a module that actually taps into it in this way

[sebastienbeau]

Hi thanks for the work, regarding the licence as Akretion is one of the original author I am totally agree for moving under AGPL-v3 ! (I have not idea why it's under GPL, pretty sure it's due to a bad copy paste...)
@jgrandguillaume are you ok for moving under AGPL-v3?

[mistotebe]

Porting ~finished, see above for pull requests.

[eltjor]

Hi thanks for putting the effort in to port this module to v8.0. Is there a timeline for when the it will be complete?

[mistotebe]

This module is feature complete and has been successfully deployed in production environments since (hence some improvements made in the past months).

See limitations in the README and consider your procurement/stock routing set-up which has become too powerful in 8.0 for this module to properly interact with for more complex cases (without unduly expanding its scope and size). Also, bear in mind that while I do not expect there to be much in terms of migration from 7.0, it has not been attempted yet.

Also, I have no idea what the community's stance is on this port vs. the port by Vauxoo that has been proposed (in #26) after I have published mine. Usually, the reasons that a proposal does not get merged boil down to the shortage of reviewers, please consider helping with that if you can.

[pedrobaeza]

Well, this is the third port of the module crm_claim_rma, so this is some kind of crazy. Vauxoo, Eezy and you should collaborate to give a unified PR with all the possible enhancements.

[mistotebe]

@pedrobaeza: Wow, there is third now? I was only aware of #26...

When I created this call for help, there has been no response until code has actually been written and proposed for merging. Need to ping @nhomar and maybe we can get some closure.

@nhomar: can you give #24 a go and maybe list the use cases you think yours handles better in #26 or the requirements not handled there that are essential for you and need to be addressed in crm_claim_rma itself and not any dependant modules? I will try and do the same.

[pedrobaeza]

As yours is the oldest, it should be treated as the preferred one, but @nhomar said that they have improved a little all, so maybe you can try a merge of his work in yours. What do you think?

[mistotebe]

I will have to take a look at what is covered and how. Might take a while since I knew very little about RMA processes before I started the port and might not appreciate the other modules' purpose to be able to do a quick review.

[pedrobaeza]

OK, any effort is appreciated. What I want is to solve this in the best possible way.

[nhomar]

~~Hello @mistotebe ~~
~~
The issue is that when our customers ask us finance this migration, we didn't know about this comments (sorry my bad I didn't see it before), then we tried to migrate everythign without touch the actual functionality (between april and may) and some stuff was not approved by customer analiysis.
~~
At the end we re-do everything on new api (trying to mantain megeable compatibility).
~~
You will be able to see the use cases in the list of tests and let me translate from spanish the user Stories in user side.
~~
And then here we are 3 iterations done by us in our repository to fix everything with the bless of the end user already.
~~
And 2 jobs re-done one here and one on ezee side.
~~
If you look in our code (which I know can have a lot of details internally but is already migrated to new api and with a bunch of unit tests) we tried to finish the migration of 100% of the repository to new api and new WMS.
~~
And as our customer asked us link everything with Logistic, we added such cases also.
~~
That's our actual situation, sadly I had short deadlines and we tried to make everything mergeable and tested to manage only 1 public effort in our side to join the job to the OCA, I can not as you see now expend X more months waiting to have them mergeable, we (vauxoo) sadly have 2 options:
~~
1. Use as it is to move on in the next 20 or 30 features we need to develop.
2. Make a first merge as it is in order to start the process of officialize some job and use the "stable version" in our side.
~~
Why I am affronting this situation?
~~
Because even if we split the job we use a "blessed" version of everything and we are too close to deploy in production, one time we deploy in production I can not affront the job to migrate afterwards from Vauxoo's version to OCA's blessed version, on this point one time we (vauxoo) decide what to do on this moment that will be the version we will use/promote.
~~
Why am I so so insitent on that OCA use our version and not others?.
~~
Let me share with you how is the customer (not names simply the use case).
~~
This customer is a huge Electronic Seller with a huge amout of Parts Customer claimes, usage of serials, AND everything related with 3 internal process Supplier warranty, Its own warranty and QA and repairs.
~~
As you can see it will be really difficult to find a customer with more cases of study where is open to share every single effort to public releases.
~~
Then conclusions about the next steps can be done in the PR I think we are checking how is the best way to manage this situation.
~~
Regards.

A complete version of this message can be seen here:

#26 (comment)

[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.