How does a product tracking system work?

Each unit receives a unique code at production. Every movement, such as warehouse receipt, dispatch and sale, is recorded as an event by scanning the code, building a complete history for that unit.

How do you verify a warranty claim?

Look up the unit by its code and check that it is genuine, was sold through a valid path, is within its warranty period and has not already been replaced under an earlier claim.

Should serial numbers be tracked individually or by batch?

Track individually when warranty, recalls or anti-counterfeit checks matter. Batch tracking is cheaper and enough when you only need to trace a production lot.

Product Tracking and Warranty: A Data Model

How to design a product tracking and warranty system: unique product codes, an event log from factory to distributor, status rules and claim checks.

When a customer brings back a faulty product, three questions follow. Is it ours? When was it sold? Is it still under warranty? Answering them quickly requires knowing where each individual unit has been. This post describes a data model for tracking product codes from factory to warehouse to distributor, and for running warranty on top of it.

Give every unit an identity

Stock quantities tell you how many units exist. Tracking needs to know which ones. Each unit gets a unique code, printed as a barcode or QR code at production. The code should be generated by the system, hard to guess and include a check digit so typing errors are caught.

product_units
  id, code (unique), product_id, batch_no, produced_at,
  current_status, current_location_type, current_location_id,
  warranty_start, warranty_end

Record events, not just the current state

The current status answers where the unit is now. The history answers everything else. Store each step as an event row and never edit it. The status on the unit is simply the result of the latest event.

unit_events
  id, unit_id, event_type, from_location, to_location,
  document_type, document_id, scanned_by, occurred_at

Typical event types are produced, received at warehouse, dispatched to distributor, received by distributor, sold, returned, replaced and scrapped. Linking each event to its document, such as a delivery challan, lets you move from one unit to the whole shipment it travelled in.

Define which moves are allowed

A unit cannot be sold before it is dispatched, or dispatched twice. Keep a small table of allowed transitions and reject any scan that breaks it, with a clear message to the person scanning. These rejections are valuable: they reveal process gaps and, sometimes, leakage.

Make scanning fast and forgiving

Scan cartons where possible: a carton code linked to its units records fifty moves in one scan.
Let warehouse and distributor staff work on a phone, with offline capture where signal is weak.
Accept a batch of scans and report the failures individually instead of rejecting the whole batch.
Make the scan API idempotent, so a repeated upload does not create duplicate events.

When does the warranty start?

This is a business decision with real cost, so settle it early. Common options are the sale date to the end customer, the dispatch date to the distributor plus a grace period, or the production date. Store both start and end dates on the unit once known, so the answer does not change if the policy changes later.

Checking a warranty claim

With the model above, a claim is a lookup by code. The system can check automatically that the code exists, that the unit reached a sold status through a valid path, that today is within the warranty period and that no earlier claim replaced the same unit. Anything unusual goes to a person, together with the unit's full history.

What the data gives you beyond warranty

How long stock sits at each stage, per product and per distributor.
Which batch a group of failures came from, for a targeted recall.
Units appearing in territories they were never shipped to.
Claim rates by product, batch and period, for the quality team.

The principle of recording facts rather than balances runs through all business data. I cover it more broadly in ERP database design mistakes. For the scanning app itself, see offline-first sales apps.