busy-office-ui
Menu

Pattern: RF count

Who uses it: whoever walks the aisles for a physical inventory or a cycle count. How often: cycle counts daily on a rotation; wall-to-wall counts a few times a year, all hands. What "done" looks like: the bin scanned open, what is ACTUALLY there entered, submitted — and critically, the expected quantity was never on screen. A count is blind by design: show the book figure and the counter anchors to it, and the count stops measuring reality and starts confirming the record. That single fact shapes this screen — it is the one RF header that deliberately withholds a number. Not for correcting a quantity you already know is wrong — a known discrepancy is a stock adjustment with a reason, made at a desk on the record; a count is how you FIND discrepancies, not how you fix them.

The screen — try it

Shown the way the scanner gets it: an isolated 360×640 document styled by ONLY the rf-essentials profile (Chrome/WebView 108) — not the docs bundle. One screen, not two: this page used to render the same component a second time at desktop width, which showed the reader a size no counter ever holds (roadmap 131.1).

Scan (type + Enter) C-02-08 to open the count; a wrong bin flashes the verdict. The quantity starts empty, not zero — an untouched field means "not counted yet", and a typed 0 means "I looked, the bin is empty": two different facts the record must keep apart (the same empty-vs-zero rule the timesheet pattern documents).

Markup

<!-- BLIND by design: the expected quantity is never on screen, or
     the counter anchors to it and the count proves nothing. The one RF
     header that deliberately WITHHOLDS a number. -->
<dl class="bo-kv bo-kv--rows"> …Count doc / Bin / Item — NO expected qty… </dl>

<input class="bo-input bo-input--code" data-scan-input data-scan-flash
    aria-describedby="scan-status" />
<p id="scan-status" data-scan-status aria-live="polite" class="bo-visually-hidden"></p>

<div class="bo-quantity">
  <input class="bo-quantity__input" type="number" inputmode="numeric"
      min="0" step="1" placeholder="—" aria-label="Counted quantity" />
  <span class="bo-quantity__unit" aria-hidden="true">ea</span>
</div>

<div class="bo-btn-group bo-btn-group--bar">
  <button class="bo-btn bo-btn--secondary">Back</button>
  <button class="bo-btn bo-btn--secondary">Item not found</button>
  <button class="bo-btn">Submit count</button>
</div>

Anatomy

  1. Count header — KV rows: document + position, bin, item. No expected quantity, on purpose.
  2. Bin scan — scan input + flash; the count opens only on the right bin.
  3. Blind quantity — quantity, empty until the counter types. inputmode="numeric" brings up the gun's own keyboard — the same call RF pick makes, and for the same reason: the device already has one.
  4. Exception bar — Back / Item not found / Submit count.

Data contract

RequestReturns / on failure
GET /rf/count/nextthe next bin/item to count — WITHOUT the book quantity; blindness is enforced server-side, not by the screen's good manners
POST /rf/count/:pos/submitthe counted figure; a large variance may return a RECOUNT of the same position (the server decides the threshold), announced as such
POST … item-not-foundrecords a zero-with-reason — distinct from a typed 0, which is a counted empty bin
409 (position already counted)who counted it and the next position — double-counting is noise in the variance report

States

StateWhat ships
Awaiting bin scanthe count stays closed until the right bin opens it — counting the wrong bin is worse than not counting
Countingquantity empty (not zero); Submit disabled until a figure exists — empty and 0 are different facts
Recount demandedthe same position re-opens, SAID to be a recount — a silent recount reads as a glitch and gets pencil-whipped
Item not foundits own exception, not a typed 0 — zero-with-reason and counted-zero diverge in the variance report
Session lostreconnect re-renders the position as the server has it; an uncommitted count is retyped — honest, and cheaper than a wrong committed one
No JSscan posts on Enter, the count is a plain form; flash and steppers are enhancements

Components used

complexity 2 of 4

↑↓ move Enter open Esc close