N NoBullshit.wiki 中文

Bakery purchasing - the supplier split-order tool: one requirements list in, one ready-to-send PO per supplier out (have a coding agent build it)

Works with:Claude / GPT-4 classCategories:BakeryLevel:Advanced Updated

Build me a single-file HTML split-order tool for a bakery buyer to
run before sending orders out. Double-click to open, no network,
data never leaves the machine.

Input one, the requirements list (one ingredient per line, pasteable
straight from a spreadsheet with a fixed column order): ingredient
name, quantity needed, unit.

Input two, the supplier directory (maintained in a settings area
inside the page, with JSON import and export): one row per
ingredient - primary supplier, pack size (e.g. 25 kg bag), minimum
order in whole packs, whether the supplier sells break-pack loose.

What the tool does:
- Group the requirements list by primary supplier, one group per
  supplier
- Round to pack size: for 60 kg of flour against a 25 kg bag, each
  line offers both bases - "round up" to 3 bags (15 kg over), or
  "whole packs plus loose" with 2 bags and a 10 kg loose top-up
  (only where the directory marks break-pack supported); a per-line
  dropdown switches between them, round-up is the default
- Show the rounding difference against need on every line: how much
  over-ordered, how much loose; never only one total difference in
  the summary
- Lines below the minimum order highlight as "under MOQ" with how
  many packs short
- Ingredients with no supplier in the directory are flagged
  "unassigned" and listed in their own table; they are never
  silently dropped into some supplier's order, and never silently
  dropped from the results
- One plain-text PO per supplier: item / pack size / pack count /
  total quantity / notes, one-click copy, formatted to paste
  straight into a chat message

Hard requirements:
- Single file, no build step, no external CDN, fonts or libraries,
  zero network requests
- If pasted data has the wrong column count or a shifted order,
  error loudly in the UI naming the row - never silently compute on
  misaligned data
- No accounts, no cloud save, no local storage, refresh clears
  everything - this is deliberate: the supplier directory travels
  between sessions via JSON export and import, and the requirements
  list is use-and-discard. Do not add localStorage on your own
  initiative; yesterday's stale requirements leaking into today's
  orders is worse than not having the tool

Why it is written this way

What and how much to order is judgment; splitting, rounding, and copying are haulage - this tool only does the hauling. The buyer's attention belongs on the questions the rounding differences expose: will 15 kg of extra flour turn over next week, is there shelf space for it, does one extra pack of a pricey ingredient tie up cash the shop needs. Forcing the difference onto every line makes each rounding decision visible instead of dissolved into one summary number.

Two rounding bases coexist behind a per-line dropdown because which one wins depends on unit price and turnover speed - two things the tool does not know. Bulk flour gets used next week either way, so rounding up is nearly free; on a pricey ingredient, one extra pack is parked cash, and break-pack wins wherever the supplier allows it. So the default serves the bulk goods and the override belongs to the expensive rows - the tool does the arithmetic right, the basis stays with the human.

The "unassigned" table exists to stop the tool from being helpfully wrong. Every requirements list carries a few ingredients missing from the directory - new items, one-off buys - and the lazy-but-plausible move is stuffing them into whichever supplier seems related. An order line the vendor does not recognize costs more back-and-forth than not ordering it at all. A separate table forces the buyer to fix the directory on the spot, which is also how the directory gets more complete every week.

Refresh-clears-everything and JSON import/export are a deliberate pair. The directory is worth keeping but the page must not remember it; the requirements list changes daily and must die on use. "Keep" is delegated to a JSON file the buyer owns; "discard" is delegated to the refresh button, and neither discipline crosses into the other's territory. These "do not add" lines have to be said out loud - ask a coding agent for "a tool" and you will likely receive a "complete solution" with localStorage persistence. Without "this is deliberate" spelled out, the agent helpfully adds it back.

Variables

This prompt has no fill-in variables; the supplier directory is maintained by the user inside the tool's settings area, saved via JSON export and reused via import.

ordering toolsupplier managementpack-size rounding