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














Reply via email to