Glossary (EDGEBIC)

What Is Actuals Preservation on Reschedule? Definition and Example

User Solutions TeamUser Solutions Team
|
6 min read

Actuals preservation on reschedule is the rule that a reschedule never moves completed work: any operation with a recorded actual end date is treated as immutable and stays exactly where it happened, while only the unstarted and in-progress operations are replanned. When a moving company re-plans its truck route after a traffic jam, it does not un-drive the miles already covered; it re-plans the road ahead. A reschedule does the same for a partly finished job: the finished operations are locked, and the engine only replans what is left.

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

How Actuals Preservation Works

A reschedule exists to react to reality: a machine went down, a job ran long, priorities changed. But by the time you reschedule, some of the work has already happened, and that work must not be disturbed. Actuals preservation is the discipline that makes reschedule safe.

The trigger is the actual end date. Once an operation carries one, it is completed, and the rescheduler treats it as immutable: it will not move the operation, recompute its dates, or reallocate its hours. The engine preserves the completed operations in the output exactly as recorded and excludes their routing steps from replanning.

Everything else replans against reality. The engine finds where the last finished step actually ended and uses that as the resume point, so the remaining steps queue behind what really happened rather than behind the original plan. A step with an actual start but no actual end is in progress: the engine keeps its start and replans only its remaining hours. A step with no actuals is fully replanned from the resume point.

The result is a schedule that is part history and part fresh plan, stitched together at the boundary between what happened and what is next.

A Concrete Example

A three-step job is planned as cut Monday 8 to 2, drill Monday 2 to Tuesday 10, paint Tuesday 10 to 4. By Monday afternoon the floor records:

StepActual startActual endResult on reschedule
CutMon 08:30Mon 15:15Preserved exactly
DrillMon 15:15Tue 11:00Preserved exactly
Paintnot startednot startedReplanned from Tue 11:00

When the planner reschedules, cut and drill both have actual end dates, so they are frozen as recorded. Paint has no actuals, so the engine replans it from Tuesday 11:00, the moment drilling actually ended, and finds Paint-1's first slot after that: Tuesday 11:00 to 17:00. Cut ran 30 minutes late to start and drill ran an hour long, and paint absorbs both, because the reschedule built on the recorded reality. Had all three steps been finished, the reschedule would have preserved the whole job and scheduled no new work at all.

How EDGEBIC Uses It

In EDGEBIC actuals preservation is built into every reschedule, not an option you switch on.

  • Completed operations are immutable. An operation with an actual end date is preserved in the output and never moved or recomputed.
  • In-progress steps resume, not restart. A step with an actual start and no actual end keeps its start and replans only its remaining hours, and its actual end stays null so the next run classifies it correctly.
  • Remaining steps build on reality. The engine resumes the unstarted steps from where the last finished step actually ended, not from the original plan.
  • The original dates survive. The first-run dates are retained, so plan-versus-actual variance stays anchored even after several reschedules.

Actuals preservation works alongside the routing snapshot, which keeps the routing steady while preservation keeps the finished work steady, and it is the foundation under partial completion, where a single step is part done. The how EDGEBIC preserves completed work on reschedule walkthrough steps through the pipeline, and what is production scheduling sets reschedule in the wider loop.

Actuals preservation is the rule that a reschedule never moves completed work: any operation with a recorded actual end date is treated as immutable and stays exactly where it happened, while only the unstarted and in-progress operations are replanned. When a moving company re-plans a truck route after a traffic jam, it does not un-drive the miles already covered; it re-plans the road ahead. A reschedule does the same for a partly finished job.

Because completed work is a historical fact, not a plan. The operator recorded when Step 1 actually started and finished; rewriting those dates on a reschedule would falsify the record and could contradict what the floor already did. Preserving them keeps the plant's history honest, keeps plan-versus-actual variance meaningful, and lets you reschedule the remaining steps freely without disturbing the work already on the books.

An actual end date on an operation triggers it. Once a step is recorded as finished, the rescheduler locks it, preserves it in the output, and excludes its routing step from replanning. Steps with an actual start but no actual end are treated as in progress: their start is kept and only their remaining hours are replanned. Steps with no actuals at all are fully replanned from the point the last finished step actually ended.

Expert Q&A: Deep Dive

Q: Steps 1 and 2 of a three-step job are finished and Step 3 has not started. When I reschedule, what actually moves?

A: Only Step 3. The engine reads the actual dates on Steps 1 and 2, treats them as immutable, and preserves them exactly as recorded. It then replans Step 3 from the moment Step 2 actually ended, finding that work center's first available slot after that point. If Step 1 started 30 minutes late and Step 2 ran an hour long, Step 3 lands later than the original plan, because the reschedule builds on what really happened rather than the paper plan.

Q: If every step of a job is already complete, what does a reschedule do to it?

A: Effectively nothing. When all steps carry actual end dates, the reschedule preserves the whole job as recorded and schedules no new work; it is a no-op for that order. This is the safe outcome you want: a finished job is history, and running the scheduler over the whole plant should never disturb it. The completed operations remain in the output with their real dates so reports and variance still see them.

Frequently Asked Questions

Ready to Transform Your Production Scheduling?

User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.

User Solutions Team

User Solutions Team

Manufacturing Software Experts

User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.

Let's Solve Your Challenges Together