A Barcode That Is Only Unique to You
The barcodes this system generates are unique within your organisation and nowhere else. They are checked against your items and your assets together, in one namespace — and the one path that skips the check is the one you will never hit.
A retail scanner in a supermarket reads a number that identifies a product to the whole world. The code on your shelf label identifies a row in your database. These are not the same kind of thing.
Generated barcodes solve one problem completely: giving every item and asset a code a scanner can read, without anybody typing anything. What they deliberately do not attempt is to be a global product identifier, and the difference decides what you can and cannot do with them.
What is generated
A code begins with a fixed marker, carries the date it was issued, and finishes with eight random digits. For assets it also carries your organisation's asset prefix — three letters by default, settable, stripped of anything that is not a letter or a digit. The result is a sixteen or seventeen character string that is meaningless to anybody outside your organisation and completely unambiguous inside it.
- A fixed marker, so a code from this system is recognisable as one.
- Your asset prefix, on assets, from the setting that also drives asset numbering.
- The date of issue in six digits, which makes a code roughly sortable by age and is occasionally useful when somebody reads one aloud.
- Eight random digits, which is where the uniqueness comes from.
Items and assets share one namespace
Before a code is issued it is checked against both your items and your assets. That is the right scope: a scanner at a receiving door does not know whether the thing in front of it is stock or a tracked asset, and it should not have to. One code, one record, whichever module owns it.
Unique to you, not to the world
The check is scoped to your organisation. Two workspaces on the same installation can hold the same code, and neither will ever notice, because no query anywhere reaches across that boundary. This is a deliberate consequence of the tenancy model rather than an oversight, and it has one practical implication worth stating.
These codes are internal identifiers. They are not GTINs, they carry no manufacturer registration, and they will not resolve in anybody else's system. If you need a code that means something to a distributor, a retailer or a customs system, that code comes from a registration authority and goes into the item's own barcode field — which is exactly why that field accepts a value you supply and only generates one when it is empty.
You sell through your own channels
Generated codes are the whole answer
Print them, scan them, and never think about it again. The uniqueness you need is uniqueness on your own shelves.
You resell manufactured goods
Store the manufacturer's code
The barcode already on the carton is the one your staff will scan by reflex. Put it in the field and no code is generated — generation only fills an empty field.
You supply a retailer
Get a registered code and store it
Their systems need an identifier issued by a numbering authority. That is a registration you hold, not something any software can mint for you.
You need both
The manufacturer's code on the item, your own on the label
Common in warehousing. The scanner reads whichever is in front of it; both resolve to the same record because both are stored.
Generation fills an empty field. It never overwrites a code you were given.
The retry loop, and the branch that skips the check
Eight random digits give a hundred million possibilities per prefix per day, so a collision is already unlikely. The generator does not rely on that: it checks, and if the code is taken it generates another, up to ten times.
If all ten collide, it falls back to a code built from the full timestamp to the second plus three random digits — and that fallback is returned without being checked. This is worth naming precisely because it is the kind of thing that reads as a defect and is not quite one. To reach it, ten independent draws from a hundred million each have to hit codes you already hold on the same day. The fallback exists so that the loop terminates rather than as a code path anybody has taken.
The honest framing is that the fallback is a guard against an infinite loop rather than a second uniqueness strategy, and it would be better if it checked too. It is on the list below for that reason and for no other.
What gets printed, and the one rule about it
A label can carry a linear barcode, a QR code, or both — a per-organisation setting, defaulting to both. The linear symbology defaults to Code 128, and anything stored that is not a recognised symbology falls back to it rather than failing.
There is one rule about how these are drawn that is worth stating because it catches people who theme their own reports: a machine-readable code does not follow a light or dark theme. Every scanner ever built expects dark marks on a light plate. A QR code carries its own white background and survives anywhere; a linear barcode is bars on nothing, so on a dark surface it becomes near-black on near-black — invisible to a person, unreadable to a scanner, and perfectly fine in every screenshot taken in light mode.
Five questions to ask about generated barcodes
How unique is a generated code?
A good answer sounds like
A named scope.
What ours actually is
Unique within your organisation, checked against your items and your assets together. Not unique across the installation and not globally registered.
Will it overwrite a manufacturer code?
A good answer sounds like
No.
What ours actually is
No. Generation only fills an empty field, and only when auto-generation is switched on.
Is it a GTIN?
A good answer sounds like
A straight no.
What ours actually is
A straight no. These are internal identifiers with no registration behind them and they will not resolve in anybody else's system.
What happens on a collision?
A good answer sounds like
A retry, with a bound.
What ours actually is
Up to ten regenerations against a live check, then a timestamp-based fallback that terminates the loop.
What is printed on the label?
A good answer sounds like
A symbology and a mode.
What ours actually is
Code 128 by default, or QR, or both, set per organisation, with an unrecognised setting falling back to Code 128 rather than failing.
Our take
Generated barcodes are one of those features whose value is entirely in being unremarkable: every item and asset gets a scannable identity, nobody types anything, and the code is unique where uniqueness matters. The one thing worth being clear-eyed about is what "unique" means here, because the word does a great deal of work in vendor material. It means unique within your organisation, across your items and assets, checked at the moment of issue. It does not mean registered, global, or meaningful to anybody else — and any system that implies otherwise without naming a numbering authority is telling you something that is not true. Within that scope this is solid, and the single improvement we would make is checking the fallback branch that nobody has ever reached.
What AWRA OpsHub does today
- Automatic barcode generation for items and for assets, issuing a code carrying a fixed marker, the issue date and eight random digits, with your organisation's asset prefix on asset codes.
- A single namespace across items and assets within an organisation, checked in both directions before a code is issued.
- Generation only into an empty field, so a manufacturer's code you supply is never replaced.
- A per-organisation switch for automatic generation, on by default, and a settable asset prefix that also drives asset numbering.
- A collision check on every generated code, with up to ten regenerations against live data.
- One implementation shared between single generation on the item screen and the queued bulk-generation job, so the two cannot drift apart.
- A choice of linear barcode, QR code or both on printed labels, with Code 128 as the linear default and an unrecognised setting falling back to it rather than failing.
- Machine-readable codes drawn on a fixed light plate with dark ink in both light and dark themes, because a scanner expects dark marks on a light ground regardless of what the reader's screen is doing.
More we can add to your workspace
- A collision check on the timestamp fallback, so the branch that terminates the retry loop is verified like every other issued code.
- Validation of a supplied barcode against its symbology, catching a thirteen-digit code with a wrong check digit at the point somebody types it.
- A registered numbering scheme, for organisations that need identifiers meaningful to a distributor, a retailer or a customs system.
- A duplicate report across items and assets, finding codes that were typed in rather than generated and happen to clash.
- Configurable code structure, so an organisation with an existing labelling convention can have generated codes fit it.
- A print run record, showing which labels were generated and when, for reconciling a batch of printed labels against the records they belong to.
Where we point you to a specialist
- We will not issue codes that imply a registration we do not hold. A global product identifier comes from a numbering authority your organisation registers with, and minting something that looks like one would put a code into your supply chain that fails the first time somebody outside your business tries to use it.
- A machine-readable code stays dark on light in every theme, and we will keep refusing to make it follow a reader's colour preference. The audience for those pixels is a scanner, and a code that themes prettily and scans intermittently is a worse outcome than one that never changes.
- Where a sector prescribes a labelling standard — a pharmaceutical serialisation scheme, a food traceability code — that standard governs and your compliance adviser owns the interpretation. We will store and print whatever it prescribes.
Checking the fallback branch and reporting duplicates across the shared namespace are both small, contained pieces, and together they close the only two ways a code can end up on two records.
Codes that fit an existing convention
The generator is deliberately opinionated about structure. Organisations that already label their stock a particular way ask for two things, and both are contained.
Configurable code structure
A pattern per organisation — segments, lengths, a check digit — so generated codes match labels you already print.
A duplicate sweep
A report across items and assets finding codes that clash, aimed at the ones that were typed in rather than generated.
A print run record
Which labels were produced, for which records, when — so a tray of printed labels can be reconciled against the shelf.
We publish scope, not dates.
Scope labellingDecide which code your staff will scan
In practice people scan whatever is nearest the front of the box. Knowing whether that is your label or the manufacturer's decides which field has to be populated, and it is a five-minute conversation that saves a lot of relabelling.
Talk through barcodesFrequently asked questions
Can two organisations on the same system have the same barcode?
Yes, and neither will ever see the other's. Every barcode query is scoped to the organisation, so the codes live in separate spaces entirely. This is a property of how the whole product separates workspaces rather than anything specific to barcodes, and it has no operational consequence — a scanner is always operating inside one workspace.
Will generating a barcode overwrite the one already on the carton?
No. A code is generated only when the barcode field is empty and automatic generation is switched on. If you record the manufacturer's code, that is the code, and nothing replaces it. Where both matter, store the manufacturer's on the item and print your own on your shelf label.
Are these codes usable outside our business?
No. They are internal identifiers with no registration behind them, and they will not resolve in a distributor's or a retailer's system. An identifier that means something outside your business comes from a numbering authority you register with, and belongs in the item's barcode field once you have it.
What happens if a generated code collides?
The generator checks before issuing, and regenerates up to ten times if the code is taken. If all ten collide, it produces one built from a full timestamp plus three random digits and returns it without checking again. That last branch exists so the loop terminates; reaching it requires ten independent draws from a hundred million each to hit codes you already hold on the same day.
Why does the label default to printing both a barcode and a QR code?
Because they fail differently. A linear barcode is fast and reliable with a dedicated scanner and unforgiving about damage across the bars. A QR code carries more, survives a torn corner and reads on any phone camera. Printing both means whichever piece of equipment is to hand can read the label, which matters most in the places where labels get scuffed.
Why do the codes look the same in dark mode?
Because the audience for them is a scanner, and every scanner expects dark marks on a light plate. A code that inverted with the theme would be unreadable to the device it exists for, and the failure would be invisible in any screenshot taken in light mode. So the plate and the ink are fixed regardless of what the rest of the screen is doing.
