Stock & Inventory in Practice in Meztezz

The kitchen and the storeroom are where most restaurants quietly lose money. Not in dramatic ways — in small ones. A recipe that calls for 60 g of paneer when the cook actually plates 90. A case of tomatoes that arrived short and nobody logged it. A bottle of liquor that someone “borrowed” for a staff meal six weeks ago. Stock control isn’t about being suspicious of your team — it’s about making the invisible visible so you can have an honest conversation about it. That’s what this part of Meztezz is for.

This guide walks through the whole stock loop in Meztezz — recipes that tie a menu item to its ingredients, purchase orders and receiving, transfers between storage locations, low-stock alerts, wastage entries, physical counts, and the single most important question for an owner: when does a sold dish actually move stock? It picks up after Setting Up Masters After Installation (units and items were created there) and runs alongside Refunds, Cancellations & Edits After Save — the “ready-KOT becomes wastage, not a stock return” rule from that post is the same rule that anchors this one.

💡 Where this lives in the app. Everything in this post lives under More → Inventory on the terminal, with a few cross-references to More → Inventory → Station Mappings (for station-to-location mapping) and the cloud dashboard’s Reports → Stock tabs (for the owner-side aggregate view at app.meztezz.com). The terminal is where every movement happens; the cloud is a read-only mirror for reporting.

The Walkthrough at a Glance

Part	What you’ll learn
1. The Mental Model — Why Stock Doesn’t Move on Its Own	The four events that ever change a number, and the rule that ties them.
2. Units & Items — The Foundation	Why one unit per item is fine, and the conversion trap to avoid.
3. Storage Locations — Where Stock Actually Sits	Main kitchen, cold storage, bar — and why stations point to them.
4. Recipes — Tying a Dish to Its Ingredients	The single feature that turns “I sold a paneer tikka” into “I used 80 g paneer”.
5. Addons & Modifiers — Stock That Hides in Plain Sight	The half-shot, the extra cheese, the side salad.
6. Purchase Orders & Receiving — How Stock Gets In	Drafting a PO, partial receipts, batch and expiry capture.
7. Transfers Between Locations	Moving 5 kg of onions from cold storage to the tandoor station.
8. The Moment of Truth — When Billing Decrements Stock	Why it’s “ready”, not “sent” — and why that matters at month-end.
9. Wastage — Honest Numbers Beat Tidy Ones	Manual entries, expired-stock write-offs, manager PIN.
10. Physical Counts — The Monthly (or Daily) Reality Check	Partial counts, variance auto-adjustments, what to count when.
11. Low-Stock Alerts — Per Brand and By Raw Material	Three cards on the Alerts tab, what each one answers, and the intentional terminal-vs-cloud divergence on the per-brand view.
12. Stock Movements Report — The Single Source of Truth	Every event in one place, with audit-trail references.
13. Negative Stock — Why It’s Allowed (and What to Do About It)	The “never block service” rule explained.
14. Terminal vs Cloud — Who Owns What	What syncs, what doesn’t, and why the cloud can’t fix a wrong count.
15. Honest List of What Meztezz Doesn’t Do (Yet)	Limits to know before you build a process around them.
16. Habits That Save You Later	Five small disciplines that pay back at audit time.

Part 1 — The Mental Model — Why Stock Doesn’t Move on Its Own

Before any screens, the mental model. There are only four kinds of events that ever change a stock number in Meztezz, and every screen in this post is one of them:

Stock in — you bought it, or you set an opening balance.
Stock out — you sold something whose recipe contains it, or you transferred it elsewhere.
Wastage — it went bad, it was spilt, it was cancelled after the kitchen made it.
Adjustment — you counted the shelf and the number on screen was wrong.

That’s it. No background job changes a stock number. No invoice changes it. No report changes it. Every single shift in a stock number is one of those four events, recorded with a timestamp, a user, a reason, and (in three of the four cases) a paper or screen trail you can hand to an auditor.

This matters because the most common stock complaint — “my stock report is wrong” — is almost always actually one of: a recipe that doesn’t reflect what the kitchen plates, a receipt that nobody logged, a transfer between locations that wasn’t recorded, or a wastage that was hidden to make the numbers look better. The fix is never “the system is broken”. The fix is “which of the four events is missing or wrong”.

Part 2 — Units & Items — The Foundation

You already created items and units during masters setup. A quick refresher on the parts that matter for inventory.

2.1 One Unit per Item — `Settings → Inventory → Manage Units & Conversions`

