OFBiz › OFBiz - User

Users - Commission Data Model

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Vinay Agarwal

Users - Commission Data Model

Hello,

As I am in process of developing a simple, but hopefully generic enough to be useful, commission model, I am leaning toward the following data model. I would appreciate feedback. If there isn’t a drastic change in the model, I hope to submit a patch by end of this week.

Regards,

Vinay Agarwal

Commissions are modeled as Agreement entities with agreementTypeId of COMMISSION_AGREEMENT.
Related AgreementItems are not used and the currency is determined from the OrderHeader or ReturnHeader.
Related AgreementTerms specify the commission amount. Two type of terms are defined so far

FIN_COMM_FIXED: itemValue specifies per unit commission in the currency of the order.
FIN_COMM_VARIABLE: itemValue specifies percentage commission.

There can be a number of agreements applicable to each product involving multiple parties (both To and From).
Find applicable agreements using AgreementProductAppl.
The commission invoices are created when payments are applied.

_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

Andrew Sykes

Re: Users - Commission Data Model

Vinay,

Did you consider using...
SupplierProduct.lastPrice: For fixed price
SupplierProduct.supplierCommissionPerc: For percentages

Please note this entity also has a currencyUom field, so it seems to
have all you need.

I'd be interested to know what you think the pros and cons are...
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

Jacopo Cappellato

Re: Users - Commission Data Model

In reply to this post by Vinay Agarwal

Vinay,

I think your design is very good.
Just a minor point:

I'd use the Agreement entity to associate the company to the party that
will receive the commissions; I'd use the AgreementItem to store the
currency, the type of agreement (item) and the terms and products are
associated to the agreement item instead of the agreement header.

For example, an agreement for a commission of 20% to the
partyId="AGENT_ABC" for the products WG-1111 and GZ-1000 can be stored
in this way:

<Agreement agreementId="6000" partyIdFrom="Company"
partyIdTo="AGENT_ABC" agreementTypeId="PRODUCT_AGREEMENT"
description="Commission Agreement with Agent ABC"/>

<AgreementItem agreementId="6000" agreementItemSeqId="0001"
currencyUomId="USD" agreementItemTypeId="AGREEMENT_COMMISSION"
agreementText="Commissions in USD"/>

<AgreementTerm agreementTermId="1000" termTypeId="FIN_COMM_VARIABLE"
agreementId="6000" agreementItemSeqId="0001" termValue="20"/>

<AgreementProductAppl agreementId="6000" agreementItemSeqId="0001"
productId="WG-1111"/>
<AgreementProductAppl agreementId="6000" agreementItemSeqId="0001"
productId="GZ-1000"/>

As you can see, the agreement terms are for the agreement item (of type
COMMISSION) and not for the agreement header; in this way you can store
commissions for many currencies or store different commissions for
different products.

What do you think?

Jacopo

Vinay Agarwal wrote:

> Hello,
>
>
>
> As I am in process of developing a simple, but hopefully generic enough
> to be useful, commission model, I am leaning toward the following data
> model. I would appreciate feedback. If there isn’t a drastic change in
> the model, I hope to submit a patch by end of this week.
>
> Regards,
>
> Vinay Agarwal
>
>
>
> 1. Commissions are modeled as Agreement entities with agreementTypeId
> of COMMISSION_AGREEMENT.
> 2. Related AgreementItems are not used and the currency is determined
> from the OrderHeader or ReturnHeader.
> 3. Related AgreementTerms specify the commission amount. Two type of
> terms are defined so far
> 1. FIN_COMM_FIXED: itemValue specifies per unit commission in
> the currency of the order.
> 2. FIN_COMM_VARIABLE: itemValue specifies percentage commission.
> 4. There can be a number of agreements applicable to each product
> involving multiple parties (both To and From).
> 5. Find applicable agreements using AgreementProductAppl.
> 6. The commission invoices are created when payments are applied.
>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

Andrew Sykes

Re: Users - Commission Data Model

Vinay, Jacopo,

Now that I've read more about this, I think I prefer the 'Agreement'
approach too. It seems a lot more flexible.

