The Same Job Shows Different Hours in Two Places

Two screens disagreeing on a job's hours almost always means one is reading the order's stored estimate while the other reads the scheduled operations, and only the scheduled figure is the operating number. The rarer cause is a genuine drift between the two internal stores of the same scheduled hours, which the anomaly report flags and a clean run fixes.

EDGEBIC by User Solutions derives a job's operating hours from its scheduled operations, not from a stored estimate, so the number stays true as the schedule changes. When two surfaces show different totals, the first question is which source each is reading. This post is the two-screens version of the reconciliation; it sits in the EDGEBIC troubleshooting guide and is the companion to the hours do not add up on a job.

First, Identify What Each Screen Reads

A job carries an order estimate and a scheduled rollup, and they mean different things. The estimate is a quote figure from when the order was entered, frequently zero for a fully scheduled job. The rollup sums the actual scheduled operations and is the operating number. Before calling two screens inconsistent, work out which source each is reading. A screen showing zero or a suspiciously round total for a busy job is reading the estimate. The rollup also has known, deliberate exclusions: it leaves out sub-assembly rollup rows, and when the primary-hours-only setting is on it leaves out parallel siblings, so two surfaces that apply those rules differently can differ for a good reason as well as a bad one.

Cause 1: One Surface Reads the Estimate, the Other the Schedule

The classic split. A report or header bound to the order estimate shows a stale or zero figure, while a surface bound to the schedule shows the real hours. They differ because they are different numbers, not because one miscounted.

How to tell: one screen shows zero or an obviously round figure for a scheduled, in-progress job; the other shows a detailed total that matches the operations.

Fix: trust the screen reading the schedule. If a surface is showing the estimate operationally, that is the surface to correct: operating numbers should bind to the scheduled rollup, never the estimate. Reading the operating figures is covered in reading the EDGEBIC Gantt: planned versus actual.

Cause 2: The Two Internal Stores Drifted

The scheduled hours are held in two places that feed different surfaces: one drives the job totals you see on the job header, the other drives capacity and load reporting. They are two stores of the same number, written by different parts of the persist step, and they should always agree. When they do not, the anomaly report flags a critical consistency drift, and the two surfaces read different numbers as a direct result. This is the one case where two screens disagreeing is a genuine data problem rather than a difference in what each is reading.

How to tell: both screens are clearly reading the schedule, not the estimate; they disagree by more than rounding; and the anomaly report's consistency-drift check flags the job as critical. Scope the report to the single job to confirm it quickly, which is covered in how to run and read the anomaly report.

Fix: re-run scheduling for the job. Both stores are recomputed and written together on a clean run, which resolves the drift. The fix has exactly one form, so a surviving disagreement after a fresh, refreshed run is not something to keep re-running against; export the flagged row for a support ticket instead.

Cause 3: One View Is Stale

The anomaly report reads the database live, but some screens hold their last load until refreshed. After a reschedule, one surface can reflect the new plan while another shows the old figure simply because it has not reloaded.

How to tell: you rescheduled and only one surface updated; the other still shows pre-run numbers.

Fix: refresh or reopen the lagging screen. If both are freshly loaded and still differ, move on to the drift check above.

Cause 4: Primary-Hours-Only Changes the Total

The job total can exclude parallel siblings when the primary-hours-only setting is on, and it excludes sub-assembly rollup rows. A surface applying that rule and one that does not will show different totals for the same job by design.

How to tell: the job has parallel or sub-assembly work, and the difference matches those excluded hours.

Fix: none; the totals are answering different questions. Compare like with like by knowing which surface applies the primary-hours-only rule.

The Reconciliation, in Order

1. Identify each screen's source: estimate or scheduled operations.
2. Trust the scheduled rollup; the estimate is a quoting figure, often zero.
3. Refresh a lagging screen before concluding the data disagrees.
4. Run the anomaly report scoped to the job for a genuine consistency drift.
5. Re-run scheduling to rewrite both stores together and clear a real drift.

Prevention

• Bind operating surfaces to the scheduled rollup, never the order estimate.
• Refresh views after a reschedule so every screen reads the same run.
• Treat a critical consistency-drift flag as a re-run trigger, since it has one fix.
• Know which surfaces apply primary-hours-only, so parallel and sub-assembly hours are compared consistently.
• Log actuals before rescheduling, so the planned, actual, and remaining figures stay coherent across every surface rather than diverging when the engine plans against stale reality.

For the broader question of reconciling planned, actual, and expected hours on a single job, see the hours do not add up on a job.