[14.0][IMP] RMA - refactor to use procurement run

[mt-software-de]

This PR replaces all lines where a stock.picking or stock.move is created, by using only procurement group runs.
This helps the RMA modules to easier interact with other stock modules like https://github.com/OCA/wms/tree/14.0/stock_warehouse_flow

Depends on:
OCA/stock-logistics-warehouse#1708
#351

[OCA-git-bot]

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

[mt-software-de]

FYI: @jbaudoux

[mt-software-de]

@pedrobaeza and @chienandalu i will redo the PR #334
Using this PR as an starting point.

[jbaudoux]

Thanks
This approach is a lot better. Routes are now properly evaluated.

[rousseldenis]

The code looks correct (I have to test use cases), but are the delivery_procurement_group_carrier and stock_helper dependencies really necessary (I think not)?

stock_helper provide extra functions in order to reuse code. I think this is a sustainable process. If not, we need to reimplement the functions here.

Sometimes, blind-blocking for such features are non sense (for me 😃 ).

[pedrobaeza]

Sorry, but the modules are right now independent and we don't want to depend on other modules. The feature is interesting, but adding such dependencies not. I don't think the amount of code to repeat is very high.

[mt-software-de]

stock_helper is in fact not needed, but delivery_procurement_group_carrier is needed.
Otherwise it is not possible to set the carrier via the proc group. Please check the change in
rma_delivery/models/rma.py

[rousseldenis]

we don't want to depend on other modules

A good answer would explain why 😃

[pedrobaeza]

A good answer would explain why

It's not the first time I have answered you about this. And you ask us about doing glue modules for certain things, but now want the reverse.

We don't want to have to add extra dependencies in all of our customers, and more being for such an old version. Such dependencies implies more code to maintain in our codebase, possible interactions in integration tests, etc. And they are not really adding value to us. Extra glue modules can be added for such needs.

delivery_procurement_group_carrier is needed. Otherwise it is not possible to set the carrier via the proc group.

You should add that in a glue module IMO.

[mt-software-de]

A good answer would explain why

It's not the first time I have asked you about this. And you ask us about doing glue modules for certain things, but now want the reverse.

We don't want to have to add extra dependencies in all of our customers, and more being for such an old version. Such dependencies implies more code to maintain in our codebase, possible interactions in integration tests, etc. And they are not really adding value to us. Extra glue modules can be added for such needs.

delivery_procurement_group_carrier is needed. Otherwise it is not possible to set the carrier via the proc group.

You should add that in a glue module IMO.

Hmmm. To make this work we need to remove the carrier_id from the proc group and set it like it was done (just with a write)
Than the glue module needs to do the following. Change the rma_delivery method which sets the carrier by write -> to not set it. And set the carrier on the proc group which will then set automatically the carrier.

I don't think that this would be a good approach.
And also this glue module needs to

[TDu]

Reviewed the last commit

[victoralmau]

Finally merged in v16 #392 with some changes (e.g. Change reception_move_ids to reception_move_id), I think PR should be adapted to the same changes.

[OCA-git-bot]

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

[mt-software-de]

Finally merged in v16 #392 with some changes (e.g. Change reception_move_ids to reception_move_id), I think PR should be adapted to the same changes.

Thats good, that there is now finally some progress.
Thanks for change reception_move_ids back to reception_move_id. That's indeed better.

May i raise some issue i have with your approach about how pushed an merged your PR through.
By squashing your commit it is quite hard to backport the changes. And also i can not agree on all changes you made.
Some of them i have now some you to revert and then fw port it again 16.

Why was this PR blocked for so long and your PR was pushed through i don't think that was a convenient way of doing it.

[victoralmau]

I am trying to clarify everything a bit.

This was left pending from #350 (review) until now (otherwise this would have been taken to later versions and adapted as necessary) in order to start with the revision.

These changes were done in v15 (indicating it was a 14.0 FWP) #384 keeping the commit of yours and then adding extra ones with the changes. Finally it was needed already in v16 and that's why #392 was done (there everything was simplified in 1 commit adding you as co-author to avoid that the diff could be reviewed in addition to other necessary changes and reduce the methods that were not necessary).

If there are things that you think you need to change I think it is best to do it in v16 and when everything is ok continue with backports (if you need them).

[mt-software-de]

I am trying to clarify everything a bit.

This was left pending from #350 (review) until now (otherwise this would have been taken to later versions and adapted as necessary) in order to start with the revision.

These changes were done in v15 (indicating it was a 14.0 FWP) #384 keeping the commit of yours and then adding extra ones with the changes. Finally it was needed already in v16 and that's why #392 was done (there everything was simplified in 1 commit adding you as co-author to avoid that the diff could be reviewed in addition to other necessary changes and reduce the methods that were not necessary).

If there are things that you think you need to change I think it is best to do it in v16 and when everything is ok continue with backports (if you need them).

Yes i have seen what you have done, but exactly thats the point, which i think is not convenient.
Because no i have to check what you changed, in my commit because there are no separate commits for it.
As well you added on the commit message me as as co-author but also im the author if the commit. 08a492c

The annoying thing for me is right now, that i have now more worked to do. Somehow i really don't know why this one was blocked.
I would be much easier if we would have merged this one and changed your suggestions and then fw port it then.

[lmignon]

@mt-software-de IMO it could be easier to revert the commit in V16 and reapply yours. Do you plan to make a PR for reintroducing the missing pieces in V16? If not, we can do it on our own while adding any relevant improvements from 2179cc5 and the test from 9bbe997

[mt-software-de]

@mt-software-de IMO it could be easier to revert the commit in V16 and reapply yours. Do you plan to make a PR for reintroducing the missing pieces in V16? If not, we can do it on our own while adding any relevant improvements from 2179cc5 and then test from 9bbe997

No i am not planing to do it. I also think implementing the relevant improvements here and the revert the changes would be the easiest way.

[mt-software-de]

@sbejaoui could you please review this PR.

[mt-software-de]

@jbaudoux @rousseldenis re-review this?
@lmignon @TDu could you please review this?

It would be nice to merge this finally and then FW Port it do v16. #403

[victoralmau]

#403