What should you do before rescheduling production?

Log actuals first, then resolve any pending Gantt drags. A reschedule plans remaining work forward from the last logged position, so stale actuals produce a confident plan built on old reality. Unsaved drags exist only on your screen and are lost by the run. In EDGEBIC by User Solutions those two steps take a few minutes and remove the two most common reasons a run produces dates the floor disputes.

What is the difference between a full and a targeted reschedule?

A full run schedules new jobs and re-plans every unfinished operation across the plant, which is right after a calendar or capacity change. A targeted run re-plans only the jobs you modified since the last run and leaves every other job's plan and reserved capacity exactly as it was. Targeted is the day-to-day choice because it cannot disturb work you never touched.

How do I verify a reschedule did what it should?

Check four things on each critical job. Actual hours in the Job View header must be unchanged. Actual start and end columns on completed rows must match what the floor reported. The job audit trail's newest event should show old and new dates side by side. And the Gantt should no longer flag operations as downstream-changed unless they carry deliberate manual overrides.

Can rescheduling delete data?

No. A reschedule replaces the future plan and keeps all history: actual dates, logged daily hours and pieces, completed rows, and every audit event survive the run untouched. Each run adds an audit entry recording the old and new dates rather than overwriting the previous record, so a sequence of reschedules leaves a readable trail rather than a single current state.

How to Reschedule Production in EDGEBIC Without Breaking Anything

To reschedule production safely in EDGEBIC by User Solutions, log your actuals, resolve any pending Gantt drags, choose the narrowest scope that covers what changed, run, then verify four things on your critical jobs. The run itself is one button. Everything that makes it trustworthy happens on either side of that button, and this post covers both sides in order.

If you are still deciding whether a run is warranted at all, production rescheduling software covers the triggers and the cadence. Here we assume you have decided.

Pre-Flight: Four Checks

1. Actuals are current

This is the one that matters. The engine computes a resume point from the last logged position and plans everything remaining from there. Log Monday's hours on Friday and every run in between planned the plant around Monday.

You do not need perfect data. One honest hours figure per operation per day supplies the resume point. The procedure is in logging actual hours and pieces.

Spot check: open the Job View for two or three jobs you know are running and confirm the actual hours header is not zero.

2. Pending drags are saved or discarded

Bars you dragged but did not save exist only on your screen. The run reads the database, so unsaved changes are silently lost.

Save what you meant. Saved changes are respected by the run: a planned-start pin holds its operation on that date and work center as an actual would, and a saved work center replacement is honored for started and pinned operations. Discard the rest so the engine can re-flow around real decisions rather than half-made ones. See drag and drop rescheduling for what each drag mode commits you to.

3. Short-confirm policy is the one you intend

Under Options, Partial-Confirm Behaviour decides what happens when an operator marked a step complete with fewer hours logged than planned.

Setting	Effect on the run
Trust the operator's Actual End	Unfinished hours are written off; downstream queues behind the stamp
Forward-shift the remaining hours (default)	The gap is re-planned onto the next free slot; downstream queues behind that
Trust Actual End unless flagged	Trust by default; forward-shift only steps flagged on the routing editor

Set this once as a site policy. Changing it between runs makes consecutive schedules disagree for reasons nobody can reconstruct afterward.

4. You know which jobs should move

Write down, or at least think through, the jobs you expect to change. A reschedule that moves jobs you did not expect is either telling you something useful or was run at the wrong scope, and you cannot tell which without a prior expectation.

Choose the Scope

Scope	Where	Use it when
Full	Drive Schedule tab, Schedule and Re-Schedule	A calendar, shift, capacity, or work center change affects everyone, or a batch of new orders needs scheduling
Targeted	Schedule View tab, Re-Schedule after saving drags	Day-to-day corrections on jobs you touched
Single job	Job View tab, Re-Schedule under the Gantt strip	One order drifted and nothing else did

The rule of thumb: use the narrowest scope that covers what actually changed. A full run on a busy plant moves jobs that had no reason to move, and that unnecessary movement is what teaches supervisors to stop reading the printout.

Targeted runs also protect capacity. Jobs you did not touch keep both their plan and their reserved slots, so a correction on one order cannot quietly displace another order's booking.

Run It

Full run. Open the Drive Schedule tab. Click Schedule and Re-Schedule. New unscheduled jobs are scheduled; already-scheduled jobs are re-planned. A Cancel button sits beside it during the run.

Targeted run. On the Schedule View tab, after saving your bar changes, click Re-Schedule. Only the jobs you modified since the last run are re-planned.

Single job. On the Job View tab, the Re-Schedule button under the Gantt strip covers the selected job's context.

