A Register That Cannot Be Filled
Our product has a serial-number register for stock: a table, a model, a service method, three screens, two routes and a count on the dashboard. It also has no code path anywhere that creates a row in it. The screens work perfectly and will always be empty.
There is a page in our system that lists the serial numbers of individual units in stock. You can open it. It has a search, a filter, a link through to each serial's own page, and a count at the top. The count is zero, and no action available to you anywhere in the product will ever change that.
This is not a table that has not been used yet. It is a table nothing can write to. The model exists, the columns are right, the relationships are wired, and the one method that would create a record is 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 is one method on one service, and nothing in the application calls it. Not the receiving path, not the counting path, not the bulk importer, not the API, not the mobile client. Searching the entire codebase for the method's name returns exactly one result: its own definition.
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 is the same shape in a different module, caught earlier and with a milder consequence. The serial register has never been wrong, because it has never held anything. But the reason it has never been examined is identical: there was a page, so it looked done.
Which is why it is being published rather than quietly wired up. If you are evaluating us, the useful thing you can take from this page is not the gap. 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, if the outbound movement is recorded against it |
| 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.
What to do in the meantime
Three workarounds, in descending order of how much we like them
- Use one batch per serial where the volume is low and the value is high. A batch already carries the supplier, the order, the receipt date and a recall status, so a batch of one is a serial record with a different name. This is genuinely workable for machinery and instruments; it is absurd for ten thousand handsets.
- Register high-value units as assets instead of stock, where they are going to be deployed rather than sold. The asset register does have a working serial number, it is searchable, it imports in bulk, and it tracks custody and movement. The boundary is that an asset is something you keep, so this does not help with goods for resale.
- Keep the serial ledger outside the system and reconcile on receipt and dispatch. Unsatisfying, honest, and what most operations in this position actually do. Put the discipline in the receiving process, not in the spreadsheet.
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, unconditionally — there is no per-item switch that can turn it off.
- 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.
What it does not do
- Any way to create a stock serial-number record. The model, the columns, the relationships, three screens and two routes exist; the single write method is called by nothing in the product.
- Per-unit warranty tracking on stock. The field is on the unreachable record.
- Serial capture at receipt, at counting, at dispatch or on the mobile client.
- Recall scoping narrower than the batch. A recall traces to everyone who received any of the batch.
Not ours, by choice
- The serial count on the traceability dashboard reads zero and always will until this is wired. We would rather say that here than have you find it in a demo.
- Batch-of-one is a real workaround with a real ceiling. It is fine at hundreds of units a year and unusable at thousands a month.
- The asset register's serial number is a genuinely different feature that happens to share a word. Do not read the working one as evidence for the other.
What is not built today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — 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 the gap you just read about. Two honest qualifications so this is worth what it claims: a handful of gaps on this blog are deliberate refusals rather than missing work — 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 rather than calling it a gap. 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 gaps, which are the ones this blog admits 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 the absence described here will never touch you. If you need to answer a question about one unit, treat serial tracking as absent, not as present-but-empty, and either use batch-of-one within its limits or tell us the requirement so it can be scoped as a build.
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 gap 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 has an API too.
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?
No. The API exposes reads — a list and a single serial — and no create endpoint. The only write method is an internal service call with no caller, and it is not routed.
Does the empty serial register break anything?
No. Nothing depends on it, no report joins to it, and stock, batches, valuation and movement history are entirely unaffected. The consequence is a page and a count that can only show zero, which is a truthfulness problem rather than an operational one.
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, no: a batch cannot tell you which unit went to which customer, and a recall scoped to a batch is as wide as the batch.
How long would it take to wire up?
The model, the columns and the read screens exist, so the work is capture — deciding where a serial is entered at receipt, how it is carried on a dispatch, and what happens when a scan finds one that is already allocated. That is design work before it is engineering work, and we would scope it against your actual receiving process rather than guess.
