Adding an On Order column to NetSuite purchase orders sounds like a simple form customization, but the important question is what “on order” should mean. It could refer to the quantity on the current purchase order, the total quantity open across all purchase orders, or the quantity expected from a specific vendor or location.
For most purchasing teams, the most useful definition is the open quantity expected for the item, calculated from approved or partially received purchase orders and reduced as item receipts are posted. That value is dynamic, so adding a permanently accurate column to a NetSuite Purchase Order requires more than dragging a field onto a form.
The reliable way to add an On Order column to NetSuite purchase orders is to define the calculation first, then choose between a saved search, a custom transaction line field, or SuiteScript 2.1. A saved search is best for reviewing open purchase-order supply, while a custom column populated by SuiteScript is the better choice when the value must appear directly on the purchase order form or PDF. Native form customization alone is not enough to calculate a live, cross-transaction On Order quantity.
What should “On Order” mean in NetSuite?
Before configuring NetSuite, we recommend writing the business definition in one sentence. This avoids creating a column that looks useful but measures the wrong quantity.
A practical definition is:
> On Order = the remaining quantity on relevant open purchase order lines for the same item, subject to the required subsidiary, location, vendor, status, and expected receipt rules.
That calculation has several moving parts:
Ordered quantity, taken from the purchase order line.
Received quantity, taken from item receipts or the related transaction status.
Remaining quantity, calculated as ordered quantity minus received quantity.
Transaction status, which determines whether the PO is still supplying inventory.
Location and subsidiary, which prevent supply from one inventory pool being shown against another.
Vendor or currency filters, if the business wants a supplier-specific view.
For example, a purchase order line for 100 units with 40 units received should contribute 60 units to the open On Order total. If the purchase order is closed, canceled, or fully received, it should contribute zero.
This is different from the quantity on the current PO line. A line-level quantity of 100 tells the buyer what this transaction requests. An aggregate On Order value tells the buyer how much supply is already expected from all relevant open POs.
NetSuite also displays related inventory concepts such as Available, Committed, Back Ordered, and On Hand. These fields are not interchangeable. The correct calculation depends on whether the goal is purchasing visibility, inventory planning, fulfillment, or a printed vendor document.
Why a standard custom column does not provide a live total
A NetSuite custom transaction column can display a value on a purchase order, but the field itself does not automatically calculate a total across other purchase orders.
A custom column can generally do one of three things:
Store a manually entered value.
Display a value sourced from a related record or item field.
Receive a value populated by automation, such as a workflow or script.
The third option is required when the column must reflect changing transaction data. An item’s open purchase-order quantity changes when someone creates another PO, edits an existing PO, receives inventory, closes a line, changes the location, or updates the transaction status.
That timing issue is the main reason a simple sourced field is not sufficient. A field sourced from the item record might show a current item-level value, but it does not necessarily reproduce the exact business definition required for a particular purchase order. It may also fail to respect the PO’s subsidiary, location, vendor, or transaction-date context.
A live search result and a stored transaction value are also different things:
A saved search calculates results when the search runs.
A stored custom column shows the value saved on the transaction.
A scripted field can calculate or refresh the stored value at selected events.
A workflow can set values under defined conditions, but it is not ideal for complex aggregate calculations.
This distinction should guide the design before anyone modifies the purchase order form.
Which method is best for an On Order column in NetSuite?
The best method depends on where the buyer needs the information and how current it must be.
| Requirement | Best-fit method | Why |
|---|---|---|
| Review total open supply by item | Transaction saved search | Dynamic results without storing values on every PO |
| Show a related item value on the PO form | Sourced custom column | Fast configuration for simple, non-aggregated data |
| Print an On Order value on each PO | Custom column plus automation | Supports transaction and PDF presentation |
| Apply location, subsidiary, and status logic | SuiteScript 2.1 or carefully designed search | Provides stronger control over filters and calculations |
| Alert buyers when open supply exceeds a threshold | Saved search alert or workflow | Better suited to exception management than document display |
| Give buyers an interactive supply view | Workbook or dashboard | Allows grouping, filtering, and drill-down |
Our general recommendation is to avoid putting a dynamic aggregate on the printed purchase order unless there is a clear operational reason. A vendor-facing PO should primarily communicate what that vendor must supply. A purchasing dashboard or saved search is normally a better place to show total open supply across all vendors.
If the column is needed for an internal approval form, buyer review, or customized PDF, a scripted custom column is appropriate.
How to add an On Order column to NetSuite purchase orders
The implementation should follow a defined sequence. The exact menu labels can vary slightly based on account configuration, permissions, and NetSuite release behavior, but the design principles remain consistent.
1. Define the calculation and scope
Start by deciding which transactions contribute to On Order.
Document the answers to these questions:
Should pending approval purchase orders count?
Should only approved POs count?
Should partially received lines count for their remaining quantity?
Should closed lines be excluded?
Should drop-ship or special-order lines be excluded?
Should transfer orders or work orders contribute to supply?
Should the calculation be item-wide or location-specific?
Should it be limited to the current vendor?
Should it respect a subsidiary?
Should expected receipt dates affect the result?
A common purchasing definition includes approved purchase orders that are not fully received or closed. It excludes canceled transactions and removes quantities as item receipts are posted.
Do not begin with the column placement. Begin with this logic, because a visually correct column can still produce misleading purchasing decisions.
2. Create the custom transaction line field
If the value must appear on purchase order lines, create a custom transaction line field, not a body field.
A line field is appropriate because each PO line has its own:
Item
Quantity
Location
Units
Vendor context
Expected receipt date
Remaining quantity
Use a clear label such as On Order Quantity or Open Supply Quantity. The field should be a numeric field with suitable decimal precision for the item types used in the account.
Important field settings include:
Apply the field to purchase orders.
Set the field to appear on the required custom forms.
Decide whether it should display on printed and emailed transactions.
Make it read-only if automation owns the value.
Add a help description that defines the calculation.
Consider whether users should see the field only internally.
The field description matters. “On Order” is ambiguous, while “Open quantity on approved purchase orders for this item and location, excluding the current PO” gives users a meaningful definition.
3. Build a transaction saved search for validation
Before automating the column, build a saved search that calculates or exposes the expected result. This provides a testing baseline.
A purchase order line search should normally filter for:
Main Line = No
Item lines only
Relevant transaction type
Appropriate purchase order statuses
Non-closed lines
Non-zero remaining quantities
Required subsidiary
Required location
Optional vendor
Optional item category
The search should expose fields such as:
Purchase order number
Vendor
Item
Location
Quantity
Quantity received
Quantity billed, if relevant to the process
Expected receipt date
Transaction status
Remaining quantity
A key design issue is avoiding duplicate totals. Transaction searches can return multiple rows when a purchase order has related item receipts, fulfillments, or other joined records. Summing the wrong result set can overstate supply.
For that reason, validate the search against known examples:
A new PO with no receipts
A partially received PO
A fully received PO
A closed PO line
Multiple open POs for the same item
The same item at different locations
The same item across subsidiaries
The saved search is not only a reporting tool. It is the control calculation used to confirm that the scripted or sourced column behaves correctly.
4. Decide whether the current PO should be included
This is one of the most important details in the design.
Suppose a buyer is editing a purchase order for 50 units and the item already has 200 units open on other POs. There are two valid values:
Existing On Order: 200 units, excluding the current PO.
Total On Order After This PO: 250 units, including the current PO.
These values answer different questions. “How much supply already exists?” requires excluding the current transaction. “What will total open supply become if we approve this PO?” requires including it.
If SuiteScript populates the line field during `beforeLoad`, the current transaction may not yet be saved. A search for existing POs will generally exclude the unsaved record, which is useful for showing existing supply but not for showing the post-save total.
If the requirement is to include the current PO, the script must add the current line quantity, account for edits to existing lines, and avoid double counting when the transaction is being edited. This is a common source of inaccurate totals.
5. Populate the column with SuiteScript 2.1 when necessary
SuiteScript 2.1 is the most flexible option when the column needs to reflect cross-transaction logic.
A typical implementation uses a User Event script or a Client Script, depending on the required behavior:
Before Load can display values when the PO opens, but it does not save the values automatically.
Before Submit can calculate and store values before the PO is saved.
After Submit can update related records or trigger a separate refresh process.
Client Script can provide interactive behavior while a user edits the form, but it cannot replace server-side validation.
Scheduled or Map/Reduce processing is better when many purchase orders must be recalculated in bulk.
The script should use efficient searches and avoid running one search per line when a purchase order contains many lines. A better pattern is to collect the item and location combinations first, run a grouped search, and map the results back to the PO lines.
The calculation should also define how it handles:
Multi-location inventory
Multi-subsidiary accounts
Units of measure
Lot-numbered or serialized items
Matrix items
Non-inventory items
Service items
Drop-ship lines
Special-order lines
Closed or canceled POs
For example, the quantity on a purchase order may be expressed in cases while inventory is tracked in eaches. The script must use NetSuite’s unit conversion rules or a consistent base unit. Otherwise, the displayed On Order amount will look plausible but remain mathematically wrong.
6. Add the field to the correct form and PDF
After the field is populated, place it on the appropriate purchase order form.
In NetSuite, a field can be available but still invisible because it is not included on the active custom form. Check both the Screen and Print settings. If the value must appear on a PDF, confirm that the Advanced PDF/HTML template references the field’s internal ID.
The PDF template may require a line-level reference similar to the transaction line field used in the form. The implementation team should test:
Creating a new PO
Editing an existing PO
Printing before approval
Printing after approval
Printing after a partial receipt
Emailing the PO
Viewing the transaction in the browser
Using different custom forms
Avoid showing an internal operational metric to vendors if the number is not intended for external use. In many accounts, the best design is to display the column on the internal form but omit it from the vendor-facing PDF.
How to keep the On Order value accurate after receipts and edits
A stored value becomes stale unless the account has a refresh strategy.
The most important trigger is the item receipt. When a receipt is created or edited, the remaining open quantity on the related purchase order changes. Other triggers include:
Purchase order creation
Purchase order approval
PO line quantity edits
Line closure
PO cancellation
Vendor change
Location change
Subsidiary change
Item receipt deletion or correction
If the On Order value is stored on each purchase order line, a script must update affected records when these events occur. That design creates additional automation and governance requirements.
A search-based approach avoids stale stored values because it recalculates when opened. The tradeoff is that the result does not necessarily appear as a native column on every PO or printed document.
For higher-volume accounts, consider separating the two purposes:
Use a saved search or workbook for live procurement analysis.
Use a scripted snapshot only where an internal document requires a point-in-time value.
Use alerts for exceptions such as excessive open supply, overdue receipts, or demand coverage gaps.
This separation reduces the risk that a printed purchase order becomes the assumed source of truth for current inventory planning.
What are the most common implementation mistakes?
The most common mistake is treating “On Order” as a universal NetSuite field with one fixed meaning. It is a business metric that must be scoped.
Other frequent problems include:
Counting fully received lines. A PO with 100 ordered and 100 received should contribute zero open quantity.
Ignoring locations. An open PO for Location A should not automatically be presented as available supply for Location B.
Including the current transaction twice. This occurs when a script searches saved POs and then adds current unsaved values without accounting for edit mode.
Joining item receipts incorrectly. A transaction search can duplicate PO lines when receipt joins are not grouped correctly.
Mixing units. Cases, packs, and individual units must be normalized before quantities are summed.
Displaying the value externally by accident. A custom field shown on the PO form can also appear in the PDF if print settings and templates are not reviewed.
Using a workflow for complex aggregation. Workflows are useful for statuses, approvals, and simple field updates. They are not the strongest tool for multi-record quantity calculations with location and status rules.
For manufacturing businesses, the same supply logic may need to account for work orders, assemblies, and component demand. Our broader guide to NetSuite work orders and assemblies covers that manufacturing context separately. An On Order PO column should not be treated as a complete materials planning calculation when production supply and component requirements are also involved.
How should we test a NetSuite On Order column?
Testing should compare the displayed value with a controlled expected result, not simply confirm that a number appears.
Create a test matrix covering ordinary and edge-case transactions. At minimum, test a new PO, a partially received PO, a fully received PO, a closed line, multiple POs for one item, multiple locations, and an edited transaction.
For each case, record:
The expected quantity
The search result
The value shown on the purchase order
The value shown on the PDF
The result after an item receipt
The result after changing quantity or location
Also test permissions. A buyer, purchasing manager, warehouse user, and administrator may see different forms, subsidiaries, or locations. A script that works for an administrator can fail for a role that lacks permission to search item receipts or view related transactions.
Finally, decide who owns the metric. Purchasing, inventory control, finance, and operations may use the same words differently. The field label, help text, saved search name, and documentation should all use the same definition.
If the requirement involves several forms, transaction types, or integrations, our team can help assess the design through the Versich contact page.
Conclusion
Adding an On Order column to NetSuite purchase orders requires a clear quantity definition, not just a form change. Decide whether the value represents the current PO line, existing open supply, or projected supply after the current transaction. Then validate the calculation with a saved search before choosing a custom field, workflow, or SuiteScript 2.1 implementation.
For most purchasing teams, a saved search is the simplest live view of open PO supply. When the value must appear directly on an internal purchase order or PDF, use a custom transaction line field with carefully designed automation, receipt triggers, unit conversion, and location-aware filters. That approach gives buyers useful visibility without turning an ambiguous field into a source of bad inventory decisions.
