A point of sale and stock system built for a pharmacy

The context

A neighbourhood pharmacy is two shops sharing a counter. On one side are medicines, which carry batch numbers, expiry dates and a pack structure where the sellable unit is often a strip of ten rather than the box of twenty strips that was bought. On the other side is everything else the shop stocks, soap and shampoo and washing powder, which behaves like ordinary retail.

Off-the-shelf point of sale software is written for the second half. It handles a barcode, a quantity and a price. Ask it to sell six tablets off a fourteen-tablet strip, or to warn you that something expires in three weeks, and it either cannot or wants a workaround the person at the counter will not keep up with.

What I was solving

1. 01A medicine is bought by the box, stocked by the strip and often sold by the tablet, so one product needs more than one sellable unit and a price for each.
2. 02Expiry is not a detail. Stock that passes its date is a write-off, and nobody notices until a customer is handed the wrong thing.
3. 03Money in the till is not profit. Without cost of goods against every line, a busy day and a good day look identical.
4. 04Medicines and general items live in one shop but need different handling, different categories and different reporting.
5. 05The counter runs on speed. Anything that needs a mouse hunt at the till gets abandoned within a week.

How I built it

1. 01Made the unit part of the product rather than a setting. A medicine carries its pack structure, so the counter picks Strip or a single unit on the cart line and the price follows automatically.
2. 02Put expiry and reorder level on the product record, then surfaced both as filters and as alerts on the dashboard rather than burying them in a report nobody opens.
3. 03Stored the cost each item carried on the day it sold, so re-pricing stock later cannot rewrite last month’s profit.
4. 04Excluded sales tax from revenue and profit, and kept purchased stock off the expense line until it actually sells, which is what separates a profit and loss statement from a cash summary.
5. 05Split the catalogue into medicine and general store with their own SKU series, categories and filters, while keeping one till and one set of books.
6. 06Built the till around the keyboard: search on F2, complete the sale on F9, tendered amount in and change out without leaving the screen.

The system

01 / 06

02 / 06

03 / 06

04 / 06

05 / 06

06 / 06

MedicalOS running on demo data for a medical and general store, from the dashboard through to the printed invoice. The figures shown are sample data, not a real shop’s books.

Two print formats, one sale

A sale produces either an 80mm thermal slip at the counter or a full A4 invoice for a customer who needs one for an employer or an insurer. Both come off the same record, and both print black on white regardless of the dark interface, because a receipt printer has no idea what a theme is.

The same care went into the profit and loss statement. It opens with sales invoiced, subtracts customer returns to reach net revenue, takes off cost of goods to give gross profit, then lists operating expenses individually before arriving at net profit, with both margins shown as percentages. It is the statement an accountant would expect, generated from the till rather than typed up afterwards.

Why build rather than buy

Generic retail software would have covered perhaps eighty percent of this shop, and the missing twenty percent is the part that matters: the strip, the expiry date and the true margin. That is usually where building your own stops being an indulgence and starts being the cheaper answer.

The figures in the screenshots are demo data for a sample store, not a real shop’s books. What they demonstrate is the shape of the system, not a claimed result.