On Thu, 2006-05-04 at 10:21 +0200, Jacopo Cappellato wrote:

> Vinay,
>
> I think your design is very good.
> Just a minor point:
>
> I'd use the Agreement entity to associate the company to the party that
> will receive the commissions; I'd use the AgreementItem to store the
> currency, the type of agreement (item) and the terms and products are
> associated to the agreement item instead of the agreement header.
>
> For example, an agreement for a commission of 20% to the
> partyId="AGENT_ABC" for the products WG-1111 and GZ-1000 can be stored
> in this way:
>
>
> <Agreement agreementId="6000" partyIdFrom="Company"
> partyIdTo="AGENT_ABC" agreementTypeId="PRODUCT_AGREEMENT"
> description="Commission Agreement with Agent ABC"/>
>
> <AgreementItem agreementId="6000" agreementItemSeqId="0001"
> currencyUomId="USD" agreementItemTypeId="AGREEMENT_COMMISSION"
> agreementText="Commissions in USD"/>
>
> <AgreementTerm agreementTermId="1000" termTypeId="FIN_COMM_VARIABLE"
> agreementId="6000" agreementItemSeqId="0001" termValue="20"/>
>
> <AgreementProductAppl agreementId="6000" agreementItemSeqId="0001"
> productId="WG-1111"/>
> <AgreementProductAppl agreementId="6000" agreementItemSeqId="0001"
> productId="GZ-1000"/>
>
>
> As you can see, the agreement terms are for the agreement item (of type
> COMMISSION) and not for the agreement header; in this way you can store
> commissions for many currencies or store different commissions for
> different products.
>
> What do you think?
>
> Jacopo
>
> Vinay Agarwal wrote:
> > Hello,
> >
> >
> >
> > As I am in process of developing a simple, but hopefully generic enough
> > to be useful, commission model, I am leaning toward the following data
> > model. I would appreciate feedback. If there isn’t a drastic change in
> > the model, I hope to submit a patch by end of this week.
> >
> > Regards,
> >
> > Vinay Agarwal
> >
> >
> >
> > 1. Commissions are modeled as Agreement entities with agreementTypeId
> > of COMMISSION_AGREEMENT.
> > 2. Related AgreementItems are not used and the currency is determined
> > from the OrderHeader or ReturnHeader.
> > 3. Related AgreementTerms specify the commission amount. Two type of
> > terms are defined so far
> > 1. FIN_COMM_FIXED: itemValue specifies per unit commission in
> > the currency of the order.
> > 2. FIN_COMM_VARIABLE: itemValue specifies percentage commission.
> > 4. There can be a number of agreements applicable to each product
> > involving multiple parties (both To and From).
> > 5. Find applicable agreements using AgreementProductAppl.
> > 6. The commission invoices are created when payments are applied.
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> > _______________________________________________
> > Users mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

David E. Jones

Re: Users - Commission Data Model

In reply to this post by Jacopo Cappellato

This layout and example from Jacopo looks like a good way to go, and is just a small variation on what you wrote up Vinay.

Doing something more generic like this and following existing patterns is great if it works out for you. I have a project coming up to do some analysis and help a client (who may be reading these emails) get some commissions functionality done, and this model should be sufficiently flexible for what they need as well.

For the commission results I like the idea of using invoices to model the money that needs to be moved around, and the status along with payments to track what has actually moved. With this we can reuse the work done by Hans, Si, Jacopo and others, and perhaps extend it if needed to have a reference back to the agreement(s) that the invoice resulted from.

-David

Jacopo Cappellato wrote:

