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.
MoveX recalculates and pushes a new snapshot
available_to_sell_qty internally in response to any of: a new PO created, stock received at Barrett, or a PO cancelled/reduced. There is no per-PO event — MoveX pushes the fully recalculated snapshot total (available to sell qty for that SKU, landing in the next 4 weeks) every time.backorder.available_to_sell_qty metafield (JSON) via metafieldsSet. Techsera does not calculate this figure — it only relays what MoveX already computed. This is the same single metafield used for every trigger; there is no separate "incoming PO" metafield.TBD (Pending Creation)
View JSON GraphQL Payload (available_to_sell_qty)
# Definition ID: TBD (Pending creation in Shopify — ProductVariant) mutation SetAvailableToSellQty($metafields: [MetafieldsSetInput!]!) { metafieldsSet(metafields: $metafields) { metafields { id namespace key value type } userErrors { field message code } } } # GraphQL Variables (Type: json with timestamp uniqueness): { "metafields": [ { "ownerId": "gid://shopify/ProductVariant/{{variant_id}}", "namespace": "backorder", "key": "available_to_sell_qty", "value": "{\"last_updated\":\"2026-09-15T10:32:00Z\",\"available_to_sell_qty\":300}", "type": "json" } ] }
backorder.available_to_sell_qty changes (via Workflow Trigger Extensions app). Extracts available_to_sell_qty from the JSON payload and reads native committed — the same single Flow regardless of which of the three MoveX triggers caused the push.new_limit = preorder_count + available_to_sell_qty − committed — the same universal formula used for every trigger.
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 the JSON value includes a last_updated timestamp or execution ID (confirmed with Workflow Trigger Extensions support). There's no per-PO event to key off anymore, just a periodic recalculated push.
⚠️ 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) MoveX (via QlikView) recalculates the variant's available to sell qty landing in the next 4 weeks internally and pushes the fully recalculated snapshot total. Techsera relays that number, unchanged, to Metafield 2:
backorder.available_to_sell_qty (JSON) via metafieldsSet. Techsera does not calculate this figure — it only relays what MoveX already computed.
⚠️ MoveX currently recalculates and pushes this value on an hourly schedule (not real-time transactional), meaning available-to-sell data can be stale for up to an hour after a state change. The team has explicitly accepted this as a known short-term risk, with plans to reduce the refresh interval to 15–30 minutes. During that window, STOQ's limit could be temporarily overstated, creating a small oversell risk.
TBD (Pending Creation)
View JSON GraphQL Payload (available_to_sell_qty)
# Definition ID: TBD (Pending creation in Shopify — ProductVariant) { "metafields": [ { "ownerId": "gid://shopify/ProductVariant/{{variant_id}}", "namespace": "backorder", "key": "available_to_sell_qty", "value": "{\"last_updated\":\"2026-09-15T10:32:00Z\",\"available_to_sell_qty\":300}", "type": "json" } ] }
prior <= 0 and current > 0). Filters specifically by heldByApp.id (STOQ holds only) and releases them.backorder.available_to_sell_qty JSON update:• Extracts
available_to_sell_qty from payload and reads native committed.• Reads
preorder_count from STOQ.• Calculates:
new_limit = preorder_count + available_to_sell_qty − committed.• Writes
new_limit to STOQ via PATCH (equivalent to count 0, limit = available_to_sell_qty − committed).
• Arrival: PO of 100 units arrives (covers 50, leaves 50 surplus)
• Remaining Committed: 0 waiting
• Available to Sell Qty: 80 (MoveX's recalculated snapshot for the next 4 weeks)
• Formula:
50 (count) + 80 (available_to_sell_qty) − 0 (committed) = 130• Open Preorder Spots:
130 − 50 = 80 (excludes 50 surplus units now selling as regular stock).
The unique identifier in the JSON value is now a timestamp (last_updated) or execution ID from MoveX/Techsera's periodic push, not a po_number/shipment_id pair — there's no per-PO event anymore, just a periodic recalculated snapshot. This still guarantees each write is unique, preventing the trigger from silently dropping consecutive identical totals.
⚠️ Baseline snapshot note: As with any Workflow Trigger Extension, the very first write after enabling the trigger establishes the comparison baseline snapshot.
Stock arrives & is fully absorbed (no surplus)
inventoryAdjustQuantities.2) MoveX (via QlikView) recalculates the internal available-to-sell snapshot in response to the receipt at Barrett and pushes the new total. Techsera relays it, unchanged, to Metafield 2:
backorder.available_to_sell_qty (JSON).
TBD (Pending Creation)
View JSON GraphQL Payload (available_to_sell_qty)
# Definition ID: TBD (Pending creation in Shopify — ProductVariant) { "metafields": [ { "ownerId": "gid://shopify/ProductVariant/{{variant_id}}", "namespace": "backorder", "key": "available_to_sell_qty", "value": "{\"last_updated\":\"2026-09-15T11:05:00Z\",\"available_to_sell_qty\":40}", "type": "json" } ] }
0 because all incoming units are allocated to existing held orders.heldByApp.id). Pending orders remain held.available_to_sell_qty from JSON and runs the universal formula: new_limit = preorder_count + available_to_sell_qty − committed.Because all arrived units were absorbed by waiting preorders, remaining open spots accurately reflect unarrived supply without overselling.
The Flow executes the exact same mathematical formula (preorder_count + available_to_sell_qty − committed) on every trigger — new PO, receipt, or cancellation.
*Uses JSON with a last_updated timestamp to guarantee trigger change-detection on every recalculated push.
PO registered on an in-stock item
backorder.available_to_sell_qty metafield (JSON) via Shopify GraphQL (metafieldsSet) — the same single metafield used for every trigger.
• If stock sells out first: Transitions seamlessly into preorder with the staged limit ready.
• If PO arrives first: the same Flow (triggered via JSON available_to_sell_qty) recalculates upon receipt, stripping arrived units and preventing inflation.
Summary of the 4 Scenarios
A single JSON metafield (available_to_sell_qty) feeds one unified Flow, fed by MoveX's recalculated snapshot regardless of which of the three triggers caused the push.
Metafield: available_to_sell_qty (JSON)
New PO in Movex → MoveX recalculates its internal snapshot, Techsera relays {last_updated, available_to_sell_qty} → the Flow writes preorder_count + available_to_sell_qty − committed.
Metafield: available_to_sell_qty (JSON)
Barrett arrival → MoveX recalculates its internal snapshot, Techsera relays {last_updated, available_to_sell_qty} → the Flow recalculates: count + available_to_sell_qty − committed.
Metafield: available_to_sell_qty (JSON)
Partial arrival → MoveX recalculates its internal snapshot, Techsera relays {last_updated, available_to_sell_qty} → the Flow runs the universal formula; all units absorbed with 0 surplus.
Metafield: available_to_sell_qty (JSON)
PO on in-stock item → the Flow stages the limit in STOQ in the 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.
available_to_sell_qty is a fully recalculated snapshot from MoveX (via QlikView), not a running total Techsera assembles from individual POs. MoveX currently recalculates and pushes this value on an hourly schedule (not real-time transactional), meaning available-to-sell data can be stale for up to an hour after a state change. This is an accepted known short-term risk, with plans to reduce the refresh interval to 15–30 minutes — during that window, STOQ's limit could be temporarily overstated, creating a small oversell risk.
| # | Event | Storefront CTA | Limit | Available | Count | Committed | Avail-to-Sell | System Reaction & Formula Calculation |
|---|