Community supermarket stock clerk - shelf capacity calculator: shelf length times item width gives facings per shelf, facings times turns against average daily sales gives days of cover, and the item you refill every day was never a hot seller - it was under-faced
You are a coding agent. Build a single-file HTML
"Shelf Capacity Calculator" for community
supermarket stock clerks: measure a shelf once,
answer three questions - how many facings per
shelf, what the full section holds, how many
days of cover that buys. Runs locally, no
network, no external dependencies.
Positioning (design to this; do not build an
inventory system): clerks refill the same items
every day and have never computed whether it is
big sales or small facings. This tool does
geometry and capacity arithmetic only: facings
per shelf, section capacity, days of cover
divided from a user-entered average daily sales
figure. It deliberately does no sales
forecasting - the daily number is the user's
own input and the tool only divides; the moment
a prediction model sneaks in, the outputs stop
being trustworthy enough to argue for shelf
space with.
Three functions:
1. Item quick-calc
- Inputs: usable shelf length (cm, minus
uprights), item width (cm, widest point of
the pack), number of shelves, average daily
unit sales (user-entered)
- Outputs: facings per shelf (floor), full
section capacity (facings x shelves), days of
cover (capacity / daily sales), recommended
facings (the minimum covering [replenishment
cycle] + 1 buffer day; flag "under-faced"
when it exceeds current facings, "space to
give" when below)
- Unit selector: each / bottle / bag / can /
case, shown with results
2. Shelf card (printable)
- Every calculated item generates a card: name /
barcode or item number / facing count /
section capacity / suggested reorder point
(the capacity level that triggers a refill)
- Print layout: multiple cards per page, legible
in black and white, folded size fits inside
the shelf's front rail
3. List and comparison
- Calculated items auto-enter a list sorted by
days of cover ascending - the top of that list
is what gets refilled daily
- One judgment line above the list: where days
of cover run below the replenishment cycle
across the board, the section is structurally
under-faced and the clerk has a number to
bring to the manager; where only isolated
items run short, it is those items' problem
- List exports and imports as JSON
Hard constraints:
- Every formula displays beside its result
(days of cover = capacity / daily sales) so
the user can see where numbers come from
- Daily sales: accept a single hand-entered
number or a few recent daily figures averaged
- no networked data pulls, no system
integration of any kind
- Data in localStorage, with JSON export/import
for moving machines
- Preload 8-10 example items including one
classic "under-faced" case and one "space to
give" case, so all three functions show
output on first open
You may not:
- Use the network or connect to any inventory
or POS system
- Do sales forecasting - no curve fitting, no
"smart suggested order quantities"; ordering
belongs to the buyer
- Build whole-store planogram management; this
is a quick calculator, not a space-planning
system
- Add accounts or external libraries
Why it is written this way
"Geometry and capacity arithmetic only, no forecasting" is the load-bearing wall. The clerk's real question is rarely "how much should we order" (the buyer's job) but "how much does this section physically hold and how long does that last" - one division answers it, and the answer verifies on the spot (build the facing and count). The moment the tool starts "intelligently predicting sales," its recommended facings stop being verifiable geometry and become unverifiable model output, and a clerk cannot take that to a manager. This tool's whole value is walking into that conversation holding a number nobody can argue with.
The recommended facings formula - minimum facings covering the replenishment cycle plus one buffer day - upgrades the tool from arithmetic to negotiating capital: the item refilled daily turns out to be a three-shelf section holding one day of sales. That number moves a manager; "this item moves fast" moves nobody. Sorting the list by days of cover and splitting the verdict into "the whole section is under-faced" versus "isolated items" matters because the fixes differ completely - one is a planogram conversation, the other is moving one item one slot.
The printable shelf card is what makes any of this survive the night it was computed: numbers that never return to the shelf live only until morning. The card carries the suggested reorder point so the clerk checks the card, not the system - and in stores where the system is unreliable, that card becomes the clerk's own minimal stock ledger. Preloading an under-faced example and a space-to-give example means anyone opening the tool understands in ten seconds what question it answers.
Variables
| Variable | Description |
|---|---|
| Replenishment cycle | Days from reporting empty to refill landing - drives recommended facings; daily-replenished and weekly-replenished items need wildly different facing counts |