NetSuite Advanced Manufacturing: BOMs, routings and work-order completion
Our reference account here is an oilfield sealing products manufacturer running NetSuite Advanced Manufacturing in production — read the case study. This page is written from that work, not from the module's marketing page — which is why it names the tradeoffs that show up once BOMs, routings and costing have to agree with each other on a live account, rather than the ones a demo environment lets you avoid.
Work-order completion and the record it leaves behind
Completing a work order in Advanced Manufacturing does more than move an assembly item into finished-goods inventory and back components out against the BOM. Each completion — full or partial, against one operation or several — posts to the AM production summary, which is the record that persists as your actual history: quantities completed and scrapped, and the labor and machine time consumed against each operation, as it really happened on the floor. The routing tells you what was supposed to happen. The production summary is what to trust when it didn't.
The distinction most NetSuite consultants get wrong
AM Capacity Plan and native Supply Planning (MRP/MPS) get treated as the same thing because they both use the word "planning." They answer different questions, they are different modules, and their output lives in different places.
AM Capacity Plan answers can the facility do all of this work in the time window — it is work-center capacity scheduling. Its records hold labor hours and machine hours per period, per work center, and that output persists: it's a schedule you can look back at.
Native Supply Planning answers a different question: what purchase orders and work orders should we create, given demand, safety stock and lead times. Its output — the planned orders sitting in the Planning Workbench — is transient. It gets purged and recreated on every planning run. Nothing about it persists between runs by design.
Conflating the two is why "our MRP doesn't work" tickets get misdiagnosed. We've seen the same pattern repeatedly: the actual problem is a capacity constraint nobody modeled, or a capacity plan built on the assumption that supply planning would tell it what to schedule. They're complementary. They are not the same module, and troubleshooting one as though it were the other wastes the time it takes to find that out.
The run-rate and costing conflict — a real tradeoff, not a bug
NetSuite collapses what older systems, and a lot of migrated data, tracked as two separate numbers — labor time and machine time — into a single run rate per operation. That run rate isn't just a scheduling input. It's tied directly to product costing.
So when a run rate came over from a legacy system wrong, or was never set to reflect true cycle time, correcting it does two things at once: it fixes MRP and capacity planning, because the schedule finally reflects how long the operation actually takes — and it changes booked product cost materially, because the same number that drives the schedule also drives the cost roll-up.
There is no version of this where you get the correct schedule without touching cost. That is the actual reason correct run-rate data often sits unfixed for months: the person who can approve a cost change isn't the person who filed the MRP ticket, and nobody wants to be the one who moved COGS without asking first. Naming that conflict plainly, and walking a controller or a CFO through exactly what changes and why, is the difference between a run-rate fix that ships and one that sits in a sandbox.
If this is the problem you have
If a planner is fighting a capacity plan that never matches the shop floor, or your MRP output doesn't line up with what's actually schedulable, or a run-rate correction is stuck because nobody wants to own the cost conversation — that's the work this page describes. Contact us, or book a call and bring the specifics.