Reference · built on requestOperator by FibricOrders & fulfillment

Pre-order Allocation

Reads pre-orders in placement order against inbound purchase orders, then proposes which orders each receipt fills and which slip.

Request accessPricing ↗

About

Pre-orders are promises made against stock that has not arrived. Pre-order Allocation reads the held orders in the sequence they were placed, the open purchase orders with their expected dates and received quantities, and the receipts the warehouse posts. When a receipt lands, it works out which orders that quantity covers and which fall past it.

It proposes the allocation for the receipt, the hold releases for the orders it fills, and a slip notice for those it does not, with the next expected date. A person approves the list, can reorder it, and each order keeps the receipt it was allocated to and every notice it received.

This is a reference listing. It documents what Fibric would read from Pre-order Allocation and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Pre-order lines on Shopify fulfillment orders held with reason INVENTORY_OUT_OF_STOCK, in the order they were placed
  • Open purchase orders and their lines: quantity, receivedQuantity, and expectedReceiptDate in Business Central, or the ShipHero purchase order with quantity_received
  • Katana purchase orders and inventory per location once a receipt is posted
  • Receipt events from the warehouse: ShipHero PO Update, or Logiwa ReceivingCompleted and PurchaseOrderStatusChanged
  • The date each pre-order was shown at checkout, so a slip is measured against what the customer saw
  • Cancellations and edits on pre-orders since they were placed

Proposed actions

  • Target capability: propose the allocation list for a receipt: which pre-orders it fills, in placement order, and the quantity left unallocated
  • Target capability: propose fulfillmentOrderReleaseHold on the orders a receipt covers
  • Target capability: propose a slip notice for orders that fall past the receipt, carrying the next expectedReceiptDate
  • Target capability: propose an exception when a receipt is short and the allocation must split or skip an order
  • Target capability: propose a Klaviyo event per affected profile so your existing flow sends the notice

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Release holds the day a receipt posts

    When a Business Central purchase order line's receivedQuantity rises, propose the Shopify holds to release in placement order and the count still waiting.

    With Microsoft Dynamics 365 Business Central, Shopify

  • Tell the tail before they ask

    Orders beyond the receipt's quantity get a proposed Klaviyo event carrying the next expected date from the Katana purchase order; your flow turns it into the email.

    With Klaviyo, Katana Cloud Inventory

  • Split a short receipt without guessing

    A ShipHero purchase order received short gets an allocation proposal showing which orders fill in full, which split, and which wait for the next receipt.

    With ShipHero, Shopify

Requirements

  • Pre-orders you can identify in the store: a hold, a tag, or a fulfillment order status you name
  • Purchase orders with expected dates and received quantities in an ERP, inventory system, or warehouse: Business Central, ShipHero, or Katana
  • Your allocation rule: strict placement order, or the exceptions you name for order types
  • A messaging path for slip notices: Klaviyo, Postmark, or your help desk
Authentication
A Shopify app token with fulfillment order write access, a Business Central or ShipHero credential for purchase orders, and a Klaviyo private key with events write scope, held per deployment.

Limits

  • Allocation follows the rule you set; it does not rank customers by value unless your rule says so
  • Expected dates come from the purchase order and move when the supplier moves them; the proposal restates the date, it cannot confirm it
  • A receipt is allocated only after the warehouse records it; a shipment in transit is a forecast, not stock
  • It does not create or change purchase orders

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Pre-order Allocation ↗

Questions and answers

What is put in front of the approver?
The allocation for one receipt: the ordered list of pre-orders it fills, any splits, and the slip notices for the ones it does not reach. They can reorder the list, exclude an order, or hold the notices.
What does each pre-order keep?
Each pre-order carries the receipt it was allocated to, the position it held, the hold release or the slip notice, the approver, and the time. An order that slips keeps its history across receipts.
Will it release or email anything by itself?
No. Releases and notices are proposals until a person approves them, and an approved item is applied one time. If the received quantity on a purchase order line changes after a proposal was built, that proposal is withdrawn and rebuilt.
Ask about Pre-order Allocation

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy