- Address.addition aus dem Backend (ERP-Freitext, praktisch Ortsteil,
Etage oder Hinweis); API-Client neu generiert.
- Listen (Sortieren, Beladen, Liefer-Übersicht): Adresse mit Zusatz in
Klammern, z. B. „… 41472 Neuss (Holzheim)".
- Lieferdetails: „Zusatz: …" unter der Anschrift von Empfänger und
Besteller; Land nur außerhalb Deutschlands.
- Maps-Suche weiter ohne Zusatz (sonst stört „3 Etage" die Suche).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Belege können im ERP eine eigene Lieferadresse (LieferAdressId) mit
anderer Person tragen als der Besteller. Die App zeigt jetzt überall den
Empfänger vor Ort:
- TourDetails.recipientOf liefert Empfänger (Name aus der Lieferadresse,
sonst Besteller), Lieferanschrift und differsFromOrderer.
- Sortieren, Auswählen, Beladen und Liefer-Übersicht: Empfängername +
Lieferadresse, bei Abweichung „Bestellt von: <Kunde>".
- Lieferdetails: hervorgehobene Karte „Abweichende Lieferadresse" mit
Empfänger, Anschrift und Kontakt; Kunden-Block als „Besteller (Kunde)"
mit Adresse, Kundennummer und Kontaktdaten.
- Maps navigiert zur Lieferadresse statt zur Kundenadresse; AppBar,
Unterschrift und Beladen-Avatar nutzen den Empfänger.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Neuer Workflow-Step "Zahlung" zeigt ausgelieferte Artikel mit Menge und
Preis, Betragsaufstellung, Zahlungsstatus und einen grossen Button
"Zahlung abwickeln" (fest unten)
- Zahlungs-Modal: grosser offener Betrag, Methoden als Cards aus den
Backend-Stammdaten, bei EC-Karte gross die Kundennummer; schliesst nur
ueber Abbrechen, "Zahlung erhalten" oder "Lieferung abbrechen" (mit Grund)
- Bestaetigung wird am Server protokolliert (RecordDeliveryPayment); bis
dahin sind "Weiter" und die Uebersicht gesperrt, ausser es ist nichts
offen (bereits bezahlt). Aendert sich der Betrag danach, wird die Zahlung
als veraltet markiert und muss erneut abgewickelt werden
- Uebersicht zeigt die abgewickelte Zahlung statt eigener Methodenauswahl;
Unterschrift-Flow ohne doppelte Inkasso-Stufe; Abschluss sendet Methode
und Inkasso-Flag der gueltigen Zahlung
- DeliveryPaymentStatus als einzige Quelle fuer offenen Betrag
(gleiche Formel wie Backend); Artikelliste/Betragskarte als geteilte
Widgets; Begruendungs-Dialog geteilt mit Info-Step
- API-Client aus aktueller Backend-Spec neu generiert
- Tests fuer Zahlungsstatus und Modal
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A) Nach erfolgreichem Abschluss (aktiv→completed) poppt die Detail-Page
automatisch zurück zur Übersicht. Scaffold ist jetzt StatefulWidget
mit BlocListener<TourBloc>; nur „gearmt", wenn die Lieferung beim
Öffnen aktiv war → erneutes Öffnen einer fertigen Lieferung poppt nicht.
B) Step „Info": Artikelliste zeigt weiter die Ursprungsmenge
(requiredQuantity). Bei entfernten/teilweise gutgeschriebenen Positionen
erscheint pro Zeile ein „Menge geändert"-Hinweis + ein tappbares Banner,
das zu Step 3 „Artikel" springt.
C) Beladen: nicht-scanbare Set-Köpfe (Parent-Komponenten) werden jetzt
IMMER mit ihrem Set gezeigt — als Kopf in der Lagergruppe ihrer
Komponenten statt isoliert unter „Dienstleistungen". _ItemRow leitet
scanNotRequired aus der Artikel-Scanbarkeit ab.
D) Step „Übersicht": Wording der Zahlungsweise-Sperre bei offen==0
präzisiert („Keine Zahlung mehr offen (bereits bezahlt)").
E) Step „Artikel": Komponenten eines Sets sind einzeln nicht mehr
entfernbar (kein Button + Hinweis). Das Entfernen/Wiederherstellen läuft
nur über den Oberartikel und kaskadiert auf das ganze Set (ganz oder
gar nix). Set-Entfernen ist blockiert, solange eine Komponente noch
nicht verladen ist.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
