I think Agreements are more like the terms of a relationship and can change over the course of that relationship.
I would tend to think of an account number as being more like relationship meta data that exists so long as the relationship exists and for that reason I would either add a generic field to PartyRelationship or otherwise add a new entity SupplierRelationship and one-to-one it with PartyRelationship. Regards Scott HotWax Media http://www.hotwaxmedia.com On 30/04/2010, at 3:37 PM, Bob Morley wrote: > > Ya perhaps ... but it just doesn't feel right. The more thought I gave it > the more I started to like the agreement approach. On my drive home I asked > myself if I could come up with an example of something that represents a > relationship between two parties AND would have some sort of identify > fields. In the end I could not come up with anything ... I think all of > our examples are reasonably modeled as agreements and one could argue that > the Employment entity in Ofbiz really should be an agreement as well. DMR > book Vol1 suggests it as a sub-class of Agreement in fig 4.13. > > If PartyRelation is really just hooking up parties for (mostly) navigational > purposes; then anything more than that seems to usually represent some sort > of Agreement between the two parties. In this way it seems Agreement is > just a specialization of PartyRelationship. > > I will do more research and come up with a more concrete proposal for review > (if any changes are required at all). > > > Adrian Crum wrote: >> >> We already have PartyIdentification and PartyIdentificationType. Maybe >> those could be tied to PartyRelationship somehow. >> > > -- > View this message in context: > http://ofbiz.135035.n4.nabble.com/Storing-supplier-provided-account-number-tp2076162p2076460.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com.
smime.p7s
Description: S/MIME cryptographic signature
