Shop Floor Actuals Tracking in EDGEBIC: What Gets Captured and Why

Shop floor actuals tracking is the capture of what really happened on each operation: when it started, how many hours ran on each calendar day, how many good pieces came off, and when it finished. In EDGEBIC by User Solutions, those facts are recorded next to the plan rather than on top of it. The scheduled dates are never overwritten, so every screen can show plan and reality side by side, and the next scheduling run can plan the remaining work forward from where the job actually is.

That sounds obvious. It is not how most shops operate. A schedule that is never told what happened degrades into a wish list within about three days, and the planner ends up defending dates that the floor stopped believing on Tuesday. This post explains the data model behind actuals in EDGEBIC: what a single actual consists of, the three ways it arrives, why setup and downtime are deliberately kept out of production hours, and what the whole thing rolls up to.

What an Actual Actually Is

An operation in EDGEBIC carries four separate pieces of reality, and they are captured independently.

The per-day split matters more than it looks. An operation planned for eleven hours across Monday and Tuesday is not one number, it is a row per day. A reschedule needs to know that Monday's six hours are locked to Monday and that only the balance is still owed. A weekly total cannot express that.

Two guard rails apply at every entry point. An actual end must be strictly later than the actual start, so an inverted pair is refused before it can persist and corrupt downstream planning. And an actual start is written once: if a planner recorded a start before the operator reached the terminal, the first kiosk punch will not overwrite it.

Three Ways Reality Reaches the Schedule

There is one data model and three doors into it.

The kiosk. A touch terminal at the machine, bound to one work center and one physical machine instance. Every tap opens or closes a punch, meaning one uninterrupted stretch of setup, run, pause, or down time. Timestamps come from the shared clock when the tap lands, so operators never type times. The full operator workflow is covered in the shop floor execution guide.

The planner grid. The Log Actuals dialog, one row per calendar day of the operation's window, with columns for scheduled hours, actual hours, actual pieces, and the rate. This is how a shop with no terminals runs, and how a planner corrects anything after the fact.

Manual entry at the terminal. The same day grid, reachable from the kiosk, for the shift where tap-as-you-go was not possible.

All three write the same records and all three land in the same append-only history. There is no second-class path.

Why Setup and Downtime Are Kept Out of Production Hours

Every punch carries a type, and only two of the six contribute to an operation's daily production hours.

Take the two-day paint booth job from the product documentation. Day one records 0.92 hours of setup, 1.75 hours of run, a 1.25 hour coolant stoppage, then another 4.25 hours of run. The daily production figure for that day is 6.00 hours, being the two run blocks. The 15.92 hours the machine sat idle overnight are recorded and never counted. The planner therefore reads 9.08 productive hours across two days against a plan of seven, and can point at the 1.25 hour machine reason code as the visible part of the gap.

Keep those buckets separate and your availability and performance numbers stay meaningful, which is the same discipline behind overall equipment effectiveness. Blend them and every metric downstream is quietly wrong.

Downtime is never anonymous. A pause or a scrap event always carries a reason code, chosen from four categories: machine, material, quality, and waiting. Sixteen default codes ship in those categories, and you can add work center specific codes that appear alongside them. A scrap piece cannot be recorded without a reason, by design, because a scrap Pareto with an "unknown" bar at the top is not analysis.

Hours and Pieces Are Two Views of One Job

Each operation carries an effective rate in pieces per hour, computed from the routing step's pieces per unit and cycle time, scaled by the work center's efficiency factor. A step at 0.14 hours per piece yields roughly 7.14 pieces per hour.

With auto-calculation on, you log the side your shop actually counts and the other derives. A machine shop counting parts logs pieces; a fabrication cell counting clock time logs hours. Both end up with a complete record.

The rate is snapshotted when the work starts. Change the routing next month and last month's records still show the rate that was in force, so historical reports stay accurate. That is also why a routing with no cycle time produces a rate of zero and a blank piece field rather than an invented number.

Observed rate is the useful output. The documented CNC example logs 42 good pieces over 7.53 hours, an observed 5.58 pieces per hour against a standard of 7.14. That gap is a question worth asking, and it only exists because the two quantities were captured independently.

