votianng/docs/PRUEFSTATUS.md

# Prüfstatus

## Belegpaarpflege, gemeinsamer Storno und Lagerkorrekturen – 13. Oktober 2026

- Serverquelle erneut per SSH aktualisiert (`868db70`); aktuelle PHP-Auftragsliste und Lageransicht mit Hauptlagerwahl angesehen. Nur der aktuelle Server-Snapshot wurde als PHP-Referenz verwendet.
- Frontend-Produktionsbuild und Maven `package` mit vollständigem Backend-Testlauf erfolgreich: **430 Tests, 427 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Nach abschließenden Kompatibilitätskorrekturen gezielte Integrationsprüfungen und den vollständigen Paketbau erneut ausgeführt. Bekannt bleibt der Hinweis auf das Frontend-Bundle über 500 kB.
- Reale Transaktionen in einer wegwerfbaren MariaDB 11.4: zusätzliche Belegpaare, Aufhebung samt Gegenbuchungen, PHP-kompatible Trennung alter Elternzuordnungen, stabile Stationsnachweise, gemeinsame Gutschrift von drei Belegen, exportierte/unexportierte Einnahmen und centgenaue Stornogebühr. Auch angebotener Auftrag mit Dauerauftragsende, Erhalt der Kurierzuordnung, Gebührenkorrektur ohne alte Preispositionen, doppelte Requests, fehlende Rechte, Export-/Rechnungsschutz und Rollback nach dem letzten Beleg geprüft.
- Lagerprüfungen: ganzes Bündel, Wiederholung, Rollback mitten in einer Gegenbuchung, Ablehnung auftragsübergreifender Bündel, historische PHP-Zusatzdaten mit leeren Zwischenfeldern, Wiederherstellung von Seriennummerndaten, TAN und Zusatzdatum. Keine Teilbuchungen bei Fehlern.
- Browserfixture `127.0.0.1:18744` schreibt ausschließlich synthetische Daten im Arbeitsspeicher: Belegpaar entfernen/hinzufügen, Fahrzeug suchen, Vorschau und Speichern; TAN, Zusatzdatum und Zusatzfeld erfassen, buchen und im Journal wiederfinden; gemeinsame Stornovorschau mit Einnahmenbestätigung und Speichern. Keine Browser-Konsolenfehler. Prüfbild: `work/gemeinsamer-storno-vorschau.png`.
- Anwendung um 20:25 Uhr mit dem abschließend geprüften JAR auf Port 8080 neu gestartet. Healthcheck `UP`, Bestandsdatenbank verbunden, ausgelieferte JS-/CSS-Dateien bytegleich mit dem Produktionsbuild. Vorhandener Anwendungstab neu geladen. Temporäre Browserfixture und wegwerfbare MariaDB beendet.
- Keine Teständerungen in der Bestandsdatenbank, keine Nachrichten an Fahrer und kein E-Mail-Versand. Offene fachliche Sonderfälle sind in [MENUE-ABGLEICH.md](MENUE-ABGLEICH.md) fortgeschrieben; vollständige PHP-Parität wird nicht behauptet.

## Artikel-/Lagerbearbeitung und bestehende Unternehmerbelege – 13. Oktober 2026

- Aktuelle Quelle erneut direkt von `172.16.0.158:/data/0/votian-test/html` gelesen: Git-Stand `868db70`, 13.10.2026 16:18:15 UTC. Auftragserfassung, Auftragsdetails und Lageransicht der angemeldeten PHP-UI lesend geprüft. Das separat geöffnete Calculator-Popup war für die Browsersteuerung nicht erreichbar; dessen Verrechnungslogik wurde im aktuellen Servercode geprüft. Kein Rückgriff auf den früheren lokalen PHP-Bestand.
- Frontend-Produktionsbuild erfolgreich. Gesamter Backend-Testlauf: **430 Tests, 427 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Nach den letzten Korrekturen gezielte Artikel-/Lager-/Unterauftrags- und SQL-Architekturprüfungen erneut erfolgreich. Maven-Paket erstellt. Bekannter Buildhinweis: Frontend-Bundle über 500 kB.
- Neue Integration gegen wegwerfbare MariaDB 11.4 mit aktuellen Spaltendefinitionen: stabile Artikel-IDs, Scanschutz, fremde Stations-/Artikel-IDs, veraltete Revisionen, Lagerbestand und Kapazität, Seriennummernduplikate, Aus-/Gegenbuchung einschließlich aller 25 Zusatzdatenfelder, wiederholte Request-IDs, Rechte-/Niederlassungsgrenzen und vollständiger Rollback bei Fehlern. Hauptauftrag 170 Euro, Unternehmerbeleg 60 Euro, Gegenbeleg −60 Euro inklusive Servicepreis/Zuschlag geprüft. Erhalt von Tour-IDs und Zustellnachweisen, zwischenzeitliche Gegenbelegänderung, abgerechneter Gegenbeleg und Rücknahme aller Änderungen bei einem Fehler am zweiten Beleg geprüft.
- Browserprüfung am ausschließlich lokalen Testserver `127.0.0.1:18744`: Artikel bearbeiten/speichern, geschützte Positionen, Stammartikelauswahl und erneuter Wechsel, Lagereingang mit Vorschau und Gegenbuchung, Unternehmerfahrzeug wechseln, gemeinsame Kalkulation anzeigen/übernehmen. Keine Konsolenfehler. Backend-Buchungen werden durch die Datenbanktests geprüft; der UI-Server verwendet synthetische Antworten und schreibt ausschließlich in den Arbeitsspeicher. Screenshot: `work/artikel-lager-bestandsauftrag.png`.
- Anwendung um 18:50 Uhr auf Port 8080 neu gestartet. HTTP/Health erfolgreich; ausgeliefertes JavaScript stimmt bytegenau mit dem neuen Frontend-Build überein. Der offene Browser-Tab wurde neu geladen.
- Keine Schreibprobe gegen Geschäftsdaten. Kein Versand an Fahrer, E-Mail-Empfänger oder externe Fachdienste. Die Testdatenbank enthält ausschließlich synthetische Stammdaten und Aufträge.
- Grenzen dieses früheren Prüfstands (inzwischen erweitert, siehe oben): einfache bestehende Unternehmerpaare können geändert werden; zusätzliche Paare, Entfernung und gemeinsames Storno bleiben offen. Lagerkorrekturen erfolgen durch zusätzliche Journalbuchungen. Historische Seriennummern-Auslagerungen ohne gesicherte Zusatzdaten, Bündel- und Spezialbewegungen benötigen weiterhin die vollständige Lagerverwaltung. Weitere offene Menübereiche stehen in [MENUE-ABGLEICH.md](MENUE-ABGLEICH.md).


