Skip to content

What shows up in the inventory list

The inventory database has more rows than the inventory list shows. The list filters. Open the list and you see the rows the kitchen actually counts, buys, or holds — not every record the database carries, not every draft that’s ever been imported, not every plated-to-order dish that exists in the system only so the till has something to attribute a sale to. The list is a deliberate, curated view; the database underneath is broader.

This page is about the filter. Why some rows you’d expect to see don’t show up, and what to do to make them appear.

The rule

A row shows in the inventory list when it’s connected to something the kitchen does. Connected means: linked to a supplier, produced by a recipe, or a child of a separation. A row that’s none of those is invisible until it earns its place.

The reason the rule exists is noise. Without it, every drafted import line, every half-finished migration, every plated-to-order dish would clutter the list and the count screen and the reorder shortlist. The chef would spend the morning scrolling past rows that don’t matter to find the ones that do. The rule strips the list down to the rows that are real, in the sense that someone in the kitchen physically touches them.

What “connected” means

Three kinds of connection earn a row its place in the list.

Linked to a supplier. The row has at least one approved supplier product underneath it — a real entry in a real supplier’s price list, approved by someone in the kitchen, with pack data and a price. This is the most common case. A row for San Marzano tomatoes with the ItalianDirect product approved beneath it is connected. A row for San Marzano tomatoes that someone typed into a draft and never finished linking is not.

Produced by a recipe. The row is the output of a recipe — a sub-assembly the kitchen makes in batches (L2: ragù, stock, dough, mirepoix) or a finished dish that needs a stock anchor (L3, batched: tiramisu, panna cotta, anything plated ahead and counted by the portion). The recipe’s existence is the connection. As soon as you save a batched recipe, its output row is connected and shows up.

A child of a separation. The row is one of the things a whole-ingredient split produces — egg yolk and egg white from whole egg, suprême and carcass from whole chicken, fillet and trim from whole fish. The parent’s separation rule names the row, and that naming counts as connection.

Anything else is loose, and loose means invisible.

What “loose” looks like in practice

A draft import landed in the database with a row called Saffron threads. The supplier-matching agent pulled it from a price list it scraped overnight, but no one has approved it yet — no supplier product is linked. The row exists in the database, with a name and a category and a creation date, but the inventory list won’t show it. It’s loose: no supplier, no recipe, no separation parent.

Or: someone typed Argan oil into the row editor as a placeholder while figuring out the brand. They saved without picking a supplier. Same outcome — the row is in the database, invisible in the list.

Or: a plated-to-order dish like Cacio e Pepe. Its row exists at L3 so the till has something to attribute the sale to and the recipe can deduct ingredients from the right place. But the recipe is à la minute, not batched, and the row has no supplier and no separation parent. The system marks it as plumbing — it’s intentionally hidden from the inventory list because there’s no stock to count, no shelf to put it on. The till still uses it; the list doesn’t show it.

How to make a loose row appear

The fix depends on which kind of row it is.

For a draft ingredient, open it from wherever the draft lives — usually a supplier matcher’s review screen — and approve a supplier product underneath. The row picks up the supplier, picks up the pack data, picks up a cost per recipe unit, and on the next list refresh appears in the inventory list with everything filled in.

For a row someone typed manually, open it from the row’s edit page and either link a supplier product (in the Suppliers tab on the detail page) or attach it to a recipe as the output. Either connection works; the list checks for any of the three, not all.

For a plated-to-order dish that you’ve decided to start batching, open its recipe, flip the Batched toggle on, save. The recipe’s output is now batched, the row is no longer plumbing, and the inventory list shows it. The reverse flip — turning a batched recipe back into à la minute — pulls the row back out of the list.

The intended friction here is real. A row you typed and saved doesn’t appear until you do the work to connect it. That’s deliberate: it forces the small completion step (link the supplier, or attach the recipe) that makes the row useful to the rest of the system. Without that step the cost is unknown and the supplier is unknown and the reorder shortlist can’t include the row anyway — showing it on the list would only be a lie.

What happens behind the scenes

The list query runs the three connection checks for every row in the venue and returns the rows that pass any of them. Connection to a supplier is checked by looking for at least one approved supplier-product row pointing at this inventory row. Connection to a recipe is checked by reading the row’s own produced by field. Connection as a separation child is checked by reading a flag the parent’s separation rule writes onto the child when it creates it.

The check runs on every list read — there’s no batch job, no nightly reconciliation. The moment you approve a supplier product, the next list read includes the row. The moment you archive the supplier product, the next list read drops the row (unless it’s also connected by a recipe or separation, in which case it stays).

The same rule governs the row pickers — the Recipe ingredient dropdown when you’re building a recipe, the Output item dropdown when you’re choosing what a recipe produces, the Storage assignment dropdown when you’re moving a row to a new location, and the item search when you’re building a purchase request. Loose rows don’t appear in any of them. The list view and the pickers all read the same gate.

One thing to know about the purchase-request item search specifically: when you type a name there, it searches your whole connected inventory, not just a recent slice of it. A row you connected this morning is findable the moment it passes the gate, no matter how many thousands of items the venue carries — and the “below par level” nudge at the top of the form counts every below-par item, so Add all to request never quietly leaves the newest ones out. (This used to be capped: on a large pantry the newest items were invisible in the purchase-request search. They no longer are.)

The count on the category button matches the list

Each category button shows a number — how many rows that category holds. That number counts exactly what the list shows when you tap the button: your raw ingredients and your batched preps, never the made-to-order plumbing rows. A button that reads 12 opens to twelve rows, every time.

This wasn’t always true. A category button could once show a large number — say 188 on a catch-all bucket quietly full of made-to-order dishes — and then open to an empty list, because the list correctly hid those plumbing rows while the number still counted them. The same gap also made the main list hide your batched preps entirely: a tray of ragù you make every morning is real stock you count, but the list used to leave it out. Both are fixed — the number, the list, and the count screen now all follow the one rule on this page, so what a button promises is what you get.

Worked example

Sara, the head chef at your venue, opens the inventory list on Monday morning. She wants to add saffron threads to the menu’s new risotto. She types saffron into the search and gets no results — the row doesn’t appear.

She frowns and opens the supplier-matcher review screen. Sure enough, there’s a draft row from last week’s price-list import: Saffron threads, 1g, sourced from a price list the matcher pulled overnight from her spice supplier. The row exists, but no one approved it yet. Sara taps the draft, reviews the pack data (1g sachets, €4.50 each, ~€4500/kg as a sanity check), confirms the canonical name Saffron threads, and taps Approve. The system creates the supplier-product link and the row’s approval is complete.

She switches back to the inventory list and refreshes. Saffron threads now shows in the list under Spices, with cost per recipe unit derived from the supplier’s pack data (€4.50 / gram), with the supplier name on the row chip, with everything she needs to drop it into the risotto recipe she’s about to write. The row was always there in the database; the connection was the gate. The connection now exists, and the row earned its place.