Restaurant POS in Egypt for a fast, connected service

Ramlyon turns the menu you already manage into a focused restaurant POS for dine-in and takeaway orders. Cashiers search and tap the same live items guests see, configure variants and add-ons, attach the customer and table, and send a server-checked order into the restaurant workflow. It is an Operations feature built for the counter, not a generic accounting screen.

A cashier screen with the restaurant in front

The POS opens as a full-screen workspace without the normal dashboard sidebar. Staff can search dishes, filter by category and tap an item to add it. An item can carry required or optional choices, single or multiple selections, add-ons and price differences. Unavailable dishes stay visible but greyed out, so the cashier can explain that an item exists but is unavailable today.

The order cart supports quantities, item configuration and order notes. A customer with a phone number is attached before the order is created; staff can find an existing diner or create one with a name and phone during the sale. The cashier can select a named table for dine-in or choose takeaway. Delivery fulfilment, addresses and driver assignment are not part of this POS promise.

A staff member with the right permission can apply a fixed or percentage manual discount to the ticket. That permission is separate from the ability to manage public discount-code campaigns. Tax and service settings use the same pricing rules as web checkout, with inclusive and exclusive treatment kept distinct from whether a line is displayed.

Totals checked again on the server

The browser calculates a total for immediate feedback, but it is not trusted as the final authority. Ramlyon rebuilds item pricing and derived totals before the order is saved. Money is handled in integer minor units rather than floating-point decimals. Item names, chosen options, prices, customer details, table, currency, tax and service settings are snapshotted onto the order so a later menu edit does not rewrite yesterday's sale.

Orders are not deleted from the operational history. Cancelling moves an order to the cancelled status and can retain a reason. This keeps the timeline and reporting source honest without claiming refund processing or payment reconciliation that the product does not provide.

Decide how POS orders enter service

One setup switch determines the starting point. A POS ticket can go directly to Preparing, ready for the kitchen, or arrive as Pending for confirmation first. From there the shared order flow moves through Pending, Preparing, Ready and Done, with Cancelled as a separate final state. Each transition stamps its own time so operational analytics can measure the steps.

The same order appears on the relevant order pages and live kitchen display. New orders and changes are pushed to open staff screens rather than discovered by constant polling. A new order can trigger an in-app chime and toast on an open dashboard. The system validates transitions, so an old device cannot revive a cancelled ticket or jump a completed order into an invalid state.

Keep working through a weak connection

The Ramlyon dashboard is installable and the POS order domain is built for offline work. A cashier can create and edit orders while disconnected; supported intentions queue on the device and replay when connectivity returns. Client-minted identifiers and idempotency keys prevent a retry from creating the same ticket twice.

Order changes are sent as narrow intentions—such as changing status, editing lines or updating details—rather than uploading one whole stale order. If two devices change different parts of a ticket, those changes can merge without one silently overwriting the other. When the server rejects an offline action, the interface reconciles to the authoritative result instead of pretending the write succeeded.

Offline capability does not turn a local device total into the financial authority. On replay, the server still applies the current validation and recalculates derived money before accepting the stored order.

POS is part of the Operations plan

The restaurant POS, order management, real web ordering, kitchen display and their staff permissions are included in Operations. The Menu plan provides the public QR menu and WhatsApp ordering without a cashier POS or managed order pipeline. Both use the same menu data, so upgrading does not require re-entering dishes. See current pricing and inclusions on the pricing page.

Ramlyon is not presented as inventory, payroll, supplier accounting or a refund processor. Its POS scope is taking a configured restaurant order, validating its price, connecting it to customer and table context, and moving it through service.

Restaurant POS questions

Can the POS handle dine-in and takeaway?

Yes. Staff can attach a named table for dine-in or mark the ticket as takeaway. This page does not claim a delivery-address or driver workflow.

Can a POS order wait for approval before the kitchen sees it as preparing?

Yes. The restaurant can choose whether POS orders start Pending for confirmation or go directly to Preparing.

Does the cashier's browser decide the final total?

No. The interface gives an immediate calculation, then the server recomputes and validates the order before saving it.

Does the restaurant POS work offline?

Supported order creation and edits queue locally and replay after reconnect. The server remains authoritative when those changes synchronize.

Put the menu and the till on the same data

Create a Ramlyon account to start with your restaurant menu, and review the Operations plan when you are ready to run the POS and order workflow.