While it runs, the engine is doing four things per job: classifying every operation as completed, in progress, or not started; computing the resume point from those actuals; preserving the finished work verbatim; and re-planning the balance against current capacity and calendars. The mechanics are in how EDGEBIC preserves completed work.

Verify: Four Points, Thirty Seconds

Do this on your critical jobs, not on all of them. Two minutes total for a normal day.

1. Actual hours are unchanged

Open Job View and read the hours header. Actual hours must be exactly what they were before the run. Only planned timing moves. If actual hours changed, something is wrong and the audit trail is the place to start.

2. Completed rows still show the logged values

Compare the grid's actual start and actual end columns against what the floor reported. Completed operations must show precisely the values that were logged, to the minute.

3. The audit trail explains the move

Click Job Audit on the Job View tab, or right-click a bar on Schedule View and choose View Audit Trail. The newest event is the reschedule, showing the job's old and new start and end side by side. Below it sit the completions and manual drags that led here.

This is the artifact you want before a customer asks, not after. It is also the fastest way to answer "did anything actually change" when a run looks like a no-op.

4. Downstream-changed flags have cleared

On the Gantt, scan for operations still marked as downstream-changed. After a run these should be gone, because the engine resolved the sequence. Any that remain still carry manual overrides the engine was instructed to respect, which may be exactly what you wanted or may be a pin you forgot to clear.

What Good Looks Like

A concrete run. JOB-2026-0125, three steps, day shift 08:00 to 16:00, with a two-hour queue time between the mill and assembly.

The plan had Saw-1 Monday 08:00 to 12:30, CNC-Mill-1 Monday 12:30 to Tuesday 15:30, Assembly-1 Wednesday 09:30 to 16:00. Reality: a blade change pushed Saw-1 to Monday 09:15 through 14:00, logged at 4.5 hours. Steps 2 and 3 have no actuals.

After the run:

Step	Dates on screen	What happened
1 Cut	Mon 09:15 to Mon 14:00	Untouched history
2 Mill	Mon 14:00 to Wed 09:00	Shifted later; same machine, same hours
3 Assemble	Wed 11:00 to Thu 09:30	Queued behind step 2 plus its two-hour queue, on its own shift calendar

The job's end moved from Wednesday 16:00 to Thursday 09:30. Step 1's bar did not move a minute. Every verification point passes: actual hours unchanged, completed row matching the log, audit entry showing the old and new end, no lingering downstream flags.

That is a successful reschedule. It produced a later date, and the later date is the point.

If the Result Looks Wrong

Three things to check before assuming a defect.

The resume point. An in-progress operation's projected end is its actual start plus its planned duration, and that can sit further out than intuition suggests. Log the real hours on the running step and re-run.

Capacity. A step landing days out even though its predecessor finished today usually means the work center's next free slot really is days away. Check the work center's load before blaming the engine, and consider an alternate work center or a priority change.

The routing copy. A job re-plans against its own frozen routing rather than the master, so a routing edit you made yesterday may not be in play. That is deliberate protection, and adopting the change is a per-job decision covered in working with frozen routings.

For anything that survives those three, rescheduling mistakes covers the configuration traps and the EDGEBIC troubleshooting guide is the wider index.

The Monthly Sweep

Four things accumulate quietly and constrain every run until somebody clears them. Fifteen minutes once a month is enough.

Stale planned-start pins. A pin set three weeks ago to hold a position for a customer visit still holds it. Pins dissolve when a real start is logged, so any pin on an operation that never started is still active. Clear the ones whose reason has passed.

Work center replacements that outlived the outage. A saved replacement routing work to a backup machine is honored on every run. When the original machine is back in service, the replacement is quietly costing you capacity on the wrong station.

Short-confirm flags. If your site policy is trust-unless-flagged, individual routing steps carry flags. Steps that were flagged during a specific problem period rarely get unflagged afterward.

Auto-filled actuals. Days wearing the auto-filled badge are the plan reflected back at you. Sort by source on your busiest work centers and replace what you can still find out.

The tell that a sweep is overdue is the downstream-changed state persisting on the Gantt after a clean run. Those operations are carrying instructions somebody gave the engine and forgot about.

Build the Habit

Log, resolve drags, pick the narrow scope, run, verify four points. On a published cadence, usually once a day before shift start. Steady small corrections beat rare large ones, and a schedule that changes predictably is one the floor will keep reading. The wider case for treating this as an operating discipline sits in what production scheduling is.

Where to Go Next

Production rescheduling software covers when a run is warranted. How EDGEBIC preserves completed work is the guarantee underneath the whole procedure. Rescheduling mistakes covers what goes wrong and why.

For a full narrative of an unplanned event moving through this workflow, see the machine breakdown reschedule walkthrough. The platform overview is the complete guide to EDGEBIC. Bring a live job list to a demo of EDGEBIC and we will run the sequence on your data.