Serialisation systems: allocating, applying and accounting for unit identity

Identifier allocation is a controlled resource

A serial scheme is a finite, ordered resource that several systems may draw from at once. Ranges are issued to lines, lines consume them, and the accounting has to survive a restore from backup. The classic incident is a database recovery that resets a counter and reissues identifiers already applied to shipped product. Allocation should be blocked out to each line in advance, tracked as issued rather than as a next value, and never reset. Where a customer or authority mandates the format, the scheme also has to carry their structure, which limits how much of it you may treat as freely yours.

Aggregation, and the harder problem of breaking it

Nobody unpacks a pallet to learn what is on it. Aggregation records that these units went into that case, and those cases onto this pallet, so one scan at dispatch resolves the whole hierarchy. The awkward part is not building the chain but breaking it: a case opened for sampling, a damaged unit swapped, a pallet rebuilt for a partial shipment. Each needs a supported disaggregation transaction. Where the system offers none, the warehouse will eventually ship a pallet whose declared contents no longer match what is physically strapped to it.

Marking, verification and the fate of a bad code

A code that cannot be read reliably is a defect whatever the database believes. Inline verification checks grade and content immediately after marking, turning a print quality problem into a rejected unit rather than a customer complaint months later. The rejected identifier then has to be accounted for — decommissioned, never quietly reused. Sites casual about rejects lose the ability to reconcile commissioned identifiers against shipped units, and that reconciliation is exactly what an external party asks to see. Store the reject reason too, so a drifting print head shows as a trend rather than as noise.

Packing continues when the server does not

Serialisation sits in the production path: if allocation stops, packing stops. Availability therefore becomes a production question rather than an IT one. The usual answer keeps a buffered allocation and a local store at the line so it can run independently and reconcile when the link returns. Decide in advance how long a line may operate disconnected and what it must refuse to do while disconnected. The boundary between plant control systems and business systems is a designed interface with defined failure behaviour, and treating it that way is more productive than assuming continuous connectivity.

Handing data to parties outside your walls

Serial data usually has to reach somewhere else: a customer's receiving system, a shared repository, an authority's platform. Those interfaces change on someone else's schedule and in someone else's format. The durable arrangement keeps your internal model clean and puts external formatting in a translation layer you control, so a change at their end is a mapping edit rather than a plant upgrade. Plan for retransmission as well, because acknowledgements go missing, and a queue of unconfirmed submissions with no resend path becomes a manual reconciliation chore that never ends.

Frequently asked questions

Is serialisation just barcode printing with extra steps?

Printing is one link in a chain that also covers allocating provably unique identifiers, recording which unit entered which case, verifying the mark, decommissioning codes never used, and reporting to external parties. A label printer with a counter satisfies none of that. The difference becomes obvious the first time someone asks you to demonstrate that a specific identifier was applied once, to one unit, which shipped to one named customer.

What happens to identifiers on units we scrap?

They are decommissioned against a reason code and never reissued. The reconciliation an auditor or customer performs compares identifiers you commissioned with identifiers you can account for, so an unexplained gap resembles diverted product rather than ordinary loss. Build the scrap transaction into the line workflow so an operator disposing of a damaged unit records it immediately, rather than dropping it in a bin and assuming the record will resolve itself later.

Should we mark individual units or only cases?

It depends on the question the identity must answer. Case-level identity supports distribution and shipment verification. Unit-level identity supports field returns, warranty claims and investigation of a single item. Unit marking costs line time, print hardware, verification equipment and a far larger data volume, so commit to it only where somebody downstream will genuinely scan it. Deciding late is expensive, because artwork, line layout and data architecture all depend on the answer.