Skip to main content

Browse allocations & pin stock to bins

An allocation is the record that ties a quantity of a product to a demand document — a sales-order line, a warehouse transfer, or a manufacturing order — and tracks that commitment through its lifecycle. The allocations list is the read surface for every allocation across your tenant, in every status. This guide covers browsing and filtering that list, reading a single allocation's detail, exporting, drilling into per-product and per-supplier analysis, and pinning an allocation's stock to a specific bin.

Before you begin

  • Open the list at Inventory → Allocations.
  • Anyone with allocation-list access can browse, filter, read detail, and export. This page is read-only — allocations are created and changed by the flows that own them (approving and fulfilling sales orders, receiving purchase orders, and working the backorder queue).
  • Pinning stock to a bin (a hard bin reservation) requires the Manage warehouse locations permission. It's currently an API-only capability with no dedicated screen — see Pin an allocation's stock to a bin below.
  • For what each status means, see the allocations reference. For the model behind the list, see Allocations & backorders.

Browse the allocations list

The list opens on the Active scope — allocations in Planned, Awaiting Receipt, or Allocated status. Fulfilled and Cancelled rows are hidden until you widen the status filter.

Read the metric cards

Five clickable cards sit above the table, one per status:

CardSubtitleCounts allocations in status
AllocatedOn-hand committedOn-hand stock committed to a line
PlannedAwaiting stockBackordered, no PO coverage yet
Awaiting ReceiptCovered by POBackordered, covered by an inbound PO
FulfilledShipped outConsumed by a shipment
CancelledNo longer neededReleased and closed

Click a card to quick-filter the table to that status; click the same card again to clear it. The active card is highlighted.

The card counts are global totals, not your filtered view

Each card shows the tenant-wide count for that status. They don't narrow to match your active search, warehouse, supplier, or advanced filters — they're a fixed at-a-glance picture of the whole allocation population. The table below the cards is what reflects your filters.

Filter, search, and save views

The list is built on the standard datatable toolbar, so it carries the same filtering, saved views, and column controls as the rest of the app.

  • Search by allocation ID, product SKU, product name, or Source — the source search matches the linked sales-order number and warehouse-transfer number, so typing an order or transfer reference surfaces its allocations.
  • Status filter — pick All, Active (P+A+AR), or a single status. Active is the default.
  • Warehouse and Supplier dropdowns narrow to one warehouse or one supplier.
  • Advanced filters build a filter tree over allocation, product, warehouse, and supplier fields. Any advanced-filter condition on status replaces the metric-card quick filter.
  • Saved views capture a filter-plus-column layout you can reopen in one click, and the Columns selector chooses which columns show.

Read the columns

ColumnShowsDefault
IDAllocation IDShown
SKUProduct SKU (links to the product)Shown
Product NameProduct nameShown
WarehouseWarehouse holding the commitmentShown
QtyQuantity committedShown
StatusLifecycle status chipShown
SourceThe linked demand document, with a tooltip naming the exact link type and line IDShown
SupplierSupplier on the allocation (Planned / Awaiting Receipt rows)Hidden
PriorityRelease priority within its poolShown
PO LineCovering purchase-order line IDHidden
CreatedWhen the allocation was createdShown
Fulfilled AtWhen it was consumed by a shipmentHidden
Cancelled AtWhen it was releasedHidden

The Source cell links straight to the sales order, transfer, or manufacturing order it belongs to. Hover it to see the underlying polymorphic reference — for example Sales Order Line ID 55347 — which support staff use to identify the exact linked record.

View an allocation's detail

Click a row's View Allocation action (or open /inventory/allocations/{id}) to read a single allocation. The detail page has two tabs and exposes no lifecycle actions — state changes happen through the sales-order, purchase-order, and backorder-queue flows.

