Table of Contents
ToggleCase Study: Automating Inbound Shipment Creation in NetSuite
The Problem Wasn’t the People—It Was the Process. And It Was Costing Hours Every Single Day.
For a confidential client in the import and distribution space, the gap between raising a purchase order and receiving goods was filled by manual data entry. Every approved PO destined for a shipping container had to be turned, by hand, into a NetSuite Inbound Shipment record — the document the warehouse and finance teams rely on to track goods in transit and to allocate the true cost of landing those goods.
Done manually, this was slow and error-prone. Someone had to identify which POs were ready, group them by their physical container, transcribe line items, and then layer on landed costs — freight, brokerage, customs, duty, tariffs, and more — each governed by its own business rules. Multiply that across dozens of containers a week, and the process consumed real hours while quietly introducing the kind of transcription mistakes that only surface later, at reconciliation.
The client wanted this to simply happen — accurately, every night, with a clear trail whenever something needed a human’s attention.
The Challenge: When Software Becomes a Barrier
Underneath “just create the shipment record” sat a surprising amount of hidden complexity. Done manually, each nightly cycle required someone to:
Identify the right POs — sifting approved purchase orders to find only those flagged and ready for an inbound shipment, and not already processed.
Group by physical container — consolidating multiple POs into a single shipment based on the container they ship in.
Transcribe line items accurately — copying each item, quantity, and location onto the shipment without error.
Apply layered landed costs — freight, brokerage, customs, duty, tariffs, certifications, demurrage and more, each with its own allocation method and its own business rules for when it does and doesn’t apply.
Do it at volume — repeating the entire sequence across dozens of containers every week.
Any one of these is manageable. Stacked together, night after night, they made the process both time-consuming and fragile.
The Impact: A Chain Reaction of Inefficiency
Because the workflow ran on manual effort, it carried the costs that manual effort always does:
Lost hours: Skilled staff spent significant time each week on repetitive data entry rather than higher-value work.
Costly errors: Transcription mistakes and misallocated landed costs often didn’t surface until reconciliation — the most expensive and time-consuming point to catch them.
Inaccurate cost of goods: Because landed cost feeds the true value of inventory, every error rippled into margin and valuation reporting.
Key-person dependency: The process lived in people’s heads and habits, making it vulnerable to absences and turnover.
The Solution: Re-aligning Technology with Business Logic
Our team at My ERP Partner built the solution as a SuiteScript 2.1 Map/Reduce script, scheduled to run nightly. Map/Reduce was a deliberate choice over a simpler Scheduled Script: NetSuite meters server work through a governance budget, and Map/Reduce lets that budget reset across stages while naturally parallelizing the workload. Just as importantly, its shape mirrored the business problem:
Get input — a saved search finds every PO line flagged for inbound-shipment creation, approved, and not already processed.
Map — each line is keyed by its Container, the physical grouping the whole process revolves around.
Reduce — every container becomes exactly one Inbound Shipment, with all its lines and landed costs.
Summarize — anything that couldn’t be processed is collected and reported.
This structure meant the code read the way the business actually thinks: POs go into containers; containers become shipments.
Getting the Details Right: Landed Cost Allocation Logic
The heart of the project — and the part most sensitive to business rules — was landed cost. My ERP Partner engineered the system to handle two fundamentally different kinds of cost applied to each shipment:
Weight-allocated costs (freight, brokerage, certifications, demurrage, repackaging, clearance) are pulled from the PO and spread across items by weight. Straightforward in principle, but with conditions: for example, certain freight charges are suppressed when the PO already carries them as a separate expense line, to avoid double-counting.
Value-allocated costs (customs, duty, tariff) are calculated as a percentage of each item’s value and allocated proportionally. These required reading per-item percentage fields, summing across lines, and rounding carefully so the totals reconciled to the cent.
On top of the base logic sat several business gates the client needed honored precisely:
An expense-line check that removes specific freight costs when they’re already accounted for elsewhere.
A PO-level flag that, when set, zeroes out customs, duty, and tariff entirely — for shipments that shouldn’t carry those charges.
Encoding these rules as explicit, well-labeled gates — rather than burying them in conditionals — kept the logic auditable. When a cost is excluded, the execution log says why, which matters enormously when finance later asks how a number was reached.
Making It Safe to Run Every Night: Idempotency and System Safeguards
Automation that runs unattended has to be idempotent — running twice must not create duplicates. My ERP Partner built two layers of protection:
Line stamping: Once a PO line is turned into a shipment, it’s stamped with a processed-date. The input search excludes stamped lines, so the next run never re-processes them.
An open-shipment guard: Before creating a shipment for a container, the script checks whether an open Inbound Shipment already exists for that container. If one does, it does not create a second — it flags the situation for a human instead. This protects against edge cases the stamping alone can’t catch, like a shipment created manually or through another path.
Intelligent Error Routing: Exceptions That Route Themselves
The client’s most thoughtful requirement wasn’t about happy-path automation at all — it was about failure. When something can’t be processed, who hears about it?
Rather than firing every exception into a single shared inbox, our script routes each one to the person who created the offending PO. If a PO is missing its container, or collides with an existing open shipment, or errors out mid-creation, the notification lands with the individual best positioned to fix it — resolved dynamically from the PO’s creator field to that employee’s email address, with all of a given person’s issues consolidated into a single tidy message.
The result is an automation that’s quiet when everything works and precise when it doesn’t. No noise, no shared-inbox diffusion of responsibility — just the right exception in front of the right person.
Engineering Notes: Where NetSuite Pushed Back
A few challenges are worth calling out — the kind of thing that separates a demo from a production system:
Field discovery: Linking a shipment line back to its source PO line didn’t use the obvious identifier; it required a specific line-level key that isn’t documented in the places you’d first look. Confirming it took targeted diagnostics against the live record.
The search-vs-record trap: A shipment’s status is a valid field when you load the record — but not a valid column in a search or lookup. The duplicate-shipment guard initially failed for exactly this reason, and the fix was to read status off the loaded record rather than through the search layer. In NetSuite, “the field exists” and “the field is searchable” are two different questions.
Checkbox serialization: A boolean flag returned inconsistent representations through the search API. Reading it authoritatively from the record — where a checkbox is unambiguously true or false — removed a whole class of subtle bugs.
The Result: Technology as a Driver of Success
What began as a nightly data-entry chore is now an unattended process engineered by My ERP Partner that groups, creates, costs, and validates inbound shipments on its own — and knows exactly who to call when it can’t. Staff are freed from repetitive entry, landed costs are applied consistently by rule rather than by memory, and exceptions reach the right person the moment they occur.
Key Strategic Takeaways
Match the architecture to the domain: Map/Reduce wasn’t just a governance decision; keying by container made the code legible to anyone who understood the business.
Make business rules explicit and logged: Every excluded cost explains itself, turning “why is this number what it is?” from an investigation into a log lookup.
Design for the unhappy path first: Idempotency and self-routing exceptions were what made the client comfortable letting this run unattended.
Trust the record, not always the search: Some of the most stubborn NetSuite bugs come from assuming the search layer sees fields the same way the record does.
Conclusion: Need Help Optimizing Your NetSuite Operations?
NetSuite includes powerful workflows for inventory tracking, purchasing, operations, reporting, and inbound logistics. However, building and maintaining custom processes like automated inbound shipment creation and layered landed cost logic makes technical system planning more important than ever.
If your business relies on NetSuite, now is the right time to review your environment and create an optimization plan.
My ERP Partner has certified NetSuite consultants on staff who understand the product in depth. Whether you need to optimize core accounting features, streamline your CRM, manage your Omnichannel commerce connectors (like Shopify, POS systems, marketplaces, and 3PLs), or build customized reports and automated workflows, we have you covered. We combine deep technical expertise with timely, cost-effective support delivery to handle your system configuration so you can focus entirely on running your business.
Contact My ERP Partner today to connect with our certified NetSuite consultants. Let us help you integrate your storefronts, configure your workflows, and keep your NetSuite system running smoothly and cost-effectively.


