What's New

The Cancelled block on the register summary only counted orders punched on that branch’s own registers. An order cancelled by the call centre, or one with no register at all, was left out of the count entirely — one branch closed a day with 7 voided orders and its slip said 0 / 0, while the void-item tables printed right underneath listed all seven.

🧾 Every Cancellation of the Branch: • Fully void and partially void orders are counted by branch and business day, whichever register or call centre punched them • A cashier’s own close still narrows to that register, and a user-filtered report narrows to that user • Fully void is an order cancelled outright; partially void is a paid or due order with lines taken off, valued line by line

🍽️ Made vs Un-Made Food: • Under both Fully void and Partially void, the slip now prints a made food and an un-made food row with the order count and amount, using the answer the cashier gave in the void dialog • A cancellation recorded without an answer (app or API voids, older orders) prints under un-made, the dialog’s own default • Both the classic and the new slip layout show the split

Result: The Cancelled figures on the day-close slip finally agree with the void tables under them.

Alert, re-order and maximum quantity on an ingredient were being rounded to whole units — 2.5 kg became 3 — while the alert level and location-wise levels kept theirs.

🔢 To Your Quantity Precision: • All three levels store decimals and follow the business Quantity Precision setting: input steps match it (0.01 at precision 2), saves round to it, and the product list shows it • Stored values render at the precision without trailing zeros, so opening an unchanged ingredient no longer trips the browser’s "enter a multiple of" check

Result: Par levels in kilos and litres, not whole units.

At one branch every bill opened at 0% GST while the dropdown showed Cash at 16% — the branch’s flagged default payment method was inactive, so the tax lookup found nothing. Re-selecting Cash fixed it, which is why it went unnoticed.

🎯 Tax Follows the Method You See: • The opening figure and every reprice now share one rule: the printed method, else the active default, else the method the dropdown pre-selects • The same rule covers due settlements, which had been repricing those orders at 0%

Result: What the dropdown shows is what the bill is taxed at.

A cashier typed the letter o as the VAT percent and the save crashed with a database error. Every free-typed charge field on the POS is now checked before it goes anywhere.

🛡️ One Guard, Every Field: • VAT/GST percent (capped at 100), service charges, delivery charges, decor charges, and the discount and customer-discount inputs — non-numeric and negative values are refused with a clear message • Blank still means clear the charge; an unknown order is refused instead of updating nothing • The VAT input is a proper number field with a decimal keypad on tablets

Result: A typo in a charge field gets a message, not a crash.

Settling a platform order’s due was quietly re-deriving the sale from a bare order row: platform commission became 0, round-off became 0, and tax followed the settling payment method. 523 orders on one platform lost their commission leg and Rs 23.5k landed on the rounding head.

📌 Components Are Fixed at Mark-Due: • A due collection restates subtotal, discounts, tax, charges, commission and round-off from the order it settles; the explicit third-party recompute keeps precedence where it applies

🩹 Repair Command for the Affected Orders: • payments:restore-due-settlement-components restores the three columns from the audit trail and re-posts the sale and payment vouchers so the commission returns and the residual clears; idempotent, with a dry run

⚙️ Quiet Reliability Fixes: • The FBR retry job no longer fails with a strict-SQL-mode error on the queue • A replayed payment deadlock now logs as a warning instead of reading like a lost payment

Result: A due settles for what was owed when it was marked due — commission, rounding and tax intact.

Customers were told a due was paid while the order stayed due. The customer-wise settlement screen could skip an order and still say Action Done Successfully — three separate ways. All three are closed.

🚫 No More Green Toaster Over a Due Order: • An order that cannot settle is now named in the response with its reason; the orders that did settle stay committed • In amount mode a failed order’s share is reported as unapplied instead of being silently credited as an advance; receipts leave failed orders out

💾 One Branch Was Running Out of Memory: • A diagnostic was serialising the whole request’s query history — hundreds of MB on a 104-order run — so the batch died mid-way and the screen showed an empty error; the same 24 orders were re-settled eight times over a month • The diagnostic is now bounded to the last 20 queries

🏗️ The Settlement Runs on Laravel Now: • Customers created from the POS have no ledger head yet; the old code silently did nothing for them — the ported settlement settles regardless, creating the head the way every other payment does • Every unsettled order is logged with its reason, and the flow is visible in Telescope for the first time • Hundreds of dues at one business were waiting on exactly this

Result: Mark a due as paid and it is paid — or you are told, by invoice, why it is not.

A Rs 500 voucher was taking Rs 580 off the bill on before-tax discount businesses, because the discount engine re-derived tax from it. A new switch makes an order-level voucher worth exactly its face value.

🧾 After Tax, Like Loyalty and Wallet: • Switch it on for the business (every branch) or per branch — next to Discount Apply Method, and on branch POS settings • The voucher deducts from the grand total after tax and every charge; tax base, GST and the discount method are untouched • Percentage vouchers freeze their amount at apply time; combined vouchers are capped at the grand total; a later manual discount supersedes it, as today