## Ergänzte Teilfunktionen – 13. Oktober 2026

- Aktuelle SSH-Quellen und angemeldete PHP-Oberflächen für Auftrag, Gruppen, Anfahrtszeiten, Berichte/Formulare und Kunden-Servicezuordnung geprüft. Ausschließlich Server-Snapshot `work/php-current-2026-10-13`; keine Verwendung des ursprünglichen lokalen PHP-Bestands.
- Frontend-Produktionsbuild und Maven `package` mit isolierter MariaDB 11.4 erfolgreich: **429 Tests, 426 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. SQL-Architekturprüfung erfolgreich; verbleibender Hinweis auf die Frontend-Bundlegröße.
- Integrationen: reale Neukalkulation vorhandener Aufträge ohne zusätzliche Aufträge/Stationen, Zahlungsbedingung neben Kilometerposition 16, Speichern/Wiederholen, Berichtsformularrechte und Vertraulichkeit, unveränderte fremde Kategorien, Rollback bei Historienfehler, veraltete Revisionen. Gruppenlöschung und Kunden-Servicezuordnungen jeweils mit künstlichem Fehler nach bereits erfolgtem MyISAM-Schreiben und erfolgreichem Fortsetzen geprüft.
- Lesend am echten Bestand: Zahlungsbedingungscodes/-texte, Niederlassungs-Anfahrtsstandards, beide Berichtsformulare (23/109 Felder) nativ gerendert, Kunden-Serviceauswahl mit 34 Preis- und 22 Leistungstypen über beide Modi geladen.
- Isolierte Browserfixture: Kalkulation speichern, 0-Minuten-Fallback, Niederlassungswechsel und Gruppen-Löschvorschau; Berichtsvorlagen mit Eingaben/Checkboxen speichern; Kunden-Serviceauswahl ändern, sortieren und speichern. Schreibtests ausschließlich gegen disposable MariaDB bzw. simulierte Browser-API. Keine echten Aufträge, Nachrichten, Lagerbewegungen oder Stammdaten zu Testzwecken verändert.
- Abschließende Layoutkorrektur: mehrzeilige CSS-Selektoren aus den PHP-Vorlagen erhalten; Klassenregeln im Formulareditor auf dessen eigenes Element begrenzt. Speichern und erneutes Öffnen mit sichtbaren Werten im Browser geprüft.
- Prüfbilder: `work/teilfunktionen-kalkulation.png`, `work/teilfunktionen-gruppen.png`, `work/teilfunktionen-berichtsformular.png`, `work/teilfunktionen-kundenservices.png`.
- Anwendung am 13. Oktober 2026 um 18:11 Uhr mit dem abschließend geprüften JAR auf Port 8080 neu gestartet. Healthcheck `UP`, Bestandsdatenbank verbunden, ausgelieferte JS-/CSS-Dateien identisch zum Produktionsbuild. Vorhandener Browser-Tab neu geladen; Anmeldemaske zeigt die verbundene Datenbank. Temporäre Browserfixture und disposable MariaDB beendet.
- Die verbleibenden Funktionslücken stehen im aktuellen Menüabgleich; dieser Stand behauptet keine vollständige PHP-Parität.


## Auftragsbearbeitung, Stammdaten, Abrechnung und aktueller Serverabgleich – 13. Oktober 2026

- PHP-Referenz ausschließlich per SSH von `root@172.16.0.158:/data/0/votian-test/html`. Angemeldete PHP-Auftragsdetails, Stammmasken, Rechnungsübersicht/-zuordnung und Foto-Set-Auswahl angesehen; Kundenlisten-Schalter zusätzlich geöffnet. Keine fachlichen Teständerungen in der Altanwendung gespeichert.
- Maven `verify` mit isolierter MariaDB 11.4: **412 Tests, 409 bestanden, 0 Fehler, 3 optionale Bestandsprüfungen übersprungen**. Frontend-Produktionsbuild erfolgreich; verbleibender Hinweis auf Bundlegröße über 500 kB. SQL-Architekturprüfung erfolgreich.
- Integrationsprüfungen: Kunden/Kurier/Fahrzeug/Kostenstellen anlegen/ändern, historische Adressen erhalten, Hierarchiezyklen und fremde Niederlassungen abweisen; Auftragsbearbeitung, Preisberichtigung, Abschluss, alte Empfänger erhalten, Storno-Gegenbuchung, Rechnungszuordnung mit künstlichem Verbindungsfehler nach MyISAM-Insert, Fortsetzen/Abbruch, Konflikte mit nachträglicher Bestandsänderung, CSV/PDF und Audit-Wiederholung.
- Neue Foto-Prüfungen: Freigaben, Setgrenzen, globale Rückfallebene, Positionsvorrang/Einzelstation, PHP-Stationskennzeichen, Set zuerst/Overrides danach, Wiederholung und Fehler ohne Dispositionsfreigabe. Adressprüfungen: unabhängige Stammdatenrechte, Schlüssel ausschließlich serverseitig, vollständige/fehlende Komponenten, fremde Länder, deutsche PLZ-Präfixe und externe Fehler. Kostenstellensuche auch gegen die isolierte DB mit Teilwort, SQL-Sonderzeichen, Kunden-/Niederlassungsgrenzen und mehreren Kostenstellen.
- Lesend am Bestand geprüft: neue Stamm-/Auftrags-/Abrechnungsabfragen, vier freigegebene Foto-Sets mit insgesamt 16 Workflows, fünf begrenzte Kunden-/Kostenstellenzeilen mit IDs. Google-Suche mit öffentlicher Adresse „Pariser Platz 1 Berlin“: drei Vorschläge; Auswahl liefert Straße, Hausnummer, PLZ, Ort und Land. Keine Fotos/Set-Zuordnungen an den echten Fotodienst geschrieben.
- Browser unter `127.0.0.1:18744` mit isolierter API-Fixture: Auftragsänderung und Abschluss, Stammdaten und Kostenstellenadresse speichern, Rechnungsnummer zuordnen, PDF herunterladen; anschließend Kostenstelle suchen/direkt öffnen, Google-Vorschlag simuliert übernehmen/speichern, Foto-Set wechseln, Stationsabweichung wählen, Preisvorschau und Auftrag speichern. Requestprüfung bestätigt Foto-Set 2 und Stationsauswahl 0/null. Keine Konsolenfehler/-warnungen. Nachweise: `work/abrechnung-ui-test.jpg`, `work/kostenstellensuche-ui.jpg`, `work/stammdaten-adressvorschlag-ui.jpg`, `work/foto-sets-ui.jpg`.
- Grenzen: Geschäftsdatenschreibtests ausschließlich disposable DB bzw. Browserfixture. Echte Fahrergeräte, Fotoübertragung, vollständige Rechnungsausgabe und Buchhaltung nicht live schreibend geprüft. Die dokumentierten offenen Teilfunktionen im Menüabgleich bleiben offen.
- Anwendung am 13. Oktober 2026 um 16:45 Uhr mit dem aktuellen JAR auf Port 8080 neu gestartet. Enthaltene Frontend-Datei entspricht dem Produktionsbuild; Healthcheck `UP`, Bestandsdatenbank verbunden, keine Schemaänderungen. Vorhandener Browser-Tab neu geladen und Anmeldemaske geprüft.

