What's New

On some menus a deal showed up four to six times in the POS search and product grid — leftovers from past menu edits multiplying the same deal. Worse: selecting it clicked every duplicate card at once, so one tap landed as a quantity of four or six in the cart.

🎯 Fixed Both Ways: • The deals list now collapses to one row per deal, keeping the original entry that holds its price • The add-to-cart trigger fires exactly once regardless of what the grid renders — belt and braces.

Result: The cashier sees each deal once, and the customer gets charged for what was actually ordered.

“Press Refresh Session” is what staff are told when a screen shows something stale — but until now it only rebuilt part of the picture. Dozens of cached lists (payment methods, account codes, order notes, zone maps and more) kept serving the old data anyway, and some were cached forever with no way to clear them at all.

🗂️ One Inventory: • Everything the system caches is now registered in one place — 26 cache families across 40+ screens — each with a defined way to be cleared • An automated check refuses any future cache that doesn't declare one.

🔄 Refresh Session Clears It All: • One press now resets every cached list for your business, branch and user — including the variant-heavy ones that previously couldn't be enumerated • Deliberately scoped: caches shared by every business on the platform are not dumpable by a single cashier.

♾️ No More Forever Caches: • Every “cached forever” entry in the application — the last being the city zone/area maps used for delivery geofencing — now expires and is clearable like everything else.

Result: When a screen looks stale, Refresh Session fixes it — every time, for every screen.

One branch could not take payments for most of a day. Its rounding accounts existed but carried the wrong account type, inherited from a mistyped parent — the validator rejected them on every order, and each rejection minted yet another unusable account: 45 duplicate “Rounding Gain” heads in eight hours.

🩹 Fixable From the UI: • Saving an account head now realigns its type with its parent and cascades the correction down the entire subtree — previously a mistyped branch was literally unfixable from the screen • The response tells you exactly what changed, because re-typing moves balances between the P&L and the balance sheet.

🛡️ Self-Healing: • Auto-created rounding heads are now typed for their purpose — Income for gains, Expense for losses — never blindly inherited from the parent • Charts with non-standard naming now find a valid parent by type instead of failing outright.

🧾 Voucher Entry Crash Fixed: • Businesses that restrict voucher account heads by position no longer crash on voucher types that were never configured — an unconfigured type simply applies no restriction • Changing these settings now refreshes all four voucher types immediately instead of serving a stale list for an hour.

Result: A wrongly-typed account can no longer stop a branch from taking money — and you can now fix one yourself.

Marking an order as due was dropping its VAT on the floor. The tax never reached the order record, so the accounting voucher found nothing to credit and absorbed the whole amount as a rounding gain — income overstated, VAT payable understated. On one affected business this was 2,310 orders and over 647,000 in unrecorded VAT in under two weeks.

✅ Fixed Going Forward: • A due order now stamps its full financial block — VAT included — before the voucher posts, exactly like a paid order • Inclusive-tax menus are handled with the same extraction the paid path uses.

🔧 And Backwards: • A repair command restates the historic vouchers, deriving each order's missing tax from two independent sources — the order's own arithmetic and the mis-posted residual — and only acts when both agree to the paisa • Anything that disagrees is tabled for human review and left untouched • Safe to re-run: already-repaired vouchers drop out of scope automatically.

Result: Your VAT liability is right again — for every due order from now on, and for the ones already posted.

Some businesses keep their books on FIFO or LIFO but run kitchen consumption on average cost. For them, the cost readers were writing consumption records one way and reading them back another — so whole consumption lines costed out at zero, quietly understating cost of sales.

🔎 What Changed: • Cost records are now recognised by what they are, not by which method the books use — an average-cost record is read as one even in a FIFO business • The cost-propagation engine now considers both your book method and your consumption method, so mixed businesses are no longer silently skipped.

🛡️ Wider Safety Net: • The double-mapping detection that FIFO and LIFO businesses always had now covers average-cost businesses too • A verification branch that computed a mismatch but never actually compared it now raises the alarm it was built for.

Result: Cost of sales reflects what the kitchen actually consumed, whichever combination of costing methods you run.

The department stock report still lumped real losses and simple counting corrections into one -Wastage column. The store-level report separated them months ago; the department view now matches.

🗑️ -Wastage vs -Variance: • -Wastage is stock that physically left — spoiled, burnt, broken, stolen, given away • -Variance is a correction where nothing was actually lost — a miscount, a data-entry slip, a unit mix-up • Note that your department -Wastage figures will look lower than before, because corrections have moved out of that column into -Variance. Nothing is missing — the two still add up to the old number.

➕➖ New Net Variance Column (both reports): • Corrections up minus corrections down, so a +10 miscount cancelled by a -4 reads as 6 • It shows the net effect of your counting corrections over the period • Wastage never enters this figure — it is a real loss, not a correction • Goes negative when corrections wrote stock down overall, which is exactly what you want to see.

Result: You can finally tell a kitchen that wastes too much from one that simply counts badly — per department.

Twice in one morning, background-job congestion on the shared queue table caused failed logins and rolled-back POS payments — the payment itself was fine, but a notification job that could not be queued took the whole transaction down with it.

