Snack shop purchasing & ordering - case-pack breakdown ordering calculator: suppliers sell by the case, inventory counts come back in bulk-bin pounds, and sales reports in bags - three unit systems coexist, so have a coding agent build a single-file tool that owns "how many bags a case really is, how many days that covers, how many cases to order"

You are a coding agent. Build a single-file HTML
"Case-Pack Ordering Calculator" for snack-shop
purchasing: runs locally, no network, no
external dependencies.

Positioning (design to this; do not build an
inventory system): purchasing by the case,
counting in pounds, selling sometimes by the
bag - three unit systems coexist and ordering
runs on mental arithmetic. This tool does
conversion and days-of-cover only: normalize
stock and sales velocity entered in any unit
into one frame, compute how many days that
lasts and how many cases to order. It
deliberately does no sales forecasting - the
velocity number is the user's own input and
the tool only divides; the moment a prediction
model sneaks in, the output stops being safe
to place orders on.

Three functions:

1. Item profiles
- Per item: name, supplier, case pack (bags
  per case x grams per bag, or net case
  weight), cost (per case), pricing basis
  (retail by pound / retail by bag), retail
  price
- The conversion chain always displays:
  1 case = N bags = M grams = M/500 pounds -
  the formula is forever visible beside the
  numbers

2. Order calculation
- Enter current stock (grams / pounds / bags,
  any one) and average daily sales (any unit);
  everything normalizes to bags
- Outputs: days of cover = normalized stock /
  normalized velocity; suggested cases =
  (replenishment cycle + buffer days) x
  velocity - stock, rounded up to whole cases
- Replenishment cycle and buffer days are
  global settings, editable
- Items whose days of cover sit below the
  replenishment cycle auto-flag red - that is
  the "must order this week" line

3. Order sheet
- Tick items to order; generate an order sheet
  grouped by supplier: item / cases / cost /
  totals
- Printable, JSON export; data in localStorage

Hard constraints:
- Every conversion shows its formula (1 pound
  = 500 grams is stated on the interface, not
  buried in code)
- Next to every stock and velocity input the
  unit currently being interpreted always
  displays - guarding the pound/kilogram mixup,
  which lands as a 2x error
- Preload 8-10 example items including one
  bulk-bin item priced by the pound and one
  packaged item priced by the bag, so both
  bases show output on first open

You may not:
- Use the network or connect to any inventory
  or POS system
- Do sales forecasting or "smart suggested
  quantities" - the suggested case count is
  always coverage arithmetic, never model
  output
- Build supplier reconciliation or payables -
  that is another job

Why it is written this way

"Conversion and days-of-cover only, no forecasting" is the load-bearing wall. The purchaser's real question at order time is rarely "how much will sell" (that takes forecasting) but "how many days does one case actually buy" - one division answers it, and the answer verifies on arrival (count the bags). The moment the tool starts "intelligently predicting," the suggested case count stops being verifiable arithmetic and becomes unverifiable model output, and the purchaser stops trusting it enough to order on. The tool's whole value is a number nobody can argue with.

The unit-in-use indicator next to every input field guards against the most expensive accident in snack-shop conversion: pounds entered as kilograms, an instant 2x error that lands as stockout or overstock depending on luck. Three unit systems coexisting is the industry's normal state - bulk bins sell by weight, packaged goods by the bag, suppliers ship by the case - so the tool does not force unified entry; it accepts any unit and normalizes internally. That is the only shape that survives daily use.

The suggested-case formula is deliberately written as "(replenishment cycle + buffer days) coverage" rounded up to whole cases, with no words like "optimal inventory": case packs are ragged in this trade (24-bag cases next to 40-bag cases), whole-case rounding is physical reality, and any extra layer of "optimization" makes the number's origin unreadable to the purchaser. Grouping the order sheet by supplier exists because the real action at the end is "text one order sheet to supplier A's rep" - the tool's last step must land on that action, or the math gets hand-copied all over again.

Variables