The Barcode You Have to Invent
Manufacturers barcode the tinned tomatoes. Nobody barcodes the rice you repack, the uniform you assemble, the spare part with the label rubbed off, or the thing you make yourself. What to do about the half of your catalogue that arrives without a code.
Scanning is sold as though every item arrives with a barcode on it. In a supermarket buying finished goods from multinationals, roughly that is true. In most other businesses it is true of maybe half the catalogue, and the half it is not true of is frequently the half that matters.
Rice bought in fifty-kilo sacks and sold in two-kilo bags. A school uniform assembled from three suppliers. A spare part whose printed label surrendered to a decade in a dusty drawer. Anything you manufacture, repack, assemble, cut to length, or import from a supplier who has never heard of GS1.
These items are not exceptions to be handled later. They are usually the ones with the highest margin, the most shrinkage and the least accurate stock record, which is a difficult combination to leave unscanned.
The two kinds of barcode, which get confused constantly
Almost every argument about barcodes in a small business comes from treating one problem as though it were the other. They are genuinely different, they cost wildly different amounts, and only one of them is a software question.
A trade barcode
- Globally unique, issued through a numbering organisation you pay to join.
- Identifies the product to anyone in the world — every retailer, distributor and customs system.
- Required if a third party is going to scan your goods at their own till.
- Has a real annual cost and an administrative process behind it.
- Belongs to the product, and travels with it out of your business.
An internal barcode
- Unique within your own business, and nowhere else.
- Identifies the item to your system — your till, your store, your count sheet.
- Costs nothing beyond a roll of labels and a printer.
- Can be generated in bulk this afternoon.
- Belongs to your record of the thing, and stops at your door.
If you sell through other retailers, you need the first kind and no software can give it to you. If you want to scan your own stock in your own shop — which is what almost everyone actually means — you need the second kind, and it is a solved problem.
If a stranger has to scan it, buy a trade number. If only your own staff will ever scan it, invent one this afternoon.
How the generated code works
An item without a barcode can be given one. The generated value carries a short prefix and the date it was created, followed by two random blocks, and it is checked for collision against every other barcode in your organization before it is assigned — retrying if it finds one, and falling back to a longer, second-precision format if it somehow keeps finding them.
The important property is the boundary of that uniqueness check. It is your organization, not the world. Two different businesses could in principle generate the same string and neither would ever know or care, because neither will ever scan the other's stock. That is not a limitation to be apologised for — it is what makes it free.
For a catalogue that has been running without codes for years, doing this item by item is not realistic, so bulk generation runs as a background job: every item with no barcode is assigned one in chunks, and whoever triggered it gets a notification when it finishes. On a catalogue of several thousand items that is a single action rather than an afternoon.
| Question | Answer |
|---|---|
| Is it globally unique? | No — unique within your organization |
| Will another retailer's till read it? | It will read the digits; it will not know the product |
| Does it cost anything? | No |
| Can existing items get one in bulk? | Yes — a background job, with a notification when it finishes |
| Can we use our own codes instead? | Yes — generation is for items that have none |
Getting it onto the item
A code in a database does nothing. The point at which this becomes useful is when the code is physically on the thing, or on the shelf edge in front of it, and that means printing.
Labels render as Code 128 for the linear barcode, and as a QR code where that suits the surface better — a QR carries more, tolerates damage better, and can be scanned from an awkward angle, which matters on a curved bottle or a bin that has been kicked for two years. QR codes are rendered at high error correction so a scuffed label still reads.
Labels print from a preview screen or straight to PDF, one item or a whole selection. The sheet is adjustable rather than fixed: how many labels across, how wide and tall each one is in millimetres, how tall the barcode is, how large the QR is. Defaults are a seventy by forty millimetre label, two to a row, and you can print up to five hundred of a single item at once for a bin or a shelf run.
Measure your label stock before printing five hundred of anything
The dimensions are in millimetres because that is what the label roll is specified in. Take one sheet of the stock you actually own, measure a label with a ruler rather than trusting the box, set those numbers, and print a single test page. Getting this wrong is not expensive in money and is remarkably expensive in afternoons.
What AWRA OpsHub does today
- Generated codes are collision-checked within your organization before assignment, with a fallback format if collisions persist.
- Bulk generation for every item missing a code, run as a background job with a notification when it completes.
- Code 128 and QR rendering, with QR at high error correction so a damaged label still reads.
- Printable labels as a preview or a PDF, single item or a selection, with the sheet dimensions set in millimetres.
- Your own codes are respected — generation fills gaps rather than overwriting what you already have.
What it does not do
- These are not trade barcodes. They are unique inside your organization and nowhere else. If your goods will be scanned at somebody else's till, you need a number issued through a numbering organisation, and no software can substitute for that.
- No check digit standard is applied. The value is encoded faithfully, but it is not an EAN-13 or a UPC and will not validate as one.
- The generated code contains the date the item was created. Harmless in almost every setting, but it is visible on the label, so if that matters to you use your own coding scheme instead.
Not ours, by choice
- We will not sell you a "global" barcode. Trade numbers come from a numbering organisation and cost what they cost; a vendor implying their generated codes are interchangeable with GS1 numbers is setting you up for a conversation with a retailer that does not go well.
- We will not overwrite a code you already have. If an item arrived with a manufacturer barcode, that is the right code for it, and generation leaves it alone.
Batch-level and location-level label variants, and label templates matched to specific stock, are scope rather than ceilings — the rendering, the PDF path and the dimension controls all exist, so this is a specification and a price.
The practical sequence for a catalogue that has never had codes: run bulk generation once, print labels for the fast-moving items only, and leave the long tail unlabelled until it earns the attention. Labelling everything is the version of this project that never finishes.
Where to put the label
This gets decided by whoever is holding the printer, and it is worth ten minutes of thought first, because relabelling is far more work than labelling.
-
On the item, when the item is discrete and durable
A spare part, a tool, a bottle, a boxed good. It travels with the thing, survives being moved, and works at the till and in the store. This is the default when the item can take a label at all.
-
On the shelf edge, when the item cannot take one
Loose goods, produce, anything sold by weight, anything too small. The label identifies the position rather than the unit, which is enough for both counting and selling.
-
On the bin, for anything you hold in quantity
Fasteners, cable, consumables. Nobody is labelling four hundred screws; label the bin, and count by weight or by measure against it.
-
On the repack, at the moment of repacking
If you break bulk, the label goes on as part of the repacking task, not afterwards. Anything deferred to afterwards is done inconsistently within a fortnight.
-
On the shelf edge as well, for your fastest movers
A duplicate at the shelf makes counting and reordering faster even when every unit is already labelled. Cheap redundancy, and it is where counters look first.
The catalogue problem underneath
Generating a barcode for every item is quick. It is also, occasionally, the wrong first move — because a code makes an item record permanent in a way that an unlabelled record is not, and if the record is wrong you have now printed the mistake and stuck it to a shelf.
Worth checking before you print
- Are there duplicate item records for the same physical thing? Two records, two codes, two stock figures, and neither is right.
- Is the unit of measure correct? An item recorded in cartons and sold in units produces a stock figure wrong by a factor of twelve, and the label makes it look authoritative.
- Do variants exist as separate items? Seven sizes of the same shirt need seven codes, not one — and if they are currently one record, the label will cement that.
- Is the item still stocked at all? A catalogue that has run for years accumulates items nobody has sold since 2021. Printing labels for those is the most literal possible waste of an afternoon.
- Does it already have a manufacturer barcode nobody entered? Check a sample physically before generating; entering the real one is better than inventing a second.
None of that is an argument for delay. It is an argument for doing your fast movers first, discovering the catalogue problems on a hundred items rather than four thousand, and fixing them before the labelling gets ambitious.
The variant question is worked through in seven sizes, one item, the catalogue discipline in the till will not sell what you have not listed, and the scanning hardware question in the scanner you already own.
What scanning actually buys you
It is worth being clear about the return, because "faster" is the reason people give and accuracy is the reason it pays.
A person keying a code from a label makes an error every few hundred entries, and the errors are silent — a transposed digit resolves to a different real item, so two stock figures are now wrong and nothing anywhere reports a problem. Scanning removes that class of error entirely rather than reducing it.
The speed is real too, and it compounds most at the counter and at receiving. But the reason to label the repacked rice and the assembled uniform is not that scanning them is quicker. It is that those items currently have no reliable stock figure at all, and everything downstream — reorder points, transfer suggestions, shrinkage investigation, margin by item — is built on that figure.
Our take
If your goods will be scanned by somebody else, buy a trade number and do not let anyone tell you a generated code substitutes for one. If only your own staff will ever scan them, generate codes in bulk this afternoon, and then print labels for your fastest-moving hundred items rather than for the whole catalogue. Check for duplicate records and wrong units of measure on those hundred first, because a label makes a wrong item record look authoritative — and a wrong figure that looks authoritative is more expensive than an obviously missing one.
Give your catalogue codes it does not have
Collision-checked generation, bulk assignment as a background job, Code 128 and high-error-correction QR rendering, and label sheets sized in millimetres to the stock you actually own.
Explore item managementFrequently asked questions
Can we generate barcodes for items that do not have one?
Yes. A generated code is checked for collision against every other barcode in your organization before it is assigned, and for a catalogue that has been running without codes there is a bulk path — a background job assigns one to every item missing a barcode and notifies you when it completes, which turns an afternoon of manual work into a single action. Items that already carry a manufacturer barcode are left alone; generation fills gaps rather than overwriting.
Are these real barcodes?
They are real in the sense that any scanner will read them, and internal in the sense that they are unique within your organization rather than globally. That distinction is the whole of it. For scanning your own stock at your own till, in your own store, on your own count sheets, an internal code does everything a trade number does and costs nothing. If your goods are going to be scanned at somebody else's till, you need a number issued through a numbering organisation, and no software can substitute for that.
What can we print?
Labels for a single item or a selection, as a preview or straight to PDF, rendered as Code 128 or as a QR code. QR is worth choosing where the surface is awkward or the label will take punishment — it carries more, reads at an angle, and is rendered at high error correction so a scuffed label still works. The sheet is adjustable: labels per row, label width and height in millimetres, barcode height, QR size. Measure your actual label stock with a ruler and print one test page before committing to a run.
What about items sold loose, by weight, or in bulk?
Label the shelf edge or the bin rather than the unit. Nobody is labelling four hundred screws or a crate of tomatoes, and the code does not have to be on the thing to be useful — it needs to be reachable at the moment somebody is counting or selling. For anything you repack, put the label on as part of the repacking task itself; a labelling step deferred to afterwards is done inconsistently within a fortnight.
Should we label everything?
No, and trying to is the version of this project that never finishes. Do your fastest-moving hundred items first. That gets you most of the accuracy benefit, and it surfaces the catalogue problems — duplicate records for one physical item, wrong units of measure, variants collapsed into a single record — on a hundred items rather than on four thousand. Fix those, then extend. The long tail can wait until it earns the attention.
Is there anything to check before generating codes?
Check a physical sample first, because entering a manufacturer barcode that nobody ever typed in is better than inventing a second code for the same product. Beyond that, look for duplicate item records, wrong units of measure, and variants that exist as one record when they should be several. A label makes an item record look authoritative, and an authoritative wrong figure causes more trouble downstream — in reorder points, transfer suggestions and shrinkage investigation — than an obviously missing one does.
