Piatkowy wieczor w Eskisehir: piecioro gosci przy stole. Dwoje zamawia przez QR, dwoje przez POS kelnera, piaty dzwoni po dodatek na wynos. Trzy kanaly, jeden stol, jeden rachunek — i 2300 zamowien miesiecznie trafia czysto do jednej table_session.
Jedna sesja, wiele zrodel
Kazdy stol otwiera table_session z TTL 1 godziny. QR, POS i telefon dziela ten sam session_token; pole order_source rejestruje pochodzenie.
Uzgodnienie zamkniecia spadlo z 40–50 minut do 3 minut.
Atomic writes
Rownoczesne POST obsluguje Idempotency-Key z crypto.randomUUID() i atomic db.batch() w D1.
- QR i POS bez kolizji.
- Serwer wymusza cene kanoniczna.
- Shadowban per zrodlo.
Techniczna odpowiedz na "Unified Orders"
Konkretnie: order_source enum, wspolny FK table_session_id i kolorowane karty KDS wedlug zrodla. Telefon niebieski, QR zielony.
Starsi goscie wola droge przez kelnera, zachowujac 18% uzycia.
FAQ
Jak zamowienie telefoniczne trafia do wlasciwej sesji? Kelner wybiera numer stolu; otwarta sesja jest reuse'owana lub tworzona nowa.
Dwa QR dodaja to samo jednoczesnie? Dwa wiersze order_item, dwie karty KDS — zamierzone.
Co po wygasnieciu TTL? Otwarte rachunki zachowane; cron 04:00 UTC sprzata tylko zamkniete sesje.
Czy to było pomocne? Udostępnij.
Powiązane artykuły
Czym jest menu QR? Kompletny przewodnik dla restauracji
Menu QR umożliwia klientom natychmiastowy dostęp do karty dań przez smartfon — b…
Przejście z papierowego na cyfrowe menu QR: przewodnik krok po kroku
Chcesz wdrożyć menu QR, ale nie wiesz od czego zacząć? Ten przewodnik obejmuje f…
Geo-targetowane menu QR: różne języki w zależności od IP gościa
Jak resort all-inclusive na 180 miejsc w Antalyi kieruje ten sam kod QR do menu …