Every stock-tracked item has one unit of measure. Paneer is in kg. Soft drinks are in bottle or can. Tandoor coal is in kg. The unit applies everywhere that item appears — on the recipe, on the purchase order, on the wastage entry, on the physical count.

The trap is mixing units. If you receive paneer in kg but your recipe calls for g, you have a 1000× error waiting to happen. Pick one unit per item and use it everywhere. If the supplier sells in 5 kg cartons and you want to track cartons, your item’s unit is carton and your recipe converts to cartons (0.016 carton per dish) — not the other way round. Most kitchens find it easier to pick the smaller unit (the one the recipe naturally uses) and let the receiving side multiply up.

💡 A word on unit conversions. Meztezz lets you define conversions (1 kg = 1000 g, 1 carton = 12 pieces) under Settings → Inventory → Manage Units & Conversions. These conversions are used during deduction — when a sale fires, the system converts the recipe ingredient’s unit into the unit each stock row is held in, so a recipe in g correctly draws down stock held in kg. The flip side: if a conversion is missing, the deduction doesn’t silently guess — it fails with “No conversion from X to Y. Add a unit conversion in Settings > Inventory.” So if your recipe and your stock use different units, define the conversion between them first, or that ingredient’s deduction will error out.

2.2 Items That Are Tracked vs Items That Aren’t

Not every menu item needs a recipe. A bottled drink can be its own stock unit — you receive it, you sell it, stock goes down by one. A masala dosa, on the other hand, doesn’t have its own stock at all — what you track is the rice batter, the potato filling, the ghee. The masala dosa is a finished item; the ingredients are raw materials.

The rule of thumb:

Raw materials (paneer, atta, oil, beer bottle, soft drink can) → tracked in stock, appear on POs, appear in recipes.
Finished items with recipes (paneer tikka, dosa, biryani) → not directly tracked; their ingredients are. Selling the dish decrements the ingredients.
Finished items without recipes (a pre-bottled mineral water sold as-is) → also a raw material from the system’s point of view. The “item” and the “stock unit” are the same thing.

If a menu item has no recipe attached, selling it does not decrement any stock. That’s by design — but it’s also the most common source of “why isn’t my stock moving?” tickets. If you expect a sale to move stock, the item needs a recipe. Even a recipe that says “1 dish = 1 unit of itself” is enough.

Part 3 — Storage Locations — Where Stock Actually Sits

A single outlet rarely has a single stockroom. The bar has its own fridge. The cold storage holds the vegetables. The tandoor station has a working tray of ingredients pulled from cold storage at the start of service. Meztezz models this with storage locations.

3.1 The Default Locations — `More → Masters → Locations`

Every new outlet is seeded with four locations: Main Kitchen, Cold Storage, Dry Storage, and Bar. You can rename them, add more, or delete the ones you don’t use. A location is just a named bucket — there’s no hierarchy, no parent-child structure.

Each item carries its current stock per location. A 5 kg paneer row in Cold Storage and a 1 kg paneer row in Main Kitchen are the same item, different shelves. The total — 6 kg — is what an owner-level report shows; the per-location breakdown is what a kitchen-level operator sees.

3.2 Station → Location Mapping — `More → Inventory → Station Mappings`

This is the bit most people miss. Each station (tandoor, chinese, bar, cold-kitchen) is mapped to one storage location. When a KOT for that station is marked ready, the recipe ingredients are deducted from that station’s mapped location — not from a global pool. (Note: the station names are created at Settings → Stations; the location mapping is a separate screen at More → Inventory → Station Mappings.)

The why: if you don’t map stations to locations, the deduction has to guess. The tandoor station should pull from the tandoor’s working tray; the bar should pull from the bar fridge. The mapping is what makes the per-location numbers useful for spotting waste.

The mapping isn’t strictly mandatory — if a station has no mapping, the deduction falls back automatically to whichever location holds the most of that ingredient (a first-expiry, first-out — FEFO — fallback), so service never blocks on a missing mapping. But “whichever location has the most” is rarely the bucket you meant, so your per-location numbers drift. If you only have one location, set every station to point to it and move on. If you have several, map them deliberately; don’t rely on the fallback.

Part 4 — Recipes — Tying a Dish to Its Ingredients

A recipe is the bridge between “a dish was sold” and “these ingredients were used”. Without it, billing has no idea what to subtract. With it, every sale moves the right amount of the right items.

4.1 Creating a Recipe — `More → Inventory → Recipes`

Open the Recipes screen, pick the menu item, and add ingredient lines. Each line is:

