Lieferauftrag anlegen
Abhol- oder Lieferauftrag mit Kunde, Adresse, Wunschzeit und Positionen erzeugen; vergibt die tägliche Bestellnummer
Funktionen · Verkaufen & Kassieren
Lieferdienst
Hier wird alles verwaltet, was das Haus verlässt oder abgeholt wird: eine Bestellung wird angenommen — am Telefon, an der Kasse, aus dem eigenen Online-Shop oder von einer Lieferplattform wie Lieferando, Wolt oder Uber Eats — bekommt eine Bestellnummer und läuft dann durch feste Schritte vom Bestätigen über die Küche bis zum „unterwegs" und „abgeschlossen". Aus der Adresse ermittelt das System automatisch Koordinaten, das passende Liefergebiet und damit Liefergebühr und Mindestbestellwert. Für die Auslieferung lassen sich Aufträge einem Fahrer zuweisen, zu einer Tour bündeln, die Reihenfolge optimieren und als Kartenlink oder QR-Code an das Handy des Fahrers geben; der Fahrer sieht seine Aufträge in einer eigenen mobilen Ansicht. Bezahlt werden kann vorab an der Kasse oder erst bei der Übergabe an der Haustür. Der eigene Bestellshop für Gäste liegt daneben (siehe Selbstbedienung & Online), das Kassieren selbst in Kasse & Zahlungen.
48 geprüfte Funktionen
Funktionsstand 07.09.2026
Offene Lieferaufträge zentral bearbeiten.
Echte Oberfläche
Lieferdienst in DiKAS
Keine Stockmotive: Die Aufnahmen stammen aus den reproduzierbaren DiKAS-Demos und zeigen die jeweilige Funktion im Produkt.
Vollständiger Überblick
Was DiKAS in diesem Bereich kann
Alle folgenden Punkte stammen aus dem gegen den Programmcode geprüften Funktionskatalog.
Bestellart an der Kasse
Im Kassenvorgang zwischen Lokal / Abholung / Lieferung umschalten, Adresse und Wunschzeit erfassen
Telefon-Modus der Kasse (Bestellannahme am Telefon)
Route pos/telefon (Menü-Kachel „Telefonannahme", Telefon-Knopf in der Kasse, „Annehmen" im Anruf-Popup): DIESELBE Kasse im Drei-Spalten-Layout — links Anrufer-Panel (Suchfeld mit Fokus, Ziffernblock genügt, ab 3 Ziffern Treffer, Enter nimmt den ersten; unbekannte Nummer → „Neuer Kunde" mit vorbelegter Nummer, nur Name + Adresse mit Adress-Autocomplete; Lieferadressen des Kunden zum Antippen) und darunter die letzten 5 Bestellungen (Lieferaufträge + Online) mit ⊕ je Position und „alles ⊕" — gegen die heutige Karte geprüft: ausgelistet grau, „derzeit aus" gesperrt, Preis heute, Optionen per Id/Name übernommen, „ab 18" schon am ⊕ (die Kasse fragt vor dem Buchen); Mitte das bestehende Artikelraster (Gruppen als Reiter); rechts der bestehende Korb + Abschluss-Panel (Bestellart, Wunschzeit-Chips sofort/+30/+45/um …, voraussichtliche Zeit aus TimeSelf/TimeDelivery, Zone + Gebühr aus der Adresse, Mindestbestellwert-Hinweis, Zahlart-Chips bar · Karte an der Tür · schon bezahlt → paymentMethod am Auftrag, Bemerkung, Vorlesen Groß in Ansage-Reihenfolge, Aufgeben = „Bestellung aufgeben mit Küchenbons"; danach „Nummer · Zeit · Betrag" zum Ansagen und leeres Suchfeld). Vorbelegung aus der letzten Bestellung: Bestellart, Adresse, Zahlart, Wunschzeit-Muster. Standardfall = Nummer → Enter → „alles ⊕" → Aufgeben (4 Aktionen; vorher über das Overlay ≥ 8). Kein Numpad im Telefon-Modus — die Tastatur gehört dem Suchfeld
Bestellung aufgeben (mit Küchenbons)
Auftrag anlegen und dabei die Küchenbons erzeugen, ohne zu kassieren. Seit 28.08.2026 mit Options-Aufpreis: die Kasse schickt als overridePrice den FERTIGEN Stückpreis (Positionswert ÷ Menge, wie der Direktverkauf), der Server nimmt ihn unverändert; fehlt er (alter Client), baut der Server ihn aus Artikelpreis + Optionen (Prozent auf den Grundpreis, Abwahl zieht ab). OpenBon.Price, DeliveryOrderItem.UnitPrice/TotalPrice und GrandTotal tragen ihn — und damit auch das spätere Kassieren (PayDeliveryOrderCommand)
Bestellhistorie je Kunde (Telefon-Modus)
GET /api/v1/delivery/customers/{id}/recent-orders?take=5 — die letzten Lieferaufträge und Online-Bestellungen des Kunden, zeitlich gemischt, stornierte/abgelehnte und blosse Warenkörbe ausgenommen; jede Position mit Menge, damaligem Stückpreis, Bemerkung und Optionen (bei Lieferaufträgen samt Options-Id aus dem Küchenbon, bei Online-Bestellungen nur der Name; die automatische Pfandposition fällt weg). Eine Online-Bestellung, die als Lieferauftrag weiterlebt, kommt nur einmal. DeliveryOrder trägt dafür seit 29.08.2026 IHasCustomerId (indizierter Kundenzugriff statt Vollscan)
Altersfreigabe im Lieferweg (Jugendschutz)
Trägt eine Position ein Mindestalter, verlangt schon die Auftragsannahme eine Bestätigung (verifiedMinAge, sonst AGE_VERIFICATION_REQUIRED); das Ergebnis hängt am Auftrag (DeliveryOrder.VerifiedMinAge). Kasse und Fahrerausgabe können zusätzlich quittieren — es gilt der höhere Wert, und er wird seit 05.09.2026 an den Auftrag geschrieben (PayDeliveryOrderCommand, DispatchDeliveryOrdersCommand), nicht nur in den Sale-Command. Ein Auftrag ohne Quittung wird bei der Ausgabe nicht herausgegeben und kommt in ageVerificationOrderIds zurück; die Lieferliste fragt nach (Fahrer-Quittung) und gibt ihn dann aus
Statuswechsel / Workflow
Neu → Bestätigt → Zubereitung → Bereit → Unterwegs → Erledigt; Zwischenschritte abschaltbar. Seit 29.08.2026 (P10a): der Schritt Bereit → Unterwegs ist für Lieferungen über den Status-Knopf zu (TOUR_REQUIRED, auch mit Beleg) — auf Tour geht ein Auftrag nur über „Mitnehmen"; der Übergang auf „Bereit" stempelt ReadyAt (Basis der Wartezeit-Ampel)
Liefergebiete & Gebühren
Zonen über PLZ-Liste oder Fahrdistanz, je Zone Liefergebühr und Mindestbestellwert. Seit 07.09.2026 (Befunde T5/T6) sagt der Auftrag, ob die Zone GEMESSEN wurde: fällt das Geocoding komplett aus (GEOCODING_FAILED) oder hat der Betrieb keinen eigenen Standort hinterlegt (STORE_LOCATION_MISSING), trägt er DeliveryFeeUndetermined und die Lieferansicht zeigt „Liefergebühr nicht ermittelbar — bitte prüfen". Vorher endeten beide Fälle in derselben stillen 0 EUR ohne Mindestbestellwert-Aufschlag, ununterscheidbar von „liegt in keiner Zone". Ist nur die Fahrstrecke nicht zu haben (Valhalla aus) und wurde über die Luftlinie bestimmt, sagt DistanceEstimated „Entfernung geschätzt" — Luftlinie ist systematisch kürzer und kann in eine günstigere Zone schieben. 🪤 Eine aufgelöste Adresse außerhalb aller Zonen ist KEIN Ausfall und trägt nichts davon
Mindestbestellwert-Aufschlag
Fehlbetrag als eigene Position aufschlagen — oder die Bestellung ganz ablehnen
Kostenfreie Lieferung ab Schwellwert
Ab einem einstellbaren Bestellwert entfällt die Zonen-Liefergebühr (NoDeliveryFeeAmount)
Adresssuche & Geocoding
Adresse vervollständigen und in Koordinaten auflösen (Google) — Basis für Zone und Route
Fahrer zuweisen (= Reservierung)
Seit 29.08.2026 (P10a) eine RESERVIERUNG: Tresen tippt Karte, tippt Fahrer → ReservedDriverId/-Name/ReservedAt am Auftrag, kein Statuswechsel, kein Beleg, keine Plattformmeldung. DriverId heißt ab jetzt „ist auf Tour" und wird nur noch von „Mitnehmen" gesetzt. Ein Auftrag, der schon unterwegs ist, wird abgewiesen (ORDER_ON_TOUR) — dafür „Fahrer umsetzen". Umreservieren auf einen anderen Fahrer geht jederzeit
Fahrer umsetzen (Tour zurückgeben)
Auftrag, der unterwegs ist, auf einen anderen Fahrer umbuchen; hat der Auftrag einen Beleg, fragt die Lieferansicht seit 29.08.2026, ob der alte Fahrer schon kassiert hat (Beleg bleibt bei ihm) oder der Beleg zum neuen Fahrer wandert — cashAlreadyCollected wird immer gesendet. Vor der Tour braucht es das nicht: dort wird einfach umreserviert
Mitnehmen (= Dispatch / Fahrerausgabe / StartTour)
Der EINZIGE Weg auf „unterwegs" (seit P10a auch für bezahlte Aufträge): Tresen-Tablet (Knopf „Mitnehmen" im Bereit-Regal → „Wer fährt?" → Vorschlag) oder Fahrer-Handy (Panel oben in „Meine Lieferungen"). Zeigt den Tour-Vorschlag und die Beutel-Checkliste je Stopp; Stopps ab-/zuwählbar; erst wenn jeder gewählte Stopp abgehakt ist, geht der eine Tipp. Server: für unbezahlte Aufträge entsteht der Bar-Beleg in der Wechselkasse des Fahrers (Druck auf dem Lieferdrucker), DriverId + Status „unterwegs" + TourStartedAt, Reservierung gelöscht, Shop/Plattform benachrichtigt. Scheitert der Beleg, bleibt der Auftrag ohne Fahrer liegen (errors). Seit 05.09.2026 (Review A, Befund 1) schließt der Dispatch KEINE Vortour mehr ab: hat der Fahrer noch Stopps „unterwegs", die nicht mitgeschickt sind, antwortet der Server ohne confirmOpenOrders mit stillOpenOrderIds/stillOpenOrderNumbers und gibt NICHTS aus; Lieferansicht, Mitnehmen-Panel und Tafel fragen nach („#90 noch offen — neue Tour trotzdem starten?") und schicken mit confirmOpenOrders=true erneut. Die offenen Stopps bleiben in jedem Fall „unterwegs" (mit ihrem DriverIssue) — erledigt werden sie nur über die Übergabe oder die Kasse. Ein bereits erledigter Auftrag wird wie ein stornierter abgewiesen (Fehlerzeile, nichts angefasst). B11 (optimistische Nebenläufigkeit): die Oberfläche schickt je Auftrag die Dokumentversion (expectedRevisions); weicht sie ab, ist der Auftrag für einen anderen reserviert oder schon mit einem anderen Fahrer unterwegs, wird er NICHT ausgegeben (conflictOrderIds); wurde gar nichts ausgegeben, antwortet der Endpunkt 409 DISPATCH_CONFLICT und die Oberfläche lädt neu. Jeder Auftrag wird einzeln gespeichert, ein DOCUMENT_CONFLICT trifft genau ihn
Bereit-Regal + Wartezeit-Ampel
Reiter „Lieferungen": fertige Lieferungen ohne Fahrer als Karten, älteste zuerst (ReadyAt, sonst letzte Änderung), Farbe nach Wartezeit aus DeliveryConfig.ColorTimesPacking (grün < grün-Minuten, gelb < gelb-Minuten, sonst rot — die Farbzeiten haben damit seit 29.08.2026 einen Leser). Tipp auf die Karte = Fahrer reservieren; Reservierung als Lesezeichen-Badge. Gleiche Ampel im Mitnehmen-Panel (Stopp-Nummer)
Tour-Vorschlag
Reine Funktion: Reservierungen des Fahrers zuerst, sonst der älteste fällige Auftrag als Anker (Wunschzeit vor Fertigzeit vor Bestellzeit); weitere Stopps nur in gleicher Richtung (Winkel vom Laden, ±45°) und mit Umweg < DeliveryConfig.MaxDetourMinutes (Default 8) — Umweg = t(letzter→neu) + t(neu→Laden) − t(letzter→Laden) aus der Valhalla-Fahrzeit-Matrix (POST /delivery/travel-matrix), ohne Routenoptimierung Luftlinie bei 25 km/h (der Vorschlag sagt „geschätzt"); höchstens MaxStopsPerTour (Default 3); Wunschzeiten weiter als 30 min bleiben liegen („erst später fällig"); Reihenfolge = nächster Nachbar vom Laden. Nachzügler: wird < 2 min nach dem Vorschlag ein Auftrag in gleicher Richtung fertig, erscheint „+1 Stopp?" — nie still hinzugefügt. Beide Werte im Admin (Lieferdienst → „Tour-Vorschlag")
Beutel-Checkliste
POST /delivery/bag-checklist je Stopp: Stück Speisen (Küchen-Kennzeichen inkl. Warengruppen-Vererbung, KitchenArticleResolver), Getränke (alles andere), Pfand-Summe (Article.Pfand), Mindestalter (Article.MinAge → „ab 18 – Ausweis prüfen"), Positionen ohne Artikel im Stamm als „ungeprüft". Der Fahrer hakt jeden Stopp ab, sonst bleibt „Mitnehmen" gesperrt
Reihum („Wer fährt?")
Beim Tresen-„Mitnehmen": anwesende Fahrer (nicht unterwegs) zuerst, der längst Wartende markiert (Ende der letzten Tour bzw. letzte Ablehnung); „Nicht ich" reiht hinten ein (localStorage, je Tag wie die Fahrerliste). Fahrer auf Tour stehen darunter und sind nie markiert
Routenoptimierung
Stopps in eine sinnvolle Reihenfolge bringen, Strecke und Fahrzeit schätzen (Valhalla)
Route an den Fahrer geben
Tour als Text plus Google-Maps-Link aufbereiten, Anzeige als QR-Code zum Abscannen
Fahrer-Maske (Handy, PWA)
Seit 29.08.2026 (P10b) die Tour-Maske des Fahrers: Kopf „Stopp 2 von 4 · 6 min" (Reihenfolge aus OptimizeDeliveryRouteQuery), eine Karte je Stopp mit Adresse Groß, Stockwerk/Klingel/Zustellhinweis, Beutelinhalt mit Anzahl und Optionen, Wunschzeit, „ab 18 — Ausweis prüfen" (aus VerifiedMinAge), Bemerkung des Gastes und Geld Groß und farbig (BEZAHLT grün / „24,50 € bar" gelb / Karte blau — Bar-Beleg aus dem Dispatch heißt „kassieren", online/vorab bezahlt heißt „nichts kassieren"). Knöpfe daumengross: Navigieren (geo: für die Karten-App, Web-Rückfall; „Ganze Tour" = alle offenen Stopps als Google-Maps-Wegpunkte, mit Laden als Ziel wenn RouteOptimization.Start gesetzt), Anrufen, „Bin in 5 min da", Kassieren, Problem. Dunkelmodus-Schalter (lokal gemerkt), Wake-Lock nur während einer laufenden Tour, eigenes Manifest public/driver-manifest.webmanifest (Start /pos/driver-route) — „Zum Startbildschirm" öffnet direkt die Tour. Freie Aufträge bleiben als eigener Block (driver-available, „Annehmen" = Reservierung, P10a); das Mitnehmen-Panel (P10a) sitzt oben in derselben Maske. Texte über die i18n-Domäne pos-driver (de/en/es/fr/it/tr)
Übergabe am Stopp — Fahrer kassiert
POST /delivery/{id}/handover: der einzige Weg der Fahrer-Maske auf „erledigt", nie nur Status (Audit F2). Bottom-Sheet mit Zahlart (konfigurierte Zahlarten des Betriebs), Trinkgeld (Stufen + Freitext) und Wechselgeld-Rechner (Schnellbeträge „Passend/50/100/200", Rückgeld Groß, „zu wenig gegeben" sperrt). Bar wie beim Dispatch gebucht ⇒ nur „erledigt", Beleg bleibt. Karte an der Tür oder Trinkgeld ⇒ der Dispatch-Bar-Beleg wird storniert (VoidReceiptCommand.BookIntoOriginalExchange = Fahrerkasse) und über den Direktverkauf mit echter Zahlart, Trinkgeld und gegebenem Betrag in der Wechselkasse des Fahrers neu gebucht (TSE, Kassenbuch); DriverTipAmount am Auftrag. Scheitert die Neubuchung, bleibt der Auftrag OFFEN und ohne Beleg (IsPaid=false) — sichtbar, die Kasse kassiert nach. Online/vorab bezahlt: nur „Übergeben", Trinkgeld dort nicht buchbar (TIP_ONLINE_PAID, steht im Sheet). Idempotent (erledigt bleibt erledigt), Fahrerbindung (NOT_YOUR_ORDER), RECEIPT_REQUIRED ohne Beleg; löscht ein gemeldetes Problem; Shop- und Plattform-Sync wie beim Status-Weg. Jugendschutz (seit 05.09.2026): die Neubuchung gilt als „am Vorgang geprüft" (AgeVerifiedAtHandover=true) — der Dispatch-Beleg hat die Prüfung schon bestanden, die Ware wird gerade übergeben; zusätzlich geht DeliveryOrder.VerifiedMinAge mit
Problem am Stopp melden
POST /delivery/{id}/driver-issue mit NobodyThere / WrongAddress / MissingItems (leer = aufheben): der Auftrag bleibt offen (Status unverändert), DriverIssue/-At/-Note am Auftrag, zwei SignalR-Pushes — DeliveryOrder (Listen laden nach) und DriverEvent (Alarm für die Disposition, signalR.driverEventChanged, deleted=true = aufgehoben). „Niemand da" startet in der Maske einen 2-Minuten-Timer mit Anruf-Knopf; läuft er ab, geht die Meldung automatisch raus, „Jetzt melden" sofort. Kein stiller Abbruch
„Bin in 5 min da"
POST /delivery/{id}/driver-arrival: Web-Push an den Gast in seiner Sprache (de/es/en/fr/it, P3-Kanal — dieselben Subscriptions wie „fertig/unterwegs") und OnlineOrder.DriverArrivalAt für die Statusseite („Dein Fahrer ist gleich da — etwa 18:42", nur bei Status „unterwegs"); ArrivalNotifiedAt am Lieferauftrag. Sperrfrist 3 min gegen Doppeltipp/Offline-Wiederholung. Ohne verknüpfte Online-Bestellung (Telefon, Plattform) nur der Zeitstempel — die Maske sagt „Vermerkt — der Gast hat keinen Push". Kein SMS (Owner)
Rückweg + Tourabschluss
„Zurück zum Laden" (Navigation zum RouteOptimization-Start) und GET /delivery/driver-tour-summary: bar / Karte / Sonstige / Trinkgeld / Bargeld abliefern (Soll) aus der offenen Wechselkasse des Fahrers (GetExchangeListQuery, PersonalId) plus Stopps des Betriebstags; erscheint automatisch, sobald der letzte Stopp übergeben ist. Ohne offene Fahrerkasse: Hinweis statt Nullen
Offline-Puffer der Fahrer-Maske
Jede Aktion (Übergabe, Problem, „Bin in 5 min") wird ZUERST in IndexedDB (dikas-driver, Speicher-Rückfall) abgelegt und dann gesendet; bei Netzverlust bleibt sie liegen und geht beim online-Ereignis in Zeitreihenfolge raus. Schlüssel Auftrags-Id + Aktion (Korrektur ersetzt, Zeitstempel bleibt); Netzfehler (0/5xx) stoppt den Lauf, fachlicher Fehler (4xx) verwirft nur diese Aktion und meldet sie. Backend-Befehle sind idempotent
Zustellangaben Stockwerk / Klingel / Hinweis
Felder Floor, DoorBell, DeliveryNote am Lieferauftrag, an der Kunden-Hauptadresse und an jeder Kunden-Lieferadresse; erfassbar im Telefon-Modus (Adressformular, Neukunde, neue Lieferadresse — vorbelegt aus der Kundenadresse) und im Shop-Checkout (Stockwerk, Klingel; der bestehende Lieferhinweis wandert jetzt als DeliveryNote mit — bis 29.08.2026 blieb DeliveryNotes in der Online-Bestellung stecken). Die Fahrer-Maske zeigt sie auf der Stopp-Karte
Fahrer-Ansicht: Mitnehmen und Reservierung (P10a in der P10b-Maske)
Oben in der Fahrer-Maske das Mitnehmen-Panel (Vorschlag aus „für mich reserviert" + freie bereite Aufträge, Beutel-Checkliste, ein Tipp = Dispatch mit expectedRevisions, Beleg, Tourzettel, Status „unterwegs"; 409 DISPATCH_CONFLICT lädt neu), darunter die Tour-Karten (nur Status 4) und unten „Freie Aufträge" mit Annehmen = Reservierung für mich (ReservedDriverId; fremd reserviert = ALREADY_RESERVED, schon unterwegs = DRIVER_ALREADY_ASSIGNED). Seit P10a gibt es kein „Losfahren" und keinen Status-Knopf mehr; auf Tour kommt ein Auftrag nur über „Mitnehmen" (TOUR_REQUIRED für /status 4). driver-jobs liefert als „meine" Aufträge die auf Tour und die für mich reservierten; fremd reservierte sind nicht „frei"
Fahrer-Kennzeichen am Mitarbeiter
Recht „Fahrer (Lieferservice)" — so geflaggte Mitarbeiter stehen automatisch in der Fahrerliste
Bezahlen am Lieferauftrag
POST /delivery/{id}/pay: Zahlart per konfiguriertem Namen (paymentMethod, Vorrang; Typ 0 = Bar, 1 = erste Kartenzahlart, alles andere ohne Namen = PAYMENT_METHOD_REQUIRED) plus Trinkgeld (tipAmount), Beleg über den Direktverkauf, Liefergebühr mit dem Satz aus DeliveryConfig.DeliveryTax. complete-payment verknüpft einen an der Kasse gebuchten Beleg: prüft Existenz und Doppelbezahlung, setzt „erledigt" nur bei Aushändigung (Abholung, oder Lieferung mit Fahrer) — eine vorab kassierte Lieferung bleibt im Workflow. Karte/Trinkgeld an der Haustür gibt es weiterhin nicht (Dispatch = Bar, s. Grenzen)
Auftrag nachträglich ändern
Auftrag zum Bearbeiten in die Kasse laden, einzelne Position stornieren
Auftrag stornieren
Lieferauftrag abbrechen (DELETE /delivery/{id} oder Status 6): storniert den Kassenbeleg — und bricht ab, wenn der Beleg-Storno scheitert (Rechte, TSE, Karte; Auftrag bleibt unverändert) —, bucht den Storno-Beleg in die Wechselkasse des Fahrers, schließt die Küchen-Bons, löst bei Shop-Bestellungen Reject/Refund/Mail aus und meldet an die Plattform. Umgekehrt storniert Reject/Gast-Storno der Online-Bestellung den Lieferauftrag mit
Lieferservice-Oberfläche
Reiter Online / Lieferung (Workflow) / Übersicht / Erledigt mit Status-Farbcodierung
Dispositions-Tafel (Wand-Tablet/TV)
Eigene Fläche /pos/delivery/tafel (Menü-Kachel „Dispositions-Tafel", P10c 29.08.2026): EIN Bildschirm, drei Spalten in Flussrichtung In Küche · Bereit · Unterwegs (je Fahrer eine Tour-Zeile mit Stopp-Kette ✓/▶/offen und ETA zurück, darunter „im Laden: Tom, wartet 6 min"), Kopfzeile als Satz („4 in Küche · 3 bereit · 2 unterwegs · nächster Fahrer zurück in ~4 min · 1 Problem"), Alarme oben mit Ton (Fahrer-Ereignisse driverIssue/SignalR DriverEvent, überfällig ab ColorTimesPacking.RedMinutes), Farbe nur nach Wartezeit (Küche ColorTimesKitchen ab Bestellzeit, Regal ColorTimesPacking ab ReadyAt/ChangedDate), Richtungs-Kürzel N/NO/O/… aus dem Winkel Laden→Adresse (RouteOptimization.StartLatitude/-Longitude, sonst CompassDirection) und Vorschlag-Chip „NO ×2", Tipp Karte → Tipp Fahrer = Reservierung (PUT /delivery/assign → ReservedDriverId), „Mitgeben" = bestehender Dispatch der reservierten Aufträge. ETA zurück ohne GPS = Tourstart + Valhalla-Gesamtfahrzeit (optimize-route, enthält den Rückweg) + 2 min je Stopp; ohne Valhalla 8 min Fahrt je Stopp + Rückweg. SignalR statt Poll (300-s-Rückfall), nur Lieferaufträge (keine Abholung), kompakt ab 15 Aufträgen, Dunkelmodus, 6 Sprachen (pos-tafel)
Tageszahlen Lieferdienst
Anzahl der Aufträge je Status des Geschäftstages (u. a. Offen-Badge in der Kassen-Ansicht); „heute" ist seit 29.08.2026 der Betriebstag des Mandanten (IBusinessDateService, Tagesgrenze), derselbe wie beim Anlegen des Auftrags und bei Belegen
Lieferando-Import
Webhook nimmt Bestellungen von Lieferando / Just Eat Takeaway entgegen; plattform-bezahlte Bestellungen bekommen seit 29.08.2026 beim Import einen Beleg mit der Plattform als Zahlart (Typ 11, nie Bargeld; idempotent über Plattform:ExternId) — gilt für alle vier Kanäle inkl. GloriaFood . Seit 07.09.2026 (Befund T2) geht keine bezahlte Bestellung mehr verloren: jeder Webhook hält den Eingang FEST, bevor er importiert (PlatformOrderInboxItem, Idempotenzschlüssel Plattform + Fremd-Id). Scheitert der Import, bleibt die Bestellung als Fehlzustand liegen und der PlatformOrderInboxWorker holt sie nach (30 s / 1 / 3 / 10 / 30 min, danach „aufgegeben" mit ALARM). Vorher antworteten Wolt und Uber 200 {received:true} auch dann, wenn der Abruf still null lieferte — die Plattform wertete das als zugestellt und sendete nie erneut, der Gast hatte bezahlt und die Küche erfuhr nichts. Bei Lieferando wird der rohe Rumpf mitgesichert: dort gibt es keinen Abrufweg
Uber-Eats-Import
Webhook-Benachrichtigung, Bestelldaten werden per OAuth nachgeladen; Storno wird übernommen
Wolt-Import
Webhook-Benachrichtigung, Bestelldaten werden nachgeladen; Storno wird übernommen
Standort während der Tour (P10d, 29.08.2026)
Die Fahrer-Maske sendet alle 30 s die Geräteposition — nur wenn DeliveryConfig.DriverLocationEnabled gesetzt ist ( Default AUS, Admin → Lieferdienst → „Standort während der Tour") und nur zwischen „Mitnehmen" und Tourabschluss (Rückweg zählt dazu). POST /delivery/driver-location: der Server prüft beide Bedingungen erneut, legt Position, Stopp-Kette und Live-Restfahrzeit ausschließlich im Arbeitsspeicher ab (IDriverLocationStore, TTL 15 min, streng je Mandant), rechnet die Valhalla-Restfahrzeit ab der Position über die offenen Stopps zurück zum Laden (gedrosselt auf 25 s) und meldet dem Fahrer, ob der Geofence gegriffen hat. POST /delivery/driver-location/end löscht beim Tourabschluss. Es gibt kein Dokument, keine Tabelle, keine Datei und keine Historie — ein Neustart des Servers leert alles. Beim ersten Start zeigt die Maske den Datenschutz-Hinweis (Zweck, Dauer, keine Speicherung, kein Tracking außerhalb der Tour) und sendet erst nach der Bestätigung; solange gesendet wird, steht ein Standort-Symbol in der Kopfzeile. Ohne Browser-Freigabe läuft die Tour normal weiter
Live-ETA und Fahrerkarte auf der Tafel (P10d)
GET /delivery/driver-locations (nur Personal, trägt Koordinaten): die Tafel holt die Positionen im 30-s-Uhrtakt und ersetzt „ETA zurück" durch Meldezeitpunkt + Live-Restminuten, gekennzeichnet mit „live". 🪤 Eine Meldung älter als 90 s gilt als veraltet und fällt sichtbar auf die P10c-Rechnung zurück — sonst stünde „zurück in 3 min", während der Fahrer seit zehn Minuten steht. „Im Laden: Tom, wartet 6 min" zählt ab der Geofence-Rückkehr statt ab dem letzten Handover. Dazu eine kleine ausklappbare Karte (Knopf in der Kopfzeile, Merker je Gerät, nie Hauptansicht) mit den Fahrerpunkten und dem Laden — Leaflet, das im Repo schon für die Kundenkarte liegt; Marker sind circleMarker (SVG, keine Bilddateien)
Geofence: Tour endet automatisch „im Laden" (P10d)
Fährt der Fahrer auf dem Rückweg (kein offener Stopp mehr) in den Umkreis des Ladens (DeliveryConfig.StoreGeofenceMeters, Default 150 m, Haversine gegen RouteOptimization.Start bzw. die geocodierte Lizenz-Adresse), gilt die Tour als beendet: der Fahrer bekommt die Bestätigung und den Tourabschluss aufgeblendet, die Tafel rückt ihn nach „Im Laden" (SignalR DriverEvent). Idempotent — die zweite Meldung im Umkreis löst nichts Neues aus. Mit offenen Stopps greift er NIE, auch wenn der erste Stopp neben dem Laden liegt
Rückmeldung an die Plattform
Annahme, Ablehnung und Statuswechsel gehen an die jeweilige Plattform zurück — seit 29.08.2026 auch aus Fahrerausgabe, Zuweisung und Annahme, nicht nur aus der Status-Fläche. Seit 07.09.2026 (Befund T4) ist ein Fehlschlag sichtbar: der Rückgabewert der Adapter wurde vorher restlos verworfen — bei abgelaufenem Token stand der Auftrag im Haus auf „bestätigt", bei der Plattform weiter auf „unbestätigt", und die Plattform stornierte nach ihrer Frist, während die Küche kochte. Jetzt tragen PlatformSyncFailed/PlatformSyncError/PlatformSyncAt den Ausgang am Auftrag, die Auftragskarte zeigt „Plattform nicht benachrichtigt — dort erneut prüfen", und der nächste gelungene Ruf löscht die Markierung wieder. Zähler dikas_stille_fehler_total{stelle="DeliveryPlatformRouter.SyncStatus"}
Eingang der Plattform-Bestellungen (Operator-Sicht)
GET /api/v1/delivery/platform-inbox und ein Warnstreifen oben in der Lieferansicht: welche Wolt-/Uber-/Lieferando-Bestellung ist eingegangen, aber noch KEIN Auftrag im Haus — offen (Wiedervorlage läuft) oder aufgegeben (bitte in der Plattform nachsehen). Neu am 07.09.2026 mit Befund T2; ohne diese Sicht wäre der durable Eingang nur eine Tabelle
Automatische Annahme
Neue Plattform-Bestellungen sofort bestätigen (erzeugt die Küchenbons)
GloriaFood-Webhook (Legacy)
Ältere Anbindung eines externen Bestellportals, API-Key optional
Status zurück an den Shop
Fortschritt des Lieferauftrags wird auf die verknüpfte Online-Bestellung gespiegelt (Gast-Tracking) — aus Status-Fläche und Fahrerausgabe; Annahme/Zuweisung/Umsetzen spiegeln weiterhin nicht (O7, offen). Umgekehrt zieht die Bridge eine nach der Anlage eingegangene Online-Zahlung an den Lieferauftrag nach (MarkDeliveryOrderPaidOnlineCommand)
Konfiguration Lieferdienst
Zeiten, Zonen, Workflow-Schritte, Drucker, Farbzeiten, Plattform-Zugänge
außer-Haus-Steuersatz (nur Schweiz)
Bei Fiscal:Country=CH bekommen Küchenartikel (Küchen-Druckoption = Speise, ggf. über die Warengruppe vererbt) im Lieferpfad den ermässigten Satz der Steuersatz-Periode (2,6 %) statt 8,1 % — auf den Küchen-Bons (Bestellung aufgeben, Bestätigen), im Direktverkauf (ProcessDirectSaleCommand.TakeAway: Kassieren, Fahrerausgabe, Plattform-Beleg) und im Online-Beleg. Getränke behalten 8,1 % (auch alkoholfreie — konservativ, es gibt kein Alkohol-Kennzeichen). DE/AT/ES: ohne Wirkung. Owner-Entscheid 29.08.2026
Kein Treffer in diesem Bereich. Gesamte Website durchsuchen
Oft gesucht
Begriffe rund um Lieferdienst
MitnehmenBereit-RegalReservierungTour-VorschlagBeutel-ChecklisteReihumWartezeit-AmpelLieferungLieferdienstLieferserviceAuslieferungFahrerBoteKurierLieferandoJust EatTakeawayUber Eats
Weiterstöbern