Restaurant Commerce — Menu, Ordering, KDS, Kiosk and POS

Reven Ordering, KDS, Kiosk and POS use one menu, the same pricing rules and a shared order record. As a result, an item that is sold out or changed in the menu should not require a manual edit in every channel.

Menu

A user with menu:manage can manage:

• the location, menu, publication and category order;
• an item's name, SKU, description, price, compare-at price and image;
• Vege, Vegan, New and Bestseller labels and spice level;
• display of an item in additional categories;
• preparation stations;
• modifier groups and minimum and maximum selections;
• options, surcharge, default value, active status and sold-out status;
• order capacity, base lead time and delivery zones.

SKU is important for links between locations and vouchers for an exact item. It should be stable and unique within the customer's chosen model.

Ordering and order operation

The public customer chooses dine-in, pickup or delivery available for the address or zone. The server recalculates prices, modifiers, delivery fee, minimum, coupons, vouchers and the payment amount. Settlement must not rely on a value sent only by the browser.

After a valid payment, an order can be accepted automatically or wait for staff. In manual mode, staff accept it and provide a promised time. A typical sequence is: paid → accepted → preparing → ready → completed. A refund requires orders:manage and a review of every tender and benefit used.

KDS

KDS shows active orders and items by preparation station. Staff with kds:operate update the work stage. The screen should run on a dedicated device, and the venue's procedure must cover a network outage and manual handoff of the order.

Kiosk

A guest can start a food order or — when configured — a separate voucher purchase. For food, the guest chooses the fulfilment mode, items and modifiers, can scan a Loyalty card, coupon or voucher, and then pays the remaining amount.

The Kiosks dashboard is used to enrol a device once and monitor its connection, terminal, fiscal printer, scanner, paper and latest error. The local agent communicates outbound with Reven and keeps the device secret outside frontend code.

In production, the terminal adapter must support status, idempotent start, result query, reversal and refund; the fiscal adapter must support device status, paper, fiscalisation and result verification. An ambiguous result must be checked against the provider reference. Do not start a second payment “blindly.” A paid order is released only after required fiscalisation when that flow is active.

POS

POS uses the shared menu for counter orders, phone orders and orders manually copied from a marketplace. Terminal-payment availability depends on the deployed provider and device. When entering an external order, staff should preserve its reference and not create a parallel online payment.

Solution boundaries

Reven v1 is not, by itself, a certified Polish fiscal cash register. The customer retains the legally required fiscal process unless the implementation scope includes a specific approved integration. Drivers in the agent package may be simulators; production status must be confirmed for the specific terminal and printer.

Pre-launch checks

1. Place a dine-in order, pickup order and an order for every delivery zone.
2. Check the base price, modifiers, fee, minimum, voucher/coupon and remaining payment.
3. Test successful payment, declined payment, repeated webhook and refund.
4. Check automatic and manual modes, KDS and the promised time.
5. On a real kiosk, check idle/reset, scanner, terminal, fiscalisation, paper-out state, network loss and recovery.