Party Classification

[Adrian Crum-3]

I know we have discussed this before, but I'm trying to use the OFBiz
party classification entities for another client and I'm running into
the same problem I've had before - the current party classification data
model just doesn't work.

The party classification data model presented in the The Data Model
Resource Book is simple and flexible. My preference would be to use that
model, but in previous discussions there was some resistance to using
the OFBiz PartyType entity in the way the book describes. So, I have
come up with a compromise solution: Use the OFBiz
PartyClassificationType entity as a replacement for the DMRB PartyType
entity, and implement the DMRB Party Classification subtypes by grouping
PartyClassificationTypes.

This is what it would look like:

PartyClassification
-------------------
partyId*, id-ne
partyClassificationTypeId*, id-ne
fromDate*, date-time
thruDate, date-time

PartyClassificationType
-----------------------
partyClassificationTypeId*, id-ne
description, description

PartyClassificationGroup
------------------------
partyClassificationTypeId*, id-ne
partyClassificationGroupTypeId*, id-ne

PartyClassificationGroupType
----------------------------
partyClassificationGroupTypeId*, id-ne
description, description

If the data currently stored in PartyClassificationType is moved to
PartyClassificationGroupType, then the proposed model will be capable of
supporting the party classification scheme illustrated in Table 2.3 of
the DMRB.

What do you think?

-Adrian

[David E. Jones-2]

On Aug 21, 2011, at 2:56 AM, Adrian Crum wrote:

> I know we have discussed this before, but I'm trying to use the OFBiz party classification entities for another client and I'm running into the same problem I've had before - the current party classification data model just doesn't work.
>
> The party classification data model presented in the The Data Model Resource Book is simple and flexible. My preference would be to use that model, but in previous discussions there was some resistance to using the OFBiz PartyType entity in the way the book describes. So, I have come up with a compromise solution: Use the OFBiz PartyClassificationType entity as a replacement for the DMRB PartyType entity, and implement the DMRB Party Classification subtypes by grouping PartyClassificationTypes.
>
> This is what it would look like:
>
> PartyClassification
> -------------------
> partyId*, id-ne
> partyClassificationTypeId*, id-ne
> fromDate*, date-time
> thruDate, date-time
>
> PartyClassificationType
> -----------------------
> partyClassificationTypeId*, id-ne
> description, description
>
> PartyClassificationGroup
> ------------------------
> partyClassificationTypeId*, id-ne
> partyClassificationGroupTypeId*, id-ne
>
> PartyClassificationGroupType
> ----------------------------
> partyClassificationGroupTypeId*, id-ne
> description, description
>
> If the data currently stored in PartyClassificationType is moved to PartyClassificationGroupType, then the proposed model will be capable of supporting the party classification scheme illustrated in Table 2.3 of the DMRB.
>
> What do you think?

Without an idea of what you're trying to model - nothing.

-David

[Adrian Crum-3]

http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201101.mbox/%3C445823.92592.qm@...%3E

-Adrian

On 8/21/2011 5:14 PM, David E Jones wrote:

> On Aug 21, 2011, at 2:56 AM, Adrian Crum wrote:
>
>> I know we have discussed this before, but I'm trying to use the OFBiz party classification entities for another client and I'm running into the same problem I've had before - the current party classification data model just doesn't work.
>>
>> The party classification data model presented in the The Data Model Resource Book is simple and flexible. My preference would be to use that model, but in previous discussions there was some resistance to using the OFBiz PartyType entity in the way the book describes. So, I have come up with a compromise solution: Use the OFBiz PartyClassificationType entity as a replacement for the DMRB PartyType entity, and implement the DMRB Party Classification subtypes by grouping PartyClassificationTypes.
>>
>> This is what it would look like:
>>
>> PartyClassification
>> -------------------
>> partyId*, id-ne
>> partyClassificationTypeId*, id-ne
>> fromDate*, date-time
>> thruDate, date-time
>>
>> PartyClassificationType
>> -----------------------
>> partyClassificationTypeId*, id-ne
>> description, description
>>
>> PartyClassificationGroup
>> ------------------------
>> partyClassificationTypeId*, id-ne
>> partyClassificationGroupTypeId*, id-ne
>>
>> PartyClassificationGroupType
>> ----------------------------
>> partyClassificationGroupTypeId*, id-ne
>> description, description
>>
>> If the data currently stored in PartyClassificationType is moved to PartyClassificationGroupType, then the proposed model will be capable of supporting the party classification scheme illustrated in Table 2.3 of the DMRB.
>>
>> What do you think?
> Without an idea of what you're trying to model - nothing.
>
> -David
>
>

[Malin Nicolas]

Hi Adrian,

I agree with your suggestion. To go further, this schema can be extended
to all EntityType since the problem that you have is also present to
manage RoleType, CustRequestType, ...

It resolve the problem : How to handle the same type in different context.
When I have finished my previous spot (yes the day will come) I'm
starting to give a hand to soften the pattern

Nicolas

Le 21/08/2011 10:56, Adrian Crum a écrit :

> I know we have discussed this before, but I'm trying to use the OFBiz
> party classification entities for another client and I'm running into
> the same problem I've had before - the current party classification
> data model just doesn't work.
>
> The party classification data model presented in the The Data Model
> Resource Book is simple and flexible. My preference would be to use
> that model, but in previous discussions there was some resistance to
> using the OFBiz PartyType entity in the way the book describes. So, I
> have come up with a compromise solution: Use the OFBiz
> PartyClassificationType entity as a replacement for the DMRB PartyType
> entity, and implement the DMRB Party Classification subtypes by
> grouping PartyClassificationTypes.
>
> This is what it would look like:
>
> PartyClassification
> -------------------
> partyId*, id-ne
> partyClassificationTypeId*, id-ne
> fromDate*, date-time
> thruDate, date-time
>
> PartyClassificationType
> -----------------------
> partyClassificationTypeId*, id-ne
> description, description
>
> PartyClassificationGroup
> ------------------------
> partyClassificationTypeId*, id-ne
> partyClassificationGroupTypeId*, id-ne
>
> PartyClassificationGroupType
> ----------------------------
> partyClassificationGroupTypeId*, id-ne
> description, description
>
> If the data currently stored in PartyClassificationType is moved to
> PartyClassificationGroupType, then the proposed model will be capable
> of supporting the party classification scheme illustrated in Table 2.3
> of the DMRB.
>
> What do you think?
>
> -Adrian
>

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/