Every area, in full

A global cohort, plus cohorts scoped to a branch or a zone, each able to override the price of any variant or modifier. A delivery menu priced 10% above dine-in is configuration, not a second menu to maintain.

Update many prices at once, or apply a percentage to an entire cohort. Cohorts inherit from a parent cohort.

Download the template, fill it in, upload it. Validated all-or-nothing so a bad file never half-imports, with row, column and file-level error reporting and a dry run before committing.

Reusable modifier groups shared across items, each set to single or multiple selection. Plus per-item notes and kitchen notes.

The product answers "what does this cost at this branch", and returns a fully resolved menu for any branch.

Items, categories, order types and VATs carry Arabic and English names, so customer-facing text is bilingual too.

From CREATED to COMPLETED, plus CANCELLED, VOIDED and REJECTED — each an event with a timestamp, notes and who changed it.

A retried request after a lost response never produces two orders. The same holds for payments, refunds, and opening or closing a drawer.

Atomic and stale-safe, with a point-in-time snapshot of every version you can inspect. Over-collection surfaces as an explicit refund-due figure.

Configured by status and by minutes elapsed: "a delivery order can change for 5 minutes, a dine-in order until it is ready" is configuration, not code.

Several named VATs, each scoped by branch, delivery zone or order type, with the tax breakdown kept on the order. Not a certified e-invoicing integration.

An order taken at one branch and fulfilled by another, with accept and reject states, and a summary that feeds the shift report so cross-branch trade reconciles.

Cash, card, mobile payment, credit, online provider and other. The order payment status follows the money: PENDING, PARTIAL, PAID, REFUNDED, VOIDED, FAILED.

One order across several tenders, partial payment supported, and a drawer movement written per payment.

Full or partial, returned by the tender it arrived on, with a ceiling that counts refunds already in flight so the same money cannot be given back twice. Cash refunds must come out of the operator’s own open drawer.

Void, failure and refund are three distinct things, each its own event with its own timestamp — in one nothing was collected, in the other something was reversed.

A timeline interleaving payment events with the drawer movements they produced, so an order waiting on provider confirmation does not look like nothing happened to it.

A provider is configured against the field schema it declares, so a new provider or a new credential needs no release. Secrets merge rather than replace, and never return to the browser.

Four routes: QR code, payment link, browser redirect, and deep link into a payment app.

If a payment provider goes down, the till keeps taking cash. Slow responses count as failures, but one tenant’s bad credential cannot open the circuit for everybody.

A refund goes back through the provider the money arrived on, under the same cap and onto the same ledger.

Provider payments history, the detail of each payment, and a per-order timeline — from the back office.

Manual and scheduled reconciliation of payment status, so an order waiting on a provider settles onto the right state.

Opening float, sale, pay-in, pay-out, safe drop, refund and void. Each records the tender’s face value and its effect on physical cash separately — a card refund and a cash refund are both refunds, but only one empties a till.

A session that does not balance enters PENDING_APPROVAL rather than closing quietly. There is an approval queue and a separate permission, so the person who counts the till is not the person who signs off the discrepancy.

A till cannot close with unresolved pending payments on it — except provider payments, which settle out-of-band by design.

An order records both the drawer session it was created on and the one it was settled on, so an order rung up on one shift and paid on another is attributed correctly to both.

Assembled from five components: sales summary, itemised sales, drawer calculation, handover summary, and delivery drawer summary.

Not just per order. Each line moves through its own states.

Item states, order states, actions and the transitions between them are all data set in the back office. A four-stage kitchen and a two-stage kitchen are the same product, configured differently.

Preparation, expeditor, runner and customer — so the grill screen and the pass each show their own slice.

State change, priority, recall, void and print.

Device registration, heartbeat, an active-device list per branch, and an offline-device list — so a dead screen in a busy kitchen is noticed rather than discovered.

Elapsed time and prep time per item, with priority flagging and per-state colour coding you define and the screen honours.

Zones are polygons you draw on a map in the console, both per-branch zones and global delivery areas.

Point-in-polygon lookup finds the zone containing an address, with automatic branch-to-zone assignment.

A service answering "which branches can deliver to this address", plus a deliverability check for a given branch and location.

Assign agent, picked up, on the way, delivered — with a separate path for a customer collecting in person. States: DISPATCHED, DELIVERED, SETTLED, RETURNED, FAILED.

Delivery agents have their own shifts, opened and closed independently of till shifts.

A delivery drawer summary on the shift report, so driver cash reconciles against the till. Delivery payment types are tracked distinctly: cash, card, cash on delivery, card on delivery.

Each writes to a movement ledger: receipt, adjustment, reserve, release, sale, transfer out, transfer in, and count.

Requested, approved, dispatched, received, completed — plus rejected and cancelled. The person requesting is not the person approving.

Selling a finished dish draws down its ingredients, with components definable at variant level too.

Barcode types are configurable, with barcode and QR rendering in the console: EAN-13, UPC, Code 128, Code 39, QR, Data Matrix and more.

Corrects on-hand and reserved drift, and catches completed orders whose stock was never deducted — every correction written as a movement so the ledger stays whole.

An operational-mode switch between RESTAURANT and MARKET, and the ability to run with no inventory at all.

Revenue, order count, average order value, cancellation rate, total discounts and average preparation time — over any date range, filterable by branch, loaded in one call.

Sales trend, peak hours by hour of day, sales by order type, sales by payment method, and top-selling items ranked.

Sales summary by day, sales by item, shift sales by drawer session, stock on hand, and the stock movements ledger. All on screen and exportable to Excel or PDF.

Across some 30 domains. Roles are built from the catalogue, not chosen from a fixed list. Permissions exist per order type — a call-centre role can create delivery orders but not dine-in ones.

Staff are scoped to the branches they may see, and an area manager is granted "access any branch" as an explicit right.

Tracks how far a new business got, resumes on the right step, and keeps each step’s state — surviving logout.

Currency symbol and its position before or after the number, and a receipt designer with multiple saved designs and 58mm or 80mm paper.

Full Arabic and English with RTL across the console — not a translation layer over an English product.