Aseria RMS

The till, mid-order

A cashier session with a dine-in ticket open: category rail on the left, menu grid in the middle, the live ticket and its total on the right.

The ticket line is the interesting part. One item carries its default ingredients, three separate bacon additions, and free-form choices for cooking and serving — the modifier system the menu overhaul was built for, where options nest and repeat rather than being a flat checkbox list. The ticket total sits above the item price because tax and service resolve server-side at pay time, not in the UI, so the till never becomes the source of financial truth. Dine-in and take-away are tabs on the same ticket because order type changes tax treatment and kitchen routing downstream, and it has to be switchable right up to payment.

One full service flow, end to end

A complete run through the till: build the ticket, apply modifiers, switch order type, take payment, print, and hand off to the kitchen.

Worth watching for what does not happen — no spinner between steps and no reload to pick up state. Every action the cashier takes commits locally and broadcasts over the self-hosted soketi layer only after the database transaction commits, so kitchen screens and queue displays follow along in the same second without ever seeing an order that later rolls back. The footer controls — drawer, open orders, floor, print — are one tap deep on purpose: this runs on venue hardware during a dinner rush, where a second lost to navigation is a second of queue.

Self-service, in a different tenant's skin

A customer builds an order on the portrait kiosk: browse categories, configure a build-your-own item under its choice rules, then review the cart and validate.

This is the same platform as the till screens, running a completely different brand — its own palette, typeface and logo, none of it Aseria's. Tenant theming goes all the way down to the customer-facing surface, which is the difference between a multi-tenant product and a shared install. The configurator is the modifier engine made visible: groups distinguish included choices from priced upgrades, a group can cap selections ("sauces, up to 2"), extras carry per-unit quantity, and the button total recomputes against those rules as you tap. The cart then itemises every one of those choices as its own line, because the kitchen ticket and the receipt both have to reproduce exactly what was ordered. The accessibility control in the footer drops the interface into reach range — a legal requirement for unattended terminals, and easy to forget until an inspection.

Owner's view of a trading day

Day-scoped revenue, order count and refunds for one venue, split by payment method and by ordering channel, over a live order feed.

Every number here is comparative — each tile carries its delta against the equivalent prior period, because an owner reads takings as a trend, not an absolute. The location switcher in the header is what makes this multi-tenant rather than merely multi-page: the same dashboard resolves against whichever venue the signed-in user is scoped to, and the reporting queries are tenant-partitioned underneath. The channel split (POS versus kiosk) is the metric that justified the kiosk build, so it is a first-class chart rather than a report you have to go and run.

Order search and the receipt behind it

The full order ledger with compound filtering, and the reconstructed fiscal receipt for a single order opened alongside it.

The filter bar has an explicit OR/AND toggle, which is unusual in an admin table and tells you what it is really for: reconciliation. Staff arrive with a partial memory — a card payment, roughly this hour, one of two tills — and need to find the order. The drawer then rebuilds the receipt exactly as the printer produced it, down to the combo's component lines, the 8.1% VAT breakdown, the till and employee that owned the sale, and the locator number the customer was called by. Exporting it as PNG or PDF is what closes a dispute, and it is why order data is stored as an immutable record rather than a mutable row.

Idle state, before anyone touches it

The attract loop a terminal falls back to between sessions — brand mark, a single call to action, and the build number in the corner.

An idle screen is a security boundary dressed as branding: dropping to it clears the cashier session, so an unattended terminal cannot be used to ring up or void anything under someone else's login. The version string burned into the corner is deliberate — with a fleet of devices across roughly twenty locations, the fastest way to diagnose a report from the field is to have staff read the build off the screen, and it is the same identifier the APK rollout tooling targets.