🔐 Logins: • The session-activity job that ran on nearly every request now only runs at most every 15 minutes per session, cutting roughly 40 queued jobs a minute down to a trickle • If queuing fails, it is logged and ignored — a queue problem can never fail a login • Also fixed a crash at login for sessions with no expiry date set.

💳 POS Payments: • A WhatsApp or SMS notification that cannot be queued no longer rolls back the payment — the notification stays pending for the next pass and the sale completes.

📄 Purchase Orders: • Fixed a listing endpoint that could produce a blank-page error instead of a proper message when something went wrong.

Result: Background congestion stays in the background instead of stopping the counter.

A review across every live branch found 247 of 1,247 branches could not post a rounding adjustment correctly — the rounding accounts were either missing, pointing at an account that no longer exists, or pointing at the wrong type of account entirely.

💸 The Worst Case: • Both rounding accounts on one branch pointed at the cash till, so every rounding difference was recorded as real cash coming in or out.

🩹 Self-Healing From Now On: • The system now verifies the account before using it — it must be a live, usable Income account for gains and Expense account for losses • A bad setting is replaced automatically and logged, instead of being trusted forever • A setup routine that used to copy one branch's setting to all its siblings without checking it — the way one wrong account spread to 42 branches — now validates first.

🔁 Existing Branches Repaired: • A one-time repair fixes every affected branch, preferring accounts you already have before creating anything new, and respecting per-branch account setups • Everything it changes is backed up and reversible.

Result: Rounding differences stop landing in your cash and start landing where an accountant expects them.

Every delivery-partner order was leaving its accounting voucher short by exactly the commission amount. The bill total is stored after commission is deducted, but sales were being recorded at the full gross figure — and nothing recorded the commission itself.

⚠️ Where It Was Going: • The gap was being absorbed by whatever the branch's rounding-loss account pointed at • On one branch that was the cash till — so commission quietly inflated recorded cash • Across four businesses this affected 7,996 vouchers.

🧾 Commission Is Now a Real Expense: • Sales stay at their gross value and the commission is posted as a distribution expense, which is how it should be treated when the restaurant is the principal in the sale • It uses the commission account set on the platform, or one created for the purpose — never a general charges account.

🏦 Each Platform Gets Its Own Receivable: • Previously platform money owed was netted against the shared walk-in customer account, so "how much has this platform not paid us yet?" was unanswerable • Every platform now has its own receivable account under a proper control head.

🔧 Existing Records: • A backfill is available to correct historic vouchers, and the nightly accounting health check now flags any branch whose rounding or commission accounts are of the wrong type.

Result: Your P&L shows what delivery platforms actually cost you — and your cash balance stops absorbing it.

A full audit of moving-average costing found whole editing paths that moved stock but never touched the average cost — so your cost of sales and stock valuation slowly drifted away from reality. All are wired now.

💰 Math Core: • When stock was sold before it was received, the later receipt was only ever costed against one oversold entry and its coverage silently collapsed to nothing • Now the receipt is applied oldest-first until it is exhausted • A real average cost was being written onto negative stock, permanently skewing the next restock's blend — negative stock now correctly carries no average • Two cost edits at the same moment could lose one silently.

🔁 Edit Paths Now Recost: • Flipping a purchase between pending and received — in either direction, including the dedicated status button • Lines added during an edit of an already-received purchase, which were skipped entirely • Plus-side stock adjustment edits • Purchase return edits — changed lines, new lines and deleted lines.

📍 One New Refusal: • Changing a stock adjustment's location while editing is now blocked — it used to strand the original location's stock with nothing reversing it.

🌙 Safety Net Widened: • The nightly checks previously skipped average-cost businesses altogether — they are now covered.

Result: Stock valuation and cost of sales stay accurate no matter how much you edit after the fact.

Purchase returns are in daily use, and editing one could quietly put your stock out.

📦 Adding a Product While Editing: • The full quantity left your stock, but only the first purchase batch was credited • New products added during an edit now spread across every batch they came from, exactly like creating a return does.

🚫 Returning More Than You Bought: • Increasing a return line past what the original purchase can still cover is now refused with a clear message, instead of pushing the batch into impossible territory.

🧮 Removed Lines: • Lines you deleted during an edit were never subtracted from the recalculated total • Fixed.

Result: Return edits leave your stock and your supplier balance where they should be.

When stock drifted in the past, tracing it was a dead end — some code paths changed balances without leaving any record. Every one of them has been found and wired into the stock history journal.

📝 Every Change Recorded: • All 99 places that touch a stock balance were reviewed; every real writer now journals what changed, why and from where • That includes the rebuild and reconciliation tools — previously the very tools used to investigate drift were erasing the trail while they ran • An automated guard now blocks any future code from changing a balance without journaling it.

🌙 Two New Nightly Checks: • Balance vs batches — your stock figure must equal what remains across its purchase batches, allowing for deliberate overselling • Balance vs journal — the live figure must match the last recorded change, which catches an untracked edit within a day instead of months later • Both ride the existing nightly audit and its email report.

🧱 Groundwork: • A new single-writer stock engine has been built and proven against every core flow — receiving, transfers, adjustments, wastage, production, consumption and returns — so a stock move can never again be half-applied. It is being switched on gradually per business, and is off by default.

Result: If a stock number ever moves unexpectedly, you find out the next morning — with a record of what did it.