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? 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