Field	What it means
Ingredient	The raw-material item to deduct (must already exist in masters).
Quantity	How much of that ingredient one serving uses, in the ingredient’s unit.
Variant (optional)	If the item has variants (Half / Full plate), each variant can have its own recipe. Leaving variant blank uses the recipe as the default.

Save. From that moment on, every time the kitchen marks a KOT for that item ready, the listed ingredients are subtracted from the mapped station’s location — provided automatic deduction is switched on (see the note below).

💡 Auto-deduction is off by default. A recipe on its own doesn’t move stock. The setting Settings → Inventory → "Automatic Stock Deduction" is what tells Meztezz to deduct recipe ingredients when a KOT is marked ready, and it ships off. Until you turn it on, you can sell paneer tikka all night and the paneer count won’t budge. Switch it on once, per terminal, when you’re ready for stock to follow your recipes.

4.2 Variants and Sizes

Half plates of biryani use less rice than full plates. Define the variants on the item (Half / Full / Family) under masters, then create a separate recipe per variant. The KOT carries the variant ID, so the correct recipe fires automatically.

If you only define a default recipe and someone orders the Half variant, the default recipe fires anyway — you’ll over-deduct. Either define every variant’s recipe, or accept that your stock numbers will run a little low for that item. Most kitchens find that defining variants once is less work than explaining a wonky paneer count every Monday.

4.3 Recipes Are Single-Level

Meztezz recipes are flat: a menu item maps directly to raw materials. We don’t currently support nested recipes (a sub-recipe like “gravy base” that itself has ingredients and is then referenced by every gravy dish). If two dishes share a base, you list the base’s ingredients in both recipes. It’s a little more typing; it keeps the data model honest and the cost calculation transparent.

Part 5 — Addons & Modifiers — Stock That Hides in Plain Sight

Addons are the ones that quietly drain stock if you don’t track them — extra cheese, a half-shot, a side salad, double paneer. Meztezz lets you put recipes on addons too.

5.1 Addon Recipes — `More → Inventory → Recipes → Addons Tab`

Same screen as item recipes, just a different tab. Pick the addon (e.g. Extra Cheese) and add its ingredient lines (e.g. 40 g mozzarella). When a guest orders a Margherita with Extra Cheese, both the Margherita’s recipe and the Extra Cheese’s recipe fire on KOT-ready — the mozzarella line is deducted twice (once from the base, once from the addon).

The non-obvious bit: addons without recipes do not deduct stock, the same as items. A Make it Spicy addon that’s just an instruction to the kitchen doesn’t need a recipe. A Cheese Slice addon does. Walk through your addons list and tag every one as either “instruction-only” or “consumes stock” — the second list needs a recipe.

5.2 Why This Matters in the Numbers

If you don’t recipe your stock-consuming addons, the kitchen genuinely uses the cheese but the system never knows. The result: your physical count finds 600 g of mozzarella missing every week, and nobody can explain it. Addons usually account for 5–15 % of total ingredient flow; un-recipied addons are the single most common cause of “ghost wastage” in the numbers.

Part 6 — Purchase Orders & Receiving — How Stock Gets In

You can’t bill what you haven’t bought. Meztezz models incoming stock through Purchase Orders — drafted, ordered, received (whole or partially), closed.

6.1 Drafting a PO — `More → Inventory → Purchase Orders → New`

Pick a supplier (or add one inline), pick a delivery location, and add line items. Each line is:

Field	What it means
Item	The raw material you’re buying.
Quantity	How much you’re ordering, in the item’s unit.
Rate	The per-unit cost you and the supplier agreed on.
Tax %	GST/VAT on the line, if applicable (optional).

A discount, if the supplier offers one, is applied once at the order level (in the totals section), not per line.

Save the draft. The status starts as draft — nothing has hit stock yet, and the supplier doesn’t owe you anything.

When the order is actually placed with the supplier (a phone call, a WhatsApp message, a sent email), move it to submitted. This is the state where the PO is “live” — you’re expecting delivery.

6.2 Receiving — Partial or Full

When the supplier delivers, open the PO and tap Receive. The wizard captures an invoice number (optional), an invoice date (required), and a storage location for the delivery, then lists each ordered line. The fields per received line:

Received quantity — what really came (can be less than ordered if the supplier short-shipped).
Batch number (optional) — for items you track by batch.
Expiry date (optional) — useful for dairy, baked goods, packaged items with shelf life.

The per-unit cost and tax come from the PO line you drafted — they’re applied as-is at receipt time, not re-entered here. (If the supplier’s invoice differs from what you ordered, that reconciliation lives in the supplier ledger, covered in 6.3.)

