What Is a Scheduling Failure Category? EDGEBIC Definition

A scheduling failure category classifies why a job could not be scheduled. In EDGEBIC by User Solutions, a job that fails to schedule is not reported as a generic error. It is labeled with a specific cause, and the label distinguishes problems found before scheduling was attempted from problems hit during the attempt.

The analogy is a mechanic who tells you what is wrong rather than that the car will not start. Out of fuel, dead battery, and seized engine are all reported as a car that will not start, and they are three completely different afternoons.

For the broader vocabulary of planning, see the manufacturing glossary.

How a Scheduling Failure Category Works

Scheduling a job means reading its product, reading that product's routing, resolving each step to a work center, and placing the steps on real capacity in dependency order. Any of those can fail, and they fail for very different reasons.

The categories split into two families, and the split is the most useful thing about them.

Pre-flight failures are data problems, found by validation before the engine even tries to place work. They include a product that cannot be resolved from the order, no routing existing for the product, a routing that exists but has no steps, a step referencing a work center that is missing or inactive, a work center with no machine instances, a work center with no shifts assigned, shifts that carry no working hours, and a link chain that forms a circle so no valid order of operations exists.

Every one of those is a master-data problem. None of them is about how busy the plant is. All of them are fixed by someone who maintains products, routings, work centers, or calendars, and most take minutes.

Runtime failures happen during the placement attempt. The main one is no available capacity within the capacity search window: the engine walked forward day by day looking for a slot that fits and reached the end of its search leash without finding one. Others cover synchronized work, such as parallel work centers that cannot find a slot free on all of them at once, or a dependent step that could not mirror its parent because the parent was never scheduled. There are also validation failures where an allocation was proposed and then rejected as invalid.

The reason the distinction earns its keep is that the two families route to different people and different actions. Pre-flight failures mean something is missing in setup. Runtime failures mean the plant, as configured, cannot fit the work, which is a planning decision rather than a data fix.

A Concrete Example

You run the schedule on Monday morning and three jobs do not appear on the board. With a generic error you would now be reading logs. With categories, the three tell you their stories directly.

The first reports that no routing exists for the product. This is a brand new part number, entered by sales when the order landed, and nobody built its routing yet. The job cannot be scheduled because there are no operations to place. Whoever maintains routings fixes it in ten minutes, and the failure was never about capacity at all.

The second reports a circular dependency in the routing. Someone editing the routing pointed a later step back at an earlier one, so no valid order of operations exists: every step waits on another step that waits on it. The engine cannot sequence a loop. A planner untangles the link chain and the job schedules.

The third reports no available capacity within the search window. This one is real. The engine looked forward and found no slot that fits on the work center this job needs. Now you have a decision rather than a bug: extend the window, add capacity on that station, move the job's dates, or route it to an alternate work center.

Three jobs, three failures, three different people, three different afternoons. The category is what made that obvious in the first thirty seconds instead of the first hour.

How EDGEBIC Uses It

The failure category is attached to each job that could not be scheduled:

• It separates data problems from capacity problems. Pre-flight categories point at products, routings, work centers, and calendars; runtime categories point at capacity and configuration.
• It names the specific cause. Missing routing, empty routing, invalid work center reference, no instances, no shifts, no daily hours, and circular dependency are distinct labels rather than one error.
• It surfaces in the failure report so a planner can triage a batch of failed jobs by cause instead of investigating each one from scratch.

For the circular-link problem specifically, see what is a dependency violation in scheduling. For the leash on the capacity search, see what is a scheduling anomaly check. To fix a looped routing, follow how to fix a circular dependency in a routing.