How a Supervisor Corrects a Kiosk Punch in EDGEBIC

In EDGEBIC by User Solutions, a bad kiosk punch is never edited in place. A supervisor corrects the hours, pieces, or reason through the history drawer, and the system records the change as a separate append-only adjustment while the operator's original punch stays exactly as it was. That design is the point: the record of what happened on the floor is a fact, and a correction is a second fact stacked on top of it, not an erasure. This is shop floor data collection treated as an audit trail rather than a scratchpad.

Every shop has mis-punches. An operator taps Complete a shift too early, fat-fingers a piece count, or picks the wrong reason tile in a hurry. What matters is not that the mistake happened but that the fix leaves a clean, defensible record. This article walks the correction path end to end so you know exactly what each edit writes.

Why Actuals Are Not Edited in Place

A production punch is one uninterrupted stretch of a single work state, opened and closed by an operator tapping the kiosk. Once closed, its start time, end time, computed hours, and piece counts describe a moment that already passed. Overwriting those values would destroy the original signal, and it would leave no way to answer "what did the operator actually enter, and who changed it?"

So EDGEBIC keeps two layers. The punch is the operator's record. A correction sits beside it, carrying what changed, the value before, the value after, who made the change, when, and a mandatory reason. Nothing is deleted, and the correction is kept forever alongside the original. For the wider rule behind this, see why actuals are immutable in EDGEBIC.

What a Correction Records

Every correction captures the same shape, whatever the field:

Because the same shape covers an hours change, a piece count, and a swapped reason, the drawer reads back as one running list of everything that happened to the day, in order, whether it was a tap or a correction.

The Correction Path, Step by Step

The supervisor never touches raw data. The flow is deliberately narrow:

1. Open the History drawer on the kiosk bound to the machine that carries the bad punch.
2. Use the Run, Setup, Down / Idle, and Edits filters to reach the closed punch for the day in question.
3. Correct the field: the hours, the good or scrap pieces, or the reason.
4. Type a reason. If the reason is empty, the save is canceled.
5. Save. The correction is kept alongside the original punch, which is left exactly as the operator closed it.

The daily totals then rebuild from the corrected punch set. That distinction matters: punches are the source, but the scheduler and the reports read the day's rolled-up production hours, so a correction is only useful once those totals reflect it. They do, automatically, which is why a corrected punch shows up on the planner's screens without anyone re-entering anything.

A Worked Correction

Carlos tapped Complete at 13:30 instead of 14:30. The run punch closed at 4.83 hours instead of the true 5.83, and the day's rollup showed 4.83.

The supervisor opens the drawer, filters to Run, finds the punch, and corrects the hours from 4.83 to 5.83 with the reason "operator tapped Complete one hour early, corrected from time-study sheet." What the drawer then holds is:

The day's rolled-up hours rebuild from 4.83 to 5.83. The original punch is unchanged. The 5.83 is now what every plan, report, and reschedule reads. The correction is a permanent, explained part of the record, which is exactly why one clean operation record matters.

Operators Get a Small Correction of Their Own

Not every fix needs a supervisor. Right after any piece tap, an Undo button appears for about ten seconds and takes the last count back, so a fat-fingered piece count can be pulled back on the spot. Crucially, the undo itself is logged and supervisors can see it in the drawer: an operator cannot silently hide a miscount, only correct it in the open. For totals that are wrong beyond that window, Edit Counts replaces the run's good and scrap counts outright.

Corrections That Cannot Drift

Two invariants keep the trail honest. First, adjustments are append-only, with no delete path. To reverse an earlier correction a supervisor writes another adjustment carrying the counter-value, so the drawer holds the full sequence of changes forever. Second, a parallel work center's actuals always follow their primary, so you never correct a mirrored sibling row directly: fix the primary and the mirror re-propagates on the next save.

The planner side follows the same rule. Editing a previously reported value in the Log Actuals dialog also demands a reason and writes an adjustment against the day, so a correction typed from the office is audited identically to one made at the machine. See logging actuals from the planner in EDGEBIC for that path.

Reading the Result

Once corrected, the schedule reflects reality and the drawer explains how it got there. Because none of this moves the plan by itself, the corrected hours only reshape remaining work on the next reschedule, where completed steps stay frozen at their real dates. Corrections upstream of that are visible, attributable, and reversible only by another visible correction. That is the whole contract: the floor's numbers can always be trusted, and the story of every edit survives with them.

For the broader picture of how captured actuals feed planning, start with what is production scheduling and the EDGEBIC kiosk and actuals guide, or bring the whole thing together at the EDGEBIC product overview.