Party Classification Data Modeling
Locked
12
12
Re: Party Classification Data Modeling
 
|
The marketing department will want to group party classifications one
way. The human resources department will want to group party classifications another way. A department head might want to group subordinates a certain way. How is each party classification grouping handled without redundant and potentially stale data? By grouping party classifications instead of grouping parties. When a party's classification changes, their membership in the various party classification groups changes automatically. It's simple and flexible. -Adrian On 9/4/2011 7:47 PM, BJ Freeman wrote: > Looks like I missed an important part of you thinking. > > Adrian Crum sent the following on 9/4/2011 11:36 AM: >> No, I want Hispanic to be a member of an arbitrary number of groups. >> >> -Adrian >> >> On 9/4/2011 7:34 PM, BJ Freeman wrote: >>> Parent child is the same as grouping in my view. >>> it even gives you a hierarchy >>> so if you point to Hispanic you can find it under Minorities. >>> if you want to further define Hispanic, Like Castillian or Mexican they >>> can be child of Hispanic >>> >>> Adrian Crum sent the following on 9/4/2011 11:10 AM: >>>> And your point is? That doesn't assign Hispanic to a classification >>>> group, it only makes Hispanic a child classification of the Minority >>>> Classification. >>>> >>>> At any rate, I have implemented the pattern I needed locally, and I have >>>> given up trying to make the case for an improved Party Classification >>>> data model. >>>> >>>> -Adrian >>>> >>>> On 9/4/2011 7:04 PM, BJ Freeman wrote: >>>>> <PartyClassificationType description="Minority" hasTable="N" >>>>> parentTypeId="" partyClassificationTypeId="MINORITY_CLASSIFICAT"/> >>>>> <PartyClassificationType description="Hispanic" hasTable="N" >>>>> parentTypeId="MINORITY_CLASSIFICA" >>>>> partyClassificationTypeId="HISPANIC_CLASSIFICAT"/> >>>>> >>>>> >>>>> Adrian Crum sent the following on 1/10/2011 4:27 PM: >>>>>> I spent some time in Party Manager trying to make sense of the Party >>>>>> Classification feature, and I can't seem to make it do anything >>>>>> meaningful. Maybe I'm not understanding something, so I'll provide an >>>>>> example and see if anyone knows how to implement it in the current >>>>>> code. >>>>>> >>>>>> In table 2.3 of the Data Model Resource Book, there is a party named >>>>>> Marc Martinez who has been classified as Hispanic. I will use him for >>>>>> my example. >>>>>> >>>>>> In Party Manager I create a person named Marc Martinez and I want to >>>>>> classify him as Hispanic. I would also like to include the Hispanic >>>>>> classification in two classification groups: US Minorities and >>>>>> Non-White. I go to the Classifications tab - where I can create >>>>>> classification groups from a list of pre-defined group types. I >>>>>> choose the Minority type, type "US Minorities" in the Description >>>>>> field, and save the group. I want to add the Hispanic classification >>>>>> to this group, but I don't see any way to add classifications. I go >>>>>> to Marc's profile page and try to assign him a classification, but I >>>>>> can only assign him to a classification group. If I assign him to the >>>>>> "US Minorities" group that still doesn't classify him as Hispanic. >>>>>> >>>>>> As far as I can tell, Party Classification doesn't work. >>>>>> >>>>>> Any ideas? >>>>>> >>>>>> -Adrian >>>>>> >>>>>> >>>>>> --- On Mon, 1/3/11, Adrian Crum<[hidden email]> wrote: >>>>>>> Understood. If we wanted to create >>>>>>> entities to avoid the sub-types mentioned in the book >>>>>>> (Organization Classification, Person Classisfication, etc) >>>>>>> then I think we could have done that in a simpler way and >>>>>>> still keep the book's model: >>>>>>> >>>>>>> PartyClassificationGroupType >>>>>>> ---------------------------- >>>>>>> *groupTypeId >>>>>>> description >>>>>>> parentGroupTypeId >>>>>>> >>>>>>> PartyClassificationGroup >>>>>>> ------------------------ >>>>>>> *groupTypeId >>>>>>> *partyTypeId >>>>>>> >>>>>>> Anyways, I have come up with a workaround. I'll just use >>>>>>> the existing PartyClassificationGroup the way the book uses >>>>>>> PartyType. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> >>>>>>> --- On Mon, 1/3/11, David E Jones<[hidden email]> >>>>>>> wrote: >>>>>>>> Every single *Type entity in OFBiz is a deviation from >>>>>>> the >>>>>>>> book (ie the *Type entities are an OFBiz pattern to >>>>>>> avoid >>>>>>>> redundant entities and keep track of entity extensions >>>>>>> like >>>>>>>> the Party -> PartyGroup,Person thingy), as are >>>>>>> dozens of >>>>>>>> other entities and hundreds of fields. That book is >>>>>>> valuable >>>>>>>> for general concepts and patterns, and is not an >>>>>>> actual data >>>>>>>> model to be used as-is. >>>>>>>> >>>>>>>> -David >>>>>>>> >>>>>>>> >>>>>>>> On Jan 3, 2011, at 5:57 PM, Adrian Crum wrote: >>>>>>>> >>>>>>>>> I don't think I'm generalizing anything. The book >>>>>>> is >>>>>>>> pretty specific and clear: Party Classification is an >>>>>>>> intersection entity that sets up a many-to-many >>>>>>> relationship >>>>>>>> between the Party entity and the Party Type entity. >>>>>>>>> I understand OFBiz deviates from the book here >>>>>>> and >>>>>>>> there, and if this is one of those cases, then I'll >>>>>>> ask >>>>>>>> again: Why was it done that way? >>>>>>>>> I'm trying to make sense of the OFBiz Party >>>>>>>> Classification model, and so far it doesn't make >>>>>>> sense. The >>>>>>>> way it is set up, I can't give a party a >>>>>>> classification >>>>>>>> without first creating a classification group, assign >>>>>>> a >>>>>>>> classification type to it, and then assign the party >>>>>>> to the >>>>>>>> classification group using party classification. >>>>>>>>> In the book it's much simpler - I just assign a >>>>>>> party >>>>>>>> type to a party using a party classification. >>>>>>> Classification >>>>>>>> groups are Party Classification sub-types and they >>>>>>> aren't >>>>>>>> necessary unless I want to group things a certain >>>>>>> way. >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> --- On Mon, 1/3/11, David E Jones<[hidden email]> >>>>>>>> wrote: >>>>>>>>>> I think you may be taking the specific term >>>>>>> "type" >>>>>>>> and >>>>>>>>>> generalizing it. Consider that *Type entities >>>>>>> in >>>>>>>> OFBiz mean >>>>>>>>>> something very specific, and it is different >>>>>>> from >>>>>>>> the more >>>>>>>>>> general use of the term in the book. >>>>>>>>>> >>>>>>>>>> -David >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Jan 3, 2011, at 3:24 PM, Adrian Crum >>>>>>> wrote: >>>>>>>>>>> That's not what the book shows. There is >>>>>>> a >>>>>>>> simple >>>>>>>>>> relationship: >>>>>>>>>>> Party -> PartyClassification -> >>>>>>>> PartyType >>>>>>>>>>> If you want to group classifications, >>>>>>> give >>>>>>>> them >>>>>>>>>> parent/child relationships, etc then you do >>>>>>> it >>>>>>>> with >>>>>>>>>> PartyType, not PartyClassification. Look at >>>>>>> table >>>>>>>> 2.3 on >>>>>>>>>> page 32. >>>>>>>>>>> -Adrian >>>>>>>>>>> >>>>>>>>>>> --- On Mon, 1/3/11, BJ Freeman<[hidden email]> >>>>>>>>>> wrote: >>>>>>>>>>>> how about a pattern of parent child >>>>>>>>>>>> for PartyClassification of supertype >>>>>>>>>>>> and the sub types then use a >>>>>>>>>> table for the >>>>>>>>>>>> attributess of the subtype. >>>>>>>>>>>> this would allow walking the parnent >>>>>>>> child >>>>>>>>>> relationships. >>>>>>>>>>>> PartyClassification >>>>>>>>>>>> >>>>>>> --->organizationClassification---->minorityClassification >>>>>>>> ---->industryclassification >>>>>>>>>>>> ========================= >>>>>>>>>>>> BJ Freeman >>>>>>>>>>>> Strategic Power Office with Supplier >>>>>>>> Automation >>>>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/> >>>>>>>>>>>> Systems Integrator-- Glad to Assist >>>>>>>>>>>> >>>>>>>>>>>> Chat Y! messenger: bjfr33man >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Adrian Crum sent the following on >>>>>>> 1/3/2011 >>>>>>>> 2:46 >>>>>>>>>> PM: >>>>>>>>>>>>> PartyClassificationGroup should >>>>>>> have >>>>>>>> a >>>>>>>>>> one-to-one >>>>>>>>>>>> relationship with an entity called >>>>>>>>>>>> PartyClassificationGroupType. >>>>>>>>>>>>> -Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> --- On Mon, 1/3/11, BJ >>>>>>> Freeman<[hidden email]> >>>>>>>>>>>> wrote: >>>>>>>>>>>>>> so the Party Classification >>>>>>> Group >>>>>>>>>>>>>> table would have a one to >>>>>>> one >>>>>>>> with >>>>>>>>>>>>>> Classification Types >>>>>>>>>>>>>> or vica versa. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ========================= >>>>>>>>>>>>>> BJ Freeman >>>>>>>>>>>>>> Strategic Power Office with >>>>>>>> Supplier >>>>>>>>>> Automation >>>>>>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/> >>>>>>>>>>>>>> Systems Integrator-- Glad to >>>>>>>> Assist >>>>>>>>>>>>>> Chat Y! messenger: >>>>>>>> bjfr33man >>>>>>>>>>>>>> Adrian Crum sent the >>>>>>> following on >>>>>>>> 1/3/2011 >>>>>>>>>> 1:41 >>>>>>>>>>>> PM: >>>>>>>>>>>>>>> Looking into this more, >>>>>>> The >>>>>>>> Data >>>>>>>>>> Model >>>>>>>>>>>> Resource Book >>>>>>>>>>>>>> mentions classification >>>>>>> groups - >>>>>>>> but I >>>>>>>>>> believe the >>>>>>>>>>>> author >>>>>>>>>>>>>> meant that Party Types could >>>>>>> be >>>>>>>> grouped >>>>>>>>>> together >>>>>>>>>>>> in >>>>>>>>>>>>>> classification groups. In >>>>>>> other >>>>>>>> words, >>>>>>>>>> the >>>>>>>>>>>> classification >>>>>>>>>>>>>> groups are defined by the >>>>>>> data >>>>>>>> contained >>>>>>>>>> in the >>>>>>>>>>>> Party Type >>>>>>>>>>>>>> table - not in a separate >>>>>>> "Party >>>>>>>>>> Classification >>>>>>>>>>>> Group" >>>>>>>>>>>>>> table. There is nothing >>>>>>> stopping >>>>>>>> us from >>>>>>>>>> having a >>>>>>>>>>>> Party >>>>>>>>>>>>>> Classification Group table, >>>>>>> but it >>>>>>>> should >>>>>>>>>> group >>>>>>>>>>>> Party Types, >>>>>>>>>>>>>> not "Classification Types." >>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --- On Mon, 1/3/11, >>>>>>> Adrian >>>>>>>> Crum<[hidden email]> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> Looking at The Data >>>>>>> Model >>>>>>>>>> Resource >>>>>>>>>>>>>>>> Book and the way >>>>>>> OFBiz >>>>>>>> models >>>>>>>>>> Party >>>>>>>>>>>>>> Classification, it >>>>>>>>>>>>>>>> appears to me OFBiz >>>>>>> models >>>>>>>> it >>>>>>>>>> wrong. >>>>>>>>>>>>>>>> According to the >>>>>>> book, the >>>>>>>> Party >>>>>>>>>>>> Classification >>>>>>>>>>>>>> entity ties >>>>>>>>>>>>>>>> a Party to a Party >>>>>>> Type >>>>>>>> with a >>>>>>>>>> from and >>>>>>>>>>>> thru >>>>>>>>>>>>>> date. >>>>>>>>>>>>>>>> In OFBiz, the Party >>>>>>>> Classification >>>>>>>>>> entity >>>>>>>>>>>> ties a >>>>>>>>>>>>>> Party to a >>>>>>>>>>>>>>>> Party Classification >>>>>>> Group >>>>>>>> with a >>>>>>>>>> from and >>>>>>>>>>>> thru >>>>>>>>>>>>>> date. The >>>>>>>>>>>>>>>> Party Type is tied >>>>>>>> directly to >>>>>>>>>> Party with >>>>>>>>>>>> no from >>>>>>>>>>>>>> and thru >>>>>>>>>>>>>>>> date. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Was that intentional? >>>>>>> Why >>>>>>>> was it >>>>>>>>>> done that >>>>>>>>>>>> way? >>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>> |
Re: Party Classification Data Modeling
Administrator
|
Davis has suggested to follow the ProductCategoryRollup pattern
http://markmail.org/message/ybd4lig4k67vdowm Is it not what you need (ie to introduce a graph instead of a tree and gain flexibility)? Jacques From: "Adrian Crum" <[hidden email]> > The marketing department will want to group party classifications one > way. The human resources department will want to group party > classifications another way. A department head might want to group > subordinates a certain way. How is each party classification grouping > handled without redundant and potentially stale data? By grouping party > classifications instead of grouping parties. When a party's > classification changes, their membership in the various party > classification groups changes automatically. > > It's simple and flexible. > > -Adrian > > > On 9/4/2011 7:47 PM, BJ Freeman wrote: >> Looks like I missed an important part of you thinking. >> >> Adrian Crum sent the following on 9/4/2011 11:36 AM: >>> No, I want Hispanic to be a member of an arbitrary number of groups. >>> >>> -Adrian >>> >>> On 9/4/2011 7:34 PM, BJ Freeman wrote: >>>> Parent child is the same as grouping in my view. >>>> it even gives you a hierarchy >>>> so if you point to Hispanic you can find it under Minorities. >>>> if you want to further define Hispanic, Like Castillian or Mexican they >>>> can be child of Hispanic >>>> >>>> Adrian Crum sent the following on 9/4/2011 11:10 AM: >>>>> And your point is? That doesn't assign Hispanic to a classification >>>>> group, it only makes Hispanic a child classification of the Minority >>>>> Classification. >>>>> >>>>> At any rate, I have implemented the pattern I needed locally, and I have >>>>> given up trying to make the case for an improved Party Classification >>>>> data model. >>>>> >>>>> -Adrian >>>>> >>>>> On 9/4/2011 7:04 PM, BJ Freeman wrote: >>>>>> <PartyClassificationType description="Minority" hasTable="N" >>>>>> parentTypeId="" partyClassificationTypeId="MINORITY_CLASSIFICAT"/> >>>>>> <PartyClassificationType description="Hispanic" hasTable="N" >>>>>> parentTypeId="MINORITY_CLASSIFICA" >>>>>> partyClassificationTypeId="HISPANIC_CLASSIFICAT"/> >>>>>> >>>>>> >>>>>> Adrian Crum sent the following on 1/10/2011 4:27 PM: >>>>>>> I spent some time in Party Manager trying to make sense of the Party >>>>>>> Classification feature, and I can't seem to make it do anything >>>>>>> meaningful. Maybe I'm not understanding something, so I'll provide an >>>>>>> example and see if anyone knows how to implement it in the current >>>>>>> code. >>>>>>> >>>>>>> In table 2.3 of the Data Model Resource Book, there is a party named >>>>>>> Marc Martinez who has been classified as Hispanic. I will use him for >>>>>>> my example. >>>>>>> >>>>>>> In Party Manager I create a person named Marc Martinez and I want to >>>>>>> classify him as Hispanic. I would also like to include the Hispanic >>>>>>> classification in two classification groups: US Minorities and >>>>>>> Non-White. I go to the Classifications tab - where I can create >>>>>>> classification groups from a list of pre-defined group types. I >>>>>>> choose the Minority type, type "US Minorities" in the Description >>>>>>> field, and save the group. I want to add the Hispanic classification >>>>>>> to this group, but I don't see any way to add classifications. I go >>>>>>> to Marc's profile page and try to assign him a classification, but I >>>>>>> can only assign him to a classification group. If I assign him to the >>>>>>> "US Minorities" group that still doesn't classify him as Hispanic. >>>>>>> >>>>>>> As far as I can tell, Party Classification doesn't work. >>>>>>> >>>>>>> Any ideas? >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> >>>>>>> --- On Mon, 1/3/11, Adrian Crum<[hidden email]> wrote: >>>>>>>> Understood. If we wanted to create >>>>>>>> entities to avoid the sub-types mentioned in the book >>>>>>>> (Organization Classification, Person Classisfication, etc) >>>>>>>> then I think we could have done that in a simpler way and >>>>>>>> still keep the book's model: >>>>>>>> >>>>>>>> PartyClassificationGroupType >>>>>>>> ---------------------------- >>>>>>>> *groupTypeId >>>>>>>> description >>>>>>>> parentGroupTypeId >>>>>>>> >>>>>>>> PartyClassificationGroup >>>>>>>> ------------------------ >>>>>>>> *groupTypeId >>>>>>>> *partyTypeId >>>>>>>> >>>>>>>> Anyways, I have come up with a workaround. I'll just use >>>>>>>> the existing PartyClassificationGroup the way the book uses >>>>>>>> PartyType. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> >>>>>>>> --- On Mon, 1/3/11, David E Jones<[hidden email]> >>>>>>>> wrote: >>>>>>>>> Every single *Type entity in OFBiz is a deviation from >>>>>>>> the >>>>>>>>> book (ie the *Type entities are an OFBiz pattern to >>>>>>>> avoid >>>>>>>>> redundant entities and keep track of entity extensions >>>>>>>> like >>>>>>>>> the Party -> PartyGroup,Person thingy), as are >>>>>>>> dozens of >>>>>>>>> other entities and hundreds of fields. That book is >>>>>>>> valuable >>>>>>>>> for general concepts and patterns, and is not an >>>>>>>> actual data >>>>>>>>> model to be used as-is. >>>>>>>>> >>>>>>>>> -David >>>>>>>>> >>>>>>>>> >>>>>>>>> On Jan 3, 2011, at 5:57 PM, Adrian Crum wrote: >>>>>>>>> >>>>>>>>>> I don't think I'm generalizing anything. The book >>>>>>>> is >>>>>>>>> pretty specific and clear: Party Classification is an >>>>>>>>> intersection entity that sets up a many-to-many >>>>>>>> relationship >>>>>>>>> between the Party entity and the Party Type entity. >>>>>>>>>> I understand OFBiz deviates from the book here >>>>>>>> and >>>>>>>>> there, and if this is one of those cases, then I'll >>>>>>>> ask >>>>>>>>> again: Why was it done that way? >>>>>>>>>> I'm trying to make sense of the OFBiz Party >>>>>>>>> Classification model, and so far it doesn't make >>>>>>>> sense. The >>>>>>>>> way it is set up, I can't give a party a >>>>>>>> classification >>>>>>>>> without first creating a classification group, assign >>>>>>>> a >>>>>>>>> classification type to it, and then assign the party >>>>>>>> to the >>>>>>>>> classification group using party classification. >>>>>>>>>> In the book it's much simpler - I just assign a >>>>>>>> party >>>>>>>>> type to a party using a party classification. >>>>>>>> Classification >>>>>>>>> groups are Party Classification sub-types and they >>>>>>>> aren't >>>>>>>>> necessary unless I want to group things a certain >>>>>>>> way. >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> --- On Mon, 1/3/11, David E Jones<[hidden email]> >>>>>>>>> wrote: >>>>>>>>>>> I think you may be taking the specific term >>>>>>>> "type" >>>>>>>>> and >>>>>>>>>>> generalizing it. Consider that *Type entities >>>>>>>> in >>>>>>>>> OFBiz mean >>>>>>>>>>> something very specific, and it is different >>>>>>>> from >>>>>>>>> the more >>>>>>>>>>> general use of the term in the book. >>>>>>>>>>> >>>>>>>>>>> -David >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Jan 3, 2011, at 3:24 PM, Adrian Crum >>>>>>>> wrote: >>>>>>>>>>>> That's not what the book shows. There is >>>>>>>> a >>>>>>>>> simple >>>>>>>>>>> relationship: >>>>>>>>>>>> Party -> PartyClassification -> >>>>>>>>> PartyType >>>>>>>>>>>> If you want to group classifications, >>>>>>>> give >>>>>>>>> them >>>>>>>>>>> parent/child relationships, etc then you do >>>>>>>> it >>>>>>>>> with >>>>>>>>>>> PartyType, not PartyClassification. Look at >>>>>>>> table >>>>>>>>> 2.3 on >>>>>>>>>>> page 32. >>>>>>>>>>>> -Adrian >>>>>>>>>>>> >>>>>>>>>>>> --- On Mon, 1/3/11, BJ Freeman<[hidden email]> >>>>>>>>>>> wrote: >>>>>>>>>>>>> how about a pattern of parent child >>>>>>>>>>>>> for PartyClassification of supertype >>>>>>>>>>>>> and the sub types then use a >>>>>>>>>>> table for the >>>>>>>>>>>>> attributess of the subtype. >>>>>>>>>>>>> this would allow walking the parnent >>>>>>>>> child >>>>>>>>>>> relationships. >>>>>>>>>>>>> PartyClassification >>>>>>>>>>>>> >>>>>>>> --->organizationClassification---->minorityClassification >>>>>>>>> ---->industryclassification >>>>>>>>>>>>> ========================= >>>>>>>>>>>>> BJ Freeman >>>>>>>>>>>>> Strategic Power Office with Supplier >>>>>>>>> Automation >>>>>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/> >>>>>>>>>>>>> Systems Integrator-- Glad to Assist >>>>>>>>>>>>> >>>>>>>>>>>>> Chat Y! messenger: bjfr33man >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Adrian Crum sent the following on >>>>>>>> 1/3/2011 >>>>>>>>> 2:46 >>>>>>>>>>> PM: >>>>>>>>>>>>>> PartyClassificationGroup should >>>>>>>> have >>>>>>>>> a >>>>>>>>>>> one-to-one >>>>>>>>>>>>> relationship with an entity called >>>>>>>>>>>>> PartyClassificationGroupType. >>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- On Mon, 1/3/11, BJ >>>>>>>> Freeman<[hidden email]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> so the Party Classification >>>>>>>> Group >>>>>>>>>>>>>>> table would have a one to >>>>>>>> one >>>>>>>>> with >>>>>>>>>>>>>>> Classification Types >>>>>>>>>>>>>>> or vica versa. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ========================= >>>>>>>>>>>>>>> BJ Freeman >>>>>>>>>>>>>>> Strategic Power Office with >>>>>>>>> Supplier >>>>>>>>>>> Automation >>>>>>>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/> >>>>>>>>>>>>>>> Systems Integrator-- Glad to >>>>>>>>> Assist >>>>>>>>>>>>>>> Chat Y! messenger: >>>>>>>>> bjfr33man >>>>>>>>>>>>>>> Adrian Crum sent the >>>>>>>> following on >>>>>>>>> 1/3/2011 >>>>>>>>>>> 1:41 >>>>>>>>>>>>> PM: >>>>>>>>>>>>>>>> Looking into this more, >>>>>>>> The >>>>>>>>> Data >>>>>>>>>>> Model >>>>>>>>>>>>> Resource Book >>>>>>>>>>>>>>> mentions classification >>>>>>>> groups - >>>>>>>>> but I >>>>>>>>>>> believe the >>>>>>>>>>>>> author >>>>>>>>>>>>>>> meant that Party Types could >>>>>>>> be >>>>>>>>> grouped >>>>>>>>>>> together >>>>>>>>>>>>> in >>>>>>>>>>>>>>> classification groups. In >>>>>>>> other >>>>>>>>> words, >>>>>>>>>>> the >>>>>>>>>>>>> classification >>>>>>>>>>>>>>> groups are defined by the >>>>>>>> data >>>>>>>>> contained >>>>>>>>>>> in the >>>>>>>>>>>>> Party Type >>>>>>>>>>>>>>> table - not in a separate >>>>>>>> "Party >>>>>>>>>>> Classification >>>>>>>>>>>>> Group" >>>>>>>>>>>>>>> table. There is nothing >>>>>>>> stopping >>>>>>>>> us from >>>>>>>>>>> having a >>>>>>>>>>>>> Party >>>>>>>>>>>>>>> Classification Group table, >>>>>>>> but it >>>>>>>>> should >>>>>>>>>>> group >>>>>>>>>>>>> Party Types, >>>>>>>>>>>>>>> not "Classification Types." >>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --- On Mon, 1/3/11, >>>>>>>> Adrian >>>>>>>>> Crum<[hidden email]> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> Looking at The Data >>>>>>>> Model >>>>>>>>>>> Resource >>>>>>>>>>>>>>>>> Book and the way >>>>>>>> OFBiz >>>>>>>>> models >>>>>>>>>>> Party >>>>>>>>>>>>>>> Classification, it >>>>>>>>>>>>>>>>> appears to me OFBiz >>>>>>>> models >>>>>>>>> it >>>>>>>>>>> wrong. >>>>>>>>>>>>>>>>> According to the >>>>>>>> book, the >>>>>>>>> Party >>>>>>>>>>>>> Classification >>>>>>>>>>>>>>> entity ties >>>>>>>>>>>>>>>>> a Party to a Party >>>>>>>> Type >>>>>>>>> with a >>>>>>>>>>> from and >>>>>>>>>>>>> thru >>>>>>>>>>>>>>> date. >>>>>>>>>>>>>>>>> In OFBiz, the Party >>>>>>>>> Classification >>>>>>>>>>> entity >>>>>>>>>>>>> ties a >>>>>>>>>>>>>>> Party to a >>>>>>>>>>>>>>>>> Party Classification >>>>>>>> Group >>>>>>>>> with a >>>>>>>>>>> from and >>>>>>>>>>>>> thru >>>>>>>>>>>>>>> date. The >>>>>>>>>>>>>>>>> Party Type is tied >>>>>>>>> directly to >>>>>>>>>>> Party with >>>>>>>>>>>>> no from >>>>>>>>>>>>>>> and thru >>>>>>>>>>>>>>>>> date. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Was that intentional? >>>>>>>> Why >>>>>>>>> was it >>>>>>>>>>> done that >>>>>>>>>>>>> way? >>>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>> |
Re: Party Classification Data Modeling
|
|
What is wrong with the solution I proposed?
-Adrian On 9/4/2011 8:23 PM, Jacques Le Roux wrote: > Davis has suggested to follow the ProductCategoryRollup pattern > http://markmail.org/message/ybd4lig4k67vdowm > > Is it not what you need (ie to introduce a graph instead of a tree and > gain flexibility)? > > Jacques > > From: "Adrian Crum" <[hidden email]> >> The marketing department will want to group party classifications one >> way. The human resources department will want to group party >> classifications another way. A department head might want to group >> subordinates a certain way. How is each party classification grouping >> handled without redundant and potentially stale data? By grouping >> party classifications instead of grouping parties. When a party's >> classification changes, their membership in the various party >> classification groups changes automatically. >> >> It's simple and flexible. >> >> -Adrian >> >> >> On 9/4/2011 7:47 PM, BJ Freeman wrote: >>> Looks like I missed an important part of you thinking. >>> >>> Adrian Crum sent the following on 9/4/2011 11:36 AM: >>>> No, I want Hispanic to be a member of an arbitrary number of groups. >>>> >>>> -Adrian >>>> >>>> On 9/4/2011 7:34 PM, BJ Freeman wrote: >>>>> Parent child is the same as grouping in my view. >>>>> it even gives you a hierarchy >>>>> so if you point to Hispanic you can find it under Minorities. >>>>> if you want to further define Hispanic, Like Castillian or Mexican >>>>> they >>>>> can be child of Hispanic >>>>> >>>>> Adrian Crum sent the following on 9/4/2011 11:10 AM: >>>>>> And your point is? That doesn't assign Hispanic to a classification >>>>>> group, it only makes Hispanic a child classification of the Minority >>>>>> Classification. >>>>>> >>>>>> At any rate, I have implemented the pattern I needed locally, and >>>>>> I have >>>>>> given up trying to make the case for an improved Party >>>>>> Classification >>>>>> data model. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> On 9/4/2011 7:04 PM, BJ Freeman wrote: >>>>>>> <PartyClassificationType description="Minority" hasTable="N" >>>>>>> parentTypeId="" partyClassificationTypeId="MINORITY_CLASSIFICAT"/> >>>>>>> <PartyClassificationType description="Hispanic" hasTable="N" >>>>>>> parentTypeId="MINORITY_CLASSIFICA" >>>>>>> partyClassificationTypeId="HISPANIC_CLASSIFICAT"/> >>>>>>> >>>>>>> >>>>>>> Adrian Crum sent the following on 1/10/2011 4:27 PM: >>>>>>>> I spent some time in Party Manager trying to make sense of the >>>>>>>> Party >>>>>>>> Classification feature, and I can't seem to make it do anything >>>>>>>> meaningful. Maybe I'm not understanding something, so I'll >>>>>>>> provide an >>>>>>>> example and see if anyone knows how to implement it in the current >>>>>>>> code. >>>>>>>> >>>>>>>> In table 2.3 of the Data Model Resource Book, there is a party >>>>>>>> named >>>>>>>> Marc Martinez who has been classified as Hispanic. I will use >>>>>>>> him for >>>>>>>> my example. >>>>>>>> >>>>>>>> In Party Manager I create a person named Marc Martinez and I >>>>>>>> want to >>>>>>>> classify him as Hispanic. I would also like to include the >>>>>>>> Hispanic >>>>>>>> classification in two classification groups: US Minorities and >>>>>>>> Non-White. I go to the Classifications tab - where I can create >>>>>>>> classification groups from a list of pre-defined group types. I >>>>>>>> choose the Minority type, type "US Minorities" in the Description >>>>>>>> field, and save the group. I want to add the Hispanic >>>>>>>> classification >>>>>>>> to this group, but I don't see any way to add classifications. >>>>>>>> I go >>>>>>>> to Marc's profile page and try to assign him a classification, >>>>>>>> but I >>>>>>>> can only assign him to a classification group. If I assign him >>>>>>>> to the >>>>>>>> "US Minorities" group that still doesn't classify him as Hispanic. >>>>>>>> >>>>>>>> As far as I can tell, Party Classification doesn't work. >>>>>>>> >>>>>>>> Any ideas? >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> >>>>>>>> --- On Mon, 1/3/11, Adrian Crum<[hidden email]> wrote: >>>>>>>>> Understood. If we wanted to create >>>>>>>>> entities to avoid the sub-types mentioned in the book >>>>>>>>> (Organization Classification, Person Classisfication, etc) >>>>>>>>> then I think we could have done that in a simpler way and >>>>>>>>> still keep the book's model: >>>>>>>>> >>>>>>>>> PartyClassificationGroupType >>>>>>>>> ---------------------------- >>>>>>>>> *groupTypeId >>>>>>>>> description >>>>>>>>> parentGroupTypeId >>>>>>>>> >>>>>>>>> PartyClassificationGroup >>>>>>>>> ------------------------ >>>>>>>>> *groupTypeId >>>>>>>>> *partyTypeId >>>>>>>>> >>>>>>>>> Anyways, I have come up with a workaround. I'll just use >>>>>>>>> the existing PartyClassificationGroup the way the book uses >>>>>>>>> PartyType. >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> --- On Mon, 1/3/11, David E Jones<[hidden email]> >>>>>>>>> wrote: >>>>>>>>>> Every single *Type entity in OFBiz is a deviation from >>>>>>>>> the >>>>>>>>>> book (ie the *Type entities are an OFBiz pattern to >>>>>>>>> avoid >>>>>>>>>> redundant entities and keep track of entity extensions >>>>>>>>> like >>>>>>>>>> the Party -> PartyGroup,Person thingy), as are >>>>>>>>> dozens of >>>>>>>>>> other entities and hundreds of fields. That book is >>>>>>>>> valuable >>>>>>>>>> for general concepts and patterns, and is not an >>>>>>>>> actual data >>>>>>>>>> model to be used as-is. >>>>>>>>>> >>>>>>>>>> -David >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Jan 3, 2011, at 5:57 PM, Adrian Crum wrote: >>>>>>>>>> >>>>>>>>>>> I don't think I'm generalizing anything. The book >>>>>>>>> is >>>>>>>>>> pretty specific and clear: Party Classification is an >>>>>>>>>> intersection entity that sets up a many-to-many >>>>>>>>> relationship >>>>>>>>>> between the Party entity and the Party Type entity. >>>>>>>>>>> I understand OFBiz deviates from the book here >>>>>>>>> and >>>>>>>>>> there, and if this is one of those cases, then I'll >>>>>>>>> ask >>>>>>>>>> again: Why was it done that way? >>>>>>>>>>> I'm trying to make sense of the OFBiz Party >>>>>>>>>> Classification model, and so far it doesn't make >>>>>>>>> sense. The >>>>>>>>>> way it is set up, I can't give a party a >>>>>>>>> classification >>>>>>>>>> without first creating a classification group, assign >>>>>>>>> a >>>>>>>>>> classification type to it, and then assign the party >>>>>>>>> to the >>>>>>>>>> classification group using party classification. >>>>>>>>>>> In the book it's much simpler - I just assign a >>>>>>>>> party >>>>>>>>>> type to a party using a party classification. >>>>>>>>> Classification >>>>>>>>>> groups are Party Classification sub-types and they >>>>>>>>> aren't >>>>>>>>>> necessary unless I want to group things a certain >>>>>>>>> way. >>>>>>>>>>> -Adrian >>>>>>>>>>> >>>>>>>>>>> --- On Mon, 1/3/11, David E Jones<[hidden email]> >>>>>>>>>> wrote: >>>>>>>>>>>> I think you may be taking the specific term >>>>>>>>> "type" >>>>>>>>>> and >>>>>>>>>>>> generalizing it. Consider that *Type entities >>>>>>>>> in >>>>>>>>>> OFBiz mean >>>>>>>>>>>> something very specific, and it is different >>>>>>>>> from >>>>>>>>>> the more >>>>>>>>>>>> general use of the term in the book. >>>>>>>>>>>> >>>>>>>>>>>> -David >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Jan 3, 2011, at 3:24 PM, Adrian Crum >>>>>>>>> wrote: >>>>>>>>>>>>> That's not what the book shows. There is >>>>>>>>> a >>>>>>>>>> simple >>>>>>>>>>>> relationship: >>>>>>>>>>>>> Party -> PartyClassification -> >>>>>>>>>> PartyType >>>>>>>>>>>>> If you want to group classifications, >>>>>>>>> give >>>>>>>>>> them >>>>>>>>>>>> parent/child relationships, etc then you do >>>>>>>>> it >>>>>>>>>> with >>>>>>>>>>>> PartyType, not PartyClassification. Look at >>>>>>>>> table >>>>>>>>>> 2.3 on >>>>>>>>>>>> page 32. >>>>>>>>>>>>> -Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> --- On Mon, 1/3/11, BJ Freeman<[hidden email]> >>>>>>>>>>>> wrote: >>>>>>>>>>>>>> how about a pattern of parent child >>>>>>>>>>>>>> for PartyClassification of supertype >>>>>>>>>>>>>> and the sub types then use a >>>>>>>>>>>> table for the >>>>>>>>>>>>>> attributess of the subtype. >>>>>>>>>>>>>> this would allow walking the parnent >>>>>>>>>> child >>>>>>>>>>>> relationships. >>>>>>>>>>>>>> PartyClassification >>>>>>>>>>>>>> >>>>>>>>> --->organizationClassification---->minorityClassification >>>>>>>>>> ---->industryclassification >>>>>>>>>>>>>> ========================= >>>>>>>>>>>>>> BJ Freeman >>>>>>>>>>>>>> Strategic Power Office with Supplier >>>>>>>>>> Automation >>>>>>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/> >>>>>>>>>>>>>> Systems Integrator-- Glad to Assist >>>>>>>>>>>>>> >>>>>>>>>>>>>> Chat Y! messenger: bjfr33man >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian Crum sent the following on >>>>>>>>> 1/3/2011 >>>>>>>>>> 2:46 >>>>>>>>>>>> PM: >>>>>>>>>>>>>>> PartyClassificationGroup should >>>>>>>>> have >>>>>>>>>> a >>>>>>>>>>>> one-to-one >>>>>>>>>>>>>> relationship with an entity called >>>>>>>>>>>>>> PartyClassificationGroupType. >>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --- On Mon, 1/3/11, BJ >>>>>>>>> Freeman<[hidden email]> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> so the Party Classification >>>>>>>>> Group >>>>>>>>>>>>>>>> table would have a one to >>>>>>>>> one >>>>>>>>>> with >>>>>>>>>>>>>>>> Classification Types >>>>>>>>>>>>>>>> or vica versa. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ========================= >>>>>>>>>>>>>>>> BJ Freeman >>>>>>>>>>>>>>>> Strategic Power Office with >>>>>>>>>> Supplier >>>>>>>>>>>> Automation >>>>>>>>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/> >>>>>>>>>>>>>>>> Systems Integrator-- Glad to >>>>>>>>>> Assist >>>>>>>>>>>>>>>> Chat Y! messenger: >>>>>>>>>> bjfr33man >>>>>>>>>>>>>>>> Adrian Crum sent the >>>>>>>>> following on >>>>>>>>>> 1/3/2011 >>>>>>>>>>>> 1:41 >>>>>>>>>>>>>> PM: >>>>>>>>>>>>>>>>> Looking into this more, >>>>>>>>> The >>>>>>>>>> Data >>>>>>>>>>>> Model >>>>>>>>>>>>>> Resource Book >>>>>>>>>>>>>>>> mentions classification >>>>>>>>> groups - >>>>>>>>>> but I >>>>>>>>>>>> believe the >>>>>>>>>>>>>> author >>>>>>>>>>>>>>>> meant that Party Types could >>>>>>>>> be >>>>>>>>>> grouped >>>>>>>>>>>> together >>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> classification groups. In >>>>>>>>> other >>>>>>>>>> words, >>>>>>>>>>>> the >>>>>>>>>>>>>> classification >>>>>>>>>>>>>>>> groups are defined by the >>>>>>>>> data >>>>>>>>>> contained >>>>>>>>>>>> in the >>>>>>>>>>>>>> Party Type >>>>>>>>>>>>>>>> table - not in a separate >>>>>>>>> "Party >>>>>>>>>>>> Classification >>>>>>>>>>>>>> Group" >>>>>>>>>>>>>>>> table. There is nothing >>>>>>>>> stopping >>>>>>>>>> us from >>>>>>>>>>>> having a >>>>>>>>>>>>>> Party >>>>>>>>>>>>>>>> Classification Group table, >>>>>>>>> but it >>>>>>>>>> should >>>>>>>>>>>> group >>>>>>>>>>>>>> Party Types, >>>>>>>>>>>>>>>> not "Classification Types." >>>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --- On Mon, 1/3/11, >>>>>>>>> Adrian >>>>>>>>>> Crum<[hidden email]> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> Looking at The Data >>>>>>>>> Model >>>>>>>>>>>> Resource >>>>>>>>>>>>>>>>>> Book and the way >>>>>>>>> OFBiz >>>>>>>>>> models >>>>>>>>>>>> Party >>>>>>>>>>>>>>>> Classification, it >>>>>>>>>>>>>>>>>> appears to me OFBiz >>>>>>>>> models >>>>>>>>>> it >>>>>>>>>>>> wrong. >>>>>>>>>>>>>>>>>> According to the >>>>>>>>> book, the >>>>>>>>>> Party >>>>>>>>>>>>>> Classification >>>>>>>>>>>>>>>> entity ties >>>>>>>>>>>>>>>>>> a Party to a Party >>>>>>>>> Type >>>>>>>>>> with a >>>>>>>>>>>> from and >>>>>>>>>>>>>> thru >>>>>>>>>>>>>>>> date. >>>>>>>>>>>>>>>>>> In OFBiz, the Party >>>>>>>>>> Classification >>>>>>>>>>>> entity >>>>>>>>>>>>>> ties a >>>>>>>>>>>>>>>> Party to a >>>>>>>>>>>>>>>>>> Party Classification >>>>>>>>> Group >>>>>>>>>> with a >>>>>>>>>>>> from and >>>>>>>>>>>>>> thru >>>>>>>>>>>>>>>> date. The >>>>>>>>>>>>>>>>>> Party Type is tied >>>>>>>>>> directly to >>>>>>>>>>>> Party with >>>>>>>>>>>>>> no from >>>>>>>>>>>>>>>> and thru >>>>>>>>>>>>>>>>>> date. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Was that intentional? >>>>>>>>> Why >>>>>>>>>> was it >>>>>>>>>>>> done that >>>>>>>>>>>>>> way? >>>>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>> > |
Re: Party Classification Data Modeling
|
|
In reply to this post by Adrian Crum-3
Thanks once i get some other stuff out of the way will try to evaluate
what this means. Adrian Crum sent the following on 9/4/2011 11:54 AM: > The marketing department will want to group party classifications one > way. The human resources department will want to group party > classifications another way. A department head might want to group > subordinates a certain way. How is each party classification grouping > handled without redundant and potentially stale data? By grouping party > classifications instead of grouping parties. When a party's > classification changes, their membership in the various party > classification groups changes automatically. > > It's simple and flexible. > > -Adrian > > > On 9/4/2011 7:47 PM, BJ Freeman wrote: >> Looks like I missed an important part of you thinking. >> >> Adrian Crum sent the following on 9/4/2011 11:36 AM: >>> No, I want Hispanic to be a member of an arbitrary number of groups. >>> >>> -Adrian >>> >>> On 9/4/2011 7:34 PM, BJ Freeman wrote: >>>> Parent child is the same as grouping in my view. >>>> it even gives you a hierarchy >>>> so if you point to Hispanic you can find it under Minorities. >>>> if you want to further define Hispanic, Like Castillian or Mexican they >>>> can be child of Hispanic >>>> >>>> Adrian Crum sent the following on 9/4/2011 11:10 AM: >>>>> And your point is? That doesn't assign Hispanic to a classification >>>>> group, it only makes Hispanic a child classification of the Minority >>>>> Classification. >>>>> >>>>> At any rate, I have implemented the pattern I needed locally, and I >>>>> have >>>>> given up trying to make the case for an improved Party Classification >>>>> data model. >>>>> >>>>> -Adrian >>>>> >>>>> On 9/4/2011 7:04 PM, BJ Freeman wrote: >>>>>> <PartyClassificationType description="Minority" hasTable="N" >>>>>> parentTypeId="" partyClassificationTypeId="MINORITY_CLASSIFICAT"/> >>>>>> <PartyClassificationType description="Hispanic" hasTable="N" >>>>>> parentTypeId="MINORITY_CLASSIFICA" >>>>>> partyClassificationTypeId="HISPANIC_CLASSIFICAT"/> >>>>>> >>>>>> >>>>>> Adrian Crum sent the following on 1/10/2011 4:27 PM: >>>>>>> I spent some time in Party Manager trying to make sense of the Party >>>>>>> Classification feature, and I can't seem to make it do anything >>>>>>> meaningful. Maybe I'm not understanding something, so I'll >>>>>>> provide an >>>>>>> example and see if anyone knows how to implement it in the current >>>>>>> code. >>>>>>> >>>>>>> In table 2.3 of the Data Model Resource Book, there is a party named >>>>>>> Marc Martinez who has been classified as Hispanic. I will use him >>>>>>> for >>>>>>> my example. >>>>>>> >>>>>>> In Party Manager I create a person named Marc Martinez and I want to >>>>>>> classify him as Hispanic. I would also like to include the Hispanic >>>>>>> classification in two classification groups: US Minorities and >>>>>>> Non-White. I go to the Classifications tab - where I can create >>>>>>> classification groups from a list of pre-defined group types. I >>>>>>> choose the Minority type, type "US Minorities" in the Description >>>>>>> field, and save the group. I want to add the Hispanic classification >>>>>>> to this group, but I don't see any way to add classifications. I go >>>>>>> to Marc's profile page and try to assign him a classification, but I >>>>>>> can only assign him to a classification group. If I assign him to >>>>>>> the >>>>>>> "US Minorities" group that still doesn't classify him as Hispanic. >>>>>>> >>>>>>> As far as I can tell, Party Classification doesn't work. >>>>>>> >>>>>>> Any ideas? >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> >>>>>>> --- On Mon, 1/3/11, Adrian Crum<[hidden email]> wrote: >>>>>>>> Understood. If we wanted to create >>>>>>>> entities to avoid the sub-types mentioned in the book >>>>>>>> (Organization Classification, Person Classisfication, etc) >>>>>>>> then I think we could have done that in a simpler way and >>>>>>>> still keep the book's model: >>>>>>>> >>>>>>>> PartyClassificationGroupType >>>>>>>> ---------------------------- >>>>>>>> *groupTypeId >>>>>>>> description >>>>>>>> parentGroupTypeId >>>>>>>> >>>>>>>> PartyClassificationGroup >>>>>>>> ------------------------ >>>>>>>> *groupTypeId >>>>>>>> *partyTypeId >>>>>>>> >>>>>>>> Anyways, I have come up with a workaround. I'll just use >>>>>>>> the existing PartyClassificationGroup the way the book uses >>>>>>>> PartyType. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> >>>>>>>> --- On Mon, 1/3/11, David E Jones<[hidden email]> >>>>>>>> wrote: >>>>>>>>> Every single *Type entity in OFBiz is a deviation from >>>>>>>> the >>>>>>>>> book (ie the *Type entities are an OFBiz pattern to >>>>>>>> avoid >>>>>>>>> redundant entities and keep track of entity extensions >>>>>>>> like >>>>>>>>> the Party -> PartyGroup,Person thingy), as are >>>>>>>> dozens of >>>>>>>>> other entities and hundreds of fields. That book is >>>>>>>> valuable >>>>>>>>> for general concepts and patterns, and is not an >>>>>>>> actual data >>>>>>>>> model to be used as-is. >>>>>>>>> >>>>>>>>> -David >>>>>>>>> >>>>>>>>> >>>>>>>>> On Jan 3, 2011, at 5:57 PM, Adrian Crum wrote: >>>>>>>>> >>>>>>>>>> I don't think I'm generalizing anything. The book >>>>>>>> is >>>>>>>>> pretty specific and clear: Party Classification is an >>>>>>>>> intersection entity that sets up a many-to-many >>>>>>>> relationship >>>>>>>>> between the Party entity and the Party Type entity. >>>>>>>>>> I understand OFBiz deviates from the book here >>>>>>>> and >>>>>>>>> there, and if this is one of those cases, then I'll >>>>>>>> ask >>>>>>>>> again: Why was it done that way? >>>>>>>>>> I'm trying to make sense of the OFBiz Party >>>>>>>>> Classification model, and so far it doesn't make >>>>>>>> sense. The >>>>>>>>> way it is set up, I can't give a party a >>>>>>>> classification >>>>>>>>> without first creating a classification group, assign >>>>>>>> a >>>>>>>>> classification type to it, and then assign the party >>>>>>>> to the >>>>>>>>> classification group using party classification. >>>>>>>>>> In the book it's much simpler - I just assign a >>>>>>>> party >>>>>>>>> type to a party using a party classification. >>>>>>>> Classification >>>>>>>>> groups are Party Classification sub-types and they >>>>>>>> aren't >>>>>>>>> necessary unless I want to group things a certain >>>>>>>> way. >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> --- On Mon, 1/3/11, David E Jones<[hidden email]> >>>>>>>>> wrote: >>>>>>>>>>> I think you may be taking the specific term >>>>>>>> "type" >>>>>>>>> and >>>>>>>>>>> generalizing it. Consider that *Type entities >>>>>>>> in >>>>>>>>> OFBiz mean >>>>>>>>>>> something very specific, and it is different >>>>>>>> from >>>>>>>>> the more >>>>>>>>>>> general use of the term in the book. >>>>>>>>>>> >>>>>>>>>>> -David >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Jan 3, 2011, at 3:24 PM, Adrian Crum >>>>>>>> wrote: >>>>>>>>>>>> That's not what the book shows. There is >>>>>>>> a >>>>>>>>> simple >>>>>>>>>>> relationship: >>>>>>>>>>>> Party -> PartyClassification -> >>>>>>>>> PartyType >>>>>>>>>>>> If you want to group classifications, >>>>>>>> give >>>>>>>>> them >>>>>>>>>>> parent/child relationships, etc then you do >>>>>>>> it >>>>>>>>> with >>>>>>>>>>> PartyType, not PartyClassification. Look at >>>>>>>> table >>>>>>>>> 2.3 on >>>>>>>>>>> page 32. >>>>>>>>>>>> -Adrian >>>>>>>>>>>> >>>>>>>>>>>> --- On Mon, 1/3/11, BJ Freeman<[hidden email]> >>>>>>>>>>> wrote: >>>>>>>>>>>>> how about a pattern of parent child >>>>>>>>>>>>> for PartyClassification of supertype >>>>>>>>>>>>> and the sub types then use a >>>>>>>>>>> table for the >>>>>>>>>>>>> attributess of the subtype. >>>>>>>>>>>>> this would allow walking the parnent >>>>>>>>> child >>>>>>>>>>> relationships. >>>>>>>>>>>>> PartyClassification >>>>>>>>>>>>> >>>>>>>> --->organizationClassification---->minorityClassification >>>>>>>>> ---->industryclassification >>>>>>>>>>>>> ========================= >>>>>>>>>>>>> BJ Freeman >>>>>>>>>>>>> Strategic Power Office with Supplier >>>>>>>>> Automation >>>>>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>>>>>>> >>>>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/> >>>>>>>>>>>>> Systems Integrator-- Glad to Assist >>>>>>>>>>>>> >>>>>>>>>>>>> Chat Y! messenger: bjfr33man >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Adrian Crum sent the following on >>>>>>>> 1/3/2011 >>>>>>>>> 2:46 >>>>>>>>>>> PM: >>>>>>>>>>>>>> PartyClassificationGroup should >>>>>>>> have >>>>>>>>> a >>>>>>>>>>> one-to-one >>>>>>>>>>>>> relationship with an entity called >>>>>>>>>>>>> PartyClassificationGroupType. >>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- On Mon, 1/3/11, BJ >>>>>>>> Freeman<[hidden email]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> so the Party Classification >>>>>>>> Group >>>>>>>>>>>>>>> table would have a one to >>>>>>>> one >>>>>>>>> with >>>>>>>>>>>>>>> Classification Types >>>>>>>>>>>>>>> or vica versa. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ========================= >>>>>>>>>>>>>>> BJ Freeman >>>>>>>>>>>>>>> Strategic Power Office with >>>>>>>>> Supplier >>>>>>>>>>> Automation >>>>>>>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/> >>>>>>>>>>>>>>> Systems Integrator-- Glad to >>>>>>>>> Assist >>>>>>>>>>>>>>> Chat Y! messenger: >>>>>>>>> bjfr33man >>>>>>>>>>>>>>> Adrian Crum sent the >>>>>>>> following on >>>>>>>>> 1/3/2011 >>>>>>>>>>> 1:41 >>>>>>>>>>>>> PM: >>>>>>>>>>>>>>>> Looking into this more, >>>>>>>> The >>>>>>>>> Data >>>>>>>>>>> Model >>>>>>>>>>>>> Resource Book >>>>>>>>>>>>>>> mentions classification >>>>>>>> groups - >>>>>>>>> but I >>>>>>>>>>> believe the >>>>>>>>>>>>> author >>>>>>>>>>>>>>> meant that Party Types could >>>>>>>> be >>>>>>>>> grouped >>>>>>>>>>> together >>>>>>>>>>>>> in >>>>>>>>>>>>>>> classification groups. In >>>>>>>> other >>>>>>>>> words, >>>>>>>>>>> the >>>>>>>>>>>>> classification >>>>>>>>>>>>>>> groups are defined by the >>>>>>>> data >>>>>>>>> contained >>>>>>>>>>> in the >>>>>>>>>>>>> Party Type >>>>>>>>>>>>>>> table - not in a separate >>>>>>>> "Party >>>>>>>>>>> Classification >>>>>>>>>>>>> Group" >>>>>>>>>>>>>>> table. There is nothing >>>>>>>> stopping >>>>>>>>> us from >>>>>>>>>>> having a >>>>>>>>>>>>> Party >>>>>>>>>>>>>>> Classification Group table, >>>>>>>> but it >>>>>>>>> should >>>>>>>>>>> group >>>>>>>>>>>>> Party Types, >>>>>>>>>>>>>>> not "Classification Types." >>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --- On Mon, 1/3/11, >>>>>>>> Adrian >>>>>>>>> Crum<[hidden email]> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> Looking at The Data >>>>>>>> Model >>>>>>>>>>> Resource >>>>>>>>>>>>>>>>> Book and the way >>>>>>>> OFBiz >>>>>>>>> models >>>>>>>>>>> Party >>>>>>>>>>>>>>> Classification, it >>>>>>>>>>>>>>>>> appears to me OFBiz >>>>>>>> models >>>>>>>>> it >>>>>>>>>>> wrong. >>>>>>>>>>>>>>>>> According to the >>>>>>>> book, the >>>>>>>>> Party >>>>>>>>>>>>> Classification >>>>>>>>>>>>>>> entity ties >>>>>>>>>>>>>>>>> a Party to a Party >>>>>>>> Type >>>>>>>>> with a >>>>>>>>>>> from and >>>>>>>>>>>>> thru >>>>>>>>>>>>>>> date. >>>>>>>>>>>>>>>>> In OFBiz, the Party >>>>>>>>> Classification >>>>>>>>>>> entity >>>>>>>>>>>>> ties a >>>>>>>>>>>>>>> Party to a >>>>>>>>>>>>>>>>> Party Classification >>>>>>>> Group >>>>>>>>> with a >>>>>>>>>>> from and >>>>>>>>>>>>> thru >>>>>>>>>>>>>>> date. The >>>>>>>>>>>>>>>>> Party Type is tied >>>>>>>>> directly to >>>>>>>>>>> Party with >>>>>>>>>>>>> no from >>>>>>>>>>>>>>> and thru >>>>>>>>>>>>>>>>> date. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Was that intentional? >>>>>>>> Why >>>>>>>>> was it >>>>>>>>>>> done that >>>>>>>>>>>>> way? >>>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>> > |
Re: Party Classification Data Modeling
|
|
In reply to this post by BJ Freeman
The second one should be a PartyClassificataionGroup and not a type. -David On Sep 4, 2011, at 12:04 PM, BJ Freeman wrote: > <PartyClassificationType description="Minority" hasTable="N" > parentTypeId="" partyClassificationTypeId="MINORITY_CLASSIFICAT"/> > <PartyClassificationType description="Hispanic" hasTable="N" > parentTypeId="MINORITY_CLASSIFICA" > partyClassificationTypeId="HISPANIC_CLASSIFICAT"/> > > > Adrian Crum sent the following on 1/10/2011 4:27 PM: >> I spent some time in Party Manager trying to make sense of the Party Classification feature, and I can't seem to make it do anything meaningful. Maybe I'm not understanding something, so I'll provide an example and see if anyone knows how to implement it in the current code. >> >> In table 2.3 of the Data Model Resource Book, there is a party named Marc Martinez who has been classified as Hispanic. I will use him for my example. >> >> In Party Manager I create a person named Marc Martinez and I want to classify him as Hispanic. I would also like to include the Hispanic classification in two classification groups: US Minorities and Non-White. I go to the Classifications tab - where I can create classification groups from a list of pre-defined group types. I choose the Minority type, type "US Minorities" in the Description field, and save the group. I want to add the Hispanic classification to this group, but I don't see any way to add classifications. I go to Marc's profile page and try to assign him a classification, but I can only assign him to a classification group. If I assign him to the "US Minorities" group that still doesn't classify him as Hispanic. >> >> As far as I can tell, Party Classification doesn't work. >> >> Any ideas? >> >> -Adrian >> >> >> --- On Mon, 1/3/11, Adrian Crum <[hidden email]> wrote: >>> Understood. If we wanted to create >>> entities to avoid the sub-types mentioned in the book >>> (Organization Classification, Person Classisfication, etc) >>> then I think we could have done that in a simpler way and >>> still keep the book's model: >>> >>> PartyClassificationGroupType >>> ---------------------------- >>> *groupTypeId >>> description >>> parentGroupTypeId >>> >>> PartyClassificationGroup >>> ------------------------ >>> *groupTypeId >>> *partyTypeId >>> >>> Anyways, I have come up with a workaround. I'll just use >>> the existing PartyClassificationGroup the way the book uses >>> PartyType. >>> >>> -Adrian >>> >>> >>> --- On Mon, 1/3/11, David E Jones <[hidden email]> >>> wrote: >>>> Every single *Type entity in OFBiz is a deviation from >>> the >>>> book (ie the *Type entities are an OFBiz pattern to >>> avoid >>>> redundant entities and keep track of entity extensions >>> like >>>> the Party -> PartyGroup,Person thingy), as are >>> dozens of >>>> other entities and hundreds of fields. That book is >>> valuable >>>> for general concepts and patterns, and is not an >>> actual data >>>> model to be used as-is. >>>> >>>> -David >>>> >>>> >>>> On Jan 3, 2011, at 5:57 PM, Adrian Crum wrote: >>>> >>>>> I don't think I'm generalizing anything. The book >>> is >>>> pretty specific and clear: Party Classification is an >>>> intersection entity that sets up a many-to-many >>> relationship >>>> between the Party entity and the Party Type entity. >>>>> >>>>> I understand OFBiz deviates from the book here >>> and >>>> there, and if this is one of those cases, then I'll >>> ask >>>> again: Why was it done that way? >>>>> >>>>> I'm trying to make sense of the OFBiz Party >>>> Classification model, and so far it doesn't make >>> sense. The >>>> way it is set up, I can't give a party a >>> classification >>>> without first creating a classification group, assign >>> a >>>> classification type to it, and then assign the party >>> to the >>>> classification group using party classification. >>>>> >>>>> In the book it's much simpler - I just assign a >>> party >>>> type to a party using a party classification. >>> Classification >>>> groups are Party Classification sub-types and they >>> aren't >>>> necessary unless I want to group things a certain >>> way. >>>>> >>>>> -Adrian >>>>> >>>>> --- On Mon, 1/3/11, David E Jones <[hidden email]> >>>> wrote: >>>>>> I think you may be taking the specific term >>> "type" >>>> and >>>>>> generalizing it. Consider that *Type entities >>> in >>>> OFBiz mean >>>>>> something very specific, and it is different >>> from >>>> the more >>>>>> general use of the term in the book. >>>>>> >>>>>> -David >>>>>> >>>>>> >>>>>> On Jan 3, 2011, at 3:24 PM, Adrian Crum >>> wrote: >>>>>> >>>>>>> That's not what the book shows. There is >>> a >>>> simple >>>>>> relationship: >>>>>>> >>>>>>> Party -> PartyClassification -> >>>> PartyType >>>>>>> >>>>>>> If you want to group classifications, >>> give >>>> them >>>>>> parent/child relationships, etc then you do >>> it >>>> with >>>>>> PartyType, not PartyClassification. Look at >>> table >>>> 2.3 on >>>>>> page 32. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> --- On Mon, 1/3/11, BJ Freeman <[hidden email]> >>>>>> wrote: >>>>>>>> how about a pattern of parent child >>>>>>>> for PartyClassification of supertype >>> >>>>>>>> and the sub types then use a >>>>>> table for the >>>>>>>> attributess of the subtype. >>>>>>>> this would allow walking the parnent >>>> child >>>>>> relationships. >>>>>>>> PartyClassification >>>>>>>> >>>>>> >>>> >>> --->organizationClassification---->minorityClassification >>>>>>>> >>>> >>>>>> >>>>>>>> >>>> >>>>>>>> >>>> ---->industryclassification >>>>>>>> >>>>>>>> ========================= >>>>>>>> BJ Freeman >>>>>>>> Strategic Power Office with Supplier >>>> Automation >>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>> Specialtymarket.com <http://www.specialtymarket.com/> >>>>>>>> Systems Integrator-- Glad to Assist >>>>>>>> >>>>>>>> Chat Y! messenger: bjfr33man >>>>>>>> >>>>>>>> >>>>>>>> Adrian Crum sent the following on >>> 1/3/2011 >>>> 2:46 >>>>>> PM: >>>>>>>>> PartyClassificationGroup should >>> have >>>> a >>>>>> one-to-one >>>>>>>> relationship with an entity called >>>>>>>> PartyClassificationGroupType. >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> --- On Mon, 1/3/11, BJ >>> Freeman<[hidden email]> >>>>>> >>>>>>>> wrote: >>>>>>>>>> so the Party Classification >>> Group >>>>>>>>>> table would have a one to >>> one >>>> with >>>>>>>>>> Classification Types >>>>>>>>>> or vica versa. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ========================= >>>>>>>>>> BJ Freeman >>>>>>>>>> Strategic Power Office with >>>> Supplier >>>>>> Automation >>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/> >>>>>>>>>> Systems Integrator-- Glad to >>>> Assist >>>>>>>>>> >>>>>>>>>> Chat Y! messenger: >>>> bjfr33man >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Adrian Crum sent the >>> following on >>>> 1/3/2011 >>>>>> 1:41 >>>>>>>> PM: >>>>>>>>>>> Looking into this more, >>> The >>>> Data >>>>>> Model >>>>>>>> Resource Book >>>>>>>>>> mentions classification >>> groups - >>>> but I >>>>>> believe the >>>>>>>> author >>>>>>>>>> meant that Party Types could >>> be >>>> grouped >>>>>> together >>>>>>>> in >>>>>>>>>> classification groups. In >>> other >>>> words, >>>>>> the >>>>>>>> classification >>>>>>>>>> groups are defined by the >>> data >>>> contained >>>>>> in the >>>>>>>> Party Type >>>>>>>>>> table - not in a separate >>> "Party >>>>>> Classification >>>>>>>> Group" >>>>>>>>>> table. There is nothing >>> stopping >>>> us from >>>>>> having a >>>>>>>> Party >>>>>>>>>> Classification Group table, >>> but it >>>> should >>>>>> group >>>>>>>> Party Types, >>>>>>>>>> not "Classification Types." >>>>>>>>>>> >>>>>>>>>>> -Adrian >>>>>>>>>>> >>>>>>>>>>> --- On Mon, 1/3/11, >>> Adrian >>>> Crum<[hidden email]> >>>>>>>>>> wrote: >>>>>>>>>>>> Looking at The Data >>> Model >>>>>> Resource >>>>>>>>>>>> Book and the way >>> OFBiz >>>> models >>>>>> Party >>>>>>>>>> Classification, it >>>>>>>>>>>> appears to me OFBiz >>> models >>>> it >>>>>> wrong. >>>>>>>>>>>> >>>>>>>>>>>> According to the >>> book, the >>>> Party >>>>>>>> Classification >>>>>>>>>> entity ties >>>>>>>>>>>> a Party to a Party >>> Type >>>> with a >>>>>> from and >>>>>>>> thru >>>>>>>>>> date. >>>>>>>>>>>> >>>>>>>>>>>> In OFBiz, the Party >>>> Classification >>>>>> entity >>>>>>>> ties a >>>>>>>>>> Party to a >>>>>>>>>>>> Party Classification >>> Group >>>> with a >>>>>> from and >>>>>>>> thru >>>>>>>>>> date. The >>>>>>>>>>>> Party Type is tied >>>> directly to >>>>>> Party with >>>>>>>> no from >>>>>>>>>> and thru >>>>>>>>>>>> date. >>>>>>>>>>>> >>>>>>>>>>>> Was that intentional? >>> Why >>>> was it >>>>>> done that >>>>>>>> way? >>>>>>>>>>>> >>>>>>>>>>>> -Adrian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> |
Re: Party Classification Data Modeling
|
Administrator
|
In reply to this post by Adrian Crum-3
I did not said it's wrong. I was just asking if you have followed David's graph suggestion and how it's done with
ProductCategoryRollup. But maybe you are aiming at solving more than the tree issue? I will have a closer look at your proposition... Jacques From: "Adrian Crum" <[hidden email]> > What is wrong with the solution I proposed? > > -Adrian > > On 9/4/2011 8:23 PM, Jacques Le Roux wrote: >> Davis has suggested to follow the ProductCategoryRollup pattern >> http://markmail.org/message/ybd4lig4k67vdowm >> >> Is it not what you need (ie to introduce a graph instead of a tree and gain flexibility)? >> >> Jacques >> >> From: "Adrian Crum" <[hidden email]> >>> The marketing department will want to group party classifications one way. The human resources department will want to group >>> party classifications another way. A department head might want to group subordinates a certain way. How is each party >>> classification grouping handled without redundant and potentially stale data? By grouping party classifications instead of >>> grouping parties. When a party's classification changes, their membership in the various party classification groups changes >>> automatically. >>> >>> It's simple and flexible. >>> >>> -Adrian >>> >>> >>> On 9/4/2011 7:47 PM, BJ Freeman wrote: >>>> Looks like I missed an important part of you thinking. >>>> >>>> Adrian Crum sent the following on 9/4/2011 11:36 AM: >>>>> No, I want Hispanic to be a member of an arbitrary number of groups. >>>>> >>>>> -Adrian >>>>> >>>>> On 9/4/2011 7:34 PM, BJ Freeman wrote: >>>>>> Parent child is the same as grouping in my view. >>>>>> it even gives you a hierarchy >>>>>> so if you point to Hispanic you can find it under Minorities. >>>>>> if you want to further define Hispanic, Like Castillian or Mexican they >>>>>> can be child of Hispanic >>>>>> >>>>>> Adrian Crum sent the following on 9/4/2011 11:10 AM: >>>>>>> And your point is? That doesn't assign Hispanic to a classification >>>>>>> group, it only makes Hispanic a child classification of the Minority >>>>>>> Classification. >>>>>>> >>>>>>> At any rate, I have implemented the pattern I needed locally, and I have >>>>>>> given up trying to make the case for an improved Party Classification >>>>>>> data model. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> On 9/4/2011 7:04 PM, BJ Freeman wrote: >>>>>>>> <PartyClassificationType description="Minority" hasTable="N" >>>>>>>> parentTypeId="" partyClassificationTypeId="MINORITY_CLASSIFICAT"/> >>>>>>>> <PartyClassificationType description="Hispanic" hasTable="N" >>>>>>>> parentTypeId="MINORITY_CLASSIFICA" >>>>>>>> partyClassificationTypeId="HISPANIC_CLASSIFICAT"/> >>>>>>>> >>>>>>>> >>>>>>>> Adrian Crum sent the following on 1/10/2011 4:27 PM: >>>>>>>>> I spent some time in Party Manager trying to make sense of the Party >>>>>>>>> Classification feature, and I can't seem to make it do anything >>>>>>>>> meaningful. Maybe I'm not understanding something, so I'll provide an >>>>>>>>> example and see if anyone knows how to implement it in the current >>>>>>>>> code. >>>>>>>>> >>>>>>>>> In table 2.3 of the Data Model Resource Book, there is a party named >>>>>>>>> Marc Martinez who has been classified as Hispanic. I will use him for >>>>>>>>> my example. >>>>>>>>> >>>>>>>>> In Party Manager I create a person named Marc Martinez and I want to >>>>>>>>> classify him as Hispanic. I would also like to include the Hispanic >>>>>>>>> classification in two classification groups: US Minorities and >>>>>>>>> Non-White. I go to the Classifications tab - where I can create >>>>>>>>> classification groups from a list of pre-defined group types. I >>>>>>>>> choose the Minority type, type "US Minorities" in the Description >>>>>>>>> field, and save the group. I want to add the Hispanic classification >>>>>>>>> to this group, but I don't see any way to add classifications. I go >>>>>>>>> to Marc's profile page and try to assign him a classification, but I >>>>>>>>> can only assign him to a classification group. If I assign him to the >>>>>>>>> "US Minorities" group that still doesn't classify him as Hispanic. >>>>>>>>> >>>>>>>>> As far as I can tell, Party Classification doesn't work. >>>>>>>>> >>>>>>>>> Any ideas? >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> --- On Mon, 1/3/11, Adrian Crum<[hidden email]> wrote: >>>>>>>>>> Understood. If we wanted to create >>>>>>>>>> entities to avoid the sub-types mentioned in the book >>>>>>>>>> (Organization Classification, Person Classisfication, etc) >>>>>>>>>> then I think we could have done that in a simpler way and >>>>>>>>>> still keep the book's model: >>>>>>>>>> >>>>>>>>>> PartyClassificationGroupType >>>>>>>>>> ---------------------------- >>>>>>>>>> *groupTypeId >>>>>>>>>> description >>>>>>>>>> parentGroupTypeId >>>>>>>>>> >>>>>>>>>> PartyClassificationGroup >>>>>>>>>> ------------------------ >>>>>>>>>> *groupTypeId >>>>>>>>>> *partyTypeId >>>>>>>>>> >>>>>>>>>> Anyways, I have come up with a workaround. I'll just use >>>>>>>>>> the existing PartyClassificationGroup the way the book uses >>>>>>>>>> PartyType. >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --- On Mon, 1/3/11, David E Jones<[hidden email]> >>>>>>>>>> wrote: >>>>>>>>>>> Every single *Type entity in OFBiz is a deviation from >>>>>>>>>> the >>>>>>>>>>> book (ie the *Type entities are an OFBiz pattern to >>>>>>>>>> avoid >>>>>>>>>>> redundant entities and keep track of entity extensions >>>>>>>>>> like >>>>>>>>>>> the Party -> PartyGroup,Person thingy), as are >>>>>>>>>> dozens of >>>>>>>>>>> other entities and hundreds of fields. That book is >>>>>>>>>> valuable >>>>>>>>>>> for general concepts and patterns, and is not an >>>>>>>>>> actual data >>>>>>>>>>> model to be used as-is. >>>>>>>>>>> >>>>>>>>>>> -David >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Jan 3, 2011, at 5:57 PM, Adrian Crum wrote: >>>>>>>>>>> >>>>>>>>>>>> I don't think I'm generalizing anything. The book >>>>>>>>>> is >>>>>>>>>>> pretty specific and clear: Party Classification is an >>>>>>>>>>> intersection entity that sets up a many-to-many >>>>>>>>>> relationship >>>>>>>>>>> between the Party entity and the Party Type entity. >>>>>>>>>>>> I understand OFBiz deviates from the book here >>>>>>>>>> and >>>>>>>>>>> there, and if this is one of those cases, then I'll >>>>>>>>>> ask >>>>>>>>>>> again: Why was it done that way? >>>>>>>>>>>> I'm trying to make sense of the OFBiz Party >>>>>>>>>>> Classification model, and so far it doesn't make >>>>>>>>>> sense. The >>>>>>>>>>> way it is set up, I can't give a party a >>>>>>>>>> classification >>>>>>>>>>> without first creating a classification group, assign >>>>>>>>>> a >>>>>>>>>>> classification type to it, and then assign the party >>>>>>>>>> to the >>>>>>>>>>> classification group using party classification. >>>>>>>>>>>> In the book it's much simpler - I just assign a >>>>>>>>>> party >>>>>>>>>>> type to a party using a party classification. >>>>>>>>>> Classification >>>>>>>>>>> groups are Party Classification sub-types and they >>>>>>>>>> aren't >>>>>>>>>>> necessary unless I want to group things a certain >>>>>>>>>> way. >>>>>>>>>>>> -Adrian >>>>>>>>>>>> >>>>>>>>>>>> --- On Mon, 1/3/11, David E Jones<[hidden email]> >>>>>>>>>>> wrote: >>>>>>>>>>>>> I think you may be taking the specific term >>>>>>>>>> "type" >>>>>>>>>>> and >>>>>>>>>>>>> generalizing it. Consider that *Type entities >>>>>>>>>> in >>>>>>>>>>> OFBiz mean >>>>>>>>>>>>> something very specific, and it is different >>>>>>>>>> from >>>>>>>>>>> the more >>>>>>>>>>>>> general use of the term in the book. >>>>>>>>>>>>> >>>>>>>>>>>>> -David >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Jan 3, 2011, at 3:24 PM, Adrian Crum >>>>>>>>>> wrote: >>>>>>>>>>>>>> That's not what the book shows. There is >>>>>>>>>> a >>>>>>>>>>> simple >>>>>>>>>>>>> relationship: >>>>>>>>>>>>>> Party -> PartyClassification -> >>>>>>>>>>> PartyType >>>>>>>>>>>>>> If you want to group classifications, >>>>>>>>>> give >>>>>>>>>>> them >>>>>>>>>>>>> parent/child relationships, etc then you do >>>>>>>>>> it >>>>>>>>>>> with >>>>>>>>>>>>> PartyType, not PartyClassification. Look at >>>>>>>>>> table >>>>>>>>>>> 2.3 on >>>>>>>>>>>>> page 32. >>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- On Mon, 1/3/11, BJ Freeman<[hidden email]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> how about a pattern of parent child >>>>>>>>>>>>>>> for PartyClassification of supertype >>>>>>>>>>>>>>> and the sub types then use a >>>>>>>>>>>>> table for the >>>>>>>>>>>>>>> attributess of the subtype. >>>>>>>>>>>>>>> this would allow walking the parnent >>>>>>>>>>> child >>>>>>>>>>>>> relationships. >>>>>>>>>>>>>>> PartyClassification >>>>>>>>>>>>>>> >>>>>>>>>> --->organizationClassification---->minorityClassification >>>>>>>>>>> ---->industryclassification >>>>>>>>>>>>>>> ========================= >>>>>>>>>>>>>>> BJ Freeman >>>>>>>>>>>>>>> Strategic Power Office with Supplier >>>>>>>>>>> Automation >>>>>>>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/> >>>>>>>>>>>>>>> Systems Integrator-- Glad to Assist >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Chat Y! messenger: bjfr33man >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Adrian Crum sent the following on >>>>>>>>>> 1/3/2011 >>>>>>>>>>> 2:46 >>>>>>>>>>>>> PM: >>>>>>>>>>>>>>>> PartyClassificationGroup should >>>>>>>>>> have >>>>>>>>>>> a >>>>>>>>>>>>> one-to-one >>>>>>>>>>>>>>> relationship with an entity called >>>>>>>>>>>>>>> PartyClassificationGroupType. >>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --- On Mon, 1/3/11, BJ >>>>>>>>>> Freeman<[hidden email]> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> so the Party Classification >>>>>>>>>> Group >>>>>>>>>>>>>>>>> table would have a one to >>>>>>>>>> one >>>>>>>>>>> with >>>>>>>>>>>>>>>>> Classification Types >>>>>>>>>>>>>>>>> or vica versa. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ========================= >>>>>>>>>>>>>>>>> BJ Freeman >>>>>>>>>>>>>>>>> Strategic Power Office with >>>>>>>>>>> Supplier >>>>>>>>>>>>> Automation >>>>>>>>>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/> >>>>>>>>>>>>>>>>> Systems Integrator-- Glad to >>>>>>>>>>> Assist >>>>>>>>>>>>>>>>> Chat Y! messenger: >>>>>>>>>>> bjfr33man >>>>>>>>>>>>>>>>> Adrian Crum sent the >>>>>>>>>> following on >>>>>>>>>>> 1/3/2011 >>>>>>>>>>>>> 1:41 >>>>>>>>>>>>>>> PM: >>>>>>>>>>>>>>>>>> Looking into this more, >>>>>>>>>> The >>>>>>>>>>> Data >>>>>>>>>>>>> Model >>>>>>>>>>>>>>> Resource Book >>>>>>>>>>>>>>>>> mentions classification >>>>>>>>>> groups - >>>>>>>>>>> but I >>>>>>>>>>>>> believe the >>>>>>>>>>>>>>> author >>>>>>>>>>>>>>>>> meant that Party Types could >>>>>>>>>> be >>>>>>>>>>> grouped >>>>>>>>>>>>> together >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>> classification groups. In >>>>>>>>>> other >>>>>>>>>>> words, >>>>>>>>>>>>> the >>>>>>>>>>>>>>> classification >>>>>>>>>>>>>>>>> groups are defined by the >>>>>>>>>> data >>>>>>>>>>> contained >>>>>>>>>>>>> in the >>>>>>>>>>>>>>> Party Type >>>>>>>>>>>>>>>>> table - not in a separate >>>>>>>>>> "Party >>>>>>>>>>>>> Classification >>>>>>>>>>>>>>> Group" >>>>>>>>>>>>>>>>> table. There is nothing >>>>>>>>>> stopping >>>>>>>>>>> us from >>>>>>>>>>>>> having a >>>>>>>>>>>>>>> Party >>>>>>>>>>>>>>>>> Classification Group table, >>>>>>>>>> but it >>>>>>>>>>> should >>>>>>>>>>>>> group >>>>>>>>>>>>>>> Party Types, >>>>>>>>>>>>>>>>> not "Classification Types." >>>>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> --- On Mon, 1/3/11, >>>>>>>>>> Adrian >>>>>>>>>>> Crum<[hidden email]> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> Looking at The Data >>>>>>>>>> Model >>>>>>>>>>>>> Resource >>>>>>>>>>>>>>>>>>> Book and the way >>>>>>>>>> OFBiz >>>>>>>>>>> models >>>>>>>>>>>>> Party >>>>>>>>>>>>>>>>> Classification, it >>>>>>>>>>>>>>>>>>> appears to me OFBiz >>>>>>>>>> models >>>>>>>>>>> it >>>>>>>>>>>>> wrong. >>>>>>>>>>>>>>>>>>> According to the >>>>>>>>>> book, the >>>>>>>>>>> Party >>>>>>>>>>>>>>> Classification >>>>>>>>>>>>>>>>> entity ties >>>>>>>>>>>>>>>>>>> a Party to a Party >>>>>>>>>> Type >>>>>>>>>>> with a >>>>>>>>>>>>> from and >>>>>>>>>>>>>>> thru >>>>>>>>>>>>>>>>> date. >>>>>>>>>>>>>>>>>>> In OFBiz, the Party >>>>>>>>>>> Classification >>>>>>>>>>>>> entity >>>>>>>>>>>>>>> ties a >>>>>>>>>>>>>>>>> Party to a >>>>>>>>>>>>>>>>>>> Party Classification >>>>>>>>>> Group >>>>>>>>>>> with a >>>>>>>>>>>>> from and >>>>>>>>>>>>>>> thru >>>>>>>>>>>>>>>>> date. The >>>>>>>>>>>>>>>>>>> Party Type is tied >>>>>>>>>>> directly to >>>>>>>>>>>>> Party with >>>>>>>>>>>>>>> no from >>>>>>>>>>>>>>>>> and thru >>>>>>>>>>>>>>>>>>> date. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Was that intentional? >>>>>>>>>> Why >>>>>>>>>>> was it >>>>>>>>>>>>> done that >>>>>>>>>>>>>>> way? >>>>>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >> |
Re: Party Classification Data Modeling
|
|
In reply to this post by David E. Jones-2
can you point me to some document that gives why
PartyClassificataionGroup exist and is used the way it is. To me it is overkill and skirts the purpose of PartyClassificataion As a matter of face any docs on PartyClassificataion and PartyClassificataionType. I will put in a docbook file for Tech_ David E Jones sent the following on 9/4/2011 12:38 PM: > > The second one should be a PartyClassificataionGroup and not a type. > > -David > > > On Sep 4, 2011, at 12:04 PM, BJ Freeman wrote: > >> <PartyClassificationType description="Minority" hasTable="N" >> parentTypeId="" partyClassificationTypeId="MINORITY_CLASSIFICAT"/> >> <PartyClassificationType description="Hispanic" hasTable="N" >> parentTypeId="MINORITY_CLASSIFICA" >> partyClassificationTypeId="HISPANIC_CLASSIFICAT"/> >> >> >> Adrian Crum sent the following on 1/10/2011 4:27 PM: >>> I spent some time in Party Manager trying to make sense of the Party Classification feature, and I can't seem to make it do anything meaningful. Maybe I'm not understanding something, so I'll provide an example and see if anyone knows how to implement it in the current code. >>> >>> In table 2.3 of the Data Model Resource Book, there is a party named Marc Martinez who has been classified as Hispanic. I will use him for my example. >>> >>> In Party Manager I create a person named Marc Martinez and I want to classify him as Hispanic. I would also like to include the Hispanic classification in two classification groups: US Minorities and Non-White. I go to the Classifications tab - where I can create classification groups from a list of pre-defined group types. I choose the Minority type, type "US Minorities" in the Description field, and save the group. I want to add the Hispanic classification to this group, but I don't see any way to add classifications. I go to Marc's profile page and try to assign him a classification, but I can only assign him to a classification group. If I assign him to the "US Minorities" group that still doesn't classify him as Hispanic. >>> >>> As far as I can tell, Party Classification doesn't work. >>> >>> Any ideas? >>> >>> -Adrian >>> >>> >>> --- On Mon, 1/3/11, Adrian Crum <[hidden email]> wrote: >>>> Understood. If we wanted to create >>>> entities to avoid the sub-types mentioned in the book >>>> (Organization Classification, Person Classisfication, etc) >>>> then I think we could have done that in a simpler way and >>>> still keep the book's model: >>>> >>>> PartyClassificationGroupType >>>> ---------------------------- >>>> *groupTypeId >>>> description >>>> parentGroupTypeId >>>> >>>> PartyClassificationGroup >>>> ------------------------ >>>> *groupTypeId >>>> *partyTypeId >>>> >>>> Anyways, I have come up with a workaround. I'll just use >>>> the existing PartyClassificationGroup the way the book uses >>>> PartyType. >>>> >>>> -Adrian >>>> >>>> >>>> --- On Mon, 1/3/11, David E Jones <[hidden email]> >>>> wrote: >>>>> Every single *Type entity in OFBiz is a deviation from >>>> the >>>>> book (ie the *Type entities are an OFBiz pattern to >>>> avoid >>>>> redundant entities and keep track of entity extensions >>>> like >>>>> the Party -> PartyGroup,Person thingy), as are >>>> dozens of >>>>> other entities and hundreds of fields. That book is >>>> valuable >>>>> for general concepts and patterns, and is not an >>>> actual data >>>>> model to be used as-is. >>>>> >>>>> -David >>>>> >>>>> >>>>> On Jan 3, 2011, at 5:57 PM, Adrian Crum wrote: >>>>> >>>>>> I don't think I'm generalizing anything. The book >>>> is >>>>> pretty specific and clear: Party Classification is an >>>>> intersection entity that sets up a many-to-many >>>> relationship >>>>> between the Party entity and the Party Type entity. >>>>>> >>>>>> I understand OFBiz deviates from the book here >>>> and >>>>> there, and if this is one of those cases, then I'll >>>> ask >>>>> again: Why was it done that way? >>>>>> >>>>>> I'm trying to make sense of the OFBiz Party >>>>> Classification model, and so far it doesn't make >>>> sense. The >>>>> way it is set up, I can't give a party a >>>> classification >>>>> without first creating a classification group, assign >>>> a >>>>> classification type to it, and then assign the party >>>> to the >>>>> classification group using party classification. >>>>>> >>>>>> In the book it's much simpler - I just assign a >>>> party >>>>> type to a party using a party classification. >>>> Classification >>>>> groups are Party Classification sub-types and they >>>> aren't >>>>> necessary unless I want to group things a certain >>>> way. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> --- On Mon, 1/3/11, David E Jones <[hidden email]> >>>>> wrote: >>>>>>> I think you may be taking the specific term >>>> "type" >>>>> and >>>>>>> generalizing it. Consider that *Type entities >>>> in >>>>> OFBiz mean >>>>>>> something very specific, and it is different >>>> from >>>>> the more >>>>>>> general use of the term in the book. >>>>>>> >>>>>>> -David >>>>>>> >>>>>>> >>>>>>> On Jan 3, 2011, at 3:24 PM, Adrian Crum >>>> wrote: >>>>>>> >>>>>>>> That's not what the book shows. There is >>>> a >>>>> simple >>>>>>> relationship: >>>>>>>> >>>>>>>> Party -> PartyClassification -> >>>>> PartyType >>>>>>>> >>>>>>>> If you want to group classifications, >>>> give >>>>> them >>>>>>> parent/child relationships, etc then you do >>>> it >>>>> with >>>>>>> PartyType, not PartyClassification. Look at >>>> table >>>>> 2.3 on >>>>>>> page 32. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> --- On Mon, 1/3/11, BJ Freeman <[hidden email]> >>>>>>> wrote: >>>>>>>>> how about a pattern of parent child >>>>>>>>> for PartyClassification of supertype >>>> >>>>>>>>> and the sub types then use a >>>>>>> table for the >>>>>>>>> attributess of the subtype. >>>>>>>>> this would allow walking the parnent >>>>> child >>>>>>> relationships. >>>>>>>>> PartyClassification >>>>>>>>> >>>>>>> >>>>> >>>> --->organizationClassification---->minorityClassification >>>>>>>>> >>>>> >>>>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> ---->industryclassification >>>>>>>>> >>>>>>>>> ========================= >>>>>>>>> BJ Freeman >>>>>>>>> Strategic Power Office with Supplier >>>>> Automation >>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>>> Specialtymarket.com <http://www.specialtymarket.com/> >>>>>>>>> Systems Integrator-- Glad to Assist >>>>>>>>> >>>>>>>>> Chat Y! messenger: bjfr33man >>>>>>>>> >>>>>>>>> >>>>>>>>> Adrian Crum sent the following on >>>> 1/3/2011 >>>>> 2:46 >>>>>>> PM: >>>>>>>>>> PartyClassificationGroup should >>>> have >>>>> a >>>>>>> one-to-one >>>>>>>>> relationship with an entity called >>>>>>>>> PartyClassificationGroupType. >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> --- On Mon, 1/3/11, BJ >>>> Freeman<[hidden email]> >>>>>>> >>>>>>>>> wrote: >>>>>>>>>>> so the Party Classification >>>> Group >>>>>>>>>>> table would have a one to >>>> one >>>>> with >>>>>>>>>>> Classification Types >>>>>>>>>>> or vica versa. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ========================= >>>>>>>>>>> BJ Freeman >>>>>>>>>>> Strategic Power Office with >>>>> Supplier >>>>>>> Automation >>>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/> >>>>>>>>>>> Systems Integrator-- Glad to >>>>> Assist >>>>>>>>>>> >>>>>>>>>>> Chat Y! messenger: >>>>> bjfr33man >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Adrian Crum sent the >>>> following on >>>>> 1/3/2011 >>>>>>> 1:41 >>>>>>>>> PM: >>>>>>>>>>>> Looking into this more, >>>> The >>>>> Data >>>>>>> Model >>>>>>>>> Resource Book >>>>>>>>>>> mentions classification >>>> groups - >>>>> but I >>>>>>> believe the >>>>>>>>> author >>>>>>>>>>> meant that Party Types could >>>> be >>>>> grouped >>>>>>> together >>>>>>>>> in >>>>>>>>>>> classification groups. In >>>> other >>>>> words, >>>>>>> the >>>>>>>>> classification >>>>>>>>>>> groups are defined by the >>>> data >>>>> contained >>>>>>> in the >>>>>>>>> Party Type >>>>>>>>>>> table - not in a separate >>>> "Party >>>>>>> Classification >>>>>>>>> Group" >>>>>>>>>>> table. There is nothing >>>> stopping >>>>> us from >>>>>>> having a >>>>>>>>> Party >>>>>>>>>>> Classification Group table, >>>> but it >>>>> should >>>>>>> group >>>>>>>>> Party Types, >>>>>>>>>>> not "Classification Types." >>>>>>>>>>>> >>>>>>>>>>>> -Adrian >>>>>>>>>>>> >>>>>>>>>>>> --- On Mon, 1/3/11, >>>> Adrian >>>>> Crum<[hidden email]> >>>>>>>>>>> wrote: >>>>>>>>>>>>> Looking at The Data >>>> Model >>>>>>> Resource >>>>>>>>>>>>> Book and the way >>>> OFBiz >>>>> models >>>>>>> Party >>>>>>>>>>> Classification, it >>>>>>>>>>>>> appears to me OFBiz >>>> models >>>>> it >>>>>>> wrong. >>>>>>>>>>>>> >>>>>>>>>>>>> According to the >>>> book, the >>>>> Party >>>>>>>>> Classification >>>>>>>>>>> entity ties >>>>>>>>>>>>> a Party to a Party >>>> Type >>>>> with a >>>>>>> from and >>>>>>>>> thru >>>>>>>>>>> date. >>>>>>>>>>>>> >>>>>>>>>>>>> In OFBiz, the Party >>>>> Classification >>>>>>> entity >>>>>>>>> ties a >>>>>>>>>>> Party to a >>>>>>>>>>>>> Party Classification >>>> Group >>>>> with a >>>>>>> from and >>>>>>>>> thru >>>>>>>>>>> date. The >>>>>>>>>>>>> Party Type is tied >>>>> directly to >>>>>>> Party with >>>>>>>>> no from >>>>>>>>>>> and thru >>>>>>>>>>>>> date. >>>>>>>>>>>>> >>>>>>>>>>>>> Was that intentional? >>>> Why >>>>> was it >>>>>>> done that >>>>>>>>> way? >>>>>>>>>>>>> >>>>>>>>>>>>> -Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |