Every product history has to start somewhere. In EPCIS, it starts with commissioning: the record that a particular identifier now stands for a particular physical item. Getting that first entry right is the difference between a history you can trust and one that contains products that never existed.
What commissioning means
Commissioning is a business step defined in the CBV (Core Business Vocabulary), the GS1 standard that supplies shared words for EPCIS events. It describes the process of associating an identifier with a physical object for the first time. For a serialized product, the identifier is a GTIN plus a serial number; for a carton or pallet, often an SSCC.
In EPCIS terms, a commissioning event is usually:
- an ObjectEvent (something happened to one or more objects),
- with action
ADD(these identifiers are coming into existence in the history), - with business step
commissioning, - and typically disposition
active(the item is now live stock).
Like other EPCIS events, it records when (the time of the event and its time-zone offset) and, in practice, where: the read point (for example, line 3) and the business location (the factory). The EPCIS business guide shows a simplified example of this event in EPCIS 2.0 JSON-LD.
The question that matters: when?
A serial number passes through several stages before it is on a finished product. The trap is to commission it at the wrong one.
| Stage | What has happened | Commission now? |
|---|---|---|
| Allocated | The ERP or serialization system has reserved serial 10045 for tomorrow's run | No: nothing physical exists yet |
| Sent to the coder | The line software has passed 10045 to the printer | No: it may never be printed |
| Printer acknowledged | The printer reports that it printed 10045 | No: the mark may be smudged, misplaced or missing |
| Verified on the item | A camera or reader has read 10045 from the bottle and confirmed it matches | Yes: this is the evidence that the identity is on a real item |
Allocation is planning. A serial that has only been allocated exists in a database, not on a bottle. If you commission at allocation and the run is cancelled, your history now contains thousands of products that were never made. What happens after an ERP creates a serial number? traces those planning stages in more detail.
The printer's acknowledgement is also not enough. A coder can report success while the ink was too faint to read, the label was skewed or the item had already left the print zone. Why "printed" is not the same as "verified" explains the gap. The sensible trigger is a successful read of the code from the item itself, which is what cameras and barcode readers on the line are there to provide.
A worked example: three serials, three outcomes
Volta Cables, a fictional cable maker, applies a serialized label to every reel. One morning, three consecutive serials go to the line:
- 10045 is printed at 09:14, read by the line camera and confirmed. The line records a commissioning event for 10045 at 09:14, at Volta's factory location. Its history has begun.
- 10046 is printed but the label is creased; the camera cannot read it and the reel is diverted for relabelling. No commissioning event is recorded for 10046. The serial is marked as rejected in the serialization system so it cannot quietly appear later.
- 10047 is allocated but the line stops before it is printed. It is never commissioned and is returned or voided according to Volta's rules.
When a distributor later scans a reel and checks its serial against Volta's records, only 10045 has a history. A serial like 10046 turning up in the market would be a signal worth investigating, because Volta's records say it was never applied to a reel. Keeping this one-to-one match between verified items and commissioning events is what exactly-once serialization is about.
What comes after commissioning
Commissioning is rarely the only event at the factory. Once units are commissioned, they are packed into cartons and the cartons onto pallets, and each packing step is recorded as an aggregation event. A sound rule is that only commissioned items can be aggregated: if a unit has no commissioning event, it shouldn't appear inside a carton.
Many programmes commission the containers too. When a carton's SSCC label is applied and verified, a commissioning event for that SSCC can be recorded before the carton is linked to its contents.
Decommissioning: the other end of an identifier's life
Sometimes an identifier must be taken out of use. The CBV defines a business step for this: decommissioning. A decommissioning event is typically an ObjectEvent with action DELETE, recording that the identifier is no longer associated with the object.
Typical reasons include:
- a label that was commissioned but then damaged and removed during rework;
- an item taken apart or repackaged so that its old identity no longer applies;
- a unit pulled from the line for destructive quality testing.
Decommissioning is about the identifier. It is different from recording that the object was destroyed, which is usually expressed with the disposition destroyed. In both cases, the old serial should not be reissued to a different item.
Why it matters to the business
Commissioning events are the foundation for every question you will ask later:
- Recalls depend on knowing exactly which serials were really made in an affected batch.
- Reconciliation between the ERP's plan and the line's output depends on a clean list of what was actually marked.
- Checks in the market, such as a distributor or consumer scanning a code, are only as good as the brand's record of which codes were legitimately applied.
An inflated or incomplete commissioning record undermines all three.
See how the Line Gateway connects ERP, printer and camera