Hit Confirm Receipt. Stock increases immediately on confirm — the received quantity is added to the delivery location’s stock for that item, and a stock_in movement is recorded with the supplier, batch and expiry attached.

If only some lines arrived, save the partial receipt and leave the PO in partial. You can receive the rest on a later date against the same PO (a submitted or partial PO can keep receiving), until everything either arrives or is short-closed manually.

💡 No separate GRN — the receipt is the GRN. In some POS systems “GRN” is a distinct screen separate from the PO. In Meztezz the receipt-against-PO action is the GRN. The paper slip you print at receipt time is what your storeroom files; the same row is what your accountant uses to match against the supplier’s invoice. One concept, one screen.

6.3 What Receiving Does to Your Supplier Balance

Receiving isn’t only a stock event — it’s also an accounts-payable event. On every confirmed receipt, Meztezz increases that supplier’s payable balance by the value of what arrived, and posts the receipt to the supplier ledger — a running, chronological “you owe / you paid” statement per supplier. You reach it from the “View supplier ledger” link inside any purchase order, and it answers the owner’s real question: how much do I currently owe this vendor?

When you pay a supplier, record it under supplier payments: the payment is allocated against outstanding receipts oldest-first (FIFO), carries its own payment number (SP-000001, …), and is gated behind a manager PIN. If a delivery was short or defective, a debit note against the receipt reduces what you owe. The cached payable balance is recomputed on every one of these writes, so the number you see is always current.

What this is not is a full general ledger. Meztezz tracks what you owe each supplier and what you’ve paid them; it does not replace your accountant’s books for tax filing or P&L. Think of it as a clean vendor statement, not a complete accounting system.

Part 7 — Transfers Between Locations

Stock rarely arrives where it’s used. The cold storage gets the 25 kg sack of onions on Monday; the tandoor station pulls 2 kg out at the start of every evening service. That pull is a transfer.

7.1 Recording a Transfer — `More → Inventory → Stock Items`

There’s no separate Transfers screen. A transfer is a per-item action: open Stock Items, find the item’s row, and tap the Transfer stock button on it. A dialog opens for that one item — you pick the source location, the destination location, and the quantity, then save. One item per transfer; if you’re moving three things between the same two shelves, that’s three transfers. On save, one transfer movement is recorded, stamped with both the source and destination location; the source’s stock drops and the destination’s rises by the same amount. In the Movements report that single event is shown as a matched pair — a transfer_out line on the source and a transfer_in line on the destination — so it reads naturally per location. Either way, the total stock on hand doesn’t change; only where it sits does.

There’s no approval step, no in-transit state. The assumption is that whoever is recording the transfer is also physically moving it, or has just received it. If your operation needs a two-step despatched / received dance, log it as two transfers (out today, in tomorrow) and accept the in-transit gap.

The dialog does enforce one limit: you can’t transfer more than the source location actually holds. Ask for more than is on hand there and it stops you with “Insufficient stock at source location”. Transfers move what’s there; they can’t conjure stock that isn’t.

7.2 What Transfers Are Not

Transfers don’t cross outlets. Stock can move freely between locations within an outlet; it cannot move between outlets. If you have two outlets and the bar at outlet B is out of soda, the workflow is “receive new stock at outlet B”, not “transfer from outlet A”. Inter-outlet transfer is on the roadmap; it isn’t shipped today.
Transfers are not adjustments. If 5 kg of paneer is missing and you don’t know why, that’s a physical count or a wastage entry, not a transfer. Transfers move stock; they don’t lose it.

Part 8 — The Moment of Truth — When Billing Decrements Stock

This is the single most asked question about Meztezz inventory, and the answer is non-obvious enough that it deserves its own part.

8.1 Stock Decrements at “Ready”, Not at “Sent”

When the cashier sends a KOT to the kitchen (you read about this in Taking Orders & Sending to the Kitchen), the KOT moves into the pending state. No stock is deducted yet. The food hasn’t been made.

When the kitchen taps Mark Ready on the KDS (or the station’s confirmation slip is processed), the KOT moves to ready. This is the moment stock is deducted — if automatic deduction is enabled. With the Settings → Inventory → "Automatic Stock Deduction" switch on (it’s off by default — see Part 4.1), the recipe ingredients for every line on that KOT are subtracted from the station’s mapped storage location, and a stock_out movement is written for each ingredient, with the KOT ID as the reference. With the switch off, marking ready changes nothing in stock — recipes and station mappings sit ready, but no deduction fires until you turn the setting on.

