One item, one code

Single product traceability

Definition

One Item, One Code (single product traceability) refers to assigning a unique identification code (such as QR code, RFID, NFC) to each smallest sales unit (single product) to achieve full-chain traceability from production and circulation to consumption. Using coding systems like GS1 and EPC, it can be applied to pharmaceuticals, food, fast-moving consumer goods, and luxury goods, supporting scenarios such as anti-counterfeiting, traceability, marketing, supply chain visualization, and consumer interaction.

One Item, One Code differs from batch traceability and enables refined management at the single-product level. Codes are assigned and linked during production, scanned in and out of inventory during circulation, and then scanned for authenticity verification, prize redemption, and feedback during consumption, forming a closed-loop data system.

Technical Features

One Item, One Code generates unique codes using Variable Data Printing (VDP) or POD (Print on Demand). Barcode scanners, PDAs, RFID readers/writers, and smart shelves use IoT SIM cards to upload scan/read-write data to the traceability platform in real time. Data must be complete and tamper-proof, and combining with blockchain can enhance credibility.

Use Cases

One Item, One Code is widely used in pharmaceutical electronic supervision codes, food traceability, full cold chain traceability, D2C brand marketing, anti-counterfeiting, and loyalty marketing scenarios. SimtoLink provides stable network connectivity and dedicated APNs for one-item-one-code collection devices, ensuring real-time reporting of traceability data and supply chain visualization.


What a unit code means at the moment of capture

On an IoT SIM, one-item-one-code means the moment of capture: a scanner, a handheld, or a reader sees the unique code and sends it off site together with the place, the station, and the operator. The code is the identity of one unit. It is not a batch total, and it is not a carton code. This holds only when coding has already linked the unit code to a batch, a work order, or a logistics unit. The capture device only reports that this code was seen at this moment. If the link has not been written and someone scans anyway, the platform receives an isolated code, and later inbound and outbound moves have nothing to hang on. The drug supervision code on a smallest sale pack is one concrete form of the same problem, but food and consumer goods use different code-segment rules. Seeing a code is not the same as having finished a regulatory report.

Cellular here is the path from the capture device to the traceability platform. Printing and coding finish on the line and do not depend on this SIM. Where the signal is poor, in a deep warehouse, a cold store, or a shop back room, the terminal may queue scan events locally. Every queued row must carry the code, the time, and a sequence number. After the link returns, backfill in sequence order. The platform merges by code. It must not open a new trail from arrival order. A consumer authenticity scan reads the same code. If a channel scan and a consumer scan are both booked as outbound, the unit looks as if it left the warehouse twice.

A retry turns one scan into two

The easy failure is a retry that is not idempotent. The handheld times out and submits the same scan again. If the platform inserts another node from the time the server received it, the trail shows two almost identical outbound events. The terminal should generate an event ID, and a repeat submit should only update delivery status. Another failure is mixing carton codes and unit codes. A whole carton leaves, the units inside are uploaded one by one, and the carton code is uploaded as well, with no parent-child declaration. A query then shows the same bottle both still in the carton and already in transit.

When an offline queue backfills across midnight, it must not rewrite the original scan time. Using the time the backfill succeeded as the outbound time puts the goods in the wrong shift when cold chain or a recall is checked against a time window. If a damaged code is typed by hand, keep a "hand-entered" mark. Do not treat it as equal to a machine read. Acceptance can use one code three times: scan it online, scan it offline and then restore the link, and deliberately resend the same event. The platform may add only one node for that code, the time stays the field time, and the duplicate is rejected or merged.

After event IDs merge, the trail keeps one node

Submit the same scan twice for one unit code. The platform may add only one node, and the second response says it was merged. Two outbound events at nearly the same time mean the event ID did not take part in deduplication, and the backfill program treated the retry as a new action. A hand-entered code must carry the hand-entered mark. It cannot share one quality grade with a machine read. When a carton leaves, declare the parent-child relation with the units inside. Otherwise a query shows both "still in the carton" and "already left the warehouse."

After an offline gap that crosses midnight, the node time stays the field scan time. It must not become the time the platform received the row. If the batch link is added only after the scan, show it as a late association. Do not rewrite the batch as of the scan moment. If a consumer authenticity read finds a code the channel already scanned, count authenticity reads and outbound events separately, so one authenticity check is not booked as a second sale. After these checks, a unit trail does not fork when a weak link recovers.

Related Terms

Back to the IoT SIM Card Glossary