Eight Production Actuals Mistakes (and the Symptom Each One Produces)

Production actuals mistakes rarely announce themselves. The schedule keeps producing dates, the reports keep producing numbers, and nothing errors out. What changes is that the numbers stop describing the shop. Below are eight mistakes that show up repeatedly in real EDGEBIC by User Solutions deployments, each with the symptom it produces and the fix that removes it. Every one is documented behavior rather than a hypothetical.

If you have not seen the underlying pipeline, how actuals flow into the schedule explains what each mistake is corrupting.

1. Logging Weekly Instead of Daily

Symptom. Reschedules produce dates the floor immediately disputes. Downstream operations sit queued behind positions that were true on Monday. Supervisors start working from a printed sheet.

Cause. A reschedule computes a resume point from the last logged position and plans everything remaining from there. Log on Friday and every reschedule between Tuesday and Friday planned the plant around Monday's picture.

Fix. Five minutes per work center at shift end. You do not need piece counts, reason codes, or a terminal to fix this one: one honest hours figure per operation per day supplies the resume point, and the resume point is what drives the reschedule. Everything else is refinement.

This is the mistake to fix first because it makes the other seven matter less. A shop logging daily with rough numbers beats a shop logging precisely once a week, every time.

2. Treating the Backfill Prompt as a Speed Bump

Symptom. Half the daily rows in the grid wear an auto-filled badge. Variance reports look suspiciously clean. Nobody can say whether a routing is accurate.

Cause. When you log an operation while an earlier one on the same job has no actuals, EDGEBIC names the missing steps and asks. Continuing copies planned values onto them: planned start becomes actual start, planned end becomes actual end, planned hours become actual hours, all tagged as system filled. Click through it habitually and a growing share of your history is the plan reflected back at you.

Fix. Cancel is the honest path when you can still find out what happened. When you do accept, treat the badge as a queue: the flag clears the moment somebody types a real value over it. And if the same upstream station generates the prompt every day, the real fix is coverage at that station, not discipline at the next one.

The badge is doing you a favor. A system that backfilled silently would leave you with no way to tell measured hours from assumed ones.

3. Editing the Parallel Sibling Instead of the Primary

Symptom. You correct hours on a work center row, save, and the old values come back on the next save anywhere in that job.

Cause. A routing step running on parallel work centers produces two rows sharing one step. The rule is one directional and absolute: the sibling follows the primary. Dates copy one to one, hours scale by the configured factor, and days the primary lacks are zeroed on the sibling. It runs job wide after every actuals save.

Fix. Correct the primary. The mirror propagates the change to the sibling within the same save. If you cannot tell which row is primary, the parallel work centers post covers how the pair is configured.

4. Expecting Setup and Downtime in the Daily Hours

Symptom. A machine was occupied 07:50 to 16:00 and the day shows 6.00 production hours. Someone concludes the data is missing hours.

Cause. Only run and rework time enters the daily rollup. Setup, teardown, idle, and machine-down time are recorded in full on their own punches, where they feed changeover variance and downtime analysis. In the documented paint booth example, 0.92 hours of setup, a 1.25 hour coolant stoppage, and 15.92 hours of overnight idle are all captured and all correctly excluded from the 6.00 hour figure.

Fix. Read the right report. Production hours answer "how much of this operation is done." Setup and downtime hours answer "why did it take so long," and they live in the shift handoff summary, the punch history, and the downtime reporting. Blending them would make both questions unanswerable, which is the same separation overall equipment effectiveness depends on.

5. Never Stamping an Actual End

Symptom. An operation shows Running indefinitely. Job progress stalls short of 100 percent. The end product roll-up refuses to report an actual end.

Cause. Logging hours does not close an operation. EDGEBIC counts a step as done when its actual end is stamped, or when logged hours have fully covered planned hours. An operation planned at 11 hours that genuinely needed 9 satisfies neither condition, so it stays open forever.

