What's New

The register summary got a full redesign — running side by side with the classic slip so you can compare before switching. Pick it from the new Slip Layout filter, or jump straight in via the Register Summary v2 entry in the Reports menu.

🖥️ Two Dresses, One Truth: • On screen: a clean card layout with section bars, and an Explain Figures toggle that reveals a plain-words description under every row • On the thermal printer and PDF: a proper full-grid document, dark text, amounts on one straight edge • A Render View As filter previews the print dress in the browser — without ever affecting what the printer receives.

⚖️ The Slip Checks Itself: • Cash in Hand prints as a ledger — opening + sales + recoveries = closing, with a warning if it ever doesn't • Net Amount proves its own formula (rounding and third-party commission included) and flags orders whose stored totals genuinely don't add up • Empty sections are dropped and named in one line instead of printing blank tables.

Result: A register slip that reads like a document, explains itself on demand, and audits its own arithmetic on every print.

Credit figures were the hardest part of the dashboard and register slip to explain — the same rupee legitimately appears in different places depending on when it was promised and when it arrived. Now the reports do the explaining themselves.

📊 The Dashboard Shows the Arithmetic: • The credit line is three rows: Sold on Credit − recovered by now = Credit Still Owed • The card's total now ties the Order Type card exactly — still-owing credit orders no longer vanish.

🧾 The Register Slip Adds Up On Paper: • Cash in Hand separates credit recovered in cash (part of closing) from bank/card (not cash) • The credit-by-category table no longer drops customers without a category, and splits owed vs recovered per row • A long-open register now says so — span warnings, still-open notices, and out-of-session bookings disclosed • Every formula on the slip carries a plain-words description of what it is and how it is built.

Result: Anyone can plus-minus the credit figures in front of a customer — and the numbers hold.

Food timing windows control when an item can be sold — but some businesses need chosen people (a call centre taking pre-orders, a manager) to punch items outside their hours.

⏰ Now a Setting, Not a Request to Support: • Business Settings → POS carries a Food Timing Bypass Users field — a simple list of user IDs • Listed users can order any item regardless of its timing window • Empty means nobody — timings stay fully enforced by default.

Result: You decide exactly who may sell outside the clock — per business, changeable in seconds.

The commission field on third-party orders was freely editable at payment time — and since commission is deducted from the payable, it worked as an uncontrolled discount that bypassed every discount permission.

🔒 Locked By Default, Everywhere: • The field is now read-only for everyone — it fills from the company's configured commission and nothing else • Every payment is re-checked server-side too, so nothing can slip past the screen.

✍️ Legitimate Changes Get a Signature: • A business setting (off by default) enables a Change Commission button • It opens an authorization box where a designated general-auth person signs the new percentage with their credentials — logged with who authorized and who entered.

Result: Commission is what the company agreement says — or what a named person signed for. Never what a cashier typed.

The accounting side of every sale got the same treatment: vouchers now behave like records, not drafts.

📒 Vouchers Hold Still: • A sale voucher's date is fixed at the sale and stops rewriting itself when nothing changed • Payments are stamped with the selling branch's shift, not the operator's • Writing a due off with a discount now reaches the ledger — the receivable actually closes.

🔍 A Nightly Tie-Out Proves It: • A daily check compares every POS order against its ledger entries and reports any divergence before it grows • Repair tooling settled the historical gaps it surfaced on day one.

Result: The POS and the general ledger tell the same story every morning — verified, not assumed.

The payment engine went through a line-by-line audit against years of till behavior, and every gap it found is closed — with the due/credit flow getting the deepest attention.

💰 Partial Collections Book What Was Handed Over: • Collecting a slice of a customer's due now books exactly the slice — not the whole order • The Due Order Paid report shows partial collections instead of dropping them from the day's numbers • Backdated and year-end-crossing due settlements book cleanly — one payment, right period.

🧾 Dues Stop Causing Side Effects: • Collecting an old due no longer clears the table someone else is sitting at, and no longer pings the kitchen as if food just left • An over-tendered split no longer credits the drawer more than the bill • A paid takeaway stays in the running list until someone actually hands it over.

Result: Credit sales, partial recoveries and settlements land in your reports to the rupee — no vanished slices, no phantom side effects.

