How EDGEBIC Reads a Routing: From Steps to Scheduled Hours

A routing becomes a schedule in four moves: the link chain is read as a dependency graph, the steps are ordered so nothing runs before its predecessors, each step's booked hours are computed from setup and per-unit time, and each step's release time is composed from queue, overlap and transit. Understanding those four moves is what lets you look at a schedule that surprises you and know which routing field to check.

This post is the mechanism. For the field definitions, start at the bill of routing explained. For the wider engine that consumes what this post describes, inside a modern finite capacity scheduling engine is the pillar treatment.

Move One: The Links Become a Graph

EDGEBIC by User Solutions does not schedule a routing top to bottom in grid order. It reads the next-in-sequence link on every step and builds a dependency graph from those links, then orders the steps so that no step is ever scheduled before something it depends on.

That distinction matters as soon as a routing stops being a straight line. Two feeder legs converging on one assembly bench have no single correct grid order, and any sort you invent will be wrong for one of the legs. A graph has no such problem: both legs are scheduled before the bench, in whatever order capacity makes sensible, and the bench waits for the later of the two.

The link on a step can point at another step, at the end product itself, or at several targets when the process fans out. The end-product link is what closes the chain, and it is why the last operation must carry it. A routing where no step points at the end product still schedules, but the engine has no anchor for depth, which brings us to levels.

Move Two: Levels Give the Graph Depth

From the same links, EDGEBIC computes a routing level for every step by walking the chain toward the end product. Level 0 is the step immediately before the finished good, and the numbers climb upstream.

Walk the three-step bracket routing:

Saw (S10) -> Drill (S20) -> Deburr (S30) -> Bracket (end product)

S30 points at the end product        -> level 0
S20 points at S30 (level 0)          -> level 1
S10 points at S20 (level 1)          -> level 2

Levels do real work. They order a routing where legs of different depths converge, they drive how the designer lays a routing out, and they are what makes a sub-assembly's steps sit at the right depth relative to the parent's.

Three chain conditions get flagged during this walk, and each has a different symptom on the floor:

The cycle case deserves emphasis because it fails quietly. The engine does not refuse to schedule. It treats both steps as the same depth and produces a plan that looks reasonable, so nobody investigates. When a warning marker appears on a routing, repairing the chain is cheaper than explaining the schedule later.

Move Three: How Many Hours a Step Books

For every work-center step the engine computes the hours it must place:

booked hours = setup time + (hours per unit x order quantity)

That is the whole formula. Setup is a fixed cost per run; run time scales with quantity. When sequence-dependent changeover is configured, the setup value is resolved from the setup matrix rather than taken flat from the step, and the resolved value is what enters the formula.

Those hours are then placed against real shift capacity on the work center. The engine does not assume an eight-hour block exists. It searches forward day by day and shift by shift, respects holidays, downtime and the work center's utilization percentage, and splits the hours across as many shifts and machine units as it needs. That allocation is its own subject, covered in multi-shift scheduling and machine instances. The point here is that the routing supplies the quantity of hours and the calendar supplies where they fit.

Component rows work differently and deliberately so. A row that names a product rather than a work center gets an instant assignment at its start time and books no capacity at all. That is what makes a purchased casting appear on the plan without pretending it occupies a machine.

Move Four: The Composition Order

This is the part that explains most "why did the next step start then" questions. After a step's hours are placed, its release time for downstream steps is composed in a strict order:

1. allocation end        the moment the booked hours finish
2. + queue time          shift-aware buffer after the step
3. -> overlap gate       transfer batch or flow step, if either is set
4. + transit days        travel time, calendar or working days
5. = release time        the earliest any successor may start

Two properties of that pipeline surprise people.

Queue time is shift-aware and consumes nothing. A two-hour queue does not tick overnight or on a holiday, and the work center is free to run other jobs during it. It models parts sitting on a rack, not a machine being held.

The overlap gate replaces, it does not add. When a step carries a transfer batch or a flow step, the gate that model produces becomes the successor's release time, and the queue time on that same step is discarded even when the queue would have ended later. That is intentional and it is the single most misread interaction in the routing model. If you want a handling lag on top of an overlap gate, the transfer-delay field is what composes; a queue on the same step does not. The anomaly report flags every step that carries both so you can confirm which one you meant. Full treatment in lot streaming and queue and transit times.

