AIDC GODiscuss Your Application

TECHNICAL FOUNDATION

Barcode Scanner Output Length: Check UPC/EAN Prefixes, Check Digits and Conversion

Diagnose UPC and EAN output-length differences by separating encoded data, decoder preambles, check-digit transmission, conversion rules and business lookup.

Discuss your application

Two scanners can read the same UPC symbol and deliver strings of different lengths. One profile may include the system character and check digit, another may suppress one of them, and another may expand a UPC-E symbol before transmission. The difference can be intentional configuration rather than a failed decode. The receiving application still needs one documented representation for product lookup.

This guide separates symbol data, decoder output and application storage. Its number is an editorial teaching string, not an assigned customer code or an AIDC GO device test. The handheld-terminal category, mobile barcode data-capture solution and Integration Support are commercial starting points; model-specific decoder controls must be confirmed from the approved configuration and software documentation.

Separate four representations before comparing length

The symbol carries data under its symbology rules. The decoder interprets that symbol. A scanner profile can then decide whether to transmit a preamble or check digit and whether to convert one supported representation to another. Finally, the receiving application may trim, pad, type-convert or map the returned string. These are four different places where a visible length can change.

Record the symbology name reported by the interface, the complete returned string, its character count, and the profile that produced it. Do not start by deleting a first or last digit. A first character may be a UPC system character or a configured country-code preamble; a last character may be a transmitted check digit. The same-looking change can also be an application transformation, so the capture boundary matters.

The GS1 General Specifications define GTIN-12, GTIN-13 and other fixed-length GS1 identification keys as numeric data strings with a final check digit. Shorter GTIN formats can be padded with leading zeroes when represented in a 14-digit field. That identifier rule is separate from the decoder's choice about which UPC preamble characters it sends to a host.

Recalculate one teaching GTIN before testing profiles

Use the editorial eleven-digit body 01234567890. Under the GS1 check-digit algorithm, the digits in alternating positions are weighted by three and one. Here, (0 + 2 + 4 + 6 + 8 + 0) × 3 = 60, while 1 + 3 + 5 + 7 + 9 = 25. The total is 85, so the next multiple of ten is 90 and the check digit is 5. The full teaching GTIN-12 is therefore 012345678905.

GS1's manual check-digit guidance describes the same alternating-weight calculation. A valid check digit confirms that the digits are structurally consistent; it does not prove that the number is allocated, that the symbol belongs to the intended product, or that a matching product record exists.

The following outputs illustrate explicit DataWedge 15.0-style choices for that teaching value. They are configuration examples, not default behavior promised for another scanner.

Output profile Illustrative returned string Length What changed
System character plus check digit 012345678905 12 Full teaching GTIN-12 representation
System character, no transmitted check digit 01234567890 11 Final 5 omitted from host output
No preamble, check digit transmitted 12345678905 11 Initial system character omitted
Country code and system character plus check digit 0012345678905 13 Additional country-code preamble transmitted

Treat preamble and check-digit transmission as independent settings

Zebra's DataWedge 15.0 decoder documentation identifies decoder_upca_report_check_digit as the UPC-A control for transmitting the check digit. It separately lists decoder_upca_preamble choices for no preamble, system character, or country code plus system character. The names, defaults and available values are specific to the documented DataWedge version and supported devices.

If the application expects 012345678905 and receives 01234567890, first determine whether the profile intentionally suppressed the check digit. If it receives 12345678905, determine whether the system character was omitted. Do not decide by length alone: compare the exact positions against a known symbol and the recorded profile.

Check-digit transmission and product recognition remain separate tests. An application may be designed to store a GTIN without the check digit and recalculate it, or it may require the complete GTIN-12. Either contract can be implemented deliberately. A structurally correct 012345678905 can still produce “item not found” when the product master has no corresponding record, the wrong identifier type is queried, or the active task expects another item.

Recognize conversion as a representation change

UPC-E uses a compressed representation for eligible number patterns. A decoder option can expand that result to UPC-A before transmission, changing the character count without changing the intended trade-item identity. In the same DataWedge 15.0 documentation, decoder_upce0_convert_to_upca converts decoded UPC-E0 data to UPC-A format and then applies the UPC-A preamble and check-digit selections.

The correct comparison is therefore not “eight characters versus twelve characters means one read is wrong.” Record the reported input symbology, whether conversion was enabled, the output profile and the resulting business key. Disable conversion only when the receiving application is designed for the compressed representation; enable it only when the application expects the expanded form. A universal rule to add zeroes or slice fixed positions will fail across number systems and conversion states.

If a project accepts UPC-A, UPC-E and EAN-13, define the canonical lookup format explicitly. Padding a GTIN-12 to a 14-digit database field is a GS1 representation rule; inserting or removing a scanner preamble is an output rule. Keep those transformations named and testable rather than merging them into one unexplained “normalization” step.

Capture raw output before opening Excel or the WMS

First scan a controlled symbol into a text-preserving diagnostic receiver that exposes every character and the symbology metadata available from the interface. Record the output length and any prefix, suffix, Enter or Tab. Then repeat with the target application. This separates scanner-profile behavior from field validation, spreadsheet conversion and application lookup.

The Excel preservation guide explains how a correct character string can later lose a leading zero or be converted to a number. The keyboard-layout guide covers wedge characters affected by the host layout. The GS1 parsing guide handles application identifiers and structured fields. None should be used to hide an unexplained decoder-output difference.

For acceptance, use at least one known UPC-A symbol, one eligible UPC-E symbol if the workflow supports it, and one EAN-13 symbol. Test each enabled profile once, preserve the received value, and compare it with the documented expected representation. Change one control at a time. A successful beep or a valid check digit is not the same as a successful lookup.

Reject unsafe repairs and preserve the exception

When the received value does not match the contract, keep the raw output, symbology, profile version and expected value in the exception record. Do not automatically delete the first digit, delete the last digit, append a zero, or accept the nearest product record. Those shortcuts can make a length test pass while selecting another identifier.

Classify the result precisely. A wrong output format is a configuration or integration exception. A correct format with an invalid check digit is a data or symbol exception. A valid, correctly represented identifier with no database row is a master-data or task-scope exception. The enabled-decoder guide covers the separate question of which symbologies are active.

Bring the known symbols, expected strings, decoder profile export, interface type, target application contract and exception examples to procurement. Ask the device or software supplier to demonstrate the exact model and version. Use Contact AIDC GO to review the hardware and integration boundary; no UPC/EAN formatting control is implied for an AIDC GO model without its approved documentation.

PROJECT DISCUSSION

Bring the workflow, evidence and unresolved questions.

AIDC GO supports hardware direction and evaluation; the customer owns application software and final business logic.

Discuss your application