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