> Vinay,
>
> I think your design is very good.
> Just a minor point:
>
> I'd use the Agreement entity to associate the company to the party that
> will receive the commissions; I'd use the AgreementItem to store the
> currency, the type of agreement (item) and the terms and products are
> associated to the agreement item instead of the agreement header.
>
> For example, an agreement for a commission of 20% to the
> partyId="AGENT_ABC" for the products WG-1111 and GZ-1000 can be stored
> in this way:
>
>
> <Agreement agreementId="6000" partyIdFrom="Company"
> partyIdTo="AGENT_ABC" agreementTypeId="PRODUCT_AGREEMENT"
> description="Commission Agreement with Agent ABC"/>
>
> <AgreementItem agreementId="6000" agreementItemSeqId="0001"
> currencyUomId="USD" agreementItemTypeId="AGREEMENT_COMMISSION"
> agreementText="Commissions in USD"/>
>
> <AgreementTerm agreementTermId="1000" termTypeId="FIN_COMM_VARIABLE"
> agreementId="6000" agreementItemSeqId="0001" termValue="20"/>
>
> <AgreementProductAppl agreementId="6000" agreementItemSeqId="0001"
> productId="WG-1111"/>
> <AgreementProductAppl agreementId="6000" agreementItemSeqId="0001"
> productId="GZ-1000"/>
>
>
> As you can see, the agreement terms are for the agreement item (of type
> COMMISSION) and not for the agreement header; in this way you can store
> commissions for many currencies or store different commissions for
> different products.
>
> What do you think?
>
> Jacopo
>
> Vinay Agarwal wrote:
>> Hello,
>>
>>
>>
>> As I am in process of developing a simple, but hopefully generic enough
>> to be useful, commission model, I am leaning toward the following data
>> model. I would appreciate feedback. If there isn’t a drastic change in
>> the model, I hope to submit a patch by end of this week.
>>
>> Regards,
>>
>> Vinay Agarwal
>>
>>
>>
>> 1. Commissions are modeled as Agreement entities with agreementTypeId
>> of COMMISSION_AGREEMENT.
>> 2. Related AgreementItems are not used and the currency is determined
>> from the OrderHeader or ReturnHeader.
>> 3. Related AgreementTerms specify the commission amount. Two type of
>> terms are defined so far
>> 1. FIN_COMM_FIXED: itemValue specifies per unit commission in
>> the currency of the order.
>> 2. FIN_COMM_VARIABLE: itemValue specifies percentage commission.
>> 4. There can be a number of agreements applicable to each product
>> involving multiple parties (both To and From).
>> 5. Find applicable agreements using AgreementProductAppl.
>> 6. The commission invoices are created when payments are applied.
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

Vinay Agarwal

Re: Users - Commission Data Model

I like Jacopo's model and will implement that.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of David E Jones
Sent: Thursday, May 04, 2006 4:38 AM
To: OFBiz Users / Usage Discussion
Subject: Re: [OFBiz] Users - Commission Data Model

This layout and example from Jacopo looks like a good way to go, and is just
a small variation on what you wrote up Vinay.

Doing something more generic like this and following existing patterns is
great if it works out for you. I have a project coming up to do some
analysis and help a client (who may be reading these emails) get some
commissions functionality done, and this model should be sufficiently
flexible for what they need as well.

For the commission results I like the idea of using invoices to model the
money that needs to be moved around, and the status along with payments to
track what has actually moved. With this we can reuse the work done by Hans,
Si, Jacopo and others, and perhaps extend it if needed to have a reference
back to the agreement(s) that the invoice resulted from.

-David

Jacopo Cappellato wrote:

