Why a Missing Tool Stops the Job Instead of Scheduling Anyway

A routing step whose required tool is inactive, unknown, or has a quantity of zero stops that job immediately, with a message naming the tool and the three ways to fix it. Other jobs in the run schedule normally. EDGEBIC by User Solutions refuses the job on purpose, because the alternative is a plan that looks perfect and collapses at the machine.

This is the third of the three ways a tool constraint moves a job, after contention and downtime, and it is the only one that produces no schedule at all.

The three causes, one message

There is really one condition with three ways in: the tool cannot supply any hours, ever, in any window.

All three produce the same refusal, and the message names the tool and tells you the three fixes: reactivate it, set the quantity above zero, or clear the step's required tool.

Note what is not on that list. Downtime is not a failure. A tool that exists, is active, has units, and is simply away for calibration produces a slide, not a stop: the operation waits for the far side of the range. The failure is reserved for the case where no future window could ever work.

The refusal is immediate

Worth knowing when you are reading a run: the tool check happens at the top of the step, before the engine begins searching forward for capacity.

That means a job blocked by a missing tool fails at once rather than after scanning weeks of calendar and reporting that it could not find capacity. It also means the message is specific. You are told the fixture is the problem, not that the mill was busy for three months.

That distinction matters because a generic capacity failure sends a planner down the zero-capacity checklist: instance counts, shifts, calendars, utilization. All of that is wasted work if the actual cause was an empty tool crib. Naming the tool is what keeps the investigation short.

Failures are contained per job

The run does not abort. Jobs whose routings need the missing tool produce no schedule and are reported; everything else places normally, which is the same discipline described in a job will not schedule at all.

That design has one consequence worth naming out loud: a failure is easy to miss if you do not look. Forty orders scheduled and six did not, and the Gantt cheerfully shows you the forty. Reading the run's messages is not optional housekeeping; it is the only place those six exist.

Why refusing beats scheduling

The instinct to schedule the job anyway is understandable. A job on the board feels like progress and a job missing from the board feels like a defect. Here is the arithmetic that says otherwise.

If the plan refuses. You learn at the planning desk, with the whole horizon still in front of you. The message names the fixture. You reactivate it, raise the quantity, record the real absence as downtime, or change the routing. Cost: minutes, and no promise has been made.

If the plan schedules anyway. The operation gets a date. Downstream steps are sequenced behind it. The job's completion date goes to a customer. Other jobs are planned around the machine time it claimed. Then, on the morning it starts, the operator discovers there is no fixture. Now you are rescheduling under pressure, the promise is already out, and everything sequenced behind the phantom operation moves too.

The second plan was never better than the first. It was the first plan with the bad news deferred to the most expensive possible moment. A scheduler that would rather be silent than wrong is not being difficult; it is refusing to spend your credibility on a plan it knows cannot execute.

This is the same principle behind guarding a tool delete while routing steps still reference it. Silent degradation, where a step whose tool vanished quietly schedules unconstrained, is strictly worse than a refused action. Retiring a tool safely is covered in how to retire a tool without breaking routings.

Prefer a quantity of zero over removing the tool

A small operational preference with a real payoff. When a tool is temporarily unavailable and will come back, set its QUANTITY to 0 rather than removing it from the model.

Both produce the same refusal and the same schedule. The difference is entirely in the message. A tool that is still in the model can be named in the failure text, so the planner reads the fixture's real name and knows exactly what to go and find. A tool that is gone can only be identified by its record, which is a slower trip and a less obvious one.

If the tool is genuinely retiring, untick Active instead, which preserves its history and its downtime records while dropping it out of every future plan.

Reading the failure well

Three habits make this symptom cheap:

1. Read the run's messages every time, not only when something looks wrong. The Gantt cannot tell you about a job that is not on it.
2. Fix the cause, not the symptom. Clearing the step's required tool always makes the message go away, and it makes the plan stop knowing about a constraint that has not gone anywhere. Reserve that fix for genuine routing changes.
3. Use downtime for absences with an end date. A fixture away for two weeks is downtime, not a zero quantity. Downtime lets the jobs schedule themselves past the window with honest dates instead of failing and waiting for a human. See how to record tool downtime.

Over 35-plus years, User Solutions has held one line consistently: a schedule is worth what its worst promise is worth. The full placement pipeline is in the scheduling engine guide, and you can see how a refusal reads in practice in EDGEBIC.