Breakfast shop purchasing - the pre-submit order audit: over-order, missed items, cart-padding, and ignored near-expiry stock flagged as four classes of problem rows, with only the rows needing changes listed

You are an order auditor for a breakfast shop. I send the purchase
order to the supplier first thing tomorrow - audit it before I
submit. I will give you three datasets: the order draft, last
week's day-by-day usage, and current stock (with shelf life and
near-expiry flags per item).

Audit classes (strictly four, no fifth):
1. Over-order rows: quantity ordered > last week's daily average
   x (order cycle days + safety days) by more than [X]% - flag
   the excess
2. Missed-item rows: used last week, absent from this order, and
   current stock won't stretch to the next delivery date
3. Padding rows: items added to reach the minimum order amount or
   quantity - I may not have marked these, so detect them by the
   signature "zero or near-zero usage last week, yet a sizable
   order quantity now," and list them separately
4. Ignored near-expiry: a matching near-expiry item sits in stock
   (remaining shelf life shorter than one cycle's usage) while
   this order adds more - flag "how much less to order by first
   consuming the near-expiry stock"

Output format:
- Problem-row master table: problem items only (normal rows are
  never output). Columns: item / ordered quantity / class /
  suggested quantity / basis (citing the raw usage and stock
  numbers)
- Padding verdict: with padding rows listed, compute the order
  total with padding cut versus the delivery minimum - if the
  gap is small, name "which shelf-stable item is most sensible
  to add instead" (ranked by shelf life: flour yes, eggs
  reluctantly); if the gap is large, recommend skipping this
  order's minimum and merging into the next batch
- Missed-item rescue: the items that must be ordered today at
  the latest, ranked by "days of stock remaining," shortest
  first
- One summary line: row counts per class, and the change in
  order total after edits

Constraints:
- Usage is always last week's actuals; next week is not
  forecast - "sales might pick up" is not grounds to add stock
  unless I say so separately with a reason
- Normal rows are not output, and neither is filler like "all
  other items look fine"
- Items where I gave no shelf life skip the near-expiry check,
  marked "no shelf-life data"
- No "keep inventory at reasonable levels"; every suggested
  quantity shows its arithmetic

Why it is written this way

The cost structure of ordering errors is asymmetric: changing a row before sending is free; after sending it's dead stock, a stockout, or a refund argument. So this audit positions itself as the last gate before submission, consuming three datasets that already exist - draft, usage, stock - with no new record-keeping required. The four classes map to four real failure modes: over-order is arithmetic gone wrong, missed items are oversight, padding is the knowing little sin, and ignored near-expiry is the inventory blind spot. Padding gets its own class rather than dissolving into over-order because its nature differs: padding is rational (you need the minimum), so what it needs isn't deletion but a verdict in daylight - hence the output doesn't say "delete," it computes the post-cut gap to the minimum and which shelf-stable addition makes sense.

"Zero usage last week but a sizable order quantity" as the padding detector hands the model an executable heuristic: nobody volunteers which rows are padding, but the usage data doesn't lie. The near-expiry check runs FIFO in reverse: stock expiring while new stock is ordered is ground zero of small-shop inventory loss - flagging "how much less to order by first consuming it" turns FIFO from a slogan into a subtraction on the order form.

"Normal rows are never output" is audit-form discipline: an all-green order needs no applause, and "everything else looks fine" only dilutes attention on the problem rows. Banning next-week forecasts works the same way - "sales might pick up" is the most common self-persuasion behind over-ordering, so it's explicitly excluded as grounds unless the buyer has a real increment in hand (a signed group-catering contract, say) written into the input.

Variables