How Hours and Pieces Convert on the Shop Floor in EDGEBIC

EDGEBIC by User Solutions converts between hours and pieces using an effective rate in pieces per hour, so a day's actuals always carry both a time figure and a piece figure even when only one was recorded. The rate comes from the routing step, and it is frozen onto each punch when it opens. This bidirectional conversion is what lets an hours-driven machine and a piece-driven machine feed the same shop floor data collection model without anyone doing arithmetic by hand.

Some operations are naturally timed and some are naturally counted. A long paint cure is an elapsed clock; a stamping press is a piece count. EDGEBIC does not force one metric on both. The terminal captures both at every machine, you record the side that fits the work, and the other derives so the plan and the reports always have a full picture.

The Effective Rate

The conversion hinges on one number, the effective rate:

effective rate (pieces/hour) = pieces per unit / cycle time

The pieces-per-unit and cycle time both come from the routing step that runs at the machine, which is where piece-rate math lives rather than on the work center record. Once you have the rate, both directions follow:

• Pieces = hours x rate
• Hours = pieces / rate

So a step running at 7.14 pieces per hour turns a logged 6 hours into roughly 43 pieces, or a logged 43 pieces into roughly 6 hours. The operator captures one; the system supplies the other.

Hours-Led, Pieces-Led, and Both Recorded

Which side leads is a convention a shop adopts per operation, not a per-machine setting:

Hours-led suits work where time is the honest metric and a piece count is a byproduct. Pieces-led suits work where the count is what matters and the time is inferred. Recording both suits operations where you want each captured directly and the gap measured, which is useful input for performance analysis.

The terminal does not need to know which you have chosen. It captures both at every machine: during a run the elapsed clock advances on its own, and the good and scrap counters are there to tap. The convention asserts itself when the day is logged, through the Auto Calc Hours control in the daily actuals grid. Ticked, it derives the missing side from the rate; unticked, both columns become independent. The concept is covered in what is an actual entry mode.

Why the Rate Is Frozen at Punch Open

The effective rate is snapshotted onto each punch the moment it opens. This matters because routings change. If a process engineer edits a step's cycle time next month to reflect a faster tool, you do not want last month's completed punches to silently recompute their derived pieces against the new number. Freezing the rate keeps historical records stable: every punch reports the quantities it was actually captured with. Report accuracy over past work no longer depends on the routing staying untouched forever. This is the same immutability principle that governs actuals across a reschedule.

When the Rate Is Zero

If a routing step has no cycle time or no pieces-per-unit, there is nothing to compute a rate from, and EDGEBIC records the rate as zero rather than inventing one. The consequences are honest:

• Where hours are the recorded truth this is fine. Hours are measured rather than calculated, and the derived pieces simply stay at zero until the routing carries a real cycle time.
• Where pieces are the recorded truth it means the counts are decoupled from any rate. They are still captured and kept, but no hours are derived from them.

The fix is always the same: give the routing step a real cycle time and pieces-per-unit, and conversion resumes on new punches. Nothing about the frozen historical punches changes.

The Observed Rate: Standard Versus Reality

There is a second rate worth understanding: the observed rate a day actually ran at. When a day has logged both real hours and real pieces, EDGEBIC computes the observed rate as pieces divided by hours for that day. This is what the day genuinely achieved, and it can differ from the routing standard.

Consider an eight-hour CNC run that produced 42 good pieces in 7.53 recorded hours:

• Standard rate from the routing: about 7.14 pieces per hour.
• Observed rate for the day: 42 / 7.53, about 5.58 pieces per hour.

The gap is not an error; it is the story. A 1.5-hour quality hold ate into the productive time, so the machine made fewer pieces per hour than the standard predicts. That variance is precisely what a planner wants surfaced, because it points at a real event with a documented cause. See how those piece counts feed the schedule once the day rolls up.

A Worked Example

Two work centers, one job, two conventions.

Paint-Booth-3, hours-led. A cure has no meaningful piece count, so the elapsed clock across a two-day run with a mid-job pause is the number that matters. The day's productive hours roll up from run time, no counters were tapped, and the planner reads the operation by its hours.

Press-2, pieces-led. The operator taps a piece counter as parts come off. With an effective rate of 120 pieces per hour, a logged 600 pieces derive to 5 hours. The plan gets both the count that was captured and the hours the system computed.

Same platform, same rollup, two honest metrics, and neither operator did any conversion math.

The Bottom Line

Hours and pieces are two views of the same work, and EDGEBIC converts between them with an effective rate drawn from the routing step. You record the side your shop genuinely counts, the other side derives, and the rate is frozen onto each punch so history stays accurate through later routing edits. A zero rate is recorded honestly rather than faked, and the observed rate on a finished day surfaces real variance against the standard. That is how a timed machine and a counted machine feed one clean model for finite capacity scheduling. Explore the whole loop in the shop floor execution guide, or see the platform at EDGEBIC.