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

Reven Ordering, KDS, Kiosk i POS korzystają z jednego menu, tych samych reguł cenowych i wspólnego rekordu zamówienia. Dzięki temu pozycja, która jest wyprzedana lub zmieniona w menu, nie powinna wymagać ręcznej edycji w każdym kanale.

Menu

Użytkownik z menu:manage może zarządzać:

• lokalizacją, menu, publikacją i kolejnością kategorii;
• nazwą, SKU, opisem, ceną, ceną porównawczą i zdjęciem pozycji;
• oznaczeniami Vege, Vegan, New, Bestseller i poziomem ostrości;
• pokazaniem pozycji w dodatkowych kategoriach;
• stacjami przygotowania;
• grupami modyfikatorów, minimalną i maksymalną liczbą wyborów;
• opcjami, dopłatą, wartością domyślną, aktywnością i wyprzedaniem;
• pojemnością zamówień, bazowym lead time oraz strefami dostawy.

SKU jest ważne dla połączeń między lokalizacjami i voucherów na dokładną pozycję. Powinno być stabilne i unikalne w przyjętym modelu klienta.

Ordering i obsługa zamówienia

Publiczny klient albo operator POS wybiera tryb na miejscu, odbiór albo dostawę dostępną dla adresu/strefy. W publicznym Ordering, Kiosk i POS miejsce tego wyboru może być skonfigurowane przed menu albo na końcu koszyka, jeżeli lokal chce najpierw zebrać pozycje. Pozycje można dodawać od razu w wybranej ilości i później zmieniać ilość przyciskami minus/plus w koszyku albo bieżącym bilecie POS. Serwer ponownie liczy ceny, ilości, modyfikatory, opłatę dostawy albo inną opłatę realizacyjną, na przykład opakowanie na wynos, minimum, kupony, vouchery i kwotę płatności. Nie należy opierać rozliczenia na wartości przesłanej tylko przez przeglądarkę.

Dnia 2026-08-14 sprawdzono zmianę wizualną publicznego Ordering na mobile: przyciski CTA koszyka i dodawania pozycji wymuszają tekst w kolorze primary-foreground, żeby zachować kontrast przy brandowanych motywach. Zmiana nie modyfikuje logiki koszyka, checkoutu ani statusów zamówień.

Dnia 2026-08-14 sprawdzono również zmianę nawigacji kategorii w publicznym Ordering na mobile: nagłówek lokalu przewija się razem z treścią, a pasek kategorii pozostaje przypięty u góry ekranu. Zmiana poprawia dostęp do kategorii podczas przewijania menu i nie modyfikuje koszyka, checkoutu, płatności ani statusów zamówień.

Po prawidłowej płatności zamówienie może zostać przyjęte automatycznie albo czekać na personel. W trybie ręcznym personel akceptuje je i wskazuje obiecany czas. Typowa sekwencja to: opłacone → przyjęte → w przygotowaniu → gotowe → zakończone. Zwrot wymaga orders:manage i sprawdzenia wszystkich tenderów oraz wykorzystanych korzyści.

Strona statusu zamówienia jest prywatna — wchodzi się na nią tokenem z URL, a token nie jest powtarzany w metadanych — dlatego ma ustawione noindex, nofollow. Pokazuje zapisane modyfikatory i naliczone opłaty z rekordu zamówienia, aby klient mógł sprawdzić wybory po płatności. Gdy zamówienie osiągnie completed, strona pokazuje wbudowaną, prywatną ankietę Guest Experience, ale tylko wtedy, gdy moduł guest_experience jest aktywny i trigger zamówień jest włączony. Statusy cancelled, refunded oraz wszystkie niezakończone nie pokazują ankiety. Strona odpytuje się co kilka sekund i zatrzymuje po stanie terminalnym, więc ankieta pojawia się sama w momencie zakończenia, bez ręcznego odświeżania. Zakup vouchera w kiosku jest technicznie zamówieniem completed, ale nie jest realnym posiłkiem, dlatego strona statusu i resolver po stronie serwera zgodnie go pomijają.

