votianng/docs/PRUEFSTATUS.md

# Prüfstatus

## 2026-10-20 · Umsetzbare Restpunkte und Betriebsstatus

Die im letzten fachlichen Abgleich konkret benannten Lücken in Transporteurstatistik und Neukalkulation waren bereits geschlossen. Zusätzlich ist nun die bisher fehlende **lesende Betriebsübersicht** unter Verwaltung → Betriebsstatus vorhanden. Referenz sind die erneut direkt vom Server gelesene `sysadmin/monitor.php` (SHA-256 `6a5cc86a12be3867283192f39e4958e365d20141ea32508d4d2ccdeff44c3e79`), die Dauerauftrags-/Vermittlungsprogramme und die im Browser geöffnete PHP-Monitoransicht. Keine alte lokale PHP-Version verwendet.

- **Sechs native Dienste:** Abschlussverarbeitung, Daueraufträge, Status-E-Mails, automatische Angebote, Angebotsentzug und BWV-Retouren. Aktivierung, Niederlassungsumfang, letzter abgeschlossener Lauf und dessen Ergebnis-/Fehlerzahlen werden angezeigt. Fehlende Freigabe der PHP-Abschaltung, fehlende Niederlassungen und unvollständige SMTP-Konfiguration erscheinen bei eingeschaltetem Dienst ausdrücklich. Die Laufwerte gelten für diese NG-Instanz und beginnen nach Neustart neu; es handelt sich nicht um eine dauerhafte Laufhistorie. Mehr als drei Minuten ohne Abschluss ergibt einen Hinweis, keinen behaupteten Prozessabsturz.
- **Gemeinsame Lebenszeichen:** `standing_orders` und `autoranking` aus `keepalive`, einschließlich fehlender, mehrdeutiger, veralteter oder zukünftiger Zeitstempel. Vergleich mit der Datenbankzeit. Diese Einträge können von PHP oder NG stammen und belegen keine exklusive Zuständigkeit.
- **Niederlassungsbezogene Zähler:** erledigte und laufende Aufträge, Gesamtzahl/höchste Nummer, verfügbare Transporteure und Vermittlungssperren sowie heutige Geräte-Abschlussmeldungen. PHP-Auswahlregeln für Storno und Status bleiben erhalten; Tagesgrenzen schließen den folgenden Mitternachtstermin aus. Geräte-Abschlussmeldungen zählen Ereignisse, nicht eindeutige Aufträge. Jede Datenquelle kann separat ausfallen, ohne Nullwerte zu erfinden oder die übrige Ansicht zu blockieren.
- **Zugang:** Mitarbeiterverwaltungsrecht 3 und ursprüngliche Niederlassung. Kunden-, Kurier-, Lagerkonten und ein fremder Arbeitskontext werden vor dem Lesen abgewiesen. Es gibt keine Betriebsumschaltung oder andere Schreibaktion in dieser Ansicht.

1.307 bisher inventarisierte Serverdateien erneut anhand ihrer Prüfsummen abgeglichen: 1.301 unverändert, sechs geänderte generierte `job_options_<HQ>.js`-Kataloge. Diese wurden frisch gelesen. Das ist keine erneute vollständige Inventarisierung aller beliebigen PHP-Spezialkonfigurationen oder eigenständigen Systemadministrationsskripte.

**Auf Benutzerwunsch ausgelassen:** Der Kategorie-9-Einnahmenexport bleibt bis zum Vorliegen seiner Felddefinition und des Originalprofils 903 „RETRANS Umsatz“ gesperrt. Die Implementierung samt isolierten Prüfungen ist vorhanden. Classic-Sammelübergabe bleibt ausdrücklich ausgeschlossen. Die sechs nativen Automatikdienste bleiben ausgeschaltet: Prozess- und Mountprüfung auf dem Server bestätigt weiterhin laufende PHP-Dauerauftrags-, Vermittlungs- und Maildienste im Testsystem. Für die Umschaltung fehlen die Festlegung des Umschaltzeitpunkts und der dann allein zuständigen Instanz. Sie ist keine weitere fehlende Fachimplementierung. Remote-Prozesssteuerung, Dateisystemeingriffe und Logdatei-Auswertung der separaten PHP-Systemverwaltung werden durch die lesende Übersicht nicht als abgelöst behauptet.

Prüfung: neun neue fachliche Prüfungen einschließlich echter isolierter MariaDB; Architekturprüfung erfolgreich. Gesamtlauf **1.627 Testfälle: 1.624 erfolgreich, drei übersprungen, keine Fehler**. Frontend: 44 Tests erfolgreich, Produktionsbuild erfolgreich. 1.249 Quell-/Frontenddateien verifiziert. Browserprüfung mit echten Antworten der Testimplementierung, Aktualisieren, Ausfall und Wiederherstellung einzelner Datenquellen; keine schreibenden API-Aufrufe. Zusätzliche Leseprüfung gegen den angeschlossenen echten Bestand bestätigt alle drei Datenquellen. Lokal auf Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Dateien identisch zwischen dist/JAR/HTTP.

Nachweise: `work/operations-focused.log`, `work/operations-verification.json`, `work/operations-ui-verification.json`, `work/operations-ui.png`, `work/operations-live-read.json`, `work/operations-php-processes.json`, `work/operations-current-source-comparison.json`, `work/operations-deployment.json`. Der erste Gesamtlauf meldete zwei Architekturverletzungen im Datumszugriff/Testaufbau; beide wurden korrigiert, die Architekturregel blieb unverändert. Keine echten Aufträge, Mails, Gerätebefehle oder Exporte wurden ausgelöst. Vollständige Funktionsgleichheit aller Rollen, Konfigurationen und externen Verbraucher bleibt damit nicht abschließend bewiesen.

## 2026-10-20 · Transporteurstatistik und Neukalkulation ergänzt

Die beiden Befunde aus der Vollständigkeitsprüfung sind umgesetzt. Referenz ist weiterhin ausschließlich der Server `172.16.0.158:/data/0/votian-test/html`; die drei betroffenen PHP-Dateien wurden vor und nach der Umsetzung per SSH anhand ihrer SHA-256-Prüfsummen abgeglichen und waren unverändert.

- **Aktuelle und historische Transporteurstatistik:** `Firma UN` ist bei Aufteilung nach Transporteur/Unternehmer vorhanden. Unter „Alle Werte“ erscheinen zusätzlich Systemgebühr und Werbevergütung, einschließlich CSV und Vergleichszeiträumen. Die Werte werden erst nach der Umsatzaggregation ergänzt, gelten als heutige Stammdatenbeträge und fließen weder in Umsatzsummen noch in Diagrammkennzahlen ein. Bruttoauswahl verändert diese Stammdatenbeträge nicht; `0,00 €` bleibt ein bekannter Nullwert.
- **Eindeutige Zuordnung:** Firma und Fahrzeugwerte gehören zum angezeigten, freigegebenen Transporteur bzw. bei Unternehmergruppen zum angezeigten Unternehmer. Bevorzugt wird dessen aktive Fahrzeugkennung; andernfalls werden seine Fahrzeugstammsätze verwendet. Mehrere gleiche Werte bleiben verwendbar, widersprüchliche Werte bleiben je Betrag unbekannt und erhalten einen Hinweis. Damit wird die in PHP teilweise beliebige Fahrzeug-/Fahrerwahl bei mehreren Treffern ausdrücklich vermieden. Niederlassungsfremde Stammsätze werden nicht ergänzt.
- **Neukalkulation:** Hauptauftrag sowie positive und negative Kurier-Unteraufträge entfernen nun auch Preistyp 16 wie `jobs/job_options.php:2091`. Vorher wird eine eindeutig beschriftete alte Zahlungsbedingung unverändert als eigener Auftragsstand gesichert. Ein bereits gespeicherter neuer Auftragsstand hat Vorrang; reine Kilometerpreiszeilen werden nicht als Zahlungsbedingung interpretiert. Mehrdeutige alte Zahlungsbedingungen verhindern das Speichern. Sicherung und Preisersetzung erfolgen in derselben Transaktion; Rechnungs-/Exporttext und Wiederholbarkeit bleiben erhalten.

Referenz-Prüfsummen:

- `statistic/statistic.php`: `f71da1670901c04bef452dceea6912a49f0fa9c3a573e58f2e027e0e2aec596f`
- `statistic/statistic_sql.inc.php`: `db7c0b971795fbe062d49bcf286d6a119606859b4959f07487a4cfc7c9177d82`
- `jobs/job_options.php`: `15dcd40feb92ed804df0d3f4f0c40161e70f7144a73e2566143eba1081113d43`

Gezielte Integrationsprüfungen gegen die isolierte lokale MariaDB umfassen unveränderte Umsatzsummen, aktive und mehrdeutige Fahrzeugzuordnung, Unternehmergruppen, Niederlassungsschutz, Archivwerte, Haupt-/Unterauftragsneukalkulation, Wiederholung und vollständiges Rollback nach einem erzwungenen Fehler. Aktuelle und historische Tabellen und ihre tatsächlichen Browser-CSV-Downloads wurden mit synthetischen Daten geprüft. Frontend: 44 Tests erfolgreich, Produktionsbuild erfolgreich. Backend-Gesamtlauf: 1.618 Testfälle, davon 1.615 erfolgreich und drei übersprungen; keine Fehler. 1.245 Quell-/Frontenddateien anhand des Build-Manifests abgeglichen. Anwendung auf `localhost:8080` neu gestartet: Health UP, Datenbank verbunden, alle sechs Frontenddateien identisch zwischen `dist`, JAR und HTTP-Auslieferung. Eine zusätzliche rein lesende Stichprobe mit dem gebauten Backend gegen den angeschlossenen Hauptbestand lieferte für 100 Transporteure jeweils Firma, Systemgebühr und Werbevergütung ohne Zeilenvervielfachung.

Nachweise: `work/courier-statistics-focused.log`, `work/courier-statistics-recalculation.log`, `work/courier-statistics-business.log`, `work/courier-statistics-csv-verification.json`, `work/courier-statistics-ui.png`, `work/courier-statistics-verification.json`, `work/courier-statistics-deployment.json`, `work/courier-statistics-live-read.json`. Keine echten Aufträge, Gebühren oder Zahlungsbedingungen wurden zu Testzwecken verändert.

## 2026-10-20 · Unabhängige Vollständigkeitsprüfung (vor obiger Umsetzung)

**Nein: Vollständige Funktionsgleichheit mit der aktuellen PHP-Anwendung ist noch nicht erreicht.** Die frühere Aussage „25 von 26“ betrifft ausschließlich die damalige, abgegrenzte Restliste. Sie ist kein Maß für die gesamte Anwendung. Dieser Durchlauf war eine lesende Prüfung; keine fachlichen Änderungen, echten Buchungen, Exporte oder Nachrichten ausgeführt.

Aktuelle Referenz erneut per SSH: `172.16.0.158:/data/0/votian-test/html`. Für 47 fachliche Menüziele nach Benutzerrolle wurden entsprechende native Module zugeordnet: 35 Zentrale, acht Kunde, drei Transporteur, ein Lager. Menücontainer, doppelte Varianten und allgemeine Anmeldung/Abmeldung/Sprache/Impressum zählen dabei nicht als eigene Fachziele. Das belegt die Modulabdeckung, nicht jede Aktion oder jede Kombination von Einstellungen. Die aktuelle PHP-Statistik wurde zusätzlich im Browser lesend berechnet.

**Bestätigte fehlende Ausgabe in der Transporteurstatistik „Alle Werte“:**

- **Systemgebühr**: PHP `statistic/statistic.php:661–667, 988–996` sowie `statistic/statistic_sql.inc.php:614–620`; die neue Statistik liest und zeigt diesen Wert nicht. Im angeschlossenen Hauptbestand haben 814 von 1.132 Fahrzeugen einen Wert ungleich null.
- **Werbevergütung**: PHP `statistic/statistic.php:670–677, 999–1007`; die neue Statistik liest und zeigt diesen Wert ebenfalls nicht. Bei 294 Fahrzeugen ist er ungleich null. Obwohl der SQL-Zweig den zugehörigen Filter auf vier setzt, ergänzt die PHP-Ausgabe die Vergütung ausdrücklich nachträglich aus den Fahrzeugstammdaten. Deshalb ist das kein ungenutzter Altcode.
- **Firma des Unternehmers („Firma UN“)**: PHP `statistic/statistic_sql.inc.php:1152` und die sichtbare Ergebnistabelle enthalten sie. `StatisticsRelationships.courierExpression` und `HistoricalStatisticsMasters` bilden derzeit nur Nummer und Benutzername ab. Eine entsprechende Unternehmensspalte fehlt.

Die Felder sind bereits in der Fahrzeug-/Unternehmerstammdatenpflege vorhanden; die Lücke betrifft ihre Ausgabe in der Statistik und im zugehörigen Download. Die neue Betragsauswahl und Ergebnisspalten sind in `frontend/src/statisticsAmountColumns.mjs` festgelegt. Aktuelle und historische Statistik benötigen den entsprechenden Abgleich; Fahrzeuggebühren dürfen dabei nicht fälschlich je Auftrag summiert werden.

**Weiterhin nicht vollständig nutzbar:** Kategorie-9-Einnahmenexport. Implementierung und isolierte Prüfungen sind vorhanden, aber die heutige reine Leseprüfung findet weiterhin weder Kategorie 9 noch deren Felddefinitionen oder Exportprofile in den zugänglichen Haupt-/Metadatenbeständen. Das Originalprofil 903 „RETRANS Umsatz“ ist dadurch weiterhin nicht verifiziert. Der echte Export bleibt folgerichtig gesperrt.

**Neu zu klärende Verhaltensabweichung:** Die aktuelle, auf dem Server nicht eingecheckte Änderung in `jobs/job_options.php:2091` löscht beim Speichern zusätzlich `jobprice.mt_sort=16`. `OrderRecalculation:136` und `OrderChildRecalculation:97` behalten diesen Typ. NG verwendet für Zahlungsbedingungen eigene Auftrags-Snapshots und liest Typ 16 nur als Legacy-Rückfall. Daher ist eine fachliche Prüfung der gewünschten Übernahme nötig; ungeprüftes Löschen könnte alte Zahlungsbedingungen entfernen. Dies ist eine bestätigte Codeabweichung, noch kein nachgewiesener fehlerhafter Geschäftsvorgang.

**Betriebsumschaltung separat:** In der gelesenen lokalen `.env`/Startkonfiguration stehen sechs native Automatikdienste auf `false` beziehungsweise ihrem Standard `false`: Abschlussverarbeitung, Daueraufträge, Status-E-Mails, automatische Angebote, Angebotsentzug und BWV-Retouren. Der Code dafür ist vorhanden. Ihre Aktivierung und der Nachweis des Zusammenspiels mit den bestehenden PHP-Diensten gehören zur Umstellung; sie wurden bei dieser Prüfung nicht eingeschaltet.

Positive Befunde: 1.487 Formularfeldzuordnungen mit 79 Feldtypen besitzen passende allgemeine oder spezialisierte Implementierungen; alle 39 geprüften Vorlage/Kategorie/Niederlassungs-Kombinationen werden vom Parser für Speicherberechnungen akzeptiert; alle Spalten aus 15 konfigurierten Kundenportallisten sind bekannt. Die beiden Umsatz-Feldtypen werden durch `ReportForms`, sieben Stations-Feldtypen durch `CustomerOrderLabels` behandelt. Die alte eingeschränkte `/invoice-items`-Implementierung ist kein aktueller UI-Blocker: Die Oberfläche verwendet bereits `/invoice-preparation`.

Prüfgrenzen: Keine erneute schreibende End-to-End-Prüfung sämtlicher Rollen, externen Geräte-/Mail-/Dateidienste oder beliebiger kundenspezifischer Konfigurationen. Die neue Browserseite erforderte eine Anmeldung; die native Prüfung stützt sich hier auf aktuellen Quellcode, laufendes JAR und lesende Datenbankproben. Separate `sysadmin`-Betriebs-/Einmalskripte, nicht vorhandene `bourse`-/`jobs3`-Seiten und alle externen API-Verbraucher sind nicht durch die 47 Menüziele abgedeckt. Classic-Sammelübergabe bleibt auf ausdrücklichen Benutzerwunsch ausgeschlossen.

Nachweise: `work/parity-menu-audit-2026-10-20.json`, `work/parity-audit-read-2026-10-20.json`, `work/parity-php-statistics-ui-2026-10-20.txt` und `work/php-audit-manifest-comparison-2026-10-20.json`. Der Hashvergleich umfasst 1.307 Serverdateien; 1.205 lagen auch im vorherigen Prüfbereich, davon 15 inzwischen geändert. Die entfernte Datei ist eine alte `glob_defs`-Kopie. 1.240 native Quelldateien/Frontenddateien stimmen weiterhin mit dem zuletzt vollständig geprüften Build überein. Dessen Teststand bleibt 1.612 erfolgreich und drei gezielt übersprungen; die Tests wurden für diese reine Auditaufgabe nicht erneut als Vollsuite ausgeführt. **Kein belastbarer Gesamtprozentsatz und keine abschließende Gesamtzahl aller verbleibenden Teilfunktionen aus diesem Befund ableitbar.**

## 2026-10-19 · Abschluss der Archivstatistik und Stand der 26er-Restliste

**25 der 26 konkret erfassten Teilfunktionen sind umgesetzt, geprüft und lokal bereitgestellt.** Die letzte Funktion, der Kategorie-9-Einnahmenexport, ist technisch implementiert und isoliert geprüft. Ihr abschließender Vergleich mit dem Originalformat bleibt von der fehlenden Felddefinition und Profil 903 „RETRANS Umsatz“ abhängig. Die Restliste ist unter `work/remaining-function-inventory-2026-10-19.json` auf einen extern blockierten Punkt reduziert. Das ist keine Aussage über eine lückenlose Inventarisierung sämtlicher PHP-Spezialkonfigurationen.

Die Archivstatistik umfasst jetzt neben den drei historischen Auftragslisten die Auftrags- und Kalkulationswerte, Transporteur-Aktionen einschließlich Wiederholungen, Abholdauer, Vergleichszeiträume und gemeinsame Filter. Hinzugekommen sind Grundpreis, TSZ, gesonderter Fracht-TSZ, Servicevergütung, EAU, BSG, Kilometer, CO₂e, Brutto- und Zusatzmontagebeträge. Nicht vollständig belegte Kennzahlen bleiben leer; heutige Provisionssätze werden nicht als historische Vergütung ausgegeben. Die PHP-Bruttoregel von 19 % betrifft Geldbeträge, nicht Kilometer, CO₂e oder Prozentwerte.

Weitere Ergänzungen: Kunden-/Transporteurnummern, alte Kundenzuordnungen, Gruppenkunden, Fahrer/Unternehmer, Kundenanlage- und Neukundenmonat, Rechnungs-/Lieferadressen und Betreuerkontakte; normale und statische Gruppen mit ODER innerhalb einer Mitgliederart und UND zwischen belegten Arten; Serviceaufträge, Kostenlast, zugeordneter oder zahlungspflichtiger Kunde und zentrale Kundenausschlüsse. Kunden- und Adressangaben werden als heutige Stammdaten gekennzeichnet. Mehrdeutige alte Kundenzuordnungen behalten den Ursprung. Gruppen und Elternbeziehungen bleiben auf freigegebene Niederlassungen begrenzt.

Start-/zweite Stationsadresse, Start-/gespeicherte Ziel-PLZ, alle Ziel-PLZ, Branchen, Partnerprovision und kombinierte Aufteilungen sind ergänzt. Bei allen Ziel-PLZ zählt jede Zielstation mit vollem Auftragswert wie in PHP; die Auftragsanzahl bleibt je Ergebnisgruppe eindeutig. Sechs Diagrammarten und CSV stehen bereit. Archiv- und Hauptdatenbank werden über begrenzte, parametrisierte Zuordnungen verbunden. Kein Index oder Geschäftsdatenbestand wurde dafür verändert.

Referenz: erneut per SSH gelesene aktuelle Dateien auf `172.16.0.158:/data/0/votian-test/html`, insbesondere `statistic/statistic_sql.inc.php` (SHA-256 `db7c0b971795fbe062d49bcf286d6a119606859b4959f07487a4cfc7c9177d82`) und die historische PHP-Statistikoberfläche. Kein alter lokaler PHP-Stand verwendet. Ein lesender Test auf dem echten Archivserver bestätigt Auftragsdetails/Snapshot, Aktionen, Abholdauer und die Stammdatenbrücke. Schreibprüfungen liefen ausschließlich in der isolierten lokalen Datenbank.

Nachweise: `work/historical-complete-*`, `work/historical-statistics-live-read-2026-10-19.json` und die vorhandenen `work/cash-export-runs-*`-Belege. **1.615 tatsächliche Testfälle: 1.612 erfolgreich, drei gezielt übersprungen, keine Fehler.** Elf gezielte Archivprüfungen, 41 Frontendtests, Produktionsbuild, sechs Diagrammprüfungen, sieben weitere Browserprüfungen und acht Aufrufprüfungen bestanden. 1.240 Quelldateien/Frontenddateien wurden mit dem gebauten Stand abgeglichen. Anwendung neu gestartet; Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch.

Der Einnahmenexport enthält Vorschau, Sammlungsreservierung, dauerhaften Dateiinhalt, Exportkennzeichnung, Wiederaufnahme, Wiederholungsschutz und Verwerfen eigener offener Vorgänge. Das echte RETRANS-Format bleibt ohne Originaldefinition gesperrt. Benötigt werden die aktuelle Kategorie-9-Felddefinition und die Format-/Feldzuordnung des Profils 903; eine solche Definition wird nicht aus dem Profilnamen geraten.

## 2026-10-19 · Zusatzmontage und gefundene Archivquellen

Zusätzliche Montagezeit in der Auftragsbearbeitung ergänzt: Kunden-/Kurier-Stundensätze, Preisaktionen, Service- und Onlinezahlarten, Neuanlage oder Aktualisierung eines verknüpften Zusatzauftrags, Zahlung, Kalkulator und Audit. Vorschau, Berechtigungen, Zuordnungs-/Rechnungs-/Exportschutz, Revision, atomarer Rollback und Wiederholungsschutz geprüft. Der aktuelle Server besitzt weiterhin keine Definition von `copy_job_flat`; die native Anlage setzt die aus `addmontEdit` belegten Folgezustände ausdrücklich um. Geldbeträge werden centgenau gerundet; Bruchteile der Stunden bleiben im Montagefeld erhalten, während die vorhandene ganzzahlige Kalkulatormenge entsprechend gekennzeichnet ist. PHPs numerischer ddMMyyyy-Vergleich für Preisaktionszeiträume bleibt kompatibel, einschließlich seiner kalenderübergreifenden Eigenheit.

Neun gezielte Prüfungen und isolierte Browserprüfung bestanden. Gesamtlauf: **1.593 tatsächliche Testfälle, 1.590 erfolgreich, 3 gezielt übersprungen**, 1.215 Quelldateien/Frontenddateien verifiziert. Health, DB und HTTP/JAR/dist abgeglichen. Nachweise: `work/added-installation-*`. Keine echten Aufträge oder Zahlungen zu Testzwecken verändert.

**Korrektur der bisherigen Archivgrenze:** Die zusätzliche Metadatensuche über die bereits konfigurierten Zentral- und Archivverbindungen findet `jobhistory`, `tourhistory`, `tourservicehistory` und `jobcalculatorhistory`. Die frühere Suche hatte nur den aktuellen Hauptbestand belegt. `work/remaining-connections-read-2026-10-19.json` dokumentiert die erfolgreiche reine Leseprüfung; Zugangsdaten sind nicht enthalten. Kategorie 9 fehlt weiterhin. Von der konkreten 26er-Liste sind 21 Punkte abgeschlossen; vier Archivfunktionen werden mit der gefundenen Quelle umgesetzt, der Einnahmenexport bleibt in Prüfung.

## 2026-10-19 · Kasse und Inkasso einschließlich PDF-Mail

Die fünf Ansichten aus `admin/statistic_cashflow.php` sind nativ unter Abrechnung → Kasse erreichbar, auch mit Kassenrecht 26 ohne Rechnungsrecht 5. Auftragserstellungsdatum (Übersicht) und Zahlungsbuchungsdatum (Einnahmen) bleiben getrennt; Liefer-/Montagezuordnung, Counter/Monteur, Serviceaufträge, Kunden-/Niederlassungsrechte und optionale Leistungs-/Artikeldetails sind berücksichtigt. Bruttoausgaben folgen der PHP-Regel Netto × 1,19.

Gebuchte Zahlart ändern, offene Monteurzahlungen in die Kasse übernehmen sowie Montagebeträge ein- und ausbuchen besitzen Vorschau, Versionsprüfung, atomare Speicherung, Audit und Wiederholungsschutz. Bereits exportierte oder gesammelte Zahlungen, Rechnungszuordnungen und PHP-Sperren verhindern Änderungen. Montageeinbuchungen berücksichtigen den tatsächlichen Restbetrag und vermeiden die Überzahlung des alten Vollbetragsablaufs.

CSV und mehrseitige PDF sind verfügbar. Der PDF-Mailversand übernimmt die aktuellen PHP-Adress-/Textvorgaben, zeigt Empfänger und exakten Anhang und verlangt abgeschlossenen Einnahmenexport. Ein dauerhaft gespeicherter SMTP-Versuch verhindert doppelte Übergaben bei Wiederholung oder Neustart. Testversand erfolgte nur per Transport-Mock; keine realen E-Mails oder Geschäftsbuchungen.

Nachweise: `work/cashflow-mail-focused-reports`, `work/cashflow-ui-verification.json`, `work/cashflow-verification.json`, `work/cashflow-deployment.json`. Vollprüfung: **1.586 tatsächliche Testfälle, 1.583 erfolgreich, 3 gezielt übersprungen**, 1.210 unveränderte Quelldateien/Frontenddateien; 41 Frontendtests und Browserprüfung aller Ansichten, vier Schreibaktionen, Downloads und Mailablauf. JAR/HTTP/dist sowie DB-Verbindung geprüft.

Von der konkreten 26er-Restliste sind nun 20 Funktionen abgeschlossen. Offen sind Kategorie-9-Einnahmenexport, zusätzliche Montagezeit und vier historische Archivansichten/-auswertungen. Aktuelle Serverquellen enthalten keine Definition für `copy_job_flat`; die zugänglichen Datenbanken keine Kategorie-9-Exportdefinition und keine `jobhistory`-/`tourhistory`-Tabellen. Herkunft von Archivtabellen und Exportprofil wurde angefragt. Diese Grenzen sind keine Aussage über eine vollständige Inventarisierung aller PHP-Spezialfälle.

## 2026-10-19 · Zahlungskontrolle und Sammelzahlungen

Neun erfasste Restfunktionen umgesetzt: acht Kontrollberichte aus der aktuellen Serverdatei `tools/payments.php` sowie Sammelnummernsuche mit Abrechnungs-/Exportdatumsfilter und Auftragszugang. Unter Abrechnung und über Sammelnummern im Zahlungsdialog erreichbar. Niederlassungsrechte, Kostenstellenfilter, einzelne Zahlungszeilen, getrennte Lagerkosten, Montage-/Inkassohinweise, Mitarbeiterstornos aus PHP-Historie und nativer Auditwarteschlange sowie nur einmal gezählte Auftragssummen geprüft. Sammlungen mit fremden Niederlassungen geben keine Gesamtsummen preis. Die PHP-Maske wurde erneut geöffnet und liefert weiterhin HTTP 500; die Auswahlregeln sind mit dem frischen Servercode abgeglichen. Keine Geschäftsdaten verändert.

Nachweise: `work/payment-controls-*`, `work/zahlungskontrolle-2026-10-19.png`. Zwei gezielte SQL-Prüfgruppen, 41 Frontendtests, Produktionsbuild und alle acht Berichte plus Sammelnummern-/Exportdatumssuche im Browser geprüft. Vollständiger Lauf: **1585 Tests, 1582 erfolgreich, drei übersprungen**, keine Fehler; 1201 Dateien abgeglichen. Lokal bereitgestellt; Health, Datenbank und sechs Assets in HTTP/JAR/Frontend identisch. Von den konkret gezählten 26 Restfunktionen bleiben **17** offen: Kasse/Inkasso 12, Zusatzmontage 1, Archiv 4. Weiter mit den Kassenansichten und Umbuchungen.

## 2026-10-19 · Zahlungseingänge und Restbetragsbuchung

Die aktuelle PHP-Detailseite, Zahlungshelfer und Zahlartenkaskade frisch per SSH geprüft; die reale Detail-UI lesend geöffnet. Im aktuellen Bestand sind Related-Customer-Zahlungen nicht freigeschaltet und keine zugehörigen Aufträge vorhanden. Neuer nativer Zahlungsdialog zeigt Einzelzahlungen, Netto-/Bruttosummen, Restbetrag, Buchungs-/Exportzeit, Counter und Sammelnummer. Vollständige positive oder negative Restsumme serverseitig verbuchen; Kunde/erste Gruppe/globaler Zahlartenkatalog und gesonderte Service-Zahlarten werden berücksichtigt. Vorgesehene Zahlart für geeignete OS-happy-Zahlungen aus Gruppe 1/11 änderbar. Anders als die PHP-Aktualisierung über alle Auftragszahlungen wird ausschließlich die gewählte Zahlung geändert. Steuerbefreiung mit Satz 0 bleibt erhalten.

Vorschau, ausdrückliche Bestätigung, Rechte 4/7, Niederlassung, lokale Freigabe, Storno/Angebot, Rechnungs-/Exportschutz, Bearbeitungssperre, Revision, atomarer Rollback, Audit 118 und wiederholbarer Vorgang geprüft. Bestehende Nachbearbeitungsgründe werden durch eine Restbuchung nicht aufgehoben; bei Zusatzmontage bleibt die Markierung unverändert. Dispositionsstatus, Preise, Stationen und Geräteaufträge bleiben erhalten. Alle Schreibtests isoliert.

Zwei gezielte SQL-Prüfgruppen, 41 Frontendtests, Produktionsbuild, 8 Browser- und 4 Ereignisprüfungen bestanden. Gesamtlauf **1584 Tests: 1581 erfolgreich, drei übersprungen**, keine Fehler; 1198 Dateien abgeglichen. Lokal bereitgestellt und HTTP/JAR/Frontend geprüft. Nachweise: `work/order-payments-*`. Die Sammelnummer ist bislang reine Anzeige; Sammelzahlungsdetails und Zahlungs-Kontrolllisten aus `tools/payments.php` sind noch offen. Zusatzmontage und Cashflow-/Inkasso-Sonderabläufe werden separat abgeglichen. Gesamtparität ungeprüft.

## 2026-10-19 · Stationsbezogene Innendienstgründe und Freitext

Die aktuelle PHP-Detailmaske und ihre Serverfunktionen frisch abgeglichen. Neuer Dialog für mehrere Innendienstgründe je Station und die interne Bemerkung für Kundenmails. Bestehende Angaben anderer Stationen bleiben erhalten; die bisherige Nachweis- und Mailanzeige verwendet die gespeicherten Werte. Lokaler oder globaler Freigabeschalter, Rechte 4/7, Niederlassung, Bearbeitungssperre, Rechnungs-/Exportschutz, Katalogänderungen und Datenrevision werden geprüft. Vorschau, Bestätigung, wiederholbarer Vorgang und atomarer Rollback verhindern Teilbuchungen. Auditoperation 148 entspricht dem PHP-Ablauf.

Nachweise: `work/station-internal-notes-*`. Drei gezielte SQL-Prüfgruppen, 41 Frontendtests, Produktionsbuild, 8 Browser- und 3 Ereignisprüfungen bestanden. Gesamtlauf **1583 Tests: 1580 erfolgreich, drei übersprungen**, keine Fehler; 1195 Dateien abgeglichen. Lokal bereitgestellt; Health, Datenbank und sechs Assets in HTTP/JAR/Frontend identisch geprüft. Schreibtests ausschließlich isoliert. Weiter: Zahlungseingänge, Restbetragsbuchung und vorgesehene Zahlart im Auftragsdetail. Gesamtparität weiterhin ungeprüft; Archivquelle offen.

## 2026-10-19 · Tourenname und interne Bemerkung nach Export

Aktuelle `admin/jb_detail.php` und die verlinkte Konservenliste frisch per SSH sowie die PHP-Detailansicht lesend geprüft. Neuer eigenständiger Dialog für Tourenname und interne Bemerkung, auch nach Export/Rechnungszuordnung. Es ändern sich ausschließlich das gewählte Textfeld, die Version, Historie und Vorgangsquittung. Preise, Stationen, Nachweise, Rechnungen, PDA und Kundenmails werden nicht verändert. Apostrophe und Zeilenumbrüche bleiben erhalten. Vorschau, ausdrückliche Bestätigung, eigene Niederlassung, Rechte 4/7, konfigurierbare PHP-Bearbeitungssperre, Revision und vollständiger Rollback sind geprüft.

Die Namensprüfung gilt jetzt auch in der gewöhnlichen Auftragsbearbeitung und beim Umbenennen gespeicherter Touren. Bereits belegte Namen desselben Zahlers (einschließlich abweichendem Barzahler) werden abgewiesen; andere Zahler/Niederlassungen dürfen gleiche Namen verwenden. Unveränderte Bestandsnamen bleiben zulässig. Leeren entfernt nur die Vorlagenkennzeichnung. Related-Customer-Regeln für Angebote/Stornos werden berücksichtigt; Historienoperationen 15/16/200 ergänzt. Die ältere Aussage „gleiche Namen verschiedener Vorlagen bleiben zulässig“ gilt damit nur noch für unterschiedliche Zahler bzw. unveränderte Bestandsnamen.

Nachweise: `work/order-metadata-*`, `work/tourname-edit-fresh-2026-10-19.txt`. Drei gezielte SQL-Prüfgruppen, 41 Frontendtests, Produktionsbuild, 8 Browser- und 3 Aufrufprüfungen bestanden. Gesamtlauf **1582 Tests: 1579 erfolgreich, drei übersprungen**, keine Fehler; 1192 Dateien abgeglichen. Lokal bereitgestellt und HTTP/JAR/Frontend geprüft. Schreibtests ausschließlich isoliert. Nächste bestätigte Lücke: Bearbeitung der stationsbezogenen Innendienstgründe und des Freitexts für Kundenmails. Gesamtparität weiterhin ungeprüft.

## 2026-10-19 · Fahrzeuganforderung der Vorbestellung

Die aktuelle PHP-Funktion `changeCourierOrder` frisch vom Server abgeglichen und umgesetzt: Vorbestellungen (Status 8, Reservierung aktiv) können ein anderes Wunschfahrzeug der eigenen Niederlassung erhalten oder die Anforderung entfernen. Optional wird die permanente Fahrerkennung für Folgetouren geändert bzw. geleert. Der Auftrag bleibt in der Vorbestellung; Rangliste, Annahme, Stationsnachweise, Preise und PDA-Befehle werden nicht verändert. Vorschau, Bestätigung, Niederlassungsgrenze, Revision, Auditoperationen 17–20 und wiederholbare Vorgangskennung sichern die Änderung. Alte Detail-UI zusätzlich lesend geprüft; keine passende Vorbestellung im sichtbaren Bestand, Regeln daher anhand des frischen Servercodes geprüft.

Geprüft: 2 gezielte SQL-Prüfgruppen, 41 Frontendtests und Produktionsbuild, 7 Browser- und 3 Aufrufprüfungen. Gesamtlauf **1581 Tests: 1578 erfolgreich, 3 übersprungen**, keine Fehler; 1189 Dateien verifiziert. Lokal neu gestartet, HTTP/JAR/Frontend abgeglichen. Alle Schreibtests isoliert. Nachweise: `work/reservation-courier-request-*`, `work/reservation-courier-change-fresh-2026-10-19.txt`. Weiter: Tourenname/Interne Bemerkung nach Rechnungsexport und Dublettenregel. Gesamtparität ungeprüft, Archivquelle weiter offen.

## 2026-10-19 · Kontakte aus Kundenstammdaten und Vorbelegung

Frisch abgeglichen: `customer_special.php:openContacts`, `metafield_special.php:presetFields` und `inc_metafield.inc.php` mit der aktuellen PHP-Kontaktmaske. Der globale Parameter `MASK_CS2CO_PRESET` wird jetzt beim Kontaktentwurf für einen Kunden ausgewertet. Feldschlüssel werden auf die niederlassungseigenen Kategorienfelder abgebildet; `co2cs` übernimmt die interne Kunden-ID (PHP konvertiert die angezeigte ExtID ebenfalls beim Speichern). Adresse und Telefon werden vorbelegt; bestehende Kontakte können die konfigurierten Kundendaten ausdrücklich neu übernehmen. Kundenstammdaten bieten den direkten Kontaktzugang mit Kundenfilter. Fremde Niederlassungen und unzulässige Quellfelder werden nicht gelesen; bestehende Kontaktwerte werden beim bloßen Abruf nicht verändert.

Nachweise `work/contact-customer-presets-*`, aktuelle nur lesende Konfiguration `work/contact-preset-read-2026-10-19.json`. Vier gezielte Backendtests, 41 Frontendtests, Produktionsbuild, 9 Browser- und 3 Ereignisprüfungen. Gesamtlauf: 1580 Tests, 1577 erfolgreich, 3 übersprungen; 1186 Dateien abgeglichen. Lokal bereitgestellt und HTTP/JAR/Frontend geprüft.

## 2026-10-19 · Fahrzeugänderung nach Abschluss

Der aktive `bookjob`-Zweig aus `admin/jb_detail.php` (frisch per SSH) ist für erledigte, noch nicht exportierte Aufträge umgesetzt. Fahrzeugwahl über alle aktiven Niederlassungen, Zuordnung zum Fahrzeughalter/Transporteur unabhängig von heutigen Fahrer-Logins, Vorschau historischer Sonderprovision und interner Niederlassungsvergütung, Bestätigung und Audit 21. Abschluss-/Buchungszeiten und Zustellnachweise bleiben erhalten; kein PDA-Auftrag oder Rankingwechsel. Veraltete fahrzeugabhängige CO₂e-/Partnerprovisionswerte werden entfernt und die Abschluss-/Rechnungsausgabe erneut vorgemerkt. Revisionsprüfung, wiederholbare Vorgangskennung und atomare Rücknahme sichern die Korrektur.

Nachweise: `work/completed-vehicle-*`; 5 gezielte Backendtests, 41 Frontendtests, Produktionsbuild, 8 Browser- und 3 Ereignisprüfungen. Gesamtlauf 1577 Tests, davon 1574 erfolgreich und 3 übersprungen, 1182 Dateien abgeglichen; lokal bereitgestellt und HTTP/JAR/Frontend geprüft. PHP-Listen-UI gelesen; keine erledigten Zeilen im geprüften Zeitraum, Detailregeln daher am aktuellen Serverquellcode geprüft. Keine Geschäftsdaten zu Testzwecken verändert.

## 2026-10-19 · Haupt-/Unterauftragsnummer

Die Detailansicht und Bearbeitung verwenden jetzt die aktuelle PHP-Anzeige `getJobIdOutput`: Nur bei beiden globalen Schaltern `GLOBAL_USE_JB_PARENT_ID_FOR_INVOICE_NO` und `GLOBAL_USE_RELATED_CUSTOMER` werden Hauptaufträge als ID/1 und Unteraufträge als Haupt-ID/2 angezeigt. Die technische Auftrags-ID bleibt sichtbar und wird unverändert für alle Aktionen verwendet.

Geprüft: ein SQL-Integrationsprüfblock (Schalter, Haupt-/Unterauftrag, ungültiger Parent, Berechtigungen), 41 Frontendtests, Produktionsbuild, 3 Browser- und 3 Ereignisprüfungen. Gesamtlauf: 1576 Tests, 1573 erfolgreich, 3 übersprungen; 1179 Quelldateien abgeglichen. Lokal bereitgestellt und HTTP/JAR/Frontend identisch geprüft. Nachweise: `work/order-detail-number-*`. Nächste bestätigte Lücke: Fahrzeugänderung an abgeschlossenen, noch nicht exportierten Aufträgen.

## 19. Oktober 2026 – Frachtvergütungs-Warnschwelle

- Aktive `job_edit.68.20.js` und `job_options.php` frisch vom Server geprüft. `JB_CR_PRICE_THRESHOLD` ergänzt die bestehende harte Sperre: manuell eingetragene Frachtvergütung wird nach Zuschlag mit dem prozentualen Basispreis verglichen. Servicevergütung und Rabatte gehen wie im aktiven JavaScript nicht in diesen Vergleich ein. Lokaler Frachtpreismodus und globale Schwelle; keine Warnung für automatische Vergütung. Die alte Foto-Force-Verzweigung ist bei fest aktiviertem `TR_PHOTO_WORKFLOW=true` inaktiv und wurde nicht zusätzlich portiert.
- Erfassung und Neukalkulation benötigen ausdrückliche Bestätigung. Die Warnung verlangt kein Sonderrecht 39; die harte Sperre behält es. Warnung ist in Preisfingerprint und Wiederholungsbeleg enthalten, auch bei Serien. Separate Historienoperation 153 mit tatsächlicher Grenze und bestätigter Vergütung. Später Protokollfehler rollt die Anlage zurück; Wiederholung erzeugt keine weiteren Aufträge oder Warnprotokolle.
- 42 gezielte Tests, drei unabhängige Ausführungen der Original-JavaScript-Funktion, elf Browser- und fünf Aufrufprüfungen bestanden. Frontend 41 Tests und Produktionsbuild. Vollständig **1576 Tests: 1573 bestanden, drei übersprungen, keine Fehler**; 1179 Dateien verifiziert. Lokal neu gestartet, Health UP, DB verbunden und sechs Assets identisch. Sämtliche Schreibtests isoliert.
- Nachweise: `work/courier-price-threshold-verification.json`, `work/courier-price-threshold-ui-verification.json`, `work/courier-price-threshold-oracle-2026-10-19.json`, `work/courier-price-threshold-deployment.json`, `work/courier-price-threshold-current-2026-10-19.txt`. Weiter: konfigurierbare Auftragsnummer in Detailansichten und weiterer Serverabgleich. Archivquellen offen; Gesamtparität ungeprüft.

## 19. Oktober 2026 – Datumswahl beim manuellen Auftragsabschluss

- Aktuelle `admin/jb_detail.php` frisch per SSH geprüft: vollständiger Abschluss bietet aktuelles Tagesdatum oder ursprüngliches Auftragsdatum samt Uhrzeit. Die lokale Niederlassungsvorgabe `MASK_JOBDETAILS_BOOKJOB_DATE` wird ohne globalen Rückfall gelesen. Buchungszeit und neu erfasste Stationsnachweise bleiben aktuell, bestehende Nachweise unverändert. Einzelne Stationsabschlüsse behalten die bisherige Zeitlogik.
- Explizite Auswahl ist Teil der wiederholbaren Anfrage; ungültige oder für andere Aktionen mitgeschickte Auswahl wird zurückgewiesen. Alte API-Anfragen und deren gespeicherte Quittungen bleiben kompatibel. Geänderte Auftragszeit verursacht einen Revisionskonflikt. Später Fehler beim Quittungsschreiben rollt Auftrag, Stationen und PDA-Befehl zurück.
- Vier gezielte Tests einschließlich SQL-Szenarien, acht Browser- und drei Aufrufprüfungen bestanden. Frontend 41 Tests und Produktionsbuild. Vollständiger Lauf: **1570 Tests, 1567 bestanden, drei übersprungen, keine Fehler**; 1176 Dateien verifiziert. Neustart, Health UP, DB verbunden und sechs Assets bestätigt. Alte Browserliste aktuell leer; Datumscontrols daher anhand frischer PHP-Ausgabe geprüft, Schreibtests ausschließlich isoliert.
- Nachweise: `work/order-booking-date-verification.json`, `work/order-booking-date-ui-verification.json`, `work/order-booking-date-deployment.json`, `work/order-booking-date-fresh-2026-10-19.txt`. Nächste bestätigte Lücke: zusätzliche Frachtvergütungs-Warnschwelle `JB_CR_PRICE_THRESHOLD`; harte Sperre ist bereits vorhanden. Archivquellen weiter offen; Gesamtparität ungeprüft.

## 19. Oktober 2026 – Zusätzliche Kommissionsnummernpflicht beim Abschluss

- Aktuelle `admin/jb_detail.php` frisch vom Server abgeglichen: der lokale Schalter `MASK_JOBDETAILS_BOOKJOB_COMMNO` verlangt bei Kunden mit Kommissionsnummern mindestens eine ausgefüllte Station. Globale und fremde Niederlassungsvorgaben greifen nicht; im Related-Customer-Modus entfällt diese Zusatzregel. Strengere kundenspezifische B/C-Regeln bleiben erhalten. Die lesende Bestandsprüfung zeigt den Zusatzschalter derzeit überall ausgeschaltet.
- Gemeinsame Abschlussprüfung schützt auch Preiskorrektur und gewöhnliches Entfernen der Nachbearbeitung. Ältere NG-Drittlandaufträge ohne Metadatenkennzeichnung werden bei vorhandener Länderklassifikation ebenfalls als prüfpflichtig angezeigt; nächste Bearbeitung synchronisiert die Kennzeichnung. Keine Massenänderung an Bestandsdaten.
- Zehn gezielte Tests und drei lesende Browserprüfungen bestanden. Vollständiger Lauf: **1567 Tests, 1564 bestanden, drei übersprungen, keine Fehler**; 1173 Dateien verifiziert. Frontend unverändert (zuletzt 41 Tests). Lokal neu gestartet, Health UP, DB verbunden, sechs Assets identisch. Schreibprüfungen ausschließlich in isolierter Datenbank.
- Nachweise: `work/completion-reference-guard-verification.json`, `work/completion-reference-guard-ui-checks.json`, `work/completion-reference-guard-deployment.json`, `work/mail-default-and-bookjob-current-2026-10-19.txt`. Weiter: Gesamtvergleich aktueller Serverfunktionen. Archivquellen weiterhin beim Benutzer angefragt; Gesamtparität ungeprüft.

## 19. Oktober 2026 – Drittland-Kennzeichnung und Abrechnungsprüfung

- Aktuelle `jobs/job_options.php`, aktiv eingebundene `job_edit.68.20.js` und leere PHP-Erfassungsmaske geprüft. Neue Nicht-EU-Aufträge erhalten `jb_third_country=1` und bleiben zur Nachbearbeitung markiert. Klassifikation nutzt die global konfigurierten EU-Länder; ein leerer Parameter klassifiziert keine neuen Aufträge und entfernt keine vorhandene Kennzeichnung. Die tatsächliche Konfiguration wurde ausschließlich lesend geprüft und ist vorhanden.
- Bei Routenänderungen wird die Kennzeichnung mitgeführt; Rückkehr in die EU entfernt sie. Preiskorrektur und gewöhnliches Abwählen der Nachbearbeitung heben eine offene Drittlandprüfung nicht auf. Eigener Dialog bestätigt Versenderstatus und geklärte Umsatzsteuerpflicht; Revision, Rechte, Abrechnungssperren, andere Abschlussanforderungen, Wiederholung und vollständiger Rollback werden serverseitig geprüft. Protokolloperationen 151/152 bleiben getrennt von Auftragserfassung. Export kann die bestehende Drittlandspalte damit auch für neue NG-Aufträge ausgeben.
- Zwölf gezielte Tests, neun Browser- und drei Aufrufprüfungen bestanden. Frontend 41 Tests und Produktionsbuild erfolgreich. Vollständiger Lauf: **1567 Tests, 1564 bestanden, drei übersprungen, keine Fehler**; 1173 Dateien verifiziert. Lokal neu gestartet; Health UP, DB verbunden, sechs Assets identisch. Keine echten Aufträge angelegt oder geändert.
- Nachweise: `work/order-third-country-verification.json`, `work/order-third-country-ui-verification.json`, `work/order-third-country-deployment.json`, `work/order-third-country-rules-current-2026-10-19.txt`, `work/order-third-country-active-js-current-2026-10-19.txt`, `work/workflow-defaults-read-2026-10-19.json`. Weiter: zusätzlicher lokaler Kommissionsnummernschalter bei Abschluss. Gesamtparität weiter ungeprüft.

## 19. Oktober 2026 – E-Mail-Startvorgaben neuer Kunden

- Aktuelle `admin/customer_special.php` frisch per SSH und die leere PHP-Maske geprüft: lokale Niederlassungsvorgaben für Erledigungs-, Abhol- und Erfassungsmail sowie Rechnungstext und beide Kundenmail-Bemerkungen übernommen. Preisangabe startet wie PHP aktiv. Globale, fremde und mitarbeiterbezogene Vorgaben werden dafür nicht verwendet.
- Acht unterstützte Zusatzfelder sind bereits vor der Kundenanlage wählbar. Eine bewusste Abwahl bleibt erhalten. Kopien behalten die Quellwerte; Bestandsbearbeitung wendet die Startvorgaben nicht erneut an. Geänderte Vorgaben erzeugen einen Revisionskonflikt; Wiederholung nach verlorener Antwort verwendet denselben Beleg. Speichern verschickt keine Mail.
- Neun gezielte Tests, 13 Browser- und vier Aufrufprüfungen bestanden; Frontend 41 Tests und Produktionsbuild erfolgreich. Vollständiger Lauf: **1562 Tests, 1559 bestanden, drei übersprungen, keine Fehler**; 1169 Dateien verifiziert. Lokal neu gestartet; Health UP, DB verbunden, sechs Assets identisch.
- Nachweise: `work/customer-creation-mail-verification.json`, `work/customer-creation-mail-ui-verification.json`, `work/customer-creation-mail-deployment.json`, `work/customer-mail-defaults-current-2026-10-19.txt`, `work/customer-mail-defaults-php-ui-2026-10-19.txt`. Weiter: Drittland-Kennzeichnung und Abschlussprüfung nach aktuellem Servercode. Gesamtparität weiter ungeprüft.

## 19. Oktober 2026 – Gesamtsumme der erledigten Kundenaufträge

- Frischer Serverabgleich von `customer/jb_list.php` und `include/jb_list_defineoutput.inc.php`: Anzahl und Nettosumme inklusive Maut für erledigte Kundenaufträge ergänzt, sobald diese Preisspalte in der Liste sichtbar ist. Die Berechnung umfasst die gesamte gefilterte Auswahl über alle Seiten. Stationslisten bleiben ohne Auftragssumme, damit Stationen nicht mehrfach zählen.
- Ungeklärte Preise sind in der Anzahl enthalten, aber ausdrücklich aus der Betragssumme ausgeschlossen. Unterkostenstellen, Suche, Storno, negative Preise und leere Ergebnisse werden berücksichtigt. Bereits vorhandene Börsensummen bleiben erhalten.
- Drei gezielte SQL-Prüfgruppen, sieben Browser- und drei Aufrufprüfungen bestanden. Frontend: 41 Tests und Produktionsbuild erfolgreich. Vollständiger Lauf: **1559 Tests, 1556 bestanden, drei übersprungen, keine Fehler**; 1169 Dateien verifiziert. Lokal neu gestartet, Health UP, DB verbunden, sechs Assets identisch.
- Nachweise: `work/customer-list-summary-verification.json`, `work/customer-list-summary-ui-verification.json`, `work/customer-list-summary-deployment.json`, `work/customer-list-totals-current-2026-10-19.txt`. Die alte Kundenrolle bleibt in der Administrator-Sitzung nicht erreichbar; PHP-Code frisch geprüft. Weiter: E-Mail-Startvorgaben bei Kundenneuanlage; Archivquellen beim Benutzer angefragt. Gesamtparität weiter ungeprüft.

## 19. Oktober 2026 – Weitere Preisspalten der Kunden-Auftragsliste

- Aktuelle `customer/jb_list.php` frisch per SSH geprüft: konfigurierbarer Nettopreis ohne Maut, Maut und Bruttopreis inklusive Maut ergänzt. Bruttopreis verwendet GLOBAL_SALES_TAX (global, Vorgabe 19 bei leer/ungültig); Maut kommt anschließend ohne weitere Besteuerung hinzu. Bestehende Spaltenvorgaben bleiben unverändert. Ungeklärte Preise bleiben in allen Geldspalten verborgen; interne Frachtbeträge werden weiterhin nicht freigegeben.
- Drei SQL-Prüfgruppen bestanden, darunter globaler/abweichender/Null-Steuersatz, fehlende Maut, manipulierter Parameter, Netto-/Bruttosortierung, Kostenstellengrenze und unveränderte Aufträge. Der erste Versuch hatte ausschließlich eine zu strenge Textskalierungsprüfung für einen korrekten Dezimalwert; auf numerischen Vergleich korrigiert. Zehn Browser- und vier Aufrufprüfungen bestanden.
- **1559 Tests: 1556 bestanden, drei übersprungen, keine Fehler.** 1168 Dateien verifiziert. Frontend unverändert (zuletzt 41 bestandene Tests); lokaler Neustart, Health UP, DB verbunden und sechs Assets bestätigt. Der lesende Aufruf der alten Kundenliste leitet die Administrator-Sitzung zur Startseite zurück; die Kundenrolle konnte in der alten UI daher nicht geprüft werden.
- Nachweise: `work/customer-price-columns-verification.json`, `work/customer-price-columns-ui-verification.json`, `work/customer-price-columns-deployment.json`, `work/customer-columns-query-fresh-2026-10-19.txt`. Weiter: Summenzeile erledigter Kundenaufträge. Archivquellen beim Benutzer angefragt; Gesamtparität weiter ungeprüft.


## 19. Oktober 2026 – Rabattdarstellung bestehender Listenbuchungen

- Aktuelle Serverfunktion `checkDiscountStr` frisch abgeglichen und mit drei unabhängigen PHP-Ausführungen ohne Datenbank geprüft. Die gemeinsame Rechnungsaufbereitung unterstützte unterschiedliche Sätze bereits; jetzt wird auch im älteren `/invoice-items`-API-Pfad die unnötige Sperre aufgehoben. Die gemeinsame Rabattzeile wählt ihren ersten Satz wie die PHP-Abfrage statt aus den für die Oberfläche sortierten Positionen. Anzeige- und Leistungsreihenfolge bleiben erhalten.
- Zwei Hinweise erklären die bestehende PHP-Darstellung bei Servicepreis und gemischten Sätzen. Gespeicherte Preise, Gesamtsumme und Zustellinformationen bleiben erhalten. SQL-Tests prüfen auch entgegengesetzte Speicher-/Anzeigereihenfolge, Wiederholung und unveränderte Beträge; Browser prüft Vorschau, Bestätigung und verlorene Speicherantwort.
- **1559 Tests: 1556 bestanden, drei übersprungen, keine Fehler.** 44 gezielte Tests, elf Browser- und drei Aufrufprüfungen; unveränderter Frontendstand mit zuletzt 41 bestandenen Tests. 1168 Dateien verifiziert, Neustart und Health/DB/sechs Assets bestätigt.
- Nachweise: `work/batch-mixed-discount-verification.json`, `work/batch-mixed-discount-oracle-2026-10-19.json`, `work/batch-mixed-discount-ui-verification.json`, `work/batch-mixed-discount-deployment.json`. Nächster Abgleich: Kundenspalten und weitere Restlücken. Gesamtparität weiterhin ungeprüft.


## 19. Oktober 2026 – Bisherige Fahrzeugkennungen ausdrücklich abwählen

- Frische Fahrzeug-/Filterfunktionen und PHP-Oberfläche abgeglichen. Der NG-Dialog bietet nun für gespeicherte, im aktuellen Katalog nicht wählbare Filter und Leistungsbits eine ausdrückliche Entfernung. Standardmäßig bleiben sie erhalten. Damit können nicht mehr angebotene EU-/AL-Filter bereinigt werden, deren Voraussetzungen andernfalls jede Speicherung blockierten.
- Entfernen ist nur für tatsächlich gespeicherte, nicht regulär angebotene Kennungen möglich. Rechte, Katalogrevision, EU-/AL-Voraussetzungen, Historie, atomare Speicherung und identische Wiederholung bleiben wirksam. Unausgewählte Kennungen bleiben erhalten; Leistungsbits oberhalb der JavaScript-Zahlengrenze werden korrekt bewahrt bzw. entfernt. Montageanzeige berücksichtigt auch erhaltene alte Montageleistungen.
- **1557 Tests: 1554 bestanden, drei übersprungen, keine Fehler.** Vier gezielte Backendtests mit Rollback, Konflikt und hohen Leistungsbits; 41 Frontendtests, elf Browser- und vier Aufrufprüfungen bestanden. 1168 Dateien verifiziert; Neustart, Health UP, DB verbunden und sechs Assets bestätigt.
- Nachweise: `work/vehicle-capability-cleanup-verification.json`, `work/vehicle-capability-cleanup-ui-verification.json`, `work/vehicle-capability-cleanup-deployment.json`. Weiter: unterschiedliche Rabatte bei bestehenden Listenbuchungen und weitere Restlücken. Gesamtparität weiterhin ungeprüft.


## 19. Oktober 2026 – Fahrzeuglager und vererbte Stellplatzplanung

- Frische Serverfassungen von `stock.php`, `stock_move.php` und `inc_stock.inc.php` sowie die alte Lageroberfläche abgeglichen. Automatisch angelegte SYSTEM-VEHICLES-Wurzeln tragen in PHP `stk_readonly=1`, bleiben dort aber für Lagerdaten und Buchungen nutzbar. NG behandelt ausschließlich diese eindeutig gekennzeichnete sichtbare Fahrzeugwurzel entsprechend; ausdrücklich gesperrte andere Lager, gesperrte Unterlager, Mitarbeiterrechte und ausgemusterte Fahrzeuglager bleiben geschützt. Der automatisch verwendete Wurzelname bleibt fest, damit spätere Fahrzeuganlagen denselben Baum wiederfinden.
- Stellplatzplanung wird wie in PHP ausschließlich am Hauptlager für den ganzen Baum eingestellt. Unterlager zeigen den wirksamen Wert; ein abweichender Schalter kann auch über die API nicht gesetzt werden. Kapazitäten und Barcode bleiben am jeweiligen Lager bearbeitbar. Buchungen verwenden dieselbe Wurzelvorgabe; zwischenzeitliche Änderungen erzeugen einen Konflikt.
- **1557 Tests: 1554 bestanden, drei übersprungen, keine Fehler.** Acht gezielte Backendtests, ergänzt um Erzeugung des Fahrzeuglagers, Kapazitätsverwaltung, echte Buchungen in der isolierten Datenbank, Wiederholung und Zugriffssperren; 41 Frontendtests, zwölf Browser- und vier Aufrufprüfungen bestanden. 1168 Dateien verifiziert; Neustart, Health UP, DB verbunden und sechs Assets bestätigt.
- Nachweise: `work/vehicle-warehouse-verification.json`, `work/vehicle-warehouse-ui-verification.json`, `work/vehicle-warehouse-deployment.json`. Weiter: ausdrückliche Abwahl nicht mehr angebotener Fahrzeugkennzeichen und Gesamtvergleich. Gesamtparität weiterhin ungeprüft.


## 19. Oktober 2026 – Fahrzeug entfernen

- Aktuellen Serverablauf samt Lager-, FDS- und internem Kurierabbau abgeglichen. Vorschau zeigt betroffene Zuordnungen; Lagerartikel, Unterlager, belegte Dispositionsplätze, fremde aktive Fahrer und verwendete technische Kuriere sperren das Entfernen. Auch bei inzwischen abgeschalteten Optionen werden bestehende Verknüpfungen geprüft.
- Fahrzeug bleibt mit Änderungsstatus 3 für historische Bezüge erhalten; Bearbeitung und Disposition schließen es aus. Leeres Fahrzeuglager wird wie in PHP gekennzeichnet und gesperrt. Kundenzuordnungen, freie FDS, aktive SID und eindeutig gebundener technischer Kurier werden gemeinsam mit Historie und Quittung bereinigt. Unklare Antwort wiederholt denselben Vorgang; Konflikte erfordern erneute Vorschau. Verknüpfte nichttransaktionale Tabellen blockieren die Änderung.
- **1557 Tests: 1554 bestanden, drei übersprungen, keine Fehler.** Acht gezielte Backendtests plus drei Nachprüfungen für Fahrzeugzeitleisten, Entfernung und Rechte; 41 Frontendtests, zwölf Browser- und drei Aufrufprüfungen bestanden. 1167 Dateien verifiziert; lokaler Neustart, Health UP, DB verbunden und sechs Assets bestätigt. Der erste Gesamtlauf deckte eine geänderte Fehlermeldung bei fehlender Fahrzeug-ID auf; korrigiert und vollständig erneut geprüft.
- Nachweise: `work/vehicle-removal-verification.json`, `work/vehicle-removal-ui-verification.json`, `work/vehicle-removal-deployment.json`. Weiter: Fahrzeuglagerrechte und Stellplatzplanung, nicht mehr verfügbare Fahrzeugfilter, anschließend Gesamtvergleich. Gesamtparität weiterhin ungeprüft.


## 19. Oktober 2026 – Fahrzeugbilder und Fotodienst

- Aktuelle Servergalerie und Upload-/Löschmeldungen sowie die PHP-Oberfläche abgeglichen. Fahrzeugbilder werden wie in PHP über den Transporteur (`cr_vehicle`) gelesen: Galerie mit Blättern, Großansicht, Dateiname, Hinweis und Erstellungszeit. Der separate alte Fahrzeugfoto-Knopf ist im aktuellen PHP auskommentiert.
- Eingebettete Verwaltung für PNG/JPG (fünf Dateien); Dienstadresse über `VEHICLE_PHOTOS_URL`, Vorgabe wie aktuelle PHP-Version. Meldungen erfordern passende Herkunft, genaues eingebettetes Fenster und Transporteurreferenz. Serverseitige Rechte-/Niederlassungs-/Zuordnungsprüfung, exakte Dateikennung bei Entfernung, atomare Historie und wiederholbare Speicherung. Offene Abgleiche bleiben im Browser-Tab erhalten. Die echte PHP-Einbettung lieferte beim Abgleich 404; Browserabläufe daher zusätzlich mit isoliertem Fotodienst geprüft.
- Fahrerwechsel erhält die technische Kurier-SID und führt deren Unternehmerzuordnung mit. **1556 Tests: 1553 bestanden, drei übersprungen, keine Fehler.** Sieben gezielte Backendtests, 41 Frontendtests, zwölf Browser- und vier Aufrufprüfungen bestanden. 1164 Dateien verifiziert. Anschließend ausschließlich den Schließen-Bestätigungsdialog sprachlich korrigiert, erneut Frontendtests/Build; alle 911 Backenddateien gegenüber dem vollständigen Lauf identisch. Paket neu erstellt, Health UP, DB verbunden und sechs Assets bestätigt.
- Nachweise: `work/vehicle-gallery-verification.json`, `work/vehicle-gallery-label-build-sources.json`, `work/vehicle-gallery-ui-verification.json`, `work/vehicle-gallery-deployment.json`. Nächster Punkt: Fahrzeugentfernung und Ausblenden entfernter Fahrzeuge. Gesamtparität weiterhin ungeprüft.


## 19. Oktober 2026 – Interner Fahrzeugkurier

- Aktuelle Serverfunktionen für Anlage/Umbenennung des optionalen Fahrzeugkuriers abgeglichen. Globale Vorgabe aktiviert die atomare Pflege samt Firma, Benutzer, Abrechnungsfahrzeugtyp und Unternehmerzuordnung. Eindeutige bestehende technische PHP-Datensätze werden übernommen; ID-Bindung verhindert Änderungen an einem beliebigen Fahrer mit gleicher SID. Das gemeinsame PHP-Passwort wird nicht übernommen; neue technische Konten bleiben ohne Portal-/App-Zugang.
- Neue/umbenannte SID mit dieser Option höchstens sechs Zeichen (INT_ plus SID). Mehrdeutige Zuordnungen, belegte Kennungen und unpassende Konten brechen vollständig ab; Wiederholungen erzeugen keine Doppelanlage.
- **1553 Tests: 1550 bestanden, drei übersprungen, keine Fehler.** Sechs gezielte Backendtests, 41 Frontendtests, fünf Browser- und drei Aufrufprüfungen bestanden. 1160 Dateien verifiziert; Neustart, Health UP, DB verbunden und sechs Assets bestätigt.
- Nachweise: `work/vehicle-associated-courier-verification.json`, `work/vehicle-associated-courier-ui-verification.json`, `work/vehicle-associated-courier-deployment.json`. Weiter: Zusammenspiel mit Fahrerwechsel, Bildergalerie/Upload-Dienst und Fahrzeuglöschung; Gesamtparität weiterhin ungeprüft.


## 19. Oktober 2026 – Bedingtes Abrechnungsfahrzeug und Fahrzeuglager

- Aktuelle PHP-Schalter und `objectInsertStock` frisch vom Server abgeglichen. Bei GLOBAL_VEHICLE_COURIER_RELATION=1 erscheint die Abrechnungsfahrzeug-Auswahl mit Fahrzeugen der Arbeitsniederlassung; neue fremde Verweise werden abgelehnt. Bei ausgeschaltetem Schalter bleiben vorhandene Werte erhalten und sind nicht überschreibbar. Kopien in andere Niederlassungen starten ohne übernommenen Abrechnungsverweis.
- Bei GLOBAL_VEHICLE_STOCK_RELATION=1 wird ein fehlender Fahrzeuglagerort als FZG+SID unter dem konfigurierten Hauptlager oder unter SYSTEM-VEHICLES angelegt. Lokale Hauptlagervorgabe geht vor globaler. Hauptlager erhalten PHP-Vorgabefelder und gegebenenfalls die Erweiterung einer bestehenden Mitarbeiter-Hauptlagerfreigabe. Vorhandene Lager, Namen, Barcodes und Bestände bleiben auch bei SID-Änderung erhalten.
- Anlage und Audit bleiben Teil derselben Fahrzeugtransaktion; ungültige, fremde oder mehrdeutige Lagerzuordnungen, ungültige Pfade und nichttransaktionale Lagertabellen verhindern die gesamte Änderung. Rein lesend bestätigt: Die Schalter sind im angebundenen System nicht gesetzt. Testaktivierung erfolgte ausschließlich in der isolierten Datenbank. Der Aktivierungshinweis ist jetzt deutlicher dargestellt, die Zusammenfassung im Kopierdialog untereinander lesbar.
- **1550 Tests: 1547 bestanden, drei übersprungen, keine Fehler.** Sieben gezielte Backendtests, 41 Frontendtests, sieben Browser- und drei Aufrufprüfungen bestanden. 1157 Dateien verifiziert; Neustart, Health UP, Datenbankverbindung und sechs identische Assets bestätigt. Nachweise: `work/vehicle-billing-stock-verification.json`, `work/vehicle-billing-stock-ui-verification.json`, `work/vehicle-billing-stock-deployment.json`.
- Weiter: interne Fahrzeugkuriere, Fahrzeugbilder und Löschablauf; danach verbleibender Gesamtvergleich. Der optionale Fahrzeugkurier-Schalter erhält bislang die Abrechnungsreferenz; seine interne Kontoanlage ist noch offen. Gesamtparität bleibt ungeprüft.

## 19. Oktober 2026 – Aktives Fahrzeug bei Stammdatenänderungen

- Aktuelle PHP-Folgewirkung ergänzt: Bearbeiten eines bestehenden Fahrzeugs und Speichern seiner Filter/Leistungen übernimmt SID und Fahrzeugtyp in die aktive Zuordnung des Eigentümer-Transporteurs. Neue Fahrzeuge und Kopien aktivieren sich weiterhin nicht. Ein Hinweis in beiden Dialogen kündigt den Wechsel an und zeigt die bisherige SID.
- Die Bearbeitungsrevision enthält nun die relevante aktive Zuordnung; ein zwischenzeitlicher Wechsel führt zum Konflikt. Unabhängige Verbindungs-/GPS-Updates blockieren die Bearbeitung nicht. Fahrzeug, Fahrerzuordnung und Audit werden atomar gespeichert. Die Wiederholung eines abgeschlossenen Vorgangs aktiviert kein inzwischen abgewähltes Fahrzeug erneut.
- Eine Gewichtserhöhung kann die AL/TG-Regel nicht mehr über die Stammmaske umgehen. **1549 Tests: 1546 bestanden, drei übersprungen, keine Fehler.** Acht gezielte Backendtests, 41 Frontendtests sowie fünf Browser- und zwei Aufrufprüfungen bestanden. 1155 Dateien verifiziert; Neustart, Health UP, DB verbunden und sechs identische Assets bestätigt.
- Nachweise: `work/vehicle-active-assignment-verification.json`, `work/vehicle-active-assignment-ui-verification.json`, `work/vehicle-active-assignment-deployment.json`. Frische reine Leseprüfung der Hauptdatenbank: Lager-/Fahrzeugtabellen sind InnoDB; die optionalen Schalter GLOBAL_VEHICLE_COURIER_RELATION / GLOBAL_VEHICLE_STOCK_RELATION und VEHICLE_STOCK_PARENT_ID sind nicht gesetzt (`work/vehicle-storage-read-2026-10-19.json`, null Schreibzugriffe). Weiter mit den bedingten Lager-/Abrechnungsbezügen und übrigen Fahrzeugfunktionen; Gesamtparität bleibt ungeprüft.

## 19. Oktober 2026 – Fahrzeugkopie

- Aktuellen PHP-Kopierpfad und sichtbare Felder (Ziel-ExtID, neue SID, neue Kommissionsnummer) abgeglichen. NG bereitet eine prüfbare Kopie für einen eindeutigen Zieltransporteur vor; freigegebene Zielniederlassungen werden angeboten. Angezeigte Stammdaten sind anpassbar, Kennzeichen und Zulassungsmonat übernommen, beide Nummern neu und beim Kopieren systemweit eindeutig.
- Wählbare Fahrzeugfilter/Leistungen können übernommen werden; Montagebit wird neu abgeleitet, EU-/AL-Voraussetzungen und der gewählte Fahrzeugtyp geprüft. Historische nicht mehr auswählbare Kennzeichen, Dokumente, Fotos, Kundenzuordnungen und bestehende Belegungen werden nicht kopiert. Rechte begrenzen Felder und Werte; Quelle, Katalog und Zieltransporteur werden vor dem Anlegen erneut geprüft.
- Anlage, Historie, neue FDS bei Aktivierung, Audit und Quittung laufen im bestehenden Stammdatenvorgang. Verlorene Antworten wiederholen denselben Auftrag ohne Doppelanlage. Quelle und aktive Fahrerzuordnung bleiben beim Kopieren unverändert.
- **1546 Tests: 1543 bestanden, drei übersprungen, keine Fehler.** Vier gezielte SQL-Tests, 41 Frontendtests, 20 Browserprüfungen und fünf Aufrufprüfungen bestanden. 1151 Dateien verifiziert; lokaler Neustart, Health UP, DB verbunden und sechs identische Assets bestätigt. Nachweise: `work/vehicle-copy-verification.json`, `work/vehicle-copy-ui-verification.json`, `work/vehicle-copy-deployment.json`.
- Weiter: Folgewirkungen beim Bearbeiten auf aktive Fahrerzuordnung, fahrzeugbezogenes Lager und interne Fahrzeugkuriere, Abrechnungsfahrzeug sowie Fahrzeugbilder/Löschen. Gesamtparität bleibt ungeprüft.

## 19. Oktober 2026 – Fahrzeug-Pflichtangaben und eindeutige Nummern

- Frische Serverfassung von `courier_vehicle.php` abgeglichen: Kennzeichen, Kommissionsnummer und Zulassungsmonat sind nun bei Anlage und Änderung Pflicht. SID und Kommissionsnummer werden über alle Transporteure derselben Niederlassung geprüft; derselbe Datensatz ist bei Änderungen ausgenommen. Identische Nummern in anderen Niederlassungen bleiben wie im PHP-Speicherpfad zulässig.
- Erstzulassung wird als Monat/Jahr bearbeitet und auf den Monatsersten normalisiert. Ältere NG-Aufrufe mit gültigem vollständigem Datum bleiben kompatibel. Ungültige Datumswerte und leere Pflichtangaben werden abgelehnt; fehlgeschlagene Nummernprüfungen ändern keine Fahrzeugdaten.
- **1545 Tests: 1542 bestanden, drei übersprungen, keine Fehler.** Acht gezielte Backendtests; acht Browser- und drei Aufrufprüfungen. Frontend unverändert zum Stand mit 41 bestandenen Tests. 1148 Dateien verifiziert; Neustart, Health UP, Datenbankverbindung und sechs Assets bestätigt.
- Nachweise: `work/vehicle-identity-rules-verification.json`, `work/vehicle-identity-rules-ui-verification.json`, `work/vehicle-identity-rules-deployment.json`. Weiter mit Fahrzeugkopie sowie übrigen Fahrzeugfolgewirkungen und Bildern; Gesamtparität bleibt ungeprüft.

## 19. Oktober 2026 – Dispositionskapazitäten bei Fahrzeugpflege

- Aktuelle Serverfunktionen `generateVehicleFastDispositionStructure` (Modi 3/4) und `generatePersistentTimeslots` abgeglichen. Neue Fahrzeuge erhalten bei global aktivierter FDS 14 Tage mit dem konfigurierten Stundenraster und Anfangskapazitäten. Ohne Aktivierung werden keine Dispositionsdaten angelegt. Bestehende Kundenzuordnungen aktivieren wie in PHP die Kapazitätsnachführung auch ohne Globalschalter.
- Änderungen an Zuladung/Stellplätzen verändern bestehende Restkapazitäten um die Differenz, begrenzt auf null. Belegungen, Zeitscheiben, Tages-Sperren und Bemerkungen bleiben erhalten. Der aktuelle PHP-Zeitraum (14 Tage bzw. Tagesdifferenz zum letzten Bestand ab 30 Tagen, exklusives Ende) wird übernommen. Änderungen, Historie und Audit sind atomar und wiederholbar; ungültige Raster oder doppelte Kapazitätstage brechen ab.
- **1542 Tests: 1539 bestanden, drei übersprungen, keine Fehler.** Sechs gezielte Backendtests erfolgreich. Die gemeinsame SQL-Fixture setzt nun auch FDS-Tabellen zurück, damit frühere Testfälle keine fremden Zuordnungen zurücklassen. Frontend unverändert zum zuletzt geprüften Stand (41 Tests). 1145 Dateien verifiziert; Neustart, Health UP, DB verbunden und sechs identische Assets bestätigt.
- Nachweise: `work/vehicle-master-disposition-verification.json`, `work/vehicle-master-disposition-targeted-reports/`, `work/vehicle-master-disposition-deployment.json`. Weiter: Pflichtangaben/Nummernprüfung, Fahrzeugkopie, aktive Fahrer-/Lagerfolgewirkungen und Bilder. Gesamtparität bleibt ungeprüft.

## 19. Oktober 2026 – Fahrzeug einem Fahrerkollegen zuordnen

- Frische PHP-Aktion `associateVehicleToNewCourierOfTheSameContractor` und sichtbare Auswahl abgeglichen. Neuer Dialog bietet Fahrer desselben Unternehmers innerhalb der Arbeitsniederlassung an und zeigt die Rücksetzung aktiver SID-Zuordnungen vorab. Nach erfolgreichem Wechsel schließen der Zuordnungs- und bisherige Fahrzeugeditor; die Fahrzeugliste des bisherigen Fahrers wird neu geladen.
- Speicherung prüft aktuelle Rechte, Unternehmer, Kollegen, Fahrzeugnummer und aktive Zuordnungen erneut. Fremde Niederlassungen, doppelte SID und verwaiste Unternehmer werden gesperrt. Fahrzeugwechsel, Rücksetzen und Audit 186 erfolgen atomar; derselbe Vorgang bleibt nach verlorener Antwort wiederholbar. Konflikte behalten die Auswahl.
- **1539 Tests: 1536 bestanden, drei übersprungen, keine Fehler.** Ein gezielter SQL-Integrationstest, 41 Frontendtests sowie 18 Browser- und drei Aufrufprüfungen bestanden. 1142 Dateien verifiziert; Neustart, Health UP, DB verbunden und sechs identische Assets bestätigt. Nachweise: `work/vehicle-driver-assignment-verification.json`, `work/vehicle-driver-assignment-ui-verification.json`, `work/vehicle-driver-assignment-deployment.json`.
- Weiterarbeit an den Folgewirkungen der Fahrzeugpflege auf Dispositionskapazitäten; danach Fahrzeugkopie und weitere aktiv sichtbare Fahrzeugfunktionen. Gesamtparität bleibt ungeprüft.

## 19. Oktober 2026 – Fahrzeugfilter und Leistungen

- Aktuelle `courier_vehicle.php`, `inc_filters.inc.php`, Bitumrechnung und sichtbare PHP-Filterauswahl abgeglichen. Fahrzeugfilter aller Statusarten werden passend zum Fahrzeugtyp angeboten; Fahrerfilter, mehrdeutige Kürzel und objektfremde Leistungen sind ausgeschlossen. Montagekennzeichen wird aus den global konfigurierten Montageleistungen abgeleitet. Hohe Leistungsbits bleiben ohne JavaScript-Zahlenverlust erhalten.
- Eigener Dialog im Fahrzeugstamm mit aktuellen Rechten/Niederlassungsprüfung, Katalog-/Bestandsrevision, atomarem Audit und wiederholbarer Speicherung. EU benötigt die Transporteur-USt-ID, AL ab 2500 kg TG. NG fordert die Korrektur ausdrücklich an; PHP entfernt diese Filter per JavaScript stillschweigend mit Hinweis. Nicht mehr wählbare historische Filter/Leistungsbits bleiben erhalten.
- **1538 Tests: 1535 bestanden, drei übersprungen, keine Fehler.** Vier gezielte Backendtests, 41 Frontendtests, 21 Browser- und drei Aufrufprüfungen bestanden. 1139 Dateien verifiziert; lokaler Neustart, Health UP, DB verbunden und sechs identische Assets bestätigt. Initiale TypeScript-/Testgenerikfehler behoben und anschließend neu gebaut/geprüft.
- Nachweise: `work/vehicle-capabilities-verification.json`, `work/vehicle-capabilities-ui-verification.json`, `work/vehicle-capabilities-deployment.json`. Nächster Punkt: Fahrzeug an Fahrerkollegen desselben Unternehmers zuordnen. Gesamtparität bleibt ungeprüft.

## 19. Oktober 2026 – Erweiterte Fahrzeugstammdaten

- Frische Serverfassung und sichtbare `courier_vehicle.php` abgeglichen. Antriebsart, Umweltstufe, Übernahmemonat, Türhöhen, Finanzierung, Fahrzeug-/Fahrer-CI und Eigenfahrzeug ergänzt. Endgerätenutzung, Partnerprovision, Werbevergütung, Versicherungsbeträge/-daten und Systemgebühr folgen den jeweiligen PHP-Rechten 10/13/40/41; verborgene Finanzwerte werden auch nicht an den Browser geliefert.
- CI wird in den beiden Vierbit-Feldern gespeichert. Aktuelle Kataloge, ausgeschlossene Fahrzeugtypen und Provisionsgrenzen werden beim Speichern geprüft; unveränderte historische Katalogwerte bleiben erhalten. Betragsänderungen und Preishistorie werden gemeinsam gespeichert oder zurückgerollt, Wiederholungen erzeugen keine doppelten Historieneinträge.
- **1534 Tests: 1531 bestanden, drei übersprungen, keine Fehler.** Fünf gezielte Backendtests, 41 Frontendtests, zwölf Browser- und drei Aufrufprüfungen erfolgreich. Monats-/Datumsfelder über native Tastatur geprüft, da `fill()` des Browserwerkzeugs deren React-Änderung nicht auslöste. 1135 Dateien verifiziert; lokaler Neustart, Health UP, DB verbunden und sechs identische Assets bestätigt.
- Nachweise: `work/vehicle-master-settings-verification.json`, `work/vehicle-master-settings-ui-verification.json`, `work/vehicle-master-settings-deployment.json`. Weiterer Abgleich: Fahrzeugfilter/-leistungen, Kopieren und Fahrerzuordnung sowie Folgewirkungen der Fahrzeugpflege. Gesamtparität bleibt ungeprüft.

## 19. Oktober 2026 – Niederlassungsvorgaben der Kuriermaske

- Aktuelle `courier_special.php` und alte UI abgeglichen. `MASK_HIDE_CR_VHT_INV`, `MASK_HIDE_CR_OUTLAY` und `MASK_HIDE_CR_DISPOSITION` wirken nun auch in NG, mit lokaler Vorgabe vor globalem Rückfall. Ein ausdrückliches 0 hebt die globale Ausblendung auf. Sind beide Dispositionsfelder ausgeblendet, entfällt wie in PHP auch der gemeinsame Schalter zur bundesweiten Vermittlung.
- `MASK_EXCLUDE_VHT_IDS` begrenzt die Fahrzeugtypen der Abrechnungsauswahl nur anhand der aktuellen Niederlassung. Bestehende ausgeschlossene Typen bleiben erkennbar und unverändert speicherbar, können aber nicht neu gewählt werden. Ausgeblendete Werte bleiben bei anderen Änderungen erhalten. Die Speicherung prüft die aktuell geltenden Regeln erneut.
- **1530 Tests: 1527 bestanden, drei übersprungen, keine Fehler.** 13 gezielte Backendtests, elf Browser- und drei Aufrufprüfungen erfolgreich. Frontend unverändert gegenüber den zuletzt bestandenen 41 Tests. 1132 Dateien verifiziert, lokaler Neustart/Health/DB und sechs identische Assets bestätigt. Nachweise: `work/courier-mask-rules-verification.json`, `work/courier-mask-rules-ui-verification.json`, `work/courier-mask-rules-deployment.json`.
- In der Testfixture zunächst unpassenden Antwortzustand berichtigt; ein exakter Labelselektor wurde auf den tatsächlichen Auswahlnamen angepasst. Produktprüfungen danach erfolgreich. Fortsetzung mit aktiven Feldern der Fahrzeugpflege; Gesamtparität weiter ungeprüft.

## 19. Oktober 2026 – Online-Status in den Kurierstammdaten

- Aktuelle Serverfassung von `courier_special.php` und sichtbare PHP-Neuanlage abgeglichen. NG zeigt nun „Derzeit online“ im Kurierstamm und Fahrerprofil mit dem aktuellen Fahrzeugtyp (`vht_id`, nicht Abrechnungsfahrzeugtyp). Genau `cr_available=1` gilt wie in PHP als online; eine angeforderte Abmeldung setzt die Anzeige nicht vorzeitig auf offline.
- Separat aktualisierbare, rein lesende Anzeige mit aktuellen Rechten/Niederlassungsprüfung. Fehler entfernen den alten Status, Wiederholung erhält Eingaben. Fehlende/mehrdeutige Fahrzeugtypen sind ausdrücklich gekennzeichnet. Die Profilrevision bleibt von Statuswechseln unabhängig.
- **1526 Tests: 1523 bestanden, drei übersprungen, keine Fehler.** Erweiterter SQL-Integrationstest prüft Statusfälle, Rechteentzug, fremde Niederlassung, ausstehende Abmeldung und fehlende/mehrdeutige Fahrzeugtypen. 41 Frontendtests sowie neun Browser- und drei Aufrufprüfungen bestanden. Eine unvollständige Verzeichnisantwort der Browserfixture wurde vor der Prüfung korrigiert.
- 1130 Dateien verifiziert; lokaler Neustart, Health UP, Datenbank verbunden, sechs identische Assets. Nachweise: `work/courier-availability-verification.json`, `work/courier-availability-ui-verification.json`, `work/courier-availability-deployment.json`. Nächster Punkt: Ausblendungs- und Fahrzeugtypvorgaben der Kuriermaske. Gesamtparität ungeprüft.

## 19. Oktober 2026 – Abweichende Rechnungsanschrift der Hauptkostenstelle

- Frisch vom Server gelesene `customer_special.php` mit NG abgeglichen: Abweichende Firmenzeilen und Rechnungsanschrift werden jetzt direkt im Kundenstamm angezeigt. Vergleich aller vier Firmenzeilen sowie der Adress-ID/Hausnummer entsprechend PHP. Direkter Zugang zur Bearbeitung der eigenen Hauptkostenstelle; ungespeicherte Kundeneingaben sperren den Wechsel.
- Fehlende/mehrdeutige Rechnungsadressen sind sichtbar erklärt. Fremde oder nicht zugehörige Hauptkostenstellen geben keine Firmendaten preis. Jeder Abruf prüft aktuelle Rechte und Arbeitsniederlassung; die Übersicht verändert keine Geschäftsdaten.
- **1526 Tests: 1523 bestanden, drei übersprungen, keine Fehler.** Neun gezielte Backendtests, 41 Frontendtests, elf Browserprüfungen und drei Aufrufprüfungen bestanden. 1128 Dateien verifiziert. Lokaler Neustart, Health UP, Datenbank verbunden und sechs identische Assets bestätigt. Nachweise: `work/customer-invoice-address-verification.json`, `work/customer-invoice-address-ui-verification.json`, `work/customer-invoice-address-deployment.json`.
- Fortsetzung: Kuriermaske frisch mit der Serverfassung abgleichen. Vollständige Gesamtparität bleibt ungeprüft.

## 19. Oktober 2026 – IBAN-Berechnung und Bankdatenprüfung

- Aktuelle sichtbare Kundenmaske und ihre Serverdateien `include/iban.js` / `include/swift.js` abgeglichen. Lokale IBAN-Berechnung aus Land, Bankleitzahl und Kontonummer mit führenden Nullen, Vorschau, ausdrücklicher Übernahme und Verwerfen. Geänderte Ausgangswerte machen den Vorschlag unbrauchbar. IBAN-Format/Prüfsumme und BIC-Format werden beim Verlassen der Felder oder per Knopf geprüft.
- Fehlerhafte Eingaben bleiben zur Korrektur stehen. Der Kundeneditor verhindert das Speichern neu eingegebener ungültiger Bankfelder; unveränderte historische Werte blockieren keine sachfremde Änderung. Leere optionale Angaben bleiben möglich. Dies sind Bedienhilfen/Browserprüfungen gemäß PHP; keine Bankabfrage und keine zusätzliche serverseitige Bankregel. Die bestehende API-Rechte-/Revisionsprüfung bleibt unverändert.
- **41 Frontendtests bestanden**, darunter 52 Vergleichsfälle gegen das isoliert ausgeführte aktuelle PHP-JavaScript für alle 48 enthaltenen Länderformate. 17 Browserprüfungen und vier Aufrufprüfungen bestanden; Speicherung nach verlorener Antwort wiederholbar. Visuell gefundenen horizontalen Überlauf korrigiert und erneut geprüft. Die Testfixture lieferte zuerst eine Kopier-ID; korrigierte Wiederholung bestätigt den ursprünglichen Kundendatensatz.
- Backendquellen und Tests sind hashgleich zum erfolgreichen Gesamtlauf mit **1521 Tests / 1518 bestanden / drei übersprungen**. Frontend neu gebaut und mit unverändertem Backend paketiert; 1125 Dateien verifiziert. Nachweise: `work/customer-bank-tools-verification.json`, `work/customer-bank-tools-ui-verification.json`, `work/customer-bank-tools-deployment.json`. Lokaler Neustart, Health UP, Datenbank verbunden und sechs identische Assets bestätigt. Gesamtparität bleibt offen.

## 19. Oktober 2026 – Kundenspezifische Stationsnummern

- Aktive Checkbox in der alten Kundenmaske und aktuelle Serverfassung von `customer_special.php` / `jb_detail_history.inc.php` abgeglichen. Pflege unter Kundenerfassung, Übernahme bei Kundenkopien, Anzeige in internen Auftragsdetails/Abliefernachweisen sowie Kundenportal und Auftragsbeleg. Kundenspezifische Niederlassungs- und globale Vorgaben haben Vorrang vor allgemeinen Werten; ausdrückliches 0 überschreibt 1. Rechnungskunden anderer Niederlassungen werden korrekt aufgelöst.
- Rechte werden bei jedem Abruf neu geprüft. Anzeigefehler erscheinen sichtbar. Firmenbezeichnungen, Nachweise und Geschäftsdaten bleiben erhalten; der Schalter steuert die Stationsüberschriften/-spalte, nicht fachliche Stationsbezüge in Artikel- oder Bearbeitungsaktionen. Geänderte Anzeigevorgaben machen eine alte PDF-Revision ungültig.
- **1521 Tests: 1518 bestanden, drei übersprungen, keine Fehler.** Neun gezielte Backendtests; erster Durchlauf scheiterte an einem fehlenden Pflichtdatum im neuen Testkunden, korrigierte Wiederholung bestanden. 35 Frontendtests, 14 Browser- und vier Aufrufprüfungen erfolgreich. 1120 Dateien verifiziert, lokal neu gestartet und sechs Assets identisch. Nachweise: `work/customer-station-numbers-verification.json`, `work/customer-station-numbers-ui-verification.json`, `work/customer-station-numbers-deployment.json`.
- Nächster bestätigter Punkt: IBAN-Erzeugung und IBAN/BIC-Prüfung in der Kundenpflege. Vollständige Gesamtparität bleibt ungeprüft.

## 19. Oktober 2026 – Kundenstammblatt als PDF

- Aktive PHP-PDF-Aktion und `generatePDFCustomer` frisch vom Server sowie der sichtbare PDF-Knopf der alten UI abgeglichen. Native Vorschau und Download mit Kunden-, Kontakt-, Bank-, Steuer-, Status-, Konditions- und Vermittlungsangaben, abweichender Rechnungsanschrift/-firma, Drittzahler, Metakunde und beiden Bemerkungsfeldern. IBAN und BIC ergänzt. Lange Texte laufen auf Folgeseiten; Zugangskonto ist enthalten, Passwort- und Zwei-Faktor-Geheimnisse nicht.
- Jeder Abruf prüft aktuelle Rechte und Kundenniederlassung. Vorschau, Folgeseiten und Download sind an die Revision der ausgegebenen Daten gebunden, einschließlich Rechnungsanschrift und Zugangskontoname. Fremde/unzugängliche Kundenreferenzen werden nicht als Datensatz offengelegt. Öffnen und Herunterladen verändern keine Geschäftsdaten. Ungespeicherte Stammdaten sperren die PDF-Aktion.
- **1521 Tests: 1518 bestanden, drei übersprungen, keine Fehler.** Vier gezielte Backendtests mit SQL-, Inhalts-, Seitenumbruch- und Geheimnisausschlussprüfung; 35 Frontendtests, acht Browserprüfungen und vier Browseraufrufprüfungen bestanden. Beide Test-PDF-Seiten per Poppler gerendert und visuell geprüft. Ein Browserselektor erfasste zunächst auch das Schließen-Symbol; korrigierte Wiederholung bestätigt, dass bei Downloadkonflikt die alte Vorschau entfernt wird.
- 1119 Dateien verifiziert, lokaler Neustart und sechs identische dist/JAR/HTTP-Assets bestätigt. Nachweise: `work/customer-stammblatt-verification.json`, `work/customer-stammblatt-ui-verification.json`, `work/customer-stammblatt-deployment.json`. Nächster bestätigter Punkt: Pflege und Detailanzeige der kundenspezifischen Stationsnummernvorgabe. Gesamtparität bleibt offen.

## 19. Oktober 2026 – Foto-Workflow-Pflege und vollständige Fotoübernahme bei Kundenkopien

- Aktuelle PHP-Setpflege und Kopierübertragung frisch per SSH sowie die alte Neuanlage lesend im Browser abgeglichen. Eigener Dialog mit allen Freigaben, Standard-Workflow je Set und Standardset; tatsächliche Setnummern bleiben erhalten. Änderungsvorschau, Verwerfenschutz und aktuelle Kunden-/Niederlassungsrechte geprüft. Historische, nicht freigegebene Standards bleiben zur Korrektur lesbar.
- Übertragung außerhalb der Datenbanktransaktion mit dauerhaftem Vorgang: Nach unklarer Antwort wird nur der Dienststand abgefragt, nicht blind erneut gesendet. Wiederholungen, konkurrierende Aufrufe, Rechteentzug, Bestandsänderungen und Fehler nach erfolgreichem Versand geprüft. Kundenkopien übernehmen den geprüften Fotostand; ihre Anlage und Übertragungsplanung sind atomar. Geänderte Vorlage oder Neuanlagevorgaben werden erkannt. Offene Übertragungen erscheinen im Kundenstamm.
- **1517 Tests: 1514 bestanden, drei übersprungen, keine Fehler.** Neun gezielte Backendtests, 35 Frontendtests, zehn Browserprüfungen und vier Prüfungen der Browseraufrufe bestanden. 1115 Dateien verifiziert. Nachweise: `work/customer-photo-copy-verification.json`, `work/customer-photo-settings-ui-verification.json`, `work/customer-photo-copy-deployment.json`. Lokal gestartet, Health UP, Datenbank verbunden, sechs Assets identisch. Keine realen Geschäftsdaten oder echten Fotodienst-Einstellungen geschrieben.
- Die zuvor offene Fotoübernahme bei Kundenkopien ist damit erledigt. Nächster bestätigter Punkt: spezielle Stammblatt-PDF-Ausgabe. Vollständige Gesamtparität bleibt ungeprüft; Classic-Sammelübergabe bleibt auf Nutzerwunsch ausgeschlossen.

## 19. Oktober 2026 – Kundenstammblatt als neuen Kunden kopieren

- Aktuelle PHP-Kopieraktion und Neuanlage frisch vom Server geprüft; die alte Neuanlage zusätzlich lesend im Browser angesehen. „Als neuen Kunden kopieren“ erzeugt zunächst nur einen bearbeitbaren Entwurf. Neue Kundennummer erforderlich; Portalzugang, Identitäten, Vorgängerhistorie, Filter, Services, zusätzliche Kostenstellen und Dokumente werden nicht dupliziert. Lokale `CS_COPY_NO_THIRD_PARTY`-Vorgabe entfernt den anfänglichen Drittzahler; die spätere bewusste Auswahl bleibt möglich.
- Hauptfelder, Kundenerfassungs- und Mailparameter werden beim ausdrücklichen Speichern gemeinsam angelegt. Kopierquelle, Konfiguration und aktuelle Rechte werden erneut geprüft. Rollback, gleichzeitig wiederholte Anlage, verlorene Antwort, getrennte Benutzer-/Kostenstellen-IDs und unveränderte Quellstammdaten getestet. Ohne Zusatzrechte werden Vertriebszuordnung und DSGVO-Zustimmung nicht neu übertragen.
- **1509 Tests: 1506 bestanden, drei übersprungen, keine Fehler.** Neun gezielte Backendtests mit umfangreichem SQL-Kopierablauf, 35 Frontendtests, neun Browserprüfungen und vier Prüfungen der Browseraufrufe bestanden. 1111 Quelldateien verifiziert. Nachweise: `work/customer-copy-verification.json`, `work/customer-copy-ui-verification.json`, `work/customer-copy-deployment.json`. Health UP, Datenbank verbunden, sechs Assets identisch. Ausschließlich isolierte Schreibprüfungen.
- **Verbleibende Teilfunktion der Kopie:** Foto-Workflow-Zuordnungen des externen Fotodiensts werden noch nicht übertragen; der Entwurf nennt diese Einschränkung ausdrücklich. Als nächstes folgen deren Kundenpflege und die Einbindung in die Kopie. Die spezielle Stammblatt-PDF-Ausgabe bleibt ebenfalls offen. Keine vollständige PHP-Parität behauptet.

## 19. Oktober 2026 – Niederlassungsübergreifender Drittzahler in der internen Erfassung

- Aktuelle PHP-Zahlerauswahl frisch vom Server und die alte Erfassungsmaske lesend abgeglichen. Ein im eigenen Kundenstamm hinterlegter, aktiver Drittzahler derselben Mandantenorganisation kann jetzt aus einer anderen Niederlassung übernommen werden. Die Erfassungsniederlassung bleibt erhalten; Preisvorgaben, Artikel, Fahrzeuge und Stationsauswahl behalten ihren jeweiligen Geltungsbereich. Die Kundenerfassung bleibt auf ihre eigenen freigegebenen Kostenstellen begrenzt.
- Zahlerdaten, Kundenhinweise, Mailvorgaben, Fotoworkflows, Preisberechnung, Speicherung und Kopier-/Wiederholungsabläufe unterstützen diese Zuordnung. Gesperrte oder fremdmandantige Zahler, zurückgezogene Zuordnungen und Fremdzugriffe auf Stationsadressen werden abgewiesen. Die Zuordnung wird vor dem Schreiben erneut geprüft; Fehler rollen den Auftrag zurück. Der reine Drittzahlerbezug gibt keine fremden Kundenberichte, Dokumente oder Stammdatenänderungen frei. Die Rechnungsmail-Pflege ist bei fremder Niederlassung sichtbar gesperrt.
- **1508 Tests: 1505 bestanden, drei übersprungen, keine Fehler.** 144 gezielte Backendprüfungen, 35 Frontendtests, neun Browserprüfungen und fünf Prüfungen der Browseraufrufe erfolgreich. 1109 Dateien verifiziert. Nachweise: `work/cross-headquarters-payer-verification.json`, `work/cross-headquarters-payer-ui-verification.json`, `work/cross-headquarters-payer-deployment.json`. Lokal gestartet; Health UP, Datenbank verbunden, sechs Assets in dist/JAR/HTTP identisch. Nur isolierte Geschäftsdaten für Schreibprüfungen verwendet.
- Nächste bestätigte Lücken im Kundenstamm: Kopieren des Stammblatts und dessen spezielle PDF-Ausgabe. Die PHP-Druckversion ist auskommentiert; die PDF-Aktion ist aktiv. Die vorhandene PHP-Kundenansicht konnte nicht erneut an die Browsersteuerung angebunden werden; sie wurde nicht neu geladen, weil dieser PHP-Leseweg Kundendaten verändern kann. Gesamtparität bleibt offen; Classic-Sammelübergabe ist ausdrücklich ausgeschlossen.

## 19. Oktober 2026 – Startzahler in der Kundenerfassung

- Aktuelle `jobs2/job_options.php` und das tatsächlich geladene Template frisch vom Server abgeglichen: Kundeneingaben starten mit `csc_id_orderer`, also der eigenen Kostenstelle. Die interne Drittzahler-Vorgabe im Kundenstamm wird hierfür nicht verwendet. Dies korrigiert eine native Abweichung, die eingeschränkte Kundenmitarbeiter zum Stammzahler umleitete oder die Maske bei fremden/fehlenden Drittzahlern blockierte.
- Eigene Kostenstelle bleibt Startzahler; ein freigegebener Wechsel umfasst nur den eigenen Kostenstellen-Unterbaum. Interne Drittzahler-Zuordnungen erweitern weder Zahlerauswahl noch Adresszugriff und invalidieren keine unveränderten Kundenentwürfe. Gesperrte eigene Kostenstellen und geänderte Portalvorgaben werden weiterhin abgewiesen. Testfälle umfassen fremde Kunden, Niederlassungen und Mandanten, fehlende Zuordnungen, Speicherung, Wiederholungsabruf und Rechteänderung.
- Isolierter Portal-Integrationstest und kompletter Lauf bestanden: **1505 Tests, 1502 bestanden, drei übersprungen, keine Fehler.** Fünf Browserprüfungen und drei Prüfungen der Browseraufrufe bestanden; Frontend unverändert zum zuletzt geprüften Build. 1107 Dateien verifiziert; Nachweise: `work/customer-entry-payer-defaults-verification.json`, `work/customer-entry-payer-defaults-ui-verification.json`, `work/customer-entry-payer-defaults-deployment.json`. Health UP, DB verbunden, sechs Assets identisch. Keine realen Geschäftsdaten geschrieben.
- Als nächstes folgt die Verwendung niederlassungsübergreifender Drittzahler in der internen Auftragserfassung. Gesamtparität bleibt offen.

## 19. Oktober 2026 – Drittzahler und übergeordneter Kunde

- Die aktuelle PHP-Kundenauswahl frisch vom Server und lesend in der alten Oberfläche geprüft. Drittzahler und übergeordneter Kunde lassen sich bei Anlage und Bearbeitung suchen, zuordnen und entfernen. Die Suche bietet Niederlassungen nach aktuellem Rechteumfang, Präfix-/Teilwortsuche, ausgeblendete Kunden, Interessenten und Folgeseiten. Historische Zuordnungen bleiben ohne ungewollte Änderung erhalten; gesperrte oder ungeprüfte Treffer tragen Warnhinweise.
- Aktuelle Kunden- und Niederlassungsrechte werden beim Schreiben erneut geprüft. Archivierte und externe Drittzahler, Selbstverweise und übergeordnete Kundenkreise werden abgewiesen. Niederlassungsübergreifende gleichzeitige Gegenverknüpfungen sind serialisiert. Zuordnungen, Audit und Vorgangsbeleg werden atomar gespeichert; Wiederholungen, veraltete Entwürfe und Rollback geprüft. Der Suchdialog liegt außerhalb des Stammformulars; Schließen über das X löst kein Speichern aus.
- **Vollständiger Lauf: 1505 Tests, 1502 bestanden, drei übersprungen, keine Fehler.** 96 gezielte Backendprüfungen, 35 Frontendtests, 13 Browserprüfungen und sechs Prüfungen der Browseraufrufe bestanden. 1106 Dateien verifiziert; Nachweise: `work/customer-references-verification.json`, `work/customer-references-ui-verification.json`, `work/customer-references-deployment.json`. Health UP, DB verbunden, sechs Assets in Build/JAR/HTTP identisch. Ausschließlich isolierte Schreibprüfungen.
- Folgender Abgleich untersucht die Verwendung hinterlegter Drittzahler in der Auftragserfassung, insbesondere fremde Kunden und Niederlassungen. Gesamtparität bleibt offen; Classic-Sammelübergabe ist auf Nutzerwunsch ausgeschlossen.

## 19. Oktober 2026 – Branche, Vertrieb und zusätzliche Kundenfelder

- Die aktive PHP-Kundenmaske und ihre Auswahlabfragen frisch vom Server abgeglichen: Branche, Vertriebsmitarbeiter, subjektives Ranking A/B/C, Newsletter-Abonnement, DSGVO-Zustimmung und Einzelrechnung sind bei Neuanlage und Bearbeitung verfügbar. Sichtbare Branchen und Mitarbeiter der Arbeitsniederlassung werden angeboten; ohne Mitarbeiterverwaltungsrecht bleibt die Auswahl auf den eigenen Mitarbeiter begrenzt. Bestehende historische Zuordnungen bleiben lesbar und unverändert speicherbar.
- Vertriebszuordnung verlangt Recht 24, DSGVO-Änderung Recht 33; aktuelle Rechte werden beim Schreiben erneut gelesen. Fehlende Zusatzrechte sperren die zugehörigen Felder. Die Neuanlage setzt keine DSGVO-Zustimmung voraus; diese wird ausdrücklich gewählt. Einzelrechnung verändert nur Bit 2 und erhält das ausgeblendete Zentralrechnungs-Bit. Ältere Clients ohne die sechs neuen Felder erhalten bestehende Werte.
- Neuanlage, Änderung, Bestandsrevision, Audit und Wiederholungsbeleg gemeinsam geprüft; verspäteter Auditfehler rollt alle Werte zurück. 95 gezielte Backendprüfungen, 35 Frontendtests, neun Browserprüfungen und drei Prüfungen der Browseraufrufe bestanden. Browsernachweise mit isolierten Daten: `work/customer-company-settings-browser-checks.json`, `work/customer-company-settings-ui-verification.json`.
- **Vollständiger Lauf: 1501 Tests, 1498 bestanden, drei übersprungen, keine Fehler.** 1102 Dateien verifiziert; Nachweise: `work/customer-company-settings-verification.json`, `work/customer-company-settings-deployment.json`. Lokal Health UP, Datenbank verbunden und sechs identische Assets in Build, JAR und HTTP. Alle Schreibprüfungen fanden ausschließlich mit isolierten Testdaten statt.
- Gesamtparität bleibt offen. Die in PHP ausdrücklich ausgeblendeten Felder für Zentralrechnung, alten Foto-Abliefernachweis und Endgeräteauswertung zählen nicht als fehlende aktive UI-Funktionen. Classic-Sammelübergabe bleibt auf Nutzerwunsch ausgeschlossen.

## 19. Oktober 2026 – Kundentyp bei Neuanlage und Bearbeitung

- Aktuelle PHP-Neuanlage lesend geöffnet und die vier Typen sowie den Servercode erneut abgeglichen. Kunde, Interessent, Potenzialkunde und Wunschkunde lassen sich nun im Stammblatt pflegen; Bezeichnungen kommen aus den Metatypen. Vorhandene Zahler- oder Barzahleraufträge sperren Rückstufungen. Das Lesen verändert keine Altdaten; eine notwendige Korrektur wird erst beim ausdrücklichen Speichern wirksam. Sendungsverfolgung wird für Nichtkunden abgeschaltet und bei Rückkehr zum Kunden nicht unbemerkt reaktiviert.
- Wechsel auf Kunde setzt „Kunde seit“; Anlage und Typänderung erzeugen die konfigurierten Vertriebsberichte und Historieneinträge 95. Der ursprüngliche Kunden-Ersteller bleibt für die Vertriebsauswertung erhalten. MyISAM-Berichte werden über einen dauerhaften InnoDB-Auftrag übertragen: temporäre Wiedererkennungsmarkierung, gesicherte Berichts-ID, anschließende Bereinigung. Unterbrechungen an beiden Grenzen und gleichzeitige Wiederholungen geprüft. Ausstehende Berichte erscheinen als Hinweis; die Vertriebsauswertung berücksichtigt ausstehende Historieneinträge ohne doppelte Zählung.
- **Vollständiger Lauf: 1498 Tests, 1495 bestanden, drei übersprungen, keine Fehler.** 108 gezielte Backendprüfungen, 35 Frontendtests, neun Browserprüfungen und drei Prüfungen der Browseraufrufe bestanden; 1099 Dateien verifiziert. Nachweise: `work/customer-type-verification.json`, `work/customer-type-ui-verification.json`, `work/customer-type-deployment.json`. Health UP, DB verbunden, sechs Assets identisch. Keine realen Kundendaten geschrieben.
- Nächste bestätigte Lücken im Kundenstamm: Branche, Vertriebsmitarbeiter, subjektives Ranking, Newsletter-/DSGVO-Schalter und Einzelrechnung. Die PHP-Schalter für „Rechnung an Zentrale“, alten Foto-Abliefernachweis und Endgeräteauswertung sind ausdrücklich ausgeblendet und werden nicht als fehlende aktive UI-Funktionen gezählt. Die Suche im aktuellen PHP und in den Datenbanktriggern ergab keinen separaten automatischen Typwechsel beim ersten Auftrag; deshalb wurde kein unbelegter Ablauf eingeführt. Gesamtparität bleibt offen.

## 19. Oktober 2026 – Alte Kundennummer und Umfirmierung

- Aktuelle PHP-Felder und Schreibwege frisch vom Server geprüft. Gespeicherte Kunden erhalten den Dialog „Alte Kundennummer / Umfirmierung“ mit Vorschau: Vorgängerkunden zuordnen, unbekannte Nummer als Hinweis speichern oder Zuordnung entfernen. Selbstverweise, Kreise und mehrdeutige Nachfolger werden abgewiesen. Kundennummeränderungen halten die eigene Nachfolgernummer aktuell; bestehende Statistik kann alte Kunden bereits einbeziehen.
- Kundenrecht, aktuelle Niederlassungen und Bestandsrevision werden beim Speichern erneut geprüft. Vorgängerzuordnung, Hinweis, Audit und Vorgangsbeleg werden atomar geschrieben; Rücknahme bei Fehlern, konkurrierende Wiederholungen und verlorene Antworten geprüft. Bei unbekannter Ersatznummer wird eine alte Verknüpfung ausdrücklich entfernt, statt wie im PHP-Schreibweg unbemerkt bestehen zu bleiben.
- **Vollständiger Lauf: 1494 Tests, 1491 bestanden, drei übersprungen, keine Fehler.** 93 gezielte Backendprüfungen, 35 Frontendtests, acht Browserprüfungen und drei Prüfungen der Browseraufrufe bestanden. 1096 Quelldateien verifiziert. Nachweise: `work/customer-previous-number-verification.json`, `work/customer-previous-number-ui-verification.json`, `work/customer-previous-number-deployment.json`. Health UP, DB verbunden, sechs Assets identisch; ausschließlich isolierte Schreibtests.
- Als nächste bestätigte Lücke folgt die Kundentyp-Pflege einschließlich Bericht, Konversionsdatum und Vertriebsprotokoll. Gesamtparität weiterhin nicht abgeschlossen; Classic-Sammelübergabe bleibt auf Nutzerwunsch ausgeschlossen.

## 19. Oktober 2026 – Kommissionsnummer-Untervorgaben

- Aktuelle PHP-Radiofelder und deren Abhängigkeiten frisch vom Server abgeglichen; die Felder wurden im vorherigen lesenden Kundenmasken-Abgleich gesehen. Im Dialog Kundenerfassung lassen sich Stationskommissionsnummern, die Unfertig-Prüfung und die Pflicht an jeder Station gemeinsam pflegen. Das Abschalten eines übergeordneten Schalters setzt die untergeordneten Schalter zurück.
- Auch das Abschalten der Stationskommissionsnummer im allgemeinen Stammblatt setzt die beiden gespeicherten Untervorgaben atomar zurück. Späteres Einschalten aktiviert daher keine alten Untervorgaben unbeabsichtigt. Bereits vorhandene Auftragsprüfung verwendet die gespeicherten Parameter: mindestens eine oder jede Station, mit der PHP-Ausnahme für Kundeneingaben. Vorschau, Rechte, Bestandsrevision und Wiederholungsbeleg bleiben erhalten.
- **Vollständiger Lauf: 1490 Tests, 1487 bestanden, drei übersprungen, keine Fehler.** 102 gezielte Backendprüfungen, 35 Frontendtests, sieben Browserprüfungen und drei Prüfungen der Browseraufrufe bestanden. 1092 Quelldateien geprüft. Nachweise: `work/customer-commission-settings-verification.json`, `work/customer-commission-settings-ui-verification.json`, `work/customer-commission-settings-deployment.json`. Health UP, DB verbunden, sechs Assets identisch. Ausschließlich isolierte Schreibtests.
- Nächste Lücke: alte Kundennummer bei Umfirmierung. Der aktuelle PHP-Schreibablauf und die reale Tabellenstruktur wurden lesend geprüft; `customerchanged`, Kunden, Firmen, Parameter und Vorgangsbelege sind InnoDB. Kundentyp-Pflege bleibt ebenfalls offen. Keine vollständige Anwendungsparität behauptet.

## 19. Oktober 2026 – Startvorgaben bei Kunden-Neuanlage

- Die frisch am Server geprüften PHP-Startwerte werden jetzt bei der nativen Kunden-Neuanlage übernommen: automatische Vermittlung aus den beiden lokalen Einstellungen zur manuellen Disposition, Lademaße/Pflicht aus `MASK_CS_CARGO_DATA_ENABLED`. Globale Werte werden hier wie in PHP nicht als Rückfall verwendet.
- Die Neuanlage zeigt die Startwerte vor dem Speichern und sendet ihre Bestandsrevision. Geänderte Vorgaben sperren eine veraltete Anlage. Kundendatensatz, Lademaß-Liste und Pflichtparameter werden gemeinsam gespeichert; Rollback und konkurrierende Neuanlagen geprüft. Bestehende Kunden erhalten diese Startwerte bei späterer Bearbeitung nicht erneut. Weitere Kundenoptionen werden nach dem Anlegen im Dialog Kundenerfassung gepflegt.
- **Vollständiger Lauf: 1488 Tests, 1485 bestanden, drei übersprungen, keine Fehler.** 97 gezielte Backendtests, 35 Frontendtests, vier Browserprüfungen und drei Prüfungen der Browseraufrufe bestanden. 1091 Quelldateien geprüft. Nachweise: `work/customer-creation-defaults-verification.json`, `work/customer-creation-defaults-ui-verification.json`, `work/customer-creation-defaults-deployment.json`. Health UP, DB verbunden, sechs Assets identisch. Keine realen Kundendaten angelegt.
- Die Kundenerfassungsmaske erläutert jetzt ausdrücklich, dass die gespeicherte Adressvorgabe derzeit keine Aktion für ungeprüfte Adressen freischaltet. Nächste bestätigte Lücken: Pflege der Kommissionsnummer-Untervorgaben, alte Kundennummer bei Umfirmierung, Kundentyp bei Anlage/Bearbeitung. Die vorhandene Vertriebsansicht für Kundenstatuswechsel ist eine Auswertung, kein Ersatz für die Typ-Pflege. Gesamtparität weiterhin offen.

## 19. Oktober 2026 – Kundenerfassungsvorgaben im Kundenstamm

- Aktuelle `admin/customer_special.php` frisch vom Server und lesend in der PHP-Oberfläche abgeglichen. Eigener Dialog im gespeicherten Kundenstamm: Kundenerfassung, automatische Vermittlung, Selbsterfassungsrabatt, Storno, bevorzugte Transporteure, Standardpreis-/Calculator-Vorgaben, Adressvorgabe, Lademaße/Pflicht, automatisch unfertig und Auftragsfarbe. Ausgeblendete Aufträge werden wie in PHP nur angezeigt; der in PHP versteckte Preiswarn-Schalter wird nicht neu angeboten.
- Gemeinsame Speicherung von Kundenfeldern, Parametern, Audit und Vorgangsbeleg mit Vorher/Nachher-Vorschau. Aktuelle Rechte einschließlich Recht 41 für bevorzugte Transporteure, Niederlassung und Bestandsrevision werden erneut geprüft. Andere Kunden in der Lademaß-Liste sowie Parameterbeschreibungen bleiben erhalten. Fehler rollen alle Änderungen zurück; Wiederholungen nach verlorener Antwort sind idempotent.
- **Vollständiger Lauf: 1484 Tests, 1481 bestanden, drei übersprungen, keine Fehler.** 92 gezielte Backendprüfungen, 35 Frontendtests, elf Browserprüfungen und drei Prüfungen der Browseraufrufe bestanden. 1088 Quelldateien geprüft. Nachweise: `work/customer-entry-settings-verification.json`, `work/customer-entry-settings-ui-verification.json`, `work/customer-entry-settings-deployment.json`. Health UP, DB verbunden, sechs Assets identisch. Alle Schreibprüfungen mit isolierten Testdaten.
- Die Adressvorgabe wird wie im PHP-Stamm gespeichert. Die aktuelle `jobs2/job_tour.php` blendet die Aktion zur ungeprüften Adressübernahme in beiden Zweigen aus; hier wurde kein zusätzlicher Prüfungs-Bypass eingeführt. Nächste bestätigte Abweichung: niederlassungsabhängige Startvorgaben bei neuen Kunden (automatische Vermittlung und Lademaße). Gesamtparität weiterhin nicht abgeschlossen.

## 19. Oktober 2026 – Kunden-Ähnlichkeitssuche

- Aktuelle `admin/nearBySearch.php` frisch vom Server gelesen und die alte Trefferliste lesend geprüft. Suche nach Firmenworten mit Teiltreffern, abweichenden Buchstaben, Wiederholungen und PHP-Gewichtung umgesetzt. Automatisches Öffnen nach Änderung des Firmennamens berücksichtigt `MASK_CS_NEW_SIMILARITY_SEARCH`; manuelle Suche bleibt verfügbar.
- Berechtigter Niederlassungsumfang und `SIMILARITY_SEARCH_FILTER_HQ` werden berücksichtigt. Archivierte/ausgeblendete Treffer sind gekennzeichnet, fremde Niederlassungen nicht aus dieser Maske bearbeitbar. Je 100 Treffer mit Folgeseiten; vorhandene Kunden lassen sich öffnen, ohne den ungespeicherten ursprünglichen Entwurf zu verlieren. Leere oder fehlgeschlagene Suchen zeigen keine alten Treffer.
- **Vollständiger Lauf: 1478 Tests, 1475 bestanden, drei übersprungen, keine Fehler.** 95 gezielte Backendtests, 35 Frontendtests, elf Browserprüfungen und zwei Prüfungen der Browseraufrufe bestanden. 1084 Quelldateien geprüft. Nachweise: `work/customer-similarity-verification.json`, `work/customer-similarity-ui-verification.json`, `work/customer-similarity-deployment.json`. Health UP, DB verbunden, sechs Assets identisch. Keine Geschäftsdaten verändert.
- Nächster Abgleich: kundenseitige Auftragserfassung und zugehörige Kundeneinstellungen. Änderungen an `jobs/job_options_*.js` des letzten Servermanifests stammen nach frischer Prüfung aus dem Generator `jobs/job_options.js.inc.php`; diese Dateien sind erzeugte Niederlassungscaches. Gesamtparität weiterhin nicht abgeschlossen. Classic-Sammelübergabe bleibt ausdrücklich ausgeschlossen.

## 19. Oktober 2026 – Firmenprüfung und Verrechnungskundenhinweis

- Aktuelle `admin/courier_special.php` und `admin/customer_special.php` frisch vom Server abgeglichen. Neuanlagen von Transporteuren prüfen den Firmennamen innerhalb der Arbeitsniederlassung gemäß `MASK_CR_CHK_CMP_EXIST_DISABLED` (global). Bereits gespeicherte Transporteure bleiben wie in PHP bearbeitbar. Konkurrierende Neuanlagen werden serialisiert; ein identischer Wiederholungsabruf bleibt auch nach Änderung des Schalters erfolgreich.
- Im Kundenstamm erscheint bei passenden Namensbestandteilen aus `MASK_CS_CHECK_INTERNAL_BOOKING_ACCOUNT` der Hinweis zur Prüfung des Steuersatzes. Lokale Vorgabe mit globalem Rückfall, Änderung des Namens aktualisiert den Hinweis. Der Steuersatz wird nicht automatisch geändert.
- **Vollständiger Lauf: 1472 Tests, 1469 bestanden, drei übersprungen, keine Fehler.** 99 gezielte Backendtests, 35 Frontendtests, fünf Browserprüfungen und zwei Prüfungen der Browseraufrufe bestanden. 1080 Dateien geprüft. Nachweise: `work/master-company-rules-verification.json`, `work/master-company-rules-ui-verification.json`, `work/master-company-rules-deployment.json`. Health UP, DB verbunden und sechs Assets identisch.
- Aktuelle Datenbankparameter nur gelesen, sämtliche Schreibprüfungen isoliert. Nächste Lücke: Ähnlichkeitssuche nach Kundenfirmen (`admin/nearBySearch.php`); aktuelle PHP-Oberfläche lesend geprüft. Die alte Transporteur-SID ist in allen gelesenen Niederlassungen abgeschaltet und wird in der aktuellen PHP-Schreiblogik ausdrücklich nicht mehr gespeichert; daraus wurde keine neue SID-Schreibfunktion abgeleitet.

## 19. Oktober 2026 – Kundenangaben in Kostenstellen übernehmen

- Aktuelle `admin/customer_special.php` vom Server erneut geprüft; die beiden Übernahmegruppen wurden zuvor auch in der alten Kundenmaske betrachtet. Native Aktion im Kundenstamm unter Kostenstellen: Firmenbezeichnungen und Postanschrift/Hausnummer getrennt auf Hauptkostenstelle oder alle Kostenstellen übertragen, je Leistungs-, Rechnungs- und Abholanschrift.
- Die Aktion verwendet gespeicherte Kundenangaben und zeigt vor der Übernahme sämtliche geänderten Anschriften. Bestehende Zusatzadressen (Typ 3), Kontakte und Kostenstellennamen bleiben erhalten. Wie PHP umfasst „Alle“ auch gesperrte, unsichtbare und externe Kostenstellen desselben Kunden. Fehlende Adressarten werden nicht angelegt. Gemeinsame Adressdatensätze vergangener Aufträge werden nicht verändert.
- Revision umfasst Quelle und Ziele. Gleichzeitige Änderungen sperren die alte Vorschau; Änderungen, Audit und Vorgangsbeleg werden atomar gespeichert. Identische Wiederholungen ändern den Bestand einmal. Umfangs- und Rechteprüfung, Rollback und konkurrierende Wiederholung im isolierten SQL-Test geprüft.
- **Vollständiger Lauf: 1469 Tests, 1466 bestanden, drei übersprungen, keine Fehler.** 91 gezielte Backendprüfungen, 35 Frontendtests, elf Browserprüfungen und drei Prüfungen der Browseraufrufe erfolgreich. Anschließende reine Tabellenlayoutkorrektur erneut mit Frontendtests/Build und Browser geprüft; Backend unverändert zum Gesamtlauf. 1078 Dateien dokumentiert.
- Nachweise: `work/customer-address-propagation-verification.json`, `work/customer-address-propagation-layout-verification.json`, `work/customer-address-propagation-ui-verification.json`, `work/customer-address-propagation-layout-deployment.json`. Health UP, DB verbunden, sechs Assets identisch. Keine echten Kundendaten verändert. Weitere bestätigte Abweichungen: Prüfung doppelter Kurierfirmennamen und Hinweis auf interne Verrechnungskunden; Ähnlichkeitssuche wird weiter abgeglichen.

## 19. Oktober 2026 – Stammdaten: Nummernvorschläge und Eingaberegeln

- Aktuelle Kunden-, Kurier- und Fahrzeugmasken frisch vom PHP-Server und Kunden-/Kurier-Neuanlage lesend in der alten UI geprüft. Niederlassungspräfixe, bewusste Übernahme eines Kundennummer-/Kuriernummernvorschlags und Bearbeitungssperren vorhandener Nummern sind umgesetzt. Fahrzeugnummern erhalten den konfigurierten Präfix. Vorschläge reservieren keine Nummer; beim Speichern wird die Belegung erneut geprüft.
- Konfigurierte Kuriernummernlängen, Telefonnummernlänge, Provisionsgrenzen, einzelne Rechnungs-/Mahnadressen sowie erforderliches Fahrzeuggesamtgewicht werden angezeigt und serverseitig geprüft. Explizite lokale Nullwerte überschreiben globale Vorgaben. Ungültige Konfigurationen werden gemeldet.
- **Vollständiger Lauf: 1464 Tests, 1461 bestanden, drei übersprungen, keine Fehler.** Zusätzlich 96 gezielte Backendprüfungen, 35 Frontendtests, zwölf Browserprüfungen und drei Prüfungen der Browseraufrufe bestanden. 1074 Dateien eingefroren und geprüft. Lokaler Start bestätigt, Health UP, DB verbunden und sechs Assets identisch.
- Nachweise: `work/master-entry-rules-verification.json`, `work/master-entry-rules-ui-verification.json`, `work/master-entry-rules-deployment.json`. Reale Konfiguration nur gelesen; sämtliche Schreibprüfungen isoliert. Nächste bestätigte Abweichung: getrennte Übernahme von Firmenbezeichnungen und Adressen in ausgewählte Kostenstellenadressarten. Gesamtparität weiterhin nicht abgeschlossen.

## 19. Oktober 2026 – Info-Startseite, Direktsuche und Kundenhinweise

- Aktuelle `admin/start.php`, `include/ajaxReqSearch.php`, `include/menu.js.php` und `groupware/calendar.php` frisch per SSH abgeglichen. Info ist aus der Kopfzeile erreichbar: Geburtstage im berechtigten Niederlassungsumfang, genaue Auftragssuche sowie Suche nach Kunde, Fahrer und Fahrzeug einschließlich Namen/Matchcode; Treffer öffnen bestehende native Dialoge.
- Neue Berichte seit dem vorigen Login innerhalb der letzten sieben Tage, vertrauliche Inhalte nur gemäß Berichtsrechten. Berichtslisten übernehmen den Zeitraum. Eigene/eingeladene überwachte Termine reichen einen Monat zurück bis sieben Tage voraus, normale Termine von heute bis morgen; mehrtägige Überschneidungen und die PHP-Monatsüberlaufregel bleiben erhalten. Kalender und Termineditor sind verknüpft.
- Öffentlicher Kundenhinweis und E-Mail-Zusatz werden mit Recht 0+35 in der Heimatniederlassung gemeinsam gespeichert, mit aktueller Rechteprüfung, Revision, atomarem Vorgangsbeleg und identischer Wiederholung bei verlorener Antwort. Im Kundenportal erscheint nur der öffentliche Hinweis als Text. Öffnen schreibt keine Lesemarken oder Status; Speichern versendet keine E-Mail. Ein ausgefallener Teilbereich blockiert die übrigen Anzeigen nicht.
- **Vollständiger Lauf: 1455 Tests, 1452 bestanden, drei übersprungen, keine Fehler.** Zusätzlich 129 gezielte Backendprüfungen, 35 Frontendtests, 19 Browserprüfungen und vier Prüfungen der Browseraufrufe bestanden. TypeScript/Produktionsbuild erfolgreich; 1070 Dateien geprüft. Nachweise: `work/information-dashboard-verification.json`, `work/information-dashboard-focused-verification.json`, `work/information-dashboard-ui-verification.json`, `work/information-dashboard-deployment.json`. Lokaler Start bestätigt, Health UP, DB verbunden und sechs Assets identisch.
- Prüfungen ausschließlich mit isolierter SQL-Datenbank und synthetischen Browserdaten. Die vorhandenen Zielformulare wurden für neue Verknüpfungen geprüft, nicht vollständig erneut im Browser abgenommen. Die bereits geöffnete alte PHP-Info-Seite ließ sich nicht an die Browsersteuerung anbinden; der Abgleich dieses Blocks beruht daher auf den frisch gelesenen Serverquellen. Keine vollständige Anwendungsparität aus diesem einzelnen Block abgeleitet.

## 19. Oktober 2026 – Persönliche Mitteilungen

- Aktuelle PHP-Mitarbeitermitteilungen und Kopfzeilenaktion erneut am Server geprüft. Die native Anzeige liest gültige persönliche und globale Mitteilungen, mit Betreff, Autor, Zeitraum, ungelesener Anzahl und 50 Einträgen je Seite. Die vorhandene Mitteilungsverwaltung ist mit Recht 18 verknüpft.
- Öffnen bleibt lesend. Nur ausdrücklich bestätigte angezeigte Nachrichten erhalten individuelle Lesebelege. Die vorhandene PHP-Lesemarke wird berücksichtigt, aber nicht pauschal erhöht: später gültige oder noch nicht angezeigte Nachrichten bleiben dadurch ungelesen. Native Einzelbestätigungen ändern bewusst nicht die pauschale PHP-Lesemarke. Fremde Empfänger/Niederlassungen, geänderte Inhalte und ungültige Zeiträume werden beim Bestätigen erneut geprüft.
- **112 gezielte Backendtests, 35 Frontendtests, 15 Browserprüfungen und vier Prüfungen der Browseraufrufe bestanden.** TypeScript/Produktionsbuild erfolgreich; 1066 Dateien geprüft. Letzter vollständiger Gesamtlauf weiterhin 1441 Tests (1438 bestanden, drei übersprungen). Nachweise: `work/personal-inbox-verification.json`, `work/personal-inbox-ui-verification.json`, `work/personal-inbox-deployment.json`. Lokaler Start bestätigt, Health UP, DB verbunden und sechs Assets identisch.
- Ausschließlich synthetische Mitteilungen bestätigt, keine echten Nachrichten geändert oder versendet. Nächste bestätigte Lücke: Info-Startseite mit Direktsuche, Geburtstagen, Berichten, Terminen und Kundenhinweisen. Classic-Sammelübergabe bleibt auf Nutzerwunsch ausgeschlossen.

## 19. Oktober 2026 – Native Anmeldungshistorie und gemeinsamer Gesamtlauf

- Erfolgreiche Mitarbeiteranmeldungen schreiben einen dauerhaften Vorgang 52 in die vorhandene Audit-Warteschlange und setzen ausschließlich den eigenen Vermittlungsstatus zurück. Projekt-/E-Mail-Status und Mitteilungslesemarke bleiben erhalten. Portal-Anmeldungen ändern keine Mitarbeiterstatus.
- Die Kundenakte kombiniert PHP-Loginhistorie und noch ausstehende native Loginereignisse. Dieselbe Anmeldung zählt vor und nach der Übernahme ins PHP-Protokoll einmal. Die Anzeige funktioniert daher auch bei ausgeschalteter Hintergrundverarbeitung. Eine fehlgeschlagene Protokollierung beendet die neue Sitzung und liefert einen erneuten Anmeldehinweis.
- **97 gezielte Prüfungen und anschließend der vollständige Lauf mit 1441 Tests erfolgreich: 1438 bestanden, drei übersprungen, keine Fehler.** 1062 Quellen/Frontenddateien geprüft. Dieser Gesamtlauf schließt auch die zuvor gezielt geprüfte Kontaktliste, Kundenakte und Kopfzeilenstatus ein. Nachweise: `work/login-activity-focused-verification.json`, `work/login-activity-verification.json`, `work/login-activity-deployment.json`. Lokaler Start bestätigt, Health UP, DB verbunden und sechs Assets identisch.
- Echte Anmeldungen oder Statusänderungen wurden für die Prüfung nicht ausgelöst. Nur der isolierte Datenbankbestand und MockMvc wurden beschrieben. Offen bleiben persönliche Mitteilungen und Info-Startseite; Classic-Sammelübergabe ist auf Nutzerwunsch ausgeschlossen.

## 19. Oktober 2026 – Persönliche Statusanzeigen in der Kopfzeile

- Die aktuelle PHP-Konfiguration und die bereits geöffnete PHP-Statusanzeige geprüft. Vermittlung, Projekte und Emails werden mit niederlassungsspezifischen Bezeichnungen und globalem Rückfallwert angezeigt. Ein Klick zeigt die aktiven Mitarbeiter; nur die separate Statusaktion ändert den eigenen Eintrag.
- Gespeichert werden dieselben `usr_state_*`-Werte wie in PHP. Fremde Arbeitsniederlassungen bleiben lesend. Tabellenlocks schützen die MyISAM-Mitarbeiter-/Konfigurationsdaten beim Schreiben des InnoDB-Status; Revision und Vorgangsbeleg verhindern verlorene Änderungen und doppelte Umschaltungen. Die Mitteilungs-Lesemarke ist kein beschreibbarer Status.
- **Fünf gezielte Backendtests, 35 Frontendtests und elf Browserprüfungen bestanden.** TypeScript/Produktionsbuild erfolgreich; 1059 Dateien geprüft. Nachweise: `work/header-activity-verification.json`, `work/header-activity-ui-verification.json`, `work/header-activity-deployment.json`. Lokal Health UP, Datenbank verbunden, sechs Assets identisch. Keine echten Mitarbeiterstatus geändert. Letzte vollständige Gesamtbasis unverändert 1424 Tests; die neuen Läufe sind gezielt.
- Noch separat umzusetzen: Loginprotokoll/Dispo-Reset, persönliche Mitteilungen und Info-Startseite.

## 19. Oktober 2026 – Native Kundenakte

- Gegen die aktuelle SSH-PHP-Version von `admin/dashb_cs.php` und den Dashboard-/Statistikdiensten abgeglichen. Unter Vertrieb → Kundenakte stehen Firma, Ansprechpartner, Bankdaten, Kostenstellen, bevorzugte/gesperrte Fahrer, letzter Auftrag, Berichte und Termine bereit. Drei Kalenderjahre werden als Jahreswerte, Monatsdiagramme und 36-zeilige Wertetabelle angezeigt; negative Umsätze bleiben erhalten.
- Rechte 0/11/36 sowie bereichsspezifische Rechte werden geprüft. Fremde Niederlassungen und vertrauliche Berichte/Termine bleiben geschützt. Nicht verfügbare Teilbereiche werden als solche angezeigt. Detailverknüpfungen führen zu vorhandenen Stamm-, Berichts-, Termin- und Auftragsdialogen.
- **53 gezielte Backendprüfungen, 35 Frontendtests und 14 Browserprüfungen bestanden**; TypeScript und Produktionsbuild erfolgreich. 1055 Dateien eingefroren und geprüft. Letzte vollständige Gesamtbasis bleibt 1424 Tests (1421 bestanden, drei übersprungen); hier wurde kein neuer Gesamtlauf behauptet. Nachweise: `work/customer-dashboard-verification.json`, `work/customer-dashboard-ui-verification.json`, `work/customer-dashboard-deployment.json`.
- Lokal Health UP, Datenbank verbunden, sechs ausgelieferte Assets identisch. DB-Schreibprüfungen nur im isolierten Testbestand. Browserprüfungen verwenden synthetische Daten; sie prüfen die neuen Verknüpfungen, nicht erneut sämtliche bestehende Zielformulare. Noch offen sind Kopfzeilen-/Infobereiche einschließlich der nativen Loginprotokollierung; die Kundenakte wertet bis dahin vorhandene PHP-Loginhistorie aus.

**Umfangsentscheidung vom 19. Oktober 2026:** Die Classic-Sammelübergabe entfällt auf ausdrücklichen Nutzerwunsch. Sie ist keine offene Migrationsfunktion mehr. Die vorhandene Classic-Einzelübergabe bleibt bestehen.

## 19. Oktober 2026 – Vollständige Kontaktliste und Firmen-Präfixsuche

- Aktuelle PHP-Kontaktliste erneut direkt vom Server und in ihrer Listenansicht geprüft. Die native Liste zeigt jetzt sämtliche konfigurierten Felder als Spalten, getrennt nach Niederlassungsformular. Fehlende Werte bleiben in ihrer vorgesehenen Spalte. Breite Tabellen lassen sich innerhalb des Listenbereichs horizontal scrollen; alle hinteren Felder sind erreichbar.
- Die Präfixsuche prüft externe Kundennummer, Firmenname und Zusatzname jeweils einzeln. Berechtigte niederlassungsübergreifende Kundenverweise werden aufgelöst; ausgeblendete, unbestätigte oder fremden Mandanten zugeordnete Firmen werden nicht durch die Suche offengelegt. Sonderzeichen bleiben wörtliche Suchzeichen.
- **31 gezielte Backendprüfungen, 32 Frontendtests und elf Browserprüfungen bestanden.** TypeScript und Produktionsbuild waren für die Listen-/Suchänderung erfolgreich; die anschließende reine CSS-Korrektur wurde erneut mit Frontendtests, Vite-Build und Browserprüfung geprüft. Letzte vollständig abgeschlossene Gesamtbasis: **1424 Tests, 1421 bestanden, drei übersprungen**. Der spätere Gesamtlauf wurde vor Abschluss bewusst beendet und zählt ausdrücklich nicht als bestanden (`work/contact-list-search-interrupted-full.json`).
- Geprüfte Quellen und CSS-Folgestand: `work/contact-list-search-verification.json` und `work/contact-list-search-layout-verification.json`, 1048 Dateien. Lokal Health UP, Datenbank verbunden und sechs Assets identisch (`work/contact-list-search-deployment.json`). Nur synthetische Kontaktdaten verändert. Die Kundenakte sowie Kopfzeilen-/Infofunktionen sind weitere bestätigte Abweichungen; deren Bearbeitung läuft.

## 19. Oktober 2026 – Konfigurierbare Kontaktkarten und sichere Verknüpfungen

- Aktive PHP-Kontaktliste und Feldreihenfolge erneut direkt vom Server abgeglichen. Explizit konfigurierte Überschriften, sichtbare Kartenfelder und Sortierfelder werden jetzt übernommen. Fehlende gespeicherte Felder verschieben keine Feldzuordnungen. Ohne Einstellung bleibt die bisherige native Darstellung erhalten; ungültige oder mehrdeutige Vorgaben werden angezeigt.
- Telefon-/Mobil-/Faxfelder erhalten wählbare Verknüpfungen, HTTP-/HTTPS-Webseiten sichere Weblinks. Mehrere E-Mail-Adressen bleiben einzelne Mailverknüpfungen. Andere bzw. ungültige Inhalte bleiben Text. Firmenbezeichnungen behalten ihre berechtigte Kundenauflösung.
- **1424 Tests: 1421 bestanden, drei übersprungen, keine Fehler** (`work/contact-presentation-verification.json`, 1047 archivierte Dateien). 30 gezielte Backendprüfungen, 32 Frontendtests und acht Browserprüfungen bestanden. Der Gesamtlauf enthält auch die nach dem vorigen vCard-Gesamttest vorgenommene Formatkorrektur. Der heruntergeladene vCard-Inhalt wurde erneut bytegenau mit der SQL-Fixture verglichen.
- Lokal Health UP, Datenbank verbunden und sechs Assets identisch (`work/contact-presentation-deployment.json`). Nur synthetische Kontaktdaten verwendet, keine echten Änderungen oder E-Mails. Präfixsuche nach Firmen und vollständige Kontakt-Listenansicht sind als nächste konkrete Abweichungen im aktuellen PHP bestätigt; der Abgleich läuft weiter.

## 19. Oktober 2026 – Vollständige Kontakt-vCard mit E-Mail-Versand

- Aktive `admin/metafield_list.php` (`511e3581655f501c4547122c0837e3c288729ba92d9f8264853920d7eedadcd4`), vCard-Klasse und `include/email_send.php` frisch per SSH gelesen; aktuelle PHP-Kontaktoberfläche geöffnet. vCard-Vorschau, Download und bestätigter E-Mail-Anhang ergänzt. Firma, Website, Geburtstag, Anschrift, private/geschäftliche Nummern und einzelne E-Mail-Adressen werden ausgegeben. Firmen werden ausschließlich im berechtigten Niederlassungsumfang und bei sichtbaren/authentifizierten Stammdaten aufgelöst.
- Globale Namens-/Adressfeldzuordnungen werden berücksichtigt. Ohne Adressvorgabe verwendet NG weiterhin die echten beschrifteten Adressfelder; die PHP-Vorgabe `8,9` würde im vorhandenen Formular Mobilnummern als Straße/Hausnummer ausgeben. Die eigene E-Mail-Adresse wird als Empfänger vorgeschlagen. Absender folgt der vorhandenen Mailkonfiguration. Vorschau und Anhang sind identisch; Änderungen an Kontakt, Zuordnung oder Absender verlangen erneute Vorbereitung.
- Dauerhafter Versandbeleg und Audit werden vor SMTP gemeinsam gespeichert. Wiederholung, Neustart, parallele Aufrufe und verlorene Bestätigung senden denselben Vorgang nicht doppelt. Persönlicher Versandverlauf und klare Anzeige ungewisser Zustellung vorhanden. Tests ausschließlich mit Mock-Transport bzw. lokalem SMTP-Testserver; keine realen Mails.
- **Gesamtbasis: 1420 Tests, 1417 bestanden, drei übersprungen, keine Fehler** (`work/contact-vcard-verification.json`, 1041 Dateien). Anschließende vCard-Formatkorrektur für Website- und E-Mail-Parameter mit allen 13 betroffenen Backendprüfungen erneut bestanden (`work/contact-vcard-format-verification.json`). Formatabgleich anhand [RFC 2426](https://www.rfc-editor.org/info/rfc2426/). 29 Frontendtests und zehn Browserprüfungen einschließlich Download sowie identischem Wiederholungsaufruf bestanden (`work/contact-vcard-ui-verification.json`); die Browser-Aufzeichnung stammt vor der anschließenden reinen Formatkorrektur, deren Inhalt im SQL-/SMTP-Test erneut geprüft wurde.
- Lokal Health UP, Datenbank verbunden und sechs Assets identisch (`work/contact-vcard-deployment.json`). Keine echten Kontakte geändert. Konfigurierbare Kontaktkarten und Sortierung folgen im nächsten Abgleich; keine vollständige Anwendungsparität behauptet.

## 19. Oktober 2026 – E-Mail- und Nummernprüfung für Kontakte und Formulare

- Aktuelle `include/checkFormTags.js` erneut direkt vom PHP-Server gelesen. Gemeinsame Kontaktfelder prüfen E-Mail-Adressen einschließlich PHP-kompatibler Kommalisten und Nummernfelder. 40 E-Mail- sowie 26 Nummernfälle wurden gegen die isoliert ausgeführten aktuellen PHP-JavaScript-Funktionen abgeglichen. Die ungewöhnlich großzügigen PHP-Zahlformate bleiben kompatibel. Unveränderte ungültige Altwerte einschließlich ihrer Leerzeichen blockieren keine anderen Änderungen.
- Die Kontaktmaske akzeptiert mehrere Adressen mit sichtbarem Hinweis; die vCard erhält eine eigene E-Mail-Zeile je Adresse. Keine native Einzeladressprüfung blockiert gültige Kommalisten mehr. SQL-Prüfungen belegen Validierung vor dem Schreiben, vollständige Rücknahme bei Historienfehlern und unveränderte Altwerte.
- **1413 Tests: 1410 bestanden, drei übersprungen, keine Fehler** (`work/form-contact-verification.json`, 1035 archivierte Dateien). 38 gezielte Backendprüfungen, 29 Frontendtests und sieben Browserprüfungen mit synthetischen Daten erfolgreich (`work/form-contact-ui-verification.json`). Lokal Health UP, Datenbank verbunden, sechs identische Assets (`work/form-contact-deployment.json`). Keine echten Kontakte verändert oder E-Mails versendet.
- Frischer Dateiabgleich über 1206 Serverdateien dokumentiert (`work/php-server-manifest-comparison-2026-10-19.json`). Weitere Kontaktfunktionen, insbesondere vollständige vCard-Ausgabe und Anhangsversand, werden anschließend ergänzt. Keine vollständige Anwendungsparität behauptet.

## 19. Oktober 2026 – Kundenverweise und Zeitangaben in Formularen

- Aktuelle PHP-Ausgabe in `include/inc_metafield.inc.php` erneut per SSH gelesen und die alte Kontakt-/Formularmaske im Browser geprüft. Der gemeinsame Formulardruck zeigt bei `co2cs` nun die externe Kundennummer und Firma. Auflösung ausschließlich mit Kundenleserecht, innerhalb der Formularniederlassung und für sichtbare/authentifizierte Firmen; fremde, fehlende oder ausgeblendete Verweise bleiben als gespeicherte ID erhalten. Gewöhnliche Auswahlfelder bleiben entsprechend PHP unverändert.
- Erinnerungszeitpunkte im historischen kompakten Speicherformat erhalten in der NG-Ausgabe einen Abstand zwischen Datum und Uhrzeit. Bewusste Lesbarkeitskorrektur: Der aktuelle PHP-Druckzweig zeigt bei diesen Feldern nur den Datumsteil. NG erhält auch die vorhandene Uhrzeit. Ungültige Altwerte bleiben sicher sichtbar; Eingaben, Speicherung und Historie werden durch die Darstellung nicht geändert.
- **1407 Tests: 1404 bestanden, drei übersprungen, keine Fehler** (`work/form-presentation-verification.json`, 1028 archivierte Dateien). 31 gezielte Prüfungen und sieben Browserprüfungen bestanden. SQL-Fixture belegt unveränderte IDs/Zeitspeicherung, aktualisierte Firmendarstellung ohne Historieneintrag, Schutz fremder/ausgeblendeter Kunden und sichere Textausgabe. Die alte leere Kontaktmaske lieferte keine befüllten Vergleichskarten; die sichtbare Ausgabekontrolle erfolgte daher mit synthetischen Daten.
- Lokal Health UP, Datenbank verbunden, sechs identische Assets (`work/form-presentation-deployment.json`). Die sichtbaren 18 Sonderauswertungen unter „Kessel Buntes“ sind im frischen UI-/Quellabgleich passenden NG-Bereichen zugeordnet (`work/extras-rest-legacy-ui-2026-10-19.txt`, `work/extras-rest-options-fresh-2026-10-19.txt`). Weitere Eingabeprüfungen werden anschließend ergänzt; keine vollständige Anwendungsparität behauptet.

## 19. Oktober 2026 – Zahlenformatierung in der Formularausgabe

- Aktuelle `include/inc_metafield.inc.php` und `include/mcglobal.inc.php` erneut per SSH gelesen. Die gemeinsame Formularausgabe formatiert `float_2` jetzt mit zwei Dezimalstellen und ganze Zahlen ohne Nachkommastellen, jeweils mit deutschem Dezimalkomma/Tausenderpunkt und PHP-kompatibler Rundung. Freie Dezimalfelder, gespeicherte Eingabewerte und Vorlagenplatzhalter bleiben erhalten. Ungültige Altwerte werden sicher als Text angezeigt; extreme Exponenten verursachen keine unbeschränkte Ausgabe.
- **1403 Tests: 1400 bestanden, drei übersprungen, keine Fehler** (`work/form-number-output-verification.json`, 1026 archivierte Dateien). 27 gezielte Prüfungen bestanden; 32 Zahlenfälle gegen die isoliert ausgeführte aktuelle PHP-Funktion geprüft. Sechs Browserprüfungen mit synthetischen Daten belegen Druckformat, unveränderte freie Genauigkeit und Eingabewerte vor/nach der Vorschau (`work/form-number-output-ui-verification.json`). Keine Formularspeicherung oder echte Datenänderung.
- Lokal Health UP, Datenbank verbunden, sechs identische Assets (`work/form-number-output-deployment.json`). Die aktuelle PHP-Preisformularmaske ist weiterhin ohne konfigurierte Felder; die sichtbare Zahlenprüfung verwendet deshalb ein isoliertes Testformular. Der weitere Abgleich läuft.

## 19. Oktober 2026 – Formularvorbelegung bei unvollständigen Stammdaten

- Die frisch gelesene PHP-Feldauflösung liefert bei fehlenden optionalen Firmen-, Adress- oder Kontaktzeilen leere Angaben. Der gemeinsame NG-Formularbaustein liest jetzt nur die für die gewählten Felder benötigten Quellen. Eine Kundennummer benötigt keine Firma/Adresse/Ansprechpartner; ein Firmenname keinen Ansprechpartner. Fehlende optionale Verknüpfungen blockieren das Formular nicht mehr, mehrdeutige Daten werden weiterhin abgewiesen.
- **1399 Tests: 1396 bestanden, drei übersprungen, keine Fehler** (`work/form-defaults-partial-verification.json`, 1024 archivierte Dateien). 22 gezielte Prüfungen bestanden, einschließlich realer SQL-Fixture mit Kunde ohne Ansprechpartner und gemeinsamer Zusatz-/Preisformulare. Unverändertes Frontend aus dem geprüften Stand mit 26 Tests. Lokal Health UP, Datenbank verbunden, sechs identische Assets. Keine echten Daten geändert.
- Restgrenzen erneut gelesen: aktuelle PHP-Classic-Sammelübergabe ruft weiterhin die nicht im eingebundenen Kopiermodul vorhandene Funktion `copy_jobs_cartage` auf, der automatische Rechnungslauf steht im aktuellen PHP unter TOBEDONE, und die alten `jobhistory`/`tourhistory`-Tabellen sowie `employeecostcenter` fehlen im verbundenen Hauptschema (`work/remaining-schema-read-2026-10-19.json`). Der separate vorhandene Belegarchivleser bleibt davon unabhängig. Dies ersetzt keine vollständige Paritätsprüfung.

## 19. Oktober 2026 – Stammdaten- und Systemvorbelegung in Preisformularen

- Frischer SSH-Abgleich der System-/Datenbankfelder in `include/inc_metafield.inc.php`: Kundenpreisformulare übernehmen jetzt verfügbare Kundenangaben, Datum und Niederlassungsdaten als bearbeitbare Formularvorbelegung. Aktueller Bearbeiter und Niederlassungslogo bleiben reine Anzeige. Derselbe lesende Baustein versorgt auch die bestehenden zweiten Stammdatenseiten; deren Verhalten wurde mitgeprüft.
- Gespeicherte Formularangaben haben Vorrang vor später geänderten Stammdaten. Änderungen werden ausschließlich in den Formularwerten gespeichert. Leere Formularwerte werden beim nächsten Öffnen entsprechend PHP erneut vorgeschlagen und als noch ungespeichert gekennzeichnet. Fremde Kunden und unpassende Objekttypen werden nicht als Datenquelle verwendet; reine Anzeigefelder lassen sich nicht einschleusen.
- **1395 Tests: 1392 bestanden, drei übersprungen, keine Fehler** (`work/customer-price-defaults-verification.json`, 1023 archivierte Dateien). 18 gezielte Prüfungen und 26 Frontendtests bestanden. Eigene SQL-Fixture belegt unveränderte Kunden-/Firmen-/Adress-/Benutzerdaten, gespeicherte Abweichungen, aktualisierte Vorschläge, Historie, Rücknahme bei Fehlern und identische Wiederholung.
- 14 Browserprüfungen mit synthetischen Daten und lokalem Testlogo erfolgreich (`work/customer-price-defaults-ui-verification.json`): vorbelegte Eingaben, Hinweise, Speichern ohne vorherige Eingabeänderung, Überschreiben nur im Formular, schreibgeschützter Bearbeiter und identische Wiederholung nach verlorener Antwort. Lokal Health UP, Datenbank verbunden, sechs identische Assets. Keine echten Geschäftsdaten geändert. Weiterer Restabgleich läuft; beliebige neue Vorlagenskripte bleiben gesondert zu prüfen.

## 19. Oktober 2026 – Automatische Werte und Summen in Kundenpreisformularen

- Aktuelle `inc_metafield.inc.php` (Autor-/Referenzfelder) und der Aufruf von `formularFinishPage` in `metafield_special.php` erneut direkt auf dem PHP-Server gelesen. Preisformulare erzeugen nun den ursprünglichen Bearbeiter, zusammengesetzte Referenzfelder sowie die bereits bekannten Auswahl-Summen serverseitig. Berechnete Summen aktualisieren sich auch während der Eingabe; gespeicherte Bearbeiter bleiben bei späteren Änderungen erhalten.
- Eingeschleuste Summen werden neu berechnet. Autor-/Referenzfelder sind nicht frei überschreibbar. Fehlende, fremde oder zyklische Referenzen werden abgewiesen. Unbekannte Speicherskripte machen das Formular ausdrücklich schreibgeschützt; Vorlagenänderungen zwischen Laden und Speichern erzeugen einen Konflikt. Die aktuelle Datenbank enthält keine eingerichteten Preisformularfelder; keine aktiven neuen Berechnungsregeln behauptet.
- **1394 Tests: 1391 bestanden, drei übersprungen, keine Fehler** (`work/customer-price-calculations-verification.json`, 1021 archivierte Dateien). 16 gezielte Backendprüfungen und 26 Frontendtests bestanden. SQL-Prüfungen belegen Berechnung, Normalisierung, Historie, ursprünglichen Autor, Manipulationsabwehr und vollständige Rücknahme bei Auditfehlern.
- Zwölf Browserprüfungen mit synthetischen Daten erfolgreich: direkte Summenänderung, Autor-/Referenzanzeige, identischer Wiederholungsaufruf nach verlorener Antwort und gesperrte Bearbeitung bei unbekannter Regel (`work/customer-price-calculations-ui-verification.json`). Lokal Health UP, Datenbank verbunden, sechs identische Assets. Stammdaten-Vorbelegungen werden anschließend gesondert ergänzt; keine vollständige Anwendungsparität behauptet.

## 19. Oktober 2026 – Erweiterte Felder in Kundenpreisformularen

- Aktuelle PHP-Preisformularmaske im Browser geöffnet und `admin/metafield_special.php`, `include/inc_metafield.inc.php` sowie `admin/customer_service.php` erneut per SSH abgeglichen. Die sechs Preis-/Aktionsformulare (20–25) unterstützen jetzt zusätzlich gerundete Dezimalpreise, ganze Zahlen, weitere Datums-/Zeitfelder, Kontaktangaben, Links/Bilder, berechtigte Suchauswahlen und Niederlassungszuordnungen. Im aktuellen Bestand sind diese sechs Formulare noch ohne Felddefinitionen; die Erweiterung wurde deshalb mit isolierten Beispieldaten geprüft.
- PHP-kompatible Rundung und Speicherung; ungültige Zahlen/Datumseingaben werden abgewiesen. Auswahllisten und Speicherung prüfen Kunde, Formular, Rechte und Niederlassung. Bestehende nicht mehr verfügbare Auswahlwerte bleiben bei anderen Änderungen erhalten. Lesesperren für die tatsächlich verwendeten Auswahlkataloge ergänzen den atomaren Ablauf mit Feldhistorie und Vorgangsbeleg.
- **1393 Tests: 1390 bestanden, drei übersprungen, keine Fehler** (`work/customer-price-fields-verification.json`, 1020 archivierte Dateien). Zehn gezielte Prüfungen einschließlich separater SQL-Fixture sowie 26 Frontendtests erfolgreich, Build bestanden. Rechte, fremde Kunden, Rundung, Rücknahme bei Historienfehlern, geänderte Definitionen und identische Wiederholung geprüft.
- 15 Browserprüfungen mit synthetischen Daten bestanden: Eingabetypen, Suchfehler/Wiederherstellung, gesperrte Eingaben bei unklarer Speicherantwort, zwei identische Speicheraufrufe, Datumsserialisierung, unverfügbare Niederlassung, Neuladen und Zurücksetzen (`work/customer-price-fields-ui-verification.json`). Lokaler Dienst Health UP, Datenbank verbunden, sechs identische Assets. Keine echten Kundendaten verändert. Automatische Formularwerte und Berechnungen bleiben im weiteren Abgleich.

## 19. Oktober 2026 – Uhrzeitgenauer Stichtag für Kurierpreise

- Aktuelle PHP-Funktionen `getJobCosts` und Rechnungsvorbereitung erneut per SSH geprüft. `MASK_CR_PRICE_MODE_DATE` berücksichtigt nun auch eine konfigurierte Uhrzeit. Die Abrechnungsübersicht wechselt entsprechend PHP erst nach dem Stichtag, die Rechnungsvorbereitung und Kundenkalkulation bereits am Stichtag. Ein leerer Stichtag aktiviert den konfigurierten Modus unmittelbar. Ungültige Werte werden nicht durch Abschneiden scheinbar gültig.
- Die aktuelle PHP-Preisfunktion wurde isoliert mit synthetischen Daten ausgeführt: vor/am/nach dem Stichtag 90/90/50. Alle 13 vorhandenen Niederlassungseinstellungen verwenden reine Datumswerte; deren Verhalten bleibt erhalten. Keine echten Geschäftsdaten geändert.
- **1392 Tests: 1389 bestanden, drei übersprungen, keine Fehler** (`work/courier-price-date-verification.json`, 1019 archivierte Dateien). 59 gezielte Prüfungen einschließlich isolierter SQL-Szenarien für Transporteurportal und Rechnungsvorbereitung bestanden. Unverändertes Frontend aus dem zuvor geprüften Build mit 26 erfolgreichen Tests. Lokal Health UP, Datenbank verbunden, sechs identische Assets (`work/courier-price-date-deployment.json`). Weitere Formularsonderfälle bleiben im Abgleich.

## 19. Oktober 2026 – Kundenabrechnung bei offener Zahlungszuordnung

- Aktuelle PHP-Rechnungsübersicht im Browser sowie `invoice/inv_aux.inc.php` (`fab9bf7297e853aa0d4e17fd8f41a0e6b5f1bc12d74786d8204cd5ca2fef80a2`) und `include/services_func.inc.php` erneut vom SSH-Server gelesen. Für Niederlassungen über 1000 beziehen sich die Zahlungspositionen auf den gesamten Auftrag; eine Kostenstellenzuordnung ist darin nicht vorhanden.
- Ein solcher Kostensplit blockiert jetzt nicht mehr die gesamte Kundenübersicht. Berechtigte Kostenstellenpositionen bleiben sichtbar, Beträge und Zahlungsinformationen des Gesamtauftrags bleiben verborgen. Die Anzeige kennzeichnet „Zahlungszuordnung offen“, zählt betroffene Aufträge einmal und nimmt sie aus der klar bezeichneten Summe geklärter Beträge heraus. Auftragsdetails zeigen ausschließlich Stationen der gewählten Kostenstelle. Auch ohne gespeicherte Preise bleibt eine eigene Station sichtbar. Dies ergänzt die sichere Anzeige; eine numerische Zahlungsaufteilung wird nicht erfunden.
- **Vollständige Regression: 1386 Tests, 1383 bestanden, drei übersprungen, keine Fehler** (`work/customer-statement-payments-verification.json`, 1017 archivierte Dateien). Acht gezielte Backendprüfungen und 26 Frontendtests bestanden, Build erfolgreich. Separater SQL-Testdatensatz für Zahlungsniederlassungen, damit bestehende Portalprüfungen unverändert bleiben. Abgedeckt: Rechte, fremde Kostenstellen, Teilbeträge, Rundung, Preisprüfung, fehlende Preise und unveränderte Geschäftsdaten beim Lesen.
- 14 Browserprüfungen mit synthetischen Daten bestanden: Summen, offene Zuordnungen, eigene/untergeordnete Kostenstelle, Detailabgrenzung, Ladefehler ohne alte Zeilen und erfolgreicher Wiederholungsabruf (`work/customer-statement-payments-ui-verification.json`). Ein unvollständiger Sprachdatensatz des Testservers wurde korrigiert. Lokal Health UP, Datenbank verbunden, sechs identische Assets (`work/customer-statement-payments-deployment.json`). Keine echten Geschäftsdaten verändert. Die vollständige Anwendungsparität bleibt im Abgleich.

## 19. Oktober 2026 – Erweiterte Rechnungsvorbereitung für Listenaufträge

- Aktuelle PHP-Listenmaske und `mk_jb_invtext` sowie `checkDiscountStr` per SSH und Browser geprüft. Listenaufträge verwenden jetzt dieselbe vollständige Rechnungsvorbereitung wie Einzelaufträge. Kalkulatorpositionen, Zusatzleistungen, unterschiedliche Rabattsätze, private Kundentexte und strukturierte Exportpositionen werden berücksichtigt. Die bestehende Vorschau mit Bestätigung und Wiederholung nach verlorener Antwort bleibt erhalten.
- Das ungewöhnliche PHP-Ergebnis für gemischte Rabatte wurde mit der frisch vom Server extrahierten Funktion und ausschließlich synthetischen Daten nachvollzogen. Die Vorschau erklärt die Darstellung des ersten Rabattsatzes und des Servicepreises; gespeicherte Preise werden dabei nicht verändert.
- **1385 Tests: 1382 bestanden, drei übersprungen, keine Fehler** (`work/batch-invoice-advanced-verification.json`, 1017 archivierte Dateien). 22 gezielte Prüfungen und 26 Frontendtests bestanden. Eine vom neuen Testszenario veränderte gemeinsame Vorlage wurde isoliert; anschließend 19 betroffene Prüfungen und die vollständige Regression erfolgreich wiederholt.
- Browserprüfung mit synthetischen Daten: sechs Rechnungspositionen, beide Hinweise, Bestätigungszwang, Verwerfen, zwei identische Speicheraufrufe nach verlorener Antwort und unveränderter Auftragspreis (`work/batch-invoice-advanced-ui-verification.json`). Lokal Health UP, Datenbank verbunden, sechs identische Assets (`work/batch-invoice-advanced-deployment.json`). Keine echten Rechnungen, Aufträge oder Exporte geändert. Keine vollständige Anwendungsparität behauptet.

## 19. Oktober 2026 – FTP-Übergabe zentraler Exportdateien

- Frischer SSH-Abgleich mit `export/export.php` (`30b7b10e11d76fc02e7b5103dc67680699604bc66b87022c568406c226ed0c28`), `export/exportdata_ftp.php` (`988fcb43d87666027455fd8f08b5aaf6fe6d745a94692badf5d2a497c63d74fe`), `include/ftp.inc.php` und der aktiven Parameterauflösung in `include/dbglobal.inc.php`. Aktuelle PHP-Exportoberfläche angesehen. Bestehende FTP-Konfiguration nur lesend geprüft, Zugangsdaten nicht ausgegeben; keine echte FTP-Verbindung hergestellt.
- Zentrale Exportdateien können nach Vorschau und ausdrücklicher Bestätigung an den hinterlegten FTP-Empfänger übergeben werden. Eigene Niederlassung, Exportrecht, zusätzliche Umsatzfreigabe, zulässige Endungen sowie Upload-/Listenabschaltung werden geprüft. Bereits übertragene Dateien sind gekennzeichnet. Die externe Dateiliste wird nur auf Anforderung geladen. Übertragen werden die gespeicherten Originalbytes, auch bei verschlüsselten Exportdateien.
- Dauerhafter Vorgang mit temporärer Datei, Inhaltsprüfung und abschließender Umbenennung. Vorhandene Zieldateien werden geprüft und nicht absichtlich überschrieben. Abgebrochene Teilübertragungen können fortgesetzt oder vor der Freigabe verworfen werden. Eine verlorene Antwort führt zu einer Prüfung desselben Vorgangs; wurde die Datei möglicherweise bereits abgeholt, erfolgt kein automatischer Neuversand. Ein vom Empfänger bestätigter Eingang kann gesondert protokolliert werden. Kennzeichnung und Audit werden gemeinsam gespeichert.
- **Vollständige Regression: 1384 Tests, 1381 bestanden, drei übersprungen, keine Fehler** (`work/export-ftp-verification.json`, 1016 archivierte Dateien). Zunächst gefundene zwei fehlende Lesesperren im Transporteur-Rollkarten-Mailablauf behoben; neun gezielte Nachprüfungen und anschließender Gesamtlauf bestanden. Die vorherige gezielte FTP-Prüfung umfasste zehn erfolgreiche Tests. 26 Frontendtests und Build erfolgreich.
- Browserprüfung mit synthetischen Daten: Dateiendungen, Übertragungsstatus, Vorschau/Bestätigung, Fehler der externen Liste, zwei identische Wiederholungsaufrufe nach verlorener Antwort, gesonderte Empfangsbestätigung und Verwerfen (`work/export-ftp-ui-verification.json`). Keine echten Exporte, Nachrichten oder Geschäftsdaten verändert. Lokal Health UP, Datenbank verbunden, sechs identische Assets (`work/export-ftp-deployment.json`). Gesamtparität bleibt im weiteren Abgleich.

## 19. Oktober 2026 – Vorbelegung der Servicezone in der Fahrzeugdisposition

- Aktuelles Server-PHP `admin/vehicle_disposition.php` erneut abgeglichen: `MASK_DISPOSITION_FIRST_ZONE_SELECTED` belegt jetzt sowohl die Fahrzeugliste als auch ungeplante Aufträge mit der ersten Kundenzone vor. „Keine Einschränkung“ wird als ausdrückliche Auswahl `ALL` behandelt und beim Aktualisieren erhalten; Kundentausch und Wiederherstellen der Startauswahl wenden die Vorgabe erneut an.
- **13 gezielte Backendprüfungen und 26 Frontendtests bestanden**, Build erfolgreich, 1013 Dateien archiviert (`work/disposition-first-zone-verification.json`). Ein anfänglicher Testdatenkonflikt (doppelte Auftragsnummer) wurde im isolierten Testdatensatz korrigiert. Grundlage für die vollständige Regression bleibt der Lauf mit 1361 Tests und drei übersprungenen Tests; der nächste Gesamtlauf steht noch aus.
- Browserprüfung: Vorbelegung, Aufhebung, Weitergabe an ungeplante Aufträge, Neuladen, Kundenwechsel und Fehlerbehandlung ohne veraltete Fahrzeugzeilen. Der Hinweis bei aufgehobener Einschränkung lautet „Alle Servicezonen.“ (`work/disposition-first-zone-ui-verification.json`, 71 ausschließlich lesende Anfragen). Lokal Health UP, Datenbank verbunden, sechs identische Assets (`work/disposition-first-zone-deployment.json`). Keine vollständige Parität behauptet.

## 19. Oktober 2026 – Bestätigte Nutzlast-Ausnahme in der Disposition

- Aktuelle PHP-Quellen per SSH geprüft: `admin/vehicle_disposition.php` (`f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`), `include/ajaxReqDisposition.php` und `include/inc_vehicle.inc.php`. PHP führt Gewichtsüberschreitungen nach einem konfigurierten Hinweis weiter. NG erlaubt jetzt negative Rest-Nutzlast bei Erstreservierung, zentraler und transporteurseitiger Mehrtagesumplanung sowie Tagesübertragung; die Überschreitung bleibt immer sichtbar und verlangt eine eigene ausdrückliche Bestätigung. Zeitkollisionen, Rechte, Sperren und veraltete Vorschauen bleiben unabhängig davon wirksam.
- Die Vorschau nennt betroffene Fahrzeuge/Tage und verbleibendes Gewicht. Änderungen setzen die Bestätigung zurück; nach unklarer Speicherantwort bleiben Auswahl und Nutzlastbestätigung für denselben Wiederholungsabruf unverändert. Speicherung, Kapazitäten, Version, Audit und Wiederholungsbeleg bleiben gemeinsam transaktional.
- Die Schreibregression deckte eine durch die Kundentageszeiten eingeführte fehlende Lesesperre im Transporteurablauf auf. Kundenbeziehung und Kundenstamm haben nun eigene, konfliktfreie Sperraliasse; auch Bemerkungen, Übergabe und Umsortierung wurden erneut geprüft. **13 gezielte Prüfungen nach dieser Korrektur bestanden**, 26 Frontendtests und Build erfolgreich, 1012 Dateien archiviert (`work/disposition-capacity-warning-verification.json`). Der vorausgehende Lauf enthielt 100 Tests mit genau diesen zwei anschließend behobenen Sperrfehlern. Vollständige Grundlage bleibt bis zum nächsten Gesamtlauf die Regression mit 1361 Tests/drei übersprungen.
- Browserprüfung mit synthetischen Daten: getrennte Bestätigung, Rücksetzen nach Eingabeänderung, verlorene Antwort mit identischem Wiederholungsabruf in Zentrale und Transporteurportal, sichtbare negative Rest-Nutzlast und separate Tagesübertragung (`work/disposition-capacity-warning-ui-verification.json`). Alle SQL-Schreibprüfungen ausschließlich in der isolierten Testdatenbank. Lokal Health UP, Datenbank verbunden, sechs identische Assets (`work/disposition-capacity-warning-deployment.json`). Keine vollständige Anwendungsparität behauptet.

## 19. Oktober 2026 – Kundenspezifischer Zeitraum der Dispositionszeitleiste

- Frischer SSH-Abgleich mit `admin/vehicle_disposition.php` (SHA-256 `f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`), insbesondere Kundentageszeiten ab 300, Offsets ab 312 und inklusive Stundenobergrenze ab 608/916. Aktuelle PHP-Oberfläche erneut angesehen; die Sitzung bietet weiterhin keine ausgewählten Kunden/Fahrzeuge. Bestandsprüfung ausschließlich lesend: keine kundenbezogenen `day_time`-Definitionen vorhanden.
- Zentrale und Transporteurportal verwenden nun Kundentageszeiten, globale letzte Stunde und ganzzahlige Start-/Endverschiebung der Anmeldeniederlassung. Die letzte PHP-Stunde wird vollständig angezeigt. Für den Transporteur gilt der erste berechtigte Kunde seiner eigenen Fahrzeugzuordnungen. Fehlende, doppelte oder ungültige Tageszeiten führen zum vollständigen konfigurierten Tag, bei ungültigen Vorgaben mit Hinweis. „Gesamten Tag anzeigen“ erschließt unabhängig davon alle 24 Stunden; Auswahl und Vergrößerung bleiben beim Aktualisieren erhalten, ein Kunden-/Niederlassungswechsel übernimmt wieder die Vorgabe.
- Angezeigte Segmente werden an den Fenstergrenzen abgeschnitten; gespeicherte Belegung und sämtliche Planungsprüfungen behalten den vollen Tag. Das Ziehen einer abgeschnittenen Karte berücksichtigt deren unsichtbaren Anfang. Fremde Belegungen außerhalb des Fensters verhindern weiterhin die Bearbeitung des Fahrzeugtags. Kunden- und Fahrzeugrechte werden erneut geprüft; der Kundenfilter wird an die Zeitleistenanfrage übergeben.
- **20 gezielte Backendprüfungen bestanden**, keine Fehler/Überspringungen; **26 Frontendtests bestanden**, Build erfolgreich, **1009 Dateien archiviert** (`work/disposition-working-range-verification.json`). Grundlage bleibt der vollständige Lauf mit 1361 Tests/drei übersprungen; kein neuer vollständiger Lauf behauptet. Browserprüfung mit synthetischen Daten: 10–19 bzw. 8–19 Uhr, ganzer Tag, Vergrößerung und Aktualisierung, Kundenwechsel sowie echtes Ziehen der abgeschnittenen 08-Uhr-Reservierung mit korrektem neuem Beginn 11:00 (`work/disposition-working-range-ui-verification.json`). Ein beim Browsercheck gefundener Rücksetzfehler in der zentralen Volltagsauswahl wurde korrigiert und erneut geprüft. Ausschließlich GET-Anfragen, keine echten Geschäftsdaten verändert.
- Lokaler Dienst Health UP, Datenbank verbunden, sechs identische Assets (`work/disposition-working-range-deployment.json`). Screenshot `work/disposition-kundenzeitraum-2026-10-19.png`. Die Nutzlast-Ausnahme und weitere konfigurierte Sonderfälle werden weiter abgeglichen; keine vollständige Anwendungsparität behauptet.

## 19. Oktober 2026 – Datumsübernahme, Firmennamen und Ziehen auf vergangene Uhrzeiten

- Aktuelles `admin/vehicle_disposition.php` erneut per SSH geprüft (`f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`): Kalenderhandler ab 2398, Datumsparameter 1190, Zeitregel 961 und Firmenfeld 508. Datumskalender in der aktuellen PHP-Oberfläche geöffnet und geschlossen; kein Geschäftsdatensatz geändert.
- `MASK_DISPOSITION_CALENDER_SUBMIT_DISABLED`: wahlweise sofortiger Tageswechsel oder zunächst vorgemerktes Datum mit „Datum übernehmen“, in Zentrale und Transporteurportal. Der tatsächlich angezeigte Tag bleibt bis zur Übernahme sichtbar; „Heute“ springt direkt. Niederlassungswechsel übernimmt deren Vorgabe. `MASK_DISPOSITION_CMP_FIELD_DISPLAYED` wählt in der zentralen Kundenliste und Gruppenliste den ersten bis vierten Firmennamen; die Kundennummer bleibt zusätzlich sichtbar. Sortierung nach gewähltem Namen; wie im PHP gilt dafür die ursprüngliche Anmeldeniederlassung. Nur die tatsächlich vorhandenen Spalten sind zulässig, keine freien SQL-Ausdrücke.
- Beim Ziehen in der Zentrale sind am heutigen Tag grundsätzlich nur aktuelle/spätere Uhrzeiten zulässig; `MASK_DISPOSITION_TIMELINE_ENABLE_DROPPING_ON_PAST_TIMESLOTS` erlaubt die vorhandene Ausnahme. Maßgeblich ist die geladene Datenbankzeit zuzüglich verstrichener Zeit, unabhängig von Browseruhr/Zeitzone. Die abweichende Transporteurregel und die separat aufrufbare manuelle Planung bleiben unverändert. Globale Rückfallwerte, explizite Null, Mitarbeiterparameter-Ausnahme, Fremdniederlassung und Mehrdeutigkeit geprüft.
- **13 gezielte Backendprüfungen bestanden** (sieben isolierte SQL-Prüfungen einschließlich bestehender Karten, Rechte, Niederlassungen und Startauswahl sowie sechs Architekturprüfungen), **21 Frontendtests bestanden**, Build erfolgreich; 1002 Dateien archiviert (`work/disposition-timeline-options-verification.json`). Vorherige vollständige Grundlage: 1361 Tests, davon drei übersprungen; kein neuer vollständiger Lauf behauptet. Browser: vorgemerktes Datum ohne Zusatzabruf, Übernahme, direkter Modus und Heute-Sprung; echtes Ziehen 09:00 bei simulierter Serverzeit 12:00 abgewiesen, 13:00 angenommen, 09:00 mit konfigurierter Ausnahme angenommen. Entwürfe verworfen, ausschließlich GET-Anfragen (`work/disposition-timeline-options-ui-verification.json`).
- Lokaler Dienst Health UP, Datenbank verbunden und sechs identische Assets (`work/disposition-timeline-options-deployment.json`). Reale Einstellungen ausschließlich gelesen; im Bestand unter den sechs betrachteten Anzeigeparametern nur global `DISPOSITION_HOURS=23` vorhanden. Sichtbarer Stundenbereich nach Kundentageszeiten/Offsets folgt als weiterer Abgleich; keine vollständige Parität behauptet.

## 19. Oktober 2026 – Dispositionskarten, Zieladressen und Anzeigeoptionen

- Erneuter SSH-Abgleich mit `admin/vehicle_disposition.php` (`f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`), `include/inc_vehicle.inc.php` (`e34830c44c742c28f658e693256e0658920d0f383b9a030a188c76af7ac7b086`) und `include/inc_job.inc.php` (`0b660ceef70176f64314cf74809fa681eac06553c534473a4690d0edf941e0c6`). Aktuelle PHP-Maske einschließlich Datumskalender angesehen; die vorhandene Sitzung zeigt weiterhin keine ausgefüllten Fahrzeuge.
- Drei konfigurierte Kartenansichten für die zentrale und die Transporteur-Disposition: Zeit-/Preisdaten, Gebietsangaben oder Empfänger mit Anschrift, Zeitfenster, Gewicht und Packstücken. Bruttobetrag mit Auftragssteuersatz, Gewichte ohne Mengenvervielfachung und PHP-spezifische Dezimalstellen. Optionale senkrechte Auftragsnummer und PLZ, Kunden-/Servicefarben und lesbare Textfarbe. Der Transporteur verwendet den ersten eigenen zugeordneten Kunden gemäß PHP-Reihenfolge; fremde Mandanten bleiben ausgeschlossen. HTML-ähnlicher Inhalt wird ausschließlich als Text dargestellt.
- Zieladresse mit Etage/Telefon im Transporteurdialog, lesendes Detail bei schreibgeschützten zentralen Karten und Auftragsinformationen vor der Erstreservierung. Aufträge ohne Rasterreservierung bleiben mit eigenem Rahmen getrennt sichtbar. Die Stundenbeschriftung kann per vorhandener Vorgabe ausgeblendet werden, ohne Breite, Zeitpositionen oder das 24-Stunden-Raster zu ändern.
- Karten werden nur für die aktuell autorisierten Fahrzeug-/Tages- oder Listenaufträge geladen. Beschränkter FDS-Zugang, ausgewählte Niederlassung, Transporteurkonto und Tagesfreigabe werden erneut geprüft. Fehlgeschlagene Abrufe entfernen veraltete Kartendetails; entzogene Freigabe blendet die Belegung aus. Mehrdeutige Stations-/Zusatzdaten und ungeeignete Farbkonfigurationen werden abgewiesen. Bestehende Konfigurationswerte wurden ausschließlich lesend abgefragt; die sechs Karten-/Farbvorgaben sind im Bestand nicht gesetzt.
- **89 gezielte Backendprüfungen bestanden, keine Fehler oder Überspringungen**; 18 Frontendtests und Build erfolgreich, 996 Dateien archiviert (`work/disposition-job-cards-verification.json`). Grundlage ist der unmittelbar zuvor bestandene vollständige Lauf mit **1361 Tests, drei übersprungen**; für diese lesende Ergänzung wird kein neuer vollständiger Lauf behauptet. Browserprüfung aller drei Modi, Adressdialoge, Fehler/Wiederholung, entzogener Freigabe, abgesetzter Karte und unveränderter Rasterbreite: `work/disposition-job-cards-ui-verification.json`. Alle Browseraufrufe lesend; SQL-Schreibprüfungen nur in der isolierten Testdatenbank.
- Lokal Health UP, Datenbank verbunden und sechs identische Assets (`work/disposition-job-cards-deployment.json`). Weitere Datums-/Anzeigeoptionen und die verbleibenden fachlichen Sonderfälle bleiben im Abgleich. Keine vollständige Anwendungsparität behauptet.

## 19. Oktober 2026 – Grafische Mehrtagesumplanung im Transporteurportal

- Frischer SSH-Abgleich mit `admin/vehicle_disposition.php` (`f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`), `include/ajaxReqDisposition.php` (`80d00e71eabbeac4154d5b5724fd0d81410874abbef12bf0a69aa0aca04fbea0`) und `include/inc_vehicle.inc.php` (`e34830c44c742c28f658e693256e0658920d0f383b9a030a188c76af7ac7b086`). Aktuelle PHP-Fahrzeugansicht geprüft; die dortige leere Fahrzeugauswahl erlaubt keinen ausgefüllten Transporteurdialog als Bildvergleich.
- Reservierungen im Transporteurportal lassen sich auf eine neue Uhrzeit oder ein freigegebenes Fahrzeug ziehen; „Umplanen“ bietet dieselbe Funktion ohne Ziehen. Wie im PHP beginnt die Verschiebung am ersten Reservierungstag. Vorschau über alle bisherigen und neuen Kalendertage, Rasterrundung, Tagesmaximum, Folgetagbeginn, Artikelgewicht und Rest-Nutzlast. Kundeneinsatzzeiten, verknüpfte Liefer-/Montageaufträge und gespeicherte Warnvorgaben werden geprüft.
- Tatsächliches Transporteurkonto, freigegebene Quell-/Zieltage und persönlich zugängliche Aufträge; keine künstlichen Mitarbeiterrechte. Fremdbelegungen, Kollisionen, Sperren, fehlende Raster, entzogene Freigaben, geschützte Aufträge und parallele Änderungen verhindern die Speicherung. Umplanung, freie Kundenzeitfenster, Nutzlast, Auftragszeit, Version, Audit und Wiederholungsbeleg werden atomar geschrieben. Auftragstage bleiben zusammenhängend; Kurierzuordnung, Auftragsdauer und Preise unverändert. Identischer Ergebnisabruf nach verlorener Antwort hat keine doppelte Wirkung.
- **1361 Tests: 1358 bestanden, drei übersprungen, keine Fehler**; 90 gezielte Backendprüfungen, 18 Frontendtests und Build erfolgreich. 991 Dateien archiviert (`work/courier-disposition-replanning-verification.json`). Browserprüfung mit synthetischen Daten: echtes Ziehen, eigener Verwerfendialog, dreitägige Vorschau, Bestätigung, verlorene Speicherantwort, identischer Wiederholungsabruf und aktualisierte Belegung (`work/courier-disposition-replanning-ui-verification.json`). Screenshots `transporteur-mehrtagesplanung-2026-10-19.png` und `transporteur-mehrtagesplanung-ergebnis-2026-10-19.png`. Lokaler Dienst und identische Assets geprüft (`work/courier-disposition-replanning-deployment.json`). Alle Schreibtests ausschließlich in der isolierten Datenbank.
- Bekannte fachliche Abweichung: Negative Rest-Nutzlast wird wie in der vorhandenen zentralen NG-Planung abgewiesen; PHP kann diesen Fall nach Warnung weiterführen. Konfigurierbare Dispositionskarten werden anschließend ergänzt. Keine vollständige Anwendungsparität behauptet.

## 19. Oktober 2026 – Tagesübergreifende Transporteur-Auftragssuche

- Frischer Serverabgleich: `admin/vehicle_disposition.php` (`f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`, Suchfeld Zeile 552, Verarbeitung ab 172) und `include/inc_job.inc.php` (`0b660ceef70176f64314cf74809fa681eac06553c534473a4690d0edf941e0c6`, `searchJobs`). Das aktuelle Suchfeld wurde in der alten PHP-Fahrzeugansicht angesehen. Service-, Kunden- und Zonenfilter sind dort ausdrücklich zentralenseitig; sie werden nicht irrtümlich als Transporteur-Lücke behandelt.
- Fahrzeugbelegung im Transporteurportal → „Auftrag suchen“: exakte Auftragsnummer, Kommissionsnummer, `jb_search` und `info_0`; im Betrieb mit zugeordneten Kunden auch Grund-/Folgeaufträge über `/1` und `/2`. Classic-Zahlen suchen ausschließlich die interne Auftragsnummer. Tagesübergreifende Treffer mit Plantermin, Status, Fahrzeugkennung und freigegebenem Fahrzeugtag; identische Stations-/Zusatzfeldtreffer erzeugen keine Doppelzeilen. Serverseiten mit jeweils 50 Fahrzeugtag-Treffern.
- Direktsprung zum ausgewählten Fahrzeugtag, farbliche Markierung des Auftrags und Rückkehr zu allen freigegebenen Fahrzeugen. Auswahl wird erneut vom Server geprüft; entzogene Tagesfreigabe blendet die Belegung aus. Reservierte Mehrtagesaufträge sowie angenommene/erledigte Aufträge ohne Rasterreservierung folgen dem vorhandenen persönlichen Dispositionsumfang. Keine Fremdauftrags-, Eltern-, Preis- oder Zugangsdaten im Ergebnis. Alle Such-/Navigationsaufrufe sind lesend.
- **1360 Tests: 1357 bestanden, drei übersprungen, keine Fehler**; 83 gezielte Backendtests, 18 Frontendtests und Build erfolgreich. 989 Dateien geprüft und archiviert (`work/courier-disposition-search-verification.json`). Isolierte SQL-Prüfungen für Rechte, Betriebsmodi, exakte Kennungen, Mehrtagesbelegung, Dubletten, fremde Mandanten, Sperr-/Freigabewechsel, 61 Treffer mit Serverblättern und unveränderte Daten. Browserprüfung für leere Treffer, Fehlerbehebung, Tagesnavigation, Markierung und entzogene Freigabe: `work/courier-disposition-search-ui-verification.json`; Screenshots `transporteur-auftragssuche-2026-10-19.png` und `transporteur-suchtreffer-2026-10-19.png`. Lokaler Dienst und identische Assets geprüft (`work/courier-disposition-search-deployment.json`). Keine realen Datenänderungen.
- Grafische Umplanung im Transporteurportal wird anschließend ergänzt. Archivdaten, fehlende Classic-Sammelfunktion und die im PHP gesperrte Transporteur-Karte bleiben ausdrücklich Referenzgrenzen; keine vollständige Parität behauptet.


## 19. Oktober 2026 – Transporteur-Sortierung und Service-Rollkarten

- Frischer SSH-Abgleich mit `admin/vehicle_disposition.php` (`f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`), `include/inc_vehicle.inc.php` und `admin/pdf_generic_function.php` (`6fb82a6caf9e3c2169c1d219b95e984b569bedbd9159244508db189d01cc1469`). Die aktuelle alte Fahrzeugansicht wurde erneut angesehen. Im angemeldeten PHP-Zugang sind weiterhin keine Fahrzeuge ausgewählt; ausgefüllte Transporteurdialoge konnten dort nicht visuell geprüft werden.
- Transporteurportal → Fahrzeugbelegung → „Reihenfolge“: vollständige Tagesreihenfolge mit Pfeilen, Startzeiten, Rasterrundung, Vorschau der durch nachfolgende Starts begrenzten Reservierungen, ausdrücklicher Bestätigung und Aktualisierung der Belegung. Auftragsdauer, Preise, Kurierzuordnung und Restkapazität bleiben erhalten. Kundenbezogene freie Zeitfenster werden aus den neuen Reservierungen neu aufgebaut. Verknüpfte Liefer-/Montageaufträge samt Warnparametern werden geprüft.
- Freigegebener Fahrzeugtag, aktuelles Konto und tatsächlich zugängliche Aufträge werden bei Vorschau und Speicherung geprüft; keine künstlichen Mitarbeiterrechte. Unbekannte Belegungen, mehrtägige/mehrfahrzeugige Reservierungen, angenommene/abgerechnete/exportierte/gesperrte Aufträge und widersprüchliche Zeitfenster verhindern diese eintägige Sortierung. Revision, Audit und Vorgangsbeleg werden gemeinsam gespeichert. Identische Wiederholung nach verlorener Antwort erzeugt keine zweite Änderung. Eigener Entwurfsschutz ohne nativen Browserdialog.
- Konfigurierte Service-Rollkarte `getServiceCartageNote` für Zentrale und Transporteur: Servicestelle, Lagerbezeichnung aus der Seriennummer, Zusatzbezeichnung, kritische Komponenten einschließlich H02/H05/H10-Abbildung, Komponentenwerte oder `[TEXT]`-Freitext, Servicearten/Austausch/Wartung und Technikernotizen. HTML, PDF und Versandvorschau verwenden denselben Inhalt. Fremdmandanten-Lager bleiben ausgeschlossen, mehrdeutige Zuordnungen werden abgewiesen. Preis-/Kassen-/Unterschriftsbereiche sind in dieser PHP-Vorlage auskommentiert und werden nicht ergänzt. Im aktuellen Bestand ist kein spezielles Rollkartenformat konfiguriert; dessen Darstellung wurde deshalb mit isolierten Beispieldaten geprüft.
- **1359 Tests: 1356 bestanden, drei übersprungen, keine Fehler**; 98 gezielte Backendprüfungen, 18 Frontendtests und Build erfolgreich. 986 Dateien geprüft und archiviert (`work/courier-disposition-planning-verification.json`). Browsernachweise: `work/courier-disposition-planning-ui-verification.json` und `work/vehicle-service-rollcards-ui-verification.json`; Screenshots `transporteur-sortierung-2026-10-19.png`, `service-rollkarte-2026-10-19.png`, `service-rollkarte-details-2026-10-19.png`. Lokaler Dienst mit Health UP, verbundener Datenbank und identischen Assets geprüft (`work/courier-disposition-planning-deployment.json`). Alle Schreibprüfungen ausschließlich in der isolierten Datenbank; keine echten Aufträge oder E-Mails ausgelöst.
- Auftragssuche und grafische Mehrtagesumplanung im Transporteurportal bleiben im laufenden Abgleich. Keine vollständige Anwendungsparität behauptet.


## 19. Oktober 2026 – Transporteur: Rollkartenversand, Übergabe und Rückholung

- Erneuter SSH-Abgleich mit `admin/vehicle_disposition.php` (`f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`), `include/ajaxReqDisposition.php` (`80d00e71eabbeac4154d5b5724fd0d81410874abbef12bf0a69aa0aca04fbea0`), `include/inc_vehicle.inc.php` (`e34830c44c742c28f658e693256e0658920d0f383b9a030a188c76af7ac7b086`) und `admin/pdf_generic_function.php`. Die angemeldete alte Fahrzeugansicht wurde frisch geladen; weiterhin keine Fahrzeuge in der aktuellen Auswahl, daher keine ausgefüllten alten Aktionsdialoge visuell verfügbar.
- Rollkartenmail im Transporteurportal aus der freigegebenen Rollkarte: Kundenempfänger, Absender/Cc/Bcc, PDF-Vorschau, ausdrückliche Prüfung und Versandhistorie. Die vorhandene Versandlogik wird mit dem tatsächlichen Kurierzugang wiederverwendet; keine künstlichen Mitarbeiterrechte. Tagesfreigabe, Kontozuordnung, Dokument und Empfänger werden vor Versand erneut geprüft. Dauerhafter Versandbeleg vor SMTP; unsichere Versandantworten führen nicht zu einem automatischen zweiten Versand.
- Einzelübergabe reservierter Aufträge, gemeinsame Rollkartenübergabe im konfigurierten FDS-Modus und Rückholung angenommener Aufträge. Vorschau mit Status- und Kurieränderungen, Bestätigung, Revisionsprüfung und wiederholbarer Vorgangskennung. Nach erfolgreichem Schließen aktualisiert sich die Übersicht; nicht mehr persönlich freigegebene Aufträge sind nur noch anonyme Belegungen. Reservierungen und Preise bleiben erhalten. Mehrtägige Zuweisungsänderungen prüfen alle betroffenen Tagesfreigaben. Es wird kein zusätzlicher Gerätebefehl erfunden.
- Der aktuelle PHP-Menüzweig bietet Einzelversand bei Status 0 an, die tatsächliche Schreibfunktion akzeptiert aber nur Status 9. NG folgt der Schreibregel und erläutert die Sperre. Die Classic-Sammelübergabe verweist auf die im aktuellen Serverbestand fehlende Funktion `copy_jobs_cartage` und bleibt entsprechend gesperrt. Ebenfalls unverändert: Der alte Transporteur-Menüpunkt „Standort auf der Karte“ führt zu einer Seite, die Benutzertyp 3 ausdrücklich ausschließt; daraus werden keine neuen GPS-Zugriffsrechte abgeleitet.
- **1357 Tests: 1354 bestanden, drei übersprungen, keine Fehler**; 88 gezielte Backendprüfungen, 18 Frontendtests und Build erfolgreich. 981 Dateien geprüft und archiviert (`work/courier-disposition-actions-verification.json`). Browserprüfungen für Mailvorschau, Bestätigungen, verlorene Antworten, identische Wiederholung, Einzelübergabe, Rückholung, Aktualisierung und gesperrte Sammelübergabe: `work/courier-disposition-rollcard-mail-ui-verification.json` und `work/courier-disposition-handover-ui-verification.json`. Screenshots: `transporteur-rollkartenversand-2026-10-19.png` und `transporteur-uebergabe-2026-10-19.png`. Lokaler Dienst auf Port 8080 mit Health UP, verbundener Datenbank und identischen Assets geprüft (`work/courier-disposition-actions-deployment.json`). Keine echten Aufträge geändert und keine echten Mails verschickt; SQL-Schreibprüfungen ausschließlich in der isolierten Datenbank.
- Umsortierung und weitere Teilfunktionen bleiben im laufenden Serverabgleich. Keine vollständige Anwendungsparität behauptet.

## 19. Oktober 2026 – Rollkarten im Transporteurportal

- Frischer Abgleich mit `admin/pdf_generic_function.php` (`6fb82a6caf9e3c2169c1d219b95e984b569bedbd9159244508db189d01cc1469`) und dem Transporteurmenü in `admin/vehicle_disposition.php`. Die geöffnete PHP-Fahrzeugansicht enthält in der aktuellen Auswahl keine Fahrzeuge; die Transporteuraktionen sind zusätzlich anhand des aktuellen Serverzweigs belegt.
- Standardrollkarte direkt je freigegebenem Fahrzeugtag, wahlweise reservierte, angenommene oder beide Auftragsarten. Gemeinsame Dokumentausgabe mit der Zentralenansicht: Abhol-/Zielanschrift, Artikel der zweiten Station, Packstücke, Zusatzangaben, Zeitfenster, Service und offener Inkassobetrag gemäß PHP mit Faktor 1,19. Fremde Aufträge und fremde Hauptauftragsreferenzen bleiben ausgeschlossen.
- HTML-Vorschau und -Download, PDF-Download und Browserdruck. Der PDF-Abruf prüft Rechte, Tagesfreigabe und Revision erneut. Zwischenzeitliche Änderungen entfernen die veraltete Vorschau; fehlgeschlagene Abrufe lassen sich wiederholen. Der Auftragsdialog wurde für seine Artikelspalten verbreitert. Konfigurierte besondere PHP-Druckformate werden weiterhin ausdrücklich als noch nicht übernommene Sonderformate angezeigt.
- **1355 Tests: 1352 bestanden, drei übersprungen, keine Fehler**; 85 gezielte Backendprüfungen inklusive bestehender Zentralenrollkarte und PDF-Ausgabe, 18 Frontendtests und Build erfolgreich. 976 Dateien archiviert (`work/courier-disposition-rollcard-verification.json`). Browser: alle drei Auswahlen, Abruffehler, Revisionskonflikt, Wiederholung und PDF-Aufruf (`work/courier-disposition-rollcard-ui-verification.json`, `work/transporteur-rollkarte-2026-10-19.png`). Lokal Health UP, Datenbank verbunden und sechs identische Assets (`work/courier-disposition-rollcard-deployment.json`). Ausschließlich synthetische Dokumente, keine echten Geschäftsdaten geändert.
- Beim weiteren PHP-Abgleich gefunden: Das Transporteurmenü bietet Einzelversand für Status 0 an, während `sendSingleJob` nur Status 9 annimmt. Die Classic-Sammelübergabe ruft `copy_jobs_cartage` auf, für das im aktuellen Serverbestand keine Definition gefunden wurde. Diese Widersprüche sind Referenzfehler; Mailversand, zulässige Übergabe-/Rückrufaktionen und Umsortierung werden separat weiterbearbeitet.

## 19. Oktober 2026 – Artikel und Zielbemerkung in der Transporteur-Disposition

- Aktuelle Serverquellen `include/ajaxReqDisposition.php` (`80d00e71eabbeac4154d5b5724fd0d81410874abbef12bf0a69aa0aca04fbea0`), `include/inc_job.inc.php` (`0b660ceef70176f64314cf74809fa681eac06553c534473a4690d0edf941e0c6`) und der Transporteurzweig der aktuellen Fahrzeugmaske abgeglichen. Auftragsaufruf über Zeitleiste und Liste; konfigurierbare Artikelspalten, Zusatzangaben sowie unvervielfachte PHP-Summen für Warenwert, Gewicht und Packstücke.
- Die Bemerkung der zweiten Station ist bei zulässigem Auftragsstatus bearbeitbar. Erledigte, fakturierte, exportierte oder aktuell gesperrte Aufträge bleiben schreibgeschützt. Fahrzeug, Tag, Kontofreigabe und Auftragszuordnung werden beim Speichern erneut geprüft. Versionsvergleich, Audit, atomare Speicherung und Wiederholungskennung verhindern verlorene Änderungen oder doppelte Wirkung nach Verbindungsabbruch.
- **1354 Tests: 1351 bestanden, drei übersprungen, keine Fehler**; 82 gezielte Backendprüfungen, 18 Frontendtests und Build erfolgreich. 973 Quelldateien archiviert (`work/courier-disposition-job-verification.json`). Browser mit synthetischen Daten: Artikel/Summen, eigener Verwerfendialog, verlorene Speicherbestätigung und identische Wiederholung mit genau einer Änderung, Wiederaufruf und erledigter Auftrag (`work/courier-disposition-job-ui-verification.json`, `work/transporteur-artikel-zielbemerkung-2026-10-18.png`). Lokal Health UP, DB verbunden und sechs identische Assets (`work/courier-disposition-job-deployment.json`). Keine echten Geschäftsdaten geändert.
- Referenzfehler abgegrenzt: Das PHP-Transporteurmenü bietet eine Karte an; `locating/map.php` (`c977597722131caf586ce62f72eb0fa35f498618a813b74794210d84a58a2b86`) verweigert Kontotyp 3 ausdrücklich. Daraus wird keine zusätzliche GPS-Berechtigung abgeleitet. Offen sind insbesondere Rollkartenaktionen, Übergabe/Rückruf und Umsortierung im Transporteurportal; keine vollständige Parität behauptet.

## 18. Oktober 2026 – Fahrzeugbelegung im Transporteurportal

- Aktuelle PHP-Ansicht geöffnet; `admin/vehicle_disposition.php` (`f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`) und `include/inc_vehicle.inc.php` (`e34830c44c742c28f658e693256e0658920d0f383b9a030a188c76af7ac7b086`) frisch vom Server abgeglichen. Die Sitzung der alten Oberfläche ist ein Zentralenzugang ohne Fahrzeuge in der aktuellen Auswahl; die zusätzlichen Transporteurregeln sind direkt aus dem aktuellen PHP-Zweig abgeleitet. Drei Konten mit `cr_disposition=1` im Bestand ausschließlich lesend gezählt.
- Neuer eigener Zugang für Transporteurkonten mit Dispositionsfreigabe. Angezeigt werden über Fahrzeugkennung zugeordnete Unterfahrer im eigenen Mandanten, gültige Fahrzeuge und ausdrücklich freigegebene Fahrzeugtage. Keine Mitarbeiterrechte oder Niederlassungsumschaltung. Fremde Aufträge bleiben als anonyme Belegung sichtbar. Globaler Modus und gespeicherte Sichtbarkeitsmarkierung werden berücksichtigt.
- Tageswechsel, Vergrößerung 1–9, 25 Fahrzeuge je Seite, Restkapazität, Status und Tagesbemerkung. Angenommene und erledigte Aufträge erscheinen auch ohne Rasterreservierung; ihre unterschiedlichen PHP-Fahrzeugzuordnungen werden berücksichtigt. Mehrtägige reservierte Aufträge bleiben am jeweiligen Tag sichtbar. Entzogene Freigaben werden bei jedem Abruf erneut geprüft.
- **1353 Tests: 1350 bestanden, drei übersprungen, keine Fehler**; 80 API-Prüfungen und erweiterte SQL-Prüfung, 18 Frontendtests und Build erfolgreich. Eine Testannahme zu einem gleichzeitig anders reservierten angenommenen Auftrag wurde durch einen ausdrücklichen Vortagsfall ersetzt; anschließende SQL-Prüfung erfolgreich. 970 Dateien archiviert (`work/courier-disposition-verification.json`).
- Browser mit synthetischen Daten: Einstieg, unbekannte Belegung, beide Auftragsarten ohne Reservierung, Verbindungsfehler/Wiederholung, erhaltene Vergrößerung und leerer nicht freigegebener Tag (`work/courier-disposition-ui-verification.json`, `work/transporteur-fahrzeugbelegung-2026-10-18.png`). Alle Anfragen ausschließlich lesend. Lokal Health UP, DB verbunden und sechs identische Assets (`work/courier-disposition-deployment.json`).
- Diese Ergänzung schließt die lesende Fahrzeugansicht. Weitere Transporteuraktionen aus dem PHP-Menü – Auftragsdialog, Bemerkung, Karte, Rollkarte, Übergabe/Rückruf und Umsortierung – bleiben gesondert umzusetzen; keine vollständige Dispositionsparität behauptet.

## 18. Oktober 2026 – Vergrößerung der FDS-Zeitleisten

- Aktuelle PHP-Maske und `admin/vehicle_disposition.php` (`f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`) abgeglichen. Die Zeitleiste bietet die PHP-Stufen 1 bis 9. `MASK_DISPOSITION_SCALING_FACTOR_DEFAULT` wird zunächst aus der Niederlassung und nur bei leerem Wert global gelesen; ungültige Werte verwenden Stufe 2.
- Die gewählte Vergrößerung bleibt beim Aktualisieren erhalten. Ein Niederlassungswechsel übernimmt deren Vorgabe, die Rücksetzschaltfläche stellt sie wieder her. Verschieben und Tastaturbedienung verwenden weiterhin die tatsächliche Zeitposition.
- **1352 Tests: 1349 bestanden, drei übersprungen, keine Fehler**, gezielte SQL-Prüfung, 18 Frontendtests und Build erfolgreich; 967 Dateien archiviert (`work/fds-timeline-scale-verification.json`). Browser: Stufen 1/3/4/9, Aktualisierung, Niederlassungswechsel sowie Planungsdialog nach Tastatur-/Ziehaktion (`work/fds-timeline-scale-ui-verification.json`, `work/fds-zeitleisten-vergroesserung-2026-10-18.png`). Keine synthetische Planung gespeichert.
- Lokal Health UP, Datenbank verbunden und sechs identische Assets (`work/fds-timeline-scale-deployment.json`). Der Bestandsabruf der fünf FDS-Anzeigeparameter war ausschließlich lesend; keine echten Geschäftsdaten geändert.

## 18. Oktober 2026 – Seitensummen der Auftragslisten

- Aktuelle PHP-Liste und frische Serverquellen `admin/jb_list.php` (`db040a7b070773da74dfbbdf3e46f3ecc55564f516f34f81dd880826221e80fc`) sowie `include/jb_list_defineoutput.inc.php` (`9c8087e29853641fca21fee5b76b0abbebad6231cb830e91a0c6f6bf3aab8a0a`) abgeglichen. Einzel- und persönliche Listen zeigen Kundenpreis, Frachtvergütung und BSG für den tatsächlich geladenen Seitenausschnitt. Summen verwenden ungerundete Beträge; BSG wird aus den Gesamtbeträgen berechnet.
- Normale Listen zählen Unteraufträge nicht doppelt; Gutschriften werden mit ihrem Vorzeichen berücksichtigt. Im Modus verbundener Kunden wird einschließlich Unteraufträgen nur der Bruttokundenbetrag summiert. Ausgeblendete Preisspalten liefern keine erfundenen Nullsummen. Kein zusätzlicher Datenbankabruf und kein Summenfuß im CSV.
- **1352 Tests: 1349 bestanden, drei übersprungen, keine Fehler**, elf gezielte Backendprüfungen, 18 Frontendtests und Build erfolgreich; 967 Dateien archiviert (`work/order-list-totals-verification.json`). Der SQL-Test berücksichtigt ausdrücklich, dass offene Unteraufträge bereits durch die bestehende Listenauswahl fehlen, erledigte dagegen sichtbar sein können.
- Browser: Einzel-/Mehrfachliste, Bruttomodus, ausgeblendete Beträge und Seitenausschnitt (`work/order-list-totals-ui-verification.json`, `work/auftragsliste-seitensummen-2026-10-18.png`). Die alte PHP-Maske wurde geöffnet, hatte für den gewählten Zeitraum aber keine Datenzeilen; die Summenregel ist zusätzlich anhand des aktuellen Quellcodes belegt. Lokal Health UP, Datenbank verbunden und sechs identische Assets (`work/order-list-totals-deployment.json`). Keine echten Geschäftsdaten geändert.

## 18. Oktober 2026 – Kundendokumente in Auftragslisten

- Aktuelle PHP-Liste und die frischen Serverquellen `admin/jb_list.php`, `include/jb_list_defineoutput.inc.php` (`9c8087e29853641fca21fee5b76b0abbebad6231cb830e91a0c6f6bf3aab8a0a`) sowie `include/inc_file.inc.php` (`47307d7a2a1b0c26635431d366400d4a9a70de6f891a794144b13b0e411192f1`) abgeglichen. Der tatsächlich gesetzte globale Schalter `MASK_JOBLIST_CHECK_NUM_OF_CS_DOCS` steuert nun die Links in Einzel- und persönlichen Listen. Ohne Schalter bleiben lokale Kundendokumente direkt erreichbar.
- Eine gebündelte Leseanfrage prüft eindeutige Kunden der aktuellen Seite. Pro Ablage werden nur einmal Dateinamen gelesen, keine Dokumentinhalte. Fremde/entzogene Kunden bleiben verborgen, Rechte und Zuordnung werden nach dem Dateizugriff erneut geprüft. Ähnliche Nummernpräfixe, versteckte Dateien und Verzeichnisse zählen nicht als Dokument. Ausfälle werden als Fehler mit Wiederholung angezeigt und nicht als leere Ablage ausgegeben. Veraltete Antworten werden verworfen.
- **1347 Tests: 1344 bestanden, drei übersprungen, keine Fehler**, 93 gezielte Backendprüfungen nach Korrektur einer Fehlertexterwartung, 18 Frontendtests und Build erfolgreich; 964 Dateien archiviert (`work/order-list-documents-verification.json`). Ein erster langer Gesamtlauf scheiterte an einer abgelaufenen bestehenden Mailvorschau; isolierte Wiederholung und anschließender kompletter Lauf bestanden (`work/order-list-documents-mail-recheck.log`, `work/order-list-documents-verify.log`).
- Browser: Fehler/Wiederholung, vorhandene/leere/fremde Ablagen, gemeinsame Prüfung wiederholter Kunden, korrekter Kundendialog sowie ausgeschaltete Bestandsprüfung (`work/order-list-documents-ui-verification.json`, `work/auftragsliste-kundendokumente-2026-10-18.png`). Lokal Health UP und sechs identische Assets (`work/order-list-documents-deployment.json`). Keine echten Dateien oder Geschäftsdaten geändert. Der ebenfalls gesetzte PHP-Schalter `MASK_JOBLIST_CHECK_NUM_OF_CS_REPORTS` wird in der aktuellen Ausgabe nicht ausgewertet; daraus wurde keine zusätzliche Berichtssperre abgeleitet.

## 18. Oktober 2026 – Voreingestellte Sortierung der Auftragslisten

- Aktuelle PHP-Liste mit Status „Angenommene Aufträge“, aufsteigender Richtung und Serverquelle `admin/jb_list.php` (`db040a7b070773da74dfbbdf3e46f3ecc55564f516f34f81dd880826221e80fc`) abgeglichen. Bei aktivem `MASK_JOBLIST_TAKENJOB_ORDERBY` der aktuellen Niederlassung und sichtbarer Annahmespalte startet diese Liste nach Annahmezeit. Andere Listen bzw. eine ausgeblendete Annahmespalte starten nach Auftragszeit. Die Anfangsrichtung entspricht PHP aufsteigend.
- Persönliche Listen, Einzelliste und CSV verwenden dieselbe serverseitige Sortierung vor der Seiteneinteilung. Ausdrückliche Spalten-/Richtungswahl hat Vorrang. Der sichtbare Pfeil zeigt auch die Voreinstellung; der erste Klick auf diese Spalte kehrt sie um. Gleichstände behalten die Auftrags-ID als stabile zweite Sortierung. Globale/persönliche Werte ersetzen den Niederlassungswert hier nicht; doppelte Vorgaben werden abgewiesen.
- **1339 Tests: 1336 bestanden, drei übersprungen, keine Fehler**, sechs gezielte Backendprüfungen, 18 Frontendtests und Build erfolgreich; 961 Dateien archiviert (`work/order-list-sorting-verification.json`). SQL: Seitenwechsel, CSV, Einzel-/Mehrfachliste, andere Status und ausgeblendete Spalten. Browser mit synthetischen Aufträgen: Anfangssortierung, Richtungswechsel und ausdrückliche andere Spalte (`work/order-list-sorting-ui-verification.json`, `work/auftragsliste-annnahme-sortierung-2026-10-18.png`). Lokal Health UP und sechs identische Assets (`work/order-list-sorting-deployment.json`). Keine echten Geschäftsdaten geändert.

## 18. Oktober 2026 – Startzeitraum der Auftragslisten

- Aktuelle PHP-Listenmaske und `admin/jb_list.php` (`db040a7b070773da74dfbbdf3e46f3ecc55564f516f34f81dd880826221e80fc`) frisch abgeglichen. `MASK_JOBLIST_STARTDATE_YESTERDAY` wird ausschließlich aus der aktuellen Niederlassung für Mitarbeiter 0 gelesen. Ohne aktive Vorgabe startet der Zeitraum heute, andernfalls gestern; das Ende ist morgen. Datum wird in Europe/Berlin nach Kalendertagen berechnet.
- Persönliche Listen und Einzelliste übernehmen dieselben Servervorgaben. Angezeigte Filter und Datenabfrage stimmen überein. Bewusst ausgewählte Zeiträume bleiben beim Aktualisieren erhalten; „Heute“ wählt ausschließlich den heutigen Tag. „Startauswahl wiederherstellen“ übernimmt in den persönlichen Listen wieder die Vorgabe. Doppelte Konfiguration wird abgewiesen, persönliche/globale Werte werden hier nicht geerbt.
- **1334 Tests: 1331 bestanden, drei übersprungen, keine Fehler**, sieben gezielte Backendprüfungen, 18 Frontendtests und Build erfolgreich. 960 Dateien archiviert (`work/list-date-defaults-verification.json`). Browser: beide Listenarten, Vorgabe mit/ohne Vortag, Heute-Auswahl und Aktualisierung (`work/list-date-defaults-ui-verification.json`, `work/listen-datumsvorgabe-2026-10-18.png`). Lokal Health UP und sechs identische Assets (`work/list-date-defaults-deployment.json`). Keine echten Geschäftsdaten geändert.

## 18. Oktober 2026 – Aufnahmeantrag mit reinem Speicheraufruf

- Aktuelle PHP-Formularoberfläche sowie `include/inc_metafield.inc.php` (`149a46799258036404ac45ba315531195ed2b4c316bfa14b4addb5c5e13fdc65`) und `admin/courier_special.php` (`64c753ec0c7b36ef86215c5ce24f5f8cf4889334c147e746e5ec5134264accfa`) frisch abgeglichen. Das vorhandene Formular Kategorie/Vorlage 1000 enthält nur den Aufruf `formularFinishPage() → finishPage()`. Diese exakt begrenzte Variante ist jetzt speicherbar; die vorhandenen fachlichen Feldregeln bleiben zuständig.
- Keine Ausführung gespeicherter JavaScript-Texte. Zusätzliche Aktionen, Argumente und doppelte Abschlussfunktionen bleiben gesperrt. Unveränderte Wiederholung erzeugt keinen zweiten Vorgang; geänderte Vorlage verlangt Neuladen. Feldzuordnungen werden nicht aus uneindeutigen Beschriftungen geraten.
- **1332 Tests: 1329 bestanden, drei übersprungen, keine Fehler**, neun gezielte Backendprüfungen und 958 archivierte Dateien (`work/form-save-wrapper-verification.json`). Browser: eine synthetische Speicherung und gesperrte Variante mit Zusatzaktion (`work/form-save-wrapper-ui-verification.json`, `work/aufnahmeantrag-gespeichert-2026-10-18.png`). Lokal Health UP und sechs identische Assets (`work/form-save-wrapper-deployment.json`). Bestandsprüfung ausschließlich lesend, keine echten Stammdaten geändert.

## 18. Oktober 2026 – Verrechnungsfahrzeuge bei Kurier-Unteraufträgen

- Aktuelle PHP-Auftragsmaske und Serverquellen `jobs/job_options.php` (`bfc6d2a725092142d36dfb93dd8ea9ae71408961c8abe5f77f82ab1e87bd9e80`) sowie `jobs/job_edit.68.20.js` (`845b163033d275911b6f237e63d1313c609ab42d5ac578bd718dd5707f841aba`) erneut abgeglichen. Bei aktivem `MASK_INVOICE_SHOW_SIDS` bestimmen die Niederlassungsvorgabe und die beiden globalen Kennungen die Verrechnungsfahrzeuge. Für Fahrzeugklassen unter 7 wird die PHP-Vorgabe auf Kennung 0 umgestellt. Beide Kennungen bleiben ausdrücklich auswählbar.
- Die Auswahl ersetzt erst nach Bestätigung das Hauptfahrzeug und erhält die gewählte Fahrzeugklasse. Veraltete Antworten werden verworfen; Laden kann wiederholt werden. Fremde, archivierte, gesperrte und nicht freigegebene Fahrzeuge werden ausgeschlossen. Fehlende/mehrdeutige Konfiguration sperrt die betroffenen Unteraufträge. Die Kalkulation prüft die Zuordnung erneut und bindet die Vorgaben an die Preisvorschau. Normale Aufträge bleiben unabhängig.
- **1330 Tests: 1327 bestanden, drei übersprungen, keine Fehler**, 89 gezielte Backendprüfungen, 18 Frontendtests und Build erfolgreich. 958 Dateien archiviert (`work/courier-parent-verification.json`). Browser: Fehler/Wiederholung, Klassenwechsel ohne stillen Fahrzeugtausch und richtige Haupt-/Unterauftrags-IDs in der Kalkulationsanfrage (`work/courier-parent-ui-verification.json`, `work/verrechnungsfahrzeug-2026-10-18.png`). Lokal Health UP und sechs identische Assets (`work/courier-parent-deployment.json`). Bestandsprüfung ausschließlich lesend; in zwei Niederlassungen sind die technischen Fahrzeuge nach bestehenden Regeln nicht freigegeben. Keine realen Sperren oder Geschäftsdaten geändert.

## 18. Oktober 2026 – Freigaben für Rabatt und Servicepreise

- Aktuelle PHP-Auftragsmaske sowie `jobs/job_options.php` (`bfc6d2a725092142d36dfb93dd8ea9ae71408961c8abe5f77f82ab1e87bd9e80`) und `jobs/job_edit.68.20.js` frisch abgeglichen. `MASK_CHECK_DISCOUNT`, `MASK_SERVICE_PRICE` und `MASK_MARKUP_MODE` aus der Erfassungsniederlassung steuern die sichtbaren Eingaben. Globale oder persönliche Werte werden hier nicht geerbt; doppelte Vorgaben werden abgewiesen.
- Deaktivierte leere Felder entfallen. Kopierte Servicepreise einschließlich einer ausdrücklichen Kuriervergütung von 0 € bleiben schreibgeschützt erhalten. Eine übernommene Rabattwahl bleibt nur beim ursprünglichen Zahler und einer geeigneten Preisart wirksam; Kundenwechsel übernehmen keine verborgene alte Rabattwahl. Vorhandene Preisrechte gelten weiter.
- **1325 Tests: 1322 bestanden, drei übersprungen, keine Fehler**, erweiterte SQL-Prüfung der Optionsvorgaben, 18 Frontendtests und Build erfolgreich. 954 Dateien archiviert (`work/entry-price-controls-verification.json`). Browser mit aktiven/inaktiven Vorgaben und überprüften Kalkulationsanfragen (`work/entry-price-controls-ui-verification.json`, `work/preisfeld-vorgaben-2026-10-18.png`). Lokal Health UP, DB verbunden und sechs identische Assets (`work/entry-price-controls-deployment.json`). Keine echten Geschäftsdaten geändert.

## 18. Oktober 2026 – Eingeschränkte Fahrzeugdisposition (Recht 28)

- Aktuelle Serverquellen `admin/vehicle_disposition.php` (`f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`) und `include/inc_vehicle.inc.php` (`e34830c44c742c28f658e693256e0658920d0f383b9a030a188c76af7ac7b086`) sowie die PHP-Oberfläche erneut abgeglichen. Recht 27 hat Vorrang; allein Recht 28 benötigt beide eindeutigen globalen Filter. Die begrenzte Ausdrucksgrammatik unterstützt Vergleiche, Boolesche Verknüpfungen, Bitmasken, IN/LIKE/BETWEEN/NULL und ausgewählte reine Funktionen; Werte werden gebunden. Unbekannte SQL-Konstrukte, fehlende und mehrdeutige Vorgaben sperren den Zugriff.
- Filter gelten vor der Seiteneinteilung für Fahrzeuge, Kundenbeziehungen, Auftragsablage, Suche, Rollkarten und Planungsziele. Direkte Aufrufe, Niederlassungswechsel, verknüpfte Aufträge, Reservierungsfahrzeuge und gespeicherte PDF-Vorschauen werden erneut geprüft. Verborgene Aufträge erscheinen nur als anonyme Belegung; Gesamtumplanung und Unternehmerübergabe eines gemischten Tages bleiben gesperrt. Kundenweite Änderungen verlangen Zugriff auf sämtliche betroffenen Fahrzeug-/Kundenbeziehungen. Tabellenalias-Sperren sichern auch die Filterprüfung bei Schreibvorgängen gegenüber PHP ab.
- **1325 Tests: 1322 bestanden, drei übersprungen, keine Fehler**, davon 151 gezielte Backendprüfungen einschließlich 21 FDS-Datenbankprüfungen. 18 Frontendtests und Build erfolgreich; 954 Dateien archiviert (`work/restricted-fds-verify.log`). Browser: gefilterte Fahrzeugliste, anonyme Zeitleiste, gesperrte Gesamtaktion und reduzierte Rollkarte (`work/restricted-fds-ui-verification.json`, `work/eingeschraenkte-disposition-2026-10-18.png`). Lokal Health UP und sechs identische Assets (`work/restricted-fds-deployment.json`). Keine echten Berechtigungen oder Geschäftsdaten geändert. Frei ausführbares PHP-SQL und Unternehmer-Logins werden dadurch nicht freigeschaltet.

## 18. Oktober 2026 – Letzten eigenen Auftrag kopieren

- Aktuelle PHP-Aktion `getLastJob()` und die nur im persönlichen Nacherfassungsmodus eingeblendete Schaltfläche aus `jobs/job_tour.php`/`jobs/job_options.php` abgeglichen. NG bietet dort „Letzten Auftrag kopieren“ aus der vorhandenen eigenen Erfassungshistorie der gewählten Niederlassung. Der Hinweis benennt ausdrücklich den letzten in NG gespeicherten Vorgang; PHP-Sitzungszustand wird nicht erfunden.
- Gruppen verwenden ihren Hauptauftrag. Fremde Konten/Niederlassungen sind ausgeschlossen, aktuelle Rechte werden erneut geprüft. Der bestehende abgesicherte Kopierablauf bleibt zuständig für Fahrzeug, Termine, Preise, Fotos und Artikel. Der Vorlagenfilter verändert diese Aktion nicht: sie lädt ausdrücklich eine normale Kopie. Entwurfsschutz, Ladefehler und Wiederholung geprüft; keine automatische Speicherung.
- **1317 Tests: 1314 bestanden, drei übersprungen, keine Fehler**, bestehender SQL-Historientest um Konten-, Niederlassungs- und Reihenfolgeprüfungen erweitert, 18 Frontendtests und Build erfolgreich. 950 Dateien archiviert (`work/entry-last-order-verify.log`). Browsernachweis: `work/entry-last-order-ui-verification.json`, `work/letzten-auftrag-kopieren-2026-10-18.png`. Lokal Health UP und sechs identische Assets (`work/entry-last-order-deployment.json`). Keine echten Geschäftsdaten geändert.

## 18. Oktober 2026 – Freigabe des reinen Kundenrechnungstexts

- `MASK_HIDDEN_FREETEXT` anhand der aktuellen Serverquellen `jobs/job_options.php` und `jobs/job_tour.php` sowie der sichtbaren PHP-Aktion „Text nur Rg“ abgeglichen. Wert 1 erlaubt die Eingabe; Wert 2 verlangt den persönlichen Nacherfassungsmodus. Ein bloßer Wechsel der Auftragsart schaltet das Feld nicht frei. Maßgeblich sind die Erfassungsniederlassung und der persönliche Modus der Login-Niederlassung; globale/persönliche Fremdvorgaben werden nicht fälschlich geerbt.
- Bereits gespeicherter Text einer kopierten Vorlage bleibt ohne Bearbeitungsfreigabe sichtbar und schreibgeschützt erhalten. Er wird bei der Preisvorschau unverändert übertragen. Fehlende und ausgeschaltete Einstellungen blenden leere Eingaben aus; doppelte Werte werden zurückgewiesen.
- **1317 Tests: 1314 bestanden, drei übersprungen, keine Fehler**, gezielte SQL-Prüfung der Vorgaben, 18 Frontendtests und Build erfolgreich. 949 Dateien archiviert (`work/entry-invoice-text-verify.log`). Browser mit aktiver/inaktiver Freigabe, manueller Nacherfassung und kopiertem Text geprüft (`work/entry-invoice-text-ui-verification.json`, `work/rechnungstext-freigabe-2026-10-18.png`). Lokal Health UP und sechs identische Assets (`work/entry-invoice-text-deployment.json`). Keine echten Geschäftsdaten geändert.

## 18. Oktober 2026 – Kundenhinweise in der Auftragserfassung

- Aktuelle Serverquellen `jobs/job_edit.68.20.js` (`845b163033d275911b6f237e63d1313c609ab42d5ac578bd718dd5707f841aba`), `jobs/job_tour.php` und `admin/cs_csc_list.php` (`d9296acc51b3073d9e4b38dd260d390eb3c30be144a0e12855e46a03024096c4`) sowie die PHP-Maske abgeglichen. Firmenhinweise werden für Zahler und Stationskostenstellen angezeigt, je Kunde zusammengefasst und mit allen Rollen beschriftet. Umordnen aktualisiert die Zuordnung ohne erneute Abfrage unveränderter Kostenstellen.
- Ein gebundener Sammelabruf prüft Erfassungsrecht, Niederlassung, Freigabe, Archivierung und Kostenstellensperren. Fehlende oder mehrdeutige Zuordnungen werden vollständig abgewiesen. HTML bleibt Text; Stationsnotizen bleiben unabhängig. Veraltete Antworten werden verworfen, Ladefehler sind wiederholbar.
- **1317 Tests: 1314 bestanden, drei übersprungen, keine Fehler**, fünf gezielte Backendprüfungen, 18 Frontendtests und Build erfolgreich. 949 Dateien archiviert (`work/entry-customer-notices-verify.log`). Browser: Fehler/Wiederholung, Zusammenfassung, Umordnen, Entfernen und unveränderte Stationsnotizen (`work/entry-customer-notices-ui-verification.json`, `work/kundenhinweise-2026-10-18.png`). Lokal Health UP, DB verbunden und sechs identische Assets (`work/entry-customer-notices-deployment.json`). Keine echten Geschäftsdaten geändert.

## 18. Oktober 2026 – Vorgabe für manuelle Disposition

- Aktuelle Serverquellen `jobs/job_options.php` (`bfc6d2a725092142d36dfb93dd8ea9ae71408961c8abe5f77f82ab1e87bd9e80`) und `jobs/job_edit.68.20.js` (`845b163033d275911b6f237e63d1313c609ab42d5ac578bd718dd5707f841aba`) abgeglichen. `MASK_MANUAL_DISPOSITION` aus der Erfassungsniederlassung steuert jetzt auch neue Aufträge. Globale/persönliche Werte werden hier nicht geerbt; doppelte Vorgaben werden zurückgewiesen.
- Persönliche Nacherfassung hat Vorrang. Beim expliziten Wechsel zum Dispositionsmodus sowie beim Verlassen eines Angebots wird die Niederlassungsvorgabe wiederhergestellt. Bei Rückkehr aus Nacherfassung wird ein bereits ausdrücklich gewähltes Fahrzeug erhalten. Manuelle Abwahl bleibt bei gewöhnlichen Eingaben erhalten; geladene Vorlagen behalten ihre serverseitig bestimmte Auswahl. Die Voreinstellung ist keine zusätzliche Zwangsdisposition.
- **1312 Tests: 1309 bestanden, drei übersprungen, keine Fehler**, 54 gezielte Prüfungen (einschließlich separatem SQL-Test der Optionsvorgaben), 18 Frontendtests und Build erfolgreich. 945 Dateien archiviert (`work/entry-manual-default-verify.log`). Browser mit zwei Niederlassungen, aktiver/inaktiver Vorgabe, Angebot, Nacherfassung und persönlichem Modus geprüft (`work/entry-manual-default-ui-verification.json`, `work/manuelle-dispositionsvorgabe-2026-10-18.png`). Lokal Health UP und sechs identische Assets (`work/entry-manual-default-deployment.json`). Keine echten Aufträge geändert.

## 18. Oktober 2026 – Dokumente direkt beim Zahler

- Aktuelle PHP-Dokumentoberfläche sowie `include/ajaxReqDocument.php` (`f7ff5340796c750f73497fbfb3f6c75bef69d946054fe8afe0da92cbbb56253f`), `import/data_transfer.php` (`c57b55631bb3c94533959f368fd46e65434525473bf0b355ca0ccf4305a0e067`) und der Auftragsmaskenaufruf frisch abgeglichen. Ein direkter Einstieg in vorhandene Kundendokumente steht beim Zahler zur Verfügung. Die bestehende Ablage mit Unterverzeichnissen und Dateiaktionen wird wiederverwendet.
- Die Sichtbarkeitsprüfung liest ausschließlich Dateinamen, keine Dokumentinhalte. Kundenrechte, tatsächliche Datei- und Niederlassungsfreigabe sowie die konkrete Zahlerzuordnung bleiben wirksam. Ähnlich beginnende Kundennummern, versteckte Dateien und Ordner gelten nicht als Kundendokument. Zugriffs- oder Zuordnungsänderungen während der Prüfung werden erneut kontrolliert. Eine fremde Erfassungsfreigabe erweitert nicht den Dokumentzugriff.
- **1312 Tests: 1309 bestanden, drei übersprungen, keine Fehler**, 17 gezielte Backendprüfungen, 18 Frontendtests und Build erfolgreich. 945 Dateien archiviert (`work/entry-payer-documents-verify.log`). Browser: Fehler/Wiederholung, richtige Kundenablage, Unterverzeichnis, korrekte Downloadanfrage und erhaltener Auftragsentwurf (`work/entry-payer-documents-ui-verification.json`, `work/zahlerdokumente-2026-10-18.png`). Die heruntergeladene Datei wurde im Dateisystem nicht lokalisiert; der Downloadinhalt ist daher nicht zusätzlich per Browserdatei belegt. Lokal Health UP und sechs identische Assets (`work/entry-payer-documents-deployment.json`). Keine echten Dokumente oder Geschäftsdaten geändert.

## 18. Oktober 2026 – Kundenberichte direkt beim Zahler

- Aktuelle PHP-Maske sowie `jobs/job_tour.php` (`9dd4e6940748c1a519bdfeed749225bc2d50e71d2c9c1303a594b8bb78a5ba4b`), `jobs/job_edit.68.20.js` und `groupware/report.php` (`099cfde4b087134b29ec74cc8f7c67396f0fac108ccd45aeea90c0afc7c57099`) direkt vom Server abgeglichen. Der Berichtsaufruf ist jetzt neben dem ausgewählten Zahler erreichbar. `MASK_JB_REPORT_BUTTON_ENABLED_PERMANENT` aus der Erfassungsniederlassung oder ein sichtbarer Kundenbericht steuern die Anzeige.
- Kunden- und Berichtsrechte, konkrete Zahlerkostenstelle, Niederlassungsumfang und Vertraulichkeit werden serverseitig geprüft. Eine fremde Erfassungsfreigabe erweitert nicht den Berichtszugriff. Keine Offenlegung allein durch fremde vertrauliche Berichte. Der bestehende Berichtsdialog öffnet mit Kunde und Niederlassung; Auftragseingaben bleiben erhalten, parallele Auftragsaktionen sind währenddessen gesperrt. Ladefehler haben eine Wiederholungsaktion.
- **1302 Tests: 1299 bestanden, drei übersprungen, keine Fehler**, 22 gezielte Backendprüfungen, 18 Frontendtests und Build erfolgreich. 941 Dateien archiviert (`work/entry-payer-reports-verify.log`). Browser mit Fehler/Wiederholung, richtigem Kundenfilter und Abbruchschutz geprüft (`work/entry-payer-reports-ui-verification.json`, `work/zahlerberichte-2026-10-18.png`). Lokal Health UP und sechs identische Assets (`work/entry-payer-reports-deployment.json`). Keine echten Berichte oder Aufträge geschrieben.

## 18. Oktober 2026 – Festpreisrabatt und Kundenvoreinstellung

- Aktuelle PHP-Auftragsmaske und Serverquellen `jobs/job_edit.68.20.js` (`845b163033d275911b6f237e63d1313c609ab42d5ac578bd718dd5707f841aba`) sowie `jobs/job_options.php` abgeglichen. `cs_discount` enthält den tatsächlichen Prozentsatz; `cs_fixprice_discount` ist ausschließlich der 0/1-Vorgabeschalter. Die native Kalkulation, Kostenstellensuche, Zahlerdaten und Vorlagen verwenden jetzt den tatsächlichen Satz. Die separat dokumentierte PZM-Vergleichslogik bleibt unverändert.
- Bei neuen Zahlern wird die Kundenvoreinstellung geladen. Manuelle Rabattwahl und die ausdrücklich gespeicherte Auswahl einer kopierten Tour bleiben erhalten. Rabatt wird nur für geeignete Preisarten oder einen positiven Servicepreis angeboten. Änderungen entwerten eine vorhandene Preisvorschau; historische Aufträge werden nicht rückwirkend geändert.
- **1295 Tests: 1292 bestanden, drei übersprungen, keine Fehler**, 35 gezielte Backendprüfungen, 18 Frontendtests und Produktionsbuild erfolgreich. 937 geprüfte Dateien archiviert (`work/fixed-discount-verify.log`). Browser: Vorgabe, manuelle Abwahl, kopierte Abwahl, unzulässiger Rabatt und Preisvorschau mit 20 % geprüft (`work/fixed-discount-ui-verification.json`, `work/festpreisrabatt-2026-10-18.png`). Lokal Health UP und sechs identische Assets (`work/fixed-discount-deployment.json`). Reale Daten nur gelesen; keine Geschäftsdaten geändert.

## 18. Oktober 2026 – Niederlassungsspezifische Erfassungsgrenzen

- Aktuelle PHP-Maske und SSH-Quellen `jobs/job_edit.68.20.js` (`845b163033d275911b6f237e63d1313c609ab42d5ac578bd718dd5707f841aba`), `auth.inc.php` und `dbglobal.inc.php` abgeglichen. `MASK_MAXTOUR` zählt Etappen; die native Stationsgrenze beträgt daher den konfigurierten Wert plus eins. `MASK_MAX_TR_REMARK` begrenzt Stationshinweise. Beide Werte stammen ausschließlich aus der ausgewählten Erfassungsniederlassung, ohne persönliche oder globale Übernahme.
- Oberfläche zeigt Stationsanzahl und Zeichenverbrauch; weitere Stationen sind an der Grenze gesperrt. Zu lange geladene Touren und Hinweise bleiben vollständig erhalten und erhalten eine Korrekturaufforderung. Backend prüft vor Kalkulation und neuer Speicherung erneut. Bereits bestätigte Anfragen bleiben nach einer späteren Grenzänderung abrufbar. Kundenportal und automatische Serienfortsetzung behalten ihre eigenen Regeln. Ohne Vorgabe gelten die bisherigen technischen Grenzen (100 Stationen/2000 Zeichen); ungültige oder doppelte Vorgaben werden ausdrücklich zurückgewiesen. Die separate Optimierungsgrenze bleibt 25 Stationen.
- **1293 Tests: 1290 bestanden, drei übersprungen, keine Fehler**, 57 gezielte Backendprüfungen, 18 Frontendtests und Produktionsbuild erfolgreich. 937 geprüfte Dateien archiviert (`work/entry-limits-verify.log`). Browser: drei erlaubte Stationen, 20 Zeichen, vollständige überlange Vorlage mit vier Stationen und 27 Zeichen sowie Korrektur geprüft (`work/entry-limits-ui-verification.json`, `work/erfassungsgrenzen-2026-10-18.png`). Lokal Health UP und sechs identische Assets (`work/entry-limits-deployment.json`); keine echten Geschäftsdaten geändert.

## 18. Oktober 2026 – Direkte Übernahme der hinterlegten Zahlerkostenstelle

- Aktuelle PHP-Auftragsmaske erneut lesend geprüft; `jobs/job_edit.68.20.js` (`845b163033d275911b6f237e63d1313c609ab42d5ac578bd718dd5707f841aba`) setzt den Zahler anhand seiner konkreten Kostenstellen-ID. Die native Übernahme verwendet jetzt ebenfalls den abgesicherten Direktabruf statt einer auf 50 Texttreffer begrenzten Suche. Ein gültiger Standardzahler wird dadurch nicht durch ähnliche Namen verdrängt.
- Zahlerwechsel und Laden gespeicherter Touren verwenden den gemeinsamen Schutz vor parallelen Aktionen. Bei einem Ladefehler bleiben Zahler und Entwurf erhalten; nach erfolgreichem Wechsel werden die neuen Kundenvorgaben geladen und der bisherige Preis verworfen. Niederlassungs-, Sichtbarkeits-, Sperr- und externe Kostenstellenprüfung bleiben serverseitig erhalten.
- **1286 Tests: 1283 bestanden, drei übersprungen, keine Fehler**, 18 Frontendtests und Produktionsbuild erfolgreich. 934 Dateien archiviert (`work/default-payer-verify.log`). Browser mit verzögerter Antwort, Fehler, Wiederholung, 50 ablenkenden Suchtreffern und erhaltenem Entwurf geprüft (`work/default-payer-ui-verification.json`, `work/standardzahler-2026-10-18.png`). Keine Geschäftsschreibanfrage. Lokal Health UP und sechs identische Assets (`work/default-payer-deployment.json`).

## 18. Oktober 2026 – Betragsgrundlage und Vergleichsgrenzen der Statistik

- Frische Serverquellen `statistic/statistic.php` (`f71da1670901c04bef452dceea6912a49f0fa9c3a573e58f2e027e0e2aec596f`) und `statistic/statistic_interface_hq.inc.php` (`40fcbd4668f467610d31f2fec802488db8595756910d491f1eb531114d0bb84b`) sowie aktuelle PHP-Statistikoberfläche abgeglichen. Auswahl von Auftragswert, Frachtvergütung, Einnahmenausgleich, BSG, Servicepreis/-vergütung, Kilometern, CO₂e oder allen Beträgen ergänzt. Vorgabe ist Auftragswert; `MASK_STATISTIC_PRICE_MODE` wird lokal und bei fehlendem Wert global ausgewertet. Eine explizite lokale Null bleibt wirksam.
- Ergebnisübersicht, Detailspalten, Diagrammvorgabe und CSV folgen der Auswahl. EAU/BSG auch in der Detailtabelle und im Gesamtexport; BSG-Gesamtwert aus den aufsummierten Beträgen statt aus gemittelten Zeilenprozentsätzen. Separate Zuschläge bleiben erhalten. Vergleichszeiträume beachten die globalen Schalter und die konfigurierte Anzahl bis fünf; deaktivierte oder ungültige Vorgaben erlauben keine zusätzlichen Vergleiche.
- **1286 Tests: 1283 bestanden, drei übersprungen, keine Fehler**, 19 gezielte Backendprüfungen, 18 Frontendtests und Produktionsbuild erfolgreich. Archiv `work/statistics-display-verify.log`, 934 geprüfte Dateien. Browser mit aktivierter/deaktivierter Auswahl, zwei Vergleichszeiträumen, BSG 50/10 % mit korrektem Gesamtwert 14 % und beiden CSV-Downloads geprüft (`work/statistics-display-ui-verification.json`). Screenshot `work/statistik-betragsgrundlage-2026-10-18.png`. Lokal Health UP und sechs identische Assets (`work/statistics-display-deployment.json`). Keine Geschäftsdaten geändert; kein Nachweis vollständiger PHP-Parität.

## 18. Oktober 2026 – Konfigurierbare Vertriebsaktionen und Statistikvorgaben

- Aktuelle PHP-Oberflächen Vertrieb und Statistik erneut geöffnet, Serverquellen `groupware/appointment.php`, `statistic/statistic.php` und `statistic/statistic_interface_hq.inc.php` (SHA-256 `40fcbd4668f467610d31f2fec802488db8595756910d491f1eb531114d0bb84b`) direkt abgeglichen. Die vier globalen `MASK_AP_BTN_CS_*`-Schalter steuern Kundenanlage, allgemeine Kundenberichte, Kundenstatuswechsel und Motivation-Counter. Kundenbezogene Berichte bleiben mit Recht 16 unabhängig vom allgemeinen Berichtsschalter erreichbar. Konfigurationsschalter ersetzen keine Zugriffsrechte.
- Statistik übernimmt `STATISTIC_DATE_MODE` ausschließlich aus der aktuellen Niederlassung (fünf Modi; ohne gültige Vorgabe Exportdatum). `MASK_STATISTIC_DATE_MODE` steuert die Auswahl von Datumsgrundlage, Auftragsstatus und Erfassungsart wie in der alten UI. Bei ausgeblendeter Auswahl werden die wirksamen Vorgaben angezeigt; Transporteur-Aktionen behalten ihr Aktionsdatum. Globale und persönliche Einstellungen werden hierfür nicht irrtümlich geerbt.
- **1282 Tests: 1279 bestanden, drei übersprungen, keine Fehler**, 16 gezielte Prüfungen, 14 Frontendtests und Produktionsbuild erfolgreich. Archiv `work/configured-navigation-verify.log`, 930 geprüfte Dateien. SQL-Prüfung aller Datumsmodi, fehlender/ungültiger/doppelter Werte, persönlicher/globaler Vorränge und Rechte. Browser mit aktivierten/deaktivierten Schaltern sowie tatsächlich abgesendeten BOOKED/CREATED/EXPORTED-Abfragen, ausschließlich isolierte Daten (`work/configured-navigation-ui-verification.json`). Screenshot `work/statistik-datumsvorgabe-2026-10-18.png`. Lokal Health UP und Assets geprüft (`work/configured-navigation-deployment.json`). Kein Nachweis vollständiger PHP-Parität.

## 18. Oktober 2026 – Kundenaktionen aus dem Vertrieb

- Frische Serverquellen `groupware/appointment.php` (`e55056ff0a98896f3ca7cfe946fcefb8edc42c2a3bd0733eb137f0b56ee5980a`) und `statistic/statistic.php` (`f71da1670901c04bef452dceea6912a49f0fa9c3a573e58f2e027e0e2aec596f`) sowie die aktuelle PHP-Terminmaske abgeglichen. Kundenanlage, Kundenstamm und vorbelegte Kundenstatistik sind aus dem Kalender erreichbar. Kalenderauswahl und Entwurfsschutz bleiben beim Öffnen und Schließen erhalten.
- Kundenkontext wird serverseitig gegen Rechte, Mandant und aktuelle Niederlassungsfreigabe geprüft. Fremde Niederlassungen sind im Kundenstamm nicht schreibbar. Die alte Monatsstatistik ab 2004 ist für genau einen Kunden verfügbar; nur diese eng begrenzte Abfrage erlaubt bis zu 100 Jahre, breite Statistiken behalten die Zehnjahresgrenze.
- **1281 Tests: 1278 bestanden, drei übersprungen, keine Fehler**, 34 gezielte Prüfungen, 14 Frontendtests und Produktionsbuild erfolgreich. Archiv `work/appointment-customer-verify.log`, 928 geprüfte Dateien. Browserprüfung mit isolierten Daten und ohne Geschäftsschreibanfrage: `work/appointment-customer-ui-verification.json`, Screenshot `work/vertrieb-kundenstatistik-2026-10-18.png`. Lokal Health UP, DB verbunden, sechs Assets identisch (`work/appointment-customer-deployment.json`). Weitere Teilabläufe bleiben im laufenden Abgleich.

## 18. Oktober 2026 – Zusätzliche Spalten der Kundenauftragsliste

- Frische PHP-Quellen `customer/jb_list.php` (`db2982580436d77796bb7ecccdcc7af7a763bdbe72e770dd012ffe80e652774c`) und `include/jb_list_defineoutput.inc.php` (`9c8087e29853641fca21fee5b76b0abbebad6231cb830e91a0c6f6bf3aab8a0a`) abgeglichen. Sieben tatsächlich gespeicherte Spaltenlayouts rein lesend geprüft (`work/customer-columns-read.json`). Die Kundenmaske leitet die bestehende Administrator-Sitzung zur Startseite um; der alte Kundenbildschirm konnte damit nicht direkt geprüft werden.
- Neun explizit konfigurierte Spalten ergänzt: Dispositionsinfo, Zieladresse mit Ort, Abhol-/Zustellabschluss, jeweilige Unterschriftsnamen, Auftragshinweis, Tourorte und Tour-PLZ. Persönliche bzw. kundenspezifische Beschriftungen und Ausrichtungen bleiben erhalten. Zieladresse ohne Ort nun entsprechend PHP getrennt. Interne `[[…]]`-Textteile bleiben ausgeblendet; HTML wird als Text angezeigt. Tour-PLZ zeigen ausländische Länderpräfixe; ohne gespeicherte Tourfolge gelten Start/Ziel. Stationssuche verwendet Abschluss und Unterschrift der gefundenen Station.
- SQL-Sortierung vor der Seitenteilung, fehlende Stationen/Nullzeitpunkte, persönliche Vorränge und zusätzliche Stationsspalten geprüft. Nicht freigegebene Finanz-/Kontofelder, fremde Kostenstellen und unberechtigte Sortierschlüssel bleiben gesperrt. Geschäftsdaten bleiben unverändert.
- **1278 Tests: 1275 bestanden, drei übersprungen, keine Fehler**, zwei gezielte SQL-Gruppen, 14 Frontendtests und Produktionsbuild erfolgreich. Archiv `work/customer-columns-verify.log`, 926 geprüfte Dateien. Browser: Datumsformat, Textausgabe, absteigende Sortierung, zweite Seite und dritte Station; keine Schreibanfrage (`work/customer-columns-ui-verification.json`). Screenshot `work/kundenspalten-2026-10-18.png`. Lokal Health UP, DB verbunden, sechs Assets identisch (`work/customer-columns-deployment.json`). Weitere Teilabläufe bleiben im laufenden Abgleich.

## 18. Oktober 2026 – Kunden- und Zonenfilter der FDS-Auftragsablage

- Frische Serverquellen `admin/vehicle_disposition.php` (`f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`) und `include/inc_vehicle.inc.php` (`e34830c44c742c28f658e693256e0658920d0f383b9a030a188c76af7ac7b086`) sowie die aktuelle PHP-Maske abgeglichen. Die Auftragsablage unterstützt „Alle Aufträge“, kundenübergreifende Anzeige innerhalb der ausgewählten Niederlassung, Servicezonen, erste voreingestellte Zone, dauerhaft aktivierte Gesamtauswahl und konfigurierte Angebote. Vorgaben stammen wie PHP teils aus der Login-Niederlassung, teils ausschließlich global.
- Zieladresse, Angebotskennzeichnung, gebundene Suche und stabile Seitenwechsel ergänzt. Lesen ist ohne Änderungsrecht und für vergangene Tage möglich. Reservierungen und fremde Niederlassungen bleiben ausgeschlossen. Nicht planbare Angebote, Stornobelege, bereits zugeordnete Aufträge und mehrdeutige Stationen erhalten einen sichtbaren Grund. Die eigentliche Angebotsumwandlung bleibt separat erforderlich.
- **1277 Tests: 1274 bestanden, drei übersprungen, keine Fehler**, drei gezielte SQL-Prüfungen, 14 Frontendtests und Produktionsbuild erfolgreich. Archiv `work/fds-eco-verify.log`, 924 geprüfte Dateien. Browserprüfung: Zonenwechsel, kundenübergreifende Gesamtauswahl und gesperrte Angebotsplanung; keine Schreibanfrage (`work/fds-eco-ui-verification.json`). Screenshots `work/fds-auftragsablage-2026-10-18.png` und `work/fds-auftragsablage-angebot-2026-10-18.png`.
- Lokal bereitgestellt: Health UP, DB verbunden, sechs Assets identisch (`work/fds-eco-deployment.json`). Reale Einstellungen und eingeschränkte FDS-Rollen ausschließlich gelesen: aktuell keine der fünf ECO-Sondervorgaben und keine aktiven SQL-Einschränkungen bzw. reinen Recht-28-Benutzer (`work/fds-eco-read.json`, `work/restricted-disposition-read.json`). Recht 28 und weitere Sonderabläufe bleiben im Abgleich; vollständige Parität ist nicht bestätigt.

## 18. Oktober 2026 – Zentrale Auftrags- und Retourenetiketten

- Frische SSH-Quellen `admin/jb_detail.php` (`4f9ab54020b9285a8a7d8b8ce00c07e2a8325ef320c86fabec79bf8c2df5d039`), `admin/metafield_special_cron.php` (`b8373b025e024548a430827b89d7c0478ae655f4ed720330f8e655d41771f9f3`) und `include/inc_html2pdf.inc.php` abgeglichen. Beide Schaltflächen in der aktuellen PHP-Auftragsdetailansicht sichtbar bestätigt. Die native zentrale Detailansicht bietet normale und Retourenetiketten mit Seitenvorschau und PDF-Download, auch bei reinem Auftragsleserecht und bereits abgerechneten Aufträgen. Kundenportal und zentrale Autorisierung bleiben getrennt; aktuelle Mitarbeiter- und Niederlassungsrechte werden geprüft.
- Alle 31 Papiergrößen des alten Konverters einschließlich `label60x40` unterstützt. Abmessungen nach wkhtmltopdf/Qt 4.8, einschließlich historischer B9-/Comm10E-Werte. Unbekannte Größen und abweichende Vorlagen werden abgewiesen. Rastervorschauen bleiben auch bei A0/B0 begrenzt; PDF-Seitengrößen unverändert. Aktuell gespeicherte Vorlagen-Hashes und globales A4-Format rein lesend bestätigt (`work/central-labels-read.json`).
- **1276 Tests: 1273 bestanden, drei übersprungen, keine Fehler**; drei gezielte Prüfungen, 14 Frontendtests und Produktionsbuild erfolgreich. Geprüft: alle Seitengrößen, Barcodes, Retouren, Rechteentzug, fremde Niederlassung, veränderte Adressen/Vorlagen/Papiergröße und unveränderte Geschäftsdaten. Archiv `work/central-labels-verify.log`, 922 geprüfte Dateien.
- Browser: beide Varianten, zweites Etikett, zwei Downloads, Escape schließt nur die Vorschau, keine Schreibanfrage (`work/central-labels-ui-verification.json`). PDFs gerendert und visuell geprüft; Screenshots `work/zentrale-etiketten-2026-10-18.png`, `work/zentrale-retourenetiketten-2026-10-18.png`. Lokal bereitgestellt: Health UP, DB verbunden, sechs Assets identisch (`work/central-labels-deployment.json`). Weitere FDS-Anzeige- und Sonderabläufe bleiben im aktuellen PHP-Abgleich; keine vollständige Parität behauptet.

## 18. Oktober 2026 – Zahlungspositionen in der Rechnungsausgabe

- Aktuelle Serverquellen `include/services_func.inc.php` (`4bd29ac9ef3b0cdb5194091c90c56740868e9d9b4c8fdfde4229f8720a6d7a10`) und `include/caglobal.inc.php` (`1f27316a4005535136b03db60f713a54a1d7a588892d8948e5832000417def11`) erneut abgeglichen. Niederlassungen über 1000 erhalten bei detaillierter Rechnungsausgabe die Zahlungspositionen FuhrlohnFixpreis, Soll, EC und Bar. Die Gruppen werden wie PHP nach Summierung mit dem Faktor 1,19 gerundet; die abschließende Offen-Summe ist keine Rechnungsposition. Der FuhrlohnFixpreis ist in diesem Aufruf ohne Kuriermodus null.
- Zahlungspositionen werden auch für PZM-Kunden als solche verarbeitet; der allgemeine PZM-Textparser der Altanwendung ist hierfür ungeeignet. Zahlungen gehören bereits zur Vorschau-Revision, und ihre Tabelle wird vor dem Schreiben auf InnoDB geprüft. Änderung seit der Vorschau, Fremdniederlassung, Export und späte Fehler verhindern eine Teilübernahme. Geldbeträge, Zahlungen, Status und Kuriertext bei ausgeschalteter Druckvorgabe bleiben erhalten.
- **1273 Tests: 1270 bestanden, drei übersprungen, keine Fehler**, 21 gezielte Prüfungen erfolgreich. Vollständiges Archiv `work/cash-invoice-verify.log`, 918 geprüfte Dateien. Browser bestätigt vier Zahlungspositionen und genau eine Übernahme in synthetischen Daten (`work/cash-invoice-ui-verification.json`, `work/rechnung-zahlungspositionen-2026-10-18.png`).
- Lokal bereitgestellt: Health UP, DB verbunden, sechs Assets identisch (`work/cash-invoice-deployment.json`). Keine realen Buchungen geändert. Weitere Druck- und Sonderabläufe bleiben im laufenden Abgleich; keine vollständige PHP-Parität behauptet.

## 18. Oktober 2026 – Kundenvorgaben für Standardpreise und durchgängige Preisprüfung

- Frische SSH-Quellen `jobs2/job_options.php` (`69651fa561f51a157ca8c49aef7f6f1ae27c80072af86f2c1e67b85ae41bfc63`), `jobs2/job_options.tpl.htm` (`d0d59bca7232dd11f7988583da672ccde92f217f64378e5c11186afccd57f0be`) und `jobs2/job_tour.php` abgeglichen; geöffnete zentrale PHP-Maske erneut lesend geprüft. `MASK_CS_DONT_MAKE_STANDARD_PRICE_*` und `CUSTOMER_MASK_CALCULATOR_USAGE_ONLY_*` unterdrücken im Kundenzugang Grund- und Streckentarife. Auch bei PZM-Kunden wird keine automatische Standardberechnung erzwungen. Maßgeblich bleiben Zahler bzw. abweichende Absenderkonditionen. Festpreisvorlagen und zusätzliche Servicepreise bleiben erhalten.
- Die Leistungspositionspflicht gilt weiterhin in der zentralen Erfassung. In der PHP-Kundenmaske sind diese Eingaben ausgeblendet; ungeklärte Kundenaufträge können wie PHP zur Preisprüfung aufgenommen werden. Beide Vorgaben sind an Revision/Vorschau gebunden, widersprüchliche globale Kundeneinstellungen werden zurückgewiesen. Die erste gezielte Prüfung deckte die bislang zu breit angewandte zentrale Pflichtprüfung auf; nach der Korrektur waren sämtliche gezielten Prüfungen erfolgreich.
- Nachweise, Auftragsbeleg und Abrechnungsübersicht zeigen den Preisprüfstatus ohne vorläufige Leistungsbeträge. Maut und Abliefernachweise bleiben sichtbar. Ungeklärte Aufträge einschließlich Kostensplits werden getrennt gezählt und nicht in die ausdrücklich bezeichnete Summe geklärter Preise aufgenommen. Auch ein Kostensplit ohne gespeicherte Preispositionen bleibt für die eigenen Stationen sichtbar. Freigabe stellt die reguläre Anzeige wieder her; gespeicherte Finanzdaten bleiben bei diesen Ansichtsänderungen unverändert.
- **1269 Tests: 1266 bestanden, drei übersprungen, keine Fehler**, 46 gezielte Tests, 14 Frontendtests und Produktionsbuild erfolgreich. Vollständiges Archiv `work/customer-price-policy-verify.log`, 917 geprüfte Quelldateien. Browsernachweis `work/customer-price-policy-ui-verification.json`: Nachweise, PDF-Viewer und Abrechnung geprüft, keine Schreibanfrage. Beide gerenderten PDF-Seiten visuell kontrolliert. Screenshots `work/kundennachweise-preispruefung-2026-10-18.png`, `work/kundenabrechnung-preispruefung-2026-10-18.png`.
- Lokal bereitgestellt: Health UP, Datenbank verbunden, sechs Assets identisch (`work/customer-price-policy-deployment.json`). Keine realen Aufträge oder Nachrichten verändert. Der Abgleich der weiteren Abrechnungs- und Aufbereitungssonderfälle läuft weiter; vollständige PHP-Parität ist damit noch nicht bestätigt.

## 18. Oktober 2026 – Kundenpreisprüfung und einmaliger Adresszuschlag

- Aktuelle Serverquellen `jobs2/job_options.php` (`69651fa561f51a157ca8c49aef7f6f1ae27c80072af86f2c1e67b85ae41bfc63`), `jobs/job_options.php`, `caglobal.inc.php` und `services_func.inc.php` frisch abgeglichen; alte Auftragsmaske lesend geprüft. Der automatische Straßen-/Hausnummernzuschlag gilt nur bei neuen Aufträgen. Zentrale Neukalkulation und Kundenbearbeitung behalten den gespeicherten Servicepreis ohne erneuten Zuschlag. Eine Auftragskopie ist entsprechend PHP ein neuer Auftrag.
- Fehlende Streckentarife dürfen im Kundenzugang als ausdrücklich ungeklärter Preis zur Nachbearbeitung gespeichert werden. Zentrale Erfassung bleibt bei fehlendem Tarif gesperrt. Grundpreis und Auftragssummen werden gemäß PHP zurückgesetzt; bestehende Teilstrecken und Frachtwerte bleiben nachvollziehbar. Der Adresszuschlag folgt zeitlich auf die Preisprüfung. Kostenteilung, Wiederholung, Rechteprüfung und Transaktionen bleiben wirksam.
- Kundenvorschau, Auftragsliste und Details zeigen „Preis in Prüfung“. Ungeklärte Beträge werden nicht als verbindlicher Nullpreis angezeigt. Barzahlungsstationen erhalten eine Aufforderung zur Abstimmung mit der Zentrale statt einer Null-Euro-Kassieranweisung. Preisberichtigung bzw. gültige Neukalkulation beseitigen die zusätzliche Preisvormerkung; andere Nachbearbeitungsgründe bleiben unabhängig erhalten.
- **1265 Tests: 1262 bestanden, drei übersprungen, keine Fehler**, 46 gezielte Tests, 14 Frontendtests und Frontendbuild erfolgreich. Der vorherige Gesamtlauf zum Adresszuschlag fand vier veraltete Mock-Aufrufe in `OrderRecalculationTest`; diese wurden auf die Bestandskalkulation umgestellt, danach waren 34 gezielte und der aktuelle vollständige Lauf erfolgreich. Geprüft: Neuanlage/Kopie, wiederholte Bearbeitung/Neukalkulation, Grundpreis, fehlender Tarif, Kostenteilung, Barhinweis, Tarifwechsel, Preisfreigabe, spätes Rollback, Fremdzugriff. Archiv `work/customer-pending-price-verify.log`, 915 Quelldateien.
- Browsernachweis `work/customer-pending-price-ui-verification.json`: Prüfstatus in Liste/Details/Vorschau, genau eine bestätigte synthetische Änderung mit sichtbarer Speicherbestätigung. Screenshots `work/kundenauftrag-preispruefung-2026-10-18.png` und `work/kundenauftrag-preispruefung-gespeichert-2026-10-18.png`. Lokal gestartet: Health UP, DB verbunden, sechs Assets identisch (`work/customer-pending-price-deployment.json`). Keine realen Aufträge, Zahlungen oder E-Mails verändert. Weitere kundenspezifische Preisvorgaben und Aufbereitungsfälle bleiben im laufenden Abgleich.

## 18. Oktober 2026 – Rechnungstexte der Unternehmerbelege

- Aktuelle Serverquellen `caglobal.inc.php` (`1f27316a4005535136b03db60f713a54a1d7a588892d8948e5832000417def11`) und `jobs/job_options.php` erneut abgeglichen. Neue und neu kalkulierte Belegpaare erhalten die PHP-Referenz auf den Hauptauftrag. Spaltenbreite und `INV_CHILD_NOFREETEXT` werden berücksichtigt; bei gesetztem Parameter wird der Kuriertext des Hauptauftrags übernommen. Kundeninterne Rechnungshinweise bleiben ausgeschlossen.
- Die Rechnungsvorschau zeigt Änderungen an Beleg und Gegenbeleg. Die Bestätigung aktualisiert alle betroffenen Texte atomar. Preise und Stationsnachweise bleiben erhalten. Eine Einzelaufbereitung des Unterbelegs ändert nur dessen eigenen Rechnungstext. Geänderte Familienbeziehungen, Vorgaben, Belegtexte, Rechnungszuordnungen und unausgeglichene Paare verhindern eine veraltete Übernahme.
- **1255 Tests: 1252 bestanden, drei übersprungen, keine Fehler**, 21 gezielte Tests und 14 Frontendtests erfolgreich. Geprüft: späte Fehler mit vollständigem Rollback, Wiederholung, Konfigurationswechsel, Gegenbeleg, Fremdniederlassung, Zyklen und unveränderte Finanzdaten. Archiv `work/child-invoice-verify.log`, 911 Quelldateien.
- Browsernachweis `work/child-invoice-ui-verification.json`: zwei verbundene Belege, genau eine bestätigte synthetische Schreibanfrage; Layout nach Korrektur erneut geprüft. Screenshot `work/unternehmerbelege-vorschau-2026-10-18.png`. Lokal gestartet: Health UP, DB verbunden, sechs Assets identisch (`work/child-invoice-deployment.json`). Keine echten Aufträge verändert. Weitere Sonderfälle der Preisberechnung und Aufbereitung bleiben im laufenden Abgleich.

## 18. Oktober 2026 – Aufbereitung angenommener Aufträge

- Aktuelle Serverquellen `jobs/job_options.php` (SHA-256 `bfc6d2a725092142d36dfb93dd8ea9ae71408961c8abe5f77f82ab1e87bd9e80`), `global.inc.php` und `get_job_distance.php` frisch gelesen; alte Auftragsmaske lesend geprüft. Zentrale Bearbeitung, Preisberichtigung und Neukalkulation merken jetzt auch Status 1 vor. Die Automatik verarbeitet angenommene Hauptaufträge einschließlich Sonderprovision, Kilometer, CO₂e, Ausführungsniederlassung und Rechnungsausgabe. Status, Annahme-/Abschlusszeiten und Stationsnachweise bleiben erhalten. Ohne Abschlussdatum bleibt die historische Fahrzeug-Partnerprovision entsprechend PHP bei null.
- Rückruf, Storno, Export oder Rechnungszuordnung machen alte Vormerkungen hinfällig, ohne Buchungsdaten zu verändern. Änderungen während der Schnittstellenanfrage verhindern die Übernahme. Adressfehler können bei eingerichtetem Nachhaltigkeitsreport bereits im angenommenen Auftrag gemeldet werden; die Meldung über fehlenden Abschlusskurier bleibt auf erledigte Aufträge begrenzt. Die manuelle CO₂e-Nachbearbeitung bleibt unverändert am erledigten Hauptauftrag.
- **1251 Tests: 1248 bestanden, drei übersprungen, keine Fehler**, 32 gezielte Tests, 14 Frontendtests und Build erfolgreich. Ein fehlender Kurier in der isolierten Testfixture wurde ergänzt; der anschließende gezielte und vollständige Lauf ist erfolgreich. Geprüft: Bearbeitung/Retry, Queue-Duplikate, spätes Auditversagen und Rollback, Lebenszykluswechsel während Berechnung, unveränderte geschützte Aufträge, fehlender Kurier und späterer regulärer Abschluss. Archiv `work/accepted-processing-verify.log`, 908 Quelldateien.
- Browsernachweis `work/accepted-processing-ui-verification.json`: Status Angenommen, neue Aufbereitungsanzeige, zwei reine Statusabfragen, keine Writes. Screenshot `work/angenommener-auftrag-aufbereitung-2026-10-18.png`. Lokal gestartet: Health UP, DB verbunden, sechs Assets identisch (`work/accepted-processing-deployment.json`). Keine echten Aufträge oder externen Berechnungen ausgelöst. Die Automatik bleibt in der tatsächlichen Konfiguration deaktiviert. Unternehmerbelegtexte und weitere Sonderfälle werden weiter mit dem Server abgeglichen.

## 18. Oktober 2026 – Betriebsbenachrichtigungen der Abschlussprüfung

- Aktuelles `tools/get_job_distance.php` vom Server abgeglichen (SHA-256 `a4c69474277fea307767f8946a34e24f7fcaa5ca83175b02d56139541f4217c9`). Fehlender Ausführungskurier und eindeutig einer Station zugeordnete Adressfehler werden als eigene Vorfälle gespeichert. Adressmeldungen setzen einen Nachhaltigkeitsreport beim Zahler oder Elternkunden voraus; allgemeine Dienstausfälle lösen diese Meldung nicht aus.
- Versand an die konfigurierte Betriebsüberwachung (`MAIL_SURVEY_ADDRESS_TO`), mit lokal konfiguriertem Absender. Die fest eingetragenen PHP-Entwickler-/Supportadressen werden nicht übernommen. Konfiguration, Freigabe, Auftrag, Rechnungsstand, PHP-Sperre, Adresse und Empfänger werden vor der dauerhaften Versandreservierung erneut geprüft. Parallelaufrufe senden genau einmal. Unklare SMTP-Antwort oder fehlender Abschlussbeleg bleiben offen und werden nicht automatisch erneut versendet. Die Auftragsdetails zeigen Versandbelege rein lesend.
- **1250 Tests: 1247 bestanden, drei übersprungen, keine Fehler**; 28 gezielte Prüfungen erfolgreich. Die zunächst versehentlich gewählte benachbarte Mail-Testgruppe wurde durch die korrekte SQL-Testgruppe ersetzt. Enthalten: Parallelversand, Empfängerwechsel, Elternreport, behobener Fehler, neue Adresse, SMTP-Unklarheit, Fehler nach Versand und vollständiger Rollback vor Versand. Archiv `work/completion-alert-verify.log`, 907 Quelldateien.
- Browsernachweis `work/completion-alert-ui-verification.json`: zwei Statusabfragen, keine Schreibanfrage; Screenshot `work/abschluss-fehlermails-2026-10-18.png`. Lokal gestartet: Health UP, DB verbunden, sechs Assets identisch (`work/completion-alert-deployment.json`). Keine echten E-Mails oder Aufträge verändert. Automatik bleibt während des PHP-Parallelbetriebs aus. Angenommene Aufträge und weitere Unternehmer-Sonderfälle bleiben im laufenden Abgleich.

## 18. Oktober 2026 – Vollständigkeitsprüfung der Kundenerfassung

- Frischer Serverabgleich `include/caglobal.inc.php::check_jb_incomplete` (SHA-256 `1f27316a4005535136b03db60f713a54a1d7a588892d8948e5832000417def11`) und `jobs2/job_options.php` (`69651fa561f51a157ca8c49aef7f6f1ae27c80072af86f2c1e67b85ae41bfc63`). Kundenkonten erhalten bei zulässiger leerer Auftrags-/Stationskommission nicht mehr allein deswegen das Unvollständig-Kennzeichen. Die gesonderte Pflichtfeldfreigabe bleibt wirksam. Zentrale Eingaben prüfen die Referenzvorgaben unverändert.
- Gemeinsame Prüfung bei Neuanlage und kundenseitiger Vollbearbeitung berücksichtigt die Ausnahme. Explizite Nachbearbeitung, Listenkunden, fehlende/zu kleine bzw. vollständig rabattierte Preise bleiben unvollständig. PZM-Detailzeilen vom Typ z sind wie Grundpreise keine eigenständige relevante Fahrt. Für Nacherfassungen mit Nachhaltigkeitsreport bei Zahler oder Elternkunde ist ein positiver CO₂e-Wert erforderlich; ein vorhandener Nullwert reicht nicht.
- **1246 Tests: 1243 bestanden, drei übersprungen, keine Fehler**, 57 gezielte Prüfungen erfolgreich. SQL: Neuanlage/Bearbeitung ohne Referenzen, weiter wirksame Pflichtfelder, Konfigurationswechsel nach Vorschau, ausdrückliche Kunden-Nachbearbeitung, Erhalt bestehender Kennzeichen, identische Wiederholung und vollständiger Rollback bei spätem Auditfehler. Archiv `work/entry-completeness-verify.log`, 903 Quelldateien. Frontend unverändert gegenüber dem zuvor geprüften Build. Lokal gestartet: Health UP, DB verbunden, sechs Assets identisch (`work/entry-completeness-deployment.json`). Keine echten Aufträge verändert. Weitere Teilfunktionen bleiben im laufenden Serverabgleich.

## 18. Oktober 2026 – Wiederholbare Abschlussaufbereitung

- Aktuelle Serverquellen `include/global.inc.php` (`ceb60bd61a1ae01729c151b78586ab8c5df301cb595e34eae8fbd923f71bcdd9`), `tools/get_job_distance.php` (`a4c69474277fea307767f8946a34e24f7fcaa5ca83175b02d56139541f4217c9`) und `include/caglobal.inc.php` frisch per SSH abgeglichen; alte Erfassungs-UI lesend geprüft. Native Vormerkung bei Nacherfassung, finalem Abschluss, zentraler Bearbeitung und Preisänderung abgeschlossener Aufträge. Verarbeiter berücksichtigt außerdem die PHP-Warteschlange vom Typ 220.
- Abgeschlossene Hauptaufträge erhalten Sonderprovision, Calculator-/geschützte oder berechnete Kilometer, positive CO₂e, historische Fahrzeug-Partnerprovision, Ausführungsniederlassung, Kunden-/Kurier-Rechnungsausgabe, Calculator und B2B-Positionen gemeinsam. Externe Abfragen erfolgen außerhalb der Buchungstransaktion; eine erneute Prüfung verhindert veraltete Ergebnisse. Erst nach erfolgreicher Buchung werden die verarbeiteten Vormerkungen quittiert. Fehler bleiben sichtbar und wiederholbar; ein PHP-Semaphor verhindert parallele Bearbeitung desselben Auftrags.
- Der weiterhin auf MyISAM liegende Routencache wird separat aus einer dauerhaften InnoDB-Vormerkung aufbereitet. Teilweise erfolgreiche Cache-Schreibvorgänge werden beim Wiederanlauf erkannt; neuere Routen und Typ 9 bleiben erhalten. Eine geänderte Stationsadresse beendet die veraltete Vormerkung als überholt, ohne die bereits gespeicherten Buchungsdaten anzutasten. Die Workbench zeigt Verarbeitungs-/Fehler-/Cache-Status und bietet eine rein lesende Aktualisierung.
- **1240 Tests: 1237 bestanden, drei übersprungen, keine Fehler**; zuletzt 16 gezielte Prüfungen, 14 Frontendtests und Build erfolgreich. Der vollständige Lauf schließt Rollback nach spätem Auditfehler, doppelte Queue-Einträge, Wiederholung ohne weitere Schnittstellenaufrufe, MyISAM-Teilfehler, geänderte Calculator-Kilometer/Adressen, Konkurrenzänderungen, PHP-Sperre, fehlenden Kurier, Rechte und Niederlassungsfreigabe ein. Zwei zunächst veraltete Testannahmen zu neuer Vormerkung und Scheduler-Durchlaufposition korrigiert; abschließender Gesamtlauf erfolgreich. Archiv `work/completion-processing-verify.log`, 901 Dateien im archivierten Abschluss-Build.
- Isolierter Browsernachweis `work/completion-processing-ui-verification.json`, Screenshot `work/abschlussaufbereitung-status-2026-10-18.png`: Statusanzeige und Aktualisierung ohne schreibende Anfrage. Lokal gestartet: Health UP, DB verbunden, sechs Assets identisch (`work/completion-processing-deployment.json`). Keine echten Aufträge oder CO₂-/Mail-Anfragen ausgelöst. Automatik bleibt aus; Aktivierung benötigt `ORDER_COMPLETION_WORKER_ENABLED`, `ORDER_COMPLETION_PHP_STOPPED` und explizite Niederlassungen. Nur `.env.example` ergänzt, tatsächliche `.env` unverändert. Gesondert im weiteren Abgleich: automatische Fehlermails, Aufbereitung noch nicht abgeschlossener Aufträge und Unternehmer-Sonderfälle; keine Gesamtparität behauptet.

## 18. Oktober 2026 – Reguläre Rechnungsaufbereitung

- `mk_jb_invtext`, `mk_jb_invtext_full`, `save_jb_invtext`, `checkDiscountStr` und `getJobCosts` frisch vom Server gelesen; aktuelle Erfassungs-UI geprüft. SHA-256 `caglobal.inc.php`: `1f27316a4005535136b03db60f713a54a1d7a588892d8948e5832000417def11`, `services_func.inc.php`: `4bd29ac9ef3b0cdb5194091c90c56740868e9d9b4c8fdfde4229f8720a6d7a10`.
- Reguläre Aufträge bieten jetzt Vorher-/Nachher-Vorschau und bestätigte Aktualisierung von Kunden-/Kuriertext, Calculator-Zeilen und B2B-Positionen. Enthalten sind Stationen/Referenzen, Kunden- und Niederlassungsdruckvorgaben, Listenmodus, interne Rechnungshinweise, Fahrzeug-/Mitarbeiterangaben, Maut, CO₂e, Leistungen, PZM-Faktoren und Rabatte. Lange NG-PZM-Zeilen werden nur aus übereinstimmender gespeicherter Kalkulation rekonstruiert; widersprüchliche Belege verlangen eine Neukalkulation. Die PHP-Textfunktion vertauscht 1/2; NG verwendet ausdrücklich die Speicherbedeutung aus der PHP-Erfassung (2=Abholung, 1=Anlieferung).
- Vorschau bleibt lesend; Speicherung prüft Auftrag, Druckparameter, Calculator und B2B-Stand erneut. Verarbeitete/fremde B2B-Zeilen bleiben geschützt; wiederholte Speicherung ist eindeutig. Calculator-Kilometer setzen Marker c; Änderungen oder Entfernung entfernen veraltetes CO₂e und setzen Nachbearbeitung. Kunden-/Kurierbeträge und Zustellnachweise bleiben erhalten. Bearbeitete reguläre Aufträge zeigen nun ebenfalls den Aufbereitungsbedarf.
- **1235 Tests: 1232 bestanden, drei übersprungen, keine Fehler**; 16 gezielte Prüfungen, 14 Frontendtests und Build erfolgreich. SQL prüft Vorschau ohne Writes, geänderte Parameter/Stationen, verarbeitete B2B-Positionen, späten Rollback, Wiederholung, MyISAM-Schreibsperre, Rechte, Fremdniederlassung, Storno, Export und die Umschaltung des Listen-/Kuriermodus. Ein generischer Java-Testtyp wurde vor dem erfolgreichen Abschlusslauf korrigiert. Archiv `work/order-invoice-verify.log`, 896 Dateien.
- Browser mit synthetischen Daten: Vorschau verworfen, erneut geöffnet, nach Pflichtbestätigung genau einmal gespeichert; klare Abhol-/Anlieferlabels und Trennung der Texte (`work/order-invoice-ui-verification.json`, `work/rechnungsausgabe-vorschau-2026-10-18.png`). Lokal gestartet: Health UP, DB verbunden, sechs Assets identisch (`work/order-invoice-deployment.json`). Keine echten Aufträge verändert. Automatische Abschlussverarbeitung und weitere Sonderfälle bleiben offen; die aktive Queue ist derzeit leer, `phoenix_log.route` weiterhin MyISAM (nur Schema/Aggregate gelesen).

## 18. Oktober 2026 – Historische Kurier-Sonderprovision

- Aktive Funktion `check_cr_agio` im aktuellen Server-PHP abgeglichen: tatsächlicher Kurier, Rechnungskunde und zum Auftragsdatum gültige Sonderprovision. Bei Abschluss und zentraler Bearbeitung werden Preispositionen 7/10 und Frachtvergütung gemeinsam aktualisiert. Die ungewöhnliche variable Serviceformel folgt dem PHP; ohne Provisionsabzug bleibt die Vergütung unverändert. Änderungen markieren die Rechnungsausgabe und aktualisieren die interne Niederlassungsvergütung.
- **1224 Tests: 1221 bestanden, drei übersprungen, keine Fehler**. Historienwechsel, zukünftige/fremde Tarife, Kostensplit ohne Zahler, Wiederholung und vollständiger Rollback geprüft. Ein zuerst gefundener Sonderfall ohne Zahler und ohne Abzug wurde korrigiert; anschließender Gesamtlauf erfolgreich. Archiv `work/courier-agio-verify.log`, 892 Dateien.
- Lokal gestartet: Health UP, Datenbank verbunden, sechs Assets identisch (`work/courier-agio-deployment.json`). Keine echten Aufträge geändert. Die automatische Abschlusswarteschlange bleibt während des PHP-Parallelbetriebs deaktiviert; die reguläre Rechnungsaufbereitung wird als nächster Baustein ergänzt.

## 18. Oktober 2026 – Kilometer und CO₂e nach Auftragsabschluss

- Aktuelle Serverquellen `tools/get_job_distance.php`, `tools/co2e_sendReq.php`, `locating/xServer.inc.php` und `include/services_func.inc.php` direkt per SSH geprüft; alte Auftragsmaske lesend angesehen. Abschlusskilometer summieren normale Google-Straßenstrecken zwischen Stationen, ohne PZM-Preisroute. Mit m/M oder exakt c geschützte Kilometer bleiben einschließlich Präzision unverändert. CO₂e verwendet tatsächliches Fahrzeug, Sendungsgewicht oder halbe Nutzlast, Fahrzeugtyp/Umweltplakette und aktuelle Faktoren. Partnerprovision aus der am Abschlussdatum gültigen Fahrzeughistorie.
- Native Nachbearbeitung unter „Kilometer / CO₂e bearbeiten“: automatische Vorschau oder begründete manuelle Werte (Kilometer mit drei, CO₂e mit zwei Nachkommastellen). Vorschau bindet Auftrag, Fahrzeug, Faktoren und Provisionshistorie; veränderte oder abgelaufene Daten erfordern neue Berechnung. Speicherung schreibt Preise 11/12/14, Versionsstand, Rechnungsaufbereitung und Historie atomar. Wiederholung funktioniert auch nach verlorenem Vorschaucache. Nachbearbeitungskennzeichen bleiben zur Prüfung erhalten; exportierte/stornierte/fremde Aufträge sind geschützt.
- **1219 Tests: 1216 bestanden, drei übersprungen, keine Fehler**. 28 gezielte Prüfungen, 14 Frontendtests/Build erfolgreich; Archiv `work/completion-sustainability-verify.log`, 889 Dateien. SQL prüft m/c-Erhalt, Neubestimmung, beide Gewichtsquellen, historischen Tarif, Änderungen während der Vorschau, manipulierte Revision, Ablauf, Rollback nach spätem Metadatenfehler, Wiederholung, Rechte und Lebenszyklus. Frühe Testfixture-/Kompilierfehler behoben; abschließender Gesamtlauf erfolgreich.
- Browser mit synthetischen Daten: 12,345 km erhalten, 3,45 kg CO₂e ergänzt; genau eine Vorschau und Speicherung mit gleicher Vorgangskennung, Pflichtbegründung und eigener Verwerfen-Dialog geprüft (`work/completion-sustainability-ui-verification.json`, `work/nachhaltigkeit-gespeichert-2026-10-18.png`). Keine echten Aufträge oder externen Berechnungen ausgelöst. Lokal gestartet: Health UP, DB verbunden, sechs Assets identisch (`work/completion-sustainability-deployment.json`). Automatische Abschlussverarbeitung und weitere Sonderfälle bleiben im laufenden Abgleich.

## 18. Oktober 2026 – Pflichtprüfung nach Abschluss und Preisänderung

- `check_jb_incomplete` aus dem aktuellen `include/caglobal.inc.php` direkt per SSH abgeglichen: relevante Fahrpreise ab 0,02 EUR, Grundpreis-/Zonentyp-Ausnahme, rabattierter Gesamtbetrag, Auftragsreferenz, Stationsreferenz-Schalter B/C und positive CO₂e bei hinterlegtem Nachhaltigkeitsreport des Zahlers oder Elternkunden. Der Abschlusslauf prüft außerdem den tatsächlichen Kurier. Die Workbench nennt die fehlenden Angaben.
- Native Abschlüsse, zentrale Bearbeitung, Fixpreiskorrektur und abgeschlossene Neukalkulation führen die Prüfung innerhalb ihrer Buchungstransaktion aus. Das Löschen des Unvollständig-Häkchens oder eine Preisberichtigung kann fehlende Referenzen/Emissionen nicht mehr übergehen. Direkte Unternehmerbelege und Gegenbelege erhalten das Kennzeichen gemeinsam; abgerechnete verbundene Belege verhindern eine abweichende Änderung. Bei Neukalkulation erfolgt die Prüfung nach dem gemeinsamen Schreiben der Unternehmerbelege. Vorhandene manuelle Kennzeichen bleiben bei Abschluss/Neukalkulation erhalten.
- **1214 Tests: 1211 bestanden, drei übersprungen, keine Fehler**, zwölf gezielte Prüfungen, 14 Frontendtests/Build. SQL: letzte Station statt Teilabschluss, Preisänderung, Checkbox-Manipulation, aktuelle Referenzregeln, Elternreport, echte Neukalkulation, Belegweitergabe und vollständiger Rollback nach spätem Gegenbelegfehler. Der erste Gesamtlauf meldete einen isolierten Mock-Testfehler; die Prüfgrenze wurde auf den abgeschlossenen Speichervorgang gelegt, der anschließende vollständige Lauf ist erfolgreich. Archiv `work/completion-checks-verify.log`, 885 Dateien.
- Isolierter Browserablauf: 150/90 EUR gespeichert, drei Prüfhinweise und Unvollständig-Kennzeichen bleiben erhalten (`work/completion-checks-ui-verification.json`, Screenshot `work/abschluss-pflichtpruefung-2026-10-18.png`). Geldfelder laden gerundete Centwerte, damit Datenbank-Floatreste keine unveränderte Preiseingabe blockieren. Keine echten Aufträge verändert. Weitere Umsetzung: Kilometer/CO₂e-Nachbearbeitung und automatische Abschlussverarbeitung, deren PHP-Quellen weiter geprüft werden.

## 18. Oktober 2026 – Annahmezeit im Kundenzugang

- Frische Serverquellen `jobs2/job_options.php`, `job_options.tpl.htm`, aktive `job_edit.33.js` und `get_saved_tour.php` geprüft. „Annahme bis“ erscheint bei `MASK_WAITTIME_ENABLED=1`, speichert die Uhrzeit auf dem heutigen Berliner Datum und wird aus Kopien übernommen. Vorbestellungen dürfen eine heutige Annahmefrist vor dem Abholtag haben. Die Kalenderzeit ist in der Vorschau sichtbar und gegen Änderungen zwischen Vorschau und Speicherung abgesichert.
- Kundenbearbeitung lädt/ändert/leert diese Zeit. Ist das Feld ausgeblendet, bleiben bestehende Werte erhalten; manipulierte Eingaben werden abgewiesen. Neue optionale Felder verändern alte Speicherbelege ohne Annahmezeit nicht. Das zentrale Nichtverfügbarkeitsstorno wird nicht in den Kundenzugang eingeblendet: PHP schließt dieses Feld dort ausdrücklich aus.
- **1209 Tests: 1206 bestanden, drei übersprungen, keine Fehler**, sieben gezielte Prüfungen und 14 Frontendtests/Build erfolgreich. SQL: Anlage, Kopie ohne altes Datum, Vorbestellung, Wiederholung, geänderte Freigabe, Vorschauabweichung, Löschen/Erhalt ausgeblendeter Werte sowie vollständige Rollbacks bei Anlage und Bearbeitung. Archiv `work/customer-acceptance-verify.log`, 882 Quelldateien. Lokal gestartet: Health UP, DB verbunden, sechs Assets identisch (`work/customer-acceptance-deployment.json`).
- Browser: Änderung 15:37 → 16:25, Vorschau und Speicherpayload geprüft; `work/customer-acceptance-ui-verification.json`, Screenshot `work/kundenerfassung-annahmezeit-2026-10-18.png`. Die alte jobs2-UI geöffnet: Tourenframe liefert HTTP 500 und Optionsframe teilweise nicht ersetzte Platzhalter; keine Daten eingetragen/gespeichert. SHA-256 Options-Template `d0d59bca7232dd11f7988583da672ccde92f217f64378e5c11186afccd57f0be`, aktives JS `8cbfd4f2fa4325183893675d567123413cda32ada7f1c07aca88e5593a55edf6`. Weiterer Abgleich: Abschlussnachbearbeitung für Kilometer/CO₂e und Pflichtangaben.

## 18. Oktober 2026 – Gespeicherter KAE-Rabatt bei Neukalkulation

- Aktuelle Serverquellen `jobs/job_options.php`, `jobs2/job_options.php` und `jobs/get_saved_tour.php` abgeglichen. Bereits gespeicherter Eigenleistungsrabatt (Preisposition 13) bleibt bei zentraler Neukalkulation erhalten; die Oberfläche zeigt den unveränderbaren Prozentsatz. Festpreis- und Tarif-Frachtvergütung folgen den unterschiedlichen PHP-Rundungs- und Rabattregeln, ohne den Tarifrabatt doppelt abzuziehen. Die Bemerkung der Rabattposition erhält die neue Berechnungsbasis.
- **1206 Tests: 1203 bestanden, drei übersprungen, keine Fehler**; 31 gezielte Prüfungen und 14 Frontendtests/Build erfolgreich. SQL: veränderte Rabattposition erfordert neue Vorschau, fremde aktuelle Kundenvorgaben überschreiben keinen gespeicherten Rabatt, doppelte/ungültige Positionen werden abgewiesen, spätes Schreibversagen rollt Auftrag/Preise/Version vollständig zurück, Wiederholung bleibt eindeutig. Archiv `work/stored-discount-verify.log`, Manifest 879 Dateien.
- Isolierter Browserablauf mit 10 % Bestandsrabatt: Vorschau, einmalige Speicherung, Auftragswert 109,00 EUR und Frachtvergütung 73,15 EUR; `work/stored-discount-ui-verification.json`, Screenshot `work/kae-rabatt-anzeige-2026-10-18.png`. Lokal gestartet: Health UP, DB verbunden, sechs Assets identisch (`work/stored-discount-deployment.json`). Reale Daten nur aggregiert gelesen: 46 Rabattpositionen mit 1,5 %, keine Duplikate. Keine echten Aufträge verändert. Gesamtparität bleibt im laufenden Abgleich.

## 18. Oktober 2026 – Ausführende Niederlassung und interne Vergütung

- Aktuelles `tools/get_job_distance.php` direkt vom Server geprüft: tatsächlicher Kurier bestimmt `hq_id_exec`, bestehende Ausführungsniederlassung ist der PHP-Rückfall. Exportkennzeichen gilt bei Fremdniederlassung oder ausdrücklich gesetztem BWV-Marker; Fernverkehr allein reicht nicht. Die lokale Vorgabe `MASK_HQ_ID_EXEC_PRICE_RATE` ist ein Faktor ohne globalen Rückfall. Erst Margenanteil auf zwei Stellen runden, anschließend Frachtvergütung addieren.
- Native Auftrags-/Stationsabschlüsse aktualisieren diese Daten atomar mit Abschluss, Kuriernachricht und Vorgangsbeleg. Neukalkulation, manuelle Preisberichtigung und BWV-Retourenvergütung halten die Zuordnung abgeschlossener Aufträge aktuell. Offene Teilabschlüsse und Gegenbuchungen werden nicht neu zugeordnet. Fehlende Zuordnung, ungültige Faktoren und mehrdeutige BWV-Marker werden gemeldet.
- **1202 Tests: 1199 bestanden, drei übersprungen, keine Fehler**, 25 gezielte Tests erfolgreich; bestehendes geprüftes Frontend unverändert. SQL: eigene/fremde Niederlassung, explizites BWV ohne Fernverkehr, Fernverkehr ohne BWV, letzter Teilabschluss, kein globaler Parameter-Rückfall, Neukalkulation, Festpreisänderung, Retourennachvergütung, wiederholte Speicherung und vollständige Rollbacks. Archiv `work/execution-accounting-verify.log`, 876 Quelldateien. Lokal gestartet: Health UP, DB verbunden, sechs Assets identisch (`work/execution-accounting-deployment.json`).
- Aktuellen Bestand nur aggregiert gelesen: zwölf Niederlassungsvorgaben mit Faktor 0,5; keine tatsächlichen Aufträge oder Vergütungen verändert (`work/kae-discount-read.json`). Gesamtparität bleibt weiter im Abgleich; nächster bestätigter Punkt ist die Erhaltung gespeicherter KAE-Rabatte bei zentraler Neukalkulation.

## 18. Oktober 2026 – BWV-Kennzeichen bei Nacherfassungen

- Frischer Serverabgleich mit `jobs/job_options.php`, `jobs/get_saved_tour.php`, aktiver `jobs/job_edit.68.20.js` und `tools/get_job_distance.php` (SHA-256 `a4c69474277fea307767f8946a34e24f7fcaa5ca83175b02d56139541f4217c9`). Das ausdrücklich gesetzte BWV-Kennzeichen ist getrennt vom Fernverkehrsmodus. Die Oberfläche bietet es bei Nacherfassungen an, übernimmt es aus passenden Kopien und entfernt es beim Wechsel von Vorlage/Modus.
- Native Speicherung schreibt den PHP-Marker `jb_bwv=1` und die Exportzuordnung für die eigene ausführende Niederlassung. Neue Vorschau bei Änderung, unveränderte Preise, wiederholbare Anlage und atomarer Rollback bei Markerfehler sind geprüft. Ein Fernauftrag allein setzt nach der aktuellen PHP-Regel vom 30. Juli 2026 das Exportkennzeichen nicht. Alte Wiederholungsbelege ohne das neue optionale Feld bleiben kompatibel.
- **1197 Tests: 1194 bestanden, drei übersprungen, keine Fehler**, 61 gezielte Tests und 14 Frontendtests/Build erfolgreich. Manifest mit 873 Dateien; `work/entry-bwv-verify.log`. Lokal neu gestartet; Health UP, Datenbank verbunden, sechs Frontenddateien identisch (`work/entry-bwv-deployment.json`).
- Browser mit isolierter Fixture: markierte Vorlage, Preisvorschau, Wechsel zur unmarkierten Vorlage, zweite Vorschau und einmalige synthetische Speicherung; `work/entry-bwv-ui-verification.json`, Screenshot `work/nacherfassung-bwv-2026-10-18.png`. Keine echten Aufträge/Mails ausgelöst. Die allgemeine Ausführungs-/Vergütungszuordnung bei Abschluss und nachträglichen Preisänderungen ist der nächste bestätigte Abweichungspunkt.

## 18. Oktober 2026 – Herkunft, Wunschkurier und ergänzte Dauerauftragsregeln

- Aktuelle Serverquellen weiter lesend geprüft: `jobs/get_saved_tour.php` (`9d4bd9f4806fa861da09918b922e2a1fc8bc0677affa5a473ec7f1698a3c8cdb`), aktive `jobs/job_edit.68.20.js` (`845b163033d275911b6f237e63d1313c609ab42d5ac578bd718dd5707f841aba`), `jobs/check_jb_permanent.php` (`d9c35f8e2a3a0c0f0fbaa4a09924cc756356251338807cd213ae707b68776ae3`). Normale Kopien übernehmen jetzt den noch eindeutig verfügbaren Wunschkurier; benannte Tourvorlagen lassen ihn wie PHP frei, außer im persönlichen Buchhaltungskopiermodus.
- Auftragseingang einschließlich sonstigem Freitext wird übernommen. Automatische Herkunft 3/4/5/7/8 ist nur mit passendem Quellauftrag möglich und in der UI gesperrt; Änderungen an der Quelle während Routing/Speichern werden erkannt. Die Kopierquelle wird bei Neuanlage in derselben Transaktion gesperrt. Bereits bestätigte Wiederholungen bleiben lesbar. Der TINYINT(1)-Herkunftscode wird numerisch gelesen, damit JDBC die Werte nicht in Ja/Nein umwandelt. Aktueller Bestand nur aggregiert gelesen (`work/template-identity-read.json`, null Schreibzugriffe).
- Daueraufträge übernehmen ausschließlich ausdrücklich mit m/M markierte Kilometer als manuelle Vorgabe. Die PHP-Sonderregel für Niederlassung 109/Kunde 18260 setzt ab 16 Stationen die Ziele ab Station 2 auf Adresse 3209/Kostenstelle 44549 zurück, nummeriert sie und entfernt die alten Kontakt-/Bemerkungsfelder. Startstation und Quellauftrag bleiben erhalten. Fehlende Zielstammdaten und Fehler bei der Änderung rollen Nachfolger und Kettenverknüpfung vollständig zurück. Im aktuellen Testbestand keine passenden Touren/Zielstammdaten; deshalb ausschließlich mit eigener SQL-Fixture geprüft. Worker bleibt ausgeschaltet.
- **1194 Tests: 1191 bestanden, drei übersprungen, keine Fehler**. 58 gezielte Kopier-/Herkunftsprüfungen, acht Regressionen und 18 Dauerauftragsprüfungen; 14 Frontendtests/Produktionsbuild erfolgreich. Gesamtarchiv `work/template-identity-recurring-rules-verify.log`, Berichte/Manifest mit 870 Dateien. Lokal bereitgestellt: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/template-identity-recurring-rules-deployment.json`). Alte Testerwartungen ohne Wunschkurier wurden auf die bestätigte PHP-Kopiersemantik aktualisiert.
- Browser: KAE gesperrt, Wunschfahrzeug QA9601, Wechsel auf Sonstiges mit „Empfang vor Ort“, zwei Vorschauen und eine synthetische Speicherung. Requests `work/template-identity-ui-verification.json`, Screenshot `work/tourkopie-herkunft-2026-10-18.png`. Keine echten Aufträge oder Mails ausgelöst. Weitere Prüfung: BWV-Kennzeichen der Nacherfassung und dessen Exportzuordnung; keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Kurier-Unteraufträge bei Auftragskopien

- Frischer SSH-Abgleich mit `getJobChildren`/`saveJobChildren` in `include/caglobal.inc.php` (SHA-256 `1f27316a4005535136b03db60f713a54a1d7a588892d8948e5832000417def11`) und `jobs/get_saved_tour.php` (`9d4bd9f4806fa861da09918b922e2a1fc8bc0677affa5a473ec7f1698a3c8cdb`). Kopien übernehmen jetzt Unternehmer/Fahrzeug und Verrechnungsbetrag, ohne alte Beleg- oder Gegenbelegnummern zu übertragen. Die Oberfläche zeigt die übernommenen Zeilen und löscht widersprechende einzelne Frachtvergütungen. Fehlende/mehrdeutige Fahrzeuge müssen ersetzt oder die Zeilen entfernt werden. Nacherfassung, Ausführungsfahrzeug, Niederlassung und Recht 38 werden geprüft.
- Der SQL-Test deckte fehlende Pflichtfelder bei nativen Unternehmerbelegen auf; diese werden jetzt gesetzt. Geprüft sind neue Haupt-/Unter-/Gegenbelege, aktuelle Rabatte, unveränderte Quellbelege, wiederholte Speicherung und vollständiger Rollback bei einem Fehler nach Anlage der Belegpaare. Fremdniederlassung und entzogenes Recht verhindern die Übernahme. Ein Gegenbeleg wird beim Kopieren seines übergeordneten Unterauftrags nicht erneut als Unternehmerzeile behandelt.
- **1189 Tests: 1186 bestanden, drei übersprungen, keine Fehler**, acht gezielte Tests sowie 14 Frontendtests/Build erfolgreich. Manifest mit 864 Dateien; `work/template-couriers-verify.log`. Lokal neu gestartet; Health UP, Datenbank verbunden und alle sechs Frontenddateien zwischen dist/JAR/HTTP identisch (`work/template-couriers-deployment.json`).
- Synthetische UI: Unternehmer QA9602/Betrag 40 EUR, Nacherfassung mit QA9601, aktuelle Verrechnung 38 EUR, Vorschau und einmalige Testanlage. Requests geprüft in `work/template-couriers-ui-verification.json`, Screenshot `work/tourkopie-unternehmer-2026-10-18.png`. Keine echten Buchungen oder E-Mails ausgelöst. Weitere Kopierdetails und übrige Funktionsparität bleiben im Abgleich.

## 18. Oktober 2026 – Angebots-, Verteilungs- und ASAP-Kopien

- Aktuelles `jobs/get_saved_tour.php` direkt vom Server geprüft (SHA-256 `9d4bd9f4806fa861da09918b922e2a1fc8bc0677affa5a473ec7f1698a3c8cdb`), dazu `checkOffer` und Verteilungsregeln aus aktiver `jobs/job_edit.68.20.js` (`845b163033d275911b6f237e63d1313c609ab42d5ac578bd718dd5707f841aba`). Kopien behalten jetzt Angebot, freigegebene Verteilung an alle Kuriere und den gespeicherten `longhaul_deselected`-Vermerk. Eine nachfolgende andere Vorlage setzt diese Werte vollständig zurück.
- Angebote erzwingen manuelle Disposition/unvollständig und übernehmen keine Versicherung, Serienfortsetzung oder ausführendes Fahrzeug. Verteilung wird gegen aktuelle CC24-Freigabe und widersprechende Dispositionsvorgaben geprüft; nicht mehr anwendbare Vorgaben erhalten einen Hinweis. Nichtverfügbarkeitsstorno bleibt bei Angebot/Verteilung ausgeschaltet. Die UI zeigt die erzwungenen Kennzeichen korrekt und verhindert widersprüchliche Eingaben.
- **1186 Tests: 1183 bestanden, drei übersprungen, keine Fehler**, sieben gezielte Prüfungen sowie 14 Frontendtests/Build erfolgreich. SQL prüft Angebotsanlage/-kopie, Verteilung, erneute Berechtigungsprüfung nach CC24-Änderung und Wiederholung. `work/template-dispatch-verify.log`, Berichte/Manifest mit 861 Dateien.
- Synthetischer Browserablauf: Angebotsvorschau, Wechsel zu Verteilungsvorlage, zurückgesetzte ASAP-/Angebotsvorgaben und einmalige Testanlage; Request-Inhalte geprüft (`work/template-dispatch-ui-verification.json`). Screenshots `work/tourkopie-angebot-2026-10-18.png`, `work/tourkopie-verteilung-2026-10-18.png`. Keine echten Aufträge verändert. Unterauftrags- und weitere Detailkopien bleiben im Abgleich; keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Termine bei Auftrags- und Tourkopien

- Frischer SSH-Abgleich mit `jobs/get_saved_tour.php` (SHA-256 `9d4bd9f4806fa861da09918b922e2a1fc8bc0677affa5a473ec7f1698a3c8cdb`, Zeilen 204–219, 310–335, 387–392), aktiver `jobs/job_edit.68.20.js` (`845b163033d275911b6f237e63d1313c609ab42d5ac578bd718dd5707f841aba`) und `include/caglobal.inc.php` (`1f27316a4005535136b03db60f713a54a1d7a588892d8948e5832000417def11`, `job_was_afterwards`). Konkrete Vorbestellungs-/Dauerauftragskopien übernehmen Beginn, alle elf Rhythmen, Wochentage und Serienende. Tourkonserven behalten den Rhythmus als Vorgabe, übernehmen aber keinen alten Ausführungstermin und kein altes Serienende. Persönliche Buchhaltungsmodi behalten Vorrang.
- Warnzeit wird übernommen; bei `MASK_WAITTIME_ENABLED` auch die Annahmeuhrzeit, wie in PHP auf den heutigen Berliner Tag bezogen. Vergangener Beginn bzw. verstrichene Annahmeuhrzeit erhalten einen sichtbaren Prüfhinweis; bestehende serverseitige Terminprüfung bleibt wirksam. Ehemalige Nacherfassungen werden über Listenerfassung oder historische Vorgänge 1/25 erkannt, bevor ihr ursprünglicher Termin angeboten wird. Keine Erledigungsstände oder Serienverknüpfungen werden kopiert.
- **1183 Tests: 1180 bestanden, drei übersprungen, keine Fehler**, zehn gezielte Prüfungen einschließlich Auftragsstapel-Regression, 14 Frontendtests/Build erfolgreich. SQL prüft Serienbeginn/-ende, Warnzeit, Annahmefrist, Konservenabgrenzung, Konfigurationswechsel, Historie und Wiederholung. `work/template-schedule-verify.log`, Berichte/Manifest mit 858 Dateien.
- Synthetische Browserprüfung mit Datumsausgabe entsprechend der Spring-JSON-Konfiguration: Beginn 19.10.2026 09:00, Warnzeit 08:45, Serienende 23.10., Mo/Mi/Fr, Annahmefrist angepasst. Vorschau-/Speicherrequests geprüft (`work/template-schedule-ui-verification.json`), Screenshot `work/tourkopie-termine-2026-10-18.png`. Keine echten Aufträge geändert. Weitere Kopier-/Bearbeitungsdetails bleiben im fortlaufenden Abgleich; keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Höherversicherung bei Auftragskopien

- Aktuelle Serverquellen abgeglichen: `jobs/get_saved_tour.php` SHA-256 `9d4bd9f4806fa861da09918b922e2a1fc8bc0677affa5a473ec7f1698a3c8cdb`, `include/caglobal.inc.php` `1f27316a4005535136b03db60f713a54a1d7a588892d8948e5832000417def11`, `saveJobInsurance` Zeilen 428–505. Aktuelle PHP-Erfassung zeigt den zugehörigen Höherversicherungsblock. Tourkopien übernehmen Warenwert, einen der fünf Tarife und den Sonderfall; die ursprüngliche Buchungs-ID wird nicht an den Kopierentwurf weitergegeben. Die neue Anlage erhält eine eigene Versicherungsbuchung, während der Quellauftrag unverändert bleibt.
- Bestand lesend geprüft: 584 Versicherungsmetadatensätze, davon 488 verknüpft; sämtliche 488 Kontextformate werden erkannt. Leeres Sonderfallfeld bedeutet wie in PHP false. Metadaten ohne Buchung übernehmen keine Versicherung. Mehrdeutige oder ungültige verknüpfte Angaben brechen das Laden mit konkretem Hinweis ab (`work/template-insurance-read.json`, keine Schreibzugriffe).
- SQL-Prüfung deckte außerdem zwei vorhandene Anlagefehler auf: Pflichtwerte `job.jb_service`, `job.jb_scrm` und `tour.tr_cs_freetext` fehlten; `tourservice` wurde fälschlich als Tabelle mit generierter ID behandelt. Beide Fehler korrigiert, auch für neue Versicherungsaufträge ohne Vorlage. Hauptauftrag, Versicherungsauftrag, Preis und Verknüpfung werden gemeinsam zurückgerollt; Wiederholung erzeugt keine zweite Buchung.
- **1178 Tests: 1175 bestanden, drei übersprungen, keine Fehler**, 16 gezielte Prüfungen sowie 14 Frontendtests/Build erfolgreich. `work/template-insurance-verify.log`, Berichte/Manifest mit 855 Dateien. Synthetische Browserprüfung einschließlich exaktem Warenwert 100000,55, Tarif 5 und Sonderfall in Vorschau-/Speicherrequest: `work/template-insurance-ui-verification.json`, `work/tourkopie-versicherung-2026-10-18.png`. Keine echten Versicherungen oder Aufträge angelegt. Weitere Kopierdetails bleiben im Abgleich; keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Dispositionsvorgaben bei Tourkopien

- Aktuelle PHP-Maske lesend geprüft, `jobs/get_saved_tour.php` erneut vom Server gelesen (SHA-256 `9d4bd9f4806fa861da09918b922e2a1fc8bc0677affa5a473ec7f1698a3c8cdb`, Zeilen 59, 418, 485, 813–819). Benannte Tourvorlagen leeren den Besteller und verwenden bei fehlender Auftragskommission die Referenz der ersten Station. Gewöhnliche Auftragskopien erhalten ihren Besteller und ihre Auftragsreferenz. `MASK_MANUAL_DISPOSITION` wird bei Vorlagen neu ausgewertet; persönliche Buchhaltungsmodi erhalten keine widersprüchliche Dispositionsvorgabe. Unvollständig- und Nichtverfügbarkeitsstorno-Kennzeichen werden übernommen.
- **1175 Tests: 1172 bestanden, drei übersprungen, keine Fehler**, sieben gezielte Tests, 14 Frontendtests und Build erfolgreich. SQL prüft neue Bestellerangabe, Referenz, Dispositionsstatus 9, beide Kennzeichen, geänderte Konfiguration und einmalige Speicherung. Quellen bleiben unverändert. Berichte `work/template-options-targeted.log`, `…-verify.log`, Manifest mit 852 Dateien.
- Browserablauf mit synthetischen SQL-Daten und geprüften Vorschau-/Speicherrequests: `work/template-options-ui-verification.json`, Screenshot `work/tourkopie-disposition-2026-10-18.png`. Keine echten Aufträge geändert. Termin- und weitere Kopierdetails bleiben im laufenden Abgleich; keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Preisvorgaben bei Tourkopien

- Frischer SSH-Abgleich von `jobs/get_saved_tour.php` (SHA-256 `9d4bd9f4806fa861da09918b922e2a1fc8bc0677affa5a473ec7f1698a3c8cdb`) und `jobs/job_options.php`: manuelle Kunden-/Kurier-TSZ einschließlich Null/negativen Werten, manuelle Entfernung, Kurier-/Servicevergütung, Fixpreisrabatt und historischer Steuerschlüssel werden übernommen. Rechte und Niederlassungsvorgaben gelten weiterhin. Zonen-Konserven erhalten Zonenberechnung; Fernverkehre übernehmen keine alte Kuriervergütung. Rabatt wird mit dem aktuellen Kundenprozentsatz neu kalkuliert.
- Manuelle Servicevergütung wird nun auch im PHP-Metadatenfeld `jb_cr_serviceprice` gespeichert. Ältere unveränderte NG-Aufträge können den Wert aus ihrem ursprünglichen Erfassungsbeleg zurückgewinnen. Positive, eindeutig verfügbare Steuerschlüssel werden anhand des Quellkennzeichens aufgelöst; technische Steuer-ID 0 wird ausgeschlossen. Entfernung erlaubt die drei in PHP gespeicherten Nachkommastellen.
- **1172 Tests: 1169 bestanden, drei übersprungen, keine Fehler**, gezielte Kopier-/Preisprüfungen und Regression des Auftragsstapels erfolgreich, 14 Frontendtests und Build erfolgreich. `work/template-pricing-verify.log`, Berichte/Manifest mit 849 Dateien. SQL prüft neue Rabattsätze, Steuerabweichung, Metadaten und Rückgriff auf alte Belege. Synthetische Browserprüfung samt Request-Inhalten: `work/template-pricing-ui-verification.json`, `work/tourkopie-preisvorgaben-2026-10-18.png`.
- Lokaler Stand neu gestartet, Health/DB und sechs Frontenddateien identisch geprüft (`work/template-pricing-deployment.json`). Reale Konfiguration nur gelesen (`work/template-pricing-read.json`), keine echten Aufträge geändert. Weitere Kopierdetails werden laufend abgeglichen; keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Kassierstation beim Kopieren von Baraufträgen

- Frischer Serverabgleich von `jobs/get_saved_tour.php` (`9d4bd9f4806fa861da09918b922e2a1fc8bc0677affa5a473ec7f1698a3c8cdb`, Zahlerauswahl Zeilen 511–514) und `jobs/job_options.php` (`bfc6d2a725092142d36dfb93dd8ea9ae71408961c8abe5f77f82ab1e87bd9e80`, Kassiertext Zeilen 2145–2160). Die alte Maske führt den Zahler stationsbezogen; NG setzte beim Laden bisher pauschal Station 1.
- Die Kopie übernimmt jetzt die eindeutige Kassierstation aus vorhandenen Kassiermarkierungen oder der tatsächlichen Barzahler-Kostenstelle. Systembarzahler wird vom echten Zahler unterschieden; freie Stationen mit Kassierhinweis bleiben zuordenbar. Mehrere/fehlende Zuordnungen ergeben eine sichtbare Aufforderung zur Auswahl, keine automatische erste Station. Auch das Löschen der ausgewählten Station verlangt eine neue Auswahl; Touroptimierung erhält eine noch offene Auswahl.
- Alte automatisch erzeugte Kassiertexte/Beträge werden entfernt, freie Stationshinweise bleiben bestehen. Der neue Auftrag erhält genau an der gewählten Station den neu berechneten Betrag. Rechnungskopien haben keine Kassierstation. **1166 Tests: 1163 bestanden, drei übersprungen, keine Fehler**, zehn gezielte Tests sowie 14 Frontendtests/Build erfolgreich; SQL prüft native und PHP-artige Quelle, Zahlung am Ziel, neue Beträge, Wiederholung und widersprüchliche Quellen. `work/template-cash-verify.log`, Berichte/Manifest mit 846 Dateien.
- Browser mit synthetischen Daten: Station 2 automatisch übernommen, gespeichert; uneindeutige zweite Vorlage blockiert vor Preisvorschau, danach bewusste Wahl von Station 2 und erfolgreiche Testanlage. `work/template-cash-ui-verification.json`, `work/tourkopie-kassierstation-2026-10-18.png`. Keine echten Aufträge geändert. Weitere Kopierdetails einschließlich manueller Preisvorgaben bleiben im laufenden Abgleich; keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Kurierfilter und Fotos bei Tourkopien

- Erneut direkt vom Server abgeglichen: `jobs/get_saved_tour.php` SHA-256 `9d4bd9f4806fa861da09918b922e2a1fc8bc0677affa5a473ec7f1698a3c8cdb`, aktive `jobs/job_edit.68.20.js` `845b163033d275911b6f237e63d1313c609ab42d5ac578bd718dd5707f841aba`. PHP-Erfassung einschließlich Filter-Schaltfläche lesend kontrolliert; deren Popup wurde vom Browser nicht geöffnet. Verbindliche Kopierlogik aus frischem PHP: Pflicht- und optionale Filter, Abzug aktueller globaler Pflichtfilter, Auswahl je Quellstation via `GET /selection?jbId`.
- Tourkopien stellen nun beide Filterklassen wieder her. Kürzel werden vollständig und unter Beachtung der Groß-/Kleinschreibung behandelt; keine Teiltreffer. Fehlende Katalogkürzel bleiben sichtbar und müssen ausdrücklich entfernt werden. Aktuelle globale Anforderungen und Kundenvorgaben kommen beim Speichern hinzu. Vollständig markierte alte Filtertexte werden aus Stationshinweisen entfernt und mit den aktuellen Beschreibungen neu erzeugt; freie Texte bleiben erhalten.
- Fotoauswahlen werden nach dem lokalen Lesesnapshot vom Fotodienst gelesen, den tatsächlichen Quellstations-IDs zugeordnet und ohne Fotobeweise übernommen. Expliziter Workflow 0 bleibt erhalten. Aktuelles passendes Standardset oder ein eindeutig passendes Set wird vorgeschlagen; bei fehlenden/uneindeutigen Sets bleiben Auswahl und Prüfhinweis sichtbar. Doppelte/ungültige Antworten oder Ausfall brechen das Laden ab, ohne den bisherigen Entwurf zu ersetzen. Ein anderer Zahler setzt die Auswahl zurück; das Laden einer Tour und erneutes Laden des Fotodienstes erhalten die kopierten Werte.
- **1160 Tests: 1157 bestanden, drei übersprungen, keine Fehler**, 52 gezielte Tests, 14 Frontendtests und Build erfolgreich. SQL prüft Filterkopie, fehlendes Kürzel, globale Anforderungen, aktuelle Beschreibungen, einmaliges Speichern, passende Foto-Set-Auswahl, neue Stations-IDs und gesicherte Übertragung ohne alte Nachweise. Rechte-/Niederlassungsprüfung erfolgt vor externen Aufrufen; kein HTTP-Aufruf in der lokalen Lesetransaktion. `work/template-copy-verify.log`, Berichte/Manifest mit 843 Dateien.
- Synthetischer Browserablauf: Kopieren mit Pflicht-/Hinweisfilter und altem Kürzel, simulierten Fotodienstausfall beheben, Auswahl 0/3 erhalten, altes Kürzel entfernen, Preisvorschau und Testanlage. `work/template-copy-ui-verification.json`, Screenshots `work/tourkopie-filter-2026-10-18.png` und `work/tourkopie-fotos-2026-10-18.png`. Keine echten Aufträge/Fotodaten verändert. Keine vollständige Anwendungsparität behauptet; Barzahlungsstation und weitere Kopierdetails werden anschließend geprüft.

## 18. Oktober 2026 – Tracking-E-Mail in der zentralen Erfassung

- Frischer PHP-Serverabgleich: `jobs/job_tour.php` SHA-256 `9dd4e6940748c1a519bdfeed749225bc2d50e71d2c9c1303a594b8bb78a5ba4b`, aktive `jobs/job_edit.68.20.js` `845b163033d275911b6f237e63d1313c609ab42d5ac578bd718dd5707f841aba`, `jobs/job_options.php` `bfc6d2a725092142d36dfb93dd8ea9ae71408961c8abe5f77f82ab1e87bd9e80`. Aktuelle PHP-Erfassung lesend kontrolliert. Tracking-E-Mail je Station ist jetzt auch zentral verfügbar, wenn `cs_tracking` des ausgewählten Zahlers freigegeben ist. Eine Adresse je Station, maximal 60 Zeichen; keine eingebetteten Token oder Steuerzeichen.
- Empfänger gehören zur geprüften Preisvorschau. Freigabe wird unmittelbar beim Speichern unter Kundensperre erneut geprüft; Kunden/Kostenstellen müssen InnoDB sein. Station und Trackingmetadaten werden atomar gespeichert, einschließlich Kopien und vorab angelegter Serientermine. PHP-GPS-Hinweis bei entsprechender Vorgabe. Vorlagen übernehmen nur Empfänger, keine privaten Trackingtoken oder Versandstände. Bestehende Vorgangshashes bleiben für Eingaben ohne neue Trackingfelder kompatibel.
- **1154 Tests: 1151 bestanden, drei übersprungen, keine Fehler**, 58 gezielte Prüfungen sowie 14 Frontendtests/Build erfolgreich. SQL prüft aktivierte/deaktivierte Freigabe, Änderung während Routenermittlung, ungültige Eingaben, Preisvorschauwechsel, Wiederholung, Metadaten-Rollback, MyISAM-Abbruch, Mehrfachkopien, Serientermine und Vorlagen ohne Quelltoken. `work/central-tracking-verify.log`, archivierte Berichte/Manifest mit 839 Dateien.
- Browserprüfung mit SQL-erzeugten synthetischen Daten: Tour laden, Zustellempfänger ändern, Preisvorschau und einmalige Testanlage. Request-Inhalte geprüft, Screenshot `work/zentralenerfassung-tracking-2026-10-18.png`, `work/central-tracking-ui-verification.json`. Keine echten Aufträge oder Mails. Hintergrund-Mailverarbeitung bleibt im PHP-Parallelbetrieb ausgeschaltet. Keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Automatische Dauerauftragsfortsetzung

- Frischer Serverabgleich: `jobs/check_jb_permanent.php` SHA-256 `d9c35f8e2a3a0c0f0fbaa4a09924cc756356251338807cd213ae707b68776ae3`, `jobs/get_saved_tour.php` `9d4bd9f4806fa861da09918b922e2a1fc8bc0677affa5a473ec7f1698a3c8cdb`, `include/caglobal.inc.php` `1f27316a4005535136b03db60f713a54a1d7a588892d8948e5832000417def11`. Die alte Seite `jobs/jb_special.php` wurde lesend geöffnet, liefert derzeit HTTP 500; dieser Abgleich beruht auf dem aktuellen Servercode.
- Native Verarbeitung erledigter Daueraufträge: elf Rhythmen, Niederlassungsfeiertage, Serienende einschließlich PHP-Mitternachtsgrenze, zuletzt erledigte Aufträge innerhalb der PHP-Zweimonatsgrenze, ursprüngliche Vorlage bei vorübergehender Änderung, ursprünglicher Wunschkurier, manuelle Disposition, aktuelle Kalkulation/Steuer/TSZ-Regeln, Kommissionsnummern und Tourname. `MASK_COURIER_IMMEDIATE` wird bei automatischer Fortsetzung wie in PHP nicht angewandt. Tracking-Empfänger erhalten neue Stationsmetadaten ohne frühere Token/Versandstände; Fotoauswahl wird lesend übernommen und über die bestehende gesicherte Fotoübertragung publiziert. Erledigungsnachweise, Artikelidentitäten und Kurier-Unterbuchungen werden nicht erneut gebucht.
- Auftrag, Vorgänger-/Nachfolgerverknüpfung und Fortsetzungsbeleg sind ein atomarer InnoDB-Vorgang. Parallel gestartete NG-Verarbeiter erzeugen nur einen Nachfolger. Geänderte Vorlagen/Preise, nicht eindeutige Wunschkuriere, fehlende Vorlagen/Kalender, Angebote und eigenständige Unteraufträge werden ausdrücklich blockiert; keine stille vereinfachte Kopie. Fehlgeschlagene Vorgänge bleiben in Verwaltung → Kessel Buntes → Daueraufträge sichtbar und werden bei aktiviertem Lauf erneut geprüft. Folgetermine in der Vergangenheit bleiben offene Aufträge, keine Nacherfassung.
- **1152 Tests: 1149 bestanden, drei übersprungen, keine Fehler**; 102 gezielte Tests sowie 14 Frontendtests/Build erfolgreich. SQL-Prüfungen: Feiertag, Enddatum, temporäre Vorlage, atomarer Rollback, zwei parallele Instanzen, Wiederholung, Quellenänderung, neue Tarife, ursprünglicher Wunschkurier, manuelle Disposition, Tracking ohne alten Token, deaktivierter Lauf, sichtbare Fehler und MyISAM-Abbruch. Fotoauswahl einschließlich Workflow 0, doppelte Antworten und Ausfall geprüft. `work/recurring-continuation-targeted.log`, `…-verify.log`, archivierte Berichte/Manifest mit 837 Dateien. SQL-erzeugte Browserdaten und Screenshot `work/dauerauftragsfortsetzung-2026-10-18.png`, `…-ui-verification.json`.
- Reale Konfiguration/Tabellen ausschließlich gelesen (`work/recurring-continuation-read.json`): beteiligte Kernbestände InnoDB, zur Prüfzeit keine wartenden Kandidaten. **Der Hintergrundlauf bleibt mit `RECURRING_ORDER_WORKER_ENABLED=false` deaktiviert.** Vor Aktivierung muss die entsprechende PHP-Fortsetzung abgeschaltet sein; PHP verwendet nicht die native atomare Sperre. Kein echter Folgeauftrag erzeugt. Native Standardfälle sind ergänzt; kundenspezifische PHP-Sonderumschreibungen sowie weitere Erfassungs-/Bearbeitungsdetails bleiben Gegenstand des fortlaufenden Abgleichs. Keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Native Bereinigung gelöschter Filter

- Frischer Serverabgleich: `admin/filter.php` SHA-256 `d3135148f5d06927465c53bf2b93d06aa3da41526d499d6ab700d07dc1dfb0b4`, `jobs/check_jb_permanent.php` `d9c35f8e2a3a0c0f0fbaa4a09924cc756356251338807cd213ae707b68776ae3`; aktuelle PHP-Filterauswahl lesend geöffnet. Nach Entfernung des letzten Katalogeintrags eines Kürzels bereinigt NG jetzt selbst benannte Tourvorlagen und dieselben offenen zukünftigen Dauerauftragsvorlagen wie PHP. Optionale Filter, andere Kürzel und Änderungszeitpunkte bleiben erhalten. Die frühere Abhängigkeit vom nächtlichen PHP-Bereinigungslauf entfällt für neue NG-Löschvorgänge.
- Gesicherte Phase `CLEANUP_PENDING` kann nach Unterbrechung fortgesetzt werden. Maximal 1000 Vorlagen je Schritt; große Mengen bleiben sichtbar offen. Das Kürzel bleibt bis zum Abschluss gesperrt. Auftragänderungen, Entfernung genau dieses Kürzels aus der Warteschlange und Abschlussbeleg laufen atomar mit Tabellensperren/InnoDB-Prüfung. Wiederholung eines fertigen Vorgangs verändert inzwischen wieder angelegte Kürzel nicht.
- **1135 Tests: 1132 bestanden, drei übersprungen, keine Fehler**; fünf gezielte Testmethoden mit SQL-Abläufen sowie 14 Frontendtests und Build erfolgreich. Geprüft: sämtliche PHP-Vorlagenbedingungen, doppelte Kürzel, Token-Grenzen, 1001 Vorlagen, Teilfehler/Rollback, Wiederaufnahme, MyISAM-Sperre, fremde Warteschlangeneinträge und unveränderte Zeitstempel. Berichte `work/filter-cleanup-targeted.log`, `…-verify.log`, archiviertes Manifest mit 832 Dateien.
- Browser: aus SQL-Tests erzeugter offener Vorgang erfolgreich fortgesetzt, Abschlussmeldung und verschwundener offener Vorgang geprüft; `work/filter-cleanup-ui-verification.json`, `work/filterbereinigung-2026-10-18.png`. Port 8080 aktualisiert, Health/DB und sechs Frontenddateien geprüft (`…-deployment.json`). Reale Tabellen und leere globale Warteschlange nur gelesen (`…-read.json`); keine bestehenden Aufträge/Filter verändert. Keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Verschlüsselte Exportablage

- Aktuelle PHP-Exportoberfläche lesend geöffnet; Serverquellen `export/export.php` SHA-256 `30b7b10e11d76fc02e7b5103dc67680699604bc66b87022c568406c226ed0c28`, `export/exportdata.php` `b1c1e1129249ee9bd3dc3b798b730249c0305b8cf319231402f0125c4144f851`, `include/mcglobal.inc.php` `1c6956c087ab652952431cf3f23bfcaafe36040b40ded0fc4f3a483430b6405e`. PHP verwendet GnuPG, den Empfänger `company.cmp_keyuser` der Niederlassungsfirma und `ENCRYPT_FILEEXTENSION`. Diese serverseitige Ablage ist jetzt bei Kunden-, Stammdaten-, Auftrags-/Gutschriften- und zentralen CSV-Exporten angebunden.
- GnuPG erhält separate Prozessargumente, keine Shellbefehle. Ein eindeutig aufgelöster primärer Fingerabdruck bestimmt den Empfänger; normale GnuPG-Vertrauensprüfung bleibt aktiv. Schlüssel werden nicht automatisch geladen. Klartext verbleibt im Speicher; bereits der dauerhafte Vorgangsinhalt und die temporäre Ablagedatei sind verschlüsselt. Wiederholung verwendet dieselben gesicherten Bytes. Geänderte Verschlüsselungsvorgaben blockieren offene Vorgänge; alte unverschlüsselte Vorgangsbelege bleiben lesbar. Dateiendung, Namenskollision, Download, Rollback und Verwerfen berücksichtigen die Verschlüsselung; zusätzliche Abrechnungsrechte gelten auch für `.ums.gpg`.
- **1134 Tests: 1131 bestanden, drei übersprungen, keine Fehler**; acht gezielte Testmethoden mit umfassenden SQL-Abläufen und realer GnuPG-Ver-/Entschlüsselung erfolgreich. Geprüft: fehlender/nicht vertrauenswürdiger Schlüssel, uneindeutiger/widerrufener Schlüssel, Wiederholung nach Dateisystem- bzw. SQL-Ausfall, Konfigurationswechsel, alte Vorgangsbelege, unterbliebene Exportmarkierungen bei Rollback und geschützte Downloads. `work/export-encryption-verify.log`, Berichte/Manifest mit 832 Dateien. Browser mit SQL-erzeugten synthetischen Daten zeigt verfügbare `.gpg`-Datei; `…-ui-verification.json`, `work/verschluesselter-export-2026-10-18.png`.
- Reale Konfiguration ausschließlich gelesen (`work/export-encryption-read.json`): elf Niederlassungen, überall Verschlüsselung aus, Endung `gpg`, kein hinterlegter Empfänger. Keine Aktivierung, Schlüsselübernahme oder echte Exportdatei. Betrieb bei späterer Aktivierung benötigt `EXPORTS_GPG_EXECUTABLE`, `EXPORTS_GPG_HOME` mit vertrauenswürdigem Empfängerschlüssel sowie den bestehenden Firmenempfänger; `.env.example` dokumentiert diese Angaben. GnuPG-Testschlüssel werden ausschließlich in temporären isolierten Schlüsselbünden erzeugt. Keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Fotoabläufe der Kundenerfassung getrennt

- Frischer SSH-Abgleich bestätigt: `jobs2/job_options.php` SHA-256 `69651fa561f51a157ca8c49aef7f6f1ae27c80072af86f2c1e67b85ae41bfc63` verwendet ausschließlich klassische `tr_photo`-Vorgaben; zentrale Workflow-Sets kommen dort nicht vor. Die neue Kundenerfassung übernimmt deshalb keine zentralen Standardsets mehr. Kundenanlage/-änderung funktioniert auch bei ausgefallenem zentralen Fotodienst. Bereits gespeicherte klassische Nachweise bleiben bei Änderungen unverändert; vorhandene echte externe Workflow-Zuordnungen bleiben vor unkoordinierter Kundenänderung geschützt.
- **1130 Tests: 1127 bestanden, drei übersprungen, keine Fehler**; 86 gezielte Prüfungen erfolgreich. Die SQL-Prüfung nutzt echte Foto-Warteschlangenlogik, einen ausgefallenen bzw. mit Standardset konfigurierten Fotodienst, Kundenanlage, Änderung, Wiederholung und unveränderte klassische Nachweise. Zentrale Erfassung verwendet weiterhin Sets und meldet einen Dienstausfall. Nachweise `work/customer-photo-channels-targeted.log`, `…-verify.log`, archivierte Berichte/Manifest mit 829 Dateien.
- Aktuelle PHP-Kundenmaske lesend geöffnet: Stationsrahmen liefert HTTP 500, Optionsrahmen rendert mit unerfüllten Template-Platzhaltern. Keine Speicherung vorgenommen; dieser Teil des Abgleichs beruht deshalb auf frischem Servercode, nicht auf einem erfolgreichen alten Kundenworkflow. Keine neue UI nötig; bestehende Vorschau zeigt weiterhin klassische Beweisfoto-Vorgaben. Keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Individuelle externe Adresskostenstellen

- Aktuelle PHP-Serverdateien `jobs/job_options.php` (SHA-256 `bfc6d2a725092142d36dfb93dd8ea9ae71408961c8abe5f77f82ab1e87bd9e80`) und `jobs2/job_options.php` (`69651fa561f51a157ca8c49aef7f6f1ae27c80072af86f2c1e67b85ae41bfc63`) abgeglichen. Bei `MASK_CREATE_EXTERN_COSTCENTER=1` legen Zentralen- und Kundenerfassung individuelle freie Adressen unter der Kundengruppe „Extern“ an. Bereits vorhandene Gruppen ohne Extern-Kennzeichen werden berücksichtigt; Namenskollisionen erhalten eindeutige Suffixe. Kostensplit ohne eindeutigen Eigentümer erzeugt wie PHP eine eigene externe Kunden-/Firmenzuordnung mit vier Adressarten. Barzahlungswechsel und zentrale Kundenvorgaben werden berücksichtigt.
- Kundenbearbeitung erhält bestehende individuelle Stationskostenstellen, ergänzt neue freie Stationen und gibt versteckte technische IDs nicht an den Client frei. Tourkopien laden versteckte externe Stationen als freie Adressen. Schreibvorgänge laufen atomar; InnoDB ist Voraussetzung. Parallele Anlagen sperren den zugehörigen Kunden und prüfen Namensgleichheit mit der Datenbank-Kollation. Die aktuelle Konfiguration wurde ausschließlich gelesen; Modus 1 wurde nirgends aktiviert.
- **1130 Tests: 1127 bestanden, drei übersprungen, keine Fehler**; 62 gezielte Prüfungen einschließlich Wiederholung, bestehender Extern-Gruppe, Kundenänderung, Kostensplit, Barzahlung, paralleler Anlagen und vollständigem Rollback. Gesamtlauf `work/order-external-addresses-verify.log`, archivierte Berichte/Manifest mit 829 geprüften Dateien. Reale Schema-/Bestandsprüfung `work/customer-external-address-read.json`: alle vier beteiligten Tabellen InnoDB, keine Schreibzugriffe.
- Browser mit synthetischen Daten: Stationskontakt geändert, Preisvorschau, verlorene Antwort und identische Wiederholung erfolgreich. Nachweise `work/order-external-addresses-ui-verification.json`, `work/individuelle-adresskostenstellen-2026-10-18.png`. Port 8080 aktualisiert, Health/DB und sechs Frontenddateien identisch geprüft (`work/order-external-addresses-deployment.json`). Damit ist die zuvor separat genannte Modus-1-Lücke geschlossen; keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Freie Stationen in der Zentralenerfassung und Tourkopie

- Aktuelle PHP-Erfassung erneut lesend geöffnet. `jobs/job_options.php` direkt per SSH geprüft: SHA-256 `bfc6d2a725092142d36dfb93dd8ea9ae71408961c8abe5f77f82ab1e87bd9e80`, Sammlerzuordnung Zeilen 1108–1140. Gemeinsame native `OrderExternalStations` ordnet nun auch Zentralen-Neuanlagen, Mehrfachkopien und Serientermine zu; der Kundenzugang nutzt denselben Ablauf.
- Die externe Vorgabe geht in die Preisvorschau-Kennung ein, selbst wenn der Betrag unverändert bleibt. Gespeichert wird exakt die geprüfte Zuordnung. Ohne Sammler bleibt bisheriges Verhalten erhalten. Tourvorlagen wandeln genau die konfigurierte Sammelkostenstelle beim Laden in eine freie Adresse um; eigene reguläre Stationskostenstellen bleiben erhalten. Dadurch scheitert die Kopie nicht mehr an einer versteckten/fremden technischen Sammelkostenstelle.
- **1129 Tests: 1126 bestanden, drei übersprungen, keine Fehler**; 61 gezielte Prüfungen einschließlich Mehrfachanlage, Wiederholung, Kopie, Vorgabenwechsel und vollständigem Rollback. Gesamtlauf `work/order-external-stations-verify.log`, Berichte/Manifest mit 827 geprüften Dateien. Isolierter Browser: Tour laden, freie Station ändern, Vorschau ohne technische Sammler-ID; Screenshot `work/zentralenerfassung-freie-station-2026-10-18.png`, `…-ui-verification.json`. Keine echten Aufträge geschrieben.
- Präzisierung: Der klassische zentrale Fotoblock ist im aktuellen PHP durch die Quellkonstante `$TR_PHOTO_WORKFLOW = true` abgeschaltet (Zeile 307). Seine alten Kann-/Muss-Parameter sind daher keine aktive zentrale Lücke; die gesonderte Kundenmaske hat ihren bereits ergänzten klassischen Ablauf. Individuelle externe Adresskostenstellen bei Modus 1 bleiben separat offen. Keine vollständige PHP-Parität behauptet.

## 18. Oktober 2026 – Freie Stationen mit externer Sammelkostenstelle

- Frischer SSH-Abgleich `2eb7f98`, `jobs2/job_options.php` SHA-256 `69651fa561f51a157ca8c49aef7f6f1ae27c80072af86f2c1e67b85ae41bfc63`, Zeilen 880–1050. Bei Kunden-Neuanlage und -Bearbeitung verwenden freie Stationen jetzt die konfigurierte `CSC_ID_PAYER_EXTERN`. Bereits so gespeicherte PHP-Aufträge sind bearbeitbar. Genau diese Konfiguration ist die Ausnahme; andere fremde Kostenstellen bleiben gesperrt. Sammelkostenstellen werden nicht als Zahler/Adresssuche freigegeben und ihre technische ID wird nicht vom Kundenclient akzeptiert.
- Vorgabe gehört zur Eingaberevision; geänderte Konfiguration nach Vorschau führt zum Konflikt. Zuordnung, Auftragsänderung und Vorgangsbeleg sind atomar; identische Wiederholung, fingierte fremde IDs und Rollback nach fehlgeschlagenem Stationsupdate geprüft. Reale Konfiguration nur gelesen (`work/customer-external-address-read.json`): alle elf expliziten Modusvorgaben sind 0, 13 Sammlerzuordnungen; einzelne konfigurierte Sammler haben kein Extern-Flag bzw. gehören einer wiederverwendeten Niederlassung. Deshalb exakt konfigurierte Zuordnung statt ungeprüfter Flag-Annahme.
- **1128 Tests: 1125 bestanden, drei übersprungen, keine Fehler**; neun gezielte Tests erfolgreich. Gesamtlauf `work/customer-external-stations-verify.log`, archivierte Berichte und Manifest mit 826 geprüften Dateien. Browser mit synthetischen Daten: freie Adressen bearbeitet, Preisvorschau, verlorene Bestätigung und identische Wiederholung; `…-ui-verification.json`, Screenshot `work/kundenauftrag-freie-stationen-2026-10-18.png`. Keine echten Aufträge verändert.
- Noch gesondert offen: individuelle Adresskostenstellen bei `MASK_CREATE_EXTERN_COSTCENTER=1` (derzeit nirgends aktiv) sowie derselbe Sammlerablauf in der Zentralenerfassung. Die bisherige Kundenlücke aus dem Fotoabschnitt ist geschlossen; keine vollständige PHP-Parität behauptet.

## 18. Oktober 2026 – Klassische Beweisfoto-Vorgaben in der Kundenanlage

- Aktueller SSH-Stand: `jobs2/job_options.php` SHA-256 `69651fa561f51a157ca8c49aef7f6f1ae27c80072af86f2c1e67b85ae41bfc63`, `tools/statistic_finishment.php` `5c953b6a59092003198125c3cb4fc8deea2e19e2c1b00f63cb71956b9d06b332`. Alte Fotoübersicht mit Kann-/Muss-Foto und Mindest-/Höchstmengen im Browser nur gelesen. 85 aktuelle Kundenvorgaben geprüft: zwei Modus 0, 62 Modus 1, zehn Modus 2, elf Modus 3; alle mit nativer Auswertung lesbar (`work/customer-photo-requirements-read.json`).
- Bei Kunden-Neuanlage werden für Modus 2/3 ab Station 2 die klassischen `tr_photo`-Vorgaben einschließlich Auftragskontext gespeichert. Fehlende Menge ergibt wie PHP `1|1`; Mode 0/1 erzeugt keine Kundenanforderung. Barzahlung ohne Zahlerauswahl berücksichtigt den anfänglichen Systembarzahler und den Wechsel nach der Kassierstation. Die Vorschau zeigt die konkreten Stationsmengen. Externer Foto-Workflow bleibt eine separate bereits vorhandene Funktion; bestehende Kundenaufträge bekommen keine rückwirkende Fotoänderung (auch PHP schreibt diese Vorgabe nur bei Neuanlage).
- Fotoparameter gehören zur Kundenvorgaben-Revision. Änderung nach Vorschau oder während externer Preis-/Routenabfrage blockiert die alte Eingabe. Auftrag, Stationen, Fotoanforderung und Vorgangsbeleg bleiben atomar; Rollback bei fehlgeschlagener Metadatenablage und identische Wiederholung sind geprüft. Keine echten Aufträge/Fotos geschrieben.
- **1127 Tests: 1124 bestanden, drei übersprungen, keine Fehler**; zehn gezielte Prüfungen, 14 Frontendtests und Produktionsbuild erfolgreich. `work/customer-photo-requirements-verify.log`, Berichte und Manifest mit 824 geprüften Dateien. Synthetische Browserprüfung: Vorschau 2–3 Fotos an Station 2, verlorene Speicherantwort, identische Wiederholung und Erfolgsanzeige. `…-ui-verification.json`, Screenshot `work/kundenauftrag-beweisfotos-2026-10-18.png`.
- Weiterer Abgleich: Die manuelle Dispositions-Checkbox der Kundenmaske wird im aktuellen PHP ausdrücklich auskommentiert (`job_options.php` 2255–2261), sie ist damit keine aktive UI-Lücke. Freie Kunden-Stationsadressen verwenden im PHP dagegen die konfigurierte externe Sammelkostenstelle; diese Zuordnung und die Bearbeitung entsprechender Altaufträge sind der nächste geprüfte Anschluss.

## 18. Oktober 2026 – Formularvorbelegungen und Punkteberechnung

- Frisch bestätigte Serverdateien auf `2eb7f98`: `include/inc_metafield.inc.php` `149a46799258036404ac45ba315531195ed2b4c316bfa14b4addb5c5e13fdc65`, `admin/metafield_special.php` `3a76c59c31e95251a8921d6588538c85b2bfb306dc9073552214be514fd43e56`. System-/Stammdatenvorbelegungen sind wie PHP im Formular bearbeitbar und werden als eigenständige Formularwerte gespeichert; spätere Stammdatenänderungen überschreiben vorhandene Werte nicht. Leere Werte beziehen wieder die aktuelle Vorbelegung. Benutzername und Logo bleiben automatisch; Logo verwendet den PHP-Pfad `images/external`.
- Aktuelle DB-Vorlagen 101/102 nur lesend geprüft: 23 bzw. 109 Felder. Vorlage 102 SHA-256 `fbd54ee9f4ccf82e0477a839645a06d6eb152ef93a497571551d50d5fb7ccd0c` enthält 45 gewichtete Fahrer- und 30 Kundencheckboxen. Native Anzeige rechnet sofort; der Server berechnet beim Speichern unabhängig von übergebenen Summen. Mehrere Kreuze je Zeile addieren sich wie PHP; Gesamt-Checkboxen fließen nicht ein. Maximalsummen 135/90 geprüft. Kein Template-JavaScript wird ausgeführt. Unbekannte Änderungen an der Berechnungsfunktion sperren den Editor mit Erklärung.
- Berichtsvorlage ist Bestandteil der Revision und wird unter PHP-kompatiblen Sperren erneut geprüft. Formularwerte und Historie bleiben atomar. Berichtseditor friert bei unklarer Speicherantwort ein und wiederholt denselben Vorgang; fehlgeschlagenes Neuladen entfernt alte Eingaben.
- **1124 Tests: 1121 bestanden, drei übersprungen, keine Fehler**; 21 gezielte Tests, 14 Frontendtests und Produktionsbuild erfolgreich. `work/form-snapshots-verify.log`, `…-full-reports/`, `…-build-sources.json` mit 821 geprüften Dateien. SQL prüft erhaltene Stammdaten, historische Vorbelegung, Replay, Rechte, Summen, Konflikte, Vorlagenänderungen und History-Rollback. Aktuelle Vorlagenprüfung `work/form-template-read.json`, keine echten Geschäftsdaten verändert.
- Browser mit synthetischen Daten: 6/6 Punkte, unveränderter Wiederholungsrequest, gesperrte Eingaben bei unklarer Antwort, Lesefehler ohne alten Editor und Speicherung separater Firma/Datum. Screenshots `work/formular-punkte-2026-10-18.png` und `work/formular-vorbelegung-2026-10-18.png`. Port 8080 aktualisiert, Health/DB und sechs Assets geprüft. Die im vorherigen Formularabschnitt genannten Vorbelegungs-/Punktelücken sind geschlossen; daraus folgt keine vollständige Anwendungsparität.

## 18. Oktober 2026 – Bestätigte Übernahme lokal belegter Gerätetelefone

- Anschluss an die aktuelle PHP-Logik zum Entfernen alter lokaler `cr_mobile_pda`-Zuordnungen: Die neue zentrale Auswahl zeigt den bisherigen Transporteur mit Niederlassung. Vor einer Übernahme ist die ausdrückliche Bestätigung im Dialog erforderlich. Zuordnungen außerhalb freigegebener Niederlassungen sind nicht auswählbar; ihre Namen werden nicht ausgegeben. Die Berechtigung wird beim Speichern erneut geprüft. Auch die freie Telefonpflege bietet eine ausdrückliche Übernahmeoption.
- Alte lokale Zuordnung, Audit 117 für den bisherigen Transporteur und neue dauerhafte Vormerkung werden in einer lokalen Transaktion gespeichert. Schlägt die Vormerkung fehl, bleibt die alte Zuordnung erhalten. Ein bereits laufender Geräteabgleich beim bisherigen Transporteur verhindert die Übernahme. Zentral fremd vergebene Nummern werden weiterhin nicht angeboten oder überschrieben.
- **1114 Tests: 1111 bestanden, drei übersprungen, keine Fehler**, Produktionsbuild erfolgreich. Zwölf gezielte Prüfungen einschließlich autorisierter Übernahme B/HH, nicht freigegebener Niederlassung, fehlender Bestätigung, paralleler Wiederholung und Rollback nach fehlgeschlagenem Vormerken. Gesamtlauf `work/courier-device-transfer-verify.log`, Manifest mit 814 geprüften Dateien. Browser zeigt den Vorbesitzer und sperrt Speichern bis zur Bestätigung; danach Vormerkung erfolgreich. `…-ui-verification.json`, Screenshot `work/geraetetelefon-uebernahme-gespeichert-2026-10-18.png`. Keine echten Zuordnungen verändert. Die im vorigen Eintrag genannte Lücke der lokalen Nummernübernahme ist damit geschlossen.

## 18. Oktober 2026 – Zentrale Gerätetelefon-Zuordnung

- Aktuelle PHP-Neuanlage erneut lesend geöffnet: Mobil-Nr. VPA/PDA ist eine zentrale Auswahl; freie Eingabe nur bei `MASK_CR_MOBILE_PDA_EDIT=1`. `admin/courier_special.php` SHA-256 `64c753ec0c7b36ef86215c5ce24f5f8cf4889334c147e746e5ec5134264accfa`; `include/global.inc.php` liest `as_intern` aus der zentralen Metaobjekt-Datenbank. Reale Schema-/Parameterprüfung ausschließlich lesend (`work/courier-device-read.json`): `sysadmin.conf_prop` ist InnoDB; für Instanz 111 sind derzeit keine nichtleeren Mobilnummern konfiguriert, entsprechend der leeren alten Auswahl.
- Im Transporteurstammblatt „Gerätezuordnung / VPA-PDA“ ergänzt: freie/eigene Nummern der aktuellen Niederlassung, Aufheben der Zuordnung, konfigurierte freie Telefonpflege, Abgleichstatus und erneute Vormerkung. Rohes Telefonfeld im Stammblatt ist jetzt nur lesbar; der Server verweigert Umgehungen über die allgemeine Stammdaten-API. Auswahl und Änderungen sind an Transporteur, Benutzerkonto, Niederlassung und Rechte gebunden.
- Zentraler Wechsel wird zuerst dauerhaft lokal vorgemerkt. Worker ordnet `conf_prop` unter InnoDB-Zeilensperren zu, wiederholt sicher nach verlorener Remote-Commit-Bestätigung und bestätigt anschließend den zentralen Stand unter denselben Sperren während der lokalen Fertigstellung. Erst dann werden lokale Nummer und Audit 117 gespeichert. Geänderte Instanz/Zieladresse, anderweitig belegte Nummern, mehrdeutige Daten oder zwischenzeitlich durch PHP geänderte lokale Zuordnung blockieren mit sichtbarem Status. Ein fremder zentraler Besitzer wird nicht überschrieben. Bereits anderweitig lokal belegte Nummern müssen zuerst dort gelöst werden; PHPs implizites Wegnehmen einer lokalen Nummer ist damit noch kein identischer Ein-Schritt-Ablauf.
- Verbindung aus `APP_DB_URL` oder aktuellem `as_intern`; Zugang aus `APP_DB_USER`/`APP_DB_PASSWORD` mit Meta-/Primär-Rückfall, ausschließlich Umgebungsvariablen. `DEVICE_PHONE_SYNC_ENABLED=true` verarbeitet nur explizit vorgemerkte Änderungen, kein Bestandsabgleich. Keine realen Gerätezuordnungen verändert.
- **1114 Tests: 1111 bestanden, drei übersprungen, keine Fehler**, 12 gezielte Prüfungen sowie 14 Frontendtests und Produktionsbuild erfolgreich. SQL prüft konkurrierende Besitzer, verlorenes Remote-Commit, InnoDB, lokale Fertigstellung/Rollback unter Remote-Sperre, unveränderte Fremdinstanzen und Prop-Typen, Rechte, Wiederholung und lokale Konflikte. Browser prüft Auswahl, verlorene Speicherbestätigung mit identischem Request, offene/abgeschlossene Zuordnung, manuellen Neuversuch, Lesefehler und freie Eingabe/Lösen. Archiv `work/courier-device-verify.log`, `…-full-reports/`, `…-build-sources.json` mit 814 Dateien; Screenshot `work/geraetetelefon-2026-10-18.png`. Keine vollständige PHP-Parität.

## 18. Oktober 2026 – Heimatkoordinaten der Transporteure

- Aktuelle PHP-Neuanlage lesend geöffnet, SSH-Stand `2eb7f98`: `admin/courier_special.php` SHA-256 `64c753ec0c7b36ef86215c5ce24f5f8cf4889334c147e746e5ec5134264accfa`, `include/inc_courier.inc.php` `a3f820164141165d72384625513e3c0de2ccd743f667ea76bd6a7a26f75c5518`, `locating/xServer.inc.php` `db74afe6f4720fd7abb4749ef3842fb40441e9f98d82dba3686ab371b833b10c`. PHP hat kein separates Heimat-PLZ-Feld mehr: Neuanlage und geänderte Adress-PLZ bestimmen den Heimatort; unveränderte PLZ erhält vorhandene Koordinaten.
- Native Stammdatenpflege aktualisiert jetzt `cr_gps_lat_home` und `cr_gps_long_home` nach derselben Auslöseregel. Geokodierung erfolgt vor der Schreibtransaktion; Revision wird anschließend unter Sperre erneut geprüft. Bekannte erfolgreiche Vorgänge werden vor externen Aufrufen erkannt. Adressänderung, Koordinaten, Audit und Beleg werden zusammen gespeichert. Fehlende/mehrdeutige Geokodierung erzeugt keine falschen Nullkoordinaten. Neuanlagen bekommen außerdem wie PHP den VA-Filter bei ungesperrtem App-Zugang.
- Vorhandener PHP-PLZ-Cache mit Punkt-Platzhaltern und Genauigkeit mindestens 5 wird bei frischer Gültigkeit nur gelesen; andernfalls vorhandene Google-Geokodierung mit Prüfung von Land, PLZ und Koordinaten. Fehlerantworten werden nicht im Anwendungscache festgehalten. Die reale Primärdatenbank enthält keinen zugänglichen `address_geo`-Cache; dort wird der konfigurierte Geokodierungsdienst benötigt. Reale Prüfung ausschließlich Metadaten/Parameter, keine Adressen gesendet (`work/courier-home-read.json`).
- **1108 Tests: 1105 bestanden, drei übersprungen, keine Fehler**, 24 gezielte Tests erfolgreich. Abgedeckt: Anlage, Änderung, unveränderte PLZ, Wiederholung bei ausgefallenem Dienst, parallele identische Anlage, Revision während Geokodierung geändert, fehlende Rechte, Audit-Rollback und frischer PHP-Cache. `work/courier-home-verify.log`, archivierte Berichte und Manifest mit 811 geprüften Dateien. Keine neue UI erforderlich; bestehende Adressfelder lösen die Funktion aus. Aktuell weiterhin offen: zentrale VPA-/PDA-Telefonzuordnung. Keine vollständige PHP-Parität.

## 18. Oktober 2026 – Fahrerprofil und App-Zugang

- Frischer Serverabgleich `2eb7f98`: `admin/courier_special.php` SHA-256 `64c753ec0c7b36ef86215c5ce24f5f8cf4889334c147e746e5ec5134264accfa`, `include/dbglobal.inc.php` `5977c0c1a9c25b8a6d28957cedeec117479fb4d0b7d70353040e30721a566b87`. Alte Maske und niederlassungsübergreifende Unternehmerauswahl lesend geprüft. Fahrerprofil im Transporteurstammblatt ergänzt: Nationalität aus der konfigurierten Ländergruppe, Geburtstag, Unternehmerzuordnung, App-Sperre und Geräte-Abmeldung.
- Unternehmersuche je freigegebener Niederlassung mit begrenzten Treffern; serverseitige Rechteprüfung und Schutz vor Zyklen auch bei gleichzeitigem gegenseitigem Zuordnen. Bestehende Nationalitätscodes bleiben erhaltbar. Sperren entfernt nur den VA-Filter und legt wie PHP einen Abmeldeauftrag Typ 2, Modus 1 mit 16 Stunden Gültigkeit an; Verfügbarkeit und SID bleiben bestehen. Die Oberfläche bestätigt die Vormerkung, nicht die Ausführung auf dem Gerät.
- Änderungen, Audit, Geräteauftrag und Wiederholungsbeleg sind atomar. Erster SQL-Zugriff im Schreibvorgang ist eine sperrende Mandantenzuordnung; damit sieht eine wartende Wiederholung den zuvor gespeicherten Beleg. SQL-Prüfungen decken parallele identische Abmeldung, niederlassungsübergreifenden Zyklus, Rollback, MyISAM-Schreibsperre, Rechteentzug, veralteten Stand und Ländergruppe ab.
- **1105 Tests: 1102 bestanden, drei übersprungen, keine Fehler**, Produktionsbuild erfolgreich. `work/courier-driver-profile-verify.log`, Berichte und Manifest mit 810 geprüften Dateien archiviert. Browser mit isolierten synthetischen Daten: Speichern einschließlich Datum, Abmeldung, identische Wiederholung nach verlorener Antwort, Lesefehler ohne alte Daten und Wiederherstellung geprüft. Ein alter Erfolgshinweis wurde beim Start eines neuen Vorgangs bereinigt und erneut geprüft. Screenshot `work/fahrerprofil-2026-10-18.png`, Ereignisse und `…-ui-verification.json`. Keine echten Fahrer gesperrt oder Geräteaufträge angelegt.
- Anschlusslücken aus frischem Quellvergleich: zentrale VPA-/PDA-Telefonzuordnung und automatische Heimatkoordinaten bei Neuanlage/PLZ-Änderung. Keine vollständige PHP-Parität.

## 18. Oktober 2026 – Zentrale Schlüssel beim Mitarbeiterlöschen

- Aktueller SSH-Stand `2eb7f98`, `admin/employee_list.php` SHA-256 `09bfbd1a245d08cb47533d5082e1275a8de1d944d53bbb9212e1c06d4da32451`, Zeilen 107–114: PHP entfernt nach lokaler Mitarbeiterlöschung die `usr`-Metaobjekte genau dieser Datenbankinstanz. Native Ergänzung für Zentralenmitarbeiter und Kundenmitarbeiter, sowohl Verwaltung als auch Kundenportal. `admin/user_list.php` hat diesen Schritt nicht; Lagerbenutzer bleiben ausgenommen.
- Lokale Kontolöschung und dauerhafte Bereinigungsvormerkung (`ngmetadel`) sind atomar und über die bestehende Vorgangskennung wiederholbar. Der gemeinsame Meta-Worker entfernt zentral erst nach Commit, bei sicher fehlendem lokalem Benutzer und unveränderter Instanznummer. Fehlende ursprüngliche Instanz wird bei Löschungen nicht nachträglich geraten. Netzwerkfehler werden zeitversetzt wiederholt; unklare Bestände bleiben mit Diagnose gespeichert. Bestehende Benutzer, andere Instanzen sowie Kunden-/Transporteur-Schlüssel werden nicht gelöscht.
- Anlage und Löschung prüfen ihren lokalen Zustand **innerhalb derselben zentralen MyISAM-Sperre**. Dadurch kann eine bereits laufende Schlüsselanlage nach einer bestätigten Bereinigung keinen neuen Schlüssel für das gelöschte Konto hinterlassen. Verlorene Delete-Bestätigung ist wiederholbar, alte Bearbeitungsfristen können übernommen werden; verspätete Abschlussmeldungen überschreiben keine neueren Ergebnisse.
- **1104 Tests: 1101 bestanden, drei übersprungen, keine Fehler**; 17 gezielte Prüfungen einschließlich Architektur, Mitarbeiter-/Kundenportalpfaden, Rollback und tatsächlicher MyISAM-Konkurrenz. Gesamtlauf `work/meta-removal-verify.log`, 807 geprüfte Dateien. Keine realen Konten oder zentralen Schlüssel gelöscht. Die zuletzt unveränderte Oberfläche ist durch den vorherigen Frontend-/Browserlauf geprüft. Bei verschachtelten JUnit-Tests weichen Surefire-Summenköpfe von den einzelnen Testfällen ab; Archivierung zählt daher die eindeutigen Testfälle und protokolliert die Abweichung (`…-verification.json`).
- Weitere bestätigte Lücken: Fahrerprofil mit Nationalität/Geburtstag, Unternehmerzuordnung, App-Sperre und Geräte-Abmeldung. Keine vollständige PHP-Parität.


## 18. Oktober 2026 – Persönliche Links bei Neuanlagen

- Frischer SSH-Abgleich HEAD `2eb7f98`: `admin/customer_special.php` SHA-256 `2159d036ac8e7c4b936c754d71270ffc6e45d8a6fe1606786fd1d0ab280dc49b`, `admin/courier_special.php` `64c753ec0c7b36ef86215c5ce24f5f8cf4889334c147e746e5ec5134264accfa`, `admin/employee.php` `4c90cdf4e63b0861dc7780cb6fd3184f8c3b21667ba90a6e6c706c8a75037bce`. Aktuelle PHP-Mitarbeiter- und Transporteur-Neuanlage lesend geöffnet; Kundenmaske zuvor erneut geprüft. PHP `GLOBAL_USAGE_HASH=true` ist eine Quellkonstante, kein DB-Parameter.
- Neue Kunden registrieren `cs`, neue Transporteure `cr` und `usr`, neue Zentralen-/Kundenmitarbeiter `usr`. Gilt auch für die Eigenanlage im Kundenportal. Die lokale Anlage und eine dauerhafte Vormerkung (`ngmeta`) werden atomar gespeichert. Keine Massenanlage für Bestandsobjekte, keine Hashänderung bei Stammdatenkorrekturen. Lagerbenutzer aus `admin/user_list.php` haben im aktuellen PHP keinen solchen Anlageschritt und bleiben ausgenommen.
- Worker mit 30-Sekunden-Takt und 60-Sekunden-Anlaufzeit, konfigurierbar durch `META_OBJECT_SYNC_ENABLED` (Standard true). Externe Registrierung erst nach lokalem Commit, unter MyISAM-Tabellensperre. Vorhandene eindeutige Schlüssel bleiben unverändert; unterschiedliche Instanzen und Objekttypen bleiben getrennt. Verlorene Insert-Bestätigung führt beim Folgeversuch zum Wiederverwenden des vorhandenen Schlüssels. Verbindungsfehler erhalten eine zeitversetzte Wiederholung; widersprüchliche Bestände oder geänderte Instanznummer blockieren. Keine Mail wird dadurch versendet.
- „Persönliche Links“ in Kunden-/Transporteur-, Zentralenmitarbeiter- und Kundenmitarbeiterdialogen zeigt Status und ermöglicht eine erneute Vormerkung. Bestehende Objekt-, Niederlassungs- und Portalrechte werden geprüft. Keine Schlüssel, Passwörter oder privaten Verbindungsmeldungen in Antworten. Lesefehler entfernen den vorherigen Status; Laden ist rein lesend. Browser geprüft mit isolierten Testdaten; Screenshot `work/persoenliche-links-2026-10-18.png`.
- **1100 Tests: 1097 bestanden, drei übersprungen, keine Fehler**, 14 Frontendtests und Produktionsbuild erfolgreich. Der erste Gesamtlauf beanstandete zwei direkte Transaktionsreferenzen; beide wurden in die bestehende DatabaseService-Grenze verlagert. Abschließender Gesamtlauf `work/meta-registration-verify.log`; 806 Dateien im geprüften Manifest. Isolierte MyISAM-Tests decken Konkurrenz, Mehrdeutigkeit und verlorene Bestätigung ab; Geschäftsprüfungen Rollback, Neustart, geänderte Konfiguration, Rechte und fehlende Objekte. Reale Metadatenbank nur lesend geprüft (`work/meta-object-read.json`), keine echten Schlüssel oder Konten angelegt.
- Nächster bestätigter Anschluss: `admin/employee_list.php` entfernt beim Mitarbeiterlöschen auch `usr`-Schlüssel. Noch keine vollständige PHP-Parität.


## 18. Oktober 2026 – Endkunden-Tracking-Mails

- Frischer SSH-Abgleich HEAD `2eb7f98`: `include/automailer7.php` SHA-256 `bbc4c3648bf3e28d090006655d686209d4b0e718d23883c1c75c6ad302183d62`, `include/inc_tracking.inc.php` `ef972832853c8f5a1178d80a90548d76b6afd9d43950638fe558b5774a2fe89e`, `locating/xServer.inc.php` `db74afe6f4720fd7abb4749ef3842fb40441e9f98d82dba3686ab371b833b10c`. Alte Kundenmaske mit Endkundentracking, durchschnittlicher Ladedauer und Unschärfeaufschlag erneut lesend geprüft.
- Stationsbezogener Empfänger, eigener globaler Tracking-Schalter, Kundenfreigabe, abgeholte erste Station und inklusive Tagesgrenze. Wie PHP kein Angebots-/Fahrzeugausschluss; zahlender Kunde darf einer anderen Niederlassung angehören. Eindeutige Tracking-Markierung, NULL-/SENT_OK-/SENT_NOK-Sperren und empfängerbezogener PHP-Semaphor berücksichtigt. Keine Freigabe oder Mail beim Anzeigen des Status.
- Zentraler Tracking-Link für `tracking_tr` mit Instanznummer und vorhandener PHP-Adresse. Bestehende Schlüssel werden wiederverwendet; neue sichere 32-Hex-Schlüssel werden unter exklusiver MyISAM-Tabellensperre erzeugt. Mehrdeutige Objekte, doppelte Hashes und falsche Stationswerte werden abgewiesen. Nach verlorener Insert-Bestätigung wird beim nächsten Versuch der vorhandene Schlüssel gelesen. Meta-Anlage außerhalb der lokalen Transaktion; bei späterem lokalem Konflikt kann ein unbenutzter Schlüssel bestehen bleiben.
- ETA: 15-Minuten-Cache, aktuelle Fahrerposition oder frischer abgeschlossener Halt, offene Stationen bis zum Ziel, aktuelle Verkehrsdauer je Strecke und Ladezeiten an Zwischenstationen. Fünf-Minuten-Abrundung und Kundenzeitfenster einschließlich Tageswechsel. Fehlende/ungültige Verkehrs- oder Positionsdaten ergeben „ist unterwegs“ statt erfundener Ankunftszeit. Keine Routen-/Metaaufrufe beim Öffnen der Statusansicht. Globale PHP-Mailsprache und Tracking-Absender mit Rückfall; nur Zieladresse und zahlender Kunde, ohne interne Texte, andere Stationen, Cc/Bcc/PDF. Logos werden von der konfigurierten Anwendungsadresse geladen.
- Dauerhafter lokaler Beleg und SENT_NOK vor SMTP atomar; SENT_OK erst nach bestätigter Übergabe. Konkurrenz, Rollback, Quellenänderung, Metaausfall, fehlende SMTP-/DB-Bestätigung und idempotente Wiederholung geprüft. Keine automatische Wiederholung nach unklarem SMTP-Ergebnis. Auftragsdetail zeigt Tracking mit Empfängerart „Stationsempfänger“.
- **1095 Tests: 1092 bestanden, drei übersprungen, keine Fehler**; 14 gezielte Tests und 14 Frontendtests, Produktionsbuild erfolgreich. Der erste Gesamtlauf beanstandete nur die Platzierung direkter JDBC-Tests; diese liegen jetzt regelkonform innerhalb DatabaseServiceTest. Abschließender sauberer Gesamtlauf `work/tracking-mail-verify.log`, Berichte/Manifest mit 802 Dateien. Browser bestätigt erfolgreich/unklar, Lesefehler ohne alte Daten und Wiederherstellung; ausschließlich GET. Screenshot `work/endkunden-tracking-2026-10-18.png`.
- Sieben reale Stationsentscheidungen nur gelesen (`work/tracking-mail-status-read.json`); keine echten Mails, Schlüssel oder Geschäftsdaten geschrieben. Port 8080 aktualisiert, Health UP, DB verbunden, sechs Assets identisch (`…-deployment.json`). Native Mailworker bleiben im bestehenden Parallelbetrieb ausgeschaltet. Keine vollständige Anwendungsparität; nächste offene Integration sind zentrale Metaobjekte bei Neuanlage.

## 18. Oktober 2026 – Fahrzeuginfo nach Annahme und zentrale Metadatenbank

- Aktuelle SSH-Referenz `2eb7f98`, `include/automailer9.php` SHA-256 `cdf4e9608aa81ef08c06cfc7d4cd080e6f22e57439b9b17c80c31dc64d57edf8`, `include/inc_automailer.inc.php` `14e86b408c277725164ac06c27fe02a38b4bfb6eeb5e2ab3f666a02b28bf2bd2`, `admin/jb_detail.php` `4f9ab54020b9285a8a7d8b8ce00c07e2a8325ef320c86fabec79bf8c2df5d039`. Kundenmaske mit KFZ-Kennzeichen-Option erneut lesend geöffnet.
- Native Fahrzeuginfo nach Annahme: globale Wartezeit (strenge Überschreitung), Auftrag innerhalb Versandfenster, angenommener/stornofreier Auftrag, offene erste Station, Kundenvorgabe Bit 6, explizite Kunden-/Rechnungsadresse und tatsächlich verknüpfter Fahrer/Benutzer/Fahrzeug. Globale Fahrzeugausnahmen, PHP-Semaphor und vorhandene SENT_OK/SENT_NOK-Kennzeichen berücksichtigt. Kein zusätzlicher Angebotsausschluss, entsprechend der aktiven PHP-Auswahl.
- Vollständige freigegebene Auftragsmail mit Kundensprache, eigener JOB_TAKEN-Einleitung und hervorgehobenem Kennzeichen; Betreff wie PHP aus dem globalen Wörterbuch vor dem Kundensprachwechsel. CC/BCC und historische Auftragsdarstellung bleiben erhalten; aktive Aufträge erhalten keinen Abschluss-PDF. Dauerhafter Beleg und PHP-Sperrkennzeichen werden atomar vor SMTP geschrieben; unklare Übergabe wird nicht automatisch wiederholt. Neues Ereignis im lesenden Auftragsmailstatus.
- Der aktuelle PHP-Code verwendet für die Meta-Datenbank `phoenix_new`. Zugang ausschließlich lesend geprüft und entsprechend der bestehenden Benutzeranweisung in die ignorierte `.env` übernommen; keine Kennwörter in Prüfdateien. MySQL 5.5.62 unterstützt SET TRANSACTION READ ONLY noch nicht. Der native Leser erkennt die Version und schützt weiterhin alle Aufrufe durch die bestehende SELECT-/Seiteneffektprüfung. Moderne Server behalten die serverseitige Nur-Lesen-Transaktion. Bestehende Newsletter-/Bewertungs-Schlüssel können damit gelesen werden; das ersetzt noch keine Metaobjekt-Synchronisation.
- **1084 Tests: 1081 bestanden, drei übersprungen, keine Fehler**; 25 gezielte Backendtests. Konkurrenz, Übergabe außerhalb SQL, Rechte/Freigaben, Empfängerauswahl, Fahrzeugwechsel, Auditrollback, verlorene SMTP-/DB-Bestätigung, PHP-Versandkennzeichen, getrennte Sprachquellen und Meta-Verbindung geprüft. `work/taken-mail-verify.log`, `…-full-reports/`, `…-build-sources.json`, 797 geprüfte Dateien. Unverändertes zuvor geprüftes Frontend verwendet.
- Browser zeigt bestätigte und unklare Fahrzeuginfo-Übergabe; ausschließlich GET (`…-ui-verification.json`, `…-ui-events.json`), Screenshot `work/fahrzeuginfo-mails-2026-10-18.png`. Drei echte Aufträge ausschließlich lesend geprüft (`…-read.json`). Meta-Schema und Tracking-Schalter ebenfalls nur gelesen (`work/tracking-mail-read.json`); Tabelle metatracking ist MyISAM ohne eindeutigen Objektschlüssel. Keine echten Mails, Tracking-Schlüssel oder Geschäftsdaten geschrieben. Statusmaildienst bleibt ausgeschaltet; Endkundentracking ist der nächste offene Mailweg.

## 18. Oktober 2026 – Vermittlungsstau und Rückmeldung

- Aktueller SSH-Stand `2eb7f98`: `include/automailer6.php` SHA-256 `8bb8250b7f6488d3aedfdc86f94ab666add404235395110148f8ec06df0acea0`, `include/automailer8.php` `7661ffcdd4cfac83dd3d219bee43efd3a612da195d869dd183deb798fbe88623`, `include/email.inc.php` `736288d673697790f12ff6ca4254cacef27e74bbf374d8749e7f46223e520144`. Kundenmaske mit Stau-/Wartezeitvorgaben lesend geprüft.
- Native Stauwarnung und anschließende Vermittlungsrückmeldung mit Tages-/Statusgrenzen, Kundenvorgabe, erster Station und Ankunftszeit, expliziter Kunden-/Rechnungsadressauswahl, PHP-Semaphor und bestehenden Staukennzeichen. Kontrollfrist entsteht erst nach bestätigter Stauwarnung. Rückmeldung benötigt diese Bestätigung und eine noch nicht abgelaufene Kontrollfrist.
- PHP-konformer kurzer Inhalt mit jeweiligem Wörterbuch, Niederlassungsabsender, Begrüßung/Footer und sicher verlinktem Logo; keine internen Auftragsinformationen, CC/BCC oder PDF. Dauerhafter Versandbeleg und PHP-Sperrkennzeichen atomar vor SMTP; Konkurrenz, Auditrollback, Quellenänderung, unklare Übergabe und Absturz geprüft. Unklare Übergaben werden nicht automatisch wiederholt. Beide Ereignisse erscheinen im lesenden Mailstatus des Auftrags.
- **1078 Tests: 1075 bestanden, drei übersprungen, keine Fehler**; 19 gezielte Backendtests, 14 Frontendtests und Produktionsbuild erfolgreich. `work/mediation-mail-verify.log`, `…-full-reports/`, `…-build-sources.json` mit 794 Dateien. Nach Gesamtlauf nur Spaltenbreiten im Frontend verbessert; 609 Backenddateien unverändert zum getesteten Stand (`…-tested-sources.json`), erneut gebaut und paketiert.
- Browser prüft bestätigte/unklare Übergabe, fehlende Rückmeldefrist, Lesefehler und Wiederherstellung; nur GET (`…-ui-verification.json`, `…-ui-events.json`). Screenshot `work/vermittlungsstatus-mails-2026-10-18.png`. Sechs aktuelle Entscheidungen in der echten Datenbank ausschließlich lesend geprüft (`…-read.json`). Port 8080 aktualisiert, Health/DB und sechs Assets geprüft (`…-deployment.json`). Keine echten Mails oder Geschäftsdatenänderungen; Dienst weiterhin standardmäßig aus und bei aktivem PHP zusätzlich gesperrt.
- Weiter offen: Annahmeverzögerung und Endkundentracking. Die Tracking-Metadatenbank ist mit der derzeitigen Konfiguration nicht lesbar; der vom Benutzer genannte Phoenix-Zugang verwendet dort eine vom aktuellen JDBC-Treiber nicht unterstützte alte Passwortauthentifizierung. Keine Server-/Kontoeinstellungen geändert. Weitere dokumentierte Spezialfunktionen bleiben im Abgleich; keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Automatische Stationsabschluss-Mails

- Aktuellen Serverstand `2eb7f98`, `include/automailer4.php` (SHA-256 `b0a1230568d0adc2ff8cb58a1d55149a237b1d41d1c8da1ae5f61228023f3c2c`) und `getAutoMailerStations` direkt per SSH geprüft; aktuelle PHP-Kundenmaske mit Stationsmail-Schalter lesend geöffnet.
- Kundenvorgabe Bit 4, normale/Barzahler-Kostenstelle, Ersatz durch Kundenadresse bei leerer Rechnungsadresse, aktiver Auftrag, Tagesgrenzen, Stationsabschluss, Fahrzeugausnahmen und bestehende PHP-Versandkennzeichen übernommen. Fotovormerkung ohne Inhalt erlaubt unmittelbaren Versand; positiver Zähler mit Trennzeichen benötigt eine volle Minute Wartezeit. Jede vorhandene Stations-Versandmarkierung verhindert Neuversand.
- Eigener PHP-Semaphor, globaler Stations-Bcc mit Niederlassungs-/Globalrückfall, globale Mailsprache aus `include/mcglobal.inc.php`. Inhalt auf die gewählte Station beschränkt, einschließlich freigegebener Eventbemerkung; ohne andere Stationen, interne Bemerkungen, Preise oder PDF. Die native Eventbezeichnung verwendet die konfigurierte Codezuordnung statt einen Ereigniscode pauschal als Abholung/Erledigung umzudeuten.
- Dauerhafter Beleg und Kennzeichen 998 vor SMTP atomar, 999 erst nach bestätigter SMTP-Übergabe. Konkurrenz, Rollback, Quellenänderung, unklare SMTP-Bestätigung und Absturz nach Übergabe geprüft; kein automatischer Neuversand bei unklarem Ergebnis. Stationszeilen in Auftragsdetail → Auftragsmail → Automatische Statusmails ergänzt.
- **1073 Tests: 1070 bestanden, drei übersprungen, keine Fehler**; 14 gezielte Backendtests erfolgreich. `work/station-mail-verify.log`, `…-full-reports/`, `…-build-sources.json` mit 790 Dateien. Unverändertes Frontend aus zuvor geprüftem Produktionsbuild verwendet. Browser prüft zwei Stationszeilen, bestätigten/offenen/unklaren Status, ausgeschalteten Dienst, Lesefehler und Wiederherstellung; ausschließlich GET (`…-ui-events.json`, `…-ui-verification.json`). Screenshot `work/stationsabschluss-mails-2026-10-18.png`.
- Sechs aktuelle Stationen in der echten Datenbank ausschließlich lesend geprüft (`…-read.json`); keine echten Mails oder Geschäftsdatenänderungen. Dienst bleibt standardmäßig ausgeschaltet und bei aktiver PHP-Freigabe zusätzlich gesperrt. Weiter offen im Mailabgleich: Vermittlungsstau/Rückmeldung, Endkundentracking und Annahmeverzögerung; keine vollständige Anwendungsparität behauptet.

## 18. Oktober 2026 – Automatische Erfassungs-, Abholungs- und Erledigungsmails

- Aktueller SSH-Stand `2eb7f98`: `include/inc_automailer.inc.php` SHA-256 `14e86b408c277725164ac06c27fe02a38b4bfb6eeb5e2ab3f666a02b28bf2bd2`, `automailer.php`/`automailer2.php`/`automailer3.php`/`automailer5.php` und `admin/jb_detail.php` direkt gelesen. Aktuelle PHP-Kundenmaske mit drei Mailereignissen, Kunden-/Rechnungsadressauswahl und Inhaltsfreigaben lesend geprüft.
- Native Verarbeitung dieser vier PHP-Worker ergänzt: drei Statusereignisse, Standard- und zusätzliche Auftragsempfänger, normale und Barzahler-Kostenstelle, getrennte Zeitfenster, erste erledigte Station, Fahrzeug-Ausschlüsse, einminütige Foto-Wartezeit, bestehende Abschlusskennzeichen und zusätzliche Empfängerbitmaske. Statusinhalt wird unabhängig von den Schaltern für manuelle Mails gewählt; Kundensprache, freigegebene Nachweise, historischer Stand und konfigurierter Abschluss-PDF bleiben erhalten.
- Dauerhafter Versandbeleg und PHP-Kennzeichen werden vor SMTP atomar geschrieben. Konkurrierende NG-Instanzen lösen nur eine Übergabe aus. Unklare SMTP-Bestätigung oder Absturz nach Vormerkung führen nicht zu automatischem Neuversand. Bei Vorbereitungs-/Auditfehlern werden keine Kennzeichen verbraucht. Auftragsdetail → Auftragsmail → Automatische Statusmails zeigt die sechs Kombinationen und den gespeicherten Status, ohne Versand auszulösen.
- Dienst standardmäßig aus (`ORDER_STATUS_MAIL_WORKER_ENABLED=false`, explizite Niederlassungsliste). Zusätzlich sperrt eine aktive globale PHP-Freigabe die native Verarbeitung. Der echte Bestand hat weiterhin `AUTOMAILER_ENABLED=1`; keine Betriebsumschaltung und keine echten Mails ausgelöst. Vor einer späteren Umschaltung müssen alle PHP-Mailprozesse beendet und die noch ausstehenden Sonderwege berücksichtigt werden.
- **1069 Tests: 1066 bestanden, drei übersprungen, keine Fehler**; sechs gezielte Backendtests einschließlich umfangreicher SQL-Prüfung, 14 Frontendtests und Produktionsbuild erfolgreich. SQL: konkurrierende Instanzen, Kennzeichen vor SMTP, zusätzliche Empfänger ohne Kundenkonto-Verknüpfung, Foto-Wartezeit, ausgeschlossene Fahrzeuge, Rollback, Quellenänderung, PHP-Sperre, MyISAM-Verweigerung, inaktive/fremde Niederlassung, ungültige Adressen und verlorene SMTP-/DB-Bestätigung. `work/automatic-mail-verify.log`, `…-full-reports/`, `…-build-sources.json`, 786 Dateien.
- Browser: getrennte Empfängerarten, unklare Übergabe, ausgeschalteter Dienst, Lesefehler ohne alte Daten, Wiederherstellung und umbrechende Tabelle. Alle UI-Anfragen lesend (`…-ui-events.json`, `…-ui-verification.json`); Screenshot `work/automatische-statusmails-2026-10-18.png`. Echte DB: globale Vorgaben und 18 native Entscheidungen für drei jüngste Aufträge ausschließlich lesend geprüft (`…-read.json`). Port 8080 aktualisiert; Health/DB/Assetvergleich erfolgreich (`…-deployment.json`).
- Weiter im Abgleich: Stationsabschluss, Vermittlungsstau und dessen Rückmeldung, Endkundentracking sowie Annahmeverzögerung; keine vollständige Mail- oder Anwendungsparität behauptet.


## 18. Oktober 2026 – Persönliche Oberflächensprache

- Frischer SSH-Abgleich mit `admin/language.php`, `admin/menu.php`, `include/auth.inc.php` und `include/dbglobal.inc.php`; alte Sprachauswahl lesend geöffnet. Eigene Mitarbeiterpräferenz je Niederlassung und Rückkehr zur globalen Systemvorgabe nativ ergänzt. Dieselben PHP-Parameter werden verwendet.
- 26 registrierte Sprachen und 959 tatsächlich vorhandene englische Wörterbucheinträge lesend bestätigt. Statische Oberflächentexte verwenden quellbezogene beziehungsweise eindeutige gemeinsame Übersetzungen. Fehlende/mehrdeutige Texte bleiben deutsch; Geschäftsdaten, Namen, Adressen und Freitexte werden nicht übersetzt. Eine vollständige Übersetzung aller Oberflächentexte oder 26 Sprachen ist nicht behauptet.
- Atomare Speicherung mit Rechte-/Kontoprüfung, InnoDB-Sperren, Revision, Audit und Wiederholungskennung. Ungültige globale Vorgaben verhindern das Zurücksetzen; verlorene Speicherbestätigungen sind mit identischem Vorgang wiederholbar. Der Sprachwechsel erhält den geöffneten Arbeitsplatz.
- **1064 Tests: 1061 bestanden, drei übersprungen, keine Fehler**; acht gezielte Backendtests, 14 Frontendtests und Produktionsbuild erfolgreich. 781 Quelldateien geprüft (`work/ui-language-verify.log`, `…-full-reports/`, `…-build-sources.json`). SQL-Prüfungen umfassen eigene/fremde Konten, Kundenmitarbeiter, Niederlassung, Rollback, konkurrierende Änderungen, Sprachkatalogfehler und Wiederholung nach späterer Änderung.
- Browser mit isolierten API-Ergebnissen: Deutsch/Englisch, leeres spanisches Wörterbuch mit deutschem Rückfall einschließlich HTML-Sprachkennung, globale Vorgabe, verlorene Speicherbestätigung und unveränderte Geschäftsdaten. Screenshot `work/sprachauswahl-2026-10-18.png`, Nachweise `…-ui-events.json` und `…-ui-verification.json`. Port 8080 aktualisiert; Health UP, DB verbunden, sechs Assets in dist/JAR/HTTP identisch (`…-deployment.json`). Keine echten Geschäftsdaten geschrieben.
- Präzisierung des Restabgleichs: eingeschränkte FDS über Recht 28 benötigt zwei SQL-Vorgaben; beide fehlen im aktuellen Bestand, ebenso ausschließlich dafür berechtigte Mitarbeiter (`work/fds-restricted-read.json`). Die aktive Rechnungs-PDF-Menüseite `jobs/jb_inv_assoc.php` entspricht der bereits ergänzten Belegsammlung; der CSV-Menüpunkt `jobs/jb_exp_csv.php` dem vorhandenen Spezialexport 04. Automatische Mailprozesse und übrige nachgewiesene Spezialfunktionen werden weiter geprüft.


## 18. Oktober 2026 – Zentrale Auftrags- und Gutschriftenexporte

- Aktuelle Serverquellen erneut direkt per SSH abgeglichen: `export/export.php` (30b7b10e…), `export/exportrequests.inc.php` (f3c65b08…), `include/inc_dbfields2array.inc.php` (f0b7baa6…), `include/jb_detail_history.inc.php` (e85f0d42…) und `export/export4job2.php` (70bbafd7…). Alte Export-UI lesend geprüft; keine echten Exporte ausgelöst.
- Kategorien 4/5/6 mit je 64 geprüften Felddefinitionen, vorhandenen RETRANS-Profilen, optionalem Beginn und einschließlichem Enddatum, Bar-/Rechnungsfilter, Kunden-EID, Einzelauftrag, Fahrzeugarten und Zahlart. Verkaufsniederlassung und erlaubte eigene Erfassungsniederlassung beim Einzelauftrag, Zahlungs-/Stornofilter, Kalkulationskindfilter und PHP-Kostensplit-Gruppierung übernommen. Vorzeichenumwandlung für Gutschriften, Zahleradressen, Niederlassungskennungen, Maut, Zahlungsbedingungen und Windows-1252-Ausgabe geprüft. Hinterlegte SQL-Feldausdrücke werden ausschließlich gegen eine feste Liste geprüft, niemals ausgeführt.
- Dauerhafte Datei vor atomarer Auftragskennzeichnung; Audit 164 je Auftrag und Exportprotokoll. Historische PHP-kompatible Raw-Deflate-Kopien mit getrennten internen/Kunden-/Mailansichten sowie zusätzlichem vollständigem strukturiertem Quellstand werden vor dem Commit gesichert. Die MyISAM-Archivtabelle wird anschließend wiederholbar beschrieben. Bei Ausfällen lesen Auftragsmails die gesicherte Kopie; verlorene Bestätigungen erzeugen keine Dublette. Bestehende Archive werden erhalten; unvollständige Altarchive und übergroße Blob-Inhalte verhindern die Kennzeichnung. Fotos bleiben wie bisher im Nachweisspeicher und werden im nativen Archivleser anhand der Station geladen.
- **1060 Tests: 1057 bestanden, drei übersprungen, keine Fehler**. 17 gezielte Tests, zwölf Frontendtests. SQL-Prüfung: Filtergrenzen, Kostensplits, fremde Niederlassung, verlorene Dateibestätigung, Rollback, MyISAM-Ausfall vor/nach Archivschreiben, idempotente Wiederholung, historische Maildarstellung und Trennung interner Texte. Gesamtlauf `work/accounting-export-verify.log`, Berichte/Quellmanifest `…-full-reports/`, `…-build-sources.json`; 773 Dateien geprüft. Nach dem Gesamtlauf ausschließlich Filterbreiten im Frontend korrigiert, Frontend gebaut/getestet und ohne Backendänderung neu paketiert (`…-tested-sources.json`, `…-package.log`).
- Browser mit isolierten API-Ergebnissen: Kundenfilter erzwingt Rechnungsart, Einzelauftrag wird bei gelöschtem Kunden zurückgesetzt, Kategorien 5/6, Exportbestätigung abgebrochen, Download bytegenau zur Backendausgabe (1731 Bytes). Testharness korrigiert: Jackson-Testdatum als ISO-Datum statt Datumsarray. Screenshot `work/abrechnungsexport-2026-10-18.png`, Nachweis `…-ui-verification.json` und `…-ui-events.json`. Echte DB ausschließlich lesend: aktuelle Profile laden, Kategorie 4 mit zwei Datensätzen rendern; 5/6 am geprüften jüngsten Tag leer (`…-read.json`).
- Port 8080 aktualisiert und Health/DB/Assetgleichheit geprüft (`work/accounting-export-deployment.json`). Keine echten Geschäftsdaten geschrieben. Weitere konfigurierte Sonderformate und die übrigen dokumentierten Spezialfunktionen werden weiter abgeglichen; keine vollständige Anwendungsparität behauptet.


## 18. Oktober 2026 – Zentrale Stammdatenexporte

- Gesamtlauf: **1055 Tests, 1052 bestanden, drei übersprungen**, keine Fehler; 17 gezielte Prüfungen, zwölf Frontendtests und Produktionsbuild erfolgreich. 767 Dateien mit Buildmanifest abgeglichen (`work/master-export-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`).
- Isolierte MariaDB: echte Exportfeld-/Profildefinitionen der Kategorien 1/2/3; eigene Niederlassung, Rechnungsadressrückfall, Zahlungsziele, Barzahler-/EID-/Fahrerfilter, Vertrags- und Exportfristen, Fahrzeugkennzeichen, ungültiges Bestandsprofil, Dubletten, fremde Profile, entzogene Rechte und manipulierte SQL-Felddefinitionen. Schreiben nach dauerhafter Dateisicherung, Rollback mit Wiederaufnahme, geänderte Quellen, beschädigte Zwischendateien, doppelte Dateinamen, niederlassungsübergreifend geteilte Firmen, Löschvormerkungen, Gesamtexport ohne Kennzeichenänderung, MyISAM-Protokollausfall mit Wiederholung, Dateientfernung/Wiederherstellung und geschützte Dateiendung geprüft.
- Browser mit isolierten SQL-Testantworten: Kategorien/RETRANS-Profile, Vorschau, Löschhinweis/Abbrechen, Gesamtexport mit deaktivierter Kennzeichnung und Download. Heruntergeladene 1643 Bytes stimmen vollständig mit dem Backendexport überein; Windows-1252 statt UTF-8 erhält alte Feldbreiten. Screenshot `work/stammdatenexport-2026-10-18.png`; Belege `…-ui-verification.json`, `…-ui-events.json`.
- Reiner Leseabgleich mit der echten Datenbank: 1308 geänderte/neue Debitoren, RETRANS-Ausgabe 968868 Bytes, derzeit keine ausgewählten Kreditoren/Fahrzeuge. Felddefinitionen und alle drei RETRANS-Profile lesbar; vorhandenes DEFAULT-Fahrzeugprofil mit fremden Feldnummern wird als fehlerhaft angezeigt. Zahlungsziele und Zusatzformulare werden gesammelt abgefragt. Keine echten Geschäftsdaten geschrieben.
- Port 8080 aktualisiert; Health UP, DB verbunden, sechs Assets in dist/JAR/HTTP identisch (`…-deployment.json`). Verschlüsselte Ablagen und abweichender PHP-Exportpfad werden ausdrücklich gesperrt, bis ihre jeweilige Anbindung vorhanden ist. Zentrale Auftrags-/Gutschriftenexporte und ihre historischen Folgeverarbeitungen bleiben Gegenstand des nächsten Abgleichs.

## 18. Oktober 2026 – Auftragsbezogene Fahrerkarte

- Gesamtlauf: **1050 Tests, 1047 bestanden, drei übersprungen**, keine Fehler; 14 gezielte Prüfungen, zwölf Frontendtests und Produktionsbuild erfolgreich. 758 Quelldateien geprüft (`work/fleet-context-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`). Nach dem Gesamtlauf nur Zeilenumbrüche der Kartenhinweise verbessert, Frontend erneut gebaut/getestet und unverändertes Backend paketiert.
- Isoliertes SQL: bestehende CLASSIC-Rangfolge, globale Rangnummern bei ausgeblendeten Fremdniederlassungen, Sperrgründe, aktuelle/stabile Kurier-ID sowie eindeutige historische SID, mehrere Ablehnungen mit letzter Zeit, fremde Aufträge/Protokolle/Fahrer, mehrdeutige SID, Angebote/BWV/Storno, Status 0/1/9 und entzogene Rechte. Kartenabruf verändert weder Auftrag noch Autoranking.
- Browser: Kandidaten-/Gesamt-/zugeordnete Fahrerauswahl, Rangdetails, rosa Ablehnung, Vorrang der roten Belegung, deaktivierte Zuweisung bei Sperre und Fehlerzustand ohne veraltete Kandidaten; Wiederherstellung nach Fehler geprüft (`…-ui-verification.json`, `…-ui-events.json`). Screenshot `work/fahrerkarte-rang-und-ablehnung-2026-10-18.png`.
- Port 8080 aktualisiert; Health UP, DB verbunden, sechs Assets in dist/JAR/HTTP identisch (`work/fleet-context-deployment.json`). Keine echten Geschäftsdaten geschrieben.

## 18. Oktober 2026 – Statistik: Zusatzmontage und Kundenausschlüsse

- Gesamtlauf: **1049 Tests, 1046 bestanden, drei übersprungen**, keine Fehler; 33 gezielte Prüfungen, zehn Frontendtests und Produktionsbuild erfolgreich. 752 Quelldateien geprüft (`work/statistics-special-values-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`).
- Isoliertes SQL: nur/ohne Zusatzmontagebeträge, negative Grundbeträge, Brutto, Vergleiche und Zielstationen; Vergütung/Mengen bleiben unverändert. Zentrale Ausschlüsse werden auf den effektiven Kunden angewendet, einschließlich Historie/Bezugskunde und Kalkulation; nachträgliche Konfigurationsänderungen, wörtliche SQL-Sonderzeichen, Dubletten/Leerwerte und gesperrte Moduskombinationen geprüft. Aktions-/Abholzeitauswertungen bleiben entsprechend den PHP-Zweigen ausgenommen.
- Browser/CSV: 300 ohne Zusatzmontage, 107,10 brutto mit Vorjahr 17,85, nach dynamischem Kundenausschluss 60 mit leerem Vorjahr. Endgültige Kunden-Gruppierung mit den SQL-Testantworten abgeglichen (`…-ui-events.json`, `…-ui-verification.json`, `…-browser-checks.json`, `…-gross.csv`, `…-excluded.csv`). Screenshot `work/statistik-zusatzmontage-ausschluesse-2026-10-18.png`.
- Port 8080 aktualisiert; Health/DB/Assets in `work/statistics-special-values-deployment.json`. Keine echten Geschäftsdaten geschrieben.

## 18. Oktober 2026 – Statistik: Annahme bis Abholung

- Gesamtlauf: **1047 Tests, 1044 bestanden, drei übersprungen**, keine Fehler. 31 gezielte Prüfungen, zehn Frontendtests und Produktionsbuild erfolgreich; 749 Quelldateien geprüft (`work/statistics-pickup-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`).
- Isoliertes SQL: Sekunden 0/300/301/600/601/900/901/1200/1201, negative Dauer, fehlende Annahme/Stationszeit, fehlende und doppelte erste Station, Datumssentinel, Vergleichsjahr, weitere/fremde Niederlassung, Zusatzadressen, Gruppenfilter, absteigende Klassen und gesperrte Basis-Kombinationen. Mittelwert/Minimum/Maximum berücksichtigen ausschließlich gültige Messungen; leere reguläre Klassen erhalten echte Nullzählungen und keine erfundenen Messwerte.
- Browser: vier Abfragen, 13 Aufträge mit neun gültigen, drei fehlenden/mehrdeutigen und einer negativen Zeit; zweite Niederlassung ergibt 14 Aufträge und zwölf Ergebniszeilen. Fünf Vorjahresklassen mit vier Nullzeilen. Zwölf CSV-Zeilen, korrekte Minutenwerte, fehlende Mittelwerte, Spaltenanzahl und endliche Diagrammkoordinaten geprüft (`…-ui-events.json`, `…-ui-download.csv`, `…-ui-verification.json`, `…-browser-checks.json`).
- Screenshots `work/statistik-annahme-abholung-2026-10-18.png`, `work/statistik-abholzeitklassen-2026-10-18.png`. Port 8080 aktualisiert; Health/DB/Assets in `work/statistics-pickup-deployment.json`. Keine echten Geschäftsdaten geschrieben.

## 18. Oktober 2026 – Statistik: Mehrfach- und statische Gruppen

- Gesamtlauf: **1045 Tests, 1042 bestanden, drei übersprungen**, keine Fehler. 29 gezielte Tests, zehn Frontendtests und Produktionsbuild erfolgreich; 745 Dateien geprüft (`work/statistics-groups-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`). Nach dem Gesamtlauf nur die Gruppenüberschrift vereinfacht, Frontend erneut gebaut/getestet und ohne Backendänderungen paketiert (`…-package.log`).
- Isoliertes SQL: ODER innerhalb einer Mitgliederart, UND zwischen Kunden/Transporteuren/Mitarbeitern/Preis-/Leistungstypen, direkte Gruppenkunden, exakte Gruppentoken, Dubletten ohne vervielfachte Summen, leere und fremde Mitglieder, Stamm-/Benutzer-ID-Unterschied, Mehrniederlassung, Historie/Bezugskunde, Zielstationen/Aktionen, statische Gruppen der aktuellen Niederlassung, Mandant/Gruppe/Modus nachträglich entzogen.
- Browser: Mehrfachauswahl bleibt bei Suche erhalten, Summen 430/130, automatischer Kalkulationswechsel mit 224,68, leere Gruppe und Rückwechsel, statische Gruppen mit 240 sowie direkte Gruppenkunden mit 430 geprüft. CSV mit vier Zeilen und expliziter Gruppenauswahl, aktuelle/Vorjahressummen 430/65. Ein zunächst falscher Verzweigungsrang im synthetischen UI-Testserver wurde korrigiert; Schnittmenge anschließend mit exakt passender Auswahl wiederholt (`…-ui-verification.json`, `…-ui-union-events.json`, `…-ui-events.json`, `…-ui-download.csv`, `…-browser-checks.json`).
- Screenshots `work/statistik-gruppenauswahl-2026-10-18.png`, `work/statistik-statische-gruppen-2026-10-18.png`. Port 8080 aktualisiert; Health/DB/Assets in `work/statistics-groups-deployment.json`. Keine echten Geschäftsdaten geschrieben.

## 18. Oktober 2026 – Statistik: Kunden-Zusatzangaben

- Gesamtlauf: **1043 Tests, 1040 bestanden, drei übersprungen**, keine Fehler. 27 gezielte Prüfungen, zehn Frontendtests und Produktionsbuild erfolgreich; 742 Dateien im finalen Manifest (`work/statistics-customer-details-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`). Nach dem Gesamtlauf ausschließlich fehlende Tabellenüberschriften im Frontend ergänzt, erneut gebaut/getestet und ohne Änderung der geprüften Backendquellen paketiert (`…-package.log`).
- Isoliertes SQL: Rechnungs-/Lieferadressen der Stammkostenstelle, zugeordnete Betreuung mit E-Mail/Telefon, gleiche/mehrere/fehlende Adressen, falsche Adressrollen, fehlende Betreuer, historische und zugeordnete Kunden, Vergleiche, Zielstationen, Kalkulation und Aktionen. Anreicherung erfolgt nach Aggregation; Mengen und Geldsummen bleiben unverändert.
- Browser: Einzel-/Gesamtauswahl, verpflichtende Kundenaufteilung, historische Nachfolgeadresse, passende Überschriften und Zellanzahl sowie CSV mit mehrzeiligen Adressen und Formelpräfixschutz geprüft (`…-ui-events.json`, `…-ui-download.csv`, `…-ui-verification.json`, `…-browser-checks.json`). Screenshot `work/statistik-kunden-zusatzangaben-2026-10-18.png`.
- Port 8080 aktualisiert; Health UP, DB verbunden und sechs Frontenddateien in dist/JAR/HTTP identisch (`work/statistics-customer-details-deployment.json`). Keine echten Geschäftsdaten geschrieben.

## 18. Oktober 2026 – Statistik: Preisvarianten und Bruttodarstellung

- Gesamtlauf: **1041 Tests, 1038 bestanden, drei übersprungen**, keine Fehler. 25 gezielte Tests, zehn Frontendtests und Produktionsbuild erfolgreich; 739 Quelldateien geprüft (`work/statistics-prices-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`).
- Isoliertes SQL: Gesamt-/Grund-/TSZ-Formeln, getrennte Zuschläge, Vorrang von jobprice Typ 10 vor Grundvergütung/Provision, ausdrücklich gespeicherte Null und fehlende Werte, doppelte Grundvergütung/mehrdeutiges Fahrzeug ohne Summenvervielfachung, pauschale Bruttowerte trotz abweichendem Auftragssteuersatz, unveränderte Mengen/KM, Vorjahr, Zielstationen, Aktionen und Berechtigungs-/Parameterentzug.
- Browser: fünf Abfragen für Grundpreis/TSZ/getrennt/netto/brutto und unbekannte Zuschlagsvergütung. Zwei CSVs mit Brutto-Umsatz 464,10, Zuschlagsvergütung 77,35, EAU Zuschläge −5,95 sowie leeren unbekannten Beträgen und Qualitätszähler geprüft (`…-ui-events.json`, `…-ui-download.csv`, `…-ui-unknown-download.csv`, `…-ui-verification.json`, `…-browser-checks.json`). Abgeleitete Browser-Differenzen werden wegen binärer Gleitkommaarithmetik mit Toleranz 1e−9 geprüft.
- Screenshot `work/statistik-preisvarianten-2026-10-18.png`. Aktiver Stand auf Port 8080 gegen archiviertes Manifest/JAR/HTTP geprüft: Health UP, DB verbunden, sechs aktive Assets identisch (`work/statistics-prices-deployment.json`). Keine echten Geschäftsdaten geschrieben.

## 18. Oktober 2026 – Statistik: Transporteur-Aktionen

- Gesamtlauf: **1038 Tests, 1035 bestanden, drei übersprungen**, keine Fehler. 22 gezielte Tests, neun Frontendtests und Produktionsbuild erfolgreich; 736 Quelldateien geprüft (`work/statistics-courier-actions-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`).
- Isoliertes SQL: alle fünf PHP-Aktionskennungen, Mehrfachaktionen und exakte Zusammenfassung nach Auftrag/Fahrer/Benutzer/Niederlassung, Aktionsdatum unabhängig vom Auftragsdatum, Datumsgrenzen/Vorjahr, Uhrzeitfilter vor Zusammenfassung, erste passende Aktion für Tagesraster, Beteiligter statt ausführendem Fahrer, historische Kundenzuordnung mit Unternehmerfilter, fremdes Protokoll/Fahrer/Auftrag, fehlende Objekte, Rechte und Zielstationen.
- Browser: vier Abfragen, fünf zusammengefasste versus sechs Einzelaktionen aus vier Aufträgen; Fahrerfilter und Ablehnung. CSV mit Aktionsart, Zählweise und separater Auftragsanzahl, Umsatz 180 (`…-ui-events.json`, `…-ui-download.csv`, `…-ui-verification.json`, `…-browser-checks.json`). Screenshot `work/statistik-transporteur-aktionen-2026-10-18.png`.
- Port 8080 aktualisiert; Health UP/DB verbunden/sechs Assets identisch (`work/statistics-courier-actions-deployment.json`). Keine echten Geschäftsdaten geschrieben.

## 18. Oktober 2026 – Statistik: Kundenservices und Auftragsmerkmale

- Gesamtlauf: **1035 Tests, 1032 bestanden, drei übersprungen**, keine Fehler; 19 gezielte Tests, neun Frontendtests und Produktionsbuild erfolgreich. 733 Dateien geprüft (`work/statistics-job-features-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`).
- SQL: ODER-Servicebitmaske einschließlich Bit 32, doppelte Servicelabel, ausgeblendete/entfernte Katalogeinträge, globale Freigabe und Entzug, vorhandene Merkmale trotz Inhalt 0/leer, Dubletten, falscher Objekttyp/ähnlicher Schlüssel, UND-Kombinationen, Gegenmengen, fremde Niederlassung, Vorjahr, Historie, Zuordnungen, Zielstationen und Kalkulation.
- Browser: vier Abfragen mit Service-Mehrfachauswahl, kombinierten Merkmalen und getrennten Ausschlüssen. CSV enthält aktuelle/Vorjahressummen 10/50 sowie die genaue Filterzusammenfassung (`…-ui-events.json`, `…-ui-download.csv`, `…-ui-verification.json`, `…-browser-checks.json`). Screenshot `work/statistik-kundenservices-2026-10-18.png`.
- Auf Port 8080 bereitgestellt, Health UP/DB verbunden/sechs Assets identisch (`work/statistics-job-features-deployment.json`). Keine echten Geschäftsdaten geschrieben.

## 18. Oktober 2026 – Statistik: Kunden- und Fahrerzuordnungen

- Gesamtlauf: **1032 Tests, 1029 bestanden, drei übersprungen**, keine Fehler. 16 gezielte Tests, neun Frontendtests und Produktionsbuild erfolgreich; 730 Quelldateien gegen Manifest geprüft (`work/statistics-relationships-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`).
- Isoliertes SQL: direkte Kunden-/Fahrerzuordnung, Fahrer einzeln/nur Fahrer/alle nach Unternehmer, separate Nummernsemantik, fehlende/selbstreferenzierende/fremde Eltern, erlaubte weitere Niederlassung, historische und zugeordnete Kunden, Vergleichsjahr, Kalkulation und Zielstationen. Umsätze und eindeutige Qualitätszählungen bleiben korrekt.
- Browser: sechs Abfragen, Gruppenkunden und Fahrer getrennt/kombiniert, Pflichtnummer blockiert leere Abfrage. CSV: fünf Ergebniszeilen, aktuelles Jahr fünf Aufträge/180, eine unerreichbare Unternehmerzuordnung (`…-ui-download.csv`, `…-ui-events.json`, `…-ui-verification.json`, `…-browser-checks.json`). Screenshot `work/statistik-unternehmerzuordnung-2026-10-18.png`.
- Port 8080 aktualisiert; Health UP/DB verbunden/sechs Assets identisch (`work/statistics-relationships-deployment.json`). Keine echten Geschäftsdaten geschrieben.

## 18. Oktober 2026 – Statistik: Kundenzeitfilter und Diagramme

- Gesamtlauf: **1030 Tests, 1027 bestanden, drei übersprungen**, keine Fehler. 14 gezielte Prüfungen, neun Frontendtests und Produktionsbuild erfolgreich; 727 Dateien einschließlich Frontendtests/-Konfiguration geprüft (`work/statistics-cohort-charts-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`).
- Isoliertes SQL: verschiedene Anlagedaten/Statuswechsel, inklusive Monatsgrenzen, fehlende Datumswerte, kombinierte Filter, Vorjahr, historischer Nachfolger, Bezugskunde, Kalkulationspositionen, globale Sperre mit HQ-Übersteuerung und späterer Entzug. JSON-Altanfragen und neue kombinierte Filter geprüft.
- Diagrammtests: exakte Gruppenidentität über unabhängige Zeiträume, fehlende Gruppen, gewichtete BSG aus Summen, unbekannte Werte, negative Beträge, Nullsummen und Diagrammgrenzen. Browser bestätigt alle sechs SVG-Arten ohne ungültige Koordinaten, Vergleichssummen 50/110 und 50/0, Quote-/Negativhinweise und fehlende KM. Kombinierter Kundenfilter und CSV mit zwei Zeilen/Summe 110 geprüft (`…-ui-verification.json`, `…-ui-events.json`, `…-ui-download.csv`, `…-browser-checks.json`).
- Screenshots: `work/statistik-tortendiagramm-2026-10-18.png`, `work/statistik-diagrammvergleich-2026-10-18.png`. Port 8080 aktualisiert; Health/DB/Assetvergleich in `work/statistics-cohort-charts-deployment.json`. Keine echten Geschäftsdaten geschrieben.

## 18. Oktober 2026 – Statistik: Leistungskalkulation

- Gesamtlauf: **1028 Tests, 1025 bestanden, drei übersprungen**, keine Fehler. Zwölf gezielte Prüfungen, fünf Frontendtests und Produktionsbuild erfolgreich; 717 Dateien gegen Manifest geprüft (`work/statistics-calculation-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`).
- Isoliertes SQL: Positions-/Auftragsanzahl, mehrere identische Positionen, Mengen, Gutschriften trotz positivem Auftragsbetrag, Dezimalpreise, 15./16./31. Monatstag, Vorjahresvergleich, Preis-/Leistungstypfilter, fremde Kataloge, berechtigte Niederlassungswahl und Wiederholung je Zielstation.
- Browser: vier vollständige Requests, Halbmonat, kombinierte Typfilter, Gutschrift und Rückwechsel zu historischen Kunden geprüft. CSV enthält sechs Ergebniszeilen mit getrennten Mengen-/Positionsspalten (`work/statistics-calculation-ui-verification.json`, `…-ui-events.json`, `…-ui-download.csv`, `work/statistik-leistungskalkulation-2026-10-18.png`).
- Port 8080 aktualisiert; Bereitstellungsprüfung in `work/statistics-calculation-deployment.json`. Keine echten Geschäftsdaten geschrieben.

## 18. Oktober 2026 – Statistik: alte Kundennummern

- Gesamtlauf: **1028 Tests, 1025 bestanden, drei übersprungen**, keine Fehler. Zwölf gezielte Prüfungen, fünf Frontendtests und Produktionsbuild erfolgreich; 714 Dateien gegen Manifest geprüft (`work/statistics-historical-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`).
- Isoliertes SQL: eindeutige und doppelte identische Zuordnungen, mehrere Nachfolger, fehlende/fremde Ziele, nur ein Zuordnungsschritt, Filter nach aktueller Nummer, ausgewählte Niederlassungen, Vergleichszeiträume und eindeutige Qualitätszählung bei mehreren Zielstationen. Keine Vervielfachung von Umsatz und Aufträgen.
- Browser mit synthetischen Daten: Altzuordnung aktiviert, Warnhinweis, aktuelle Kundennummer S3 und CSV mit Qualitätszählung geprüft (`work/statistics-historical-ui-verification.json`, `…-ui-events.json`, `…-ui-download.csv`, `work/statistik-alte-kundennummern-2026-10-18.png`).
- Port 8080 aktualisiert: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/statistics-historical-deployment.json`). Keine echten Geschäftsdaten geschrieben.

## 18. Oktober 2026 – Statistik: Anforderungen und Stationsaufteilungen

- Gesamtlauf: **1028 Tests, 1025 bestanden, drei übersprungen**, keine Fehler. Zwölf gezielte Prüfungen, fünf Frontendtests und Produktionsbuild erfolgreich; 714 Dateien gegen Manifest geprüft (`work/statistics-stations-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`).
- SQL: Pflicht- und optionale Anforderungen, UND-Verknüpfung mehrerer Kürzel, exakte Token statt Teiltreffer/Wildcards, doppelte Katalogkürzel, Suchwert mit Prozent/Unterstrich, entfernte Vorgaben, Adressen der Stationen 1/2 trotz doppelter Abholstation und dritter Station. Alle Zielstationen mit gezielt wiederholten Beträgen/KM und separater Anzahl verschiedener Aufträge; fehlende Zieladressen und fremde Niederlassungen ausgeschlossen.
- Browser: Auswahl bleibt bei der Anforderungssuche erhalten; beide Adressspalten, Warnhinweis und Zähleinheit der Zielstationen sowie heruntergeladene CSV geprüft (`work/statistics-stations-ui-events.json`, `…-ui-verification.json`, `…-ui-download.csv`, `work/statistik-adressgruppen-2026-10-18.png`, `work/statistik-zielstationen-2026-10-18.png`).
- Port 8080 aktualisiert: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/statistics-stations-deployment.json`). Keine echten Geschäftsdaten geschrieben.

## 18. Oktober 2026 – Statistikfilter und Branchenaufteilung

- Gesamtlauf: **1027 Tests, 1024 bestanden, drei übersprungen**, keine Fehler; elf gezielte Prüfungen, fünf Frontendtests und Produktionsbuild erfolgreich. 714 Dateien gegen getestetes Manifest geprüft (`work/statistics-filters-verify.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`).
- Isolierte SQL-Prüfung: inklusive und dezimale Grenzen, Null/0, fünf kombinierte Maße, SID/Typ, Erstellerkonto gegenüber abweichender Herkunft, Branchen ohne Zuordnung, gezahlter/zugeordneter Kunde, doppelte Zusatzdaten, Vergleichssummen, absteigende Gruppen, entfernte Typen, Mandanten-/Niederlassungsrechte. Alte JSON-Anfragen ohne Filterblock bleiben kompatibel.
- Browser: widersprüchliche Grenzwerte vor dem Request gesperrt; vollständiger Filterrequest, Branchen- und Vorjahresergebnis, leere Trefferliste und heruntergeladene CSV geprüft (`work/statistics-filters-ui-verification.json`, `…-ui-download.csv`, `work/statistik-filter-ergebnis-2026-10-18.png`). Ausschließlich synthetische Daten und Wegwerfdatenbank.
- Port 8080 aktualisiert: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/statistics-filters-deployment.json`).

## 18. Oktober 2026 – Kundenauftragsbearbeitung und Tracking-E-Mail

- Vollständiger Regressionstest nach Korrektur der Wunschkurier-Tabellensperre: **1020 Tests, 1017 bestanden, drei übersprungen**, keine Fehler (`work/customer-order-edit-verify2.log`, `…-full-reports/`, `…-verification.json`, `…-build-sources.json`). 26 gezielte Tests sowie fünf Frontendtests und Produktionsbuild erfolgreich. Dieser Lauf liegt vor der folgenden Tracking-Erweiterung.
- Isolierte MariaDB: Stationsanlage/-reihenfolge mit stabilen IDs, Preisneuberechnung und Tarifänderung nach Vorschau, Wunschkurier/Statusübergang, Barzahlung/Kostenteilung, Vorbestellung, geschützte Texte, ausgeblendete Angaben, Berechtigungsentzug während Routenprüfung, Signatur-/Status-/MyISAM-Sperren, spätes Audit-Rollback und identische Wiederholung. Alte Auftragsidentität, Erstellzeit und Herkunft bleiben erhalten.
- Browser mit synthetischen Daten: Station hinzufügen/verschieben, Kommissionsänderung, Preisvorschau, simulierte 503 und bytegleiche Wiederholung mit gesperrten Eingaben (`work/customer-order-edit-ui-verification.json`, `…-ui-events.json`, `work/kundenauftrag-bearbeiten-ergebnis-2026-10-18.png`).
- Abschließender gemeinsamer Gesamtlauf: **1023 Tests, 1020 bestanden, drei übersprungen**, keine Fehler (`work/customer-tracking-final-verify.log`, `…-final-full-reports/`, `…-final-verification.json`). 713 Quelldateien gegen das getestete Manifest geprüft. Die Staging-Routine invalidiert kompilierte Klassen nun bei Inhaltsänderungen; der zuvor erkannte Zeitstempelfehler wurde durch einen sauberen Gesamtbuild und diesen Folgelauf ausgeschlossen.
- Tracking-Prüfungen: Freigabeentzug, E-Mail-Validierung, private Tracking-Teile, Stationsfolge, GPS-Hinweis, unveränderte Altbelege und konkurrierende Wiederholung mit anderer Adresse. Zusätzlich ausgeblendete Lademaße und Fernauftragsklassifizierung ohne aktuelle Route abgesichert. Browser mit synthetischen Daten: ungültige Adresse, Reihenfolgewechsel, Vorschau und identische Wiederholung nach 503 (`work/customer-tracking-ui-verification.json`, `work/kunden-tracking-vorschau-2026-10-18.png`).
- Port 8080 mit beiden Erweiterungen neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-tracking-deployment.json`).

## 17. Oktober 2026 – Datentransfer-Sonderzugänge

- Vollständiger Regressionstest: **1019 Tests, 1016 bestanden, drei übersprungen**, keine Fehler. 86 gezielte Tests und fünf Frontendtests bestanden. Nach dem Gesamtlauf ausschließlich die bereits im Browser geprüfte gegenseitige Frontendsperre lokaler/externer Aktionen neu paketiert; Backendquellen unverändert. 709 finale Quelldateien geprüft (`work/transfer-portal-verify.log`, `…-full-reports/`, `…-verification.json`, `…-targeted-retest.log`, `…-final-sources.json`).
- Isolierte SQL-/Dateisystemtests: Sonderkonto ohne Mitarbeiter, Typ 5, feste Mandanten-/Objekt-/Dateizuordnung, Unterverzeichnisse, Upload/Download/Entfernen/Wiederherstellen, Zähler am tatsächlichen Kundenobjekt, Wiederholung, abgebrochener Beleg, geänderte Konfiguration/Typ/Niederlassung, fremde EIDs, Administratorvorbehalt externer Server und Live-Entzug während Download. Bestehende Dokument-/FTP-Funktionen mitgeprüft. HTTP-Session/CSRF und gesperrte Fremd-API-Pfade geprüft.
- Browser mit synthetischen Daten: eigener Arbeitsplatz, feste Serverauswahl, lokale/externe Aktionen, eigener Bestätigungsdialog, simulierte 503, vollständige Sperre und bytegleiche Wiederholung (`work/transfer-portal-ui-verification.json`, `…-ui-events.json`, `work/datentransfer-sonderzugang-2026-10-17.png`, `work/datentransfer-sonderzugang-ergebnis-2026-10-17.png`). Echte Datenbank nur auf aggregierte Kontotyp-/Konfigurationsinformationen gelesen; keine echten Dateien oder Konten verändert.

- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/transfer-portal-deployment.json`).

## 17. Oktober 2026 – Kundenaufträge: Texte und Kontakte

- Gesamtprüflauf: 1015 Tests, davon 1011 bestanden, drei übersprungen und eine fehlerhafte Testannahme zum automatisch aktualisierten `tr_modify`. Nach Korrektur ausschließlich dieser Testannahme: 83 gezielte Tests bestanden (Kundenauftragstexte, SQL-Integration, API-Sicherheit). Produktionscode gegenüber dem Gesamtprüflauf unverändert. Fünf Frontendtests, Produktionsbuild und Paketierung erfolgreich; 705 finale Quelldateien geprüft (`work/customer-order-texts-verify.log`, `…-full-reports/`, `…-final-targeted.log`, `…-final-targeted-reports/`, `…-build-sources.json`).
- Isolierte SQL-Tests: eigene Kunden-/Kostenstellen-/Niederlassungszuordnung, aktuelle Rechte und Bearbeitungsfreigabe, Status/Export/Abrechnung/Sperrzeit/erledigte Stationen, unveränderte Preise und Adressen, geschützte interne Texte und Barzahlungsmarker, ausgeblendete Bemerkungen, veraltete Vorschau, Stationsmanipulation, identische Wiederholung, vollständiger Rollback bei spätem Auditfehler und InnoDB-Schreibvoraussetzung.
- Browser mit synthetischen Daten: Änderungsvorschau und Bestätigung, unterbrochene Speicherantwort, gesperrte Eingaben, bytegleiche Wiederholung und eigener Verwerfen-Dialog (`work/customer-order-texts-ui-verification.json`, `…-ui-events.json`, `work/kundenauftrag-texte-vorschau-2026-10-17.png`, `work/kundenauftrag-texte-ergebnis-2026-10-17.png`). Echte Datenbank ausschließlich lesend auf Schema/Feldlängen/Freigaben geprüft; keine echten Aufträge geändert.
- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-order-texts-deployment.json`). Kundenänderungen an Route, Stationen, Zeiten, Fahrzeug und Preisen bleiben gesondert offen.

## 17. Oktober 2026 – Import-PLZ-Sonderreihenfolge

- 17 gezielte Tests bestanden, einschließlich SQL-Regression für ZONE_JOBS und BMW. Fünf Frontendtests, Produktionsbuild und Paketierung erfolgreich. 701 finale Quelldateien geprüft. Letzter vollständiger Testlauf bleibt der BMW-/ALLERGO-Lauf mit 1007 Tests/1004 bestanden/drei übersprungen (`work/import-postal-order-targeted.log`, `…-test-reports/`, `…-verification.json`, `…-final-sources.json`).
- Tests: beide PLZ-Listen und deren Vorrang, gleiche PLZ/stabile Reihenfolge, unbekannte PLZ/andere Kunden, mehr als 25 Stationen, Abschalten der Optimierung, geänderte Kundenkennung, unzulässige Abholverschiebung für andere Kunden. Isolierte Speicherung prüft Abholstation an Position 3, Zielpreise an Positionen 1/2, Zahlerkostenstelle, Tourdaten und identische Wiederholung ohne Routen-Netzaufruf.
- Browser: angezeigte PLZ-Sonderregel und tatsächliche Abholposition, simulierte 503, gesperrte Eingaben und identische Wiederholung einschließlich Reihenfolge `[2,1,0]`. Kein echter Auftrag angelegt (`work/import-postal-order-ui-events.json`, `work/import-plz-reihenfolge-2026-10-17.png`, `work/import-plz-reihenfolge-ergebnis-2026-10-17.png`).

- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/import-postal-order-deployment.json`).

## 17. Oktober 2026 – BMW und ALLERGO

- Vollständiger Build: **1007 Tests, 1004 bestanden, drei übersprungen**, 118 Suiten, keine Fehler. Je 93 gezielte Tests für BMW und ALLERGO mit Dokumentquellen/Schema-/Zugriffsschutzregression, fünf Frontendtests und Produktionsbuild erfolgreich. Backendquellen unverändert; nach dem Gesamtprüflauf ausschließlich Bestätigungsblock und Tabellen-Zellausrichtung im Frontend korrigiert, neu gebaut und paketiert. Abschließend 698 Dateien gegen finales Manifest geprüft (`work/allergo-import-verify.log`, `…-verification.json`, `…-full-reports/`, `…-final-sources.json`, `…-final-package.log`, `work/bmw-import-targeted.log`).
- BMW in Wegwerfdatenbank: Kundenzonen einschließlich Zone 0, Abholstation, 09 Uhr, sechste Spalte als Kommission, physische Dateizeile einschließlich Leerzeile, eigener Doppelimportkontext, geprüfte Optimierungsfolge, atomarer Rollback und Formatbindung im Wiederholungsbeleg.
- ALLERGO in Wegwerfdatenbank: 46-Spaltenabbildung, internationaler Empfänger, Adresszusätze, Erledigt-Status/Unterschriftsname am Absender, 16 Uhr trotz abweichender Terminspalten, Paketbemerkungen, Nullpreise, bestehende PHP-info_0-Kennungen, Teilimporte, fremde Kennungen/Kunden, Bestätigung der kundengebundenen Namensübertragung, stale preview, vollständiger Rollback, MyISAM-Schreibziel, Tageswechsel und Rechteentzug. Keine echten Daten verändert.
- Browser: BMW-Zonen/Optimierungsfolge und identische Wiederholung; ALLERGO aus Kundenablage vorbefüllt, 46-Spalten-Daten, Namensbestätigung, unklare Antwort mit gesperrter Bearbeitung und identischer Wiederholung. Layout nach Korrektur erneut visuell geprüft; eigener Verwerfen-Dialog funktioniert. `work/bmw-import-ui-verification.json`, `work/allergo-import-ui-events.json`, `work/allergo-import-vorschau-2026-10-17.png`, `work/allergo-import-ergebnis-2026-10-17.png`.

- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/allergo-import-deployment.json`).

## 17. Oktober 2026 – TIMS-Import

- Vollständiger Build: **1001 Tests, 998 bestanden, drei übersprungen**, 116 Suiten, keine Fehler. Gezielter Vorlauf 96 Tests, fünf Frontendtests/Produktionsbuild erfolgreich. Manifest mit 692 Dateien unverändert (`work/tims-import-verify.log`, `…-verification.json`, `…-full-reports/`, `…-build-sources.json`).
- Wegwerfdatenbank: 06:00 Uhr, Kommissionsübernahme in Bemerkungen, alle Firmen-/Kontaktmodi, globale Vorgabe und Niederlassungsvorrang, Konflikt bei Parameteränderung, Kontext TIMS, Wiederholungsbeleg und Formatbindung. Gemeinsame TOURS-/DHL- und Dokumentquellenregression erfolgreich.
- Browser: Auswahl TIMS, Hinweise zur konfigurierten Trennung, getrennte Firmen-/Kontaktdarstellung und Kommissionsbemerkung in der Vorschau, unklare Antwort mit gesperrten Eingaben, identische Wiederholung einschließlich Format. Synthetische Daten, keine echten Aufträge erstellt (`work/tims-import-ui-events.json`, `work/tims-import-vorschau-2026-10-17.png`, `work/tims-import-ergebnis-2026-10-17.png`).

- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/tims-import-deployment.json`).

## 17. Oktober 2026 – DHL-Import

- Vollständiger Build: **998 Tests, 995 bestanden, drei übersprungen**, 115 Suiten, keine Fehler. Gezielter Vorlauf 96 Tests, fünf Frontendtests/Produktionsbuild erfolgreich. Manifest mit 690 Dateien unverändert (`work/dhl-import-verify.log`, `…-verification.json`, `…-full-reports/`, `…-build-sources.json`).
- SQL-Tests prüfen DHL-Spalten ohne Kommission, Datum, 17:45/12:45 Uhr in tatsächlich gespeicherten Aufträgen, getrennte Importkontexte, Rollback bei spätem Fehler, Formate im Wiederholungsbeleg und aktuelle Rechte. TOURS-Regression und Dokumentquellen im Gesamtlauf erfolgreich.
- Browser mit synthetischen SQL-Daten: DHL-Auswahl, CSV/Vorschau, unterbrochene Speicherantwort, gesperrte Eingaben und identische Wiederholung einschließlich `format=DHL`. Keine echten Aufträge erstellt (`work/dhl-import-ui-events.json`, `work/dhl-import-vorschau-2026-10-17.png`, `work/dhl-import-ergebnis-2026-10-17.png`).

- Port 8080 neu gestartet: Health UP, Datenbank verbunden und sechs Frontenddateien in dist/JAR/HTTP identisch (`work/dhl-import-deployment.json`).

## 17. Oktober 2026 – Tourenimport TOURS

- Vollständiger Build: **994 Tests, 991 bestanden, drei übersprungen**, 114 Suiten, keine Fehler. Gezielter Vorlauf 94 Tests, fünf Frontendtests und Produktionsbuild erfolgreich. Alle 688 Dateien des Quellenmanifests unverändert (`work/tours-import-verify.log`, `…-verification.json`, `…-full-reports/`, `…-build-sources.json`).
- Isolierte SQL-Tests: mehrere datierte Touren, Teilimporte, PHP-Doppelimportmarker einschließlich führender Nullen, mehrzeilige Bemerkungen, Kontakt-/Telefonaufbereitung, fremde Kunden/Niederlassungen, veraltete Vorschau, Rechteentzug, MyISAM-Schreibziel und kompletter Rollback bei spätem Fehler. Namensübertragung nur nach Bestätigung und ausschließlich bei diesem Kunden; Wiederholungsbeleg bindet diese Bestätigung. Gemeinsamer Job-Erzeuger erneut mit dem Zonenimport geprüft.
- Browser mit synthetischen SQL-DTOs: Vorschau, gesperrte Übernahme ohne Namensbestätigung, unterbrochene Speicherantwort mit gesperrten Eingaben, bytegleich wiederholter Speicherauftrag und bestätigtes Ergebnis (`work/tours-import-ui-events.json`, `work/tourenimport-vorschau-2026-10-17.png`, `work/tourenimport-ergebnis-2026-10-17.png`). Keine echten Aufträge angelegt.
- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/tours-import-deployment.json`). Standardformat umgesetzt; manuell übergebene Gruppen-Spaltenlayouts bleiben gesondert offen.

## 17. Oktober 2026 – Zonenbezogener Auftragsimport

- Vollständiger Build: **990 Tests, 987 bestanden, drei übersprungen**, 113 Suiten, keine Fehler. Gezielter Vorlauf 99 Tests, fünf Frontendtests und Produktionsbuild erfolgreich. Quellenmanifest mit 683 Dateien unverändert (`work/zone-jobs-verify.log`, `…-targeted.log`, `…-test-summary.json`, `…-test-reports/`, `…-build-sources.json`). Ein zunächst beanstandeter direkter Transaktionsstatus-Zugriff im Testhelfer wurde in die erlaubte DatabaseServiceTest-Grenze verschoben; Gesamtlauf danach wiederholt und erfolgreich.
- Wegwerfdatenbank: Gruppierung einschließlich Zone 0, optimierte Folge, Nullpreise/Steuerkennung, Telefonnummer/Barbemerkung, Tourdaten, bestehende PHP-Marker, geänderte Vorschau, fremder Kunde, Rechteentzug, ungültige Stationsfolgen, Tageswechsel, Wiederholung nach Erfolg und vollständiger Rollback bei spätem Belegfehler. MyISAM-PLZ-Basis erlaubt, MyISAM-Schreibziel abgewiesen. Routenberechnung läuft außerhalb der DB-Transaktion; Nichterreichbarkeit bleibt als Warnung sichtbar. Parser prüft CSV-Zitate, Apostrophe, Leerzeilenzählung, führende Nullen, Feld-/Zeilengrenzen. Gemeinsamer Quelldateiabruf umfasst auch ZONE_JOBS.
- Browser mit synthetischen SQL-DTOs: Kundenimport öffnen, CSV einfügen, zwei Zonen/optimierte Folge/Barhinweis prüfen, simulierte 503 mit gesperrten Eingaben und identische Wiederholung, Abschluss mit Auftragsnummern. Kein realer Auftrag angelegt (`work/zone-jobs-ui-events.json`, `…-ui-verification.json`, `work/zonen-auftragsimport-2026-10-17.png`, `work/zonen-auftragsimport-ergebnis-2026-10-17.png`).
- Echte Datenbank ausschließlich lesend: Referenz-/Schreibtabellen, notwendige Spalten und 13 externe Stationskostenstellen-Parameter geprüft. `serviceplz` ist MyISAM, alle benötigten Schreibtabellen InnoDB. Keine echten Personen, Adressen oder Aufträge gelesen/geschrieben (`work/zone-jobs-read-probe.log`).
- Port 8080 neu gestartet und geprüft: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/zone-jobs-deployment.json`). Standardformat abgeschlossen; zusätzliche Gruppen-Spaltenlayouts und kundenspezifische Spezialreihenfolge sind ausdrücklich separate Restpunkte im Menüabgleich.

## 17. Oktober 2026 – Kundenimporte aus der Dokumentablage

- 89 gezielte Tests bestanden: Dokumentablage/Quelldateien, bestehende Kundenimporte, PLZ-Import und API-Zugriffsschutz. Fünf Frontendtests sowie Produktionsbuild erfolgreich. Letzter vollständiger Lauf: 985 Tests, 982 bestanden, drei übersprungen im PLZ-Block. Keine Behauptung eines erneuten Gesamtprüflaufs (`work/document-import-targeted.log`, `…-frontend-test.log`, `…-test-reports/`).
- SQL-/Dateisystemtests mit Wegwerfdaten: alle drei Kundenformate, Windows-1252-Umlaute, falsche Formatkennung, falscher Dokumentbereich, fremder Kunde und live entzogenes Preisrecht. Browser mit synthetischen DTOs prüft die drei Schaltflächen, Importart, Originalinhalt und Zeichensatz. In diesem Browsertest keine Importübernahme mit abweichenden Vorschau-Testdaten ausgeführt (`work/document-import-ui-events.json`, `work/kundenimporte-dokumentablage-2026-10-17.png`).
- Quellenmanifest (679 Dateien) unverändert; Port 8080 neu gestartet. Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/document-import-build-sources.json`, `…-deployment.json`).

## 17. Oktober 2026 – PLZ-Nachbarschaftsimport

- Vollständiger Backendbuild: **985 Tests, 982 bestanden, 3 übersprungen, 0 Fehler**. Zuvor 83 gezielte Tests erfolgreich; fünf Frontendtests und Produktionsbuild erfolgreich. Anschließend ausschließlich Scrollbereich/Tabellenklassen im Frontend korrigiert, erneut gebaut und paketiert. 679 Dateien gegen finales Quellenmanifest geprüft (`work/postal-import-verify.log`, `…-targeted.log`, `…-package.log`, `…-test-summary.json`, `…-test-reports/`, `…-build-sources.json`).
- Isolierte MariaDB mit echter MyISAM-PLZ-Basis und InnoDB-Nachbarschaften: gerichtetes Ergänzen, Spaltenreihenfolge mit Lücken, bestehende Sortierung, doppelte Dateiangaben, führende Nullen, fremde Niederlassung, veraltete Vorschau, geänderte PLZ-Basis, mehrdeutige Länder/Zuordnungen, Rechteentzug, geänderte Wiederholungsdaten und vollständiger Rollback bei Belegfehler. Nichttransaktionale Zieltabelle ausdrücklich abgewiesen. Dokumentquelle einschließlich Änderungs- und Pfadprüfung getestet.
- Browser auf 18780 mit SQL-Testdaten: Vorschau, verlorene Speicherantwort, identische Wiederholung, Erfolg, Öffnen einer Importdatei aus der Dokumentablage, Verwerfen mit eigenem Dialog und Entwertung der Vorschau bei Änderung. Nach visueller Prüfung scrollbaren Inhalt und lesbare Tabelle korrigiert; Aktionsleiste bleibt sichtbar. `work/plz-nachbarschaftsimport-2026-10-17.png`, `…-ui-events.json`, `…-ui-verification.json`.
- Reale Datenbank ausschließlich Engine-/Schemaabfragen: `serviceplz` MyISAM; `serviceplzneighbour`, generische Ablage, Mitarbeiter und Niederlassungen InnoDB. Keine echten Nachbarschaften verändert oder importiert (`work/postal-import-read-probe.log`). Lokale Bereitstellung mit Health/DB/Assetprüfung in `work/postal-import-deployment.json`.

## 17. Oktober 2026 – Externe Dateiübertragungen

- Vollständiger Backendbuild: **982 Tests, 979 bestanden, 3 übersprungen, 0 Fehler**. Zuvor 85 gezielte Tests erfolgreich. Fünf Frontendtests und Produktionsbuild erfolgreich; 675 Dateien gegen Quellenmanifest geprüft (`work/remote-transfer-verify.log`, `…-targeted.log`, `…-test-summary.json`, `…-test-reports/`, `…-build-sources.json`).
- Isolierte SQL-/Dateisystemtests: alle vier Aktionen, idempotente Wiederholung, Antwortverlust nach lokalem Abschluss und entferntem Umbenennen, unveränderte Nutzdaten trotz nachträglicher Änderungen, Fremdakteur/-HQ, Adminbeschränkungen, Rechteentzug, veränderte Serverkonfiguration, Pfadprüfung, Namenskollisionen, Sicherung/Wiederherstellung, Erhaltung neu angelegter Fremddateien und einmalige PHP-Umbenennung/Objektpräfixe. Anfangs falscher Hashvergleich sowie ein Mockito-Spy im Test korrigiert.
- Echte Protokolltests gegen ausschließlich lokale synthetische FTP-, FTPS- und SFTP-Server: Listen/Lesen/Schreiben/Umbenennen/Entfernen, UTF-8, Linkschutz, Kollisionen, Ablehnung falscher Zertifikatsnamen und unbekannter SSH-Hostschlüssel. `work/remote-transfer-protocols.log`, Testprogramm `work/RemoteTransferProtocolProbe.java`. Testzertifikat nur für diesen Prüfprozess vertraut; Anwendungsschutz unverändert. Transportimplementierung anhand der offiziellen Apache-Commons-Net-Dokumentation geprüft.
- Browser auf 18776: Übernahme mit Ersetzungsbestätigung, simulierte 503, gesperrte Eingaben/Schließen, exakt identische Wiederholung, externes Entfernen/Wiederherstellen und Senden. Screenshot `work/externe-daten-2026-10-17.png`, `work/remote-transfer-ui-events.json`, `…-ui-verification.json`.
- Reale Datenbank ausschließlich aggregierte Parameteranzahlen gelesen: zwei konfigurierte Server-/Benutzer-/Passworteinträge, zwei entfernte Pfade und eine Serverliste; keine Geheimnisse ausgegeben, keine echten Dokumente gelesen oder übertragen (`work/remote-transfer-read-probe.log`). Lokale Auslieferung auf 8080 in `work/remote-transfer-deployment.json` geprüft.

## 17. Oktober 2026 – Zentraler Datentransfer und Dokumentbereiche

- Vollständiger Backendlauf: **979 Tests, 976 bestanden, 3 übersprungen, 0 Fehler**. Zuvor 82 gezielte Tests erfolgreich; fünf Frontendtests und Produktionsbuild erfolgreich. 670 Quell-/Frontenddateien gegen Buildmanifest geprüft (`work/data-transfer-verify.log`, `…-test-summary.json`, `…-test-reports/`, `…-build-sources.json`).
- SQL-/Dateisystemtests auf isolierter MariaDB: allgemeine Namen ohne Präfix, identischer Upload, Entfernen/Wiederherstellen, Mandantenwurzel ohne Unterpfad, fremde HQ, geschützte Standard- und HQ-Verzeichnisse, Pfadmanipulation, Rechteentzug während Download, getrennte Upload-/Downloadrechte. Auftrags-/Mitarbeiterablage mit Zählern und Objektrechten, Suchgrenzen, exakte Auftragsnummern und wörtliche Suchsonderzeichen geprüft. Sitzung/CSRF für alle sechs Dokumentarten und neue Endpunkte geprüft.
- Browser mit synthetischen SQL-Daten auf 18775: Menü, allgemeine Ablage, Archivverzeichnis, Download, Auftragsnummernsuche und Auftragsdokumente. Nachweis `work/datentransfer-2026-10-17.png`, Ereignisse `work/data-transfer-ui-events.json`.
- Reale Datenbank ausschließlich Schema-/Metadatenabfragen; keine echten Dokumente oder Personendaten gelesen und keine Änderungen (`work/data-transfer-read-probe.log`). PHP frisch per SSH und alte UI gelesen. Lokale Auslieferung wird in `work/data-transfer-deployment.json` geprüft.

## 17. Oktober 2026 – Kunden-CSV, Exportablage und Wiederaufnahme

- Vollständiger Backendlauf: **979 Tests, 976 bestanden, 3 übersprungen, 0 Fehler** (`work/invoice-csv-verify.log`, `work/invoice-csv-test-summary.json`, archivierte Berichte `work/invoice-csv-test-reports/`). Gezielt zuvor 80 erfolgreich. Frontend: 5 Tests und Produktionsbuild erfolgreich. 667 Quell-/Frontenddateien gegen Buildmanifest geprüft.
- Echte SQL-Integration ausschließlich auf der isolierten MariaDB 127.0.0.1:33079/crm_qa: Datumsauswahl trotz altem Auftragsdatum, Export-/Storno-/HQ-Grenzen, 21 Felder mit Zuschlägen/Dezimalen/Fixpreis, Ankunft/letzte Station, CSV-Trennzeichen und Formelschutz, fehlende Rechte/fremder Kunde, Gruppenkunden ohne Eigenaufträge/fremde HQ-Kinder. Datenänderung zwischen Vorschau und Download sowie während Vorschauerzeugung erkannt.
- Dateisystem-/SQL-Grenze getestet: Speicherung und identische Wiederholung, fehlende Speicherantwort, Wiederaufnahme mit dem ursprünglichen Inhalt trotz nachträglich geänderter Auftragsdaten, Verwerfen, Entfernen und Wiederherstellen. Vorhandene Kundenportal-Exporttests liefen im vollständigen Testlauf ebenfalls erfolgreich. Neue Routen auf Sitzung, CSRF und Fachrechte geprüft.
- Browser auf 18774 mit aus dem SQL-Test erzeugten synthetischen Daten: CSV-Vorschau, konkreter Zeitraum 10.10.2026, Download, zwei identische Speicheranfragen nach simulierter 503-Antwort, gesperrte Eingaben während unklarer Antwort, Dateiliste, Entfernen/Bestätigen/Wiederherstellen, veralteten Download abweisen und Vorschau neu laden. Nachweis `work/kunden-csv-2026-10-17.png`; Ereignisse/Prüfergebnis `work/invoice-csv-ui-events.json` / `work/invoice-csv-ui-verification.json`. Ein anfänglicher Namenskonflikt im isolierten Testserver wurde behoben; der Anwendungscode war davon nicht betroffen.
- Reale SQL-Prüfung beschränkt auf Schema/Parameter/Engines (`work/invoice-csv-read-probe.log`): keine echten Geschäftsdatensätze, keine Änderungen. Server-PHP und alte CSV-UI frisch geprüft. Lokale Auslieferung auf 8080 mit Health-/Dateihashprüfung dokumentiert in `work/invoice-csv-deployment.json`.

## 17. Oktober 2026 – PDF-Auftragsbelege je Rechnung

- 80 gezielte Tests erfolgreich, fünf Frontendtests und Produktionsbuild erfolgreich. Letzter Gesamtbuild im vorangegangenen Zuordnungsblock: 979 Tests, 976 bestanden, drei übersprungen. Quellenmanifest mit 664 Dateien unverändert (`work/invoice-documents-targeted.log`, `…-frontend-tests.log`, `…-frontend.log`, `…-build-sources.json`).
- SQL/PDF: zwei Aufträge über drei Seiten, Umlaute, HTML-Escaping, eingebettete Unterschrift, alter Auftrag außerhalb des Übersichtszeitraums, fremde Niederlassung/Rechte, ungültige Nummer, Sortierung, fehlende Vorschau, Stationsänderung, Änderung während der PDF-Erstellung, defekte Unterschrift und offene Rechnungszuordnung. Authentifizierung/CSRF für beide neuen Endpunkte geprüft. Testdaten um Pflichtfeld ergänzt und Unterschriftskoordinaten als SQL-Parameter gebunden; Seitenumfang mit zusätzlichen Stationen geprüft.
- Alle drei PDF-Seiten gerendert und visuell geprüft; Text und Bildobjekte zusätzlich ausgelesen. `work/invoice-documents.pdf`, `work/invoice-documents-page-1.png` bis `…-3.png`. Ausschließlich synthetische Daten.
- Browser: Belegsammlung öffnen, zwei Seiten ansehen, Gesamtdownload, Sortierungswechsel, simulierte Änderung mit entfernter Vorschau/gesperrtem Download, erneutes Laden. `work/invoice-documents-ui-events.json`, `…-ui-verification.json`, `work/rechnungsauftraege-2026-10-17.png`.
- Echte Datenbank ausschließlich lesend: Stations-/Preis-/Rechnungsspalten und eindeutige Fahrzeugtypen geprüft; keine echten Aufträge, Rechnungen, Unterschriften oder Kontakte abgerufen (`work/invoice-documents-read-probe.log`).
- Port 8080 neu gestartet und geprüft: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/invoice-documents-deployment.json`).

## 17. Oktober 2026 – Rechnungszuordnung und Korrekturen

- Gesamtbuild: **979 Tests, 976 bestanden, drei übersprungen**, 110 Suiten, keine Fehler. Gezielter Vorlauf 80 Tests, fünf Frontendtests und Produktionsbuild erfolgreich. Quellenmanifest mit 661 Dateien unverändert (`work/invoice-assignment-verify.log`, `…-targeted.log`, `…-test-summary.json`, `…-test-reports/`, `…-build-sources.json`).
- Wegwerfdatenbank: Auftrags-/Erledigungsdatum, Fahrzeugfilter, Exportvoraussetzung, nicht zugeordnete/zugeordnete Aufträge, Korrekturfreigabe, fremde Niederlassung, geänderte Vorschau, geänderte Wiederholung, Rechte, Null-/Nulldatum, alte Vorgangsformate, Teilfehler und fremde PHP-Korrektur. Nach simuliertem Antwortverlust bleiben MyISAM-Ergebnisse eindeutig und lassen sich fortsetzen. Test-Erwartung für direkten Rechtefehler korrigiert.
- Browser mit synthetischen SQL-DTOs: zwei exportierte Aufträge, Fahrzeugfilter, explizite Korrektur, Vorher-/Nachher-Prüfansicht, simulierte 503 mit gesperrten Eingaben, zwei bytegleiche Speicheranforderungen und erfolgreicher Abschluss. Datumsdarstellung im Testserver auf API-Format normalisiert (`work/invoice-assignment-ui-verification.json`, `…-ui-events.json`, `work/rechnungszuordnung-2026-10-17.png`).
- Echte Datenbank ausschließlich lesend: `invoice` weiterhin MyISAM, Vorgangs-/Auftrags-/Preis-/Niederlassungstabellen InnoDB; Rechnungsfelder und Fahrzeugtypen bestätigt. Keine echten Aufträge oder Rechnungen gelesen/geschrieben (`work/invoice-assignment-read-probe.log`).
- Port 8080 neu gestartet und geprüft: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/invoice-assignment-deployment.json`).

## 17. Oktober 2026 – Kundenkarte

- 84 gezielte Tests erfolgreich, darunter Kundenportal, Zentralenkarte, API-Zugriffsschutz und neue Kennungslisten-Unitfälle. Fünf Frontendtests und Produktionsbuild erfolgreich. Letzter vollständiger Lauf im Kurierzuweisungsblock: 976 Tests, 973 bestanden, drei übersprungen. Quellenmanifest mit 660 Dateien vor Übernahme unverändert (`work/customer-map-targeted.log`, `…-frontend-tests.log`, `…-frontend.log`, `…-build-sources.json`).
- SQL-Integration: Freigabe und Entzug, leere/ungültige Liste, genaue Fahrzeugauswahl, Telefonfallback, Ortungsquellen, veraltete/ungültige/abgeschaltete Positionen, Vortag/Zukunft, fremder Mandant, gleiche Kennung mehrfach, deaktivierte Niederlassung, unabhängiges Listenrecht und ausschließlich GET. Keine internen Auftragsdaten in Antworten. Test-Metadatenschema an reale Spalten angepasst.
- Browser mit synthetischen SQL-Daten: Fahrzeuggruppe öffnen, Fahrzeug auswählen, Kontaktdaten und veraltete Ortung anzeigen; beim dritten Abruf simulierte 403, Karte und Fahrzeugdaten entfernt, automatische Aktualisierung beendet. `work/customer-map-ui-events.json`, `…-ui-verification.json`, `work/kundenkarte-2026-10-17.png`.
- Reale Datenbank nur lesend: Spalten mit leeren Ergebnissen und aggregierte Konfiguration geprüft, keine echten Positionen/Telefonnummern/Aufträge gelesen und keine Schreibzugriffe (`work/customer-map-read-probe.log`).
- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-map-deployment.json`).

## 17. Oktober 2026 – Kundenseitige Kurierzuweisung

- Sauberer Gesamtbuild: **976 Tests, 973 bestanden, drei übersprungen**, 109 Suiten, keine Fehler. Gezielter Vorlauf mit 153 Tests, fünf Frontendtests und Produktionsbuild erfolgreich. `work/customer-assignment-verify.log`, `…-targeted.log`, `…-test-summary.json`, `…-test-reports/`, `…-build-sources.json`.
- SQL-Integration: eigene/untergeordnete Kostenstelle, Kundenrecht und Freigabeentzug, Related-Modus, fremder oder abgemeldeter Kurier, doppelte Fahrzeuganmeldung, Status/Storno/Export/Fremddisposition/Bearbeitungssperre, geänderte Vorschau, identische und veränderte Wiederholung. Bevorzugungen als MyISAM geprüft; atomarer Rollback nach bereits vorbereiteten PDA-Kommandos und Freimeldezeit, 30-Sekunden-Rückruf, Erhaltung alter Rankingzeilen, alle drei geografischen Modi und Survey-Metadaten.
- SQL-Prüfung korrigierte Aliasüberschneidungen der Tabellenlocks und Zeitzonenabhängigkeit der Sperrzeit. Rankingabfragen verwenden eindeutige Aliase auch in mehrfach verwendeten Unterabfragen.
- Browser mit synthetischen SQL-DTOs: Auftragsdetail → Kurierauswahl → Warnungen/Rankingfolge → Bestätigung → simulierte 503 → identischer Wiederabruf → Erfolg. `work/customer-assignment-ui-events.json`, `…-ui-verification.json`, `work/kunden-kurierzuweisung-2026-10-17.png`. Keine echte Disposition ausgeführt.
- Reale Datenbank ausschließlich lesend: Parameteranzahl, Anfahrts-/Rankingspalten und InnoDB-Engines der fünf Schreibtabellen geprüft; keine Aufträge oder Kurierpositionen gelesen (`work/customer-assignment-read-probe.log`).
- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-assignment-deployment.json`).

## 17. Oktober 2026 – Kunden-Barzahlung und Kostenteilung

- Sauberer gezielter Build mit **153 erfolgreichen Tests**, fünf Frontendtests und Produktionsbuild erfolgreich. Letzter vollständiger Lauf im vorangegangenen Tourenblock: 976 Tests, 973 bestanden, drei übersprungen. Quellenmanifest vor Übernahme unverändert. `work/customer-payments-targeted.log`, `…-frontend-tests.log`, `…-frontend.log`, `…-build-sources.json`.
- SQL in Wegwerfdatenbank: beide Cash-Tarifmodi, Systemzahler/tatsächlicher Zahler/Auftraggeber, genau eine Kassierstation, Kopie ohne alte Beträge, Split 99/100 mit 50 Euro netto je Kostenstelle, Wiederholung, Rechteentzug, fehlende/fremde Zahler, Einzelkostenstelle, verborgene Preisbeträge, identische und widersprüchliche Parameter sowie Rechnungstext bei ausgeblendeten Stationsbemerkungen.
- Browser mit synthetischen SQL-DTOs: Barauftrag geladen, Kassierstation beim Umsortieren mitgeführt, Kostenteilung 100/19/119 Euro geprüft, zweimal exakt identische Speicheranfrage nach simulierter 503 und eindeutige Erfolgsmeldung. `work/customer-payments-ui-events.json`, `…-ui-verification.json`, `work/kundenauftrag-zahlung-2026-10-17.png`.
- Reale SQL-Prüfung ausschließlich lesend: Spalten und elf Niederlassungsschalter bestätigt, keine echten Auftrags-/Adressdaten gelesen und keine Schreibzugriffe (`work/customer-payments-read-probe.log`).
- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-payments-deployment.json`).

## 17. Oktober 2026 – Kundentouren und Kopien

- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-tours-deployment.json`).

- Sauberer Gesamtbuild: **976 Tests, 973 bestanden, drei übersprungen, keine Fehler**, 109 Suiten. Gezielter Lauf **149 Tests erfolgreich**, fünf Frontendtests und Produktionsbuild erfolgreich. Danach nur Darstellung des Quellenhinweises im Frontend angepasst und neu gebaut/paketiert. `work/customer-tours-verify.log`, `…-targeted.log`, `…-frontend-tests.log`, `…-frontend.log`, `…-test-summary.json`, `…-build-sources.json`.
- SQL-Prüfung: Laden ohne Bearbeitungssperre, Stationslücken, Warenbewegung 0, fremde Kostenstelle/private Hinweise, Referenzfallback, Fest-/Servicepreis, Strecken-/Fahrzeugänderung, Quellenänderung vor und nach erfolgreichem Speichern, identische Wiederholung/geänderte Anfrage, Herkunftsverknüpfung, Zonenpreis, Rechteentzug, 51 Touren über zwei Seiten ohne fremde Zahlerdaten, Fahrzeugausschluss/Standard und Pflichtmaße. Leere Ausschlusslisten wurden während der Prüfung korrigiert.
- Browser mit synthetischen SQL-DTOs: gespeicherte Tour geladen, Stationsreferenz übernommen, 85 Euro netto / 101,15 Euro brutto, interne Hinweise entfernt, Wiederholung nach simulierter 503 mit identischen Payloads und eindeutiger Erfolgsmeldung. `work/customer-tours-ui-events.json`, `…-ui-verification.json`, `work/kundentour-kopieren-2026-10-17.png`. Schreibpfade separat gegen Wegwerfdatenbank geprüft.
- Reale SQL-Prüfung ausschließlich lesend: neue Abfragen/Spalten bestätigt, 550 vorhandene Kopiermodus-Parameter; keine echten Auftrags-/Adresszeilen gelesen oder geschrieben (`work/customer-tours-read-probe.log`). Kein Fremdsystemversand.

## 17. Oktober 2026 – Kundenseitige Auftragserfassung

- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-entry-deployment.json`).

- Sauberer Gesamtbuild: **976 Tests, 973 bestanden, drei übersprungen, keine Fehler**, 109 Suiten. Gezielter Lauf mit **149 Tests erfolgreich**; fünf Frontendtests und Produktionsbuild erfolgreich. Logs `work/customer-entry-verify.log`, `…-targeted.log`, `…-frontend-tests.log`, `…-frontend.log`, Zusammenfassung `…-test-summary.json`.
- SQL-Integration: Anlage/Herkunft/Besteller/Auftraggeber, Mehrfachsendung und geänderter Wiederholungsaufruf, Unterkostenstelle/Standardzahler, fremde Kostenstellen/Kuriere/Filter, verbotene Zentralenfunktionen, Erfassungsentzug vor Wiederholung und während der Routenprüfung, ausgeblendete Preise/Bemerkungen/Lademaße, Vorbestellung und mehrdeutige Winterzeit, Selbstbedienungsrabatt, Wunschkurier/Beziehungsentzug, manueller Kundenstatus und Rollback einer fehlgeschlagenen Stationsanlage inklusive anschließendem Wiederholen. Zusätzliche Preis-Unitfälle für Rundung, Tarif-/Frachtunterschied und ungültigen Rabattsatz.
- Browser mit synthetischen Antworten: zwei Stationen, 100 Euro netto / 119 Euro brutto, Entwertung der Vorschau nach Referenzänderung, Bestätigung, simulierte unterbrochene Speicherantwort, gesperrte Eingaben und identischer Wiederabruf. `work/customer-entry-ui-verification.json`, `…-ui-events.json`, `work/kundenauftrag-erfassung-2026-10-17.png`. Die echten Schreibpfade sind separat gegen die Wegwerfdatenbank geprüft.
- Reale Datenbankprüfung ausschließlich lesend (`work/customer-entry-read-probe.log`), null Kundenauftrags-/Adresszeilen und null Schreibzugriffe. Alte PHP-UI teilweise defekt; Serverquellen frisch gelesen.
- Testaufbau korrigiert: MariaDB-Booleanabbildung der Herkunftsspalte und zuvor veränderter Testbenutzername. Fehlender Java-Import behoben; sauberer Build in separatem Verzeichnis verhindert gleichzeitig vom Editor erzeugte Klassendateien.

## 17. Oktober 2026 – Kundenroute und Maut

- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-route-deployment.json`).

- Nach dem erfolgreichen Gesamtbuild des vorherigen Blocks: **80 gezielte Tests erfolgreich**, fünf Frontendtests und Produktionsbuild erfolgreich; sauber neu paketiert, Quellenmanifest unverändert (`work/customer-route-targeted.log`, `…-frontend-tests.log`, `…-frontend.log`, `…-package.log`, `…-build-sources.json`). Kein weiterer vollständiger Testlauf für diesen kleinen Folgeblock.
- SQL-Integration: aktuelle/veraltete/zukünftige GPS-Daten, Typ 0/2/3 und ausgeschaltete/LBS-Ortung, fremder Mandant/geänderte Fahrzeugzuordnung, ungültige Koordinaten, Fallback, fehlende Basis, alle Stationen erledigt, Stationslücken/-duplikate, Parameter-/Status-/Rechteentzug und URL-Escaping. Maut netto/Related-Modus, eingeschränkte Kostenstelle, ungültige/mehrdeutige Werte und PDF-Summe geprüft.
- Browser mit synthetischen SQL-DTOs: aktuelle Position, Wechsel zur letzten erledigten Station, Entfernung des Links bei fehlender Routenbasis und 12,50 Euro Maut / 122,50 Euro Gesamtsumme. Kein Google-Aufruf und keine echten Fahrzeugpositionen abgerufen. `work/customer-route-ui-verification.json`, `work/customer-route-ui-events.json`, `work/kundenauftrag-route-2026-10-17.png`.

## 17. Oktober 2026 – Kundenbörse, Historie und Stationsartikel

- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-history-deployment.json`).
- Sauberer Gesamtbuild: **973 Tests, 970 bestanden, drei übersprungen, keine Fehler**, 109 Suiten. Jeweils 80 gezielte Tests für Börse und anschließend Historie/Stationsartikel erfolgreich; fünf Frontendtests und Produktionsbuild erfolgreich. Quellenmanifest unverändert (`work/customer-history-verify.log`, `…-targeted.log`, `…-test-summary.json`, `…-build-sources.json`; Börsenlauf `work/customer-bourse-targeted.log`). Zwei Testaufbaufehler (Composite-Key-Insert und SQL-Literal mit Semikolon) behoben; Produktiv-SQL-Schutz unverändert.
- Börsen-SQL: 51 Angebote über zwei Seiten, mehrere Gebote/doppelte Station ohne Preisvervielfachung, fehlendes/Null-Euro-Gebot, Rabatt-/Gesamtsummen, Status-/Datums-/Storno-/Kostenstellen-/Gruppenkundengrenzen, Related-/Cash-Vorrang, Sortierung, Rechte- und Modusentzug, fehlende Tabelle.
- Historie: Erfasser/Umschaltung, 53 freigegebene Ereignisse über zwei Seiten, ausschließlich Vorgänge 1/10, fremde Mandanten/Kunden/Kontakte, sofortiger Rechteentzug, fehlende Historientabelle. Stationsartikel: Konfiguration, Barcode, Stationstrennung, ausgeblendete interne Hinweise, Konfigurationsentzug und PDF-Revision. Paketanzahl mit 0/3, 2/3, mehreren Artikeln/Scans und ungültigem Wert. Beide PDF-Seiten visuell geprüft.
- Browser ausschließlich mit synthetischen SQL-DTOs: Börsen-Seitenwechsel und Gesamtsumme 200 Euro; Historienseite 2, Stationsartikel und Paketanzahl. Nachweise `work/customer-bourse-ui-verification.json`, `work/customer-history-ui-verification.json`, `work/kundenboerse-gesamtsumme-2026-10-17.png`, `work/kundenauftrag-historie-2026-10-17.png`, `work/kundenauftrag-stationsartikel-2026-10-17.png`.
- Reale Prüfung nur lesend: Historien-/Artikelschema gültig, 13 HQ-Historienparameter aktiv; Börsenparameter und -tabellen fehlen (`work/customer-history-read-probe.log`, `work/customer-bourse-read-probe.log`). PHP-Börsen-UI HTTP 500 und fehlendes `jobs3`; kein vollständiger Echt-Börsenvergleich möglich. Keine realen Auftrags-/Konten-/Parameteränderungen.

## 17. Oktober 2026 – Kundenetiketten

- Gesamtbuild: **973 Tests, 970 bestanden, drei übersprungen, keine Fehler**, 109 Suiten. Danach ausschließlich Auflösung der Etiketten-PNG-Vorschau erhöht; die betroffenen Pfade mit **80 gezielten Tests** erneut erfolgreich geprüft und neu paketiert (`work/customer-labels-verify.log`, `…-preview-targeted.log`, `…-package.log`, `…-test-summary.json`, `…-final-sources.json`). Fünf Frontendtests und Frontendbuild erfolgreich.
- SQL-/PDF-Integration: mehrere und nicht fortlaufende Zielstationen, Rückrichtung, 60×40-mm- und A4-PDF-Abmessungen, Umlaute, Barcode aus beiden PDF-Seiten mit 300 dpi zurückgelesen, geänderte Adresse/Vorlage/Feldtypen, fremde Kunden/Unterkostenstellen, Rechteentzug, doppelte Stationen und unbekanntes Papierformat. Kein physischer Druckertest.
- Browser mit synthetischen Daten: zwei Etiketten, Seitenwechsel, Hin-/Retouren-PDF-Downloadanforderungen, vertauschte Adressen und scharfe Vorschau geprüft (`work/customer-labels-ui-verification.json`, `work/kundenetiketten-retoure-2026-10-17.png`). PHP-Dialog selbst anhand der aktuellen Servervorlage verglichen; kein echter PHP-Generierungsaufruf mit temporären Dateischreibzugriffen.
- Reale lesende Vorlagenprüfung: 22 Konfigurationen (Hin/Retoure × elf Niederlassungen), alle gültig und A4, null Kundenaufträge gelesen und null Schreibzugriffe (`work/customer-labels-config-probe.log`). Referenzvorlagen und Logo mit Herkunft festgehalten.
- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-labels-deployment.json`). Keine vollständige Anwendungsparität behauptet.

## 17. Oktober 2026 – Kundenauftragsnachweise und PDF

- Gesamtbuild: **973 Tests, 970 bestanden, drei übersprungen, keine Fehler**, 109 Suiten; fünf Frontendtests und Frontendbuild erfolgreich. Manifest unverändert (`work/customer-order-evidence-verify.log`, `…-test-summary.json`, `…-build-sources.json`).
- 80 gezielte Tests mit ergänzter Kundenintegration: Stationssignatur/-foto, Kunde/Kostenstelle/Rechte, fehlende Berechtigung nach Ansicht, ausgeblendete interne Notizen/Koordinaten/Trackingtoken, kundenspezifischer Parameter-Vorrang, Nettosumme und PHP-Bruttofaktor, fremde Leistungszeilen, defekte Signatur, kollidierende B2B-Kennung, ausschließlich erledigte PDF-Aufträge und Versionswechsel vor Download. PDF-Text und beide gerenderten Seiten geprüft. Reale Ganzzahltypen für Auslage/Gewicht und zusammengesetzter Leistungsschlüssel im Test abgeglichen.
- Browser mit synthetischen Daten: öffentliche Daten/Leistungssummen, Unterschrift, Stationsfoto, zwei PDF-Seiten vor/zurück und Downloadanforderung geprüft (`work/customer-order-evidence-ui-verification.json`, `…-ui-events.json`, `work/kundenauftrag-nachweise-2026-10-17.png`, `work/kundenauftrag-pdf-2026-10-17.png`). Keine echten Kundenfotos oder -belege abgerufen.
- Fünf lesende Schemaabfragen plus Parameter-/Datentypprüfung gegen den echten Bestand erfolgreich, keine Schreibzugriffe (`work/customer-order-evidence-read-probe.log`). Paketanzahlzweig noch nicht mit eigenem gezielten Datensatz geprüft; Sonderlayouts und vollständige Parität nicht bestätigt.
- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-order-evidence-deployment.json`).

## 17. Oktober 2026 – Kundenauftragsdetail: Artikel und Fotos

- Gesamtbuild: **973 Tests, 970 bestanden, drei übersprungen, keine Fehler**, 109 Suiten; fünf Frontendtests und Frontendbuild erfolgreich. Quellenhashes unverändert (`work/customer-order-additions-verify.log`, `…-test-summary.json`, `…-build-sources.json`).
- 84 gezielte Tests einschließlich SQL-/Dateiintegration: PHP-Freigaben, Station-2-Filter, konfigurierbare Spalten, Summen und Steuer-ID, Split-Schutz, interne Suchtexte, fehlende/ungültige Bilder, Pfadversuche, fremde Kunden und kollidierende B2B-Kennungen, mehrteilige B2B-Bilder, Rechte-/Parameterentzug während Datei-I/O. Keine Produktivmutationen.
- Browser mit synthetischen Daten: Artikel-/Bruttosummen, Dateifoto und B2B-Foto, deaktiviertes fehlendes Foto, Detailaktualisierung sowie Standardzustand der automatischen Aktualisierung bei Statuswechsel geprüft (`work/customer-order-additions-ui-verification.json`, `…-ui-events.json`, `work/kundenauftrag-artikel-2026-10-17.png`, `work/kundenauftrag-fotos-2026-10-17.png`). Der tatsächliche Ablauf des 60-Sekunden-Timers wurde nicht separat abgewartet.
- Reale lesende Schema-/Parameterprüfung erfolgreich, drei Schemaabfragen ohne Treffer und ohne Schreibzugriff (`work/customer-order-additions-read-probe.log`). Im aktuellen Parameterbestand nur globale Seriennummernoption gesetzt; Artikel-/Fotoansicht bleiben ohne jeweilige PHP-Freigabe ausgeblendet. Kein echter Kundenfotoabruf durchgeführt.
- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-order-additions-deployment.json`). Weitere Bereiche bleiben offen.

## 17. Oktober 2026 – Kundenexport-Dateiverwaltung

- Sauberer Gesamtbuild: **973 Tests, 970 bestanden, drei übersprungen, keine Fehler**, 109 Suiten; fünf Frontendtests bestanden. Nach der Browserprüfung ausschließlich Dialogbeschriftung im Frontend korrigiert, Frontend neu gebaut und mit unverändert geprüftem Backend erneut paketiert (`work/customer-export-management-verify.log`, `…-package.log`, `…-test-summary.json`, `…-build-sources.json`).
- 94 gezielte Tests mit erweiterter SQL-Integration: einmalige Speicherung/Entfernung/Wiederherstellung; unveränderlicher Inhalt nach Preisänderung; Teil-Datei, Verbindungsfehler, SQL-Rollback nach Dateiverschiebung, halbfertiger Hardlink, geänderte Kundenzuordnung, Rechteentzug, Fremd-/Mehrfachreferenzen, veränderte Datei, fehlende Datei und unveränderte Originalmetadaten nach Wiederherstellung. Test-Kundenkennung der Kopfzeilenprüfung korrigiert, anschließend alle Tests grün.
- Browser: Serverspeicherung und Entfernen nach simuliertem Antwortverlust mit jeweils zwei identischen Anforderungen, Wiederherstellung, Fortsetzen und Verwerfen offener Speicherung; Fortsetzen bei geändertem Kundenumfang deaktiviert. Korrekte Bestätigungsbeschriftung geprüft. Ausschließlich synthetische Testdaten (`work/customer-export-management-ui-verification.json`, `…-ui-events.json`, `work/kundenexport-dateiverwaltung-2026-10-17.png`).
- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Dateien in dist/JAR/HTTP identisch (`work/customer-export-management-deployment.json`). Keine echten Exportdateien durch Tests erzeugt, entfernt oder wiederhergestellt. Weiterarbeit am PHP-Abgleich; keine vollständige Anwendungsparität behauptet.

## 17. Oktober 2026 – Gespeicherte Kundenexportdateien

- Gesamtbuild erneut erfolgreich: **973 Tests, 970 bestanden, drei übersprungen, keine Fehler**, 109 Suiten; fünf Frontendtests und Build erfolgreich. Quellenhashes vor Übernahme unverändert (`work/customer-export-files-verify.log`, `work/customer-export-files-test-summary.json`, `work/customer-export-files-build-sources.json`).
- 94 gezielte Tests, darunter 55 Dateieinträge über zwei Seiten, bytegenauer Download inklusive Null-/Nicht-UTF8-Bytes, fremde Kunden/HQs, Unterkostenstellenzugang, physische Namenskollision, Pfadwechsel, fehlende Dateien, Symlinks und Rechteentzug während des I/O. Datenbank und Dateien bleiben unverändert. Initiale Spring-Konstruktorzuordnung korrigiert, danach alle Tests grün.
- Reale SFTP-Leseprobe: fünf verschiedene Kunden, 45 Dateireferenzen; **alle 45 Dateien fehlen im aktuellen Testserververzeichnis**, daher kein echter Dateidownload verifiziert. Keine Schreibzugriffe (`work/customer-export-files-read-probe.log`).
- Browser mit synthetischen SQL-DTOs: Pagination, verfügbare und gesperrte Downloads und Binärabruf geprüft (`work/customer-export-files-ui-verification.json`, `work/kundenexport-dateien-2026-10-17.png`).
- Port 8080: Health UP, DB verbunden, sechs Dateien in dist/JAR/HTTP identisch (`work/customer-export-files-deployment.json`).

## 17. Oktober 2026 – Kundenexport

- Gesamtbuild: **973 Tests, 970 bestanden, drei übersprungen, keine Fehler**, 109 Suiten. Fünf Frontendtests und Produktionsbuild erfolgreich; Quellen vor Paketübernahme unverändert (`work/customer-exports-verify.log`, `work/customer-exports-test-summary.json`, `work/customer-exports-build-sources.json`).
- 92 gezielte Tests: alle drei Kategorien mit aktuellen 217/7/20 Felddefinitionen, Rabatt-/Bruttobeträge, Stornoausschlüsse, Gruppen-/Unterkostenstellen-/Mandantengrenzen, Kalkulation/Fallback, unabhängiges Exportrecht, sofortiger Entzug, fremde Profile, gespeichertes SQL als abgelehnte Metadaten, Revisionen, Namenskollision, idempotente Anlage/Änderung und vollständiger Rollback nach Auditfehler. Formatregeln, Bedingungen, Grenzen, Verschachtelung, unverändert wörtliche Datenwerte und Dateinamen geprüft.
- Echter Bestand: **25 Konten, 75 Exportabfragen, 34 Altprofile**, keine Schreibzugriffe. 22 verwaiste Profile mit ausschließlich gelöschten Feldnummern identifiziert (`work/customer-exports-read-probe.log`, `work/customer-exports-profile-reference.log`).
- Browser: vier Exportzeilen, Download mit identischer Auswahl, Profilformat und Antwortverlust mit zwei bytegleichen Speicheranforderungen; nur synthetische Daten (`work/customer-exports-ui-verification.json`, `work/customer-exports-ui-events.json`, `work/kundenexport-profil-2026-10-17.png`).
- Port 8080: Health UP, DB verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-exports-deployment.json`). Kein Anspruch auf vollständige Parität; Serverdateiverwaltung und Sonderexporte werden anschließend bearbeitet.

## 17. Oktober 2026 – Kundenstatistik

- Sauberer Gesamtbuild: **961 Tests, 958 bestanden, 3 übersprungen, keine Fehler**, 108 Suiten; fünf Frontendtests und Produktionsbuild erfolgreich. Quellhashes vor Paketübernahme unverändert (`work/customer-statistics-verify.log`, `work/customer-statistics-test-summary.json`, `work/customer-statistics-build-sources.json`).
- 83 gezielte Tests bestanden, darunter erweiterte isolierte Kundenintegration: Netto-/Storno-/Gutschrift-/Vergleichssummen, alle Fahrzeug-/PLZ- und Zeitaufteilungen, doppelte erste Station ohne Vervielfachung, minutengenaues Zeitfenster, SID-Injection als literal, Gruppenkunden ausschließlich im eigenen Mandanten, leere/mehrdeutige/fremde HQ-Auswahl, Zuordnungswechsel, getrennte Rechte 8/10 und sofortiger Entzug. CSV mit Zeilenumbrüchen/Formelanfängen und negativen Zahlen geprüft. SQL-Ziel-PLZ nutzt CHAR(59), damit die vorhandene Leseanweisungsprüfung unverändert bleibt.
- Echtbestand: ein tatsächlich für Statistik freigeschaltetes Kundenkonto, drei erfolgreiche Auswertungen, **keine Schreibzugriffe** (`work/customer-statistics-read-probe.log`). Erster Probeversuch wählte Konten ohne Recht 8; Auswahl auf tatsächlich berechtigte Konten korrigiert, keine Rechte verändert.
- Browser mit synthetischen SQL-DTOs: Gesamt 80 Euro/5 Aufträge, Monats-/Zeit-/Kostenstellen-/PLZ-Aufteilung, Vergleich 100 Euro/1 Auftrag, Download mit identischen angewendeten Filtern (`work/customer-statistics-ui-verification.json`, `work/customer-statistics-ui-events.json`, `work/kundenstatistik-2026-10-17.png`).
- Port 8080: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-statistics-deployment.json`).

## 17. Oktober 2026 – Kundenstornierung

- Sauberer Gesamtbuild: **958 Tests, 955 bestanden, 3 übersprungen, keine Fehler**, 107 Suiten; fünf Frontendtests und Produktionsbuild erfolgreich. Quellenhashes vor Paketübernahme unverändert (`work/customer-cancellation-verify.log`, `work/customer-cancellation-test-summary.json`, `work/customer-cancellation-build-sources.json`).
- Isolierte SQL-Prüfung: Status 8/9, zentral/fremd erfasste Aufträge, eigene/fremde Kostenstellen/Mandanten, aktuelle Rechte/Freigabe, Export/Sentineldatum, Rechnung, Rechnungszuordnungssperre, aktive Bearbeitungssperre, Unterauftrag, konkurrierende Preisänderung. Exakte negative Gesamtsumme, Rabattpositionen, origin 7, B2B-Preis/-Summe mit Originalbezug, keine Umdeutung fremder Typ-300-Datensätze. Dauerauftrag, Zahlungsbuchungen, Ranking, FDS und PDA unverändert. Zugehöriger-Kunde-Modus ohne Gegenbuchung, idempotente Wiederholung, InnoDB und vollständiger Rollback nach spätem Auditfehler geprüft. Testfixtures für UTC-/lokale Bearbeitungszeit und numerisches TINYINT-Feld korrigiert.
- Echter Bestand: **25 Kontenzuordnungen und 21 Stornovorschauen**, rein lesend, keine Mutationen (`work/customer-cancellation-read-probe.log`).
- Browser mit synthetischen DTOs: Stornoprüfung, Bestätigung, simulierter Antwortverlust, bytegleiche Wiederholung, genau eine Gegenbuchung, aktualisierte Liste und Stornodetail (`work/customer-cancellation-ui-verification.json`, `work/customer-cancellation-ui-events.json`, `work/kundenstorno-2026-10-17.png`).
- Geprüftes Paket auf Port 8080: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/customer-cancellation-deployment.json`).

## 17. Oktober 2026 – Kundenabrechnung und Zwei-Faktor-Einrichtung

- Sauberer Gesamtbuild: **958 Tests, 955 bestanden, 3 übersprungen, keine Fehler**, 107 Suiten. Fünf Frontendtests und Produktionsbuild erfolgreich. Quellenhashes vor Übernahme unverändert (`work/customer-security-billing-verify.log`, `work/customer-security-billing-test-summary.json`, `work/customer-security-billing-build-sources.json`).
- Abrechnung: Erledigungsdatum statt Auftragsdatum, Storno-/Statusfilter, eigene Unterbäume, PRIVAT/EXTERN-Ausschluss, Alt-/NG-Kostensplit, fehlende Leistungen, genaue Addition vor Rundung, Seitenwechsel mit vollständiger Summe, sofortiger Rechteentzug. Details über Kundenrecht 5 ohne Listenrecht 4, fremde Splitstationen/-texte ausgeschlossen. 84 gezielte Tests erfolgreich.
- 2FA: Kundenfreigabe unabhängig von Zentralenfreigabe, kein zusätzliches Mitarbeiterrecht nötig, aktuelles Passwort, Einrichtung ohne DB-Schreibzugriff, Sitzungsbindung, 10-Minuten-Ablauf, fünf Fehlversuche, Abbruch/Neubeginn, Konflikte durch geänderte Zugangsdaten/Freigaben, deaktivierte Niederlassung, Gegenprüfung paralleler Einrichtungen, Aktivierung/Deaktivierung und identische Wiederholungen. Aktivierungscode beim Login gesperrt, nächster Code akzeptiert; InnoDB und vollständiger Rollback einschließlich Audit/Beleg getestet. Ein Testvergleich wurde auf den Stand nach der absichtlichen konkurrierenden Passwortänderung korrigiert.
- Echtbestand jeweils nur gelesen: **25 Kundenkonten** für Abrechnung und 2FA erfolgreich, keine Mutationen (`work/customer-statement-read-probe.log`, `work/customer-twofactor-read-probe.log`).
- Browser: Abrechnung 95/36/35 Euro, eingeschränktes Splitdetail 9 Euro, Kostenstellenwechsel und Detailaufruf mit synthetischen SQL-DTOs (`work/customer-statement-ui-verification.json`, `work/kunden-abrechnung-2026-10-17.png`). 2FA-Einstiegsdialog und gesperrte QR-Aktion ohne Passwort geprüft (`work/kunden-zweifaktor-2026-10-17.png`); keine echten Zugangsdaten im Browser eingegeben, Aktivierung serverseitig im Wegwerftest geprüft.
- Auf Port 8080 bereitgestellt: Health UP, DB verbunden und sechs Dateien in dist/JAR/HTTP identisch (`work/customer-security-billing-deployment.json`). Offene Grenzen: Kostensplit-Zahlungszuordnung für Sonderniederlassungen >1000, vollständiger Rechnungslauf/Archiv und weitere Kundenbereiche. Kein Anspruch auf vollständige Anwendungsparität.

## 17. Oktober 2026 – Kundenmitarbeiter und eigenes Konto

- Sauberer Gesamtbuild: **954 Tests, 951 bestanden, 3 übersprungen, keine Fehler**, 106 Suiten; fünf Frontendtests und Produktionsbuild erfolgreich. Quellhashabgleich vor Übernahme (`work/customer-employees-verify.log`, `work/customer-employees-test-summary.json`, `work/customer-employees-build-sources.json`).
- SQL-Prüfung: eigene/untergeordnete/fremde Kostenstellen, eingeschränkter eigener Zugang, Anlage mit PHP-Passwort und Vorgaben, globale Kontoeindeutigkeit, Kundentyp/Niederlassung im Verbund, Suche einschließlich literal `%`, alle Sortierungen und 51 Treffer über zwei Seiten. Geschützte Hauptzugänge, keine Selbstrechteänderung, nicht delegierbare Rechte, begrenzte Kostenstellenmatrix, Passwort/2FA, Kontolöschung, sofortiger Rechteentzug, Konflikte, InnoDB-Voraussetzung, vollständiger Rollback und Wiederholungen geprüft. Eigenes Kontaktprofil löst auch nach verlorener Antwort keine unnötige Neuanmeldung aus.
- Vorhandene optionale Matrixfixture zu Beginn geleert, damit wiederholte Testläufe keine alten Grants übernehmen. Fehlendes `parameter.md_id` im alten Testschema ergänzt; danach gezielte 80 Tests und Gesamtbuild erfolgreich.
- Echtbestand nur gelesen: **25 Kundenkonten und 25 Mitarbeiteransichten/-listen** erfolgreich, keine Schreibzugriffe (`work/customer-employees-read-probe.log`).
- Browser mit synthetischen DTOs: Unterkostenstellenfilter, Kontakt- und Rechteänderung, Antwortverlust und zwei identische Wiederholungen; eigener Verwerfendialog behält den Entwurf. Keine echten Konto-/Passwort-/Rechteänderungen. Belege `work/customer-employees-ui-verification.json`, `work/customer-employees-ui-events.json`, `work/kunden-mitarbeiterkontakt-2026-10-17.png`, `work/kunden-mitarbeiterrechte-2026-10-17.png`.
- Port 8080 mit geprüftem Paket neu gestartet; Health UP, Datenbank verbunden und sechs Dateien in dist/JAR/HTTP identisch (`work/customer-employees-deployment.json`). Weitere Kundenabläufe/Abrechnung bleiben offen.

## 17. Oktober 2026 – Kostenstellen im Kundenportal

- Vollständiger sauberer Build: **954 Tests, 951 bestanden, 3 übersprungen, keine Fehler**, 106 Suiten. Fünf Frontendtests und Produktionsbuild erfolgreich; unveränderte Quellhashes vor Paketübernahme (`work/customer-centers-verify.log`, `work/customer-centers-test-summary.json`, `work/customer-centers-build-sources.json`).
- SQL-Prüfung: Anlage mit vier übernommenen Adressen/Abrechnungsintervall, Umbenennung samt Unterpfaden, Sichtbarkeit, Löschung nur unbenutzter Unterkostenstellen, alle aktuellen Datenbankbezüge, geänderte Referenzen nach Vorschau, Adresswiederverwendung/Neuanlage, unveränderte gemeinsame Adresse, Elternfirmenvorgabe und gesperrte Firmenfelder. Geocoder trotz PLZ-Ausnahme, EXTERN-Schutz, Rechte-/Scopeentzug, Konflikte, InnoDB-Voraussetzung, vollständiger Rollback nach Auditfehler und identische Wiederholung geprüft.
- Echtbestand ausschließlich gelesen: **25 Kundenkonten, 25 gültige Zuordnungen, 25 Kostenstellenansichten und 12 Referenzspalten**, keine Schreibzugriffe (`work/customer-centers-read-probe.log`).
- Browser mit synthetischen SQL-DTOs: Kostenstelle angelegt, Adresse geändert, beide Speicherungen nach simuliertem Antwortverlust identisch wiederholt; Eingaben während unklarer Antwort gesperrt. Layout mit zwei Spalten geprüft. Belege `work/customer-centers-ui-verification.json`, `work/customer-centers-ui-events.json`, `work/kunden-kostenstellenpflege-2026-10-17.png`.
- Port 8080 mit geprüftem Paket neu gestartet: Health UP, DB verbunden, sechs identische Dateien in dist/JAR/HTTP (`work/customer-centers-deployment.json`). Keine echten Kostenstellen-/Adressänderungen durch Tests. Weitere Kundenabläufe und übrige Fachbereiche bleiben offen.

## 17. Oktober 2026 – Kundenzugang und Auftragslisten

- Sauberer Gesamtbuild: **954 Tests, 951 bestanden, 3 übersprungen, keine Fehler**, 106 Suiten. Fünf Frontendtests und Produktionsbuild erfolgreich. Quellhashabgleich vor Paketübernahme (`work/customer-portal-verify.log`, `work/customer-portal-test-summary.json`, `work/customer-portal-build-sources.json`).
- SQL-Integration: echte Typ-2-Passwort-/2FA-Prüfung, fremde/mehrdeutige Mandanten, eigene/untergeordnete Kostenstellen und Kundenverbünde, zyklische Hierarchien, Barzahler/zugehöriger Kunde, Suche und Datumsübersteuerung, dritte Station, literal `%`, alle Spaltensortierungen, Titel/Ausrichtung, Pagination ohne Doppelzeilen, geänderte Elternzuordnung, sofortiger Rechteentzug, deaktivierte Niederlassung und doppelte Kontozuordnung. HTTP-Zentralen-/Fremdportal-/Niederlassungssperre, CSRF und Sitzungswiderruf geprüft. Zwei Testaufbaufehler (Pflichtfelder/erwarteter Barzahlertreffer) und eine CSRF-Status-Erwartung korrigiert.
- Echtbestand nur lesend: **25 Kundenkonten, 25 gültige Zuordnungen, 25 Listenabfragen**, im aktuellen Zeitraum keine Detailtreffer; **0 Schreibzugriffe** (`work/customer-portal-read-probe.log`). Details mit synthetischen SQL-Daten geprüft.
- Browser: eigener Kundenzugang, drei Stammkostenstellenaufträge, sechs mit Unterkostenstellen, ein wörtlicher Prozenttreffer, dritte Station über Bemerkung und Detail samt Empfänger/Rechnungstext. Belege `work/customer-portal-ui-verification.json`, `work/customer-portal-ui-events.json`, `work/kundenportal-detail-2026-10-17.png`.
- Port 8080 mit geprüftem Paket neu gestartet: Health UP, DB verbunden und sechs Dateien in dist/JAR/HTTP identisch (`work/customer-portal-deployment.json`). Weitere Kundenabläufe und übrige Fachbereiche bleiben offen.


## 17. Oktober 2026 – Transporteur-Auftragsbörse

- Gesamtbuild erneut **952 Tests, 949 bestanden, 3 übersprungen, keine Fehler**, 106 Suiten. Fünf Frontendtests und Produktionsbuild erfolgreich. Hashabgleich vor Übernahme (`work/courier-bourse-verify.log`, `work/courier-bourse-test-summary.json`, `work/courier-bourse-build-sources.json`).
- SQL-Integration mit 109 synthetischen Aufträgen: eigene/fremde Kundenbeziehungen, doppelte Relation ohne Mehrfachzeilen, untergeordneter Transporteur ohne implizite Freigabe, fremder/mehrdeutiger Mandant, Statusschutz, alle Sortierspalten, literal eingegebenes Prozentzeichen, sechs Filter, Nummernsuche ohne Datum, Seitenwechsel und leerer HQ-Filter. Entzug des Schalters oder der Kundenbeziehung sperrt Liste und Detail unmittelbar. Keine internen Freitextfelder in DTOs. HTTP-Sitzung/CSRF geprüft.
- Browser: bedingter Menüeintrag, Niederlassungsauswahl, Aktualisierungsschalter, zweite Seite mit drei Einträgen, Suche und geschützte Detailansicht (`work/courier-bourse-ui-verification.json`, `work/auftragsboerse-2026-10-17.png`, `work/boersenauftrag-2026-10-17.png`).
- Port 8080 neu gestartet; Health UP, DB verbunden, sechs Dateien in dist/JAR/HTTP identisch (`work/courier-bourse-deployment.json`). Echtdaten/-parameter unverändert.

## 17. Oktober 2026 – Transporteurportal

- Sauberer Gesamtbuild: **952 Tests, 949 bestanden, 3 übersprungen, keine Fehler**, 106 Suiten. Fünf Frontendtests und Produktionsbuild erfolgreich. Quellen vor Übernahme per SHA-256 abgeglichen (`work/courier-portal-verify.log`, `work/courier-portal-test-summary.json`, `work/courier-portal-build-sources.json`).
- SQL-/Sicherheitstests: echte Typ-3-Passwort-/2FA-Anmeldung, Wiederverwendungsschutz, eigene/direkte untergeordnete/fremde Transporteure, mehrdeutige Mandantenzuordnung, Parameterentzug, Angebots-/Statusfilter, Preisregeln und Leistungszusätze. Bemerkung/Passwort mit Konflikt, Wiederholung, vollständigem Rollback nach Auditfehler und InnoDB-Voraussetzung; Historienrechte und Geheimnisfilter. 78 HTTP-Sicherheitstests erfolgreich.
- Echtbestand rein lesend: **50 Konten**, fünf Historienabfragen und **23 Aufträge über zehn Konten** erfolgreich geprüft; keine Schreibzugriffe (`work/courier-portal-live-read-bounded.log`). Die erste umfassende MAX-Abfrage für die Stichprobe lief in einen Timeout; durch eine auf die letzten 1000 Aufträge begrenzte Stichprobe ersetzt. `SYSTEM_BOURSE_MODE=1` ist aktuell in keiner Niederlassung gesetzt.
- Browser mit synthetischen Daten: Typ-3-Oberfläche, Fahrzeug-/Rechnungstextfilter, korrekte gefilterte Summen, Bemerkung nach Antwortverlust identisch wiederholt, Historienansicht mit ISO-Datum und begrenzten Details. Passwort nur serverseitig geprüft, kein echter Browser-Passwortwechsel. `work/courier-portal-ui-verification.json`, `work/transporteurportal-2026-10-17.png`, `work/transporteur-historie-2026-10-17.png`.
- Port 8080 neu gestartet; Health UP, DB verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch (`work/courier-portal-deployment.json`). Keine vollständige Anwendungsparität behauptet.
## 17. Oktober 2026 – Lagermitarbeiterverwaltung

- Sauberer Gesamtbuild: **947 Tests, 944 bestanden, 3 übersprungen, keine Fehler**, 105 Suiten. Fünf Frontendtests und Produktionsbuild erfolgreich. Quellhashabgleich vor Übernahme (`work/warehouse-users-verify.log`, `work/warehouse-users-test-summary.json`, `work/warehouse-users-build-sources.json`).
- SQL-Integration: Kontoanlage Typ 4, bestehender Passwortlogin, keine Zentralenrechte, Rechtevergabe an der richtigen Heimatniederlassung, Startlager/Fax, Konflikte, doppelte Zuordnungen, delegierte Unterlager, Kontoschutz, Passwort-/Sitzungswechsel, Löschung, identische Wiederholungen, InnoDB-Voraussetzung und vollständiger Rollback bei spätem Auditfehler. Zentrale Mitarbeiter-Lagerrechte als Regression geprüft. 77 API-Sicherheitstests erfolgreich.
- Echtdaten ausschließlich gelesen: alle **9 Lagerkonten** samt Profil, Zugang und Lagerfreigaben erfolgreich aufgelöst. Die sechs benötigten Schreibtabellen sind InnoDB; keine realen Konto- oder Rechteänderungen (`work/warehouse-users-live-read.log`).
- Browser mit synthetischen Testdaten: Auswahl über Niederlassungen, Kontakt-/Startlagerdialog, gespeicherter Stand nach simuliertem Antwortverlust und bytegleicher Wiederholung, unveränderter fremder Niederlassungseditor ohne falschen Entwurfsalarm, Freigabedialog. `work/warehouse-users-ui-verification.json`, `work/lagermitarbeiter-startlager-2026-10-17.png`.
- Port 8080 neu gestartet; Health UP, DB verbunden und dist/JAR/HTTP identisch (`work/warehouse-users-deployment.json`).

## 17. Oktober 2026 – Artikelpflege für Lagerkonten

- Sauberer Gesamtbuild erneut **945 Tests, 942 bestanden, 3 übersprungen, keine Fehler**, 105 Suiten. Fünf Frontendtests und Produktionsbuild erfolgreich; Quellhashabgleich vor Übernahme. `work/warehouse-portal-articles-verify.log`, `work/warehouse-portal-articles-test-summary.json`, `work/warehouse-portal-articles-build-sources.json`.
- Erweiterte SQL-Prüfung: fehlende/entzogene Artikelberechtigung, eigene/fremde Niederlassung, Stammdatenpflege, Neuanlage, Gebindebestandteile und Historie, identische Wiederholung und Rollback nach Auditfehler. Gemeinsame Warengruppenverwaltung bleibt auch im direkten Servicezugriff gesperrt.
- Browser: Berechtigung blendet Artikelbereich ein; eine Stammdatenänderung wurde mit Vorschau, Antwortverlust und identischer Wiederholung abgeschlossen. Zentralen-, Gruppen- und Spaltenverwaltungsaufrufe bleiben aus. `work/warehouse-portal-articles-ui-verification.json`, `work/lagerportal-artikel-2026-10-17.png`.
- Port 8080 mit geprüftem Paket neu gestartet: Health UP, DB verbunden, sechs identische Dateien in dist/JAR/HTTP (`work/warehouse-portal-articles-deployment.json`). Keine realen Artikel-, Lager- oder Kontomutationen.

## 17. Oktober 2026 – Lagerportal, Anmeldung und Berechtigungen

- Vollständiger sauberer Build: **945 Tests, 942 bestanden, 3 übersprungen, keine Fehler**, 105 Suiten. Fünf Frontendtests und Produktionsbuild erfolgreich. Zwei alte Testschemata um die jetzt benötigte Lagerkontozuordnung/Niederlassungssperre ergänzt; danach vollständiger Wiederholungslauf grün. Belege `work/warehouse-portal-verify.log`, `work/warehouse-portal-test-summary.json`, `work/warehouse-portal-build-sources.json`.
- SQL-Prüfung mit echter Passwortprüfung: Typ-4-Anmeldung, keine Administratorumgehung, fehlende/fremde/mehrdeutige Startlager, reine Lesefreigabe, Haupt-/Unterlagerrechte, entzogene Freigaben, Auftragsscope samt Status/Zeitraum/Duplikaten, tatsächliche Buchung und Wiederholung, deaktivierte Niederlassung, Kontotypwechsel und 2FA mit Wiederverwendungsschutz. Eine fehlende Alias-Sperre wurde im Buchungstest gefunden und korrigiert.
- HTTP-Prüfung: ausschließlich erlaubte Lagerpfade/-methoden, kein Arbeitsplatzwechsel, kein Zentralen-/Exportzugang, CSRF, sofortiger Sitzungsentzug bei geänderten Zugangsdaten.
- Browser: automatische Startlagerwahl, fehlende Verwaltungs-/Exportaktionen, auftragsbezogene Testbuchung mit Antwortverlust/identischer Wiederholung, reiner Lesezugang und Abmeldung. `work/warehouse-portal-ui-verification.json`, `work/lagerportal-2026-10-17.png`. Im Echtbestand neun Lagerkonten, neun gültige Konten, sieben Startlager und insgesamt 22 Hauptlagerfreigaben gelesen; keine Schreibzugriffe (`work/warehouse-portal-read-probe.log`).
- Port 8080: Health UP, DB verbunden und sechs identische Dateien in dist/JAR/HTTP (`work/warehouse-portal-deployment.json`). Artikelpflege für Lagerkonten wird separat ergänzt; keine vollständige Portal-/Anwendungsparität behauptet.

## 17. Oktober 2026 – Barcodelisten, Scanner und Lageraufträge

- Vollständiger sauberer Build: **943 Tests, 940 bestanden, 3 übersprungen, keine Fehler**, 105 Suiten. Fünf Frontendtests und Produktionsbuild erfolgreich; Quellhashabgleich vor Übernahme (`work/warehouse-scanner-test-summary.json`, `work/warehouse-scanner-build-sources.json`).
- Code-39-Grafiken aller 22 Befehls-/Ziffernlabels und aller zugelassenen Zeichen wieder decodiert. Ungültige Zeichen/HTML-Inhalte nicht als Grafik oder aktives Markup ausgegeben. Lager-/Unterlagerrechte und fremde Hauptlager geprüft.
- Isolierte SQL-Prüfung: Erkennungsprioritäten, tatsächlicher Serienort trotz älterem Journal, doppelte Artikel-/Lager-/Seriencodes, literal eingegebene Sonderzeichen, fremde Mandanten, gesperrte Bereiche, Rechteentzug. Lageraufträge: Zeitraumgrenzen, erledigte/fremde Aufträge, Hausnummern, reine Anlieferadressen, Fremdzahler, doppelte Stationen, alle sieben Sortierungen und Pagination. Zugeordnete Scannerbuchung tatsächlich gespeichert und identisch wiederholt.
- Browser: Befehle, Zahlenpuffer, Rückschritt/Löschen, TAN/Bemerkung/Seriennummer/Auftrag, Lagerauswahl, Auftragssuche und Buchungsvorschau. Ein Datumsformatfehler wurde gefunden und durch ein definiertes Datumsformat in der API behoben. Danach Auftrag übernommen und Buchung nach simuliertem Antwortverlust mit identischem Payload abgeschlossen (`work/warehouse-scanner-ui-verification.json`). Bilder: `work/lager-barcodeliste-2026-10-17.png`, `work/lager-scannerbefehle-2026-10-17.png`, `work/lager-scannerbuchung-2026-10-17.png`, `work/lagerauftraege-2026-10-17.png`.
- Echtbestand nur gelesen: 14 Hauptlager / 2108 Lagerorte, davon 187 ohne gültigen Code-39-Wert; aktueller erster Lagerauftragsabruf 175 ms und 0 Treffer. Unbekannter Scancode bleibt UNKNOWN. Schreibzugriffe 0 (`work/warehouse-scanner-read-probe.log`). Hardware-Scanner/Drucker nicht physisch getestet.
- Port 8080 mit geprüftem Paket neu gestartet: Health UP, Datenbank verbunden, sechs Assets in dist/JAR/HTTP identisch (`work/warehouse-scanner-deployment.json`).

## 17. Oktober 2026 – Lageradresse und Kundenzuordnung

- Vollständiger sauberer Build: **939 Tests, 936 bestanden, 3 übersprungen, keine Fehler**, 104 Suiten. Fünf Frontendtests und Produktionsbuild erfolgreich. Quellhashabgleich vor Paketübernahme (`work/warehouse-details-build-sources.json`, `work/warehouse-details-test-summary.json`).
- Isolierte SQL-Prüfung: exakte Adresswiederverwendung, Neuanlage, gemeinsame Adresse unverändert, Geocoderfehler auch bei ausgelassener PLZ-Prüfung, niederlassungsübergreifende Suche/Zuordnung, ausgeblendete und fremde Datensätze, Literal-Suche, Aufheben, Rechteentzug, Konflikt, Wiederholung und vollständiger Rollback bei Auditfehler.
- Echtbestand ausschließlich gelesen: 14 Lagerdetails und Schema des Straßenverzeichnisses; keine Schreibzugriffe (`work/warehouse-details-read-probe.log`).
- Browser: Adressvorschlag übernimmt alle Felder; Adresse und Hamburger Kostenstelle gespeichert, Antwortverlust jeweils mit identischem Request wiederholt und nach Wiederöffnung bestätigt. Belege `work/warehouse-details-ui-verification.json`, `work/lageradresse-2026-10-17.png`, `work/lager-kundenzuordnung-2026-10-17.png`.
- Port 8080 mit geprüftem Paket neu gestartet; Health-/DB-/Assetprüfung in `work/warehouse-details-deployment.json`. Übrige Lücken bleiben offen.

## 17. Oktober 2026 – Lagerjournal und Lagerbewegungen

- Vollständiger sauberer Build: **938 Tests, 935 bestanden, 3 übersprungen, keine Fehler**, 104 Suiten. Fünf Frontendtests und Produktionsbuild erfolgreich. Quellenhashes vor Übernahme unverändert. Belege: `work/warehouse-movements-verify.log`, `work/warehouse-movements-test-summary.json`, `work/warehouse-movements-build-sources.json`. Geprüfter Stand auf Port 8080, Health UP, Datenbank verbunden und sechs identische Frontenddateien in dist/JAR/HTTP (`work/warehouse-movements-deployment.json`).
- Journaltests: Zeitraumausnahmen, Quelle/Ziel/Unterbäume und UND/ODER, sämtliche Sortierungen, Warengruppenduplikate, historische/fehlende Artikel, Fremdlager-Maskierung, CSV-Formelschutz, gemeinsame Spalten/Sortierrichtung, Konflikte, Wiederholung, Rollback und aktuelle Rechte. Buchungstests: Mengen, Kapazität, Serienpflicht/Kollision, 25 Zusatzdaten, Aus-/Wiedereinlagerung, Serienkorrektur, Mehrfachbuchungen, Gebindeauflösung/-storno, Wiederholung, späte Transaktionsfehler, zwischenzeitliche Änderungen, MyISAM-Abweisung und Rechteentzug. Drei gezielte Integrations-/HTTP-Tests erfolgreich.
- Browser mit isolierten SQL-Fixture-DTOs: Journalsuche, gemeinsame Spaltenänderung mit verlorener Antwort und identischer Wiederholung; Artikelwahl, Buchungsposition, Mengen-/Lagervorschau und identische Buchungswiederholung. Screenshots `work/lagerjournal-2026-10-17.png`, `work/lagerbuchung-2026-10-17.png`; Vorgangsbelege `work/warehouse-journal-ui-verification.json`, `work/warehouse-movements-ui-verification.json`.
- Echte Daten ausschließlich gelesen: Journalvorgaben aller 14 Hauptlager, alle Artikelauswahlmodi außer Gruppenfilter, eine reale Buchungsvorschau und historisches Journal. 51.668 Treffer mit erster 100er-Seite in 206 ms (Einzelmessung). Keine tatsächliche Lager-/Artikelmutation, keine Nachrichten-/Geräteübertragung. `work/warehouse-movements-read-probe.log`.

## 17. Oktober 2026 – Lagerorte und Bestandslisten

- Vollständiger sauberer Build: **936 Tests, 933 bestanden, 3 übersprungen, keine Fehler**, 104 Suiten. Fünf Frontendtests und Produktionsbuild erfolgreich. Quellenmanifest `work/warehouse-build-sources.json`, Build `work/warehouse-verify.log`, Zusammenfassung `work/warehouse-test-summary.json`; geprüfter Stand auf Port 8080 mit sechs identischen Frontenddateien (`work/warehouse-deployment.json`).
- Gezielte SQL-/HTTP-Sicherheitsprüfung: Lageranlage, Elternpfade, Sichtbarkeit, Kapazitätsgrenzen, Änderungskonflikte durch Lager- oder Bestandsänderungen, Nullbestands-/Seriennummern-/Unterlagerschutz, Rollback bei Auditfehler, Wiederholung, Hauptlagerfreigabe, Unterlagerrechte, Leseschalter, entzogenes Recht und echte MyISAM-Abweisung. Bestandsmodi, 15 Zusatzfelder, Warengruppen-Duplikate, Mengensummen, sämtliche Sortierspalten, Literal-/SQL-Suchtexte, mandantenfremde und nicht freigegebene Läger sowie CSV-Formelschutz geprüft. Drei gezielte Tests erfolgreich (`work/warehouse-targeted.log`).
- Browser: echte SQL-Fixture-DTOs, Lagerpfadnavigation, Kapazitäts-/Barcodevorschau, simulierter Antwortverlust und exakt identische Wiederholung (`work/warehouse-ui-verification.json`). Summierte Artikelliste → Seriennummerndialog → Treffer über Zusatzfeld 15. Screenshots `work/lagerorte-2026-10-17.png` und `work/lager-seriennummern-2026-10-17.png`.
- Echte Daten nur gelesen: Tabellen/Spalten/Indizes, 14 zugängliche Hauptlager und deren Unterlager; erste Bestandsseiten in allen fünf Modi. Nach Optimierung auf einmalige Warengruppenaggregation: 4295 Lager-/Artikelzeilen in 155 ms, 2754 Artikelsummen in 181 ms, 9641 Inventurzeilen in 199 ms, 8312 Seriennummern in 170 ms (jeweils Zählung plus erste 100 Zeilen, Einzelmessung; `work/warehouse-read-probe.log`). Keine echten Lager- oder Artikelmutationen für diese Prüfungen.

## 17. Oktober 2026 – Artikelpflege

- Sauberer vollständiger Build: **933 Tests, 930 bestanden, 3 übersprungen, keine Fehler**. Sieben gezielte SQL-/Sicherheits-/Audit-Kompatibilitätstests, fünf Frontendtests und Produktionsbuild erfolgreich. Quellen gegen `work/article-columns-build-sources.json` vor Paketübernahme geprüft; Belege `work/article-columns-verify.log`, `work/article-columns-test-summary.json`.
- Isolierte SQL-Tests: globale doppelte Nummer/Barcode/Neuanlagename, wörtliche Suchzeichen, fremde Niederlassung/Mandant, entzogene Rechte, Änderungskonflikte, Gebindeaddition und identische Wiederholung, Selbst-/Kreiszuordnung, verschachtelter Entfernungsschutz, Seriennummern-/Lagerbestandsregeln, Grenzen echter SMALLINT/MEDIUMINT/TINYINT/TEXT-Spalten, Warengruppenanlage/-umbenennung, doppelte/gemeinsame Zuordnungen, vollständiger Rollback bei Auditfehler. InnoDB-Abweisung durch simulierte Metadaten; ältere Auditdaten ohne Artikelkennung bleiben lesbar. Publisher schreibt Artikelkennung in `log.at_id` und wiederholt nicht doppelt.
- Browser: Stammdatenvorschau, Speicherung mit Antwortverlust und identischer Wiederholung, danach Gebindebestandteil mit demselben Fehlerfall. Zwei identische Wiederholungspaare in `work/article-ui-events.json` / `work/article-ui-verification.json`. Warengruppenmaske und gesperrter bestehender Schlüssel geprüft. Screenshot `work/artikelpflege-2026-10-17.png`.
- Echte Daten ausschließlich gelesen: Tabellen/Spalten/Engines/Nummernvorgaben, Artikeloptionen, Artikelliste, Detail und Historie erfolgreich (`work/article-schema-probe.log`, `work/article-read-probe.log`). Keine Artikel-, Lager- oder Protokollschreibvorgänge im echten Bestand durch die Prüfung.

- Ergänzend geprüft: persönliche Artikellistenspalten, Rückfall, Reihenfolge, unzulässige Spalten/Sortierung, doppelte/fremde Parameter, Rollback, konkurrierende Änderungen und echte MyISAM-Abweisung der Parameterfixture. Isolierte Oberfläche speichert fünf Spalten und zeigt sie anschließend in der Liste (`work/artikel-listenspalten-2026-10-17.png`). Live-Paket mit sechs identischen Frontenddateien auf Port 8080 (`work/article-columns-deployment.json`).

## 17. Oktober 2026 – FDS-Auftragssuche

- Vollständiger sauberer Build: **930 Tests, 927 bestanden, 3 übersprungen, keine Fehler**, 104 Suiten. Zwei gezielte SQL-/Sicherheitstests, fünf Frontendtests und Produktionsbuild erfolgreich. Quellhashes unverändert vor Paketübernahme. Belege `work/fds-search-final-verify.log`, `work/fds-search-test-summary.json`, `work/fds-search-build-sources.json`.
- SQL-Prüfungen: Classic-ID gegenüber numerischer Kommissionsnummer, verknüpfte Aufträge und `/1`/`/2`, mehrere Kinder, fremde Eltern/Aufträge, beide GDC-Suchfelder und ignorierte andere Objekte/Felder, identische Referenzen ohne doppelte Treffer, mehrere Reservierungstage, fehlende/fremde Fahrzeuge, ungültiger Tag, fehlender Tagesdatensatz, Literaltext mit Apostroph/HTML, keine Teilwort-/SQL-Ausweitung, 60 Treffer auf zwei Seiten, ungültige/mehrdeutige Modusvorgabe, fehlende Rechte und entzogene Niederlassungsfreigabe. Alle Suchen unverändernd.
- Echter Bestand ausschließlich gelesen: letzte Auftrags-ID und vorhandene alphanumerische Kommissionsnummer ergeben jeweils einen Treffer (`work/fds-search-read-probe.log`), keine Schreibzugriffe.
- Browser: `/2` findet zwei Folgeaufträge, leere Suche zeigt keine Treffer, `/1` zeigt mehrere Reservierungstage und unzugängliche Reservierungen. Auswahl springt vom 17. auf den 18. Oktober, setzt Filter zurück und markiert Auftrag 10 im richtigen Fahrzeugtag. `work/fds-search-ui-events.json`, `work/fds-search-ui-verification.json`, `work/disposition-auftragssuche-2026-10-17.png`. Nur lesende Fixture-Anfragen.
- Port 8080 neu gestartet; Health, Datenbank und sechs identische Frontenddateien in dist/JAR/HTTP über `work/fds-search-deployment.json` geprüft. Gesamtparität bleibt offen.

## 17. Oktober 2026 – Fremde FDS-Niederlassung: Auftrag und Stammblatt

- Vollständiger sauberer Build: **929 Tests, 926 bestanden, 3 übersprungen, keine Fehler**, 104 Suiten. Frontend: fünf Tests und Produktionsbuild erfolgreich. `work/fds-workspace-final-verify.log`, `work/fds-workspace-test-summary.json`; Quellhashes vor JAR-Übernahme geprüft (`work/fds-workspace-build-sources.json`).
- SQL-Integration prüft verfügbare Direktaufrufe im fremden FDS-Kontext und Ausblendung ohne entsprechende Rechte. FDS-Freigabe allein erlaubt keinen allgemeinen Arbeitsplatzwechsel; gesondertes Leserecht erlaubt Aufträge, Stammdaten benötigen ihre eigene Matrixzelle. Entzug der Zelle sperrt den Zugriff erneut. Vorhandene Prüfungen für Mandant, deaktivierte Niederlassung, Login-/Live-Rechte und Matrixduplikate weiterhin erfolgreich.
- Browser: verweigerter Wechsel, Abbrechen mit erhaltener HH-Auswahl, erfolgreicher Fahrzeugstammaufruf in Arbeitsniederlassung 8, Rückkehr zur eigenen Niederlassung und erfolgreicher Auftragsaufruf in 8. Ungespeicherte Tagesnotiz sperrt den Auftragsknopf. Beide Zielanfragen tragen den richtigen HQ-Header. Keine Geschäftsdatenspeicherung. Die isolierte Testantwort für das Transporteursverzeichnis musste um deren Suchkriterien ergänzt werden; keine entsprechende Produktänderung nötig.
- Belege: `work/fds-workspace-ui-events.json`, `work/fds-workspace-ui-verification.json`, `work/disposition-niederlassungswechsel-2026-10-17.png`. Port 8080 neu gestartet und Health, Datenbankverbindung sowie sechs dist/JAR/HTTP-Assets identisch geprüft (`work/fds-workspace-deployment.json`).

## 17. Oktober 2026 – Freigabe späterer Reservierungen

- Vollständiger sauberer Build: **929 Tests, 926 bestanden, 3 übersprungen, keine Fehler**, 104 Suiten (`work/fds-reservation-release-final-verify.log`, `work/fds-reservation-release-test-summary.json`). Fünf gezielte SQL-/Sicherheitstests zuvor bestanden; fünf Frontendtests und Produktionsbuild erfolgreich. Quellhashes vor Paketübernahme unverändert (`work/fds-reservation-release-build-sources.json`). Eine erste Testannahme über 800 kg wurde als explizite Fahrzeugvorgabe in die isolierte Fixture übernommen; deren bisheriger Standard war 1000 kg.
- Isolierte SQL-Prüfung: 116 Zeiteinheiten auf drei Tagen, davon 68 ZE ab Folgetag freigegeben und 48 ZE am ersten Tag erhalten. 15 kg Artikelgewicht je freigegebenem Tag ausgebucht; korrekte 795 kg nach Freigabe, bestehende Abweichung sichtbar korrigiert. Freie Kundenzeitfenster neu berechnet. Angenommener Auftrag unverändert bis auf Version; andere Aufträge, frühere Tage, fremde Fahrzeuge und unbetroffene Zeitfenster unverändert.
- Prüfungen für fehlende Rechte/fremde Niederlassung, entzogene Rechte beim Speichern, Original-/unpassenden Tag, Status/Angebot, Rechnungen, Verarbeitungssperren, unvollständige Raster, fremde Aufträge, mehrere Fahrzeuge, negative Gewichte, parallele Kapazitäts-/Gewichts-/Zeitfensteränderungen, MyISAM und vollständigen Rollback bei spätem Auditfehler. Tagessperre/Unternehmerfreigabe bleiben auch bei Freigabe erhalten. Letzte verbleibende spätere Reservierung und gewichtsloser Fremdniederlassungsauftrag tatsächlich freigegeben; ohne Gewicht wird die gespeicherte Kapazität erhalten.
- Echtdaten nicht verändert. Quellenhashes erneut remote geprüft; aktueller Bestandsnachweis für fehlende zukünftige Reservierungen aus `work/fds-single-handover-read-probe.log`.
- Browserfixture: bleibenden ersten Tag und zwei freizugebende Tage mit Gewichten geprüft, bestätigt, Antwortverlust mit identischer Vorgangskennung wiederholt. Danach nur noch der andere Auftrag am gewählten Tag, 795 kg, ursprüngliche Tagesflags und Notiz erhalten. Belege `work/fds-reservation-release-ui-events.json`, `work/fds-reservation-release-ui-verification.json`; Bild `work/disposition-reservierungsfreigabe-2026-10-17.png`.
- Port 8080 neu gestartet; Health-/DB-/Assetprüfung in `work/fds-reservation-release-deployment.json`. Gesamtparität weiterhin offen.

## 17. Oktober 2026 – Einzelübergabe und Rückholung

- Vollständiger sauberer Build: **928 Tests, 925 bestanden, 3 übersprungen, keine Fehler**, 104 Suiten (`work/fds-single-handover-final-verify.log`, `work/fds-single-handover-test-summary.json`). Zwei gezielte Tests zuvor erfolgreich, fünf Frontendtests und Produktionsbuild bestanden. Hashabgleich mit `work/fds-single-handover-build-sources.json` vor Paketübernahme.
- Isolierte MariaDB: Gerätekurier in eigener Niederlassung trotz gleichnamigem fremden Kurier, fehlende/doppelte/gesperrte Gerätezuordnung, uneindeutiges Fahrzeug, ungültiger/doppelter Modus, Status/Angebot, andere Zuordnung, Abrechnung/Bearbeitung, Sperre an einem späteren Reservierungstag, parallele Status-/Modusänderung, Mandanten/Rechte, MyISAM und Auditfehler mit vollständigem Rollback. Übergabe und Rückholung tatsächlich gespeichert und identisch wiederholt; nur ausgewählter Auftrag geändert, alle Reservierungen/Kapazitäten und andere Aufträge erhalten. Classic-Standard ohne Parameter tatsächlich angenommen und zurückgeholt. Fremdniederlassungsfreigabe beim Speichern erneut geprüft.
- Echter Bestand ausschließlich gelesen: globaler Gerätekurierparameter fehlt, Spaltentypen/Nullbarkeit passen, aktuell keine passenden gegenwärtigen/zukünftigen Reservierungen (`work/fds-single-handover-read-probe.log`, Schreibzugriffe 0). Der erste Leseproben-Compilerlauf kollidierte mit dem parallelen Maven-Clean; nach Abschluss der Kompilierung erfolgreich wiederholt.
- Browserfixture aus SQL-Test: Auftrag 10 einzeln dem Gerätekurier 11 zugeordnet, Annahmestatus/Zuordnung angezeigt, wieder zurückgeholt, anschließend Status 9 ohne Kennung bei unveränderten Reservierungen. Beide Speichervorgänge mit simuliert verloren gegangener Antwort und identischer Wiederholung. Belege `work/fds-single-handover-ui-events.json`, `work/fds-single-handover-ui-verification.json`; Bild `work/disposition-einzeluebergabe-2026-10-17.png`.
- Lokale Anwendung mit geprüftem Paket neu gestartet; Health-/DB-/Assetprüfung in `work/fds-single-handover-deployment.json`. Die übrigen offenen Bereiche bleiben dokumentiert.

## 17. Oktober 2026 – FDS-Auftragsaktionen

- Sauberer vollständiger Build: **927 Tests, 924 bestanden, 3 übersprungen, keine Fehler**, 104 Suiten (`work/fds-order-actions-final-verify.log`, `work/fds-order-actions-test-summary.json`). Zwei gezielte Tests zuvor bestanden, fünf Frontendtests und Produktionsbuild erfolgreich. Quellhashes vor Paketübernahme unverändert (`work/fds-order-actions-build-sources.json`).
- Isolierte MariaDB: getrennte Bemerkungen, Unicode-/Textgrenzen, keine Änderung, fehlende/doppelte Zustellstation, doppelte interne Notiz, abgeschlossene/angenommene Aufträge, geschützte/gesperrte Aufträge, fremde Aufträge/Fahrzeuge, verlorene Berechtigungen in anderer Niederlassung, parallele Änderungen, fremde Kurierzuweisung, mehrtägige Reservierung, vollständiger Rollback nach spätem Auditfehler, MyISAM-Abweisung und Wiederholungsbeleg geprüft. Freigabe und Entzug erhalten leere sowie bereits gesetzte passende Kurier-/Fahrzeugzuweisung, alle Reservierungen/Kapazitäten und andere Aufträge.
- Echtbestand ausschließlich lesend: Bemerkungsfelder sind TEXT (65535 Bytes), die drei Schreibtabellen InnoDB, keine internen Bemerkungszeilen vorhanden (`work/fds-order-actions-read-probe.log`); Schreibzugriffe 0.
- Browserfixture aus SQL-Prüfung: beide Bemerkungen geändert, Vorschau bestätigt, nach Antwortverlust mit identischer Kennung wiederholt, erneut geöffnet und Werte verifiziert. Einzelfreigabe und Entzug ebenso mit verlorener Antwort und identischer Wiederholung; Status wechselt 9 → 0 → 9. Drei erfolgreiche Wiederholungsprüfungen (`work/fds-order-actions-ui-events.json`, `work/fds-order-actions-ui-verification.json`). Bilder `work/disposition-auftragsbemerkungen-2026-10-17.png`, `work/disposition-einzelfreigabe-2026-10-17.png`.
- Port 8080 mit geprüftem Paket neu gestartet; Auslieferungsprüfung in `work/fds-order-actions-deployment.json`. Übrige Lücken werden weiter bearbeitet.

## 17. Oktober 2026 – FDS-Planungsdaten

- Vollständiger sauberer Build: **926 Tests, 923 bestanden, 3 übersprungen, keine Fehler**, 104 Suiten (`work/fds-planning-data-final-verify.log`, `work/fds-planning-data-test-summary.json`). Fünf Frontendtests und Produktionsbuild bestanden. Nach der Browserprüfung ausschließlich die Scrollcontainer zweier Dialoge korrigiert, Frontend erneut gebaut und Paket erstellt; Backend-Quellhashes unverändert (`work/fds-planning-data-build-sources.json`).
- Isolierte SQL-Prüfung: Termin 18.10. 08:00 → 19.10. 06:00, 116 → 120 ZE, SMS 07:30, Vermittlungsfrist um denselben Abstand verschoben; MAIL_SENT erhalten. Rechte, fremde Aufträge, ungültige Zeiten, 127/128-Grenze gegen echte TINYINT-Testspalte, fehlende Änderung, doppelte Vorgaben, parallele Reservierung/Annahme, Konflikte, MyISAM-Schutz, vollständiger Rollback nach Auditfehler, identische Wiederholung und gezieltes Leeren der SMS-Vorgabe geprüft. Andere GDC-Werte, Reservierungen und Kapazitäten bleiben unverändert.
- Echter Bestand ausschließlich lesend: Spaltentypen und SMS-Zeilen geprüft, keine Schreibzugriffe (`work/fds-planning-data-read-probe.log`).
- Browserfixture aus SQL-Test: Änderungsvorschau und Bestätigung, Entwurfsverwerfen, sichtbarer Dialogfuß bei langen Inhalten, gesperrte Eingaben nach verlorener Antwort, identische Wiederholung und verschwundener Treffer am ursprünglichen Tag. Belege `work/fds-planning-data-ui-events.json`, `work/fds-planning-data-ui-verification.json`, Bild `work/disposition-planungsdaten-2026-10-17.png`.
- Port 8080 mit geprüftem Paket neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in Build/JAR/HTTP identisch (`work/fds-planning-data-deployment.json`).

## 17. Oktober 2026 – Erstreservierung ungeplanter FDS-Aufträge

- Vollständiger sauberer Build: **925 Tests, 922 bestanden, 3 übersprungen, keine Fehler**, 104 Suiten (`work/fds-initial-final-verify.log`, `work/fds-initial-test-summary.json`). Fünf betroffene Tests zuvor gezielt ausgeführt; fünf Frontendtests und Produktionsbuild bestanden. Quellhashes vor Paketübernahme mit `work/fds-initial-build-sources.json` verglichen.
- Isolierte SQL-Prüfung: Suche, Kunden-/Tagesabgrenzung, literal behandelte Suchzeichen, mehrseitige Liste, fehlende Rechte, fremde Kunden/Aufträge, bereits zugewiesene/angebotene Aufträge, fehlende Dauer, parallele Reservierung/Annahme, Bearbeitungs-/Abrechnungsschutz, Unternehmerdisposition, Kollision am letzten Tag, Nutzlast, vollständiger Rollback bei spätem Auditfehler, wiederholte Speicherung, unveränderte andere Fahrzeuge und frische Fremdniederlassungsfreigabe. Dreitägige Erstreservierung mit 15 kg Artikelgewicht tatsächlich gespeichert; 785 kg verbleiben an jedem Zieltag.
- Echtdaten ausschließlich lesend: zehn berechtigte Konten gegen die Kandidatenabfrage geprüft, am aktuellen Tag keine passenden Aufträge (`work/fds-initial-read-probe.log`). Keine echte Reservierung, Auftragsspeicherung oder Mail.
- Browserfixture aus SQL-Test: ungeplanten Auftrag gewählt, Fahrzeug/09:00 gesetzt, drei Tage samt Kapazitäten geprüft, verlorene Speicherbestätigung mit gesperrten Eingaben und identischer Wiederholung, danach leere Kandidatenliste und neue Fahrzeugbelegung. Belege `work/fds-initial-ui-events.json`, `work/fds-initial-ui-verification.json`; Bild `work/disposition-erstreservierung-2026-10-17.png`.
- Port 8080 mit geprüftem Paket neu gestartet; Health UP, Datenbank verbunden und sechs Frontenddateien in Build/JAR/HTTP identisch (`work/fds-initial-deployment.json`). Weitere dokumentierte Bereiche bleiben offen.


## 17. Oktober 2026 – Grafische Fahrzeugzeitleisten

- Aktuelle SSH-Quellen und PHP-Disposition gelesen; Herkunft und Umfang im Menüabgleich. Im echten Datenbestand ausschließlich lesend 50 Fahrzeugzeitleisten geprüft (`work/fds-timelines-read-probe.log`), keine Schreibzugriffe.
- Vollständiger sauberer Build: **924 Tests, 921 bestanden, 3 übersprungen, keine Fehler**, 104 Suiten (`work/fds-timelines-final-verify.log`, `work/fds-timelines-test-summary.json`). Fünf Frontendtests und Produktionsbuild bestanden. Quellhashes vor Paketübernahme mit `work/fds-timelines-build-sources.json` verglichen.
- Isolierte SQL-Prüfung: begrenzte/validierte Fahrzeuglisten, Reihenfolge, fremde/fehlende Fahrzeuge, fehlende Rechte, vollständig verborgene Auftragskennungen ohne Leserecht, gesperrte/verarbeitete/vergangene Tage, fremde Aufträge, unvollständige und ungültige Raster sowie freigegebene andere Niederlassung. Tatsächliche Mehrtagesumplanung mit anschließend neuer Zeitleiste erfolgreich.
- Browserfixture aus dem SQL-Test: native Ziehbewegung von TEST-A nach TEST-B auf 09:00, Vorschau aller drei Tage, gesperrte Eingaben nach verlorener Antwort, zwei identische Speicheranfragen, neue Belegung 09:00–17:00 auf TEST-B und Wiederöffnung per Enter. Belege `work/fds-timelines-ui-events.json`, `work/fds-timelines-ui-verification.json`, Prüfbild `work/disposition-zeitleiste-2026-10-17.png`. Ausschließlich synthetische Testdaten gespeichert.
- Anwendung auf Port 8080 mit geprüftem Paket neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in Build/JAR/HTTP identisch (`work/fds-timelines-deployment.json`). Erstreservierung und weitere Fachbereiche bleiben offen.

## 17. Oktober 2026 – Liefer-/Montageabhängigkeiten der FDS-Planung

- Frische Remote-Quellen und aktive PHP-Disposition geprüft; Herleitung im Menüabgleich. Das PHP-Anzeigefeld `jb_is_installation` wird aus `jb_service` berechnet und ist keine Datenbankspalte. Die Implementierung benutzt den bestätigten bestehenden Datenvertrag.
- Vollständiger sauberer Build: **923 Tests, 920 bestanden, 3 übersprungen, keine Fehler**, 104 Suiten (`work/fds-dependencies-final-verify.log`, `work/fds-dependencies-test-summary.json`). Vier betroffene SQL-Workflows separat erfolgreich; Frontend erneut gebaut. Quellhashes vor Paketübernahme mit `work/fds-dependencies-build-sources.json` geprüft.
- Isolierte SQL-Prüfung: Lieferung strikt vor Kindauftrag, Gleichstand/umgekehrte Folge abgewiesen, globaler/örtlicher Warnmodus samt Fallback, ungültige/mehrdeutige Vorgaben, fehlende Reservierung, anderer Eigentümer, fehlender Auftrag, direkte Kreisverknüpfung, Eltern- und Kindbeziehungen gleichzeitig, gemeinsamer neuer Startstand beim Umsortieren, Montagefahrzeughinweis, abweichende Fahrzeuge, nachträglich geänderte Fahrzeugdienste, Verknüpfungen, Parameter oder Anfangsreservierungen, Wiederholung ohne Doppelspeicherung. Eintägige Umsortierung und Mehrtagsspeicherung tatsächlich ausgeführt. Eine zunächst noch mehrtägige Testreservierung wurde für den Eintagstest korrekt eingegrenzt.
- SELECT im echten Bestand bestätigt Feldtypen und 95.512 Elternverknüpfungen; keine dieser Kindzeilen hat Montagebit 2. Kein eigener Parameter zur Abschwächung der Reihenfolge vorhanden, daher gilt standardmäßig die strikte Prüfung. Keine echten Aufträge oder Fahrzeugdaten verändert (`work/fds-dependencies-read-probe.log`).
- Browserfixture aus dem finalen SQL-Lauf zeigt alle drei relevanten Hinweise zusammen: fehlende Montagekennzeichnung, zugelassene abweichende Reihenfolge mit deutschen Datumswerten und getrennte Fahrzeuge. Speichern ist bis zur ausdrücklichen Bestätigung aller Hinweise deaktiviert. Kein Speicheraufruf in dieser zusätzlichen Sichtprüfung (`work/fds-dependencies-ui-events.json`); Bild `work/disposition-lieferung-montage-2026-10-17.png`.
- Lokale Anwendung neu gestartet; Health UP, Datenbank verbunden, sechs Frontenddateien in Build/JAR/HTTP gleich (`work/fds-dependencies-deployment.json`). Weitere offene Bereiche bleiben im Menüabgleich dokumentiert.

## 17. Oktober 2026 – Mehrtagesplanung mit Artikelgewicht

- Aktuelle SSH-PHP-Reservierungs-, Artikel- und Gewichtsprüffunktionen gelesen; aktive PHP-Disposition lesend geöffnet. Quellenhashes und bewusste Korrektur des PHP-Mehrtagspfads im Menüabgleich dokumentiert. Keine Bestandsänderung in PHP.
- Sauberer vollständiger Maven-Lauf: **922 Tests, 919 bestanden, 3 übersprungen, 0 Fehler**, 104 Suiten (`work/multiday-weight-final-verify.log`, `work/multiday-weight-test-summary.json`). Fünf Frontendtests und Produktionsbuild bestanden. Quellen und gebaute Frontenddateien vor Paketübernahme gegen `work/multiday-weight-build-sources.json` geprüft.
- Isolierte MariaDB: gewichtete Fahrzeugübertragung über drei Tage, tägliche Artikelgewichte ohne Stückzahlmultiplikation, erkennbare und bestätigte Bestandsberichtigung, unveränderte andere Aufträge/Zeiten/Tagesattribute, Gewichte ohne Artikelwert, Null- und negative Einzelwerte, Überlast nur am letzten Tag, fehlende Nutzlast, Wertebereich, Konflikte nach Änderung eigener/fremder Artikelgewichte, Nutzlast oder Restkapazität, Rollback nach spätem Auditfehler, InnoDB-Pflicht, identische Wiederholung, überlappende Tage desselben Fahrzeugs und Rückführung auf eintägige Reservierung. Gewichtsloser Ablauf samt bisherigen Rechte-/Reservierungstests weiterhin erfolgreich. Ein anfänglicher Testaufbaufehler durch DDL über den DML-Adapter wurde im isolierten Test behoben; Produktcode blieb davon unberührt.
- Bestandsprüfung nur SELECT: alle fünf Schreibtabellen InnoDB; tatsächliche Spaltentypen abgeglichen. Keine zukünftigen FDS-Fahrzeugtage. Von 50 jüngsten historischen Tagesbeständen sind 30 anhand vorhandener Fahrzeugdaten berechenbar, alle ohne positive reservierte Artikelgewichte und mit abweichendem gespeicherten Restwert; bei 20 fehlen auswertbare Ausgangsdaten. Keine historischen Werte verändert (`work/multiday-weight-read-probe.log`).
- Browserfixture aus dem echten Java-SQL-Test: Artikelgewicht 15 kg, drei neue Reservierungstage, sechs Vorher-/Nachher-Gewichtszeilen, markierte Bestandskorrektur, deaktivierte Eingaben nach simulierter verlorener Antwort und zwei identische Speicheranfragen. Anschließend 995 kg am freigegebenen Quelltag sichtbar. 32 Anfragen (`work/multiday-weight-ui-events.json`, `work/multiday-weight-ui-verification.json`); Bild `work/mehrtagesplanung-gewicht-2026-10-17.png`. Nur synthetische Speicherung.
- Lokale Anwendung auf Port 8080 mit dem geprüften Paket neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien in Build/JAR/HTTP identisch (`work/multiday-weight-deployment.json`). Dieses Paket enthält auch die zuvor geprüften gewöhnlichen Niederlassungsrechte und Niederlassungseinstellungen. Keine vollständige PHP-Parität behauptet; übrige offene Tabellenzeilen bleiben Teil des Gesamtziels.

## 17. Oktober 2026 – Niederlassungseinstellungen

- Aktive Remote-PHP-Seite und alle sechs Live-Ansichten gelesen; Quellenhash und fachliche Abgrenzung im Menüabgleich. Keine echten Standort-/Support-/Identifikationsdaten verändert.
- Vollständiger sauberer Maven-Lauf: **921 Tests, 918 bestanden, 3 übersprungen, 0 Fehler**, 104 Suiten (`work/headquarters-settings-final-verify.log`, `work/headquarters-settings-test-summary.json`). Frontend-Produktionsbuild und fünf API-/Arbeitsniederlassungstests bestanden. Quellen vor Paketübernahme mit `work/headquarters-settings-build-sources.json` abgeglichen.
- Isolierte MariaDB: alle fünf bearbeitbaren Bereiche und Fahrzeugzählung; führende Nullen, Parameterbeschreibungen, gemeinsam verwendete Adresskopie und fehlende Adresse, unveränderte Bank-/Länderwerte, fremder Mandant, unklare Zuordnung, fehlende/entzogene Rechte, ungültige Felder/Längen, doppelte/falsch zugeordnete Parameter, Konflikt nach Vorschau, Rollback von Firmenänderung und Adressneuanlage nach Auditfehler, wiederholte Speicherung und abweichende Wiederholung. MyISAM wird vor Änderungen abgewiesen. API-Test für Anmeldung, CSRF und Rechte 47/45.
- SELECT-Prüfung im echten Bestand: neun Standort- und Supportansichten, jeweils zehn Hotline-/GLN-/DUNS-Werte einschließlich bundesweitem Eintrag, 55 Fahrzeugklassengruppen. Alle fünf Schreibtabellen sind bereits InnoDB. Eine tatsächlich geteilte Adresse erkannt; keine Bestandsänderung (`work/headquarters-schema-read-probe.log`, `work/headquarters-settings-read-probe.log`).
- Browserfixture: alle sechs Bereiche sichtbar, Supportkontakt-Vorschau, gesperrte Eingaben nach simulierter verlorener Speicherantwort, zwei identische Speicheranfragen und bestätigter neuer Listenwert. 31 Anfragen (`work/headquarters-settings-ui-events.json`, `work/headquarters-settings-ui-verification.json`). Ausschließlich synthetische Daten; Bild `work/niederlassung-einstellungen-2026-10-17.png`.

## 17. Oktober 2026 – Auftragslisten mit gewöhnlichen Niederlassungsrechten

- Sauberer vollständiger Maven-Lauf: **919 Tests, 916 bestanden, 3 übersprungen, keine Fehler**, 104 Suiten (`work/ordinary-headquarters-final-verify.log`). Fünf Frontend-Tests und Produktionsbuild bestanden. Erster Gesamtlauf erkannte zwei veraltete Testvoraussetzungen (fehlendes `hq_disabled` im lokalen Filterschema und Root-Zugriff nach CC24-Entzug); beide angepasst, anschließend vollständiger sauberer Lauf bestanden. Produktquellen mit `work/ordinary-headquarters-build-sources.json` abgeglichen.
- Isolierte SQL-Prüfung: HQ-Vektor und Matrix müssen gemeinsam passen; vier Rollen, Seitengesamtzahl und CSV; fehlende/entzogene globale und fachliche Rechte, Root-Ausnahme ohne Rechtegewinn, gesperrte/mehrdeutige/fremde Niederlassung, doppelte Matrix und ungültiger Vektor. Heimatkonto bleibt unverändert, Rückkehr funktioniert auch bei defekten Freigaben. API-Test prüft ordentlichen Root-Zugriff nach CC24-Entzug und Sperre nach Entzug des globalen Mehrniederlassungsrechts.
- Bestandsprüfung ausschließlich lesend: **50 normale Mitarbeiterzugänge, 230 erlaubte Niederlassungsauswahlen, 50 Mehrniederlassungslisten**; sieben Konten ohne eindeutige Mandantenzuordnung abgewiesen. Keine Bestandsänderung (`work/ordinary-headquarters-read-probe.log`).
- Browser mit synthetischen SQL-Fixturedaten: Filter der ersten parallelen Liste auf HH; zweite Liste behält B. Bestätigter Fremdauftragswechsel zeigt `HH · Arbeitsniederlassung` und schreibgeschützte Details. Entzogene Freigabe sperrt Folgezugriff; eigene Niederlassung ist weiter erreichbar. Nur GET-Anfragen (`work/ordinary-headquarters-ui-events.json`, `work/ordinary-headquarters-ui-verification.json`). Bild `work/niederlassung-auftragsdetail-2026-10-17.png`.

## 17. Oktober 2026 – Vermittlungsstaufrist

- Vollständiger Maven-Lauf: **919 Tests, 916 bestanden, 3 übersprungen, 0 Fehler**, 104 Suiten (`work/mediation-deadline-final-verify.log`). Danach zwei zusätzliche SQL-Assertions für Erhalt von `MAIL_SENT` und vollständigen Rollback nach fehlgeschlagenem Bearbeitungsbeleg ergänzt; beide betroffenen SQL-Workflows erneut bestanden (`work/mediation-deadline-rollback-check.log`). Fünf Frontend-Tests bestanden, Produktionsbuild grün; danach ausschließlich Darstellung der Frist lesbarer gestaltet und erneut gebaut/paketiert.
- Isolierte SQL-/Serviceprüfungen: Kunden-/globale Standardwerte, Systembarzahler, Kopierregel und Zahlerwechsel, Vorbestellungen/Daueraufträge, alle vorab erzeugten Serientermine, identische Wiederholung, veränderte Regeln zwischen Vorschau/Speichern, Fremdniederlassung, fehlerhafte/mehrfache Parameter und Fristen, Zeitumstellungen, atomare Speicherung und Bearbeitung. Bereits versandte Vormerkungen werden nicht erneut aktiviert.
- Bestandsprüfung ausschließlich mit SELECT: **50 Kundenvorgaben gelesen, drei aktiv; eine vorhandene Auftragsfrist gelesen; keine Ablehnung** (`work/mediation-deadline-read-probe.log`). Keine Daten oder Mailstatus im Bestand geändert und keine Mail versandt.
- Browserfixture: übernommene Frist, Vorlauf bei Vorbestellung, deaktivierte Vormerkung, Verwerfen der Vorschau bei Moduswechsel, gesperrtes Formular nach fehlender Speicherantwort und zwei identische Speicheranfragen bis zur bestätigten Speicherung. Echter Java-Fixtureinhalt, für den Browser in das ISO-Datumsformat der HTTP-API übertragen. Datumeingabe über native Taste bestätigt; finale Speicheranfrage enthält vollständiges ISO-Datum. Der anschließend separat angebotene Maildialog besitzt in dieser Fixture keinen Versandendpunkt. Belege `work/mediation-deadline-ui-events.json`, `work/mediation-deadline-ui-verification.json`; Bild `work/vermittlungsfrist-2026-10-17.png`.
- Laufende Anwendung auf Port 8080 aktualisiert; Start-/Dateiabgleich in `work/mediation-deadline-deployment.json`. Automatische NG-Worker nicht aktiviert. Gesamtziel bleibt offen; nächste Prüfung betrifft die gewöhnlichen Niederlassungsfunktionen der Auftragslisten.

## 17. Oktober 2026 – Kunden-Mailvorgaben und Preisänderungsmail

- Vollständiger Maven-Lauf: **914 Tests, 911 bestanden, 3 übersprungen, 0 Fehler**, 104 Suiten (`work/customer-mail-final-verify.log`, `work/customer-mail-test-summary.json`). Fünf Frontend-Tests und Produktionsbuild bestanden. Nach dem Gesamtlauf ausschließlich den erklärenden UI-Satz zur Wartezeit präzisiert und Frontend/JAR neu paketiert.
- Isolierte MariaDB: acht sichtbare Mailbits, Erhalt versteckter/weiterer Bits, Deutsch/Englisch, Ankunftszeit/Fußzeile, positive Aktivierungswartezeit und separate Minutenwahl; Nullstandards, Parameterbeschreibungen, Konflikte, Rechteentzug, Fremdniederlassung, Kundenwechsel, Rollback bei spätem Parameter-/Auditfehler, verlorene Antwort, konkurrierende Änderungen und InnoDB-Pflicht geprüft. API prüft Anmeldung, beide Rechte und CSRF.
- Preisberichtigung/Neukalkulation: echte isolierte Schreibpfade erzeugen jeweils genau einen neuen Mailbeleg. Wiederholungen bleiben einfach; simulierte Belegfehler rollen Preis-/Berechnungsänderungen zurück.
- Reiner SELECT-Probelauf gegen den Bestand: 25 Kunden-Mailvorgaben gelesen, keine Abweisung; Kunde, Parameter und Vorgangsbelege sind InnoDB (`work/customer-mail-read-probe.log`). Keine echten Kundeneinstellungen verändert, kein SMTP.
- Browserfixture: **59 Anfragen**, Vorschau aller 13 Angaben, zwei identische Speicher-POSTs nach verlorener Antwort, gesperrte Eingabe bei unklarem Ausgang, erfolgreiches Wiederholen, erneutes Laden, Abbruchschutz und aktualisierter Kundeneditor. Nur synthetische Antworten (`work/customer-mail-ui-events.json`, `work/customer-mail-ui-verification.json`), Prüfbild `work/kunden-mailvorgaben-2026-10-17.png`.
- Geprüfter Stand auf Port 8080 neu gestartet; Deployment-Nachweis in `work/customer-mail-deployment.json`. Übrige dokumentierte Funktionen bleiben im aktiven Gesamtziel.

## Änderungsmail nach Auftragsbearbeitung – 17. Oktober 2026

- Frischer Remote-Quellstand, tatsächliches JavaScript-Include und Live-Erfassungsoberfläche geprüft; Hashes und bewusste Unterschiede im Menüabgleich. Keine echte Speicherung oder Mail in PHP.
- Vollständiger sauberer Maven-Lauf auf identischem separatem Quellsnapshot: **912 Tests, 909 bestanden, 3 übersprungen, 0 Fehler**, 104 Suiten (`work/edit-mail-final-verify.log`, `work/edit-mail-test-summary.json`, `work/edit-mail-build-sources.json`). Bestehende Integrationsfälle um die neuen Abläufe erweitert. Frontend-Produktionsbuild und fünf Frontendtests bestanden; bekannter Bundlegrößenhinweis.
- Isolierte SQL-Prüfung: tatsächliche Auftragsbearbeitung erzeugt genau einen wiederverwendbaren Beleg, identische Speicherung ist idempotent. Rollback des Belegs, fehlender/fremder Bearbeitungsbeleg, falsche Heimat-/Arbeitsniederlassung, Auftragstausch, Rechteentzug, Angebote/Storno/Export, geänderte Kundenvorgaben und veränderte Stationsdaten geprüft. CHANGE-Inhalt für offene und erledigte Aufträge, Nachweise, Rechnungstext und PDF; keine Abschlussumfrage. Wiederholung nach simuliertem Neustart sendet nur einmal; weiterer Versand erfordert den aktuellen Vorgängerbeleg. SMTP-Callback bestätigt die bereits abgeschlossene Transaktion.
- Echter Bestand ausschließlich gelesen: 25 erledigte Aufträge als Änderungsmail gerendert, acht mit Bildern, fünf konfigurierte PDFs, keine technische Abweisung (`work/edit-mail-read-probe.log`). Kein Bearbeitungsbeleg in der echten Datenbank angelegt, kein SMTP. Beide synthetischen PDF-Seiten gerendert und visuell kontrolliert.
- Browserfixture aus isolierten SQL-Testantworten: verlorene Speicherantwort → zwei identische PUTs, danach Empfängervorschlag; ungespeicherter Entwurf sperrt Mail; CHANGE-Vorschau und beide PDF-Seiten; explizite Bestätigung; verlorene Versandantwort → Sperre → gespeicherter SENT-Status. Nach Schließen/Wiederöffnen bleiben Mailaktion und Versandstatus verfügbar. **36 Anfragen, ein simulierter Versand, kein SMTP** (`work/edit-mail-ui-events.json`, `work/edit-mail-ui-verification.json`). Prüfbild `work/auftragsmail-bearbeitung-2026-10-17.png`.
- Port 8080 mit beiden Mailergänzungen neu gestartet; Health UP, Datenbank verbunden, sechs Frontenddateien identisch in dist/JAR/HTTP (`work/edit-mail-deployment.json`). Die übrigen dokumentierten Funktionen bleiben im aktiven Gesamtziel.

## Mehrsprachige Auftragsmails – 17. Oktober 2026

- Frischer Remote-PHP-Stand und Live-Sprachauswahl lesend geprüft; Quellen im Menüabgleich. Echter Sprachbestand ausschließlich gelesen: 26 registrierte Sprachen, 118 englische Mailtexte.
- Vollständiger Maven-Lauf: **912 Tests, 909 bestanden, 3 übersprungen, 0 Fehler**, 104 Suiten (`work/mail-language-final-verify.log`, `work/mail-language-test-summary.json`). Wegen konkurrierender Editor-Kompilation in `backend/target` lief Maven auf einem identischen Quellsnapshot unter `work/mail-language-build`; dessen Quellhashes sind in `work/mail-language-build-sources.json` dokumentiert. Der erste normale Build deckte fehlende Imports/Methodenbezüge auf; diese sind korrigiert. Der geprüfte JAR stammt vollständig aus dem getrennten Build.
- Isolierte SQL-Prüfung: englischer Betreff/Inhalt/PDF, unveränderte Kunden-/Leistungswerte, deutscher Rückfall, ungültige/mehrdeutige Sprache, Übersetzungsänderung nach Vorschau, historische englische und gemischte Feldbezeichnungen mit ausgeblendeten privaten Inhalten, Erfassungs- und Detailversand einschließlich Sprach-Tabellensperren. SMTP ausschließlich simuliert.
- Echter Bestand: 25 aktuelle erledigte Aufträge mit englischer Übersteuerung nur im Arbeitsspeicher gerendert, acht mit Bildern, fünf konfigurierte PDFs, keine technische Abweisung (`work/mail-language-render-read-probe.log`). Keine Kundenparameter verändert und keine Mails versandt. Die Stichprobe beweist keine vollständige Wörterbuchabdeckung.
- Browser: englischer Betreff/Inhalt, Hinweis auf fehlende Übersetzungen, unveränderte Datenwerte, beide PDF-Seiten, aktivierter Versand erst nach Bestätigung, ein simulierter Versand und „Weitere Mail“ geprüft. Prüfbild `work/auftragsmail-englisch-2026-10-17.png`, Anfragen/Prüfungen in `work/language-mail-ui-events.json` und `work/language-mail-ui-verification.json`. Beide PDF-Seiten gerendert und visuell geprüft.
- Port 8080 neu gestartet; Health UP, Datenbank verbunden, sechs Frontenddateien identisch in dist/JAR/HTTP (`work/mail-language-deployment.json`). Frontendcode unverändert. Übrige Funktionen bleiben im aktiven Gesamtziel.

## Historische Auftragsmails – 17. Oktober 2026

- Referenz: frischer Remote-Arbeitsbaum `2eb7f98`, drei erneut verifizierte Quellenhashes im Menüabgleich und echte PHP-Detailansicht. Keine Bestandsänderung und kein echter Mailversand.
- Vollständiger Maven-Lauf: **908 Tests, 905 bestanden, 3 übersprungen, 0 Fehler**, 103 Suiten (`work/archive-mail-final-verify.log`, `work/archive-mail-test-summary.json`). Fünf Frontend-Tests bestanden. Anschließend ausschließlich Testassertionen für Erledigungszeit und Rechnungstextfreigabe ergänzt; fokussierte Archiv-/Mail-/SQL-Prüfung erneut erfolgreich (`work/archive-mail-invoice-verification.log`). Produktcode seit dem Gesamtlauf unverändert.
- Isolierte MariaDB: lokale MyISAM-Snapshots, Jahrestabellenpriorität, klassisches/Matrixformat, eingefrorene Preise trotz anderer aktueller Werte, Kundenflags, Kostenstellenbindung, Archivänderung nach Vorschau, doppelte/falsche Snapshots, lokaler und separater Archivversand, fehlende Mailteile sowie tatsächlich verweigerter Testzugriff. Raw-Deflate-Grenzen, abgeschnittene/angehängte Daten, UTF-8/Windows-1252, PHP-Doppelfelder und SQL-Allowlist mit Ablehnung von Funktionen/Mehrfachbefehlen getestet. Alle Schreibvorgänge nur im isolierten Container.
- Echter Bestand: **25 exportierte Aufträge erfolgreich gerendert, 16 mit Bildern, alle 6 konfigurierten PDFs erzeugt, keine technische Abweisung** (`work/archive-mail-read-probe-final.log`). Der zunächst erkannte C1-Eurozeichencode wurde durch korrekte Windows-1252-Decodierung behoben.
- Echter Archivserver: aktuelle PHP-Zugangsdaten funktionieren; **MySQL 5.5.58-0+deb8u1-log**. Ein tatsächlicher Snapshot aus `job2_2024` mit einer Station und sechs Mailbestandteilen wurde ausschließlich gelesen (`work/archive-server-read-probe.log`). Für den in der PHP-UI betrachteten Auftrag existiert kein Snapshot; er nutzt entsprechend PHP den expliziten Rückfall auf aktuelle Daten.
- Browser: synthetische SQL-Antworten, sichtbare Archivquelle, historische Werte, Signaturen/Foto, beide PDF-Seiten, gesperrter Versand vor Bestätigung und genau ein simulierter Versand mit anschließender „Weitere Mail“-Aktion. **20 protokollierte Anfragen, kein SMTP** (`work/archive-mail-ui-events.json`, `work/archive-mail-ui-verification.json`). Prüfbild `work/archiv-auftragsmail-2026-10-17.png`. Beide PDF-Seiten außerdem direkt gerendert und visuell kontrolliert.
- Port 8080 mit geprüftem Stand neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien identisch in dist/JAR/HTTP (`work/archive-mail-deployment.json`). Archivzugangsdaten ausschließlich in der ignorierten `.env`. Vollständige Archivlisten und übrige Fachbereiche bleiben im aktiven Gesamtziel.

## Manuelle Auftragsmail mit PDF und Kundenumfrage – 17. Oktober 2026

- Referenz: frischer Remote-PHP-Arbeitsbaum `2eb7f98` und echte PHP-Detailansicht. Quellen/Hashes und bewusste Unterschiede im aktuellen Menüabgleich.
- Isolierte Datenbank: Kundenfeld-/Preisfreigaben, Bilder/Unterschriften, Artikel, persönliche Umfragelinks, Ansprechpartner, geänderte Nachweise/Metaobjektschlüssel, Rechteentzug, Fremdniederlassung, Auditrollback, InnoDB-Pflicht, Neustart/Wiederholung, zwei konkurrierende Versender und SMTP-Fehler geprüft. Mail-Umfrageprüfung schreibt keine PDA-Daten; bestehende PDA-Regeln bleiben getestet.
- SMTP-Senke auf Loopback prüft UTF-8, HTML/Textalternative, CID-Bilder, exakte PDF-Bytes und privaten Bcc-Umschlag. Keine echten Mails verschickt. PDF seitenweise gerendert und visuell geprüft, inklusive Foto, Unterschriften, Unicode, Preisfreigaben, Umfragelink-Annotation und Seitenzählung.
- Browserprüfung erfolgt ausschließlich mit synthetischen SQL-Antworten unter Port 18744, ohne SMTP. Vorschau, explizite Bestätigung, PDF, bewusste weitere Mail und verlorene Versandantwort → Statusprüfung → Neuversandsperre geprüft.
- Vollständiger Maven-Lauf: **902 Tests, 899 bestanden, 3 übersprungen, 0 Fehler**, 102 Suiten (`work/detail-mail-final-verify.log`, `work/detail-mail-test-summary.json`). Fünf Frontend-Tests und Produktionsbuild bestanden. Nach der visuellen Prüfung wurde lediglich die Mailansicht verbreitert; anschließend Frontend neu gebaut und ohne Codeänderung im Backend neu paketiert.
- Echter Bestand ausschließlich gelesen: **25 aktuelle, nicht exportierte Erledigungsaufträge erfolgreich gerendert, 7 mit Bildern, 4 konfigurierte PDFs im Speicher erzeugt, keine technische Abweisung** (`work/detail-mail-read-probe.log`). In dieser Stichprobe wurde kein Umfragelink ausgewählt; positive persönliche Links, geänderte/fehlende Schlüssel und PDF-URI-Annotationen sind mit isolierten Daten geprüft. Keine Bestandsänderungen, externen Bildabrufe oder SMTP-Verbindungen.
- Port 8080 verwendet den geprüften Stand; Health UP, Datenbank verbunden, sechs Frontenddateien identisch in dist/JAR/HTTP (`work/detail-mail-deployment.json`). Browsernachweis `work/auftragsmail-details-2026-10-17.png`; Zustandsprüfung `work/detail-mail-ui-verification.json`.

## Native Abliefernachweise – 17. Oktober 2026

- Frische SSH-Quellen `image.inc.php`, `inc_job.inc.php`, `jb_detail.php` und `jb_detail_history.inc.php` sowie die echte PHP-Detailansicht mit Unterschriften, Fotos und Stationsmeldungen abgeglichen. Quellen/Hashes im Menüabgleich.
- Vollständiger Maven-Lauf: **898 Tests, 895 bestanden, 3 übersprungen, 0 Fehler**, 101 Suiten (`work/delivery-final-verify.log`, `work/delivery-test-summary.json`). Frontend-Produktionsbuild erfolgreich, bekannte Bundlegrößenwarnung.
- Isolierte Datenbankprüfungen: Auftrags-/Stations-/Fotobindung, fremde Niederlassung, aktueller Rechteentzug, `pic` vor B2B, CDATA-Blöcke in Reihenfolge, doppelte Blöcke, beschädigte Bilddaten, Wiederholung und ungültige Zeitstempel. Daten werden ausschließlich gelesen. API-Prüfungen für Anmeldung und Leserecht; Unterschriftentest prüft getrennte Striche und den letzten Linienabschnitt, Grenzwerte und unzulässige Formate. Die Mail-Regressionsprüfung schließt `[[INTERNAL PAY …]]` aus dem Empfängerinhalt aus.
- Echter Bestand ausschließlich gelesen: **25 vollständige Ansichten, 56 Stationen, 12 Unterschriften und 12 Fotos**, davon sechs Fotos dekodiert; keine technischen Abweisungen (`work/delivery-read-probe.log`). Keine PHP-Temporärdateien, Bestandsänderungen oder SMTP-Aufrufe.
- Browserfixture mit tatsächlichen SQL-Antworten: Unterschrift, Foto, Ankunft/Quittungsgeber, Ablieferstatus, Innendienstbemerkung und Artikelbarcode sichtbar. Fotofehler → gezieltes Wiederholen sowie vollständiger Ladefehler → erneut laden geprüft. 21 protokollierte Anfragen, sämtlich GET. Nachweise `work/delivery-ui-events.json`, `work/delivery-ui-verification.json`; Prüfbild `work/abliefernachweise-2026-10-17.png`.
- Geprüfter Stand auf Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien identisch in dist/JAR/HTTP (`work/delivery-deployment.json`). Eigener Prüftab, Browserfixture und Datenbankcontainer anschließend entfernt.
- Die Nachweisanzeige ist ergänzt; bestätigte Mail für erledigte/bearbeitete Aufträge, PDF-/Archivwege und die übrigen dokumentierten Funktionen bleiben im aktiven Gesamtziel.

## Bestätigte Erfassungsmail – 17. Oktober 2026

- Frische Remote-PHP-Quellen und echte Auftragsdetails lesend geprüft; Quellen/Hashes im Menüabgleich. Kein echter Mailversand, keine Bestandsänderung.
- Vollständiger Maven-Lauf: **893 Tests, 890 bestanden, 3 übersprungen, keine Fehler**, 100 Suiten (`work/request-mail-final-verify.log`, `work/request-mail-test-summary.json`). Ein vorheriger Lauf beanstandete ausschließlich die Platzierung einer Test-Transaktionsassertion; diese liegt jetzt im erlaubten Test und der gesamte Lauf wurde erfolgreich wiederholt. Frontend-Build und fünf Frontend-API-Tests bestanden; bekannter Bundlegrößenhinweis.
- Isolierte MariaDB: Fremdvorgang/Fremdkonto/Fremdniederlassung, Rechteentzug, geänderte Stations-/Mailvorgaben nach Vorschau, Preise/Sichtbarkeitsbits, Empfänger/Cc/Bcc, Erledigungs-/POD-Sperre, Auditrollback und MyISAM-Abweisung. Zwei unabhängig instanziierte Versender bestätigen parallel dieselbe Mail: genau eine Übergabe. Kopiebeleg, verlorene Antwort und Neustart erzeugen ebenfalls keinen zweiten Versand. SMTP-Callback weist nach, dass die Transaktion zuvor beendet ist.
- Lokaler SMTP-Testserver prüft UTF-8, HTML plus Textalternative, To/Cc/Bcc im Umschlag und fehlenden Bcc-Header. Keine echte SMTP-Verbindung. Echter Bestand ausschließlich gelesen: **30 offene Aufträge geprüft und gerendert, keine technischen Abweisungen** (`work/request-mail-read-probe.log`).
- Browserfixture mit synthetischen SQL-Antworten: gespeicherte sechs Kopien, verlorene Speicherantwort und identische Wiederholung, anschließende Vorschau, Bestätigungscheckbox, verlorene Versandantwort → Sperre → Status SMTP bestätigt, Schließen ohne erneute Anlage. Genau zwei identische Anlage-POSTs und ein Mail-POST. Zusätzlich Verlauf, geänderte Vorschau und Ladefehler geprüft. Nachweise `work/request-mail-ui-events.json`, `work/request-mail-history-events.json`, `work/request-mail-ui-verification.json`; Bild `work/auftragsmail-erfassung-2026-10-17.png`.
- Port 8080 mit dem geprüften Stand neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien identisch zwischen dist/JAR/HTTP (`work/request-mail-deployment.json`). Eigene Browserfixture, Prüftab und isolierter Datenbankcontainer anschließend geschlossen/entfernt.
- Erledigte/historische/bearbeitete Aufträge, PDF/Ablieferdaten, weitere Sprachen sowie native automatische Mailworker bleiben im Gesamtziel offen.

## Statusmail-Empfänger – 17. Oktober 2026

- Frische SSH-Quellen und echte PHP-Erfassung geprüft; Quellen/Hashes im Menüabgleich. Keine Bestandsänderung und kein echter Testversand.
- Vollständiger Maven-Lauf: **890 Tests, 887 erfolgreich, 3 übersprungen, 0 Fehler**, 100 Suiten (`work/statusmail-final-verify.log`, `work/statusmail-test-summary.json`). Anschließende Präzisierung der Standardempfänger-Verknüpfungen mit Erfassungs-, Mail-, API-Sicherheits- und gesamter isolierter SQL-Suite erneut geprüft (`work/statusmail-linkage-verify.log`). Frontend-Build und fünf Frontend-API-Tests erfolgreich; bekannte Bundle-Größenwarnung.
- Empfängerlisten/Zeilenumbrüche/Anzeigenamen/Dubletten, PHP-Regelkombinationen, Systembarzahler versus tatsächlicher Zahler, fehlende Ereignisse/Angebote, nachträglich geänderte Vorgaben, veränderte Empfänger nach Vorschau, Kopien, wiederholtes Speichern und Kompatibilität alter Anfragebelege geprüft. Zugriff erfordert Anmeldung und Erfassungsrecht.
- Isolierte MariaDB bestätigt das vorhandene `automailer5`-Auswahlformat und die Unterdrückung bereits verarbeiteter Ereignisse (`1025`, `MAIL_SENT`, `MAIL_NOT_SENT`). Kopie liest nur Adressen; Transaktionsrollback hinterlässt keine Mailvormerkung. Fixture `work/statusmail-ui-fixture.json` enthält ausschließlich synthetische Daten.
- Echter Bestand ausschließlich gelesen: **420 Mailkonfigurationen**, 18 mit gültigen Standardempfängern, 402 mit Hinweisen, keine technischen Abweisungen; zusätzliche LKW-Vorschläge geprüft (`work/statusmail-read-probe.log`). Nachprüfung der vollständigen Empfänger-Verknüpfungen mit 144 weiteren lesenden Abrufen ohne technische Abweisung in `work/statusmail-linkage-read-probe.log`. Kein SMTP-Aufruf.
- Browser: Vorlagenadressen übernommen, zwei Adressen/mehrere Kopien in der Vorschau, Angebote ohne zusätzliche Adressen, Laden fehlgeschlagen → Speichern gesperrt → neu laden bewahrt Entwurf, unterbrochene Speicherantwort → identische Wiederholung mit unveränderten Empfängern. Screenshot `work/statusmail-erfassung-2026-10-17.png`; Anfragen und geprüfte Wiederholung in `work/statusmail-ui-events.json`/`work/statusmail-ui-verification.json`.
- Port 8080 mit dem geprüften Stand neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien identisch zwischen dist/JAR/HTTP (`work/statusmail-deployment.json`). Eigene Testtabs, Browserfixture und Testcontainer anschließend geschlossen.
- Fortschreibung: Separat bestätigte Mail für offene NG-Erfassungen ergänzt (Abschnitt oben). Weitere Mailwege und native Ablösung/Betriebsumschaltung der PHP-Mailverarbeiter bleiben offen. Das Gesamtziel läuft weiter.


## CC24-Arbeitsniederlassung und Auftragslisten – 17. Oktober 2026

- Frischer SSH-PHP-Arbeitsbaum `2eb7f98`; allgemeines Wechselmenü aufgeklappt und echte Auftragslisten-Checkboxen erneut gelesen. Quellen/Hashes und verbleibende Fachlichkeit im aktuellen Menüabgleich. Keine Änderung an PHP oder dessen Sitzungskontext.
- Vollständiger `clean verify`: **879 Tests, 876 bestanden, 3 optionale Live-Prüfungen übersprungen, keine Fehler, 99 Suiten**. Nachweise `work/workspace-final-verify.log`, `work/workspace-test-summary.json`. Anschließend eine zusätzliche Seitenbildungsassertion ergänzt und der gesamte neue SQL-Ablauf erneut erfolgreich geprüft (`work/workspace-pagination-check.log`). Frontend-Build erfolgreich, bekannter Bundlegrößenhinweis (`work/workspace-frontend.log`).
- Isolierte SQL-Prüfungen: CC24-Mitgliedschaft, aktive und eindeutig mandantenzugeordnete Ziele, fehlende/entzogene Rechte, keine nachträgliche Rechteerweiterung, separate Lagerfreigabe, beschädigter/mehrfacher Parameter, sichere Heimat-Rückkehr, unveränderter Loginbenutzer. Persönliche Listen-/Spaltenwerte im Fremdkontext lesbar, entsprechende Pflege und andere Mitarbeiter dort gesperrt. Niederlassungslisten prüfen alle vier PHP-Zuordnungen, eindeutige Treffer trotz Mehrfachrollen, Eigentümer-Mandantengrenze, Deaktivierung/Mehrdeutigkeit, frischen Rechteentzug, Trefferzahl, Seitenbildung und CSV.
- HTTP-Prüfungen: Anmeldung/CSRF, Ablehnung gefälschter/mehrfacher Header, Wiederherstellung des ursprünglichen SecurityContext auch nach Fachfehlern, Abweisung vor Schreibcontroller bei Entzug, Recovery-Endpunkte bleiben erreichbar. Fünf Frontend-API-Tests für getrennte Tabs, an Benutzer/Heimat gebundene Persistenz, alte Antworten, laufende Schreibantworten, Wechsel-Vorprüfung und Rückfall bestanden (`work/workspace-api-tests.log`).
- Echter Bestand nur lesend geprüft: **142 Arbeitsplatzansichten, 49 CC24-Mitglieder, 441 erlaubte Arbeitskontexte einschließlich persönlicher Listenwerte und 46 Mehrniederlassungslisten**. Acht Konten der Stichprobe besitzen keine gültige eindeutige Mandantenzuordnung und wurden vor der Ansichtsprüfung ausgesondert. Keine Konten, Parameter, Aufträge oder Zugriffsrechte geändert (`work/workspace-read-probe.log`). Ein erster Diagnoseversuch mit erwarteten Ablehnungen innerhalb einer gemeinsamen Lesetransaktion führte nach den SELECTs zu einem Rollback-only-Abschluss; das Prüfprogramm trennt diese Vorbedingungen nun korrekt. Abschließender Lauf Exit 0, keine Datenbankstörung.
- Isolierte Browserfixture mit tatsächlichen Java-Antwortdaten: Wechsel in einem von zwei Tabs, Neuladen/Persistenz, fremden Auftrag frisch im Zielkontext öffnen, Dialogsperre, Dispositionskarte, Entzug und Heimat-Rückkehr, Rückfall nach Neuladen, unabhängige Niederlassungsfilter in zwei Parallelfenstern. Alle Fixture-Anfragen lesend, keine Konsolenfehler. Nachweise `work/workspace-ui-events.json`, `work/workspace-ui-verification.json`; Bild `work/cc24-arbeitsplatz-listen-2026-10-17.png`.
- Port 8080 aktualisiert: Health UP, Datenbank verbunden, sechs Frontenddateien identisch in dist/JAR/HTTP (`work/workspace-deployment.json`). Automatische Angebots-/Rückrufworker bleiben unverändert deaktiviert. Eigene Browserfixture, Testtabs und isolierter Testcontainer nach Abschluss geschlossen/entfernt.
- Fortschreibung: Zusatzempfänger und Vorschlagsregel ergänzt; bestätigte Auftragsmail bleibt offen. Gewöhnliche Mehrniederlassungslisten ohne CC24 und die übrigen offenen Fachbereiche bleiben im Gesamtziel.

## CC24-Verwaltung und Erfassung – 17. Oktober 2026

- Aktuelle SSH-Quellen und echtes PHP-Mitarbeiterpopup mit CC24-Ja/Nein gelesen. Quellen/Hashes und verbleibende Verbraucher stehen im Menüabgleich. Keine PHP-Änderung.
- Isolierte MariaDB: Anlage/Entzug, exakte Kennungen, Erhalt fremder IDs und Metadaten, doppelte/ungültige Parameter, Revisionskonflikt, identische Wiederholung, geänderte Wiederholungsdaten, Audit-Rollback und MyISAM-Abweisung. Live- und Sitzungsrechte 3/34, fremder Mandant, Portalbenutzer, fremder Erfassungskontext und Administratorkonten geschützt. Nicht-Administrator darf eigenen CC24-Status ändern.
- Erfassung: CC24 ohne gewöhnlichen HQ-Vektor/Matrix, Entzug mit anschließender Abweisung, keine zusätzlichen Fachrechte, unabhängiges Lagerrecht, deaktivierte und mehrdeutig mandantenzugeordnete HQ ausgeschlossen. Globale Kurierliste, leerer Parameter, gewöhnliche Mitarbeiter und PHP-Sondermitarbeiter separat geprüft. Vorschau/Anlage bei Sperre vor Routing und Schreiben abgewiesen.
- Gesamtprüfung: **873 Tests, 870 erfolgreich, 3 übersprungen, 0 Fehler**, 98 Suiten (`work/cc24-final-verify.log`, `work/cc24-test-summary.json`). Danach Historienanzeige CC24 vorher/nachher ergänzt und als Rechteänderung eingeordnet; SQL-Gesamtworkflow dieses Bausteins plus Historienprüfungen erneut erfolgreich (`work/cc24-audit-check.log`). Frontend-Build erfolgreich, bekannte Größenwarnung (`work/cc24-frontend.log`).
- Echter Bestand ausschließlich gelesen: **17 Mitarbeiteransichten, davon 8 CC24-Mitglieder, 72 Erfassungskontexte**. Parameter/Audit InnoDB, HQ 10 nicht vorhanden (`work/cc24-read-probe.log`). Keine Zugangsdaten, Rechte oder Aufträge im Bestand geändert.
- Isolierte Browserfixture: Bestätigung vor Speichern, Entwurf behalten, verlorene Antwort nach Speicherung, identische Wiederholung mit gesperrtem Bearbeiten/Schließen, geschütztes Konto, Lesefehler und erneutes Laden. Keine Konsolenfehler. Prüfbild `work/cc24-zugang-2026-10-17.png`; Belege `work/cc24-ui-events.json`, `work/cc24-ui-verification.json`.
- Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien identisch zwischen dist/JAR/HTTP (`work/cc24-deployment.json`). Testcontainer, Fixture und eigene Prüftabs nach Abschluss entfernt.
- Fortschreibung: Allgemeiner CC24-Arbeitsplatzwechsel und CC24-Auftragslistenauswahl anschließend ergänzt (Prüfung oben). Statusmail-Vorschlag und Gesamtziel bleiben offen.



## 17. Oktober 2026 – Kundenmitarbeiter und Kostenstellenrechte

- Frischen SSH-PHP-Arbeitsbaum geprüft. Aktueller PHP-Matrixdialog liefert HTTP 500; die Ursache ist damit allein nicht bewiesen. Die ebenfalls festgestellte fehlende Tabelle steht separat im Schema-/Betriebsbefund. Quellcodevergleich und Grenzen im Menüabgleich.
- Vollständiger `clean verify`: **870 Tests, 867 bestanden, drei vorhandene optionale Live-Tests übersprungen, keine Fehler, 98 Suiten** (`work/portal-employees-final-verify.log`, `work/portal-employees-test-summary.json`). Frontend-Produktionsbuild erfolgreich, bekannter Bundlegrößenhinweis. Nachträglich wurde nur der Audittext um das vorherige Profil ergänzt; der gesamte neue SQL-Ablauf danach erneut fokussiert geprüft (`work/portal-employees-audit-check.log`) und neu paketiert.
- Isolierte MariaDB: neue Konten und PHP-Listenvorgaben, globale Login-Konflikte, fehlende/aktivierte/deaktivierte Matrix, InnoDB-Skript, Stammkostenstellenwechsel, fremde/zyklische Kostenstellen, geschützte Hauptzugänge, Delegation, Erhalt fremder Freigaben/unbekannter Rechtebits, aktuelle Session-/DB-Rechte, Konflikt/Retry und parallele Kontoanlage. Profil/Rechte/Matrix/Audit rollen nach Fehlern gemeinsam zurück. Passwort/2FA/Löschung, vollständige Zuordnungsbereinigung, MyISAM-Abweisung und Ausschluss von Portalbenutzern aus der NG-Zentralenanmeldung geprüft. Neue Kunden-Hauptrechte im vorhandenen Stammdatentest mit unabhängiger PHP-Bitfolge geprüft.
- Echter Bestand ausschließlich gelesen: **25 Kundenlisten, 33 Mitarbeiteransichten**, darunter zusätzliche Portalmitarbeiter. Kein Konto, Passwort oder Recht geändert. Matrix-Tabelle fehlt (`work/portal-employees-read-probe.log`).
- Browser: tatsächliches Java-Fixtureformat, Kundenstamm-Einstieg, vollständiger Rechtekatalog und Stammkostenstellen, verlorene Antwort mit exakt identischem Retry, nachgeladenes Ergebnis, gesperrter Entwurf bei unklarem Ausgang, Weiterbearbeiten/Verwerfen, eingeschränkte Matrix und fehlende Tabelle, Lesefehler/Retry sowie Schutz des Hauptzugangs. Keine Passwort-/2FA-/Löschanfrage über den Browser; diese Aktionen ausschließlich in isolierten SQL-Tests. Nachweise `work/portal-employees-ui-events.json`, `work/portal-employees-ui-verification.json`, Bild `work/kundenmitarbeiter-portalrechte-2026-10-17.png`.
- Port 8080 aktualisiert; Health/DB und dist/JAR/HTTP-Abgleich in `work/portal-employees-deployment.json`. Testcontainer, Testserver und Testtabs nach der Prüfung entfernt. Die vorbereitete Matrix-Tabelle ist keine ausgeführte Bestandsmigration. Gesamtziel und übrige Menülücken bleiben offen.


## 17. Oktober 2026 – Portal-Hauptzugänge

- Aktuellen SSH-PHP-Arbeitsbaum sowie Kunden-/Transporteurstammblatt der echten PHP-Oberfläche geprüft. Referenzen und bewusst abweichende Passwortvergabe stehen im Menüabgleich.
- Vollständiger `clean verify`: **868 Tests, 865 bestanden, drei vorhandene optionale Live-Tests übersprungen, keine Fehler, 98 Suiten**. Nachweise: `work/portal-accounts-final-verify.log`, `work/portal-accounts-test-summary.json`. Frontendbuild erfolgreich, bekannter Bundlegrößenhinweis; anschließende reine UI-Korrektur verhindert eine Erfolgsmeldung beim Schließen ohne Änderung, erneut gebaut und paketiert.
- Isolierte SQL-Prüfungen: Aktivierung, Umbenennung ohne Passwortwechsel, Sperre ohne Kontaktverlust, Passwortwechsel mit Legacy-Hashentzug, 2FA-Rücksetzung, eigenes Passwort, globale Namenskonflikte, unbekannter Kontotyp, falsche Hauptkostenstelle, fremde Niederlassung, frischer Rechteentzug, veraltete Revision, Rollback bei Auditfehler, parallele identische Anfragen, Wiederholung mit anderem Passwort und MyISAM-Abweisung. Session-/CSRF-/Rechteprüfung für alle neuen Endpunkte. Keine Geheimnisse in API-Antworten oder Audit/Belegen.
- Echter Bestand nur gelesen: 20 Hauptzugänge erfolgreich abgerufen. Aggregierter Zuordnungscheck für 67.273 Kunden und 7.485 Transporteure ohne abweichenden Kontotyp bzw. Heimatniederlassung; Kundenhauptkostenstellen konsistent. `user`, `employee`, `customer`, `courier`, `costcenter`, `genericdatacontainer` InnoDB. `employeecostcenter` fehlt. Nachweise: `work/portal-accounts-schema.log`, `work/portal-accounts-read-probe.log`.
- Browserprüfung mit synthetischen Daten und tatsächlichem Java-Antwortformat: Einstieg über Kundenstamm, aktive/gesperrte Konten, 2FA-Rücksetzungsbestätigung, erforderliche Passwortwiederholung bei Aktivierung, gesperrte Speicherknöpfe bei fehlender Eingabe, 503-Lesefehler und erfolgreiches erneutes Laden. Keine Zugangsdaten im Browser eingegeben und keine schreibende Kontoanfrage ausgeführt; Schreibabläufe durch isolierte SQL-Tests geprüft. Screenshot `work/portal-hauptzugang-2026-10-17.png`, Anfragen `work/portal-accounts-ui-events.json`.
- Laufende Anwendung auf Port 8080 mit neuem Paket gestartet. Health UP, DB verbunden, sechs Frontenddateien identisch in dist/JAR/HTTP (`work/portal-accounts-deployment.json`). Automatische Angebots-/Rückrufworker bleiben deaktiviert. Testtab und isolierter Testcontainer geschlossen/entfernt. Weitere Portalmitarbeiter/Kostenstellenrechte und übrige offene Menübereiche sind noch nicht abgeschlossen.


## 17. Oktober 2026 – Mitarbeiter-Lagerrechte und Buchungszugang

- Frischen SSH-PHP-Arbeitsbaum `2eb7f98` und echte Mitarbeiteroberfläche geprüft. Hauptlager, Unterlager und beide Schalter mit aktuellem Code abgeglichen. Referenz-Hashes und bewusst strengere Rechteprüfung stehen im Menüabgleich; kein lokaler PHP-Altstand verwendet.
- Abschließender vollständiger `clean verify`: **866 Tests, 863 bestanden, drei optionale Live-Tests übersprungen, keine Fehler, 98 Suiten** (`work/stock-rights-final-verify.log`, `work/stock-rights-test-summary.json`). Frontend-Produktionsbuild erfolgreich; nur bekannter Bundlegrößenhinweis. Nach dem ersten vollständigen Lauf wurden Suche und Rechteabfrage optimiert; der abschließende Lauf enthält diese Änderungen.
- Isolierte MariaDB: atomare Parameterspeicherung mit Audit/Beleg, verlorene Antwort/idempotenter Retry, unveränderte Beschreibungen und fremde Rechte, Rollback nach Auditfehler, geänderter Lagerbaum, Fremdmandant/geschützte Konten, eingeschränkte Delegation, unerlaubte Wurzel-/Unterlagerfreigaben, Leserechte, aktuelle und Heimatniederlassung, doppelte/fehlerhaft zugeordnete Parameter sowie MyISAM-Abweisung. Bestehende Buchungs-/Gegenbuchungstests bestehen weiter. Neue Tests prüfen sofortigen Rechteentzug bei gesperrter Vorschau und zugängliche Treffer hinter der ersten internen Suchseite.
- Echter Bestand nur gelesen: 17 Mitarbeiterkonfigurationen und 14 Hauptläger; in dieser Stichprobe keine blockierten Parameter. `parameter`, `genericdatacontainer` und `stock` sind InnoDB (`work/stock-rights-read-probe.log`). Keine realen Lagerbewegungen, Konten- oder Rechteänderungen.
- Browser mit echten Java-Fixtureantworten: Einstieg aus Mitarbeiterliste, Hauptlager-/Unterlagerauswahl, Lesemodus, Artikelverwaltung, erfolgreiche Speicherung nach verlorener Antwort, gesperrter Entwurf während unklarem Ergebnis und exakt identischer Retry. Beschränkte Bearbeiter können fremdes Hauptlager bzw. letzte Unterlagereinschränkung nicht entfernen. Lesefehler/erneutes Laden und Abbruch des Entwurfsdialogs geprüft. Nachweise: `work/stock-rights-ui-events.json`, `work/stock-rights-ui-verification.json`; Bild `work/mitarbeiter-lagerrechte-2026-10-17.png`.
- Port 8080 mit aktuellem Paket neu gestartet. Health UP, DB verbunden; sechs Frontenddateien zwischen dist, JAR und HTTP identisch (`work/stock-rights-deployment.json`). Angebots-/Rückrufworker bleiben im Parallelbetrieb deaktiviert. Testtab und Fixture-Server geschlossen, isolierter Testcontainer anschließend entfernt.
- Weiterhin offen: Kundenportal-Kostenstellenrechte, Sprache/CC24/Metaobjekte, vollständige Lagerverwaltung und die weiteren aktuellen Tabellenpunkte. Das Gesamtziel bleibt aktiv.

## 17. Oktober 2026 – automatische Angebotsrunden

- Frischen SSH-PHP-Arbeitsbaum und die erreichbare PHP-Autorankingliste geprüft. Quellen und bewusste Abweichungen im Menüabgleich. Kein lokaler PHP-Altstand verwendet.
- Vollständiger `clean verify`: **859 Tests, 856 bestanden, drei optionale Live-Tests übersprungen, keine Fehler** (`work/autooffer-full-verify.log`, `work/autooffer-test-summary.json`). Frontend-Produktionsbuild erfolgreich, bekannter Bundlegrößenhinweis.
- Isolierte MariaDB: Favoritenpriorität, Wiederholungsrunden mit neu gelesener Verfügbarkeit, Versuchslimit, Ignoriermarkierung, fester Kurier/Reservierungsfenster, manuelle/globale Rückfälle, alle drei gerichteten Bereichsmodi, Belegung über Tagesgrenzen, Quarantäne, doppelte Historie, PHP-Lock und fehlende Anfahrtszeit. Zwei parallele Worker erzeugen genau ein Angebot; Auditfehler rollt Auftrag/Kurier/Ranking/Nachweis gemeinsam zurück. Alle Schreibziele einzeln als MyISAM abgewiesen. Cursor überspringt eine volle Seite unvollständiger Aufträge. Rechte-/Sessiontests und reine Regeltests einschließlich Fahrzeug-/Filterausnahmen, Nationalität/EG-Lizenz sowie inklusiver Ortungs-Endminute.
- Echter Bestand nur gelesen: 40 vorliegende Status-8-Aufträge haben keine aktivierte Dispositionskonfiguration (`work/autooffer-read-probe.log`). Zusätzlich 20 geeignete manuell zuzuweisende Bestandsaufträge mit **nur im Arbeitsspeicher angenommenem Status 8** durch dieselbe Berechnung geprüft: 20 READY, sieben Kandidaten, keine Änderungen (`work/autooffer-simulation.log`). Dies ist kein Nachweis tatsächlich verteilter Live-Angebote.
- Browser mit tatsächlichen Java-Fixtureantworten: Reihenfolge Favorit/Bereich/Nachbarschaft, aufklappbare Kandidatenliste, nächste Auswahl, Reservierungswartezeit, 503-Fehler und erfolgreicher Retry. Aktualisieren liest beide Vermittlungsanzeigen neu. Kein POST durch die neue Vorschau (`work/autooffer-ui-events.json`, `work/autooffer-ui-verification.json`). Screenshot: `work/automatische-angebotsrunden-2026-10-17.png`.
- Der aktivierte Angebotslauf aktualisiert den vorhandenen MyISAM-Keepalive `autoranking` mit einem separaten, idempotenten Zeitstempel. Isolierter SQL-Test bestätigt Aktualisierung nur bei aktiviertem Worker und Erhalt fremder Prozesszeiten (`work/autooffer-heartbeat-test.log`); reale Tabelle nur gelesen (`work/autooffer-heartbeat-probe.log`).
- Abschließend paketiert und auf Port 8080 neu gestartet: Health UP, DB verbunden, sechs Frontenddateien zwischen dist/JAR/HTTP identisch (`work/autooffer-deployment.json`). Nach der vollständigen Suite wurde nur der Keepalive ergänzt und dessen gezielter SQL-Test erneut erfolgreich ausgeführt.
- Angebots- und Rückrufdienst bleiben im Parallelbetrieb ausgeschaltet. Keine realen Angebote, Kurieränderungen oder Gerätemeldungen ausgelöst. Betriebsumschaltung, Geräte-/Prozessüberwachung und die übrigen offenen Menübereiche bleiben separat.


## 17. Oktober 2026 – Rückrufdienst und Angebotsfristen

- Aktuelle SSH-Hauptschleife, Rückruffunktionen und Parameterauflösung abgeglichen. Hintergrundregeln, konservative Bestandskorrekturen und Umschaltung im Menüabgleich.
- Vollständiger `clean verify`: **851 Tests, 848 bestanden, drei optionale Live-Tests übersprungen, keine Fehler** (`work/revocation-full-verify.log`, `work/revocation-test-summary.json`). TypeScript/Vite erfolgreich; bekannter Bundlegrößenhinweis. Danach ausschließlich den Hinweis „wird zurückgerufen“ zu „ist zum Rückruf fällig“ präzisiert und das Paket erneut gebaut (`work/revocation-package.log`).
- Neue isolierte Prüfungen: exakte Fristgrenze, automatische/manuelle Dauer, beide Rückrufmodi, feste Vorbestell-/Dauerkuriere, Rangverlust/-erhalt, NULL/Storno/Abrechnung/PHP-Sperre, anderer aktueller Fahrer gegenüber neuerer Historie eines fremden Fahrers, fehlende/doppelte Nachweise, geänderte Annahme, lokale Aktivierung ohne globalen Fallback, ungültige/fehlende/mehrdeutige Parameter, PDA-Zeit/Gültigkeit/Niederlassung, doppelte parallele Verarbeitung, spätes vollständiges Rollback, erhaltene Preise/Rankingversuche, Belegtneuberechnung, passende/fremde/verwaiste Vermittlungssperre, Batchcursor und ausgeschalteter Worker ohne DB-Zugriff. MyISAM-Rankinghistorie lesbar, jede tatsächliche MyISAM-Schreibtabelle blockiert. Session/Rechte/HQ für den lesenden API-Endpunkt geprüft.
- Browser mit Java-/SQL-Testantworten: separater Lesefehler und Wiederholung, Frist abgelaufen/laufend, automatischer/manueller Folgestatus, Rangverlust/-erhalt, fehlender aktueller Rankingnachweis, deaktivierter Worker sichtbar. Keine Browser-Schreibrequests und keine Konsolenfehler. Nachweise `work/revocation-ui-verification.json`, `work/revocation-ui-events.json`; Bild `work/angebotsfrist-2026-10-17.png`.
- Echte Datenbank ausschließlich gelesen: 40 aktuelle Aufträge erfolgreich abgefragt, aktuell keine offenen Fahrerangebote in der geprüften Niederlassung. Daher kein Live-Nachweis eines fälligen Angebots. Zeitabhängige Rückrufe ausschließlich isoliert geprüft; reale DB-Schreibzugriffe/Gerätenachrichten null (`work/revocation-read-probe.log`). Neuer Worker im lokalen Betrieb ausdrücklich aus; der eigentliche autonome Angebotslauf bleibt offen. Gesamtziel aktiv.
- Paket auf Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien dist/JAR/HTTP bytegleich (`work/revocation-deployment.json`). Eigene Fixture-Server, Browserprüftab und MariaDB-Testcontainer entfernt.


## 17. Oktober 2026 – automatische/manuelle Einzelvermittlung

- Frische SSH-PHP-Aktionsskripte, Popupgenerator und JavaScript abgeglichen; aktuelle echte PHP-Auftragsliste gelesen. Referenzgrenzen und bewusste Ergänzung automatischer Geräterückrufe im Menüabgleich.
- Vollständiger `clean verify`: **840 Tests, 837 bestanden, drei optionale Live-Tests übersprungen, keine Fehler** (`work/mediation-full-verify.log`, `work/mediation-test-summary.json`). TypeScript/Vite erfolgreich; bekannter Bundlegrößenhinweis. Ein fehlgeschlagener erster Testaufbau nutzte versehentlich den Generated-Key-Helper für die schlüssellose Autoranking-Tabelle; Fixture auf normales INSERT korrigiert.
- Isolierte MariaDB: Statusregeln, Rechnungskunden-/Barzahlerauflösung, fehlende Vorgabe, BWV-/Erledigt-Sperre, Rechte/HQ, PHP-Bearbeitungssperre, Revisionskonflikte bei Kunde/Parameter/Markierung, keine Vorschau-Schreibeffekte, parallele identische Speicherung, abweichende Wiederholungsdaten, spätes vollständiges Rollback. Marker-Duplikate werden beim automatischen Wechsel bereinigt, manuell erhalten. Rückruf je unterschiedlichem Fahrer, 30 Sekunden/zehn Jahre, Belegtneuberechnung, unveränderte Freimeldung/Preise/Rankinghistorie. MyISAM-Sperre für jede der vier Schreibtabellen.
- Browser mit Java-/SQL-generierter Fixture: Checkbox und Vorschau, automatische Speicherung mit verlorener Antwort und exakt identischem Retry, manuelle Rücknahme angenommener Aufträge, automatische Sperre, erhaltene Auswahl beim Abbrechen sowie 409-Konflikt ohne erneutes Speichern. Keine Konsolenfehler. Nachweise `work/mediation-ui-verification.json`, `work/mediation-ui-events.json`, Bild `work/vermittlungswechsel-2026-10-17.png`.
- Echte DB ausschließlich gelesen: **40 Vermittlungsstände, 36 zulässige Vorschauen, 17 Kunden mit „Nur Anforderungen“**. Null DB-Schreibzugriffe, Routingaufrufe und Gerätnachrichten (`work/mediation-read-probe.log`). Eigenständiger Vermittlungsworker bleibt offen; Gesamtziel aktiv.
- Geprüftes Paket auf Port 8080 neu gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien zwischen dist/JAR/HTTP bytegleich (`work/mediation-deployment.json`). Eigene Fixture-Server, Prüftabs und MariaDB-Testcontainer entfernt. Keine autonomen Schreibworker aktiviert.


## 17. Oktober 2026 – laufende Aufträge in der Kurierauswahl

- Aktuellen SSH-Popupgenerator und echte PHP-Auftragsliste erneut gelesen. Neuer lesender Auftragsabruf für CLASSIC, BWV und manuelle Auswahl. Herkunft und Grenzen einschließlich der korrigierten Neukurier-Restposition im Menüabgleich.
- Vollständiger abschließender `clean verify`: **825 Tests, 822 bestanden, drei optionale Live-Tests übersprungen, keine Fehler** (`work/running-full-verify-final.log`, `work/running-test-summary.json`). TypeScript/Vite erfolgreich, bekannter Bundlegrößenhinweis.
- Neue isolierte SQL-Prüfungen: leere Liste, 23 Aufträge über zwei Seiten, Gesamtzahl und stabile Reihenfolge, Status 0/1, NULL-Stornoflag, Ausschluss aktueller/stornierter/erledigter Aufträge, erledigte Station in korrekter Folge, Duplikate in Vorlaufdaten, belegtes und künftiges Fahrzeug, fremde BWV-Kurzübersicht ohne vertrauliche Detailfelder, Rechte/Heimatniederlassung, geänderte Fahrerbindung, CLASSIC-Sichtbarkeit fremder Fahrzeuge und BWV-Ausnahme. Auftragsbestände vor/nach Lesetest unverändert; aktualisierter Stations-/Erledigungsstand wird erneut gelesen.
- Ein zunächst fehlender Vorlaufdatensatz der neuen Testfixture wurde ergänzt. Inkrementelle Fremdklassen wurden durch `clean` beseitigt. Der erste Gesamtlauf zeigte zusätzlich einen bestehenden nächtlichen Kartentestfehler: „vor 45 Minuten“ fiel vor Mitternacht. Die heutigen Fixture-Ortungen werden jetzt auf mindestens eine Sekunde nach Tagesbeginn begrenzt; die expliziten Vortags-/Mitternachtsfälle bleiben unverändert geprüft. Anwendungscode der Karte unverändert.
- Browser: CLASSIC und manuelle Auswahl mit echten Java-/SQL-Testantworten; BWV-Einbindung mit denselben Auftragsantworten. Simulierter Lesefehler mit erfolgreicher Wiederholung, Seitenwechsel, Stationsmarkierung, fremde Übersicht ohne Detailknopf, eigene Lesedetails mit Anschriften/Kontakt/Abschluss und erhaltene Kurierauswahl. Abschließender Browser ohne Warnungen/Fehler, keine schreibenden Fachaktionen. Nachweise `work/running-ui-verification.json`, `work/running-ui-events-classic.json`, `work/running-ui-events.json`; Bild `work/laufende-auftraege-rangliste-2026-10-17.png`.
- Reale Datenbank ausschließlich gelesen: **65 Fahrzeugabfragen und 38 laufende Aufträge** erfolgreich; null DB-Schreibzugriffe und null externe Routingaufrufe (`work/running-read-probe.log`).

- Geprüftes Paket auf Port 8080 gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien zwischen dist/JAR/HTTP bytegleich (`work/running-deployment.json`). Eigene Fixture-Server, Testtabs und MariaDB-Testcontainer entfernt. Retourenworker bleibt deaktiviert. Gesamtziel weiterhin aktiv.

## 17. Oktober 2026 – Fahrerwechsel bei abweichendem Fahrzeughalter

- Aktuellen SSH-Ranking-/Popup-/JavaScript-Stand erneut gelesen; echte PHP-Transporteuransicht mit Fahrer- und Fahrzeugspalten geöffnet. Details und Grenzen im Menüabgleich. Keine reale Anmeldung oder Zuweisung ausgeführt.
- Vollständiger `clean verify`: **824 Tests, 821 bestanden, drei optionale Live-Tests übersprungen, keine Fehler** (`work/multi-full-verify-final.log`, `work/multi-test-summary.json`). Frontend-Verbesserung der Fahrerlesbarkeit, gemeinsamer Einstieg aus der normalen Auftragsbearbeitung und BWV-Anmeldeklasse sind im abschließenden Stand enthalten. TypeScript/Vite- und Paketbau erfolgreich. Bekannter Bundlegrößenhinweis.
- Neue isolierte Prüfungen: deaktivierter/aktivierter Mehrfahrerparameter, lokaler Nullwert über globaler Aktivierung, getrennte Fahrer-/Halter-ID, Fahrernamenssuche, Fahrerfavorit gegenüber gesperrtem Halter, personenbezogener Pflichtfilter, Anmeldung nach Auswahl geändert, doppelte Anmeldung, App-Sperre ohne Offline-Umgehung, Halter bei fehlender Anmeldung, allgemeine Statusaktion ohne Fahrerbindung, Karten-Vorschau/-Speicherung, BWV-Kandidat und Routenstart des anderen Fahrers bei fehlenden Halterkoordinaten, fremde Fahrer-Niederlassung bei unveränderter Auftragshoheit, spätes vollständiges Rollback, richtige Autoranking-/Belegt-Zuordnung, unveränderter Halter, identischer Retry nach späterer Abmeldung und abweichende Fahrer-ID unter derselben Vorgangskennung.
- Ein zunächst falscher erwarteter HTTP-Status im neuen Test wurde an den bestehenden expliziten Fehler für wiederverwendete Vorgangskennungen angepasst. Ein zwischenzeitlich inkonsistenter inkrementeller Klassenstand wurde durch den sauberen Neubau beseitigt. Der abschließende vollständige Lauf ist grün.
- Browserfixture aus echten Java-/SQL-Testantworten: tatsächlicher Fahrername und abweichender Halter sichtbar, Namensfilter, Fahrer-ID in Vorschau und Speicherrequest identisch, simulierte verlorene Antwort mit exakt gleichem Wiederholungsrequest und erfolgreicher Zuweisung. Normaler Auftrag öffnet aus der Bearbeitung denselben CLASSIC-Dialog; ungespeicherter Entwurf sperrt den Einstieg. Abschließender Browser ohne Warnungen/Fehler. Nur lokale Fixture-Schreibrequests. Nachweise `work/multi-driver-ui-verification.json`, `work/multi-driver-ui-events-assignment.json`, `work/multi-driver-ui-events-workbench.json`; Bild `work/fahrer-fahrzeug-zuweisung-2026-10-17.png`.
- Echte Datenbank ausschließlich gelesen: Mehrfahrerparameter aktiv, **862 angemeldete Fahrzeug-/Fahrerpaare, davon vier mit anderem Halter und ein mehrdeutiges Paar**. Alle 861 eindeutigen Paare erneut erfolgreich aufgelöst. Zum nächtlichen CLASSIC-Prüfzeitpunkt keine verfügbaren Kandidaten. Null DB-Schreibzugriffe und null externe Routingaufrufe (`work/multi-read-probe.log`). Keine vorhandene Anmeldung korrigiert oder verändert.

- Geprüftes Paket auf Port 8080 gestartet: Health UP, Datenbank verbunden, sechs Frontenddateien zwischen dist/JAR/HTTP bytegleich (`work/multi-deployment.json`). Eigene Browserfixtures und MariaDB-Testcontainer entfernt. Retourenworker bleibt deaktiviert.

## 17. Oktober 2026 – CLASSIC-Rangliste und gemeinsame Belegt-Erkennung

- Aktuellen SSH-PHP-Arbeitsstand und erreichbare echte PHP-Auftragsliste abgeglichen. Der gewählte Autoranking-Zeitraum war leer; Regeln und Gruppen sind über den aktuellen Popupgenerator geprüft, kein vollständiger visueller Nachweis des alten Popups. Quellen, bewusste Korrekturen und Grenzen im Menüabgleich.
- Abschließender vollständiger `clean verify`: **823 Tests, 820 bestanden, drei optionale Live-Tests übersprungen, keine Fehler** (`work/classic-full-verify-final.log`, `work/classic-test-summary.json`). Frontend-Produktionsbuild erfolgreich; bekannter Bundlegrößenhinweis.
- Isolierte SQL-Tests: alle drei Vermittlungsmodi, gerichtete Bereichs-/PLZ-Nachbarschaften und Rangverlust, konfigurierbare Tiefe, Favoriten, gesperrte/nicht verfügbare Kuriere, Fahrzeugklasse, Maße, Auslagen, Pflichtfilter/Favoritenausnahmen, Länderfreigaben und optionale Einschränkungen der übrigen Kuriere. Freie/belegte Reihenfolge berücksichtigt heutige Vorlaufzeit, spätere Vorbestellungen, Storno und veraltetes Belegt-Merkmal. Dieselbe Berechnung ist für BWV geprüft. Eigene Modus-2- und Modus-3-Testtabellen verhindern gegenseitige Beeinflussung älterer Kartenfixtures.
- Fremdniederlassungs-Kandidaten: zulässige Bereichs-/Favoritenauswahl, zwischenzeitliche Standortänderung, blockierte allgemeine Statusaktion, atomare Zuweisung und identischer Retry bei unverändertem Auftrags-HQ. Bestehende Rechte-, CSRF-, Revisions-, Schreibschutz- und Rücksetzungsprüfungen bleiben grün.
- Browser mit Java-generierter lokaler Fixture: CLASSIC als Standard, Favoriten-/Gruppen-/Belegungs-/Textfilter, Reihenfolge, gesperrte Schaltflächen, Fremdniederlassungs-Vorschau und erfolgreiche Testzuweisung. Zusätzliche BWV-Anzeigefixture prüft reale Belegung gegenüber altem Belegt-Merkmal. Keine Konsolenfehler; keine echten Aufträge geändert. Nachweise `work/classic-ui-verification.json`, `work/classic-ui-events.json`, `work/classic-bwv-ui-events.json`; Bilder `work/classic-rangliste-2026-10-17.png` und `work/classic-bwv-belegung-2026-10-17.png`.
- Reale Datenbank ausschließlich gelesen: CLASSIC-Modus 1, zum nächtlichen Prüfzeitpunkt keine verfügbaren Kandidaten, keine Warnungen oder SQL-Fehler. Null DB-Schreibzugriffe und null externe Routingaufrufe (`work/classic-read-probe.log`).
- Geprüftes Paket auf Port 8080 gestartet: Health UP, Datenbank verbunden, alle sechs Frontenddateien zwischen dist/JAR/HTTP bytegleich (`work/classic-deployment.json`). Eigene Fixture-Server, Prüftabs und MariaDB-Testcontainer entfernt. Retourenworker bleibt deaktiviert. Gesamtziel weiterhin aktiv; offene Sonderfälle und übrige Bereiche bleiben im Menüabgleich ausgewiesen.

## 17. Oktober 2026 – bundesweite BWV-Kandidatenauswahl

- Aktuellen SSH-PHP/JS-Stand und echte PHP-Auftragsliste gelesen; Popup-Regeln über den aktuellen Generator abgeglichen, da das Öffnen echte Koordinaten/Preismerkmale schreiben würde. Funktionsumfang und verbleibende Sonderfälle stehen im aktuellen Menüabgleich.
- Abschließender `clean verify`: **814 Tests, 811 bestanden, drei optionale Live-Tests übersprungen, keine Fehler** (`work/candidates-full-verify-final.log`, `work/candidates-test-summary.json`). TypeScript/Vite erfolgreich, bekannter Bundlegrößenhinweis.
- Neue Prüfungen: PHP-Entfernungsmaß/strikte Grenze, Radiusparameter und Maximum, echte automatische Erweiterung von 50 auf 150 km, manuelle leere Suche, Heimatorttreffer, Favorit außerhalb des Radius, eigene Zeitfenster/Wunschort ohne Verfügbarkeitsfenster, Filterausnahmen und ungültige Vorschau nach Parameteränderung, Frei-/Belegt-Reihenfolge, Kundensperre, Rechte/CSRF/HQ-Grenze, fremdes Fahrzeug nur für BWV, atomare Zuweisung mit unverändertem Auftrags-HQ, identischer Retry und Konflikt bei geänderten Standortdaten.
- Isolierter Browser mit Java-generierten Such-/Preisfixtures: zwei Kandidaten, Favoriten-/HQ-Filter, 153,30/184,10 € in korrekter auf-/absteigender Reihenfolge, kompletter Vergleich, einzelner Routenausfall, Abbruch, Vorbestellung mit automatisch übernommenem Wunschstart, erfolgreiche Testzuweisung, Radiussteuerung und manuelle Fahrzeugliste. Keine Fehler im abschließenden Browserlauf. Bild `work/bwv-kandidaten-2026-10-17.png`; Ereignisse und Prüfergebnis `work/candidates-ui-events*.json`, `work/candidates-ui-verification.json`. Browser-Schreibrequest nur an die lokale Fixture; SQL-Schreibtests ausschließlich in eigener MariaDB.
- Reale Datenbank ausschließlich gelesen: 858 angemeldete Fahrzeuge, davon 793 fremde Niederlassungen; konfigurierte Radiusstufe 40 km, Maximum 960 km, Favoriten-/Fensterabfragen erfolgreich. Null Datenbankschreibzugriffe und null externe Routingaufrufe (`work/candidates-read-probe.log`).
- Port 8080 mit geprüftem Paket neu gestartet: Health UP, Datenbank verbunden, alle sechs Frontenddateien zwischen dist/JAR/HTTP bytegleich (`work/candidates-deployment.json`). Eigene Browserfixture, Testtab und MariaDB-Testcontainer entfernt. Der Retourenworker bleibt während des PHP-Parallelbetriebs deaktiviert. Gesamtziel weiterhin aktiv.

## 17. Oktober 2026 – BWV-Retourenprüfung und Nachvergütung

- Aktuellen SSH-Arbeitsstand, PHP-Hintergrundblock, PDA-Warteschlange und generierte Preisdetails abgeglichen. Echte Auftragsliste erneut gelesen; kein echter Auftrag abgeschlossen oder nachvergütet. Fachliche Details, bewusste PHP-Korrekturen und Betriebsumschaltung im Menüabgleich.
- Abschließender vollständiger `clean verify`: **800 Tests, 797 bestanden, drei optionale Live-Tests übersprungen, keine Fehler** (`work/retour-full-verify-final.log`, `work/retour-test-summary.json`). Frontendbuild erfolgreich; bekannter Bundlegrößenhinweis.
- Neue Tests: ungültige/überlaufende Beträge, Geldrundung, deaktivierter Worker ohne DB-Zugriff, Rechte/HTTP-Sitzung/HQ-Grenze, 59-/60-Minuten-Grenze, Betrag inklusive Service, nachträgliche Preisänderung, Export-/Stornoschutz, angeboten/angenommen/fremde Niederlassung, storniertes und NULL-Stornoflag beim Folgeauftrag, unveränderte Vergütung mit Anschluss, vollständiges Rollback bei PDA-Fehler, einmalige Verarbeitung bei zwei gleichzeitigen Aufrufen, PHP-Marker ohne NG-Beleg, Nullbetrag, Audit 192, Nachricht nur für den jeweiligen Auftrag, Ausführungs-/Ablauffrist, manuelle Preisberichtigung, Neukalkulation und Fortschritt hinter mehr als 50 ungültigen Markern.
- Isolierter Browser: fällige Vergütung 112,00 € inklusive 7,00 € Service gegenüber vorher 146,65 €, Reduktionshinweis, deaktivierter automatischer Lauf, gesperrter Preisstand, abgeschlossener Betrag/Zeitpunkt, nativer BWV-Zuweisungseinstieg und Sperre bei ungespeichertem Entwurf. Keine Schreibrequests. Eine anfangs falsche Datumsserialisierung der Testfixture wurde auf die ISO-Konfiguration der echten API korrigiert; der abschließende Build zeigt keine Konsolenfehler. Nachweise `work/retour-ui-verification.json`, `work/retour-ui-events.json`, `work/bwv-retouren-2026-10-17.png`.
- Reale Datenbank ausschließlich gelesen: 14 Retourenmerkmale in der geprüften Niederlassung; drei reale abgeschlossene Merkmale erfolgreich mit neuer Statusabfrage gelesen. Worker deaktiviert, null DB-Schreibzugriffe und null externe Routingaufrufe (`work/retour-read-probe.log`).
- Port 8080 mit geprüftem Paket neu gestartet: Health UP, DB verbunden, alle sechs Frontenddateien zwischen dist/JAR/HTTP bytegleich (`work/retour-deployment.json`). Automatischer Retourenlauf bleibt aus, bis der PHP-Verbraucher bei der Betriebsumschaltung abgelöst wird. Keine Remote-Konfiguration geändert.
- Gesamtziel weiterhin aktiv; vollständige Kandidatenvermittlung, weitere Geräte-/Abrechnungsabläufe und die übrigen offenen Bereiche bleiben im Menüabgleich ausgewiesen.

## 17. Oktober 2026 – BWV-Vergütungsvergleich und Übernahme

- Aktueller SSH-PHP/JS-Stand, echte Auftragsliste und native Preisvorschau geprüft. Popup-Abgleich über aktuellen Generator, weil bereits dessen Öffnen Bestandsdaten verändert; kein Popup-Schreibtest auf echten Aufträgen.
- Vollständiger `clean verify`: **787 Tests, 784 bestanden, drei optionale Live-Tests übersprungen, keine Fehler** (`work/bwv-full-verify-final.log`, `work/bwv-test-summary.json`). Anschließende reine Tabellenformatierung erneut mit TypeScript/Vite gebaut und paketiert.
- Neue Tests: getrennte Rund-/PZM-Zuschläge, Auswahl/Gleichstand, Retourenformel, KM-/Geldrundung, Erhalt freier Notizen, UTC-/Datums-/Randwertprüfung, fehlende/ungültige Daten, gültige und fehlende Straßenroute, Cache und Heimat-PLZ-Abgleich. SQL-Integration prüft Basis-/Serviceübernahme, Tarif- und Standortkonflikte, Umgehungsschutz, vollständiges Rollback bei Belegfehler, Preisdetails/Retourenmerkmal, identischen Retry ohne Routing, geänderte Vorgangsabsicht, unabhängige Zeitfenster, belegte Auftragsendstation, mehrdeutige Belegung und fehlende Heimatkoordinaten.
- Browserfixture aus echter Java-Kalkulation: Rundkilometer/PZM-Tabelle, Heimat-/Anfahrt-/Rückfahrtwerte, Retourenbetrag samt Hinweis bei höherer Hinfahrt, ungültiger Wunschort mit gesperrtem Speichern und erfolgreicher Testzuweisung. Keine Konsolenfehler. Bild `work/bwv-verguetung-2026-10-17.png`, Ereignisse `work/bwv-ui-events.json`.
- Reale Datenbank ausschließlich gelesen: 41 aktive BWV-Aufträge in der geprüften Niederlassung, 16 gespeicherte Vergütungsgrundlagen insgesamt, Kontextabfrage mit aktuellen Tarifen erfolgreich. Null DB-Schreibzugriffe und null externe Routenaufrufe (`work/bwv-read-probe.log`). Schreib- und Routingtests nutzen ausschließlich lokale Fixtures bzw. simulierte Routen.
- Port 8080 mit geprüftem Paket neu gestartet: Health UP, DB verbunden, sechs Frontenddateien zwischen dist/JAR/HTTP bytegleich (`work/bwv-deployment.json`). Eigener Fixture-Server, Testtab und MariaDB-Testcontainer entfernt.
- Gesamtziel weiterhin aktiv; Grenzen und weitere offene Bereiche sind im Menüabgleich ausdrücklich fortgeschrieben.

## 17. Oktober 2026 – automatische Bewertungsregeln bei Zuweisung

- Aktuelle SSH-Funktion `checkJobForSurvey` und die echte PHP-Bewertungsmaske geprüft; neun Kriterien, Parameter-Fallback, PDA-Merkmal und Protokoll 134 umgesetzt. Details und bewusste Korrekturen der PHP-Datums-/Branchenfehler im Menüabgleich.
- 22 gezielte Regeltests prüfen alle Kriterien, exakte Gruppenzuordnung, Datumsgrenzen, ungültiges Datum, Metakunde und kombinierte Bedingungen. Isolierte Integration prüft echte Kunden-/Firmenverknüpfung, Regeländerung nach Vorschau, Online-/Offline-Unterschied beim angenommenen Kurier, Setzen/Rücksetzen, HQ-Deaktivierung mit globalem Fallback, keine Änderung bei deaktivierter Funktion, keine zweite Historie bei Retry, widersprüchliche Regeln und vollständiges Rollback bei fehlgeschlagener Speicherung.
- Browserfixture zeigt „Bewertung am Fahrergerät anfordern (Regel #99)“ und erfolgreiche Zuweisung. Keine Konsolenfehler, keine echten Aufträge geändert. Nachweise `work/order-survey-ui-verification.json`, `work/bewertung-zuweisung-2026-10-17.png`.
- Reale Datenbank nur gelesen: 44 Kategorie-15-Regeln, Trigger deaktiviert; auch eine rein lesend simulierte Aktivierung ließ sich auswerten (`work/order-survey-read-probe.log`). Keine Konfiguration verändert.
- Vollständiger abschließender `verify`: **766 Tests, 763 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler (`work/order-survey-verify-final.log`, `work/order-survey-test-summary.json`). Frontendbuild erfolgreich, bekannter Bundlegrößenhinweis. Vier ältere FDS-Testfixtures verwenden jetzt den Datenbanktag statt des lokalen Rechnertages; damit sind Vergangenheitsprüfungen auch während der zweistündigen Datumsabweichung zur UTC-Testdatenbank zuverlässig. Die fachlichen Prüfungen wurden beibehalten.
- Port 8080 mit dem geprüften Paket neu gestartet: Health UP, Datenbank verbunden, alle sechs Frontenddateien zwischen dist/JAR/HTTP bytegleich (`work/order-survey-deployment.json`). Eigene Testtabs, Fixture, Testcontainer und SSH-Verbindung geschlossen. Das Gesamtziel bleibt aktiv; weitere Funktionslücken stehen im Menüabgleich.


## 16. Oktober 2026 – direkte Listen-Kurierzuweisung

- Aktuellen SSH-Arbeitsbaum und erreichbare PHP-Oberflächen geprüft; Abgleich und verbleibende Sonderfälle im Menüabgleich.
- Vollständiger `clean verify`: **743 Tests, 740 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler (`work/courier-assignment-verify.log`, `work/courier-assignment-test-summary.json`). Frontendbuild erfolgreich; bekannter Bundlegrößenhinweis. Nachfolgende reine Warnlisten-Formatierung erneut gebaut und paketiert.
- Neue isolierte Integration: Suche mit literalen Wildcards, Rechte/HQ-Grenzen, globale/lokale/fehlende/NULL-Anfahrtszeit, veraltete Vorschau, Unterauftragsschutz, Kundensperre, geänderte bisherige Freimeldezeit, Rollback nach Receiptfehler, identischer Wiederholungsrequest und abweichender Vorgang, Online-Angebot/Offline-Annahme, gleicher Kurier, unveränderte Vergütung, Erhalt anderer Autoranking-Zeilen, Aktualisierung vorhandener Paarzeile und Entfernen temporärer Preiswerte. Karten-Zuweisung weiterhin grün. HTTP prüft Sitzung, CSRF und beide benötigten Rechte.
- Browser mit isolierter Fixture aus echter Java-Vorschau: Einstieg aus Parallel- und Einzelliste, Online-/Offline-Vorschau, optionale Rücksetzung und Bestätigung. Simulierte verlorene Antwort führt zum identischen Wiederholungsrequest: zwei Vorgänge, drei Speicheraufrufe, keine Konsolenfehler. Prüfbild `work/kurierzuweisung-vorschau-2026-10-16.png`, Ereignisse `work/courier-assignment-ui-events.json`.
- Echte Datenbank ausschließlich gelesen: 68 freigegebene Fahrzeuge, Zuweisungsvorschau erfolgreich (`work/courier-assignment-read-probe.log`). Keine echte Disposition oder Bestandsänderung ausgeführt.
- Port 8080 neu gestartet: Health UP, Datenbank verbunden, alle sechs Frontenddateien zwischen dist/JAR/HTTP bytegleich (`work/courier-assignment-deployment.json`). Gesamtziel weiterhin offen.


## 16. Oktober 2026 – Autoranking- und Reservierungs-Sammelaktionen

- Aktueller SSH-Arbeitsbaum und reale PHP-Liste mit A/R-Links geprüft. Auswahlregeln, LKW-Zuordnung und konfigurierter Erhalt/Entfernung der Kurierzuordnung nativ ergänzt; genaue Grenzen im Menüabgleich.
- Isolierte Integration prüft normale/Reservierungsaufträge, Zukunft/Altdatum, Angebote, Ferntouren, LKW-Grenze, Favoriten, fremde Erfassungs- mit eigener Dispositionsniederlassung, ausgeschlossene fremde Niederlassung, Rechnungskunden-Sichtbarkeit, Null-Reservierungsflag und Schutzgründe. Zusätzlich Kandidatenkonflikt, Wiederholung/abweichender Request, Rollback nach zweitem Audit, getrennte Historienbeschreibungen, HQ-/Globalparameter, LKW-Mapping, Ablauf, Rechte und MyISAM-Sperre.
- Browserfixture: A in Parallelliste, R in Einzelliste, Vorschau aller Kandidaten mit Sperrgründen, Erfolgsmeldungen und identischer Wiederholungsrequest nach simulierter verlorener Antwort. Zwei Vorgänge, drei Requests, keine Konsolenfehler. Nachweise `work/ranking-batch-ui-verification.json`, `work/autoranking-vorschau-2026-10-16.png`.
- Reales Schema und Parameter nur gelesen; beide Vorschauen erfolgreich, im geprüften Zeitraum keine Kandidaten (`work/ranking-batch-read-probe.log`). Keine Bestandsänderungen.
- Wiederkehrender lokaler Docker-Verbindungsabbruch im alten Mehrtagesplanungstest führte zur Umstellung auf je Fixture geschlossene Pools. Dadurch aufgedeckter echter Nur-Lesen-Zustandsübertrag bei leeren/Metadatenabfragen behoben: tatsächlicher Transaktionsbeginn verhindert Übernahme in einen späteren Schreibvorgang. Regression auf derselben Verbindung einschließlich Lese-/Schreibabbruch und weiterhin serverseitig verbotenem Schreibversuch in einer Lesetransaktion erfolgreich.

- Abschließender vollständiger `clean verify`: **741 Tests, 738 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler (`work/ranking-batch-verify-final-success.log`, `work/ranking-batch-test-summary.json`). Zwei ältere Mockprüfungen wurden an den ausdrücklich gestarteten Lesevorgang angepasst; weitere SQL-Aktionen vor einer fehlgeschlagenen Engineprüfung bleiben verboten. Frontendbuild erfolgreich, bekannter Bundlegrößenhinweis.
- Port 8080 neu gestartet: Health UP, DB verbunden, alle sechs Frontenddateien zwischen dist/JAR/HTTP bytegleich (`work/ranking-batch-deployment.json`). Eigene PHP-/Prüftabs, Fixture, Testcontainer und SSH geschlossen. Gesamtziel weiterhin offen; automatischer Vermittlungsdienst sowie Kandidaten-/Rankingdetails und weitere offene Menübereiche bleiben gesonderte Aufgaben.

## 16. Oktober 2026 – Listenwarnungen und Unteraufträge

- Aktuelle Server-PHP-Quellen erneut gelesen, tatsächliche alte Liste geöffnet. Warn-/Farbregeln, Etappenprüfung und -fortschritt, Favoritenanzeige sowie status-/vorzeichenabhängige Unterauftragsanzeige ergänzt. Wirkungslose PHP-Schalter anhand ihrer vollständigen Verwendung geklärt; Details im Menüabgleich.
- Vollständiger `verify` (zuvor zusätzlich `clean verify`): **736 Tests, 733 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler (`work/order-appearance-verify-final.log`). Zusätzlicher CSV-Integrationstest erfolgreich. Frontend-Produktionsbuild erfolgreich; bekannter Bundlegrößenhinweis.
- Grenzwerte, Vorbestellungs-/Wartezeitregeln, Angebotsausnahme, separate HQ-Fristen, erledigte erste Station, benachbarte/fehlende/negative Etappenzeiten, Pflichtnummern, Kundenfarben, Preiswarnung, negative Beträge und vollständige Fahrzeugkürzel geprüft. SQL-Tests prüfen Favoriten ohne Duplikate, Unteraufträge mit wechselnden Vorzeichen/Status/Bezugskundenmodus und fehlendem Hauptauftrag sowie mehrdeutige Parameter, GDC-Warnung und Anfahrtszeit.
- Browserfixture: Warnzellen, Kopfzeilenfarbe, lesbarer Weißkontrast auf dunkler Kundenfarbe, Fahrerklammern, zwei erledigte PLZ-Stationen und aufgeklappte Etappenwarnung in Parallelliste geprüft; dieselben Warnungen in Einzelliste bestätigt. Favoritenschalter übermittelt, keine Konsolenfehler. Prüfbild `work/auftragslisten-warnungen-2026-10-16.png`; UI-Nachweis `work/order-appearance-ui-verification.json`.
- Echte Datenbank ausschließlich gelesen: bestehender Auftrag mit persönlicher Spaltenprojektion, Favoriten und Warnmetadaten erfolgreich (`work/order-appearance-read-probe.log`). Keine Bestandsänderungen.

- Port 8080 aktualisiert: Health UP, DB verbunden, alle sechs Frontenddateien zwischen dist/JAR/HTTP bytegleich (`work/order-appearance-deployment.json`). Endgültiger Testnachweis `work/order-appearance-test-summary.json`. Gesamtziel weiterhin offen.

## 16. Oktober 2026 – Spezialfilter der Auftragslisten

- Aktuelle SSH-PHP-Quellen und reale alte Listenoberfläche einschließlich erweitertem Adressbereich/erledigten Aufträgen abgeglichen. Neue Kriterien für Einzel-/Parallellisten, siehe Menüabgleich. SQL vor Trefferzählung und Seiteneinteilung, identischer Export, eigene Rücksetzung pro Liste.
- Vollständiger `verify`: **729 Tests, 726 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler. Frontend-Produktionsbuild erfolgreich. Vorherige Läufe trafen einen lokalen Docker-Verbindungsabbruch im bestehenden Mehrtagesplanungstest. Dort wird nun der identische Zielrasterbestand einmal gesammelt gelesen, statt je Zeitzelle eine neue Verbindung aufzubauen; alle einzelnen Rasterwerte werden weiterhin geprüft. Danach vollständiger Lauf grün (`work/order-filters-verify-batched.log`).
- Isolierte SQL-Tests prüfen: gemeinsame Station statt verteilten Treffern, Länderausschluss/D-Normalisierung, Rechnungskunde gegenüber Barzahler, Fahrerkennung in Unteraufträgen ohne Duplikate, Benutzernummer statt Mitarbeiternummer, Text-Wildcards als Literal, alle Preis-/Statusflags, Angebots-/Bereichsfilter, Pflicht-/Wunschkürzel, Leistung/Bezugsgruppe, versteckte Aufträge, Zukunfts-/Nummern-/Datumsregeln, 105 gefilterte Datensätze und zweite Seite, Exportgrenze sowie Rechte/Session/ungültige Filter.
- Browserfixture: unabhängige Kriterien für zwei Parallellisten, kombinierte Anforderungen, Länderausschluss samt automatischer Entfernung, Einzelansicht, Rücksetzung und identische CSV-Kriterien geprüft. Bei Sichtprüfung gefundene Breitenabweichung korrigiert; Filter umbrechen und nutzen die verfügbare Breite. Keine Konsolenfehler, nur GET-Anfragen. Nachweise `work/order-filters-ui-verification.json`, `work/auftragslisten-spezialfilter-2026-10-16.png`.
- Echten Bestand ausschließlich gelesen: Auswahllisten und kombinierte Listenabfrage erfolgreich, keine fachlichen Änderungen (`work/order-filters-read-probe.log`). Port 8080 neu gestartet: Health UP, DB verbunden, alle sechs Frontenddateien zwischen dist/JAR/HTTP bytegleich (`work/order-filters-deployment.json`). Eigene Prüftabs, Fixture, Testcontainer und SSH geschlossen; Nutzertabs erhalten. Gesamtziel weiterhin offen.

## 16. Oktober 2026 – Direkte Stationssortierung

- Aktuellen SSH-PHP-Arbeitsstand und die angemeldete Sortieroberfläche abgeglichen. Eigener nativer Sortierdialog aus Liste und Auftragsbearbeitung, Stationskarten, Pfeile/Ziehgriff, Routenvorschau und Optimierung mit festen Endpunkten ergänzt. Fachliche Zuordnungen und Schutzbedingungen im Menüabgleich beschrieben.
- Vollständiger `clean verify` gegen isolierte MariaDB: **726 Tests, 723 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler. Nach anschließender reiner Frontend-Anpassung des Ziehgriffs erneuter erfolgreicher Produktionsbuild und Paketbau. Bekannter Hinweis zur Bundlegröße bleibt.
- Isolierte SQL-Prüfung: Stations-ID und Reihenfolge in Tour, Artikel, Kalkulation, Servicepreis und Einnahmen; unveränderte Mengen/Beträge/Scans/Unterschriften; Reihenfolgetausch ohne Überschreiben, gemeinsame Geräteaktualisierung und Audit, Wiederholung, abweichende Vorgangskennung, Revision, Rollback nach spätem Fehler, fehlende Adresse, ungültige/mehrdeutige Stationen, Rechte/Niederlassung sowie Auftragssperren und exportierte Einnahmen. MyISAM verhindert den Schreibbeginn. Optimierung bleibt ungespeichert und wird nach zwischenzeitlicher Auftragsänderung zurückgewiesen. Session und CSRF geprüft.
- Browserfixture: Pfeile und Ziehgriff, Speicherung mit absichtlich fehlender 503-Bestätigung und identischer Wiederholung, Optimierung als Entwurf, eingebettete Karte, 409-Konflikt und Neuladen nach explizitem Verwerfen geprüft. Abschließend per Ziehgriff geänderte Reihenfolge erfolgreich gespeichert; frisches Prüffenster ohne Konsolenfehler. Prüfbild `work/stationssortierung-2026-10-16.png`, Ereignisse `work/station-sort-ui-events.json`, Prüfergebnis `work/station-sort-ui-verification.json`.
- Echte Datenbank ausschließlich gelesen: Sortieransicht eines Bestandsauftrags und sechs betroffene Fachtabellen erfolgreich geprüft; alle sechs InnoDB. Keine fachlichen Bestandsänderungen. Nachweise `work/station-sort-read.log`, `work/station-sort-verify.log`.
- Port 8080 aktualisiert: Health UP, Datenbank verbunden, sechs Frontenddateien zwischen Build/JAR/HTTP bytegleich (`work/station-sort-deployment.json`). Eigene Prüftabs, Fixture, Testdatenbank und SSH geschlossen; Nutzertabs erhalten. `git diff --check` ohne Fehler. Gesamtziel weiterhin offen.

## 16. Oktober 2026 – Persönliche Auftragslistenspalten

- Aktuelle SSH-PHP-Quellen und tatsächliche Mitarbeitereinstellungen abgeglichen. 64 Spalten, Pflege, Auswertung in Einzel-/Mehrfachliste, SQL-Sortierung, CSV und native Direktaktionen ergänzt. Grenzen im Menüabgleich ausdrücklich aufgeführt.
- Vollständiger `clean verify` gegen isolierte MariaDB: **724 Tests, 721 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler. Zusätzliche gezielte Integrationsprüfung deckt 104 Treffer, zweite Seite, Rechnungskunde, erste/zweite Station, Brutto/Maut/BSG, KM/CO₂/TSZ, Zeitberechnung, Boolean-Favorit, Rechte, Konflikt/Rollback/Replay, Quellen-Duplikate, Exportgrenze und Tabellenformelschutz ab.
- Browserfixture: Spalten umgeordnet; erste Speicherung liefert absichtlich 503, Wiederholung hat identische Vorgangskennung und Nutzlast. Weiterer Speicherversuch liefert 409; explizites Verwerfen/Neuladen übernimmt den aktuellen Stand. Dieselbe Reihenfolge in beiden Listenansichten, Preis-Sortierung vor/nach Richtungwechsel, CSV mit aktueller Belegung und native Bearbeitung geprüft. Screenshot `work/auftragslistenspalten-2026-10-16.png`, Ereignisse `work/order-columns-ui-events.json`.
- Echte Datenbank nur gelesen: alle 64 SQL-Projektionen und konfigurierte persönliche Liste erfolgreich; keine fachlichen Schreibzugriffe. Nachweise `work/order-columns-read.log`, `work/order-columns-verify.log`, `work/order-columns-ui-build.log`.
- Aktualisierte Anwendung auf Port 8080: Health UP, Datenbank verbunden, alle sechs Frontenddateien zwischen Build/JAR/HTTP bytegleich. Finale Browseransicht ohne Konsolenfehler; eigenes Prüffenster und isolierte Dienste geschlossen. Prüfbild der Pflege: `work/auftragslistenspalten-editor-2026-10-16.png`. Gesamtziel weiterhin offen.

## 16. Oktober 2026 – Gemeinsame Stammdatendokumente

- Frischen SSH-PHP-Stand und angemeldete Dateitransferoberfläche abgeglichen. Neue native Dateiablage für Kunden, Transporteure und Fahrzeuge: Upload, Download, Ersetzen, Entfernen, Wiederherstellen, Unterordner und offene Vorgänge. Umfang und verbleibende Transfer-/Objektgrenzen im Menüabgleich.
- `clean verify` mit isolierter MariaDB: **723 Tests, 720 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler. Frontend-Produktionsbuild erfolgreich; bekannter Hinweis zur Bundlegröße.
- Schreibprüfungen ausschließlich mit lokaler temporärer Dateiablage und wegwerfbarer Datenbank. Getrennte Rechte, Niederlassungen, doppelte EID/Mandantenpfade, Dateigrößen/-typen, Namens-/Pfadschutz, Symlinks, Mengenbegrenzung, Administratorausnahme, Umbenennung/HQ-Unterpfad, alle drei Objekttypen, Zähler und Audit geprüft. Inhaltlich geänderte Datei bei gleicher Größe/Zeit ergibt Konflikt. Wiederholung mit anderem Inhalt wird abgewiesen.
- Gezielte Fehler: abgeschlossener Dateischreibvorgang ohne SQL-Abschlussbeleg, abgeschnittene Stagingdatei und erfolgreiches Hardlink mit fehlgeschlagenem Unlink. Wiederaufnahme erfolgreich. Große Nutzlast über mehrere 50.000-Zeichen-Blöcke gegen tatsächlichen Spaltentyp TEXT geprüft; Teile werden nach Abschluss entfernt. MyISAM für das Journal verhindert den Schreibbeginn. HTTP-Session und CSRF geprüft.
- Browserfixture: Upload mit unterbrochener 503-Bestätigung, identischer Wiederholung, Entfernen, Wiederherstellen und Download samt Inhaltsprüfung. Entfernen hat eigenen React-Dialog „Entfernen/Abbrechen“. Finale Oberfläche ohne Konsolenfehler. Prüfbild `work/stammdaten-dokumente-2026-10-16.png`, Prüfnotiz `work/documents-ui-verification.json`.
- Echte Dokumentablage und Datenbank ausschließlich gelesen: SFTP-Verbindung mit geprüften SSH-Hostschlüsseln, unterstützte Hardlink-Erweiterung, Mandanten-/Typverzeichnisse für Kunden/Transporteure/Fahrzeuge und TEXT-Spalte bestätigt. Keine fachlichen Bestandsänderungen. `.env` enthält die konfigurierte gemeinsame Ablage und bleibt ignoriert; keine Zugangsdaten im Quellcode.
- Port 8080 aktualisiert: Health UP, Datenbank verbunden, alle sechs Frontenddateien zwischen Build/JAR/HTTP identisch. Eigene Prüftabs, Fixture, isolierte MariaDB und SSH geschlossen; Nutzertabs erhalten. `git diff --check` erfolgreich. Gesamtziel weiterhin offen.

## 16. Oktober 2026 – Erweiterte Verzeichnissuche und CSV

- Aktuelle SSH-PHP-Listen und tatsächliche PHP-Erweiterungsoberfläche erneut abgeglichen. Neue Status-/Parameter-/Adress-/Fahrzeug-/Niederlassungsfilter und frei konfigurierbarer vollständiger Listenexport. Details und verbleibende Grenzen im Menüabgleich.
- `clean verify` mit isolierter MariaDB: **719 Tests, 716 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler. Frontend-Produktionsbuild erfolgreich; danach nur Korrektur des UI-Fehlerzustands und verständliche Export-Beschriftungen, erneut gebaut und paketiert.
- SQL-Prüfungen: kombinierte Merkmale und Adressen, Parameterduplikate ohne doppelte Treffer, Nullwert 0, Mindestmaße, Zulassungsmonat, VPA/Anforderungen, Mandanten-/Niederlassungsrechte, interne Firmen nur für Administrator, Export aller 105 Treffer unabhängig von Seite, Quote-/Formelschutz und getrennte Exportrechte mit Session/CSRF.
- Browserfixture: kombinierte Suchkriterien im Request bestätigt, Exportspalten umgeordnet und Trennzeichen geändert, Download bestätigt. Ungültige Ladedauer liefert Fehler, Filter bleiben editierbar; Korrektur auf 0 führt erfolgreich zur Ergebnisliste.
- Laufzeit auf Port 8080 aktualisiert: Health UP, Datenbank verbunden; alle sechs Frontenddateien zwischen Build, JAR und HTTP bytegleich. Eigene Browserprüftabs/Fixture geschlossen, isolierte MariaDB entfernt und SSH beendet; Nutzertabs unverändert.
- Echter Bestand nur lesend: 54 Kunden- und drei Transporteurschalter in kombinierten Abfragen über neun erlaubte Niederlassungen sowie normale Verzeichnisse geprüft; **keine Bestandsänderungen**. Logs `work/master-search-*`, Bilder `work/kundensuche-2026-10-16.png` und `work/kundenexport-2026-10-16.png`.


## 16. Oktober 2026 – Persönliche Kunden-/Transporteurslisten

- Aktuelle PHP-Quellen ausschließlich per SSH unter `/data/0/votian-test/html` gelesen; Kunden-/Transporteurslisten im angemeldeten Browser geprüft.
- Neue persönliche Spalteneditoren, SQL-Verzeichnisse, Zahler-/Stammdaten-/Berichts-/Dauerauftragsnavigation und native Stammdatenhistorie ergänzt. Grenzen stehen im Menüabgleich.
- `npm run build`: erfolgreich. `CRM_INTEGRATION_URL=jdbc:mariadb://127.0.0.1:33079/crm_qa ./mvnw -q clean verify`: 718 Tests, null Fehler/Fehlschläge, drei optionale Live-Tests übersprungen.
- Isolierte MariaDB: Änderung/Rollback/Replay/Konflikt, unangetastete Längen-/Fremdparameter, Fremdniederlassung, 105 Kunden, serverseitige Seiten/Filter, Transporteur mit zwei Fahrzeugen, Classic-SID, Archivzugriffskontrolle und geheimnisfreie Historie.
- Browserfixture: zweite Seite, kombinierte Filter, Kostenstellen-/Fahrzeugeditor, Zahlerübernahme, Berichte/Daueraufträge mit Kunden-ID, 503 identisch wiederholt, 409 mit explizitem Verwerfen/Neuladen, übernommene Reihenfolge.
- Echte Datenbank: Spalten, Kunden-/Transporteurslisten und aktuelle Historie ausschließlich gelesen; keine Teständerungen. Lokale Anwendung mit neuem JAR auf Port 8080 gestartet, Health UP und Datenbankverbindung bestätigt; alle sechs Frontend-Dateien stimmen zwischen Build, JAR und HTTP bytegenau überein.
- Nachweise: `work/kundenspalten-2026-10-16.png`, `work/kundenverzeichnis-2026-10-16.png`, `work/transporteursverzeichnis-2026-10-16.png`; technische Logs unter `work/master-*`.

## Kostenstellenspalten und Erfassungsauswahl – 16. Oktober 2026

- Aktueller SSH-Arbeitsstand **`2eb7f98`**, `admin/employee.php`, `admin/cs_csc_list.php`, `include/dbglobal.inc.php`; angemeldete PHP-Kostenstellenauswahl gelesen. Keine alten lokalen PHP-Quellen.
- `clean verify` gegen isolierte MariaDB 11.4: **712 Tests, 709 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler (`work/columns-verify.log`). Frontend-Produktionsbuild erfolgreich; bekannter Hinweis zur Bundlegröße. Anschließend nur die Darstellung der Tabellenaktionsknöpfe angepasst und Frontend/Anwendung erneut gebaut.
- SQL/Unit: 21er-Grenze, erlaubte Felder und Längen, positionsgenaue Parameter, Heimat-/Globalfallback, unveränderte übrige Parameter, Wiederholung/abweichende Wiederholung, Konflikt, atomarer Rollback, eigene Pflege ohne Mitarbeiterrecht, fremde Mitarbeiter-/Mandantengrenze, doppelte/falsch zugeordnete Parameter, Historie und MyISAM-Schreibsperre. Suchfilter vor LIMIT, 60 gültige Zahler auf zwei Seiten, externe/gesperrte/unsichtbare/fremde Kostenstellen, fehlende Adresse, Telefon/Ort kombiniert sowie wörtliche `%`, `_` und `!`. Session-/CSRF-/Erfassungsrecht und SQL-Bezeichner-Whitelist geprüft.
- Browser mit synthetischen Daten: zweite Seite, Telefonfilter, Statistik mit K100/Niederlassung 7 und Vorjahresbeginn, Berichte mit Kunden-ID 1/Niederlassung 7; Reihenfolge ändern, Länge, zusätzliche Straße, Speichern. Simulierte 503-Speicherantwort mit identischer Wiederholung, 409-Konflikt und bestätigtes Verwerfen/Neuladen. Vier PUTs, erste zwei inhaltlich identisch. Neue Spalten anschließend in derselben Auswahl wirksam; Kostenstelle 055 in die Erfassung übernommen. Keine Konsolenwarnungen/-fehler.
- Prüfbilder: `work/kostenstellenspalten-2026-10-16.png`, `work/kostenstellenauswahl-2026-10-16.png`; Ereignisse `work/cost-center-columns-ui-events.json`. Echter Bestand ausschließlich gelesen: persönliche Konfiguration eindeutig/speicherfähig und neue Suche lesbar (`work/ColumnsReadProbe.java`), **null Bestands-Schreibzugriffe**.
- Anwendung auf Port 8080 aktualisiert: Health `UP`, Datenbank verbunden, alle sechs Frontenddateien in Build/JAR/HTTP identisch. Eigene Prüftabs und Fixture geschlossen, isolierte Datenbank entfernt, SSH beendet. Nutzertabs erhalten; `git diff --check` erfolgreich.
- Weiter offen: Kunden-/Transporteur-/Auftragsspalten und die ausdrücklich beschriebenen Such-Sonderfälle; dies schließt die Gesamtmigration nicht ab.

## Parallele Auftragslisten und Startstatus – 16. Oktober 2026

- Frischer SSH-Arbeitsstand **`2eb7f98`**, relevante Dateien bis zum Abschluss unverändert. SHA256: `admin/employee.php` `4c90cdf4e63b0861dc7780cb6fd3184f8c3b21667ba90a6e6c706c8a75037bce`, `admin/jb_list.php` `db040a7b070773da74dfbbdf3e46f3ecc55564f516f34f81dd880826221e80fc`, `admin/jb_list_fs.php` `e58e7e07a5b0ae820cf2463302377d6043e35edae95630d07c2b4826e5035a61`, `include/dbglobal.inc.php` `5977c0c1a9c25b8a6d28957cedeec117479fb4d0b7d70353040e30721a566b87`. Persönliche PHP-Auswahl und tatsächliche drei Listenframes (33/33/33) gelesen; dort nichts gespeichert.
- Gesamtprüfung `clean verify` gegen isolierte MariaDB 11.4: **708 Tests, 705 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler (`work/parallel-lists-verify.log`). Frontend-Produktionsbuild erfolgreich. Anschließende reine UI-Bereinigung entfernt eine doppelte Statusbeschriftung und den für Mehrfachlisten nicht aussagekräftigen bisherigen Einzelzähler; Frontend erneut gebaut, Paket aktualisiert und UI erneut geladen. Bekannte Bundlegrößen-/Testagent-Hinweise bleiben ohne Fehler.
- SQL/Unit: zwei Bestandsparameter, alle vier Startstatus, Rückfall auf Heimat-/allgemeine Vorgaben, gültige Listenanzahl, unbekannter/widersprüchlicher Status abgewiesen, Maximalzahl, eindeutige Mandantenzuordnung, aktuelle Rechte, fremde Niederlassung, Duplikate, Revision, Rollback bei Belegfehler, identische Wiederholung und geänderter Wiederholungsinhalt. Bestehende acht Listen-/Erfassungsparameter bleiben unverändert. MyISAM-Schreibsperre, Mitarbeiterhistorie mit typisierten Werten und HTTP-Anmeldung/CSRF geprüft.
- SQL-Listenbestand: Status 0/1/2/8/9 getrennt, Status 10 ohne Statusfilter; stornierter erledigter Auftrag erhalten, fremde Niederlassung ausgeschlossen, 201 angenommene Aufträge mit getrennten Seiten und korrekter Gesamtzahl, persönliche Fahrzeuggrenze und Transporteurbemerkungen, Nummernsuche übersteuert den Zeitraum.
- Browser mit synthetischer lokaler Fixture: Liste 2 auf Seite 2 (101–200 von 201), während Liste 1 leer gesucht und Liste 3 auf Status 9 geändert wurde. Aktualisierung nur in Liste 2 abgeschaltet und nach Reload erhalten. Höhenanteil geändert, Von-Nummer nach Bis-Nummer übernommen, CSV oberhalb des Limits abgewiesen, gefilterter CSV und native Auftragsdetails geöffnet. Vier Startlisten gespeichert, verlorene Bestätigung 503 mit gesperrten Eingaben und identischer Wiederholung; anschließend 409-Konflikt, Verwerfen/Neuladen und drei Listen mit erhaltener vierter Statusauswahl gespeichert. Vier PUTs, erste zwei Bodies identisch (`work/parallel-lists-ui-events.json`). Keine Konsolenwarnungen/-fehler.
- Prüfbilder: `work/mehrfachlisten-parameter-2026-10-16.png`, `work/parallele-auftragslisten-2026-10-16.png`. Die Fixture verwendet SQL-erzeugte synthetische Aufträge, ergänzt um synthetische Stations-/Anzeigetexte. Echter Bestand ausschließlich gelesen: persönliche Konfiguration lesbar/eindeutig und Statusabfrage korrekt (`work/ParallelListsReadProbe.java`), **null Bestands-Schreibzugriffe**.
- Anwendung auf Port 8080 neu gestartet: Health `UP`, Datenbank verbunden und alle sechs Frontenddateien in Build/JAR/HTTP bytegleich. Persönliche Spaltenlayouts und weitere im Menüabgleich benannte Fachprozesse bleiben offen.
- Eigene Prüftabs und Fixture geschlossen, isolierte Datenbank entfernt, SSH beendet; Nutzertabs erhalten. `git diff --check` erfolgreich.

## Persönliche Kopier- und Nacherfassungsmodi – 16. Oktober 2026

- Frischer SSH-Arbeitsstand **`2eb7f98`**, einschließlich uncommittierter Änderungen in `jobs/get_saved_tour.php`. Relevante Dateien zum Abschluss unverändert. SHA256: `jobs/job_options.php` `bfc6d2a725092142d36dfb93dd8ea9ae71408961c8abe5f77f82ab1e87bd9e80`, `jobs/job_edit.68.20.js` `845b163033d275911b6f237e63d1313c609ab42d5ac578bd718dd5707f841aba`, `jobs/get_saved_tour.php` `9d4bd9f4806fa861da09918b922e2a1fc8bc0677affa5a473ec7f1698a3c8cdb`, `admin/employee.php` `4c90cdf4e63b0861dc7780cb6fd3184f8c3b21667ba90a6e6c706c8a75037bce`. Beide Disposition/Buchhaltung-Auswahlfelder im angemeldeten PHP-Parameterdialog gelesen; keine Änderungen dort.
- Abschließendes `clean verify` gegen isolierte MariaDB 11.4 erfolgreich: **704 Tests, 701 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler (`work/entry-modes-verify.log`). Frontend-Produktionsbuild erfolgreich; bekannter Hinweis zur Bundlegröße bleibt. Die bisherigen Erfassungsprüfungen zu Datum, Fahrzeug, Abschlussstatus, Preis und Speicherung laufen weiterhin erfolgreich.
- SQL/Unit: fehlende und ungültige Vorgaben, doppelte Schlüssel, Erfassungsrecht, persönliche Originalniederlassung bei fremder Erfassungsniederlassung, alle Moduskombinationen, Übersteuerung, Kopierdatum, aktuell freigegebenes Fahrzeug, vorgesehener Unternehmer bei noch nicht angenommenem Auftrag und gesperrter Unternehmer. Die bestehenden atomaren Parameterprüfungen testen jetzt acht Schlüssel einschließlich beider neuer Historienwerte; wiederholbare Speicherung, Revision, Rollback, Rechte und Mandant bleiben geprüft. HTTP-Optionen und nicht berechtigter Kopieraufruf mit `dispatch=true` ebenfalls geprüft.
- Browser mit synthetischer lokaler Fixture: neue Buchhaltungserfassung mit leerem Datum; Kopie mit Datum/Fahrzeug; Moduswechsel abgebrochen und bestätigt; Dispositionskopie ohne beides; explizite Nacherfassung mit aktueller Minute; nicht mehr verfügbares Fahrzeug mit sichtbarer Warnung. Der Hinweis wurde während der Prüfung aus dem automatisch geschlossenen Kopierbereich herausgezogen, damit er nach dem Laden sichtbar bleibt. Anschließend neue Preisvorschau und genau eine synthetische Auftragsspeicherung mit Nacherfassungsmodus, Zeitpunkt und Fahrzeug. Kein echter Auftrag wurde angelegt.
- Unabhängige Pflege: nur Nacherfassungsmodus auf Disposition geändert, Kopiermodus bleibt Buchhaltung. Simulierte verlorene Speicherbestätigung 503, gesperrte Eingaben und erfolgreiche identische Wiederholung; zwei PUT-Bodies byteinhaltlich gleich. Nächste neue Erfassung startet als Sofortauftrag, Kopie weiterhin als Nacherfassung. Keine Konsolenwarnungen/-fehler. Anfragen: `work/entry-modes-ui-events.json`; Prüfbilder: `work/erfassungsmodi-parameter-2026-10-16.png`, `work/buchhaltungskopie-2026-10-16.png`.
- Echter Bestand ausschließlich gelesen: persönliche Modi, Erfassungsoptionen und Parameterpflegeansicht lesbar (`work/EntryModesReadProbe.java`), **null Bestands-Schreibzugriffe**. Anwendung auf Port 8080 neu gestartet: Health `UP`, Datenbank verbunden, alle sechs Frontenddateien in Build/JAR/HTTP bytegleich. Persönliche Listenspalten, parallele Listen und Sprache bleiben offen.
- Eigene Prüftabs und Fixture geschlossen, isolierte Testdatenbank entfernt, SSH beendet. Beide Nutzertabs erhalten; `git diff --check` erfolgreich.

## Persönliche Listenparameter und Auftragsfilter – 16. Oktober 2026

- Frischer SSH-Stand **`2eb7f98`**, relevante Dateien während der Prüfung unverändert. SHA256: `admin/employee.php` `4c90cdf4e63b0861dc7780cb6fd3184f8c3b21667ba90a6e6c706c8a75037bce`, `admin/jb_list.php` `db040a7b070773da74dfbbdf3e46f3ecc55564f516f34f81dd880826221e80fc`, `include/dbglobal.inc.php` `5977c0c1a9c25b8a6d28957cedeec117479fb4d0b7d70353040e30721a566b87`. PHP-Parameterdialog einschließlich sechs Auswahlmöglichkeiten gelesen; dort keine Daten geändert.
- Abschließendes `clean verify` gegen isolierte MariaDB 11.4 erfolgreich: **700 Tests, 697 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler (`work/list-preferences-verify.log`). Frontend-Produktionsbuild erfolgreich. Ein Vorlauf deckte eine zeitabhängige Assertion im bestehenden Mitarbeitertest auf: Der Test verglich `usr_modify` mit einem Stand vor seiner eigenen simulierten Paralleländerung. Die vollständige Zeilenprüfung erfasst den Ausgangszustand jetzt nach dieser Simulation; gezielter Wiederholungstest und Gesamtprüfung bestehen.
- SQL: sechs Schlüssel, identische Wiederholung und abweichender Tokeninhalt, atomarer Rollback bei Belegfehler, Revision, aktuelle Rechte, Administrator-/Mandanten-/Niederlassungsgrenzen, eigene Pflege ohne Mitarbeiterrecht, doppelte Parameter, ungültiger Fahrzeugkatalog, Rückfall auf Heimatniederlassung und MyISAM-Schreibsperre. Historie 203 vor/nach Veröffentlichung ohne Duplikate. Synthetischer Bestand mit mehr als zwei Seiten: Filter vor LIMIT, überschneidungsfreie Seiten, Fahrzeugübersteuerung, Nummernbereich trotz anderem Datum und Transporteurbemerkungen samt Lese-Rechtegrenze. HTTP-Anmeldung/CSRF und Architekturregeln geprüft.
- Browser: 100/205 Einträge und zweite Seite; Umstellung auf 200 mit sofort neu berechneter Seitenanzahl. Speicherbestätigung 503 mit gesperrten Eingaben und identischer Wiederholung, anschließender 409-Konflikt mit Verwerfen/Neuladen. Von-Nummer 105 automatisch als Bis-Nummer, ein passender Auftrag, Unterwegs mit beiden Transporteurbemerkungen und aktivierter Aktualisierung. Drei PUT-Anfragen, davon die ersten beiden identisch (`work/list-preferences-ui-events.json`). Eine anfänglich falsch als Array serialisierte Zeit in der synthetischen Fixture wurde auf ISO korrigiert; der echte Spring-Endpunkt verwendet bereits ISO. Danach kein weiterer Laufzeitfehler während der geprüften Abläufe.
- Prüfbilder: `work/listenparameter-2026-10-16.png`, `work/persoenliche-auftragsliste-2026-10-16.png`. Echter Bestand ausschließlich gelesen: Parameteransicht eindeutig und speicherfähig; persönliche Auftragsabfrage lesbar (`work/ListPreferencesReadProbe.java`), **null Bestands-Schreibzugriffe**. Keine Kontendetails oder Geheimnisse ausgegeben.
- Anwendung nach erfolgreicher Gesamtprüfung auf Port 8080 neu gestartet: Health `UP`, Datenbank verbunden und alle sechs Frontenddateien in Build/JAR/HTTP bytegleich. Spaltenkonfigurationen, Mehrfachlisten und Kopier-/Nacherfassungsmodi bleiben ausdrücklich offen; nächste Referenzen dafür bereits im frischen PHP-Stand identifiziert.


- Eigene Prüftabs und Fixture geschlossen, isolierte Testdatenbank entfernt, SSH beendet. Nutzertabs erhalten; `git diff --check` erfolgreich.

## Globale PDA-Ortung und Mitarbeiter-Niederlassungen – 16. Oktober 2026

- Aktueller SSH-Arbeitsstand **`2eb7f98`**; die drei verwendeten Dateien gegenüber Start `d7530c0` unverändert. SHA256: `admin/employee.php` `4c90cdf4e63b0861dc7780cb6fd3184f8c3b21667ba90a6e6c706c8a75037bce`, `admin/employee_list.php` `09bfbd1a245d08cb47533d5082e1275a8de1d944d53bbb9212e1c06d4da32451`, `include/inc_autoranking.inc.php` `7097d6237436df27e84c84b062cbcd87f89fe40e4ade1ee4b41645c5245e8c24`. PHP-Checkboxauswahl und realer Mitarbeiter-Parameterdialog gelesen; keine Änderungen gespeichert.
- `clean verify` gegen isolierte MariaDB 11.4 erfolgreich: **694 Tests, 691 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler (`work/pda-settings-verify.log`). Frontend-Produktionsbuild erfolgreich; bekannter Hinweis zur Bundlegröße bleibt.
- SQL: beide Parameter atomar, Wiederholung mit gleichem Token, Token mit anderen Daten abgewiesen, Audit 194, Rollback bei Belegfehler, Änderung durch anderen Bearbeiter, aktueller Rechteentzug, Pflege mit Recht 9 ohne Recht 3, eigene/fremde Mitarbeiterparameter, Mandantenkonflikte, doppelte Parameter, ungültiger Bestand korrigierbar und MyISAM-Schreibsperre. Niederlassungs-Teilmenge, Alle, leere Auswahl, fremde/unbekannte IDs und doppelte Werte geprüft. HTTP-Bindung von CSV- und leerer Auswahl geprüft.
- Browser mit synthetischer lokaler Fixture: gemeinsame Auswahl B/HH, leere Auswahl fällt auf B zurück; Uhrzeiteingabe per Tastatur, 503 nach gespeichertem Vorgang mit identischer Wiederholung, 409-Konflikt, Verwerfen-Dialog, Reload und erneutes Speichern. Vier Schreibversuche für drei Vorgänge; erster und zweiter Body identisch. Keine Konsolenwarnungen/-fehler. Prüfbild `work/pda-ortung-2026-10-16.png`, Anfragen `work/pda-settings-ui-events.json`.
- Echter Bestand nur gelesen: Ortungskonfiguration eindeutig/gültig und freigegebene Mitarbeiter-Teilmenge lesbar (`work/PdaSettingsReadProbe.java`). Keine persönlichen Daten oder Geheimnisse ausgegeben, keine Bestandswerte oder Schemas geändert. Anwendung nach Gesamtprüfung auf Port 8080 neu gestartet: Health `UP`, Datenbank verbunden und alle sechs Frontenddateien in Build/JAR/HTTP bytegleich. Eigene Prüftabs und Fixture geschlossen, isolierte Testdatenbank entfernt, SSH beendet. `git diff --check` erfolgreich.


## Mitarbeiterhistorie – 16. Oktober 2026

- Aktuellen SSH-Arbeitsbaum berücksichtigt; HEAD bei Abschluss **`47ec87d`**. Der zuletzt hinzugekommene Commit ändert keine der hier verwendeten Konto-/Historienseiten gegenüber `090d3d5`. Die uncommittierten Änderungen in `inc_history.inc.php` wurden mitgelesen; sie betreffen den Auftragshistorienparser. SHA256: `admin/history.php` `4eb5246f9e4f2b79cc9591054474f2d01cd934c60d9be54893fcc8fb0d31c28e`, `include/inc_history.inc.php` `d46d900ced72a9202d6f9d466a4e3d76d4bce56d23a71cfd95a641730f0ffe51`, `admin/employee_rights.php` `ee09cc8204fb335641cdcf39de36cf68afdeaa0233f10320f8146031f242670f`. Aktuelle PHP-Mitarbeiterliste und Historienseite im Browser gelesen; keine Bestandsänderung.
- Abschließendes `clean verify` gegen wegwerfbare MariaDB 11.4: **688 Tests, 685 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler. Frontend-Produktionsbuild erfolgreich. Im ersten Gesamtvorlauf wurde der neue Testhelfer von der vorhandenen Architekturprüfung wegen eines direkten JDBC-Typs abgewiesen; die Schema-Fixture läuft jetzt ausschließlich über den erlaubten Testaufbau in `DatabaseServiceTest`. Architekturprüfung unverändert und erfolgreich.
- Unit: historische Passwort-Hashes und unbekannte interne Felder werden nicht ausgegeben; PHP-Statusformate, Unicode/Pipe/Gleichheitszeichen in strukturierten Profilen, Rechte/Niederlassungen, beide Matrixformate, ältere Outbox-Nachrichten ohne Mitarbeiterfeld und exakte Zuordnung statt ID-Präfixverwechslung.
- SQL: Tagesgrenzen, neueste Reihenfolge, Archiv mit gelöschtem handelnden Benutzer, leeres Ergebnis, ungültiger/fehlender Bestand, 2500er-Grenze, Mandant/Portalzugang, aktuelles und sitzungsseitiges Recht 32, Administratorschutz, MyISAM nur lesend im GET, sofort sichtbare ausstehende Ereignisse, Veröffentlichung mit echter Ziel-emp_id, alte Nachrichten, wiederholte Veröffentlichung und Abbruch nach MyISAM-Insert. Bereits geschriebenes, noch nicht quittiertes Ereignis erscheint einmalig. Fehlende Protokolltabelle liefert verständlichen 503-Fehler. HTTP-Anmeldung und Mitarbeiterrecht ebenfalls geprüft.
- Live-Bestand nur gelesen: Historienservice und Vorgangskatalog funktionieren. `log` und `logoperation` sind MyISAM; keine `loghistory*`-Tabellen vorhanden. Vorgang 184 ist tatsächlich Kategorie `2fa` und wird ausdrücklich zusätzlich zu `emp` berücksichtigt. Keine historischen Hashwerte, Konten oder Personendetails in der Probe ausgegeben.
- Browser mit synthetischer SQL-Fixture: Einstieg aus Mitarbeiterliste, 503 und erfolgreicher neuer Abruf, sieben Ereignisse mit sicheren Details, leere Archivabfrage, Archivwechsel auf 2020 mit korrektem Tagesfilter und Benutzer-ID bei gelöschtem Handelnden. Keine Konsolenwarnungen/-fehler. Prüfbild `work/mitarbeiterhistorie-2026-10-16.png`; ausschließlich GET-Anfragen in `work/employee-history-ui-events.json`.
- Geprüfte Anwendung auf Port 8080 neu gestartet: Health `UP`, Datenbank verbunden und alle sechs Frontenddateien in Build/JAR/HTTP bytegleich. Eigene Prüftabs und Fixture geschlossen, isolierte Testdatenbank entfernt, SSH beendet; Nutzertabs erhalten. `git diff --check` erfolgreich.

## Mein Konto und Zwei-Faktor-Einrichtung – 16. Oktober 2026

- Aktueller SSH-Arbeitsstand **`090d3d5`**; PHP-Startseite im angemeldeten Browser gelesen und Einrichtungs-Markup mit synthetischen Daten isoliert gerendert. Der echte PHP-Einrichtungs-GET wurde wegen seines sofortigen Secret-Schreibzugriffs nicht aufgerufen. SHA256: `GA_generateBarcode.php` `fd3f8684cd36a550315b4457dce5661edbf15fb535a4770a679ffe86872e6c5d`, `start.php` `a99041a0d1e2139da36af9474d877183ea643017a64b9955395aebede0541fb6`, `GoogleAuthenticator.php` `6dd4a909c55bf4d52d4d10425ae62e319798ef8692b58c357bcdac1444193885`.
- Vollständiges `clean verify` gegen wegwerfbare MariaDB 11.4: **683 Tests, 680 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler. Anschließend nur die QR-Darstellung verkleinert, Frontend erfolgreich neu gebaut und paketiert. Bekannter Bundlegrößen-Hinweis bleibt bestehen.
- SQL: eigenes Profil/Passwort ohne Mitarbeiterrecht, Fremdzugriff gesperrt, nur lesende Einrichtung, identische Wiederholung, andere Sitzung, Ablauf, fünf Fehlversuche, neue Kopplung, konkurrierende Einrichtung, geänderte Policy/Stammdaten, Aktivierungs-/Reset-Rollback, Rechteentzug, geschützter Administrator, fremde Niederlassung und doppelte Parameter. Aktivierungscode beim Login verbraucht; nächster Zeitschritt erfolgreich. Alle Geheimnisse bleiben aus Belegen/Audit ausgeschlossen.
- Unit/HTTP: SVG-QR unabhängig bis zur vollständigen otpauth-Adresse zurückdekodiert, RFC-4648-Base32-Vektoren, redigierte DTOs, Authentifizierung, CSRF, kein Cache, eigene Identität trotz manipuliertem Zielparameter und administrative Routen ohne Recht 3 gesperrt.
- Browser ausschließlich mit flüchtiger synthetischer Fixture ohne Datenbank: Profilkonflikt, bewusstes Verwerfen und erneutes Speichern; QR-Anfrage und Aktivierung mit jeweils verlorener Antwort und identischer Wiederholung; falscher App-Code korrigierbar; Erfolg führt zur Anmeldung, erneuter Login und gesperrte Selbst-Deaktivierung sichtbar. Keine Konsolenwarnungen/-fehler. Nachweis `work/twofactor-ui-events-verified.json` mit redigierten Geheimnissen und Anfragen-Digests; Prüfbild `work/mein-konto-2fa-2026-10-16.png`.
- Live-Bestand ausschließlich gelesen: eigener Kontodialog und 2FA-Policy erfolgreich geladen, interne Sitzungsbindung 64 Zeichen. Keine Bestandskonten, Passwörter, Rechte oder Datenbankschemas geändert. Keine Qwen-Nutzung.

## Mitarbeiterkonten und bestehende Zwei-Faktor-Anmeldung – 16. Oktober 2026

- Aktuelle PHP-Dateien direkt per SSH unter `/data/0/votian-test/html`, HEAD **`090d3d5`**, gelesen. PHP-Mitarbeiteranlage und `[2FA]-Bestätigung` im Browser abgeglichen. Kein ursprünglicher lokaler PHP-Stand, kein Qwen.
- Kontoanlage mit vier Standardparametern, Passwortwechsel mit Altpasswort-Hashlöschung, NG-Sitzungsentzug, Kontoentfernung und bestehende TOTP-Anmeldung ergänzt. Schutz und Abgrenzung im Menüabgleich dokumentiert; 2FA-Einrichtung und Sonderparameter bleiben offen.
- Vollständiges `clean verify` gegen wegwerfbare MariaDB 11.4: **677 Tests, 674 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler. Gezielter Vorlauf: 58 Prüfungen erfolgreich. Nachfolgende reine Präzisierung zweier UI-Meldungen auf „NG-Sitzungen“ erneut gebaut und paketiert.
- SQL: globale Anmeldenamenkollision, andere/fremde Niederlassung, Nullrechte, alle vier PHP-Defaults, aktuelle Reset-Berechtigung, Admin-/Selbstschutz, alter Hash unbrauchbar, TOTP-Secret erhalten, Revisionskonflikt, exakte Löschbestätigung, wiederholte und gleichzeitig identische Anlage, atomarer Rollback bei Protokoll-/Belegfehler und MyISAM-Schutz. Wiederholungen mit anderem Passwort werden abgewiesen. Keine Zugangsdaten in API-Antwort, Audit oder Vorgangsbeleg.
- TOTP: sechs unabhängige RFC-6238-SHA1-Vektoren, Format/führende Nullen, exaktes Zeitfenster, fehlender/falscher Code, keine Header-Abkürzung, verbrauchter Code mit neuer Providerinstanz abgewiesen, nächster Zeitraum erlaubt und ältere Sitzung entzogen. Erzwungener Fehler bei Schlüsseldrehung rollt auch den verbrauchten Zeitschritt zurück. HTTP-Prüfungen für Sitzung, CSRF und aktuell entzogene Rechte erfolgreich.
- Live-Bestand nur gelesen: Konto-Vorschau und 64-stellige interne Sitzungsbindung erfolgreich berechnet; keine Hashwerte ausgegeben, keine Konten/Passwörter/Rechte/Schema geändert. Alle Schreibprüfungen in der wegwerfbaren SQL-Datenbank oder einer flüchtigen UI-Fixture ohne Datenbankanschluss.
- Browser: neue Kontoanlage, HTTP-503 und identische Wiederholung, Erfolg und Listeneintrag; Passwortdialog mit identischer Wiederholung und danach leeren Geheimnisfeldern; Löschbestätigung verlangt exakten Namen; Administratorkonto gesperrt; Anmeldung mit fehlendem Code abgewiesen und mit synthetischem Code erfolgreich. Beide Anfragenpaare in `work/accounts-ui-events.json` über Digest nachgewiesen; Geheimnisfelder dort redigiert. Prüfbild `work/mitarbeiter-kontoanlage-2026-10-16.png`.
- Anwendung auf Port 8080 neu gestartet: Health `UP`, Datenbank verbunden; alle sechs Frontenddateien in Build/JAR/HTTP bytegleich. Keine Browserwarnungen/-fehler. Eigene Prüftabs, Fixture, isolierte MariaDB und SSH beendet; Nutzertabs erhalten. `git diff --check` erfolgreich.

## Mitarbeiter: Stammdaten und Rechte – 16. Oktober 2026

- Frischer SSH-Stand **`090d3d5`**, aktuelle PHP-Mitarbeiterliste, Stammdaten und Rechte-Matrix gelesen. Quellen: `employee.php` SHA256 `4c90cdf4e63b0861dc7780cb6fd3184f8c3b21667ba90a6e6c706c8a75037bce`, `employee_list.php` `09bfbd1a245d08cb47533d5082e1275a8de1d944d53bbb9212e1c06d4da32451`, `employee_rights.php` `ee09cc8204fb335641cdcf39de36cf68afdeaa0233f10320f8146031f242670f`. Kein ursprünglicher lokaler PHP-Stand, keine Qwen-Nutzung.
- Vollständiges `clean verify` gegen wegwerfbare MariaDB 11.4: **670 Tests, 667 bestanden, drei optionale Live-Tests übersprungen**, keine Fehler. Gezielter Vorlauf: 61 Prüfungen erfolgreich. Ein im neuen Sitzungstest erkannter leerer Servletpfad wurde durch den Request-URI-Rückfall korrigiert. Frontend-Produktionsbuild erfolgreich; bekannter Bundlegrößen-Hinweis. Im abschließenden Wiederholungslauf außerdem einen sekundenabhängigen Fixturefehler im Servicepreis-Test behoben: Nach der absichtlichen PHP-Preisänderung wird für den folgenden Rollbacktest auch der ursprüngliche Änderungszeitstempel wiederhergestellt.
- SQL-Integration: eigene/fremde/mandantenfremde Mitarbeiter, Portalzugänge, literal behandelte Suchzeichen, Rechtekatalog, allgemeine/erbliche/Matrixrechte, exakte VIP-IDs, unbekannte hintere Bits und fremde Matrixzellen, Administrator-/Selbstschutz, Rechteentzug, doppelte Matrix, Kataloglücke, globale Anmeldenamenkollision, Geburtstagswerte und Erhalt von Passwort-/TOTP-Spalten. Parallele PHP-Stammdaten- und Delegationsänderung verhindern Übernahme. Fehler nach Rechte-/Stammdatenänderung rollt alles einschließlich Audit/Beleg zurück; identischer Vorgang mit neuer Serviceinstanz bleibt einmalig, veränderte Nutzdaten unter gleicher Kennung werden abgewiesen. MyISAM-Schreibziel wird abgewiesen.
- HTTP: fehlende Anmeldung, CSRF, aktuelles Mitarbeiterrecht, sofortiger Entzug in bestehender Sitzung, gesperrter gelöschter Zugang, keine vorzeitige Erweiterung alter Sitzungsrechte und kein Rückfall bei Datenbankausfall. Der gemeinsame Sitzungs-Principal bleibt durch einzelne Anfragen unverändert. Auch die Delegationsprüfung erweitert keine bei Anmeldung fehlenden allgemeinen Rechte.
- Live-Bestand ausschließlich gelesen: acht beteiligte Tabellen InnoDB; ausgewählte reale Liste mit 17 Mitarbeitern, 53 Rechtedefinitionen und 477 Matrixzellen erfolgreich geladen. Aktuelle Sitzungsrechte eindeutig lesbar. Nur aggregierte Prüfergebnisse ausgegeben, keine Geschäfts-/Konto-/Schemaänderung.
- Browser mit synthetischer SQL-Fixture: Stammdatenkonflikt mit gesperrtem Speichern, bewusstes Verwerfen, aktueller Stand, erfolgreiche Änderung; leere Niederlassung, Mitarbeiter-Suche, geschütztes Administratorkonto, Rechtefilter, Zeilenwahl, geschützte Niederlassungsfreigabe, Pflichtbestätigung, simulierte HTTP-503-Antwort, gesperrtes Schließen einschließlich Escape und erfolgreiche identische Wiederholung. Keine Konsolenwarnungen/-fehler. Prüfbild `work/mitarbeiter-rechte-2026-10-16.png`; beide Rechte-PUTs in `work/employees-ui-events.json` bytegleich hinsichtlich Nutzdaten.
- Anwendung vor Paketierung beendet, neue Version auf Port 8080 gestartet; Health `UP`, Bestandsdatenbank verbunden. Sechs Frontenddateien in Build/JAR/HTTP bytegleich. Eigene PHP-/NG-Prüftabs, Fixture-Server, wegwerfbare MariaDB und SSH-Verbindung beendet. `git diff --check` erfolgreich. Verbleibende Mitarbeiterabläufe sind ausdrücklich im Menüabgleich ausgewiesen.

## Listenerfassung: rabattierte Servicepreise – 16. Oktober 2026

- Aktuelle PHP-Erfassungsoberfläche gelesen; Referenz ausschließlich der frisch per SSH gelesene Stand **`090d3d5`**. Maßgeblich sind `job_options.php:1069–1078,1846–1856`, `caglobal.inc.php:1075–1125,1203–1229,1485–1598` und `services_func.inc.php:883–969`. Fünf Referenzfälle mit der echten PHP-Funktion und synthetischen Datenbank-/Schreib-Stubs ohne Bestandszugriff ausgewertet. Keine Qwen-Nutzung.
- Rabattierte Servicepreise in der Aktualisierung bestehender einfacher Listenaufträge ergänzt; separate Cent-Rundung, rabattierter Detailausweis, ungekürzter zusätzlicher Serviceausweis, Selbsterfasserrabatt und 100 % Servicepreisrabatt. Der ungewöhnliche PHP-Rabatttext ist ausdrücklich dokumentiert und vor Übernahme sichtbar erklärt. Unterschiedliche von null abweichende Rabattsätze bleiben mit konkreter Meldung ausgeschlossen.
- Vollständiges `clean verify` gegen wegwerfbare MariaDB 11.4 erfolgreich: **663 Tests, 660 bestanden, 3 optionale Live-Tests übersprungen**, keine Fehler. Zuvor gezielte Unit-/SQL-Prüfungen erfolgreich; ein Typinferenzfehler im neuen Test vor Ausführung korrigiert. Frontend-Build erfolgreich mit bekanntem Bundlegrößen-Hinweis.
- Unit-Prüfung: unabhängige Druckschalter, alle fünf PHP-Referenzwerte einschließlich positivem Rabatttext und halbem Cent, genaue B2B-Präzision, Service-only, 100 %, gemischte Rabattsätze, Mehrdeutigkeit und ungültige Summen. SQL-Integration: unverändernde Vorschau, Servicepreisänderung ohne Auftragsversionswechsel, Rollback nach zweitem Export-Insert, unveränderte Preise/Stationen/Metadaten, Erhalt fremder Exportzeilen und identische Wiederholung mit neuem Service.
- Browser ausschließlich mit synthetischen SQL-Daten: 117 € Auftragssumme, Vorschau mit 9 € rabattiertem Servicedetail und 10 € separatem Serviceausweis, sichtbarer Hinweis, Pflichtbestätigung, HTTP-503, gesperrtes Verwerfen/Schließen und erfolgreiche identische Wiederaufnahme. Keine Konsolenwarnungen/-fehler. Prüfbild `work/listen-servicerabatt-2026-10-16.png`, Anfragen `work/batch-service-discount-ui-events.json`.
- Laufende Anwendung vor Paketierung beendet und danach neu gestartet: Health `UP`, Bestandsdatenbank verbunden, sechs Frontenddateien in Build/JAR/HTTP bytegleich. Eigener Servicepreis-Prüftab, Fixture-Server und wegwerfbare Datenbank beendet; `git diff --check` erfolgreich.


## Auftragsbearbeitung: Text nur für die Kundenrechnung – 16. Oktober 2026

- Aktuelle PHP-Erfassungsmaske mit **Text nur Rg** angesehen; das Popup scheiterte im isolierten Tab am vorhandenen JavaScript-Zugriff auf `top`. Fachlicher Abgleich frisch per SSH mit Serverstand **`090d3d5`**, `jobs/job_options.php:227,1990–1993,2270` und `include/caglobal.inc.php:1203–1205,1343`. Kein ursprünglicher lokaler PHP-Bestand verwendet; keine echten Aufträge geöffnet, gesperrt oder geändert.
- Rechnungszusatz in der Auftragsbearbeitung ergänzbar/änderbar/löschbar. Bei der Rechnungstext-Aktualisierung einfacher Listenbuchungen nur dem Kundenrechnungstext hinzugefügt; Kuriertext und B2B-Preispositionen bleiben davon unberührt. Bestehender Fehler beim Speichern anderer Felder behoben: unveränderte formatierte Rechnungstexte verlieren keine Leerzeilen mehr. Grenzen der allgemeinen Rechnungsaufbereitung bleiben bestehen.
- Vollständiges `clean verify` gegen wegwerfbare MariaDB 11.4 erfolgreich: **657 Tests, 654 bestanden, 3 optionale Live-Tests übersprungen**, keine Fehler. Frontend-Build erfolgreich, bekannter Bundlegrößen-Hinweis. Implementierung und Prüfung direkt durch Codex, keine Qwen-Nutzung in dieser Ergänzung.
- Unit-Prüfung: richtige Einfügestelle, Unicode/Apostroph/Zeilenumbrüche, unveränderter Kuriertext bei aktivem und deaktiviertem Ausweis, identische B2B-Positionen, Leertext, Formatgrenze und mehrdeutige Metadaten. SQL-Integration: Rechte/HQ, Eingabegrenze, Anlage/Änderung/Entfernung, unveränderte Preise/Stationen/fremde Zusatzdaten, ältere Clients ohne Feld, Kopiervorlage, veraltete Bearbeitung und Vorschau nach reiner PHP-Metadatenänderung, Audit-Rollback und Wiederholung nach neuem Service.
- Browser ausschließlich mit synthetischen SQL-Testdaten: Zusatz bearbeiten und speichern, Vorschau mit getrennten Kunden-/Kuriertexten, bewusste Übernahme, simulierte verlorene Antwort sowohl beim Bearbeiten als auch bei der Rechnungsaktualisierung. Während unklarer Speicherung sind Eingaben/Verwerfen/Schließen gesperrt; danach erfolgreicher Text sichtbar. Pro Endpunkt zwei identische PUT-Anfragen in `work/invoice-notes-ui-events.json`. Entwurfsschutz mit „Weiterbearbeiten“ erhält die Vorschau. Keine Konsolenwarnungen/-fehler. Prüfbild: `work/rechnung-nur-kundentext-2026-10-16.png`.
- Anwendung auf Port 8080 neu gestartet, Health **UP**, Bestandsdatenbank verbunden. Alle sechs Frontend-Dateien in Build/JAR/HTTP bytegleich, `git diff --check` erfolgreich. Eigene Prüftabs, Fixture, Testdatenbank und SSH-Verbindung beendet; Nutzertabs erhalten. Keine realen Geschäfts-/Schemaänderungen, Mails oder externen BI-Testübertragungen.

## Listenerfassung: gespeicherter Selbsterfasserrabatt – 16. Oktober 2026

- Aktuelle PHP-UI berücksichtigt; Preis- und Rechnungstextlogik frisch per SSH vom Stand **`090d3d5`** geprüft. Referenz: `include/caglobal.inc.php:1485–1598` und `jobs/job_options.php:1053,1846–1849,1897–1898`. PHP-Rundungsbeispiele direkt auf dem Server ohne Datenbankänderungen ausgewertet; kein ursprünglicher lokaler PHP-Bestand verwendet.
- Bestehende einfache Listenbuchungen mit gespeichertem Selbsterfasserrabatt können Rechnungstexte und B2B-Positionen aktualisieren. Zuschlagsbasis vor dem Selbsterfasserrabatt, normaler Kundenrabatt danach, unabhängige Servicepreiszweige und Druckschalter berücksichtigt. Der Preis selbst wird nicht erneut rabattiert. Ungültige oder widersprüchliche Metadaten werden abgewiesen; manuelle Preisberichtigung entfernt den überholten Rabatt atomar.
- Vollständiges `clean verify` gegen wegwerfbare MariaDB 11.4 erfolgreich: **654 Tests, 651 bestanden, 3 optionale Live-Tests übersprungen**, keine Fehler. Zusätzlich gezielte Unit- und SQL-Integrationstests erfolgreich. Frontend-Build erfolgreich, bekannter Bundlegrößen-Hinweis. Bestehende vier Refresh-Unit-Tests erhalten, sieben neue Tests ergänzt.
- Regressionsfälle: sechs Rechnungspositionen, abweichende Druckschalter und Eurozeichen, deaktivierter Kuriertext, halber Cent und auf null gerundeter Rabatt, nicht ganzzahliger Prozentsatz, fehlende/ungültige/mehrdeutige Metadaten einschließlich doppelter Nullsätze, ungültiger Zuschlag, manuelle/fehlende Fuhrposition. Eingabedaten bleiben unverändert.
- SQL-Integration: unverändernde Vorschau, veraltete Rabattmetadaten, Rollback nach zweitem Export-Insert, genaues B2B-JSON, Speicherung ohne Änderung von Preisen/Metadaten/Stationen, Versionswechsel, identische Wiederholung und Erhalt fremder Exportdaten. Manuelle Preisberichtigung entfernt nur ersetzte Preisdetails einschließlich Rabatt 13; andere Zusatzdaten bleiben erhalten.
- Browser ausschließlich mit synthetischen SQL-Testdaten: Vorher-/Nachher-Vergleich, sechs Positionen, bewusste Übernahme, verlorene Speicherantwort und identische Wiederholung. Erfolgreicher Kunden-/Kuriertext danach sichtbar, keine Konsolenwarnungen/-fehler. Prüfbild: `work/listen-selbsterfasserrabatt-2026-10-16.png`; Speicheransicht: `work/listen-selbsterfasserrabatt-gespeichert-2026-10-16.png`; zwei identische PUT-Anfragen in `work/batch-refresh-ui-events.json`.
- Quellcode und Tests wurden vor dem Wechsel der Arbeitsweise von Qwen erstellt und durch Codex geprüft sowie übernommen; Korrekturrunden sind lokal protokolliert. Auf Benutzerwunsch keine weitere Qwen-Nutzung. Abschlussprüfung, Dokumentation und Neustart durch Codex.
- Anwendung auf Port 8080 neu gestartet, Health **UP**, Bestandsdatenbank verbunden. Alle sechs Frontend-Dateien in Build/JAR/HTTP bytegleich, `git diff --check` erfolgreich. Eigener Prüftab und Fixture beendet, Testdatenbank gestoppt; Nutzertabs erhalten. Keine echten Geschäfts-/Schemaänderungen, keine Mails oder externen BI-Testübertragungen.
- Weiter offen: komplexe Kalkulationszweige, automatische Aktualisierung ohne Einzelprüfung und allgemeine PHP-Hintergrundverarbeitung. Genaue Grenzen in `AUFTRAGSERFASSUNG.md`; keine vollständige Anwendungsmigration behauptet.

## Listenerfassung: Rechnungsausgabe nach Bearbeitung – 16. Oktober 2026

- Aktuelle PHP-Listenmaske geöffnet und Bearbeitungs-/Rechnungstextpfade frisch per SSH vom Serverstand **`93bf782`** gelesen. Kein ursprünglicher lokaler PHP-Bestand; keine echten Aufträge geöffnet, gesperrt oder verändert. Das leere PHP-Calculatorformat zusätzlich direkt aus den Serverbytes bestätigt.
- Neue Aktualisierung in der Auftragsbearbeitung: Vorher-/Nachher-Vorschau, bewusste Ersetzung manueller Rechnungstexte, Neubildung der B2B-Positionen aus gespeicherten Preisen, Hinweis nach Freitext-/Referenz-/Preisänderungen. Gilt für einfache eindeutig zugeordnete Listenbuchungen einschließlich manueller Fixpreise. Komplexe Sonderkalkulationen werden ausdrücklich abgewiesen; genaue Grenzen in `AUFTRAGSERFASSUNG.md`.
- Vollständiges `clean verify` gegen wegwerfbare MariaDB 11.4 erfolgreich: **647 Tests, 644 bestanden, 3 optionale Live-Tests übersprungen**, keine Fehler. Nach Ergänzung der leeren PHP-Calculatorzeichenfolge vier gezielte Unit-Tests erneut erfolgreich. Frontend-Build erfolgreich; bekannter Bundlegrößen-Hinweis.
- SQL-Integration prüft nur lesende Vorschau, bearbeiteten Freitext, manuelle Preisberichtigung, Markierung/Version, unveränderte Preise und Zustellnachweise, geänderte Druckvorgaben/B2B-Ausgabe, Fremdniederlassung, Export/Storno/PHP-Sperre/Rechnungszuordnung, bereits verarbeitete Positionen und MyISAM-Schutz. Rollback nach dem zweiten Export-Insert sowie nach Auditfehler stellt alte Texte und Positionen in beiden Schemas wieder her. Wiederholung nach neuem Service und zwei gleichzeitige identische Anfragen erzeugen keine Duplikate. Fremde HQ und Scanmeldung `REF|501` bleiben unverändert.
- Ein echter Integrationsbefund korrigiert: MariaDB behandelt `jb_origin TINYINT(1)` standardmäßig als Boolean. Der Auftrags-Snapshot normalisiert den numerisch gelesenen Herkunftscode und bewahrt damit Herkunft 7 auch beim Weiterverarbeiten. Kein Schemaeingriff.
- Browser ausschließlich mit synthetischen Daten aus dem SQL-Test: Listenauftrag öffnen, Hinweis, Vorher-/Nachher-Vergleich, gesperrte Übernahme ohne Bestätigung, Vorschau verwerfen, HTTP-503 und identische Wiederholung. Während unklarer Speicherung sind Änderungen/Verwerfen/Schließen gesperrt. Danach Erfolgsmeldung und neuer Kunden-/Kuriertext sichtbar; keine Browserwarnungen/-fehler. Prüfbild: `work/listen-rechnung-aktualisiert-2026-10-16.jpg`; zwei identische Speicheranfragen in `work/batch-refresh-ui-events.json` nachgewiesen.
- Keine realen Geschäfts-/Schemaänderungen, Mails oder BI-Übertragungen. Nicht als vollständige Migration der Rechnungsaufbereitung eingestuft; automatische Hintergrundaktualisierung und komplexe Kalkulationszweige bleiben offen.
- Anwendung vor der abschließenden Paketierung beendet und auf Port 8080 neu gestartet: Health `UP`, Datenbank verbunden, neuer Controller im JAR; sämtliche sechs Frontend-Dateien in Build/JAR/HTTP bytegleich. `git diff --check` erfolgreich. Eigene Browser-Tabs, Fixture, Testdatenbank und SSH-Verbindung beendet; Nutzertabs erhalten.

## Listenerfassung: B2B-Rechnungspositionen – 16. Oktober 2026

- Aktuelle PHP-Listenerfassung im Browser geöffnet; `jb_edit_batch.php`, `caglobal.inc.php` und `services_func.inc.php` erneut direkt vom SSH-Serverstand **`93bf782`** gelesen. Kein ursprünglicher lokaler PHP-Bestand verwendet. Reale Tabellenstruktur nur lesend geprüft: `phoenix_log.b2b_objects` ist InnoDB.
- Neue Listenbuchungen erzeugen B2B-Rechnungspositionen für Treibstoffzuschlag, Rabatt und Servicepreis sowie die nach Kundenabrechnungsmodus und Druckvorgaben verlangten Detailpositionen. Vorschau und gespeicherte Listen zeigen Faktor, Leistung, Basis und Betrag. PHP-Sonderfälle einschließlich negativer Rabattpositionen und zweier unabhängiger Servicepreiszweige sind dokumentiert. Andere Typ-300-Datensätze bleiben erhalten.
- Abschließendes `clean verify` gegen eine wegwerfbare MariaDB 11.4: **642 Tests, 639 bestanden, 3 optionale Live-Tests übersprungen**, keine Fehler. SQL-Prüfungen verwenden zwei getrennte Schemas und prüfen das genaue JSON-Format, HQ-Grenzen, MyISAM-Schutz, geänderte Druckvorgaben, stabile Wiederholung sowie vollständigen Rollback nach Fehlern in der zweiten Tour und nach dem zweiten B2B-Schreibzugriff.
- Browserprüfung mit synthetischen Antworten aus den SQL-Tests: Positionen in Vorschau und gespeicherter Liste, HTTP-503 beim ersten Speichern und identische Wiederholung ohne Doppelbuchung. Abschließende Layoutkorrektur der eingebetteten Tabelle geprüft; keine Browserwarnungen/-fehler. Prüfbild: `work/listen-b2b-2026-10-16.jpg`; Anfragen: `work/batch-ui-events.json`.
- Frontend-Build erfolgreich. Nach der reinen CSS-Korrektur erneut gebaut und paketiert; Anwendung auf localhost:8080 neu gestartet. Health `UP`, Datenbank verbunden; alle vier Frontend-Dateien in Build, JAR und HTTP bytegleich. Keine echten Aufträge, Rechnungen, Mails oder externen CO₂e-Testaufrufe erzeugt.
- Weiter offen: automatische Nachberechnung dieser Positionen bei späterer Auftragsbearbeitung, nachträgliche Übernahme bestehender Listen, eigener BI-Transport mit Empfangsbestätigung und die vollständige PHP-Hintergrundverarbeitung. Die gesamte Anwendung ist damit nicht als vollständig migriert eingestuft.

## Listenerfassung: Rechnungstexte und CO₂e – 16. Oktober 2026

- Aktuelle PHP-Listenerfassung im Browser geprüft; Quellvergleich ausschließlich mit dem aktuellen SSH-Serverstand. Rechnungsparameter im Bestand nur lesend geprüft.
- Kunden-/Kurierrechnungstext in Vorschau, Speicherung und Listenansicht; Rabatt-, Zuschlags-, Servicepreis- und Exportformatvorgaben. Zu lange Texte werden mit Zeilenbezug abgewiesen. Optionale CO₂e-Berechnung, Eingabeprüfung, Cacheablauf, historische Partnerprovision und vollständiger Berechnungsbeleg ergänzt. Genaue Abgrenzung und Formatabweichungen in `AUFTRAGSERFASSUNG.md`.
- `clean verify` gegen eine anschließend entfernte MariaDB 11.4 auf 127.0.0.1:33079: **639 Tests, 636 bestanden, 3 optionale Live-Tests übersprungen**, keine Fehler. Neue Prüfungen: Drucktexte/Unicode/Zeilenlimit, Cacheablauf und Fremdantworten, Tarif-/Parameteränderung, atomarer Rollback einschließlich CO₂e/Provision/Beleg sowie Wiederholung nach Cacheverlust.
- Browserprüfung ausschließlich mit synthetischen API-Antworten aus den Datenbanktests: CO₂e-Auswahl, zwei ausgefüllte Zeilen, Rechnungstexte aufgeklappt, fehlende Kilometer sichtbar, simulierter HTTP-503 beim Speichern und identische Wiederholung. Gespeicherte Liste zeigt Rechnungstexte und CO₂e. Prüfbild: `work/listen-rechnung-co2-2026-10-16.jpg`; Anfragen: `work/batch-ui-events.json`.
- Frontend-Build erfolgreich. Anwendung auf localhost:8080 neu gestartet; `/api/health` UP und Datenbankverbindung verfügbar. Alle vier ausgelieferten Frontend-Dateien sind bytegleich mit Build und JAR. Keine echten Aufträge, keine Mails und keine externen CO₂e-Testaufrufe erzeugt.
- Weiter offen in diesem Bereich: BI-/B2B-Exportzeilen und vollständige PHP-Hintergrundverarbeitung für Entfernungen/Geocodierung/Warnmails. Gesamte Anwendung ist damit nicht als vollständig migriert eingestuft.


## Listenerfassung – 16. Oktober 2026

- Aktuelles `jobs/jb_edit_batch.php`, `include/services_func.inc.php`, relevante Teile von `global.inc.php`, `dbglobal.inc.php` und `caglobal.inc.php` direkt per SSH unter `/data/0/votian-test/html` gelesen. PHP-UI in einem eigenen Tab geöffnet: Kundenwahl, Kundenlisten, 20 Zeilen, Datum/Uhrzeit, Tourentext, Referenz, Fracht-/Servicebetrag, Fahrzeug, KM, Rabatt/Zuschlag und Zeilenreset abgeglichen. Kein lokaler PHP-Altbestand verwendet. SHA-256 der Erfassungsdatei: `373f7efe167e17a24f7111160a442bf1967325a4de9e11fa1b7813e49c753e6f`; Preisfunktionen: `4bd29ac9ef3b0cdb5194091c90c56740868e9d9b4c8fdfde4229f8720a6d7a10`.
- Neuer nativer Einstieg **Aufträge → Listenerfassung**. Funktionsumfang und bewusst begrenzte PHP-Nebenpfade in `AUFTRAGSERFASSUNG.md` dokumentiert. Aktuelle Schemaabfrage nur lesend: `job`, `tour`, `tourservice`, `jobprice`, `jobbatch`, `jobbatchlist`, `genericdatacontainer` sämtlich InnoDB. Keine Bestandsänderungen und keine echten Aufträge/Mails erzeugt.
- `clean verify` mit wegwerfbarer MariaDB 11.4 erfolgreich: **633 Tests, 630 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Neue Prüfungen: Preisformel einschließlich doppeltem Serviceanteil beim Kurierlohn, Rabatt-/Zuschlags-/Fuhrlohnschalter, Servicefahrt, Betragsgrenzen und Sommerzeit, Erfassungsrecht/CSRF, Neukundenliste/Anhängen, geänderte Tarife, fremde Aufträge, gesperrte Fahrzeuge, veraltete Vorschau, MyISAM-Schutz, Rollback beim Fehler in der zweiten Station und zwei gleichzeitige identische Buchungsanfragen. SQL-Integration prüft Preise, Herkunft 7, Status 2, neutrale Station, Kilometer, Referenz und Zahlungsbedingung. Keine Änderungen an der normalen Einzelauftragsformel.
- Produktionsfrontend erfolgreich gebaut (bekannter Bundlegrößen-Hinweis). Browser mit aus dem SQL-Test erzeugten synthetischen Daten: Fehler bei unvollständiger Zeile, 20 Eingabezeilen, Datumsbelegung, deutsche Dezimalkommas, Fahrzeugsuche, Rabatt/Zuschlag, Preisvorschau **123,00 €** für Zeilen 1 und 3, erfolgreiche Speicherung nach simuliertem HTTP-503. Eingaben während unklarer Speicherung gesperrt; beide Speicheranfragen hatten dieselbe Kennung und denselben vollständigen Inhalt. Listenansicht zeigt korrekt formatierte Erledigungszeiten sowie Service-/Zuschlagsanteile.
- Prüfbild: `work/listenerfassung-2026-10-16.jpg`. Der Datums-/Uhrzeitbereich nutzt durchgehend Berliner Ortszeit; die Listenausgabe formatiert Daten serverseitig unabhängig vom JDBC-/JSON-Datentyp.
- Entwurfsschutz im Browser geprüft: „Weiterbearbeiten“ erhält die Eingaben; „Verwerfen“ schließt nur nach bewusster Auswahl. Im abschließenden UI-Lauf keine Browserwarnungen/-fehler.
- Anwendung auf Port 8080 neu gestartet; `/api/health` meldet `UP`, `/api/system` eine verbundene Bestandsdatenbank. Sämtliche Frontend-Dateien im JAR bytegleich mit dem Produktionsbuild; ausgelieferter Index und referenzierte JS-/CSS-Dateien ebenfalls bytegleich. `git diff --check` erfolgreich. SSH, temporäre Tabs, Fixture-Server und Testdatenbank beendet. Bestehende Nutzertabs erhalten; dort für den neuen Einstieg neu laden.

## Auftragserfassung: An/Ab ohne Auswahl – 15. Oktober 2026

- Aktuelle PHP-Speicherung und `photoScopeMatches` erneut direkt per SSH unter `/data/0/votian-test/html` geprüft. Die beiden ausgeschalteten An/Ab-Kästchen entsprechen `tr_ware_from_to=0`. Kein ursprünglicher lokaler PHP-Bestand verwendet.
- „Weder Abholung noch Zustellung“ als vierte Stationsart ergänzt. Anlegen, Auftragsdetails, Kopieren/Vorlagen, Bearbeitung und Neukalkulation erhalten den Wert 0. Fotoworkflows berücksichtigen `NONE`: allgemeine und beide Ausschlussregeln erlaubt, reine Abhol-/Zustellregeln ausgeschlossen; Typwechsel verwirft eine zuvor explizite Fotoauswahl.
- Abschließendes `clean verify` gegen wegwerfbare MariaDB 11.4 erfolgreich: **628 Tests, 625 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Enthalten sind alle 20 Kombinationen aus Stationsart und Foto-Scope, Erfassung/Leseabbildung aller vier Richtungen, Vorlagenübernahme, Neukalkulation sowie echte isolierte SQL-Schreib-/Lesezyklen für Bearbeitung und Kopieren. Keine Änderungen an realen Aufträgen oder am Bestandsschema.
- Frontend-Produktionsbuild erfolgreich; bekannter Hinweis zum Bundle über 500 kB. Im Vorlauf Typisierung eines vorhandenen Formularhandlers und einer neuen Testliste korrigiert; das minimale SQL-Prüfschema für den erstmals dort aufgerufenen Kopierpfad ergänzt und einen JDBC-Zahlenvergleich typunabhängig gemacht. Abschließender Gesamtlauf fehlerfrei.
- Browser mit synthetischen Daten: Vorlage übernimmt `NONE`; passende Fotooptionen erscheinen; Wechsel von einer exklusiven Fotoauswahl zurück auf `NONE` setzt die Auswahl korrekt zurück. „Kein Pflichtfoto · 0–5 Fotos“ bleibt explizit wählbar. Preisprüfung und einmaliges Speichern ausschließlich an die lokale Fixture erfolgreich; Nutzdaten enthalten `NONE` und Workflow 0. Keine Browserwarnungen/-fehler. Prüfbild: `work/station-none-2026-10-15.jpg`.
- Anwendung vor Paketierung beendet und anschließend auf Port 8080 neu gestartet. Health `UP`, Bestandsdatenbank verbunden, Index und drei JS-/CSS-Dateien in Build/JAR/HTTP bytegleich; `NONE` im ausgelieferten Backend vorhanden. SSH, Prüftab, Fixture und Testdatenbank beendet. Bestehende Tabs erhalten; für die neue Auswahl dort neu laden. `git diff --check` erfolgreich.

## Auftragserfassung: sechs Abweichungen zum aktuellen PHP – 15. Oktober 2026

- Erfassungs-, Preis- und Routingdateien erneut frisch vom SSH-Server unter `/data/0/votian-test/html` gelesen; Referenz `93bf782` einschließlich der ausgelieferten Arbeitsdateien. Kein ursprünglicher lokaler PHP-Bestand. Der vorangegangene Abgleich der angemeldeten PHP-Oberfläche bleibt in `AUFTRAGSERFASSUNG.md` nachvollziehbar.
- Ergänzt: automatische PZM-/Bestandstarifwahl nach Kundenabrechnungsmodus einschließlich Kostenstellen-Override und geladener Festpreistouren; 36-Monats-Grenze; Tourenoptimierung mit festem/freiem Ende; Places-Vorschläge im Straßenfeld; eigenständige PLZ-Preisanfrage; Routenkarte, Berechnungsstand und Cache-Aktualisierung.
- Vollständiger abschließender `clean verify` gegen wegwerfbare MariaDB 11.4: **614 Tests, 611 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Enthalten sind Datenbankintegration, SQL-Architektur und HTTP-Sicherheit. Frontend-Produktionsbuild und finale Paketierung erfolgreich; bekannter Bundle-Hinweis > 500 kB.
- Neue Prüfungen: Datumsgrenze vor Datenbank-/Dienstzugriff, AUTO-Auflösung ohne Änderung der Originalanfrage, stabile Wiederholung trotz geänderter Kundenvorgaben, Kostenstellen-Override, Optimierungsreihenfolge und Endstationsvergleich, ungültige Permutationen, Cache-Umgehung, Route mit Geometrie/Zeitpunkt, allgemeine PLZ-Preise mit einmaligem Grundpreis/Zuschlag, fehlende Tarife sowie Recht 7 und CSRF. Anzeigegeometrie und Abrufzeit beeinflussen weder Preisfingerprint noch Bestands-Routenbeleg.
- Browser ausschließlich mit synthetischen Daten: PLZ-Preisanfrage ohne vollständigen Auftrag, Übernahme einer Places-Adresse, Optimierung mit Vorschau und expliziter Übernahme, Kassierstation bleibt nach Umsortierung derselben Station zugeordnet. Preisprüfung, expliziter frischer Routenabruf und eingebettete Karte geprüft. Datumsfeld weist eine Nacherfassung aus 2022 ab. Einziger Speicheraufruf ging an die lokale Fixture; Nutzdaten enthalten AUTO und die korrekt verschobene Kassierstation. Geladene Festpreisvorlage eines PZM-Kunden wechselt nach Änderung der Hausnummer wieder auf AUTO. Keine Browserwarnungen/-fehler. Prüfbild: `work/php-entry-implementation-2026-10-15/routenkarte.jpg`.
- Keine echten Aufträge, Geschäfts-/Schemaänderungen, Uploads oder Nachrichten. Externe Places-/PZM-Antworten wurden in den gezielten Tests simuliert; damit ist keine vollständige Live-Tarifgleichheit oder ein PHP-/NG-Schreib-Lesezyklus bestätigt. Zahlungsbedingungsspeicherung und PHP-B2B-Export bleiben die separat dokumentierten Integrationsgrenzen.
- Anwendung vor JAR-Ersetzung beendet, final paketiert und auf Port 8080 neu gestartet. Health `UP`, Bestandsdatenbank verbunden; Index und alle drei JS-/CSS-Dateien in Build/JAR/HTTP bytegleich, neuer Erfassungscontroller im Paket vorhanden. Temporärer Prüftab, Fixture-Server, Testdatenbank und SSH-Verbindung beendet; bestehender Anwendungstab erhalten. Für die neuen Funktionen dort neu laden. `git diff --check` erfolgreich.

## Fahrzeugdisposition: Rollkarte aufs Endgerät – 15. Oktober 2026

- Vollständiger Maven-Lauf gegen wegwerfbare MariaDB 11.4: **606 Tests, 603 bestanden, 0 Fehler, 3 optionale Prüfungen übersprungen**, einschließlich SQL-Architektur und HTTP-Sicherheit. Frontend-Produktionsbuild erfolgreich, bekannter Bundle-Hinweis > 500 kB.
- Frischer SSH-Stand und angemeldete PHP-FDS geprüft; kein ursprünglicher lokaler PHP-Bestand. Alte Auswahl ohne Fahrzeugzeilen, deshalb gefüllten Aktionsdialog anhand des aktuellen PHP-Codes abgeglichen.
- SQL: direkte Gerätezuordnung statt Fahrzeughalter, Angebot ausgelassen, Mehrtageshinweis, Vorschau ohne Schreibwirkung, Status/Version/Annahmezeit und einmaliger Audit-/Vorgangsbeleg. Preise, andere Aufträge, Tageskapazitäten und Reservierungen unverändert. Fehlende/doppelte Betriebsart, Geräte-/SID-Mehrdeutigkeit, App-Sperre, Tages-/Bearbeitungssperren, Unternehmerfreigabe, Fremdauftrag, unvollständiges Raster, fremdes Reservierungsfahrzeug, Zuweisung/Sondervermittlung, Abrechnung/Storno/Export abgewiesen. Geänderte Aufträge, Geräte und Betriebsart entwerten die Vorschau. Fehlende Rechte, CSRF, Pflichtbestätigung und nachträglicher HQ-Rechteentzug geprüft.
- Fehler am ersten und zweiten Auftragsaudit rollen sämtliche Auftragsänderungen zurück. Wiederholung bleibt ohne Doppeländerung, geänderte Daten unter derselben Kennung scheitern. Schreiben auf MyISAM-Aufträge abgewiesen; lesende Hilfstabellen dürfen MyISAM bleiben. Ein anfänglicher DDL-Test über die bewusst auf DML beschränkte API wurde in die direkte Testdatenbank-Einrichtung verlegt. Nach veralteten kompilierten Testklassen wurden ausschließlich generierte Testklassen neu gebaut; abschließender Gesamtlauf fehlerfrei.
- Browser mit SQL-generierten synthetischen Daten: Betriebsart-Hinweis blockiert die Aktion, Neuabruf, Konflikt mit erzwungener neuer Vorschau, Liste einschließlich ausgelassenem Angebot und Mehrtageswarnung, Pflichtbestätigung, verlorene Antwort mit gesperrtem Schließen/Neuabruf, erfolgreicher Ergebnisabruf und aktualisierte angenommene Aufträge. Scrollbarer Dialog mit fester Überschrift und Fußleiste; keine Konsolenwarnungen/-fehler. Prüfbild: `work/fds-rollkartenuebergabe-2026-10-15.jpg`.
- Reale Daten ausschließlich gelesen: Aufträge/Belege InnoDB und Gerätekurierzuordnungen vorhanden. `GLOBAL_USE_RELATED_CUSTOMER` fehlt; der direkte Übergabepfad ist deshalb im aktuellen Bestand nicht freigegeben. Keine Parameterumstellung, echte Auftragsänderung oder Geräteübertragung. Classic-Tourbildung bleibt offen.
- Anwendung vor JAR-Ersetzung beendet, erfolgreich paketiert und auf Port 8080 neu gestartet. Health `UP`, Datenbank `CONNECTED`; Index und alle vier JS-/CSS-Assets bytegleich in Build/JAR/HTTP, neuer Übergabecontroller im JAR. Temporäre Prüftabs, Fixture-Server und Testdatenbank entfernt, SSH beendet. Bestehenden Anwendungstab erhalten; für den neuen Stand im Browser neu laden. `git diff --check` erfolgreich.


## Kundenpflege: Rollkarten-Mailadressen – 15. Oktober 2026

- Vollständiger abschließender Maven-Lauf gegen wegwerfbare MariaDB 11.4: **605 Tests, 602 bestanden, 0 Fehler, 3 optionale Prüfungen übersprungen**, einschließlich SQL-Architekturtest. Frontend-Produktionsbuild erfolgreich; bekannter Bundle-Hinweis > 500 kB. Im gezielten Vorlauf wurde eine reine Groß-/Kleinschreibungsabweichung der Fehlertext-Erwartung korrigiert.
- Frischer SSH-Stand `93bf782`; alte angemeldete Kundenseite und aktuelle manuelle/automatische Versandverbraucher geprüft. Kein ursprünglicher lokaler PHP-Bestand. Die alte UI enthält die Zeitpflege, die vier Adressfelder werden nativ ergänzt.
- SQL-/HTTP-Prüfung: Vorschau ohne Schreibwirkung; Anlage und direkte Übernahme durch `VehicleRollcardMail`; alle vier Felder, Deduplizierung, Pflichtbestätigung, ungültiger/fehlender Absender und Empfänger, Kopfzeilen- und Shell-Steuerzeichen, 100-Empfängergrenze. Rechte 0/2, Anmeldung/CSRF, fremde HQ und zwischenzeitlich verschobener Kunde. Teilweise ungültiger Bestand reparierbar; doppelte/abweichend zugeordnete Parameter blockieren. Beschreibungen, allgemeine Verteiler und fremde Werte bleiben erhalten.
- Isolierte MariaDB: keine doppelten Änderungen nach verlorener Antwort oder neuem Service; andere Nutzdaten mit gleicher Kennung abgewiesen; genau ein Gewinner bei konkurrierender Bearbeitung; alter Revisionsstand nach PHP-Änderung abgewiesen. Zwischenfehler beim vierten Parameter und Auditfehler rollen alle Parameter samt Belegen zurück. MyISAM-Schreibbestand gesperrt. Gemeinsames Entfernen ohne Rückfall auf allgemeine Empfänger geprüft.
- Browser mit synthetischen SQL-Daten: Einstieg im Kundenstamm, leere/gespeicherte Vorgaben, ungültige Adresse, bereinigte Vorher-/Nachher-Tabelle, Pflichtbestätigung, Entwurfsschutz mit Weiterbearbeiten, verlorene Antwort mit gesperrtem Schließen/Neuladen, erfolgreiche Wiederaufnahme und Entfernung samt Neuabruf. Scrollbarer Dialog mit fester Überschrift und Speicherleiste. Prüfbild: `work/rollkarten-mailadressen-2026-10-15.jpg`.
- Reale Daten ausschließlich gelesen: neue native Ansicht für einen Bestandskunden erfolgreich; `parameter` und `genericdatacontainer` InnoDB, weiterhin keine kundenspezifischen Rollkarten-Mailparameter. Keine realen Geschäfts-, Parameter- oder Schemaänderungen und kein echter Mailversand. PHP-Cron kann Empfänger ergänzen und Aufträge annehmen; seine durch `true` übergangenen Zeit-/Wiederholungs-/Freigabeprüfungen sind dokumentiert. Betriebsstatus des Cron nicht geprüft oder verändert.

- Anwendung vor JAR-Ersetzung beendet, erfolgreich paketiert und auf Port 8080 neu gestartet. Health `UP`, Datenbank `CONNECTED`; Index und alle vier JS-/CSS-Assets in Build/JAR/HTTP bytegleich. Neuer Controller im Paket enthalten. Finalen Browserbuild samt aktualisiertem Wirkungshinweis geprüft, keine Konsolenwarnungen/-fehler. Prüftabs, Fixture-Server, Testdatenbank und SSH-Verbindung beendet. Vorhandenen Anwendungstab mit Anmeldeeingaben erhalten; dort für die neue Oberfläche neu laden. `git diff --check` erfolgreich.

## Fahrzeugdisposition: PDF und Rollkartenmail – 15. Oktober 2026

- Frischer SSH-Stand **`93bf782`**, Versandmenü, Empfängerauflösung und PDF-Aufruf gelesen; aktuelle angemeldete PHP-FDS geöffnet. Kein ursprünglicher lokaler PHP-Bestand. Die alte Auswahl bleibt ohne Fahrzeugzeilen; kein gefülltes Versandmenü visuell vergleichbar.
- Vollständiger abschließender Maven-Testlauf gegen wegwerfbare MariaDB 11.4: **600 Tests, 597 bestanden, 0 Fehler, 3 optionale Prüfungen übersprungen**. Enthält PDF-, SMTP-, SQL-, HTTP- und SQL-Architekturprüfungen. Frontend-Produktionsbuild erfolgreich; bekannter Hinweis auf Hauptbundle > 500 kB. Frühere Testkorrekturen: Namensüberschneidung mit Mockito `verify`, SQL-Testparameter statt Semikolon im SQL-Literal, erwarteter CSRF-Status und Fehlertext.
- SQL-Integration: Vorschau ohne Schreibwirkung, Rechte/Kunden-/HQ-Grenzen, Auswahl mehrerer Kunden, fehlende Vorgaben ohne globalen Rückfall, doppelte Parameter, geänderter Inhalt und geänderte Empfänger nach Vorschau. Auditfehler rollt den Startbeleg zurück und löst keinen SMTP-Versuch aus. Wiederholung, paralleler zweiter Aufruf und neuer Service nach simuliertem Neustart bleiben ohne Doppelversand. Unklare SMTP-Antwort wird dauerhaft unbestätigt geführt; Fehler beim Speichern des Ergebnisses hinterlässt den Startbeleg und verhindert erneuten SMTP-Versuch. Fremde HQ mit nachträglich entzogenen Rechten wird abgewiesen. Aufträge und Reservierungen unverändert.
- PDF-/SMTP-Prüfung: Unicode (einschließlich Ł/ë/ü), eingebettete Schrift, Inkasso, sichtbarer HTML-Text, lange Wörter, mehrseitige Artikel und vollständige Schlusszeilen. Leere Ausgabe und nicht unterstützte Zeichen werden gemeldet. Drei SQL-generierte PDF-Seiten vollständig gerendert und visuell geprüft. Lokaler SMTP-Socket prüft exakte Envelope-Empfänger, privaten Bcc-Header, UTF-8-Betreff und bytegleichen PDF-Anhang. Keine externen Testempfänger.
- Browser mit synthetischen SQL-Daten: direkter PDF-Download, fehlende Empfänger, ausdrückliche Kundenwahl bei gemischter Rollkarte, An/Cc/Bcc-Vorschau, beide Pflichtbestätigungen, Seiten 1–3 mit Randbegrenzung, verlorene Versandantwort, gesperrtes Schließen und erfolgreiche Wiederholung. Versandverlauf nach Wiederöffnung vorhanden. PDF-Iframe im eingebetteten Browser war leer und wurde durch gerenderte PDF-Seiten ersetzt; finaler Produktionsbuild geprüft. Keine Browserwarnungen/-fehler. Beide Downloadwege bytegleich mit der jeweils geprüften PDF-Ausgabe. Prüfbild: `work/fds-rollkartenmail-2026-10-15.jpg`.
- Echter Bestand nur gelesen: `genericdatacontainer` InnoDB, `gdc_content` TEXT; keine kundenspezifischen Rollkarten-Mailparameter vorhanden. Reale Empfänger-/Absendervorgaben sind Voraussetzung für echten Versand. Keine realen Geschäfts-, Schema- oder Parameteränderungen, kein echter E-Mail-Versand. Umfang und verbleibende Lücken siehe Menüabgleich.
- Anwendung vor JAR-Ersetzung beendet, erfolgreich paketiert und auf Port 8080 neu gestartet. Health `UP`, Bestandsdatenbank `CONNECTED`; Index und alle vier JS-/CSS-Assets in Build/JAR/HTTP bytegleich. Mailcontroller, PDF-Generator und PDFBox 3.0.8 im Paket vorhanden. Temporäre Prüftabs, Fixture-Server, Testdatenbank und SSH-Verbindung beendet. Bestehenden Anwendungstab mit Anmeldeeingaben erhalten; für die neue Oberfläche dort neu laden. `git diff --check` erfolgreich.

## Fahrzeugdisposition: Mehrtagesplanung – 15. Oktober 2026

- Erneut frischer SSH-Stand **`93bf782`**, aktuelle Reservierungs-/Mehrtages-/Parameterpfade und alte angemeldete FDS-UI geprüft. Kein ursprünglicher lokaler PHP-Bestand. Die alte Auswahl enthält keine Fahrzeugzeilen; kein gefüllter Alt-Mehrtagesdialog sichtbar. Die widersprüchliche PHP-Gewichtsverbuchung begrenzt den neuen Ablauf auf bestehende Reservierungen ohne Artikelgewicht, siehe Menüabgleich.
- Vollständiger Maven-Testlauf gegen wegwerfbare MariaDB 11.4: **592 Tests, 589 bestanden, 0 Fehler, 3 optionale Prüfungen übersprungen**. Zuvor sieben gezielte Unit-/SQL-/HTTP-Prüfungen erfolgreich. Frontend-Produktionsbuild erfolgreich; bekannter Bundle-Hinweis > 500 kB. SQL-Architekturprüfung enthalten.
- Unit-/HTTP-Prüfung: Rechte 27/4/7, Anmeldung und CSRF, Kalenderaufteilung einschließlich Wochenende und Resttag, kundenbezogener Folgestart im Format `HH_UU`, Zeitraster, Mitternacht, Jahresgrenze, maximal 60 Tage, doppelte/unterbrochene Reservierungen und mehrere Quellfahrzeuge.
- SQL-Integration: Öffnen über Folgetag lädt gesamten Auftrag; Vorschau unverändernd; Kundenparameter vor globalem Wert; drei alte und drei neue Fahrzeugtage. Gesperrte/verarbeitete/fehlende/vergangene Tage, Zielbelegung erst am letzten Folgetag, unvollständiges Raster, inaktive Kundenzeit, fehlende Favoritenbeziehung, Unternehmerfreigabe, Artikelgewicht, Angebot/Annahme/Zuweisung, Rechnung und PHP-Bearbeitung verhindern jede Änderung. Änderungen an Zielbestand, Folgezeit oder Verfügbarkeitsblöcken entwerten die Vorschau. Auditfehler rollt alle Tage zurück. Erfolgreiche Übertragung und Verschiebung auf demselben Fahrzeug erhalten die volle Dauer, alle Kapazitätsfelder, anderen Aufträge und nicht betroffenen Tage. Freie Blöcke enthalten keine reservierten Rasterplätze. Wiederholung erzeugt weder zweites Audit noch zweite Änderung; geänderte Wiederholungsdaten werden abgewiesen. Rechteentzug für fremde HQ nach Vorschau wird beim Schreiben erkannt.
- Browser mit synthetischen, aus der SQL-Prüfung erzeugten Daten: neue Aktion am Auftrag; Ziel-/Datums-/Zeitwahl; drei Folgetage mit Rundung und Restdauer; Pflichtbestätigung. Mitternachtsfehler entfernt die alte Vorschau. Eigener Entwurfsdialog erhält bei „Weiterbearbeiten“ die Auswahl. Verlorene Speicherantwort sperrt Eingaben, Schließen und Neuladen; erneuter Ergebnisabruf erfolgreich. Tagesdetail und anschließende Übersicht zeigen den entfernten Quellauftrag. Keine Browserwarnungen/-fehler. Scrollbarer Dialog mit fester Überschrift und Speicherleiste. Prüfbild: `work/fds-mehrtagesplanung-2026-10-15.jpg`.
- Keine realen Geschäfts-, Schema- oder Parameteränderungen zur Prüfung. Alle Schreibnachweise stammen aus der wegwerfbaren Datenbank bzw. der lokalen Browserfixture. Reale Datenbasis enthält nach vorangegangener Leseprüfung keine aktuellen Fahrzeugtage mit vorhandenem Raster; daher kein echter Mehrtagesauftrag als Schreibtest.
- Anwendung vor JAR-Ersetzung beendet, erfolgreich paketiert und auf Port 8080 neu gestartet. Health `UP`, Bestandsdatenbank `CONNECTED`; Index und alle vier JS-/CSS-Assets in Build/JAR/HTTP bytegleich. Mehrtagescontroller im Paket vorhanden. Temporäre Prüftabs, Fixture-Server, Testdatenbank und SSH-Verbindung beendet. Bestehenden Anwendungstab mit Anmeldeeingaben erhalten; für die neue Oberfläche dort neu laden. `git diff --check` erfolgreich.

## Fahrzeugdisposition: Umsortierung und Fahrzeugübertragung – 15. Oktober 2026

- Frischer SSH-Stand **`93bf782`**, aktuelle PHP-UI und tatsächlicher Sortier-/Übertragungspfad samt Gewichts-, Mehrtages- und Verfügbarkeitshelfern geprüft. Keine ursprünglichen lokalen PHP-Quellen. Die alte UI zeigt für die aktuelle Auswahl keine Fahrzeugzeilen; kein visueller Abgleich eines ausgefüllten Alt-Sortierdialogs möglich.
- Vollständiger Maven-Testlauf gegen wegwerfbare MariaDB 11.4: **586 Tests, 583 bestanden, 0 Fehler, 3 optionale Prüfungen übersprungen**. Nach einer reinen Hinweistextkorrektur sieben gezielte Planungs-/SQL-Tests erneut erfolgreich. Frontend-Produktionsbuild erfolgreich; bekannter Bundle-Hinweis > 500 kB. SQL-Architekturprüfung im vollständigen Lauf enthalten.
- SQL-Integration: unverändernde Vorschau; Umsortierung mit Rundung und verkürzter Reservierung bei unveränderter Auftragsdauer/Zuweisung; No-op; Status/Angebot, aktuelle PHP-Sperre, Rechnung, Mehrtagesdauer/-reservierung und Tagessperren. Zielüberschneidung, ungenügende Restnutzlast, inaktive Kundenfenster und Unternehmerfreigabe verhindern die Übertragung. Änderungen am Zieltag, Artikelgewicht oder Kundenbezug machen die Vorschau ungültig. Artikelgewichte aus mehreren Stationen werden ohne Mengenmultiplikation summiert. Andere Zielaufträge, Tage, Kapazitätsfelder, Statusbits und Bemerkungen bleiben erhalten; freie Kundenblöcke enthalten keine reservierten Zeitabschnitte. Auditfehler rollt beide Aktionen vollständig zurück; Wiederholung erzeugt keine zweite Änderung. HQ-Freigabe und entzogene Rechte werden beim Schreiben für fremde HQ erneut geprüft. Lesen mit MyISAM-Stammtabellen getestet; keine MyISAM-Schreibdaten.
- HTTP-/Unit-Prüfung: Anmeldung, CSRF, Rechte 27/4/7, vollständige eindeutige Auftragsliste, Rasterrundung, gleiche/absteigende Startzeiten und Mitternachtsgrenze. Übertragung kürzt keine Auftragsdauer.
- Echte Daten ausschließlich gelesen: alle fünf benötigten Schreibtabellen und `tourarticle` sind InnoDB; Artikelspalten vorhanden. Der Bestand enthält aktuell keine Fahrzeugtage ab heute mit vorhandenem Raster. Die reale Planungsvorschau konnte deshalb nicht geprüft werden; alle Schreibnachweise stammen aus isolierten Daten. Keine realen Geschäfts-/Schemaänderungen.
- Browser mit synthetischen SQL-Fixtures: neue Fahrzeugzeilenaktion, Pfeilumsortierung, Planzeiten per Tastatur, Vorschau mit Rundung/Kürzung, Pflichtbestätigung, verlorene Antwort mit gesperrtem Schließen/Neuladen und erfolgreicher Wiederholung. Konflikt nach paralleler Änderung verlangt Neuabruf; eigener Entwurfsdialog erhält bei Abbruch die Auswahl. Übertragung zeigt beide Restnutzlasten und führt nach Speicherung zur leeren Quellbelegung.
- Finaler Browserbuild erneut geladen: scrollbarer Dialog mit fester Überschrift und erreichbarer Speicherleiste; datumsformatierte Vorschau und erfolgreiche Speicherwiederholung geprüft. Keine Browserwarnungen/-fehler. Prüfbild ausschließlich mit synthetischen Daten: `work/fds-belegung-umplanen-2026-10-15.jpg`.
- Anwendung jeweils vor JAR-Ersetzung beendet, final paketiert und auf Port 8080 neu gestartet. Health `UP`, Bestandsdatenbank verbunden; vier JS-/CSS-Assets in Build/JAR/HTTP bytegleich. Planungscontroller im Paket vorhanden. Temporäre Prüftabs, Fixture-Server, wegwerfbare Datenbank und SSH-Verbindungen beendet. Vorhandenen Anwendungstab mit Anmeldeeingaben erhalten; für die neue Oberfläche dort neu laden. `git diff --check` erfolgreich.
- Funktionsumfang und verbleibende Mehrtages-/Versand-/Grafiklücken siehe Menüabgleich.

## Fahrzeugdisposition: Standardrollkarten – 15. Oktober 2026

- Frischer SSH-Stand **`93bf782`**: FDS-Menü, `getVehicleJobList`, `getCartageNote` und beide Zeitfensterhelfer gelesen. Keine ursprünglichen lokalen PHP-Quellen verwendet. Alte angemeldete UI am vergangenen Tag 14.10.2026 geprüft; sie zeigt in der aktuellen Auswahl keine Fahrzeuge, somit kein visueller Abgleich einer ausgefüllten Altrollkarte möglich.
- Vollständiger Maven-Testlauf gegen wegwerfbare MariaDB 11.4: **579 Tests, 576 bestanden, 0 Fehler, 3 optionale Prüfungen übersprungen**. Der letzte Lauf enthält auch Nullbeträge, leere Plantermine und Packstückwerte. Frontend-Produktionsbuild und Paketierung erfolgreich; bekannter Bundle-Hinweis > 500 kB. SQL-Architekturprüfung enthalten.
- SQL-Integration: reservierte/angenommene Aufträge, Mehrfachreservierung, Annahme ohne Tagesdatensatz, anderer Tag, Angebote/Erledigungen/Storno/fehlende Zeiteinheiten, gleiche SID in anderer Niederlassung, Freigabeprüfung samt entzogenen Rechten, unveränderte Sitzungs-HQ und Geschäftsbestände. Folgeauftragsreferenz, Artikel nur von Zielstation 2, Packstücksumme, drei Zeitfensterverfahren, Zusatztexte, Teilzahlung/Überzahlung/Nullbeträge, gespeichertes HTML als sichtbarer Text, geänderte Inhaltsrevision, doppelte Zusatzfelder und fehlende Zielstation geprüft. Mehrdeutige oder unvollständige Angaben führen zu verständlichen Fehlern.
- HTTP-/Unit-Tests: fehlende Anmeldung, fehlendes Dispositions-/Auftragsleserecht, fremde HQ ohne Freigabe, unzulässige Auswahl, Dienstleistungsbits, Grenzzeiten einschließlich 24:00 und Dezimalrundung des PHP-Inkassoverfahrens. Kein Schreibendpunkt und kein Versand.
- Echte Daten ausschließlich gelesen: Fahrzeug-/Rollkartenabfrage und Parameterzugriff erfolgreich. Die gewählte reale Kombination enthält derzeit keine passenden Aufträge; der vollständige Inhaltsnachweis stammt daher aus der isolierten SQL-Prüfung. Keine realen Geschäfts-, Parameter- oder Schemaänderungen.
- Browser mit synthetischen Daten: Auswahl aller/reservierter/angenommener Aufträge, lesbare Vorschau, Fehler mit entfernter alter Ausgabe und gesperrtem Export, erfolgreicher Neuabruf, leere Rollkarte ohne Druck/Download sowie Ausgabe der freigegebenen Niederlassung HH. Finalen Build geprüft; Download bytegleich zur vom Backend erzeugten HTML-Vorschau. Die reine Vorschau setzt keinen Hinweis auf ungespeicherte Änderungen. Keine Konsolenwarnungen/-fehler im finalen Durchgang. Prüfbild: `work/fds-rollkarten-2026-10-15.jpg`.
- **Prüfgrenze:** Systemdruckdialog/PDF-Speicherung nicht automatisiert ausgelöst. „Drucken / PDF“ verwendet den Browserdruckdialog; es gibt keinen direkten PDF-Endpunkt. Kundenspezifische Sonderlayouts sowie Versand/Umsortierung/Übertragung bleiben offen, siehe Menüabgleich.
- Anwendung vor JAR-Ersetzung beendet, paketiert und auf Port 8080 neu gestartet. Health `UP`, Datenbank `CONNECTED`; vier JS-/CSS-Dateien in Build/JAR/HTTP bytegleich. Temporäre Prüftabs, Fixture-Server, wegwerfbare Datenbank und SSH-Verbindung beendet. Der vorhandene Anwendungstab enthält Anmeldeeingaben und wurde deshalb nicht erneut geladen; für die neue Oberfläche ist dort ein Neuladen erforderlich. `git diff --check` erfolgreich.

## Fahrzeugdisposition: Niederlassungswechsel – 15. Oktober 2026

- Frischer SSH-Stand **`93bf782`**, aktuelle FDS und tatsächliche Niederlassungs-/Rechtefunktionen abgeglichen. Angemeldete PHP-UI: Wechsel B → HH am vergangenen Tag 14.10.2026, ausgewählte Niederlassung danach im Menü bestätigt. Keine ursprünglichen lokalen PHP-Quellen und keine automatische Tagesneuanlage.
- Vollständiger Maven-Testlauf gegen wegwerfbare MariaDB 11.4: **571 Tests, 568 bestanden, 0 Fehler, 3 optionale Prüfungen übersprungen**. Gezielter Vorlauf für FDS, Kundentag, Startauswahl und API-Sicherheit erfolgreich. Frontend-Produktionsbuild erfolgreich; bekannter Hinweis zum Hauptbundle > 500 kB. SQL-Architekturprüfung im Testlauf enthalten.
- SQL-Integration: eigenes/anderes/leeres/fremdes HQ, genaue Freigabeliste (8 gegenüber 18), Administratorausnahme nur innerhalb des Mandanten, fehlendes Master-/Dispositionsrecht, mehrdeutige HQ-Zuordnung, entzogene Rechte/Freigabe nach Vorschau, geänderte Benutzer-HQ/-Typ-Zuordnung. Andere Kundennummern und gleichnamige Fahrzeuge bleiben getrennt. Tagesblock, Bemerkung, Unternehmerfreigabe und kundenweite Freigabe mit Audit in Ziel-HQ, einmaligem Vorgangsbeleg und Rollback bei Auditfehler. Wiederholung mit anderer HQ abgelehnt; ursprüngliche Tages-, Parameter-, Auftrags- und Rasterdaten unverändert. Lesende Berechtigungstabellen absichtlich MyISAM getestet.
- HTTP-Tests: Anmeldung, CSRF, zusätzliche HQ-Parameter an Übersicht/Detail/Kundentag/Vorschau, Abweisung fehlenden Masterrechts und ungültiger ID; unveränderte Sitzungsniederlassung. Andere Stamm-/Auftragsdialoge werden im fremden Dispositionskontext nicht angeboten.
- Echte Daten ausschließlich gelesen: neun verfügbare Niederlassungen, 339 Fahrzeuge der geprüften anderen Niederlassung; Sitzungs-HQ unverändert. `user`, `employee`, `headquarters` und `mandatorheadquarters` im echten Bestand InnoDB. Keine echten Geschäfts-, Rechte-, Parameter- oder Schemaänderungen.
- Browser mit synthetischen Daten: eigener Startkunde, Wechsel nach HH mit zurückgesetzten Kunden-/Transporteur-/Zonen-/Textfiltern, eindeutig beschrifteter Fahrzeugtag. Speichern mit verlorener Antwort, gesperrtem Schließen und erfolgreichem erneutem Ergebnisabruf. Kundentag-Freigabe mit Vorschau/Bestätigung und aktualisiertem Tageskennzeichen. Leere Niederlassung zeigt null Fahrzeuge, erneutes Anwenden der eigenen Startauswahl stellt B/Kunde wieder her. Finalen Produktionsbuild neu geladen; erneutes Anwenden derselben Startauswahl und anschließender HQ-Wechsel ebenfalls geprüft. Keine Konsolenwarnungen/-fehler. Prüfbild: `work/fds-niederlassungswechsel-2026-10-15.png`.
- Laufende Anwendung vor JAR-Ersetzung beendet, neu paketiert und auf Port 8080 gestartet. Health `UP`, Datenbank `CONNECTED`; vier JS-/CSS-Dateien in Build/JAR/HTTP bytegleich. Bestehenden lokalen Tab neu geladen, erneute Anmeldung erforderlich. Temporäre Prüftabs, Fixture-Server, Testdatenbank und SSH-Verbindung beendet. `git diff --check` erfolgreich. Umfang und offene Abläufe stehen im Menüabgleich.

## Fahrzeugdisposition: Gruppen und Startauswahl – 15. Oktober 2026

- Frischer SSH-Stand **`93bf782`**, aktuelle Gruppen-/Kundenauswahl und Mitarbeiterparameter gelesen. Alte angemeldete FDS-UI mit vergangenem Datum und geöffnetem Gruppen-/Niederlassungsmenü geprüft. Kein ursprünglicher lokaler PHP-Bestand verwendet, keine automatische Tagesneuanlage ausgelöst.
- Vollständiger Maven-Testlauf gegen wegwerfbare MariaDB 11.4: **567 Tests, 564 bestanden, 0 Fehler, 3 optionale Live-Tests übersprungen**. Frontend-Produktionsbuild erfolgreich, bekannter Bundle-Hinweis > 500 kB. Gezielter Lauf einschließlich bestehender Tagesaktionen und Kundentagssperre ebenfalls erfolgreich.
- SQL-Integration: direkte Gruppenmitgliedschaft (1 gegenüber 11), readonly-/Mandantengrenze, gleiche Gruppennamen, eigene/fremde Kunden, Root-/EXTERN-Ausschluss, Kunden ohne Fahrzeug und leere Gruppen. Eigene Mitarbeiterparameter ohne globalen/anderen Mitarbeiter-/Niederlassungsrückfall, Schreiben beider Schlüssel, Entfernen, Erhalt fremder Schlüssel/Metadaten sowie unveränderte Aufträge/Tagesbestände. Fehler beim abschließenden Vorgangsbeleg rollt beide Parameter und Audit zurück. Speicherwiederholung, veraltete Vorgaben, zwischenzeitliche Gruppen-/Mitarbeiteränderung, ungültige gespeicherte Listenwerte und doppelte Parameter geprüft. Recht 27, Abweisung von Recht 28, Sitzung/CSRF und SQL-Architektur enthalten. Lesende Stammtabellen in der isolierten Prüfung teilweise MyISAM.
- Browser mit synthetischen Daten: Startgruppe/-kunde automatisch angewendet; Wechsel zu leerer und gleichnamiger Gruppe; Kunde ohne Fahrzeug. Speichern nach verlorener Antwort mit gesperrtem Schließen und erfolgreicher Wiederholung. Vollständiges Neuladen stellt Vorgabe wieder her. Konflikt beim Entfernen verlangt Neuladen; danach entfernt. Temporäre Filterwechsel bleiben getrennt von gespeicherter Auswahl, erneutes Anwenden korrekt. Keine Konsolenwarnungen/-fehler. Prüfbild: `work/fds-gruppen-startauswahl-2026-10-15.png`.
- Echte Daten ausschließlich gelesen: persönliche Vorgaben lesbar, zwölf Dispositionsgruppen, 82 Fahrzeuge, geprüfte Gruppe ohne passende Kunden. `groups`, `mandatorheadquarters`, `employee`, `user`, `parameter` und `genericdatacontainer` im echten Bestand InnoDB. Keine realen Parameter-, Kunden-, Fahrzeug-, Auftrags- oder Schemaänderungen.
- Anwendung vor JAR-Ersetzung beendet, geprüftes Frontend paketiert und auf Port 8080 neu gestartet. Health `UP`, Bestandsdatenbank verbunden; vier JS-/CSS-Dateien in Build/JAR/HTTP bytegleich. Bestehenden Anwendungstab neu geladen, Anmeldung erforderlich. Temporäre Prüftabs, Browserfixture, wegwerfbare MariaDB und SSH-Verbindung beendet. `git diff --check` erfolgreich.
- Umfang und weitere Lücken sind im Menüabgleich beschrieben.


## Fahrzeugdisposition: Kundentag und Filter – 15. Oktober 2026

- Frische SSH-Referenz **`93bf782`**, aktuelle FDS-Seite, AJAX-Kundentagesaktion, Fahrzeug- und Bitmaskenhelfer gelesen. Alte angemeldete UI mit vergangenem Datum und geöffnetem Servicefilter geprüft; keine automatische Tagesneuanlage ausgelöst. Kein ursprünglicher lokaler PHP-Bestand verwendet.
- Vollständiger Maven-Testlauf gegen wegwerfbare MariaDB 11.4: **563 Tests, 560 bestanden, 0 Fehler, 3 optionale Live-Tests übersprungen**. Frontend-Produktionsbuild erfolgreich; bekannter Hinweis auf Hauptbundle > 500 kB. Ein anfänglicher Kompilierfehler durch eine in der neuen Testklasse mehrfach zugewiesene Lambda-Variable wurde korrigiert; gezielter und vollständiger Lauf danach erfolgreich.
- SQL-Integration: UND-Servicebits, unbekannte/interne Dienstleistungen, eigener/fremder Transporteur, kundeneigene Zone einschließlich 0, Wochentagsausnahmen, inaktive Fenster, gesperrte Beziehungen sowie Niederlassungs-/Globalfallback für ausgeschlossene Fahrzeuge. Kundentagsvorschau enthält ausgeblendete und gesperrte Fahrzeugbeziehungen. Unverändernde Vorschau, Erhalt höherer Sperrbits/Kapazitäten/Bemerkungen/Aufträge/Raster, Setzen und Aufheben des Kundenkennzeichens, Wiederholung ohne doppeltes Audit, No-op, veralteter Tages-/Beziehungsstand, fehlende/verarbeitete Tage, Vergangenheit, fremde Fahrzeuge und Mitkunden sowie doppelte Kennzeichen geprüft. Fehler beim abschließenden Vorgangsbeleg rollt beide Fahrzeugtage, Kundenkennzeichen und Audits zurück. Recht 27, Abweisung von Recht 28, CSRF und SQL-Architektur im vollständigen Lauf enthalten.
- Isolierter Browser: kombinierte Filter, Zone 0 und Transporteur, Sammelvorschau mit zwei Fahrzeugen trotz einer sichtbaren Fahrzeugzeile, weitere betroffene Kunden, Pflichtbestätigung, verlorene Antwort nach Commit, gesperrtes Schließen und erfolgreiche Wiederholung. Konflikt beim Freigeben verhindert erneutes Speichern bis zum Neuladen; danach erfolgreiche Freigabe. Fehlende Tagesbestände sperren die Sammelaktion. Tageswechsel über Heute und Tastatur geprüft. Abschließend gespeicherte Kundentagssperre sichtbar; keine Konsolenwarnungen/-fehler. Prüfbild ausschließlich mit synthetischen Daten: `work/kundentag-fds-2026-10-15.png`.
- Echte Daten ausschließlich gelesen: neue Filter- und Kundentagsabfragen funktionieren (82 Fahrzeuge, 80 Transporteursoptionen, eine Kundenauswahl, keine zusätzlichen Dienstleistungen). Alle neun hier geprüften Stamm-/FDS-/Vorgabentabellen InnoDB. Keine realen Kunden-, Fahrzeug-, Tages-, Auftrags- oder Schemaänderungen.
- Anwendung vor JAR-Ersetzung beendet, mit finalem Frontend paketiert und auf Port 8080 neu gestartet. Health `UP`, Bestandsdatenbank verbunden, alle vier JS-/CSS-Assets in Build/JAR/HTTP bytegleich. Bestehenden Anwendungstab neu geladen; Anmeldung erforderlich. Temporäre Prüftabs, Browserfixture, wegwerfbare MariaDB und SSH-Verbindung beendet. `git diff --check` erfolgreich.
- Weitere offene Funktionen sind im Menüabgleich aufgeführt.


## Fahrzeugdisposition: Tagessteuerung – 15. Oktober 2026

- Frischer SSH-Stand **`93bf782`**: Dispositionsseite, AJAX-Aktionen und Fahrzeughelfer gelesen. Alte angemeldete Dispositionsseite und Auswahlfenster geprüft; aktuelle Gruppenwahl ohne Fahrzeugzeilen. Kein ursprünglicher lokaler PHP-Bestand verwendet.
- Vollständiger Maven-Testlauf gegen wegwerfbare MariaDB 11.4: **559 Tests, 556 bestanden, 0 Fehler, 3 optionale Live-Tests übersprungen**. Frontend-Produktionsbuild erfolgreich; bekannter Bundle-Hinweis über 500 kB. Eine ungültige zusammengesetzte `var`-Deklaration in der neuen Testklasse wurde vor dem erfolgreichen gezielten und vollständigen Lauf korrigiert.
- SQL-Integration: eigene/fremde Niederlassung und Kundenfilter, unverändernde Vorschau, unabhängige Sperrbits einschließlich Erhalt höherer Bits, Bemerkung mit Zeilenumbruch/HTML als Text, Längenlimit, Vergangenheit, Verarbeitungssperre, veralteter Tages-/Auftragsstand, Rechnung/Export/PHP-Bearbeitung, fremde Reservierung ohne Datenpreisgabe, Mehrfahrzeug- und Mehrtagesfälle, Transporteursfreigabe, vollständiges/abweichendes Raster. Übergabe und Entzug ändern nur passende offene Nicht-Angebotsaufträge; Version, Zuweisung und Audit geprüft. Angenommene Aufträge, Angebote, Zeitraster und Restkapazität bleiben erhalten. Auditfehler rollt Tag und Aufträge zurück; Speicherwiederholung und Missbrauch der Vorgangskennung geprüft. Rechte 27/4/7, CSRF und zentrale SQL-Architektur eingeschlossen. Rechnungstabelle in dieser Prüfung wie im Bestand MyISAM, nur gelesen.
- Browser mit synthetischen Daten: Menüeinstieg, Belegungsleiste und Reservierungen, Freigabe mit Auftragsvorschau und Pflichtbestätigung, verlorene Antwort nach Commit, gesperrte Eingaben/Schließen und erfolgreiche Wiederholung. Tagessperre erhält Unternehmerfreigabe; mehrzeilige Bemerkung gespeichert. Konflikt verwirft keine Eingabe, verlangt Neuladen und nutzt den nativen Entwurfsdialog. Anschließend aktueller Bestand und aktualisierte Übersicht sichtbar. Keine Konsolenwarnungen/-fehler. Prüfbild: `work/fahrzeugdisposition-2026-10-15.jpg`.
- Echte Daten ausschließlich gelesen: 82 Fahrzeuge, eine Kundenauswahl, keine vorhandenen Tageszeilen für den 15.10.2026. `vehicleavailability`, `vehicledisposition`, `job` und `genericdatacontainer` InnoDB; `invoice` MyISAM und ausschließlich lesend. Keine realen Tages-, Auftrags-, Reservierungs-, Schema- oder Freigabeänderungen.
- Anwendung vor JAR-Ersetzung beendet, mit finalem Frontend paketiert und auf Port 8080 neu gestartet. Health `UP`, Datenbank `CONNECTED`, alle vier JS-/CSS-Dateien in Build/JAR/HTTP bytegleich. Vorhandenen Anwendungstab neu geladen; Anmeldung erforderlich. Temporäre Prüftabs, Browserfixture und Testdatenbank beendet. `git diff --check` erfolgreich.
- Umfang, Voraussetzungen und weiterhin offene FDS-Aktionen stehen im Menüabgleich.

## Fahrzeug-Kundenzuordnungen / Einsatzzeiten – 15. Oktober 2026

- Frischer SSH-Stand **`93bf782`**, Zuordnungsmaske, Fahrzeug-/FDS-Helfer, Zeitrasterkonvertierung und 60-Tage-Aktualisierung gelesen. Kein ursprünglicher lokaler PHP-Bestand verwendet. Alte angemeldete Zuordnungsseite für vorhandenes Fahrzeug aufgerufen, HTTP 500; Regeln und UI-Felder zusätzlich im aktuellen PHP geprüft.
- Vollständiger Maven-Testlauf mit wegwerfbarer MariaDB 11.4: **551 Tests, 548 bestanden, 0 Fehler, 3 optionale Live-Tests übersprungen**. Frontend-Produktionsbuild und `git diff --check` erfolgreich; bekannter Hinweis auf Hauptbundle > 500 kB. Im ersten gezielten Lauf betraf ein Fehler nur die Groß-/Kleinschreibung des erwarteten Fehlermeldungstextes; korrigiert, vollständiger Lauf anschließend erfolgreich.
- Datenbankprüfung mit echten SQL-Operationen: eigene/fremde Niederlassung, Standard- und Kundentageszeiten, Zone 0/fremde Zone, Wochenserialisierung und Längenlimit, Sperrstatus, neues 60-Tage-Raster, belegte Abschnitte, Kapazität/Tagessperre/Bemerkung, bestehende Aufträge unverändert. Unvollständiges Raster sowie veraltete Vorschau nach Reservierungs-/Parameter-/Beziehungsänderung verhindern Speicherung. Auditfehler rollt sämtliche Beziehungen, Parameter und FDS-Neuanlagen zurück. Entfernung erhält andere Kunden, fremde Aufträge und Reservierungen desselben Auftrags auf anderem Fahrzeug; Favoriten werden neu nummeriert. Wiederholung nach Commit erzeugt kein zweites Audit und setzt nichts erneut. Sitzung, Recht 1, CSRF und zentrale SQL-Architektur geprüft.
- Browser mit synthetischen Daten: Einstieg über Kurier/Fahrzeug, Wochen-/Zonenänderung, Vorschau, verlorene Antwort nach Speicherung, gesperrte Eingaben und Wiederholung mit derselben Vorgangskennung. Aktualisierte Ausnahmen sichtbar. Mehrfachentfernung mit Auftragsvorschau und anschließender leerer Liste geprüft. Kundensuche, kundenspezifische und Standard-Tageszeitfenster sowie Neuanlage mit anschließend sichtbarer Wochen-Ausnahme geprüft. Finales Wochenraster einschließlich Sonntag vollständig sichtbar; keine Konsolenwarnungen/-fehler. Prüfbild: `work/fahrzeug-kundenzuordnungen-2026-10-15.jpg`.
- Echte Daten ausschließlich gelesen: `customervehicle` und alle drei FDS-Tabellen InnoDB. Globales Raster 20 Zeiteinheiten pro Stunde. Die einzige gefundene Fahrzeug-Kunden-Zuordnung hat ein leeres Tageszeit-Mapping; die neue Ansicht zeigt den Fehler und verhindert fehlerhafte Berechnung. Keine tatsächlichen Beziehungs-, Reservierungs-, Schema- oder Parameteränderungen.
- Laufende Anwendung vor JAR-Ersetzung beendet, mit finalem Frontend paketiert und auf Port 8080 neu gestartet. Health `UP`, Datenbank `CONNECTED`, alle vier JS-/CSS-Dateien in Build/JAR/HTTP bytegleich. Bestehenden Anwendungstab neu geladen; Anmeldung erforderlich. Temporäre Prüftabs, Fixture-Server und Testdatenbank beendet.
- Vollständige grafische FDS-Disposition und übrige Funktionslücken bleiben im Menüabgleich ausdrücklich offen.

## Ortungs-/Freimeldungsprüfung – 15. Oktober 2026

- Frische SSH-Referenz **`93bf782`**, insbesondere `locating_D2.php`, `ranking.inc.php` und Polygonfunktionen. Ausschließlich Serverquellen verwendet. Alte angemeldete UI mit vorher als nicht existent geprüfter Testkennung aufgerufen: HTTP 500. Keine reale Kennung verwendet, weil dieser PHP-GET bereits PLZ/Ranking ändern kann; Regeln deshalb im aktuellen Code geprüft. Der dortige externe LBS-Versand ist auskommentiert.
- Vollständiger Maven-Testlauf gegen disposable MariaDB 11.4: **543 Tests, 540 bestanden, 0 Fehler, 3 optionale Live-Tests übersprungen**. Nach einer abschließenden Hinweistextkorrektur die acht gezielten Ortungs-/Zuweisungstests erneut erfolgreich. Frontend-Produktionsbuild, Paketierung und `git diff --check` erfolgreich; bekannter Hinweis auf Hauptbundle > 500 kB.
- SQL-Integration: unverändernde Vorschau, Rechte 19/4/7, fremde Niederlassung bei gleicher Fahrerkennung, PLZ-Polygone, Mittelpunktmodus, gerichtete Nachbarn und Bereichszuordnung, fehlende Freimeldung, ungültige/alte/zukünftige Position, Offline/Ortung aus, Quellen 0/1/2/3, fehlende vorherige GPS-Ortung und unplausibler Netzwerksprung. Änderungen an Position/Parametern machen Vorschau ungültig. Fehler beim Auditbeleg rollt Kurieränderung zurück; Wiederholung erzeugt weder zweite Rankingzeit noch zweites Audit. Auditoperation 27 und LRANK geprüft. HTTP-Zugriffs- und SQL-Architekturtests im vollständigen Lauf enthalten.
- Isolierter Browser: Vorschau mit PLZ/Ortungsalter/Nachbarschaft, Pflichtbestätigung, simuliert verlorene Antwort nach Speicherung, gesperrtes Schließen/Neuladen, erfolgreiche Wiederholung und aktualisierte Freimeldung. Anschließend unveränderndes Prüfergebnis; veraltete Position verhindert Übernahme. Keine Konsolenwarnungen/-fehler. Prüfbild ausschließlich mit synthetischen Daten: `work/ortungspruefung-2026-10-15.jpg`.
- Echte Daten ausschließlich gelesen. Ein synthetischer Berliner Prüfpunkt liefert im Polygonmodus **10117**, im PHP-kompatiblen Mittelpunktmodus **10179**. Benötigte Geometrietabellen und `phoenix_log.locating` sind MyISAM; hier ausschließlich lesend verwendet. Keine realen Freimeldungs-/Rankingänderungen, Endgerätebefehle oder Schemaänderungen zur Prüfung.
- Laufende Anwendung vor Ersetzung des JAR beendet und mit geprüftem Paket auf Port 8080 neu gestartet. Health `UP`, Datenbank `CONNECTED`, alle vier JS-/CSS-Dateien in Build/JAR/HTTP bytegleich. Bestehenden Anwendungstab neu geladen; Anmeldung erforderlich. Temporäre Prüftabs, Fixture-Server und Testdatenbank beendet.
- Funktionsumfang, bewusst strengere Plausibilitätsregeln und übrige Lücken siehe `MENUE-ABGLEICH.md`. Vollständige Kandidatenrangliste/Ablehnungskarte und Kundenzugangskarten bleiben offen.

## Karten-Zuweisung – 15. Oktober 2026

- PHP-Referenz per SSH erneut `93bf782`, alte angemeldete Kartenoberfläche geöffnet. Aktueller `job_courier.inc.php`, `ajaxReqMap.php`, Ranking-/Länderlogik sowie die tatsächlichen Schreibwirkungen von `locating_D2.php` gelesen. Keine Nutzung des ursprünglichen lokalen PHP-Stands.
- Abschließender vollständiger Maven-Lauf gegen wegwerfbare MariaDB 11.4: **536 Tests, 533 bestanden, 0 Fehler, 3 optionale Live-Tests übersprungen**. Frontend-Produktionsbuild und `git diff --check` erfolgreich. Bekannter Hinweis auf Hauptbundle > 500 kB. Ein früher Testfehler betraf die erwartete Ausnahmeformulierung, ein weiterer eine fehlende Pflichtspalte im neu ergänzten Testkurier; beide behoben und vollständigen Lauf wiederholt.
- Neue SQL-Integrationsprüfungen: unverändernde Vorschau, Rechte/HQ/Fahrzeuggrenzen, veralteter Fahrzeugstand, Kundensperre/globaler Parameterfallback, optionale/verbindliche Laderaumprüfung, exakte Pflichtfilter, Offline/Angebot/BWV-Sperren, gerichtete und nicht transitive PLZ-Nachbarn, eigene/fremde Bereichszuordnung, Rollback bei Belegfehler, wiederholte Anfrage ohne zweite Änderung, Autoranking-Werte, Audit mit Zielkurier/Rankingfolge und einmaliger Rückrufbefehl an den bisherigen Kurier. Zwei verbleibende Aufträge halten dessen Belegtmeldung korrekt auf 1. HTTP-Rechte und CSRF-Einbindung geprüft.
- Browser mit isolierten synthetischen Daten: Auftrag laden, Kurier wählen, Vorschau, Hinweisbestätigung vor Freigabe, simuliert verlorene Antwort nach Speicherung, erneuter Ergebnisabruf mit derselben Vorgangskennung, Erfolgsmeldung/aktualisierte laufende Aufträge und Sperre der erneuten gleichen Zuweisung. Finaler Frontend-Build neu geladen, keine Konsolenwarnungen/-fehler. Prüfbild: `work/karten-zuweisung-vorschau-2026-10-15.jpg`.
- Echte Daten ausschließlich gelesen: beteiligte Schreibtabellen `job`, `courier`, `autoranking`, `genericdatacontainer`, `phoenix_pda.commandexec` sind InnoDB; `customercourier` bleibt MyISAM und wird hier nur gelesen. Keine reale Zuweisung, Geräte-/Ortungsanforderung oder Schemaänderung zur Prüfung.
- Laufende Anwendung vor JAR-Ersetzung beendet; neues Paket auf Port 8080 gestartet. Health `UP`, Datenbank `CONNECTED`, alle vier JS-/CSS-Assets von Build/JAR/HTTP bytegleich. Vorhandenen Browser-Tab neu geladen; erneute Anmeldung erforderlich. Temporäre Prüftabs, Fixture-Server und Testdatenbank beendet.
- Umfang und verbleibende Karten-/Menülücken stehen in `MENUE-ABGLEICH.md`. Die damals noch offene Ranking-/Freimeldungsprüfung hinter dem alten Link „Neue Ortung“ ist inzwischen ergänzt, siehe oben; die dortige externe LBS-Anforderung ist im aktuellen PHP-Code auskommentiert.

## Kartenübersicht – 15. Oktober 2026

- Frischer PHP-Serverstand **`93bf782`**, alte angemeldete Kartenoberfläche, Kartenabfragen und ihre Ranking-/Ortungsbezüge geprüft. Ausschließlich aktuelle SSH-Quellen verwendet.
- Vollständiger Maven-Testlauf mit isolierter MariaDB 11.4: **533 Tests, 530 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Frontend-Produktionsbuild erfolgreich. Kartenbibliothek als separater, erst beim Öffnen geladener Teil; bekannter Hinweis auf das übrige Hauptbundle über 500 kB bleibt.
- Echte SQL-Abfragen im isolierten Schema mit MyISAM-Stammtabellen: eigene/fremde Niederlassungen, gleiche Fahrerkennung in zwei Niederlassungen, heutige/alte/genau mitternächtliche Ortung, zukünftige Zeit, Typ 0/9, fehlende Koordinaten, aktive/angebotene/abgeschlossene/stornierte/fremde Aufträge, Kundentypen bei Fahrzeugbezeichnungen, Lagergrenzen, fremde Stationen, fehlende Adressverknüpfung und Normalisierung D→DE. Positionsbewegung und Wegfall beim nächsten Abruf geprüft. Zugriff und Geokodierung gehen ausschließlich über `DatabaseService` bzw. den bestehenden Routendienst.
- HTTP-Tests für Anmeldung, eigenes Kartenrecht 19, zusätzliches Auftragsrecht 4, Sichtbarkeit des Menüpunktes und korrekte Kachelkonfiguration. Ungültige Koordinaten/Kachelvorlagen und Übergrenze ohne unvollständiges Ergebnis separat geprüft. Der Kartenservice führt keine Schreibtransaktion aus.
- Reale Datenbank ausschließlich gelesen: Abfragen funktionieren, am Prüfzeitpunkt keine heutigen Ortungen und keine Lageradressen in der geprüften Niederlassung; zentrale Position vorhanden. Datenbank- und PHP-Serveruhr auf gleiche lokale Zeit geprüft. Keine neue Ortung, Endgerätenachricht, E-Mail oder Schemaänderung.
- Browser mit isolierten synthetischen Antworten: heutige gültige/ungültige/ausgeschaltete/alte Positionen, Filter, Details, laufende Aufträge, native Auftragsdialog-Navigation, Zentrale, Lager, Stationskarte, Fehlerhinweise und erfolgreiche Wiederholung einer kurzzeitig ausgefallenen Geokodierung. Überlagerte Marker werden gemeinsam auswählbar; Auswahl des gewünschten Transporteurs aus drei Punkten geprüft. Die Karte wurde nach dem finalen Build neu geladen, Konsole ohne Warnungen/Fehler. Prüfbild: `work/kartenuebersicht-2026-10-15.jpg`. Die synthetische Auftragsfixture enthält keinen vollständigen Auftrag 101; beim Navigationstest deshalb nur korrekten Dialog-/Endpunktaufruf geprüft, keine Speicherung.
- Lokales Paket mit dem fertigen Frontend auf Port 8080 gestartet; Healthcheck `UP`, Datenbank `CONNECTED`, ausgelieferte JS-/CSS-Dateien identisch mit Build/JAR. Temporäre Prüftabs, Testserver und disposable MariaDB nach Abschluss beendet.
- Der ursprüngliche Kartenabruf bleibt lesend. Die später ergänzte explizite Zuweisung ist im folgenden Prüfstand beschrieben; weitere Lücken siehe Menüabgleich.

## PZM-Preisvergleich – 14. Oktober 2026

- Frische SSH-Referenz **`0702d0c`**, angemeldete PHP-Auswertung Modus 19 und aktueller `ajaxReqKmPrice.php` geprüft. Kein ursprünglicher lokaler PHP-Bestand verwendet.
- Vollständiger Maven-Lauf mit isolierter MariaDB 11.4 plus gezielter Abschlusslauf nach Ergänzung der Export-Standprüfung: **526 Tests, 523 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Frontend-Produktionsbuild und SQL-Architekturprüfung erfolgreich; bekannter Bundle-Hinweis über 500 kB. Ein zwischenzeitlicher Testfehler betraf nur die erwartete Formulierung „anderen Auswahl“; korrigiert und erneut erfolgreich ausgeführt.
- Zwei getrennte Testdatenbanken mit unterschiedlichen internen Kunden-IDs: Zuordnung über EID/HQ, abgeschlossene/vollständige Aufträge, Storno, Exportunabhängigkeit, fremde Kunden-/Auftragsniederlassungen, beide Datumsgrenzen bis einschließlich Sekundenbruchteilen. Unbekannter Kunde, Maximalmenge, ungültige Stationen, LKW-Ausnahme, bepreiste/unbepreiste An-/Abfahrten, Vergleich ohne Übernahmerundung und spezielle PHP-Rabattregel.
- Benutzer-/HQ-Bindung, Recht 46 und CSRF, abgelaufene Ergebnisse, idempotenter Start, konkurrierende/erneute Zeilenanfragen, verlorene Antwort ohne erneute Kalkulation sowie CSV aus dem gespeicherten Ergebnis. Export eines veralteten Browserstands wird abgewiesen. Separate SQL-Quelle verweigert UPDATE, mehrere Statements, FOR UPDATE und INTO OUTFILE. Geschäftsdatensätze der Testquelle bleiben unverändert.
- Echter Bestand ausschließlich lesend: Auftragsquelle `172.16.0.203:3391/phoenix` erreichbar. Sie benötigt einen SELECT-Zugang ohne modernes `SET TRANSACTION READ ONLY`, das diese ältere Datenbank nicht unterstützt. Geprüfter gemeinsamer Kunde: Auftrag **22617875**, 14.10.2026, PHP und NG jeweils **58,41 € / 14,66 km**. Keine echten Auftrags-, Preis-, Kunden- oder Schemaänderungen.
- Isolierter Browser: Menü/Kundenauswahl, berechnete Zeile mit Detailkalkulation, fehlerhafte Stationsposition, übersprungener LKW, verlorene Antwort und Fortsetzung, Pause nach laufendem Auftrag, veralteter Exportstand. CSV heruntergeladen und bytegleich zum Backend-Export. Die erste Exportprüfung traf nach unterdrücktem Neuladen noch den vorherigen Build; nach Schließen der Ansicht und Laden des aktuellen Builds erfolgreich. Prüfbild: `work/pzm-preisvergleich-2026-10-14.jpg` mit ausschließlich synthetischen Daten.
- Anwendung vor JAR-Ersetzung beendet, neu paketiert und auf Port 8080 gestartet. Health `UP`, primäre Datenbank verbunden; finale HTTP-/JAR-/Frontend-Assets bytegleich. Separate Vergleichsquelle bereits erfolgreich lesend geprüft. Vorhandenen Anwendungstab aktualisiert; erneute Anmeldung ist erforderlich. Temporäre Datenbank und Browserfixture nach Abschluss beendet.
- Umfang und Lebensdauer des Vergleichs sowie weitere offene Bereiche stehen im Menüabgleich. Stichprobenparität ist kein Nachweis aller Tarif-/Adresskonstellationen.

## PZM-Zonen und BWV-Einstellungen – 14. Oktober 2026

- Frische SSH-Referenz **`3a4fdeb`**, angemeldete PHP-Oberflächen der Modi 18/20 und tatsächliches Zonen-API-Format geprüft. Kein ursprünglicher lokaler PHP-Stand verwendet.
- Abschließender Maven-Testlauf mit isolierter MariaDB 11.4: **520 Tests, 517 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Frontend-Produktionsbuild, SQL-Architekturprüfung und `git diff --check` erfolgreich. Bekannter Bundle-Hinweis über 500 kB. Ein zwischenzeitlicher Einzellauf fand fehlerhafte inkrementelle Testklassen; nach Entfernen ausschließlich der kompilierten Klassen und vollständiger Neukompilierung war der gesamte Lauf erfolgreich.
- Parameterpflege: exakte Schlüssel einschließlich Leerzeichen/Punkt bei Fahrzeugen, eigene/globale Geltung, Erhalt lokaler Suchradius-Vorgaben und Beschreibungen, leere optionale Werte, Komma/Punkt, positiver Radius, ungültige/mehrdeutige Werte, erlaubte Schalter, veraltete Revision/Vorschau, Rechtegrenzen und CSRF, wiederholte Speicherung und vollständiger Rollback bei Auditfehler.
- PZM-Dienst über lokalen HTTP-Testserver: EAP-Invertierung, Zonenbezeichnungen, vollständige Kunden-ID bei Rundungsausnahmen, kein Schreiben durch Vorschau, dauerhafter Plan vor API-Aufruf, simulierte verlorene Antwort nach externer Änderung, Fortsetzung ohne erneuten POST, Sperre neuer Vorgänge, Bindung an ursprünglichen Bearbeiter, externer Erfolg mit anschließendem Auditfehler, Wiederholung abgeschlossener Vorgänge und veraltete Zonenrevision. Bestätigte Zonenänderung invalidiert native Routen-Caches.
- Echter Bestand ausschließlich gelesen: 3 PZM-Vorgaben, 3 Zonen, 18 BWV-Felder; alle wie in PHP. 11 lokale Suchradius-Übersteuerungen erkannt. Keine realen Parameter-, Auftrags-, Zonen- oder Schemaänderungen und kein Versand.
- Isolierter Browser: beide Menüeinträge, 18 BWV-Felder, Radiusvalidierung, Entwurf behalten, globale Vorschau, simulierte verlorene Antwort mit Schließsperre und erfolgreicher Wiederholung, erneut geladener Testwert 50. Alle drei PZM-Schalter, Zonenschalter, Kundenausnahmen, Vorschau und wiederholbarer Zonenabschluss geprüft. Keine Browserwarnungen/-fehler. Prüfbilder: `work/bwv-settings-2026-10-14.png`, `work/pzm-zones-2026-10-14.png` (synthetische Daten).
- Paketierung mit `verify -DskipTests` nach erfolgreichem Testlauf; bisherige Anwendung vor JAR-Ersetzung beendet und auf Port 8080 neu gestartet. Health `UP`, Datenbank verbunden, HTTP-/JAR-/Build-Assets bytegleich. Vorhandenen Anwendungstab aktualisiert. Temporäre Testtabs und lokale DB-/UI-Testumgebung beendet.
- Grenzen der externen API, BWV-Konfigurationsumfang und weiterhin offene Bereiche stehen im Menüabgleich.

## Mail-Verteiler und Vorlaufzeit-Zuschläge – 14. Oktober 2026

- Frische SSH-Referenz **`24094e2`** und angemeldete PHP-Oberfläche Modus 13 geprüft. Kein ursprünglicher lokaler PHP-Bestand verwendet.
- Maven-Tests mit isolierter MariaDB 11.4: **506 Tests, 503 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Frontend-Produktionsbuild und SQL-Architekturprüfung erfolgreich; bekannter Hinweis auf Bundle über 500 kB. Eine zunächst fehlerhafte SQL-Testfixture mit ungebundenem Semikolon wurde auf einen gebundenen Wert korrigiert; danach vollständiger Testlauf erfolgreich.
- Regeln/DB: Nachtfenster, 24:00 nur als Ende, ganze Minuten 0–999, fehlende und ungültige Altwerte, doppelte/abweichend zugeordnete Parameter. Lokale/leere Verteilerübersteuerung, fremde Niederlassung, globale Duplikate, ausgeschlossene/geschützte Mail-Parameter, CSV mit Formelschutz. Rechte 2/46 und CSRF, unverändernde Vorschau, Beschreibungs-/Fremdparametererhalt, gemeinsame Geltung über Niederlassungen, Revision bei Textänderung, Rollback beim zweiten Parameter bzw. Auditfehler, verlorene Antwort nach Commit und zwei konkurrierende Schreiber.
- Reale Datenbank ausschließlich lesend: **21 Verteiler**, wie PHP; ca. 0,30 Sekunden einschließlich globaler Vorgaben. Wochenendwert `Absolut_kuerzeste` als ungültig markiert. Keine echten Parameter-/Auftragsänderungen, Nachrichten oder Schemaänderungen.
- Isolierte Browserfixture: Verteilerfilter, vollständiger CSV trotz Filter (bytegleich zum Backend), Bestandswarnung, Ablehnung ungültiger Minuten, Entwurf behalten, Vorschau mit globalem Geltungsbereich, simulierte verlorene Speicherantwort, Schließsperre und erfolgreiche Wiederholung. Danach erneut geöffnet: korrigierter Testwert 60, unveränderte übrige Werte, keine Bestandswarnung. Keine Konsolenwarnungen/-fehler. Prüfbild: `work/mail-vorlaufzeiten-2026-10-14.png`.
- Paketierung mit `verify -DskipTests` nach erfolgreichem Testlauf abgeschlossen. Anwendung um 17:35 Uhr auf Port 8080 neu gestartet. Healthcheck `UP`, Datenbank verbunden; HTTP-/JAR-Assets bytegleich mit Frontend-Build. Vorhandenen Anwendungstab aktualisiert. Temporäre UI-/DB-Testumgebung und Prüftabs beendet.
- Umfang/Grenzen und verbleibende Bereiche sind im Menüabgleich dokumentiert.

## Kundenmasken und Kundenzugang-Listenerweiterungen – 14. Oktober 2026

- Frische SSH-Referenz **`24094e2`**; beide angemeldeten PHP-Listen, Schreibendpunkt und tatsächliche Parameterverbraucher abgeglichen. Kein ursprünglicher lokaler PHP-Bestand verwendet.
- Maven-Tests mit isolierter MariaDB 11.4: **491 Tests, 488 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Frontend-Produktionsbuild, SQL-Architekturprüfung und `git diff --check` erfolgreich. Bekannter Bundle-Hinweis über 500 kB.
- Neue Prüfungen: Kunden-/Loginumfang einschließlich ausgeblendeter Kunden, gesperrter Erfassung und leerer Logins; eigene/fremde Niederlassungen, Rechte 0/2/46 und CSRF. Unterschied `par_text`/`par_value`, inaktive Schalter, gemeinsame Kundenflags und getrennte Loginflags, Erhalt fremder Kundenlistenmitglieder/Parametertexte/Spalten, leere Vorgaben und Login-HQ-Rückfall. Fehlende oder doppelte Spalten, doppelte Parameter und abweichende Geltungsbereiche. Veraltete Zuordnung/Kundenrevision/Vorschau, Rollback nach zweitem Spaltenschreibzugriff und Auditfehler, Wiederholung nach Commit mit verlorener Antwort sowie zwei konkurrierende Schreiber. Referenzierte Tabellen in der isolierten Prüfung bewusst MyISAM, nur Parameter/Belege InnoDB.
- Reale Datenbank ausschließlich gelesen: **1.365 Masken, 6.030 Logins**, entsprechend alter PHP-UI; ca. 0,74 bzw. 0,32 Sekunden. Fünf Masken mit doppelten Vorgaben gekennzeichnet, keine Loginwarnungen. Einzelansichten und Revisionen geladen. Keine Geschäftsdaten- oder Schemaänderungen.
- Isolierte Browserfixture: Loginfilter, Kunden-/Login-Geltungsbereiche, Änderungen mit Vorschau, Entwurf behalten, verlorene Speicherantwort mit gesperrtem Schließen und erfolgreicher Wiederholung. Gespeicherten Ort und Schalter erneut geladen; andere Zusatzspalten und zweiter Login bleiben erhalten. Lademaße nicht editierbar, Hinweis auf derzeit inaktive manuelle Disposition sichtbar. Beide CSV-Dateien heruntergeladen und bytegleich zu Backend-Exporten. Keine Konsolenwarnungen/-fehler. Prüfbild: `work/kundenzugang-2026-10-14.png`.
- Paketierung mit Maven `verify -DskipTests` nach den erfolgreichen Tests abgeschlossen. Anwendung um 16:57 Uhr auf Port 8080 neu gestartet; Healthcheck `UP`, Datenbankverbindung und bytegleiche JAR-/HTTP-/Build-Assets geprüft. Vorhandenen Anwendungstab aktualisiert.
- Umfang ist die native Pflege der bestehenden Kundenzugangsvorgaben. Offene Funktionsbereiche bleiben im Menüabgleich ausgewiesen.

## Sonderkonditionen und getnow – 14. Oktober 2026

- Frische SSH-Referenz **`24094e2`**; beide angemeldeten PHP-Auswertungen, Verknüpfungen zu den Tarifmasken sowie die Ankunftsdefinition in Stationshistorie/Scan-Ereignissen geprüft. Kein ursprünglicher lokaler PHP-Bestand verwendet.
- Abschließendes Maven `verify` mit isolierter MariaDB 11.4: **481 Tests, 478 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Frontend-Produktionsbuild, SQL-Architekturprüfung und `git diff --check` erfolgreich. Bekannter Hinweis auf Frontend-Bundle über 500 kB.
- Neue DB-Prüfungen: sämtliche Sonderkonditionskennzeichen, zukünftige/negative/verwaiste Tarife, Abrechnungstypen, gesperrte/ausgeblendete/archivierte Kunden, gleiche externe Kundennummern, fremde Niederlassungen, fehlende/fremde Transporteure und Grenze von 5000 Zeilen. Unabhängige Rechte für Auswertung und Zielmasken. getnow mit echten Ankunftsfeldnamen, fremden Zusatzdaten, doppelten/ungültigen Ankünften, Randsekunden, Storno-/offenen Aufträgen, negativen Zeiten, Mitternacht und 26 Stunden. Hilfsdaten/Koordinaten werden nicht ausgegeben. CSV mit UTF-8, Formelpräfixschutz und vollständigen Hinweisfeldern.
- Realer Bestand ausschließlich gelesen: **443 Sonderkonditionskunden** wie in der alten UI, Abfrage ca. 0,8 Sekunden. getnow-Stichprobe: fünf echte Ankunftszeilen, ca. 0,1 Sekunden, keine Datenwarnungen. Alte PHP-Seite gibt dieselben fünf Aufträge wegen weiterer Zusatzdatensätze jeweils doppelt aus und erzeugt dabei falsche Fahrzeiten. Eine zuerst zu breit angelegte Suche nach einer passenden Bestandsstichprobe lief in den Timeout; die anschließende begrenzte Stichprobensuche und die eigentliche Kunden-/Datumsabfrage waren erfolgreich.
- Isolierte Browserfixture: alle sieben Ziele (Servicepreis, Frachtvergütung, Calculator, PLZ, Bereich, Provision, Kundenstamm) mit Kundenvorbelegung geprüft. Synthetischen Servicepreis geändert, Entwurf behalten, verlorene Speicherantwort simuliert, Schließen bis zur Wiederholung gesperrt, gespeicherten Wert nach erneutem Öffnen geprüft. getnow mit acht Testzeilen einschließlich Fehlerhinweisen, Auftragsöffnung und Rückkehr. Beide CSV-Dateien im Browser heruntergeladen und bytegleich zu Backend-Exporten. Keine Konsolenwarnungen/-fehler. Prüfbilder: `work/sonderkonditionen-2026-10-14.png`, `work/getnow-2026-10-14.png`.
- Anwendung um **16:38 Uhr** auf Port 8080 neu gestartet. Healthcheck `UP`, Bestandsdatenbank verbunden, JAR-/HTTP-JS und CSS bytegleich mit Produktionsbuild. Vorhandenen Anwendungstab aktualisiert; temporäre Browser- und DB-Testumgebung beendet.
- Keine realen Tarif-/Kunden-/Auftragsschreibtests, keine Schemaänderungen oder Nachrichten. Die übrigen Funktionslücken bleiben im Menüabgleich separat offen.


## Beweisfoto-Vorgaben und Servicepreis-Ausweis – 14. Oktober 2026

- Aktuelle SSH-Referenz **`24094e2`**; beide alten Einstellungsseiten und die aktuelle Kunden-/Stations-/Rechnungscode-Logik abgeglichen. Kein früherer lokaler PHP-Stand verwendet.
- Abschließendes Maven `verify` mit isolierter MariaDB 11.4: **478 Tests, 475 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Frontend-Produktionsbuild, SQL-Architekturprüfung und `git diff --check` erfolgreich; bekannter Hinweis auf das Frontend-Bundle über 500 kB.
- Neue Prüfungen: vier Fotomodi, Kann-/Muss-Mengen, fehlende/ungültige Mengen, Minimal-/Maximalgrenzen, verwaiste/doppelte Parameter, Geltungsbereich, inaktiver Servicepreis-Wert, Entfernen bei allgemeinem Ausweis, siebenstellige Kunden-ID, eigene/fremde Niederlassungen, getrennte Lese-/Schreibrechte und CSRF. Vorschau ohne Schreibzugriff, Erhalt von Texten/fremden Parametern, veraltete Revision/Vorschau, Rollback beim zweiten Parameter bzw. Auditfehler, Wiederholung nach Commit mit verlorener Antwort und zwei gleichzeitige Schreiber geprüft.
- Realer Bestand ausschließlich lesend: Parameter und Vorgangsbelege sind InnoDB. 24 Foto-Konfigurationen samt Einzelansichten erfolgreich gelesen, keine ungültigen Vorgaben; Servicepreis-Liste der geprüften Niederlassung leer. Eine zunächst zu langsame korrelierte Listenabfrage wurde durch eine gezielte Parameterabfrage ersetzt und erneut erfolgreich geprüft. Keine Geschäftsdaten-/Schemaänderungen.
- Browserfixture mit synthetischen Daten: Liste mit gesperrten/gleichzeitig für Zentrale und Kunde geltenden Vorgaben; Bearbeiten, ungültiges Minimum, Entwurf behalten, Vorschau, absichtlich verlorene Speicherantwort und erfolgreiche Wiederholung; Kundensuche, Neuanlage und Entfernen; allgemeiner Servicepreis-Hinweis und kundenspezifisches Entfernen. Gespeicherte Vorgabe nach Neuladen geprüft, CSV im Browser heruntergeladen und bytegleich zum Backend-Export. Keine Konsolenwarnungen/-fehler. Prüfbild: `work/kundenvorgaben-2026-10-14.png`.
- Anwendung mit geprüftem JAR auf Port 8080 neu gestartet. Healthcheck `UP`, Produktions-JS/CSS bytegleich. Vorhandener Anwendungstab aktualisiert; temporäre Prüftabs, UI-Testserver und disposable Datenbank beendet.
- Umfang ist die Konfigurationspflege der beiden bestehenden Verfahren. Die neue Erfassung verwendet Foto-Workflow-Sets; vollständige native Rechnungserstellung und die übrigen Restpunkte bleiben im Menüabgleich offen.


## Dauerauftragsübersicht und Kalender – 14. Oktober 2026

- Frische SSH-Referenz **`24094e2`**, alte Dauerauftragsliste und Historienumschaltung im Browser gelesen. Ausschließlich aktuelle Serverquellen verwendet. Leere aktuelle PHP-Liste offen berücksichtigt; keine künstlichen Aufträge im realen Bestand angelegt.
- Abschließendes Maven `verify` mit isolierter MariaDB 11.4: **465 Tests, 462 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Frontend-Produktionsbuild, SQL-Architekturprüfung und `git diff --check` erfolgreich. Bekannter Hinweis auf Frontend-Bundle über 500 kB.
- Neue Datenbank-/Regeltests für aktive Serien, Stichtags-/Endgrenzen, Status/Gutschriften, bereits verknüpfte Nachfolger, eigene/fremde Kunden/Niederlassungen, Barzahler, fehlendes Recht 46 und Kalender ohne Auftragsrecht 4. Rhythmen 1–11 zusammen mit vorhandenen Serientests, Feiertagsfolgen, Jahres-/Monatswechsel, Vorwärts-/Rückwärtsverschiebung, Historienbeginn inklusive 1. Januar, ungültige Wochentage und Kalenderjahre, leere Kalender und sichere Beendigung ohne künftige Feiertage. Enddatum um 00:00 gegenüber 23:59:59 ausdrücklich geprüft. Mehrdeutige und zyklische Vorgängerketten werden abgewiesen. Bestehende HTTP-Rechtetests um Kalenderendpunkt erweitert.
- Echte Datenbank ausschließlich lesend über `DatabaseService`: aktueller Stichtag liefert null Aufträge für den geprüften Kunden; mit Stichtag 01.02.2025 ist dessen vorhandener Vierwochenauftrag sichtbar. Kalender 2025 liefert **12 Termine und 18 Vorgänger**, ohne Schema-/Geschäftsdatenänderung.
- Isolierter Browsertest: Kunde und Stichtag wählen, Kalender öffnen, Feiertagsverschiebung vom 21./22. auf den 23. Oktober, Tagesdetails, Historie einblenden, aktuellen Auftrag öffnen und zum unveränderten Kalender zurückkehren. Historisches Kalenderjahr 2025 mit Markierung am 1. Januar, Folgejahr 2027 ohne Termine nach Serienende. Native Datumsänderung mit Hinweis auf vorherige Auswahl und anschließend leerem Ergebnis. CSV heruntergeladen und bytegleich mit Backend-Export. Keine Konsolenwarnungen/-fehler. Prüfbild mit synthetischen Daten: `work/dauerauftragskalender-2026-10-14.png`.
- Anwendung mit abschließendem JAR auf Port 8080 neu gestartet; Healthcheck, Datenbankverbindung und bytegleiche Produktionsassets geprüft. Vorhandenen Anwendungstab neu geladen; temporäre Prüftabs, UI-Testserver und disposable MariaDB beendet.
- Kalender ist eine lesende Vorschau, keine zweite Hintergrundverarbeitung. Weitere Funktionslücken stehen im Menüabgleich.

## Gespeicherte Touren: Verwaltung – 14. Oktober 2026

- Frische SSH-Referenz **`24094e2`**, alte `jb_special.php`-Oberfläche mit Checkboxen, Mehrfachlöschung und Bearbeitungslinks lesend geprüft. Keine früheren lokalen PHP-Quellen verwendet.
- Abschließendes Maven `verify` mit isolierter MariaDB 11.4: **458 Tests, 455 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Frontend-Produktionsbuild, SQL-Architekturprüfung und `git diff --check` erfolgreich. Bekannter Hinweis auf Frontend-Bundle über 500 kB.
- Integration mit echter isolierter MariaDB: Umbenennen einschließlich Leerzeichenbereinigung, keine Änderung bei identischem Namen, Vorschau ohne Schreibvorgang, Auftrags-/Stations-/Preiserhalt auch für exportierte Aufträge, Rechte 4/7/46 einzeln, eigene/fremde Niederlassungen und Kunden, Barzahlerzuordnung, ungültige Namen/Mehrfachauswahl, doppelte IDs und 200er-Grenze. Veraltete Revision/Vorschau, nicht versionierte PHP-Namensänderung, aktive/abgelaufene PHP-Sperre und konfigurierbare Sperrdauer geprüft. Bei fehlgeschlagenem zweiten Audit werden beide Änderungen zurückgerollt. Wiederholung nach erfolgreichem Commit mit verlorener Antwort erzeugt keine zweite Änderung/Audit; parallele konkurrierende Vorgänge lassen genau einen Schreiber durch. Sitzung/CSRF und zusätzliche Bearbeitungsrechte per HTTP geprüft. Interne Revisions-/Zahlerdaten erscheinen nicht im CSV; rohe Revisionsbestandteile werden nicht über die Tourenliste ausgegeben.
- Reale Datenbank ausschließlich lesend über `DatabaseService`: benötigte Tabellen `job`, `genericdatacontainer`, `headquarters` sind InnoDB. Zehn Vorlagen des zuvor in PHP geprüften Kunden geladen, Revisionskennung und unverändernde Umbenennungsvorschau erfolgreich. Keine reale Umbenennung oder Entfernung durchgeführt.
- Browserfixture `127.0.0.1:18744`: Kunden-Konserven → Tourenliste, Umbenennung mit Vorschau, absichtlich nach Speicherung unterbrochene Antwort, gesperrtes Schließen und erfolgreiche Wiederholung. Entwurf behalten/verwerfen, direkter Auftragseditor und Rückkehr, Seitenauswahl mit Einzelabwahlen, Zwei-Konserven-Vorschau/-Entfernung und aktualisierte Liste geprüft. Keine Konsolenwarnungen/-fehler. Sämtliche Teständerungen nur im Arbeitsspeicher der Fixture. Prüfbilder: `work/konservenverwaltung-2026-10-14.png`, `work/konservenverwaltung-ergebnis-2026-10-14.png`.
- Anwendung mit geprüftem JAR auf Port 8080 neu gestartet; Healthcheck, Datenbankverbindung und bytegleiche Auslieferung der Produktionsassets geprüft. Vorhandenen Anwendungstab neu geladen. Temporäre Prüftabs, UI-Testserver und disposable MariaDB beendet.
- Keine Testschreibvorgänge gegen Geschäftsdaten, keine Schemaänderung, keine Nachrichten. Dauerauftragskalender/-historie wurden anschließend ergänzt (siehe oben); weitere Sonderfunktionen bleiben im Menüabgleich offen.

## Kessel Buntes: Bestandsübersichten und Konservennutzung – 14. Oktober 2026

- Aktuelle SSH-Referenz **`24094e2`**; alte Transporteursliste, Auslandsrechnungen, Kunden-Konserven, Konservennutzung und verlinkte Tourenliste im angemeldeten Browser gelesen. Ausschließlich frische Serverquellen verwendet.
- Vollständiges Maven `verify` mit isolierter MariaDB 11.4: **456 Tests, 453 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Frontend-Produktionsbuild, SQL-Architekturprüfung und `git diff --check` erfolgreich. Bekannter Hinweis auf Frontend-Bundle über 500 kB.
- Neue echte Datenbankprüfungen: eigene/fremde Niederlassung, fehlendes Recht 46, falsche/fehlende Kunden, Zeitraumgrenzen, fehlende Datumsfilter bei Bestandslisten, doppelte Zahler-/Barzahlerzuordnung, gleichnamige und entfernte Konserven, null Nutzungen, mehrere Historieneinträge pro Auftrag, Stichtag/zulässige Logaktionen, Groß-/Kleinschreibung und unvollständige Logtexte. Unvollständige Aufträge, doppelte Stationsposition, mehrere Fahrzeuge, Geräteparser, Beziehungscode im alten TINYINT(1)-Format, ausländische Hauptkostenstellen-Rechnungsadressen und führende Nullen geprüft. Latin-1-Fahrzeugtypbezeichnungen mit aktuellem UTF-8-Verbindungszeichensatz als Regressionstest. 5000-Zeilen-Grenze und CSV-Formelschutz einschließlich Ausschluss interner Kunden-IDs geprüft.
- Echte Bestandsdaten ausschließlich über `DatabaseService` gelesen: **339 Transporteurzeilen**, **21 Auslandsanschriften**, **694 Kunden mit Konserven**. Beim in der PHP-UI geprüften Kunden ergeben Tourenliste und Nutzungsstatistik dieselben zehn Vorlagen; im gewählten Septemberzeitraum ohne Nutzungen. Nichtleere Nutzungsfälle werden mit synthetischer Historie in der Testdatenbank abgedeckt. Beim Abgleich erkannte Schema-/Kollationsunterschiede vor Abschluss korrigiert.
- Isolierte Browserfixture `127.0.0.1:18744`: alle vier neuen Auswertungen, direkte Kunden-Konservenliste und Rückkehr, auf-/absteigende Preissortierung, passende Filter je Modus, Hinweis auf vorherige Auswahl, entfernte und doppelte Vorlagennamen, Geräte-/Beziehungsdaten sowie fremde Rechnungsanschriften geprüft. CSV tatsächlich heruntergeladen und bytegleich zum Backend-Export. Keine Konsolenwarnungen/-fehler. Prüfbild mit synthetischen Daten: `work/kessel-buntes-konserven-2026-10-14.png`.
- Anwendung mit dem abschließenden JAR auf Port 8080 neu gestartet; Healthcheck und bytegleiche Auslieferung des Produktionsbuilds geprüft. Vorhandener Anwendungstab neu geladen; temporäre Prüftabs, UI-Testserver und disposable MariaDB beendet.
- Keine Testschreibvorgänge gegen Geschäftsdaten, keine Schemaänderungen, keine E-Mails/Endgerätenachrichten. Die hier geprüfte Konservenliste war zunächst eine Bestandsansicht; Bearbeitung/Mehrfachentfernung wurden anschließend ergänzt (siehe oben). Dauerauftragskalender/-historie und weitere offene Menüs bleiben im Menüabgleich ausdrücklich vermerkt.

## Kessel Buntes: sechs Sonderauswertungen – 14. Oktober 2026

- Aktuelle PHP-Referenz **`24094e2`** ausschließlich vom SSH-Server; Erledigungsstatistik, Servicezeiten, Ziel-PLZ, Ziel-PLZ/Ort, Preise und Auftragsherkunft im angemeldeten alten Browser geöffnet. Keine früheren lokalen PHP-Quellen verwendet.
- Abschließendes Maven `verify` mit isolierter MariaDB 11.4 erfolgreich: **453 Tests, 450 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Frontend-Produktionsbuild, SQL-Architekturprüfung und `git diff --check` erfolgreich. Bekannter Hinweis auf Frontend-Bundle über 500 kB.
- Echte Datenbanktests der sechs Varianten mit eigenen/fremden Kunden und Niederlassungen, Erledigungs- gegenüber Auftragsdatum, offenen/geschlossenen Randsekunden, allen relevanten Stornostatus, unvollständigen Aufträgen, Null-/0000-/9999-Exportzeiten, positiven Etappenpreisen und Gruppierung. Stationspositionen 1/20/21, fehlende und negative Zeitdifferenzen, Dauer über 24 Stunden, Fahrzeuggruppen, unbekannte Herkunft, das alte Herkunftsfeldformat, doppelte Metatypbezeichnungen und doppelte Stationspositionen geprüft. Suchzeichen werden wörtlich behandelt; mehr als 5000 Ergebniszeilen werden abgewiesen. CSV prüft vollständige Stationsspalten, Umlaute/UTF-8, Trennzeichen und Formelpräfixschutz. HTTP-Prüfung für Sitzung, CSRF und Recht 46 einschließlich fehlender Rechte; die fest einprogrammierte alte Benutzer-ID gewährt keinen Sonderzugang.
- Reale Daten ausschließlich über `DatabaseService` gelesen: alle sechs neuen Abfragen kompatibel, zusätzlich eine nichtleere Bestandsstichprobe für Erledigung, Ziel-PLZ/Ort, Etappenpreis und Herkunft. Servicezeiten hatten in den geprüften Stichproben keine passenden Daten und wurden mit synthetischen exportierten Serviceaufträgen geprüft. Auftragsherkunft September 2026: dieselben **76 Aufträge** und Bezeichnungen wie die sichtbare PHP-Auswertung; Zuordnung der Herkunftscodes zusätzlich unabhängig per SQL verglichen.
- Browserfixture `127.0.0.1:18744`, ausschließlich synthetische Antworten: alle sechs Auswertungen, führende PLZ-Nullen, Stationsdetails mit 26 Stunden bzw. negativer Dauer, Seitenwechsel bei 51 Testzeilen, Filteränderung mit Hinweis auf vorheriges Ergebnis, native Datumseingabe und leeres Ergebnis. CSV tatsächlich im Browser heruntergeladen und bytegleich zum Backend-Export geprüft. Keine Konsolenwarnungen/-fehler. Abschließendes Prüfbild: `work/kessel-buntes-auswertungen-2026-10-14.png`.
- Anwendung um **14:14 Uhr** auf Port 8080 neu gestartet und geprüft: Healthcheck `UP`, Bestandsdatenbank verbunden, ausgelieferte JS-/CSS-Dateien bytegleich mit dem Produktionsbuild. Vorhandenen Anwendungstab neu geladen. Temporäre Prüftabs, UI-Testserver und disposable MariaDB anschließend beendet.
- Keine Geschäftsdaten-/Schemaänderungen, keine E-Mails oder Endgerätenachrichten. Die verbleibenden Auswertungs- und Einstellungsfunktionen des alten Sammelmenüs sind im Menüabgleich weiterhin separat offen.

## Kundenumsatz und Rechnungsnavigation – 14. Oktober 2026

- Frische SSH-Referenz **`24094e2`**; alte Kundenberichte und Rechnungsoberfläche im angemeldeten Browser lesend geprüft. Kein Rückgriff auf den früheren lokalen PHP-Bestand.
- Vollständiger Backend-Testlauf mit isolierter MariaDB 11.4: **451 Tests, 448 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Frontend-Produktionsbuild, SQL-Architekturprüfung und `git diff --check` erfolgreich. Abschließender Maven-Paketbau erfolgreich. Bekannter Hinweis auf Frontend-Bundle über 500 kB.
- Datenbanktests für alle drei Umsatzperioden: inklusive Tages-/Jahresgrenzen, Schaltjahrvergleich wie PHP, Stornoauswahl null/0/1/3, Abschlussstatus, negative/fehlende Preise und Summenrundung. Bar-/Angebotsaufträge bleiben entsprechend PHP enthalten. Keine Unterkunden oder fremde Niederlassungsaufträge; alternativer Bezug über den verbundenen Kunden, leere Bestände, Kunden-/Berichtsrechte und Mandanten-/Niederlassungsgrenzen geprüft. HTTP-Prüfung für Anmeldung und Rechte 0/16; Rechnungsrecht 5 ist unabhängig von der Umsatzanzeige.
- Zwei vorhandene Kunden über `DatabaseService` ausschließlich gelesen und alle drei neuen Summen mit den aktuellen PHP-Auswahlbedingungen unabhängig nachgerechnet: identische Ergebnisse. Keine Geschäftsdaten geändert.
- Isolierte Browserfixture `127.0.0.1:18744`: drei Vergleichswerte, Rechnungsnavigation mit Kundenauswahl und Jahres-/Monatszeitraum, Kundenstamm öffnen, Rückkehr mit erhaltener Berichtsauswahl, Entwurf behalten/verwerfen, Hinweise bei fehlendem Rechnungsrecht bzw. anderer Niederlassung. Absichtlich unterbrochene Speicherantwort sperrt das Schließen; erneute Prüfung übernimmt die ausschließlich im Arbeitsspeicher geführte Testzuordnung und gibt die Rückkehr frei. Keine Konsolenwarnungen/-fehler. Prüfbild mit synthetischen Daten: `work/kundenberichte-umsatz-2026-10-14.png`.
- Anwendung um **13:53 Uhr** mit dem geprüften JAR auf Port 8080 neu gestartet und geprüft: Healthcheck `UP`, Bestandsdatenbank verbunden, ausgelieferte JS-/CSS-Dateien bytegleich mit dem Produktionsbuild. Vorhandenen Anwendungstab neu geladen; temporäre Prüftabs, UI-Testserver und disposable MariaDB beendet.
- Keine Schemaänderungen und kein E-Mail-/Endgeräteversand. Abrechnung bleibt auf die eigene Niederlassung begrenzt; vollständige Rechnungserstellung und übrige Funktionslücken sind weiterhin im Menüabgleich aufgeführt.

## Zweite Stammdatenseiten und Zusatzformulare – 14. Oktober 2026

- Aktuelle SSH-Referenz **`24094e2`**; alte Kunden-, Transporteur- und Fahrzeug-Zusatzseiten im Browser lesend geprüft. Keine Nutzung des früheren lokalen PHP-Bestands.
- Vollständiger Backend-Testlauf mit isolierter MariaDB 11.4: **449 Tests, 446 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Frontend-Produktionsbuild, SQL-Architekturprüfung und `git diff --check` erfolgreich. Bekannter Hinweis auf das Frontend-Bundle über 500 kB.
- Echte Datenbanktests: drei Stammdatentypen, eigene/fremde Niederlassung, Rechte und freigegebene Kategorien, Datums-/Warnformate, Zahlenrundung, Checkboxen, Leeren, automatische Vorlagenwerte ohne fremde Kundendaten, unveränderte Spezialfelder, Schema-/Konfigurationsänderungen und doppelte Bestandswerte. Feldhistorie mit Seitengrenze; Wiederholungen erzeugen keine zweite Änderung. Zwei gleichzeitige Schreiber ergeben genau einen Erfolg; erzwungene Historien-/Auditfehler rollen vollständig zurück. HTTP-Tests prüfen Sitzung, CSRF und Rechte.
- Reale Daten nur über `DatabaseService` gelesen: Optionen, neue Formularansicht und Historie funktionieren mit 1 Kundenfeld, 28 Transporteurfeldern und 2 Fahrzeugfeldern. Zusätzliche Transporteurkategorien sind im aktuellen Bestand nicht freigeschaltet (`MASK_FORMS_CR` leer).
- Isolierte Browserfixture `127.0.0.1:18744`: Kundenhinweis speichern, nach unterbrochener Speicherantwort erneut prüfen und Druckvorschau; Transporteur-Warndatum/Checkbox speichern und historisch anzeigen; ungespeicherten Formularwechsel abbrechen; konfigurierte Zusatzvorlage mit automatischen Werten und bearbeitbarem Zahlenfeld; TÜV-/SAP-Daten speichern und in der Historie wiederfinden. Keine Konsolenwarnungen/-fehler. Browserdruck/PDF-Schaltfläche vorhanden, nativen Druckdialog nicht automatisiert ausgeführt. Prüfbild mit synthetischen Daten: `work/stammdaten-zusatzformulare-2026-10-14.png`.
- Maven-Paketbau erfolgreich. Anwendung um **13:37 Uhr** mit dem geprüften JAR auf Port 8080 neu gestartet: Healthcheck `UP`, Bestandsdatenbank verbunden, JS-/CSS-Dateien bytegleich mit dem Produktionsbuild. Vorhandenen Anwendungstab neu geladen; temporäre Prüftabs und Testserver geschlossen, disposable MariaDB beendet.
- Keine Teständerungen in Geschäftsdaten, keine Schemaänderung und kein E-Mail-/Endgeräteversand. Vorhandene PHP-Warn- und Exportprozesse werden durch die Pflege der Bestandsfelder weiter unterstützt; native Hintergrundprozesse sind damit nicht zusätzlich portiert. Weitere Lücken stehen im Menüabgleich.



## Kunden–Transporteur-Beziehungen – 14. Oktober 2026

- Aktueller PHP-Serverstand **`24094e2`** per SSH; beide alten Beziehungsmasken im angemeldeten Browser gelesen. Kein Rückgriff auf den früheren lokalen PHP-Bestand.
- Frontend-Produktionsbuild erfolgreich. Vollständiger Maven-Testlauf mit isolierter MariaDB 11.4: **444 Tests, 441 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. SQL-Architekturprüfung erfolgreich. Bekannter Bundlegrößenhinweis über 500 kB.
- Datenbanktests mit echter MyISAM-Beziehungstabelle und InnoDB-Historie/Vorgangsbelegen: Anlegen, Status-/Notizänderung, Rangfolge, Mehrfachentfernung über mehrere Kunden, Provisionshistorie, Erhalt fremder Daten, eigene Niederlassung, Rechte 1/39, ungültige Sätze, gleiche Sekunde/künftige Historie, veraltete Revision und wiederverwendete Vorgangskennung. Zwei parallele Anlagen ergeben genau einen Erfolg.
- Erzwungener Verbindungs-/Bestätigungsfehler nach tatsächlichem MyISAM-INSERT bzw. DELETE: Plan bleibt erhalten, Teilstand wird erkannt, Wiederaufnahme erzeugt keine doppelten Beziehungen oder Audits. Erzwungener Auditfehler nach Provisionsänderung: MyISAM-Wert bleibt geändert, Historie wird zurückgerollt und beim Fortsetzen genau einmal geschrieben. Externe Zwischenänderungen werden nicht überschrieben. Wiederaufnahme durch einen anderen Bearbeiter bzw. ohne Provisionsrecht wird abgewiesen. Tabellensperren werden nach COMMIT/ROLLBACK gelöst.
- HTTP-Prüfung: Sitzung, CSRF und Transporteurrecht für die neuen Lese-/Schreibendpunkte. Echten Bestand ausschließlich über `DatabaseService` gelesen: Kunden-/Transporteursansicht, Suche und Historienabfrage kompatibel; beim geprüften Transporteur 18 Beziehungen. Keine fachlichen Schreibtests gegen den Bestand und keine Schemaänderungen.
- Browserfixture `127.0.0.1:18744`, ausschließlich synthetische Daten im Arbeitsspeicher: Anlage vom Kunden- und Transporteurstamm, Favoritenrang, Provisionshistorie, Notiz/Status, Filter, Mehrfachentfernung, Entwurf behalten und Wiederaufnahme eines offenen Vorgangs. Keine Konsolenwarnungen/-fehler. Prüfbild: `work/kunden-transporteur-beziehungen-2026-10-14.png`.
- Anwendung um **12:42 Uhr** mit dem geprüften JAR auf Port 8080 neu gestartet: Healthcheck `UP`, Bestandsdatenbank verbunden, ausgelieferte JS-/CSS-Dateien bytegleich mit dem Frontend-Build. Vorhandenen Anwendungstab neu geladen; temporäre Prüftabs, UI-Testserver und disposable MariaDB beendet. Der verbleibende Umfang ist im Menüabgleich separat aufgeführt.

## Kunden-Radien und CSV-Zuordnungsimporte – 14. Oktober 2026

- Frische PHP-Referenz direkt per SSH, Git **`24094e2`**, in ignoriertem Arbeitssnapshot `work/php-radius-2026-10-14`. Kunden-Serviceverwaltung und deren Datenimportfenster der angemeldeten PHP-UI lesend geprüft. Kein Rückgriff auf den früheren lokalen PHP-Bestand.
- Vollständiger Backend-Testlauf mit isolierter MariaDB 11.4 erfolgreich: **441 Tests, 438 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Anschließender Frontend-Produktionsbuild und Maven-Paketbau erfolgreich. SQL-Architekturprüfung und `git diff --check` erfolgreich. Bekannter Hinweis auf Frontend-Bundle über 500 kB.
- Echte Transaktionstests für ZONE, ZONEAGIO und RADIUSZONE: begrenzter Ersetzungsumfang, landesspezifische PLZ, führende Null, Erhalt fremder Kunden/Zonen und anderer Preisfelder, Nullsetzung aller kundenspezifischen Zonenaufschläge, Preisentfall bei Radiusersetzung. Fehlerhafte/doppelte Zeilen und Zuordnungskonflikte schreiben nichts. Geänderte Revision/Vorschau, fehlendes Importrecht und falsche Niederlassung werden abgewiesen. Erzwungener Auditfehler rollt die gesamte Änderung zurück.
- Radiusberechnung mit synthetischen Ortskoordinaten: drei Intervalle, sortierte Schlüsselfolge, Bezirks-/Dublettenregeln, Firmenadress-Fallback, leerer Ortsbestand und Geokodierungsfehler. Zwischen Vorschau und Übernahme geänderte Ortsdaten sowie eine während der Geokodierung geänderte Kundenadresse werden erkannt. Zwei parallele Importe derselben Revision ergeben genau einen Erfolg. Bestätigte Requests bleiben selbst bei anschließend ausgefallenem Geokodierer wiederholbar, ohne doppelte Änderung.
- Reale Bestandsdaten ausschließlich über `DatabaseService` gelesen: Kunden-Importoptionen und Standards funktionieren; `phoenix_special.cityradius` (MyISAM) enthält **0 Zeilen**. Deshalb keine echte Radiusberechnung möglich, bis die Orts-/Bezirksdaten bereitgestellt sind. Kein geographischer Ersatzbestand erfunden. Importsperre bei leerem Radiusbestand betrifft die automatische Berechnung, nicht die drei CSV-Importe.
- Browserfixture `127.0.0.1:18744` ausschließlich mit synthetischen Daten im Arbeitsspeicher: UTF-8-Datei einlesen, Zeilenfehler, führende PLZ-Null, Vorher-/Nachheransicht, Zonenaufschläge einschließlich Nullsetzung, Speichern/erneutes Lesen, Radiusimport, Berechnung/Übernahme, Entwurf behalten sowie Windows-1252-Datei mit Umlaut. Fehlender Geobestand zeigt einen Hinweis und deaktiviert die Berechnung. Keine Konsolenwarnungen/-fehler. Screenshot: `work/kunden-zonenimport-2026-10-14.png`.
- Anwendung um **12:16 Uhr** mit dem geprüften JAR auf Port 8080 neu gestartet: Healthcheck `UP`, Bestandsdatenbank verbunden, ausgelieferte JS-/CSS-Dateien bytegleich mit dem Produktionsbuild. Temporäre Browser-Tabs, Testserver und disposable MariaDB anschließend beendet.
- Keine Teständerungen in Geschäftsdaten, keine Schemaänderung, keine E-Mails oder Endgerätenachrichten. Vollständige allgemeine Datentransfer-/FTP-/SFTP-Funktionalität bleibt gesondert offen; dieser Block ergänzt die drei kundenspezifischen Zuordnungsformate.

## Kundenpreisformulare und Endgeräte-Servicevorgaben – 14. Oktober 2026

- Aktueller PHP-Serverstand direkt per SSH gelesen: **`24094e2`**. Abnahmeprotokoll, Abliefergrundlisten und Kunden-/Aktionspreisformulare im angemeldeten Browser geprüft. Kein Rückgriff auf den früheren lokalen PHP-Bestand.
- Frontend-Produktionsbuild und vollständiges Maven `verify` mit isolierter MariaDB 11.4 erfolgreich: **434 Tests, 431 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. SQL-Architekturprüfung erfolgreich; bekannter Bundlegrößenhinweis über 500 kB. Anschließende UI-Text-/Hinweiskorrektur und Scroll-/Fußleistenkorrektur erneut gebaut und in das JAR verpackt.
- Neue Integrationsprüfungen: Fragen-/Mail-Zuordnung, nicht fortlaufende Service-IDs, vier getrennte Abliefergrundlisten, leere Codes, reservierte Trennzeichen, Höchstzahl, Duplikate, Erhalt fremder Kunden/Objekttypen/Listen und inaktiver Altwerte; Preisformulare mit Feldhistorie, Kategorien-/Niederlassungsabgrenzung, Schemaänderungen, ungültigen Zahlen/Daten und unveränderlichen Spezialfeldern. Wiederholte Requests bleiben einmalig. Zwei konkurrierende Schreiber mit gleicher Revision ergeben genau einen Erfolg. Erzwungene Historien-/Auditfehler rollen vollständig zurück. HTTP-Prüfungen für Anmeldung, CSRF und Rechte.
- Echte Daten ausschließlich gelesen: neue Optionsabfrage, alle vier Abliefergrundlisten, alle sechs Preisformulare und deren Historie. Im Bestand fehlen derzeit die Feldzuordnungen/Vorlage der sechs Preisformulare und die allgemeinen Servicearten für Abnahmeprotokolle; die neue UI zeigt diese Konfigurationslücken ausdrücklich an.
- Isolierte Browserfixture `127.0.0.1:18744` mit synthetischen Daten: Abliefergrund speichern/erneut lesen; Fragen samt Mail-Bedingung umordnen, Abschlusstext speichern; Preisformular bearbeiten, Werte erneut lesen, Feldhistorie und Druckvorschau; Entwurf behalten/verwerfen und leere Konfiguration prüfen. Keine Konsolenwarnungen/-fehler. Browserdruck/PDF-Schaltfläche vorhanden, kein nativer Druckdialog automatisiert ausgeführt.
- Anwendung mit dem abschließenden JAR auf Port 8080 neu gestartet: Healthcheck `UP`, Bestandsdatenbank verbunden, ausgelieferte JS-/CSS-Dateien bytegleich zum Produktionsbuild. Vorhandenen Browser-Tab neu geladen; temporären Testserver, Browser-Tabs und disposable MariaDB beendet. Screenshot mit Testdaten: `work/kunden-abnahmeprotokoll-2026-10-14.png`.
- Keine fachlichen Schreibtests gegen den Bestand, keine E-Mails oder Endgerätenachrichten versandt, keine Schemaänderung. Automatische Radiusberechnung und Kunden-Zuordnungsimporte wurden anschließend ergänzt; Details im Menüabgleich.

## Kunden-Servicevorgaben – 14. Oktober 2026

- Frische Serverquelle aus `admin`/`include` per SSH: 650 Einträge, Git `868db70`. Alte Kundenliste, Kundenstamm und `customer_service.php` lesend geprüft. Ausschließlich aktueller Server-Snapshot als PHP-Referenz.
- Frontend-Produktionsbuild und Maven `package` mit vollständigem Backend-Testlauf erfolgreich: **432 Tests, 429 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Bekannter Hinweis auf das Frontend-Bundle über 500 kB.
- Neue echte Transaktionen gegen wegwerfbare MariaDB 11.4: Zonenanlage/-umbenennung/-löschung mit Zuordnungen, Erhalt von vier Preiswerten und PLZ-Zuschlägen, Ländereindeutigkeit, mehrere Radiusbezirke, Preiserhalt, feste Metatypnummern, vier Auslieferarten, Standardübernahme, Rabatt-Typ 0, SMS-/Rollkartenzeiten. Fremdkunden, fehlende Administratorrechte, veraltete Revisionen, ungültige Uhrzeiten, belegte Auslieferarten und wiederverwendete Request-IDs mit anderen Daten werden abgewiesen. Erzwungener Auditfehler nach Zonen-/Zuordnungslöschung rollt den gesamten Vorgang zurück; Wiederholung erzeugt keine zweite Änderung.
- Aktuelle Tabellen und Spalten am echten Bestand nur lesend geprüft. Neue Service-Leseabfragen erfolgreich gegen einen bestehenden Kunden: eine Kunden-Auslieferart und sieben allgemeine Standardvorgaben. Ansicht und Vorschau erzeugen keine Kunden-Standardwerte.
- Browserfixture `127.0.0.1:18744` ausschließlich mit synthetischen Daten im Arbeitsspeicher: neue Zone und PLZ-Zuordnung speichern, Radius ändern und Preis erhalten, Tageszeit per Tastatur eingeben und gespeichert wiederlesen, Rabatt-Typ wechseln, Entwurf erhalten/verwerfen. Keine Konsolenfehler/-warnungen. Screenshot: `work/kunden-servicevorgaben-2026-10-14.png`.
- Anwendung um 09:55 Uhr mit dem geprüften JAR auf Port 8080 neu gestartet. Healthcheck `UP`, Bestandsdatenbank verbunden, ausgelieferte JavaScript-/CSS-Dateien bytegleich mit dem Produktionsbuild. Vorhandener Anwendungstab neu geladen; Testserver und disposable MariaDB beendet.
- Keine Testschreibvorgänge gegen Bestandsdaten, kein SMS-/E-Mail-Versand, keine Schemaänderungen. Automatische Radiusberechnung, Import und separate Aktionspreis-/Protokollformulare bleiben im Menüabgleich ausdrücklich offen.

## 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.

## Historischer Ausgangsstand (keine aktuelle Resteliste)

Die folgenden Punkte beschreiben die ursprüngliche erste Ausbaustufe. Zahlreiche dieser Bereiche wurden inzwischen umgesetzt; maßgeblich sind die datierten Prüfstände oben. Diese historische Liste darf nicht als aktueller Funktionsstand oder Grundlage einer Prozentangabe verwendet werden:

- 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 vorauf dem testdenen 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.