Subsequent state changes (served, completed, settled, bill printed) do not move stock again. Stock fires exactly once per KOT, at the ready transition.

8.2 Why “Ready” and Not “Sent”

The honest reason: a KOT that’s pending might still get cancelled before the kitchen starts cooking — guest changed their mind, table walked out, cashier hit the wrong button. If we deducted at sent, every such cancel would have to roll stock back, which is fiddly and prone to drift. Deducting at ready means stock changes only after a human in the kitchen has physically committed to the ingredients.

The cost: a KOT sitting in pending looks “free” from a stock point of view, even though the order has been taken. If you want to know “what’s already committed but not yet cooked”, look at the active-orders screen, not the stock screen.

8.3 Cancels After Ready Become Wastage

If a KOT is cancelled while still pending, stock is restored — nothing was deducted, nothing to restore. If a KOT is cancelled after ready, stock is not put back — instead, a wastage record is created for the cooked food. This is the “no phantom stock returns” rule, and it’s covered in more depth in Refunds, Cancellations & Edits After Save → Part 10. The rationale is the same here: the ingredients are physically gone, and pretending otherwise would lie to your stock report.

Part 9 — Wastage — Honest Numbers Beat Tidy Ones

Wastage exists for everything that leaves stock without being sold — spoilt produce, dropped trays, expired packaged items, food the chef wasn’t happy with, the staff meal that came out of the kitchen pantry.

9.1 Recording Wastage — `More → Inventory → Food Wastage`

Open Food Wastage and tap Record Food Wastage. Pick the item, the quantity, the category, and (optionally) a reason and a note. The seeded categories are Spoilage, Expired, Breakage/Spillage, Pest/Contamination, Storage Failure and Other — add your own under the Categories sub-screen. Save.

Recording wastage is a two-step flow, by design. Saving the entry creates a record in pending status — it does not deduct stock yet. Stock only moves when a manager approves the record: approval (which requires a manager PIN) is what writes the wastage movement against the chosen location and pulls the quantity out of stock. The Wastage Report (More → Reports → Stock → Wastage) groups every entry by category, item and date.

💡 Who can record, who can approve. The two steps use two different permissions. Recording the entry needs the inventory:adjust permission — that’s all it takes to log a pending wastage, and nothing leaves stock at that point. Deducting it needs the wastage:approve permission and a manager PIN. The reason is plain operational: wastage is the easiest way to hide a missing item, so the action that actually removes stock is the one gated behind a manager keystroke, with the manager’s name on the record.

9.2 Expired-Stock Wastage

For items with batch tracking switched on, Meztezz records each delivery as its own dated batch and watches every batch in the background, so expiry is tracked per batch on the shelf — not lumped together per receipt. When making a dish would consume an expired batch, the Block sales on expired stock setting (on by default) holds the KOT until a manager resolves it; on resolve, that batch is written off as wastage (category Expired, tagged as an expired-batch resolution) and the order goes through. With the block turned off, the expired stock is used and counted toward an “Expired consumed today” figure instead. Either way the wastage carries an audit trail of who set the expiry and who resolved it.

This whole mechanism — per-batch tracking, the oldest-expiry-first (FEFO) depletion order, the background alert sweep, and the food and liquor sale-blocks — has its own full walkthrough in Batch & Expiry Tracking in Meztezz. Batch tracking is opt-in per item, so anything you haven’t switched it on for still behaves as a single fungible total; a manual count remains the right tool for spotting expiry on items you don’t batch-track.

9.3 Wastage From Ready-KOT Cancels

The third wastage source is automatic and explained in Part 8: a KOT cancelled after ready writes a wastage movement for the cooked food. These show up in the same Wastage Report (More → Reports → Stock → Wastage) under a KOT cancelled reason (the entry reads “Wastage – KOT cancelled: …” with the cancellation reason you typed). If you see a spike there, the question is usually for the kitchen (“why are we marking ready and then pulling back?”), not the cashier.

Part 10 — Physical Counts — The Monthly (or Daily) Reality Check

No recipe is perfect. No kitchen is perfect. Every system that tracks stock by deduction eventually drifts from physical reality. The reality check is a physical count — someone walks the shelf with a tablet and types in what’s actually there.

10.1 Starting a Count — `More → Inventory → Physical Count`

Open Food Physical Count, pick the location, and tap Start Count. Meztezz opens a count session: a list of every item that has any stock recorded at that location, with the system quantity on one side and a blank field for the counted quantity on the other.

You don’t have to count everything. Skip the items you’re not counting and they stay untouched — only the lines you fill in will produce variances. This is what “partial count” means in practice: it’s not a separate mode, it’s just don’t fill in the lines you didn’t count.

