When the Kiosk Queue and the Floor Disagree

When the kiosk's NEXT UP panel names one job and the cell is running another, the disagreement is information rather than a fault, and the kiosk deliberately gives the operator no way to resolve it. A shop floor queue disagreement has about five causes, each with a different owner, and telling them apart in thirty seconds is a skill worth teaching every supervisor.

The temptation is to treat the queue as advisory: the plan says one thing, the floor knows better, everyone gets on with it. That works for a shift and fails over a month, because a floor running a private sequence produces punches the plan cannot interpret and dates nobody can defend. The better habit is to read the disagreement, name its cause, and route it to whoever can actually close it.

What NEXT UP Actually Claims

The idle screen shows the first queued job for the bound work center, with its job number, product, customer, scheduled start, a due label, and a priority. COMING UP lists the next few behind it in queue order. That is the whole claim: this is the order the last scheduling run produced for this machine.

It is not a claim that the order is optimal, and it is not a claim that it is current. It is current as of the last time the terminal read the database, which is why the Refresh button exists. See what an operator sees at the kiosk for the full panel layout.

What the kiosk will not do is let anyone change it. There is no re-sequence, no reassign, and no job search. Those are planner actions, and keeping them off the terminal is the reason the plan has one author. A cell that could re-order its own queue would be able to break the dates of cells it cannot see, and nothing in the record would say who did it.

The Five Disagreements

The pattern across all five is worth stating plainly: four of the five are resolved somewhere other than the terminal, and in three of them the underlying cause is data the plan never received. A queue that keeps arguing with the floor is usually a queue being fed stale reality.

The First Cause Is Almost Always Missing Actuals

If a shop reports only one disagreement, it is this one: the screen offers a job the cell already ran.

The mechanism is direct. Rescheduling plans the remaining work forward from your last logged position, so an operation with no logged actuals is an operation the engine still believes is waiting. It gets re-planned onto the machine's next free slot, which is often right now, and there it sits at the top of the queue looking wrong. See how a reschedule uses last night's actuals.

The fix is not at the terminal. It is upstream in time: log the day before the next scheduling run. A cell that punches daily rarely sees this disagreement at all, which is the strongest practical argument for the daily habit. See the daily rhythm of a kiosk-run shop.

The wrong move here is genuinely harmful. Punching the finished job again to make the screen agree writes a second set of actual hours onto work that already happened, and daily actuals are last-write-wins, so the fabricated day can overwrite the real one.

When the Plan Is Right and the Floor Is Blocked

The second cause looks identical on the screen and is completely different underneath: the plan says start, and the cell physically cannot.

Usually the upstream step was reported complete when it was not, or a prior operation was auto-filled from plan rather than reported. Days written by the system from the plan carry a visible badge for exactly this reason, so a supervisor investigating a blocked start should look for it: see the auto-filled actuals badge explained. If the badge is on the upstream day, the plan is repeating a guess about work that may not have finished.

Here the honest response is to leave the queue alone, correct the upstream actuals, and reschedule. The floor's contribution is the observation, not the fix.

The Setup-Grouping Disagreement Is a Modeling Gap

The third cause deserves separating out, because it is the one shops live with for years.

A cell that always groups jobs by material, color, or fixture is applying a real economic rule the plan does not know about. The scheduler produced its order from the information the routing gave it, and if the changeover cost is not in there, no amount of rescheduling will produce the grouped order.

Treating this as a queue problem guarantees it recurs every week. Treating it as a routing problem ends it. Until the model catches up, the interim answer is to have the planner sequence the group deliberately so the plan and the floor agree on paper, which keeps the punches interpretable. If your queue disagreements are almost all of this kind, see how to auto-resequence a work center queue after a drag.

The Hot Job That Never Rose

The fourth cause is the most political and the easiest to diagnose.

Job priority in EDGEBIC is a plain positive number, and lower sorts first. A job that everyone in the building calls urgent but that carries the same number as everything else is, to the scheduler, ordinary. Nothing about a phone call from a customer reaches the plan by itself.

So when a hot job sits mid-queue, the question is not why the scheduler ignored it. The question is whether anyone changed its priority or its due date. If the answer is no, the plan is behaving correctly and the disagreement is entirely on the human side. If the answer is yes and it still sits low, that is a genuine scheduling question with a genuine answer: see my high priority job scheduled behind a lower one.

Meanwhile, if the floor runs it anyway, they should punch it as run. Reality in the punch record is always better than tidiness.

An Empty Queue Is a Binding Question First

The fifth case is not really a disagreement about order, but operators report it the same way.

A kiosk session is bound to one work center and one machine instance, and the idle screen offers only work queued at that exact pair. A terminal pointed at the neighboring lane will report an empty queue with complete accuracy while work piles up three feet away. So the first check is Switch WC to confirm the binding, then Refresh.

If the binding is right and the queue is still empty, the plan genuinely has nothing there in the current window, and that is a planner question with two usual answers: the job was never released, or it was scheduled onto a different work center than the floor expects.

The Escalation Rule Worth Writing Down

Give the floor a two-step rule and nothing more, because a longer rule will not survive a busy shift.

Step one: tap Refresh. If the plan has already been corrected, the right queue appears and there was never a disagreement, only a stale screen.

Step two: if it still disagrees, tell the supervisor, then punch what you actually run. Both halves matter. The report is what gets the plan corrected before tomorrow's run. The punch is what keeps the plan correctable at all, because an unpunched shift leaves the engine planning around work it thinks is still waiting.

Note the one banner that is not part of this rule. If a yellow warning says the routing has changed since the job was scheduled, that is a different message with its own handling: tell the planner, then acknowledge it. See the BOR drift banner at the kiosk.

For the supervisor's side of the loop, the per-person, per-day work list is the practical companion to the machine queue: see how supervisors use the dispatch view.

The takeaway

A queue that argues with the floor is telling you something, and in most shops it is telling you the plan has not been fed. Read the five causes, notice that four of them resolve away from the terminal, and hold the line on the two rules that make the rest work: the kiosk never re-sequences, and the punch always reflects what actually ran. Explore the platform at EDGEBIC, see the upgrade path in RMDB to EDGEBIC, and read on in closing the loop from shop floor to plan and who should log actuals: the operator or the planner.