Reading the Schedule Audit Trail: Who Moved This Job in EDGEBIC

Every drag, reschedule, and machine swap on the EDGEBIC Gantt writes to a production schedule audit trail, so the question every plant eventually asks, "who moved this job, when, and by how many days," has a recorded answer rather than a shrug. EDGEBIC by User Solutions logs schedule changes as they happen, and surfaces them in a per-job history and two plant-wide reports. This post shows where the record lives and how to read it back.

The visual scheduling pillar guide covers making changes; this post covers the record those changes leave behind.

Every Save Leaves a Trace

The audit trail is not a feature you switch on; it is a byproduct of normal editing. Every time you press Save Changes on the Gantt, EDGEBIC writes a change-history event. Reschedule runs, machine swaps, and completions are recorded too. The result is a running log of what happened to the schedule, tied to jobs and timestamps, that you never have to maintain by hand.

That log matters because a schedule is a shared, moving thing. Jobs slip, planners reroute, the engine re-plans, and a week later someone asks why a customer's date changed. Without a record, the answer is guesswork. With one, it is a lookup. This is the same accountability that makes any serious production scheduling practice trustworthy: the plan is not just current, it is explainable.

One Job's Full History

When the question is about a single job, two entry points give you its whole story:

• View Audit Trail, on the right-click menu of any bar for that job, opens the full change history: every reschedule, every drag, and every completion event, in order.
• Job Audit, a button on the Job View tab header, opens the same per-job history from the single-job cockpit.

Both answer "everything that happened to this job." When a slip is the product of several changes stacked over a week, the per-job trail is where you see the sequence: one reschedule here, a manual drag there, a completion in between. Reading them in order tells you not just that the job moved, but the chain of decisions that moved it. Job View is the natural home for this, since it is the single-job cockpit where you already read the job in depth.

Plant-Wide: Two Focused Reports

When the question is broader than one job, two reports read the change log from different angles.

Reschedule History answers "who moved jobs, when, and by how much." Set a date range and it lists the reschedule events in that window:

This is the report you open when a job slipped and nobody remembers touching it. The days-delta quantifies the move, and the actor and reason columns turn "it just moved" into "this person rescheduled it on Tuesday for this reason."

Resource Replacement Audit answers "which jobs were moved to a different machine, and to where." It lists every operation whose work center changed, with the original machine, the new machine, the actor, and the timestamp. Because a machine swap on the Gantt saves as the Resource Replaced state and stores the original work center, the report can reconstruct every reroute precisely, which is far faster than hunting the Gantt for rerouted bars.

Two Investigations, Worked

A customer's job slipped four days. Open Reschedule History, set the range to the week the slip appeared, and find the job. The row confirms the four-day delta and names the actor and reason. If the slip came from several changes, switch to that job's View Audit Trail to see the full ordered chain, and you know whether it was one reschedule, a manual drag, or a combination that produced the slip.

Operations keep turning up on unexpected machines. Open Resource Replacement Audit and read the from-and-to machine columns. Each row names the operation, its original machine, its new machine, and who made the swap. In minutes you have the full list of reroutes, which you can then cross-check against the resource load view to see whether any of them pushed a machine over capacity.

Why the Trail Completes the Picture

The Gantt shows you the schedule as it is now. The audit trail shows you how it got that way, and the two together are what let a plant trust an interactive schedule. Under the override-and-warn model, planners are given real power to drag, reroute, and reschedule, and that power only stays safe when it is accountable. The trail is that accountability: every deliberate change is recorded, attributable, and quantified, so the freedom to edit the plan never turns into a mystery about who edited it.

There is one honest limit worth knowing. The change log records events from the point the audit capability was in place forward, so it will not reconstruct history from before then. Everything from that point on, though, is captured automatically, with no discipline required of the planner beyond doing their normal work.

Read the trail as the natural close to the editing story. You stage changes with Save and Discard, you commit dates with Save, you re-plan with Re-Schedule, and every one of those actions leaves a recorded footprint you can read back. That is what turns a schedule from a snapshot into an accountable, explainable plan.

See the full EDGEBIC platform, or bring a job that slipped last month to a demo and trace exactly who moved it, when, and why, with US.