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.
Who does what across the stack
Each component maintains a strict single responsibility boundary to prevent race conditions and out-of-sync inventory numbers.
Movex
ERP where purchase orders (POs) originate and expected inventory is created. Has zero concept of Shopify or preorder rules.
Barrett
Physical warehouse. Receives and checks in physical shipment units against open POs.
Techsera
Integration middleware. Responsible for writing inventory deltas and PO signal triggers into Shopify.
Shopify
Tracks available vs committed stock natively. Holds and releases fulfillment orders on inventory adjustments.
STOQ
Decides preorder button eligibility, applies checkout holds, and strictly enforces the customer sell limit.
New PO arrives in Movex
backorder.incoming_po_quantity metafield via Shopify's GraphQL API (metafieldsSet) — this value is set/overwritten each time, not accumulated. It exists only to carry this one PO's quantity and trigger the next step.View GraphQL Request 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: { "metafields": [ { "ownerId": "gid://shopify/ProductVariant/{{variant_id}}", "namespace": "backorder", "key": "incoming_po_quantity", "value": "100", "type": "number_integer" } ] }
preorder_max_count is read for that variant — the update endpoint sets an absolute value, so the current limit has to be queried first.current limit + incoming PO quantity.The preorder limit immediately reflects incoming stock. Physical inventory and order holds are completely untouched at this stage.
The metafield itself is transient — it only exists to trigger this sequence; the real accumulated value lives in STOQ's preorder_max_count.
Stock arrives & covers everything
delta — no state lookup required.inventoryQuantityPrior <= 0 AND inventoryQuantity > 0), queries the fulfillment orders on hold for this variant, filters to holds placed specifically by STOQ (heldByApp.id), and releases only those — never a blanket release, to avoid touching holds from other apps (e.g. a payment hold).Both the limit and sold tally remain accurate in STOQ history. There is nothing to reset or recalculate.
Stock arrives & covers only part
0 — pending preorders wait in queue.The math holds whether inventory arrives in a single batch or multiple split shipments.
PO registered on an in-stock item
A single static limit update set once when the PO arrives cannot correctly accommodate both possible real-world event sequences:
- Case A (PO physically arrives before stock sells out): If the limit was bumped at registration, when physical stock arrives it increases available inventory, but the STOQ limit remains inflated — allowing overselling beyond real PO backing later.
- Case B (Stock sells out before PO physically arrives): If the limit was untouched while stock was positive, the variant transitions into preorder with limit
0— improperly blocking sales when a valid PO is actually on the way.
Instead of pushing the limit when the PO is registered in Movex, defer the calculation until the variant actually transitions into preorder (stock reaches 0). At that exact moment, query the remaining outstanding PO quantity (registered but not yet physically received) and write that as the active STOQ limit.
Can we query outstanding (registered-but-not-yet-received) PO quantity per variant on demand at any point in time?
This capability is currently unconfirmed and must be validated with Techsera/Movex API capabilities before finalizing Scenario 4.
🔍 Dynamic JIT (Investigating): Stock reaches
0 → Query outstanding POs → Set STOQ limit dynamically.
Summary of the 4 Scenarios
The first two only ever affect the preorder limit. The next two only ever affect what happens to orders already on hold — never both at once.
Preorder Limit Increment
Movex PO → Techsera → STOQ Limit (+PO Qty). No physical stock changes.
Full Order Release
Barrett receipt → Shopify Inventory Delta. Committed released, Available turns positive.
Partial Order Release
Committed drops by arrival count. Available stays 0. Preorders continue taking orders.
PO on In-Stock Item (Event Ordering Conflict)
Static limit update causes inflation (Case A) or 0-limit lockouts (Case B). Investigating dynamic calculation upon stock reaching 0.
What's confirmed, what's open
Engineering validation status as of latest integration checks (STOQ confirmation Sept 2).
Shopify native available/committed math handles Flows 2 and 3
Nothing needs to be custom-built to track allocation — this is built-in Shopify inventory functionality.
Shopify Flow "Send HTTP request" can call STOQ API directly
Confirmed by STOQ support — custom headers (X-Auth-Token), external endpoints, and JSON payloads fully supported.
Shopify metafield mirror of the limit is strictly read-only
Writing directly to the metafield does not enforce checkout caps — only STOQ's own PATCH endpoint updates the real limit.
Metafield trigger & definition created in Shopify
Definition ID: gid://shopify/MetafieldDefinition/214024749169 (backorder.incoming_po_quantity, type number_integer). Techsera writes incoming PO quantities via metafieldsSet, and the installed Workflow Trigger Extensions app detects changes to trigger Shopify Flow.
Scenario 4: Outstanding PO Query on Stockout (Under Investigation)
Resolving event-ordering conflicts (Case A: early arrival inflation vs Case B: early stockout lockout). Can Techsera/Movex query outstanding (registered-but-not-yet-received) PO quantity per variant on demand when stock hits 0?
Fulfillment-hold release flow testing
Flow designed but hit editor bugs during initial setup. Requires a clean rebuild and verification pass before production go-live.
Capacity consideration: Workflow Trigger Extensions Free Tier
The Free plan includes a ceiling of 5,000 trigger events / month. Not an immediate blocker for launch, but an operational metric to monitor as catalog updates and PO volume scale.