A Kiosk Punch Did Not Appear in the Report: Causes and Fixes

When a kiosk punch does not appear in a report, the cause is almost always that the punch is still open, that its punch type is not counted as productive hours, or that the report window does not cover the date the hours landed on. EDGEBIC by User Solutions rolls closed run and rework punches into the daily hour breakdown that production and utilization reports read, and everything outside that rule is reported elsewhere.

This post is the detailed version of the missing-punch symptom in the EDGEBIC troubleshooting guide. For the mechanism, how punches roll up into daily actual hours covers the rollup and what a punch type is covers the categories.

What You Are Seeing

An operator worked a shift and used the kiosk. The punch history drawer for that operation shows the taps. But the daily production report, the utilization report, or the job's actual hours show less than the operator worked, or nothing at all for that date.

The punch record and the reported hours are two different things, and the gap between them is where the answer lives.

Why It Happens

Cause 1: The punch is still open. A punch is created when the operator taps a button and closed when the next punch starts or the operation is completed. An open punch has no end time and no hours stamped on it, so it contributes nothing to the rollup. If a shift ends without anyone tapping complete and no later punch closes it, that punch stays open and the hours never materialize. This is the single most common cause of a whole shift disappearing.

Cause 2: The punch type is not productive time. Only run and rework punches feed the daily actual hours. Setup, teardown, down, and idle are recorded on the punch for reason analysis and for the availability and performance components of OEE, but they never flow into the productive-hours total. A shift that was mostly changeover and a breakdown reports very few productive hours, which is correct and is exactly the number the variance reports are meant to show.

Cause 3: The hours landed on a different date. The rollup assigns hours to a calendar date. A shift that crosses midnight can put part of its hours on the following day. A single-day report window then misses them entirely.

Cause 4: A double tap produced a zero-length punch. If the same button is tapped twice in quick succession, the resulting punch has effectively no duration. Any zero or negative duration is clamped to zero rather than stored as a negative number, so the punch exists in the history but carries no hours.

Cause 5: The report reads punches, not hours, or the reverse. Operator count on the shift production report comes from distinct operator names on punch records. Hours entered by a planner through the log actuals screen, or typed against the schedule, produce hours with no punch behind them. That combination reports real hours with an operator count of zero.

Cause 6: The rollup has not been rebuilt after an edit. A supervisor punch adjustment corrects the punch record. The daily breakdown is rebuilt from the punches, so an adjustment is reflected once that rebuild runs for the operation.

Cause 7: The hours belong to a component step. The per-day production reports count parent-step rows. Component and sub-assembly rows written elsewhere are not swept up by the kiosk rollup, by design, so hours recorded against them appear in the job rather than in the plant-wide daily totals.

How to Fix It

1. Open the punch history for the operation and look for an open punch. A punch with no end time is your answer. Completing the operation, or starting the next punch, closes it and stamps the hours.
2. Read the punch types in that history. Add up only the run and rework time and compare that to the reported hours. If they match, the report is correct and the missing time is setup, teardown, down, or idle.
3. Widen the report window by a day on each side. If the hours reappear, they landed on the adjacent date and the original window was too tight.
4. Look for a zero-duration punch. A punch with the same start and end is a double tap. A supervisor adjustment corrects the intended hours.
5. Have a supervisor adjust the punch where the record is genuinely wrong. Adjustments are append-only, so a correction is written as a new record rather than overwriting history. How to adjust an operator punch walks the dialog.
6. Rebuild the daily breakdown after adjustments. The reported hours follow the punches once the rollup runs for that operation.
7. Check whether the hours came from the kiosk at all. An operator count of zero next to real hours means the entry came from the schedule or the log actuals screen rather than the shop floor.

A Worked Example

An operator runs a paint booth for eight hours. The kiosk history shows a two hour setup with a color-change reason, four hours of run, a one hour down punch with a breakdown reason, and one more hour of run.

The daily production report shows five hours on that booth. That is correct: four plus one hour of run time. The two setup hours and one down hour are on the punch records with their reason codes, where the availability side of OEE reads them. Nothing was lost, and the five hour figure is the productive output the variance calculation is meant to compare against plan.

How to Prevent It

• Make completing the operation the last action of every shift. An operation left running is the main source of vanished hours, and the habit costs one tap.
• Train operators on what each punch type means. Setup logged as run inflates productive hours and hides changeover cost. Run logged as setup does the reverse.
• Reconcile daily rather than weekly. A one day gap between the shift and the report is easy to reconstruct. A two week gap is not.
• Watch for zero operator counts on rows with real hours. That pattern maps exactly to hours entered outside the kiosk, and it tells you where adoption is thin.
• Widen the window before escalating. A single-day report on a night shift shop will produce this symptom regularly and needs no fix beyond a wider range. If the report is empty across a whole window, a report shows no rows for a date range covers that case instead.