Putting barcode scanners on a Cambodian warehouse floor

What does a barcode actually change on a warehouse floor?

It changes who types. A scan puts the code into the system without anyone reading it off a carton and keying it in, and that keystroke is where a great deal of stock error begins.

Three cases cover almost every item in a Cambodian warehouse. An imported carton arrives already carrying a GTIN barcode, and you scan what the manufacturer printed. A locally produced item has no code the world agrees on, so you assign one and print it. And plenty of goods carry nothing at all: a sack of rice, a drum of solvent, a pallet built this morning out of four part-cases. There the code becomes yours to control, which is better than it sounds, because a code you print is a code that can carry a pallet identity and a bin number rather than a product name alone.

What a barcode does not do is tell you where anything is. It identifies a thing, and the location comes from a second scan: the bin label on the rack, read before or after the item, so the movement has both ends. A site that scans items but never scans locations has swapped typing for scanning and kept the harder problem, which is that stock is recorded as sitting at Battambang · Depot rather than in a particular aisle at Battambang · Depot, and a picker still walks the building looking for it.

It does not fix a process either. If a receipt is not booked against the transfer that dispatched it, a scanner only makes the wrong number arrive faster. Scanning is an input method, and what it feeds is a stock ledger that has to be right about transfers, in-transit quantities and receipts before any of the hardware is worth buying. That is the work described on the inventory system these scanners feed, and it is the thing to settle first.

EAN-13, Code 128, or a 2D code: which one does your stock need?

You choose by who has to understand the number. EAN-13 is for goods the outside world has already labelled, Code 128 is for anything that only means something inside your building, and a 2D code is for the case where one scan has to carry more than an identity.

EAN-13 is the thirteen-digit retail barcode on a consumer product, and it encodes a GTIN issued to the manufacturer through GS1, which is what makes it mean the same thing outside your building as inside it. A retail barcode carries an identity and nothing else: no lot, no expiry, no quantity. Two cases of the same juice from the same supplier, one made in March and one in September, carry exactly the same thirteen digits, and no amount of scanning will separate them.

Code 128 encodes whatever text you give it (your own SKU, a bin location, a pallet number), which is why it is the right choice for anything internal, where you are not asking the rest of the world to recognise the number. Nobody has to issue it to you and nothing has to be registered, so the label costs what the label costs. Every bin in a rack, every pallet built on a production line, every own-produced item that will never cross a retail checkout: all of it belongs here.

A 2D code earns its place when one scan has to carry more than an identity: lot and expiry alongside the SKU, so a picker taking a case off the rack confirms the batch and the date in the same movement instead of reading them off the carton and typing them in. That is the difference between a traceability record you can stand behind and one assembled from memory at the end of a shift, which is the subject of lot and expiry traceability in a Cambodian warehouse.

A barcode scanner reads all three without knowing the difference, and the difference is entirely in what the number means to the stock system on the other side of it. The one place it matters at purchase time is the hardware. A laser scanner reads 1D bars only. An imager reads 1D and 2D both. If there is any chance you will want lot and expiry inside the scan, buy imagers now rather than buying the fleet twice.

Is KHQR a barcode you can scan into stock?

No. KHQR is not a product barcode. It is Bakong's payment standard, and the code identifies a merchant account so a customer's banking app knows who to pay. KHQR carries no product identity: no SKU, no lot, no quantity, nothing a stock system can use. Point a warehouse scanner at a KHQR sticker and you get a payment string back, and the stock record does not move.

The confusion is understandable, because QR codes are part of daily life here and both things are black squares on a white sticker. The phrase QR inventory gets used loosely, which is what keeps the idea alive. If you are offered QR-based inventory, the question to ask is which QR: a 2D code your own system printed, carrying your SKU and its lot, is a working stock label, and a merchant payment code is not, however many times it is scanned.

The same distinction settles a related argument at a receiving door. A KHQR code on a delivery note tells you who gets paid. It says nothing about what arrived, so it can never stand in for a receipt scanned against the transfer that dispatched it.

What happens to a scan when the connection drops mid-count?

It has to be written anyway, or the count is worthless. The bottleneck is rarely the national network, and it is almost always the building you are standing in: a concrete stockroom that kills the signal two aisles in, a power cut that takes the router down while the generator catches, ten seconds of dropout in the middle of a count. The national network is not the bottleneck: 4G coverage is wide and mobile data here is cheap.

A scanning build is held to one specification: a scan is a local write first, so the device records the movement, keeps its own queue, and syncs when it can, with the row carrying the time the scan happened rather than the time it reached the server. There is no inventory handheld Scale can put in your hands today. Offline scanning is the architecture the build is written against rather than a shipped demo, and that specification is a fair thing to hold any vendor to, ours included.

The timestamp clause is the one people skip, and it decides whether a count is usable. A queue that stamps rows on arrival files a scan taken at 09:14 as though it happened at 11:40, after the reconnect, which puts it on the wrong side of every movement in between and turns a clean count into a difference nobody can explain. The second clause worth writing down is duplication: a scan has to carry an identity the server recognises, so a retry updates the row it already holds instead of posting the movement twice. A scan is written locally first, carries its own identifier, and reconciles when the link returns, with conflicts surfaced rather than resolved silently. Both problems surface first as a stock variance a cycle count cannot trace, which is where most people meet them.