## Parameterdatenbank und Google-Geokodierung – 13. Oktober 2026

- Bereitgestellten Zugang zu `172.16.0.111:3711/phoenix` getrennt vom Hauptdatenbankzugang in der ignorierten lokalen `.env` gespeichert; Dateirechte 0600.
- Anmeldung und fester SELECT auf den Google-Parameter erfolgreich. Einmaliger Kompatibilitätsimport für `mysql_old_password` und den alten Server ohne READ-ONLY-Transaktionen; alle SQL-Abfragen über `DatabaseService`, keine Schreibanweisungen. Laufenden Anwendungstreiber und dessen Schutzmechanismen unverändert gelassen.
- Schlüssel als `GOOGLE_MAPS_API_KEY` übernommen. Öffentliche Beispieladresse Brandenburger Tor, Berlin über Google Geocoding per HTTPS geprüft: `OK`, ein Ergebnis. Kein Auftragsdatensatz angelegt, keine Zugangsdaten ausgegeben.

## PLZ-/Bereichspreise, Rabatte und Bereichspflege – 13. Oktober 2026

- Alle vier angemeldeten PHP-Masken und ihre Speicher-/Zuordnungsregeln vor der Umsetzung geprüft. Echtes Schema und Daten nur lesend: PLZ und Bereiche jeweils 10 × 10 Zellen, keine mehrdeutigen Tarifzellen; erster Bereich mit zwei PLZ-Zuordnungen wie in der Altmaske. Lesezeit im Probeaufruf ca. 268 bzw. 110 ms.
- Frontend-Produktionsbuild und vollständiges Maven `clean verify` mit isolierter MariaDB 11.4 erfolgreich: **391 Tests, 388 bestanden, 0 Fehler, 3 optionale Bestandsprüfungen übersprungen**. SQL-Architekturprüfung unverändert.
- Neue Tests prüfen Zugriffsrechte/CSRF, Feldpräzision, Kunden-/Niederlassungsgrenzen, Fahrzeugzuordnung, Blättern, Richtungstrennung, Preis-/Rabatt-Erhalt, Historie, veraltete Revisionen, doppelte Zeilen und Wiederholungsbelege. Bereichsnamen, eindeutige PLZ-Zuordnung je Niederlassung, symmetrische und nicht transitive Nachbarschaften, Reparatur einseitiger Verknüpfungen sowie Rollback bei fehlendem Rückweg bzw. Beleg getestet.
- Isolierte Browserfixture auf Port 18744: PLZ-Preis und Frachtvergütung speichern/erneut lesen, Zeilen blättern; Bereich anlegen/umbenennen, PLZ verknüpfen/entfernen, Nachbarn hinzufügen und auf Gegenseite kontrollieren sowie entfernen. Kundenspezifische Bereichsrabatte einschließlich Fahrzeugzuordnung und Vergleichswerten gespeichert. Entwurfsschutz über eigenen Dialog bestätigt, keine Konsolenwarnungen/-fehler. Nachweise: `work/bereichsrabatte-ui-test.png`, `work/bereichspflege-ui-test.png`.
- Anwendung um 15:00 Uhr mit dem geprüften JAR auf Port 8080 neu gestartet. Der vorhandene Browser-Tab zeigt die Anmeldung.
- Geschäftsdatenschreibtests ausschließlich gegen disposable MariaDB bzw. Browserfixture. Keine Teständerungen in der Bestandsdatenbank. Die vorhandenen InnoDB-Schreibtabellen wurden ohne Schemaänderung weiterverwendet.

## Servicepreise, Servicerabatte und Typverwaltung – 13. Oktober 2026

- Alte angemeldete PHP-Matrizen in beiden Servicemodi, Rabattmodus, Preis-/Leistungstypverwaltung und Gruppenmaske mit Quellen abgeglichen.
- Bestandsdatenbank nur lesend geprüft: Modus 0 mit 9 × 20 Zellen, Modus 1 mit 13 × 14 Zellen; keine mehrdeutigen Zellen. Typverwaltung liest 14 Preistypen, 13 Leistungstypen und 239 freigegebene Gruppen. Kundensuche liefert die begrenzte Auswahl von 100 Bestandskunden.
- Frontend-Produktionsbuild und vollständiges Maven `clean verify` mit isolierter MariaDB erfolgreich: **383 Tests, 380 bestanden, 0 Fehler, 3 optionale Bestandsprüfungen übersprungen**. Zusätzliche Integrationsprüfungen decken Preis-/Rabatt-Erhalt, Wirksamkeitsdatum, Kunden-/Niederlassungsgrenzen, Konflikte, doppelte Bestandszeilen, Rollback, wiederholte Speicherung, Typenpflege und Protokollwiederaufnahme vor und nach erfolgtem MyISAM-Insert ab.
- Isolierter Browser-Test auf Port 18744: deutsche Dezimaleingaben, Preis-/Rabatt-Speicherung, Kundenauswahl, Zukunftsdatum, Anzeigeumschalter, Typ-Neuanlage mit Gruppe, Umbenennung, Löschvorschau und Entwurfsschutz. Keine Konsolenwarnungen oder -fehler. Nachweis: `work/servicepreise-ui-test.png`. Keine fachlichen Schreibtests gegen die Bestandsdatenbank.
- Anwendung am 13. Oktober 2026 um 14:28 Uhr mit dem geprüften JAR auf Port 8080 neu gestartet; Start erfolgreich. Der vorhandene Browser-Tab zeigt die Anmeldung.
- Grenzen: Browser-Schreibtest mit API-Fixture, Datenbank-Schreibtest mit disposable MariaDB; keine behauptete Live-Schreibprüfung. PLZ-/Bereichstarifpflege wurde anschließend ergänzt (siehe neuesten Prüfstand oben).

