A Job Header Date Does Not Match Its Operations: Causes and Fixes

When a job's summary start or end date disagrees with the earliest and latest of its own operations by more than a minute, a replan changed the operations and never recomputed the header, and one scheduling run for that job puts them back in step. EDGEBIC by User Solutions keeps a header record for every scheduled job that summarizes the whole thing: its start is the earliest operation start, its end is the latest operation end. Screens that need one date per job read the header rather than walking every operation, which is why a stale header quietly misleads a report while the board is perfectly correct.

This post is the detailed version of the header-drift symptom in the EDGEBIC troubleshooting guide. For the wider set of consistency findings and their tolerances, see what the anomaly checks actually look for.

What You Are Seeing

A job list, a due-date report, or a late-job view shows a start or end date for a job that does not match what the schedule board shows for that job's first and last operations. The anomaly report names the job, shows the header dates and the earliest and latest child dates side by side, and reports the gap in minutes.

Why It Happens

Cause 1: A Partial Replan Moved Operations Without Recomputing the Header

This is the documented cause. The header is recomputed after a job is scheduled, so a full run always leaves the two in agreement. A path that adjusts child operations without going through that recompute leaves the header holding the previous window while the operations sit somewhere else.

How to tell: the header dates match where the job used to be, and the operations match where it is now.

Cause 2: The Gap Is Under a Minute and Is Not Drift at All

The check tolerates one minute. Operations can land on second-level boundaries that do not round identically into a summary, and that is a normal artifact rather than a disagreement between two writers. Anything at or beyond a minute means the header and the operations were written at different moments.

How to tell: the gap is measured in seconds, and no finding appears in the report even though two screens show slightly different times.

Cause 3: The Header Includes Operations You Are Not Looking At

The header spans every operation on the job, including ones already complete and material steps that carry no labor hours. A job that started last week and still has work in front of it legitimately shows a header start in the past, because completed work is never moved by a reschedule and its recorded dates still count toward the span.

How to tell: the header start or end matches an operation you were mentally excluding, usually a finished one or a material line.

How to Fix It

• For a stale header: run scheduling for that job. The recompute runs after each job is scheduled, so a single pass rebuilds the header from its own operations and the drift clears.
• For a sub-minute gap: nothing to do. The tolerance exists precisely so this does not generate noise.
• For an apparent gap explained by a completed or material operation: nothing to fix in the schedule. Widen the comparison to every operation on the job and the header will make sense.

Until the header is recomputed, trust the operations. They are the plan the engine built. The header is a summary derived from them, so it is the one that can be behind.

How to Diagnose It, in Order

1. List every operation on the job, including completed ones and material steps, and note the earliest start and the latest end.
2. Compare those two dates to the header. If they match, the disagreement you saw was a filtered view rather than drift.
3. Measure the gap. Under a minute is expected and unreported; a minute or more is a genuine finding.
4. Ask what changed the job last. A targeted replan after a downtime event or a priority change is the usual trigger.
5. Re-run scheduling for that job and re-open the anomaly report to confirm the finding returns zero rows.

How to Prevent It

• Prefer a full scheduling pass over piecemeal edits when a job's dates need to change, because the header recompute is part of the pass.
• Check the header after any targeted replan. A single job re-run is fast, and it is far cheaper than explaining a late-job report that nobody can reconcile against the board.
• Read reports and boards as two views of one plan. When they disagree, the operations win and the header gets rebuilt, not the other way around. If two screens disagree on hours rather than dates, the same job shows different hours in two places covers that case.
• Run the anomaly report after a large replan. Consistency findings are quick to clear the same day. How to run and read the anomaly report covers the routine, and what is production scheduling covers why one job carries so many dates in the first place.