Log to stock

A prep batch sits on the work in progress board from the moment it’s started until the moment it’s logged to stock. Log to stock is that moment. It’s the only action in the entire prep area that moves a single number on the pantry — start doesn’t, advance through stages doesn’t, even cancel doesn’t. The cook weighs the finished pot or counts the finished pieces, taps the green button at the bottom of the card, types the actual yield (which almost never matches the recipe’s target), and confirms. In one save the system deducts the ingredients from their pantry rows, freezes the cost of those specific quantities at today’s prices, increments the prep’s own pantry row by the real yield, ticks the task above on the daily checklist, and refreshes the cost-per-portion on every menu item that consumes this batch downstream.

This page is for two readers. If you’re the owner, “Why this page exists” tells you why this one action is the load-bearing moment of the back of house. If you’re the head chef, jump to “How to log a batch” for the workflow.

Why this page exists

A prep is a real-world cooking process: a pot on the stove, a sheet of dough on the bench, a bain-marie of stock reducing for four hours. The recipe targets a yield — 12 kg of bolognese, 50 dough balls, 4 L of stock — but the real yield is governed by physics. Sauces evaporate. Trim happens. A cook over-portions one ball and under-portions the next. The difference between the target and the actual is rarely zero, and pretending it is would put the pantry out of sync with the walk-in within a week.

Log to stock is where the system stops pretending. It asks the cook how much did you actually make? and records that. The ingredients are deducted at the recipe’s per-unit ratios scaled to the actual yield, not the target. The cost-per-unit on the pantry row is computed against that actual yield, so the dishes that consume this prep this week are costed against what the kitchen really made, not what the recipe wished for.

The other reason this action exists is the audit trail. Every successful log writes a production record — a ledger row carrying the recipe, the cook, the timestamp, the actual yield, and the frozen cost. When the cost-of-goods report at the end of the month surprises you, you can find the batch, find the ingredients consumed, find the price each was at on the day, and trace exactly where the surprise came from.

The rule

Log to stock is the only path in the prep area that moves stock. Everything else — starting a batch, advancing it through stages, cancelling it, applying a template, scheduling auto-apply — is preparation for this single moment. The button always asks for the actual yield first, because the actual is rarely the target.

What the action records

A successful log writes one production record and updates several pantry rows in one save. The production record carries:

The recipe and the batch link. Which recipe ran, which live card is being closed, which task on the checklist (if any) it came from.
The actual yield. The number the cook just typed, in the recipe’s yield unit. Defaults to the planned target from when the batch was started; the cook overrides if reality differs.
The ingredient consumption. For each ingredient in the recipe, the quantity consumed by this batch — computed as the recipe’s per-unit amount times the actual yield, including any per-ingredient trim or cook-loss factor. The system writes the consumption against each pantry row, drawing down the oldest stock first when the row holds multiple lots.
The frozen ingredient cost. The cost of those exact ingredient quantities, multiplied by each ingredient row’s cost-per-unit at the moment of log. Summed into one number — the cost of this batch, not an average. The cost is frozen on the production record forever; later price changes won’t rewrite history.
The cost per unit of yield. Total frozen cost divided by actual yield. The pantry row for the prep itself reads its live cost-per-unit from the most recent production batch, so the next dish that consumes this prep is costed against what the kitchen really paid this morning.
The operator and the timestamp. Who logged the batch, when. Stamped onto the production record.
The optional notes. Free text — reduced more than usual, salt was a little heavy, used the last of the opened olive oil bin — saved on the record and visible from the prep’s history.

The cascade fires in the same save. Every menu item whose recipe consumes this prep recomputes its cost-per-portion against the prep’s new cost-per-unit. The food-cost percentage on every affected dish refreshes on the next dashboard load — usually within seconds.

How to log a batch

The button appears on a live card once the batch reaches the Ready stage. The cook advances the card from In progress to Resting (for prep that simmers, ferments or chills passively) and then to Ready when the prep is finished and waiting to be weighed.

Tap Log to stock. The dialog opens with a live preview banner at the top spelling out exactly what’s about to happen: “Logging 11.2 kg of Bolognese base → Bolognese base. The system will (1) deduct the recipe’s ingredients from active stock, oldest first, (2) freeze the cost on this batch, (3) increase the Bolognese base stock by 11.2 kg.”

