Why a Completed Step Frees Its Operator in EDGEBIC

In EDGEBIC by User Solutions, a completed operation books no operator hours on a reschedule: the labor ledger is rebuilt from scratch each run, unstarted work still consumes the pool, and finished work is released. It is a one-sentence rule with a large consequence. Without it, every job your shop finishes would permanently reduce the labor capacity the scheduler believes it has, and after a good quarter the plan would insist nobody is available for anything.

This article explains why the rule exists, what it does and does not touch, and how to read a schedule that refuses to place a skill-constrained job.

The Labor Pool in One Paragraph

When a routing step names a required skill, the scheduler has a second constraint to satisfy beyond the machine. For each candidate day and shift it asks how many free hours the qualified pool has: every operator certified on that skill, rostered on that shift and weekday, and not on time off, minus whatever hours are already booked against them. If the pool has room, the work can be placed and the hours are booked. If it does not, the step slides to the next staffed window. See how operator skills gate work center assignment.

That ledger is the thing at stake. Every entry in it is a claim on someone's future time, and its accuracy decides whether tomorrow's plan is real.

Three States, Three Behaviors

On a reschedule, EDGEBIC classifies every existing operation into one of three states and treats the labor pool accordingly.

The middle row is the one people expect least and it follows the same logic as the other two. A partly finished operation has some labor behind it and some ahead of it. The part behind it lives in the punch record. The part ahead of it still needs a person, so it still charges the pool. See how partial completions carry forward.

Why Finished Work Must Let Go

Consider the alternative for a moment. Suppose completed operations kept their bookings.

Monday's welding job books six hours of Joe. It finishes Monday. Tuesday's reschedule rebuilds the plan, and Joe still carries six booked hours from a job that is over. Wednesday another job finishes and books more. By the end of the month Joe's ledger is full of work he has already done, and the scheduler concludes he has no capacity left. The next skill-constrained job slides a week for no reason anyone can see on the floor, because the shortage is entirely in the record.

This is not a hypothetical class of bug. It is what happens whenever a forward-looking reservation is allowed to survive the event it was reserving for. The cure is structural: clear the ledger, rebuild it from the current plan, and let only future work contribute.

The same reasoning applies to machine capacity, where completed allocations release the machine hours they consumed while the completed operation itself stays exactly where it was.

Nothing About the Completed Record Changes

Releasing the booking is not the same as forgetting the work, and it is worth being precise about the boundary.

The completed operation keeps its actual start and actual end. It keeps every daily hour logged against it. It keeps the operator name on each punch, the pause reasons, the piece counts, and any supervisor corrections with their original values preserved alongside. None of that is touched, now or ever, which is the guarantee described in why actuals are immutable.

What is released is only the forward claim. The plan stops holding Thursday open for a job that ended Monday.

That separation is the same one described in planned crew versus who actually worked: bookings are a projection with a short lifespan, punches are history with none.

A Worked Example

One certified operator, Joe, on Day Shift. Eight hours per day.

Monday's plan. Job A books 6.0 of Joe's hours for Tuesday. Job B needs 4.0 hours of the same skill and finds only 2.0 free on Tuesday, so it slides to Wednesday. That is the constraint doing its job correctly.

Tuesday happens. Job A runs and the operator taps Complete Operation at 15:30. The punch record shows 6.4 productive hours under Joe's name.

Tuesday night's reschedule. The ledger is cleared and rebuilt. Job A is complete, so it books nothing. Joe's Wednesday is untouched and his Tuesday is no longer reserved by anything. Job B, still unstarted, books its 4.0 hours on Wednesday as planned. If a rush job had arrived needing Tuesday evening coverage, the pool would now correctly show room.

Job A's row on the Gantt did not move by a minute, and its 6.4 logged hours are exactly where they were.

When a Skill Job Still Will Not Place

Because stale bookings cannot accumulate, a refusal to place skill-constrained work almost always has one of three ordinary causes, and they are quick to check in order.

Certification. Expired or inactive certifications are filtered out before the scheduler ever sees them, and a certification that expires partway through the horizon is treated as expired for the whole run. If a person vanished from a pool, check expiry dates first.

Roster coverage. The pool only counts people rostered on that shift and weekday. A shift nobody is rostered on has a pool of zero no matter how many certified operators you employ. See how the shift operator roster works.

Time off. A recorded absence removes that person from the pool for those dates, and on a small pool one absence is enough to slide a job. See how operator time-off reshapes the schedule.

The Bottom Line

The labor ledger is rebuilt on every scheduling run, unstarted work charges it, and completed work releases what it once held. That keeps your apparent labor capacity honest indefinitely, while the completed operation's own record, its dates, hours, operator, and reasons, stays permanently untouched. Plan against the pool, report against the punches, and let finishing a job actually give the time back. See the whole execution loop in the shop floor execution guide, or explore EDGEBIC.