- Home
- Blog
- Shop Floor Execution
- The Prior-Step Actuals Gate at the Kiosk in EDGEBI…
The Prior-Step Actuals Gate at the Kiosk in EDGEBIC
In EDGEBIC by User Solutions, the prior-step actuals gate is the check that fires when an operator starts or completes a run at the kiosk while earlier steps of the same job have no actuals yet. It surfaces as a warning: "no actual dates logged to prior workcenters, continue." The gate exists to stop a downstream operation from being logged on top of an untouched upstream one, which would leave a job with an out-of-sequence, misleading actuals record. It gives the operator a clean choice at the moment it matters, and it is a quiet but important guard in the shop floor data collection loop.
Work happens in a routing order. Actuals should follow that order too, and the gate is how EDGEBIC keeps them honest when they threaten not to.
When the Gate Fires
The check runs at two moments: when an operator taps Start Run, and again when they tap Complete. In both cases EDGEBIC looks at the other steps of the same job that come earlier in the routing sequence. If any of those earlier steps has no actual start recorded, the gate triggers and the warning appears, listing the missing work centers.
The gate is deliberately narrow. It does not fire when there is nothing to flag. On the very first job started after a fresh schedule run, no prior sibling steps exist to be missing, so the gate is a no-op. It also stays quiet when every upstream step already carries an actual start. The prompt shows specifically when an earlier step in the sequence is blank, which usually means someone is logging a downstream operation before the upstream one was recorded, the classic out-of-sequence entry.
The Two Choices
The warning is a fork with two honest branches.
- Cancel. Stop, and log the earlier operations properly first. This is the honest path. The upstream steps get their real actuals, and the downstream step then logs against a complete history.
- OK, continue. Accept the backfill. EDGEBIC fills the missing earlier steps with their planned values and lets you keep working.
Neither branch corrupts the record silently. Cancel keeps you honest by construction. OK is transparent about what it did, because the backfilled days are marked.
What the Backfill Actually Writes
When you accept the prompt, EDGEBIC back-fills each missing earlier step from its plan:
- Actual start equals the planned start.
- Actual end equals the planned end.
- Actual hours equal the planned hours per day.
Those days are tagged as system auto-filled, and they wear a badge in the Log Actuals grid so they stay recognizable as guesses rather than facts. The backfill lets the operator keep moving instead of being blocked at the kiosk, which matters on a busy floor. But it carries an assumption: that the earlier steps ran exactly as planned. That is only true if they did.
If the upstream saw actually ran two hours long, the auto-filled saw day now shows the planned figure and hides the overrun. Your plan-versus-actual comparison for that step is wrong until you fix it. So the backfill is a stopgap, not a resolution.
Cleaning Up an Accepted Backfill
Every auto-filled day is meant to be revisited. Open the Log Actuals grid on the backfilled step, find the day carrying the auto-filled badge, and replace the planned guess with the real hours or pieces. The moment you change the value, the badge disappears and the day becomes a normal hand-entered entry. The provenance flips from system-filled to user-entered, both on screen and in the underlying record, so anyone reviewing later can tell exactly which days were reconstructed and which were confirmed. For how that badge behaves in the grid, see logging actuals from the planner.
The best practice is simple: prefer Cancel when you can, and if you accept a backfill, treat it as a to-do. Auto-filled days assume the plan happened exactly as written, which is fine as a bridge and wrong as a permanent record.
The Same Handshake Everywhere
The gate is not a kiosk-only quirk. The identical prior-workcenter handshake appears in the planner's Log Actuals dialog when you set an actual start on a downstream step whose upstream steps are blank. The wording, the choice, and the auto-filled tagging are the same, because the two surfaces feed the same actuals model. Whether the trigger is an operator tapping Start Run at the machine or a planner setting a start from the office, the job never ends up with a downstream actual sitting on an upstream blank without a clear, marked record of how the gap was filled.
There is one refinement worth knowing: on the very first job of a new schedule, the gate finds no missing siblings and stays silent. That prevents a spurious warning on work that legitimately has no upstream history yet.
Why the Gate Earns Its Place
Out-of-sequence actuals do real damage. A downstream step logged over an untouched upstream one produces a record where step three finished before step one started, which misleads both the reschedule and the reports. The reschedule computes a resume point from a broken history, and the earned-value and progress figures read against a plan the shop did not follow. The gate makes that gap impossible to ignore. It does not forbid working out of sequence, because sometimes a floor genuinely gets ahead of its paperwork; it forces a decision and records the outcome.
That is consistent with the rest of the platform's approach to actuals: fail loudly, mark provenance, and keep a defensible trail. Completed work is immutable, corrections are audited, and reconstructed values are badged. The prior-step gate is the entry-side member of that family.
The Bottom Line
The prior-step actuals gate stops a job from recording downstream work over an untouched upstream step. When it fires, cancel and log the earlier steps for real, or accept a clearly badged backfill from plan and correct it later. The backfill assumes the earlier steps ran as planned, so treat every auto-filled day as a to-do you resolve in the Log Actuals grid. The result is a job whose actuals follow its routing order and whose reconstructed days are always recognizable. See how the whole capture loop fits together in the shop floor execution guide, and explore the platform at EDGEBIC.
Expert Q&A: Deep Dive
Q: An operator hit the prior-workcenter warning and clicked OK to keep moving. What did that cost me?
A: It back-filled the earlier steps with planned values, tagged auto-filled. That is fine as a stopgap, but it assumes the upstream steps ran exactly to plan. If the saw actually ran two hours long, the auto-filled saw day now hides that overrun, and your plan-versus-actual comparison for that step is wrong. Revisit every auto-filled day: open the Log Actuals grid, find the badge, and replace the guessed values with reality. Editing the value clears the badge and makes the day a real entry.
Q: Why does EDGEBIC gate on prior steps at all instead of just letting operators log whatever they finish?
A: Because a job's actuals are a sequence, and a downstream step logged over an untouched upstream step produces an out-of-order record that misleads the reschedule and the reports. The gate makes the missing history impossible to ignore. It gives you a clean choice at the moment it matters: stop and log the earlier work honestly, or accept a clearly marked backfill you can correct later. Either way the job never ends up with a downstream actual sitting on top of an upstream blank.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.

User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
The Schedule Reconciliation Report in EDGEBIC, Explained
Eight parameter checks over two exception grids. See how EDGEBIC reconciles the plan against the plant and shows only the rows that disagree.
Why a Dependent-Parallel Child Is Exempt From the Over-Booked Check
Three synchronized drills book 24 hours on an 8 hour day. That is real plant behavior, not a capacity breach, and flagging it would make the whole check useless.
Confirming a Sub-Assembly Versus the End Product in EDGEBIC
One dialog, two mechanisms. See why confirming an end product reduces the build directly while confirming a sub-assembly works through ordinary stock netting.