## Auftragsfilter und Adresszuordnungen – 13. Oktober 2026

- Vorheriger abgeschlossener Build: **374 Tests, 371 bestanden, 3 optionale Live-Prüfungen übersprungen**.
- Angemeldete PHP-Filterverwaltung mit Langtexten sowie PLZ-/Bereichsadressmasken und Quellen geprüft. Bestandsabfragen: 92 Filter, 0 offene Filtervorgänge, 3 PLZ-Adresszuordnungen und 11.524 Bereichsadresszuordnungen (erste 100 geladen).
- Isolierte UI- und MariaDB-Tests prüfen Filterpflege, wiederaufnehmbare MyISAM-Vorgänge, Hausnummernbereiche/Parität, Bereichsauffüllung, Ausnahmezuordnung und Löschvorschau. Nachweise: `work/filter-ui-test.png`, `work/plz-adressen-ui-test.png`, `work/bereichsadressen-ui-test.png`.


## Nachrichten, Formulardefinitionen, Newsletter und Bewertungen – 13. Oktober 2026

- Angemeldete alte PHP-Masken und Aktionspfade vor der Umsetzung geprüft. Echte Datenbank ausschließlich lesend: Nachrichten-/Mitteilungstabellen samt Engine, 39 Formularkategorien, 580 Felddefinitionen, 28 Vorlagen; Newsletter 20 Felder, Bewertungen neun Felder. Alle sechs Bewertungsauswahlen liefern Bestandsdaten; Bewertungsvorlage im Bestand leer (ID 0).
- Frontend-Produktionsbuild erfolgreich. Maven `verify` mit isolierter MariaDB 11.4: **362 Tests, 359 bestanden, 0 Fehler, 3 optionale Bestandsprüfungen übersprungen**. SQL-Architekturprüfung unverändert. Kontakt- und Bewertungsabläufe gegen die isolierte DB prüfen IDs, Kategorienabgrenzung, Historie, Konflikte, Löschung und Rollback.
- Nachrichtenprüfungen: unabhängige Rechte, Niederlassungs-/Empfängergrenzen, veraltete Revisionen, MyISAM-Teilfehler, derselbe Versandtoken, Benutzer-Deduplizierung, konkurrierende Antwortbestätigung und Gruppenlöschung mit Mitgliedern. Keine echten Endgerätenachrichten geschrieben.
- Newsletterprüfungen: UTF-8 und Bildformat/-größe, Kategorien-/Feldabgrenzung, Vorlagen-Sanitizing, verschachtelte Leerblöcke, persönliche Abmeldeschlüssel, Einwilligungen/Empfängerauswahl, fremde Tokens, geänderter Inhalt und unklare SMTP-Zustellung. HTML, Textalternative, Inline-Bilder sowie Cc/Bcc per SMTP ausschließlich an lokalen Testserver übergeben. Keine externe E-Mail; zentrale Metadatenbank für Newsletter-Abmeldeschlüssel nicht live geprüft.
- Isolierte UI-Fixture auf Port 18744: Endgeräteantwort und Mitteilung, Nachrichtengruppe mit allgemeiner Gruppe anlegen und direkten Transporteur zuordnen; Formulardefinitionen sortieren/ergänzen, Vorlageninhalt speichern/erneut lesen; Newsletter bearbeiten, Ausgabe, Versandvorschau und Ergebnis; Bewertung mit Zeitraum, Niederlassung und Kunde anlegen/erneut öffnen/ausgeben. UI-Mailversand simuliert, ohne SMTP. Bild-Upload-Dialog nicht per Browser bedient; Bildvalidierung automatisiert geprüft.
- Prüfbilder: `work/nachrichten-ui-test.jpg`, `work/nachrichtengruppen-ui-test.png`, `work/formulare-ui-test.png`, `work/newsletter-ui-test.png`, `work/newsletter-versand-ui-test.png`, `work/bewertungen-ui-test.png`.
- Verbliebene Funktionslücken und betriebliche Grenzen stehen im [Menüabgleich](MENUE-ABGLEICH.md). Der gesamte Menüumfang ist weiterhin nicht abgeschlossen.

## Kontakte, Kundenstatuswechsel, Motivation-Counter und E-Mail – 13. Oktober 2026

- PHP-Oberflächen und Source für alle vier Bereiche abgeglichen; echtes Schema und Metafelddefinitionen ausschließlich lesend geprüft. Berlin besitzt 30 Kontaktfelder; im aktuellen Bereich keine Kontakte. Der native Motivation-Counter liefert wie die PHP-Seite 2 abgeschlossene Aufträge und 82,98 € für Oktober 2026.
- `npm --prefix frontend run build` erfolgreich. `CRM_INTEGRATION_URL=jdbc:mariadb://127.0.0.1:33079/crm_qa backend/mvnw -q -f backend/pom.xml verify`: **293 Tests, 290 bestanden, 0 Fehler, 3 optionale Bestandsprüfungen übersprungen**. Die Architekturprüfung bleibt unverändert: Raw-JDBC nur im eigenen `DatabaseServiceTest`; alle Geschäftsabläufe benutzen `DatabaseService`.
- Separate temporäre MariaDB 11.4 ausschließlich für Tests: Kontakt-Neuanlage mit zwei parallelen Schreibern, eindeutige IDs, Aktualisierung, Konfliktschutz, Feldhistorie, Löschung und vollständiges Rollback nach Teiländerung geprüft. Keine Schema- oder Geschäftsdatenänderungen in der vorhandenen VoTiAn-Datenbank.
- Benachrichtigungen: Empfängerabgrenzung, Deduplizierung, fehlende Adressen, Header-Injection, geänderte Terminrevision, falscher Benutzer, doppelte Bestätigung und SMTP-Fehler automatisiert geprüft. Echte SMTP-Protokollkommunikation nur gegen einen lokalen Testserver, mit UTF-8 und BCC-Empfängern. **Keine echte E-Mail gesendet; Relay-Zugang/Zustellung extern nicht getestet.**
- Isolierte Browserfixture auf Port 18744: Kontakte anlegen/ändern, Verlauf, Entwurfsschutz, Druckansicht, Kundenstatusauswertung, Niederlassungsvergleich, passwortgeschützte Zielpflege sowie Benachrichtigung nach Termin-Neuanlage und Versandvorschau/Versandergebnis bedient. Keine Konsolenfehler. Abnahmebilder: `work/crm-motivation-ui.jpg`, `work/crm-mail-ui.jpg`.
- Aktuelles JAR mit identischem Frontend-Build auf Port 8080 neu gestartet. Bestehende Anmeldung wiederverwendet; Verbindung zum Bestand und neue Kontaktfelder/Umsatzansicht im Browser geprüft. Die Statusauswertung über alle freigegebenen Niederlassungen zeigt die im PHP-Abgleich vorhandenen Bestandskundenzuordnungen für DD, HB und L. Keine Browser-Konsolenfehler. Die Zielpflege erfordert den im Bestand noch fehlenden Parameter `MOTIVATIONCOUNTER_PASSWORD`.
- Funktionsumfang und bewusste Unterschiede stehen im [Menüabgleich](MENUE-ABGLEICH.md).