10.2 Recording the Variance

For each line you count, type in the actual physical quantity. When you’ve entered your counts, move to the Review step: it lays out the variance (counted − system) for every counted line, in both quantity and value (using the item’s most recent cost), so you can sanity-check the big movers before committing. A positive variance means you found more than the system expected; a negative one means stock is missing. When you’re happy, tap Complete Count.

On completion, Meztezz writes one adjustment movement per counted line where the variance is non-zero. The reason is set to Physical count. The system quantity is now equal to the counted quantity — until the next sale moves it.

You also get a one-page summary on screen: total items counted, total variance value (positive = found stock, negative = missing), top five gainers and losers. Print or screenshot it for the file.

10.3 What to Count, How Often

There’s no rule in the app; this is operational habit. The pattern most Meztezz restaurants settle into:

Daily: high-value or high-loss items only (liquor, premium proteins, premium dairy). Five-minute count, big payoff.
Weekly: the full bar inventory and the cold storage. Twenty to thirty minutes.
Monthly: every location, every item. An hour or two. This is the count that grounds your month-end financial picture.

The cost of not counting is invisible — your reports look fine, right up until you do a count and find a 12 % variance built up over three months.

Part 11 — Low-Stock Alerts — Per Brand and By Raw Material

Every item carries a minimum stock number (set at More → Inventory → Items → Edit → Minimum Stock). When stock falls below this, the item shows up in the Low Stock list.

Two things share the name “Alerts” on the terminal, and they’re not the same. The quick More → Inventory → Alerts sheet is a flat, per-item list of what’s currently low or expiring — handy for a glance during service. The three-card layout — per-brand low stock, low stock rolled up by raw material, and expiring items — lives in the report at More → Reports → Stock → Alerts (and mirrors to the cloud at Reports → Stock → Alerts). The three cards described below are that report view; read the card that matches the question you’re asking.

11.1 Per-Brand Low Stock — On the Terminal

The terminal lists every item where any single location is below the minimum. If you keep 10 kg of paneer in Cold Storage and 1 kg working at the Tandoor station, and the minimum is 2 kg, the tandoor row appears in the Low Stock list — even though you’ve got 11 kg overall. The terminal cares about the working bucket, because that’s the bucket service runs out of.

11.2 Per-Brand Low Stock — On the Cloud Dashboard — `Reports → Stock → Alerts`

The cloud aggregates stock across locations per item, then compares against the minimum. The same paneer (1 kg + 10 kg) shows as 11 kg, well above the 2 kg minimum, and is not flagged. The cloud cares about the owner-level question: “is the outlet about to run out of paneer entirely?”

Both views are correct for who’s reading them. A station-level operator wants to know “should I top up the tandoor’s working tray now?” — the terminal answers that. An owner running three outlets wants to know “do I need to send a buying order tonight?” — the cloud answers that. This is an intentional divergence between terminal and cloud reporting — it’s not a bug.

11.3 Low Stock by Raw Material — The Rolled-Up View (Terminal AND Cloud)

The two cards above are at the brand level — one row per stock item (Amul Butter 500 g, Verka Butter 500 g, …). That answers “which SKU do I reorder?” but not “do I have enough butter overall?” The third card answers the second question.

For every raw material, the system sums the current stock across all its linked brands and compares against the sum of their minimum-stock numbers. If the total falls below the combined minimum, the raw material appears in the rolled-up list, with the deficit, the unit, and the count of brands that contribute to it. This card behaves the same on both the terminal and the cloud — same math, same threshold. The terminal-vs-cloud divergence in 11.1/11.2 applies only to the per-brand card; the rolled-up card is in lockstep.

Why both cards: a brand can be flagged in the per-brand card while its raw material rollup still looks fine (other brands of the same ingredient are well-stocked). And the opposite — a raw material can be flagged in the rollup even when no individual brand is below its minimum (each brand is just above its own minimum, but together they no longer cover the kitchen’s expected throughput).

💡 Which card to read. If you’re placing a purchase order, read the per-brand card — it names the SKU and gives a suggested reorder quantity (top the item back up to roughly twice its minimum). The separate auto-reorder feature, which can draft purchase orders for you, uses a similar top-up formula with a configurable multiplier, so the two are close but not always identical to the paisa. If you’re asking the chef-level question “is the kitchen going to run out of an ingredient tonight, regardless of brand?”, read the by raw material card. Separately, the orange badge on the More button on the terminal reflects your unread stock alerts — low-stock, expiring and drift alerts together — so the count there is the broader “things need your attention” signal, not any single card.

