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
[email protected]
