How Sub-Assembly Actuals Are Logged Separately in EDGEBIC

In EDGEBIC by User Solutions, a daily actuals row can carry a component marker: rows without one belong to the operation itself, and rows with one record how much of that day's work went into a specific component. That split is what lets a step that fabricates several parts keep honest per-part times without pretending to be several operations, and it is why a machine-side correction can never overwrite detail entered in the office.

Most operations never need it. When you do need it, knowing which rows are which saves an afternoon of reconciling totals that disagree.

Two Kinds of Daily Row

Every scheduled operation gets one daily row per calendar date it works: planned hours, actual hours, actual good pieces, and the remainder. Those are the operation's own rows, and they are what the kiosk builds from punches. See how punches roll up into daily actual hours.

An operation that produces distinct components can carry additional rows on the same dates, each tagged to one component. They sit alongside the operation's rows rather than replacing them.

The presence of the marker is the whole distinction, and it drives every rule that follows.

The Kiosk Never Touches Component Rows

When an operator taps Complete Operation, or when a supervisor asks for a rebuild after correcting a punch, EDGEBIC recalculates daily hours from the current punch set. That rebuild is destructive by design: it recomputes every affected date from scratch so a corrected punch flows straight through.

It is also carefully scoped. The rebuild only rewrites rows with no component marker. Component rows survive untouched.

That scoping matters more than it sounds. Punches at a machine have no idea which component a given minute went into: an operator taps Start Run, not Start Run On Bracket B. If the rebuild treated component rows as its own, a routine supervisor correction on Thursday would silently erase a planner's component breakdown from Tuesday, and nobody would notice until a cost review months later. Different sources of truth, different rows, no collisions.

Who Maintains Which

The division of labor follows from the same logic.

The floor owns the operation's hours. Operators punch, the rollup builds the operation's daily rows, and supervisors correct punches when something was mis-tapped. See how a supervisor corrects a kiosk punch.

The planner owns the component detail. Component rows are entered and maintained in the Log Actuals dialog, where the planner works date by date with the full context of what the job is producing. See logging actuals from the planner.

Neither surface has to coordinate with the other, because neither writes the other's rows.

Why Totals Do Not Double Count

The obvious risk with two levels of detail is adding them together. A step logged at 6.0 hours with component rows of 4.0 and 2.0 could easily be read as 12.0 hours of work.

The end-product rollup avoids this by construction: it aggregates operational steps only, excluding sub-assembly rollup rows and component splits, so a job's total hours count each hour once. See rolling a job's actuals up to the end product for how the rollup is built and why it withholds a job's actual end until every operational step is finished.

The practical rule when you are reading a grid rather than the rollup: decide first whether you are looking at operation rows, component rows, or both, before you sum anything. A grid that shows both is showing you detail, not a total.

On the Live Routing Diagram

The Actual Live screen draws the job's routing as a diagram with a progress card on every node. A sub-assembly node is a special case there, because it can stand for more than one scheduled step: the node rolls up every row belonging to that sub-assembly so its card shows combined progress.

That creates one small ambiguity, and EDGEBIC resolves it with a question rather than a guess. Double-click a sub-assembly node to log actuals and you are asked which child step you mean before the dialog opens. Pick the step, and the flow from there is identical to logging from the job view: the same closed-operation check, the same actual-start capture, the same dialog.

A pure material node, by contrast, tracks no actuals at all. There is nothing to log against a step that only consumes stock.

A Worked Example

Operation 30 on a weldment job fabricates two brackets, left and right, on the same fixture across Tuesday and Wednesday.

The operation logged 9.5 hours, which is the number the reschedule and the utilization variance both read. The component detail tells the cost side that the left bracket took 5.0 hours and the right took 4.5, which is exactly what a quoting review needs and exactly what punches alone could never say.

On Thursday a supervisor corrects Tuesday's punch from 6.0 to 6.4 hours. The operation's Tuesday row updates. Both component rows stay as entered, waiting for the planner to redistribute the extra 0.4 hours if it matters.

The Bottom Line

Component detail lives on its own daily rows, marked as such, entered by the planner, and protected from the kiosk's punch rebuild. The operation's own hours stay the single number that drives scheduling and variance, and the job rollup counts each hour once by excluding the splits. Use component rows where the parts genuinely differ, skip them where they do not, and never sum both levels together. See the full loop in the shop floor execution guide, or explore EDGEBIC.