Extending OrderHeader, and the finalizeOrder process

[Forrest Rae]

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
is used for contacting the customer for payment.  One piece of data is a
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
capture these three pieces of data on the setBilling screen that is part
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

[Hans Bakker]

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
> is used for contacting the customer for payment.  One piece of data is a
> 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
> capture these three pieces of data on the setBilling screen that is part
> 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
>

[Forrest Rae]

Hans, thanks for the reply.

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?

-Forrest

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

> 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
>> is used for contacting the customer for payment.  One piece of data is a
>> 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
>> capture these three pieces of data on the setBilling screen that is part
>> 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
>>
>

[Michael Brohl-3]

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.
>
> 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?
>
> -Forrest
>
> On 6/17/15 11:01 PM, Hans Bakker wrote:
>> 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
>>> is used for contacting the customer for payment.  One piece of data
>>> is a
>>> 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
>>> capture these three pieces of data on the setBilling screen that is
>>> part
>>> 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
>>>
>>
>