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:

1. Manually — the "Receipt" button: pick products, quantities, prices and the supplier.
2. 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. If a product with the same name is already in your list, the line shows that it goes into that product and converts the quantity to its unit ("2 kg" → 2000 g). Packs such as "3 boxes × 12 l" are recognized and offered as a conversion to litres or millilitres — quantity and price change only when you press "Apply".

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 persons, 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.

A supplier can have several contact persons — each with a role and their own channels. For every contact you pick where the order should be sent — the "Send via" field: e-mail, WhatsApp or Telegram. The list only offers channels that are actually filled in for that person, so an order can never be addressed to nowhere. The chosen channel comes first in the send dialog and is marked with a star; and it decides what the daily auto-order does: e-mail is sent by the system itself, while for a messenger it prepares a ready draft order — nobody but a human can write into a messenger first — and you send it in one click.

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:

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. The price on a tag is the same one the POS charges — the catalog price (the location's own price if set). A different in-store price is set in the stock card with «Set own price…» and a reason: both the tag (marked «*») and the POS use it, the online store keeps the catalog price. This is not the same as order stickers — those are printed by the kitchen, see Kitchen and front-of-house printing.

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 works from the reorder point, not from the forecast: the daily cron builds a purchase order for items below the reorder point (opt-in switch in "Procurement → Alerts"), sends it by e-mail itself and leaves a draft for messenger channels; ordering by forecasted demand does not exist yet.
• The email digest of what to order exists (an opt-in switch with its own address); push notifications are sent on the AWS contour only.
• 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.