When an operation shows a bar on the Gantt but has no resource or machine-instance rows underneath it, the resource detail was not built on the last scheduling cycle, and a clean re-run rebuilds it. EDGEBIC by User Solutions expects every work-center operation to carry resource detail that names the machine and instance doing the work, so an operation missing that detail is flagged by the anomaly report and left out of resource load until it is rebuilt.
This post covers the missing-resource symptom in the EDGEBIC troubleshooting guide. It is the counterpart to a resource is logged against the wrong work center, where the detail exists but names the wrong machine, and it relates to hours do not add up on a job. To confirm the flag before and after, run the scheduler anomalies report.
What You Are Seeing
An operation sits on the Gantt with the correct work center and hours, but it has no resource or instance rows beneath it, so it never appears on resource-load or utilization reports. The header looks complete; the detail that should credit a machine is simply absent, and the anomaly report flags the operation.
Why It Happens
Cause 1: The Resource Detail Was Not Rebuilt (the Usual Answer)
The persist step rebuilds resource detail for non-completed schedules, recreating the machine and instance rows. If that rebuild was missed on the last cycle, the operation keeps its header but loses its detail, leaving nothing to credit a machine.
How to tell: the operation header is correct, but no resource or instance rows sit under it.
Cause 2: A Complex Routing Increased the Rebuild Work
Parallel branches and alternate work centers put more work on the persist step, since each operation's detail must be rebuilt against its resolved machine. A missed rebuild on such a routing leaves an operation with a header and no rows.
How to tell: the symptom appeared on a job with parallel or alternate routing after a reschedule.
Cause 3: It Is a Material Step, Not a Work-Center Step
A material step is assigned instantly and does not carry machine resource detail, so no rows under it is expected. That is not the same as a work-center operation missing its detail.
How to tell: the step is a material step, in which case the absence of machine resources is correct.
How to Fix It
- Re-run scheduling for the job. The persist step rebuilds the resource detail and recreates the machine and instance rows the operation needs.
- Verify with the anomaly report scoped to the job: the missing-resource flag clears after a clean run.
- Re-check resource load, since the rebuilt detail lets the machine pick up the operation's hours.
- Confirm the step is not a material step, where no machine resource detail is the correct state.
How to Diagnose It, in Order
- Confirm the operation is a work-center step, not a material step, since material steps carry no machine detail by design.
- Check for resource and instance rows under the operation; their absence is the whole symptom.
- Ask whether a reschedule ran, especially on a parallel or alternate routing.
- Re-run scheduling to rebuild the detail.
- Verify the anomaly flag clears and resource load picks up the operation's hours.
How to Prevent It
- Re-run scheduling after a reschedule on complex routings, where the rebuild work is greatest, and confirm every operation carries resource detail.
- Read a resource-load gap against the Gantt, since a header with no detail is invisible to load reports but visible on the timeline.
- Verify with the anomaly report scoped to the job, which flags a work-center operation missing its resources before and confirms it is fixed after.
- Never hand-add resource rows, since a fresh run rebuilds them and the merge keeps them consistent. For detail that exists but names the wrong machine, see a resource is logged against the wrong work center.
The resource detail underneath the operation was not built or was dropped on the last scheduling cycle, so the operation exists as a header with no resource or machine-instance rows beneath it. A work-center operation should always carry resource detail that names the machine and instance doing the work; when that detail is missing, the anomaly report flags the operation. The bar shows because the schedule header is intact, but the operation will not appear correctly on resource-load reports until the detail is rebuilt by a clean re-run.
It drops the operation out of resource load. The resource rows are what credit hours to a machine and instance, so an operation with no resource detail contributes nothing to any machine's load, even though its bar sits on the Gantt. Utilization for the machine that should be doing the work is understated by exactly those hours. The schedule is not lost; the detail beneath it is missing and a fresh run rebuilds it.
Re-run scheduling for the affected job. The persist step rebuilds the resource detail for non-completed schedules, recreating the machine and instance rows the operation needs, so a clean run restores what was missing. Verify with the anomaly report scoped to the job: the missing-resource flag clears after the run. Do not try to hand-add resource rows, because the run rebuilds them and hand-edits fight that process.
Expert Q&A: Deep Dive
Q: An operation shows on the Gantt with the right work center and hours, but resource load never counts it. Where are its hours going?
A: Nowhere, because the operation has no resource detail to credit them. Resource rows are what attribute an operation's hours to a specific machine and instance; without them, the operation contributes to no machine's load even though the header and its hours appear on the Gantt. That is why resource load never counts it. Re-run scheduling for the job so the persist step rebuilds the resource detail, then re-check the report: the machine's load picks up the operation's hours once the rows exist again. The anomaly report will confirm the missing-resource flag has cleared.
Q: This appeared after a reschedule on a job with parallel or alternate routing. Is that the cause?
A: Likely yes. Complex routings with parallel branches or alternate work centers put more work on the persist step to rebuild each operation's resource detail, and a missed rebuild leaves an operation with a header but no rows. The reschedule is the trigger and the missing detail is the mechanism. A clean scheduling re-run rebuilds the resource detail for the affected operations, and the anomaly report confirms every operation now carries the machine and instance rows it needs.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
An Operation Moved and the Machine Was Free: Finding the Hidden Cause
A job slid and every machine shows open hours. Tooling is the cause the Gantt cannot draw. How to rule it in or out in two minutes before you chase calendars.
An Operation Shows Running Forever Though All Hours Are Logged
A step stays in progress after every hour is logged because completion is an explicit stamp, not an hours threshold. How to close it and stop it recurring.
Another User Changed This Record: Causes and Fixes
EDGEBIC refuses a save when the record moved after you loaded it. The usual cause is a colleague, but the message also appears when you are alone. How to read it and what to do.