Software for a pharmacy: the problem is not the till

A pharmacy's till is the least interesting part of its software. A till sells an item at a price; a pharmacy dispenses one lot of one product, and that lot carries a batch number and an expiry date the sale must keep. Everything hard follows from that: the box on the shelf is not one row of stock but several, each with its own date.

Why is one product not one row?

Because the same product arrives on different dates and must leave in a fixed order, fixed by expiry. A row holding one quantity answers how many we have, never how many are still good in three months.

So the row carrying a quantity is the lot: product, batch, expiry, quantity received, supplier, date received. The product becomes a parent grouping its lots. Dispensing takes quantity from one specific lot — normally the earliest expiry on the shelf — and the sale keeps that batch and date attached.

A general stock system fails here quietly. It sells twenty boxes, reduces a single number, and the batch that leaves is whichever box a hand reached for. Nothing breaks that day; it breaks at the near-expiry list.

What is a near-expiry list actually for?

It is a work list for today, not a report for the month. A report says what happened; a list says what to do before closing: return this lot while the supplier's window is open, pull that one forward, destroy or discount a third if policy allows.

Three things separate a list from decoration: a horizon kept as a setting, not retyped into a filter each morning; an action on each line, recorded when taken, so a lot leaves for a stated reason; and a person, because a lot with no owner is a lot nobody returns.

The horizon matters more than the screen: too wide and the list is the whole stock, so nobody reads it.

What happens when the molecule and the brand disagree?

The prescription names a molecule; the shelf holds several brands of it, in different pack sizes. Identifying stock by brand pushes the counter into one of two bad moves: sell what the record calls stock and the shelf does not have, or abandon the sale.

The workable shape is an equivalence group: products sharing molecule, strength and form sit together, and each member keeps its own price, lots and stock. A substitution then becomes a recorded event — this brand was asked for, that one left the shelf — not an invisible swap. Stock moves on the lot actually dispensed, the only one whose expiry means anything.

Keep the group factual. Once it starts encoding therapeutic judgement, the software is making a clinical claim it has no business making.

What does a shift handover have to contain?

Three numbers and a signature: the cash that should be in the drawer, the cash in it, the difference with a reason; the stock moved outside a sale, adjusted line by line; and who closed the shift, with the time.

The expected figure must be derived from the day's movements — sales, refunds, payments on account — not computed by the person counting. If the total is typed in at closing, the difference is always zero.

A difference is normal and should be recordable in one step: an amount, a reason from a short list, the name of whoever accepted it. What must never be possible is editing the opening float until the day balances; that permission turns the handover into arithmetic.

The signature is worth something only if the account behind it is personal. A shared login signs every handover by "the pharmacy"; the OWASP authentication cheat sheet covers why a shared credential cannot carry accountability.

What must the register hold so an inspection is an export?

An inspection names a period and a product, and the answer should be a file, not a morning spent retyping invoices. The register is written as the sale happens, with the fields already in the row: date and time, user, product, lot and expiry, quantity and direction, supplier or prescriber, price.

Two properties make it usable: it is append-only, so a correction is a reversing line and the file still shows what it said before; and it exports to a plain format, because whoever reads it will not have your software.

Which fields are mandatory and how long the register is kept belong to the pharmacist's regulator. Our part is the shape: the field exists, it is filled when the event happens, and the export is one button.

Question	A till records	A pharmacy counter needs
What went out?	A product and a price	A lot, its batch, its expiry
What expires next?	Nothing	A list with an owner
Which brand was sold?	The one on the receipt	The substitution, recorded
Who closed the shift?	A total	Cash, difference, reason, user
What can be shown later?	A receipt roll	An export of the register

What should be settled before you compare products?

Do these in order; each turns the next into a requirement.

1. Count lots, not boxes. List the lots of one fast-moving product with their expiry dates.
2. Fix the near-expiry horizon in months, in writing, and name who works the list.
3. Write down last week's substitutions and check whether stock still balances once they are included.
4. Walk the closing handover: who counts, against what, who accepts a difference.
5. Ask for one period's register and answer an inspector's question from it alone.
6. Test the export and the restore on a clean machine, in a format your accountant accepts.
7. Only then compare products. A package that fails two of those shows it in a demo, not in the fourth month.

Where this goes wrong

• The lot is dropped at the till. The sale records a product, expiry becomes a monthly guess.
• The list is printed and filed. The same lots reappear until they are destroyed at a loss.
• Substitution is a remark. The counter swaps brands and mentions it in passing; stock and register both record the wrong product.
• The drawer is balanced by editing. The float is adjusted until totals agree, and cash losses vanish.
• One login for the whole counter. Every shift is signed by the same account, so the signature proves nothing.
• The register is the invoices folder. Every inspection becomes a day of retyping.

What this does not cover

This is about stock, expiry, substitution and the record around them. It says nothing about which products a pharmacy may hold, how a prescription must be kept, or what a register entry must contain — those rules come from the pharmacist's regulator, and no software opinion substitutes for them. It leaves out purchasing, reimbursement and pricing policy, and assumes one counter and one stockroom.

We build pharmacy systems around the lot — batch and expiry, a near-expiry list someone works, recorded substitutions, a signed handover, and a register that exports.