Comments (28)
Yes, but for now you don't need to create such wizards except the existing one for invoices.
from commission.
Not while the PR is not in good state, and the current diff is not correct. I plan to work on it on August.
from commission.
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?
from commission.
@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.
from commission.
Great, go ahead.
from commission.
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?
from commission.
No, let's do it. Migration scripts can handle that. I will take care of it when merged.
from commission.
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 !
from commission.
Yes, you can review such PR, but formally there's a problem with git commits.
from commission.
is there any plan to merge #363 ?
from commission.
Thanks for the feedback and the estimation :) @BT-fschubert FYI
from commission.
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 😄
from commission.
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?
from commission.
@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?
from commission.
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?
from commission.
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.
from commission.
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.
from commission.
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.
from commission.
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?
from commission.
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?
from commission.
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
from commission.
@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?
from commission.
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.
from commission.
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.
from commission.
Hello, how are you all? In my humble capacity as a tester I am migrating from 14 to 15 and I get the following error:
insert or update on table "res_partner" violates foreign key constraint "res_partner_commission_id_fkey" DETAIL: Key (commission_id)=(9) is not present in table "commission"
I see that you are trying to solve this migration, is it possible that the error that I am getting is because details are still missing? I hope to be of help with the tests. Greetings!
from commission.
from commission.
pedrobaeza
Thank you @pedrobaeza you are always there
from commission.
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.
from commission.
Related Issues (20)
- Purchase commission HOT 7
- Migration to version 16.0 HOT 1
- Manual commission applied to a sales order incorrectly HOT 1
- Commission defined at the sales order, not just the sales order line HOT 4
- Commision base on payment Date HOT 2
- Not computing agent commission (settle commissions command) HOT 8
- Sales Commissions wont calculate HOT 4
- [14.0][BUG] sale_commission: all settles aren't reciving any value
- [QUESTION]: Commission module is ready to migrate from 14 to 15?
- POS commission Calculation HOT 1
- Sales Commission: Settlements based on Sale Order (not needed Invoice) HOT 10
- sale_commission_product_criteria HOT 1
- Migration to version 17.0 HOT 2
- HELP: How do I update from the 13.0 to the 16.0 version of this module without losing my data? HOT 1
- Sales Commission By Sections (Value Ranges) based on the Total of Sale Order not for every Sale Line HOT 1
- [14.0][sale_commission]
- Commission based on paid amounts on invoices HOT 1
- [16.0][RFC]Use Many2one reference to ease the hook with other modules HOT 1
- What is a "manual" settlement? HOT 3
- button fa-users not showing in order lines HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from commission.