What Is a Scheduling Anomaly Check? EDGEBIC Definition

A scheduling anomaly check is an automated test that flags a specific data integrity problem in a schedule, such as a job that ends before it starts or a step carrying two conflicting rows. In EDGEBIC by User Solutions, a whole family of these checks runs after a plan is built, grouped into validation, flow, inventory, and configuration categories. Each check has a code, a plain-language meaning, and a Critical or Warning severity, so a planner can find and fix a broken record before it distorts a report or a downstream schedule.

This entry is part of the EDGEBIC glossary series. For the broader vocabulary, see the manufacturing glossary. Anomaly checks are a diagnostic sibling of the resource replacement audit, which trails routing changes rather than data faults.

How a Scheduling Anomaly Check Works

A schedule is only as trustworthy as the records behind it. A single row with an end date before its start date, or two rows where one step should have one, quietly poisons every report that sums hours or dates. Anomaly checks are the automated guardrails that catch those records so a human does not have to hunt for them.

EDGEBIC organizes the checks into families by prefix, each guarding a different part of the system:

• V checks are core schedule validations. Examples: V1 flags an actual end date earlier than the actual start (an inverted date); V4 flags split-op pairs, two or more schedule rows for one job-and-step; V7 flags duplicate daily-hour rows that would double-count.
• F checks cover flow and lot-streaming interactions. F1 flags a FlowStep overlap silently ignored when a step routes to an alternate work center; F2 flags FlowStep and queue time set together, where FlowStep wins unexpectedly.
• I checks cover inventory integrity. I3 flags a negative on-hand balance (more issued than received); I1 flags on-hand cache drift where the stored quantity disagrees with the ledger sum. The plant-wide sweep of the same ground is the inventory integrity check.
• C checks cover configuration mismatches. C1 flags a transfer batch set on a continuous-process work center, where the piece-count model does not apply and the setting is ignored.

Each anomaly carries a severity. Critical means the record will produce wrong numbers and needs fixing; Warning means it is worth a look but may be intentional, like a deliberate long gap between steps. The report counts each check's hits so a planner can clear the criticals first.

A Concrete Example

Suppose a reschedule of Job 42 leaves a duplicate row for Step 3. The next anomaly run reports:

Left alone, that duplicate makes Step 3's hours count twice, inflating the job's totals and any utilization report that touches it. The V4 check surfaces it immediately, so the planner knows to let the partial-completion merge collapse the pair back to one row rather than discovering the double-count later in a wrong earned value number.

Now a second example on the inventory side: an over-issue drops a stocked product's ledger sum below zero. The run reports an I3 negative on-hand anomaly, Critical. That is physically impossible stock, and it will corrupt any projection built on the item, so it is fixed by tracing the missing receipt before planning runs against that product. Two different families, two different faults, one report that catches both.

How EDGEBIC Uses Scheduling Anomaly Checks

The checks are surfaced through the Scheduler Anomalies report, one of the panes in EDGEBIC's reports catalog. The pane runs its full set across the schedule (dozens of checks in several categories) and renders a summary chip for each check at the top; clicking a chip filters the detail grid to that check's rows, and clicking again clears it. The step by step is in how to run and read the anomaly report in EDGEBIC, and a plain-English tour of what each check looks for is in what the EDGEBIC anomaly checks actually look for.

One of those categories is the configuration gap check, which flags a schedule built on master data that no longer supports it, such as a work center left with no shifts. The point of running the checks after every plan is that data faults are cheapest to fix the moment they appear. A V4 caught today is a one-row merge; the same V4 found next week is a wrong report someone already acted on. Treating the anomaly report as a routine post-schedule step, rather than a tool you reach for only when something looks off, is what keeps the numbers on every other EDGEBIC report worth trusting.