A routing translates production steps into an expected sequence, resource requirement, and cost structure. Small errors in its assumptions can multiply across hundreds of orders. Setup time entered as a per-unit value, or a resource count misunderstood as elapsed time, can distort both capacity and cost.
A NetSuite manufacturing routing acceptance test should compare planned operation time with captured activity and explain what happens when output is partial or rejected. The aim is a routing that planners, operators, and cost accountants can interpret consistently.
For each step, describe the physical work, required resource, output, and completion condition. Identify where material is consumed and where quality decisions occur. Include waiting, curing, or transfer requirements where they affect the schedule, but distinguish them from active resource time.
Agree the work-centre structure. A team, a machine group, and an individual machine are different capacity concepts. Determine what the selected NetSuite configuration represents and how the resource count affects scheduling and costing.
Confirm the required manufacturing features, routing setup, cost templates, and capture tools. Do not assume a shop-floor interface can record every field supported by a desktop transaction. Test the actual method operators will use.
Setup prepares an operation for an order or batch. Run time describes the processing requirement for output. The routing should reflect that distinction using the units expected by the configuration.
In NetSuite routing setup, operation setup time and per-unit run rate are expressed in minutes. Cost capture and reporting may present time differently, so validate conversions and the source of actual time. A rate per hour applied to a value interpreted as minutes creates a large error without changing the apparent number entered.
Also define when a second setup is required. Splitting production over two shifts does not automatically mean two setups, while changing tooling between partial runs may genuinely require another. The operator needs a rule that matches physical work.
Consider an order for 100 units. Operation 10 is cutting, with 20 minutes of setup and one minute of run time per unit. Planned elapsed processing time is 120 minutes.
Operation 20 is assembly, with 30 minutes of setup and two minutes per unit. Planned processing time is 230 minutes. If the operations must run sequentially and no other delays apply, their combined active processing time is 350 minutes.
That 350-minute sum is not automatically the order's promised lead time. Queueing, calendars, transfer time, overlap rules, and resource availability can change the schedule. Record these assumptions separately so a planner can explain the difference.
For the costing test, define the actual resource and rate assumptions independently. This prevents a schedule calculation from being mistaken for the complete manufacturing cost.
In the hypothetical order, the first assembly run processes 60 units. The remaining 40 are processed later without another physical setup. The total assembly setup remains 30 minutes, not 60.
Ask the operator to record the partial completion using the intended workflow. Then inspect the operation quantities, remaining work, captured setup time, and cost entries. Confirm that a later completion does not automatically repeat a setup amount contrary to the agreed process.
If the second run does require new setup, capture that fact and its reason. The difference should be visible as an operational event or reviewed variance, rather than hidden by changing the standard routing retrospectively.
Suppose all 100 units pass through cutting, but assembly yields 98 good units and two rejected units. Actual cutting time is two hours. Actual assembly time is four hours, ten minutes above its 230-minute plan because of inspection and rework activity included in this illustrative time measure.
Use simple hypothetical rates to calculate an expected conversion-cost check. Cutting uses one machine at 40 currency units per hour and one operator at 25 per hour. Two hours therefore produce machine cost of 80 and labour cost of 50. Assembly uses one operator at 30 per hour for four hours, producing 120. Total illustrative conversion cost is 250, excluding overhead and other charges.
If that total is viewed per good unit, 250 divided by 98 is approximately 2.55. This is a management calculation for the example. Actual postings depend on the cost categories, rates, resources, quantities, and costing method configured in the account.
The test should show where the two rejected units are recorded and whether they require rework, scrap approval, or another disposition. Do not increase good completion quantity merely to make the operation match the original order.
Repeat one calculation with more than one resource. Two operators working for one elapsed hour represent two labour hours if both are charged for that hour. They do not necessarily provide twice the machine capacity.
Check whether the routing's resource count, completion record, and cost template agree on that interpretation. An operator entering total labour hours into a field that is then multiplied by resource count can double the intended cost.
Make the expected calculation part of the test evidence: rate, resource count, time or quantity basis, and resulting amount. Inspect the ledger impact and WIP movement where applicable rather than relying only on a screen total.
A routing can calculate costs correctly while scheduling work unrealistically. Test calendars, operation dependencies, allowed overlaps, and the handling of work that spans non-working periods.
Likewise, a plausible schedule does not establish that the cost template uses the right rates or accounts. Have the production planner approve timing assumptions and the cost accountant approve the accounting design.
If standard costing is used, review how setup is distributed through the applicable costing lot size and how current production batches compare with that assumption. A small run can carry different setup economics from the batch used to establish a standard.
For each tested operation, retain the routing version, work centre, planned setup, planned run rate, resource count, expected quantity, actual time, good output, rejected output, and expected and actual cost.
Include the partial-completion sequence and any corrections. Record whether the operator used mobile capture, an integration, or a desktop process. A passing result through one entry route does not automatically validate another.
Approve the routing only after the remaining work and cost are explainable. Unexplained residual quantities or duplicated time should be resolved before the route becomes a production default.
Setup and per-unit run time are different concepts. Confirm how the selected cost design allocates setup across output, especially for standard costing and partial completions.
Define good, processed, and rejected quantities separately according to the supported workflow. The quantity representing saleable output should not be inflated to conceal rejects.
Sometimes their availability aligns, but they are distinct resources. A machine may run unattended or require several operators. Model and test the actual relationship.
Time, resources, rates, output, and setup frequency may differ. Break the variance into those causes before changing the routing or accepting the difference as normal.
CuriousRubik can discuss a scoped routing diagnostic using a representative order, partial completions, and expected cost calculations. The result to aim for is a route whose time and cost logic the operating team can explain.