Marking an operation complete closes it by stamping an actual end date, converting the step from a plan into a recorded fact that every future reschedule must work around. In EDGEBIC by User Solutions completed work is frozen exactly where it happened: the engine never moves it, never recomputes its hours, and plans the remaining work forward from where the job really is, which is why the documentation puts it plainly that completion is a statement rather than a side effect.
This entry is part of the EDGEBIC glossary series; for the broader vocabulary of production planning, see the manufacturing glossary.
How Marking Complete Works
There are two roads to a completed operation, and they meet at the same destination.
The explicit road is stamping an actual end on the operation. A planner does this on the actuals grid, or an operator does it at the shop-floor kiosk by finishing their punch. When completion is recorded without an explicit end time, the actual end snaps to the end of the last day that has logged hours, meaning 23:59 of that day. That snap exists for a specific reason: without it, a step started at 08:00 and completed the same day could end up recorded as finishing at midnight, before it began.
The implicit road is hours. An operation counts as done once its logged hours have fully covered its planned hours, even with no end stamped. The Job View grid, the Gantt shading, and the live progress cards all read it as complete. A step that runs exactly to its estimate therefore closes itself, which is convenient and also the reason a step that finishes slightly under plan can sit open indefinitely while everyone assumes it closed. A bulk actuals load can close operations as their rows land, which is what Mark Complete on Import does.
Above the operation level sits the job. Clicking Complete this Job opens a dialog asking for a completion date and an optional reason. Once confirmed, the header reads that the job is completed, the actuals buttons lock with a message saying no more actuals can be logged, and the job's bars take the completed shade on the Gantt. Reopen Job reverses this when a correction is needed.
The job-level roll-up is deliberately conservative. A job reports an actual end and 100 percent only when every one of its operations is done. Finishing one step early never flags the whole job complete.
A Worked Example
From the documentation's logging walkthrough: a step planned at 11 hours, logged across two days.
Monday, the operator logs 6 hours. Tuesday, they log the remaining 5. Total logged is 11 hours against 11 planned, so the step now reads Complete in the live progress view even though no end was stamped. That is the implicit road working exactly as designed.
The planner then also stamps the end explicitly: double-click the row's Actual End, choose End = Now, and save. Job Progress climbs. Once the following assembly step is done too, the end product rolls up to 100 percent, and the planner presses Complete this Job, gives a completion date, and confirms.
Now consider the reschedule that runs the next morning. The completed step is frozen at the hours and dates recorded, not recomputed from its estimate. An in-progress step keeps its logged hours and only its remaining hours are re-planned. Not-started steps re-plan from the point work really reached. Nothing that was logged is ever moved. This is what makes completion consequential: it is the mechanism by which reality overrides the plan.
How EDGEBIC Uses Mark Complete
The behavior touches several surfaces at once, and knowing which is which prevents most confusion:
- The Gantt moves the bar to its actual position and applies the completed shade, so a glance at the board distinguishes what happened from what is planned.
- The Job View header and Job Progress report recompute actual hours, remaining hours, and percent complete from the schedule roll-up.
- The next reschedule is where completion really pays. Completed operations are frozen at their actual dates and only future work is re-planned. See actuals preservation on reschedule.
- The optimizer respects it too. Its safety strip carries a standing guarantee that completed work is untouched, so an optimizer proposal can reorder future work without ever disturbing what the floor already did.
- A partially completed step is a different case. A step that ran some but not all of its hours before a reschedule is handled by a site policy rather than by the completion rule. See partial completion in scheduling.
- The audit history keeps the edits. Corrections to actuals carry a reason, and vague reasons make later investigations harder than they need to be.
The single most useful habit is treating completion as deliberate. Stamp the end when the work is finished, even when the hours came in under the estimate, because an operation left open is a gap in the record that the roll-up, the reports, and the next reschedule will all faithfully reproduce. The job close-out walkthrough covers the screens involved, and logging actual hours and pieces covers the daily entry that leads up to it. For the underlying date field see an actual date in scheduling.
Marking complete closes an operation by stamping its actual end date, which turns the step from a plan into a recorded fact. From that point the operation is treated as immovable: every future reschedule leaves it exactly where it happened and re-plans only the work that has not been done. Completion is a deliberate statement rather than a side effect, because reports and the scheduling engine both treat it as final.
Yes. An operation also counts as done when its logged hours have fully covered its planned hours, even with no explicit end stamped. The Job View, the Gantt shading, and the live progress cards all read it as complete. Both roads lead to the same place, which is why a step that quietly accumulates its full planned hours will show as finished without anyone pressing a button.
The actual end snaps to the end of the last day that has logged hours, meaning 23:59 of that day. This is what stops a job that started at 08:00 and completed the same day from ending up recorded as finished before it began. If you need a precise end time, stamp it explicitly on the operation row rather than relying on the snap.
Yes, and the route depends on whether the whole job was closed. If only the operation was completed, open the job's actuals and correct the actual end on that row; the next reschedule will pick up the corrected fact. If somebody pressed Complete this Job, the Log Actual and Complete this Job buttons are locked and a banner says so, so you use Reopen Job first, fix the actuals, then complete again. When you edit, give a real reason, because the reason lands in the audit history and the next person reading it needs more than the word fix. The general principle is that recorded work is immovable to the scheduler but never immovable to a person with the right permission; the engine trusts what you logged, so the correction has to happen in the log rather than in the plan.
Mostly training, with one system nuance worth knowing. An operation does count as done once logged hours fully cover planned hours, so a step that runs exactly to plan closes itself. The steps that stall are the ones that finished slightly under plan, where the hours never quite reach the threshold and nobody stamps an end. That is a real gap in the record rather than a display quirk, because the job roll-up only reports an actual end and 100 percent when every one of its operations is done. The habit to teach is that completion is a statement: when the work is finished, stamp it, even if the hours came in under the estimate. The site policy for what happens to the unlogged remainder is a separate setting, and leaving the step open is not a way of avoiding that decision, it just defers it.
Expert Q&A: Deep Dive
Q: An operator marked a step complete an hour early and now the reschedule has planned the next step too soon. Can we undo it?
A: Yes, and the route depends on whether the whole job was closed. If only the operation was completed, open the job's actuals and correct the actual end on that row; the next reschedule will pick up the corrected fact. If somebody pressed Complete this Job, the Log Actual and Complete this Job buttons are locked and a banner says so, so you use Reopen Job first, fix the actuals, then complete again. When you edit, give a real reason, because the reason lands in the audit history and the next person reading it needs more than the word fix. The general principle is that recorded work is immovable to the scheduler but never immovable to a person with the right permission; the engine trusts what you logged, so the correction has to happen in the log rather than in the plan.
Q: Our operators log hours but never press complete, and jobs sit at 99 percent forever. Is that a training problem or a system problem?
A: Mostly training, with one system nuance worth knowing. An operation does count as done once logged hours fully cover planned hours, so a step that runs exactly to plan closes itself. The steps that stall are the ones that finished slightly under plan, where the hours never quite reach the threshold and nobody stamps an end. That is a real gap in the record rather than a display quirk, because the job roll-up only reports an actual end and 100 percent when every one of its operations is done. The habit to teach is that completion is a statement: when the work is finished, stamp it, even if the hours came in under the estimate. The site policy for what happens to the unlogged remainder is a separate setting, and leaving the step open is not a way of avoiding that decision, it just defers it.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
The EDGEBIC Scheduling Glossary Index
A themed index to the EDGEBIC glossary: scheduling engine, capacity and calendars, materials and planning, shop floor, reporting, quoting, and data import terms, defined in plain language.
What Is the Critical Chain in Manufacturing Scheduling?
The critical chain is the longest dependent path through a plan once shared machine contention is counted, not just step precedence. Here is how it differs from the critical path.
What Does Finite Capacity Mean in EDGEBIC?
Finite capacity means the scheduler refuses to book more hours on a machine than that machine actually has. See exactly how EDGEBIC enforces it, day by day and shift by shift.