The Fridge Has No Calendar

Every pharmacy that stores anything cold has the same two records, and they live about a metre apart. One is the fridge itself — a serial number, a purchase invoice somewhere in a file, a plug in a wall. The other is a laminated card taped to the door, with a service engineer's phone number and a date in biro. The card is the calendar. The fridge is the asset. Software that manages one of those and quietly implies it manages the other is the single most common way a cold-chain requirement gets mis-bought.

Our asset register manages the fridge. It manages it properly: who has it, where it is, what state it was in when it changed hands, when it was last physically verified and by whom, with the location and the person's name attached to a dated row that cannot be quietly edited away. For a pharmacy chain that has lost track of which branch has which nebuliser, that is the whole problem solved.

It does not manage the card. There is no service interval on an asset, no next-service date, no calibration date, and nothing anywhere in the product that watches a date approach and tells somebody. That is a real boundary, it is easy to state, and this post states it — along with the more interesting fact underneath it, which is that the machinery for watching a date arrive is built and running in this product. It is simply not connected to assets. Knowing that changes what the gap costs you to work around, and it changes what you should ask for.

What the register is actually for

An asset register answers custody questions. Every one of them is in the past or the present tense, and the register answers all of them from something it stored at the time rather than by inference.

The verification action is the one worth dwelling on, because it is the closest thing the register has to a recurring discipline. Recording a verification stamps the moment it happened and the user who did it, optionally captures GPS coordinates if your settings require them for verification, and lays down a dated movement row alongside the ones for transfers and hand-backs. The asset reports count how many assets were verified in the last thirty days. The insights widget flags any asset whose last verification is older than a hundred and eighty days, or which has never been verified at all.

That is a genuine control. If you want a monthly walk-round where a pharmacy technician scans every fridge, freezer, cold box and thermometer in the branch and the system holds a dated, attributed record of the walk, that works today and it works well.

The one date that looks forward, and what it is about

There is exactly one forward-looking date on an asset, and the product does watch it: the date the warranty expires. It is a field on the asset form, it shows on the asset detail screen, and the Asset Watch insight counts every non-retired asset whose warranty expires within the next sixty days and puts that number in front of you.

So the register is not blind to the future. It looks forward once, sixty days out, about one thing. And that one thing is a commercial fact, not a clinical one.

A warranty date tells you who pays for the repair. It does not tell you the machine needs one.

This distinction matters more in a pharmacy than almost anywhere else. A fridge under warranty that has not been serviced in two years is a compliance problem and a stock-loss risk. A fridge out of warranty that was calibrated last month is fine. The date the product watches is the one that answers neither question. It is a useful date — knowing your warranties are lapsing is worth something — but if you read the sixty-day warning as a maintenance prompt, you will be reading it wrong.

The status that leaves no trail

An asset can be marked as being in maintenance. Asset::STATUS_MAINTENANCE is a real status, it is one of the values an asset can hold, and the insights widget counts how many of your assets are sitting in it right now. So far so reasonable.

Here is the part to understand. Every other significant thing that happens to an asset happens through a movement — a dated, attributed row that says what action occurred, who performed it, what changed, and optionally where they were standing. Check-out, check-in, transfer, relocation, verification, marked-lost, marked-damaged, retirement. Each writes a row. Together they are the asset's history, and it is the history, not the current status, that survives an audit.

Maintenance does not work that way. Two movement actions for it are declared in the code — one for sending an asset out to maintenance, one for it returning — and nothing in the application writes either of them. There is no service, no controller and no job that records them. The only way to put an asset into the maintenance status is to edit the asset, and editing an asset records no movement.

This is stated plainly in the code itself. The model that defines those two actions carries a note explaining that they are deliberately excluded from the list of actions the movement filter offers, precisely because offering them would give a user three filter choices that could only ever return an empty table. Somebody already found that trap and closed it. The underlying gap is still the gap.

The calendar machinery exists. It is not wired to assets.

This is the finding that makes the post worth writing rather than a one-line disclaimer. The product has a workflow engine, and that engine has a category of trigger that fires not when a record changes but when a date arrives. Internally these are called relative-date events. Six of them exist.

A batch of amoxicillin can raise a workflow because its expiry date is approaching. That is the exact mechanism a calibration reminder would need. It exists, it is configured through the workflow builder, it routes to people and notifications like any other workflow.

