Orders' retailLocation & physicalLocation are always null

Hello,

I have found that all orders that I create within my test store have a null physicalLocation and retailLocation. (Context docs: Order ). The unusual thing is that I can see that orders have fulfillmentOrders with their own locations, so it’s not that the order doesn’t have locations associated with it.

For example, here is an order with two fulfillment orders for two locations, but retail and physical location are still null:

{
  "data": {
    "order": {
      "id": "gid://shopify/Order/6367180882240",
      "legacyResourceId": "6367180882240",
      "retailLocation": null,
      "physicalLocation": null,
      "fulfillmentOrders": {
        "nodes": [
          {
            "id": "gid://shopify/FulfillmentOrder/7337752396096",
            "assignedLocation": {
              "location": {
                "id": "gid://shopify/Location/96215892288"
              }
            }
          },
          {
            "id": "gid://shopify/FulfillmentOrder/7337754689856",
            "assignedLocation": {
              "location": {
                "id": "gid://shopify/Location/103998685504"
              }
            }
          }
        ]
      }
    }
  },

In the case of retailLocation, the docs say that this is for retail orders. These orders are created through the online storefront or via a draftOrder, so I would expect it to apply given they are for retail, not b2b or similar (and are not POS, if this is relevant). But I may completely misunderstand the definition of retail order; I couldn’t find any docs for this.

For physicalLocation, this is a deprecated field so less important as I won’t use it anyway, but I don’t see any reason it should be null. In the primary admin order json (or REST), there is a location_id field which is also null. Both physicalLocation & location_id have similar descriptions, so it’s possible they are the same.

I can see from this old Shopify Community topic that location_id was at one point only for POS orders - so is there a chance that these two fields are only for POS orders

(I’d like to also briefly clarify that I do know how to find locations for orders - I can do this with the fulfillmentOrders, just like above! But what I am asking about is what these fields mean, for the purposes of understanding how to translate a REST model / approach to a GraphQL one)

I’d appreciate any assistance people have with understanding why these fields are null!

I have an update, and I’d thought I’d put it here even if just to avoid a DenverCoder9 sort of situation. It’s based off of experimental observation, so do take it with a pinch of salt, and it does contradict the docs (although I think they are misleading at best, downright wrong at worst)

The deprecation notices encourage you to use fulfillmentOrder location. This location appears to always represent where the physical stock is moving from.
For example, for a POS order where the Customer walks away with the item that day, there will be a fulfillmentOrder with the location of the shopify store.
If a merchant is using POS Pro and has selected to fulfill a POS order later, then the fulfillmentOrder’s location will be the location of the warehouse the stock is leaving from - which might be different to the POS store’s location.
This is a different behaviour to the order.location in REST, which means following the official advice will result in different behaviour between REST/GraphQL

There is also a retailLocation, which is described as the ‘physical location’ a ‘retail order’ takes place. It appears that it is null for all non-POS orders, and has the location of the store for POS orders (except the draft order exception listed in the docs).
I’m not sure what retail orders are (shopify does not define this, nor does the API provide any means of categorising orders by ‘retail’ status that I can find), but it appears to mean POS orders, even though non-POS orders are retail too.

In both regular POS orders and POS-Pro orders being fulfilled later, the retail location is the same - the location of the store the sale took place.

The TL;DR is if you are looking to replace REST order.location or GraphQL order.physicalLocation, you should look into ignoring the docs, and using retailLocation, as this appears to be a direct translation of old functionality.