> Vinay,
>
> I think your design is very good.
> Just a minor point:
>
> I'd use the Agreement entity to associate the company to the party that
> will receive the commissions; I'd use the AgreementItem to store the
> currency, the type of agreement (item) and the terms and products are
> associated to the agreement item instead of the agreement header.
>
> For example, an agreement for a commission of 20% to the
> partyId="AGENT_ABC" for the products WG-1111 and GZ-1000 can be stored
> in this way:
>
>
> <Agreement agreementId="6000" partyIdFrom="Company"
> partyIdTo="AGENT_ABC" agreementTypeId="PRODUCT_AGREEMENT"
> description="Commission Agreement with Agent ABC"/>
>
> <AgreementItem agreementId="6000" agreementItemSeqId="0001"
> currencyUomId="USD" agreementItemTypeId="AGREEMENT_COMMISSION"
> agreementText="Commissions in USD"/>
>
> <AgreementTerm agreementTermId="1000" termTypeId="FIN_COMM_VARIABLE"
> agreementId="6000" agreementItemSeqId="0001" termValue="20"/>
>
> <AgreementProductAppl agreementId="6000" agreementItemSeqId="0001"
> productId="WG-1111"/>
> <AgreementProductAppl agreementId="6000" agreementItemSeqId="0001"
> productId="GZ-1000"/>
>
>
> As you can see, the agreement terms are for the agreement item (of type
> COMMISSION) and not for the agreement header; in this way you can store
> commissions for many currencies or store different commissions for
> different products.
>
> What do you think?
>
> Jacopo
>
> Vinay Agarwal wrote:
>> Hello,
>>
>>
>>
>> As I am in process of developing a simple, but hopefully generic enough
>> to be useful, commission model, I am leaning toward the following data
>> model. I would appreciate feedback. If there isn't a drastic change in
>> the model, I hope to submit a patch by end of this week.
>>
>> Regards,
>>
>> Vinay Agarwal
>>
>>
>>
>> 1. Commissions are modeled as Agreement entities with agreementTypeId
>> of COMMISSION_AGREEMENT.
>> 2. Related AgreementItems are not used and the currency is determined
>> from the OrderHeader or ReturnHeader.
>> 3. Related AgreementTerms specify the commission amount. Two type of
>> terms are defined so far
>> 1. FIN_COMM_FIXED: itemValue specifies per unit commission in
>> the currency of the order.
>> 2. FIN_COMM_VARIABLE: itemValue specifies percentage commission.
>> 4. There can be a number of agreements applicable to each product
>> involving multiple parties (both To and From).
>> 5. Find applicable agreements using AgreementProductAppl.
>> 6. The commission invoices are created when payments are applied.
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

Jacopo Cappellato

Re: Users - Commission Data Model

In reply to this post by Vinay Agarwal

That's great.

In order to help you set up the agreements data for your test, a few
minutes ago, I've committed (rev. 7512) the screens to edit the
Agreement Item Terms.

So now it's possible to set up all the commission information using the
user interface.

Hope this helps,

Jacopo

Vinay Agarwal wrote:

> I like Jacopo's model and will implement that.
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of David E Jones
> Sent: Thursday, May 04, 2006 4:38 AM
> To: OFBiz Users / Usage Discussion
> Subject: Re: [OFBiz] Users - Commission Data Model
>
>
> This layout and example from Jacopo looks like a good way to go, and is just
> a small variation on what you wrote up Vinay.
>
> Doing something more generic like this and following existing patterns is
> great if it works out for you. I have a project coming up to do some
> analysis and help a client (who may be reading these emails) get some
> commissions functionality done, and this model should be sufficiently
> flexible for what they need as well.
>
> For the commission results I like the idea of using invoices to model the
> money that needs to be moved around, and the status along with payments to
> track what has actually moved. With this we can reuse the work done by Hans,
> Si, Jacopo and others, and perhaps extend it if needed to have a reference
> back to the agreement(s) that the invoice resulted from.
>
> -David
>
>
> Jacopo Cappellato wrote:
>> Vinay,
>>
>> I think your design is very good.
>> Just a minor point:
>>
>> I'd use the Agreement entity to associate the company to the party that
>> will receive the commissions; I'd use the AgreementItem to store the
>> currency, the type of agreement (item) and the terms and products are
>> associated to the agreement item instead of the agreement header.
>>
>> For example, an agreement for a commission of 20% to the
>> partyId="AGENT_ABC" for the products WG-1111 and GZ-1000 can be stored
>> in this way:
>>
>>
>> <Agreement agreementId="6000" partyIdFrom="Company"
>> partyIdTo="AGENT_ABC" agreementTypeId="PRODUCT_AGREEMENT"
>> description="Commission Agreement with Agent ABC"/>
>>
>> <AgreementItem agreementId="6000" agreementItemSeqId="0001"
>> currencyUomId="USD" agreementItemTypeId="AGREEMENT_COMMISSION"
>> agreementText="Commissions in USD"/>
>>
>> <AgreementTerm agreementTermId="1000" termTypeId="FIN_COMM_VARIABLE"
>> agreementId="6000" agreementItemSeqId="0001" termValue="20"/>
>>
>> <AgreementProductAppl agreementId="6000" agreementItemSeqId="0001"
>> productId="WG-1111"/>
>> <AgreementProductAppl agreementId="6000" agreementItemSeqId="0001"
>> productId="GZ-1000"/>
>>
>>
>> As you can see, the agreement terms are for the agreement item (of type
>> COMMISSION) and not for the agreement header; in this way you can store
>> commissions for many currencies or store different commissions for
>> different products.
>>
>> What do you think?
>>
>> Jacopo
>>
>> Vinay Agarwal wrote:
>>> Hello,
>>>
>>>
>>>
>>> As I am in process of developing a simple, but hopefully generic enough
>>> to be useful, commission model, I am leaning toward the following data
>>> model. I would appreciate feedback. If there isn't a drastic change in
>>> the model, I hope to submit a patch by end of this week.
>>>
>>> Regards,
>>>
>>> Vinay Agarwal
>>>
>>>
>>>
>>> 1. Commissions are modeled as Agreement entities with agreementTypeId
>>> of COMMISSION_AGREEMENT.
>>> 2. Related AgreementItems are not used and the currency is determined
>>> from the OrderHeader or ReturnHeader.
>>> 3. Related AgreementTerms specify the commission amount. Two type of
>>> terms are defined so far
>>> 1. FIN_COMM_FIXED: itemValue specifies per unit commission in
>>> the currency of the order.
>>> 2. FIN_COMM_VARIABLE: itemValue specifies percentage commission.
>>> 4. There can be a number of agreements applicable to each product
>>> involving multiple parties (both To and From).
>>> 5. Find applicable agreements using AgreementProductAppl.
>>> 6. The commission invoices are created when payments are applied.
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

