What's New

The daily inventory report now shows mini-store sold quantities and remaining stock right under the direct consumption section — no more jumping between reports to reconcile what the mini-store moved during the day.

🧹 Also in this release: • The Ingredient Wastage menu item is now visible to every user who holds the wastage permission — not just admins — so the people actually recording wastage can reach the screen themselves.

Result: One report tells the whole day's consumption story — kitchen, direct and mini-store together.

Post-dated cheques used to live in a physical drawer and someone's memory. They now live in a dedicated cheque register that follows each cheque through its whole life — received or issued, deposited, cleared, bounced or cancelled — with the accounting entries posting themselves at every step.

🗂️ One Register, Full Lifecycle: • Record cheques received from customers and cheques you issue to suppliers, with amount, cheque number, maturity date and bank • Every status change books the correct voucher automatically — clearing moves the money into the bank, bouncing reverses it and restores the party's due • A pending cheque can be edited and its voucher is rewritten in place; the register and the ledger can never disagree.

🧾 Captured at the Counter: • Taking a cheque against an invoice? Enter its maturity date on the payment itself and the register picks it up automatically • Edit or delete that payment later and the linked cheque follows suit — amounts, dates and banks stay in lockstep, and once a cheque has been deposited or cleared, the payment is locked against silent changes.

👤 Party-Aware Ledgers: • Every cheque entry carries its customer or supplier through to the ledgers, so party statements and receivable/payable views show exactly whose paper is in the drawer • You choose per business whether a received cheque reduces the customer's due immediately or only once it clears.

⏰ Maturity Never Sneaks Up: • A maturity report shows what is due, overdue and coming this week • A daily sweep reminds the right people about cheques maturing today — before the bank tells you the hard way • The register itself is a live, searchable table with filters for direction, status, bank, party and maturity window.

Result: No more forgotten cheques, missed maturities or ledgers that disagree with the drawer — the register knows, and it does the bookkeeping for you.

Manual accounting vouchers — debit, credit, journal, expense, income and contra — can now be routed through a configurable approval chain of up to four levels before they touch your books. Until the chain signs off, the voucher stays out of every report and balance.

🧭 You Define the Chain: • Each level names the roles or specific users who may approve at that step • One level for a simple maker–checker setup, or up to four for larger finance teams • The person who created a voucher can never approve it, and no one can approve the same voucher at two different levels.

📥 A Live Approval Inbox: • Pending vouchers appear in a dedicated inbox showing amount, branch, creator and how far along the chain each one is • Filter by voucher type, branch and date, search by voucher number or creator — approve or reject without ever leaving the page • Rejections require a note, and editing a rejected voucher sends it back through the chain from the start.

🧾 Every Step on Record: • Submissions, approvals, rejections and resubmissions are written to a permanent history — who acted, when, at which level, with what note, and the voucher amount at that moment • The history is append-only: it can be read, never rewritten.

Result: A manual voucher can no longer slip into your ledgers on one person's say-so — and there is always a paper trail of who let it in.

The transfer edit form has always shown a destination dropdown — pre-selected, required, and completely ignored on save. Changing it did nothing.

🔀 Now It Works: • While a transfer is still pending or in transit — before any stock has actually moved — you can point it at a different branch • Everything that belongs to the destination moves with it: the store department, the default cost centre and the counterparty account, re-derived for the new branch pair.

🚫 Refused Loudly When It Matters: • Once either side has received or completed the transfer, the stock is physically there — redirecting is refused and the whole edit rolls back rather than half-saving • Same for transfers fulfilling a transfer order raised by the current destination • The check runs against a locked read, so a transfer someone completes while your form is open cannot be rewritten out from under the stock that just landed • When the destination can no longer change, the dropdown is disabled with a note explaining why.

Result: A transfer raised against the wrong branch is a two-second fix instead of a delete-and-redo.

Roles decide what an employee can do — and the employee form treated them as an afterthought.

👥 Cloning: • Cloning an employee copied every field except their roles, so the clone arrived able to do nothing • The clone form now opens with the source employee's roles pre-selected, scoped to your business.

✏️ Editing: • The roles dropdown existed only on the add form — editing an employee gave no way to even see what they hold • Admins now see and change roles right on the edit form, with the current assignments pre-selected • Clearing the dropdown genuinely clears the roles, and a form that never carried the field leaves them untouched — the two are no longer confusable.

🔐 Scoped Sensibly: • Anyone who may add an employee can set roles at creation; changing them afterwards is admin-only.

Result: What an employee can do is managed where you manage the employee.

Two quality-of-life upgrades for stock reconciliation sessions.

