An Operation Shows Running Forever Though All Hours Are Logged

An operation stays in progress after every hour has been logged because completion in EDGEBIC by User Solutions is a deliberate statement, not a side effect of reaching an hours total. A step closes on one of two events: someone stamps its actual end, or the logged hours fully cover the planned hours. When the plan budgeted more hours than the job really needed, the second road is never reached, and nobody took the first one.

That is the whole cause, and the fix is one field. The rest of this post is about why the symptom is worth caring about rather than ignoring, because an operation left open costs more than an untidy grid.

This is the detailed version of one symptom family in the EDGEBIC troubleshooting guide. If your problem is that logged hours did not reduce the remaining work after a reschedule, that is a different fault with different causes, covered in actual hours did not reduce the remaining work.

What You Are Seeing

The operation's daily rows are filled in. The operator has moved to the next job. The bar still shows the in-progress state on the Gantt, the step still reads Running on the live view, the job header still shows remaining hours, and the job will not reach 100%. Nothing errored, and nothing is missing.

Why It Happens

Cause 1: Planned Hours Are Higher Than the Work Needed

This is the common one. A step planned at 11 hours that genuinely took 7 has 7 logged hours against an 11 hour plan. The automatic completion road requires logged hours to cover planned hours, so it never triggers. The step waits for a human.

How to tell: add the logged daily hours and compare with the planned hours on the step. If the logged total is lower and no more work is coming, this is your cause.

Cause 2: Nobody Stamped the Actual End

An operation can also be finished exactly on plan and still stay open, simply because the closing action was never taken. At the kiosk that action is the Complete Operation tap. In the planner it is the Actual End field. Logging hours does not close anything by itself, and neither does completing the piece count.

How to tell: the operation's Actual End reads as not set, while the hours look right.

Cause 3: The Job Is Waiting on This One Step

This is not a separate cause so much as the consequence people notice first. A job reports an actual end and 100% complete only when every operation is done. One open step holds the whole job open, which is why the symptom usually arrives as "the job will not close" rather than "this step will not close."

How to tell: the job header refuses to reach 100% and one step in the grid has no actual end.

The Fix

Stamp the end explicitly:

1. Open the Job View tab and select the job.
2. Double-click the operation's Actual End cell in the grid, or right-click the bar and take the Edit Actual Dates path.
3. Use End = Now for the current moment, or Use Sched End to accept the planned finish.
4. Save.

Two guardrails apply. The end must be strictly later than the actual start, and an inverted pair is blocked at every entry point, because an end before a start is always a typing error rather than a real event. And when completion is recorded without an explicit time, the end snaps to 23:59 of the last day that carries logged hours, which is why a step started at 08:00 and completed the same day can never finish before it began.

To undo a completion, clear the actual end. The operation returns to in-progress and can be logged against again.

Why an Open Step Is Not Harmless

It is tempting to leave it, because the hours are recorded and the hours are what the reports read. Three things say otherwise.

The reschedule keeps planning the difference. Completed operations are frozen where they happened. An in-progress operation keeps its logged hours and has only the remainder re-planned. A step with 7 logged hours against an 11 hour plan therefore carries 4 phantom hours into every reschedule, booked on a machine that is actually free. On a bottleneck that gap is real capacity you are hiding from yourself.

Every progress figure stays wrong. Percent complete is actual hours over planned hours, and the job roll-up will not reach 100% while one step is open. That flows into the job progress picture, the late jobs list, and the delivery view, so a finished job can sit on a late list because of one unstamped field.

The record loses its meaning. Completed work is treated as immovable fact everywhere in the product. A step that never says it finished never gets that protection, and a month later nobody can tell whether it ended early, ended on time, or is still running.

Preventing the Next One

Make the closing action part of the routine. At the kiosk, Complete Operation belongs in the same habit as clocking off. In the planner, stamping the end belongs in the same visit as logging the last day's hours. Logging actual hours and pieces covers both entry points.

Fix routings that are consistently heavy. If the same step needs manual closing on every job, its planned hours are wrong. Correct them and the step starts closing itself, and your capacity picture gets more honest at the same time.

Read the open steps weekly. A job whose steps are all finished except one that has no end is a five-second fix if you catch it in the same week, and an argument if you catch it at month end. How actuals are tracked covers what each surface is showing you and where.