Jacopo Cappellato

Re: Users - Commission Data Model

Vinay, Si, others,

I'm reading your interesting comments in JIRA issue OFBIZ-853; I agree
with what Si says in
http://jira.undersunconsulting.com/browse/OFBIZ-853?page=comments#action_13178

However, in order to keep things simple, it would be much more easier to
create commission on a sales invoice status change (e.g. to PAID)
instead of running it everytime a payment is applied to the invoice.

Is this simplification acceptable?

Jacopo

Jacopo Cappellato wrote:

> That's great.
>
> In order to help you set up the agreements data for your test, a few
> minutes ago, I've committed (rev. 7512) the screens to edit the
> Agreement Item Terms.
>
> So now it's possible to set up all the commission information using the
> user interface.
>
> Hope this helps,
>
> Jacopo
>
> Vinay Agarwal wrote:
>> I like Jacopo's model and will implement that.
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> On Behalf Of David E Jones
>> Sent: Thursday, May 04, 2006 4:38 AM
>> To: OFBiz Users / Usage Discussion
>> Subject: Re: [OFBiz] Users - Commission Data Model
>>
>>
>> This layout and example from Jacopo looks like a good way to go, and is just
>> a small variation on what you wrote up Vinay.
>>
>> Doing something more generic like this and following existing patterns is
>> great if it works out for you. I have a project coming up to do some
>> analysis and help a client (who may be reading these emails) get some
>> commissions functionality done, and this model should be sufficiently
>> flexible for what they need as well.
>>
>> For the commission results I like the idea of using invoices to model the
>> money that needs to be moved around, and the status along with payments to
>> track what has actually moved. With this we can reuse the work done by Hans,
>> Si, Jacopo and others, and perhaps extend it if needed to have a reference
>> back to the agreement(s) that the invoice resulted from.
>>
>> -David
>>
>>
>> Jacopo Cappellato wrote:
>>> Vinay,
>>>
>>> I think your design is very good.
>>> Just a minor point:
>>>
>>> I'd use the Agreement entity to associate the company to the party that
>>> will receive the commissions; I'd use the AgreementItem to store the
>>> currency, the type of agreement (item) and the terms and products are
>>> associated to the agreement item instead of the agreement header.
>>>
>>> For example, an agreement for a commission of 20% to the
>>> partyId="AGENT_ABC" for the products WG-1111 and GZ-1000 can be stored
>>> in this way:
>>>
>>>
>>> <Agreement agreementId="6000" partyIdFrom="Company"
>>> partyIdTo="AGENT_ABC" agreementTypeId="PRODUCT_AGREEMENT"
>>> description="Commission Agreement with Agent ABC"/>
>>>
>>> <AgreementItem agreementId="6000" agreementItemSeqId="0001"
>>> currencyUomId="USD" agreementItemTypeId="AGREEMENT_COMMISSION"
>>> agreementText="Commissions in USD"/>
>>>
>>> <AgreementTerm agreementTermId="1000" termTypeId="FIN_COMM_VARIABLE"
>>> agreementId="6000" agreementItemSeqId="0001" termValue="20"/>
>>>
>>> <AgreementProductAppl agreementId="6000" agreementItemSeqId="0001"
>>> productId="WG-1111"/>
>>> <AgreementProductAppl agreementId="6000" agreementItemSeqId="0001"
>>> productId="GZ-1000"/>
>>>
>>>
>>> As you can see, the agreement terms are for the agreement item (of type
>>> COMMISSION) and not for the agreement header; in this way you can store
>>> commissions for many currencies or store different commissions for
>>> different products.
>>>
>>> What do you think?
>>>
>>> Jacopo
>>>
>>> Vinay Agarwal wrote:
>>>> Hello,
>>>>
>>>>
>>>>
>>>> As I am in process of developing a simple, but hopefully generic enough
>>>> to be useful, commission model, I am leaning toward the following data
>>>> model. I would appreciate feedback. If there isn't a drastic change in
>>>> the model, I hope to submit a patch by end of this week.
>>>>
>>>> Regards,
>>>>
>>>> Vinay Agarwal
>>>>
>>>>
>>>>
>>>> 1. Commissions are modeled as Agreement entities with agreementTypeId
>>>> of COMMISSION_AGREEMENT.
>>>> 2. Related AgreementItems are not used and the currency is determined
>>>> from the OrderHeader or ReturnHeader.
>>>> 3. Related AgreementTerms specify the commission amount. Two type of
>>>> terms are defined so far
>>>> 1. FIN_COMM_FIXED: itemValue specifies per unit commission in
>>>> the currency of the order.
>>>> 2. FIN_COMM_VARIABLE: itemValue specifies percentage commission.
>>>> 4. There can be a number of agreements applicable to each product
>>>> involving multiple parties (both To and From).
>>>> 5. Find applicable agreements using AgreementProductAppl.
>>>> 6. The commission invoices are created when payments are applied.
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>

