Migration to version 15.0

[OCA-git-bot]

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-15.0

Modules to migrate

• hr_commission - By @ernesto-garcia-tecnativa - [15.0][MIG] hr_commission: Migration to version 15.0 #400
• sale_commission - Split into commission, account_commission and sale_commission - By @pedrobaeza / @@AungKoKoLin1997 - [15.0][MIG+REF] sale_commission: Refactorization to split and extract the base #387
• sale_commission_formula > commission_formula - By @AungKoKoLin1997 - [15.0] sale_commission_formula: Migration to 15.0 #377
• sale_commission_pricelist - By @arleite - [15.0][MIG] sale_commission_pricelist #424
• sale_commission_salesman - By @ernesto-garcia-tecnativa - [15.0][MIG] sale_commission_salesman: Migration to version 15.0 #402

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

[pedrobaeza]

My intention for this version is to split the current base module sale_commission into 3:

• commission, which contains the basic definition of agents, commission types, mixins, etc. To add here a differentiation between customer and vendor commission types. This is split also from the next one for being able to have other possible documents to have commissions without the need of the next layer.
• account_commission, that performs the commissions on invoices, looking at the customer/vendor type to put them.
• sale_commission, that performs the commissions on sales orders and propagate them to customer invoices.

Then a theoretical purchase_commission can come for filling such gap.

What do you think about this?

[manuelcalerosolis]

@pedrobaeza, we are interested in migrating to v 15.0, we are missing it, if you think we can start by migrating sale_commission to commission, in a first stage.

[pedrobaeza]

Great, go ahead.

[manuelcalerosolis]

@pedrobaeza

Do you propose changing the name of the tables from "sale.commission" to "commission"?

Or is this change going to be very traumatic for migrations from versions prior to 15.0?

[pedrobaeza]

No, let's do it. Migration scripts can handle that. I will take care of it when merged.

[houssine78]

Hi @manuelcalerosolis @pedrobaeza

I saw that you proposed a refactor of the sale_commission module for v15. I see that Manuel proposed this PR #343 that brings the base module commission.

Then I see the following PR #345 from @slominchar which seems to be a straight port of the v14 module.

Do you have any insight on the actual roadmap ? I'll be glad to make the review as soon I'm fixed of the porting roadmap.

Thanks !

[pedrobaeza]

Yes, you can review such PR, but formally there's a problem with git commits.

[BT-aestebanez]

is there any plan to merge #363 ?

[pedrobaeza]

Not while the PR is not in good state, and the current diff is not correct. I plan to work on it on August.

[BT-aestebanez]

Thanks for the feedback and the estimation :) @BT-fschubert FYI

[ValentinVinagre]

Hi @manuelcalerosolis @pedrobaeza @yostashiro @AungKoKoLin1997 exist in this moment 2 MIG PR's for the commission module in v.15
first -> #363
second -> #372

Which one is currently active? what is left to check? Pedro, how do you see that the modules have been separated? We need the modules for clients, we were waiting to see if this migration would be finished in the summer, but since we have seen that it is not... we want to see what remains to be done.
Thanks 😄

[pedrobaeza]

The problem with both PRs is that they are not doing the split in the best way using correctly git. Do you want to do it, Valentín?

[standingmind]

@pedrobaeza
I want to work in migration of this sale_commission but I want to clear first. We will split sale_commission into 3 modules as you mentioned. But I want to know settlement should be exist in which module?

[AungKoKoLin1997]

The problem with both PRs is that they are not doing the split in the best way using correctly git. Do you want to do it, Valentín?

@pedrobaeza Sorry for my PR. I didn't fully understand this #328 (comment). Now I try to split the current base module sale_commission into 3 modules as you mentioned.

• commission module that contains the basic definition of agents, commission types, mixins.
• account_commission which perform the commission on customer invoices , make settlements and create bills for settlements like the base module's settlement.
• sale_commission that performs the commissions on sales orders and propagate them to customer invoices.

Could you please tell me my understanding is enough or not? And I don't get the main point of why need to split commission and account_commission. I think we can't do anything only with commission module(just my pov). So, I am not sure but should we combine these two into one module?

