AWRA OpsHub Search

The Fridge Has a Calendar

The vaccine fridge in a branch pharmacy has a laminated card taped to its door with a hand-written date on it. Our asset register can tell you who holds that fridge, which room it stands in, what condition it was in at the last hand-off and the exact minute somebody last laid eyes on it. Since October it can also hold what is written on the card — and chase it — which is worth understanding before you buy anything.

Pharmacy & Pharmaceutical Distribution Washingtone Aura 12 min read

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 manages the card as well. A maintenance schedule on the asset holds the interval and the next due date, opens a work order ahead of it, and tells the person responsible; the work order records the engineer, what was done, what it cost and how long the machine was out of service. Two things stay outside it — a calibration certificate as a record of its own, and temperature — and this post states both, along with how the two halves fit together. Knowing that 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 question What the register holds How it gets there
Who has this machine? A current custodian on the asset Set by every check-out, transfer and hand-back
Where is it? A current location and warehouse Set by relocation and transfer movements
What state was it in? A condition on the asset, and the condition before and after on each movement Captured at each hand-over, dated and attributed
When did somebody last check? The date of the last verification, and who performed it Written the moment a verification is recorded
Is it out past its return date? An expected return date, compared with today Surfaced in Asset Watch and the asset reports
Is it lost, damaged or retired? A status, plus a retirement date and a reason Set by the corresponding movement

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.

Verification asks a different question from service

A verification says: this machine exists, it is here, this person saw it, and it looked like this. It does not say the machine is working correctly, that it holds temperature, or that a qualified engineer has certified it. Those are separate claims. The first and the third belong to the maintenance side described below; the second belongs to a data logger.

The dates that look forward

The asset itself carries one forward-looking date the product has always watched: the date the warranty expires. 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, and a daily reminder names each one, by email and in the bell, from a lead time you set (thirty days by default).

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 serviced last month is fine. So the date that answers the service question lives somewhere else: on a maintenance schedule attached to the asset.

A schedule says how often — every so many days, weeks, months or years — and whether the next date counts from the calendar or from the last time the work was actually done. It names who does the work, which outside vendor if any, and how many days of warning to give. Every morning the product opens a work order for each schedule coming due, tells the person assigned in their notification bell, and chases any work order still open past its due date.

The repair that leaves a trail

Every 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. Together they are the asset's history, and it is the history, not the current status, that survives an audit.

Maintenance works the same way. A work order that takes the machine out of service writes a movement when the machine goes and another when it comes back, and while it is held out of service the edit form, a transfer or a damage report cannot quietly change its status underneath it.

A fridge goes out for repair on the 4th and comes back on the 19th. Here is the entire record.

4 May — a corrective work order is started and takes the fridge out of service movement row written
4–19 May — the fridge is with the repair vendor work order in progress
19 May — the work order is completed return movement written
What the engineer did, what it cost on the work order
What the history shows on 20 May fifteen days out of service, who did the work, and what it cost

Downtime is derived from the two movements, so how many days a unit was out of service last year is a figure the register can answer.

What the schedule does not do

Two precisions worth having before you buy. The first: the workflow builder's event catalogue still has no asset entry, so an asset date cannot start a custom workflow, and asset reports are not among the ones that can be emailed on a cadence. The maintenance schedule does its own date-watching and its own notifying; it does not go through the workflow engine.

One precision worth having

Assets is listed in the workflow module registry. That is a different list — it names the modules the workflow area knows about for scoping and permissions. The event catalogue, which is what determines whether anything can start a workflow run, has no assets entry. If you need a reminder routed through a workflow rather than the maintenance bell, ask to see an asset event chosen as a trigger.

The second: a calibration certificate is not a record of its own. A calibration can be a schedule and an inspection work order with its resolution written down, but the certificate itself — the issuing laboratory, its reference and its expiry — has no dedicated place, so keep the certificate with the work order's paperwork. An older equipment register for scanners and tills also holds a last- and next-maintenance date that nothing reads; it is mentioned here only so nobody mistakes it for the schedule.

Setting it up for a pharmacy

  1. Give every serviced machine a schedule

    Fridges, freezers, cold boxes, nebulisers — each with its interval, the engineer or vendor who does the work, and enough lead days that the work order lands before the engineer's calendar fills.

  2. Count from the last service where the interval is a gap

    A service due twelve months after the last one should count from completion, so a late service does not shorten the next interval. A statutory date that falls on a calendar day should count from the calendar.

  3. Let the bell do the chasing

    The person assigned is told when a work order opens and again when it is overdue. Make sure every schedule has an assignee who is still at the company.

  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. Use it for the walk-round, and the schedule for the service.

  5. File the calibration certificate with the work order

    Write the certificate reference into the resolution when the inspection is completed, so the record and the paper point at each other.

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, serviced when — which is the question the data logger cannot answer.