What a Changeover Looks Like in the Data

Setup deserves its own paragraph because it is where most shops discover their standards are wrong.

A changeover at a paint booth switching from white to black is captured as six ordered phases: teardown, fixture, tools, first article, quality hold, and run-off. Each is its own record with its own elapsed time, and each freezes the routing's setup standard and the product that ran previously on that machine.

A documented run of that changeover produces 0.33 hours of teardown, 0.17 fixture, 0.50 tools, and 0.33 first article. Total actual setup: 1.33 hours against a 0.75 hour standard, a variance of 0.58 hours. The teardown alone consumed nearly half of what the standard allowed for the whole changeover.

That is a specific, actionable finding, and it exists only because the phases were captured separately. A single "setup took 1.33 hours" figure tells you the standard is wrong; the phase split tells you which part of it. The same data feeds sequence-dependent changeover analysis, because the previous product is recorded alongside.

Every Number Knows Where It Came From

Actuals carry provenance. A day's value is either user entered or system filled from the plan, and the grid shows which through an auto-filled badge in the Source column.

System fill happens in one specific situation. If somebody logs a downstream operation while an earlier operation in the same job has no actuals at all, EDGEBIC warns before continuing. Accept the prompt and the earlier steps are filled from their planned values so the sequence stays coherent; those days wear the badge. Edit one and the badge clears the moment the value changes, because it is now a fact rather than an assumption.

That single flag is what separates "we know this happened" from "we assumed this happened," and it is the first thing to check when actual dates look wrong.

Two Behaviors Worth Knowing Up Front

Parallel steps follow their primary. A routing step running on parallel work centers appears as two rows. You log only the primary. The sibling's dates mirror it one to one and its hours scale by the configured factor, automatically, on every save. Edit the sibling directly and the next save on that job overwrites it from the primary again. Correct the primary and the fix propagates. See parallel work centers for why the pair exists at all.

Completion is a statement, not a side effect. Logging hours does not close an operation. An operation counts as done when its actual end is stamped, or when its logged hours have fully covered the planned hours. If you complete on the same day you started without giving an explicit time, the end snaps to 23:59 of the last day that has logged hours, which is what prevents a same-day job from appearing to finish before it began.

What It All Rolls Up To

Actuals are captured per operation, but planners ask about jobs. EDGEBIC maintains one roll-up against the job's end product: first operation to start, hours and pieces summed across operations, and a percent complete computed as actual hours divided by planned hours.

The completion rule is strict on purpose. A job reports an actual end, and 100 percent, only when every operational step is done. Finishing one step early never flags the whole job complete. That roll-up drives the Job View hours header, the Job Progress report, and the dashboards, so all three agree.

When You Need This, and When You Do Not

Actuals tracking earns its keep when any of the following is true.

• Jobs run longer than a shift, so "started" and "finished" are not the same conversation.
• Routings have four or more operations, so a slip at step two has to be visible at step five before it hurts.
• You reschedule more than once a week, because a reschedule is only as honest as the position it resumes from.
• Customers ask for dates you intend to keep, which is the whole argument in job shop on-time delivery.

A single-operation shop running same-day work can live without it. Everyone else is choosing between measured reality and a confident guess.

One thing actuals never do on their own: move the plan. Recording six hours on Monday changes no dates anywhere. The plan for remaining work changes when a reschedule runs, and then completed work stays exactly where it was logged. That separation is deliberate, and it is what makes the numbers trustworthy enough to reschedule against. For the wider context of what a schedule is and what it commits you to, see what production scheduling is.

Where to Go Next

Three companion posts complete this chapter. Logging actual hours and pieces walks the fields and dialogs step by step. How actuals flow into the schedule traces one punch from tap to re-planned date. Actuals logging mistakes covers the eight traps that make good data look wrong. Actual live monitoring draws the same logged progress onto the job's routing diagram as a read-only view that changes nothing.

For where actuals sit among the platform's other mechanisms, see the complete guide to EDGEBIC. To see it against your own routings, bring a job and a week of floor data to a demo of EDGEBIC and we will log it together.