[pedrobaeza]

commission module that contains the basic definition of agents, commission types, mixins.

Thinking this twice, I think the settlement basic model with lines, having agent, date and amount, it's also a good idea. Later modules will add any kind of extra field for linking with their sources.

And I don't get the main point of why need to split commission and account_commission

The idea here is to avoid dependency on the invoices lines as the source of the settlements. This way, you can have settlements coming directly from sales orders, purchase orders, or any other kind of code that doesn't depend on invoices. Imagine for example a commission system that comes from the leads. We are not implementing this latter, but this design will fit with such requirement.

It's also important to preserve the diffs at minimum for proper commit history and for later investigations on the code history. Let me know if you have doubts about it. If you are going to OCA days at Liége, I will be there, and it's another good occasion to review it together.

[AungKoKoLin1997]

Thinking this twice, I think the settlement basic model with lines, having agent, date and amount, it's also a good idea. Later modules will add any kind of extra field for linking with their sources.

I am thinking about it. Do you mean we create settlement base model like mixin and we inherit this base and create new model and have each settlement menu for other modules like sale_commission, account_commission. I mean we have a sale settlement menu for sale_commission.

How about if we split into 4 modules:

• commission module that contains the basic definition of agents, commission types, mixins and base settlement model.
• account_commission which perform the commission on customer invoices , make settlements and create bills for settlements
• sale_commission that performs the commissions on sales orders and settlement from sale orders.
• sale_account_commission that depends on the account_commission and sale_commission and propagate commission on sale orders to customer invoices.

[pedrobaeza]

More than a mixin, I talk about a full model. All settlements, coming from any source, will generate a record of this model. The difference is that a settlement_type will differentiate it (and we can put security rules for filtering it if we want).

About the fourth module, sale_account_commission, as sale already depends on account, I don't think we should need such extra glue module. Just make sale_commission depends on account_commission, and what we can do is to make optional the transfer of the commissions via a config option.

[AungKoKoLin1997]

The difference is that a settlement_type will differentiate it

Let me confirm this. When we make commission settlement, we need to choose settlement_type like sale order or account for generating settlement from sources. If we choose settlement_type to sale order when we make commission settlement, system will generate settlement from sale order lines. Is that right?

[pedrobaeza]

Not really, current settlement wizard will directly set the settlement_type to invoice. If tomorrow there's directly a wizard to settle sales orders, then such wizard will internally set that type in the created settlements, but the menu to see them all will be the same. Such sales wizard will also set the corresponding link for each line to each sale agent line. Do you understand what I want to say?

[AungKoKoLin1997]

So, we have each wizard to settle for each source and we set the settlement_type in the created settlements. I mean if we use sale_commission, there is a wizard to settle sale orders, but the menu to see them will be the same

[pedrobaeza]

Yes, but for now you don't need to create such wizards except the existing one for invoices.

[AungKoKoLin1997]

@pedrobaeza Can you please review this PR #374? We split into three modules as we talked. But we have one concern about sale_commission. Now sale_commission performs the commissions on sales orders and propagate them to customer invoices. In the future, if we want to add directly settlements from sale orders, do we need to create new module for this part? I think we can't add this part in sale_commission module because this module depends on account_commission and may be user don't want to use account_commission. And then, I think we should add the option for transferring commssion from sale to invoice via config option in new module. Now, we can only make settlement from invoice. So, we need to propagate commission on sale orders to customer invoices. What do you think about this?

[pedrobaeza]

As sale depends on account, I think we can create a module sale_commission_direct_settlement that includes the settlements from sale, and you decide which one to use. What do you think?

Other option is to create sale_commission with the bare agent line additions, and sale_account_commission for transferring the lines to the invoices, and the other one for the settlements.

[yostashiro]

I think the first option is good as an interim arrangement. I am not aware of real need of creating settlements directly from sales orders. When such need comes out sale_commission_direct_settlement can be created.

This second option sounds more reasonable in case the need of direct settlement from sales orders turns out to be material. Maybe this can be considered for future versions.

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