A Booking Points to a Machine Unit That Is Gone

A booking that points to a machine unit that is gone is an orphan instance allocation: it references a specific instance number that was removed from the work center after scheduling ran. The anomaly report flags it as critical because the Gantt and capacity views resolve instance names to draw and total the booking. The fix is to restore the removed unit or re-run scheduling so the engine reassigns the job to a live instance.

EDGEBIC by User Solutions tracks each work center's machines as numbered instances, and each allocation is pinned to a specific one. When that unit is later removed, the allocation is left pointing at nothing. This post, part of the EDGEBIC troubleshooting guide, covers the two fixes and how to avoid orphaning bookings in the first place.

What an Orphan Instance Booking Is

A work center with more than one machine models each as a numbered instance. When the engine schedules an operation, it assigns it to a particular instance so the Gantt can show which physical unit runs the job and capacity can be tracked per machine. That assignment is a reference to an instance that must continue to exist.

If the work center's instance list is later trimmed, an allocation pinned to a removed unit becomes an orphan. The critical anomaly check fires when a booking references an instance number that is not in the work center's current instance list. The symptom looks similar to a schedule pointing to a deleted work center, but here the work center still exists; it is one of its machine units that is gone.

How It Happens

The usual trigger is reducing the instance count. A work center runs four machines, jobs get booked across all four including instance four, and later the count is dropped to three because a machine was retired or the number was corrected. The jobs already sitting on instance four are pinned to a unit that no longer exists. Reducing the count does not reschedule those jobs automatically, so their allocations are orphaned until a fresh pass moves them.

A direct removal of a specific instance, rather than a count reduction, produces the same result for any job booked on it.

How to Tell

Run the anomaly report and look for the critical config-gap chip that reports an instance not present in the work center's instance list. The Detail names the instance number and the work center. You will also notice it on the Gantt, where the affected operation cannot resolve its machine unit, and in per-machine capacity views that cannot total the orphaned booking.

Fix 1: Restore the Removed Instance

If the unit was removed by mistake, restore it so the work center's instance list includes it again. The orphaned booking reconnects to a live unit immediately, and reports resolve it. This is the right path when the machine is still real and the removal was an error.

Fix 2: Re-Run Scheduling

If the unit is genuinely gone, re-run scheduling for the affected job. The engine picks a valid instance from the current list and replaces the orphaned allocation, moving the work onto a surviving machine. This is the right path after a deliberate reduction: the job simply needs to be rebooked onto the instances that remain.

See how to configure instances and utilization and how to change the number of machines in a work center for where the instance count lives.

Confirming the Fix

After restoring the unit or re-running scheduling, re-open the anomaly report and confirm the orphan-instance chip returns zero rows for the job. On the Gantt, the operation should resolve to a real machine unit, and per-machine capacity views should total it correctly.

Prevention

• Reschedule after any instance reduction. Whenever you lower a work center's instance count or remove a specific unit, run one scheduling pass over the jobs that used the removed units, so their bookings move onto surviving machines before anyone opens a report.
• Run the anomaly report after configuration changes. A quick plant-wide scan after trimming instances surfaces every orphaned booking at once.
• Prefer adjusting over removing when possible. If a machine is temporarily down rather than gone, a downtime window or deactivation keeps the instance in the list while stopping new work, which avoids orphaning existing allocations. This connects to the wider habit of deactivating rather than deleting machines with history.
• Audit after imports. If instance counts come in from your ERP, a scheduling pass and an anomaly-report read catch a count that dropped in the source before it distorts a live plan.