How a preorder becomes a real order
Four scenarios covering how Movex, Barrett, Techsera, Shopify, and STOQ stay in sync — from a purchase order landing in the ERP to customer delivery.
New PO arrives in Movex
backorder.incoming_po_quantity metafield (JSON) via metafieldsSet. Including the PO number guarantees each write is unique — even if two POs carry the same quantity back-to-back, the trigger won't miss one by comparing identical values.View JSON GraphQL Payload
# Definition ID: gid://shopify/MetafieldDefinition/214024749169 mutation SetIncomingPOQuantity($metafields: [MetafieldsSetInput!]!) { metafieldsSet(metafields: $metafields) { metafields { id namespace key value type } userErrors { field message code } } } # GraphQL Variables (Type: json with PO uniqueness): { "metafields": [ { "ownerId": "gid://shopify/ProductVariant/{{variant_id}}", "namespace": "backorder", "key": "incoming_po_quantity", "value": "{\"po_number\":\"PO-4521\",\"quantity\":100}", "type": "json" } ] }
backorder.incoming_po_quantity changes (via Workflow Trigger Extensions app). Extracts quantity from the JSON payload and initiates the read → calculate → write sequence.preorder_max_count is read for that variant — STOQ's update endpoint sets an absolute value, so the current limit is queried first.current limit + quantity.
The trigger compares against a stored snapshot and only fires when the value differs from the last recorded one — a plain repeated number would risk being silently dropped, which is why po_number is included (confirmed with Workflow Trigger Extensions support).
⚠️ Baseline snapshot note: The trigger needs an existing snapshot to compare against. The very first write after enabling the trigger can be absorbed into that baseline instead of firing — a one-time initial setup consideration for testing.
Stock arrives, covers preorders & leaves surplus
inventoryAdjustQuantities.2) Writes the received shipment's identifier (
shipment_id) and the PO it is being received against (po_number), along with the updated remaining in-transit total across all open POs, to Metafield 2: backorder.units_in_transit (JSON) via metafieldsSet.
⚠️ units_in_transit is always the running total across every open PO for this variant — not the specific shipment that just arrived. When a shipment fully closes out one PO, the new value written is the sum of whatever other POs are still outstanding, not zero (unless this was genuinely the last open PO).
TBD (Pending Creation)
View JSON GraphQL Payload (units_in_transit)
# Definition ID: TBD (Pending creation in Shopify — ProductVariant) { "metafields": [ { "ownerId": "gid://shopify/ProductVariant/{{variant_id}}", "namespace": "backorder", "key": "units_in_transit", "value": "{\"shipment_id\":\"SHIP-8842\",\"po_number\":\"PO-4521\",\"units_in_transit\":80}", "type": "json" } ] }
prior <= 0 and current > 0). Filters specifically by heldByApp.id (STOQ holds only) and releases them.backorder.units_in_transit JSON update:• Extracts
units_in_transit from payload and reads native committed.• Reads
preorder_count from STOQ.• Calculates:
new_limit = preorder_count + units_in_transit − committed.• Writes
new_limit to STOQ via PATCH (equivalent to count 0, limit = units_in_transit − committed).
• Arrival: PO of 100 units arrives (covers 50, leaves 50 surplus)
• Remaining Committed: 0 waiting
• Units in Transit: 80 (PO#2)
• Formula:
50 (count) + 80 (transit) − 0 (committed) = 130• Open Preorder Spots:
130 − 50 = 80 (excludes 50 surplus units now selling as regular stock).
Includes shipment_id in the JSON value to guarantee each write is unique, preventing the trigger from silently dropping consecutive identical units-in-transit totals.
⚠️ Baseline snapshot note: Like Flow 1, the very first write after enabling the trigger establishes the comparison baseline snapshot.
Stock arrives & is fully absorbed (no surplus)
inventoryAdjustQuantities.2) Writes received shipment identifier, the PO it is being received against, and updated remaining in-transit units to Metafield 2:
backorder.units_in_transit (JSON with shipment_id and po_number).
TBD (Pending Creation)
View JSON GraphQL Payload (units_in_transit)
# Definition ID: TBD (Pending creation in Shopify — ProductVariant) { "metafields": [ { "ownerId": "gid://shopify/ProductVariant/{{variant_id}}", "namespace": "backorder", "key": "units_in_transit", "value": "{\"shipment_id\":\"SHIP-8842\",\"po_number\":\"PO-4521\",\"units_in_transit\":40}", "type": "json" } ] }
0 because all incoming units are allocated to existing held orders.heldByApp.id). Pending orders remain held.units_in_transit from JSON and runs the universal formula: new_limit = preorder_count + units_in_transit − committed.Because all arrived units were absorbed by waiting preorders, remaining open spots accurately reflect unarrived PO units without overselling.
Flow 2 executes the exact same mathematical formula (preorder_count + units_in_transit − committed) across all physical stock receipt scenarios.
*Uses JSON with shipment_id to guarantee trigger change-detection on every partial shipment.
PO registered on an in-stock item
backorder.incoming_po_quantity metafield (JSON) via Shopify GraphQL (metafieldsSet).
• If stock sells out first: Transitions seamlessly into preorder with the staged limit ready.
• If PO arrives first: Flow 2's formula (triggered via JSON units_in_transit) recalculates upon receipt, stripping arrived units and preventing inflation.
Summary of the 4 Scenarios
Two distinct JSON metafields drive two dedicated Flows: one for incremental PO creation, and one for physical shipment recalculations.
Metafield 1: incoming_po_quantity (JSON)
Movex PO → Techsera writes {po_number, quantity} → Flow 1 reads current limit and writes limit + quantity.
Metafield 2: units_in_transit (JSON)
Barrett arrival → Techsera writes {shipment_id, units_in_transit} → Flow 2 recalculates: count + units_in_transit − committed.
Metafield 2: units_in_transit (JSON)
Partial arrival → Techsera writes {shipment_id, units_in_transit} → Flow 2 runs universal formula; all units absorbed with 0 surplus.
Metafield 1: incoming_po_quantity (JSON)
PO on in-stock item → Flow 1 stages limit in STOQ in background (sits inert until stock reaches 0).
Live Preorder Event Simulator
Simulate real-world PO creations, customer preorders, and inventory arrivals to watch the 5 core system variables and Flows react in real time.
units_in_transit is always the running total across every open PO for this variant — not the specific shipment that just arrived. When a shipment fully closes out one PO, Techsera writes the sum of whatever other POs are still outstanding (not zero, unless this was genuinely the final PO).
| # | Event | Storefront CTA | Limit | Available | Count | Committed | In Transit | System Reaction & Formula Calculation |
|---|