🖊️ Bulk Reason: • A count usually has one explanation repeated down the column, but every row demanded its own dropdown — 124 clicks for one decision on a 124-item count • A new bar applies one reason to every counted or varianced row currently in view — your filter tabs and search box set the scope, and the button counts its targets live • It never overwrites a reason someone chose deliberately, and reports how many it left alone.

📋 Full Count Record (optional setting): • The posted count record used to hold only the rows that moved — an item counted and found correct left no trace at all, putting a hole in the stock report's physical closing exactly where the count agreed • Turn on Save full stock reconciliation in business settings (Purchase tab) and the record covers every item in the session, zero-variance rows included, at their snapshot cost • Nothing else changes: no extra adjustments, no accounting impact, and the record of what was physically counted by hand stays honest.

Result: Counting gets faster, and the count record finally proves what was checked — not just what was wrong.

Discount and due-order alerts are addressed “care of” a responsible user. When no such user was recorded — or the user had since been deleted — the send crashed, and because the queue marks a message sent before attempting it, the alert was lost forever, not delayed. At one business, 37 such alerts never reached anyone.

📱 The Irony: • Every one of these alerts already carried a management phone number as its fallback — the code crashed one line before it would have used it.

✅ Now: • With no care-of user, the alert goes straight to the management number • With no recipient at all, it is abandoned and logged — never misaddressed to the customer's own mobile, which is where the old fall-through would have sent it.

Result: The alerts built to keep management informed actually reach management.

Branches reporting to two tax authorities at once schedule a background retry when the second submission needs another attempt. Every one of those retries was dying before it sent anything — the lookup code reached for the logged-in user's session, and a background job has none. Affected branches quietly lost one to three invoice syncs a day.

🎫 The Fix: • The retry job now carries everything it needs with it — business, branch, price group and tax settings all resolved from the invoice's own branch, never from a session • A crash was actually the lucky outcome: one code path could have submitted an invoice with no items on it to the tax authority. That path is closed too.

Result: Fiscal invoices reach the authority on retry, with the right items, without a human resubmitting them.

A major infrastructure program landed this week, aimed at one goal: a server going down — planned or not — should be invisible at the counter.

⚡ Faster Background Jobs: • Notifications, prints and syncs moved off the database queue onto a dedicated in-memory queue processed on all four servers • The lock storms that twice made the whole system feel slow are gone — and if a queue ever does jam, a request now waits 3 seconds instead of 50 before carrying on without it.

🔁 Automatic Failover: • The cache and queue layer now runs with live standby copies in both data centres and promotes a replacement automatically if the active one dies — the application follows without a restart • Database traffic flows through a routing layer, so moving the database between data centres is one rehearsed command — drilled successfully in both directions with zero application changes.

🕐 Scheduled Jobs Everywhere: • Nightly audits, reports and cleanups used to depend on a single server being alive • They now run from any surviving server, with a shared lock guaranteeing each job still fires exactly once.

Result: Maintenance windows and hardware failures stop being your problem — the fleet reroutes around them.

Announced earlier as groundwork, the single-writer inventory ledger is now switched on for every business. Every stock movement in the system flows through one engine that applies each move completely or not at all.

🧱 What Runs Through It: • Purchase receiving and purchase deletes • Transfers, adjustments and wastage • Production and its ingredient consumption • Sales consumption and direct ingredient sales • Purchase returns — every core stock flow, no exceptions.

⚛️ Atomic by Construction: • A stock move can never again be half-applied — the balance, the batch allocations and the journal entry land together or the whole move is refused • Every movement is journaled, so “what changed this number?” always has an answer.

🧪 Proven Before It Reached You: • The engine ran flag-gated business by business, with parity checks proving it produced the same results as the old paths, before being enabled estate-wide • The nightly balance-vs-batches and balance-vs-journal health checks keep watching it every night.

Result: Stock numbers that used to drift in edge cases now physically cannot — there is one writer, and it never does half a job.

Background recosting can legitimately reach back to old sales — for example when stock that was oversold finally arrives and its real cost becomes known. When that old sale sat in a closed fiscal year, the protection fired at the wrong moment: after the line details were rewritten but before the header saved, leaving the record internally inconsistent inside a frozen year.

🚧 The Guard Moved Up Front: • A transaction in a closed year is now skipped before anything is written — nothing in a frozen year moves, not even partially • The error message now names the transaction, its date and the year that blocked it, instead of pointing you at the year you had selected.

⏭️ The Batch Continues: • One closed-year transaction used to abandon everything queued behind it — those sales never got recosted at all • The job now skips it, logs it, and finishes the rest.

Result: Closed years stay exactly as closed as your accountant thinks they are.

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.