Financial recalculation (API)

Bug Reports
1

Case:

  • an order with 9 lines (3 suppliers, 3 products for each)
  • call process_dropshipments

Result:

  • the order was split into 3 orders by a supplier (as expected)
  • the “financial” field of the first order is equal to this field of parent order
  • other 2 orders have zeros in “financial” data

Expected:

  • each child order should have recalculated financial data by its lines

Case 2:

  • split shipments by my app internal rules (create additional shipments, change the quantity of each line for each shipment)

Results:

  • shipments were split
  • total_price filed of each line contains the old value. Even if the line qty for the shipment is 0, total_price will be item_price * old qty.

Expected:

  • all values should be recalculated according to made changed
2

We will be addressing some issues around splitting orders + financial calculations for v3 in the next few of weeks. If you could add the specific endpoints you are calling and show the actual vs expected responses, that would be extremely helpful.

3

API v3

The Order

http://puu.sh/AlTDw/3890df883b.png

endpoint: /order/1-1646/process_dropshipments

Child Order 1

http://puu.sh/AlTGS/7580e302d0.png

Child Order 2

http://puu.sh/AlTHC/c23dad2a28.png

Child Order 3

http://puu.sh/AlTIP/8225f3e3b4.png

API v2: “split shipments”
/order/1-1646-1/create_shipment/ (add one more shipment)

/shipment/$shipment_id/line/$shipment_line_id/ (set proper qty for each line of each shipment)

Shipment 1

http://puu.sh/AlTTT/aeb8a6a5b1.png

Shipment 2

http://puu.sh/AlUbA/eab16b0994.png

Also, this process if resource intensive. 2 shipments, 2 lines each = 4 API calls, 4 x 5 = 20 and so on.

4

Any updates for the subject?

5

No additional updates at this time.

6

Hi Ivan,

For v3 orders, financials are now automatically recalculated when orders are split by either of these endpoints:

  • /order/{order_number}/process_dropshipments
  • /order/{order_number}/split

You also mentioned creating multiple shipments for v3 orders via the v2 api, but that is not supported. V3 orders should be split instead of creating multiple shipments for them.

7

Hi,

I see, “product_amount” is recalculating now
What about discount_amount, shipping_amount, tax_amount?

1-7433 1-7433 2018-07-20T14:37:26.364937+00:00 {“credit_card_issuer”:“Cash on delivery”,“discount_amount”:0,“product_amount”:277.99,“shipping_amount”:0,“tax_amount”:36.14,“grand_total”:314.13}
1-7433-1 1-7433 2018-07-20T14:40:08.428965+00:00 {“credit_card_issuer”:“Cash on delivery”,“discount_amount”:0,“product_amount”:250,“shipping_amount”:0,“tax_amount”:36.14,“grand_total”:286.14}
1-7433-2 1-7433 2018-07-20T14:40:08.662893+00:00 {“credit_card_issuer”:null,“discount_amount”:0,“product_amount”:1,“shipping_amount”:0,“tax_amount”:0,“grand_total”:1}
1-7433-3 1-7433 2018-07-20T14:40:08.892801+00:00 {“credit_card_issuer”:null,“discount_amount”:0,“product_amount”:26.99,“shipping_amount”:0,“tax_amount”:0,“grand_total”:26.99}
8

Only product_amount and grand_total are recalculated.

For shipping, discount, and tax, they are passed on to the first order and zero’d out on the next order. We want to include the other amounts in the future, but we will need to make some adjustments so we can properly include information about how those values should be split. Just evenly distributing them is not the correct thing to do in many cases:

  • shipping costs usually increase when splitting because it will require multiple shipping labels
  • discounts are often tied to specific products or groups of products
  • items may be taxed at different amounts

So for now, we expect people will need to make their own adjustments to those amounts after the split if they are important.

9

Thank you for the clarification.