Issued, Not Sold
A shop sells and a store issues, and the difference is not vocabulary. It decides which movements the replenishment maths can see, who has to sign, and whether "which ward used it" is a question your records can answer at all.
Two facilities, both losing money on consumables, both convinced their inventory system is failing them. One is a pharmacy counter selling to walk-in patients. The other is a central store issuing to eight wards.
They have opposite problems, and the reason is a distinction most people never have cause to think about: a sale and an issue are different kinds of movement, and inventory systems treat them differently — sometimes very differently — in ways that decide what your reorder points and your consumption reports are actually measuring.
For a hospital store this is unusually good news, and it is worth understanding why before assuming your numbers need fixing.
A sale and an issue are not the same movement
Both reduce stock. Almost everything else about them differs, and the differences are the reason they are recorded separately.
A sale
- Exchanges stock for money, at a price, with tax.
- Completes in seconds at a counter, in front of somebody waiting.
- Has a customer, who may be anonymous.
- Is final at the moment it happens.
- Is measured in revenue and margin.
An issue
- Moves stock from a store to a consuming part of the organization.
- Has a requester, an approver, and a reason.
- Goes somewhere specific — a ward, a theatre, a project.
- Can require a signature before it happens.
- Is measured in consumption and cost.
The third and fourth rows are where the operational difference lives. A sale cannot wait for an approval, so it does not have one. An issue frequently should, and can.
A sale cannot wait for an approval, so it does not have one. An issue often should — and that is the whole reason the two are recorded differently.
Why the store's numbers work
The nightly reorder-point calculation measures usage from stock issued through check-outs, once the resulting adjustment has been posted. For a hospital store, that is exactly and only how stock leaves.
So the machinery works out of the box in a way it does not for a shop. Consumption is measured from real movements, the average is real, and the reorder point that results is a real number rather than a placeholder.
It is worth knowing the inverse case, because facilities frequently contain both. A pharmacy counter selling to walk-in patients records sales rather than issues, and sales are not in the usage signal — so a counter-only item computes a reorder point from safety stock alone. The same building can therefore have a central store whose alerts are accurate and a retail counter whose alerts are silent, for reasons that have nothing to do with how well either is run.
If your facility has both, configure them differently
For items that leave through the store, set lead time and let the calculation do its work — measured usage is real and the multiplication is meaningful. For items that leave through a counter, set safety stock deliberately, because measured usage will be zero and safety stock is the only term that survives. It is the same field on the same screen, used for two different reasons, and getting it wrong in either direction is invisible until something runs out.
The counter side of this argument is set out in the till sells, the reorder point does not hear it.
What an issue records
An issue is a header with lines beneath it, and the split matters for what you can report on later.
| Level | What it carries |
|---|---|
| The issue | Reference number, warehouse, location, project, reason, notes, who requested and who approved |
| Each line | Item, batch, source location, quantity, unit cost |
| The signatures | Submitted by, approved by, adjusted by — three distinct roles |
| The accounting | The debit and credit accounts the movement posts against |
The batch on the line is what makes a recall traceable, and the unit cost is what makes a consumption report a cost report rather than a count. Both are captured at the moment of issue rather than looked up afterwards, which is why they remain correct when the price changes next month.
The ward dimension, which you have to choose
Here is the part that needs deciding at setup rather than discovering at reporting time. There is no department field on an issue. If you want to answer "how much did theatre consume this quarter", you have to carry that dimension in a field that exists.
There are three workable choices and they behave differently, so it is worth picking on purpose rather than letting each storekeeper improvise.
-
By location
Model each ward or department as a location and issue to it. Cleanest for reporting, gives you stock-on-hand per ward as a bonus, and it is the most work up front because somebody has to maintain the ward's own holdings.
-
By project
Use the project field on the issue. Good where consumption maps to something fundable — a programme, a campaign, a grant, a theatre list — and it travels into cost reporting naturally. Less good if your wards are permanent and your projects are not.
-
By custom field
Add a department field to the issue. Simplest to set up, keeps a clean dimension without pretending a ward is a warehouse, and it is a label rather than a stock location — so it reports well and holds no balance.
-
By nothing, which is the default
A reason and a note. Works day to day, produces no aggregate at all, and is how most facilities discover the problem — at the end of a quarter, when the question is asked and the answer has to be assembled by reading notes.
Whichever you pick, pick it before go-live and write it down. This is the single most common thing to get wrong in a store implementation, because it costs nothing to defer and cannot be fixed retrospectively — the dimension either was recorded at the time or it was not.
What AWRA OpsHub does today
- Issues feed the replenishment calculation directly, so a store's reorder points are computed from real measured consumption.
- Batch and unit cost are captured per line at the moment of issue, so traceability and cost reporting both survive later price changes.
- Three distinct roles are recorded — who submitted, who approved, who posted — rather than one actor for the whole movement.
- An issue above a configured value is refused until somebody holding the high-value approval permission signs it, and self-approval can be blocked separately.
- Each issue carries its accounting accounts, so consumption reaches the ledger as a posting rather than as a report somebody transcribes.
What it does not do
- No department dimension on an issue. Ward, unit or department has to be carried by location, project or a custom field. Choose before go-live, because a dimension not recorded at the time cannot be reconstructed later.
- No requisition-to-issue chain from the ward. A ward asking for supplies is a request in whatever form your facility uses; the issue is recorded in the store. The two are not linked as a single document with a status.
- Consumption is not compared against activity. The system reports what a ward consumed, not what it consumed per patient, per bed-day or per procedure. That ratio is the useful number and it needs a denominator this system does not hold.
Not ours, by choice
- We will not treat an issue as a sale to make a consumption report look like a revenue report. They are different movements with different meanings, and blending them produces a figure that reconciles to nothing.
- We will not hold patient or clinical activity data to compute a per-patient consumption ratio. That denominator belongs to your clinical system, and the honest answer is an export that joins the two rather than a duplicate record we would be poorly placed to protect.
A first-class department dimension on issues, and a requisition document linking a ward's request to the store's issue with a status, are both scope rather than ceilings. The adjustment model, the approval chain, the custom-field system and the reporting datasets all exist and work.
The per-patient ratio is worth naming as the goal even though the system does not produce it. Consumption per ward is a number that goes up when activity goes up, which makes it nearly useless for spotting waste. Consumption per bed-day or per procedure is the number that finds it, and getting there means exporting consumption and joining it to activity from wherever that lives.
Who signs, and for what
Issuing is where most consumable loss occurs in a facility, and not usually through theft — through issuing generously, issuing without a record, and issuing to whoever asks most persistently.
The value threshold is the control that has teeth here. Above a figure you set, an issue is refused until somebody with the appropriate permission signs it, and self-approval can be blocked so the person raising it cannot be the person authorising it. That is a genuine refusal rather than a notification, which distinguishes it from most of what gets described as an approval workflow.
Deciding the threshold
- Set it where a normal week produces a handful of approvals, not dozens. A threshold that fires constantly is clicked through, which is worse than no threshold.
- Set it in value rather than in quantity — a box of gloves and a box of implants are not the same event.
- Block self-approval unless you have a genuinely single-person store, in which case decide who the second person is and where they are at four in the afternoon.
- Decide the emergency path deliberately. There will be a night when a theatre needs something and the approver is unreachable, and the answer should be written down rather than invented.
- Review the approvals monthly rather than only the issues. A run of approvals for the same item by the same person is a pattern worth understanding.
The fourth item is the one that gets skipped, and it is the one that determines whether the control survives. A threshold with no emergency path teaches people that the system obstructs clinical work, and once that belief exists it applies to everything else the system asks of them too.
The costing side of consumption is worked through in what a visit actually costs and forty items, one procedure, and the traceability that the batch on each line makes possible in the recall notice arrives on a Friday.
Our take
If your stock leaves through a store, your reorder points work from real measured consumption and you mostly need to set lead times honestly. If some of it leaves through a counter, those items need safety stock set deliberately instead, and the same building can easily contain both. The decision to make before go-live rather than after is the ward dimension: location, project or custom field, chosen once and written down — because that is the one thing on this page that cannot be recovered retrospectively.
See how issuing is recorded
Batch and unit cost per line, three distinct signatures per issue, a value threshold that refuses rather than warns, and consumption that feeds replenishment from real movements.
Explore stock issuingFrequently asked questions
Why do our store reorder points work when our pharmacy counter's do not?
Because the nightly calculation measures usage from stock issued through check-outs, and a store issuing to wards is doing exactly that — the consumption is real, the average is real, and the resulting reorder point is meaningful. A counter records sales instead, and sales are not in that usage signal, so a counter-only item computes its reorder point from safety stock alone. The same facility can have an accurate store and a silent counter for reasons that have nothing to do with how well either is run. For counter items, set safety stock deliberately.
How do we report consumption by ward?
By choosing a dimension to carry it, because there is no department field on an issue. Three options work: model each ward as a location and issue to it, which gives you stock on hand per ward as well; use the project field, which suits consumption that maps to something fundable; or add a department custom field, which is a clean label that holds no balance. Pick one before go-live and write it down — a dimension that was not recorded at the time cannot be reconstructed afterwards, and this is the most common thing to get wrong in a store implementation.
Can we require approval before stock is issued?
Yes, above a value you configure — and it is a genuine refusal rather than a notification. An issue above the threshold cannot proceed until somebody holding the high-value approval permission signs it, and self-approval can be blocked separately so the person raising it cannot authorise it. Set the threshold where a normal week produces a handful of approvals rather than dozens, and decide the emergency path in advance, because there will be a night when a theatre needs something and the approver is unreachable.
Does the issue record which batch was used?
Yes, per line, along with the source location and the unit cost at the moment of issue. The batch is what makes a later recall traceable — it is how the trace knows the stock left that store on that date. The unit cost matters for a different reason: capturing it at issue rather than looking it up later means a consumption report stays correct when the price changes next month, which is what turns it from a count into a cost.
Can a ward raise a requisition that becomes an issue?
Not as a single linked document with a status. A ward asking for supplies happens in whatever form your facility uses, and the issue is recorded in the store; the two are not chained together. In practice most facilities run the request side on paper or by message and record the issue accurately, which preserves the consumption and the audit trail even though the request itself is outside the system. If a linked requisition matters to you, it is worth scoping deliberately rather than assuming it is there.
What consumption number should we actually be watching?
Consumption per unit of activity rather than consumption per ward. A ward's total consumption rises when its activity rises, which makes it almost useless for spotting waste — a busy month and a wasteful month look identical. Consumption per bed-day or per procedure is the number that finds the problem, and the system does not produce it because it does not hold the denominator. Export consumption and join it to activity from your clinical system; it is worth the effort, because it is the only version of this figure that means anything.
