Inventory
The Inventory section tracks stock of ingredients and goods. The core idea: you describe each dish's recipe once, and then components are deducted automatically when an order is completed — stock stays accurate without manual bookkeeping.
Open: Admin panel → Inventory. Three tabs: Stock, Documents, Suppliers.
Stock#
- A product = an ingredient or a stock item: name, unit, current quantity.
- Minimum stock — when the quantity drops below this level the row is highlighted: time to reorder.
- A product can be archived — it disappears from the list but stays in the document history.
Recipes: auto-deduction on orders#
Each dish (in the Menu section) gets a recipe — which products and how much go into one serving. When an order is completed:
- components of every order item are deducted according to their recipes;
- for combo sets, the deduction unfolds the recipe of every dish inside the combo;
- all movements are visible in the Documents tab.
To link products to dishes quickly there are AI suggestions: the system analyzes your menu and proposes which dishes use a product — you just confirm.
Semi-finished products (preps)#
For preps (sauces, dough, broths) a product gets its own recipe. The "Produce" button creates a production document: the prep is added to stock while its components are deducted. In dish recipes a prep is used like any other product.
Goods receipt#
Two ways to register incoming goods:
- Manually — the "Receipt" button: pick products, quantities, prices and the supplier.
- By invoice photo — snap a photo of the delivery note: AI recognizes line items, quantities and prices and matches them to your products. You review and confirm. New products can be created right from the recognized invoice.
Every receipt is stored as a document linked to a supplier — purchases flow into Finance (food cost, gross profit).
Purchase price control on receiving#
On receiving, every line is compared with the median price of that product over the last 30 and 90 days. If the price is noticeably higher, a "+N % vs median" badge lights up next to the line — the storekeeper sees the increase at the moment of receiving, not a month later in a report.
A few details that matter:
- the sample unit is the invoice, not the line: a supplier who splits a delivery into five lines does not shift the median five times harder;
- fewer than three deliveries is not a sample, so no badge appears;
- a discrepancy confirmed by the storekeeper lands in the supplier's journal — the counterparty gets a history of price shifts and a marker on the "Suppliers" tab;
- the same median feeds the "purchase price spike" risk rule — the owner sees it in the "Cash risks" block, see Loss control. The storekeeper's and the owner's numbers match, because they are computed once, on the server.
Suppliers#
The Suppliers tab is your counterparty database: legal name, tax ID, bank and account, address, contact person, phone, email. A supplier is selected when registering a receipt, so each counterparty has a purchase history. An archived supplier disappears from the list but stays in documents.
Variance: where the difference went#
The "Variance" tab answers a question invisible in both sales and receipts: between two stocktakes more left the store than was sold. Consumption over the cycle is split into three parts:
| Part | What it is |
|---|---|
| Sales | cost of goods sold, recorded at the moment of sale from recipes |
| Explained | waste write-offs, production of semi-finished items, transfers between locations |
| Unexplained (variance) | what the stocktake found: expected quantity minus counted quantity |
The third line is the loss: an inaccurate recipe, portions served "by eye", unrecorded waste, or theft. It has to be read together with the first two — otherwise you cannot tell "we served more than the norm" from "we wrote it off as waste".
An honest caveat: a manual stock adjustment inside the cycle stores an absolute value rather than a delta, so part of the "unexplained" is in fact explained by an operator's hand — such documents are counted separately and shown alongside.
Losses exceeding theoretical consumption by more than a configured percentage raise the "consumption above norm" rule — see Loss control.
Demand forecast and prep plan#
The "Forecast" tab turns sales history into a plan for tomorrow: how many dishes will sell on this weekday, what has to be prepped (with recipes exploded and a "be ready by" hour), what to order from suppliers, and what risks running out before the day ends.
Details — Demand forecast.
Products by weight and labels#
Products by weight. A product can be measured in kilograms/litres rather than pieces: stock, recipes and write-offs all use those units. If scales are connected to the till through the hardware bridge, the weight is filled in automatically — both on receiving and when selling a dish priced by weight (canteen, deli). Price-by-weight is configured on the dish card, see POS.
Shelf labels. Products get warehouse labels with a barcode, name, price and an expiry date: if the product has a shelf life in days, the expiry is computed as the print date plus that period. This is not the same as order stickers — those are printed by the kitchen, see Kitchen and front-of-house printing.
There is no batch tracking or FEFO yet: the system knows a product's shelf life and prints a label from it, but does not keep separate batches with different dates.
What you need to get started#
- The "Inventory" section — it is on by default; at 30 or more SKUs the system will suggest setting it up itself.
- Ingredient and product cards with units of measure and pack sizes.
- Recipe cards on dishes — without them automatic write-off on sale will not work.
- Purchase prices — otherwise cost of goods, food cost and menu engineering cannot be calculated.
- Permissions: running a stocktake is available to the owner and the manager.
- The bridge and a label printer — for prep labels and price tags.
Limitations#
- Inventory analytics runs on the AWS contour. On the Russian brand functions built on the analytics databases are unavailable — parity is tracked as an open task.
- Negative stock is allowed deliberately: an incoming delivery "forgives" the shortfall rather than blocking a sale.
- There is no batch tracking or FEFO in stock quantities. FEFO exists only in marking (which opened pack to finish) and does not affect quantities.
- There are no automatic unit conversions — grams and kilograms are described by the card's pack size rather than converted on the fly.
- Recipe cards for variants and add-ons are not counted: the base dish composition is what gets written off.
- There is no mobile stocktake with a phone scanner.
- Auto-ordering from a supplier at a minimum stock level is not implemented — the demand forecast exists, automatic purchase orders do not.
- There is no email digest for purchasing; alerts arrive in the team chat and as push notifications.
- EGAIS and Chestny ZNAK are Russian specifics: those views appear only for locations with the country set to Russia; live exchange with the state marking system over API is not connected (submission is semi-manual), and the regulator's EGAIS test contour has not been passed. VetIS (Mercury) works on mocks — the API access key has not been obtained.
Troubleshooting#
Stock was not written off after a sale. The dish has no recipe card, or a variant/add-on was sold — their composition is not included in the write-off.
Stock went negative. By design: the system does not block a sale, and the shortfall is closed by the next delivery.
Cost of goods is empty. Purchase prices for ingredients are not filled in — without them neither food cost nor the menu-engineering matrix can be built.
I do not see the marking or alcohol views. They appear only for a Russian location.
A stocktake cannot be run. Running one is available to the owner and the manager; other roles get read-only access.
No purchasing email arrives. There is no email digest here — shortage and expiry alerts go to the team chat and push.
Related#
- Demand forecast — prep plan, purchase draft and run-out risk
- Loss control — the "consumption above norm" and "purchase price spike" rules
- Menu engineering — what to do with a dish once its cost is known
- Finance — purchases, food cost and gross profit
- Orders — completing an order triggers deduction
- QR menu — dishes and combo sets the recipes are attached to
- Shop — the stock level is visible to the buyer on the storefront: "only a few left" or the exact number
FAQ#
Do all dishes need recipes?#
No. Start with your bestsellers and add the rest gradually. Dishes without recipes simply don't deduct stock.
What happens when an order is cancelled?#
Deduction is tied to order completion: cancelled orders don't touch stock.
Which languages do invoice photos work with?#
The AI handles typical delivery notes in the region's main languages (Georgian, Russian, English and others). You always review the result before confirming.
Can I run inventory across several locations?#
Yes, stock and documents are kept per location — pick the location at the top of the page.