Setup, Run, Wait, Move, Queue: BC Routing Time Elements
A Microsoft Dynamics 365 Business Central routing operation isn’t one number — it’s up to five separate time elements, each behaving differently, each entered in its own place, and each carrying its own unit of measure. Get one of them wrong and a schedule doesn’t fail loudly; it just quietly computes a duration nobody intended. This page walks through all five with one worked example, so the differences are concrete rather than abstract.
The worked example
Picture an injection-molding operation on a routing: mold a plastic housing, 200 units, on molding press “MOLD-2.”
- Setup time: 45 minutes. The mold has to be installed and the press temperature brought up to spec before the first shot. This happens once, no matter how many units run.
- Run time: 2 minutes per unit. Each shot, cool enough to eject, takes two minutes. For 200 units, that’s 400 minutes of running time.
- Wait time: 30 minutes. The parts need to finish off-gassing before they can be handled for the next step.
- Move time: 10 minutes. Time to physically transport the finished housings to the next work center.
- Queue time: 15 minutes, entered not on this operation but on the next work center — a buffer before that resource can start working the arriving parts.
Five numbers, five different jobs. Here’s what each one actually does to the schedule.
Setup time: fixed, once, per operation
Setup is a flat cost the operation pays once, regardless of how many units are in the lot. Whether this run is for 20 units or 2,000, the mold still needs 45 minutes to install and heat. Setup time is entered directly on the routing line, and it has its own unit-of-measure code, independent of run time’s.
The one place setup time isn’t quite flat: if the routing line’s Concurrent Capacities field says more than one unit of the resource is being used for this operation — two molding presses running the same job side by side, say — the allocated setup time scales with that number, because genuinely more than one setup has to happen. The duration of that setup, though, only scales with the resource’s efficiency percentage, not with how many units are running in parallel; two presses being set up in parallel doesn’t take twice as long in wall-clock time, it takes about the same time, done twice over.
Run time: per unit, and it’s where lot size lives
Run time is the one element that multiplies by quantity. Two minutes per unit, 200 units, is 400 minutes of run time for this operation — and that multiplication is exactly why lot size and run time can’t be considered separately. Halve the lot size and you halve the run time; nothing else on the operation changes.
Run time’s duration is also the one place both a resource’s efficiency and its capacity matter directly: duration is calculated as run time divided by efficiency, divided by capacity (using whichever is smaller — the work center’s own capacity setting, or what this specific routing line asks for). A press running at 80% efficiency needs 2.5 minutes of wall-clock time to deliver 2 minutes of “book” run time; a work center modeled with capacity 2 running the same 400 minutes of book run time can, in principle, finish it in half the wall-clock time, because two units of the resource are absorbing the work in parallel.
When one setup covers several orders at once
Concurrent capacities has a second, less obvious use beyond parallel machines: allocating a shared setup across several individual orders that get processed together in one batch. Picture a curing oven that bakes several separate customer orders in a single load — one door open, one heat cycle, several orders’ worth of parts inside. The oven’s setup time genuinely only happens once, but the cost of that setup has to land somewhere across the orders sharing it, or one unlucky order absorbs a setup charge that really belonged to the whole batch. Setting the concurrent-capacity value on each order’s routing line in proportion to its share of the batch — a bigger order carrying a bigger fraction of the shared setup, a smaller one carrying less — spreads a single real-world setup event across every order it actually served, without changing how long any of them physically sit in the oven.
Wait and move time: real time, zero capacity
This is the distinction that trips people up most: wait and move time genuinely extend how long an order takes to get through the shop, but neither one occupies the resource’s calendar the way setup and run time do. The 30 minutes the housings spend off-gassing doesn’t tie up MOLD-2 — the press is free to start the next job the moment the current one’s run time finishes, even while the previous batch is still sitting there waiting. Move time works the same way: the 10 minutes it takes to physically walk parts to the next work center is real elapsed time on the order, but it isn’t “load” on any resource’s capacity.
Practically, this means a work center’s load report — the comparison of demand against capacity described in Work Centers, Machine Centers, and Shop Calendars — reflects setup and run time only. An operation can have a long elapsed span dominated by wait or move time without that time showing up as load anywhere, which is correct: nothing is actually being tied up during it.
Queue time: the buffer that lives on the resource, not the operation
Queue time is the odd one out structurally — it isn’t a field on the routing line at all. It’s set on the work center (or machine center), and it represents the gap between when material physically arrives at a resource and when work on it can actually begin: time to get it staged, mounted, or simply next in line behind whatever else is ahead of it. In the worked example, the 15 minutes of queue time belongs to whichever work center receives the housings next, not to the molding operation that produced them.
How it all adds up to lead time
Setup, run, wait, and move on every operation, plus queue time at every work center the routing touches, sum end to end into the item’s total production lead time — the elapsed span from when work could start to when the finished item is done, across the whole routing, not just one operation. For the molding operation alone: 45 minutes setup, plus 400 minutes run, plus 30 minutes wait, plus 10 minutes move, plus 15 minutes queue at the next stop, is 500 minutes of elapsed schedule from a single operation — of which only 445 minutes (setup plus run) is actual load on MOLD-2’s own capacity.
The trap: a 60× error that never announces itself
Every one of the four routing-line time fields — setup, run, wait, move — carries its own independent unit-of-measure code. That flexibility is genuinely useful (a fast setup entered in minutes next to a long run entered in hours on the same line, correctly converted), but it’s also exactly how a routing goes badly wrong without any error message telling you so.
Take the run time in the worked example: 2 minutes per unit is the intended value. If the routing line’s Run Time Unit of Meas. Code were accidentally set to hours instead of minutes, Business Central doesn’t reject the entry or flag a mismatch — it schedules 2 hours per unit, faithfully and consistently. For 200 units, that’s not 400 minutes of run time, it’s 400 hours — the operation that should finish well within a day now spans over sixteen days, and every downstream operation, and the order’s whole due date, shifts to match a number that was never real. Nothing about the resulting schedule looks like an error from inside Business Central; the math is internally consistent, it’s just consistent with the wrong premise.
There’s no substitute for checking the actual unit-of-measure code on each time field when a routing’s numbers look right but its computed dates don’t. The tell is usually a production order whose lead time is wildly out of proportion to the work being described, or a work center whose load report shows overload that doesn’t match what’s physically happening on the floor — both are worth a routing-line audit before assuming the schedule itself, or the demand driving it, is what’s wrong.
For how these five elements feed into the actual forward/backward date computation, see How Business Central Schedules a Production Order, Step by Step. For the concept-level version of what “real capacity” means beyond a routing’s own numbers — shift patterns, efficiency, parallel machines — see Modeling Real Capacity: Shifts, Calendars, Efficiency, and Parallel Machines.
For Microsoft’s field-by-field reference, see Create routings and Set up work centers and machine centers.