How to Pack Multiple Waves in NetSuite Ship Central
Learn how to overcome Sales Order packing concurrency limitations in NetSuite Ship Central, improving overall warehouse efficiency.

On this page
A common warehouse scenario: a single Sales Order releases into three waves, each producing its own Item Fulfillment in Picked status. User A opens wave 1 in Ship Central and begins packing. The Sales Order flips to Started pack status, and User B, standing at the next packing station with wave 2 ready to go, hits a wall. They can't open the same Sales Order to pack the second fulfillment concurrently. Every other user in the pack area can work simultaneously, but the moment two packers land on the same Sales Order, the second operator is locked out.
This is a real concurrency limitation in NetSuite Ship Central, and the fix requires understanding how the app scopes its packing session.
Why the Lockout Happens
Ship Central organizes the pack-and-ship workflow around the Sales Order as the parent packing record, not around the individual Item Fulfillment. When a user opens a Sales Order in the app, Ship Central acquires ownership of that Sales Order's packing session. The ownership stays in place until the user finishes, cancels, or uses Save & Close to release it.
The lock is at the Sales Order level. Multiple users can pack concurrently only when each user is working a different Sales Order. The moment two users target the same Sales Order, even if they intend to pack different waves or different Item Fulfillments, Ship Central serializes the access. The Save & Close button allows sequential work, but never true parallel work.
The control here is the Sales Order-level session lock, not the Item Fulfillment or the wave. Until NetSuite scopes the lock to the child fulfillment, true multi-user packing on a single order is blocked.
This is not a bug in the wave configuration. The setting Create Item Fulfillment at Locations Using Warehouse Management: Per Order in a Wave is correct for splitting a Sales Order across multiple waves. The Manually pack orders? = Y and Allow packing of partially picked orders = Active flags together correctly produce separate, independently packable Item Fulfillment records. The bottleneck is purely in how Ship Central binds the pack session to the parent Sales Order.
What the System Will and Won't Let You Do
| Behavior | Works? | Why |
|---|---|---|
| Two users, two different Sales Orders, simultaneously | Yes | Each user holds a separate Sales Order session |
| Two users, same Sales Order, two different waves/IFs | No | Session lock is at Sales Order level |
One user Save & Close, then another user opens | Yes (sequential) | Lock releases on Save & Close |
| Direct packing on the Item Fulfillment record in NetSuite UI | Yes, but loses the mobile experience | Bypasses Ship Central entirely |
The third option is the workaround most teams discover first. If User A is packing wave 1 in Ship Central, User B can open the second Item Fulfillment record directly in NetSuite and pack it from the desktop or from a custom mobile process. Cartons, scan validation, and shipping label generation work, but you lose the guided kiosk workflow and the audit trail that Ship Central creates natively. The NetSuite Connector documentation describes the same lifecycle for these fulfillments, noting that a sales order can produce multiple item fulfillments that each progress through Picked to Packed to Shipped independently, see Handling Partially Fulfilled Orders in NetSuite Connector.
Configuration Options to Check First
Before reaching for a custom process, walk through these three settings. The third one is the one most teams miss.
- Setup > Warehouse Management > Ship Central Preferences > Packing, confirm
Allow packing of partially picked ordersisActive. Without this, you can't even start a wave until all waves are picked, and the concurrency question becomes moot. - Setup > Accounting > Accounting Preferences > Order Management, review
Create Item Fulfillment at Locations Using Warehouse Management. Set toPer Order in a Waveto keep the multi-IF split. Setting it toPer Waveconsolidates everything and removes the parallel opportunity entirely. The Warehouse Management Guide explains that thePer Orderpreference "consolidates the line items for each order in a released wave", see Creating Wave Transactions for the full behavior matrix. - Custom record
Custom Record (Ship Central Configuration), fieldcustrecord_sc_pack_session_scope, on older Ship Central SuiteApp versions, this field determines whether the pack session binds to the Sales Order or to the Item Fulfillment. Setting it toItem Fulfillmentenables parallel packing on the same Sales Order. The field is not exposed in every account; verify availability in your installed SuiteApp version under Customization > Lists, Records, & Fields > Record Types before relying on it.
Workaround: SCM Mobile Custom Process for Parallel Packing
If the session-scope field isn't available in your environment, the most stable workaround is a custom SCM Mobile process that opens directly on the Item Fulfillment record. The packer scans or selects an Item Fulfillment (not a Sales Order) and the process drives carton creation, scan validation, and label generation on that single fulfillment. Because the process never opens the parent Sales Order in Ship Central, no session lock is acquired.
Below is a minimal SuiteScript 2.1 user-event script that adds a custom button to the Item Fulfillment record when it is in Picked status and at least one line remains unpacked. The button launches the SCM Mobile process on that fulfillment.
/**
* @NApiVersion 2.1
* @NScriptType UserEventScript
* @NModuleScope SameAccount
*/
define(['N/record', 'N/runtime', 'N/ui/serverWidget'],
function (record, runtime, ui) {
function beforeLoad(ctx) {
if (ctx.type !== ctx.UserEventType.VIEW) return;
var rec = ctx.newRecord;
if (rec.type !== record.Type.ITEM_FULFILLMENT) return;
if (rec.getValue('status') !== 'Picked') return;
var remaining = 0;
var lineCount = rec.getLineCount({ sublistId: 'item' });
for (var i = 0; i < lineCount; i++) {
var packed = rec.getSublistValue({
sublistId: 'item', fieldId: 'quantitypacked', line: i
}) || 0;
var fulfilled = rec.getSublistValue({
sublistId: 'item', fieldId: 'quantity', line: i
}) || 0;
if (packed < fulfilled) { remaining++; }
}
if (remaining === 0) return;
var form = ctx.form;
form.addButton({
id: 'custpage_sc_parallel_pack',
label: 'Pack in SCM Mobile',
functionName: 'scParallelPack("' + rec.id + '")'
});
form.clientScriptModulePath = './sc_parallel_pack_cs.js';
}
return { beforeLoad: beforeLoad };
});Pair this with a client script that calls window.open on the SCM Mobile deep link bound to the Item Fulfillment internal ID. The record type internal ID is itemfulfillment; the tranid field holds the human-readable fulfillment number that the mobile process uses for scanning. When troubleshooting, the System Notes Guide is the fastest way to confirm which user holds the active pack session and when the session was last released.
When the Native Path Is the Right Answer
If your operation only sees the lockout a few times per week, the simplest fix is operational, not technical. Stagger the packers: assign wave 1 to User A, then Save & Close after each carton so User B can grab the next wave. The throughput cost is small if your average wave takes under five minutes to pack, and you keep the native audit trail intact. From an audit perspective, this is the cleanest path because every carton, scan, and label is recorded inside Ship Central's session log, which your auditors can pull directly.
If the lockout happens every hour, the session-scope field or a custom SCM Mobile process is the better investment. The parallel packing throughput recovers, and the carton-level data still flows back to the Item Fulfillment record. The only loss is the unified Sales Order-level session view in Ship Central, a trade most high-volume warehouses accept.
Before locking in either path, confirm your Ship Central SuiteApp version under Setup > SuiteApps > Manage Installed SuiteApps. The session-scope field and the SCM Mobile framework were expanded in the 2025.x release line; accounts on older versions may need a SuiteApp update before either approach works cleanly.


