UNITYZM Showing Sign in

Sector

Pharmacy

A retail pharmacy has to keep four things straight at once: what is on the shelf and when it expires, what was dispensed and by whom, what the controlled register says, and which scheme still owes you money. Most run each of the four in a different book.

Sold as

Per branch, per seat

Compliance scope

Keeps the records; certifies nothing

Footprint

Light

Default posture

Internal

What it is

One counter, four books, one ledger.

A pharmacy is not short of records. It is short of records that agree with each other. Stock is counted on a sheet, the register lives in a hardback book behind the counter, claims go out in a batch someone assembles by hand at month end, and the till knows about none of it. Each is correct on its own terms. The gap between them is where the money goes.

Put them on one ledger and the questions change. Not "how much stock do we have" but which batch, in which branch, expiring when. Not "did we claim for that" but which claims are still unpaid, and how far short the last remittance came in. The expiry a pharmacy writes off at the end of the quarter was visible ninety days earlier; the short-paid claim was visible the week the remittance landed. Neither is a hard problem to see. Both are hard to see in four separate books.

It runs on the same platform as everything else UnityZM deploys, which is the reason it can be stood up in days rather than quarters. A pharmacy is the Operations edition for the dispensary and the Commerce edition for the counter, in one deployment. The domains are already there; what changes is which of them are turned on.

Who buys it. Independent pharmacies and small chains — typically two to ten branches — that already know roughly where their losses are and cannot prove it line by line.

What it turns on

What the cockpit does, and what it does not.

Every domain is present in the platform. A deployment decides which are rendered as operator tools, which face the public, and which are not there at all. The second column matters as much as the first.

In the cockpit

  • Formulary, branches and suppliers
  • Goods received, by batch and expiry
  • Stock on hand per branch and batch
  • Expiry and recall exposure
  • Branch transfers
  • Prescriptions and dispensing log
  • Controlled register with running balances
  • Scheme members, claims and remittances
  • Till, sales and returns
  • Role-scoped access, per person

Not in this build

  • Enforced prescription workflow
  • Enforced controlled-drug locking
  • Automated claim submission to schemes
  • Clinical decision support
  • Electronic prescribing links
  • Regulatory certification of any kind

The feature list

Every screen, in the order the sidebar shows them.

Twenty-five screens across eight groups. Each is filterable and searchable, each can be exported, and access is set per person — so this is the full list, not the highlights.

Overview

  • Dashboard
  • Process

Dispensing

  • Prescriptions
  • Dispensing log
  • Controlled register

Retail

  • Till & sales
  • Returns

Stock

  • Goods received
  • Stock on hand
  • Expiry & recalls
  • Branch transfers

Insurance

  • Scheme members
  • Claims
  • Remittances

Data

  • Data entry
  • Documents
  • Statistics
  • Reports

Setup

  • Formulary
  • Branches
  • Suppliers
  • Insurance schemes

People

  • Users
  • Calendar

Across all of them. Search and per-column filters on every table; add, edit and delete in place; ten roles with their own screen lists; a process map showing who owns each of the twelve stages and what it must leave behind; multi-branch throughout, with transfers between branches; and your own address, branding and sign-in.

How it works

Four records in. One ledger. Questions you could not ask before.

Nothing here is new information — a pharmacy already writes all of it down. What changes is that it is written once, in a place where the four records can be compared.

What a pharmacy keeps today Stock sheet counted by product, not by batch The register a hardback book, written up after Claims batch assembled by hand at month end The till knows takings, nothing else One ledger the same movement, written once — by batch, by branch, by person What you can then ask Which batch expires first? and in which branch Which claims are unpaid? and how far short Who signed for that? every entry, chained Roles decide who sees which of these. A cashier sees the till; a pharmacist signs the register.

How it lands

Days, not quarters — because nothing is being built.

A pharmacy deployment is configuration, not a project. The cockpit, the roles and the screens already exist; what is specific to one pharmacy is its formulary, its branches, its suppliers, its schemes and its people. Those arrive as data.

Scope. Branches, roles, and which of the four books hurt most.

Stand up. The cockpit on its own address, branded, with roles set per person.

Load. Formulary, opening stock with batch numbers and expiry dates, suppliers, schemes.

Walk it. A pharmacist, a cashier and a stock controller each work a real day on it before anyone signs anything.

Go. Counter and dispensary live; claims follow once one scheme cycle has run through end to end.

The honest constraint: opening stock has to be counted by someone, once, with batch numbers and expiry dates. No system can infer what is on a shelf it has never seen. That count is the real work of the first week — and it is work a pharmacy owes itself regardless.

Read it in full

Two documents, both readable here.

Nothing to request and nothing to be emailed. Each opens formatted in the browser and prints to PDF from the same page, so the copy you save is the copy that is current.

The editions behind it