What Is a Rate Variant in Actuals Tracking?

A rate variant is a day whose real pieces-per-hour differs from the rate the operation was planned at. Every operation carries a rate, and that rate converts between hours and pieces during actuals entry. When a day records both hours and pieces, the ratio between them is the rate that day actually ran at. The difference between that and the planned rate is the variant, and a consistent one is a message about the routing rather than about the day.

This entry belongs to the EDGEBIC by User Solutions glossary. For the wider vocabulary, see the manufacturing glossary, and for the underlying number, pieces per hour in work center capacity.

How the Rate Works During Actuals Entry

Hours and pieces are two views of the same work, and a rate is what connects them. The daily actuals grid has one row per calendar day of the operation's window, with the scheduled hours and pieces, the actual hours and pieces, the rate, and a source marker showing whether a person typed the day or the system filled it from plan.

The Auto Calc Hours (derive missing side from Rate) checkbox governs the conversion. Leave it ticked and you type one side only: enter six hours and the pieces fill in from the rate, or enter the pieces and the hours derive. This is the normal way to work, because most shops genuinely count one side and estimate the other. The same conversion is available on a bulk load as Auto-Calculate Hours in an actuals import.

Untick it and both columns become independent, so you type the hours you worked and the pieces you counted. That is when a day stops being a conversion and starts being an observation, and it is the only way the grid can report a rate the estimate did not produce.

Alongside the per-day rate, the grid reports an effective rate for the operation, which is the practical answer to "what is this job actually running at?"

Why the Numbers Diverge

A routing rate is a forecast made before anything was cut. The floor is where reality arrives. Material from a different batch machines slower, an operator gets quicker through a long run, a fixture turns out better than the estimate assumed, or a machine is not running at its usual speed.

One divergent day is noise and is not worth chasing. The same divergence across several days is a pattern, and patterns in the rate have consequences beyond the paperwork, because the planned rate is what reserved the capacity in the first place.

A Concrete Example

An operation is planned at 35 pieces per hour, so 500 pieces is a little over fourteen hours of run time.

Monday, the operator logs six hours and counts 180 pieces, with Auto Calc unticked so both numbers are real. That day ran at 30 pieces per hour. Tuesday, eight hours and 244 pieces, which is 30.5. The job is consistently running about fifteen percent under the estimate, most likely because of the material batch.

Wednesday, the operator logs five hours and no count. Auto Calc is on, so the conversion uses the operation's planned rate of 35 and fills in 175 pieces, which is around twenty more than this job has been managing on any day so far. The grid shows the day's rate as the planned one, and the contrast with Monday and Tuesday is visible on screen.

Nothing about this breaks the schedule: the operation's planned hours and its place on the board are unaffected, because the rate governs the conversion between hours and pieces, not the capacity the plan reserved. What it affects is whether the piece numbers can be trusted, and whether anyone notices that this routing is planned optimistically.

When the job closes, two days of counted evidence is a solid argument for revisiting the cycle time on that product. That is a deliberate change to the routing, made with the job's numbers in hand, not a mid-shift reflex.

How EDGEBIC Uses It

The rate appears wherever hours and pieces meet. It sits in the Log Actuals grid as the rate for each day, with the operation's effective rate reported below the grid. It appears as a Rate (Pcs/Hr) column in the Job View operation grid, next to the scheduled and actual pieces. And it appears in the kiosk's manual entry day grid, which is the same day-by-day layout the planner uses, so a typed-in day converts exactly as an office-entered one does.

The practical habit is the one the grid is designed around: pick the side your shop actually counts, log that side consistently, and let the rate derive the other. Hand-typing both sides inconsistently across days is what produces an effective rate nobody recognizes, and it is a far more common cause of a strange number than any real production problem.

The neighboring definitions are the daily hour breakdown whose rows carry these values, the shift breakdown that splits one of those days into the shifts that produced it, pieces per hour as the underlying unit, the actual entry mode that decides whether a terminal leads with hours or pieces, and work center efficiency which scales the planned rate. For the mechanism, see how hours and pieces convert on the floor, and for the walkthrough, how to log actual hours and pieces.

An estimate contradicted by two days of counted production is not the best number available. Recording both sides honestly is how you find the better one.