Why new Order calculation requires line items belong to shipment?

I had an issue using new features - WorkflowsVNext. When adding/removing items in the cart using CartHelper.AddEntry() or PurchaseOrderManager.RemoveLineItemFromOrder() everything is fine, but updating Quantity of the line item "old" way didn't work. While quantity got updated any calculations didn't take it into account. I was updating LineItem's Quantity by getting LineItem from the cart and setting new Quantity.

I found that issues were caused because I didn't update shipment's LineItem's Quantity. And documentation describes it: http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-Commerce/9/Orders/calculating-orders-beta/

So the questions:

1. Why order calculations were changed to use Shipment's LineItems?

2. Is there an API to change Quantity through one method call so that both - Cart's LineItem and Shipment's LineItem's Quantity gets updated?

3. Are there any plans to fix API for add/remove/update cart items in the cart, so that there is only one way to do it and use one "base" object (now CartHelper is used for adding an item, but PurchaseOrderManager for removing item)? Would be nice to have just Cart.AddItem(), Cart.RemoveItem() or similar.

#143934 Feb 03, 2016 14:41
  • Hi,

    The change was made to get a more consistent view of line items and quantity handling. The lineItemQuantityIndexMap is *very* difficult to work with. ...and things will eventually end up in a shipment anyway so that would make sense. At least that is/was our current line of reasoning. If you feel that this is confusing or simply wrong - please let us know. We're always interested in feedback to improve the product.

    I understand that it is a bit confusing now since we have not yet established proper mutability thru the new order abstractions (IOrderGroup / IOrderFor et al), but you're forced to cast back and forth. Rest assured that the API:s will be fleshed out, cleaned up and made more usable/understandable. This is one of the reasons why this part of our API:s is still beta-tagged (unstable) - we will make changes (possibly breaking changes) without releasing those changes as a new major version of Episerver Commerce.

    Eventually CartHelper will be a very thin wrapper on top of the new API:s, but we still intend to keep CartHelper for reasons of backwards compatibility.

    #143947 Feb 03, 2016 16:12
First   1   Last