The Alerts tab also includes an Expiring Items card — stock with a recorded expiry date inside the warning horizon (configurable, default 30 days). The card itself is informational — it’s the warning, not the gate. The actual gate is a separate setting, Block sales on expired stock (on by default), which holds a KOT that would consume an already-expired batch until a manager clears it; see Batch & Expiry Tracking for how that works. PDF and Excel exports of the inventory report include all three cards as separate pages / sheets.

Part 12 — Stock Movements Report — The Single Source of Truth

If you only ever read one inventory report, read this one. More → Reports → Stock → Movements (terminal) and Reports → Stock → Movements (cloud) both list every single event that has ever moved stock, in chronological order, with the type, reason, quantity, location, user and reference. (There’s also a live More → Inventory → Movements list for a quick in-the-moment glance; the report under Reports is the one with the full window and the KPI totals below.)

The report columns:

Column	What it shows
Date / Time	When the movement was recorded.
Item	The raw material whose stock moved.
Type	One of `stock_in`, `stock_out`, `adjustment`, `transfer` or `wastage` — plus `bottle_open` when a sealed liquor bottle is auto-opened for a pour. A purchase is recorded as a `stock_in` and a sale as a `stock_out`; the finer cause lives in the Reason column, not here.
Quantity	Signed — negative for out, positive for in.
Unit Cost / Total	The per-unit cost and line value of the movement.
Reason	The specific cause — purchase, sale (KOT consumption), transfer_out, physical_count, expired stock, manual adjustment.
By	Who recorded it.

The location and the reference (the originating PO / KOT / count / wastage ID — your audit trail) aren’t columns in this report; they live one tap deeper, in the live More → Inventory → Movements list, where each row expands to show where it happened and what record it came from.

The terminal report caps at 1000 rows per outlet, which is plenty for a single outlet’s daily or weekly view. The cloud scales the cap for multi-outlet orgs (up to 5000 rows across all outlets). KPI totals (total in, total out, total wastage value) are always computed over the full window, never capped, so the headline numbers stay correct even when the row list is windowed.

This report is the primary tool for answering any “why doesn’t my stock match?” question. Walk through the movements for the item in question, location by location, and the missing or extra entry will usually announce itself.

Part 13 — Negative Stock — Why It’s Allowed (and What to Do About It)

Sooner or later, you’ll see a stock number go negative. A line showing -1.2 kg paneer. This is allowed by design, and the reason is plain: food service never blocks on stock. If a guest orders a paneer tikka and the system says paneer is at zero, Meztezz still lets the order go through. The kitchen knows whether there’s paneer in the kitchen; the system shouldn’t override them.

💡 Liquor is the one exception. Bar/liquor items are excise-regulated, so they are the single place Meztezz does block. If a KOT containing a liquor item would drive bar stock below zero, the order is stopped at send time with a hard error showing the shortfall (and a ”≈ open N more bottles” hint) — there is no manager override. This block is enforced on the terminal and surfaces to whoever took the order: a waiter sending the ticket from the captain-app sees the same stop. The fix is to restock the bar, reduce the quantity, or remove the line. Food never blocks this way; liquor always does.

Negative stock means one of three things, and the diagnosis is usually quick:

A receipt is missing. Stock was used (decremented by sales) but the corresponding receipt was never logged. Find the supplier’s invoice for the missing batch and record the receipt with the correct date.
A recipe is wrong. The recipe is over-deducting — saying 100 g where the kitchen plates 80 g. Compare the recipe to a fresh weigh-and-plate test in the kitchen and fix it.
A transfer wasn’t recorded. Stock physically arrived at a station but wasn’t transferred in the system. Record the transfer retroactively.

The cloud dashboard displays negative values without flagging them as errors. They are surfaced exactly as they are; it’s up to the owner and the storeroom to chase them down. A weekly review of the Stock Movements report for negative-going items is the practical habit.

Part 14 — Terminal vs Cloud — Who Owns What

A quick truth-in-advertising section, because new owners sometimes expect to manage stock from the cloud and are surprised when they can’t.

The terminal owns every inventory action. Recipes are created on the terminal. Purchase orders are drafted and received on the terminal. Transfers are recorded on the terminal. Physical counts happen on the terminal. Wastage is logged on the terminal. Stock decrements (on KOT-ready) happen on the terminal. The terminal is the system of record.

