Scott Gray wrote: > Hi Jacopo, > > I have to admit to not being a big fan of the primary* pattern, for example > in the Shipment entity I really feel it has done nothing except cause us to > take shortcuts when writing shipping logic. In terms of an Agreement or even > a Shipment, what does it actually mean to be the primary? > > I understand its usage in Product.primaryProductCategoryId, where it can be > used in cases where you need to be able to inspect a hierarchy rather than a > graph e.g. for reporting purposes, but it makes less sense to me for those > other entities. > > Could we not for now just limit the UI and logic to only handle a single > agreement, but allow for the many-to-many in the data model?
My vote is to not add a primaryFoo field, but use a joined entity, with an appropriate Purpose attached. Once you have code that can look up the joined entity with a purpose, adding more logic to handle other purposes is easy. But having a primaryFoo in the base entity means you have duplicate code for dealing with the same info. > > Regards > Scott > > On 8/07/2010, at 1:07 AM, Jacopo Cappellato wrote: > >> Thanks Scott, >> >> the link was indeed useful. >> I like the plan of creating the AgreementOrderAppl entity, because it will >> be definitely very flexible. >> However the existing order code (ui and business logic) is based on the >> assumption that one agreement is associated to a cart/order, and I would >> like to fix this process asap before enhancing the data model with the >> AgreementOrderAppl entity. >> >> So, what if I add the new field to the OrderHeader but instead of naming it >> "agreementId" we use "primaryAgreementId"? >> >> Kind regards, >> >> Jacopo >> >> >> On Jul 3, 2010, at 9:36 AM, Scott Gray wrote: >> >>> Hi Jacopo, >>> >>> Not sure if this is of any use to you: >>> http://ofbiz.135035.n4.nabble.com/orders-and-contracts-td2248364.html#a2248394 >>> >>> Regards >>> Scott >>> >>> HotWax Media >>> http://www.hotwaxmedia.com >>> >>> On 3/07/2010, at 6:24 PM, Jacopo Cappellato wrote: >>> >>>> yes, I will do. >>>> >>>> Jacopo >>>> >>>> On Jul 2, 2010, at 8:01 PM, Jacques Le Roux wrote: >>>> >>>>> Pretty logical, I see. Maybe Jacopo will consider it? >>>>> >>>>> Thanks >>>>> >>>>> Jacques >>>>> >>>>> From: "BJ Freeman" <bjf...@free-man.net> >>>>>> never saw it as enhanced only following the Data model book. >>>>>> since most told me that features were not complete in ofbiz, I completed >>>>>> them. >>>>>> Since most of my discussion were ignored I just made my own, using the >>>>>> OOTB as a basis. >>>>>> I use what I can of the svn and add on top the way I see it. >>>>>> ========================= >>>>>> BJ Freeman >>>>>> http://bjfreeman.elance.com >>>>>> Strategic Power Office with Supplier Automation >>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>> 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> >>>>>> Jacques Le Roux sent the following on 7/2/2010 10:26 AM: >>>>>>> Interesting, so you enhanced the OOTB model and actions, right? >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> From: "BJ Freeman" <bjf...@free-man.net> >>>>>>>> I used the model on page 146 >>>>>>>> and the example agreementID 10002 >>>>>>>> since the Agreement has the product agreement, the service matches the >>>>>>>> product agreement productID and updates the orderitem orderterms(page >>>>>>>> 128) and table 4.9(page 129) . an SECA checks that the order terms can >>>>>>>> be accepted based on the order, like a promo may be disqualified based >>>>>>>> on the order terms. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ========================= >>>>>>>> BJ Freeman >>>>>>>> http://bjfreeman.elance.com >>>>>>>> Strategic Power Office with Supplier Automation >>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>> 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> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Jacopo Cappellato sent the following on 7/2/2010 3:26 AM: >>>>>>>>> When an order is initiated, it is possible to select an agreement >>>>>>>>> that will govern the orders (OrderTerms are cloned from >>>>>>>>> AgreementTerms, if the agreement has a price list then the agreement >>>>>>>>> prices are used in place of ProductPrice); however the agreementId is >>>>>>>>> only added to the cart but it is lost when the order is saved. >>>>>>>>> This causes issues if the order is edited: the agreement is lost and >>>>>>>>> the system is unable to apply the agreement prices to the edited >>>>>>>>> order. >>>>>>>>> >>>>>>>>> The solution I am proposing is to add the agreementId field to >>>>>>>>> OrderHeader entity. >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> Jacopo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >
