WooCommerce Order Routing with NetSuite — The Column That Turns Off Automatic Location Assignment
- NetSuite ships its own routing engine. Oracle documents that “the Automatic Location Assignment feature lets you configure NetSuite to assign fulfillment locations automatically to sales order lines” — per line, from rules an administrator sequences, not per order from code.
- Writing a location is an opt-out, not an instruction. Oracle states: “Select a location manually in the Location column. Doing this automatically checks the Do Not Auto Assign Location box.” An item’s Preferred Location does the same thing, so the flag can be set from two directions and no error is raised either way.
- The engine runs after the fact, not at order entry. Oracle documents that it “assigns locations when a sales order is approved” and then “assigns locations in the background”, and that it “only assigns locations if the sales order is approved and there is no payment hold on the sales order”.
- The best location depends on queue depth, not just stock. A location’s total shipping capacity is measured “by counting the number of open fulfillment requests for the location”, so a location drops out of contention when its work queue fills — a state no stock-level query can see.
Almost every guide to multi-warehouse order routing between a storefront and NetSuite describes the same architecture: the integration receives the order, queries stock per location, picks a warehouse, and writes that warehouse onto the sales order. NetSuite documents a feature that does this work itself, on a rule set that a fulfillment manager owns, evaluated per sales order line after approval. More importantly, it documents that writing a location manually checks a box named Do Not Auto Assign Location — so the standard architecture does not merely duplicate the engine, it switches the engine off, silently, one line at a time. This post specifies what the engine does, when it runs, what turns it off, and the decision table for when your integration should own routing anyway.
Contents
- Which system should own the routing decision?
- When does NetSuite assign locations, and what triggers it?
- Writing the Location column switches the engine off
- How the engine narrows candidate locations
- Shipping capacity is queue depth, not stock level
- Fulfillment requests and item fulfillments are different records
- A fulfillment request blocks sales order cancellation
- What WooCommerce can and cannot tell you about location
- When the integration should own routing anyway
- A pre-go-live checklist
Which system should own the routing decision?
NetSuite should own it in any account where the Automatic Location Assignment feature is available and the fulfillment rules are stable enough to write down. Oracle’s description is precise: the feature “lets you configure NetSuite to assign fulfillment locations automatically to sales order lines”. The unit of assignment is the line, not the order, which matters immediately — a two-line order can be split across two warehouses by the engine without the integration modelling split fulfillment at all.
The feature is enabled at Setup > Company > Enable Features, on the Transactions subtab under Shipping & Receiving. Oracle lists prerequisites before either fulfillment automation feature is switched on: “The Location feature is enabled”, “The Multi-Location Inventory feature is enabled”, “Inventory is associated with locations”, and — specific to this feature — “If you plan to use the Automatic Location Assignment feature, make sure you’ve checked the Perform Item Commitment After Transaction Entry box on the Accounting Preferences page.”
That last prerequisite is the tell. Item commitment happens after transaction entry, which means allocation is deliberately not resolved at the moment the order is written. An integration designed around a single atomic write at order-create time is designing against the grain of a platform that has already decided this work happens later.
When does NetSuite assign locations, and what triggers it?
Assignment runs on approval, asynchronously, and only when specific business events are configured. Oracle states plainly: “Usually, this feature assigns locations when a sales order is approved. After approval, NetSuite assigns locations in the background. Wait a bit, then check the assigned locations by viewing or editing the sales order.” The instruction to wait is the documentation conceding that this is an eventually-consistent process.
Two conditions gate it. Oracle documents that “automatic location assignment only assigns locations if the sales order is approved and there is no payment hold on the sales order”. An order sitting in a payment hold is not routed at all, which is correct behaviour and also a trap for any integration that polls for a location and treats its absence as a failure.
The triggers are configurable and default to nothing. Under Setup > Order Management > Setup Tasks > Advanced Order Management, Oracle documents that “each option under Automatic Location Assignment corresponds to a business event in NetSuite. You must select at least one event. If no events are selected, the automatic location assignment process will not be triggered and NetSuite will be unable to assign locations automatically.” The five available events are sales order approved, payment hold released, sales order changed, item fulfillment changed, and fulfillment request rejected — the last appearing only when the Fulfillment Request feature is enabled. A settings page with nothing ticked is a routing engine that never fires, and it reports no error.
Writing the Location column switches the engine off
This is the finding that reverses the standard integration design. Oracle documents, in the list of ways to stop automatic assignment on a line: “Select a location manually in the Location column. Doing this automatically checks the Do Not Auto Assign Location box.” The write is not a hint the engine will reconsider. It is the documented way to exclude the line from the engine permanently.
The same flag is set from a second direction. On the item record, Oracle documents that configuring a Preferred Location also checks Do Not Auto Assign Location, and that lines carrying such items are skipped rather than assigned. A SKU-to-home-warehouse mapping — an extremely common integration pattern, and one that looks like configuration rather than code — therefore removes those lines from the engine’s reach as thoroughly as writing the column does.
A line with a manually written location has a location, which is what a post-write verification check looks for. What it has lost is everything the engine would have applied afterwards — capacity gating, backorder rules, the radius and location-type filters, and re-evaluation when the order changes. The integration passes its own tests while the routing rules the operations team configured never execute.
One caveat stated honestly, because it decides your design: Oracle documents this behaviour for selecting a location in the Location column, in the context of the sales order form. Whether a write from an outside interface sets the same flag is an account-level question you should answer in a sandbox before go-live, not assume in either direction. The check is cheap — create an order through your integration with a location written, then read the Do Not Auto Assign Location field on the resulting line and see whether it came back checked. Section 10 puts that test in a checklist.
How the engine narrows candidate locations
The engine evaluates an ordered configuration and stops as soon as every line has a location. Oracle documents that a configuration is “a collection of rules and backorder rules that are evaluated in sequence to determine the ideal fulfillment location for each line in a sales order”, that “if a configuration has multiple rules, they are evaluated from top to bottom in the specified order in the sequence (called the evaluation order)”, and that “if all the lines in a sales order have a location after a particular rule has been evaluated, all subsequent rules in the sequence are skipped”. Rules can be scoped to specific line items using a transaction saved search as a filter, restricted by location type, by a set of named locations, or by radius from the shipping address.
Within a rule, Oracle documents the engine performing six steps in sequence to narrow the candidates.
| Step | What the engine does | What it means for an integration |
|---|---|---|
| 1 | Selects only locations that can ship to the region in which the shipping address is located | Region-to-location eligibility is NetSuite configuration, not integration logic |
| 2 | Selects only locations that have inventory | The stock check the integration was going to perform already happens here |
| 3 | Selects all locations that match the specified location types | Store, warehouse and third-party types are filtered by rule, not hard-coded |
| 4 | Selects locations within the specified radius around the shipping address | Distance routing needs no geocoding service in the integration |
| 5 | Selects locations based on the minimize fulfillment locations strategy | Split-shipment avoidance is a documented strategy, not custom code |
| 6 | Selects locations based on the optimal fulfillment location strategy | The tie-break rule is owned by operations and changes without a deploy |
Verdict: five of the six steps are things the standard integration architecture rebuilds in application code. Oracle names the default strategy as minimizing fulfillment locations and assigning the closest location. If the rules a business actually wants are expressible in that sequence, the integration’s correct contribution is to write a clean sales order and stay out of the Location column.
Rules can also serve as backorder rules: Oracle documents that “the rules in a configuration can be used as both ordinary rules and backorder rules”, evaluated in sequence after the ordinary rules when lines remain unassigned. Configurations are set per subsidiary, and one constraint is worth knowing before you build: “after you save the automatic location assignment configuration, you cannot change the subsidiary.”
Shipping capacity is queue depth, not stock level
A location can hold stock, sit closest to the customer, pass every rule filter, and still be excluded because its work queue is full. Oracle documents two separate capacity meters on a location, and both count fulfillment requests rather than units of inventory.
For daily capacity, “NetSuite measures the current number of shipping sales orders by counting the number of fulfillment requests created for the location”, where daily shipping capacity “refers to the maximum number of shipping sales orders that can be assigned to a location by automatic location assignment in one day (from 00:00 to 23:59)”. Once that ceiling is hit, Oracle states that “because the daily shipping capacity has been reached, automatic location assignment will no longer assign the location to sales order lines during the day”.
Total capacity works differently and is the more interesting one. It “represents the maximum number of orders allowed to accumulate in the work queue at the location”, and NetSuite “measures the shipping capacity by counting the number of open fulfillment requests for the location”. Oracle is explicit about the release condition: “when the total shipping capacity at a location is reached, NetSuite stops assigning fulfillment requests until at least one of the fulfillment requests is fulfilled.” Leaving the field blank means unrestricted capacity.
This is the mechanism that a stock-level routing query in an integration structurally cannot reproduce. Available quantity tells you whether a warehouse can ship the item; open fulfillment request count tells you whether it can ship it today. A store that routes purely on stock will keep loading its best-stocked location on a promotion day while a second warehouse with adequate stock stays idle. Getting the reading right matters more than the cadence you read at — the same point our analysis of why sync cadence is not what causes oversells makes about allocation generally.
One further piece of dynamic state: Oracle documents an Auto Loc. Assignment Suspended attribute on an item’s location list that temporarily prevents assignment to that location, and notes it can be checked by NetSuite automatically when a fulfillment request line is rejected. Warehouse-floor behaviour therefore feeds back into routing eligibility without anyone editing a rule.
Fulfillment requests and item fulfillments are different records
These are two records in sequence, and conflating them produces integration code that writes to the wrong object. Oracle describes the fulfillment request as “an intermediary step between the sales order and the fulfillment stage of the order fulfillment workflow” — “a request or demand to fulfill a sales order” that lets staff at a location “view fulfillment requests for their location, accept or reject the request, and process the request to fulfill the order”.
The item fulfillment is the record created from the fulfillment request, and the relationship is one-to-many: Oracle documents that you can create multiple item fulfillments from a single fulfillment request. For a shipping order the fulfillment type is Ship and the record created is an item fulfillment; for a pickup order the type is Store Pickup and the record is a store pickup fulfillment. Statuses move together but not identically — an item fulfillment starts at Picked, and the fulfillment request reaches Picked only when all its items have been picked, otherwise remaining In Progress until items are marked Shipped.
Fulfillment requests can be created manually after a sales order is saved and approved, or automatically when fulfillment request creation is configured as an automation process. Note the prerequisite chain: Oracle documents that “if you plan to use the Fulfillment Request feature, the Pick, Pack, and Ship feature must also be enabled”. An integration that expects fulfillment requests in an account without Pick, Pack, and Ship will find none, and nothing will explain why.
A fulfillment request blocks sales order cancellation
Oracle states the constraint in one sentence: “After a fulfillment request is created, the associated sales order can’t be canceled.” For a storefront integration this is not a footnote — it is the specification for your cancellation path.
A WooCommerce order can move to cancelled at any point a store admin decides, including well after the order reached NetSuite and a fulfillment request was raised against it. An integration that maps WooCommerce cancellation to a NetSuite sales order cancellation will therefore fail on exactly the orders that have progressed furthest, and it will fail after the customer has already been told the order is cancelled. The two systems then disagree in the most expensive direction: the storefront shows cancelled, the warehouse holds a live request to pick and ship.
The correct design treats cancellation as conditional on fulfillment state rather than as a state mirror. Before attempting a cancellation, check whether a fulfillment request exists for the order; when one does, the operation is a fulfillment-side workflow — reject or close the request through the fulfillment path — not a sales order cancellation, and the storefront status should reflect that the cancellation is pending rather than complete. Encoding that branch is cheap at design time and very expensive to retrofit after the first mis-shipped cancelled order.
What WooCommerce can and cannot tell you about location
WooCommerce core has no warehouse concept, so the storefront cannot be the source of a routing decision under any design. Stock in core is a single quantity per product or variation. The store-level Inventory settings documented by WooCommerce cover stock management on or off, hold stock for unpaid orders for a number of minutes, low stock and out of stock thresholds, notification toggles, out of stock visibility, and the stock display format. There is no location dimension anywhere in that set, and none on the product record.
Two consequences follow directly. First, the quantity a WooCommerce product carries is a single aggregate — whatever the integration chose to publish — and it cannot express “12 in the London warehouse, 0 in the Manchester store”. Deciding what that single number should represent when stock is spread across locations is a design decision that has to be made explicitly, because the default of summing everything oversells any item the nearest shippable location does not hold.
Second, the routing decision has to be recorded on the storefront side as a result rather than computed there. Writing the assigned location back onto the WooCommerce order as order meta is useful for support and for customer-facing dispatch messaging, and it is honest — it reflects a decision NetSuite made. Computing it there is not possible from core data. Which field a sync actually reads is a recurring source of silent wrongness in this stack; our write-up of the timestamp that never moves when stock moves covers a case where the field choice looks correct and returns an empty set on a busy day.
When the integration should own routing anyway
The engine is not always the right owner. It requires a feature set, it operates per subsidiary, and its rule vocabulary is fixed. The decision is mechanical.
| Dimension | Let the engine route | Integration routes |
|---|---|---|
| Feature availability | Location, Multi-Location Inventory and the feature itself are enabled | Any prerequisite missing and not being added |
| Rule shape | Expressible as region, inventory, location type, radius, consolidation, tie-break | Needs inputs NetSuite does not hold — carrier quotes, third-party stock, contractual allocation |
| Who changes the rules | Operations, in the UI, without a deploy | Engineering owns fulfillment policy by agreement |
| Capacity awareness | Wanted — daily and total queue ceilings apply | Not wanted, or enforced in an external system of record |
| Timing tolerance | Assignment after approval, in the background, is acceptable | The location must be known synchronously at order acknowledgement |
Verdict: the last row decides most real cases. If a customer-facing message at checkout must name the dispatching location, background assignment cannot supply it and the integration has to compute something. If the location is needed only by the warehouse, the engine wins on every dimension — and the honest hybrid is to let it route while the integration reads the assigned location back for messaging.
Where routing genuinely must sit in the integration, do it deliberately: set Do Not Auto Assign Location explicitly rather than as a side effect, so the next engineer reads an intention instead of an accident. Building either shape — engine-owned or integration-owned — against documented interfaces is what our NetSuite and WooCommerce integration work is for, and the wider set of decisions in this stack is collected in the NetSuite and WooCommerce guide library.
A pre-go-live checklist
Run this in a sandbox against your own account before any routing design is locked. Each item resolves a question this post could only answer from documentation.
- Confirm the Automatic Location Assignment feature is enabled under Transactions > Shipping & Receiving, and that Location and Multi-Location Inventory are on.
- Verify the Perform Item Commitment After Transaction Entry box is checked on the Accounting Preferences page.
- Open Advanced Order Management and record which business events are selected — an empty selection means assignment never runs.
- Create an order through the integration with the Location column written, then read Do Not Auto Assign Location on the resulting line to see whether the flag was set.
- Create the same order with the Location column empty, approve it, wait, and confirm a location appears on each line.
- Check every item the storefront sells for a Preferred Location, which excludes those lines from assignment.
- Record the daily and total shipping capacity values on each location, and confirm blank means unrestricted is the intended setting.
- Test an order held for payment and confirm your integration does not treat the missing location as an error.
- Edit a synced order’s quantity and confirm whether assignment is re-run, since Oracle requires Auto Assign Locations to be clicked again after such an edit.
- Attempt a cancellation on an order that already has a fulfillment request, and confirm your integration handles the refusal rather than retrying.
The ninth item is the one most likely to surprise a working integration. Oracle documents that “if you edit a sales order by changing the quantity of a line, changing the item on a line, or adding a new line, you must click the Auto Assign Locations button again to rerun the automatic location assignment process”. An integration that patches order lines after creation can therefore leave a location assigned against a quantity that no longer exists, unless the sales-order-changed event is among the configured triggers.
Get the working checklists
The runbooks and decision checklists from these guides, as printable PDFs — free in the SoftXone guide library.
References
- NetSuite Applications Suite — Automatic Location AssignmentOracle — the feature definition quoted above, the enable path under Transactions > Shipping & Receiving, and the note that a configured preferred location is set in the Location column.
- Assigning Locations Automatically in a Sales OrderOracle — source of the Do Not Auto Assign Location behaviour, the assign-on-approval and background-processing statements, and the requirement to rerun assignment after editing an order.
- Automatic Location Assignment RulesOracle — rule criteria, the evaluation order and skip behaviour, the six-step narrowing sequence, and backorder rules.
- Automatic Location Assignment ConfigurationsOracle — what a configuration contains, default configuration per subsidiary, and the statement that the subsidiary cannot be changed after saving.
- Configuring Locations for Automatic Location AssignmentOracle — daily and total shipping capacity, both measured by counting fulfillment requests, and the condition for a location to become available again.
- Managing Automation Settings for Automatic Location AssignmentOracle — the five business events, the requirement to select at least one, and the approved-and-no-payment-hold condition.
- Configuring Items for Automatic Location AssignmentOracle — Preferred Location checking Do Not Auto Assign Location, plus the Auto Loc. Assignment Allowed and Suspended attributes.
- Fulfillment RequestsOracle — the fulfillment request as an intermediary record, its relationship to item fulfillments, and the statement that the sales order cannot be canceled once one exists.
- Enabling Automation FeaturesOracle — the verbatim prerequisite list, including Perform Item Commitment After Transaction Entry and the Pick, Pack, and Ship requirement for Fulfillment Request.
- WooCommerce — Products SettingsWooCommerce — the complete core Inventory settings list, which contains no location or warehouse dimension.
Frequently asked questions
Does NetSuite route multi-warehouse orders without a custom integration?
Yes. The Automatic Location Assignment feature assigns fulfillment locations to sales order lines from rules configured in the interface. Three things must be true first: the Location and Multi-Location Inventory features are enabled, the Perform Item Commitment After Transaction Entry box is checked on the Accounting Preferences page, and at least one business event is selected under Advanced Order Management. All three default to off or empty, so an account nobody has configured shows no assignments and reports no error.
Why did a synced order never receive a fulfillment location?
Four documented causes are worth checking in order. No business event is selected, so the process never triggers. The order is not approved, or it carries a payment hold, and Oracle gates assignment on both. The line has Do Not Auto Assign Location checked, which happens automatically when a location is written into the Location column. Or the item carries a Preferred Location, which sets the same flag. None of these produce an error message.
Can a single order ship from more than one warehouse?
Yes. Assignment happens per sales order line, so a two-line order can resolve to two locations without the integration modelling split fulfillment itself. The default strategy minimises the number of fulfillment locations and assigns the closest, so consolidation is preferred where stock allows. Each location that ends up holding lines produces its own fulfillment request, and each fulfillment request can yield multiple item fulfillment records as stock is picked and shipped.
What happens if a customer cancels after the order reached NetSuite?
Oracle documents that once a fulfillment request has been created, the associated sales order cannot be canceled. A storefront cancellation therefore cannot be mirrored as a sales order cancellation on any order that has progressed to fulfillment. Check for an existing fulfillment request before attempting the cancellation, and when one exists, treat the operation as a fulfillment-side workflow while showing the customer a pending rather than completed cancellation.
Should the integration write the fulfillment location or leave the field empty?
Leave it empty unless the dispatching location must be known synchronously at checkout. Writing it checks Do Not Auto Assign Location, which removes the line from capacity gating, radius and location-type filters, backorder rules, and re-evaluation when the order changes. Where routing genuinely belongs in the integration, because it needs carrier quotes or third-party stock NetSuite does not hold, set that flag deliberately rather than acquiring it as a side effect.
Leave a Reply