Brief
There seems to be a gap in the way Shopify order management can be used and perceived via admin UI versus what is currently possible to be perceived from the API. This causes issues when it comes to understanding what tracking code corresponds to the returned items and in what final state (in terms of quantities left) given fulfillments (received from API) are.
The Scenario
1. User creates an order with single item (qty=20)
2. User creates fulfilmentX (qty=6)
3. User creates fulfilmentY (qty=2)
4. User creates a return for fulfilmentX (qty=3)
5. User completes the return by refunding the items (qty=3)
What I can get from the API (VIEW_API):
1. The order line_items
2. The order fulfillments (with references to specific line_items with the original fulfilment quantities mentioned in #2 and #3). (fulfilmentX (qty=6), fulfilmentX (qty=2))
3. The refunds that list quantities that were returned+refunded.
What I see in UI (VIEW_UI):
1. When creating the fulfilment I am given a choice to pick quantities from each fulfillments separately.
2. When the returns have been registered - the fulfilment quantities listed are reduced according to my choices made when creating returns. (fulfilmentX (qty=3), fulfilmentX (qty=2)).
The Problem
When building integrations against Shopify, there's a certain gap where I don't know from which fulfilment the returns were done from (because that information is not provided by the refunds). This causes issues due to:
1. Each fulfilment having its own tracking code so in our integrations it's very important to deduce the quantities from correct fulfilment.
2. I have no way of constructing the state that is described above under VIEW_UI#2: when the returns have been registered - the fulfilment quantities listed are reduced according to my choices made when creating returns.
3. There's no clear way to map the refunded items to certain Order line_item group. There's restock_type, which does help a little when you choose to restock (where you will get "cancel" on Unfulfilled and "return" for Fulfilled quantities), but it will always return generic "no_restock" when you choose not to restock (thus the indication on if the quantity was removed from Unfulfilled or Fulfilled line is - again - lost.
I could brute-force the quantity reductions by using refunds to pick quantities from random fulfillments, but that would not solve the issues described above.
The Question
These four questions are basically three proposals on how to solve this issue or how to basically provide full overview of what has happened (and how) with the Order for the API users:
1. Will there ever be Returns API exposed to the partners to bridge this gap?
2. Would it be possible to add returned quantity field for fulfilment line items for there to be at least possibility to construct correct end-state for the fulfillments (as we don't have access to returns)?
3. Would it be possible to add fulfilment ID to each refund line_item (when returned/refunded from fulfilment) to be able to have clear reference from which fulfilment the entity was sourced?
4. Would it be possible to restock_source on the refund that wound indicate if the restock was done from fulfilled or unfulfilled rows (this would help a little to compartmentalise the changes).