## Vertriebskalender und Termine – 12. Oktober 2026

- Alte PHP-Kalender-, Bearbeitungs- und Statistikoberfläche im angemeldeten Browser angesehen; Aktionspfade, Tabellenengine, Teilnehmerformat, Metatypen und Parameter anhand von PHP/Schema geprüft.
- Frontend-Produktionsbuild und Maven `verify` erfolgreich: **265 Backend-Tests bestanden, 3 optionale Live-Tests übersprungen, keine Fehler**. 21 neue Prüfungen für Rechte/CSRF, unverzichtbare Sichtbarkeit in Liste und Statistik, Mandantengrenzen, Zeitraum/Überlappung, Teilnehmer, UTF-8-Länge, unveränderliche Altverknüpfungen, Revision/MyISAM-Konflikte, eigene Bestätigung, Terminabschluss und Wiedervorlage.
- Echte Datenbank ausschließlich gelesen: Optionen mit 151 Mitarbeitern und sechs verfügbaren Gruppen, Kundensuche, Jahresliste und Statistik 2026 (0) sowie 2025 (1) für die eigene Niederlassung erfolgreich. Die Zahlen sind auf die Sichtbarkeit dieses Kontos beschränkt, keine globale Bestandszählung.
- Isolierter Browser-Server ohne DB-Anbindung: Tag/Woche/Monat/Jahr, mehrtägiger Termin, Bestätigung der eigenen Teilnahme, Bearbeitung/Terminverschiebung, Entwurf behalten, Termin erledigen, Wiedervorlage, Folgetermin aus Kundenbericht samt Teilnehmergruppe und Rückfrage für allgemeinen Terminartwert geprüft. Die Statistik zählt vier Testtermine, obwohl ein Termin in zwei Tageszellen erscheint. Keine echten Geschäftsdaten angelegt, geändert oder gelöscht.
- Datumseingaben im eingebetteten Browser verwenden native Input-Ereignisse; geänderte Uhrzeiten wurden nach dem Speichern erneut angezeigt. Löschrechte, unzugängliche Termine und konkurrierende Änderungen sind automatisiert gegen Mocks geprüft. Die eigenständige Playwright-Suite wurde nicht ausgeführt.
- Finales JAR mit dem aktuellen Frontend neu gestartet. Bestehende Browser-Anmeldung wiederverwendet, DB-Status verbunden; Vertriebskalender 2025 zeigt den vorhandenen sichtbaren Termin, Tagesansicht wieder auf heute gesetzt. Keine Browser-Konsolenfehler. Abnahmebild mit isolierten Testdaten: `work/vertrieb-ui-test.jpg`.
- Offener Funktionsumfang und bewusste Unterschiede zur PHP-Fassung: [MENUE-ABGLEICH.md](MENUE-ABGLEICH.md), Abschnitt Vertriebskalender.

## Kunden- und Transporteursberichte – 12. Oktober 2026, weiterer Verwaltungsblock

- PHP-Oberflächen für beide Berichtsarten und die Berichtsstatistik im angemeldeten Browser angesehen, Quellcode und reale Metatypen/Tabellenschemata abgeglichen.
- Frontend-Produktionsbuild und Maven `verify` erfolgreich: **244 Backend-Tests bestanden, 3 optionale Live-Tests übersprungen, keine Fehler**. 16 zusätzliche Prüfungen sichern Berichtsrechte, CSRF, Mandantengrenzen, Vertraulichkeit in Liste/Zählung/Statistik, Hauptkundenbezug, SQL-Parameter, UTF-8-Länge, Revisionen und konkurrierende MyISAM-Änderungen ab. Der Fehlerfall beim nachgelagerten Terminabschluss darf keine doppelte Berichtsanlage auslösen.
- Echte Datenbank ausschließlich per SELECT geprüft: beide Optionen-/Objektsuchen und sämtliche sieben Sortierungen, Statistik mit Aufteilung. Ergebnis für eigene Niederlassung und 01.07.–12.10.2026: drei Kundenberichte / null Transporteursberichte; Liste und Statistik stimmen mit der alten Oberfläche überein.
- Isolierter Browser-Server ohne Datenbank: vorhandenen Kundenbericht bearbeitet und vertraulich gemacht; Abbrechen/Weiterbearbeiten erhält den Entwurf; neuen Transporteursbericht angelegt, allgemeiner Berichtstyp ausdrücklich bestätigt; Berichtsstatistik nach Typ/Kundentyp und CSV-Datei inhaltlich geprüft. Keine echten Berichte oder Termine angelegt, geändert oder gelöscht. Löschrechte und konkurrierende Löschung sind automatisiert mit Mock-Daten geprüft.
- Anwendung mit dem gebauten JAR neu gestartet. Bestehende Anmeldung verwendet, Datenbankstatus verbunden; native Kundenberichtsliste mit drei Einträgen und Berichtsstatistik im echten Backend angezeigt, keine Browser-Konsolenfehler.
- Umsetzungsgrenzen, insbesondere Zusatzformulare (CRM-Termin-Neuanlage im späteren Vertriebsblock ergänzt), stehen im [MENUE-ABGLEICH.md](MENUE-ABGLEICH.md). Die automatisierte Playwright-Suite wurde nicht ausgeführt; Bedienprüfungen erfolgten über den integrierten Browser.

