shoppingcart serialization, not shoppinglist

[Adam Heath <do...@brainfood.com>]

Using a shoppinglist to save a cart is very poor form.  You'll not be
able to save shipgroup assignments, postal address per shipgroup,
shipping method, virtual product features, payment settings, promo
codes, tons of stuff.  We need to be able to restore *all* these things.

Saving the cart to an order is a possibility, but that will end up
causing a bunch of ecas(entity and service) to run.  Things like
inventory reservation, posting of payments, etc.

We(Ean and I) have talked, and the way we'd like to see this done, is
to invent a new order type, CART(or something), to go along with
SALES_ORDER and PURCHASE_ORDER.  We are very close to just having to
go and doing this.  Of course, this could cascade to lots of other
code, that explicitly checks the orderTypeId.

In an ideal world, there were be *no* separate serialization step.
The cart would *always* modify the database view of an order.  Always.
 The final step would just then be changing it's type from CART to
SALES_ORDER.  This second phase, however, it more difficult.

Re: shoppingcart serialization, not shoppinglist

[Adam Heath <do...@brainfood.com>]

Adrian Crum wrote:
> Adam Heath wrote:
>> Using a shoppinglist to save a cart is very poor form.  You'll not be
>> able to save shipgroup assignments, postal address per shipgroup,
>> shipping method, virtual product features, payment settings, promo
>> codes, tons of stuff.  We need to be able to restore *all* these things.
> 
> What if the order is finalized after those promos expire or shipping
> rates/methods have changed?

how can the order be finalized?  It hasn't been submitted yet.  We
just want to the cart data into the order entities, as they are fully
expresive with everything nescessary.  Just keep the rest of ofbiz
from processing the order, maybe by using a PENDING status, or maybe
NEWBORN.

>> We(Ean and I) have talked, and the way we'd like to see this done, is
>> to invent a new order type, CART(or something), to go along with
>> SALES_ORDER and PURCHASE_ORDER.
> 
> We use the term "Quote" where I work.
> 
> 

Re: shoppingcart serialization, not shoppinglist

[Adrian Crum <ad...@hlmksw.com>]

Adam Heath wrote:
> Using a shoppinglist to save a cart is very poor form.  You'll not be
> able to save shipgroup assignments, postal address per shipgroup,
> shipping method, virtual product features, payment settings, promo
> codes, tons of stuff.  We need to be able to restore *all* these things.

What if the order is finalized after those promos expire or shipping 
rates/methods have changed?

> We(Ean and I) have talked, and the way we'd like to see this done, is
> to invent a new order type, CART(or something), to go along with
> SALES_ORDER and PURCHASE_ORDER.

We use the term "Quote" where I work.

Re: shoppingcart serialization, not shoppinglist

[Jacques Le Roux <ja...@les7arts.com>]

From: "Adam Heath" <do...@brainfood.com>
> Robert Morley wrote:
>> Introducing a new type "CART" as an OrderType does not feel right to
>> me.  It would seem having an Order of type "SalesOrder" and being able
>> to influence which functionality you wish to execute on that entity via
>> its status (or additional attribute) might be work considering.  We had
>> a very similar problem, we wanted to work with a persisted version of
>> the SalesOrder which was a more long term object from our perspective.
>>
>> What we have done is only apply payments in a single transaction as part
>> of completing the order (obviously not totally desirable) but this
>> avoided payment processing as part of saving / updating the order.  As
>> for inventory reservations, we actually wanted to reserve items as they
>> are added to the order so we left this but then built some logic around
>> releasing and re-reserving when items were updated/removed from the
>> order.  There were a number of gotchas in the set of services you can do
>> with an order -- for example, the service to load an order into a cart
>> for updating is really expecting to "clone" the order ... I believe it
>> nulls out the orderId on the shopping cart for example to cause a new
>> order to be created.
>>
>> Can you consider a product store configuration that would indicate when
>> reservations should occuring based on the state of the order (if this
>> does not already exist).  So when you are cobbling up your order
>> (ORDER_CREATED status) it may not be doing reservations, but when you
>> change it to ORDER_PROCESSING (or some similar state) it will then do
>> the reservations, payment perference processing, etc.
>
> Yeah, we toyed with a different status too.
>
> In essence, everything in an order has to always be modifiable, always
> during browse.  Then, at some special point, the user hits 'place
> order'.  A single boolean-flag change should occur at that point, and
> the order starts entering into the workflow.

This would be very helpful for the POS. It's a long awaited solution

Jacques

>>
>> On Apr 6, 2010, at 12:59 PM, Adam Heath wrote:
>>
>>> Using a shoppinglist to save a cart is very poor form.  You'll not be
>>> able to save shipgroup assignments, postal address per shipgroup,
>>> shipping method, virtual product features, payment settings, promo
>>> codes, tons of stuff.  We need to be able to restore *all* these things.
>>>
>>> Saving the cart to an order is a possibility, but that will end up
>>> causing a bunch of ecas(entity and service) to run.  Things like
>>> inventory reservation, posting of payments, etc.
>>>
>>> We(Ean and I) have talked, and the way we'd like to see this done, is
>>> to invent a new order type, CART(or something), to go along with
>>> SALES_ORDER and PURCHASE_ORDER.  We are very close to just having to
>>> go and doing this.  Of course, this could cascade to lots of other
>>> code, that explicitly checks the orderTypeId.
>>>
>>> In an ideal world, there were be *no* separate serialization step.
>>> The cart would *always* modify the database view of an order.  Always.
>>> The final step would just then be changing it's type from CART to
>>> SALES_ORDER.  This second phase, however, it more difficult.
>>
>> Robert Morley
>> Software Developer
>> Emforium Group Inc.
>> ALL-IN Software™
>> 519-772-6824 ext 220
>> rmorley@emforium.com
>>
>>
> 

