The Anomaly Report Still Lists a Problem I Fixed: Causes and Fixes

When an anomaly row survives a fix, it is almost always because the schedule was never regenerated: the report audits the bookings that currently exist, and correcting a setting does not rewrite bookings that were already placed. EDGEBIC by User Solutions reads the current stored state every time the anomaly report loads, so the clearing sequence is always the same three moves: fix the cause, re-run scheduling, re-open the report.

Skipping the middle move is the single most common reason a planner believes a check is broken. This post covers the four reasons a row persists and how to tell them apart, and it belongs with the other diagnostic entries in the EDGEBIC troubleshooting guide. For the report screen itself see how to run the scheduler anomalies report, and for the findings that are meant to stay see the anomaly report flags a job I think is fine.

What You Are Seeing

You corrected the thing the anomaly row named: you added the missing shift, restored the machine unit, fixed the instance count, or entered the holiday. You re-open the report and the same row is still there, with the same job, the same date, and the same description.

Why It Happens

Cause 1: The Schedule Was Not Regenerated

Most checks describe a schedule row that already exists. Over-utilization, instance collisions, off-calendar bookings, plan inversion, and consistency drift are all statements about placed work. Changing a setting changes what the engine will produce next time. It does not move a booking that is already stored.

How to tell: the fix was to master data (a calendar, a shift, an instance count, a machine unit) and you have not scheduled since.

Cause 2: The Report Pane Is Holding an Older Result

The report loads its data when it opens and keeps that result on screen. If you leave it open across a scheduling run, you are reading the state from before the run. There is no live refresh behind the pane.

How to tell: the report has been open since before your last run.

Cause 3: The Finding Is About a Routing, Not a Schedule

The routing-level checks, covering overlap gates, transit mode, and fields the scheduler does not read, evaluate the routing record itself. Rescheduling will not clear them because the engine is not what is wrong. Only correcting the routing clears them, and they clear immediately on the next report load without a scheduling run.

How to tell: the row names a routing step and a configuration field rather than a date and a machine.

Cause 4: The Finding Is a Warning That Is Meant to Persist

Some warning-level checks reflect normal variance. An idle gap between two consecutive jobs on a machine unit is a throughput observation, not an error. Drift between the hours a routing predicts and the hours actually booked has legitimate causes, including a routing edited after the schedule was built and work that ran on an alternate machine.

How to tell: the row is a warning, the description reads as an observation, and the number is small.

How to Fix It

• Re-run scheduling after any master-data fix, then re-open the report. This clears the large majority of persistent rows.
• Close and re-open the report rather than trusting a pane that has been open across runs.
• For routing-level rows, correct the routing and reload the report. No scheduling run is required for those to clear.
• For warnings, decide rather than chase. Accept the ones that describe reality and act on the ones that repeat on the same work center.

How to Diagnose It, in Order

1. Check whether you have scheduled since the fix. If not, that is the answer.
2. Reload the report so you know you are reading current state.
3. Read the severity. Critical rows are the gate. Warnings need a judgment, not a reflex.
4. Read the detail column, which carries the specific values behind the row: the machine, the date, the hours booked against the cap, and the jobs involved.
5. If the row survives a clean re-run, the cause you fixed was not the cause of this row. Re-read the description and work the check on its own terms.

How to Prevent It

• Adopt the three-move habit: fix, re-run, re-open. Written on a sticky note it removes most of this class of confusion.
• Run the report after the last scheduling run of the session, not before it. A report run mid-session audits a plan you are about to replace.
• Remember that calendar edits are not retroactive. A holiday, a downtime window, or a shift change governs future runs; existing bookings move only when the job is rescheduled, as covered in a job was booked on a holiday.
• Track which checks you have cleared so a reappearance on the next run reads as a regression rather than as noise, and treat critical checks as the ones that must reach zero before you publish.