How to Run and Read the Schedule Anomaly Report in EDGEBIC

Open the Reports tab, choose Scheduler Anomalies, leave the job filter blank, and click Run. That is the whole operation in EDGEBIC by User Solutions, and it takes seconds. The skill is not in running it: it is in reading the result in the right order and knowing which findings deserve your morning.

For what the report covers and why a scheduler audits itself at all, read schedule diagnostics explained first. This post is the routine.

Running the Report

The report lives under Reports in the Diagnostics group, as Scheduler Anomalies. Two decisions before you click Run.

Scope. Leave the job filter blank for a plant-wide scan, or type one or more job numbers separated by commas to scope the run. Filtered runs are faster and are what you want while chasing a specific job. Plant-wide is what you want on a cadence.

What plant-wide adds. The stock integrity and changeover matrix families are only evaluated on a plant-wide run. They are per-product and per-work-center conditions rather than per-job ones, so scoping to a job would be misleading and slow. If you are investigating a stock figure that disagrees with its transaction history, or a setup matrix cell that never seems to apply, a filtered run will not show it regardless of which job you type.

Then click Run. On a large database a plant-wide pass takes a few seconds longer than a filtered one, because it loads the inventory ledger and the matrix as well.

Reading the Result in the Right Order

The result has two parts and most people read them backwards.

Read the summary strip first

Along the top sits one chip per check. Green means the check found nothing. Amber or red means it found rows, with the count. That strip converts roughly fifty checks into a single glance, and it tells you which family to open before you have read a single grid row.

A run where every chip is green is the state you want before publishing a schedule. It is achievable, and in steady operation it is normal.

Then read the grid, sorted by severity

The grid comes back grouped by severity and then by check, with critical findings first. Each row carries the check it came from, its category, the job it belongs to, the date, a one-line description and a detail field with the specifics.

Read in this order:

1. Criticals. Impossible or corrupt: an operation ending at or before it starts, a machine booked past its physical daily hours, a booking pointing at a machine unit that no longer exists, a stock cache that disagrees with its own ledger.
2. Warnings, by family. Configuration ambiguity where the engine had to pick something. A work center with no shift calendar. Two overlap models set on one step. A transfer batch at or above the order quantity.
3. Informational. Read once, note it, move on.

Click through to the record

Clicking a row navigates to the schedule or routing that produced it. That is the shortest path from a finding to a fix, and it is why reading the report inside the application beats reading an exported copy of it.

Everything exports to Excel or PDF from the report footer, and report layouts are remembered per report, so the columns you set up once come back next week.

A Triage Routine That Scales

Four hundred rows is not four hundred problems. It is usually five or six root causes repeated across jobs. Work it that way.

Count causes, not rows. The summary chips already group the rows for you. A family with 180 rows and one obvious shared shape is one fix.

Fix, reschedule, re-run. Many findings are downstream consequences. Clearing a work center that had no shift calendar removes the finding itself and often removes a cluster of gap and configuration findings that were symptoms of the same hole. The second run after a real fix typically drops by an order of magnitude.

Do not reschedule on top of uncleared criticals. The engine will faithfully build a plan on corrupt inputs, and you will spend the week arguing with the output rather than with the data.

Note the intentional ones. Synchronized mirror machines book without a capacity check by design, so a plant that uses them will always show related findings. Lot streaming overlaps operations on purpose, so a plant that uses it will always show overlap-related rows on those steps. The report reports conditions; you supply the verdict. What matters is that the standing set is one you recognize.

That last point is the whole discipline in one sentence: the value of a familiar baseline is that an unfamiliar family jumps out.

When to Run It

The import case is worth its own line, because it is the highest-yield moment there is. Hundreds of records change at once, and a single wrong column repeats across all of them. A conversion factor left off a minutes column produces setup values sixty times too large on every step in the file. The report shows you the shape of that in one pass. The import mechanism is covered in import masks explained and the mistakes it prevents in import mask mistakes.

A Worked Triage

A plant runs its first plant-wide sweep after loading routings from an ERP export. The strip shows three amber families and one red.

Red, criticals. Bookings referencing machine units that do not exist on their work center. Cause: a work center's instance count was reduced after those jobs were scheduled. Fix: restore the count or reschedule the affected jobs. One decision, twenty rows gone.

Amber, configuration gaps. Several work centers scheduled against with no shift definition at all. Cause: the import created the work centers automatically but nobody assigned shifts. Fix: assign shifts, which is covered in shifts and calendars. This one usually also removes a cluster of unexplained-gap findings, because the gaps were the schedule routing around machines with no capacity windows.

Amber, overlap conflicts. Steps carrying both a queue time and a flow step, imported from a system where the two composed. Cause: in EDGEBIC the overlap gate replaces the queue on the same step. Fix: decide which one you meant, and move handling time to the transfer-delay field. Background in lot streaming.

Amber, dead fields. Move hours and teardown hours populated from the legacy export. Cause: the source system scheduled with them; EDGEBIC reads them for cost only. Fix: relocate the intent into queue time or transit days.

Four causes. One afternoon. The next run comes back green except for the standing set the plant recognizes.

Where to Go Next

The plain-language walk through every family, with the thresholds each uses, is what the anomaly checks actually look for. The consequences of leaving findings unread are collected in ignoring schedule warnings. If you arrived here with a symptom rather than a routine, why does my schedule look wrong starts from the symptom instead.

For routing-side causes, which is where a large share of findings originate, see routing setup mistakes. The full platform map is the complete EDGEBIC guide, and EDGEBIC is the product hub.

Bring US the report from your first sweep and we will triage it with you. Contact US.