How to Check What a Scheduling Run Changed in EDGEBIC

To check what a scheduling run changed in EDGEBIC, read the confirm dialog before the run, watch the failure dialog after it, compare the grid date columns, and open a job's audit trail for the full history. A run is never a black box: EDGEBIC by User Solutions tells you the scope before it starts, reports any job it could not plan, and keeps a timestamped event history for every job. Knowing where each of those lives is how you hand dates to the floor with confidence.

This is a verification task. For the run itself, read how to run the scheduler in EDGEBIC; for what happens inside a pass, inside an EDGEBIC scheduling run goes deeper. All task guides are at the EDGEBIC how-to hub.

Before You Start

• You have just run, or are about to run, the scheduler.
• You know roughly which jobs you selected, so you can tell expected changes from surprises.
• You can open a job's audit trail from the row's audit button on the grid.

Check 1: The Confirm Dialog (Before the Run)

The Confirm Scheduling dialog is your first and cheapest check on scope. It appears after you press the schedule button and states the split: how many jobs are new (first-time scheduling) and how many existing jobs will be rescheduled. Read the number. If it is larger than the count of rows you meant to select, you probably answered yes to the Schedule All Orders prompt, which only appears when nothing is ticked. Answer no, fix your selection, and start again. Nothing is written while the dialog is open.

Check 2: The Failure Dialog (After the Run)

If any job in the run could not be planned, the Scheduling Failure Dialog opens on its own. It lists each failing job with:

• The category of failure, such as a missing routing or an inactive work center.
• The affected job.
• A short summary and a fix hint.

The failing job is dropped from the run and the rest completes normally, so a single bad order never aborts the pass. Read the dialog when it appears, because it does not reopen on the next run. Fix the underlying issue, then re-run the affected jobs.

Check 3: Compare the Grid Dates

After the run, the jobs that moved are the ones whose date columns differ from before:

Jobs you did not select should read exactly as they did before. A useful habit on important runs is to note the dates on the jobs that matter before you run, so the comparison afterwards is against a real baseline rather than a memory.

Check 4: The Job Audit Trail (Full History)

For the definitive record of what happened to one job, open its audit trail from the row's audit button. It lists every event in the job's life in chronological order: created, scheduled, rescheduled, actuals posted, completed and reopened. Job-level events and per-operation events both appear, so you can see both when the whole job was re-planned and when a single step's actuals were written. If a job you did not expect to move shows a different date, the audit trail settles it: a reschedule event with the run's timestamp means it moved, and no such event means your memory of its old date was wrong.

What Did Not Change (By Design)

Some things a run never touches, and confirming this is part of checking the result:

• Recorded work is never moved. Completed and in-progress operations stay exactly where they are; only remaining work is re-planned.
• Unselected jobs keep their schedules and their reserved capacity.
• A populated due date is never moved. A blank one is filled once, then left alone.
• The job's routing snapshot is frozen on its first schedule, so a later master-routing edit does not silently rewrite a running job.

Common Mistakes

Skipping the confirm dialog. It is the one moment the run tells you its scope before acting. Clicking through it without reading the job counts throws away your best early warning that the selection is wrong.

Missing the failure dialog. It appears once and does not come back on the next run. If jobs are missing from the Gantt afterwards, they may have failed silently to your eye but loudly in a dialog you dismissed.

Comparing against memory instead of a baseline. "I'm sure that job was on Tuesday" is not evidence. Note the dates before an important run, or use the audit trail, which carries timestamps.

Assuming a moved unselected job is a bug. It almost always means the job was included after all, usually via the Schedule All Orders prompt. The confirm dialog's job count is the tell.

What to Do Next

If a job moved further than you expected, how to see why a job is late is the diagnostic. To keep future runs narrow so there is less to check, how to schedule a single job covers scope discipline. For the wider case on stable, trustworthy plans, getting your team to trust the schedule is worth reading, and the EDGEBIC product page covers the platform.