orderEditBegin should return original line item ID on CalculatedLineItem

Products and Orders APIs
1

Please update the orderEditBegin mutation to include the original order’s line item ID on the corresponding CalculatedLineItem object. This is essential for 100% accurate synchronization between an ERP and Shopify.

2

Hey @Mitchell_Claborn - just confirming I don’t see a fully reliable way to map a CalculatedLineItem back to its original LineItem from orderEditBegin today.

You can compare the calculated line item data against calculatedOrder.originalOrder.lineItems, but that becomes a bit not ideal when an order has duplicate variants or matching custom line item details, so I agree that it doesn’t cover a 100% accurate ERP sync case.

I’ll pass this feedback along on our end as a feature request for exposing the original line item ID directly on the calculated line item. Let me know if there’s a specific mutation flow or example order shape where this is blocking you, since that would help frame the use case more clearly.

3

Here’s a typical scenario:

ERP order:
item1 qty=5 price=10.00 shopify_line_item_id=111
item1 qty=5 price=8.00 shopify_line_item_id=2

Shopify order:
item1 qty=5 price=10.00 id=111
item1 qty=5 price=8.00 id=222

Now on the ERP, change the price of the 8.00 item to 7.00. ERP does orderEditBegin to push that change to Shopify. Because the line item IDs don’t exist on the CalculatedOrder, the ERP code has to essentially guess which line item to change the price on. In this case it is relatively simple, but more complex cases exist where the determination cannot be made with 100% accuracy.

4

Hey @Mitchell_Claborn - thanks for the example there. I checked this against the current behaviour, and you’re right that CalculatedLineItem doesn’t expose a direct reference back to the original LineItem ID today. Since the order edit mutations use the calculated line item ID, an ERP starting from the original Shopify line item ID still has to map across after orderEditBegin, and duplicate/similar line items can make that ambiguous.

I’ll pass this along as a feature request to expose the source/original line item ID on calculated line items. In the meantime, the best available fallback is matching against calculatedOrder.originalOrder.lineItems, but for tied cases I’d treat that as ambiguous rather than guessing for sure - thanks for the reply. Please let me know if I can help with anything else here.