Step 1 — the job the scan resolves to

Nothing resolves without this Both forms look the scanned order number up in the job list and refuse a scan that matches nothing — there is no job record, so there is no customer, no counts, and the Save button stays disabled. SO57579 is a real order off the Line 1 sheet; it is not in the demo seed and never will be, because the seed’s counts are what several tests assert against. Add it here, and remove it when you are done. The record carries a band material of its own, so you can see both halves of the question: scan the code and the material comes off the scan; type the order number instead and the same value comes off the record. The forms say which, every time.

Step 2 — scan one of these

Two scanners, two kinds of code A handheld imager is a keyboard: it types what the code says into the SO field and sends Enter, so it wants the payload. A phone camera cannot type into a field — it opens a URL, so it wants a link. Both carry the same ticket and go through the same parse path in the form. Every code prints what it encodes underneath it, so what was scanned is never a guess. The payload is SO | sheets | parts | band material. The fourth segment is what fills the Band material field on both forms, and the form says the value came off the scan rather than out of the sales order. A three-field code still works exactly as it did.

QR code encoding the ticket payload S O 5 7 5 7 9, 8 sheets, 4 parts, band material 0.5 millimetre White

Handheld imager

Put the cursor in the SO field on either form and scan. The scanner types the payload and sends Enter, which resolves the ticket and fills in the customer, the counts and the band material. It does not save — a stray scan must not log an event on its own.

Works from the filesystem. No server, no network.

QR code linking to the Job Tracker form with the R72 ticket in the URL

Phone camera → Job Tracker

Opens the Job Tracker with the ticket already read in. Resolves on load; still saves nothing until you press Save, because a URL gets revisited by back buttons and restored tabs.

QR code linking to the QA and QC form with the R72 ticket in the URL

Phone camera → QA / QC

The same, into the inspection form. Pass or fail plus a reason is still a deliberate act on the form.

Step 3 — where to watch it land

Job Tracker QA / QC Dashboard Available queue

With the fixture added and nothing scanned yet, SO57579 sits in the Available queue: no scans means stage Available. Log a stage on the Job Tracker and it moves onto the board. Fail it on QA/QC and it appears under QA holds. Removing the fixture takes the scans and QA events with it.

Where these numbers came from

Banding sheet
R72_BANDING_SHEET.pdf — run R72, SO57579, GE of Miami, P1 - White/CP, 4 part(s) / 8 panel(s), cabinet BDW4-183023*, generated 9/17/2026 12:43:05 PM.
Line 1 sheet
2026 Cabinet Production Schedule.xlsx, “Line# 1 Production”, worksheet row 31 — SO57579, GE OF MIAMI, GV, “(2)BASE (1) (7)PANTRYS (1)APPLIED ENDS”, WHITE/DRIFTWOOD, $2,582.82, CSP DM.
Sheets 8, parts 4
The banding sheet’s panel and part counts. A panel is a sheet, so the figures carry straight across. Both are for run R72 only, not for the whole sales order — the part still worth remembering.
Band material
“0.5mm White”, verbatim. The R72 sheet lists it against all four parts and again under “Band materials needed for this run”.
No due date
The sheet carries two candidate dates for row 31 — column J (2026-09-14) and the date block it sits under (2026-09-18) — and does not say which is a due date. Neither form uses one, so the fixture does without.
Finish colour
The banding sheet says White/CP and the Line 1 sheet says WHITE/DRIFTWOOD. Not a live question — noted so nobody reopens it as a defect. Band material is what this rig carries, and it comes from the banding sheet alone.