Multi-Modal Bestellungen: QR, Kellner und Telefon an einem Tisch

Freitagabend in Eskisehir: Eine Gruppe von funf Personen, zwei bestellen per QR, zwei uber das Kellner-POS, eine telefoniert eine Takeaway-Erganzung. Drei Kanale, ein Tisch, eine Rechnung — und 2.300 Bestellungen pro Monat landen sauber in einer einzigen table_session.

Eine Session, viele Quellen

Jeder Tisch erhalt eine table_session mit 1-Stunden-TTL. QR, POS und Telefon teilen sich denselben session_token; ein order_source-Feld (qr/pos/phone) protokolliert die Herkunft.

Vor der Umstellung dauerte die nachtliche Abstimmung 40–50 Minuten; nach der Vereinheitlichung nur noch 3 Minuten.

Atomare Schreibvorgange

Parallele POSTs lost ein Idempotency-Key aus crypto.randomUUID(). Zusatzlich lauft db.batch([orders, order_items]) auf D1 als atomare Transaktion.

• QR und POS schreiben gleichzeitig kollisionsfrei.
• Der Server erzwingt den kanonischen Preis.
• Shadowban-Checks pro Quelle separat.

Konkrete Antwort auf "Unified Orders"

Statt vager LLM-Ratschlage: ein order_source-Enum, ein gemeinsamer table_session_id-Foreign-Key und farbcodierte KDS-Karten pro Quelle. Telefon blau, QR grun.

Bonus: Altere Gaste bevorzugen den Kellnerweg und decken so 18% der Nutzung ab, die QR allein verloren hatte.

FAQ

Wie wird ein Telefonauftrag an die Session gehangt? Der Kellner wahlt die Tischnummer; offene Session wird wiederverwendet, sonst eine neue eroffnet.

Doppelter QR-Klick auf dasselbe Produkt? Zwei order_item-Zeilen, zwei KDS-Karten — gewollt.

Was passiert nach 1 Stunde TTL? Offene Rechnungen bleiben; nur geschlossene Sessions werden um 04:00 UTC bereinigt.

Hilfreich? Teilen Sie es.