Hours Landed on a Date Outside the Operation Window: Causes and Fixes

When an operation's day-by-day hour split carries a date that the operation's own window does not cover, the cause is nearly always rows left behind when a reschedule moved the window, and one clean scheduling run for that job clears it. EDGEBIC by User Solutions stores each operation twice on purpose: once as a start and end window, and once as a set of per-date hour rows that let a screen total hours by day. Those two views must agree, so a day row dated outside the window is a consistency finding, not a scheduling decision.

This post is the detailed version of the out-of-window hours symptom in the EDGEBIC troubleshooting guide. For the wider family, what the anomaly checks actually look for covers every consistency check and its tolerance, and schedule diagnostics explained covers why the system audits itself at all.

What You Are Seeing

The anomaly report shows a finding naming a date and the operation's own start and end dates, and the two do not line up. On screen the effect is a day-by-day hours view that shows time on a date the Gantt bar does not cover, or a daily total that includes a day the operation clearly does not run.

The check has no tolerance. A day row is either inside the operation's date window or it is not, which makes this one of the quickest findings to confirm by eye.

Why It Happens

Cause 1: A Reschedule Moved the Window and a Row Stayed Behind

This is the documented cause and the one to assume first. When a job is rescheduled, the persist step clears the existing day rows and machine bookings for every operation that is not complete, then writes new ones for the new window. If the previous window's rows were not cleared before the rebuild, the operation ends up carrying dates from where it used to be.

How to tell: the job moved recently, and the flagged date sits where the operation was scheduled before the move.

Cause 2: The Operation Is Complete and the Dates Are History

Completed work is never moved by a reschedule. That is deliberate, and it means the day rows on a finished operation record what happened rather than what is planned. A finding on a completed operation is not something to correct in the schedule, because no scheduling run will rewrite it.

How to tell: the operation shows recorded start and end dates, and the flagged day sits inside the period the floor actually worked.

Cause 3: You Are Looking at a Component Row, Not the Operation's Own

Sub-assembly component rows are tracked separately from the operation's own day rows and are evaluated on their own terms. A component line that looks out of window in a report is a different object from the parent operation's daily split, so it is not this finding.

How to tell: the row belongs to a component of a sub-assembly rather than to the operation itself.

How to Fix It

• For a stale row after a move: run scheduling once for the affected job. The persist pipeline deletes the existing day rows and machine bookings for every operation that is not complete before writing new ones, which is precisely the operation needed here.
• For a completed operation: leave it. Confirm the recorded hours match what the floor reported, and if they do not, correct the record through the actuals screens rather than through a reschedule.
• For a component row: trace it back to the sub-assembly it belongs to and read it against that routing rather than against the parent operation's window.

Do not edit the day rows by hand. The operation's machine bookings carry the same hours from a different angle, and changing one without the other produces a different consistency finding: totals that disagree between two screens, which is covered in the same job shows different hours in two places.

How to Diagnose It, in Order

1. Read the operation's own start and end dates and compare them against the flagged date. The gap usually points straight at the previous window.
2. Check whether the operation is complete. If it is, the finding is a record rather than an error.
3. Ask whether the job moved recently. A downtime event, a priority change, or a capacity edit followed by a reschedule are the common triggers.
4. Re-run scheduling for that job alone rather than for the whole plant, so you can see whether the finding clears without disturbing anything else.
5. Re-open the anomaly report and confirm the finding returns zero rows for that job, instead of assuming the run did it.

How to Prevent It

• Let the reschedule finish. A run that is canceled part-way through its persist step is the situation where an operation can end up holding rows from two different windows.
• Re-run the anomaly report after any large replan. Consistency findings are cheap to clear the same day and confusing to explain a month later, and the report is built for exactly this pass. How to run and read the anomaly report covers the routine.
• Correct actuals through the actuals screens, not by editing the plan, so recorded days and planned days never get mixed. If hours appear with no plan behind them at all, actual hours appear with no planned hours covers that separate case.
• Treat totals-by-date screens as the early warning. A daily total that includes a day the job does not run is usually the first place this shows up, well before anyone opens the report.