Funktionen · Verkaufen & Kassieren
Hier bestellt der Gast selbst — ohne dass jemand vom Personal etwas eintippt. Es gibt drei Wege dafür: den eigenen Online-Shop des Betriebs (Speisekarte im Netz, Abholung oder Lieferung, bezahlt wird online oder vor Ort), den QR-Code am Tisch (der Gast scannt, bestellt vom eigenen Handy, kann seine Rechnung selbst bezahlen und den Kellner rufen) und das Bestellterminal im Lokal (ein fest aufgestellter Bildschirm, an dem der Gast tippt, bezahlt und eine Abholnummer bekommt). Dazu kommt der zweite Bildschirm an der Kasse, auf dem der Gast mitliest, was gebucht wird, und am Ende seinen Beleg als QR-Code abholen kann. Alles, was so bestellt wird, landet im selben Betrieb wie ein Vorgang an der Kasse — mit Bon, Beleg und Küchendruck.
Online-Bestellungen laufen direkt in der Kasse ein.
Echte Oberfläche
Keine Stockmotive: Die Aufnahmen stammen aus den reproduzierbaren DiKAS-Demos und zeigen die jeweilige Funktion im Produkt.
Vollständiger Überblick
Alle folgenden Punkte stammen aus dem gegen den Programmcode geprüften Funktionskatalog.
Karte, Preise, Bilder, Optionen und Nährwerte für Gäste — ohne Anmeldung, Verstecktes bleibt aussen vor. Seit 21.08.2026 liefert sie auch die Allergen-Codes und Zusatzstoffe vom Artikel (OnlineMenuItem.Allergens/Additives) plus die Klartext-Definitionen des Betriebs (AllergenDefinitions, Rückfall EU-14). Seit 05.09.2026 auch mit reiner qrselfservice-Lizenz erreichbar (OnlineMenuController = RequiresAnyModule)
Manuell ausverkaufte Artikel (Article.ManualSoldOut, Küchenmonitor 02) bleiben auf Karte/QR/Kiosk sichtbar (OnlineMenuItem.SoldOut, Badge „derzeit aus", Hinzufügen deaktiviert) und werden serverseitig abgelehnt: Shop-Checkout und QR-Bestellung mit ARTICLE_SOLD_OUT, der Kiosk über ProcessDirectSaleRequest.SelfOrder=true; Nachbestell-Warenkorb sortiert sie mit Hinweis aus
Gast wählt „ohne <Allergen>" (Mehrfachauswahl der vorkommenden Allergene) und im Shop/QR-Tisch zusätzlich vegetarisch/vegan; betroffene Artikel werden ausgeblendet, leere Gruppen verschwinden. EINE gemeinsame Filterleiste für Shop, QR-Tischbestellung und Kiosk (dort nur Allergene — der Kiosk-Artikel trägt keine Vegan-Flags). Rechtlicher Rahmen: fester Hinweis „Angaben laut Betreiber; bei Allergien bitte zusätzlich das Personal fragen" — KEINE Zusicherung, das Wort „Garantie" ist tabu (Owner-Regel). Detailansichten (Shop-Sheet, QR-Options-Overlay) zeigen Allergene und Zusatzstoffe offen sichtbar
GET /api/v1/online-menu/wait-estimate (öffentlich, Mandant über Host, seit 29.08.2026): offene Küchen-Tickets × OnlineShopConfig.AvgPrepMinutes (Default 15), Deckel 90 min; Lieferung = Abholung + DeliveryConfig.TimeDelivery; Last low/normal/high über die Schwellen LoadNormalFromTickets/LoadHighFromTickets (Default 3/8); Antwort 30 s je Mandant gecacht. Ein Ticket ist ein Bon (BonId) mit mindestens einer Küchen-Position in Arbeit (dieselbe Regel wie Küchenmonitor und Live-Puls, KitchenArticleResolver), Bons älter als 2 h zählen nicht. Shop-Startseite und Warenkorb zeigen „Abholung ab ~HH:MM · Lieferung ab ~HH:MM", der Checkout lässt keine Wunschzeit vor dem berechneten Zeitpunkt zu (das Spätere aus Vorlaufzeit und Schätzung); bei high + CloseWhenOverloaded sperrt der Shop den Bestellknopf mit Gast-Meldung und der Server lehnt mit SHOP_OVERLOADED ab; der QR-Tisch zeigt bei high einen Hinweis über der Karte, bestellt aber weiter. Verwaltung: Online-Shop → Bestellung → „Wartezeit aus der Küchenlast". readyAt/deliveryAt sind die Wanduhr des Betriebs mit Offset (DateTimeOffset aus IBetriebsZeit, z. B. 18:20:00+02:00, seit 05.09.2026 — vorher DateTime.Now, im Cloud-Pod UTC und damit zwei Stunden zu früh)
Name, Branding, Impressumsdaten und die Frage „nimmt der Betrieb gerade Bestellungen an?" — auch für den QR-Tisch (Branding, Rechtslinks, Kundenkonto-Schalter), deshalb seit 05.09.2026 onlineorder ODER qrselfservice
Warenkorb absenden, Status abfragen, vor der Bestätigung selbst stornieren (Endpunkt vorhanden, Knopf im Shop fehlt — s. 05 F3). Der Lieferauftrag entsteht bei Barzahlung sofort, bei Online-Zahlart erst nach bestätigter Zahlung (29.08.2026). Der Checkout fragt bei Lieferung Stockwerk und Klingel ab (floor, doorBell, seit 29.08.2026 P10b); sie und der Lieferhinweis (deliveryNotes) wandern über die Bridge an den Lieferauftrag und stehen dem Fahrer auf der Stopp-Karte. Seit 29.08.2026 trägt die Antwort des Anlegens einmalig guestSecret; die Statusseite heißt /shop/order/{id}?k=<secret> (Poll bleibt der Rückfall). Seit 05.09.2026 (Befund 9-05) autorisiert dieses Geheimnis JEDE anonyme Aktion an der Bestellung — GET {id}, cancel, init-payment, verify-payment, pay-with-voucher. Der Gast schickt es als Kopfzeile X-Order-Secret (ersatzweise ?s=); fehlt es oder passt es nicht, antwortet der Server 404 wie auf eine unbekannte Bestellung. Ein angemeldeter Mitarbeiter kommt ohne Geheimnis durch, ein angemeldeter Shop-Kunde (Claim portal_customer) ausdrücklich nicht
Anonymer SignalR-Hub /hubs/guest-order: Beitritt NUR mit Order-Id + Secret aus der Bestätigungs-URL, Gruppe je Bestellung und Mandant; jede Änderung an der Bestellung (NotifyDocumentChangedAsync("OnlineOrder"), alle 12 Stellen) meldet OrderChanged an genau diese Gruppe, der Gast lädt nach — Statuswechsel erscheint unter 2 s. Falsches Secret ⇒ keine Gruppe. MAUI hostet keinen Hub, dort bleibt der 15-s-Poll
Bei „unterwegs" zeigt die Statusseite zusätzlich „Dein Fahrer ist n Stopps entfernt — noch ca. m min" bzw. „kommt als Nächstes zu dir" (driverStopsAway, driverEtaMinutes an der Bestell-Antwort, fünf Gast-Sprachen). Die Zahlen kommen aus der Tourreihenfolge und der Live-Restfahrzeit des Fahrers und stehen nur da, wenn der Betrieb „Standort während der Tour" eingeschaltet hat und eine frische Meldung vorliegt — sonst bleibt die Zeile weg. Ohne Karte, ohne Punkt, ohne Koordinate (Owner-Vorgabe): der anonyme Endpunkt liest dafür nur den Arbeitsspeicher des Servers (kein Dokument, keine Datenbank) und gibt ausschließlich Stopp-Zahl und Minuten heraus
Opt-in-Knopf auf der Statusseite (VAPID, Service Worker gast-push-sw.js — nur Push, KEIN Caching); Subscription hängt an der Bestellung (max. 5). Bei „fertig"/„unterwegs" Push in der Sprache des Gastes (de/es/en/fr/it) und eine Status-Mail über die IEmailQueue-Outbox, nur wenn der Mandant SMTP hat; je Status genau einmal (GuestNotifiedStatus), erloschene Subscriptions (404/410) fliegen raus. Seit 29.08.2026 (P10b) zusätzlich der Fahrer-Push „Deine Bestellung kommt in 5 min" (NotifyDriverArrivalCommand, dieselben Subscriptions, Sperrfrist 3 min) und die Statusseite zeigt bei „unterwegs" driverArrivalAt („Dein Fahrer ist gleich da — etwa {time}"). Push ist AUS, bis WebPush__VapidPublicKey/__VapidPrivateKey gesetzt sind — der Knopf erscheint dann gar nicht. Ohne Fremdpaket: RFC 8291/8292 in reinem .NET
GET /api/v1/online-menu/manifest.webmanifest?start=/shop: Name = Betrieb, Farben und Icon (Logo, sonst Favicon) aus der Shop-Konfiguration; die Gast-Oberfläche hängt den <link rel=manifest> zur Laufzeit ein, weil index.html für Kasse und Gast dieselbe ist
Zahlung starten und serverseitig verifizieren, auch ohne Webhook. Stripe Payment Element (Karte, Apple Pay, Google Pay — Wallets hängen nur am Dashboard, s. StripePaymentMethodTypes); seit 29.08.2026 auch PayPal (Redirect-Fluss, Schalter OnlineShopConfig.PayPalEnabled + Client-Id/-Secret in der BackendConfig; Capture beim Verify) und Trinkgeld im Checkout (nur bei Online-Zahlung, OnlineOrder.TipAmount, im Zahlbetrag, am Beleg Receipt.TipAmount wie beim Tischweg)
Guthaben prüfen und die Bestellung bei Volldeckung ganz per Gutschein bezahlen — Stripe bleibt aussen vor
Erzeugt idempotent den Beleg am Zahlungszeitpunkt (Nummer aus dem gemeinsamen seq_receipt-Kreis, Steueraufschlüsselung, Zahlbeine). Ob er TSE-signiert wird, entscheidet der Vor-Ort-Bezug — Abgrenzung in 11 Fiskal Deutschland
Neue Bestellungen sehen, annehmen, ablehnen, Status weiterschalten (Neu / In Arbeit / Fertig / Erledigt)
Branding, Farben, Theme, Öffnungszeiten, Bestell- und Zahlungsoptionen, Artikel-Sichtbarkeit. Im Zahlungsreiter bleiben Anbieter-Aktivierung, Barzahlung und Vorkasse; die mandantenweiten Stripe-/PayPal-Zugangsdaten liegen zentral unter Hardware → Zahlungsoptionen
Bilder hochladen (werden nach WebP gewandelt) und öffentlich ausliefern; der Metadaten-Save führt die durch den CouchDB-Anhang entstandene Revision weiter
Impressum, Datenschutz, AGB und Widerrufsbelehrung aus den Firmendaten generieren
Händlernummer (FUC), Terminal-Nr., Signaturschlüssel und Test-/Produktivumgebung in Einstellungen → Kasse → Bizum (Redsys). Nur auf ES-Deployments sichtbar (configService.isSpain(), gleiche Regel wie gestoria/verifactu). Der Schlüssel wird verschlüsselt gespeichert, die Antwort trägt nur hasRedsysSecretKey, ein leeres Feld heißt „unverändert lassen". Vollständig übersetzt de/en/es — die einzige Einstellungsmaske, für die das gilt. Bis 06.09.2026 gab es diesen Weg nicht: die vier Felder standen an der BackendConfig und wurden von BizumPaymentProvider gelesen, aber in keinem HTTP-Vertrag — einrichten konnte Bizum nur, wer die Datenbank aufmacht
Prüft unter Hardware → Zahlungsoptionen, ob die zentral hinterlegten Schlüssel wirklich funktionieren; die Maske erscheint auch bei reiner QR-Tisch-, Reservierungs- oder Disco-Nutzung
Webtitel, Beschreibung, SEO-Text, Kennzeichnungen und Bildergalerie je Artikel; Hauptbild/Thumbnail und Galerieliste werden revisionssicher in demselben CouchDB-Dokument geschrieben
Schlägt aus dem Artikelnamen einen Beschreibungstext vor — Entwurf, wird nicht selbst gespeichert
Registrieren, anmelden, Passwort zurücksetzen, Bestellhistorie. Anlegen ist seit 05.09.2026 gedrosselt (Politik aushang, 60/min je IP — Befund 9-06); login bleibt bewusst ohne eigene Drossel, dort greift die Konto-Sperre nach fünf Fehlversuchen
Aus einer früheren Bestellung einen neuen Warenkorb bauen, gegen die aktuelle Karte geprüft
Kachel unter dem Hero für erkannte Gäste: mit Konto die jüngste abgeschlossene Bestellung über den Server-Nachbestellweg; ohne Konto die im Browser gemerkte letzte Bestellung (localStorage, nur Artikel/Optionen/Mengen — keine Adresse), die der anonyme E-Mail-Lookup (customer-lookup, liefert bewusst nur found) als Kunde bestätigt. Vor dem Anzeigen gegen die aktuelle Karte geprüft (nicht mehr drauf, „derzeit aus", Optionen weg, Preis anders — dieselben vier Fälle wie BuildReorderCartQuery); nichts Bestellbares = keine Kachel; Hinweise erscheinen in der Kachel, sonst geht es direkt in den Warenkorb
Suchfeld über der Kategorie-Leiste (Tisch) bzw. über dem Kategorie-Raster (Kiosk); mit Suchtext gilt die Kategorie-Auswahl nicht, gesucht wird über die ganze (erlaubte) Karte in Name, Web-Titel und Beschreibung. EINE Trefferregel für alle drei Flächen (menuItemMatchesQuery/filterGroupsByQuery), die Shop-Startseite nutzt dieselbe
Bis zu drei Vorschläge als reine Regel, kein ML: der Wirt pflegt am Artikel (Web-Reiter, Feld SuggestGroupIds) Gruppen, aus denen vorgeschlagen wird; ohne Pflege fällt der Shop bei einer Speise ohne Getränk auf die Getränkegruppe der Karte zurück (Namensregel de/es/en/fr/it). Nie vorgeschlagen: schon im Korb, „derzeit aus", Artikel mit Pflichtoptionen. Ein Tipp legt den Artikel in den Korb
Im Reiter „Bestellungen" trägt jede Position einen Knopf „Nochmal": ohne Optionen landet der Artikel sofort im Warenkorb und der Korb öffnet sich; mit Optionen (Pflicht oder damals gewählt) öffnet sich der Artikel-Dialog mit vorbelegten Optionen. Nicht mehr auf der Karte oder „derzeit aus" → kein Knopf, sondern Hinweis. Braucht TableOrderBillItem.ArticleId (seit 29.08. am Bon-Item)
Initialen des Artikelnamens auf der Gruppenfarbe (gepflegte Farbe, sonst feste Palettenfarbe aus dem Gruppennamen — deterministisch) statt leerer Fläche; EINE Komponente für Shop, QR-Tisch, Kiosk und die Passt-dazu-Karten
Fiskalischen Beleg als PDF laden oder per Mail schicken, Bewirtungsbeleg erzeugen
Prüft die Adresse vor dem Absenden gegen die Lieferzonen (PLZ-Liste, sonst echte Fahrstrecke) und nennt Zone, Liefergebühr und Lieferzeit; Adresssuche mit Autovervollständigung
Prüft anonym, ob zu einer E-Mail ein Kunde existiert — nur Ja/Nein, keine Personendaten; streng ratelimitiert
Lehnt der Betrieb eine bezahlte Bestellung ab (oder storniert er sie), wird der fiskalische Beleg bestandsneutral gegen gebucht und die Stripe-Zahlung automatisch erstattet — seit 29.08.2026 auf allen Wegen: Reject aus der Online-Liste, Status 6 UND Storno-Knopf der Lieferansicht (DELETE /delivery/{id}); Reject/Gast-Storno stornieren umgekehrt den Lieferauftrag mit. Reject ist idempotent (bereits abgelehnt/storniert = folgenlos)
Dienst gleicht alle zwei Minuten offene Online-Zahlungen direkt mit Stripe ab — fängt bezahlte Bestellungen, deren Gast nie auf der Erfolgsseite ankam; ersetzt den Webhook
Gast scannt den Tisch-QR, sieht die Karte und bestellt vom eigenen Handy
Mehrere Gäste an einem Tisch bekommen getrennte Bons, Sitzplatz per Cookie gemerkt
Gast sieht seine offenen Positionen — nur seinen Platz oder den ganzen Tisch
Zahlung über den Zahlungsanbieter starten und bestätigen, Bon wird abgerechnet; Trinkgeld (Prozent/Aufrunden/frei) rechnet seit 29.08.2026 shop/tip-calc.ts — dieselbe Quelle wie der Webshop-Checkout; Stripe.js kommt für alle Gastwege aus shop/stripe-loader.ts (vorher vier Kopien)
Bezahlen-Reiter mit drei Modi: alles (Platz/Tisch) · Positionen anhaken · durch n Personen teilen (Betrag = offen/n, wer zuletzt zahlt, übernimmt den Rest-Cent). Jede Teilzahlung mit eigenem Trinkgeld und eigenem Beleg NUR über das Gewählte (beim Anteil: jede Position anteilig als Bruchmenge, Artikel/PLU/Steuersatz/Arbeitsplatz bleiben nachvollziehbar); der Rest bleibt am Tisch offen, der Kellner kassiert ihn normal. Bereits bezahlte Positionen verschwinden bei den anderen Gästen binnen 15 s; wer trotzdem eine schon bezahlte schickt, bekommt 409 mit übersetzter Gastmeldung, nichts wird gebucht. Seit 05.09.2026: Laden → Prüfen → Beleg → TSE → Bons laufen je (Mandant, Tisch) serialisiert (SemaphoreSlim, In-Process — dikasnext bleibt replicas=1); trifft der 409 erst NACH dem Karteneinzug, erstattet der Server sofort beim Anbieter (RefundPaymentAsync, Antwort refunded) und der Gast liest „erstattet" bzw. „bitte ans Personal"; jeder Teil- UND Restbeleg trägt Cent-Beträge (Cent-Verteilung auch bei der vollen Zahlung); Stripe/PayPal-Intent in der Instanzwährung (OnlinePaymentCurrency)
Ruf vom Handy an den Kassenbereich, z. B. um bar zu zahlen
Pro Tisch einen neuen QR-Token erzeugen (alter wird ungültig), einzeln oder alle Tische einer Gruppe als Blatt drucken, Link kopieren, lokal testen
Schalter, Auto-Bestätigung und Tokenwechsel beim Tagesabschluss. Ohne onlineorder werden Bestellungen zwingend sofort als offene Bons gebucht, weil es keine Annahmeliste gibt.
Fest aufgestellter Bildschirm: Gast wählt, bezahlt am Terminal und bekommt einen Bon
Je Automat eigener Bondrucker und eigenes Kartenterminal, Adresse /selforder/<Nr>
Nach der Zahlung wird eine Nummer vergeben; der Gast wartet darauf
Bildschirm mit den laufenden und den zuletzt fertigen Nummern
/shop/abholung auf der Gäste-Domain (seit 29.08.2026): derselbe Feed wie der Abhol-Monitor (GET /api/v1/selforder/tickets, 5-s-Takt, fertige 5 min sichtbar), nur Nummern — keine Namen, Artikel oder Belege. Der Gast liest sie auf dem eigenen Handy
Was noch bestätigt werden muss, ältestes zuerst; Küche und Theke melden getrennt fertig
Zweiter Bildschirm zum Gast: laufender Warenkorb, danach der Beleg, im Leerlauf eine Bilderschleife
Sechsstelliger Code am Bildschirm, Eingabe an der Kasse — oder automatische Kopplung im Kiosk-Betrieb
Nach der Zahlung erscheint der Beleg als QR-Code; die Ziel-Adresse baut ausschließlich der Server
Unter dem geöffneten Beleg (/r/:id/:secKey) fragt der Gast-Bildschirm 1–5 Sterne und optional einen Satz ab — genau einmal je Beleg, der Beleg-Schlüssel ist der Zugang. Ab 4 Sternen erscheint der Link zum Google-Bewertungsprofil, wenn im Shop unter „Bewertungen" eines hinterlegt ist; darunter nur ein Dank, keine Weiterleitung. Gespeichert werden nur Sterne, Text, Belegnummer — kein Name (GuestFeedback). Beim aus dem QR rekonstruierten Beleg gibt es kein Formular. Auswertung: 15
Slideshow-Bilder/-Videos und Willkommen-Medium bis 100 MB hochladen/löschen, Wechselintervall der Bilderschleife (3–120 s) einstellen
/rest/online/{key}/… für Fremdsysteme: Artikel, Tische, Drucker, Bestellung anlegen/öffnen/bezahlen. Zugang per API-Schlüssel (Zugriffsart Online-Bestellung/Buchungen) — KEIN Lizenzmodul-Gate. /order und /open legen eine unbezahlte Lieferbestellung an; /pay bucht seit 18.08.2026 einen vollwertigen Kassenbeleg (Belegnummer, TSE, Kassenbuch, Tagesabschluss) und KEINE Lieferbestellung mehr
/rest/extern/{key}/tabletop/… für kartenbasierte Zapf-/Tischsysteme
Kein Treffer in diesem Bereich. Gesamte Website durchsuchen
Oft gesucht
Weiterstöbern
Marketing-Cookies erlauben?
Wir würden gerne mit Google Ads messen, welche Anzeigen zu einer Anmeldung führen. Dafür werden Cookies gesetzt und Daten an Google (USA) übertragen — nur mit deiner Einwilligung. Unsere anonyme Reichweitenmessung (Matomo) läuft davon unabhängig. Details und Widerruf in der Datenschutzerklärung.
