What Is a Partial Completion in Scheduling? Definition and Example

A partial completion is a routing step that has run some but not all of its planned hours at the moment of a reschedule, and the engine keeps the hours already worked while replanning only the hours still owed. A step with 4 of its 12 planned hours logged is rescheduled for the missing 8, not the full 12. It is the middle ground between an untouched step and a finished one: part of it is history, and part of it still needs a slot on a machine.

This entry is part of the EDGEBIC by User Solutions glossary series; for the broader vocabulary of production planning, see the manufacturing glossary.

How a Partial Completion Works

A step arrives at a reschedule in one of three states. Untouched steps have no actuals and are planned freely. Completed steps have an actual end date and are immutable. A partial completion is neither: it has hours worked but hours still owed.

There are two ways a step becomes partial. It can be genuinely in progress, with an actual start and no actual end, still running when you reschedule. Or it can be short-confirmed: an operator pressed complete but logged fewer hours than planned, leaving a gap between the planned total and what was recorded.

Either way, the engine preserves the worked portion as a historical block and computes the remaining hours as planned total minus logged hours. It then replans that remainder. For an in-progress step it resumes from the actual start; for a short-confirm it resumes from the operator's completion stamp. Crucially, the engine leaves the historical block's actual end null on an in-progress partial, so the next reschedule re-reads it as in progress and the round trip stays consistent.

The Three Handling Policies

What happens to the unlogged hours is a site policy, chosen once and applied to every partial completion.

• Forward-shift-remaining (the default) reschedules the missing hours onto the next available slot. The gap is honored: the work still has to happen, so it is placed on the machine again.
• Trust-actual-end treats the operator's close-out as final. The shortfall is written off: if the operator says done, the job is done, and the missing hours are not re-allocated.
• Trust-unless-flagged trusts the close on most steps but re-allocates the shortfall on specific steps flagged to always account for it, so a forgiving paint step and a strict precision-grinding step can coexist under one rule.

In every policy the logged hours are real and untouched. Only the treatment of the gap differs.

A Concrete Example

A 16-hour CNC run is planned across Monday and Tuesday. The operator logs 6 hours Monday and 4 Tuesday, then presses complete on Wednesday morning. That is 10 logged against 16 planned: a 6-hour shortfall with a completion stamp.

Under the default forward-shift policy, the engine:

• Preserves a historical block for CNC-3 spanning the two logged days, with the daily hours truncated to the days that actually carried work.
• Computes the remaining 6 hours and reschedules them from Wednesday morning onto CNC-3's next available slot: Wednesday 09:00 to 15:00.
• Queues the following step after Wednesday 15:00.

The planner now sees two rows for the step: the historical block and the forward-shifted 6-hour block. The operator's early close is respected, and the missing hours are placed on the machine rather than invented or discarded.

How EDGEBIC Uses It

In EDGEBIC partial completions are handled at every reschedule, governed by the site's partial-completion policy.

• The worked portion is preserved. A historical block holds the hours already logged, with its daily breakdown reflecting only the days that carried work.
• The remainder is replanned. The engine schedules planned-minus-logged hours from the resume point, not the whole step again.
• In-progress rows stay in progress. The historical row's actual end is left null so repeated reschedules classify it consistently.
• The persist boundary merges cleanly. The engine's two-row output (historical plus forward) is collapsed to one database row per step, keyed on the step and its work center so a parallel sibling on another machine is not wrongly merged, and duplicate daily rows are removed.

Partial completion sits directly on top of actuals preservation on reschedule: completed steps are frozen, and partial steps are the finer case where a single step is split between history and remaining work. To choose the policy, see how to set how partial completions are handled in EDGEBIC, and the partial completion reschedule walkthrough steps through the timelines bar by bar. For the other end of the same story, closing a step outright so it is frozen against every future reschedule, see what mark complete means on an operation.