## Verwaltung und Zeitraumstatistik – 12. Oktober 2026

- Die alten PHP-Ansichten für Feiertage, Anfahrtszeiten, Gruppen, Impressum und Statistik wurden vor der Portierung im angemeldeten Browser geprüft. Listenerfassung, Filter und Berichte wurden ebenfalls angesehen und waren in diesem Prüfstand noch offen; der spätere Berichtsblock ist oben dokumentiert. Umfang und Abweichungen: [MENUE-ABGLEICH.md](MENUE-ABGLEICH.md).
- Frontend-Produktionsbuild erfolgreich; Backend: **228 Tests bestanden, 3 optionale Live-Tests übersprungen**, keine Fehler. Die 23 zusätzlichen Tests prüfen unter anderem Revisionen, Rechte, geschützte Tage/Systemgruppen, Zeitfenster, Gruppenzyklen, SQL-Parameter, getrennte Statistikrechte und CSRF.
- Isolierter Browsertest ohne DB: Feiertage aus Vorlage übernehmen/speichern, CLASSIC-/BWV-Trennung und einzelne Anfahrtszeit speichern, Gruppe anlegen, Mitglied hinzufügen/entfernen, Vergleichsstatistik mit 1234 Aufträgen und CSV-Download. Der Schutz ungespeicherter Eingaben wurde als Anwendungsdialog geprüft. Keine Löschaktion gegen den echten Bestand.
- Echte SELECT-Prüfungen: Feiertagsansicht, Gruppenliste, alle elf Mitgliedsarten, CLASSIC/BWV sowie alle zwölf Statistikaufteilungen erfolgreich. Ein Zeichensatzkonflikt bei Fahrzeugtypnamen wurde dabei gefunden und korrigiert. Keine echten Verwaltungsdaten geschrieben.
- Die bestehenden Browsertests wurden auf die serverseitige Statistik umgestellt; die automatisierte Playwright-Suite wurde in diesem Durchlauf nicht ausgeführt. Die genannten Bedienprüfungen erfolgten über den integrierten Browser.

## Freie Artikel, Tastenkürzel, Nachhaltigkeit und Niederlassungen – 12. Oktober 2026

- Frontend-Build erfolgreich; Backend: **205 bestanden, 3 optionale Live-Tests übersprungen**, keine Fehler. Prüfung von freien Artikeln/Vorlagen, Eingabegrenzen, CO₂e-Vertrag/Cache/Preiszeilen, Niederlassungsrechten und isoliertem Anfragekontext.
- Isolierte Browserprüfung: freie Artikel, manuelle Nachhaltigkeitsvorschau, Alt+E/G/S/L, Unterdialogschutz und bestätigter Niederlassungswechsel. Speichern am Fixture-Server gesperrt. Gewünschte Hinweisbox entfernt.
- Sieben neue Rechte-/Fahrzeugspalten und neun freigegebene Niederlassungen des Zentralenkontos per SELECT bestätigt. Keine echten Aufträge/Lagerbuchungen angelegt.
- CO₂e-Zugangsdaten und PZM-Endpunkt autorisiert in lokale ignorierte `.env` übernommen. Aktiver Google-Schlüssel aus separater PHP-Parameterquelle wegen Zugriffsverweigerung nicht abrufbar. Kein erfolgreicher Live-Lauf externer Berechnungsdienste behauptet.
- Altmenü mit Untermenüs im Browser und PHP geprüft: [vollständiger Menüabgleich](MENUE-ABGLEICH.md).


## Kostensplit, Unteraufträge, Artikel/Lager und Karte – 12. Oktober 2026

- Die vier Funktionen sind in der nativen Erfassung implementiert. Fachliche Grenzen und Bestandsparameter: [AUFTRAGSERFASSUNG.md](AUFTRAGSERFASSUNG.md).
- Frontend-Produktionsbuild und Maven-Testlauf erfolgreich: **190 Tests bestanden**, 3 optionale Live-Integrationstests übersprungen, keine Fehler. Die Tests umfassen Kostenrundung, Unteraufträge/Gegenbuchungen, Rechte, Idempotenz, Lagerbestände und Sperren, Seriennummern, Rollback, Vorlagenkopien und Kartenkoordinaten.
- Browserprüfung mit isolierten API-Antworten: Eingabe und Vorschau aller vier Funktionen, Lagerauswahl, Kartenfehler/Übernahme und stabile Artikelzuordnung beim Umordnen der Stationen. Speichern am Fixture-Server gesperrt.
- Bestandsprüfung ausschließlich mit SELECT: Artikel-/Lagerspalten und InnoDB, Kartenparameter und technische Verrechnungskostenstellen. Keine echten Auftrags-, Verrechnungs- oder Lagerbuchungen angelegt. Eine reale fachliche Abnahme mit PHP-Abrechnung bleibt erforderlich.
- Die folgenden Abschnitte dokumentieren frühere Prüfstände.

## Sonderprozesse der Auftragserfassung – 12. Oktober 2026

- Fotoworkflows je Kunde/Station, automatische Kilometer-/PZM-Kalkulation, Fernverkehr/ASAP und Auslandsabholung sind implementiert; Details und Dienstkonfiguration: [AUFTRAGSERFASSUNG.md](AUFTRAGSERFASSUNG.md).
- Frontend-Build und Maven `verify`: erfolgreich. **145 Backend-Tests bestanden**, 3 optionale Live-Integrationstests deaktiviert. Neue Tests prüfen unter anderem Fotoübertragung mit wiederaufnehmbaren Leases ohne HTTP unter Datenbanksperren, Stationsauswahl/Barzahler, PHP-Preismarker, Mindestpreise, Fernverkehr, Auslands-Rundfahrten, fehlerhafte Dienstantworten und begrenzte HTTP-Antworten.
- **36 Playwright-Prüfungen bestanden**, darunter 11 Erfassungsprüfungen. Die Sonderprozess-Vorschau wurde zusätzlich visuell geprüft. Browser-APIs sind vollständig simuliert; der Testserver verwendet ausdrücklich eine unerreichbare Datenbankadresse.
- **28 Python-Tests bestanden.**
- Ausschließlich lesend gegen den Bestand geprüft: benötigte HQ-Spalten, PLZ-Geodaten/-Polygone und Vorhandensein der Foto-, Fernverkehrs- und PZM-Parameter. Keine Parameterwerte mit Zugangsdaten wurden ausgegeben. Der Geocache und lokale PZM-/Google-Verbindungsparameter sind in der erreichbaren DB nicht vorhanden; `PZM_URL` und `GOOGLE_MAPS_API_KEY` müssen über die Umgebung bereitgestellt werden.
- Keine produktiven Aufträge oder Fotoauswahlen angelegt. Ein echter Durchlauf mit PZM, Fotodienst, PHP-Disposition, Fahrergerät und Abrechnung steht noch aus.