Details tab shows the core fields: ID, product (linked by SKU), warehouse, status, priority, created date, the committed Quantity, the Source Document link (with the same link-type-and-ID tooltip as the list), and the supplier. Three cards appear only when they apply:

  • Fulfillment — the fulfilled date, shown once the allocation has been consumed by a shipment.
  • Cancellation — the cancelled date, shown once the allocation has been released.
  • PO Coverage — the covering PO Line ID and whether the coverage is tight, shown when the allocation is covered by a purchase-order line. Tight coverage means the covering PO line is committed exactly to this allocation. See Allocations & backorders for how coverage is assigned.

Activity tab reads the allocation's activity log as a timeline — each entry names the event (created, updated, deleted), who caused it, and when. If nothing has been logged, it shows an empty state.

Opening an allocation that no longer exists

If the allocation ID can't be found, the page shows an error alert with a Go Back button rather than an empty shell.

Export allocations

Export the current list to a spreadsheet for offline analysis or sharing.

  1. Click Export above the table.
  2. Choose a formatXLSX or CSV.
  3. Confirm the scope. The default exports every allocation matching your current filters.
  4. Run the export. The file downloads as allocations-<timestamp>.<format>.

The export carries these columns: ID, SKU, Product Name, Warehouse, Quantity, Status, Source Type, Source ID, Supplier, Priority, PO Line ID, Created At, Fulfilled At, and Cancelled At.

The backorder queue has its own export

This export is the all-status allocations list. The backorder queue has a separate export with its own columns and scope options (including a selected-rows scope). If a selected-rows export is ever requested with no rows checked, it falls back to exporting the full filtered set.

Drill into product and supplier analysis

The backorder analysis views live on the allocation pipeline page (Inventory → Allocation Pipeline) alongside the backorder queue. Three tabs turn the flat queue into focused, drillable analysis:

  • Product Analysis — active backorders for one product, in release order, each with a coverage bar showing how much of the backordered quantity an inbound PO covers (and whether that coverage is tight). From here you reorder a backorder's priority, change its PO coverage, and jump to the supplier.
  • Supplier Analysis — the same active backorders grouped by supplier, so you can see everything one supplier owes you at once.
  • Breakdown — active backorders rolled up by supplier, product, and month.

The tabs are deep-linkable: the active tab lives in the URL (?tab=product-analysis), and the selected product or supplier rides along as product_id or supplier_id, so a link restores the exact view on load. To cross-drill, click the chart-line icon next to a SKU or supplier — it jumps you from a product to its supplier's analysis, or from a supplier to a product's, carrying the context across.

Pin an allocation's stock to a bin

Pinning is a hard bin reservation: it ties an allocation's stock to a specific warehouse bin (its warehouse_location_id) so the pick-list builder always picks that order from that bin instead of auto-picking in warehouse pick order.

Pinning is currently API-only (SKU-8191)

There is no dedicated screen for pinning yet — the capability is exposed only through the allocation's pin-bin endpoint (guarded by the Manage warehouse locations permission). A UI for it's tracked under SKU-8191. The rules and rejection messages below describe what that endpoint enforces.

A bin can only hold a reservation when all three of these are true:

  • The bin belongs to the allocation's warehouse. You can't pin to a bin in a different warehouse.
  • The bin is live — not deprecated.
  • The bin holds enough on-hand stock to cover the allocation's quantity.

If any condition fails, the reservation is rejected with a 422 and a clear message — for example "Bin A-01 holds 3 but the reservation needs 5." or "The bin must belong to the allocation's warehouse." — and nothing is pinned. Fix the bin choice (or move stock into the bin with a location transfer) and try again.

Pinning steers the pick list, not the low-level auto-consumption

A pin is honoured through the pick-list → fulfillment path — the pinned bin becomes the pick line for that order. The low-level auto-consumption resolver that decides which bin a movement draws from is intentionally not bin-pinned, to avoid a class of warehouse-pool deadlock. In practice this means a pin controls how a picked, fulfilled order sources its stock; it doesn't repoint every background consumption for the product.

Next steps

Last verified: