Ya ... the one thing I wondered about was the Employment entity. I
believe PartyRelationshipType has it set as hasTable = "Y" but then it
redundantly stores the role, party to/from as well as the from/thru
dates. I would think if Employment is a sub-class of
PartyRelationship, it should only have its unique fields (I think two
termination related fields).
I would think a "fundamental" type like supplier may have its own
SupplierRel table, but things that can be very vertical specific
(dealers / houseowners) might be something better stored in an
Agreement. Would seem to me to jive with other "supplier" entities
that already exist in the system.
Another thought that occurred to me is that we could have a
PartyRelationshipIdent entity (like Good & Party) where we could store
all sorts of identification numbers on the relationship. This would
give a nice place for the employee's number, and the other
identification numbers we are talking about. Waddya think about that?
On Apr 29, 2010, at 5:28 PM, Adrian Crum wrote:
My thoughts have changed a bit since that previous thread on the
subject.
We have similar needs here with parties in other relationships. Our
dealers have dealer numbers and license numbers, our suppliers give
us numbers (the same as the previous thread), and the homeowners
have a customer number and other bits of information we have to
maintain for them.
The solution I came up with here was to create a properties entity
for each party type. Each properties entity contains fields for the
various bits of information we need to track for each party type.
The reason I mentioned that is to point out that there can be more
than one piece of information you need to attach to a party. If
those things are added to the party relationship, then that entity
might start to look like a kludge. The same thing could happen if
those fields are added to the agreement entity.
So now I'm undecided. If I had to choose between Party Relationship
or Agreement, I would lean toward Agreement.
-Adrian
On 4/29/2010 1:42 PM, Bob Morley wrote:
My use case here is very similar to this thread --
http://ofbiz.135035.n4.nabble.com/Customer-number-from-suppliers-td142646.html#a142646
I think this thread would suggest the choices are ...
1) New field on PartyRelationship; something like "accountNumber"
which
would be similar to "positionTitle" in that it really is only
applicable to
some of the PartyRelationshipType sub-classes.
2) Formalize the sub-class by setting hasTable = "Y" on the type and
creating a new "SupplierRel" entity that contains this
"accountNumber".
3) Leverage the agreement model for this relationship.
What I was personally going to do was #2 from this list (before
reading the
thread) but after seeing positionTitle I am kind of leaning towards
doing
#1. Since I have to do this for our solution I want to do it in an
acceptable manner for inclusion into Ofbiz (providing we at least
agree that
this would be a good thing).
