What Is an Original Scheduled Date in a Production Schedule?

An original scheduled date is the start or end an operation received on its very first scheduling run, frozen at that moment and never overwritten by any later run. It is the reference point that makes per-operation variance measurable: without it, each reschedule would quietly erase the evidence of the one before, and nobody could say how far a step had drifted from what was first committed. EDGEBIC by User Solutions stores the original pair alongside the current plan and the recorded actuals, so all three coexist.

How it works

Every scheduled operation carries three pairs of dates, and keeping them straight is most of the concept.

The original pair is written once, on the first scheduling run that ever places the operation, and then never touched. Reschedules do not update it. Manual moves do not update it. Recording actual work does not update it.

The current planned pair is where the engine plans the operation right now. This is the pair that changes: every reschedule recomputes it from present capacity, calendars, priorities, and whatever recorded work has landed since. It is the working answer to "when will this run?"

The actual pair holds the recorded start and end from the floor, when they exist. It is the answer to "when did this run?"

Because all three are stored independently, two different variances are computable at once. Comparing the original pair to the current pair shows plan drift: how much the schedule for this operation has moved since it was first committed, regardless of whether the operation has started. Comparing the current or original pair to the actual pair shows execution variance: how the floor differed from the plan.

The permanence is the design, not an accident of implementation. A reference point that can be refreshed is not a reference point. If the original pair were re-stamped on each run, every job would eventually read as perfectly on plan, because the plan and its baseline would move together. The measurement only means something because nobody can move one end of it.

At job level the same idea surfaces as a summary: the engine's originally planned window for the whole job, which is the earliest original start and the latest original end across its operations, sitting beside the job's current window.

A concrete example

A job runs three operations. The first scheduling run produced this plan, and the original pair for each row was frozen from it.

Then the saw hit a blade change and step one actually ran Monday 09:15 to 14:00, an hour and a quarter late starting. A reschedule re-planned the remaining work from the real finish.

Read the third row. Nothing has happened to assembly: it has no recorded work, nobody dragged it, and its work center's capacity is unchanged. Its current window has nonetheless moved from Wednesday afternoon to Thursday morning, purely because the operations feeding it moved. The original pair is what makes that movement visible as a number rather than a memory.

Note also that step one's original window and its actual window differ while its current window now matches the actual. That is the normal end state for a completed operation: the plan has been reconciled to reality, and the original pair is the only surviving record of what was first intended.

Run a second reschedule tomorrow and the current column changes again. The original column will read exactly as it does above, and will still be readable next quarter when someone asks how a job that shipped on Thursday came to be promised for Wednesday.

How EDGEBIC uses it

The original pair is visible on the job summary as the engine's planned window for the whole job, sitting alongside the job's current dates so plan drift is a glance rather than a query.

It underpins variance reporting, described in what is variance in manufacturing scheduling, and it is the per-row counterpart to a whole-chart snapshot. The distinction between the two is worth understanding: the original pair is automatic and per operation, while the snapshot covered in what is a Gantt baseline is deliberately saved and covers the whole picture at a moment you choose. Together they answer the same question at two scales.

The other two pairs have their own definitions. Recorded work is covered in what is an actual date in scheduling, and the hours version of the same plan-versus-reality comparison is covered in what is planned vs actual hours.

Because the current pair is the one that moves, understanding what a run is allowed to change matters: that is laid out in what is a reschedule in scheduling. And when you want the story of how an operation got from its original window to its current one, event by event, the record is described in what is a schedule change log.

The takeaway

An original scheduled date is a single frozen fact that turns a schedule from a snapshot into a history. Three pairs of dates on one operation sounds like clutter until you try to answer "has this drifted?" with only two of them. The rule to remember is that the original pair cannot be refreshed, and that this is a feature: a baseline you are allowed to move would show zero variance forever. For the neighboring concepts see what is a Gantt baseline and what is variance in manufacturing scheduling, then explore EDGEBIC or, if you are coming from the legacy product, RMDB to EDGEBIC.