_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

Jacopo Cappellato

Re: Users - Commission Data Model

In reply to this post by Jacopo Cappellato

Vinay,

with rev. 7524 I've implemented the ui to link products to agreement
items (AgreementProductAppl).

Jacopo

Jacopo Cappellato wrote:

_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

Vinay Agarwal

Re: Users - Commission Data Model

Jacopo,

Thanks. I also saw the view entities you created and I am using those. The
code and demo data is almost done except for the service's invocation. I
think I will just invoke it from createPaymentApplication. I was also
thinking of using days part of the terms to indicate when the invoice is to
be paid. If the days are zero, then I will invoke service to apply payment
immediate after they are created (this will help my need by removing one
extra step). I also am adding FIN_COMM_MIN and FIN_COMM_MAX (both per using)
fields to contain side effect of some commission rules.

Vinay

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Jacopo Cappellato
Sent: Friday, May 05, 2006 7:46 AM
To: OFBiz Users / Usage Discussion
Subject: Re: [OFBiz] Users - Commission Data Model

Vinay,

with rev. 7524 I've implemented the ui to link products to agreement
items (AgreementProductAppl).

Jacopo

Jacopo Cappellato wrote:

[mailto:[hidden email]]
>> On Behalf Of David E Jones
>> Sent: Thursday, May 04, 2006 4:38 AM
>> To: OFBiz Users / Usage Discussion
>> Subject: Re: [OFBiz] Users - Commission Data Model
>>
>>
>> This layout and example from Jacopo looks like a good way to go, and is
just

