How Partial Completions Carry Forward in EDGEBIC

When an operation in EDGEBIC by User Solutions is only partly done, whether it is still running or was marked complete short of plan, the logged hours stay locked and only the remainder is re-planned forward. The step keeps its machine, stays one row on your screen, and never loses or invents an hour. Partial completion scheduling is one of the quietest but most important behaviors in the platform, because half-finished work is the normal state of a busy shop, and how a scheduler handles it decides whether your plan stays honest. This article explains exactly how partial work carries forward.

Real operations do not finish neatly at shift end. A step runs three hours into a twelve-hour plan and stops for the day. An operator marks a job done with fewer hours than the routing expected. A naive scheduler either freezes the whole thing (pretending it is complete) or re-plans it from scratch (throwing away the work already done). EDGEBIC does neither. It carries the partial work forward.

Two Kinds of Partial

There are two situations EDGEBIC treats as partial, and it helps to name them.

In progress. The step has an actual start but no actual end. Work is happening and is not finished. Example: a 12-hour grind with 4 hours logged so far.

Short-confirm. The operator marked the step complete (an actual end is stamped) but the logged hours fall materially short of the planned hours. Example: a 16-hour run closed after 10 hours logged.

Both are partial in the sense that hours are still owed against the plan. EDGEBIC detects the gap using a small tolerance so that ordinary rounding does not trigger a false partial, and then handles each according to a clear rule. For the underlying concept, see what is a partial completion in scheduling.

The Carry-Forward Mechanism

When a reschedule runs, a partial step is handled in three moves.

Preserve the history. The hours already logged stay on their real days, and the historical portion of the step is written back with its work center unchanged. This is the immutability principle applied to the completed part of a partial step: what happened, happened.

Re-plan the remainder. The engine computes the remaining hours (planned minus logged) and places them on the next available slot on the same work center. A started operation never moves to a different machine. Downstream steps queue behind this new forward end.

Merge back to one row. Internally the historical piece and the forward piece are handled separately, because the engine's dedup logic needs them apart. But at the persist boundary they are merged into a single row per routing step per work center. On your screen you see one operation, with its real logged hours, its real start, and a window that now stretches to cover the re-planned remainder. This is why an in-progress operation sometimes shows a schedule window longer than its planned hours: the window spans both history and remainder.

One subtlety keeps the cycle clean. The in-progress historical row is not backfilled with a projected end. If it were, the next reschedule would read it as complete and discard the operator's eventual real finish. Leaving the end null keeps the step genuinely in progress and makes the whole thing idempotent: rescheduling twice yields the same result as rescheduling once.

Short-Confirm: A Site Policy

The short-confirm case (operator marks done early) is governed by a setting you choose once, under Options as Partial-Confirm Behavior:

The default forward-shifts, because in most shops a step closed early with hours still owed means those hours genuinely still need doing. But a shop where the operator's word is final can trust the stamp instead. You decide the policy as a site; you do not decide it job by job. To set it, see how to set how partial completions are handled.

A Worked Example

Job 303. Step 1 is a 16-hour CNC run planned Monday 08:00 to Tuesday 16:00 on CNC-3. The operator presses Mark Complete on Wednesday morning but logged only 10 hours over Monday and Tuesday. Site policy is the default, forward-shift.

The engine detects the short-confirm: 16 planned, 10 logged, a 6-hour gap beyond tolerance. It:

1. Preserves the historical block on CNC-3 from Monday 08:00 to the Wednesday stamp, with the daily hours truncated to the two days that actually had logged hours.
2. Sets the resume point to the operator's Wednesday stamp.
3. Re-plans the 6-hour remainder onto CNC-3's next free slot: Wednesday 09:00 to 15:00.

The planner sees one CNC-3 row for step 1 whose window spans the historical block and the forward 6 hours. Step 2 queues after Wednesday 15:00. The operator's premature close is respected, no hours are invented or discarded, and the missing 6 hours are simply owed and re-planned.

Why the Merge Matters

The merge-to-one-row behavior is not cosmetic. Without it, every reschedule of an in-progress job would leave behind another historical-plus-forward pair, and after a week of daily reschedules the database would carry a pile of duplicate rows for the same step. EDGEBIC collapses the pair at the persist boundary, deduplicating the daily hours by date and the resource allocations by their machine, day, and instance. The result is that repeated reschedules stay clean: one row per routing step per work center, run after run.

This hygiene is part of why the platform stays trustworthy over long horizons. A partial step that survives fifty reschedules looks exactly as clean on day fifty as on day one. For the wider point about clean records, see why one clean operation record matters.

The Payoff

Carrying partial work forward correctly is what lets you reschedule a running shop without fear. Started work keeps its machine and its logged hours; only the honest remainder moves; the screen shows one clean operation; and the cycle is idempotent so you can run it daily. It also keeps your WIP management accurate, because a half-done job is shown as exactly that: real hours logged, real remainder still owed. Combined with the three-zone model, this is what makes EDGEBIC's reschedule surgical rather than destructive, and it is why planners can run it on a daily rhythm without dreading what it will do to work in progress.

For the full picture of how actuals drive the plan, see how a reschedule uses last night's actuals and the shop floor execution guide. Explore the platform at EDGEBIC.