It's really not a large change. Just a correction. The first link is how the data model currently is. This second is my proposed change. While there could be some tidying up with the fks to the Party entities, that's a bit beyond the scope and certainly beyond a pressing need.
http://aycu23.webshots.com/image/3062/2002215157491048351_rs.jpg http://aycu13.webshots.com/image/2172/2002213016819728875_rs.jpg Admittedly this is without looking at the code, based on function following form they shouldn't be difficult. 1)Remove Agreement.productId, relationships to Product entities should be through agreementProductAppl. 2)Remove AgreementProductAppl.price. agreementProductAppl is best suited for agreement items not based on price 3)Remove AgreementItem.currencyUomId. When referring to price lists this is defined in the price rule. When it's referring to a lump sum, it's defined in the agreement text. This can probably be improved through another manner, but becuase you're not supporting a number value, currencyUomId wouldn't be helping in a conversion. 4) merge AgreementPartyApplic and AgreementPartyRole. AgreementPartyApplic.partyId doesn't mean much without a context of role. AgreementPartyRole can be equally beneficial as AgreementItemPartyRole and leaving AgreementItemSeqId null. 5) create AgreementPriceRuleApplic or AgreementPriceRule (to satisfy field length constraints). link this to either AgreementItem or Addendum (I prefer addendum as this is where price lists are generally spelled out). fromDate and thruDate i think would be redundant on this with the ProductPriceRule.fromDate and thruDate. 6) Investigate further the function of AgreementTerm.invoiceItemTypeId As far as actual code, I think it's pretty straight forward from other implementations, but would be happy to write some up next week when I have a bit more free time. --- David Welton <[EMAIL PROTECTED]> wrote: > > sincerely speaking, I'd be a bit worried about the > quality of the final > > results since it seems to me that you don't have a > clear understanding > > of how the current *OFBiz* agreement stuff is > designed and used. > > Please, understand that this is not a lack of > trust on your skills, but > > such a big task (that will include existing data > model, services and > > user interface refactoring) would be a challenging > task for everyone > > (even for core contributors like, for example, Si, > David and me). > > > > I'd like to hear the opinions from others about > this subject: do we > > really need to refactor the agreement data model > or can we complete and > > refine the existing processes? what are the most > urgent limitations in > > the current agreement data model? > > I'd be interested to hear more concrete details > about how the proposed > change would work, as well as see working code, to > get a better idea. > That's usually more useful than 'meta' discussions, > as long as > everyone understands that the potential changes > might not be adopted. > > -- > David N. Welton > - http://www.dedasys.com/davidw/ > > Linux, Open Source Consulting > - http://www.dedasys.com/ >