Fix. Stamp the end. Double-click the row's actual end cell, use End = Now or Use Sched End, save. If the same operation is consistently finishing under its planned hours, that is a routing conversation rather than a logging one.

The job-level completion rule is strict for the same reason: every operational step must be done before the job reports complete, so one early finish never flags the whole job.

6. Inverted Dates From a Date Picker

Symptom. A save is refused with a message that the end is not after the start.

Cause. Almost always a date picker sitting on the wrong year, occasionally the wrong month. The pair is rejected at every entry point rather than stored, because an operation whose end precedes its start corrupts every downstream calculation that reads it as complete.

Fix. Correct the date and save again. This is the one mistake on the list that stops you rather than quietly persisting, which is the point of the guard.

Related and often confused: an actual end that reads 23:59 is not an error. When completion is recorded without an explicit time, the end snaps to the end of the last day with logged hours, which is what stops a same-day job from finishing before it began. Actual dates look wrong traces the four origins of a suspicious date.

7. Vague Reasons and Blank Operator Names

Symptom. The history drawer is full of entries reading "fix", "correction", and "per Dave". Nobody can reconstruct a variance six months later. An audit question takes a day to answer.

Cause. Two habits. Edits to previously reported values require a reason, and an empty reason cancels the save, so people type a character to get past it. And the operator field on a terminal punch is a free-text name with no login behind it, so a blank one is anonymous forever.

Fix. Write the sentence you would want to find. "Operator tapped complete one hour early, corrected from time study sheet" is the documented example and it is the right length. The history is append-only: corrections are added, never erased, so a good reason keeps its value permanently. The whole argument for that discipline sits in audit-ready scheduling.

8. Ignoring the Routing-Changed Banner

Symptom. An operator runs a job to instructions that no longer match the routing engineering updated last week. Or the reverse: the floor works to a change the schedule knows nothing about.

Cause. A terminal compares the live routing against the copy that was in force when the job was scheduled, and raises a non-blocking banner when the work center, setup time, cycle time, or queue time differs. It is easy to acknowledge without reading.

Fix. Read the listed fields, acknowledge, and tell the planner. The banner exists because a scheduled job carries its own frozen routing copy on purpose, which is covered in routing snapshots explained. The banner is the handshake between the two versions, and skipping it is how a shop ends up running one routing while the schedule plans another.

A Ninth: Expecting Piece Counts From a Routing With No Cycle Time

Symptom. Piece fields stay stubbornly at zero no matter what the operator does, or auto-calculation refuses to derive pieces from hours.

Cause. The pieces-per-hour rate is computed from the routing step's pieces per unit and its cycle time, scaled by the work center's efficiency factor. If either input is zero, the rate is zero, and EDGEBIC records the hours while leaving the piece fields blank rather than inventing a number.

Fix. Fill in the routing. For work centers where hours are the primary measure this is harmless and you can ignore it. For work centers where the shop counts pieces, a zero rate means the counter is decoupled from any conversion, so every piece figure has to be typed by hand and no variance comparison is possible.

There is a related tell on the terminal: piece counters that will not increment usually mean the current punch is a setup or paused state rather than a run. Pieces only count during run time, by design.

The Pattern Underneath

Seven of these eight mistakes share a shape: a system behavior that is correct gets read as a defect because the reason for it is not obvious at the moment it bites. Setup hours are excluded on purpose. Siblings are overwritten on purpose. Auto-filled days are badged on purpose. Inverted dates are refused on purpose.

The eighth, weekly logging, is the only one that is simply a bad habit, and it is also the one that costs the most. Fix that first, then work down the list as symptoms appear.

Where to Go Next

Shop floor actuals tracking covers the model these mistakes distort. Logging actual hours and pieces is the procedure done right. How actuals flow into the schedule traces the pipeline each mistake interrupts.

For symptoms that survive this list, the EDGEBIC troubleshooting guide is the wider index, and the complete guide to EDGEBIC puts actuals in context. Bring a month of your own logged data to a demo of EDGEBIC and we will tell you which of the eight you have.