Type the actual yield. The field pre-fills with the planned target from when the batch was started. Most of the time you adjust — it’s rare for a long-running prep to land exactly on target. Adjust down for evaporation, trim, spillage, a dough that didn’t proof. Adjust up when the recipe over-delivered (a stock that yielded more than expected because the cook simmered it less than usual).

Confirm. Tap the Log button at the bottom right. The card disappears from the board. The pantry row for the prep updates. The task on the checklist above ticks itself.

There’s one safety switch in the dialog — Force log, off by default. If any ingredient is short — the recipe asks for 120g of basil but the basil row only has 80g of active stock — the log refuses by default, returning a precise message: “Not enough Basil in stock — short by 40 g.” The cook has two choices: restock the gap first and try again, or turn on Force log if the prep was actually made and the gap will be filled by tomorrow’s delivery. Force-log proceeds; the basil row goes negative; a warning is returned and shown in the dialog after submit; the pantry list shows the row red until restocked. The cost calculation still runs because the cost-per-unit on the production record is taken from the recipe’s roll-up at log time, not from a per-batch ingredient sum.

If you started the wrong recipe or the prep was scrapped before it reached Ready, don’t log — tap Cancel on the card instead. Nothing moves either way; the card disappears; the task drops back to To do.

What happens behind the scenes

Three operations run atomically when you tap Log.

First, the demand calculation. The system reads the recipe snapshotted onto the batch at start time, walks the ingredient list, and computes the quantity of each ingredient needed for the actual yield. If the recipe says 2 kg of beef per 12 kg of bolognese and you logged 11.2 kg, the demand for beef is 1.87 kg. Any per-ingredient yield-loss factor (a beef shoulder might be 94% usable after trim) is applied here.

Second, the oldest-first ingredient deduction. For each ingredient the system scans the pantry row’s active stock and decrements quantity in age order — oldest production batch first if the row is itself a prep, oldest delivery first if the row is a raw ingredient. When a lot hits zero it’s marked exhausted but kept on the ledger; the next dish that consumes from this row draws from the next-oldest lot. If any ingredient is short and Force log is off, the whole save aborts; if Force log is on, the short ingredient is allowed to go negative and a warning is returned.

Third, the cost freeze and output stock-up. The system multiplies each ingredient quantity by the row’s current cost-per-recipe-unit, sums into one frozen cost, and writes a new production record carrying the recipe, the cook, the timestamp, the actual yield, the ingredient consumption, the frozen cost, and the resulting cost-per-unit-of-yield. The prep’s own pantry row is incremented by the actual yield; its live cost-per-unit is read from this fresh production record going forward.

If the batch was started from a task on the daily checklist, the task is ticked Done in the same save and stamped with the cook’s id and the timestamp.

After the save returns, the cascade fires. Every recipe that consumes this prep as an ingredient is walked, its cost-per-portion is recomputed against the new cost-per-unit, and the result is written back. Every menu item pointing at any of those recipes will show a fresh food-cost percentage on the next dashboard load. None of these downstream rows is hand-edited; the chain does it.

The history of the prep keeps every production record forever. Each one is a snapshot of one batch — recipe, cook, time, yield, ingredients consumed, frozen cost. When a number on the dashboard surprises you later, this is where you trace it.

Worked example — a four-hour bolognese base

It’s Wednesday at your venue. The kitchen is finishing a bolognese base started at 9:30am. The recipe targets 12 kg of finished sauce per batch from this combination of ingredients:

2 kg lean beef chuck at €18/kg → €36.00
1.5 kg tomatoes (canned San Marzano) at €1.40/kg → €2.10
1 kg onions at €0.80/kg → €0.80
1 kg carrot–celery mirepoix at €1.20/kg → €1.20
0.75 L red wine at €4.50/L → €3.38
5 L beef stock at €1.80/L (made in-house) → €9.00
Herbs, oil, seasoning → €1.72
Recipe-target cost: €54.20 across 12 kg → €4.52/kg

The batch has been on the stove since 9:30am — first the soffritto, then the meat, then the wine, then the tomatoes and stock, then four hours at the lowest simmer with the lid off. By 1:30pm the cook, Sara, declares it done. She taps → Ready on the card; the chip flips to emerald green.

