The Serial That Went Back to Available
A serial number is one physical unit with its own location, batch, received date and status, and columns still waiting for its warranty date and its supplier. 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, when it was received, what state it is in, when it last moved, and which document brought it in. Who supplied it and under which order are read from that receipt, which was taken against the supplier's order, rather than stamped on the unit itself. It also has a column for when its warranty runs out, which nothing in the stock flow fills yet.
| 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. Reached through the receipt that brought the unit in; the unit has columns for both, which the receiving flow leaves to the receipt rather than copying across. |
| Received date | When it arrived, as distinct from when it was made. |
| Warranty expiry | Per unit, not per item, so two units bought a year apart can hold different dates. A column on the record today that no receipt fills; capturing it is on the list below. |
| 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 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.
It is also how the movement paths were built when serials started travelling with stock. Receipts, issues, invoice checkouts, till sales, transfers, till returns and supplier returns each name the units that move and state the status they leave them in — sold, issued, in transit, returned to supplier, missing from a short delivery, or available again on arrival or restock. None of them leans on the default.
-
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 has a column per unit on a serial and a field on tracked assets. The asset copy is filled and read — expiring warranties are counted on the asset panel and reminded by email and in the bell daily — 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: a column on the unit that no receipt fills yet, and nothing watching it. For an organisation holding serialised equipment under warranty, that is the field worth wiring up — captured at receipt, then swept by a scheduled job of the same shape as the ones that already run, the asset warranty reminder among them.
Making a serial's dates work for you
Every field has a column per unit and the reminder machinery already exists for batches, employee documents and asset warranties. What is missing is filling the warranty date and the wiring between them.
A warranty date and reminder per unit
The warranty date captured on each unit at receipt, then 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.
Service history against a unit
What was done to one machine and when, beside the movements it already has, for equipment that is repaired rather than replaced.
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, received date, status, last movement and originating document, with the supplier and purchase order one step away on the receipt that document is.
- 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.
- Serial numbers on every stock movement for items with tracking switched on: one serial per unit received, and the units named on issues, invoice checkouts, till sales, transfers in transit and on arrival, till returns that restock and supplier returns, each checked to be on that shelf. Each status is set explicitly by the movement, not by a default.
- A history page for one unit, listing every trace event that references it, newest first, on the web and through the interface.
More we can add to your workspace
- The supplier and purchase order stamped on each unit at receipt, so a warranty claim or a recall can filter serials by supplier directly instead of going through the receipts.
- A warranty date captured on each serial at receipt, and a reminder driven by it, 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 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 date and its reminder are the highest-value contained piece here — the column already exists per unit, the scheduling machinery already runs several 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 by design — the column sits on the unit — and filling it at receipt is work we can add. Ask any vendor whether theirs is filled or only defined.
Can I see everything that happened to one unit?
A good answer sounds like
Yes, as a history.
What ours actually is
Yes. Every movement writes an event against the serial, and the unit's page lists them in order.
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 has a daily reminder, by email and in the bell, as does batch expiry. The serial has its own column for the date, which nothing in the stock flow fills yet; capturing it at receipt 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?
Reservations today are quantities per warehouse: a confirmed sales order holds five of an item at a branch, and a manual hold does the same. Committing one identified unit to one order is a separate capability we can add. 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?
Open the unit. Its page lists the trace events that reference it, each with its direction, quantity, source document, user and time, and every movement since serials were captured on issues, sales, transfers and returns writes one. That is the view a warranty claim or a delivery dispute 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.
