How a Reschedule Uses Last Night's Actuals in EDGEBIC

When EDGEBIC by User Solutions reschedules a job, it does not start over. It reads your logged actuals, works out where the shop really is, and plans only the remaining work forward from that point. This is actuals based rescheduling, and the resume point it computes from last night's shop floor data is the hinge the whole re-plan turns on. Get the actuals in, and the reschedule reflects reality. Skip them, and it plans against yesterday's guess.

This article traces exactly how a reschedule consumes actuals: how it sorts work into zones, how it derives the resume point, and how it forward-shifts the remaining hours. If you want the concept behind the zones first, planned, in-progress, and completed work explained sets it up, and edgebic rescheduling explained gives the wider tour.

Step One: Sort Every Operation Into a Zone

Before it plans anything, the engine classifies each operation of the job by its actuals.

• Completed if both an actual start and an actual end are set. Frozen history.
• In progress if an actual start is set but no end. Logged hours locked; remainder movable.
• Not started if there are no actuals. Fully re-plannable.

There is a subtle fourth case: a step with no actuals of its own that sits before a step that does have them. The engine infers that the earlier step must have run and backfills its actuals from the scheduled dates, tagging them as system-filled so a planner can review them. After that inference, that step is treated as completed too.

The zones are read purely from what the floor logged. This is why how actuals flow into the EDGEBIC schedule matters: the reschedule is only as good as the actuals feeding it.

Step Two: Compute the Resume Point

The resume point is the single most important number the reschedule produces. It is the earliest moment remaining work may begin, and the engine computes it as the maximum of:

• every completed step's actual end date, and
• every in-progress step's projected end (its actual start plus its planned duration).

Whichever is later wins. The engine then sets the job's start-from constraint to that value. From here on, every slot search, every capacity check, and every instance selection begins after the resume point. Not-started steps cannot slide earlier than reality.

This is why a job's tail moves when an early step runs long. If step 1 finishes two hours late, the resume point is two hours later, and everything queued behind it shifts by that amount. The completion date the engine reports is therefore an honest reflection of what the floor actually did.

Step Three: Preserve, Then Forward-Shift

With the zones sorted and the resume point set, the engine builds the output.

Completed steps are re-emitted exactly as they were logged. Their dates, hours, and machine assignments do not change. This is the immutability guarantee covered in why actuals are immutable.

In-progress steps are split logically. The hours already clocked stay on their real days and keep their work center. The remaining balance (planned hours minus logged hours) is re-planned onto the next available slot on that same machine. Internally these are handled as two pieces, but when the run is saved they merge back into one row per routing step per work center, so on your screens you see a single operation whose window now extends to cover the re-planned remainder.

Not-started steps are scheduled fresh from the resume point, queuing behind whatever the in-progress work finishes, against current capacity and calendars.

Short-confirms (an operator marks a step done with fewer hours than planned) are handled by your site's Partial-Confirm Behavior policy: forward-shift the gap by default, or trust the operator's stamp. Either way the logged hours are never invented or discarded silently. See how partial completions carry forward for the detail.

A Worked Example

Job 0125, twenty pieces of Widget-A, three steps, day shift 08:00 to 16:00.

The plan on Monday morning:

Reality: the saw hit a blade change. Step 1 actually ran Mon 09:15 to 14:00, logged at the kiosk. Steps 2 and 3 have no actuals.

You reschedule. The engine:

1. Classifies step 1 as completed. Preserves it at Mon 09:15 to 14:00.
2. Sets the resume point to Mon 14:00, step 1's real end.
3. Re-plans step 2 from Mon 14:00 on CNC-Mill-1: two hours Monday afternoon, eight Tuesday, one Wednesday morning, new end Wed 09:00.
4. Re-plans step 3 after step 2's two-hour queue time: Assembly-1, Wed 11:00 to Thu 09:30.

Result:

The job's end moved from Wed 16:00 to Thu 09:30. Step 1's bar never moved a minute. And the new end is a date you can promise, because it accounts for the real blade change.

Verifying What the Reschedule Did

Thirty seconds of checking after a run on your critical jobs is worth it.

• Open the Job View and confirm the hours header: actual hours must be unchanged by the reschedule. Only the forward timing moves.
• Compare the grid's actual start and actual end columns against what the floor reported. Completed rows must show exactly the logged values.
• Open the audit trail. The newest event is the reschedule, with the job's old and new dates side by side. Earlier events show every completion and drag that led here.

If a step landed later than you expected, the usual causes are a resume point set by an in-progress step's projected end, or a work center whose next free slot really is days out. Check the running step's logged hours and the work center load before assuming a problem. For the identification of constraints that hold capacity, production bottleneck identification helps.

Why This Beats "Wipe and Rerun"

A reschedule that starts from actuals gives you something a full reset cannot: a forward plan anchored to reality. The completed work stays put, the remaining work queues behind where the shop actually is, and the promise dates you hand out are believable. Combined with a daily shop floor daily rhythm, this keeps your plant's plan and its reality tracking closely all week, and it keeps your WIP management grounded in where jobs really are rather than where the old plan left them.

For the full loop from operator punch to updated plan, see the shop floor execution guide, and explore the platform at EDGEBIC.