Transit applies after whichever gate fired, and only on work-center steps. On a component row the travel is already inside the component's own availability, so applying it again on the consuming step double counts it.

Move Five: Where a Step Actually Starts

Now the two halves meet. A step's earliest start is:

start = the latest of:
          the order's own start time
          every predecessor's release time

Then the capacity search takes over and finds the first slot at or after that time where the work center can take the hours. Two consequences follow.

A step never starts before its slowest predecessor releases, which is why a single late feeder leg moves an assembly and everything after it. And a step's actual start can be later than its earliest start, sometimes much later, because capacity was not available. That gap is the schedule being honest about load, and it is not a routing problem.

Distinguishing the two matters when you are debugging. An unexplained gap of more than four days between sequential steps, with no queue, overlap or transit on the routing and no competing job occupying the downstream machine, is flagged by the diagnostics as a finding. A gap with a competing job in it is excluded, because the wait is real. That distinction is described in what the anomaly checks look for.

A Worked Pass Through a Routing

Take a steel bracket, 500 pieces, on day and night shifts.

The engine's pass:

S10  booked = 0.02 x 500 + 1.0  = 11.0 h
     starts Monday 08:00, runs across the day and night shifts
     queue 0, no overlap, no transit
     release = allocation end, so S20 may start then

S20  booked = 0.015 x 500 + 0.5 = 8.0 h
     earliest start = S10 release; capacity search lands it on the day shift
     queue 2.0 h, shift-aware, added after the hours finish
     release = allocation end + 2 working hours

S30  booked = 0.005 x 500 + 0   = 2.5 h
     earliest start = S20 release
     no queue, no overlap, no transit
     release = allocation end, and the chain reaches the end product

Every date on that job traces to one of those three arithmetic lines plus the calendar. Change the drill's per-unit time from 0.015 to 0.020 and S20 books 10.5 hours instead of 8.0, which pushes S30 and the promise date. That traceability is the reason routing accuracy pays back faster than any engine tuning.

Transit: Calendar Days Versus Working Days

One field changes answers more than its size suggests. Transit days can count flat calendar days or only days on which the work center has shifts.

Send shafts out for five-day heat treatment, finishing on a Wednesday:

• Working days. Count Thursday, Friday, Monday, Tuesday, Wednesday. The gate lands at the end of the following Wednesday's shift.
• Calendar days. Add five flat days, landing on the Monday, with the weekend consumed silently.

Both are correct for some vendors and wrong for others. A vendor quoting business days needs working-day mode. A carrier quoting flat turnaround needs calendar mode. The two diverge most across weekends and holiday weeks, which is precisely when a promise date is most likely to be quoted.

Sub-Assemblies and the Frozen Snapshot

When a component row names a product that has a routing of its own, the scheduler expands that routing at scheduling time. The sub-assembly's own steps are planned against real capacity, the parent's consuming step waits for the sub-assembly to be available, and both appear on the job. The routing you maintain stays one level deep; the plan the engine builds is as deep as your product structure.

One rule governs what happens afterwards. At scheduling time, each job records its own copy of the routing it was planned with. Later edits to the standard routing do not reach back into that job. This is why a corrected mill rate improves every new order and leaves last week's job showing its original hours, and it is what keeps the paperwork on the floor valid. Rescheduling a job against the current standard routing is an explicit choice, described in editing a live job's routing.

Reading a Schedule Backwards

Put the four moves together and you have a diagnostic procedure. A step landed somewhere you did not expect, so:

1. Check its predecessors' release times, not their end times. Queue, overlap and transit sit between them.
2. Check the link chain, not the sequence numbers. A warning marker explains a strange order instantly.
3. Check the arithmetic: setup plus per-unit hours times quantity. A wild number is almost always a batch total in a per-unit field.
4. Check capacity: if the work center was booked, the gap is load, not configuration.

Those four cover the large majority of routing-driven surprises. The ones they do not cover are collected in routing setup mistakes, and the systematic sweep across a whole plant is schedule diagnostics explained. If you are still deciding whether finite capacity is the right model at all, finite versus infinite capacity scheduling is the category piece.

The full platform map is the complete EDGEBIC guide, and the product hub is EDGEBIC.

Bring a job whose dates you cannot explain. Contact US and we will trace it field by field.