The Code That Matches Twelve Things
A storekeeper scans a label and the system finds four different records that all legitimately carry that number. What happens next is decided by who is holding the scanner — and that is a deliberate choice, not an accident.
Most descriptions of barcode scanning skip the interesting part. They tell you a scan finds the item, which is true right up until the moment a code matches more than one thing, or matches something the person scanning is not allowed to see. Both happen in ordinary use, and how a system behaves in those two cases is most of what separates scanning that helps from scanning that generates arguments.
The starting point is that a scanner is not a lookup for one kind of record. In a working operation the same handheld is pointed at a stock item on a shelf, a delivery note on a pallet, an asset tag on a laptop, a warehouse bay label, and a printed transfer docket — often within the same ten minutes.
So the question a scan actually asks is not "which item is this". It is "what, of everything in this system, does this code refer to".
One input, twelve possible answers
An untyped code — a plain string of characters with nothing to say what kind of thing it names — is tried against twelve different record types in a fixed order.
- An asset, by its tag or serial
- A stock item, by its barcode
- A purchase order
- An invoice
- A point-of-sale sale
- A stock transfer
- A quotation
- A stock adjustment
- A procurement request
- A request for quotation
- A location
- A warehouse
The important detail is that it does not stop at the first match. It collects every match, deduplicated, and only then decides what to do — which is what makes the ambiguous case a first-class outcome rather than a silent wrong answer.
Two types are deliberately not in that list
A customer and a cash drawer can both be resolved by a scan, but only from a code that says what it is — a prefixed code of the form cust: or drawer:. Neither is tried against a bare untyped string. That is the right call: customer references are the most likely of all these to collide with a supplier code or an old item number, and a bare scan silently landing on a customer record would be worse than not resolving at all. It does mean that if you want customer or drawer codes to scan, they have to be printed with the prefix.
Codes that say what they are
The other path is a code that carries its own type — a prefix, then the value. Where you control what gets printed, this is always the better option, because it removes the guessing entirely.
| If the code starts with | It resolves as | Typical use |
|---|---|---|
asset: or ast: | An asset | Equipment tags, laptops, vehicles |
item: | A stock item | Shelf labels, bin labels |
po: | A purchase order | Printed on the order sent to a supplier |
inv: | An invoice | Customer paperwork |
wh: or loc: | A warehouse or a location | Bay, rack and door labels |
st: or transfer: | A stock transfer | The docket travelling with the goods |
cust: | A customer | Account cards, delivery paperwork |
drawer: | A cash drawer | Till identification at shift change |
Quotations, adjustments, procurement requests, requests for quotation and point-of-sale sales all have prefixes too. The pattern is consistent and most have a short alias, so a label does not have to carry a long word to be unambiguous.
A prefix the system does not recognise resolves to nothing rather than falling back to guessing, which is the conservative behaviour and the correct one.
The part that surprises people: permission comes first
When a plain code matches several records, the natural assumption is that the system shows you the list and asks you to choose. That is what happens, but not before something else happens first, and the order changes the outcome.
-
Every match is tested against what this account may see
Each candidate record is checked for access before it is offered. A match the person scanning has no business seeing is not shown to them as an option to pick from — it is removed from the list entirely.
-
If nothing survives, the scan is refused as an access problem
Not "code not found", which would be misleading and would quietly teach people the label is broken. The response says the code matched records that are not available to this account, and suggests scanning something assigned to it instead.
-
If exactly one survives, there is no ambiguity to resolve
The scan resolves cleanly and the person is never told there was ever a second candidate. From where they stand, the code meant one thing.
-
Only if two or more survive are you asked to choose
The list comes back with the type, the identifier, the label and the current status of each, so the choice is made on visible facts rather than on a row of identical-looking numbers.
The same code can be unambiguous for a storekeeper and ambiguous for an operations manager, because the manager can see more of the records it matches.
That sentence is worth sitting with, because it inverts the usual expectation that a broader account has an easier time. Here, seeing more records means seeing more collisions. If your operations lead reports being asked to disambiguate codes that scan cleanly for everyone else, nothing is broken — you are watching the permission filter do exactly what it was built to do.
It also means an ambiguity report gathered from one account is not a picture of what your floor staff experience. Test scanning with the account that will actually be scanning.
What happens to the scan that found nothing
Every scan is recorded, and this includes the ones that fail. The record carries the code, whether it resolved, what it resolved to if it did, and which exception applied if it did not.
Three outcomes are distinguished, and they mean genuinely different things operationally.
| Outcome | What it means | What it usually indicates |
|---|---|---|
| Resolved | The code found exactly one accessible record | Normal |
| Unresolved | The code matched nothing at all | A label from a system you no longer run, a supplier code never registered, or a damaged print |
| Exception | The code matched, but something stopped it | Ambiguity, an access refusal, or a duplicate scan of the same code |
The scan record also carries the device — a label and a fingerprint — and where the scan came from, including whether it arrived through a phone linked to a desktop session rather than typed at the console. So a pattern of failures can be traced to one handheld rather than being read as a general problem.
The honest limit on all of that
The scan events are written, and they are covered by data retention so they are pruned rather than accumulating forever. What does not exist is a screen that shows them to you as a report. There is no "unresolved scans this week" list to open. The data that would answer the most useful question in this whole area — which labels on your floor do not scan — is being collected and is not currently surfaced anywhere you can read it.
Scanning and then doing something
Resolving a code is only useful if the next action is within reach, and the console is built around that — it is a scan-and-act screen rather than a lookup. A resolved record comes back with the actions available on it, already filtered to what this account may do.
One case does not execute from the scan, deliberately. Verifying a high-value or otherwise high-risk asset routes into an approval workflow rather than completing on the spot. A verification is a statement that somebody laid eyes on a thing, and for the assets where that statement carries weight, it goes through the same route as any other consequential decision instead of being a side effect of pointing a scanner.
The wider principle: scanning is an input method, not an authority. It makes the person faster at doing what they were already allowed to do. It does not let them do more.
What AWRA OpsHub does today
- Twelve record types resolved from a plain code, tried in a fixed order, collecting every match rather than stopping at the first.
- Typed prefixes for fourteen record types, most with short aliases, so a label you control can say what it refers to and skip the guessing entirely.
- Access filtering before ambiguity — matches this account may not see are removed from the candidate list, so a code with four matches and one visible resolves cleanly.
- An explicit access refusal rather than a misleading "not found" when every match is out of reach.
- Every scan recorded — resolved, unresolved or exception — with the code, the resolved record, the exception, the device label and fingerprint, and the scan source.
- Actions offered on the resolved record, filtered to what the account may do, so scanning leads into work rather than into a read-only page.
- High-risk asset verification routed to a workflow instead of executing from the scan.
What it does not do
- There is no scan audit report. Every event is written and nothing renders them. The question "which labels on our floor do not scan" is answerable from the data and not answerable from any screen.
- No alert on a rise in unresolved scans. A shelf of labels degrading past readability shows up as people complaining, not as a notification.
- Customer and cash-drawer codes need their prefix. Neither is tried against a bare code, so a plain customer number will not resolve.
- No batch or serial resolution from the universal console. Batch handling exists in its own right; it is not one of the twelve types this input tries.
Not ours, by choice
- We will not let a scan resolve to a record the person scanning may not see, even to be helpful, and even where the ambiguity would be cleared by showing it. A scanner that reveals the existence of records by listing them as options is a permission leak with a barcode in front of it.
- We will not silently pick the most likely match when a code is ambiguous. Guessing correctly nine times out of ten produces a system people trust and a tenth transaction posted against the wrong record, which is worse than being asked to choose.
A scan audit report — unresolved codes by frequency, exceptions by device, ambiguity by code — is scope rather than a ceiling. The events are already being written with everything such a report needs; what is missing is the screen.
If you are rolling scanning out, the single highest-value preparation is deciding which of your labels you control and printing those with a type prefix. Codes you generate should never be ambiguous. Reserve the plain-code path for labels that arrived on somebody else's box.
What to decide before you hand out scanners
Four decisions, none of them technical
- Which labels do you print, and do they carry a type prefix? Everything you control should. This is the one change that removes most ambiguity permanently.
- Who scans what? Test with the account that will do the scanning, not with an administrator, because a broad account sees more collisions and gives you a pessimistic picture.
- What is the standing instruction when a code does not resolve? "Tell somebody" is not enough — name the somebody and the channel, because there is no report that will surface it for you.
- Which assets are high-risk enough that verifying them should go through approval rather than complete at the scan? That setting is the difference between a verification that means something and a number that went up.
The related reading: the phone-as-scanner bridge is covered in the scanner you already own, generating codes for items that arrived without them in the barcode you have to invent, and the counting workflow this feeds in the count that cannot see the answer.
Our take
The resolution behaviour is the part to trust — twelve types tried, every match collected, access applied before ambiguity, and a refusal that says what it means. Print your own labels with a type prefix and most of the difficulty never arises. The gap to plan around is that every scan is recorded and none of it is shown to you, so the failing-label problem needs a named person and a channel rather than a screen.
See scanning end to end
One input that resolves twelve record types, typed prefixes for the labels you print, access applied before ambiguity, and actions offered on the record you scanned.
Explore scanningFrequently asked questions
What happens when one barcode matches several records?
The matches are first filtered to what the account scanning is allowed to see. If none survive, the scan is refused as an access problem rather than reported as "not found". If exactly one survives, it resolves normally and the person is never told there was a second candidate. Only if two or more survive are you asked to choose, and the list shows the type, identifier, label and current status of each so the choice is made on visible facts.
Do we have to print special barcodes?
No, but you should for the labels you control. A plain code is tried against twelve record types and may match more than one. A code carrying a type prefix — item, asset, purchase order, warehouse and so on — resolves to exactly one kind of thing with no guessing. Codes that arrived on somebody else's box will always go through the plain path, which is what that path is for. Customer and cash-drawer codes are the exception: they only resolve with their prefix, so a bare customer number will not scan.
Can we see which labels are failing to scan?
Not from a screen today. Every scan is recorded — the code, whether it resolved, what it resolved to, which exception applied, and which device it came from — and that data is exactly what such a report would need. What does not exist is anything that renders it. Until it does, the practical answer is a standing instruction to a named person: when a code does not resolve, report it through a specific channel, because nothing will surface it automatically.
Why did a code scan fine for one person and not another?
Almost always the permission filter, and it usually runs the opposite way to expectation. Matches the account cannot see are removed before ambiguity is assessed, so an account with narrow access often gets a clean single match where a broader account gets asked to choose between several. If your operations manager is disambiguating codes that scan cleanly on the floor, that is the filter working correctly rather than a fault.
Does scanning let people do things they otherwise could not?
No. Actions offered on a resolved record are filtered to what the account may already do, so scanning is a faster route to permitted work rather than a way around permissions. One case is deliberately slower rather than faster: verifying a high-risk asset routes into an approval workflow instead of completing at the scan, because a verification is a statement that somebody physically checked something and for those assets that statement is treated as consequential.
What kinds of scan failure are distinguished?
Three, and they mean different things. Unresolved means the code matched nothing — usually a label from a system you no longer run, a supplier code that was never registered, or a damaged print. An exception means it matched but something stopped it, most often ambiguity, an access refusal, or the same code scanned twice in a row. Resolved means exactly one accessible record was found. Each is recorded with the device it came from, so a pattern of failures can be traced to one handheld rather than read as a general problem.
