The beep feels like the job is done. The scanner read the code, the screen flashed, and everyone moves on. But a scan by itself answers nothing: it does not say whether the number is valid, what its fields mean, or where the information went. The value of scanning is created after the beep, in the short journey from a decoded symbol to a record somebody can rely on months later.

That journey has four stages, and skipping any one of them quietly breaks traceability: capture the symbol, parse it into fields, validate what you got, and record it in a form that can be found again. This article walks through each stage with one running example — a serialized medicine carton — and shows what "good" looks like at every step.

Capture is not understanding

Capture is the physical act: a scanner reads bars or modules and returns characters. A good capture is complete and unambiguous — the whole symbol, read cleanly, with no guessed characters. Anything less is not a head start; it is a corrupted input that every later stage will faithfully preserve.

The most common capture failure is also the most human: a damaged label that almost scans. An operator retries, tilts, moves closer, and eventually gets a read — but never checks whether the read matches the label. Capture discipline is simple: if the symbol does not read cleanly, treat it as an exception (see the receiving-exceptions article) rather than forcing a result.

Parse: from characters to fields

Parsing turns the captured characters into named fields. For a plain 1D barcode the parse is trivial — the characters are the identifier, usually a GTIN. For a GS1 symbol the parse is where the real work happens: the element string is split by its Application Identifiers into GTIN, batch, expiry, and serial, each with its own meaning and format.

Take the carton in our example. Its GS1 DataMatrix decodes to the element string (01)10950600013436(17)271231(10)ABC123(21)SN0001. Parsed, that is: GTIN 10950600013436, expiry 31 December 2027, batch ABC123, serial SN0001. The parentheses are human-readable punctuation only — the encoded symbol carries the fields and their separators, not the brackets. If your parser cannot separate these fields reliably, you do not have four facts; you have one long string that only a human can interpret, and traceability built on human interpretation does not scale.

Validate before you trust

Validation is the stage most often skipped, because a successful decode feels like proof. It is not. A decode proves the symbol was readable; validation proves the content makes sense. At minimum, validate three things before the data goes any further.

  • The check digit recomputes. For a GTIN, the GS1 Modulo-10 check digit must match; a mismatch means the number as read is not the number that was issued, and the scan stops there.
  • Each field is well-formed. The expiry date must be a real calendar date in YYMMDD order; the batch and serial must be present where policy requires them; the GTIN must be the right length for its format.
  • The identity is expected. A valid, well-formed GTIN that nobody ordered and no catalogue recognizes is not a success — it is an unknown item, and it belongs in the exception path.

Record so it can be found

Recording is where most traceability efforts quietly fail, because they record for the present instead of for the recall. A record written for today answers "what arrived?"; a record written for a recall answers "which units, from which batch, received when, from whom, and where did they go?" — and it must answer those questions by GTIN, by batch, or by serial, whichever key the investigation starts from.

Two properties separate a useful record from a decorative one. First, it preserves the scan as captured, not only the corrected version: if a label was re-scanned or an exception was resolved, both the original and the resolution belong in the history. Second, it keeps the fields separate: GTIN, batch, expiry, and serial as distinct values, not fused into one text blob. A record that must be re-parsed by a human during a recall is a record that was never really structured at all.

That is the whole journey: a clean capture, a correct parse, a strict validation, and a retrievable record. When all four hold, the beep at the dock door becomes evidence. When any one is missing, it stays just a sound.

A scan event is not a recordThe left panel is what the beep gives you; the right panel is what traceability requires. A scan becomes a record only when every item on the right holds.
A scan event
  • Decoded characters from the symbol
  • Device and timestamp of the scan
  • No proof the content is valid
  • No link to an expected order or catalogue
A complete record
  • Fields parsed: GTIN, batch, expiry, serial
  • Check digit and formats validated
  • Identity matched to an expectation
  • Stored separately, retrievable by GTIN, batch, or serial
  • Original scan preserved alongside any correction

References