Questions worth a straight answer

No — none, at any point. There are no network calls anywhere in the application. There is no server component at all — the database is one JSON file on your disk, and even activation is done offline by exchanging codes.

The practical consequence is the one that matters at 9pm on a Thursday: a dead line to your building cannot stop you taking orders, printing tickets or closing the till. The application works with the internet unplugged, permanently.

The live database sits in the operating system's user-data folder — %APPDATA%\Meezan ERP POS\ on Windows, ~/Library/Application Support/… on macOS and ~/.config/… on Linux.

It is also mirrored on a throttle to Documents/Meezan ERP Restaurant/ as plain, human-readable files you can copy. Writes are atomic and fsync'd with a rolling .bak, and if the primary file is ever found corrupt the application falls back to the backup automatically.

You lose the machine, not the business. Restore the Documents/Meezan ERP Restaurant/ folder — from your own backup, a network drive or the old disk if it is readable — install the application on the replacement machine, and import.

Because the licence is node-locked, the new machine will show a new machine code on the activation screen; send it to us and we re-issue against the remaining term. The honest advice is the same as for any local-first system: copy that Documents folder somewhere else on a schedule you can actually keep.

No. The mirror in Documents/Meezan ERP Restaurant/ is deliberately outside the application's own folders, so it survives an uninstall. Removing the program removes the program.

That is also why an upgrade or a reinstall is uneventful — the data and the activation are both waiting where the new install looks for them.

Yes. Install on the new machine, copy the Documents/Meezan ERP Restaurant/ folder across, and use Import data backup from the File menu. Nothing is locked to a particular disk or user profile except the licence.

For the licence, read the new machine code on the activation screen and send it to us for a re-issue against your remaining term. See the licensing section below for how that works and why a code cannot simply be copied.

Yes. The mirrored files are plain and human-readable — you can open them in a text editor, keep them in your own backup rotation, or hand them to an accountant or a developer. There is no proprietary container and no key you have to ask us for.

The File menu also has an explicit Export data backup so you can take a snapshot on demand, before a menu overhaul or a year-end, without going hunting through folders.

No, and we would rather say so plainly than dress it up. The database is local to each machine by design — that is the same decision that gives you an application with no network calls, no cloud dependency and no monthly fee, and you cannot have both.

A licence covers several devices so that a till, a back office and a manager's machine can each run the application, but each keeps its own database. If your operation genuinely needs one live ledger across several tills at once, tell us on the contact form before you buy so we can be straight with you about fit.

Yes, throughout — every posting has both sides, and the trial balance and balance sheet are asserted to balance at the end of the automated test suites before any release ships. Revenue and COGS post as two entries rather than one, and COGS is booked once, by the delivery, in the order flow.

Stock transfers deliberately post no journal entry, because moving your own goods between your own warehouses is not an accounting event. Fixed assets depreciate straight-line, and the same period cannot be depreciated twice.

Both are supported and you choose in Settings, as part of your company costing method. FIFO suits kitchens working through dated stock in the order it arrived; weighted average suits commodity ingredients bought repeatedly at drifting prices.

Whichever you pick, stock consumption is transactional — a consumption that fails leaves nothing half-mutated behind it, so you never end up with stock moved and cost unbooked.

No. A posted entry cannot be edited in place; to correct it you post a reversal, and the original stays visible.

Treat that as a feature rather than an obstacle. An audit trail that can be quietly rewritten is not an audit trail, and when an auditor, a partner or your future self asks what happened on a given night, the answer is the whole sequence — what was posted, what reversed it and what replaced it.

It is rejected. So is a posting to an account that does not exist in your chart of accounts. Version 1 accepted both silently, which is precisely how a ledger drifts away from reality without anyone noticing.

The wider rule is that every posting is checked before it is written, so a bad number is refused at the door rather than becoming a NaN somewhere downstream in your accounts.

Yes. POS pricing is VAT-inclusive: the price on the menu is the price the guest pays, and VAT is extracted from that ticket rather than added on top. A 46.00 gross ticket at 15% books a net of 40.00.

This is how counter and dine-in pricing works in practice in the Kingdom, and it means your posted revenue and your VAT line are consistent with the number on the customer's receipt without anyone doing arithmetic by hand.

Every POS sale requires an open session, opened with a counted float on a specific register. At close the cashier counts each tender against the expected figure — float plus cash sales minus payouts — and the difference shows as over or short before anything is submitted.

Submitting posts nothing. The variance reaches the ledger only when a supervisor approves the close, as a single balanced Cash Over/Short journal entry — and a cashier cannot approve the drawer they counted. Every open, payout, close and decision lands on an append-only audit trail.

Yes. You design the chain yourself: any number of levels, each a named action assigned to users and/or roles, with amount bands per document type so a small expense takes a short path and a large one takes the long one. Levels run in sequence, with optional parallel stages where everyone must sign but in any order.

A gated document is held as a draft — the ledger holds nothing until the final level approves, at which point the draft posts and the posted id is recorded on the approval. Rejecting or returning requires a written reason, only the preparer can resubmit, and the whole trail is append-only.

Yes — tag postings with cost centres, which nest in a hierarchy (branch above kitchen and counter) and ride the journal line without ever changing what an entry posts. A sale order’s cost centre carries through to its invoice, and manual journals can be tagged line by line.

Three reports come with them: movement per centre, P&L by centre with branches side by side, and budget vs actual with a signed variance. Every report keeps an explicit Unallocated column, so postings nobody tagged are visible rather than quietly missing.

Yes. Link the customer record to the vendor record that is the same business — explicitly, in Customers & Vendors; names and VAT numbers are never matched by guesswork — and the statement screen gains a Receivable / Payable / Both selector.

“Both” interleaves invoices, receipts, bills and payments in date order on one running balance, and the closing figure is a net memo: what they owe you minus what you owe them. The AR and AP control accounts stay untouched — nothing is offset in the ledger.

It prepares Phase-2 e-invoice artifacts: UBL 2.1 XML generation, the ICV invoice counter value, the PIH hash chain with chain integrity verified on every read, and the Base64 TLV QR payload for tags 1 to 5 — seller name, VAT number, timestamp, invoice total and VAT total.

What it does not do is fabricate tags 6 to 9, which carry the XML digital signature and the signing certificate. Those depend on a CSID issued by ZATCA during device onboarding — a real credential the application stores but will never invent. Until yours is in place, documents are flagged signed: false rather than emitting a QR code that looks compliant and is not.

No software can make that claim on your behalf, and we will not. Meezan ERP POS is built for ZATCA Phase 2 and prepares the artifacts, but onboarding your device with ZATCA and obtaining your CSID is yours to complete — it involves your credentials and your organisation, not ours.

What we can promise is that the application refuses to fake the parts only ZATCA can issue. Anyone telling you their product makes you compliant the moment you install it is describing something that is not in their gift.