Pharma Enterprise

The challenge

A medicine name is not enough to sell. The same product can sit in several batches, with different expiry dates, prices, and quantities. The counter has to pick a sellable lot, show the cashier what is wrong, and still move quickly when the next person is waiting.

Around that sale, the pharmacy holds bills, takes more than one payment method, returns stock, records purchases, and keeps doctors, patients, suppliers, and staff on different permissions. A receptionist should not land in the same workspace as an owner.

The solution

After sign-in, the home screen is a module grid filtered by the permissions on the account. A doctor-only account lands in a doctor home instead. Billing is a keyboard-oriented till: search or scan, cart, batch change, prescription load, split payment, hold, and returns.

Inventory covers the medicine master, purchase entry, stock, adjustments, and thinner tools for barcodes, transfers, counts, and expiry. Clinical screens cover doctors, prescriptions, and patients. Administration covers suppliers, users, and editable role permissions. The API validates the write, checks the permission, and stores the invoice and the stock movement.

• Point of sale with batch lookup, quantity caps, and a cart merged by batch.
• Prescription lookup that fills the customer and attempts to add the remaining medicines.
• Held invoices that can be resumed from the counter or from a link.
• Split payments, with credit offered only for owner and admin roles.
• Returns, invoice history, customers, and billing summaries loaded from the API.
• Purchase entry, stock lists, and confirmed stock adjustments.
• Patient, doctor, supplier, and user administration, including a role permission editor.

System architecture

The client is a React single-page app on Vite. Redux holds two things: the auth slice, and an RTK Query API slice. Feature screens keep their own workflow state. The point-of-sale cart lives in the billing page, not in the global store, so a refresh does not pretend an unsaved cart is still there. A held invoice is how that work survives.

One API module declares the endpoints and the cache tags. A 401 on a normal request refreshes the session and retries once. Login clears the previous cache before the new session is stored, so one cashier does not see the previous cashier's queries. Child pages can inject actions into the shared header.

A small shared package exports the role and permission keys used by the React app and by Express. Route guards wait until the user exists, and they prefer the permission list returned by the server. The API checks those keys again on the write. Feature folders group billing, inventory, and the clinical screens. Server modules follow route, controller, service, model, and validation files.

Key engineering decisions

Core capabilities

Technology stack

Engineering impact

Billing, stock, and clinical work sit in one client with a boundary the API can enforce. New operational screens reuse the list shell, the header slot, toasts, and outlined fields instead of a new visual language each time.

The cashier's keyboard path, the batch picker, and the hold flow are one product. That is what makes a dense counter usable: the next action is on the same bill.

Permission changes propagate through cached user data, so the menu is not a hard-coded list of job titles.

Money shown while editing is treated as a preview. The invoice the API stores is the one later screens and returns use.

Workflows and modules

These drawings describe the counter and the modules around it. They are not captures of a live pharmacy system.

Engineering takeaways

1. I treat a counter as a state machine: scan, batch, hold, and pay have to know about each other.
2. I want the permission word in the menu to be the same word the API checks.
3. I keep stock identity on the batch, because a product name hides expiry and quantity.