## Auftragserfassung – 12. Oktober 2026

Die native Erfassung ist für Sofortaufträge, Vorbestellungen, Daueraufträge, Barzahlung, Fahrzeugzuweisung und Nacherfassung implementiert. Fachlicher Umfang und verbleibende Grenzen: [AUFTRAGSERFASSUNG.md](AUFTRAGSERFASSUNG.md).

- Frontend-Produktionsbuild und Maven `verify`: erfolgreich. 117 Backend-Tests bestanden; die 3 ausdrücklich optionalen Live-Integrationstests waren in diesem Build deaktiviert.
- Playwright: alle 32 Browserprüfungen bestanden, davon 7 neue Erfassungsabläufe. Isolierte API-Antworten, ausdrücklich unerreichbare DB für den Browser-Testserver.
- Python: alle 28 Tests bestanden.
- Zusätzliche echte SELECT-Prüfungen: Tabellen/Datentypen/Engines, Erfassungsoptionen, Kostenstellen, gespeicherte Adressen, Fahrzeuge, Vermittlungs-/Filterabfragen sowie eine Festpreisvorschau erfolgreich. Ein nicht vorhandener Kundenparameter wurde dabei korrigiert: `CUSTOMER_MASK_JB_INCOMPLETE_<id>` ist eine Parametereinstellung, keine Kundenspalte.
- Transaktionsgrenzen, Rollback, Wiederholungen nach fehlender Speicherantwort, Preisänderungen, Recht 7/38/39, CSRF und MyISAM-Protokollwiederholung sind automatisiert ohne Bestandsänderungen geprüft.
- Kein produktiver Auftrag wurde zum Test angelegt oder geändert. Eine reale fachliche Abnahme einschließlich PHP-Hintergrundverarbeitung, Fahrergerät und Abrechnung steht aus.

Die neue Anwendung ist nicht mehr generell schreibgesperrt: Neuanlagen mit Recht 7 besitzen einen eigenen transaktionalen Schreibpfad. Andere Bestandsänderungen bleiben deaktiviert. Die folgenden Abschnitte dokumentieren historische Prüfstände und sind für den heutigen Erfassungsumfang durch den obigen Nachtrag ergänzt.

## Erste Bestandsanbindung – 1. Oktober 2026

## Aktuelle Umstellung auf den zentralen Datenbankservice

Die neue Anwendung verwendet für jeden Datenbankzugriff `database.DatabaseService`, einschließlich Anmeldung, Listen, CSV-Leseabfragen, Verbindungstest und Schemadiagnose. Python ist bei der Diagnose nur noch der Launcher des Java-JARs. Der zentrale Schreibzugang bleibt gesperrt. Architekturtests erzwingen die Grenze auch für die Integrationstests; die PHP-Altanwendung bleibt unverändert.

Nach wiederhergestellter Datenbankverbindung wurden am 1. Oktober 2026 um 17:00 Uhr **49 Backend-Tests einschließlich des Integrationstests gegen die Bestandsdatenbank** erfolgreich ausgeführt: keine Fehler, keine übersprungenen Tests. Außerdem bestanden alle **10 Python-Tests**. Der Integrationstest lädt Aufträge, Kunden und Kuriere über die API und den zentralen Service mit simuliertem Anwendungskonto und echten SELECT-Abfragen.

Die erneute Java-CLI-Diagnose war ebenfalls erfolgreich: MariaDB `11.7.2-MariaDB-ubu2404-log`, 13 geprüfte Tabellen, keine fehlenden erforderlichen Spalten. Es wurden keine Daten oder Tabellen geändert. Die Anwendung bleibt gestoppt; nach den Tests waren die Ports 8080 und 5173 frei.

