SKIP TO CONTENT
A/L
SYS_001LIVE

Sceneway HMS

Hotel & Restaurant Operations System

One operational system for rooms, restaurant, kitchen, stores and accounts across multiple properties.

TYPE
HOTEL ERP
STATUS
LIVE
YEAR
2026
ROLE
Product owner, system design, full-stack implementation
PLATFORM
Flutter (Android / Windows / Web), Node.js API
STACK
Flutter · Dart · Node.js · MySQL · REST · IndexedDB
Operational modules
11
Client platforms, one codebase
3
Accounting core, zero re-entry
1
01

PROBLEM

A hotel with a restaurant attached does not run one business — it runs five. The front desk sells rooms. The restaurant sells covers. The kitchen consumes stock. Purchase brings stock in. Accounts has to reconcile all of it by the end of the day.

In practice each of those runs on something different: a room register in one software, a POS billing machine at the counter, stock on paper, purchase bills in a folder, and accounting re-entered from scratch at month end by someone reading printouts.

The cost is not the software licences. The cost is that nobody can answer simple questions — what did this property actually earn last night, which items are eating margin, why does physical stock disagree with the register — without a person spending a day joining records by hand.

02

SYSTEM

Sceneway treats a property as a single ledger with several front-ends. Every operational screen — a check-in, a KOT, a stock issue, a purchase entry — is an event. Events post to inventory and to accounts as a consequence of being recorded, not as a separate month-end exercise.

The room register and the restaurant POS are deliberately the same system. A resident guest can sign a restaurant bill to their room folio, and it lands on the folio, the outstanding and the day book at once.

Multi-property is handled at the data layer through tenant and property scoping, so a group can operate several hotels with isolated data and consolidated reporting.

03

CORE FLOW

How the operation moves through the system.

ARCH_01 / SCENEWAY MODULE TOPOLOGY
  • Reservations, check-in/out, folios, tariff and tax plans
  • Restaurant, bar and room-service billing; table and cover management
  • Kitchen order tickets routed per station; fires recipe consumption
  • Stores, issues, transfers, physical verification and variance
  • Roles, shift assignment, per-user audit trail on every posting
  • Supplier bills, receipt against order, rate history, payable ageing
  • Bill of materials per dish; converts covers sold into stock consumed
Every module posts its double-entry consequence here. Nothing is re-keyed for accounts.
  • DAY BOOK
  • LEDGERS
  • OUTSTANDING
  • STOCK VALUATION
  • REPORTS
SELECT OR HOVER A NODE FOR DETAIL

Rooms, POS, KOT, inventory, staff, purchase and recipe modules all post into a shared accounting core, which produces the day book, ledgers, outstanding balances, stock valuation and reports.

04

KEY MODULES

M01Front desk
Availability, reservation, check-in, room move, folio, checkout and settlement.
M02Guest registration
Guest master with ID capture, repeat-guest history and company billing.
M03Restaurant POS
Table map, running bills, splits, discounts, tax handling, post-to-room.
M04KOT
Station routing, preparation state, void and re-print with reason and audit.
M05Recipes
Per-dish bill of materials with yields; drives automatic consumption.
M06Inventory
Multi-store issues, transfers, wastage, physical count and variance report.
M07Purchase
Supplier orders, receipt against order, rate history, payable ageing.
M08Staff & roles
Role-based access down to the action; every posting carries who and when.
M09Accounting
Chart of accounts, journals, receipts, payments, outstanding, trial balance.
M10Reporting
Day book, occupancy and average rate, item profitability, consumption vs sale.
M11Multi-property
Property-scoped data with group-level consolidated reporting.
05

ARCHITECTURE

Client
Single Flutter codebase compiled for Android tablets, Windows counters and web back office.
API
Node.js REST service; tenant and property resolved from the token, never from the request body.
Data
MySQL with tenant-scoped access, transactional posting and an append-only audit trail.
Local cache
A local queue holds counter operations so billing survives a network drop.
Posting engine
One service translates business events into inventory movements and journal entries.
Deployment
Windows Server with IIS reverse proxy for on-premise properties; Linux for hosted tenants.
06

ENGINEERING

The parts that were not obvious, and what the system does about them.

  1. 01 / 05

    Recipe consumption that survives reality

    A dish sold should deduct its ingredients, but kitchens substitute, waste and serve half portions. Naive deduction produces stock figures nobody trusts, so consumption is posted as a computed expectation with an explicit variance against physical count — the report shows both numbers rather than pretending one of them is the truth.

  2. 02 / 05

    A bill that belongs to two places at once

    A restaurant bill signed by a resident guest is simultaneously a restaurant sale and a charge on a room folio. Modelling it as one sale with a settlement route into the folio — instead of two documents — is what keeps revenue reports and outstanding balances from disagreeing.

  3. 03 / 05

    Offline billing without duplicate bills

    Counters cannot stop when the link does. Operations are queued locally with client-generated idempotency keys, so a retry after reconnect can never post the same bill twice.

  4. 04 / 05

    Day-end close as a boundary, not a ritual

    Night audit has to freeze a business day while the restaurant is still serving past midnight. Business date is an explicit field on every posting, separate from the timestamp, which makes the close deterministic and re-runnable.

  5. 05 / 05

    Tax plans that change per property

    Rates and applicability differ by property, service and slab. Tax is resolved from a versioned plan at posting time and stored on the document, so reprinting an old bill reproduces the old tax rather than today rules.

07

SCREENS

  1. SCREEN_01Front desk — availability grid and arrival board
  2. SCREEN_02Restaurant POS — table map and running bill
  3. SCREEN_03KOT — kitchen station queue
  4. SCREEN_04Inventory — issue entry and variance
  5. SCREEN_05Accounts — day book and outstanding
08

RESULT

Properties run the front desk, restaurant, kitchen and stores on one system, with accounts produced as a by-product of daily operation rather than a month-end reconstruction.

Day-end figures are available at day end. Item-level profitability and consumption-versus-sale variance become answerable questions instead of estimates.