A Register That Cannot Be Filled
Our product had a serial-number register for stock: a table, a model, three screens, two routes and a count on the dashboard — and, for most of its life, no code path that could put a row in it. It fills now, one serial per unit at receipt and every unit named on the way out. This is what was wrong, what fixed it, and the test that would have found it sooner.
There is a page in our system that lists the serial numbers of individual units in stock. It has a search, a filter, a link through to each serial's own page, and a count at the top. For most of its life that count read zero, and no action anywhere in the product could change it. Today it fills from receiving, and every unit that leaves is named on the movement that took it.
The register was never a table that had simply not been used yet. It was a table nothing could write to. The model existed, the columns were right, the relationships were wired, and the one method that would create a record was called by nothing.
What is there
The design is not a sketch. A stock serial record can hold the item it belongs to, the batch it came in with, the warehouse and bin it is sitting in, a status, the supplier and the purchase order it arrived on, the date it was received, a warranty expiry date, the date it last moved, a free-text note and a metadata payload. That is a considered model of an individually identified unit, written by somebody who had thought about warranty and traceability.
The reading side is finished too. There is an index of traced items, a per-item page, a per-serial page, a web route and an API route to fetch a single serial, and a serial count rendered as a figure on the traceability dashboard.
The writing side used to be one method on one service that nothing called. It was not wired up so much as replaced by capture on the movements themselves. An item can switch serial tracking on, and from then new stock is received with exactly one serial per unit. Issues, invoice checkouts, till sales, stock transfers, till returns and supplier returns each name the units that leave, and each unit has to be on that shelf. A transfer puts its units in transit and receives them at the far end, and a short delivery records the ones that never arrived as missing. The same capture runs through the API. The mobile app and the stock count are the two places it reaches next.
A count that can only ever be zero is worse than no count. It is a figure, in a dashboard, that a reader will interpret as a measurement.
The lesson this is the second instance of
We have been here before, in procurement, and we wrote it down at the time: an unreachable feature is an unverified feature. The receipt-matching service in that module sat behind a single API endpoint for a long time with no screen, and because nothing rendered its output nobody discovered it was returning a false result on every order in the system. It had never worked. It could not have worked. Nobody could tell.
This was the same shape in a different module, caught earlier and with a milder consequence. The serial register was never wrong, because it never held anything. But the reason it went unexamined was identical: there was a page, so it looked done.
Which is why it was published rather than quietly wired up, and why this page now records the fix instead of disappearing. If you are evaluating us, the useful thing to take from it is the test: ask any vendor to create the record, not to show you the screen.
Why this bites hardest in Korean supply
Because the goods that move through Korean manufacturing and distribution are disproportionately goods where the individual unit matters. Consumer electronics, batteries and cells, automotive components, semiconductors and the equipment around them, medical devices, industrial machinery. In all of those, three questions are routine, and all three are questions about one unit rather than about a quantity.
| The question | Answered by a batch | Answered by a serial |
|---|---|---|
| Is this specific unit still under warranty? | Only if the whole batch shares a date | Yes — a per-unit warranty expiry is exactly what the field is for |
| Which customer received the unit with this number? | No | Yes — a till sale or an invoice checkout names the units that left |
| How wide is a recall? | To the batch, which may be far wider than the defect | To the affected units |
| Which supplier and which order did it arrive on? | Yes — batches carry both | Yes, and per unit |
| Is it expired? | Yes — batch expiry is fully built and alerted | Not the relevant question for durables |
The batch column is not a consolation prize. Batch tracking in our product is genuinely complete: a batch carries a lot number, its supplier, the purchase order, when it was received, when it was manufactured, a quality status, a recall status and its own allocated landed cost, and allocation is always oldest-expiry-first. For consumables, that is the right granularity and the serial question never arises.
For a durable good with a warranty and an owner, it is not. And that is the category this market makes and moves, which is why the serial now travels with the unit rather than sitting in a register beside it.
How to adopt it
Three steps, in the order we would take them
- Switch tracking on per item, starting with the units that carry a warranty. Stock already on the shelf can still leave without a serial, so nothing locks on the day you switch. Every new receipt carries one serial per unit, and once only registered units remain, every movement has to name them.
- Keep batch tracking alongside it. A serial can carry the batch it arrived in, so a recall can start from the lot and narrow to the units, and the batch still carries the supplier, the order, the receipt date and a recall status.
- Register high-value units as assets instead of stock, where they are going to be deployed rather than sold. The asset register has its own serial number, searchable, importable in bulk, with custody and movement. An asset is something you keep; goods for resale belong in stock with tracking on.
What AWRA OpsHub does today
- Batch and lot tracking with the supplier, the purchase order, the received and manufactured dates, a quality status and a recall status on every batch.
- Allocation ordered oldest-expiry-first on every issue path by default, with a per-item stock rotation setting that can switch an item to first-received-first.
- Batch-level trace events with direction, quantity, source document and location, so a batch can be traced one step back and one step forward.
- Batch expiry alerting on a 30/60/90 horizon with value at risk, daily, plus a workflow event per expiring batch.
- A working serial number on the asset register — searchable, bulk-importable, and used in movement and custody.
- Serial tracking for stock, switched on per item: one serial per unit at receipt, and the units named on issues, invoice checkouts, till sales, transfers, till returns and supplier returns, each checked to be on that shelf.
- Transfers that carry serials in transit and receive them at the far end, with the units that did not arrive on a short delivery recorded as missing.
- A trace event for every serial status change, read on the unit's own page, on the web and through the API.
- Serial capture through the API on receipts, issues, checkouts, till sales and transfers.
- Serial entry in the mobile app on receipts and issues, till sales and transfers, checked by the same rules as the web.
More we can add to your workspace
- Scanning a serial with the phone camera, so a unit is named at receiving, issue or transfer without typing it.
- Serial capture during a stock count, so a count confirms which units are on the shelf as well as how many.
- A warranty date captured per unit at receipt, filling the per-unit field the register already holds.
- A recall report scoped to affected serials, listing who received each unit from the trail every movement now writes.
- Bulk import of serials for stock already on the shelf when tracking is switched on.
Where we point you to a specialist
- The serial count on the traceability dashboard reads zero only where no item has tracking switched on. It used to read zero for everyone, and that is what this page was first written about.
- Adoption is gradual on purpose. Units on the shelf before tracking was switched on can leave unnamed, so the register is complete for new stock first and for older stock as it sells through.
- The asset register's serial number is a genuinely different feature that happens to share a word. Both work; they answer different questions.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsOur position
If your traceability requirement stops at the batch — which it does for consumables, food, pharmaceuticals by lot, and most distribution — this product does that work properly and you can leave serials off. If you need to answer a question about one unit, switch serial tracking on for that item: units are captured at receipt and named on every movement out, on the web, in the mobile app and through the API. Where your receiving runs on a scanner rather than a keyboard, tell us, and we will scope camera capture of serials as part of your workspace.
Three questions that find an unreachable feature in any product
Create the record in front of me. Do not show me the list.
A good answer sounds like
They perform the action that produces a row, from the interface a user would use.
What it actually means
This single question would have found the old defect on this page in ninety seconds. A screen is evidence of intent, not of a working path.
Which user action writes this table?
A good answer sounds like
A named screen or step — receiving, counting, dispatch.
What it actually means
If the answer is the API, ask whether anything calls it. Ours is now written by receiving, issue, sale, transfer and return.
Show me a report with real data in it, from a customer account.
A good answer sounds like
A populated screen, redacted if necessary.
What it actually means
Empty demo data hides this class of defect completely, and demo environments are almost always empty in exactly the places that matter.
Tell us what one unit has to answer for
Warranty, recall scope, per-unit custody, or a customer asking which one they got. If serial-level identity is a requirement rather than a preference, describe it and we will come back with a written scope before you commit to anything.
Describe the requirementFrequently asked questions
Could I load serials through the API?
Yes, on the same movements as the web: units received on a check-in, named on an issue or checkout, on a till sale, and dispatched and received on a transfer. The mobile app takes the same serials on receipts, issues, till sales and transfers.
What happens to stock I already hold when I switch tracking on?
It keeps moving. Units on the shelf from before tracking can leave without a serial, while every new receipt carries one per unit. Once only registered units remain for that item, every movement has to name them, so the register becomes complete as older stock sells through.
Is batch tracking a real substitute?
For consumables, yes, and it is the right granularity — you almost never want per-unit identity on a box of gloves. For durables with warranties and owners, a batch is too coarse: it cannot tell you which unit went to which customer, and a recall scoped to a batch is as wide as the batch. That is what serial tracking is for, and the two work together.
What is still to wire up?
Scanning serials with the phone camera, serial capture during a stock count, a warranty date taken per unit at receipt, a recall report scoped to serials, and bulk import of serials for stock already on hand. Each is something we can add to your workspace, scoped against your actual receiving process.
