I added more to the contact mech it is robust enough you just add types and reasons.
========================= BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93> Specialtymarket.com <http://www.specialtymarket.com/> Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Linkedin <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro> Bob Morley sent the following on 4/29/2010 1:42 PM: > 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).
