Couple of options here: - Set the po number directly in the cart (this is done to set the po in other methods, but there isn't much in CheckOutEvents using the cart directly) - have the "payment" response chain go to setPoNumber and then carry on to calcShippingBeforePayment, but I don't think this is the best way to handle such a simple field and I have to admit it looks like I mistakenly added setPoNumber to ShoppingCartEvents while working on the commit
A few screens and methods relating to anonymous checkouts use the corresponding_po_id but they aren't affecting by changing the name in this screen. Is there a convention for field naming in forms? I only seem to come across names like this in ftl files. Regards Scott On 29/03/07, Chris Howe <[EMAIL PROTECTED]> wrote:
That will work if you change the variable name corresponding_po_id to correspondingPoId in the templates. We then need to double check that corresponding_po_id isn't used/expected elsewhere. The placement of setPoNumber in the chain needs to be looked at as well. --- Jacopo Cappellato <[EMAIL PROTECTED]> wrote: > Before doing this, I think that it would worth trying to chain, in > the > checkout events in the ecommerce's controller the call to setPoNumber > > <request-map uri="setPoNumber"> > <security https="true" auth="true"/> > <event type="java" > path="org.ofbiz.order.shoppingcart.ShoppingCartEvents" > invoke="setPoNumber"/> > <response name="success" type="request" value="orderentry"/> > <response name="error" type="request" value="orderentry"/> > </request-map> > > it should work > > Jacopo > > Chris Howe wrote: > > Could someone please revert the changes made in rev 519570. This > > breaks the storing of a customer provided PO number in ecommerce. > > Thanks. > > > > ,Chris > >
