¶ The Ordering Views — the Business Manager's Decision Screen (Build Spec)
Status: BUILT, DEPLOYED AND VERIFIED LIVE 2026-10-01 — see the record below the work items. The mockup below
was the design OpenCode built from, and the built screen matches it: my own drive of the deployed app passed
39/39 checks and the suite 645 OK. (It was APPROVED on 2026-10-01 with the four-offer cap, and this page
carries the record of the build and its verification.)** Matthew, on seeing the first
render: "that view is pretty much what I was visualizing — so yes let's go ahead with it", with one amendment:
the supplier offers are capped at four (§4), because a pharmacy may hold six or seven accounts and the row must
not become unreadable. The build brief was issued to OpenCode in
from-hermes and has since been built and verified. The two remaining questions are PARKED until he has seen the
live screen (§12) — "park these until I can see the view" — and both are built as the stated starting positions,
each reversible in one line.
Matthew's approach (2026-10-01): "build a view as close to the specification I am talking about and then make
further modifications from there — it's difficult to discuss this without this 'combined view'." So the layout was
rendered first, on dummy data, for him to change by looking at it — and it was changed that way.
Written from Stock Order Views — the research
question, in Matthew's words: "we need to design our UI's accordingly so that the business manager can see clearly
what is needed and how the relevant stock compares with the other suppliers the pharmacy uses" — and from the
state of the live app, which already holds almost all of the data and has none of the one view.Matthew's rulings this session (2026-10-01):
- "we can only use the data that we have" — a supplier's availability is whatever its imported file says,
and nothing more. So there is no "short supply" claim anywhere: a cell states what the file states, and a line
the file does not list is not in their file of , not unavailable.- "I want both — why do we have to choose one or the other?" — the NHS reimbursement column and the
margin column. The either/or was never a design choice; it was the residue of
phase 4's parked
margin question (its W4), which had no reimbursement figure per pack to subtract until phase 7 and the
Drug Tariff ingestion produced one. Both columns are in scope.- The requirement in one line, also his: "what we need is a clear view, or perhaps a collection of views that a
business manager can rely on to make decisions … the current views may hold this information, but there is no
one collective view and any business manager would find this frustrating."Parents: Supply Orders Part 3 (stages 1–4, live) ·
the figure: The Derived Pricing — Phase 7 (live) ·
the comparison: The Client Comparison — Phase 8 (live) ·
the ordering rules: Supply Orders Pricing — Phase 3,
Phase 4 and the
v1 ordering spec.Naming note. This page carries no phase number on purpose: the pricing family reached 1–4 and the
reference-data family 7–8, so a bare "9" would be ambiguous. It is a presentation stage over data that is already
live, and its path is its name.
¶ The screen as designed — the mockup to argue with (2026-10-01)
A rendered design mockup on dummy data, not a screenshot of anything built. It is the app's own shell and styles
(the pharmacy base template, its own palette, cards and table rules) with the spec's layout applied, so what is being
argued about is the layout rather than the finish. It deliberately shows a pharmacy holding six supplier accounts
so the four-offer cap can be seen working. What to look at, in order:
- The four offer columns — the best four offers for that item, in order, each cell naming its own supplier with
the price, its basis, the file's date and the freshness. Four honest states are visible on the rows: Current ·
Stale · One working day old · Invalid price row · Not in their file of <date> · No price file on record. - The cap doing its job — the ibuprofen and amoxicillin rows each have six suppliers with an offer and show the
four cheapest, with +2 more offers not shown on the row; the full list stays on the line's own supplier
control, so nothing is unreachable. - The two money columns — NHS reimbursement with the rule that produced it (the deduction, the Part II
exemption, the concession month), and Margin beside it: a gain on one row, a loss shown rather than hidden on
another, and on a third the sentence your purchase price is not per pack, so it is not compared. - The guardrail row — the typhoid vaccine has no dm+d pack, so every financial cell is suppressed and the row says
why; the item cannot be ordered until it is linked. - On order — the amoxicillin row shows 24 packs already on an exported order beside the quantity the app proposes,
which is the parked question 1 at the foot of this page made visible. - The basket bar at the foot: each supplier's running value against its own minimum, its shortfall and its
create-draft button — always visible, never blocking, with no cross-supplier total. Note the sixth supplier sitting
there with no lines, because its only offer is stale: the cap changes what is shown, never what is routed. - The collection strip above the grid: the four places the manager otherwise hunts for, each with its own
freshness line.
One layout consequence the mockup makes obvious: the app's <main> is max-width: 880px
(pharmacy/templates/pharmacy/base.html), and this grid needs roughly 1560px to keep a row on one line. The
ordering screen therefore needs a wider container of its own — a class on main, not a new base template — and
that is stated as a work item below rather than left as a surprise on the first build.
¶ 1. The problem — and the one thing it cannot solve
The data exists. What does not exist is one place to stand while deciding. Today a business manager assembling
an evening order moves between, at least:
| Where | What it holds |
|---|---|
Stock dashboard (/stock/) |
counts, the low-stock list, dm+d link counts, last position refresh |
Low/zero stock report (/stock/low-stock/) |
the items at or below their alert level (guide C2) |
Build an order (/stock/orders/new/) |
the routed basket, per-supplier values, the minimum advisory, the per-row price columns and the reimbursement cell |
Price files (/stock/prices/, import, detail) |
which files we hold, for which supplier and date, and what they contained |
Suppliers (/stock/suppliers/, detail) |
who we may buy from, their minimum order value, their portal, their price-file history |
A stock item (/stock/items/<pk>/) |
one item's dm+d link, pack and derived reimbursement |
Price concessions (pharmacy_medicines) |
the month's concession lines |
Every one of those screens is a part of the decision and none of them is the decision. The build screen is
closest, and it still asks the manager to open a dropdown per row to compare suppliers, and to scroll to a group
card to see whether a basket clears a wholesaler's minimum.
What this work cannot fix, and must say so on the screen: we hold prices, not stock. VeriPath holds no
wholesaler availability feed of any kind, and any figure of that kind would be invented. The single availability
signal the platform legitimately holds is the supplier's latest imported file — the line is there at that price,
or it is not there, or the row was unreadable — and the screen says exactly that, with the file's date, and no more.
¶ 2. What exists to build on (verified in the working copy, 2026-10-01)
pharmacy_stock/price_view.pyis the single price answer and is already shaped for this work: its
REPORT_COLUMNS(best price with supplier · spread · prices on file · freshness · NHS reimbursement) carry the
comment that they are the "parked report column set … so a switch to a column per wholesaler is one edit, no
template change". This spec is that switch. The module already refuses to compare aNOT_STATEDprice, measures
freshness in working days (bank holidays fromStockSettings), distinguishes No supplier data from Invalid
price row, and never renders a blank price or a£0.00.- The reimbursement cell already exists and is the honest three-state surface this work extends:
figure·
No published figure for this pack · Withheld — · and, for an item with no dm+d link, Not linked to a
dm+d pack yet — (phase 8; the research page's "Unbridgeable Code Queue" is already built). The rule
that produced the figure is already on the cell's title attribute. services.reorder_suggestions()produces the "what is needed" rows from the cached positions only (no live
ERPNext call per item): active items whose cached total is at or below the alert level, with a quantity that
tops up toorder_up_to_level. The screen already prints the last position refresh.order_build.htmlalready groups by proposed supplier, shows each group's value and the phase 4 minimum
advisory, and carries the per-row candidate supplier select (price · stale · not comparable · no price).Order.StatusisDRAFT → EXPORTED → RECEIVED(orCANCELLED) andOrderLine.quantityexists, so
"already on an unshipped order" — the quantity of that item on orders inDRAFT/EXPORTED— is computable
from our own records today. Nothing shows it.- The nav is one link,
Stock(pharmacy/templates/pharmacy/base.html), andStockDashboardViewalready computes
the low-stock list and the dm+d link counts (linked / queued / unlinked) that an entry card needs.
¶ 3. The screen
The collective view is the existing build screen, not a new page — it is already the screen where the order is
assembled and it already owns the draft → export → receive lifecycle. /stock/orders/new/ becomes the decision
grid; the other screens keep their jobs and become reachable from it (§6).
¶ 3.1 The rows
- Default: every item at or below its alert level, exactly as the reorder list produces today (the app
proposes, the pharmacist decides — that rule does not change). - Plus a search box over active stock items so a top-up line can be added to the basket deliberately — the
research page's "Review Bulk Lines" intent, done as add a line rather than as a filter over a different
screen. An added line carries the same supplier, reimbursement and margin data as a proposed one. - Each row shows on hand · alert level · on order (not yet received) · last position refresh, so
"what is needed" is stated once and completely. The on-order figure is shown and not subtracted from
proposal quantities — the starting position of the parked question in §12 (Matthew, 2026-10-01), one line either
way.
¶ 3.2 The column order
Read left to right, it is the order a manager decides in:
- Item — name, pack size, unit; a link to the item's own page.
- Stock — on hand, alert level, on order, position age.
- The best four offers (§4) — the competing prices for that item, in order, four columns at most.
- Best pick — the proposed supplier, overridable per line as today.
- NHS reimbursement — the phase 7 derived figure for the pack, with the rule that produced it named on the
cell. - Margin — the difference, advisory (§3.3).
- Order qty — the pharmacist's figure, as today.
- Why — the routing reason, the refusal reason, the staleness warning; never empty where the row is not simply
a price winner.
¶ 3.3 The two money columns, and their honest states
Both are advisory, never blocking, and never a substitute for judgement: the app proposes, the pharmacist
decides, and nothing is exported automatically.
- NHS reimbursement is per pack, from the derived pricing (phase 7) against the live releases; its cell
carries the rule text. It is the figure the NHS pays for the pack. - Margin is
reimbursement − best usable purchase price, computed only when both sides are per pack. It is
the figure this whole work exists for, so a negative margin is shown, not hidden — a loss on a line is exactly
what a buyer needs to see before placing it — marked advisory. - The margin's states, all of them textual, are the deliverable as much as the number: figure · no supplier
price on file · no published figure for this pack · your purchase price is not per pack, so it is not
compared · withheld — · not linked to a dm+d pack yet — . No cell is ever£0.00, blank or
a number computed from a different basis. - Its tooltip must say what it is not: the derived figure excludes the Single Activity Fee, which is per
prescription item and is never folded into a pack figure (pharmacy_medicines/catalogue.py) — so the margin is
gross, before fees and overheads, and the column says so on its face rather than letting a manager read it as
net profit.
¶ 4. The best four offers — the change this work is really for, and its cap
The per-row dropdown becomes four offer columns, holding the best four offers for that item, each cell
naming its own supplier and carrying:
- the price and its basis (
PER_PACK/PER_UNIT), because a per-unit price beside a per-pack one is a trap; - the price file's date and the working-day freshness, in the cell or its tooltip;
- one of the honest states: priced · stale · not comparable (basis not stated) · invalid price row ·
not in their file of <date> — which is the availability line Matthew ruled on, and says only what the file
says; - a marker on the best usable offer, and the proposed pick defaulted to it as today.
The cap is four, by Matthew's ruling of 2026-10-01: "we need to limit the number of suppliers to 3/4 … if one has
6 then the suppliers with the best 4 offers get to be displayed" — because a pharmacy may hold six or seven accounts
and a row that keeps growing sideways becomes unreadable. So:
- At most four offer columns, ever, ordered best first — usable offers before unusable ones, and within each
group cheapest first (a stale, unstated or invalid price is shown only when there is room for it, never above a
usable one). - Ranked per item, not per pharmacy. The four columns are that item's four best offers, so the same supplier sits
in different columns on different rows — which is why each cell names its own supplier. Four is the ceiling,
not a promise: a row with two offers shows two. - Nothing is hidden. Where a supplier has an offer that does not fit, the row says
+N more offers not shown, and every candidate stays reachable on the line's own supplier control — the existing select, which lists
them all with their prices and states. The cap changes what is shown; it never changes what is routed, what is
valued or what may be ordered. - The number lives in one place. Four is a constant in
price_view.py, beside the column set it governs, so
moving it to three, or making it a client setting, is one edit and no template change. The speculative
"configurable later" is not built now.
(This also answers the research page's closing question about information density: the grid is dense by design, and
what keeps density from becoming ambiguity is the honesty rules — never a blank, never a £0.00, always a reason —
plus this cap.)
¶ 5. The basket bar
The per-group value card becomes a bar that is always visible at the foot of the workspace, one line per
supplier in the basket:
• Sigma — 12 lines — £25.28 of a £150.00 minimum — £124.72 short — [Create draft]
with its states exactly as phase 4 built them: clear · short (with the shortfall in money) · value not
known (so it is not checked) · no minimum set (no warning, not a zero-value one). It never blocks, never
changes a quantity and never adds a line. There is no cross-supplier total: it would be commercially
meaningless, and one is not built.
¶ 6. The collection strip
Above the grid, one compact strip of links — the collection — each carrying its own freshness line so nobody
has to go looking and nobody reads stale data as current:
| Link | Its freshness line |
|---|---|
| What we are low on (low/zero stock report, guide C2) | as at the last position refresh |
Price data we hold (/stock/prices/) |
N files · newest dated <date> |
Who we may buy from (/stock/suppliers/) |
N suppliers · M without a price file |
This month's NHS concessions (pharmacy_medicines) |
month and publication date |
The item in full (/stock/items/<pk>/) |
from each row's item link |
and one standing sentence, which is Matthew's ruling made visible: "Supplier availability is whatever their
latest price file says — VeriPath holds no wholesaler stock feed."
¶ 7. The entry point
StockDashboardView already computes the low-stock list and the dm+d link counts, so the dashboard's "Low / zero
stock" card becomes the entry: the count of items needing a decision, the last refresh, and one link —
"Open the ordering view". A pointer, not a second grid: two grids showing the same rows is how screens drift
apart. The dashboard keeps its other cards unchanged.
¶ 8. Work items
- W1 — the four offer columns.
price_view: the parked column set becomes the best four offers for the item
(the cap in §4, ranked per item: usable before unusable, cheapest first), each carrying the supplier's name, price,
basis, file date, freshness and its state, plus the+N more offers not showncount. The reimbursement cell and the
comparability guard stay exactly as they are. One query set for the screen, no lookup per row (the module's standing
rule), and the cap held as a single constant in this module. - W2 — the margin. A derived, read-only figure beside the reimbursement:
reimbursement − best usable per-pack price, with the states in §3.3 and the tooltip that names the rule and the SAF exclusion. No new stored column
and no history — it is a reading of two existing answers, like the value totals in phase 4. - W3 — on-order quantity (PARKED starting position, §12). The quantity of the item on orders in
DRAFT/EXPORTED, computed in the same query
set as the reorder rows. Shown; not subtracted from proposals (starting position). - W4 — the always-visible basket bar, carrying phase 4's advisory verbatim and the per-supplier create-draft
action already implemented. - W5 — the collection strip (§6) with each link's freshness line, and the standing availability sentence.
- W6 — the dashboard entry card (§7).
- W7 — the add-a-line search over active stock items (§3.1.2), with the same gate as the grid.
- W8 — copy, guides and records. The build screen's note, the C6 guide (Order Stock and Export the Order
File), C2, and the pricing walkthrough
have to say the same things as the screen: the minimum is contractual and not enforced; availability is the
imported file and nothing more; the margin is advisory, gross, and per pack or not at all. A guide that
disagrees with a screen is a defect in this project, not a documentation lag. - W9 — the wider container.
mainismax-width: 880pxinpharmacy/templates/pharmacy/base.html; the grid
needs ~1560px. Give the ordering screen its own wider container (a class onmain, as the mockup shows) rather
than a new base template, and let the other pharmacy screens keep 880px. This is the only change any other page
sees, and it is additive.
¶ 9. Deliberately out of scope
- Any supplier availability or stock feed, real-time or otherwise. We have no such data and will not imply it
(Matthew's ruling 1). - Auto top-up, auto-export, and anything blocking an order on a threshold — phase 4's advisory ruling stands
unchanged. - Any second grid or dashboard copy of the ordering rows.
- Cost or margin history, and per-supplier spend reporting — a later, separate subject.
- Net margin (after fees and overheads) — the figure is gross and says so; netting the SAF and fees into a pack
figure is exactly the error phase 7 §5.6 forbids. - Persisting a price or margin onto
Order/OrderLinebeyond the existing snapshots. The snapshots stay as
phase 3 wrote them.
¶ 10. Roles, boundary and performance
- RP / Dispensing Technician / Business Manager (
PharmacyStockManageRequiredMixin), exactly as the build
screen today. The Counter Assistant is refused (403) — prices and margins are commercial data, the same gate
phase 4 set for value surfaces. No widening of any surface. - No ERPNext client constructed, no position-cache write, nothing central. The screen reads the cache, the
client's own price rows, the client's own order lines and the read-only reference mirror, as the existing screens
already do. - One query set per screen, never a lookup per row — the rule
price_viewand the position cache already
follow, and the reason the supplier columns are aprice_viewchange rather than a template loop.
¶ 11. Tests
Per-item: at most four offers are shown, ranked per item and usable-first, with a supplier outside the four
reachable on the line's supplier control and counted in +N more offers not shown; a row with two offers shows two
and never a blank fifth cell; cheapest usable price marks the best offer; a NOT_STATED price is never comparable and never wins; a
stale price is shown, aged and never silently taken; not in their file of appears for a supplier with a
file that lacks the item, and no cell ever reads "short supply"; the margin appears only where both sides are
per pack, its negative case is shown and marked advisory, and each of the §3.3 states renders its sentence; an
unlinked item suppresses every financial cell and states its reason (the existing phase 8 rule); the on-order figure
counts DRAFT + EXPORTED lines and not RECEIVED or CANCELLED ones; the basket bar's four states including
value not known; the Counter Assistant refused every surface; the export file unchanged — two columns, no
price, no margin; and the boundary assertions above.
¶ As built and verified live (2026-10-01, session 49)
Built by OpenCode in pharmacy_booking_app f05fc3f (the view) and 44d8595 (the satellite line and the rig
README), branch feature/wda-supplier-lookup, deployed on VPS2 — read back from the running container: MAX_OFFERS = 4 in price_view.py, main.wide in the base template, the best four offers header in order_build.html, and
the migrations ending at 0014 (so no migration, as the brief required). No new stored column. Verified by
Hermes, not from the handback:
- The screen, live on
test-client-pharmacy, driven through the real OIDC login by a new committed verifier
(veripath-ops7e2be34,scripts/verify-pharmacy-ordering-views-live.py; its parsing sits in three helpers —order_rows,order_lines,grid_rows— checked against the templates' own markup before the drive): 39 checks, 39 passed, none failed.
The wide container; the four-offer header with its four ranked sub-columns; exactly four offer cells on every row
and not one blank; the offers naming their own supplier with price, basis and freshness; the best usable marked;
not in their file of <date> for a supplier whose own file lacks the item; both money columns present with the
reimbursement's rule, a loss shown rather than hidden, and the gross/SAF sentence; no "short supply" and no
£0.00anywhere on the page; the basket bar with two supplier lines, its own create-draft action each and the
no-cross-supplier-total sentence; the collection strip's four links each with a freshness line; the add-a-line
search returning a marked row; the dashboard pointing at the view without re-rendering the grid; the Dispensing
Technician admitted and the Counter Assistant refused (403). - The on-order figure was cross-checked against the app's own orders list, not taken on trust: summed from the
DraftandExportedorders' lines and compared per item, every one of the five rows matched (Ibuprofen 400mg
192, Ibuprofen 200mg 3, Salbutamol 10, Amoxicillin 21). No delivery-received order touches those items in the demo
tenant, so the exclusion ofReceived/Cancelledis stated as by construction and by the module's own unit tests
rather than as a live difference. - The maths behind the money was read in the code, not assumed:
margin_cell()derives
reimbursement − best usable per-pack priceand refuses to compare a per-unit price with a per-pack reimbursement;
_best_usable()prefers a per-pack price, so a cheap unit price can never win a row;on_order_quantities()counts
DRAFT+EXPORTEDin one aggregate query. - No regression on the screens that kept the parked column set: the low-stock report still renders Best price
(supplier), and the dashboard, price files, suppliers and an item page all answer 200. - The two copy items verified where they belong: guide C6 now describes the ordering view (its column table
matches the screen field for field), guide C2 points at it and repeats the three rulings, and the
walkthrough has Stops 3 and 4
rewritten with its "the margin column is not built" line corrected. - Suite, on my own run: 645 tests, OK (230.6 s), on my own run of
scripts/run_pharmacy_tests.shagainst this commit — the count the handback claimed, reproduced on this host rather than taken from the note.
One thing the demo tenant cannot show, and it is the seed rather than the code. The tenant holds 7 suppliers, 3
of them without a price file, so no item has a fifth offer and the +N more offers not shown count is not
exercised live — the rows fill their four cells with real offers and not in their file cells instead. The cap
itself is live (four cells, never five), the counter is proved by the deterministic six-supplier test, and the
sentence appears in the code path that would render it. If the live +N is wanted — for the guide figures as much
as for the proof — the demo seed needs two more priced suppliers so one row carries five offers; that is a seed
change, not a build change, and it is Matthew's to ask for.
¶ 12. The two questions — PARKED until Matthew has seen the screen
PARKED (Matthew, 2026-10-01): "I can't really answer those questions now until I see the view … so I'll say park
these until I can see the view." Nothing waits on either: both are built as the starting positions recorded below,
each reversible in one line, and both are re-asked once the screen is live — because the first of them cannot be
answered from a picture at all, only from using the thing.
Answered, and no longer open: the supplier cap is four (§4) — his ruling, the same day.
- On-order quantities — PARKED. Should an item that is already on an order which has not arrived yet still be
proposed for another one? Today's behaviour, and the starting position: the quantity already on order is simply
shown on the row, and the app proposes exactly what it proposes now — so amoxicillin at 6 on hand, with 24 on an
exported order and a 60 target, is still proposed as 54. The other way would net the 24 off and propose
30, so an item stops being chased while its order is in flight — which is right if orders are prompt and wrong
if a delivery is about to arrive short. Why it cannot be settled from the mockup: it is not a layout question,
it is what the pharmacist wants the app to want, and it shows itself only in use. - The add-a-line search (W7) — PARKED. Whether the ordering screen carries a search box for adding a top-up line
from the whole catalogue, or the alert-level list is enough for the first pass. Starting position: built, because
the list alone cannot express "while I am here, I want more of this one"; if it proves to be clutter it is one
block of template and one view to remove.