A Completed Job Moved When I Rescheduled: Why It Almost Never Did

Completed work is never moved by a reschedule, so when a finished operation appears to have moved, the cause is elsewhere: it was never recorded as complete, a partial step's forward remainder is being read as the original, or the view is stale. EDGEBIC by User Solutions treats an operation with a recorded actual start and actual end as permanent historical fact and re-emits it verbatim on every reschedule, so its dates, hours, and machine do not change.

The control you use to diagnose this is the operation's actual start and end dates, backed by the change audit trail. This post is the honest version of the completed-work-moved symptom in the EDGEBIC troubleshooting guide. For the mechanism, how to reschedule safely covers how the engine preserves finished work.

The Rule: Actuals Are Immutable

A reschedule in EDGEBIC is surgical. It separates work into three zones: completed steps that carry both an actual start and an actual end, in-progress steps that have a start but no end, and remaining steps with no actuals. Completed steps are preserved verbatim, their rows written back unchanged. In-progress steps keep the hours already logged and forward-shift only the balance. Remaining steps replan from scratch. So genuinely completed work cannot move; the engine's own preservation path re-emits it from the original row. Given that, an apparent move points at one of the following. Why frozen routings protect in-flight jobs covers a related protection.

Cause 1: It Was Never Recorded as Complete

The engine only treats an operation as complete when it carries a recorded actual end date. An operation with planned dates but no actual end, or with an actual start but no actual end, is not complete to the engine, so a reschedule replans it as remaining or in-progress work. This is the most common cause: a step that looks finished on the shop floor but was never marked done in the system.

How to tell: open the operation and read its actual end date. If it is blank, the step was never recorded as complete, and replanning it is correct behavior.

Fix: record the actual end date, on the kiosk or in the job view, then reschedule. With a real actual end, the operation is preserved verbatim from then on. Actuals tracking explained covers how completion is recorded.

Cause 2: A Partial Step's Forward Remainder Looks Like a Move

When a step is partially finished, the engine preserves the historical portion with the hours you logged and forward-shifts a remainder covering the balance that was never logged. That produces two bars for one step: a past block of actuals and a future block of remaining work. Read quickly, the future block can look like the completed part having moved.

How to tell: look for two bars carrying the same job and step. The past bar holds your actuals; the future bar is the remainder. If you marked the step complete but logged fewer hours than planned, the engine forward-shifts the gap as that second bar.

Fix: nothing is broken. The past bar is preserved; the future bar is the genuine remaining work. If you meant the step fully done, the logged hours were short of the plan, and reconciling the hours is the real task. Partial completion reschedule walkthrough walks this two-bar shape end to end.

Cause 3: A Stale View or a Neighboring Row

Sometimes nothing moved and the view simply did not refresh. The job view can need a reload after a reschedule to redraw preserved rows in place, and a partial remainder or a parallel sibling sitting near the completed bar can read as the same operation when it is a different row.

How to tell: check the change audit trail for the job. If it records the completed operation's actual dates as unchanged, the operation did not move and you are looking at a stale draw or a neighboring row.

Fix: reload the job to redraw preserved rows, then confirm the actual start and end on the specific row you are worried about. Verify whether that row is the completed operation, a remainder, or a sibling. Actual dates look wrong covers reading actual dates correctly.

A Word on Inferred Completion

One more case looks like movement but is not. If a later step has actuals and earlier steps in the same job do not, the engine concludes the earlier steps must have run and backfills their actuals from their scheduled dates, then preserves them. So an earlier step you never recorded can end up preserved with inferred dates rather than replanned. This keeps the routing coherent and is intentional; the inferred step is marked as backfilled.

How to Diagnose an Apparent Move, in Order

1. Read the operation's actual end date. Blank means it was never complete, so replanning it is correct.
2. Look for two bars on one step. A past-plus-future pair is a partial step's preserved actuals plus its remainder, not a move.
3. Check the change audit trail. Unchanged actual dates mean the operation did not move.
4. Reload the job view. A stale draw redraws preserved rows in place after a refresh.
5. Confirm the row's identity. A remainder or a parallel sibling near the completed bar is a different row.

Prevention

• Record actual end dates promptly. The single thing that protects a finished operation from replanning is a recorded actual end, so capturing completion on the floor is the whole prevention.
• Reconcile short-logged steps. A step marked done with fewer hours than planned produces a forward remainder; logging the real hours avoids the surprise second bar.
• Reload the job after a reschedule before judging what moved, so a stale draw does not read as a move.
• Use the audit trail as the source of truth. It records each operation's actual dates and every reschedule event, so it settles whether anything genuinely changed. If a not-completed job jumped in position, why did my job jump after a reschedule covers that symptom directly.