The cloud is a read-only mirror. Every movement syncs up to app.meztezz.com and is queryable through the dashboard’s Reports → Stock tabs — a deeper set than the terminal’s, including Current Stock, Stock Summary, Movements, Wastage, Alerts, Consumption, Food Cost and more (purchases get their own top-level report group). The cloud aggregates across outlets, gives the owner a single-pane view, and never originates a movement. You can’t fix a stock number from the cloud — you have to do it on the terminal, and let the correction sync up.

This is not a temporary limitation; it’s the architectural rule of the whole product. The terminal must work offline (the internet goes down; lunch service does not). Stock is operational data. Operational data is owned by the terminal. The cloud’s job is reporting, not control.

Part 15 — Honest List of What Meztezz Doesn’t Do (Yet)

This list is here so you don’t build a process around something that isn’t there. If any of these is critical for you, tell us — many are on the roadmap, and the order is influenced by what users actually ask for.

No inter-outlet transfers. Stock cannot move between outlets in the system. If you need to balance stock across outlets, the workflow today is “wastage out at the source, stock-in at the destination”, which loses the linkage.
No nested / sub-recipes. A “gravy base” used by ten dishes can’t be a recipe of its own. You list the gravy’s ingredients in each dish’s recipe.
No purchase-vs-sales unit split. Each stock item is held in one unit. Recipes can use a different unit as long as you’ve defined the conversion (Settings → Inventory → Manage Units & Conversions) — the deduction uses it. What’s missing is a built-in “buy in cartons, sell in pieces” split that tracks both at once; you still pick the item’s single stocked unit and rely on conversions to bridge the recipe side.
Recipe costing doesn’t follow specific batches. Stock can now be tracked per batch, with oldest-expiry-first (FEFO) depletion — the system knows whether today’s deduction came from Monday’s batch or Wednesday’s (see Batch & Expiry Tracking). What still uses an average is dish costing: a recipe’s costed value reads each item’s running average cost, not the specific cost of the batch that was depleted, so the costed figure won’t swing batch-to-batch even though the quantity does.
No return-to-vendor (RTV). If a supplier sent something defective and you’re sending it back, the system doesn’t have a first-class RTV flow. The practical workaround is a wastage entry with reason “returned to vendor” plus a paper credit note from the supplier.
No stock split / repack movement. “I split this 5 kg pack into 50 × 100 g pouches” isn’t a recordable event; the system still sees 5 kg.
No full general ledger. Meztezz does track per-supplier payables — a vendor ledger, supplier payments (FIFO-allocated, manager-PIN gated) and debit notes (see Part 6.3). What it doesn’t do is replace your accountant’s books: there’s no P&L, no tax-filing ledger, no chart of accounts. It’s a clean vendor statement, not an accounting suite.
No formal stock period open/close. Closing the day closes the financial day; it doesn’t close an inventory period. Physical counts are the practical way to draw a line.

If any of these is on your roadmap-for-Meztezz wishlist, write us — Part 16 has the address.

Part 16 — Habits That Save You Later

Five small disciplines that the restaurants with the cleanest stock numbers all share. None of them are big; together they’re the difference.

Recipe every stock-consuming addon. Walk your addons list this week. Tag each as “instruction” or “stock”. For every “stock” one, add a recipe. This single exercise usually cuts ghost wastage by half.
Log the receipt the day the stock arrives. Not tomorrow, not on the weekend. The cost of a one-day-old receipt is small; the cost of a two-week-old receipt is a stock count you can’t explain.
Daily count on the top five high-value items. Liquor and premium proteins. Five minutes. Catches both honest drift and the rarer dishonest patterns early enough to ask a soft question instead of an awkward one.
Review Stock Movements weekly for anything trending negative. Sort the movements by item, watch for items whose running total dips below zero. Each one is a process leak — fix it while the memory of the week is still fresh.
Print the Wastage Report at the end of every week and discuss it with the kitchen. Not to assign blame — to ask “is anything in our prep flow producing this consistently?” The kitchen usually knows the answer and is just waiting to be asked.

If any of this didn’t behave the way the guide describes — a recipe that fires the wrong quantity, a receipt that didn’t update stock, a low-stock alert that’s flagging the wrong row, a wastage entry that won’t accept your PIN, or a negative stock number you can’t trace — drop us a line at bazimat@gmail.com or contact us. Tell us which Part you’re on and what you’re seeing; we’ll usually have you sorted in a single back-and-forth.

Once stock is moving honestly, the next chapter is the one most owners ask about long before they’re ready for it: Discounts, Offers, Coupons & Happy Hours — every discount mechanism, the stacking rules, and how each one shows up on the bill and in your reports. We’ll publish that one next. 🎉