A Reschedule Created a Duplicate Schedule Row

Two schedule rows for the same job and step on the same work center are a split-op pair the merge missed, and a clean scheduling re-run collapses them into one. The important first move is telling a real duplicate from a parallel operation, because two rows across different work centers is a correct parallel setup, not a duplicate.

EDGEBIC by User Solutions works a partially complete step as a historical portion plus a forward portion, then collapses them into one database row per step at the persist step. When that collapse is missed, both rows survive and the job appears to carry a step twice. This post separates the real duplicate from the look-alike; it sits in the EDGEBIC troubleshooting guide and pairs with rescheduling explained and how EDGEBIC preserves completed work on reschedule.

First, Check the Work Center on Each Row

The whole diagnosis turns on one fact: are the two rows on the same work center or different ones? Two rows for the same job and step on the same work center is a real duplicate. Two rows sharing the step but on different work centers is a parallel operation and is correct. Read the work center before doing anything else. This one distinction saves most of the wasted effort here, because the fix for a real duplicate is a scheduling re-run and the fix for a parallel pair is to leave it alone, and getting them backward either breaks a valid parallel setup or leaves a real duplicate inflating the job's hours.

Cause 1: A Split-Op Pair That Was Not Collapsed

When a step is partially complete, the engine carries a historical portion and a forward portion. The persist step is supposed to merge them into one row. If that merge was missed, both rows persist and the step's hours count twice.

How to tell: two rows share the same job and step on the same work center, and the anomaly report and SQL regression checks flag them as a split-op pair.

Fix: re-run scheduling for the job. The merge collapses the pair into one row per step and, when the rows are historical, keeps the one carrying the completed actuals, so no finished work is lost in the collapse. Verify with the anomaly report scoped to the job: the split-op flag clears after a clean run. The same condition is one of the SQL regression checks that run against the database directly, so if you have access to that snapshot you can confirm the pair is gone there as well as in the in-app report. Both surfaces look for the same shape, two rows sharing a job and a step, so a clean read from either is sufficient.

Cause 2: A Parallel Operation Mistaken for a Duplicate

Synchronized and independent parallel operations legitimately produce two rows that share a step across different work centers. The duplicate check excludes these mirrors on purpose, so it will not flag them, and it should not.

How to tell: the two rows are on different work centers, and the duplicate check does not flag them.

Fix: none; leave them. Merging a parallel pair would break the setup. A parallel operation that did not mirror as expected is a different question covered in a parallel operation did not mirror.

Cause 3: Duplicate Daily Breakdown or Resource Rows

A related symptom is not a duplicate schedule header but duplicate detail rows underneath it: two daily breakdown entries for the same date, or stale resource rows left from an earlier cycle. These inflate the step's hours without a second header.

How to tell: one schedule row per step, but the step's hours exceed what its window and instances allow, and the anomaly report flags a total booking over the window or a duplicate daily breakdown.

Fix: re-run scheduling. The persist step deduplicates the daily breakdown and resource rows, deleting and recreating the detail for non-completed schedules, so a clean run removes the stale detail.

The Reconciliation, in Order

1. Read the work center on each row. Same work center is a duplicate; different is parallel.
2. For a same-work-center pair, confirm the split-op flag in the anomaly report.
3. Re-run scheduling for the job to collapse the pair, keeping the completed actuals. Re-running one job is cheap; if a full reschedule is what drags, what to tune when a reschedule takes too long covers the run mode and logging levers.
4. For inflated hours with one header, check for duplicate daily breakdown or stale resource rows and re-run.
5. Verify the flag clears on a fresh run rather than assuming the fix.

Prevention

• Re-run scheduling to correct a duplicate, never hand-edit rows, since the merge is what keeps step rows single.
• Log actuals before rescheduling, so the historical and forward portions are clean when the merge runs.
• Read different work centers as parallel, not duplicate, to avoid merging a legitimate parallel pair.
• Verify with the anomaly report scoped to the job, which flags a split-op pair before and confirms it is gone after.
• Watch inflated hours as much as extra rows, since duplicate detail underneath a single header inflates a step just as a second header does, and both clear on a clean run.

A job that jumped to a different time after a reschedule, rather than duplicated, is covered in why did my job jump after a reschedule, and completed work that appeared to move is covered in a completed job moved when I rescheduled.