The good and scrap counters only increment while a run punch is open, so the parts made during first article and run-off are real, in the bin, and numerically invisible. In EDGEBIC by User Solutions that is deliberate rather than a gap, because the same window that decides which hours count as production also decides which pieces count as output. The consequence worth internalizing is that a kiosk count and a physical count will never agree, and you should stop trying to make them.
The rule, in one line
If the current punch is not a run punch, tapping the counters does nothing. Setup phase, paused, machine down: the taps are inert until somebody resumes the run.
Operators discover this the first time they try to log a piece during a changeover and nothing moves. It reads as a broken button. It is not, and the fix is simply to resume the run, but the reason behind it is worth explaining once to a floor rather than leaving people to guess.
The two setup phases that make parts
Look at where the changeover ladder actually puts metal through the machine.
| Setup phase | Does it produce a part? |
|---|---|
| Teardown | No |
| Fixture | No |
| Tools | No |
| First article | Yes, one piece for a dimensional check |
| QA hold | No |
| Run-off | Yes, a final run-up before production release |
Two of the six phases exist precisely to make something. A first article is a part. A run-off produces parts. They go in the bin like any other, and neither of them touches the counters, because both phases sit before the run punch opens.
On a long production run this is a rounding error. On a twenty-piece job it is ten percent of your output. The phases themselves, and the reason each one is timed separately, are covered in how setup phases become setup variance.
Why the rule is right anyway
The temptation is to call this a design flaw and ask for counters that work everywhere. It is worth resisting, because the window is doing real work.
Only run time, and rework, become the job's production hours. Setup, downtime, and idle time are recorded and kept separately, so that nobody's efficiency is judged on a coolant leak. Pieces follow the same boundary.
The payoff is that the two measures are commensurate. Run hours over run pieces gives a rate that describes production and nothing else. Widen the piece window to include the changeover while leaving the hour window alone and that rate becomes a number with no clean meaning: output from one span of time divided by a different span of time. On short runs, where changeover can be half the elapsed clock, a rate contaminated that way would be worthless.
So the counter and the clock agree with each other. Neither of them describes the total physical output of the machine, and that is the trade being made.
Where the undercount travels
Three places, and it helps to know which are affected and which are not.
Daily actual pieces. Good taps become the day's actual piece count, good pieces only, with scrap tracked separately alongside its reasons. Anything made outside the run window is absent here.
The derived side. Where a shop lets one measure derive from the other, an undercount on pieces carries into the derived hours through the operation's rate. This matters most for machines where the floor records pieces and lets hours follow. The mechanics of that conversion are in how hours and pieces convert on the shop floor.
Progress reads. Anything showing how much of the quantity is done inherits the same definition, so a job can look marginally behind on quantity while being exactly where it should be physically.
What is not affected is your rate, for the reason above, and your setup variance, which is measuring the changeover time rather than its output.
What to do instead
Reconcile against the routing, not against the bin. The useful comparison is run hours against run pieces, checked against the standard rate. That comparison is internally consistent and tells you something actionable. Comparing the counter to a physical count tells you only that the changeover made parts, which you already knew.
Settle physical quantity at the operation, not from the running count. The moment that matters for quantity is completion, and that is where a real number belongs.
Adjust deliberately or not at all. The edit-counts dialog replaces the good and scrap totals for the current run, so crediting changeover parts to the job is possible. Do it as a decision with a reason, not as a habit, because a number that is sometimes the run window and sometimes the whole machine is a number nobody can interpret. The lighter-weight correction for a genuine mis-tap is the ten-second piece undo.
Tell the floor what the number is. Half the friction here is an operator believing the kiosk disagrees with him. It does not; it is measuring something narrower than he is. One sentence at training time prevents a year of low-grade distrust, and it fits naturally alongside the good, scrap, and rework distinction in good, scrap, and rework counts explained.
The takeaway
Piece counters are live only during a run punch, so parts produced during first article and run-off are physically real and numerically absent. That is the same boundary that keeps setup and downtime out of production hours, and it is what makes run hours over run pieces a clean rate rather than a mixture of two different spans of time. The cost is that the kiosk total is not a physical count and never will be. Reconcile it against the routing and the standard rate, settle quantity at operation completion, treat any manual top-up as a deliberate decision, and make sure the floor knows what the counter is measuring before somebody decides it is broken. See the whole punch-to-plan cycle in the shop floor execution guide, and the engine those actuals feed on the EDGEBIC product overview.
Because the current punch is not a run punch. The good and scrap counters are live only while a run punch is open, so tapping them during a setup phase or while the job is paused does nothing. Resuming the run makes them work again. This is not a fault to report; it is the same window rule that governs which hours count as production, applied to pieces.
They exist physically and they are not counted. First article runs the first piece for a dimensional check and run-off is a final run-up before production release, so both phases genuinely put material through the machine, but both are setup phases and piece counters only increment during run. The parts are in the bin and outside the count, which is why a kiosk total and a physical count will not agree and should not be expected to.
No, and trying to is the mistake this rule causes. The counter and the production clock use the same window, so they agree with each other, and neither of them describes the whole physical output of the machine. Reconcile the kiosk count against the routing instead: run hours against run pieces gives you a rate you can compare to the standard. Reconcile the bin at the operation or the job, where the physical quantity actually matters.
Expert Q&A: Deep Dive
Q: Our operator swears he made 22 pieces and the kiosk says 20. Is somebody wrong?
A: Probably not, and the two extra parts are usually the ones that came off during the changeover. First article puts a piece through for a dimensional check and run-off is a final run-up before the job is released to production, so a changeover routinely produces one to three real parts before the run punch ever opens. Piece counters only increment during a run punch, so those parts land in the bin and never touch the count. It looks like a discrepancy and it is actually the system working as designed. The right response is to stop treating the kiosk total as a physical inventory number and to explain to the floor what it is: a measure of production output during production time. If the extra pieces are good and you want them credited to the job's quantity, that is a deliberate adjustment somebody makes with the edit-counts dialog, which replaces the good and scrap totals for the current run, and it should be a decision rather than a habit, because once you start topping up counts by hand the number stops meaning any one thing.
Q: We make short runs where the changeover produces a meaningful share of the parts. Does this rule distort our numbers badly?
A: It distorts one number and improves another, which is worth separating. The number it distorts is quantity produced per operation, because on a run of twenty pieces, losing two to the setup window is a ten percent understatement of physical output, and that matters if somebody is using kiosk counts to decide whether the job is finished. The number it improves is your rate, which is the more useful one. Because production hours and production pieces are measured over the same run window, dividing one by the other gives a clean pieces-per-hour figure that is not contaminated by changeover time, and on short runs a rate polluted by setup would be almost meaningless. So the practical answer for a short-run shop is to lean on the rate for capacity and standards work, and to settle physical quantity at the operation completion rather than from the running count. It also raises the value of getting your setup standards right, since on short runs changeover is where most of the variability lives, and phase-level setup timing is exactly what the kiosk is capturing while the piece counters sit idle.
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 Schedule Reconciliation Report in EDGEBIC, Explained
Eight parameter checks over two exception grids. See how EDGEBIC reconciles the plan against the plant and shows only the rows that disagree.
Why a Dependent-Parallel Child Is Exempt From the Over-Booked Check
Three synchronized drills book 24 hours on an 8 hour day. That is real plant behavior, not a capacity breach, and flagging it would make the whole check useless.
Confirming a Sub-Assembly Versus the End Product in EDGEBIC
One dialog, two mechanisms. See why confirming an end product reduces the build directly while confirming a sub-assembly works through ordinary stock netting.