PartyClassificationGroup should have a one-to-one relationship with an entity called PartyClassificationGroupType.
-Adrian --- On Mon, 1/3/11, BJ Freeman <bjf...@free-man.net> 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<adrian.c...@yahoo.com> > 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 > >> > >> > >> > >> > >> > >> > >> > > > > > > > > > >