The documentation site keeps growing with the product: this round adds chapters written from the live screens, with real module screenshots.

📖 New Ground Covered: • Dashboard and Kitchen chapters • Staff management, the full report catalogue, the customer app, both Options menus — and a POS grand tour from punch to payment.

Result: Every menu your team can click now has a page that explains it.

The customer-app admin screens and the Options menus were visible to anyone who knew the URL. Both are now governed by real permission labels, enforced server-side.

🛡️ Closed at the Route, Not Just the Menu: • A new customer_app permission module with a master label and one per link • Middleware closes every admin URL the menu hides — hiding a link is no longer the only lock • The Options screens got the same treatment.

🔐 Charge Authorization Asks Properly: • Delivery/service-charge auth now asks every configured auth person and no longer stalls waiting for a re-login.

Result: What a user can't see, their browser also can't reach.

Bank card offers (10% up to Rs. 150 on a given BIN, say) applied at payment — but the unpaid bill handed to the customer never showed them, so the table saw a total the card would never be charged.

💳 Pick It at Print Time: • In the POS Print Bill window (F8), choosing a card payment method now offers the branch's active banking discounts — the same offers as the payment screen • The printed bill adds two lines under the total: the capped discount and Payable after Bank Discount, on every bill layout.

🔒 Informational, Never Sneaky: • The bill's own total stays the gross amount and the order is only discounted at payment, exactly as before • The discount rides card methods only — a cash reprint clears it automatically, and the server refuses any combination the payment screen would refuse.

✍️ Small Courtesy Alongside: • The POS search windows (print bill, order edit, make payment, view detail/history) now say "Nothing to search — enter a Table No. or Token No. first" on an empty submit instead of a generic error — caught in the browser before a request is even sent.

Result: The customer holding an unpaid bill sees the bank discount and the exact amount their card will be charged — before they ever hand it over.

Two report doors that only admins could open are now ordinary permissions you grant per role (v2.30.240–241).

📊 Business Wise Sale for Non-Admins: • The report and its menu link open to any role granted the new business_wise_sale permission — it was hardcoded admin-only before.

🏢 "All" in the Branch Dropdown: • A second permission, view all branches in reports, adds the All option to the branch filter of every report that offers one — item, product, variant, cashier, day-wise, top customers, order history and more • Without it, a non-admin stays pinned to their own allowed branches.

🛡️ Enforced on the Server: • The grant is checked when the report runs, not just when the dropdown renders — a hand-crafted "all branches" request from an ungranted user collapses to their own branch.

Result: Managers see exactly the reports and the branches you grant — no admin account required, no side door around it.

For the very same day and branch, the Business Wise Sale report could read 344 orders where Done Orders and the rider-wise report both said 337 — while the amounts matched to the rupee. The seven extra rows were cancelled orders: their totals are zeroed on cancellation, so they inflated the count without moving the money.

🚫 Cancelled Means Not Counted: • Business Wise Sale now excludes cancelled orders, the same way every neighbouring report already did • Counts and totals agree across all three screens — verified against the production day that exposed it.

Result: One day, one order count — whichever report you open.

Businesses on exclusive menu tax store item tax as zero at the POS and add tax on the bill — but the fiscal sync only rebuilt per-item tax for a single brand, so everyone else synced invoices whose items said 0% while the bill said 16% (v2.30.237–238).

🧾 Per-Item Tax Goes Universal: • Every exclusive-tax business now syncs each line with tax derived from the bill's actual rate — item tax, rate and totals reconcile with the bill to the paisa.

💳 Card-Rate Bills Re-Derive: • On inclusive menus, paying through a method with its own tax rate (a 8% card rate on a 16% menu, say) re-prices the bill — but the stored item tax kept the menu rate, so the sync could report double the tax actually charged • Item tax is now re-derived from the bill whenever the two disagree.

🏷️ Every Discount Convention Reconciles: • Whether a business taxes the discounted subtotal or taxes the full subtotal and discounts the gross, the sync distributes the bill's real tax pro-rata across the items — both styles land consistent.

Result: What the tax authority receives per item now matches what the customer was actually charged — for every tax setup, not one brand.