>> a small variation on what you wrote up Vinay.
>>
>> Doing something more generic like this and following existing patterns is
>> great if it works out for you. I have a project coming up to do some
>> analysis and help a client (who may be reading these emails) get some
>> commissions functionality done, and this model should be sufficiently
>> flexible for what they need as well.
>>
>> For the commission results I like the idea of using invoices to model the
>> money that needs to be moved around, and the status along with payments

to
>> track what has actually moved. With this we can reuse the work done by
Hans,
>> Si, Jacopo and others, and perhaps extend it if needed to have a
reference

>> back to the agreement(s) that the invoice resulted from.
>>
>> -David
>>
>>
>> Jacopo Cappellato wrote:
>>> Vinay,
>>>
>>> I think your design is very good.
>>> Just a minor point:
>>>
>>> I'd use the Agreement entity to associate the company to the party that
>>> will receive the commissions; I'd use the AgreementItem to store the
>>> currency, the type of agreement (item) and the terms and products are
>>> associated to the agreement item instead of the agreement header.
>>>
>>> For example, an agreement for a commission of 20% to the
>>> partyId="AGENT_ABC" for the products WG-1111 and GZ-1000 can be stored
>>> in this way:
>>>
>>>
>>> <Agreement agreementId="6000" partyIdFrom="Company"
>>> partyIdTo="AGENT_ABC" agreementTypeId="PRODUCT_AGREEMENT"
>>> description="Commission Agreement with Agent ABC"/>
>>>
>>> <AgreementItem agreementId="6000" agreementItemSeqId="0001"
>>> currencyUomId="USD" agreementItemTypeId="AGREEMENT_COMMISSION"
>>> agreementText="Commissions in USD"/>
>>>
>>> <AgreementTerm agreementTermId="1000" termTypeId="FIN_COMM_VARIABLE"
>>> agreementId="6000" agreementItemSeqId="0001" termValue="20"/>
>>>
>>> <AgreementProductAppl agreementId="6000" agreementItemSeqId="0001"
>>> productId="WG-1111"/>
>>> <AgreementProductAppl agreementId="6000" agreementItemSeqId="0001"
>>> productId="GZ-1000"/>
>>>
>>>
>>> As you can see, the agreement terms are for the agreement item (of type
>>> COMMISSION) and not for the agreement header; in this way you can store
>>> commissions for many currencies or store different commissions for
>>> different products.
>>>
>>> What do you think?
>>>
>>> Jacopo
>>>
>>> Vinay Agarwal wrote:
>>>> Hello,
>>>>
>>>>
>>>>
>>>> As I am in process of developing a simple, but hopefully generic enough

>>>> to be useful, commission model, I am leaning toward the following data
>>>> model. I would appreciate feedback. If there isn't a drastic change in
>>>> the model, I hope to submit a patch by end of this week.
>>>>
>>>> Regards,
>>>>
>>>> Vinay Agarwal
>>>>
>>>>
>>>>
>>>> 1. Commissions are modeled as Agreement entities with

agreementTypeId
>>>> of COMMISSION_AGREEMENT.
>>>> 2. Related AgreementItems are not used and the currency is
determined
>>>> from the OrderHeader or ReturnHeader.
>>>> 3. Related AgreementTerms specify the commission amount. Two type of
>>>> terms are defined so far
>>>> 1. FIN_COMM_FIXED: itemValue specifies per unit commission in
>>>> the currency of the order.
>>>> 2. FIN_COMM_VARIABLE: itemValue specifies percentage
commission.
>>>> 4. There can be a number of agreements applicable to each product
>>>> involving multiple parties (both To and From).
>>>> 5. Find applicable agreements using AgreementProductAppl.
>>>> 6. The commission invoices are created when payments are applied.
>>>>
>>>>
>>>>
------------------------------------------------------------------------

>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> [hidden email]
>>>> http://lists.ofbiz.org/mailman/listinfo/users
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>