What Is a Schedule Change Log?

A schedule change log is the audit trail that records every change to a job's production plan, from the first save through every reschedule, work-center swap, date override, completion, and reopening, each stamped with the reason it happened. It is the schedule's history book, so a planner can always answer "why does this job look the way it does?"

This entry defines the schedule change log and shows how it reads inside EDGEBIC by User Solutions. For the wider index of terms, see the manufacturing glossary; for the states a job passes through, see what is job status; and for the reschedule action that writes many of these entries, see EDGEBIC rescheduling explained.

How it works

Every meaningful change to a plan produces a change log entry, and each entry carries a reason drawn from a fixed set. The reasons are deliberately specific so the history reads clearly rather than as a wall of "something changed."

The reasons are: Initial, for the first time a plan is persisted; Reschedule, for a change the engine produces during a scheduling run; a work-center swap, for a drag-drop move to a different machine; a date override, for a planner dragging a single bar to a new time; Closed, for a job being marked complete; and Reopened, for a completed job being put back into progress. A cancellation reason is reserved for order cancellations.

Because each entry is written after its change lands, the log is append-only history. It never alters the plan; it explains the plan. That separation is what makes it trustworthy. The scheduling engine, the Gantt drag, and the completion action each do the real work, and each leaves a labeled footprint behind.

A concrete example

Think of the maintenance booklet in a car's glovebox. Every service writes one dated line: oil change, brake pads, timing belt. Nobody edits an old line; you just read down the list to understand the car's history. A schedule change log is that booklet for a job.

Take a job that starts life planned on Monday. The first save writes an Initial entry. On Tuesday a machine goes down and the engine replans the shop, producing a Reschedule entry for this job with a new end date. On Wednesday a planner decides the finishing step should run on a different machine and drags it there, writing a work-center swap entry. On Friday the operator finishes the job, writing a Closed entry.

Read those four lines in order and the job's whole week is legible: planned, replanned by a breakdown, hand-moved to another machine, then completed. No line contradicts another, and none was edited after the fact.

How EDGEBIC uses it

In EDGEBIC, the schedule change log surfaces in the Job Audit Trail report, where entries are filtered and color-coded by schedule change type. That lets a planner scan for one class of event, for example every manual date override in a period, without wading through routine engine reschedules.

The distinction between engine-driven and human-driven changes is the practical value. An Initial or Reschedule entry came from a scheduling run; a work-center swap or a date override came from a person acting on the Gantt; a Closed or Reopened entry came from the actuals workflow. When a schedule looks surprising, the log tells you which category of decision produced it, so you investigate the right thing.

Because completed work is never moved by a reschedule, the log also gives you a clean boundary: once a job is Closed, later runs will not silently disturb it, and if it ever does change state, a Reopened entry makes that explicit. To see the reschedule mechanics that generate these entries, read EDGEBIC rescheduling explained; to understand the completion actions behind Closed and Reopened, read planned, in progress, and completed work explained. For a general grounding in the underlying document, see work order.