How Kiosk Punches Roll Up Into Daily Actual Hours in EDGEBIC

In EDGEBIC by User Solutions, daily actual hours are a rollup: closed run and rework punches are grouped by the date they started on, and each group becomes one row of actual hours and good pieces for that operation on that date. The punches are the raw evidence of what happened at the machine. The daily rows are the derived summary that the scheduler, the Gantt bars, and every actuals-based report actually read. Knowing which is which is the difference between trusting a number and arguing about it.

This is the quiet middle layer of shop floor data collection. Operators never see it. Planners see it constantly, because it is what appears in the Log Actuals grid and what a reschedule consumes. Here is exactly how the rollup is built.

Two Levels: Punches and Daily Rows

A punch is one uninterrupted stretch of a single work state, opened and closed by an operator tap. A single eight-hour shift on one operation might produce six punches: a setup, a run, a down with a reason, another run, an idle, and a final run. That granularity is what makes downtime analysis possible.

A daily row is coarser on purpose. It carries one date, the planned hours the scheduler allocated to that date, the actual hours worked, the actual good pieces produced, and the remaining hours implied by the difference. One operation running across three days produces three daily rows, no matter how many punches sit underneath them.

The Rollup, Step by Step

When an operator taps Complete Operation, or when a supervisor asks for a rebuild after a correction, EDGEBIC runs the same procedure.

One: load every punch on the operation. All of them, open and closed, of every type.

Two: keep only closed run and rework punches. An open punch has no end time yet, so it has no hours to contribute. Setup, teardown, idle, and down punches are set aside here. This is the single most consequential rule in the whole process, and it is covered in the next section.

Three: group by start date. Each surviving punch is filed under the calendar date its clock opened on. A punch that crosses midnight books entirely to its start date and is never split.

Four: sum hours and good pieces per date. Hours add up straightforwardly. Pieces are good pieces only: scrap is recorded on the punch with its reason but never counted as output, and rework pieces are counted on their own field. See good, scrap, and rework counts explained for where each count lands.

Five: compute the rate for the date. If the date has both hours and pieces, the rate is the observed one: pieces divided by hours, rounded. If one of them is zero, EDGEBIC falls back to the rate snapshotted on the last closed punch, so the row still carries a sensible number instead of a blank.

Six: upsert. Dates that already have a daily row get updated. Dates that do not get a new row inserted.

Seven: zero the orphans. If a date used to have punches and no longer does, because a punch was removed or re-dated, its row is zeroed rather than left holding hours nothing supports.

Why Setup and Downtime Stay Out

The exclusion of setup, teardown, idle, and down time from daily actual hours is deliberate, and it is worth defending because it surprises people the first time they see it.

The daily rows feed capacity and progress math. When a planner looks at an operation that was quoted at 7 hours and sees 7.53 actual hours logged, the comparison is meaningful only if both numbers measure the same thing: productive work. If a 1.25 hour coolant failure were folded in, the operation would look 30 percent over standard when the work itself ran clean, and the next quote would be padded for a problem that was never a labor problem.

The lost time is not discarded. It sits on its own punches with its reason code, ready for a Pareto review, for the availability factor in OEE, and for setup variance. Two different questions, two different numbers, one honest record underneath both.

A Worked Two-Day Example

Paint Booth 3, one operation, logged hours-led.

The rollup produces two rows: Tuesday at 6.00 actual hours (1.75 plus 4.25) and Wednesday at 3.08. Total logged production: 9.08 hours against 7.00 planned. The planner sees a 2.08 hour overrun and, one click into the punch history, sees the 1.25 hour coolant event that explains most of it. Neither number had to be reconstructed from memory at shift end.

Rebuilding After a Correction

Because the daily rows are derived, a correction never has to be applied twice. A supervisor edits a punch in the history drawer with a mandatory reason, the original value is preserved beside the correction, and a rebuild recalculates the affected dates from the current punch set. See how a supervisor corrects a kiosk punch for the audit trail that edit leaves behind.

One category of daily row is protected during a rebuild: sub-assembly split rows, which the planner maintains through the Log Actuals dialog rather than the kiosk. A kiosk rebuild leaves those untouched, so a machine-side correction can never wipe component detail entered in the office.

Why the Plan Cares

The daily rows are what the next reschedule reads. Logged hours on a date tell the engine how much of the operation is already behind you, remaining hours tell it how much to plan forward, and the actual end tells it where the successor step can begin. Completed work is never moved, so the rollup is not just reporting: it is the boundary between history and plan. That mechanism is walked end to end in how a reschedule uses last night's actuals.

The Bottom Line

Punches record what happened, minute by minute and state by state. Daily actual hours summarize the productive part of it, one row per operation per date, with good pieces and an observed rate alongside. Only run and rework time crosses that boundary, which keeps productive hours honest while preserving every lost minute for the analysis that should own it. See the whole loop in the shop floor execution guide, or look at the platform at EDGEBIC.