Re: Extending OrderHeader, and the finalizeOrder process

[Michael Brohl]

Hi Forrest,

I'd suggest to use OrderAttribute to store custom data for the order.

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de

Am 18.06.15 um 16:30 schrieb Forrest Rae:

Hans, thanks for the reply.





-Forrest

On 6/17/15 11:01 PM, Hans Bakker wrote:

I do agree with you that invoice is a better place for this data, I can change the entity I'm extending. Still, I would like to capture this data at order entry, and I'm wondering about best way to do that given the design of the order entry process. It's my understanding that invoices aren't created until an order is approved. Hmmm, Perhaps I could capture this data as part of a custom order approval process?

Isn't the invoice you want follow up for payment?

Regards,
Hans

On 18/06/15 12:38, Forrest Rae wrote:

Hi Everyone,

I'm wondering about best practices here, and want to avoid going down a
route that might lead to pain and suffering.

I need to track three custom pieces of data per sales order. This data

purchase order number, then there are two others that are tracking
numbers specific to the customer's payment system.  This data is
required to be "not-null".

I've extended OrderHeader.  Problem is, the order entry screens will
fail at the end, because of the not-null constraint.  (I added the
constraints manually, due to a bug OFBIZ-6493)

I started digging into the finalizeOrder request chain.  I'd like to

of finalizeOrder chain.  It appears I'd need to do some pretty heavy
lifting to augment this process, including modifying the ShoppingCart
class, etc.

Obviously someone has had to do this before, so just wondering if there
are any best practices to avoid modifying the Java classes.

-Forrest

is used for contacting the customer for payment. One piece of data is a capture these three pieces of data on the setBilling screen that is part

smime.p7s
Description: S/MIME Cryptographic Signature