The event catalogue that the workflow builder reads contains twelve modules and thirty-eight events. Assets is not one of the twelve. There is no asset event of any kind — not created, not updated, not a date arriving. So there is no asset workflow to build, and consequently nowhere to hang a service reminder even though the mechanism for one is running a few tables away.

A maintenance date that exists where nothing reads it

There is one more thing a thorough evaluator would find, and it is better that you hear it here than discover it while reading our database and draw the wrong conclusion.

A second, older equipment register exists alongside the main one — built for scanners, tills, tablets and printers. It holds two dates the main asset register does not: when an item was last maintained, and when it is next due. At some point somebody intended maintenance scheduling and built the storage for it.

Nothing refers to it. No screen renders it, no report reads it, no route reaches it, and nothing fills it. The only next-maintenance date anywhere in the product sits in a store no part of the application touches. It does not power a feature, it will not appear in your data, and it should not appear in anybody's answer to a maintenance question. It is recorded here so that the ledger below is complete.

What you can actually do inside the product

The workaround people reach for is a custom field, and it half works. Assets are a custom-fields module, so you can define a "Next calibration due" date field and it will behave like a first-class field: it appears on the asset form, it comes back through the API, it is visible in the mobile app, it can be filtered and shown in asset reports, it exports, and it imports. If you have three hundred pieces of equipment and a spreadsheet of due dates, you can get those dates into the register in an afternoon.

What the field cannot do is tell you the date has arrived. Custom field values raise an event when the value changes — somebody edits it, and the system knows. A date arriving is not a change. Nothing in the database moves on the morning a calibration falls due. There is nothing to notice, so nothing is noticed.

The second workaround is a scheduled report — build a filtered view of assets due for service and have it emailed every Monday. Scheduled report delivery is built and it runs hourly, and eighteen report modules can be scheduled: items, adjustments, customers, invoices, procurement requests, RFQs, quotations, purchase orders, inventory levels, stock movement, item activity, low stock, the three location reports, POS sales, cash drawers and the POS sales summary. Assets is not among them. An asset report cannot currently be put on a cadence.

1. Put the date in the register anyway

   A "Next service due" or "Next calibration due" date field on the asset, filled for every piece of equipment that has an interval. It costs one afternoon and it means the date lives next to the machine rather than in somebody's drawer.

2. Accept that the register will not chase it

   Nothing will notify anyone. Plan on the assumption that the field is a record, not a reminder, and do not let anyone on your team believe otherwise.

3. Keep the chasing where it already works

   A shared calendar with recurring entries, or whatever your engineer already sends. This is the part the register does not replace, and pretending otherwise is how a date gets missed.

4. Use verification as the physical control

   A monthly or quarterly verification round is fully supported, dated, attributed and GPS-stampable, and the hundred-and-eighty-day staleness flag will surface anything nobody has looked at. That is a real discipline the register enforces — use it for the walk-round, not for the service calendar.

5. Ask us before you assume it is coming

   A service schedule on assets is a well-shaped piece of work: a date field, an event in the catalogue, and the relative-date trigger that already exists. It is commissionable. It is not shipped, and a roadmap is not a feature.

The cold chain specifically

One more boundary, because pharmacy buyers ask about it and it deserves a direct answer rather than a careful one. There is no temperature anywhere in this product. No reading, no log, no excursion record, no minimum and maximum, no alarm threshold, no integration with a data logger. Searching the entire application for temperature returns nothing but the sampling settings on the AI features.

So the register cannot tell you that a fridge held two to eight degrees overnight, cannot tell you it did not, and cannot hold the evidence either way. If your requirement is continuous temperature monitoring with an audit trail, that is a data-logger product and you should buy one. What the register can do alongside it is tell you which fridge, in which branch, in whose care, verified when — which is the question the data logger cannot answer.

How to test this in ninety seconds

This applies to us and to everyone else you are looking at. Maintenance scheduling is one of the easiest capabilities to imply and one of the easiest to check, and the check is the same regardless of whose demo you are sitting in.

That last one is the load-bearing question, and it is the one that separates a register from a maintenance system. Storing a date is trivial and every product does it. Noticing that a stored date has arrived, deciding who cares, and telling them — that is the feature. When you ask it of us today, the answer is that nothing happens, and the reason is now fully written down above.

The card on the fridge door is doing a job. Until the product does that job, the card stays — and the useful thing we can offer is a register that knows exactly which fridge the card belongs to, which branch it is in, who is responsible for it, and when a human being last stood in front of it. That is not the whole cold chain. It is the part that is usually missing, and it is worth having on its own terms.