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