Barcode management in LS Central: setup, duplicates, and till lookup failures

Implementation · 8 min read

A barcode failure at the till looks like a scanner problem and is almost never a scanner problem. The scanner read the number correctly. The number simply does not resolve to one item, in one place, in the data the POS is searching. Barcode management is therefore a data discipline with three questions at its centre: where does this number live, is it the only record carrying it, and was it typed by a person when the system could have generated it. Answer those three and most lookup failures disappear before they reach a customer.

Three places a barcode number can live

Confusion starts because a barcode number can legitimately exist in three different places, and they are not interchangeable. A real forum question on the Dynamics community captures the confusion exactly: is the GTIN field on the item card the correct way to add barcodes, given that other documentation points to the item reference list? The honest answer is that they do different jobs.

That last row matters operationally. In the same forum thread, the accepted guidance is that the GTIN can be maintained and labels printed from Business Central through Reports, Print Label, while the GTIN is not available as a field on order lines — and that many Business Central customers add a separate barcoding solution because the out-of-the-box barcoding is limited. None of that makes the GTIN useless; it makes it the wrong place to debug a till lookup. The till resolves barcode records and references. Debug where the till actually looks.

The one hard rule: a number, once, in the table

The LS Central field documentation for Barcode No. is short enough to quote in spirit: the number must be unique — the same number cannot exist twice in one table — and as many numbers as needed can be created. Two corollaries follow. First, an item is not limited to a single barcode; several numbers can point at one item, which is how manufacturer changes and own-label replacements are absorbed without renumbering the item. Second, one number can never point at two items inside the table, so a duplicate is not a cosmetic defect — it is a broken key. There is also a collision to avoid at setup: a barcode number cannot be a number already used as a number in the Income/Expense Account table. Clean data is the precondition here as everywhere in retail data: a number entered before anyone has checked what it collides with creates downstream effort at receiving, at counting, and at the till.

Duplicates usually arrive by process, not by malice. A number is typed manually for an item that already carries it under a variant. A spreadsheet import loads manufacturer barcodes over the top of existing records instead of against them. A replacement product inherits the outgoing product's shelf label — and its barcode record — before the old item is retired. Each route produces the same symptom family: the till finds nothing, finds the wrong item, or finds the right item in the wrong variant. The fix is never at the till. It is in the table, where the number's single home can be restored.

Variants and masks: generate combinations, do not hand-type them

Variants multiply barcodes faster than any other feature in the item file. LS Central variants handle retail items with up to six different variant dimensions, and the design intent is explicit: assign a unique barcode for each variant combination, and staff can scan the barcode at the POS terminal and let the program find which variant is being sold — which is also how variant sales statistics become collectable. Multiply a handful of sizes by a handful of colours and the combinations outnumber anyone's typing accuracy.

That is what barcode masks are for. When barcode masks have been assigned to Product Groups or to items, the program uses the mask to generate barcodes automatically for each variant combination. Without a mask, every combination has to be manually assigned its barcode — every one a chance to transpose two digits, reuse a number, or skip a combination entirely and discover the gap during a sale. The setup order matters too: Variant Framework Codes must be set up before variant dimensions, and the Barcode Mask field sits on the Variant Framework Codes Card, so the mask decision belongs at framework setup time, not after the variants already exist. Item References follow the same per-variant discipline on the Business Central side: a documented setup example adds one Barcode reference with one number for an item's ESSENTIAL variant and a different number for its PREMIUM variant, each reference carrying its variant code. A barcode without its variant code is half a key.

GS1 barcodes: know which version the store is running

Barcodes in LS Central encode information such as product numbers, serial numbers, and batch numbers, and they are used to automatically identify and track products as they move through the supply chain. LS Central supports GS1 Barcodes — compact 1D barcodes that can hold additional product attributes, such as the weight of fresh food. The versioning is the part stores get wrong when a lookup behaves unexpectedly after an upgrade. GS1 functionality exists in two versions. Version 1 was in use up until LS Central version 26 and relies on manual setup stored in the GS1 BarcodeV1 setup page. From version 27, both Version 1 and Version 2 are available: Version 2 needs no setup and works according to the GS1 standard. The versions can be switched in the GS1 Barcode Setup page, and switching needs no data upgrade. So before rebuilding any GS1 setup by hand, check which version is active — a store on Version 2 that is still maintaining Version 1 setup pages is doing work the system is no longer asking for.

When the till cannot find it: a diagnosis procedure

1. Capture the exact number. Scan the failing barcode into a document or note the digits from the label. Diagnose the number that was actually read, not the number someone remembers.
2. Search the Barcodes table for that number. No record at all means the number was never given a home — check whether it exists only as a GTIN or only on a supplier document, then create the barcode record for the item.
3. Check for the number more than once. More than one record carrying the number is the duplicate case: decide which item the number belongs to, remove it from the other, and give the displaced item its own number.
4. If the item is a variant, check the variant dimension of the record. Confirm the barcode belongs to the exact variant combination in hand, and check the Item References for a Barcode reference carrying the matching variant code — a base-item resolution with the wrong variant is a data error, not a sale.
5. If variants are involved and barcodes were typed by hand, check the mask. Confirm a barcode mask is assigned at the Product Group or item level and on the Variant Framework Code; where it is missing, expect manual gaps and regenerate the combinations systematically instead of patching one scan at a time.
6. If the barcode is GS1, check the active version. Confirm in the GS1 Barcode Setup page whether Version 1 or Version 2 is active before changing any GS1 setup.
7. Retest at the till with the physical item. Scan the same item that failed, in the same store, and complete a test sale line before returning the item to the shelf.

What success looks like

Success is boring, and that is the point. Every barcode in the table resolves to exactly one item or one variant combination; a scan of each variant of a variant item lands on that variant, not on the base item; and a search for any number the store sells returns a single record. The practical test: pick five items at random from the shelf, including at least one variant item in two different variants, scan each one at the till, and confirm the item and variant on screen match the product in hand five times out of five. Anything less is a data queue to work through — in the table, at a desk, before the next customer is kept waiting.

FAQ

Can one item have several barcodes? Yes. As many barcode numbers as needed can be created for an item. The rule runs the other way: one number cannot appear twice in the Barcodes table.

The GTIN is filled in, so why does the till not find the item? The GTIN field and the barcode records the till resolves are different homes for a number. Check the Barcodes table and the Barcode-type Item References first — that is where lookup succeeds or fails.

One size scans and another does not. What broke? Most likely the variant barcodes were assigned manually and one combination was missed or mistyped. Check that combination's record, then check whether a barcode mask is assigned so the remaining combinations are generated rather than typed.