N NoBullshit.wiki 中文

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

Works with:Claude / GPT-4 classCategories:Community SupermarketLevel:Intermediate Updated

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

single-file toolshelf standardsplanogram