"Exactly-once" is a phrase that engineers say with a slightly pained expression. It sounds like an obvious requirement — every serial used once, recorded once — yet it is one of the hardest properties to achieve in any system that combines machines, networks and databases. This guide explains what it means on a packaging line, why it is hard, and the techniques that make it achievable.
Three promises, not one
"Exactly-once serialization" bundles three separate promises:
- No serial is printed on two packs. Two products must never share one identity.
- No serial is lost. Every serial issued to the line ends in a known state — packed, rejected, or returned — and nothing disappears from the records.
- No serial or carton is registered twice. The ERP and other systems record each result once, even if the message carrying it was sent more than once.
Each promise fails in a different way, so each needs its own protection. If you have not yet followed a pack through the line's stations, the journey of a serialized product through a packaging line gives the context for the examples below.
Why it is hard: the uncertain moment
Imagine posting a cheque. You put it in the post box and go home. A week later, the payee says it has not arrived. Do you write another one? If the first was merely delayed, you have now paid twice. If it was lost, not writing another means you never pay.
Computer systems face this constantly. Line software sends "carton 0457 contains these twelve serials" to the ERP. The network drops before the reply arrives. The software now does not know whether the ERP recorded the carton.
- Resend blindly and the carton may be registered twice.
- Give up and the carton may never be registered.
Neither is acceptable. And the same uncertainty exists between software and printer (did it print?), between printer and camera (which pack is this?), and between camera and reject device (did the pack actually leave?).
Technique 1: one-way serial states
The first protection is a strict state machine for every serial: a fixed list of statuses and the only moves allowed between them.
A simplified version:
- available → sent to printer → verified → packed → registered
- sent to printer → rejected/void
- verified → rejected/void
The rules that matter are the ones that forbid moves. Once a serial is sent to a printer, it can never return to "available", because it might already exist on a physical pack. That single rule is what prevents most duplicate prints. If a smudged pack is reprinted, it gets a new serial, and the old one is voided.
We describe these states in context in what happens after an ERP creates a serial number.
Technique 2: write it down before you act
Every state change is written to durable local storage before the system acts on it. The serial is marked "sent to printer" before the message goes to the coder. The carton registration is written into a persistent outbox before it is sent to the ERP.
If the PC loses power halfway, it restarts, reads its own records and knows what might have happened. A serial marked "sent to printer" with no camera result is treated as possibly printed — and voided, not reissued. A registration still in the outbox is still to be delivered.
The analogy is a pilot's checklist: you tick the item as you do it, so if you are interrupted you know where you were.
Technique 3: make repeats harmless (idempotency)
Across a network, guaranteeing that a message is delivered exactly once is generally not possible. The practical approach is to accept that it might be delivered more than once and make sure that processing it twice has the same effect as processing it once. That property is called idempotency.
In practice, each registration carries a stable identifier — say, the carton's ID plus a registration ID created when it entered the outbox. If the ERP receives the same registration again, it recognises the identifier and returns the original result instead of creating a second record.
A lift button is idempotent: pressing it five times calls the lift once. A vending machine coin slot is not.
Idempotency needs cooperation from the receiving system. If the ERP cannot recognise repeats, the sender has to compensate with the next technique.
Technique 4: check before retrying
When the outcome of a send is uncertain, a careful system asks the destination what it knows before trying again: "Do you have carton 0457?" If yes, mark it registered. If no, send it. If the ERP returns a definite business rejection — say, a serial it does not recognise — that is not a network problem and should not be retried automatically; it becomes an exception for a person to resolve.
Separating transient failures (timeouts, network drops — worth retrying) from permanent rejections (bad data, business rule violations — retrying will not help) prevents endless blind resubmission.
Technique 5: reconcile the totals
Finally, at the end of a run (and ideally continuously), the system proves the books balance:
serials issued = packed + rejected/void + returned unused
If that equation does not hold, something is missing or duplicated, and it should be investigated before the batch is released. Reconciliation is the safety net that catches whatever the other techniques missed.
The same applies to cartons and pallets: every carton's serial count should match its records, and every pallet's carton list should match what was built. These parent–child records are what aggregation means.
Where physical reality breaks the rules
Most real duplicates and losses come from the physical world, not the database:
- Hand removals. An operator lifts packs off the belt between coder and camera. The software's tracking now points at the wrong packs. Detecting consecutive mismatches and stopping is the defence.
- Unconfirmed rejects. A reject device misses; a pack marked rejected ends up in a carton. A chute sensor confirming each reject is the defence.
- Manual reprints. Someone reprints a code by hand from the coder's keypad, outside the software. Locking down manual printing of serialized messages is the defence.
- Rework. Packs opened and repacked later must keep their serials and be re-aggregated, not given new ones.
Each of these needs a procedure as much as a feature.
Events need the same care
If your line also produces supply-chain event data — for example commissioning and aggregation events in EPCIS — the same principles apply. Give each event a stable identity when it is created, queue it durably, and let receivers recognise duplicates. See what a commissioning event is.
What it really takes
Exactly-once serialization is achievable, but honest projects budget for:
- a defined serial state model, agreed between line and ERP teams;
- durable local storage and an outbox on the line;
- idempotent or queryable interfaces on the ERP side;
- physical confirmation at the reject station;
- operator procedures for stops, removals and rework;
- reconciliation reports, reviewed before batch release;
- testing of failure cases — power cuts, network drops, jams — not just the happy path.
Network and ERP outages are one of the main stress tests for all of this; see what happens when the internet or ERP goes down during production, and the local layer that implements most of it in why edge software matters on a packaging line.