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