This account uses NetSuite's modern Supply Allocation engine (not just the classic "commit what's on the shelf" logic). When a sales order is entered, NetSuite immediately promises inventory to it — and it's allowed to promise future inventory too: stock that hasn't arrived yet but is on an inbound purchase order, transfer order, or work order. It decides who gets what using allocation strategies (rulebooks), order priorities (1 = most important), and sales-channel reservations (e.g., a block of stock is fenced off for Amazon, and Amazon orders may only eat from that fence). Everything happens automatically at order entry, synchronously — there's no overnight batch allocation job.
true at runtime-2 (verified by test order)Bottom line: This is a NetSuite Supply Allocation instance (the successor to plain item commitment), configured to allocate as-soon-as-available, partial-quantity, closest-to-ship-date, from both on-hand and future (inbound) supply, with ATP-based promise dates, line-level order priority, and channel-fenced supply via Order Reservations. The account is a retail vertical demo/dev build ("Stairway for Retail") that contains six purpose-built demonstration scenarios exercising each allocation capability — which made the behavior easy to verify empirically.
Probed live via N/runtime.isFeatureInEffect (not guessed from UI):
| Feature | State | Meaning for allocation |
|---|---|---|
SUPPLYALLOCATION | TRUE | The modern allocation engine is the system of record. Adds quantityallocated, allocation strategies, allocation alerts. |
SALESCHANNELALLOCATION | TRUE | Supply can be fenced per sales channel; channels carry allocation priority. |
AVAILABLETOPROMISE | TRUE | Promise dates computed from cumulative supply/demand timeline. |
MULTILOCINVT | TRUE | Allocation is per-location (13 locations; nearly all demo supply sits in 03: Chicago DC, id 5). |
SUPPLYCHAINCONTROLTOWER / SUPPLYCHAINPREDICTEDRISKS | TRUE | Supply Chain Control Tower surfaces allocation exceptions ("Reallocate" alerts observed on lines). |
ORDERALLOCATION / AUTOLOCATIONASSIGNMENT | FALSE | NetSuite does not pick the fulfillment location automatically — the location is whatever is entered on the line. |
DEMANDPLANNING | FALSE | No demand-plan-driven allocation; item replenishment fields (MRP / Reorder Point) exist but no planning engine runs. |
INVENTORYSTATUS | FALSE | No status-based supply exclusion (e.g., "Quarantine" stock). The "Inspection" location (id 6) plays that role instead, with makeinventoryavailable = F. |
WMSSYSTEM / FULFILLMENTREQUEST / CROSSSUBSIDIARYFULFILLMENT | FALSE | No WMS or store-fulfillment layer sitting on top of allocation. |
Think of the warehouse as a bakery. This bakery promises cakes to customers the moment they order — including cakes still in the oven (inbound POs). It does not automatically decide which branch bakes your cake (no Automatic Location Assignment), and it doesn't forecast how many cakes to bake next month (no Demand Planning).
Extracted from the hidden preference fields on /app/setup/acctsetup.nl (Accounting Preferences → Order Management):
| Preference | Value | Effect |
|---|---|---|
NEWITEMCOMMITMENT | T | The new (Supply Allocation) commitment engine is active — this is the definitive marker that classic commitment has been superseded. |
DELAYEDTRIGGERCOMMITMENT | F | Commitment/allocation runs synchronously at order save — verified: my test order had quantitycommitted=5 the instant it was created. |
COMMITORDERSAFTERDECOMMITTING | T | When stock is freed (de-committed), other open orders are automatically re-committed. |
ENABLEINVENTORYALLOCATIONTRACKINGENABLEINVFUTURESUPPLYTRACKINGENABLEINVINSTOCKSUPPLYTRACKINGENABLEINVDEMANDSUPPLYTRACKING | T (all) | Full supply/demand pegging trails are being tracked, for both in-stock and future supply. |
FULFILLCOMMITTED ("Fulfill Based on Commitment") | ALLOW UNCOMMITTED | Warehouse can ship quantities even if not committed — allocation guides but does not hard-block fulfillment. |
PICKINGTICKETUNCOMMITTED | F | Picking tickets print committed lines only. |
DROPSHIPINCLUDECOMMITTED | T | Drop-ship PO quantity includes committed quantities. |
VALIDATE_LOT_AVAIL_QTY_AT_COMMIT | F | Lot-level availability not enforced at commit time. |
ALLOCATION_AUTO_FIX_DATA / ALLOCATION_WORK_QUEUE_THREAD_LIMIT | T / 25 | Background allocation data-repair enabled; work queue capped at 25 threads. |
From the orderallocationstrategy table (SuiteQL):
| ID | Name | Future supply? | Complete qty only? | Closest to ship date? | Uses ATP? | Allowed future order types |
|---|---|---|---|---|---|---|
| -2 | Predefined Available Allocation Strategy ← DEFAULT | Yes | No (partial OK) | Yes | Yes | InbShip, PurchOrd, TrnfrOrd, WorkOrd |
| -3 | Predefined Complete Allocation Strategy | No | Yes (all-or-nothing) | No | Yes | — |
| 2 | ASAA-Available-Reserved (custom) | Yes | No (partial OK) | No | Yes | InbShip, PurchOrd, TrnfrOrd, WorkOrd |
Observed usage across all 26,800+ SO lines: 8,240 lines carry the default strategy -2, 11 lines use the custom strategy 2 (the demo scenarios), and ~18,550 older/non-inventory lines carry none. Line-level orderpriority values 0–6 are actively used (15,077 lines at priority 0; scattered 1–6 on the demo orders). My unmodified test order was stamped with strategy -2 automatically — confirming it is the account default (also visible as defaultorderallocationstrategy: "-2" in the SO line UI payload).
A strategy is the rulebook NetSuite follows when handing out inventory. The default rulebook here says: "Give the order whatever you can, whenever you can — partial is fine, counting stock that's still on its way, and prefer supply that lands closest to the date the customer wants." The alternative rulebook (Complete Allocation) says "all-or-nothing", and the custom one is a variant used for reserved/channel scenarios.
| Sales Channel | ID | Allocation priority | Only use reservations as supply? |
|---|---|---|---|
| Retail Store | 1 | — | No |
| Web Store | 2 | — | No |
| Amazon | 3 | 2 | YES — fenced |
| Other Channels | 4 | 1 (highest) | No |
| Wholesale | 5 | — | No |
Four live Order Reservation transactions (type = OrdResv) exist, reserving supply at Chicago DC for specific channels — e.g., reservation #3 holds 10 units of NS-SA-Channel for Amazon, and reservations #4/#5 hold 25/50 units of NS-SA-EIA for Amazon/Wholesale. Because Amazon is flagged "only use reservation as supply," Amazon orders can consume only their fenced stock — they can't raid general inventory. Accounting Preferences also shows an Order Reservations approval-routing section and a Supply Change Order section (default status: Pending Approval), both part of the Supply Allocation suite.
Imagine roping off a section of the stockroom with a sign that says "AMAZON ONLY." Amazon orders shop only inside the rope; everyone else shops the rest of the room. "Other Channels" gets VIP treatment (priority 1) when inventory is scarce.
All 157 configured items (100%) use atpmethod = CUMULATIVE_ATP_WITH_LOOK_AHEAD. This means when NetSuite computes an expected ship date, it builds a running supply/demand timeline and is allowed to "look ahead": future inbound supply can cover earlier demand as long as no intermediate demand is shorted. Verified in practice: a test order for an out-of-stock item (all supply already allocated to other orders) got expectedshipdate = 10/7/2026 — pushed past the last inbound PO (9/28) because that PO's units were already spoken for.
ATP is the answer to "if you order now, when can we ship it?" — calculated from a calendar of everything arriving and everything already promised. This account uses the smartest of NetSuite's three ATP flavors.
I created three sales orders and one item fulfillment (all deleted afterward — zero residue) against the demo items, which live almost entirely at 03: Chicago DC (location 5):
| Test | Setup | Result | Conclusion |
|---|---|---|---|
| #1 — In-stock demand SO 63174 |
5 × NS-SA-Channel (30 available at Chicago DC) | Instantly: quantitycommitted=5, quantityallocated=5, backordered=0, ship date = same day, strategy auto-set to -2 |
Allocation is synchronous at order entry; default strategy applied without user input. |
| #2 — Zero available SO 63175 |
10 × NS-SA-ASAA-RES (0 available; 150 inbound on 2 POs — but 200 already allocated to SO007462) | allocated=0, backordered=10, ship date pushed to 10/7/2026, line flagged allocationalert = "Reallocate" |
Future supply is finite and first-come-first-served — once pegged to another order, it's gone. The engine raises a Reallocate exception instead of double-promising. |
| #3 — Custom strategy SO 63176 |
Same as #2 but explicitly using strategy 2 (ASAA-Available-Reserved) |
Identical result — still nothing to give | Strategy changes how supply is selected, but can't conjure supply that's already allocated. |
| #4 — Fulfillment IF 63178 |
Transformed test SO #1 → Item Fulfillment, shipped 5 units | Fulfillment saved & shipped cleanly; line went isfullyshipped=T |
Committed/allocated stock flows straight through to fulfillment; "Allow Uncommitted" preference means no hard commitment gate. |
Order SO007462 wants 250 units of NS-SA-ASAA-RES. On hand at Chicago DC: 50. Inbound POs: 50 (9/10) + 100 (9/28). Its line shows quantitycommitted = 50 (physical stock) but quantityallocated = 200 (stock + both inbound POs) and backordered = 200. That 50/200 split is the signature of Supply Allocation: commitment covers only what's on the shelf, while allocation additionally pegs future supply — 200 = 50 + 50 + 100 exactly. The remaining 50 units of unmet demand triggered the "Reallocate" alert. My test orders #2/#3 then proved that this pegging is exclusive: no other order could touch those inbound units.
The account contains six purpose-built items (all named NS-SA-*, memo "Demo - Supply Allocations") each exercising one capability — useful as a living reference:
| Item | Scenario | What it demonstrates |
|---|---|---|
| NS-SA-ASAA-RES | As-Soon-As-Available | Allocating on-hand + future PO supply to one large order (the 50/200 example above). |
| NS-SA-Fill Rate | Fill-rate / priority | Six competing orders with priorities 1–6 splitting 3 on-hand + 13 inbound; higher priority lines got allocated first (priority 1 → allocated 3; priority 5 → allocated 0). |
| NS-SA-Reallocate | Reallocation | Moving allocation between orders (one order allocated 100 incl. future; two others stripped to 0, priority 1 winning). |
| NS-SA-Channel | Channel fencing | Order Reservations per channel + "only use reservation as supply" on Amazon. |
| NS-SA-EIA | Earliest Item Availability | Reservation-backed supply consumed across channels with earliest-availability logic. |
| NS-SA-GP01 | Gross Profit | Allocation weighed against order profitability. |
scriptList search for allocation-related scripts returned zero. The logic is 100% native NetSuite.makeinventoryavailable = F, keeping its stock invisible to allocation. All other 12 locations expose their inventory.N/runtime.isFeatureInEffect server-side for ~35 candidate features. This is authoritative — it reflects what the engine actually enforces, not what the UI implies. Result: SUPPLYALLOCATION=T, SALESCHANNELALLOCATION=T, AVAILABLETOPROMISE=T, with location-assignment/demand-planning/WMS all off.N/config module was blocked in this session, so I loaded /app/setup/acctsetup.nl in a hidden iframe and read the actual form fields from the DOM — capturing NEWITEMCOMMITMENT=T, DELAYEDTRIGGERCOMMITMENT=F, FULFILLCOMMITTED=ALLOWUNCOMMITTED, the four allocation-tracking flags, and the Order Reservations / Supply Change Order approval sections.orderallocationstrategy (3 strategies with full rule flags), saleschannel (priorities + reservation fencing), item.atpmethod (100% cumulative-ATP-with-look-ahead), location.makeinventoryavailable, per-location balances in inventoryitemlocations, and line-level quantitycommitted / quantityallocated / quantitybackordered / orderpriority / allocationalert / orderallocationstrategy across 26,800+ SO lines, plus all OrdResv transactions and inbound POs for the demo items.quantityallocated (200) = on-hand 50 + inbound PO 50 + inbound PO 100 — an exact match, confirming the future-supply interpretation rather than coincidence.ASAA-Available-Reserved differs from the default only in disabling "closest to ship date" selection — worth documenting internally so users know when to pick it.