Lot-numbered items + Supply Allocation + NetSuite WMS: how are you keeping committed lots committed?
I’m working with a distributor that also does light manufacturing and holds order-specific (decorated or customised) stock. Everything is lot-tracked, and fulfilment runs on NetSuite WMS. We keep hitting the same family of allocation and commitment problems. I’d like to hear how others have solved them, or decided to live with them.
Setup
- Features ON: Supply Allocation, Sales Channel Allocation, WMS, Lot Tracking, Advanced Bin/Numbered Inventory, Work Orders, Assemblies, MRP, ATP, Outsourced Manufacturing.
- Features OFF: Inventory Status.
- “Perform Supply Allocation After Transaction Entry, Update or Delete”: checked.
- Default allocation strategy: Allocate As Soon As Available, Available Quantity, Reserved (not Firm). Future inventory (PO/WO/TO/inbound shipment) counts as supply. “Commitment Confirmed Stops Allocation on Order Line” is unchecked.
- Order Management: “Automatically set to firm Committed Quantities in a Wave” is unchecked, and “Fulfill Based on Commitment” is Allow Uncommitted.
- Manufacturing: “Manufacturing Issue Based on Commitment” is Allow Uncommitted.
Symptoms
- Wave lot collisions. A released wave’s pick recommendation (FEFO) chooses a lot that is already fully committed to a different order. Fulfilment then fails with “Inventory numbers are not available [On Hand:N, Committed:N+1]”.
- The allocator re-commits drained lots. Drop a bad lot assignment and let NetSuite re-commit, and it often picks the same lot again. Lot-level quantity available doesn’t seem to net off what other orders have committed against that lot. Oracle’s docs admit that location-level and lot-level commitment drift apart when commits happen without a lot, and that partial fulfilments keep them drifting.
- The Order Allocation Schedule steals from released waves. When it ran, it re-sourced stock out from under orders already being picked, so we disabled it.
- Firm protects, but only lines that actually get firmed. We tested this in sandbox. Entering, editing or receiving against a competing order never took committed stock from an existing line; only an Allocate Orders / allocation-schedule pass did. In that pass, an unfirmed committed line lost 9 of its 10 units to a higher-priority order. A firmed line isn’t even offered as a candidate, even with “Select All Orders”. That held with “Commitment Confirmed Stops Allocation on Order Line” left unchecked on the strategy. So our exposure is every committed-but-unfirmed line, including waved ones, since the auto-firm-in-wave preference is off. Oracle also documents that the Reallocate Order Item tool can override Commitment Confirmed, which we haven’t tested.
- We can’t reserve order-specific stock. Customised stock is identified by naming its lot after the order, but NetSuite treats a lot name as meaningless and counts that stock as free. Blocked or non-pickable bins stop picking but not allocation. Inventory Status would help, but it is account-wide, effectively irreversible once used, and can’t tie stock to a specific order anyway.
- Work orders compete with sales orders. WO component demand and SO demand compete for the same lots. RF assembly builds fail with “You only have N available” when a staged lot has been partly soft-committed to something else.
- Waves are frozen snapshots. Pick tasks are generated from the commitment as it stood when the wave was built. Re-pinning a lot on the order afterwards doesn’t reach the wave. Decommitting after release strands the picker on stock NetSuite then refuses to fulfil.
What we’ve built so far
- A scheduled, lot-aware allocation pass that pins specific lots and firms them.
- A gate that won’t let an order into a wave until its lots are pinned.
- A custom “true available” report, because native Available overstates what is committable.
- Allocate-and-firm on release for WOs and TOs.
- The native allocation schedule, switched off.
It works, but it’s a lot of custom machinery around a native engine we don’t fully trust.
Questions
- Is anyone running Supply Allocation with lot-numbered items and NetSuite WMS without these collisions? What made the difference?
- In our test, firmed lines were protected even with “Commitment Confirmed Stops Allocation on Order Line” unchecked. What does that box actually add? Is it about future-supply re-dating rather than on-hand reallocation? And do you firm on commit, firm on wave release (via the auto-firm preference or a script), or leave lines reallocatable on purpose?
- How do you reserve stock for one specific order without Inventory Status? A dedicated non-available location, a custom reservation record, something else?
- How do you stop WMS recommending a lot that’s committed to another order? A wave-criteria filter, a pick-task script, or a process rule?
- Any real-world experience with Oracle’s FEFO Lot Assignments SuiteApp, or with RF-SMART, in solving this rather than just moving it?
- How do you sequence WO component demand against SO demand when they draw on the same lots?
- Did you end up turning off automatic commitment entirely and running one controlled committer? Would you do it again?
Replies here or DMs both welcome. I’m happy to share what we’ve learned in return.
The first gap I’d investigate is that real-time Supply Allocation is still enabled. Turning off the allocation schedule leaves another allocation path active alongside your custom committer.
I’d focus on three things: who can change commitments, which orders are eligible for each lot, and whether WMS enforces those same reservations.
On your checkbox question, Oracle documents “Commitment Confirmed Stops Allocation on Order Line” as preventing both new allocations and reallocations on confirmed lines, in real-time and batch processing. Its documented scope extends beyond future-supply dates. Your test establishes protection in the batch path you exercised; I’d also test receipts, partial commitments, and subsequent quantity changes. Because the checkbox stops new allocations too, partially committed lines need a deliberate process for allocating the remaining backorder. Reallocate Order Item remains an explicit override.
Here’s the acceptance test I’d use:
• Lot A: 10 units, earliest expiry, customised for SO-100.
• Lot B: 10 units, interchangeable stock.
• SO-100 needs 10; SO-200 needs 4; WO-300 needs 6.
The expected result is SO-100 → A:10, SO-200 → B:4, WO-300 → B:6. Lot A must be excluded from SO-200’s eligible supply before FEFO sorting happens. If SO-100 ships four units, A’s remaining six still belong to SO-100; they must not become available to another order.
That distinction is important: FEFO determines the preferred lot among eligible lots. It doesn’t establish ownership of customised stock.
Without Inventory Status, I’d make the order-to-lot relationship explicit in your reservation records and enforce it in both allocation and mobile lot selection. A reservation record alone won’t constrain native allocation or a picker’s alternative lot scan. Concurrent reservation attempts also need to be serialised; a correct availability report can still become stale between reading and committing.
For released waves, I’d retain your pin-before-wave gate and test the native auto-firm preference. Any lot change after release should go through a controlled pick-reversal/release process. Oracle explicitly warns that changing commitments does not update existing wave and pick-task quantities.
For WO/SO competition, I’d put both into the same reservation queue with an agreed priority rule. For example, protect released picks and production already staged, then allocate remaining stock by required date and business priority. I’d also sandbox “Limit to Committed” for fulfillment and manufacturing issue; those are quantity controls, so lot validation still needs to remain.
The FEFO SuiteApp is worth testing as a replacement for the lot-assignment portion of your process. Oracle documents a separation between its Commit and Assign mode and Supply Allocation for the same lot-item/location pool, and confirmed lines are skipped. I’d avoid adding it as another competing committer.
For RF-SMART, I’d ask for a sandbox demonstration using the exact example above, including simultaneous releases and a partial pick. The deciding question is whether it enforces the same lot reservations across SOs, WOs, and picking.
Given your existing machinery, I’d test one controlled commitment process before adding more scripts. The biggest remaining risk appears to be another allocation or picking path making decisions outside that process.
