The Serial That Went Back to Available
A serial number is one physical unit with its own location, supplier, purchase order, warranty and status. Every field it holds is left alone when an update says nothing about it — except two, which are written every single time.
A generator is marked damaged on Tuesday. On Thursday somebody corrects its warranty date. On Friday it is available again, and nobody did that.
Our take
Serial tracking is the highest-resolution thing an inventory system does and it is worth the effort exactly where identity matters — a warranty claim, a recall, a service history, an argument about which unit was delivered. The mechanism here is sound: a serial is keyed to the item it belongs to, it holds everything you would want, and every movement writes an entry to an append-only trail beside it. The one contract detail worth carrying in your head is that two of its fields carry defaults rather than being left alone. In the receiving flow those defaults are exactly right. On any other path that touches a serial, a status the caller did not think to pass is a status that gets rewritten — and the record will look perfectly ordinary afterwards.
What a serial number is, here
A record of one physical unit, identified by three things together: your organisation, the item it is a unit of, and the serial as written. The same serial on two different items is two records, correctly — a manufacturer's numbering is theirs, and two manufacturers can both ship a unit numbered 000147.
It carries where the unit is, which batch it came from, who supplied it, which purchase order brought it, when it was received, when its warranty runs out, what state it is in, when it last moved, and what document created it.
| Field | What it answers |
|---|---|
| Warehouse and location | Which building and which shelf. |
| Batch | Which production run, where the item is also batch-tracked. |
| Supplier and purchase order | Who sold it and under which order — the two facts a warranty claim starts from. |
| Received date | When it arrived, as distinct from when it was made. |
| Warranty expiry | Per unit, not per item. Two units of the same product bought a year apart have different dates. |
| Status | What state the unit is in. |
| Last movement | When it last did anything. |
| Source type and id | Which document brought it into existence. |
The update contract, precisely
When a serial is recorded, the system either creates the record or updates the existing one, matched on those three key columns. What it writes is whatever the caller supplied, with empty values dropped — so an update mentioning only a warranty date changes only the warranty date, and the supplier, location and batch already on the record are untouched.
Two fields do not work that way. Status and last movement are given values before that filtering happens, so they are never empty and are therefore always written. An update that says nothing about the status writes "available". An update that says nothing about the last movement stamps the current moment.
Right in the flow it was written for
This is not a mistake so much as a contract tuned to its main caller. A unit being received is available, and it has just moved — so defaulting both is correct and saves every receiving path from stating the obvious. What the contract asks in exchange is that any other path carries the current status forward deliberately, because omission is not neutral here.
Saying nothing about a status is a way of saying available.
How to work with a contract like this
The general principle is worth stating because it applies well beyond this one function, and it is one of the recurring shapes in software that fails quietly.
-
A helper that defaults is not a helper that preserves
Two functions with identical signatures can behave oppositely on an omitted field — one leaves it, one writes a default. Neither is wrong; assuming without checking is. Read the definition before trusting the call.
-
Pass what you know, even when it is unchanged
Carrying the current status through an update costs one line and removes the entire class of problem. It also documents the intent: this update is not changing the status, and here is proof it thought about it.
-
Check the trail rather than the record
The serial record is current state and it moves. The trace events beside it are append-only, so when a status looks wrong, the sequence of movements is the thing that tells you what actually happened and when.
The warranty date nobody is chasing
Worth naming while we are here, because it is a genuinely useful field sitting slightly idle. Warranty expiry is recorded per unit on a serial and separately on tracked assets. The asset copy is read — expiring warranties are counted and surfaced on the asset panel — and batch expiry has a daily reminder that goes out at twenty-five to nine every morning.
The serial's own warranty date sits between those two: recorded faithfully, visible when you open the unit, and not yet feeding a reminder of its own. For an organisation holding serialised equipment under warranty, that is the field worth wiring up, and it is a scheduled job of the same shape as the four that already run.
Making a serial's dates work for you
Every field is already stored per unit and the reminder machinery already exists for batches and employee documents. What is missing is the wiring between them.
A warranty reminder per unit
A scheduled sweep of serials whose warranty ends inside a window you set, on the same footing as the batch expiry reminder that already runs daily.
Status preserved on unrelated edits
An update path that carries the current status forward unless it is explicitly changed, so correcting a warranty date cannot revive a damaged unit.
A per-unit history view
Every trace event for one serial in one chronological list, which is the view a warranty claim or a dispute actually needs.
We publish scope, not dates.
Scope serial trackingWhat AWRA OpsHub does today
- A record per physical unit, keyed on your organisation, the item and the serial as written, so a manufacturer's numbering can be used unchanged and the same serial on two items stays two units.
- Per-unit warehouse, location, batch, supplier, purchase order, received date, warranty expiry, status, last movement and originating document.
- An update that writes only what the caller supplied, leaving every field it did not mention exactly as it was.
- Sensible defaults for status and last movement, correct for the receiving flow that is the main caller.
- Append-only trace events that can reference a specific serial, carrying direction, event type, quantity, the source document and line, a reference, the user and the moment.
- Batch allocation recording alongside serial recording, so an issue drawing on several batches is traceable to each.
- A traceability screen listing serials with their item, batch, warehouse and location, on the web and through the interface.
More we can add to your workspace
- A warranty reminder driven by a serial's own expiry date, matching the daily batch expiry reminder that already runs.
- Status preserved through an unrelated edit, so correcting a warranty date leaves a damaged or reserved unit exactly as it was found.
- A single chronological history for one unit, reading every trace event that references it, which is the view a warranty claim needs.
- A serial-level reservation, so a specific unit can be committed to a specific customer before it ships.
- Service history against a unit, recording what was done to it and when, for equipment that is repaired rather than replaced.
- A duplicate check across items, flagging the same serial recorded against two different products where that is genuinely impossible in your catalogue.
Where we point you to a specialist
- We will not invent a serial number for a unit that arrived without one. A serial is the manufacturer's identity for that unit, and a synthetic one would make your records disagree with the plate on the machine and with every warranty document attached to it.
- Where a sector requires unit-level serialisation to a prescribed scheme — pharmaceutical serialisation, medical device identifiers — that scheme governs and your compliance adviser interprets it. We will store, print and report whatever it specifies.
- We will keep the trace events append-only. A movement history that can be edited is a history that answers whatever the last editor wanted it to, and it is the record most likely to be needed precisely when somebody would prefer it said something else.
The warranty reminder is the highest-value contained piece here — the date is already recorded per unit, the scheduling machinery already runs four similar sweeps, and it turns a stored field into money recovered on claims.
Five questions to ask about serial tracking
What identifies a serial?
A good answer sounds like
A named key.
What ours actually is
The organisation, the item and the serial as written — so the same serial on two products is two units.
Does an update wipe fields it does not mention?
A good answer sounds like
No, with any exceptions named.
What ours actually is
No, with two exceptions named: status and last movement carry defaults and are written every time.
Is the warranty date per unit or per product?
A good answer sounds like
Per unit.
What ours actually is
Per unit. Two units of the same product bought a year apart hold different dates.
Can I see everything that happened to one unit?
A good answer sounds like
Yes, as a history.
What ours actually is
The events exist and reference the serial; a single chronological view per unit is the reporting piece named above.
Can the movement history be edited?
A good answer sounds like
No.
What ours actually is
No. Trace events are inserted and never updated.
If you hold equipment under warranty, start with the dates
The fastest return on serial tracking is almost never traceability — it is the claims that get made because somebody knew the unit was still covered. That needs the date recorded and something watching it.
Talk through serial trackingFrequently asked questions
Why is a serial keyed to the item rather than to the whole workspace?
Because serial numbering belongs to the manufacturer, and two manufacturers will happily both ship a unit numbered 000147. Keying on the item means both can be recorded as written. It also means a genuine duplicate — the same serial recorded twice against the same product — is caught, which is the case that actually indicates an error.
What happens if I update a serial without saying what its status is?
It is set to available. That default is correct for the receiving flow this method was written for, where a unit being recorded is by definition available and has just moved. On any other path, the current status should be passed through deliberately — one line, and it removes the possibility of a damaged unit quietly becoming sellable.
Is the warranty date used for anything automatically?
Not yet, at the serial level. Warranty expiry on tracked assets is counted and surfaced on the asset panel, and batch expiry has a daily reminder. The serial's own date is recorded and shown on the unit, and wiring it into a scheduled reminder is the first item on the list above.
Can I reserve a specific unit for a specific customer?
Not at serial level today. Stock can be held and made unavailable at a location, but committing one identified unit to one order is a separate capability. It matters most where units differ materially — a machine with a specific configuration, or a unit already certified for a customer's site.
How do I find out what happened to one unit?
Through the trace events, which reference the serial and record every movement with its direction, quantity, source document, user and time. Today that means reading them alongside the unit rather than in one view; a per-unit chronological history is the reporting piece named above and is the view a warranty claim or a delivery dispute actually needs.
Should we serialise everything?
No. Serial tracking earns its keep where the identity of a specific unit will be needed — warranty, recall, service history, a dispute about which one was delivered. For consumables and commodities it is a data entry cost with no question behind it. The useful test is whether anybody will ever ask "which one", and for most of a catalogue the honest answer is that nobody will.