She carries the pot to the kitchen scale. Actual weight: 11.2 kg. The recipe-target was 12 kg; evaporation took 800 g over four hours — about 8% loss, normal for an open-pot simmer of that length.

She returns to the page and taps ✓ Log to stock on the card. The dialog opens. The banner at the top reads: “Logging 12 kg of Bolognese base → Bolognese base. The system will (1) deduct the recipe’s ingredients from active stock, oldest first, (2) freeze the cost on this batch, (3) increase the Bolognese base stock by 12 kg.”

Sara overwrites the actual yield field with 11.2. The banner updates: “Logging 11.2 kg of Bolognese base…”. She types a note in the notes field — reduced 800g more than recipe target — and taps Log.

In the same second, three things happen.

Ingredients deducted, oldest first. Each ingredient’s pantry row scales to the actual yield (11.2 / 12 = 93.3% of the recipe-target quantities). The system walks the ingredient list and writes:

Beef chuck: 1.87 kg deducted from the oldest lot in the walk-in. The lot was bought yesterday at €18/kg; the row goes from 4.5 kg to 2.63 kg.
Tomatoes: 1.4 kg deducted, costed at €1.40/kg.
Onions: 0.93 kg deducted at €0.80/kg.
Carrot–celery: 0.93 kg deducted at €1.20/kg.
Red wine: 0.70 L deducted at €4.50/L.
Beef stock: 4.67 L deducted at €1.80/L (drawn down from the production batch the kitchen logged on Monday).
Herbs, oil, seasoning: 93.3% of recipe quantities.

Cost frozen. The system multiplies each quantity by the live per-unit cost on its pantry row and sums: €54.20. (Note: when the actual yield is below the target, the per-ingredient deduction scales down proportionally, so the absolute frozen cost also scales down — fewer ingredients consumed, less cost frozen. The same total ingredient mass spread across less yield is the reason the per-kg cost rises, not the absolute batch cost.) A production record is written carrying recipe, cook (Sara), timestamp (13:32), actual yield (11.2 kg), ingredient consumption, and the frozen cost of €54.20. Cost-per-kg-of-yield: €54.20 ÷ 11.2 = €4.84/kg — up from the recipe-target €4.52/kg, because the same total cost is spread across less yield.

Output stock up. The Bolognese base pantry row goes from 0 to 11.2 kg available. The row’s live cost-per-unit is now €4.84/kg, read from this fresh production record.

Downstream cascade. Every recipe that uses bolognese base recomputes. The Tagliatelle al ragù dish consumes 200 g of bolognese per portion. At the new cost-per-kg, that’s 200 g × €4.84/kg = €0.97 of bolognese per portion — up from the recipe-target €0.90 per portion. Combined with the pasta, Parmigiano and basil, the total food cost per portion is now €2.24 on a dish that sells at €18 — food-cost percentage at 12.4%, a hair above the recipe-target 12.1% because of the morning’s evaporation.

Card cleared. The bolognese card disappears from the work in progress board. Task ticked. The Bolognese base — 12 kg row at the top of today’s checklist auto-ticks to green. The counter climbs.

A few seconds later, service starts. The first Tagliatelle al ragù of the night consumes 200 g of bolognese; the pantry row goes from 11.2 to 11.0 kg; the till deducts 200 g at €4.84/kg = €0.97 against this dish’s food cost. The trail from cook stirred the pot for four hours to till charged €18 for the plate runs through one ledger entry, no manual reconciliation, and an audit anyone can re-read three months later.

Work in progress board — where the Log to stock button lives, on the bottom of every Ready card
Start a prep — the action that put the card on the board hours or days earlier; logging is the closing bracket on starting
Daily tasks — when a logged batch came from a recipe task on the checklist, the task auto-ticks itself in the same save
Recipes — how the kitchen turns ingredients into a costed output — the recipe whose ingredient list is walked at log time
Inventory — overview — the destination of every successful log; the pantry rows that update
Editing an inventory item — the prep’s pantry row whose live cost-per-unit is read from the most recent production record
Waste log — the parallel path that moves stock when a logged batch later goes bad (spoilage, contamination)
Stock counts — the periodic audit that reconciles the pantry against physical reality when production logs and the walk-in drift apart
Prep — overview — the entry to the whole back-of-house workflow