What Is a Configuration Gap Check in Scheduling?

A configuration gap check is a scheduling anomaly test that flags a plan resting on master data no longer able to support it. It runs three tests: a job scheduled on a work center that defines no shifts of its own and does not inherit the global ones, a booking that names a machine instance which no longer exists at that work center, and a single schedule whose booked hours exceed what its own time window and instance count physically allow. The first and third report as warnings; the orphan instance reports as critical.

The unifying idea is simple. Every other check asks whether the plan is internally consistent. This one asks whether the plan still matches the shop it was built for. Master data moves, and a plan built last Tuesday can quietly outlive the work center list it was based on.

This entry belongs to the EDGEBIC by User Solutions glossary. For the wider vocabulary, see the manufacturing glossary, and for the parent concept, the definition of a scheduling anomaly check.

How the Configuration Gap Check Works

The work center with no calendar

A work center can either inherit the plant's global shifts or define its own. If it is set to define its own and nobody adds any, the engine has zero working windows to allocate against. The cell appears on every dropdown, accepts routing steps, and shows up in reports, but it has no hours. A job routed through it either fails to place or produces a plan nobody can trust.

The check flags any schedule sitting on a work center in that state. It is a warning rather than a critical because the numbers themselves are not corrupt; the cell is simply missing the calendar that would make them meaningful.

The orphan machine instance

Every allocation names the physical machine it ran on: instance 1, instance 2, and so on within a work center. If the work center's instance count is later reduced, bookings that referenced the removed machine now point at a machine that is not there. That is a critical firing, because the plan is committing work to a resource which no longer exists in the master data.

The cause is nearly always housekeeping: someone trimmed a work center's instance list after the schedule ran, usually to reflect a machine being sold, scrapped, or moved to its own cell.

More hours than the window can hold

The third test is arithmetic on a single operation. It sums the hours booked against one schedule row and compares them to the row's own start-to-end window multiplied by its instance count. Exceeding that is not possible for a real operation, so the firing points at duplicate or stale allocation rows.

The usual source is a partial completion that split into a historical portion and a forward portion and never collapsed back into one row. The check measures the window in whole minutes so it matches the equivalent database query, which makes it slightly more forgiving than the tighter over-utilization test that uses a hair-thin tolerance.

A Concrete Example

A shop imports its machine list from a spreadsheet: sixty work centers, names, descriptions, instance counts. The import lands cleanly and the planner starts routing products through them.

The first schedule run leaves a dozen jobs unplaced. The anomaly report comes back with configuration gap warnings on eleven of the imported cells. Every one of them was created set to use its own shifts, and the spreadsheet carried no shift rows, so all eleven have no working windows at all.

The planner selects the eleven, switches them to inherit the plant's global shifts, and re-runs. The warnings clear, the jobs place, and the imported cells start behaving like the hand-entered ones.

Six weeks later a different firing appears: critical, orphan instance. A drilling cell had been entered with four machines; one was moved into its own work center and the count reduced to three. Three jobs still carried allocations naming instance 4. Re-running those jobs re-placed the work across the three remaining machines and the critical chip went green.

How EDGEBIC Reports Configuration Gaps

In EDGEBIC, the configuration gap tests run inside the Scheduler Anomalies report under the Reports menu. Run it plant-wide after any master data change, especially after an import or after editing a work center's instance count, because those are the two moments the plan is most likely to have outlived its inputs.

Every firing is scoped to a job, so the report gives you a job number and the work center involved rather than a general complaint. From there the fix is usually one of three moves: give the work center a calendar, restore or re-place the missing instance, or re-run the job so a stale split row collapses.

The related definitions are the work center shift that supplies the calendar, the machine instance that a booking names, and the over-utilization check that catches the same excess-hours pattern from the work center's side. For the practical walkthrough, see how to run and read the anomaly report, and for the symptom-first version, capacity shows zero for a work center.

Treat a clean configuration gap strip as proof that the plan and the shop still describe the same place.