Restaurant Commerce — меню, Ordering, KDS, Kiosk і POS

Reven Ordering, KDS, Kiosk і POS використовують одне меню, однакові правила ціноутворення та спільний запис замовлення. Тому продану або змінену позицію меню не потрібно вручну оновлювати в кожному каналі.

Меню

Користувач із правом menu:manage може керувати:

• локацією, меню, публікацією й порядком категорій;
• назвою позиції, SKU, описом, ціною, порівняльною ціною та зображенням;
• позначками Vege, Vegan, New і Bestseller та рівнем гостроти;
• показом позиції в додаткових категоріях;
• станціями приготування;
• групами модифікаторів і мінімальною/максимальною кількістю виборів;
• варіантами, доплатою, значенням за замовчуванням, активністю й статусом sold out;
• місткістю замовлень, базовим lead time і зонами доставки.

SKU важливий для зв’язків між локаціями та ваучерів на конкретну позицію. Він має бути стабільним і унікальним у вибраній клієнтом моделі.

Ordering та обробка замовлення

Публічний клієнт або оператор POS вибирає обслуговування в закладі, самовивіз або доставку, доступну для адреси/зони. У публічному Ordering, Kiosk і POS місце цього вибору можна налаштувати перед меню або наприкінці кошика, якщо заклад хоче спочатку зібрати позиції. Позиції можна одразу додавати в обраній кількості, а потім змінювати кількість кнопками мінус/плюс у кошику або поточному POS-квитку. Сервер заново розраховує ціни, кількість, модифікатори, вартість доставки або інший збір за виконання, наприклад пакування на виніс, мінімум, купони, ваучери й суму платежу. Розрахунок не можна базувати на значенні, переданому лише браузером.

14 серпня 2026 року перевірено візуальну зміну публічного Ordering на mobile: CTA-кнопки кошика й додавання позиції примусово використовують колір тексту primary-foreground, щоб зберігати контраст у брендованих темах. Зміна не змінює логіку кошика, checkout або статуси замовлень.

14 серпня 2026 року також перевірено зміну навігації категорій у публічному Ordering на mobile: шапка закладу прокручується разом зі сторінкою, а панель категорій залишається закріпленою зверху екрана. Зміна покращує доступ до категорій під час перегляду меню й не змінює кошик, checkout, оплату або статуси замовлень.

Після коректної оплати замовлення може бути прийняте автоматично або очікувати на працівника. У ручному режимі працівник приймає його й зазначає обіцяний час. Типова послідовність: оплачено → прийнято → готується → готово → завершено. Повернення потребує orders:manage і перевірки кожного tender та використаної переваги.

Сторінка статусу замовлення приватна — вхід за токеном з URL, а токен не повторюється в метаданих — тому для неї встановлено noindex, nofollow. Вона показує збережені модифікатори й нараховані збори із запису замовлення, щоб клієнт міг перевірити вибір після оплати. Коли замовлення досягає completed, сторінка показує вбудовану приватну анкету Guest Experience, але лише якщо модуль guest_experience активний і тригер замовлень увімкнено. Статуси cancelled, refunded та всі незавершені анкету не показують. Сторінка опитується кожні кілька секунд і зупиняється на термінальному статусі, тому анкета з’являється при завершенні без ручного оновлення. Купівля ваучера в кіоску технічно є замовленням completed, але не реальним прийомом їжі, тому сторінка статусу й серверний resolver однаково її пропускають.

KDS

KDS показує активні замовлення й позиції за станціями приготування. Працівники з kds:operate оновлюють етап роботи. Екран має працювати на виділеному пристрої, а процедура закладу — враховувати втрату мережі й ручне передавання замовлення.

Kiosk

Гість може почати замовлення їжі або, якщо налаштовано, окрему купівлю ваучера. Для їжі він вибирає або підтверджує спосіб отримання, позиції та модифікатори, може відсканувати картку Loyalty, купон або ваучер, а потім оплачує залишок.

Панель Kiosks використовується для одноразової реєстрації пристрою й контролю з’єднання, термінала, фіскального принтера, сканера, паперу та останньої помилки. Локальний агент установлює вихідне з’єднання з Reven і зберігає secret пристрою поза frontend-кодом.

У production адаптер термінала має підтримувати статус, ідемпотентний старт, запит результату, reversal і refund; фіскальний адаптер — стан пристрою, папір, фіскалізацію й перевірку результату. Неоднозначний результат потрібно перевірити за reference провайдера. Не можна «наосліп» запускати другий платіж. Оплачене замовлення передається в роботу лише після обов’язкової фіскалізації, якщо такий сценарій активний.

POS

POS використовує спільне меню для замовлень біля стійки, телефоном і вручну перенесених із marketplace. Для користувача з кількома локаціями POS відкриває локацію з доступним меню; вручну вибрана локація без меню відправляє працівника до налаштування меню. POS може мати власний config продукту pos і успадковує відсутні поля з ordering, тому крок вибору типу виконання й збори можна тримати спільними або відокремити для POS. Доступність термінальної оплати залежить від установленого провайдера та пристрою. Під час введення зовнішнього замовлення працівник має зберегти його reference й не створювати паралельний онлайн-платіж.

Межі рішення

Reven v1 сам по собі не є сертифікованою польською фіскальною касою. Клієнт зберігає потрібний за законом фіскальний процес, якщо обсяг упровадження не включає конкретну затверджену інтеграцію. Драйвери в пакеті агента можуть бути симуляторами; production-статус підтверджується для конкретного термінала й принтера.

Перевірки перед запуском

1. Створіть замовлення для обслуговування в закладі, самовивозу й кожної зони доставки.
2. Перевірте базову ціну, модифікатори, збір, мінімум, ваучер/купон і залишок до сплати.
3. Перевірте успішний і відхилений платіж, повторний webhook і повернення.
4. Перевірте автоматичний і ручний режим, KDS та обіцяний час.
5. На реальному кіоску перевірте idle/reset, сканер, термінал, фіскалізацію, відсутність паперу, втрату мережі й відновлення.

За інтеграції з LoyaltyPlant кіоск зберігає перевірену сесію клієнта на сервері. У REGULAR можна почати з картки або коректного подарунка; видалений подарунок не входить до підсумкового чека. Помилка оплати не дозволяє повторне списання: перед новим замовленням потрібно завершити попередню спробу й знову відсканувати картку. Фактичне нарахування балів перевіряють у постачальника, а не за успішною відповіддю фонового завдання.