KDS

KDS pokazuje aktywne zamówienia i pozycje według stacji przygotowania. Personel z kds:operate aktualizuje etap pracy. Ekran powinien działać na dedykowanym urządzeniu, a procedura lokalu musi uwzględniać awarię sieci i ręczne przekazanie zamówienia.

Kiosk

Gość może rozpocząć zamówienie jedzenia albo — jeżeli skonfigurowano — osobny zakup vouchera. Dla jedzenia wybiera lub potwierdza tryb odbioru, pozycje i modyfikatory, może zeskanować kartę Loyalty, kupon lub voucher, a następnie płaci pozostałą kwotę.

Panel Kioski służy do jednorazowego zapisania urządzenia i monitorowania połączenia, terminala, drukarki fiskalnej, skanera, papieru i ostatniego błędu. Lokalny agent komunikuje się z Reven wychodząco i przechowuje sekret urządzenia poza kodem frontendu.

W środowisku produkcyjnym adapter terminala musi obsługiwać stan, idempotentny start, zapytanie o wynik, odwrócenie i zwrot; adapter fiskalny — stan urządzenia, papier, fiskalizację i sprawdzenie wyniku. Niejednoznaczny wynik trzeba sprawdzić po referencji dostawcy. Nie wolno uruchamiać drugiej płatności „w ciemno”. Opłacone zamówienie jest zwalniane dopiero po wymaganej fiskalizacji, jeżeli taki przebieg jest aktywny.

POS

POS używa wspólnego menu do zamówień przy ladzie, telefonicznych i ręcznie przepisanych z marketplace. Dla użytkownika z wieloma lokalizacjami POS otwiera lokalizację z dostępnym menu; ręcznie wskazana lokalizacja bez menu kieruje personel do konfiguracji menu. POS może mieć własną konfigurację produktu pos, a brakujące pola dziedziczy z ordering, więc miejsce wyboru trybu realizacji i opłaty można utrzymać wspólnie albo rozdzielić dla POS. Dostępność płatności terminalowej zależy od wdrożonego dostawcy i urządzenia. Wprowadzając zewnętrzne zamówienie, personel powinien zachować jego referencję i nie tworzyć równoległej płatności online.

Granice rozwiązania

Reven v1 sam w sobie nie jest certyfikowaną polską kasą fiskalną. Klient zachowuje wymagany prawem proces fiskalny, chyba że zakres wdrożenia obejmuje konkretną, zatwierdzoną integrację. Sterowniki w pakiecie agentowym mogą być symulatorami; status produkcyjny musi zostać potwierdzony dla konkretnego terminala i drukarki.

Kontrola przed uruchomieniem

1. Złóż zamówienie na miejscu, na odbiór i dla każdej strefy dostawy.
2. Sprawdź cenę bazową, modyfikatory, opłatę, minimum, voucher/kupon i resztę płatności.
3. Przetestuj płatność udaną, odrzuconą, ponowiony webhook i zwrot.
4. Sprawdź tryb automatyczny i ręczny, KDS oraz obiecany czas.
5. Na realnym kiosku sprawdź bezczynność/reset, skaner, terminal, fiskalizację, brak papieru, utratę sieci i odzyskanie pracy.

Przy integracji LoyaltyPlant kiosk utrzymuje zweryfikowaną sesję klienta po stronie serwera. W trybie REGULAR można rozpocząć od karty lub poprawnego prezentu; usunięty prezent nie trafia do końcowego paragonu. Nieudana płatność nie uprawnia do ponownego obciążenia: przed nowym zamówieniem trzeba zakończyć poprzednią próbę i ponownie zeskanować kartę. Rzeczywiste naliczenie punktów należy potwierdzić u dostawcy, a nie samym udanym wywołaniem zadania.