Im ersten erreichbaren Testlauf fiel eine ungeeignete Prüfung von `@@session.tx_read_only` auf: Dieser Wert beschreibt den Sessionstandard, nicht den Modus der einzelnen Transaktion. Die Prüfung wurde ersetzt und der Service aktiviert nun ausdrücklich `DataSourceTransactionManager.setEnforceReadOnly(true)`. Ein zusätzlicher Test mit echtem Transaktionsmanager und gemockter Verbindung prüft die Reihenfolge `SET TRANSACTION READ ONLY → SELECT → COMMIT`; es gibt keine Schreibversuche gegen den Bestand. Grundlagen: [MariaDB SET TRANSACTION](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/set-commands/set-transaction), [Spring DataSourceTransactionManager](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/datasource/DataSourceTransactionManager.html#setEnforceReadOnly(boolean)).

Der zuvor bei unterbrochener Verbindung geprüfte Fehlerfall bleibt gültig: Der CLI-Modus liefert bereinigtes JSON mit `reason: UNAVAILABLE`, Exitcode 1 und startet keinen Webserver.

## Durchgeführt

| Prüfung | Ergebnis |
|---|---|
| React-/TypeScript-Produktionsbuild | Erfolgreich |
| Spring-Boot `clean verify`, inklusive gebündeltem React | Erfolgreich |
| 20 Backend-Tests ohne Bestandszugriff | Erfolgreich: Legacy-Mapping einschließlich Boolean-Flags und mehrwertiger Statuscodes, Rechte, Niederlassung, CSV, gesperrte Schreibmethoden |
| 1 optionaler Integrationstest mit vorhandener Datenbank | Erfolgreich: Auftrags-, Kunden- und Kurier-API über MockMvc mit echten JDBC-Abfragen; Test-Authentifizierung, keine Datenänderungen |
| 7 Python-Konfigurationstests | Erfolgreich: Kommentare, Escaping, Umgebungspriorität, keine PHP-Ausführung |
| 1 HTTP-Integrationstest gegen das gebaute JAR | Erfolgreich: Health, Offline-Systemzustand, geschützte API, öffentliche Logo-Datei |
| Manuelle Browserprüfung im integrierten Browser | Anmeldung mit Testantworten, Auftragsliste, Mehrstoppdetails, Disposition, Touren, Kunden, Kuriere, Abrechnungshinweis, Auswertung, serverseitige Suche, Logout und eingeschränktes Folgekonto geprüft |
| Browserprüfung mit fehlenden Preisen und Terminen | Keine Browserfehler; unbekannte Werte bleiben „–“, Summen als unvollständig gekennzeichnet |
| Abhängigkeiten des Frontends | `npm install` meldet keine bekannten Sicherheitslücken |
| Verbindung und Schemametadaten der Bestandsdatenbank | Erfolgreich mit `scripts/check-database.py`: 13 Tabellen geprüft, keine erforderlichen Spalten fehlen; keine Anwendungsdatensätze gelesen und keine Schreibzugriffe |
| Backend nach Neustart mit dem konfigurierten Datenbankkonto | Erfolgreich: `GET /api/health` liefert `status: UP`; `GET /api/system` liefert `connected: true`, `reason: CONNECTED`, `readOnly: true`, `schemaChanges: false` |

Für die Browserprüfung diente ausschließlich ein separater lokaler HTTP-Testserver mit ausdrücklich markierten Testantworten. Er ist kein Bestandteil der Anwendung und hat keine Datenbank. Es wurden keine Testdatensätze in MySQL angelegt. Die vollständige automatisierte Playwright-Browsersuite ist vorbereitet, konnte hier wegen eines abgewiesenen Chrome-Prozessstarts nicht ausgeführt werden; sie wird nicht als bestanden gewertet. Die entsprechende Bedienung wurde im integrierten Browser geprüft.

## Verbindung zur Bestandsdatenbank

Die lokale Verbindungskonfiguration steht in der `.env` im Projektstamm: `DB_URL` enthält Host, Port und Datenbanknamen; `DB_USER` und `DB_PASSWORD` enthalten das Datenbankkonto. Die Prüfung am 1. Oktober 2026 mit `scripts/check-database.py` war erfolgreich:

- Verbindung: `connected: true`
- Serverversion: `11.7.2-MariaDB-ubu2404-log`
- Geprüfte Tabellen: `checkedTables: 13`
- Fehlende erforderliche Spalten: `missingColumns: {}`
- Gelesene Anwendungsdatensätze: `applicationRowsRead: 0`
- Schreibzugriffe: `writes: 0`

Die mit dem zuvor verwendeten Datenbankkonto aufgetretene Anmeldungssperre (MySQL-Fehler **1045**, auch beim Versuch mit TLS) blockiert den Zugriff mit dem anschließend konfigurierten Datenbankkonto nicht mehr. Die Prüfung hat ausschließlich Server- und Schemametadaten gelesen; sie bestätigt die Existenz der vom Prüfskript benötigten Tabellen und Spalten.

## Noch nicht erfolgreich geprüft

Die SQL-Zuordnungen beruhen auf dem vorhandenen PHP-Quellcode. Die drei Listen wurden mit jeweils 500 Bestandsdatensätzen erfolgreich gelesen. Der Fehler beim Kunden-/Kurierlesen wurde zuvor als `NumberFormatException` bei `company.cmp_archived` reproduziert: JDBC lieferte einen Boolean, der Mapper erwartete eine Zahl. Der Mapper akzeptiert nun Boolean-Flags; `tinyInt1isBit=false` erhält außerdem mehrwertige numerische Legacy-Codes. Alle 21 Backend-Tests einschließlich der optionalen Bestandsprüfung bestanden nach der Korrektur.

Die Bestandsprüfung verwendet ausschließlich für den Test eine simulierte Authentifizierung innerhalb einer vorhandenen Niederlassung. Sie bestätigt weder die reale Benutzeranmeldung noch sämtliche Filter und Berechtigungsgrenzen. Diese sowie die fachlichen Ergebnisse sind weiterhin gegen die PHP-Anwendung zu vergleichen.

### Tagesansicht der offenen Aufträge

Am 1. Oktober 2026 wurde die Auswahl für das vorhandene Zentralenkonto `admin_b` zusätzlich mit dessen Niederlassung und Rechten über den echten Leseadapter geprüft: Status `DISPOSITION` und Abholdatum 1. Oktober 2026 liefern genau einen Auftrag, `21891299`. Die zuvor fehlende Datumseinschränkung hatte auch historische und weit in der Zukunft geplante Aufträge geladen. Die Oberfläche verwendet wie die Standardliste im PHP-Bestand den heutigen lokalen Kalendertag als vorbelegten Zeitraum; andere Zeiträume bleiben über die Filter auswählbar. Es gibt keine fest programmierte Konto- oder Auftragsausnahme und keine Statusänderung in der Datenbank.

Frontend- und Backend-Build nach dieser Änderung erfolgreich (20 reguläre Backend-Tests bestanden; die optionale Bestands-Testsuite in diesem Build deaktiviert). Im Browser mit isolierten Testantworten geprüft: Schon die erste Listenanfrage enthält beide Tagesgrenzen; ein bewusst erweiterter Zeitraum zeigt zusätzlich einen Zukunftsauftrag; „Heute“ reduziert die Liste wieder auf den Tagesbestand. Das laufende Backend wurde neu gestartet und liefert den aktualisierten Frontend-Build.

## Bewusst noch offene Fachlichkeit

Die neue Oberfläche und der JDBC-Leseadapter sind eine erste Ausbaustufe, keine vollständige fachliche Ablösung. Noch offen sind insbesondere:

- Native Auftragserfassung/-bearbeitung, Disposition mit Fahrerkommunikation, Stationsabschluss und Storno einschließlich Gegenbuchungen.
- Originale Tarife, Preisgültigkeiten, Rabatte, Zuschläge, Kurierabrechnung, Rechnungserstellung und Buchhaltungsexporte.
- Kostenstellenhierarchie, separate Fahrzeuge, Daueraufträge, Tourvorlagen, Lager/Artikel und kundenspezifische Schnittstellen.
- Kunden-/Kurierportale, zusätzliche Niederlassungsrechte, Archiv- und Log-Datenbanken.
- Konfiguration der tatsächlich vorhandenen PHP-Basisadresse `LEGACY_APP_URL`, um noch nicht portierte Fachabläufe gezielt aufzurufen.

Die Detailanalyse steht in `ALTSYSTEM-ANALYSE.md`. Es gibt keine neue Datenbank, keine automatische Schemaänderung und keinen Seed-Mechanismus. Die bisherige PHP-Anwendung wurde durch diese Umsetzung nicht verändert.