Scott, Adam, BJ,
thanks for your feedback. Based on your comments we will probably need also an AgreementOrderApplPurpose (or Type) entity so that we could have an agreement that governs the terms and prices applied to a customer, the commissions due to a sales rep etc... (unless we just rely on the type id of the Agreement). I will not have time to work on this now (I have managed to fix the error for a customer in a simpler way) but this is definitely something to keep an eye on. Thanks and kind regards, Jacopo On Jul 7, 2010, at 10:55 PM, Adam Heath wrote: > 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> >
