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 ... :)
