http://ofbiz.116.s1.nabble.com/Users-Commission-Data-Model-tp138846p138852.html
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.
> 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