On 4/05/2010, at 7:34 AM, Robert Morley wrote: > > On May 3, 2010, at 3:09 PM, Robert Morley wrote: > >>> >>> That wasn't what I was suggesting, I was describing SupplierRelationship as >>> being an extension to PartyRelationship in the same way that Person or >>> PartyGroup extends Party. >>> >> >> >> Yes I think this is the solution that Adrian has original suggested a couple >> of years back and is the same solution I had thought about implementing when >> I started this thread. I think the difficulty here comes in the fact that >> the data model book has sub-classes for both PartyRelationship and Agreement >> for this purpose (Supplier Relationship and Purchase Agreement respectively >> from page 43 and 149 of The Data Model Resource Book volume 1). There are >> also sub-classes for both for "Employeement" named "Employment" and >> "Employment Agreement". >> >> The book suggests that Agreement is involved in a single PartyRelationship >> (but the relationship may be associated with a collection of Agreements). >> Ofbiz does not model this association, but I think it probably should. A >> scan of the forum for anything on this topic did not produce any results. >> Again the book suggests the PartyRelationship is an informal relationship >> where the agreement is created "when a formal agreement is established >> between these parties and a contract is drawn stipulating certain terms of >> this agreement ...". >> >> For a supplier I think it is desirable to have an informal PartyRelationship >> between the Internal Organization and the Party that will be supplying >> products. We may also (optionally) have a formal agreement that dictates >> pricing and other terms (like net 30, etc). However, the life of this >> section agreement may be much shorter than the life of the relationship to >> the supplier. And it is very likely that the supplier supplied >> "customerNumber" or "accountNumber" would live across many agreements. >> >> As a result, I would like to get started on this new entity "SupplierRel" >> and will provide a patch soon. > > Argh! Ok now I understand why "Employment" which is a logic sub-class of > PartyRelationship was not coded as such. The issue is that there is not a > specific single primary key for PartyRelationship -- its primary keys are > partyto, partyfrom, roleto, roleform, and fromDate. As a result, without > duplicating all of those keys you can not recall create the Employment entity > like we do with other "inherited" entities like Party / Person & PartyGroup. > > So the options are to add "partyRelationshipId" to the entity and the > changes that would involve (including about a 100 seeded PartyRelations), > duplicate the fields in SupplierRel (like Employment does now), or fall back > to putting the field directly on PartyRelationship itself. > > Community direction requested ... :)
I think you missed the second half of my earlier email: > I'm not sure how I would handle something like a security card but IMO the > Employment entity should be an extension to PartyRelationship, I mean it > already shares the same primary key fields. Employment already has the same PK fields as PartyRelationship.
smime.p7s
Description: S/MIME cryptographic signature