Re: shoppingcart serialization, not shoppinglist

[Adam Heath <do...@brainfood.com>]

Robert Morley wrote:
> Introducing a new type "CART" as an OrderType does not feel right to
> me.  It would seem having an Order of type "SalesOrder" and being able
> to influence which functionality you wish to execute on that entity via
> its status (or additional attribute) might be work considering.  We had
> a very similar problem, we wanted to work with a persisted version of
> the SalesOrder which was a more long term object from our perspective.
> 
> What we have done is only apply payments in a single transaction as part
> of completing the order (obviously not totally desirable) but this
> avoided payment processing as part of saving / updating the order.  As
> for inventory reservations, we actually wanted to reserve items as they
> are added to the order so we left this but then built some logic around
> releasing and re-reserving when items were updated/removed from the
> order.  There were a number of gotchas in the set of services you can do
> with an order -- for example, the service to load an order into a cart
> for updating is really expecting to "clone" the order ... I believe it
> nulls out the orderId on the shopping cart for example to cause a new
> order to be created.
> 
> Can you consider a product store configuration that would indicate when
> reservations should occuring based on the state of the order (if this
> does not already exist).  So when you are cobbling up your order
> (ORDER_CREATED status) it may not be doing reservations, but when you
> change it to ORDER_PROCESSING (or some similar state) it will then do
> the reservations, payment perference processing, etc.

Yeah, we toyed with a different status too.

In essence, everything in an order has to always be modifiable, always
during browse.  Then, at some special point, the user hits 'place
order'.  A single boolean-flag change should occur at that point, and
the order starts entering into the workflow.

> 
> On Apr 6, 2010, at 12:59 PM, Adam Heath wrote:
> 
>> Using a shoppinglist to save a cart is very poor form.  You'll not be
>> able to save shipgroup assignments, postal address per shipgroup,
>> shipping method, virtual product features, payment settings, promo
>> codes, tons of stuff.  We need to be able to restore *all* these things.
>>
>> Saving the cart to an order is a possibility, but that will end up
>> causing a bunch of ecas(entity and service) to run.  Things like
>> inventory reservation, posting of payments, etc.
>>
>> We(Ean and I) have talked, and the way we'd like to see this done, is
>> to invent a new order type, CART(or something), to go along with
>> SALES_ORDER and PURCHASE_ORDER.  We are very close to just having to
>> go and doing this.  Of course, this could cascade to lots of other
>> code, that explicitly checks the orderTypeId.
>>
>> In an ideal world, there were be *no* separate serialization step.
>> The cart would *always* modify the database view of an order.  Always.
>> The final step would just then be changing it's type from CART to
>> SALES_ORDER.  This second phase, however, it more difficult.
> 
> Robert Morley
> Software Developer
> Emforium Group Inc.
> ALL-IN Software™
> 519-772-6824 ext 220
> rmorley@emforium.com
> 
> 

Re: shoppingcart serialization, not shoppinglist

[Robert Morley <rm...@emforium.com>]

Introducing a new type "CART" as an OrderType does not feel right to  
me.  It would seem having an Order of type "SalesOrder" and being able  
to influence which functionality you wish to execute on that entity  
via its status (or additional attribute) might be work considering.   
We had a very similar problem, we wanted to work with a persisted  
version of the SalesOrder which was a more long term object from our  
perspective.

What we have done is only apply payments in a single transaction as  
part of completing the order (obviously not totally desirable) but  
this avoided payment processing as part of saving / updating the  
order.  As for inventory reservations, we actually wanted to reserve  
items as they are added to the order so we left this but then built  
some logic around releasing and re-reserving when items were updated/ 
removed from the order.  There were a number of gotchas in the set of  
services you can do with an order -- for example, the service to load  
an order into a cart for updating is really expecting to "clone" the  
order ... I believe it nulls out the orderId on the shopping cart for  
example to cause a new order to be created.

Can you consider a product store configuration that would indicate  
when reservations should occuring based on the state of the order (if  
this does not already exist).  So when you are cobbling up your order  
(ORDER_CREATED status) it may not be doing reservations, but when you  
change it to ORDER_PROCESSING (or some similar state) it will then do  
the reservations, payment perference processing, etc.

On Apr 6, 2010, at 12:59 PM, Adam Heath wrote:

> Using a shoppinglist to save a cart is very poor form.  You'll not be
> able to save shipgroup assignments, postal address per shipgroup,
> shipping method, virtual product features, payment settings, promo
> codes, tons of stuff.  We need to be able to restore *all* these  
> things.
>
> Saving the cart to an order is a possibility, but that will end up
> causing a bunch of ecas(entity and service) to run.  Things like
> inventory reservation, posting of payments, etc.
>
> We(Ean and I) have talked, and the way we'd like to see this done, is
> to invent a new order type, CART(or something), to go along with
> SALES_ORDER and PURCHASE_ORDER.  We are very close to just having to
> go and doing this.  Of course, this could cascade to lots of other
> code, that explicitly checks the orderTypeId.
>
> In an ideal world, there were be *no* separate serialization step.
> The cart would *always* modify the database view of an order.  Always.
> The final step would just then be changing it's type from CART to
> SALES_ORDER.  This second phase, however, it more difficult.

Robert Morley
Software Developer
Emforium Group Inc.
ALL-IN Software™
519-772-6824 ext 220
rmorley@emforium.com