Offline selling at a counter is a different problem: how the till keeps working when the line drops.

Why do Khmer product labels break in ways English ones do not?

The script stacks, and a narrow thermal label runs out of height before it runs out of width. Khmer subscript consonants and vowel signs sit above and below the base line, so the same product name is taller than its Latin equivalent at the same point size, and the label that comfortably held an English description clips a Khmer one.

A long name cannot be shortened by cutting bytes either: cut in the wrong place and you split a cluster and print something that is not a word. That matters because a picker reads the name, not the number. The barcode itself is unaffected, since it carries digits and Latin characters, so a broken label scans perfectly and still sends someone to the wrong rack. Khmer also does not sort the way a byte comparison sorts it, so an alphabetical product list has to be collated properly, or your count sheets and pick lists arrive in an order that looks random to the person holding them.

None of this is exotic and all of it is checkable in a demo. Ask to see a label printed on paper, carrying the longest Khmer product name in your catalogue, and a count sheet sorted by name. A vendor whose label engine ships the font and collates the list properly will show you in two minutes. One who has never tried it will offer you a screenshot instead.

What should you ask a vendor before buying scanners?

Ask these eight questions, and weigh the answers above anything printed on the hardware datasheet. Scanners are the cheap part of a scanning project. What decides whether the floor is still using them a year from now is what happens on the far side of the scan.

1. What does one scan write? You want a movement row carrying a quantity, a location, a user and a time, not a note attached to a product record.
2. What happens when the scanner reads a code the system does not know? Refusing is defensible and offering to create the item on the spot is defensible. Doing nothing visible is not.
3. Can one item hold more than one code? The supplier's GTIN on the outer carton, a different GTIN on the inner pack and your own printed label all have to resolve to the same SKU, each with its own pack quantity.
4. Where is a scan written when there is no connection, how long can the queue hold, and which timestamp survives: the scan or the sync?
5. What stops a doubled scan becoming two movements, and can that be demonstrated rather than described?
6. Can it print a label with a long Khmer name on it? Ask for the printed label, not the screen.
7. Does the scan capture lot and expiry, and can the system pick FEFO while costing FIFO? Those are two independent rules, and a system that treats them as one will get one of them wrong.
8. Which scanner models are supported, and is the demo running on the model you are being quoted?

A vendor who answers all eight in front of you, on the hardware you would actually buy, has spent time on a warehouse floor. One who wants to talk about drop ratings and battery life instead has spent it in a showroom. The same is true of the questions you ask about the ledger underneath, because a scanner that writes into a weak stock model is an expensive way to record the wrong number faster.

Frequently asked questions

Do I need GS1 numbers to run barcodes in my own warehouse?

No, not for internal use. A GS1 number exists so that a code means the same thing in someone else's building as it does in yours, which is what matters when you sell into a retailer or an export customer that requires a GTIN on the pack you ship. For receiving, picking, transfers and counting inside your own sites, a Code 128 label carrying your own SKU does the same work and costs you nothing beyond the label stock.

Can one product have two barcodes?

Yes, and most imported products end up with several. The outer carton carries one GTIN, the inner pack carries another, and you may add your own printed code on top for items that arrive bare. All of them have to resolve to one SKU in the system, and each has to carry the quantity it represents, so that scanning the outer carton of a 24 x 330ml case adds twenty-four units and scanning a single can adds one. A system that allows only a single code per item will make somebody type the difference in, which is the habit you bought scanners to remove.

Will scanning fix my stock variance?

It removes one cause of variance and leaves the rest. Keying errors go away, along with most transposed digits and most wrong-item picks. What stays is everything the scanner never saw: the transfer dispatched but never received, the damage nobody wrote off, the sample handed to a customer at the gate. Scanning makes the remaining differences smaller and easier to trace, which is the actual benefit, rather than making them disappear.

Laser scanner or imager?

An imager, unless you are certain you will never need a 2D code. A laser reads 1D bars only, so it will read EAN-13 and Code 128 and stop dead at a code carrying lot and expiry. An imager reads both. Since the fleet is usually bought once and kept for years, and lot control tends to arrive later rather than earlier, the imager is the cheaper decision over the life of the hardware.

Is FEFO the same as FIFO?

No, and collapsing them causes real damage. FIFO, first in first out, is a cost-flow rule: it decides which cost is released when stock leaves, and it drives your valuation and the COGS figure your accounts consume. FEFO, first expired first out, is a picking rule: it decides which physical case a picker takes off the rack. They are independent of one another, and an expiry-controlled warehouse usually wants both at once, picking FEFO on the floor while costing FIFO in the ledger.

Can I scan with a phone instead of buying handhelds?

For a small site, yes. A phone camera reads both 1D and 2D codes, and it costs you nothing extra because the phone is already in the building. It is slower per scan than a dedicated device, worse in a dim aisle or a chilled room, and harder on the battery. It is worth saying plainly that there is no inventory handheld Scale can put in your hands today: offline scanning is the architecture the build is written against rather than a shipped demo, and the specification above is what any vendor should be held to, ours included.

Where to go next

Two pages carry this further. Inventory and warehouse systems is the service these records belong to. Inventory in a Cambodian garment factory covers the harder case, where the thing on the rack is a work order rather than a saleable SKU and the label has to follow it through cutting and sewing.