A Sub-Assembly Scheduled Before Its Parent: Causes and Fixes

When a sub-assembly step schedules ahead of the parent step it feeds, the cause is almost always a broken dependency link between the two, most often a next-in-sequence connection that is empty or points at a step the engine cannot resolve by name. EDGEBIC by User Solutions orders every routing by following the real dependencies between steps, so a component that genuinely feeds a parent is never placed after it once the link between them resolves.

This is the deeper version of the out-of-order symptom in the EDGEBIC troubleshooting guide. It differs from steps scheduled out of sequence, which covers a single routing's internal order, because here a lower-level component and the parent that consumes it are the pair that inverted. For the structure that ties components to parents, see what a bill of materials is, and for why ordering matters at all, what production scheduling is.

What You Are Seeing

A component operation (a machined part, a welded sub-frame, a painted panel) finishes on the Gantt after the parent operation that needs it has already started, or the two overlap when one should clearly precede the other. The routing looks numbered in the right order, yet the plan runs them out of order, and it is worse when both steps use the same work center.

Why It Happens

Cause 1: The Sequence Link Is Missing or Unmatched

The scheduler sorts steps by following the next-in-sequence link that ties a component step to the step that consumes it. When that link is empty, the engine has no way to know the component must come first. When the link points at a step by name and that name was changed or does not match, the link fails to resolve and is treated as absent.

How to tell: the component step's next-in-sequence field is blank, or it names a step that no longer exists under that name.

Cause 2: The Two Steps Share One Work Center

When a component and its parent run on the same work center, they compete for the same capacity. Without an explicit dependency between them, the scheduler has only the sequence number to separate them, and two steps on one machine can interleave. The shared machine is what exposes the missing link, because on different machines a later start is less visible.

How to tell: the inverted pair runs on the same work center, and removing the shared machine (routing one to an alternate) makes the order correct.

Cause 3: The Link Resolves by Name Instead of Identifier

The engine resolves the next step by its identifier first and only falls back to matching by name. A link carried only by name survives everyday edits poorly: rename the target step and the name-only link silently stops matching. The identifier-based link is the durable one.

How to tell: the link worked before a step was renamed and stopped after.

How to Fix It

• Populate the empty link. On the component step, set its next-in-sequence connection to the step that consumes it so the dependency is explicit.
• Confirm the link resolves by identifier. A link matched by identifier survives renames; one matched only by name does not. Re-point any name-only link.
• Re-run scheduling. The engine rebuilds the order from the real dependencies, so once the links resolve, the component schedules ahead of its parent.
• If a shared work center is the trigger, the fix is still the link, not moving the work. An explicit dependency orders two steps on one machine correctly.

How to Diagnose It, in Order

1. Read the two steps' work centers. A shared work center points straight at a missing dependency rather than a capacity problem.
2. Check the component step's next-in-sequence link. Empty or unmatched is the most common single cause.
3. Confirm the link resolves by identifier, especially if a step was recently renamed.
4. Re-run scheduling and read the Gantt: the component should finish before the parent starts.
5. If it persists, route one of the pair to an alternate work center as a test; if the order corrects, the dependency link was the issue all along.

How to Prevent It

• Always populate next-in-sequence links on component steps that feed a parent, so the dependency is explicit rather than inferred from numbers.
• Prefer identifier-based links over name-only links, since renaming a step breaks a name-only connection quietly.
• Watch shared work centers closely. A component and its parent on one machine need the dependency spelled out, because the machine cannot enforce order on its own.
• Verify on the Gantt after any routing edit, not just the sequence numbers, since the numbers are a fallback and the dependency is what actually orders the plan. A single job's internal ordering is covered in steps scheduled out of sequence.