A GS1 barcode can decode successfully while a warehouse management system (WMS) rejects the result, puts two values into one field, or looks up the wrong identifier. To locate the mismatch, compare the intended label data, the value received by the application, the parsed fields and the WMS lookup result. A successful decode alone does not establish that all four agree.
For system integrators and application teams, this comparison helps identify what needs attention: label construction, output configuration, parsing or business mapping. It also gives a hardware supplier a specific question to investigate before the team changes devices.
Start with one mismatch you can reproduce
Choose one label and one WMS task. Record what should happen: which item should be found, which batch or serial should appear, and what result confirms acceptance.
Then capture the application's received value and its parsed fields separately. A screenshot of a text box is useful context, but it may conceal control characters or show a reformatted value. Compare the earliest available received value with the value immediately before parsing. Note where each observation was taken.
Ask the application owner to identify the first disagreement. Did the receiver get unexpected characters? Did the parser produce an unexpected batch? Did the correct GTIN fail to match an item? These are different findings and need different follow-up work.
If the symbol still cannot be decoded consistently, start with Barcode Label and Scanner Selection Basics to evaluate the physical capture conditions.
Confirm which data representation you have
This guide focuses on GS1 Application Identifier element strings, particularly in GS1-128 and GS1 DataMatrix workflows. Confirm that the label uses that syntax. The appearance of an ordinary Code 128 or DataMatrix symbol does not establish its data structure.
Human Readable Interpretation (HRI) places parentheses around Application Identifiers, such as (01) and (10). Those AI parentheses are not encoded as part of the GS1 element string. Their absence from a scan result is therefore not evidence that the scanner lost characters. GS1's explanation of AI parentheses covers this distinction.
Also identify the software interface's expected format. The GS1 Barcode Syntax Engine, for example, provides separate inputs for bracketed element strings, unbracketed data, scan messages and GS1 Digital Link URIs. Its scan-data interface expects an AIM symbology identifier and intact separator characters. These are interface requirements, not assumptions about every scanner's default output. GS1 Barcode Syntax Engine documentation
If the received value is a GS1 Digital Link URI, route it through an appropriate URI-aware process. Feeding it into an element-string parser without recognizing the representation creates a different problem from a missing separator.
Read field boundaries from the GS1 rules
An Application Identifier (AI) specifies the meaning and format of its following data. Three relevant examples are:
- AI 01: a GTIN represented by 14 digits.
- AI 10: a batch or lot value, with a variable length of up to 20 permitted characters.
- AI 21: a serial value, also variable length up to 20 permitted characters.
Use the actual AI definitions, including character and association rules. The GS1 Syntax Dictionary records these constraints and identifies fields with predefined lengths that need no separator.
For AI 10 followed by another element, the separator establishes where the batch ends. When AI 10 is last, the end of the message provides that boundary. Do not generalize this into a rule that every fixed-length AI can omit a separator: GS1 distinguishes predefined length from fixed length. GS1 DataMatrix Guideline, sections 2.2.2–2.2.3
Example: a missing separator can produce a different valid parse
The following synthetic input uses a GTIN found in GS1's software documentation, plus invented lot and serial values. It illustrates parsing; it is not a customer label or evidence of an allocated product identity.
Intended fields, shown in bracketed form:
(01)09521234543213(10)LOT7(21)SN42
A normalized GS1 DataMatrix scan message can be displayed as:
]d2010952123454321310LOT7<GS>21SN42
Here, ]d2 is the reported symbology identifier. The visible <GS> marker stands for one Group Separator control character: decimal 29, hexadecimal 1D. It is not four literal characters to type into the input. FNC1 is a function symbol character used in GS1 encoding; the transmitted GS character represents the separator in this scan-message format.
In a local software check with the GS1 reference engine, the actual separator produced the intended batch LOT7 and serial SN42. Removing that character produced this input:
]d2010952123454321310LOT721SN42
The engine accepted it, but extracted batch LOT721SN42 and no serial field. The altered batch still met the field's syntax constraints.
That result explains why checking only for a parser error is insufficient. Assert the expected field set and values as well. Searching for the digits 21 inside the batch would be an unsafe repair: those digits can belong to the batch itself. Find the first place where the separator or intended field boundary was lost.
This check used synthetic strings and software, without a physical scanner or WMS connection.
Compare the output contract at both ends
Preserve an unmodified diagnostic capture before experimenting with cleanup rules. Record whether it contains the received application string, a byte capture, formatted display text or already-parsed fields. Include the configuration and software versions needed to repeat the observation.
For byte-oriented captures, a hexadecimal view can expose a control character that a normal text box hides. For string interfaces, use an escaped display that distinguishes the actual character from text describing it. Record both the display convention and the underlying value.
Output settings can also change which data is delivered. Zebra DataWedge 15.0, for example, documents GS1 token selection, token order and separator settings. It can output tokens or barcode data together with tokens. This is a vendor-specific example of why the receiver's expectations must match the configured output; it does not establish equivalent features on an AIDC GO device. Zebra DataWedge Keystroke Output
Some transformations are intentional. Microsoft's documented Dynamics 365 Supply Chain Management workflow expects a configured GS1 prefix and conversion of the nonprintable group separator to a printable character, such as a tilde. A different parser may require the original control character. Check the receiving system's contract before declaring a replacement wrong. Microsoft's GS1 barcode configuration guidance
Verify that both ends agree on the representation and that any conversion preserves field boundaries. A prefix that identifies the format, a field separator and an Enter key that submits a form serve separate purposes.
If the delivery channel itself needs review, use Barcode Scanner Integration: Wedge vs Intent vs SDK. Changing the channel still requires a defined data contract.
Check WMS mapping after parsing succeeds
Once the extracted values match the intended fields, follow the lookup performed by the WMS. Ask the application or master-data owner:
- Which identifier does this task expect: a GTIN, an internal item code or another key?
- Is the required relationship present in the relevant item and packaging records?
- Are batch and serial values assigned to the correct business fields?
- Does the current receiving, picking or confirmation step use the mapping being tested?
Avoid generic normalization as a shortcut. Keep the original identifier available, and document any conversion required by the destination field. Removing leading zeros from all inputs or sending the entire GS1 message to an item lookup can change what the application is being asked to match.
Microsoft's guidance also separates AI parsing from field mappings and menu-item policies. Use that as an example of application-specific configuration, rather than a universal WMS setup recipe.
A syntax check does not query your item master or confirm that a warehouse transaction has been accepted. Capture the lookup result and business response separately. The AIDC Device Integration Checklist helps assign responsibility for these application-level decisions.
Build a small test set with explicit expected results
Keep the diagnostic set focused on the disputed data. Include a known-good control, the failing sample and variations that exercise the suspected boundary. The following are investigation suggestions, not a prescribed GS1 certification test.
| Observation or test | Comparison to make | Evidence and owner |
|---|---|---|
| Batch and serial appear joined | Intended fields versus received separator and parsed fields | Capture at adjacent handoffs; capture and application teams |
| A short lot works, but a longer one fails | Different permitted lot lengths with a following element | Exact inputs and expected fields; parser owner |
Text appears to contain <GS> |
Actual control character versus literal display-marker text | Character or byte record; output and receiver owners |
| The GTIN changes during processing | Received identifier versus value used for lookup | Transformation rule and lookup key; application owner |
| A deliberately invalid check digit is supplied | Expected rejection versus parser response | Validation result; parser owner |
| Correct fields still fail an item lookup | Parsed values versus expected master-data relationship | Lookup and task result; WMS or master-data owner |
For every case, record both syntax expectations and business expectations. The missing-separator example needs a field-value assertion even when the parser reports success. Likewise, a syntactically valid identifier deliberately absent from test master data should not be treated as an accepted item.
Change one condition at a time and rerun the affected cases alongside the known-good control. Repeat on the intended receiving screen and configuration so a convenient test application does not become the sole evidence for the WMS workflow.
Once this specific mismatch is resolved, place the result into the broader AIDC Pilot Validation Checklist.
Frequently asked questions
Why are the printed parentheses missing from my scan result?
Parentheses identify the AIs for a human reader. They are not encoded as AI delimiters in the GS1 symbol. Software can also generate a bracketed display, so compare the documented input format rather than expecting the scan to look exactly like the printed text.
Can a successful parse still give the wrong WMS result?
Yes. The example above produced a valid-looking but unintended batch after a separator was removed. Even correctly extracted fields can fail a business lookup. Test the intended values and the receiving task's acceptance result separately.
Is a visible <GS> marker the actual separator?
It may be a diagnostic display convention, or it may be literal text. Check the underlying characters. In the normalized scan-message example, the separator is one control character; a configured receiver may instead use an agreed printable representation.
Will switching from keyboard input to an SDK fix the mismatch?
A different interface may change how data is delivered. It does not automatically correct the label, parser or WMS mapping. Locate the mismatch first, then evaluate whether the documented interface and configuration meet the application's needs.
Bring a reproducible data question to the hardware discussion
Prepare the capture task, label format, a shareable sample, the received representation, expected fields and actual result. Add the application environment and current output settings. A short description of where the values first diverge is more actionable than “the scanner does not work.”
AIDC GO can discuss hardware direction and the model or configuration information needed for evaluation. Your application team owns parsing policy, WMS rules and final acceptance. Specific interface capabilities need confirmation for the proposed configuration.
If the workflow calls for a handheld device, explore the rugged handheld terminals category with those requirements in view. To start a project conversation, discuss your application and summarize the mismatch you need to reproduce.