Summary
A cloud-based point-of-sale and operations platform for restaurants, bars and cafés. Staff take orders by table, guests can order from a QR code, orders reach the right preparation station, and fiscal receipts, payments, invoices, stock and reports all live in one system.
What ScanBar is
A restaurant is a sequence of hand-offs. An order is taken by a waiter or placed by a guest, split across the kitchen and the bar, prepared, served, printed and fiscalised, paid, and finally reported on and taken out of stock. ScanBar connects that whole chain in one platform.
It is our most established product. It runs as a single cloud service shared by many restaurants, each one kept strictly separate, and it is built around the fiscal rules restaurants in North Macedonia work under.
Connected workflows
Each role sees the part of the service it needs.
- Waiters and cashiers: a visual table layout, table sessions, order entry, quick user switching with a PIN, receipts, payment by cash, card or invoice
- Guests: ordering from their own phone by scanning the QR code on the table, without an account
- Kitchen and bar: station screens that show only their own items and move each one from ordered to preparing, prepared and delivered
- Managers: menus, stations, tables, users and devices; invoices for business customers, generated as PDF and sent by email
- Stock: warehouses, purchase orders, transfers, stocktaking and a full movement history, with stock deducted automatically as orders are delivered
- Reporting: sales and stock analytics, including cash and card totals per user
- Order entry
Taken by a waiter at the table, or placed by the guest through a QR code.
- Preparation
Split automatically to the kitchen and bar stations and tracked until delivered.
- Fiscal and payment
Fiscal receipt through the on-site print service; cash, card or invoice.
- Stock and reporting
Stock deducted as items are delivered; sales and stock analytics.
Hardware and fiscal printing
ScanBar talks to the physical side of a restaurant. A small print service on site connects the browser to the receipt and fiscal printers; the platform registers each printing and fiscal device, maps devices to stations, and checks in on them so staff know when a device has gone quiet.
Fiscal rules are part of the domain model rather than an afterthought: tax groups, a lock that prevents changes once a receipt has been fiscalised, and a proper reversal when a fiscalised receipt has to be corrected.
Engineering behind it
Many restaurants share one deployment, so tenant isolation is enforced in every request and covered by dedicated tests. A table can have only one active session at a time, guaranteed by the database rather than by convention. Stock changes are driven by order events, so inventory follows what was actually served.
The current work prepares the platform to keep running on site and synchronise with the cloud, with sync identifiers and ordered change sequences already in the data model.