📊 Everywhere It Should Show: • Payment screen, every receipt layout, due totals, the register summary and both Z-report slips print it as its own Voucher Discount line; the sale voucher balances in the ledger • The switch takes effect the moment it is saved — settings saves now refresh the POS session, and the voucher check reads the live switch, so a cashier logged in earlier is not stuck on the old path

🔢 Voucher Numbers: • Sequential vouchers now carry the voucher prefix (random ones always did)

Result: Rs 500 off means Rs 500 off — on the bill, the receipt, the register and the books.

Customers recovering an account used to depend on one SMS gateway. A new tab decides, per brand, which channels may carry the code — and proves each one works before you switch it on.

📲 Three Channels, One Page: • Login Settings → OTP & Recovery: Email OTP, SMS OTP with a provider choice — Firebase (device-side, no per-SMS cost) or the SMS-module gateway — and WhatsApp OTP through our messaging service with an editable #OTP# template • Each channel shows a readiness badge and links to its setup page; enabling an unconfigured channel raises a warning instead of failing quietly • Existing brands change nothing until the page is saved

🧪 Send Test OTP for Firebase: • A button on the Firebase OTP page sends a real code to a phone and verifies it, using the Web API key in the field • Every classic misconfiguration maps to a plain-language fix — key invalid, Authentication never started, Phone provider off, SMS region policy blocking the country, admin domain missing, billing, wrong code

💬 WhatsApp Codes Through the ERP: • The customer app delegates WhatsApp OTP sends to a new internal ERP endpoint that applies the brand’s template and gateway

Result: Account recovery that reaches customers on the channel they actually use — configured and tested from one screen.

Several settings screens inherited from the customer-app port saved per brand but read across all brands, or were not reachable from the menu at all. They are now in the navigation and brand-scoped end to end.

📚 Pages & Social Media: • Terms, privacy, about us, refund/shipping/cancellation policies and social links form a proper tab group with the shared brand selector • Policy status toggles that used to fatal now work; the social links screen finally opens; six content pages share one editor

🔥 Firebase OTP, reCAPTCHA, Push Notifications, Analytics: • All four resolve the selected brand and appear in the nav; marketing analytics gets its eight tool types on a card grid • A Refresh App Cache button next to the brand selector clears the customer app’s config caches on demand

🔐 Login Setup Redesigned: • Customer Login and Panel Login URL as pill tabs in the v9 design, brand-scoped, with corrected warning modals • Branch phone is now editable from Branch Settings — no more placeholder numbers in the customer-app footer

Result: Every customer-app setting is reachable, saved for the brand you picked, and shown for that brand.

Customer notifications now go out through our own messaging service — one gateway hub for SMS, email, WhatsApp Web and the WhatsApp Cloud API — chosen per branch, with templates that sync themselves.

📡 Per-Branch Gateway Choice: • Branch Settings gain a messaging gateway selection — auto, WhatsApp Web or Cloud API — replacing the old session-name field • A mapped Meta template goes to the Cloud API gateway; plain text goes to a WhatsApp Web gateway; a cloud send without a mapped template is refused explicitly instead of failing quietly

🧩 Templates That Sync and Fill Themselves: • Template lists pull straight from the messaging service for branches that use it; other providers are unchanged • Sends support Meta named parameters ({{contact_name}}) alongside positional ones ({{1}}) — the same saved mapping serves both kinds

🔧 Under the Hood: • Every send is logged with its delivery status and the notification queue is updated, so a message that did not go out can be traced

Result: WhatsApp customer notifications work again, branch by branch, template or free text — on a service we run.

Kitchens asked for recipe sheets they can hand to staff. Both recipe types now export to Excel, and no money figure ever leaves with them.

📄 Food Recipes: • The report’s Export Excel button renders a flat sheet: one recipe row followed by its ingredient rows • Master rows carry Food # and Variant #; ingredient rows carry the ingredient SKU — on screen, in the kitchen quick-show and in the sheet

🏭 Manufacturing Recipes: • An Export Excel button on the recipe list posts the current filters to a dedicated export that reuses the listing query, so private recipes stay private • Dedicated SKU columns on the list, the ingredient detail table and the export

🔒 Costs Stay Inside: • Sale price, purchase cost, recipe total, unit cost and ingredient costs are omitted from both sheets regardless of the on-screen cost toggle — tests plant a sentinel price in every money field and assert it never surfaces

Result: Printable recipe sheets for the kitchen, with nothing on them the kitchen should not see.

Counting stock across a big menu is easier when the grid shows only what you are counting — and the history panel no longer drags the whole archive in.

🔎 Filter the Session Grid: • A category dropdown beside the product/SKU search; bulk reason assignment follows the same scope • Reason dropdowns show variance and correction reasons only by default — wastage reasons are back with one tick in Business Settings (rows already saved with a wastage reason keep it)

🕘 History That Loads Fast: • The history panel opens on the last 7 days; from/to date, department and status filters reach older sessions • The date inputs show the applied window, Reset restores it, and each card names who created the session and when it was posted

Result: Reconciliation sessions stay focused, and their history opens instantly.