BJ, the existing data model (as it is described in the Data Model Resource Book as you have mentioned previously) already takes care of this and I am not planning to change this. My proposal was related to the agreements picked for an order.
Jacopo On Jul 8, 2010, at 12:59 AM, BJ Freeman wrote: > how will you get all the companies role of agreements for a particular party > that has a partyrelationship of customer? > how will you get all the Sales agreements for a partyrelationship of customer > with the company under the role of agreements? > > > BJ Freeman sent the following on 7/7/2010 10:19 AM: > > > ========================= > 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 > >> I have the implementation that uses the Sales agreement and a >> productaggreemt for retail, wholesale, custom. >> so as you think though the changes you might want to consider hooks to >> allow this in future. >> >> also the agreements are based on partyID role of customeras a >> relationship with the company so I don't see how just AgreementOrderAppl >> tied to the order header will accomplish this. >> >> ========================= >> 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 >> >> >> Jacopo Cappellato sent the following on 7/7/2010 6:07 AM: >>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> >>
