Every live EWM site has a stretch where the scans stop landing. It might be a new label run, a new batch of devices, or the first month after go-live. The floor does what floors do: it hovers, reverses, tries again, keys the number by hand, and the throughput quietly drops. This note sits inside our SAP EWM health check and optimisation work, because it is the first thing we look at when a live system is struggling.
It follows the first week of an EWM health check, and it deals with one narrow question: why the floor cannot read what it is holding.
Scan failures are rarely one fault.
The sharpest example we can point to is our EWM rescue case. A national operation had gone live on SAP EWM with another team, and the floor could not scan. There was no single cause. The barcodes had been printed to the wrong symbology, not the GS1 Code 128 standard the operation required, so the makeup of the barcode was wrong before a scanner ever saw it. The hardware had been procured tethered to fixed points rather than matched to how operators move. And a reflective cover sat over the labels, so even a correctly configured scanner could not get a clean read.
Fix any one of those and you still have a floor that cannot scan. That is the trap. Each cause hides the others, and the symptom looks identical from the dock: an operator hovering, reversing, hovering again, and eventually getting a lucky read. Within 90 days of Luminar coming in, that floor was scanning and scalability had improved by roughly 70%. The order of work was the point. Check the layers one at a time, from the label to the screen, and do not stop at the first fault you find.
Start with what the barcode says.
Two separate questions hide in here, and sites tend to check only one. The first is symbology: which barcode type is printed. The second is content: what is encoded in it.
On symbology, the requirement for the site comes from the operation and its trading partners, and in the rescue case it was GS1 Code 128. A label can look perfectly good to the eye and still be the wrong type for the scanner profile, or for the party who will read it next. Confirm what the standard is, then confirm what is actually being printed, by comparing a label from the printer against the specification rather than against what someone remembers.
On content, GS1 labels carry data in numbered fields called application identifiers. The pallet label most distribution centres meet is the one built around the SSCC, the serial shipping container code, an 18 digit number that identifies one logistics unit. If the SSCC is built wrongly, or an identifier is missing or in the wrong order, the scanner may read the bars perfectly well and the system will still reject the result. Operators experience that as a scan that beeps and then does nothing, which is easy to mistake for a hardware fault.
Print quality and label finish.
A barcode is a contrast problem. The scanner is measuring dark bars against a light background, and anything that narrows the gap makes the read slower or impossible. Check the print first: bars that are faint, smeared or broken by a tired print head; a thermal ribbon near the end of its life; labels that fade or scuff between the printer and the pallet. A label that reads fine at the printer and fails at the dock has usually been damaged or aged in between. Direct thermal stock, in particular, can darken or fade with heat and light, so a label that has sat in a sunny dock for a day is a different label from the one that left the printer.
Then look at where the label goes and what covers it. Glare is the quiet one. A glossy or laminated surface under dock lighting throws the light straight back at the scanner, which is what the reflective cover did in the rescue case. Wrapping matters too: a label that wraps around a corner of a pallet or a curve of a carton bends the barcode across two faces. And height matters. A label placed at the bottom of a pallet face makes a standing operator bend for every scan, so they stop doing it properly.
These are cheap to test. Take a handful of real labels off real pallets, not fresh ones from a test print, and scan each in the conditions where it will be read.
The scanner against the aisle.
A scanner that reads a label at arm's length is not the same scanner that reads a label three pallets up. High racking needs extended-range scanning, and a standard-range device forces the operator to climb, lift or guess. Reading distance is a hardware spec, so match it to the highest and lowest labels the site actually has.
Then look at how people carry the device. The rescue case found hardware procured tethered to fixed points, when the operators moved around the floor. The same mismatch shows up in other forms: a handheld for someone who needs both hands free, a vehicle-mounted unit where the driver has to dismount to scan a low label, a wearable on a job that needs a keyboard. Ergonomics decides whether a scan is one motion or a wrestle, and a wrestle gets skipped on a busy shift.
Configuration belongs here as well. On Knauf Pinkenba, we set up the Getac mobile devices and Zebra scanners with the configuration the GWMS RF flow required (see the Knauf Pinkenba case), so that mobile data entry and scanning landed simply for the operator. A good device on the wrong settings fails exactly like a bad device.
Wi-Fi, and the screen that expects the wrong field.
Coverage where the work is.
A scan can read perfectly and still go nowhere if the device has lost the network. Steel racking, dense stock and cold rooms are all places where coverage can be thin, and the failure is patchy: fine in one aisle, dead two bays along. Walk the site with a device and note where it hesitates. Operators already know these spots by name.
What the screen is waiting for.
The last layer is the RF screen itself. At each step the screen expects one specific thing: a handling unit, a bin, a product. If the operator scans a barcode that holds something else, or the label carries data in a form the screen does not expect, the read is good and the step still fails. This is a design problem, not a hardware one, and it is why our note on the RF flow as the product matters here. A screen that fails without saying what it wanted teaches the floor to work around it.
The scanner only reads what it is shown. Everything between the printer and the screen decides what it is shown.
How to diagnose it on the floor in an afternoon.
You do not need a project to find the stack. You need a handful of real labels, the devices people actually use and a shift lead who will tell you the truth. Work from the label outward.
- Pull labels from the printer, the dock and a rack face. Compare the symbology and encoded content against the specification. Look at contrast, scuffing and glare.
- Scan the same labels with each device type in use, at the real heights and distances. Note which combinations fail.
- Walk a path through the site with a device and watch the connection. Mark where it drops.
- Follow one operator through an inbound and an outbound flow. Watch every failed scan and ask what the screen wanted at that moment.
- Ask the team where they key numbers by hand. Those workarounds point straight at the weak links.
Keep a list of every failure with the label, device, place and screen. The pattern usually appears within a couple of hours: one device type failing at one height, or one label run failing everywhere. Fix the cheapest layer first, retest, and move on to the next. Once the floor reads reliably, stock accuracy is the next thing to look at, and our note on stock accuracy after go-live picks it up from there.
How Luminar approaches a floor that cannot scan.
We are independent and we do not sell the build, the labels or the hardware, so the finding is whatever the floor shows. A senior consultant spends a day on your site with your labels and your devices, works through the layers above, and writes up what is stacked and in what order to fix it. You get a plain-language memo in five working days, with no proposal attached.