What the asset register answers well

  • Which branch holds which machine, right now
  • Who signed for it, and when it changed hands
  • When a person last physically confirmed it exists
  • When this machine is next due for service, and who was told
  • How many days it was out of service last year
  • What was done at the last repair, by whom, and what it cost
  • What it cost, when it was bought, when the warranty lapses

What sits outside it

  • Has it held temperature since the last check
  • Is its calibration certificate current, as a record of its own
  • A service interval counted in hours or cycles rather than days
  • An asset date starting a custom workflow

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.

Ask for these, in this order

  • Show me an asset record with a next-service date on it — a real field, not a note.
  • Now show me the screen that lists everything due in the next thirty days.
  • Who gets told, through what channel, and can I see the message that was sent?
  • Send an asset out for repair and bring it back. Show me the history afterwards, and tell me how many days it was out.
  • Show me the repair itself recorded against the machine: what was done, by whom, what it cost.
  • If the answer to any of these is a custom field, ask what happens on the morning the date arrives.

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, the answer is a work order opened ahead of the date and a notification to the person assigned.

What the asset register does about maintenance, and what we can add

Built and verified in the code

  • Custody, with attribution. Custodian, department, location and warehouse on every asset, changed only through dated movement rows that record who performed the action and, where your settings require it, where they were standing.
  • Verification as a repeatable control. Recording a verification stamps the date and the user, captures condition before and after, and lays down a movement row. Asset reports count verifications in the last thirty days.
  • Staleness flagging. The Asset Watch insight counts every non-retired asset never verified, or last verified more than a hundred and eighty days ago, and factors it into the register's health score.
  • Warranty expiry watched. Warranties expiring within sixty days are counted in Asset Watch, and reminded by name daily, by email and in the bell, on a lead time you set.
  • Overdue returns. Assets still out past the return date they were checked out against are counted and put in front of you, and for individually tracked assets a daily reminder goes to admins and to the custodian.
  • Preventive maintenance schedules on an asset, by days, weeks, months or years, counted from the calendar or from the last completed service, with a next due date, an assignee, a vendor and lead days.
  • Work orders opened automatically ahead of the due date, the assignee notified, and overdue work orders chased.
  • Corrective, preventive and inspection work orders with a resolution, the condition afterwards, and labour, parts and other cost against a repair vendor — on the web, the interface and the mobile app.
  • Out-of-service movements, written when a work order takes a machine out and when it returns it, so downtime is derived from the history.
  • Depreciation on assets, straight line or reducing balance, posted to the ledger by a monthly run.
  • Custom fields on assets, which store, list, report, export, import, and appear in the API and the mobile app.

More we can add — each one verified against the code

  • A calibration certificate as a record of its own — the issuing laboratory, its reference and its expiry — rather than a line in a work order's resolution.
  • An asset entry in the workflow event catalogue, so an asset date can start a custom workflow, and asset reports on a scheduled email.
  • Service intervals counted in hours or cycles from a meter reading, beside the calendar ones.
  • Temperature: readings, an excursion log, thresholds and a data-logger integration.

Where the line falls

  • If your problem is knowing which branch has which machine and who is answerable for it, this is a strong fit today.
  • If your problem is a preventive-maintenance calendar with reminders and a service history, the schedules and work orders cover it; a calibration laboratory’s certificate register stays with whatever already holds it.
  • If your problem is temperature evidence for an inspector, you need a data logger regardless of what any inventory product tells you.

A calibration certificate record on the asset, or an asset event in the workflow catalogue, is a well-shaped piece of work on top of schedules that already run. If it is a requirement, raise it as one and we will scope it honestly.

Verified against the repository, maintenance schedules and work orders included. Every item above was checked by searching for it, rather than by failing to remember it.

More we can add to your workspace

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 needs

The card on the fridge door does a job. The schedule does that job — and it sits on a register that already knows 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.

Bring us the requirement, not the wish list

If you are evaluating for a pharmacy or a clinic group, send the actual equipment list and the actual inspection requirement. We will tell you which parts the register and the schedules cover today, which parts need a second system, and which parts are worth building — and we will put it in writing before you commit to anything.

Talk to us about a pharmacy deployment

Share this article

LinkedIn X WhatsApp

Keep reading

All blogs

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center