votianng/docs/MENUE-ABGLEICH.md

# Menüabgleich Altanwendung / Votian NG

## Aktueller Stand vom 20. Oktober 2026

Transporteurstatistik, Neukalkulation und die lesende Betriebsübersicht sind ergänzt. Der aktuelle Nachweis und die bewusst ausgelassenen Abhängigkeiten stehen in [PRUEFSTATUS.md](PRUEFSTATUS.md). Die folgenden datierten Abschnitte dokumentieren frühere Zwischenstände; dort als offen bezeichnete Funktionen können inzwischen umgesetzt sein. Die damalige 26er-Restliste ist keine vollständige Zählung der Gesamtanwendung.

## 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 · Konkret gezählte Restfunktionen

**26 konkret nachgewiesene offene Teilfunktionen** in der bereinigten Restliste. Gezählt wird eine eigenständig auswählbare Ansicht oder fachliche Aktion; gemeinsame Filter, Spalten und technische Hilfsfunktionen zählen nicht separat. Dies ist eine belegte Mindestzahl, keine abschließende Inventur aller PHP-Spezialkonfigurationen und kein Prozentnachweis. Ältere pauschale „teilweise/offen“-Angaben weiter unten sind hierfür nicht die Zählgrundlage.

| Gruppe | Offene Teilfunktionen | Inhalt |
|---|---:|---|
| Kasse / Inkasso | 12 | Fünf Einnahmenansichten; Zahlart ändern; Inkasso in Kasse umwandeln; Liefer-/Montagezahlung umbuchen; CSV; PDF; PDF-Mail; Umsatzexport Kategorie 9 |
| Zahlungskontrolle | 9 | Sammelzahlungsdetails mit Suche/Exportdatumsfilter sowie acht einzeln auswählbare Abrechnungskontrollberichte |
| Zusatzmontage | 1 | Servicezeit samt Kunden-/Kurierpreis, Zusatzauftrag und Zahlung buchen/ändern |
| Archiv | 4 | Historische Zentralen-, Kunden- und Transporteur-Auftragslisten sowie Archivauswertung |

Die Kassenmaske wurde tatsächlich geöffnet: fünf Ansichten sichtbar, keine Buchung ausgelöst. `tools/payments.php` liefert aktuell HTTP 500; die neun dort vorgesehenen Ansichten sind durch den frisch gelesenen PHP-Code belegt, ihre alte Laufzeitfunktion nicht. Exportkategorie 9 und zugehörige Profile fehlen im aktuellen Datenbestand. Die Neuanlage eines Zusatzmontageauftrags ruft `copy_job_flat` auf; eine Definition fehlt im durchsuchten aktuellen Serverbestand, während der Änderungszweig für vorhandene Zusatzaufträge vorliegt. Alle vier Archivfunktionen benötigen die bislang nicht auffindbaren `jobhistory`-/`tourhistory`-Tabellen. Diese Einschränkungen sind Teil der Restliste, keine bereits abgeschlossenen Funktionen.

Nicht mehr offen: Zahlungseingänge im Auftrag, Restbetragsbuchung und Änderung der vorgesehenen Zahlart; vollständig geprüft und lokal bereitgestellt (1584 Tests, 1581 erfolgreich, drei übersprungen). Nicht mitgezählt: ausdrücklich entfallene Classic-Sammelübergabe, im PHP deaktivierte Statistiken und die Betriebsumschaltung bereits implementierter Dienste. Vorhandene Kundenportal-Spezialspalten: 15 Konfigurationen, keine unbekannten Spalten im letzten lesenden Abgleich. Konfigurierte Formular-Skripte besitzen native Entsprechungen; bloße Schutzmeldungen für beliebige zusätzliche Skripte sind keine bestätigten Lücken.

Einzelne Restpunkte mit Quellen und Status: `work/remaining-function-inventory-2026-10-19.json`. Frische SSH-Nachweise: `work/function-count-*-2026-10-19.txt`, `work/cashflow-implementation-reference-2026-10-19.txt`. Nur lesende Datenbankprüfung: `work/function-count-read-2026-10-19.json`. PHP-UI-Nachweise: `work/function-count-cashflow-php-ui.txt`, `work/function-count-payments-php-ui.txt`.

## 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. 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 – Auswahl- und Spezialfelder in Objektformularen

- Frischer SSH-Abgleich mit `2eb7f98`: `include/inc_metafield.inc.php` SHA-256 `149a46799258036404ac45ba315531195ed2b4c316bfa14b4addb5c5e13fdc65`, `admin/metafield_special.php` `3a76c59c31e95251a8921d6588538c85b2bfb306dc9073552214be514fd43e56` und `admin/metafield_editor.php` `c3fe9a1f6d05a46bb7277cbf3c0f01751f62c3d7cd5f708e7799632345bebcb6`. Formularverwaltung und Vorortprüfung im Browser geöffnet, ohne Speicherung.
- Stammdaten-Zusatzseiten und Berichtsformulare unterstützen jetzt Kunden-, Transporteur-, Fahrzeug-, Niederlassungs-, Branchen-, Fahrzeugklassen- und Gruppenauswahl, Niederlassungs-Checkboxen, Kontaktkunden, Autor und zusammengesetzte `ref:`-Felder sowie die zusätzlichen Telefon-/Mail-, Link- und Bildfeldtypen. Auswahl mit Suche und maximal 100 Treffern; weitere Treffer werden angezeigt. Nur ausdrücklich bekannte Tabellen-/Spaltenkennungen werden auf SQL abgebildet.
- Eigene bzw. freigegebene Niederlassungen und Kunden-/Transporteurrechte werden geprüft; globale Auswahllisten bleiben im Mandanten. Unveränderte historische Auswahlwerte bleiben erhalten. Nicht mehr verfügbare Niederlassungszuordnungen werden sichtbar erhalten. Autorfeld wird beim ersten Speichern gesetzt; Referenzen werden unabhängig von der Feldreihenfolge berechnet, mit Prüfung auf Zyklen, fehlende Bindungen und Länge. Werte und Feldhistorie werden zusammen gespeichert; Masterformulare zusätzlich mit Audit und wiederholbarer Vorgangskennung.
- PHP-kompatible Tabellensperren wurden um die tatsächlich verwendeten Auswahlquellen erweitert. Neue Optionen werden innerhalb der gesperrten Speicherung erneut geprüft. Reale Stammdaten und Formularwerte wurden nicht verändert. Aktuell verwenden vor allem Bewertung (15) und Vorortprüfung (102) die Auswahltypen; der Bewertungseditor besaß seine entsprechende Spezialbedienung bereits. Diese Erweiterung macht sie zusätzlich in den allgemeinen Objekt-/Berichtsvorlagen verfügbar.
- Browserprüfung mit synthetischen Daten: Auswahl, Niederlassungsänderung einschließlich historischem Wert, identische Wiederholung nach verlorener Speicherantwort und Ladefehler mit geleertem Editor. Nachweis: `work/form-fields-ui-verification.json`, `work/formularauswahl-2026-10-18.png`. Vorbelegte System-/Stammdatenfelder und weitere Template-Sonderregeln werden weiter mit PHP abgeglichen; dieser Block belegt keine vollständige Formularparitä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 – Auftrags- und Gutschriftenexporte ergänzt

- Zentrale Exportkategorien 4/5/6 mit vorhandenen Profilen, Datums-/Kunden-/Auftrags-/Zahlarten-/Fahrzeugfiltern, PHP-Preis- und Kennzeichenumwandlungen, Vorschau und Windows-1252-Download.
- Gespeicherter Export mit atomarer Auftragskennzeichnung, Audit, wiederholbarem MyISAM-Protokoll und historischer Auftragskopie. Getrennte interne/Kunden-/Mailansichten, stabile Preise/Stationen/Unterschriften sowie Wiederaufnahme nach Archivfehlern geprüft.
- Aktueller Servercode und alte UI erneut geprüft. 1060 Tests (1057 bestanden, drei übersprungen), zwölf Frontendtests und Browser-/Downloadprüfung erfolgreich; auf Port 8080 bereitgestellt. Konfigurierte weitere Sonderformate und sonstige Spezialbereiche bleiben Gegenstand des weiteren Abgleichs.


## 18. Oktober 2026 – Debitoren, Kreditoren und Fahrzeuge exportieren

- Aktuelle PHP-Exportseite im Browser geprüft; SSH-Referenz weiterhin `/data/0/votian-test/html`: `export/export.php` SHA-256 `30b7b10e11d76fc02e7b5103dc67680699604bc66b87022c568406c226ed0c28`, `export/exportrequests.inc.php` `f3c65b08d27f86675ccca3e5fe877aa6f81130dc41288187a758d7e11ea4115a`, `include/inc_dbfields2array.inc.php` `f0b7baa606b8f9ddce643aabe8f5e0ed8ea34aba9609e0e35a975c042d61b40b`, `export/exportinterface_admin.inc.php` `c55b120e0bf712a04f3f96981bad32cc8683816c3d6eaae96482ec0d34044bc1`.
- Datentransfer bietet zentrale Stammdatenexporte mit Recht 6: Kategorien 1/2/3, vorhandene Profile, Profilkopie/-pflege, Neu-/Änderungs-/Gesamtfilter, Vorschau und Windows-1252-Download. Statische Feldzuordnung statt ausführbarer Datenbank-SQL-Ausdrücke; PHP-Transformationen für Status, Bankart, Steuerkennzeichen, Rechnungsadresse, Intervall, Zahlungsziel, Fahrzeugart/Corporate Identity und RETRANS-Debitorensonderblöcke umgesetzt.
- Gemeinsame Exportablage mit wiederaufnehmbaren Vorgängen, Entfernen/Wiederherstellen und geschützten Buchhaltungsdateien. Exportkennzeichen werden erst nach dauerhafter Dateisicherung atomar zurückgesetzt; entsprechend PHP vorgemerkte Fahrzeuge werden dann entfernt. Gesamtexport und direkter Download ändern keine Kennzeichen. Das MyISAM-Exportprotokoll wird nach dem Geschäftscommit aus einem dauerhaften Auftrag nachgetragen; ein Ausfall verliert weder Datei noch Wiederholungsstatus.
- Bewusste Abweichungen: Vorschau/Bestätigung statt sofortiger Buchung, Blockade mehrdeutiger Zuordnungen und geteilter Firmen, keine Ausführung allgemeiner PHP-Nachlaufscripts anhand artfremder IDs. Profilpflege folgt dem bestehenden Mitarbeiterrecht 6. Die alte zusätzliche Formular-Passwortabfrage ist keine neue Berechtigung in NG.
- 1055 Tests (1052 bestanden, drei übersprungen), Browserprüfung und Bereitstellung auf Port 8080 erfolgreich. Weitere zentrale Auftrags-/Gutschriftenexporte, historische Folgeverarbeitung und externe Sonderformate bleiben offen; keine vollständige Parität behauptet.

## 18. Oktober 2026 – Fahrerkarte: Rangfolge und Ablehnungen

- Aktuelle SSH-Quelle und PHP-Karte erneut geprüft: `locating/map.php` (SHA-256 `c977597722131caf586ce62f72eb0fa35f498618a813b74794210d84a58a2b86`) und `locating/map.inc.php` (`d7c7811b6ec6776b0c180dc575ee87aa6680682814c9a34267872ee18721ca6f`). PHP blendet ungeeignete Kandidaten aus und kennzeichnet Ablehnungen aus Protokolloperation 11 rosa; Belegung und ungültige Freimeldung haben Vorrang. In der geöffneten aktuellen PHP-Karte waren keine heutigen Fahrer sichtbar; Farb-/Rangregeln deshalb zusätzlich im Servercode geprüft.
- Native Karte nutzt die vorhandene vollständige CLASSIC-Kandidatenberechnung. Auswahl zwischen passenden Kandidaten nach globalem Rang, allen heutigen Ortungen und zugeordnetem Fahrer. Details mit Bereich/Nachbarschaft, Favorit, früherem Angebot, Sperrgründen und Ablehnungsanzahl/-zeit. Rangnummern bleiben bei Fremdniederlassungs- und Positionsfiltern unverändert.
- Ablehnungen werden über stabile Kurier-ID zugeordnet; historischer SID-Rückfall nur bei Eindeutigkeit in derselben Niederlassung. Kein Abfluss fremder Fahrer/Protokolle. Fehlende/veraltete Rangdaten sperren Zuweisungen, Fehler leeren die Kandidatenauswahl; serverseitige Zuweisungsvorschau bleibt maßgeblich. Kundenspezifische Kartenansicht wurde bereits am 17. Oktober implementiert.
- 1050 Tests (1047 bestanden, drei übersprungen), Browserprüfung und Bereitstellung auf Port 8080 erfolgreich.

## 18. Oktober 2026 – Zusatzmontagebeträge und zentrale Kundenausschlüsse

- Aktuelle Serverquelle erneut geprüft: `statistic_sql.inc.php` 697–705 ersetzt die Umsatzbasis für Zusatzmontage durch Gesamtbetrag minus Grundbetrag bzw. nur Grundbetrag. Native exklusive Auswahl mit unveränderten Auftragszahlen und Vergütungsformeln, kombinierbar mit Brutto/Preisvarianten/Vergleichen; Freigabe über `GLOBAL_USE_RELATED_CUSTOMER` wird bei jeder Abfrage geprüft.
- `STATISTIC_EXCLUDED_CS` (PHP 934–938) wird für normale Auftrags- und Kalkulationsauswertungen bei jeder Abfrage neu eingelesen. Exakte Kundennummern, dedupliziert und als SQL-Parameter gebunden; maßgeblich ist der historische/zugeordnete Ergebniskunde. Ergebnis und CSV nennen die Anzahl konfigurierter Ausschlüsse. Aktionen und Abholzeit folgen ihren PHP-Ausnahmen.
- Erneut geprüft: Geräte-/Online- und Befragungsstatistiken sind in `statistic_interface_hq.inc.php` ausdrücklich durch `if(false)` deaktiviert. Sie sind keine aktiven fehlenden Menüpunkte. Historische Archivauswertungen bleiben wegen fehlender Archivtabellen und fehlerhafter PHP-Referenz offen.
- 1049 Tests (1046 bestanden, drei übersprungen), Browser/CSV und Bereitstellung auf Port 8080 erfolgreich.

## 18. Oktober 2026 – Zeit zwischen Annahme und Abholung

- Native Auswertungsbasis mit fünf PHP-Zeitklassen bis einschließlich 5/10/15/20 Minuten und über 20 Minuten. Auftrags-/Niederlassungs-/Datumsfilter, Vergleiche, Gruppen, Kunden-Zusatzangaben und weitere Aufteilungen bleiben kombinierbar. Zeitaufteilung bleibt verpflichtend; Kalkulationspositionen, Aktionsprotokoll und alle Zielstationen sind eine andere Basis und deshalb nicht kombinierbar.
- Aktuelle PHP-Oberfläche: Kategorie Transporteure → „Annahmeverhalten: Zeit zw. Annahme und Abholung“ geöffnet. Quelle `statistic/statistic_sql.inc.php` (1160–1181) und `statistic/statistic.php` (880–926) verwenden Auftragsannahme und Abschluss der ersten Station sowie Unix-Zeitdifferenz; diese Grundlage übernommen. Fehlerhafte/fehlende/mehrdeutige Angaben werden separat gezählt statt in die kürzeste Klasse verschoben. Doppelte erste Stationen erzeugen keine zusätzlichen Aufträge.
- Fünf reguläre Klassen einschließlich Nullzählungen je vorhandener Ergebnisgruppe, zusätzlich Datenqualitätsklassen; Mittelwert/Minimum/Maximum in Minuten, CSV und Auftragsanzahl-Diagramme. 1047 Tests (1044 bestanden, drei übersprungen), Browserprüfung und Bereitstellung auf Port 8080 erfolgreich. Zusatzmontagebeträge und globale Kunden-Ausnahmen bleiben gesondert offen.

## 18. Oktober 2026 – Statistikgruppen vollständig auswählbar

- Mehrfachauswahl mit Suche, Auswahlzähler und Zurücksetzen ergänzt. Gruppen vereinigen Mitglieder derselben Art; bevölkerte Arten werden gemeinsam gefordert. Kunden, Transporteure, Mitarbeiter (über Benutzer-ID), Preis- und Leistungstypen werden berücksichtigt; die letzten beiden aktivieren im Formular die Leistungskalkulation. Direkt zugeordnete Kunden sind separat einschließbar, ohne Pflicht zur Eingabe einer einzelnen Kundennummer.
- Statische Gruppen erscheinen wie in PHP nur bei `GLOBAL_USE_RELATED_CUSTOMER`, mit Mandant, Niederlassung 0 und `grp_readonly=1`. Ihre Kunden stammen aus der aktuellen Niederlassung; normale Gruppen gehören zur aktuellen Niederlassung, ihre Mitglieder können aus allen erlaubten ausgewählten Niederlassungen stammen. Modus und Zugriff werden bei jeder Abfrage erneut geprüft. Bestehende Einzelgruppenfilter bleiben kombinierbar.
- Aktuelle Serverquellen `statistic/statistic_sql.inc.php` (873–930), `statistic/statistic_interface_hq.inc.php` (932–976) und `include/inc_group.inc.php` geprüft; normale Mehrfachauswahl auch in der PHP-Oberfläche geöffnet. Bewusste Korrekturen: leere Gruppen liefern keine Treffer statt einer uneingeschränkten Auswertung; doppelte Preistypnamen vervielfachen keine Beträge; Mitarbeiter berücksichtigen die ausgewählten Niederlassungen; bei Aktionen folgt der Transporteurfilter dem beteiligten Fahrer. Keine rekursive Gruppennesting-Auflösung, entsprechend dem PHP-Helfer.
- Ergebnis und CSV nennen die angewendeten Gruppen und Mitgliederarten. 1045 Tests (1042 bestanden, drei übersprungen), Browserprüfung und Bereitstellung auf Port 8080 erfolgreich. Annahme-/Abholdauer, Zusatzmontagebeträge und globale Kunden-Ausnahmen bleiben gesonderte Restpunkte.

## 18. Oktober 2026 – Kunden-Zusatzangaben in der Statistik

Rechnungs- und Lieferadressen sowie E-Mail/Telefon der Kundenbetreuung sind einzeln wählbar. Die aktuelle PHP-Quelle auf dem Server verwendet hierfür die Stammkostenstelle mit Adressrollen 2/4 und die Mitarbeiterzuordnung `cs_admin`. Die native Umsetzung ergänzt diese Angaben nach der Auswertung, erhält deshalb auch bei mehreren Adressen korrekte Summen und berücksichtigt historische Nachfolger/Bezugskunden. Tabelle und CSV enthalten die gewählten Zusatzspalten. 1043 Tests (1040 bestanden, drei übersprungen), Browserprüfung und Bereitstellung auf Port 8080 erfolgreich; Details im Prüfstatus. Gemischte/statische Gruppenfilter und weitere statistische Sonderauswertungen bleiben gesondert offen.

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

- Aktuelle PHP-Oberfläche zeigt vier Preisvarianten (IDs 0–3). SSH-Referenz `statistic_sql.inc.php` 58–59 und 105–209, `statistic_interface_hq.inc.php` 1143–1154. Brutto ist nur mit Recht 23 und `GLOBAL_USE_RELATED_CUSTOMER` sichtbar; diese Freigaben werden auch serverseitig erneut geprüft.
- Gesamtpreis, Grundpreis ohne TSZ/Servicepreis, nur TSZ und gesonderte Zuschläge umgesetzt. Grundvergütung nutzt Typ-10-Auftragspreis, danach gespeicherte Grundvergütung, danach eindeutige Fahrzeugprovision. Zuschlagsvergütung folgt der PHP-Differenzformel und kann Serviceanteile enthalten; Oberfläche weist darauf hin. Doppelte Grundvergütungen/uneindeutige Provisionen vervielfachen keine Umsätze und werden als unbekannt gekennzeichnet.
- Brutto rechnet wie PHP Geldbeträge pauschal mit 1,19 um, unabhängig von einzelnen Auftragssteuersätzen. BSG/Quoten, Mengen und KM werden nicht hochgerechnet. Offensichtliche PHP-Rechenfehler (Quadrieren des Zuschlagswerts bei Brutto und vom gewählten Umsatz abweichende EAU-Basis) werden nicht übernommen: EAU ist die Differenz der tatsächlich angezeigten Umsatz- und Vergütungswerte.
- Getrennte Frachtvergütung/EAU für Zuschläge in Tabelle, CSV und Diagramm. Unbekannte Werte bleiben leer mit Qualitätszähler. Preisvarianten sind mit Aktionen, Zielstationen und Vergleichen kombinierbar; Kalkulationspositionen bleiben eine eigene Nettobasis.
- 25 gezielte Tests, zehn Frontendtests, Browser/CSV erfolgreich; Gesamtlauf 1041 Tests/1038 bestanden/drei übersprungen, 739 Dateien geprüft und Port 8080 aktualisiert. Zusatzmontage-Betragsfilter und weitere Statistikdetails bleiben offen.

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

- PHP-Transporteurstatistik im Browser erneut geöffnet; fünf aktive Menüpunkte mit IDs 1006/1007/1003/1011/1008 erfasst. Aktueller SSH-Quellcode `statistic_sql.inc.php` 790–823 und 1375–1431 sowie echtes `phoenix_log.log`-Schema nur lesend geprüft (Zeitstempel, HQ, Auftrag, Fahrer, Benutzer und Operation).
- Eigene Auswertungsbasis „Transporteur-Aktionen“ mit automatischen/manuellen Vermittlungsversuchen, Annahmen, Ablehnungen und automatischen Entzügen. Wahlweise alle Einträge oder PHP-Zusammenfassung nach Aktion/Auftrag/Fahrer/auslösendem Benutzer/Niederlassung. Gruppierung zeitlich nach erster passender Aktion; Uhrzeit wird vor der Zusammenfassung geprüft.
- Zeitraum folgt dem Aktionsprotokoll. Transporteurfilter und Unternehmerzuordnung folgen dem Beteiligten; die Frachtvergütung bleibt am ausgeführten Auftrag. Protokoll, beteiligter Fahrer und Auftrag müssen in ausgewählten freigegebenen Niederlassungen liegen. Bestehende Status-/Auftragsfilter gelten zusätzlich. Auftragszahlen bleiben getrennt von Aktionszahlen; wiederholte Beträge werden deutlich erklärt und im CSV mit Zählweise dokumentiert.
- 22 gezielte Tests, neun Frontendtests, Browser und CSV erfolgreich; Gesamtlauf 1038 Tests/1035 bestanden/drei übersprungen, 736 Dateien geprüft und auf Port 8080 bereitgestellt. Annahme-/Abholzeit-Auswertung, weitere Betragsvarianten und sonstige Spezialstatistiken bleiben offen.

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

- Erneuter SSH-Abgleich mit unveränderten Statistikdateien: `statistic_sql.inc.php` 671–710, `statistic_interface_hq.inc.php` 833–895 und `include/global.inc.php` (`mcConvertSel2Num`). Aktuelle PHP-Kundenstatistik im Browser geprüft: Diese bedingten Controls sind ohne `GLOBAL_USE_RELATED_CUSTOMER` ausgeblendet. Das Verhalten wird übernommen; die echte Einstellung wurde nicht verändert.
- Mehrere Kundenservices per Bitmaske mit ODER-Verknüpfung; Service 1 bleibt wie in PHP ausgeblendet. Filter für Serviceauftrag und „zu Lasten der Spedition“ jeweils alle/nur/ohne. Merkmale richten sich nach der Existenz des jeweiligen `genericdatacontainer`-Eintrags, nicht dessen Inhalt; doppelte Einträge vervielfachen keine Aufträge.
- Globale Freigabe und aktuelle Serviceauswahl werden vor jeder Abfrage geprüft. Filter sind mit den bestehenden Zeitraum-, Kunden-, Zuordnungs-, Kalkulations- und Stationsauswertungen kombinierbar. Ergebnisse und CSV halten die verwendete Auswahl fest.
- 19 gezielte Tests, neun Frontendtests und Browser/CSV erfolgreich; Gesamtlauf 1035 Tests/1032 bestanden/drei übersprungen, 733 Dateien geprüft und Port 8080 aktualisiert. Zusatzmontage-Betragsformeln und andere Spezialstatistiken bleiben gesondert offen.

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

- Aktuelle PHP-Kunden-/Transporteurstatistik im Browser geprüft; frischer SSH-Abgleich `statistic_sql.inc.php` 732–765 und 1152–1157 sowie `statistic_interface_hq.inc.php` 1030–1074. Elternfelder und Niederlassungen nur lesend im echten Schema bestätigt.
- Nach direkten zugeordneten Kunden oder Fahrern einer eingegebenen Stammnummer filtern. Unternehmer/Fahrer einzeln, nur zugeordnete Fahrer nach Unternehmer sowie alle nach Unternehmer zusammenfassen. Neue Aufteilung „Übergeordneter Kunde“. Ohne Zuordnungsschalter bleibt die Transporteurnummer auf den ausführenden Transporteur bezogen.
- Eltern nur innerhalb der ausgewählten freigegebenen Niederlassungen. Fehlende, fremde oder selbstreferenzierende Eltern führen zur sichtbaren Kennzeichnung und eigener CSV-Qualitätsspalte. Aufträge bleiben beim ursprünglichen Kunden/Fahrer erhalten; dies vermeidet den stillen Wegfall durch den PHP-Inner-Join. Keine rekursive Zuordnung. Vergütung bleibt am ausgeführten Auftrag.
- 16 gezielte Tests, neun Frontendtests, Browser/CSV erfolgreich. Gesamtlauf 1032 Tests/1029 bestanden/drei übersprungen; 730 Quelldateien geprüft, auf Port 8080 bereitgestellt. Weitere Statistik-Spezialfilter bleiben separat offen.

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

- Aktuelle PHP-Kundenstatistik tatsächlich geöffnet, Monatsfelder „Datensatz angelegt seit“/„Nur Neukunden seit“ und sechs Diagrammarten geprüft. Serverdateien erneut unverändert gehasht; `statistic_sql.inc.php` 767–775 sowie `statistic.php` 214–215 und 1458–1749 maßgeblich. Echtes Schema nur lesend: `company.cmp_new_date` ist datetime, `customer.cs_become_cs_date` date.
- Beide Kundenzeitfilter ab einschließlich Monatsanfang, getrennt nach Anlage des Firmenstamms und Wechsel zum Kundenstatus. Kombinierbar mit Vergleichszeiträumen, bezahlendem/zugeordnetem Kunden, historischen Kundennummern und Leistungskalkulation. Filter folgen dem jeweils ausgewerteten Kunden. Niederlassungs-/globale Einstellung `MASK_STATISTIC_CS_CREATE_DATE_DISABLED` wird in der Oberfläche und erneut vor jeder Abfrage beachtet.
- Native Torten-, Balken-, normierte Stapel-, Multi-Balken-, Flächenstapel- und Flächendiagramme aus den vollständigen Abfrageergebnissen. Kennzahl und einzelner/alle Vergleichszeiträume wählbar, exakte gruppenbezogene Summierung und eigene zugängliche Wertetabelle. BSG wird aus summierten Werten neu berechnet, nicht addiert; Quoten werden nicht als additive Torten-/Stapelwerte angeboten.
- Negative Werte in Balken/Fläche, ausdrücklicher Hinweis bei ungeeigneten Torten-/Stapelwerten. Unbekannte Beträge bleiben Lücken; keine heimliche Nullsetzung oder Kürzung. Diagrammgrenze 120 Kategorien/30 Reihen mit sichtbarer Eingrenzungsaufforderung; Ergebnistabellen und CSV bleiben vollständig. Zielstations- und Kalkulationszählung werden korrekt benannt. Keine externen Diagrammdienste.
- 14 gezielte Tests, neun Frontendtests und Browser/CSV einschließlich aller sechs Diagrammarten erfolgreich. Gesamtlauf: 1030 Tests/1027 bestanden/drei übersprungen, 727 Dateien einschließlich Frontendtests/-Konfiguration gegen Manifest geprüft. Lokal auf Port 8080 bereitgestellt. Unternehmer-/Fahrerzuordnungen und weitere PHP-Spezialauswertungen bleiben gesondert offen.

## 18. Oktober 2026 – Statistik: Leistungskalkulation

- Frischer SSH-Abgleich derselben aktuellen Statistikdateien (Hashes siehe Erweiterte Zentralenstatistik). Die alte Kundenstatistik mit Calculatorformat und Preis-/Leistungstypauswahl tatsächlich geöffnet. `jobcalculator` und seine Mengen-/Preisfelder nur lesend im echten Schema geprüft.
- Eigene Auswertungsbasis Leistungskalkulation, Filter nach gespeichertem Preis-/Leistungstyp, Aufteilung nach beiden Typen und Einzelpreis. Menge und Umsatz stammen ausschließlich aus den Kalkulationspositionen; Positionen und verschiedene Aufträge werden getrennt gezählt. Identische doppelte Positionen bleiben echte Positionen. Fremde Niederlassungen sind ausgeschlossen.
- Positive/negative Auswahl folgt dem Positionsbetrag, auch bei positivem Gesamtauftrag. Halbmonatlich teilt wie PHP am 15./16. Tag. Vergleichszeiträume, sämtliche bestehenden Auftragsfilter, historische Kundenzuordnung und Zielstationsauswertung kombinierbar; bei Zielstationen wird die wiederholte Mengen-/Betragsbasis ausdrücklich ausgewiesen. Nicht zuordenbare Kurier-/KM-Kennzahlen werden in diesem Modus nicht vorgetäuscht.
- Tabellen und CSV unterscheiden Kalkulationswerte von Auftragswerten. Preis-/Leistungsaufteilungen werden beim Rückwechsel entfernt. Unbekannte historische Typnamen bleiben über die API filterbar; die Auswahllisten zeigen die freigegebenen aktuellen Kataloge ohne doppelte Namen.
- Zwölf gezielte Tests, fünf Frontendtests und Browser mit CSV, Gutschrift, kombinierten Typfiltern und Rückwechsel erfolgreich. Gesamtlauf: 1028 Tests/1025 bestanden/drei übersprungen, 717 Dateien geprüft. Port 8080 mit diesem Stand aktualisiert; Kundenzeitfilter, Diagramme und weitere Spezialauswertungen werden anschließend ergänzt.

## 18. Oktober 2026 – Statistik: alte Kundennummern

- Aktuelle PHP-Referenz `statistic/statistic_sql.inc.php`, insbesondere Zeilen 64–75 und 1697, plus tatsächlich geöffnete Kundenstatistik mit „Einbezug der alten Kunden-EID“. Die aktuelle Datenbank wurde ausschließlich lesend geprüft: `customerchanged` ist InnoDB, 1125 Zuordnungen/1105 alte Kunden, davon 16 mit mehreren unterschiedlichen Zielkunden (`work/statistics-current-schema.log`).
- Neue Option führt eindeutige Altzuordnungen genau einen Schritt zum Nachfolgekunden zusammen. Doppelte identische Zuordnungen vervielfachen nichts. Kundenfilter, Kundenaufteilung, Gruppe und Branche verwenden den zugeordneten Kunden; Kostenstelle bleibt die tatsächliche Buchungskostenstelle. Alle Vergleichszeiträume und Zielstationsauswertungen unterstützen die Option.
- Ziele müssen in den ausgewählten, freigegebenen Niederlassungen liegen. Mehrdeutige oder fehlende/nicht freigegebene Ziele bleiben ausdrücklich beim bisherigen Kunden. Betroffene Aufträge werden je Zeitraum gezählt und im Browser sowie mit eigenen CSV-Spalten kenntlich gemacht. Keine willkürliche Auswahl eines Nachfolgers und keine Stammdatenkorrektur.
- Zwölf gezielte Tests, fünf Frontendtests, Browser einschließlich Suche nach aktueller Kundennummer und CSV sowie Gesamtlauf mit 1028 Tests/1025 bestanden/drei übersprungen erfolgreich. 714 Dateien gegen Manifest geprüft. Port 8080 aktualisiert: Health UP, Datenbank verbunden, sechs Frontenddateien in dist/JAR/HTTP identisch.

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

- PHP-Filterauswahl tatsächlich geöffnet. Zusätzliche aktuelle Serverreferenzen: `admin/filter.php` SHA-256 `d3135148f5d06927465c53bf2b93d06aa3da41526d499d6ab700d07dc1dfb0b4`, `include/inc_filters.inc.php` `05eb95a45ead8ecb3681a7f455984d06d49b5cc4dc807481d2988dc52b5325c3`; Statistikreferenzen wie unten. Keine PHP-Einstellungen gespeichert.
- Durchsuchbare Anforderungsauswahl, gleiche Katalogausschlussgrenze `vht_id<=100`. Alle ausgewählten Kürzel müssen je Auftrag als Pflicht- oder optionale Anforderung vorkommen. Exakte kommaseparierte Tokens, keine Teilzeichen-/Wildcardtreffer; doppelte Katalogkürzel erscheinen gemeinsam mit ihren Beschreibungen. Die fehlerhafte PHP-Variable `$$tfx` für optionale Mitteltokens wird nicht übernommen.
- Startadresse und Adresse der zweiten Station als kombinierbare Aufteilungen. Wie PHP Straße/PLZ/Ort der Sortierpositionen 1 und 2, unabhängig von der letzten Station. Skalare Zuordnung verhindert Vervielfachung bei doppelten Stationspositionen; fehlende Adressen bleiben mit „–“ sichtbar.
- „Alle Ziel-PLZ“ wertet wie PHP jede adressierte Station mit `tr_sort>1` aus. Der volle Betrag und vorhandene KM-/CO₂e-Werte zählen je Zielstation erneut, auch in den Summen. Die Oberfläche weist deshalb ausdrücklich Zielstationen, Anzahl verschiedener Aufträge und die wiederholte Wertbasis aus; CSV-Kopf benennt diese Wertbasis ebenfalls. Dieser Modus ist keine gewöhnliche einmalige Umsatzsummierung.
- 1028 Tests/1025 bestanden/drei übersprungen erfolgreich; Browser und CSV geprüft, Port 8080 aktualisiert. Archiv, Leistungskalkulation, historische Kundenkonsolidierung und Diagramme bleiben separat offen.

## 18. Oktober 2026 – Erweiterte Zentralenstatistik

- Aktuelle PHP-Statistikmaske tatsächlich geöffnet und mit frisch per SSH gelesenen Serverdateien verglichen: `statistic/statistic_sql.inc.php` SHA-256 `db7c0b971795fbe062d49bcf286d6a119606859b4959f07487a4cfc7c9177d82`, `statistic/statistic_interface_hq.inc.php` `40fcbd4668f467610d31f2fec802488db8595756910d491f1eb531114d0bb84b`, `statistic/statistic.php` `f71da1670901c04bef452dceea6912a49f0fa9c3a573e58f2e027e0e2aec596f`. Keine PHP-Auswertung gespeichert oder echte Daten verändert.
- Fahrzeugkennung/SID, konfigurierte Auftragstypen (`vht_product`, ab 2), Erfassungsart Zentrale/Kunde sowie Unter-/Obergrenzen für Gewicht, Länge, Breite, Höhe und Stellplätze ergänzt. Wie PHP gelten positive Grenzen einschließlich; Null und leere Angaben schränken nicht ein. Erfassungsart folgt `job.emp_id → user.usr_type`, nicht `jb_origin`. Unbekannte oder entfernte Auftragstypen und widersprüchliche Grenzen werden abgewiesen.
- Branchenaufteilung über die Firma des zahlenden beziehungsweise zugeordneten Kunden und auf-/absteigende Sortierung sämtlicher Gruppen ergänzt. Unbekannte Branchen bleiben mit „–“ in der Auswertung; Aufträge und Summen werden durch Zusatzdaten nicht vervielfacht. Filter wirken auf alle Vergleichszeiträume und deren Gesamtsummen. CSV übernimmt die tatsächlich angezeigten Ergebniszeilen.
- Bestehende Auftrags-/Kurier-/Kundenfilter, Niederlassungs- und Mandantengrenzen bleiben wirksam. Anfragen ohne den neuen Filterblock bleiben kompatibel. Keine vollständige Statistikparität: Archiv, Leistungskalkulation, historische Kundenkonsolidierung, weitere Adressaufteilungen und Diagramme bleiben separat zu prüfen.
- Gesamtlauf mit 1027 Tests/1024 bestanden/drei übersprungen erfolgreich; Browser einschließlich CSV geprüft. Port 8080 aktualisiert, Health UP, sechs Frontenddateien in dist/JAR/HTTP identisch.

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

- **Aktuelle Referenz:** ausschließlich frisch per SSH gelesene Serverdateien unter `/data/0/votian-test/html`, Arbeitsbaum `2eb7f98`. `jobs2/job_options.php` SHA-256 `69651fa561f51a157ca8c49aef7f6f1ae27c80072af86f2c1e67b85ae41bfc63`, `jobs2/job_tour.tpl.htm` `b93f24cb9c213ac2564fc2fa347785a4b8ecfa76a97ef3e5f855c1aefadb9572`, `jobs2/job_edit.34.js` `8cbfd4f2fa4325183893675d567123413cda32ada7f1c07aca88e5593a55edf6`, `jobs2/get_saved_tour.php` `1079d235a31b47d7c4f75a8a51f6f3695999b14dcdf833310e5c8fae5bfdc158`. Die aktuelle PHP-Kundenerfassung wurde geöffnet; der Stationsframe liefert mit dem bestehenden Zentralenzugang HTTP 500 und ungelöste Vorlagenwerte. Die Tracking-Controls konnten dort deshalb nicht funktionsfähig bedient werden; Feldlänge, Freigabe und Speicherung sind aus dem aktuellen Servercode belegt.
- **Bearbeitung:** Eigene, noch nicht angenommene Kundenaufträge (Status 8/9) unter derselben Nummer ändern: Stationen ergänzen/umordnen/entfernen, Anschriften/Kontakte, Termin, Fahrzeug/Wunschkurier, Anforderungen, Maße, Zahler, Barzahlung und Kostenteilung. Preisvorschau mit aktueller Tarifprüfung, Erhalt unveränderter bestehender Festpreise, erneute Kostenverteilung/Vermittlungsfrist. Unveränderte alte Vorbestellzeiten bleiben gültig; neue Termine werden validiert. Statusübergang bei Wunschkurier wie PHP, manuelle/Fernverkehrs-Disposition hat Vorrang.
- **Schutz:** Aktuelle Kunden-/Kostenstellenrechte und Bearbeitungsfreigabe, Signaturen/erledigte Stationen, Export/Rechnung/Gegenbuchung, PHP-Bearbeitungssperre, Version sowie alle relevanten Buchungen/Parameter werden geprüft. Bestehende Stations-IDs und geschützte interne Vermerke bleiben an ihrer Station. Nicht mehr gültige Strecken-/CO₂-Werte werden verworfen beziehungsweise zur Prüfung markiert. Atomare Speicherung einschließlich Preisen, Audit und dauerhaftem Wiederholungsbeleg; keine Auftrag-neuanlegen-und-löschen-Abkürzung.
- **Tracking:** Kundenvorgabe `cs_tracking`, eine E-Mail je Station (maximal 60 Zeichen), Tourübernahme, Anzeige in der Vorschau, Anlage und Änderung. Nur die Empfängeradresse wird an den Browser geliefert; bestehende private Tracking-Teile hinter dem Trennzeichen bleiben bei Änderung an derselben Stations-ID erhalten. Leeren entfernt die Vorgabe, ausgeblendete Felder werden nicht gelöscht. Der PHP-GPS-Hinweis folgt der ersten Station und der Vorgabe `MASK_CR_PRICE_MODE`. Keine E-Mail wird beim Bearbeiten oder Prüfen versendet.
- **Grenzen:** Vollständige Kundenänderungen an Foto-Workflows, Versicherungs-/Mautbuchungen, Unternehmer-Unteraufträgen, gebuchten Artikeln/Lager, Fahrzeugreservierungen, Serien, übergreifenden Angeboten und komplexen Leistungskalkulationen sind weiterhin gesondert offen; solche Aufträge werden im neuen Voll-Editor ausdrücklich nicht verändert. Reine Text-/Kontaktänderungen haben ihren eigenen vorhandenen Dialog. Allgemeine Auftragsbearbeitung der Zentrale und Auftragsanlage sind getrennte Funktionen. Noch keine vollständige Anwendungsparität.
- **Prüfung:** Gemeinsamer abschließender Gesamtlauf mit 1023 Tests/1020 bestanden/drei übersprungen erfolgreich; 713 Quelldateien geprüft. Browserprüfung einschließlich ungültiger Adresse, umgeordneter Stationen und identischer Wiederholung erfolgreich. Port 8080 aktualisiert, Health UP, sechs Frontenddateien in dist/JAR/HTTP identisch. Ausschließlich isolierte Testdaten geschrieben.

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

- Eigene Anmeldung und eigener Arbeitsplatz für den konfigurierten Sonderkontotyp aus `DATATRANSFER_USERTYPE_SPECIAL` sowie Typ 5/RAMP. Bestehende Passwort-/2FA-Prüfung, keine Zentralenrechte; weder allgemeine Stammdaten noch Aufträge, Importaktionen oder Niederlassungswechsel erreichbar. Nur fest zugeordnete Ablage, Objektkennung und freigegebener Server. Geänderte Konten, Kontotypen, Niederlassungen und Konfigurationszuordnungen werden in laufenden Sitzungen erneut geprüft.
- Dokumentliste, Unterverzeichnisse innerhalb der Ablage, Download, Upload/Ersetzen, Entfernen/Wiederherstellen und Wiederaufnahme nutzen die vorhandene gemeinsame Ablage. Dateipräfix und Dokumentzähler gehören zum konfigurierten Kunden/Transporteur/Objekt. Externe FTP-/FTPS-/SFTP-Übertragung nutzt ausschließlich den hinterlegten Alias und Objekt-Unterpfad; Administratorvorbehalte gelten weiter. Lokale und externe Aktionen sperren sich nun auch bei unklaren Antworten gegenseitig.
- Eindeutige Konten-/HQ-/Mandantenzuordnung; Objekt muss zur zugeordneten Niederlassung gehören. Mehrdeutige EIDs, fremde Dateipräfixe, unzulässige Pfade und Symlinks werden abgewiesen. Typ 5 verwendet das niederlassungsgebundene Dateipräfix; der unbeschränkte PHP-Aufruf ohne Objekt-ID wird nicht übernommen. Keine Änderungen an vorhandenen Konten, Freigaben oder Serverdateien.
- Frischer SSH-Abgleich: `import/data_transfer.php` SHA-256 `c57b55631bb3c94533959f368fd46e65434525473bf0b355ca0ccf4305a0e067`, `include/global.inc.php` `ceb60bd61a1ae01729c151b78586ab8c5df301cb595e34eae8fbd923f71bcdd9`, `admin/login.php` `a59356d989b55f2f898ddc1af043df274d01591d87e3e04f3aed95f4ff276c98`, `include/dbglobal.inc.php` `5977c0c1a9c25b8a6d28957cedeec117479fb4d0b7d70353040e30721a566b87`. Alte Datentransfer-UI unter Zentralenkonto geöffnet; kein Sonderkonto im echten Browser angemeldet. Reale Konfiguration nur lesend: ein Typ-100-Konto, eindeutige Kunden-/TKBG-Zuordnung mit passender Niederlassung. Kein `import_TKBG.php` vorhanden; daher keine zusätzliche aktive Importfunktion aus diesem Alias abgeleitet.

## 17. Oktober 2026 – Classic-Tourbildung in der Restliste präzisiert

- `include/ajaxReqDisposition.php` ruft im Classic-Zweig `copy_jobs_cartage()` auf. Diese Funktion ist im aktuellen Serverbaum nicht definiert; das ausdrücklich eingebundene `include/copy_job.inc.php` enthält nur `copy_job()` und `setJobList()`. Damit ist ein funktionierender Classic-Zusammenfassungsablauf derzeit nicht als Portierungsreferenz belegt. Keine probeweise Ausführung mit echten Aufträgen.
- SHA-256: `admin/vehicle_disposition.php` `f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`, `include/ajaxReqDisposition.php` `80d00e71eabbeac4154d5b5724fd0d81410874abbef12bf0a69aa0aca04fbea0`, `include/copy_job.inc.php` `3b61f1771b8c4b111a55f1283150f873e4cbf4610cd81a00953edb9ee75387c3`. Einzelübergabe im Classic-Modus bleibt davon unabhängig bereits implementiert.


## 17. Oktober 2026 – Kundenseitige Text- und Kontaktkorrektur

- Kundenauftragsdetail → „Texte und Kontakte bearbeiten“: globale Kommissionsnummer (50 Zeichen), Auftragstext, Stationsfirma/-name, Kontakt, Telefon, Stationsreferenz (30 Zeichen) und freigegebene Stationsbemerkung. Vorher-/Nachher-Vorschau mit ausdrücklicher Bestätigung. Vorhandene Stations-IDs und Reihenfolge bleiben gebunden; dieser Dialog ändert keine Strecke oder Preise.
- Aktuelle PHP-Freigabe `MASK_JB_CS_EDITJOB`, Erfassungsfreigabe und Kundenlistenrecht, eigener Kunde/erlaubte Auftraggeber- und Zahlerkostenstelle sowie eigene Niederlassung. Nur Status 8/9 ohne Storno, Export, Rechnung, laufende Zuordnung, Gegenbuchung, Unterauftrag oder aktive PHP-Bearbeitungssperre. Bereits quittierte Stationen gesperrt. Rechte und Konfiguration werden auch vor jeder Wiederholung live geprüft.
- Interne `[[…]]`-Texte und Kassieranweisungen werden nicht zur Bearbeitung ausgegeben und unverändert erhalten. Deaktivierte Stationsbemerkungen bleiben vollständig erhalten. Geschützte Kennzeichnungen können nicht als Kundeneingabe eingeschleust werden. Änderung, Auftragsversion, Rechnungstext-Vormerkung, Audit 163 und Wiederholungsbeleg atomar; unklare Antwort sperrt Bearbeitung und erlaubt dieselbe Anfrage erneut.
- Frischer SSH-Abgleich: `customer/jb_list.php` SHA-256 `db2982580436d77796bb7ecccdcc7af7a763bdbe72e770dd012ffe80e652774c`, `include/jb_list_defineoutput.inc.php` `9c8087e29853641fca21fee5b76b0abbebad6231cb830e91a0c6f6bf3aab8a0a`, `jobs2/job_options.php` `69651fa561f51a157ca8c49aef7f6f1ae27c80072af86f2c1e67b85ae41bfc63`, `jobs2/job_options.tpl.htm` `d0d59bca7232dd11f7988583da672ccde92f217f64378e5c11186afccd57f0be`. Alte Kundenmaske tatsächlich geöffnet: Optionsfelder sichtbar, Stationsframe liefert HTTP 500. Keine echte PHP-Bearbeitung geöffnet/gespeichert.
- Teilumfang: kundenseitige Änderung von Strecke, Stationszahl/-folge, Abholzeit, Fahrzeug und Zahlungs-/Preisparametern bleibt separat offen. Rechnungsdarstellung wird vorgemerkt; vorhandene automatische PHP-Verarbeitung bleibt im Parallelbetrieb zuständig. Dieser Eintrag behauptet keine vollständige Kundenbearbeitung oder Gesamtparität.

## 17. Oktober 2026 – Rechnungslauf in der Restliste präzisiert

- Erneut frisch gelesen und UI geöffnet: `invoice/inv_details.php` SHA-256 `07f5406385de91c5297e7739a0632149c501575a41ef505a2ec1e7a28cc85332`, `invoice/invoice.php` `249fe840446468b184ec101a117857b6cfb0a75b5bbae145c3e1a1a855e951fe`, `inv_header.php` `6594da19ed12437839a6ec1ec3c6e1b1d19f2780348a748838bc7456e657d243`, `inv_list.php` `076642c7576fb94cb41a935e9fd790705e8d4550a8a870c5088ce7d7584be62d`. Rechnungsintervalle/-typen und Zentralen-Rechnungslauf stehen dort selbst unter TOBEDONE. Die ältere Behauptung einer fehlenden automatischen Nummernvergabe/eines implementierten PHP-Rechnungslaufs ist durch diese Menüseiten nicht belegt und wurde in der Übersicht berichtigt.


## 17. Oktober 2026 – Kundenspezifische PLZ-Reihenfolge bei Importen

- `XSplanTourStb978440` aus der erneut live gelesenen `locating/xServer.inc.php` (SHA-256 `db74afe6f4720fd7abb4749ef3842fb40441e9f98d82dba3686ab371b833b10c`) für ZONE_JOBS/BMW übernommen. Erste vollständig passende PLZ-Liste gewinnt: Berliner Reihenfolge ohne Umland, sonst erweiterte Reihenfolge mit 14612/16727. Gleiche PLZ behalten ihre Eingangsfolge.
- Die Sonderregel gilt ausschließlich für Kundenkennung STB978440, bei aktivierter Optimierung und mindestens drei Gesamtstationen. Sie benötigt keine Geokodierung und unterstützt das Importlimit von 100 Stationen. Unbekannte PLZ oder andere Kunden verwenden den bestehenden Routenweg. Die PHP-Korrektur vermeintlicher DOS-Zeichen an gemeinsam verwendeten Adressen wird nicht ausgeführt; CSV-Zeichensatz wird vor dem Import ausdrücklich gewählt.
- Auch eine gemäß PHP verschobene Abholstation erscheint an ihrer tatsächlichen Position in der Vorschau und wird dort gespeichert. Kostenstelle, Importmarker, Ziel-Fixpreise und Tourdaten folgen den richtigen Stationen. Anders als der alte nachträgliche Sortierer werden Preispositionen dabei nicht abgekoppelt. Andere Kunden können keine Verschiebung der Abholstation über den Importauftrag einschleusen.
- 17 gezielte Tests, fünf Frontendtests und Browserprüfung mit isolierten SQL-Daten erfolgreich. Letzter Gesamtprüflauf davor: 1007 Tests, 1004 bestanden, drei übersprungen. Aktiver PHP-Importer STB existiert auf dem Server nicht; die STB-Auswahl ist daher eine externe Serverauswahl, keine noch fehlende native Importdatei. Die Gruppen-Spaltenlayouts werden in den gewöhnlichen Importlinks/HTTP-Parametern nicht übergeben und bleiben als gesonderter, nicht über die normale UI erreichbarer Altcode dokumentiert.

## 17. Oktober 2026 – ALLERGO-Sendungsimport

- Nativer Einstieg unter Datentransfer → Kunden und aus `import_ALLERGO_`-Dokumenten. Aktives 46-Spaltenformat mit Kopfzeile, UTF-8/Windows-1252, Vorschau aller übernommenen Absender-/Empfänger-/Sendungsdaten. Ein Auftrag ALLERGO am Importtag 16 Uhr, Absender der ersten neuen Sendung als erledigte Startstation samt Unterschriftsname, Zielstationen in Dateireihenfolge. Keine Kurierzuweisung, Rechnung/Nullpreise/Steuerkennung 4/V, Null-Fixpreis je Ziel.
- Transaktionskennung im bestehenden PHP-Kontext `tr/info_0/ALLERGO`; Teilimporte überspringen bereits vorhandene Sendungen. Fremde/verwaiste/mehrdeutige Kennungen stoppen den Import. Namensübertragung nur nach sichtbarer Bestätigung und nur beim ausgewählten Kunden. Atomare Anlage einschließlich Adressen, Stationen, Preisen, Markern, Audit und dauerhaftem Wiederholungsbeleg; Tageswechsel stoppt neue Übernahme, erfolgreiche Belege bleiben abrufbar.
- Aktiv verwendete Paket-/Referenzdaten stehen als lesbarer Text in der Bemerkung. Empfängermail, Termin-/Warnfelder, Kuriernummer und Artikelbuchung sind auch im aktuellen PHP nicht aktiv angebunden und werden entsprechend nicht als Aktion ausgeführt. Das im CSV als `empbsp` bezeichnete Feld 19 ist im aktiven Code das Empfängerland; der Dialog dokumentiert diese Bedeutung.
- Bewusste Datenkorrekturen: explizite zweistellige Länder, vollständige Tourdaten einschließlich Absender und tatsächlicher Zielländer statt pauschalem DE, kein HTML in Bemerkungen. Unterschiedliche Absender in neuen Sendungen erfordern getrennte Dateien, statt Folgeabsender wie PHP stillschweigend zu ignorieren. Maximal 1 MB/500 Dateizeilen und 99 neue Ziele je Auftrag. Gruppen-Spaltenlayouts bleiben ein eigener Restpunkt.
- Frische Serverreferenz `import/import_ALLERGO.php`, SHA-256 `8eebcc801f62bdf11c1c25519716da52bc288c3cbbad5f16e972ea3892e1492a`; aktive Auswahl ALLERGO in der PHP-UI geprüft. Keine echte Importdatei und keine echten Aufträge verändert.

## 17. Oktober 2026 – BMW-Auftragsimport

- Nativer Kundenimport und Einstieg aus `import_BMW_`-Dokumenten. Aktives Standardformat mit Kopfzeile: Lfd., Bezeichnung, Straße, PLZ, Ort, Kommission, optional Dummy. Die laufende Nummer ist keine Kommission; Spalte sechs enthält die Kommissionsnummer. Keine Telefon-/Barfelder im aktiven Standardlayout. Ein Auftrag je Kundenzone mit Hauptkostenstellen-Abholadresse, Importtag um 09:00 Uhr, Nullpreisen/Disposition/Steuerkennung 4/V.
- Eigene PHP-Kennung `Kunde_Tag_Dateizeile_Kommission` im Kontext `BMW`, einschließlich Einfluss leerer Dateizeilen. Bestehende ZONE_JOBS-Kennungen unterdrücken BMW nicht. Vorschau mit optionaler nativer Optimierung, anschließend exakt diese Stationsfolge atomar speichern; Rechte, Tageswechsel, Revision und Wiederholung wie beim Zonenimport. Dessen Routenlimit und gesonderte Gruppenlayouts gelten weiterhin.
- Frisch gelesen: `import/import_BMW.php`, SHA-256 `40b92bb6bb72e989d33edb1f9dbc3d5dd7f828c39fa433c81d3de273f0945e16`. Auswahl BMW in der alten Import-UI geprüft, keine echte Datei ausgeführt. 93 gezielte Tests, fünf Frontendtests/Produktionsbuild und Browserprüfung mit synthetischen SQL-Daten erfolgreich. Gemeinsamer Gesamtprüflauf mit ALLERGO: 1004 Tests bestanden, drei übersprungen; anschließend lokal bereitgestellt.

## 17. Oktober 2026 – TIMS-Tourenimport

- Nativer Einstieg unter Datentransfer → Kunden und aus Dokumenten mit `import_TIMS_`. CSV-Aufbau wie TOURS, Datum TTMMJJJJ und 06:00 Uhr. Kommissionsnummer wandert nach Ankunft/Abfahrt als `[*Nummer*]` in die Stationsbemerkung; das Kommissionsfeld bleibt leer. Eigener Doppelimportkontext `TIMS`.
- Aktueller Parameter `IMPORT_TOURS_FIELD_TR_COMP` mit Niederlassungsvorrang und globalem Rückfall: `0` erhält die Firma ohne abgeleiteten Ansprechpartner, `1` trennt Firma/Ansprechpartner am doppelten Unterstrich, Standard übernimmt den ersten Bestandteil vor dem einfachen Unterstrich als Ansprechpartner. Der angewandte Modus ist sichtbar und Bestandteil der unveränderlichen Vorschau. Fehlende Kontaktbestandteile übernehmen keine Werte aus der vorherigen Zeile.
- Getrennte Prüfung gegen laufende PHP-Auswahl TIMS und frisch gelesene `import/import_TIMS.php`, SHA-256 `f2cb104c66bc092d9ce8454d335d9c7e86420ea047ec7cac273eb2a580aa6a55`. Gemeinsame atomare Anlage und Wiederholungsregeln des TOURS-/DHL-Imports; keine aktive Kurierzuordnung im PHP. Gruppen-Spaltenlayouts bleiben getrennt.

## 17. Oktober 2026 – DHL-Tourenimport

- Datentransfer → Kunden → „DHL importieren“ sowie Kundendokumente mit `import_DHL_`. Aktives PHP-Standardformat mit 9–14 Spalten, optionaler Kopfzeile/Abschlussspalte und ohne Kommissionsspalte. Datum aus TT.MM.JJ am Tourennamenende, 17:45 Uhr beziehungsweise 12:45 Uhr in Niederlassung 3; deutsche Adressen, Kontakt/Telefon und Ankunft-/Abfahrtbemerkungen wie bei TOURS.
- Eigener PHP-Doppelimportkontext `DHL`; vorhandene TOURS-Markierungen beeinflussen DHL nicht. Gemeinsame Vorschau, kundengebundene bestätigte Tourennamenübertragung, atomare Auftragsanlage und dauerhafter Wiederholungsbeleg. Der Beleg bindet auch das Format; Umschalten des Formats erlaubt keine Wiederverwendung desselben Vorgangs. Keine aktive Kurierzuordnung im aktuellen PHP vorhanden.
- Frisch per SSH gelesen: `import/import_DHL.php`, SHA-256 `98b2cbcb28ae97b5d1e24da9ed2b0089dbc6548536de20f83ff832fd180a091e`. DHL in der laufenden alten Datenimport-UI ausgewählt; keine echte Importdatei ausgeführt. Gruppen-Spaltenlayouts sind kein Teil dieses Standardimports.

## 17. Oktober 2026 – Tourenimport aus CSV

- Datentransfer → Kunden → „Touren importieren“ sowie Kundendokumente mit `import_TOURS_` öffnen den nativen Standardimport. Optionale Kopfzeile, 10–15 Spalten einschließlich optionaler Zeit-/Dummyfelder, UTF-8/Windows-1252, maximal 1 MB/500 Stationen/100 Stationen pro Auftrag. Die ersten zehn Pflichtspalten sind sichtbar dokumentiert; Ankunft/Abfahrt ergänzen Bemerkungen, Streckenzeit/Fixdauer/Dummy bleiben wie im aktiven PHP ohne Speicherung.
- Datum aus TTMMJJJJ am Ende des Tourennamens, 09 Uhr, Status 9/Disposition, Vorbestellung, keine Kurierzuweisung, Preise 0 und Steuerkennung 4/V. Ein Auftrag je zusammenhängender Tour, leere Namen übernehmen den vorherigen. Keine zusätzliche Startstation; Reihenfolge aus der Datei, nicht aus der frei wählbaren Stationskennung. Kontakt aus dem ersten Firmen-Namensbestandteil, Telefon aus dem dritten Bemerkungsbestandteil mit PHP-Landesvorwahlregel. Korrekt zitierte Nutztexte und mehrzeilige Bemerkungen bleiben erhalten.
- Vorhandene `tr/check_exist/TOURS`-Kennungen (Tourname plus Stationskennung, einschließlich führender Nullen) werden berücksichtigt. Teilimporte erzeugen ausschließlich die fehlenden Stationen im neuen Auftrag; Vorschau zeigt übersprungene Stationen. Ungültige Datumsangaben, doppelte Kennungen und auseinandergerissene Touren werden vor dem Schreiben abgewiesen.
- Übertragung bereits verwendeter Tourennamen nur nach ausdrücklicher Bestätigung der angezeigten Aufträge und ausschließlich beim gewählten Kunden in der eigenen Niederlassung. Andere Kunden-/Niederlassungsaufträge bleiben unverändert. Fremde oder verwaiste Doppelimportkennungen werden nicht ungeprüft übernommen. Dies korrigiert die unbeschränkte PHP-Umbenennung ohne Kundengrenze.
- Gemeinsame Transaktion für Namensänderungen, neue Aufträge, Stationen/Adressen, Nullpreispositionen, Importmarkierungen, Audit und Wiederholungsbeleg; zentrale Tabellensperren koordinieren paralleles PHP. Unklare Antwort wiederholt denselben Vorgang einschließlich bestätigter Namensübertragung. Keine Netzaufrufe im Schreibvorgang. Aktuelle Rechte 0/7/22 und InnoDB-Schreibtabellen erforderlich.
- Frische Referenz `import/import_TOURS.php` SHA-256 `dc3fcb5c78761c15c85f3dad3a50aa153f1253414d93caf26ec47a90a4080f6e`, aktive Telefonaufbereitung aus `include/global.inc.php`, CSV-Leser aus `include/inc_file.inc.php`. TOURS-Auswahl in der alten Datenimport-UI geprüft, keine echte Importdatei ausgeführt. Aktiver 15-Spalten-Code berücksichtigt statt veralteter 11-Spalten-Beschreibung im Dateikopf. Manuell übergebene Gruppen-Spaltenlayouts bleiben gesondert offen.

## 17. Oktober 2026 – Zonenbezogener Auftragsimport

- Datentransfer → Kunden → „Aufträge importieren“ sowie passende `import_ZONE_JOBS_`-Dokumente öffnen den nativen Zonen-Auftragsimport. Semikolon-CSV mit Kopfzeile, UTF-8/Windows-1252, Vorschau der Kundenzonen, Adressen, normalisierten Telefonnummern, Barhinweise und bereits importierten Zeilen. Grenzen: 1 MB, 500 Datenzeilen, 100 Stationen je Auftrag.
- Ein Auftrag je Zone, Hauptkostenstelle als Zahler, deren eindeutige Abholadresse als erste Station. Wie aktuelles PHP: heutiger Importtag 11 Uhr, Vorbestellung, Status 9/Disposition, keine Kurierzuweisung, keine Warenbewegung, Preise 0, Steuerkennung 4/V; je Zielstation eine Null-Fixpreisposition. Nichtleeres Barfeld erzeugt ausschließlich `**** BARZAHLUNG ****` in der Stationsbemerkung, keinen Barzahlerwechsel.
- PHP-kompatible Doppelimportkennungen `Kunde_Tag_Datenzeile_Kommission` in `tr/check_exist/ZONE_JOBS`. Leerzeilen behalten ihren Einfluss auf die ursprüngliche Zeilennummer; alte Anführungszeichenbereinigung wird für die Kennung berücksichtigt. Nutztexte selbst behalten Apostrophe/korrekt zitierte CSV-Zeichen. Führende PLZ-Nullen werden ergänzt; fehlende/mehrdeutige deutsche PLZ, Kundenzonen oder Kostenstellen stoppen den gesamten Import vor dem Schreiben.
- Optionale native Routenoptimierung bereits in der Vorschau, Start fest/Ende frei, 3–25 Stationen je Zone. Größere Touren oder nicht verfügbare Geokodierung/Optimierung behalten mit sichtbarem Hinweis ihre CSV-Reihenfolge. Übernahme verwendet exakt die geprüfte Folge; keine erneute Netzberechnung beim Speichern. Das vom aktuellen PHP aufgerufene `locating/tsp.py` fehlt auf dem Server; keine funktionierende PHP-Optimierung behauptet. Die kundenspezifische PHP-Sonderreihenfolge STB978440 ist inzwischen ergänzt (siehe neuester Abschnitt); manuell übergebene Gruppen-Spaltenlayouts bleiben gesondert.
- Aktuelle Kunden-/Erfassungs-/Importrechte (0/7/22), eigene Niederlassung und externe Stationskostenstelle werden geprüft. Kurze zentrale Tabellensperren stabilisieren auch die MyISAM-PLZ-Referenz gegenüber PHP. Aufträge, Adressen, Stationen, Preise, Markierungen, Audit und Wiederholungsbeleg gemeinsam atomar. Veraltete Vorschau, geänderte Zeilen und Tageswechsel vor Erstübernahme werden abgewiesen; erfolgreicher Vorgang bleibt auch am Folgetag identisch abrufbar.
- Frische SSH-Referenzen: `import/import_ZONE_JOBS.php` SHA-256 `034dc785f61fe04c72cb17494e5dd53295e9aca9f9a7986dbb70d7e84016da8b`, `locating/xServer.inc.php` `db74afe6f4720fd7abb4749ef3842fb40441e9f98d82dba3686ab371b833b10c`; `importCSV`, `getAddress` und Import-Verknüpfung aus den aktiven Include-Dateien gelesen. Alte Datenimport-UI auf ZONE_JOBS umgestellt; keine echte Importdatei ausgeführt. Abholadresse eindeutig auf die Hauptkostenstelle begrenzt statt der mehrdeutigen/fehlerhaften alten Hilfsabfrage.

## 17. Oktober 2026 – Kundenimporte aus der Dokumentablage

- Kundendokumente mit `import_ZONE_`, `import_ZONEAGIO_` oder `import_RADIUSZONE_` öffnen die vorhandenen nativen Importdialoge mit der passenden Importart und einer Kopie des Dateiinhalts. Vorschau und Übernahme verwenden weiterhin die bereits geprüften fachlichen Importabläufe.
- Gemeinsamer Quellabruf für Kunden- und PLZ-Import: Objekt-/Niederlassungsbindung, aktuelle Dokument- und Importrechte, bei Kunden zusätzlich Preisrecht 2, Dateirevision und 1-MB-Grenze. UTF-8 wird streng geprüft, alte Windows-1252-Dateien werden automatisch erkannt. Erneute Rechte-/Kontextprüfung nach Datei-I/O.
- Frischer Serverabgleich: `import_ZONE.php` SHA-256 `7bf4ad62340c4b55d4004c831f163b0dc78687c8266a9b6bd0f2cba8f23bc4cc`, `import_ZONEAGIO.php` `9c17e25f08bb354bd7fd224ed989977cddd8f4c57ed4b89c6a5f2bfb40a4cbca`, `import_RADIUSZONE.php` `c568fcd18045ebe5cdf00ea944b4b4e79f7275567d2e0be986ddf397436de795`. Formatwahl und Dokumentaktionen der alten Datenimportseite berücksichtigt. Auftragsbezogene Importformate bleiben separat offen.

## 17. Oktober 2026 – PLZ-Nachbarschaftsimport

- Unter Datentransfer → Datenimporte steht der native `ZIPCODE_NEIGHBOURS`-Import zur Verfügung. CSV-Datei oder eingefügter Inhalt, UTF-8/Windows-1252, Semikolon ohne Kopfzeile, bis zu zehn Nachbarn je Basis-PLZ. Passende Dateien in den Dokumentdialogen öffnen denselben Import mit einer geprüften Kopie ihres Inhalts.
- PHP-Semantik: ausschließlich gerichtete Verbindungen ergänzen, Reihenfolge aus der CSV-Spaltenposition, leere Spalten überspringen ohne Umnummerierung. Bestehende Zuordnungen und ihre Reihenfolge bleiben unverändert. Keine automatische Gegenrichtung und keine Löschungen. Doppelte Nennungen werden als bereits berücksichtigt angezeigt.
- Verbindliche Vorschau mit neuen/vorhandenen Verbindungen. Mehrdeutige/fehlende PLZ, widersprüchliche Bestandszuordnungen, Selbstverknüpfungen und unzulässige Zusatzspalten werden vor dem Speichern abgewiesen. Führende Nullen bleiben erhalten; numerische Kurzangaben werden nur bei eindeutiger Zuordnung ergänzt. Grenzen: 1 MB und 5.000 Verbindungen.
- Importrecht 22 wird live geprüft; Schreiben ausschließlich in die gewählte Niederlassung. MyISAM-PLZ-Basis während der Übernahme lesend gesperrt, InnoDB-Nachbarschaften, Audit und Wiederholungsbeleg atomar gespeichert. Veraltete Vorschau und geänderte Datei beim Öffnen erkannt. Identische Wiederholung nach verlorener Antwort erzeugt keine Duplikate.
- Frische SSH-Referenz: `import/import_ZIPCODE_NEIGHBOURS.php` SHA-256 `2060f14b48d96dec2e999a50c8f975d51400906650b2be4c5c53060ee2ca8803`. Alte Datenimport-UI auf dieses Format umgestellt und geprüft: keine FTP-Verbindungsdaten für das reine Importformat. Importschaltflächen/-vorschau zusätzlich aus dem aktuellen PHP gelesen; keine echte Importdatei auf dem Server ausgeführt.

## 17. Oktober 2026 – Externe Dateiübertragungen

- Dokumentdialoge bieten nun externe Dateien über FTP, explizites FTPS und SFTP. Serverauswahl aus `FTP_IMPORT_SERVERLIST`, Niederlassungs-/Globalvorrang der Verbindungswerte, Adminanzeige/-zugriff sowie objektspezifische entfernte Unterverzeichnisse entsprechen der aktuellen PHP-Konfiguration. Zugangsdaten bleiben ausschließlich serverseitig. Optionaler Port aus `FTP_PORT_<Name>`, sonst 21 bzw. 22.
- Dateien in die gemeinsame Ablage übernehmen, lokale Dateien senden, externe Dateien entfernen und wiederherstellen. Übernahme verwendet die vorhandenen Präfix-/Umbenennungs-, Quoten- und Dokumentzählerregeln; lokale Ersetzung erfordert die konkrete Vorschauversion. Vorhandene externe Namen werden nicht automatisch überschrieben: vorher entfernen oder anderen Dateinamen verwenden. Entfernen sichert die Datei im selben externen Verzeichnis.
- Dauerhafte Vorgänge und Dateiinhalt in der bestehenden generischen Ablage: identische Wiederholung nach Verbindungsabbruch, Fortsetzen mit ursprünglichen Daten, Erkennung geänderter Serverkonfiguration. Bereits erneut angelegte Fremddateien werden bei Wiederaufnahme einer Entfernung erhalten. Rechte und Zielkonfiguration werden vor und nach Netzwerkzugriff erneut geprüft.
- FTPS mit Zertifikats-/Hostnamenprüfung und verschlüsseltem Datenkanal; SFTP mit den konfigurierten vertrauenswürdigen Hostschlüsseln. Ungültige Pfade, Links und Namenskollisionen werden abgewiesen. Grenzen: 4 MB pro Vorgang, 2.000 externe Einträge. FTP besitzt keine atomare Nicht-überschreiben-Operation gegenüber unabhängigen Fremdclients; deren gleichzeitige Änderungen zwischen letzter Prüfung und Umbenennung sind eine Protokollgrenze. NG-Vorgänge sind untereinander serialisiert.
- Frische Serverreferenz: `import/data_transfer.php` SHA-256 `c57b55631bb3c94533959f368fd46e65434525473bf0b355ca0ccf4305a0e067`, `include/ftp.inc.php` `a7746c9cc91e229eb4e43a650b54f9e139e38d9e2171ee845896f7af21848795`. PHP-Serverauswahl, Protokolle und Übertragungsaktionen geprüft. Formatbezogene Datenimporte, kundenspezifische Sonderzugänge und RAMP-Zugänge bleiben getrennte Prüfpunkte.

## 17. Oktober 2026 – Zentraler Datentransfer und Dokumentbereiche

- Neuer Menübereich Datentransfer mit allgemeiner mandantenbezogener Dokumentablage, Unterverzeichnissen und Suche nach Kunden, Transporteuren, Fahrzeugen, Aufträgen und Mitarbeitern. Auftrags- und Mitarbeiterdokumente verwenden die bestehenden PHP-Verzeichnisse und Namenspräfixe; allgemeine Dateien behalten ihren Namen.
- Rechte 22/23 und objektspezifische Rechte werden aus der laufenden Sitzung und erneut aus der Datenbank geprüft. Allgemeine Ablage schützt auch speziell konfigurierte Objektverzeichnisse anderer Niederlassungen desselben Mandanten. Rootzugriff entspricht der PHP-Freigabe. Download prüft Rechte nach Dateiübertragung erneut.
- Gemeinsamer vorhandener Dokumentablauf: Upload, Ersetzen, Entfernen, Wiederherstellen, Dateizähler und sichere Wiederaufnahme unterbrochener Vorgänge. Kein neuer paralleler Dateibaum.
- Frische SSH-Referenz: `import/data_transfer.php` SHA-256 `c57b55631bb3c94533959f368fd46e65434525473bf0b355ca0ccf4305a0e067`, `include/inc_file.inc.php` `47307d7a2a1b0c26635431d366400d4a9a70de6f891a794144b13b0e411192f1`. Alte allgemeine Dokumentseite im Browser geprüft, ohne externe Verbindung oder Schreibaktion.
- Dieser Block deckt die gemeinsame Dokumentablage ab. Die angebotenen FTP-/FTPS-/SFTP-Verbindungen und formatbezogenen Importschaltflächen werden gesondert umgesetzt; sie sind damit noch nicht als erledigt markiert.

## 17. Oktober 2026 – Zentrale Kunden-CSV mit Zuschlagsaufteilung

- Abrechnung → Kunden-CSV: native Ausgabe der tatsächlich im PHP-Menü aufgerufenen `special_export_04`, mit den 21 originalen Spalten. Mindestpreis, Mehrkilometer/Menge, Nacht-, Wochenend-, Wartezeit- und Stoppzuschlag, positive sonstige Zuschläge, Fixpreisfälle, Kommentare, Kommissionsnummern, Kurier-/Firmenadresse und Steuerkennung. Bei Unternehmerzuordnung stammt die Adresse vom übergeordneten Kurier, die Steuerkennung weiterhin vom ausführenden Kurier.
- Die echte PHP-Erzeugung filtert nach **Erledigungsdatum**, obwohl deren vorgeschaltete Liste Auftragsdatum/Fahrzeuge anbietet. NG zeigt den tatsächlich exportierten Zeitraum und alle Fahrzeugtypen ausdrücklich. Nur erledigte, positiv bepreiste und bereits exportierte Aufträge; keine Null-/Platzhalter-Exportzeit, nur Storno 0/1/3. Gruppenkunden umfassen wie die aktive SQL-Auswahl ausschließlich direkte Unterkunden; NG begrenzt diese auf die eigene Niederlassung und gültige Kostenstellen.
- Vorschau, UTF-8-/Semikolon-Download, gemeinsame PHP-Exportablage, Dateiliste/Pagination, wiederholbare Speicherung, Fortsetzen/Verwerfen, Download sowie wiederherstellbares Entfernen. Nutzt die bestehende durable Exportablage mit unveränderlichem Inhalt, Prüfsumme und `exportfiles`-Verweis; unklare Antworten verwenden dieselbe Vorgangskennung. Keine automatische Löschung älterer Dateien beim bloßen Öffnen wie im alten PHP. Vorgeschriebene, noch nicht angebundene Exportverschlüsselung sperrt weiterhin die Serverablage.
- Beabsichtigte Korrekturen: PHP ermittelt die vermeintliche letzte Stationsnummer mit `getCountOfTable("job", $jbId)`; die aktuelle Hilfsfunktion zählt damit alle Aufträge. NG nutzt stattdessen die letzte gespeicherte Station innerhalb des konfigurierten Limits, sonst Auftragserledigung, mit sichtbarer Erläuterung. Unbekannte HQ-Kürzel verschieben keine Spalten, sondern verwenden den HQ-Namen mit Hinweis. CSV-Zitate schützen Semikolons/Anführungszeichen; potenzielle Tabellenformeln in Textfeldern werden neutralisiert. Geänderte Daten erfordern eine neue Vorschau.
- Frischer SSH-Abgleich `172.16.0.158:/data/0/votian-test/html`, HEAD `2eb7f98`: `jobs/jb_exp_csv.php` SHA-256 `c727017a3393b833d08a77104dd03b7595500fb02e7ae10e5ed73b7684d049a6`; aktives `export/exportrequests_special.inc.php` `1181e3ee85d786968ba9d778118cc517c35afb1452a52c9ee6346323b3f8af4f`; tatsächliche Implementierung von `getCountOfTable` aus `include/dbglobal.inc.php` gelesen. Alte CSV-UI ohne Kundenauswahl geöffnet, damit deren GET-seitige Dateilöschung nicht ausgeführt wird.
- Reale Metadatenabfrage bestätigt Spalten, InnoDB für `jobcalculator`/`exportfiles`/`genericdatacontainer` und eine konfigurierte Stationsgrenze 25. Keine echten Auftrags-/Kurierdaten gelesen, keine realen Dateien erzeugt oder entfernt. Weitere kundenspezifische Exportformate 01–03 und die übrigen noch nicht abschließend abgeglichenen Fachbereiche bleiben separat zu prüfen. Keine vollständige Anwendungsparität behauptet.

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

- Belegsammlung pro Rechnungsnummer mit Sortierung nach Kostenstelle/Auftragsnummer oder Auftragsnummer. Enthält alle aktuell zugeordneten Aufträge des ausgewählten Kunden in der eigenen Niederlassung, unabhängig vom Zeitraum/Fahrzeugfilter der Übersicht. Eigene Vorschau mit Seitenwechsel und Gesamtdownload; bisherige Leistungsübersicht bleibt verfügbar.
- Inhalt nach aktueller PHP-PDF-Ausgabe: Rechnungs-/Auftragszeiten, Fahrzeugart und Transporteur, Stationsadressen/Kontakte/Referenzen, Empfänger, Unterschriften und rabattierte Nettoleistungen. Unterschriften werden direkt im Speicher verarbeitet; keine PHP-Tempdateien oder externen URLs. Mehrseitige Aufträge bleiben lesbar, Kunden-/Niederlassungsgrenzen gelten auch beim Download.
- Fehlende Stations-/Leistungsdaten und defekte Unterschriften werden ausdrücklich angezeigt. Mehrdeutige Reihenfolgen, fremde Kundenanteile und offene Rechnungszuordnungen sperren die Sammlung. Vorschau-Revision und erneute Datenprüfung nach PDF-Erzeugung erkennen Änderungen einschließlich MyISAM-Rechnungsdaten. Grenzen: 500 Aufträge, 1.000 Seiten, 50 MB.
- Frische Serverreferenz: `jobs/jb_inv_assoc.php` SHA-256 `b0a72a13f805fc0b9604fec7418c2e48f369dc73887ce0de041b3905d03f2255`, `admin/jb_detail_.php` `30fde154de627bcce392b9a0ee82e494392f44ea7694c2c192f894fff5bd576d`. Alte PDF-Menüseite mit Sortieroptionen angesehen; keine realen PDF-/Tempdateien auf dem PHP-Server erzeugt.
- Die Belege sind Rechnungsanlagen mit Auftragsnachweisen. Eine darüber hinausgehende Finanzbuchhaltung wird damit nicht behauptet. Historische Tabellen und weitere dokumentierte Bereiche bleiben gesondert zu prüfen.

## 17. Oktober 2026 – Rechnungszuordnung und Korrekturen

- Abrechnung bietet nun einen eigenen Bereich für exportierte Aufträge nach Auftragsdatum. Fahrzeugtypen lassen sich mehrfach filtern; keine Auswahl entspricht allen Fahrzeugen. Die bestehenden Kunden-/Kurierübersichten bleiben nach Erledigungsdatum verfügbar.
- Rechnungsnummer und -datum können auch bei exportierten Aufträgen hinterlegt und vorhandene Angaben nach ausdrücklicher Auswahl korrigiert werden. Prüfansicht zeigt alte und neue Angaben je Auftrag. Datum wie PHP um 12:00 Uhr gespeichert. Unfertige, fremde und kundenübergreifend gesplittete Aufträge bleiben gesperrt; Preise und Exportstatus werden nicht verändert.
- Dauerhafter Vorgang vor MyISAM-Schreiben, exakter Vergleich von alter Nummer und vollständigem Datum, sichere Wiederholung nach unterbrochenen Antworten und Wiederaufnahme nach Teilfehlern. Gleichzeitige PHP-Korrekturen werden erkannt und nicht überschrieben. Bereits gespeicherte Teile bleiben beim Beenden erhalten. Frühere Vorgänge ohne Korrekturdaten bleiben lesbar.
- Frischer SSH-/UI-Abgleich: `jobs/jb_inv_assoc.php` SHA-256 `b0a72a13f805fc0b9604fec7418c2e48f369dc73887ce0de041b3905d03f2255`, `invoice/inv_details.php` `07f5406385de91c5297e7739a0632149c501575a41ef505a2ec1e7a28cc85332`, HEAD `2eb7f98`. Alte PDF-Ausgabe mit Datums-/Fahrzeugfiltern, Rechnungszuordnung und Sortierung im Browser angesehen. Keine echten Zuordnungen ausgeführt.
- Präzisierung früherer Restlisten: `invoice/inv_details.php` führt Rechnungslauf und Rechnungsintervalle selbst als `TOBEDONE`. Eine automatische Nummernvergabe ist in den geprüften Menüseiten nicht belegt und daher kein nachgewiesener Paritätsfehlpunkt. Die PDF-Auftragsbelegsammlung je Rechnungsnummer wird gesondert ergänzt; weitergehende externe FiBu-Prozesse sind damit nicht geprüft.

## 17. Oktober 2026 – Kundenkarte

- Eigenständige Kartenübersicht im Kundenportal mit Suche, gruppierten Fahrzeugmarkierungen, Fahrzeugauswahl, Telefonkontakt, Ortungsquelle/-zeit und automatischer Aktualisierung alle zehn Sekunden. Veraltete Ortungen werden deutlich markiert; abgeschaltete und ungültige Positionen bleiben ohne Kartenpunkt.
- PHP-Freigabe `MASK_JB_MAP_VIEW_ENABLED_<cs>` und explizite Fahrzeugliste `MASK_JB_MAP_VIEW_COURIERS_<cs>` werden bei jedem Abruf geprüft. Nur heutige, nicht zukünftige Ortungen im eigenen Mandanten und aktive Niederlassungen. Keine internen Auftrags-/Freimeldedaten. Entzogene Freigabe entfernt bereits angezeigte Daten sofort; leere Liste zeigt einen Konfigurationshinweis.
- Fahrzeugkennungen werden einzeln validiert und als gebundene SQL-Werte verwendet. Das alte PHP-Format `A','B` und einfache Listen werden unterstützt. Keine Ausführung gespeicherter SQL-Fragmente. Gemeinsame Kartendarstellung mit der Zentralenkarte, ohne deren Verwaltungsfunktionen in die Kundenansicht zu übernehmen.
- Frischer SSH-Abgleich: `locating/map.php` SHA-256 `c977597722131caf586ce62f72eb0fa35f498618a813b74794210d84a58a2b86`, `include/ajaxReqMap.php` `9693a843ed0ba6de90a69332b867e560858da2fa76dc1ae4d6ec2cb4a36ab7b8`, `locating/map.inc.php` `d7c7811b6ec6776b0c180dc575ee87aa6680682814c9a34267872ee18721ca6f`. Alte Karten-UI geöffnet; bestehender Zentralenlogin, keine vollständige PHP-Kundensitzung behauptet.
- Reale Konfiguration ausschließlich lesend geprüft: elf Kartenfreigaben, keine globalen Fahrzeuglisten. Daher werden ohne explizite Liste keine Fahrzeuge freigegeben. Die frühere Kartenlücke ist damit geschlossen; weitere Fachbereiche bleiben offen.

## 17. Oktober 2026 – Kundenseitige Kurierzuweisung

- Kundenauftragsdetail mit Auswahl freigegebener bevorzugter Kuriere, Verfügbarkeits-/Belegungswarnungen, abweichender Fahrzeugklasse, Zuweisungsvorschau, Rankingfolge und optionaler Rücksetzung der bisherigen Freimeldezeit. Ausschließlich eigene Kundenkostenstellen und Niederlassung, keine Unteraufträge, kein Related-Modus. Kundenparameter `CUSTOMER_MASK_JOBLIST_DISPO_FAV_ENABLED_<cs>` und Listenrecht werden bei jedem Zugriff erneut geprüft.
- Zuweisung erhält vorhandene Rankinghistorie; bevorzugter Kurier wird als angeboten gespeichert. Bisherige Kuriere erhalten den PHP-Rückruf mit 30 Sekunden Vorlauf. Anfahrtszeit aus `srvpt_traveltime`, mindestens 30 Minuten; künftige Aufträge verlieren erst nach dieser Schwelle Ranking. Vorhandene Bewertungsregeln werden angewendet. Keine Preisänderung und keine Vergabe von Zentralenrechten.
- Aktuelle Fahrer-/Fahrzeuganmeldung, widersprüchliche Präferenzen, bearbeitete/exportierte/stornierte Aufträge und Änderungen nach Vorschau werden geprüft. Schreiben, PDA-Rückruf, Ranking, Audit und Wiederholungsbeleg sind atomar; die Tabellen werden auch gegenüber alten MyISAM-Präferenzen stabilisiert.
- Frischer SSH-Abgleich: `customer/jb_list.php` SHA-256 `db2982580436d77796bb7ecccdcc7af7a763bdbe72e770dd012ffe80e652774c`, `include/jb_list_defineoutput.inc.php` `9c8087e29853641fca21fee5b76b0abbebad6231cb830e91a0c6f6bf3aab8a0a`; bevorzugte Kennungen aus `getCustomerCouriers` und Rankingfunktion gelesen. Die referenzierte `lib_courier.8.js` fehlt auf dem Server; vorhandene `lib_courier.js` zusätzlich geprüft (`2028034a884701e1fcfb5eda37c4783721905ccc3d6955d34b1ea17e1067ed38`). Die alte Kundenliste leitet den vorhandenen Zentralenlogin zur Startseite um; keine vollständige PHP-Kundensitzung behauptet.
- Reale Konfiguration: eine aktivierte Kunden-Dispositionsfreigabe. Karten-Sonderansicht, Archive und weitere Fachbereiche bleiben offen.

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

- Zahlungsarten gemäß aktueller PHP-Konfiguration: Rechnung/Barzahlung bei `MASK_CASH_PAYER_SELECT`, sonst zusätzlich Kostenteilung; nur bei freigegebener Zahlerauswahl. System-Barzahler und tatsächlicher Bezahler werden getrennt gespeichert. Pflicht-Kassierstation folgt beim Umsortieren der gewählten Station. Tarifbasis entspricht dem jeweiligen PHP-Modus.
- Kostenteilung über mehrere interne Kostenstellen mit centgenauen Nettobeträgen, Steuer und Gesamtbetrag in der Vorschau; keine öffentliche Betragsanzeige bei ausgeblendeten Preisen. Fremde Zahler, Kombination Barzahlung/Split, fehlende Kassierstation und nicht mehr freigegebene Modi werden serverseitig abgelehnt.
- Eigene Bar-/Split-Aufträge können nun geladen werden. Alte Kassierhinweise und Beträge werden entfernt und beim neuen Auftrag neu erzeugt. Auftrags-/Rechnungstext bleibt wie im PHP unabhängig von der Freigabe für Stationsbemerkungen verfügbar. Identische mehrfach vorhandene Parameterwerte sind zulässig, widersprüchliche Werte werden abgelehnt.
- Frische SSH-Referenz: `jobs2/job_tour.tpl.htm` SHA-256 `b93f24cb9c213ac2564fc2fa347785a4b8ecfa76a97ef3e5f855c1aefadb9572`, `include/inc_set_costsplit.inc.php` `6e66f2b0993d3dd5d445f2d0b043b2fed1f13ea476c6f1d4f1a0760baee455c5`; aktive JS- und Optionsdatei zusätzlich geprüft. Alle elf realen Niederlassungsparameter für `MASK_CASH_PAYER_SELECT` stehen auf 1; dort werden Rechnung und Barzahlung angeboten.
- Die oben ergänzte Zahlungsunterstützung ersetzt die Einschränkung im vorangegangenen Tourenblock. Andere dokumentierte Fachbereiche bleiben offen; keine vollständige Anwendungsparität.

## 17. Oktober 2026 – Kundentouren und Kopien

- Gespeicherte Kundentouren mit Suche, Zahlerfilter und Seitenwechsel laden; bei freigegebener Auftragsliste auch bestehende eigene Aufträge kopieren. Gleiche Funktion im Kundenauftragsdetail. Nur aktuelle aktive Kostenstellen des eigenen Kunden und die eigene Niederlassung; Verbund-/Related-Sicht erweitert die Kopierberechtigung nicht. Lesen setzt keine PHP-Bearbeitungssperre.
- Übernahme von Stationsfolge (einschließlich „Keine Warenbewegung“), freigegebenen Bemerkungen, Kommissionsnummer, Filtern und Lademaßen. Kommissionsnummer bei benannter Tour ersatzweise aus der ersten vorhandenen Stationsreferenz. Fremde Stations-Kostenstellen werden zu freien Adressen; interne `[[…]]`-Hinweise und interne Preisfelder gelangen nicht in die öffentliche Antwort. Neuer Sofortauftrag mit erneuter Prüfung, keine Übernahme erledigter Status oder alter Termine.
- Fest-/Servicepreise, bestehender Rabatt und Steuerschlüssel serverseitig aus dem Quellauftrag. Festpreis nur für identische Strecke, Fahrzeugart und Zahler; Zonenpreise werden neu ermittelt. Aktueller Kopiermodus übernimmt ausschließlich einen weiterhin freigegebenen Wunschkurier. Quellenänderung vor dem Speichern verwirft die Vorschau; eine bereits erfolgreich gespeicherte identische Kopie bleibt auch nach späterer Quellenänderung abrufbar.
- Kunden dürfen Vorlagen nur laden. Benennen/Überschreiben bleibt wie in den aktuellen PHP-Platzhalterblöcken der Zentrale vorbehalten. Vorlagenpflege ist bereits im Zentralenzugang vorhanden. Kopien von Bar-/Split-Aufträgen bleiben bis zum nächsten Zahlungsblock ausdrücklich abgelehnt.
- Fahrzeugtypen gemäß `MASK_EXCLUDE_VHT_IDS_CS` und `hq_vht_default`; ausgeschlossene Wunschfahrzeuge verschwinden. Bei alter, gesperrter Fahrzeugart in einer Tour erfolgt ein sichtbarer Wechsel zum aktuellen Standard und eine Neuberechnung. Pflichtlademaße gemäß `RANKING_JB2CRVH_MEASURE_CS_MANDATORY_<cs>` werden angezeigt und serverseitig geprüft.
- Frischer SSH-Abgleich: `jobs2/get_saved_tour.php` SHA-256 `1079d235a31b47d7c4f75a8a51f6f3695999b14dcdf833310e5c8fae5bfdc158`, `jobs2/get_tournames.php` `1cf58356a71780a11fe7d4b19072388faaae6790e5a90672e57bb38a11cd100a`, `include/ajaxReqJob.php` `2168ffc8b3a59851769fba110dfd15a1e5ed6e9798b151107f0652d046e021f2`; zusätzlich aktuelle Options-/Tour-Templates und aktive JS gelesen. Alte UI zeigt Tourenauswahl und vorbehaltene Eingaben, aber weiter einen defekten Tour-Frame und nicht ersetzte Platzhalter. Keine vollständige PHP-Kundensitzung behauptet.
- Weiter offen: Kundenbearbeitung bestehender Aufträge, Zahlungs-/Kalkulationssonderfälle und die weiteren dokumentierten Fachbereiche. Keine vollständige Anwendungsparität.

## 17. Oktober 2026 – Kundenseitige Auftragserfassung

- Neue Erfassungsmaske im Kundenportal: Sofortauftrag/Vorbestellung, Kostenstellen- und freie Adressen, Stationen hinzufügen/entfernen/umsortieren, Warenbewegung, Kontakte/Referenzen, freigegebene Bemerkungen und Lademaße, Zahlerauswahl, gewünschter Kurier und Kurierfilter. Herkunft 4, Besteller aus dem angemeldeten Konto und Auftraggeber-Kostenstelle werden serverseitig gesetzt. Erfassungsfreigabe nach `cs_jbedit`/`hq_workmode`; kein Zentralenrecht wird vergeben.
- Preisvorschau und Speichern verwenden die vorhandene Tarif-/Routen-/Foto-/Transaktionslogik. Die öffentliche Vorschau enthält ausschließlich freigegebene Kundenbeträge. Preisunterdrückung, Standardzahler, Unterkostenstellen, Wunschkurierbeziehung und erneute Freigabeprüfung unmittelbar vor dem Schreiben. Eine unverändert wiederholte Anfrage erzeugt keinen zweiten Auftrag; ungeklärte Speicherantworten sperren Änderungen bis zum Wiederabruf.
- Selbstbedienungsrabatt nach aktuellem `jobs2/job_options.php`: gerundeter Abzug beim kalkulierten Festpreis; bei PLZ-/Bereichstarifen Abzug in der Frachtvergütung, einschließlich des zusätzlichen aktuellen PHP-Subtotal-Schritts bei aktivem Frachtvergütungsmodus. Historisierung als Jobpreisart 13. Zentralenberechnung unverändert.
- Frische SSH-Referenz auf `172.16.0.158:/data/0/votian-test/html`, HEAD `2eb7f98` mit Arbeitsbaumänderungen: `jobs2/job_edit.php` SHA-256 `c514803932ab76e31274b3767dd685e0cf43486cebc5d6a9e00b5e7c4f4ed689`, `jobs2/job_options.php` `69651fa561f51a157ca8c49aef7f6f1ae27c80072af86f2c1e67b85ae41bfc63`, `jobs2/job_tour.php` `0631705934d95bdfd14f97cbeb145d15c3efe0d57842b0df17933fd4b22418f6`, aktive JS-Datei `job_edit.33.js` `8cbfd4f2fa4325183893675d567123413cda32ada7f1c07aca88e5593a55edf6`, `include/caglobal.inc.php` `1f27316a4005535136b03db60f713a54a1d7a588892d8948e5832000417def11`. Menüfreigabe zusätzlich aus `admin/menu.php:306–350` gelesen.
- Alte UI geöffnet: `jobs2/job_tour.php` HTTP 500, Optionsframe mit nicht ersetzten Platzhaltern. Daher keine vollständige funktionierende PHP-Kundensitzung behauptet. Reale Metadatenprüfung: 1.852 Kunden mit Erfassungsfreigabe, vier mit Kurierauswahl, einer mit Filterauswahl; SQL-Spalten und Steuerschlüssel 4/19 % bestätigt. Keine echten Aufträge angelegt.
- Weiter offen innerhalb dieses Bereichs: kundenseitige Bearbeitung bestehender Aufträge, Kopie/Tourvorlagen, Kunden-Leistungskalkulation, Sonderzahlungsmodi/Drittzahler und weitere kundenspezifische Maskenfelder. Dieser Block ist keine vollständige Kundenmaskenparität und keine vollständige Anwendungsparität.

## 17. Oktober 2026 – Aktuelle Kundenroute und Maut

- Frische Serverreferenz: `locating/showInGoogleMaps.inc.php` (`62fc4c364352984223650c31d90f0d588b41a81b5f71a8446b5857c52fe1ff5c`), `include/ranking.inc.php` (`1392991c91526072919097b96033079da880d4d759acbe1c43f858914c4d5c25`) und Kostenblock der aktuellen `include/jb_detail_history.inc.php`.
- Kundenauftragsdetail: aktueller Google-Maps-Routenlink bei laufendem, nicht storniertem Auftrag und aktivierter Mitarbeiterhistorie. Frische, gültige GPS-/Netzwerkposition (Typ 0/2/3) des aktuell zugeordneten Fahrzeugs im eigenen Mandanten; sonst letzte erledigte Station bis zur ersten unerledigten Station. Parameter für Ortungsalter, Standard 900 Sekunden, berücksichtigt. Zukünftige/abgeschaltete/veraltete/fremde Positionen ausgeschlossen. Vollständig erledigte oder unvollständige Routen zeigen einen Hinweis. Keine neue Geräteortung und kein externer Kartenaufruf beim Öffnen des Auftrags; Link öffnet durch Benutzeraktion.
- Maut und Summe einschließlich Maut im Kundenauftragsdetail und PDF. Entsprechend dem tatsächlichen PHP-Kostenblock wird die gespeicherte Maut unverändert addiert, auch bei bereits brutto ausgewiesenen Leistungen im Related-Modus. Keine Anzeige für nicht freigegebene Rechnungskostenstellen; ungültige oder mehrdeutige Mautpositionen werden nicht stillschweigend verrechnet.
- Eigenständige Kartenübersicht aus dem Kunden-Hauptmenü, Kunden-Erfassung/Bearbeitung, Archive/Sonderformulare und weitere Fachbereiche bleiben offen.

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

Frisch per SSH mit HEAD `2eb7f98` abgeglichen: `customer/brs_jb_list.php` (`d81e28466156c048c2c0b70d7c63577d6dfb41574302f3d07688ba198b5aaca6`), `include/jb_list_defineoutput.inc.php` (`9c8087e2…`), `include/jb_detail_history.inc.php` (`e85f0d42…`) und `include/inc_job.inc.php` (`0b660cee…`). Konstantenauflösung mit `defineGlobalParameters` aus der aktuellen `dbglobal.inc.php` geprüft.

- Kundenbörse bei `SYSTEM_BOURSE_MODE=1`: Angebote (0/8/9), laufende (1) und erledigte (2) Aufträge, feste Datumsauswahl, günstigstes Gebot, rabattierter Leistungspreis, Kostenstellenhierarchie, Sortierung, Pagination, Detail und Gesamtanzahl/-summe erledigter Aufträge. Preise werden unabhängig von Geboten/Stationszeilen summiert. Nur eigener Kunde und tatsächlicher Zahler; fremde Gruppenkunden, Barzahler-/Related-Umdeutungen und stornierte Listenzeilen ausgeschlossen.
- Die aktuelle PHP-Börsenseite liefert beim lesenden Browseraufruf HTTP 500; `jobs3/job_edit.php` fehlt auf dem Server. Im Datenbankbestand fehlen `bourse_bid`/`bourse_job` und die Aktivierung. Die neue Liste wurde deshalb mit synthetischer SQL-Fixture geprüft; bei Aktivierung ohne Gebotstabelle erscheint eine verständliche Fehlermeldung. Keine Aktivierung/Schemaänderung am echten Bestand. Börsen-Erfassung/Bearbeitung bleibt Teil der noch offenen Kundenbearbeitung.
- Auftragserfasser oder Mitarbeiterhistorie nach HQ-Parameter `MASK_JOBDETAILS_USER_HISTORY`: nur Vorgänge 1/10, Name/Vorname/Telefon; E-Mail nur in der Erfasseransicht. Mandantengeprüfte Kontakte, keine internen Logbeschreibungen, Seitenwechsel und sofortige Rechteprüfung. Der Parameter ist im aktuellen Bestand in allen 13 konfigurierten HQs auf 1 gesetzt.
- Stationsartikel unter Abliefernachweisen gemäß `MASK_JOBDETAILS_STATIONS_POD_SCAN_EVENTS`, konfigurierten Artikelspalten/-überschriften und Seriennummernoption. Keine Standardspalten, wenn PHP keine vorsieht; Spalte 99 bleibt wie der auskommentierte PHP-Ausgabezweig unsichtbar. Stationen über echte Sortiernummern; interne `[[…]]`-Hinweise entfernt. Auch im nativen Kunden-PDF enthalten. Paketanzahlzweig jetzt mit fehlendem/eindeutigem/mehrdeutigem/ungültigem Scanwert gezielt geprüft.
- Weiter offen: Kunden-Erfassung/Bearbeitung, aktuelle Routen-/Kartenansichten, archivierte Detail-Snapshots und Sonderformulare sowie die übrigen dokumentierten Fachbereiche. Kein Anspruch auf vollständige Parität.

## 17. Oktober 2026 – Kundenetiketten und Retouren

Aktuelle Serverquellen: `admin/metafield_special_cron.php` (`b8373b025e024548a430827b89d7c0478ae655f4ed720330f8e655d41771f9f3`), `include/inc_metafield.inc.php` (`149a46799258036404ac45ba315531195ed2b4c316bfa14b4addb5c5e13fdc65`) und `include/barcode.php` (`354eeed063787c276bad059edc83ce8c332afedc38ba2c7f6c048af456171f1b`). Aktuelle Datenbankvorlagen 1023/1024 samt Felddefinitionen lesend abgeglichen; Logo frisch per SCP vom Server übernommen und SHA-256 geprüft (`d3ab4b68…`).

- Kundenauftragsdetail → Etiketten / Etiketten Retoure: je Zielstation ein Blatt, Startstation 1 als Absender bzw. Retourenziel, vertauschte Adressrichtung, Auftragsnummer und nativer Code-128-Barcode wie im aktuellen PHP. Tatsächliche Stationsnummern bleiben auch bei Lücken erhalten; doppelte Nummern werden abgelehnt.
- PDF mit eingebetteter Schrift/Logo, Vorschau mit Seitenwechsel, Neuladen und Download. HQ-/Globalparameter `MASK_JB_LABEL_SIZE`: 60×40 mm als PHP-Standard, außerdem A4/A5/Letter. Reale Konfigurationsprüfung bestätigt beide aktuellen Vorlagen an allen elf Niederlassungen mit Kundenzugängen, überall A4. Keine echten Kundenetiketten erzeugt.
- Unterstützt sind die aktuell geprüften PHP-Vorlagen und deren Feldbelegung. Inhalts- oder Feldtypänderungen werden erkannt und verlangen erneuten Abgleich; keine beliebigen Vorlagenskripte, SQL-Ausdrücke oder externen Ressourcen. Eigenständiges natives Layout mit denselben wesentlichen Inhalten, keine allgemeine PHP-Template-Engine. Aktuelle Rechte/Zuordnung und Revision vor jedem Download; keine Änderungen am Auftrag.
- Auf Port 8080 bereitgestellt. Kategorie 300 für Abnahmeprotokolle fehlt im aktuellen Bestand. Allgemeine Sonderformulare, weitere Kundenabläufe und die übrigen dokumentierten Fachbereiche bleiben offen.

## 17. Oktober 2026 – Kundenauftragsdaten, Stationsnachweise und PDF

Frisch per SSH gelesen: `include/jb_detail_history.inc.php` (`e85f0d42456dd84773b4495653bbff02a1687ef1231401e15a45143f65d8aeff`), `admin/pdf_generic.php` (`de6e54d5d19fa52853949a7ce9b2086a6af257fd98c74c1a92f8a7d360a6b35d`) sowie objektbezogene Parameterauflösung aus `include/dbglobal.inc.php`; weiterhin HEAD `2eb7f98`.

- Kundenauftragsdetail: Re.-Ko.-Nr., Besteller, Kostenstelle, Fahrzeugtyp, Auslage, Gewicht, Reservierung und Annahme. Kuriername nur bei `CUSTOMER_MASK_SHOW_USER_DATA`, mandantengeprüft. Rabattierte Leistungen mit Summe; im Modus zugehöriger Kunde wie PHP brutto mit 19 %. Fremde Kostenstellen werden nicht offengelegt, eingeschränkte Summen ausdrücklich gekennzeichnet.
- Stationsnachweise: Unterschrift, freigegebene Ankunftszeit und Kostenstelle, Trackingadresse und Versandstatus ohne Token, Ablieferstatus/-grund gemäß Parameter; Paketanzahl bei eindeutiger Artikel-/Prozesszuordnung. Keine Koordinaten, internen Kuriernotizen oder `[[…]]`-Texte. Stationsfotos aus `pic` oder B2B mit Zuordnungsprüfung und erneuter Autorisierung beim Abruf. Defekte Nachweise werden angezeigt, ohne alle übrigen Daten auszublenden.
- Erledigte Kundenaufträge: eigenständiger PDF-Beleg aus derselben freigegebenen Projektion mit Leistungsaufteilung, Adressen, Unterschriften und Rechnungstext, mehrseitige Bildvorschau und Download. Geänderter Datenstand erfordert Neuladen. Nativer A4-Beleg; besondere PHP-PDF-Seitenlayouts und archivierte `job2`-Snapshots noch offen. Keine Rechnungserstellung und keine Nachweismail durch diese Leseaktionen.
- Auf Port 8080 bereitgestellt. Weitere Detailfunktionen (u. a. Scan-Artikelprozessdarstellung, Mitarbeiterhistorie und Karten), Etiketten/Protokoll, Kunden-Erfassung/Bearbeitung/Börse und übrige Fachbereiche bleiben offen. Die aktuelle Datenbank enthält Etikettenkategorien 302/303 mit Vorlagen 1023/1024; Kategorie 300 fehlt.

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

Frischer SSH-Abgleich mit `customer/jb_detail.php` (`df256286ec2b96bcaef0405f55bafdbc82384597b8e1998d919a9691d5d2ab8d`), `include/inc_job.inc.php` (`0b660ceef70176f64314cf74809fa681eac06553c534473a4690d0edf941e0c6`), `include/image.inc.php` (`9048068e16aa5f9e6e004a9cdd4b92ac2612d2cda55961529a2b57a6e78c32e8`) und `include/jb_list_defineoutput.inc.php` (`9c8087e29853641fca21fee5b76b0abbebad6231cb830e91a0c6f6bf3aab8a0a`), Server-HEAD `2eb7f98`.

- Artikel und Rechnungsposten an Station 2 entsprechend der PHP-Freigabe `MASK_JOBDETAILS_JBP_BOOKING_ENABLED`: konfigurierte Spalten/Überschriften, freie Positionen, Seriennummernoption, Warenwert/Packstücke/Gewicht sowie Bruttosummen. PHP-Steuerregel übernommen: gespeicherter `jb_sales_tax_rate` wird hier als Steuer-ID aufgelöst; fehlender Treffer einschließlich 0 verwendet 19 %. Uneindeutige Split-Kalkulation wird nicht einem einzelnen Kunden angezeigt.
- Mobile Dateifotos aus `genericdatacontainer` und exakt zugeordnete B2B-Fotos, Einzelansicht und Download. Separate `.env`-Konfiguration `PHOTOS_*`, begrenzte und validierte PNG/JPEG-Daten, erneute Zugriffsprüfung nach Dateiabruf. Mehrdeutige B2B-Auftrags-/Stationskennungen werden gesperrt. Das aktuelle Serververzeichnis `documents/photos` fehlt; betroffene Dateifotos erscheinen nicht verfügbar, B2B-Fotos bleiben unabhängig nutzbar.
- Interne `[[…]]`-Bemerkungen einschließlich eines nicht geschlossenen Endblocks werden aus Kundenausgabe und Suchkriterien entfernt. Detailaktualisierung und automatische Listenaktualisierung alle 60 Sekunden; standardmäßig bei offenen Aufträgen aktiv, bei erledigten aus, während Dialogen/inaktiver Seite pausiert.
- Auf Port 8080 bereitgestellt. Weiter offen: kundenbezogene PDF-/Etiketten-/Protokollabläufe, weitere Detailfelder, Erfassung/Bearbeitung/Börse und die übrigen dokumentierten Fachbereiche. Keine vollständige Parität behauptet.

## 17. Oktober 2026 – Kundenexport: Serverablage und Dateiverwaltung

Erneuter SSH-Abgleich mit `export/export.php` und `export/exportinterface_admin.inc.php`; Hashes unverändert (`30b7b10e…`, `c55b120e…`). Globale Parameterauflösung für `EXPORT_PATH` und die kundenspezifische Kopfzeile anhand der aktuellen Serverstellen korrigiert.

- Serverdateien speichern: unveränderlicher Exportinhalt mit Prüfsumme und Vorgangskennung, dauerhafte Zwischenablage in `genericdatacontainer`, eindeutiger physischer Dateiname, PHP-kompatibler Eintrag in `exportfiles`. Offene Speicherungen fortsetzen oder verwerfen. Ein Retry regeneriert den Inhalt nicht aus inzwischen geänderten Auftragsdaten.
- Manuelles Entfernen wie in der PHP-Maske, zusätzlich wiederherstellbar: Datei in `.ng-trash`, vollständiger Dateieintrag für die Rückkehr erhalten. Fehlende Dateien können als fehlende Listeneinträge entfernt und wiederhergestellt werden. Keine automatische Löschung beim Öffnen der Liste.
- Aktuelles Kundenrecht 7 und Hauptkostenstellenzugang, eindeutige Zuordnungen, globaler Ablagepfad, Namens-/Prüfsummenkonflikte, Fremdreferenzen, feste SQL-Sperren, InnoDB und Audit. Angefangene Datei-/Datenbankoperationen bleiben nach einem Ausfall fortsetzbar. Fremd veränderte Dateien werden nicht überschrieben oder entfernt.
- Abgelegte Dateien sind für Alt- und Neuanwendung über `exportfiles` sichtbar. Verschlüsselung ist im aktuellen Bestand deaktiviert; bei künftig aktivierter Pflichtverschlüsselung bleibt die Serverspeicherung gesperrt, bis deren native Anbindung umgesetzt ist. Sonderexporte, zentrale FiBu-/FTP-Verarbeitung, übrige Kundenabläufe und die anderen dokumentierten Fachbereiche bleiben offen.

## 17. Oktober 2026 – Gespeicherte Kundenexportdateien

Frischer Serverabgleich mit `export/exportdata.php` (`b1c1e1129249ee9bd3dc3b798b730249c0305b8cf319231402f0125c4144f851`) sowie Dateiliste und Dateinamenbildung in `export/export.php`. Native Liste mit Pagination und Binärdownload aus der gemeinsamen PHP-Ablage; separater, hostschlüsselgeprüfter SFTP-Root in `EXPORTS_*` aus `.env`. Keine Bereinigung beim bloßen Aufruf. Kundenrecht 7, eindeutige Konto-/HQ-/Mandantenzuordnung; historische Dateien ohne Kostenstellenumfang nur für den Kundenhauptzugang. Fehlende Dateien, ungültige Pfade, Symlinks, übergroße Dateien und kunden-/HQ-übergreifend kollidierende physische Dateinamen sind nicht herunterladbar. Nach dem Dateiabruf wird der Zugriff in einer neuen Transaktion erneut geprüft. Speicherung sowie Entfernen/Wiederherstellen inzwischen umgesetzt (siehe neueren Eintrag); Spezialexporte weiter offen.

## 17. Oktober 2026 – Kundenexport und PHP-Profile

Frischer SSH-Abgleich bei HEAD `2eb7f98` mit `export/export.php` (`30b7b10e11d76fc02e7b5103dc67680699604bc66b87022c568406c226ed0c28`), `export/exportrequests.inc.php` (`f3c65b08d27f86675ccca3e5fe877aa6f81130dc41288187a758d7e11ea4115a`) und `export/exportinterface_admin.inc.php` (`c55b120e0bf712a04f3f96981bad32cc8683816c3d6eaae96482ec0d34044bc1`). Aktuelle Exportmaske im Zentralenzugang geöffnet; Kundenvariante anhand des aktuellen Servertemplates geprüft. Die PHP-Dateiliste bereinigt alte Dateien bereits beim Seitenaufruf; weitere Abgleiche dieser Liste erfolgen nur im Quelltext.

- Kundenrecht 7 unabhängig von Zentralenrechten: Kategorien 110/115/120 (Kundenaufträge, Auftragsservices, Aufträge mit Services), aktuelle Felddefinitionen, eigene Unterkostenstellen und direkt zugeordnete Gruppenkunden im eindeutigen Mandanten. Unterkostenstellen-Zugänge bleiben im eigenen Baum. Erledigungsdatum, Status-/Stornofilter, rabattierte Leistungen, Invoice-/Stationsfelder und Kalkulationszeilen ohne Station beziehungsweise ohne Kalkulation.
- Profile im vorhandenen `exportparameters`: Auswahl, Anlage/Kopie, Änderung, Reihenfolge, Festbreiten, Ausrichtung/Füllzeichen, Zahl-/Datumsformate, Bedingungen, Teiltext/Links-Rechts, Feldverweise, Wiederholung/Zähler, Kopf-/Zeilen-/Dateitexte. Datenbank-SQL aus Felddefinitionen wird nicht ausgeführt. Aktuelle Rechte, Revision, feste Sperren, InnoDB, Audit und identische Wiederholung.
- Vorschau und UTF-8-Textdownload, maximal ein Jahr/2.000 Aufträge/10.000 Zeilen/10 MB; kein Auftrags-/Rechnungs-Exportkennzeichen verändert. Endzeichen werden nicht wie im alten unbedingten Abschneiden verloren; leere Länge bedeutet vollständiger Text. Datenwerte werden nicht erneut als Platzhalter interpretiert.
- Reale Altprofilprüfung: 22 von 34 Profilen verweisen ausschließlich auf 25 nicht mehr vorhandene Feldnummern (`100010` usw.). Sie werden als verwaist angezeigt und können im Entwurf bereinigt werden; keine geratenen Feldzuordnungen und keine Änderung dieser echten Profile.
- Noch offen in diesem Bereich: Sonderexporte, Verschlüsselung und zentrale FiBu-/FTP-Verarbeitung; Serverdateien sind inzwischen umgesetzt. Uneindeutige Split-Kalkulationszeilen werden ausdrücklich abgelehnt. Weitere Kundenabläufe, Rechnungsläufe und die übrigen dokumentierten Fachbereiche bleiben offen.

## 17. Oktober 2026 – Kundenstatistik

Frischer SSH-Abgleich mit `statistic/statistic.php` (`f71da1670901c04bef452dceea6912a49f0fa9c3a573e58f2e027e0e2aec596f`), `statistic/statistic_sql.inc.php` (`db7c0b971795fbe062d49bcf286d6a119606859b4959f07487a4cfc7c9177d82`) und `statistic/statistic_interface_cs.inc.php` (`022d382c3dbfe47f7ab72417cdc409febd6768169229bfc5a331a84e6defaa2a`). Alte Statistikmaske im Zentralenzugang lesend geöffnet; kundenspezifische Oberfläche anhand des aktuellen Servertemplates geprüft.

- Eigener Kundenmenüpunkt mit Recht 8: Anzahl und Nettoumsatz erledigter Aufträge, Gesamt-/Monatsformat, tägliches Zeitfenster, Halb-/Ganz-/Zweistundenaufteilung, Fahrzeug-SID, Fahrzeugtyp/Start-/Ziel-PLZ und Kombinationen, bezahlende Kostenstelle, Sortierung und konfigurierbare Vergleichsjahre. Recht 8 erlaubt in PHP die kundenweite Statistik unabhängig von Kostenstellen-Navigationsrecht 0 und Listenrecht 4; dieser Umfang wird separat geprüft.
- Gruppenkundenmodus zeigt ausschließlich direkt zugeordnete Kunden; deren Niederlassungen und die Aufträge müssen eindeutig demselben Mandanten angehören. HQ-Mehrfachauswahl mit Alle/Keine/Eigene und HQ-Aufteilung wie im Meta-Kundenzweig. Leere HQ-Auswahl liefert leere Ergebnisse.
- Stornofilter und `GLOBAL_USE_RELATED_CUSTOMER` berücksichtigt; Kostenstellenaufteilung erzwingt wie PHP den tatsächlichen Zahler. Keine Fuhrlohn-, internen Mitarbeiter- oder fremden Kundendaten im Ergebnis. Mehrere erste Stationszeilen vervielfachen keine Summen.
- CSV nur mit aktuellem zusätzlichem Kundenrecht 10, erneute serverseitige Auswertung der angewendeten Filter, Schutz gegen Formelausführung durch Textzellen. Nur aktueller Bestand; maximal ein Jahr je Zeitraum, zehn freigegebene Vergleichsjahre und 5.000 Zeilen je Zeitraum.
- Lokal auf Port 8080 bereitgestellt. Noch offen sind unter anderem Kunden-Datenexportprofile, Erfassung/Bearbeitung/Börse, Karten und Dokument-/Foto-/Formularabläufe sowie die früher dokumentierten übrigen Fachbereiche. Keine vollständige Parität behauptet.

## 17. Oktober 2026 – Kundenstornierung

Frischer SSH-Abgleich: `customer/jb_list.php` (`db2982580436d77796bb7ecccdcc7af7a763bdbe72e770dd012ffe80e652774c`), `include/jb_list_defineoutput.inc.php` (`9c8087e29853641fca21fee5b76b0abbebad6231cb830e91a0c6f6bf3aab8a0a`), `include/copy_job.inc.php` (`3b61f1771b8c4b111a55f1283150f873e4cbf4610cd81a00953edb9ee75387c3`) und `jobs2/job_options.php` (`69651fa561f51a157ca8c49aef7f6f1ae27c80072af86f2c1e67b85ae41bfc63`). Kundenoberfläche anhand des aktuellen Serverquelltexts; Tests mit synthetischen Daten, keine echte Stornierung.

- Aus dem Kundenauftragsdetail: Stornoprüfung und ausdrückliche Bestätigung. Kundenrecht 4, eigene erlaubte Kostenstellen/Verbundzuordnung und `CUSTOMER_MASK_JOBLIST_CANCELLATION_ENABLED_<Kunde>` werden aktuell geprüft. Nur kundenerfasste Aufträge mit Status 8/9, noch ohne Storno/Export/Rechnungszuordnung/Gegenbuchung; aktive PHP-Bearbeitungssperren bleiben geschützt.
- Storno ohne Kosten setzt Status 2, Stornokennzeichen 2, Benutzer/Zeit und den PHP-Hinweis; Kommissionsnummern werden geleert. Standardmodus erzeugt genau eine negative Gegenbuchung einschließlich Preispositionen und typgeprüfter B2B-Rechnungspositionen. Der gespeicherte Gesamtpreis wird exakt negiert, auch bei historischen Abweichungen zu Leistungszeilen. Im Modus des zugehörigen Kunden entfällt die Gegenbuchung wie in PHP.
- Zahlungen, FDS/Disposition, Ranking, PDA-Kommandos und die Dauerauftragsregel bleiben unverändert. Aktueller Scope und Freigaben, Revision, InnoDB, Sperren, Audit und Wiederholungskennung sichern die gemeinsame Speicherung. UI sperrt Eingaben nach unklarer Antwort und wiederholt denselben Vorgang.
- Auf Port 8080 bereitgestellt und geprüft. Andere Kundenabläufe und die zuvor aufgeführten übrigen Bereiche bleiben offen.

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

Frischer SSH-Abgleich mit `invoice/inv_details.php` (`07f5406385de91c5297e7739a0632149c501575a41ef505a2ec1e7a28cc85332`), `invoice/inv_aux.inc.php` (`fab9bf7297e853aa0d4e17fd8f41a0e6b5f1bc12d74786d8204cd5ca2fef80a2`), `include/services_func.inc.php` (`4bd29ac9ef3b0cdb5194091c90c56740868e9d9b4c8fdfde4229f8720a6d7a10`), `admin/GA_generateBarcode.php` (`fd3f8684cd36a550315b4457dce5661edbf15fb535a4770a679ffe86872e6c5d`) und `admin/start.php` (`a99041a0d1e2139da36af9474d877183ea643017a64b9955395aebede0541fb6`). Alte Abrechnungsmaske lesend geprüft; der PHP-QR-Aufruf schreibt bereits beim Öffnen einen Schlüssel und wurde deshalb nur im aktuellen Serverquelltext geprüft.

- Kundenrecht 5 öffnet eine eigene Abrechnungsübersicht: eigene Kostenstelle/Unterbaum, Erledigungszeitraum, reguläre Aufträge und Kostensplit, Leistungen/Rabatte, Status und seitenübergreifende Summe. EXTERN/PRIVAT samt Unterbäumen bleiben ausgeschlossen. Kundenrecht 0 ist hierfür wie in PHP nicht erforderlich.
- Kostensplits berücksichtigen alte und native Kennzeichnung; Beträge sind auf zugeordnete Kostenstellen begrenzt. Die Detailansicht aus der Abrechnung benötigt kein zusätzliches Listenrecht 4. Für Splitpositionen erscheinen ausschließlich eigene Stationen/Anteile, kein gemeinsamer Rechnungstext mit möglichen Fremdangaben.
- Eigene Kunden-2FA ohne Zentralenrechte: PHP-Kundenfreigabe (zweiter Wert von `USERTYPE_2FA_ENABLED`), aktuelles Passwort, lokal erzeugter QR-Code, sechsstelliger App-Code, Abbruch/Neubeginn und Deaktivierung. Schlüssel bleibt bis zur Bestätigung ausschließlich in der Sitzung; zehn Minuten Gültigkeit, fünf Fehlversuche, Konfliktprüfung, atomare Speicherung und Wiederholungskennung. Der Aktivierungscode kann nicht erneut zum Login verwendet werden.
- Korrektur gegenüber der vorherigen Mitarbeiterumsetzung: `USER_2FA_NO_DEACTIVATION` sperrt in PHP nur Typ 1. Kunden dürfen die eigene 2FA nach Passwort-/Codeprüfung deaktivieren. Keine Geheimnisse im Audit; bestehende Sitzungen werden bei Zugangsdatenänderung widerrufen.
- Noch offen: Brutto-Zahlungszuordnung für Kostensplits bei Sonderniederlassungen >1000, vollständiger Rechnungslauf, Archiv, weitere Kundenabläufe (Erfassung/Bearbeitung/Storno/Börse/Export/Statistik/Karten/Dokumente/Fotos/Formulare) und übrige zuvor dokumentierte Lücken. Keine vollständige Anwendungsparität behauptet.

## 17. Oktober 2026 – Kundenmitarbeiter und eigenes Konto ergänzt

Frischer SSH-Abgleich mit `admin/employee.php` (SHA-256 `4c90cdf4e63b0861dc7780cb6fd3184f8c3b21667ba90a6e6c706c8a75037bce`), `admin/employee_list.php` (`09bfbd1a245d08cb47533d5082e1275a8de1d944d53bbb9212e1c06d4da32451`), `admin/employee_csc_rights.php`, `include/dbglobal.inc.php` und `include/global.inc.php`; alte Mitarbeitermaske im vorhandenen Zentralenzugang lesend geöffnet. Kundenvarianten anhand der aktuellen Typ-2-Zweige geprüft, keine Impersonation und keine lokale PHP-Referenz.

- Kundenarbeitsplatz mit Mitarbeiterliste, Kostenstelle/Unterkostenstellen, Suche, sieben Sortierungen, Seitenwechsel und eigenem Konto. Ohne Kundenrecht 2 bleibt nur das eigene Konto sichtbar.
- Anlage, Name/Vorname/E-Mail/Telefon/Mobil/Anmeldename nach Kundenrecht 2 und 10 bzw. globaler Freigabe. Geburtstag und Kostenstellenwechsel sind keine Kundeneingaben. Hauptzugang gegen Fremdbearbeitung/Löschung geschützt; neue Mitarbeiter beginnen ohne Rechte.
- 16 Kundenrechte getrennt vom Zentralenrechtekatalog. Keine Selbstrechteänderung, keine Vergabe/Entfernung nicht delegierbarer Rechte; unveränderbare Rechte bleiben erhalten. Kostenstellenmatrix bei aktiver PHP-Vorgabe, Rechten 2/10/12 und begrenzter Delegation, ohne neue Tabelle anzulegen.
- Passwort für eigenes Konto bzw. durch Kundenhauptzugang mit aktueller eigener Passwortprüfung; 2FA-Rücksetzung mit Kontobestätigung, bei eigener Rücksetzung zusätzlich aktuellem Code und globaler Deaktivierungssperre. Geheimnisse werden nicht protokolliert. Änderungen an Zugangsdaten widerrufen bestehende Sitzungen.
- Kontolöschung räumt persönliche Vorgaben/Freigaben atomar auf. Aktueller Scope, Rechte, Konfliktprüfung, InnoDB, Audit und identische Wiederholung für alle Mutationen. Auf Port 8080 bereitgestellt und geprüft.
- Noch offen im Kundenportal: 2FA-Neueinrichtung, Erfassung/Bearbeitung/Storno, Börse, Abrechnungsübersicht/Export/Statistik, Karten, Dokument-/Foto-/Formularabläufe und Archiv. Die älteren Angaben zu fehlender Kostenstellen- und Mitarbeiterpflege sind überholt.

## 17. Oktober 2026 – Kundenportal: Kostenstellenpflege ergänzt

Frischer SSH-Abgleich mit `/data/0/votian-test/html/customer/costcenter.php`, SHA-256 `55add4eefc9244736d9ffa6de69e037774dc94089d850eb1e9a958134beff09e`. Keine lokale PHP-Referenz verwendet.

- Eigene Kostenstellen und berechtigte Unterbäume/Kundenverbünde, Kundenrecht 1 für Anlage/Umbenennung/Sichtbarkeit/Löschung, Kundenrecht 3 für Adressen. Persönliche Basis und Hauptkostenstelle geschützt; EXTERN-Pfade erlauben keine Strukturpflege.
- Neue Unterkostenstelle übernimmt vier Adressen und das Intervall der Kunden-Hauptkostenstelle. Umbenennung aktualisiert Unterpfade; Löschung prüft sämtliche im aktuellen Schema vorhandenen Kostenstellenbezüge und Unterkostenstellen.
- Adresstypen, Firmenzeilen, Elternfirmenvorgabe, Ansprechpartner/Kontakt/Bemerkung, Hausnummer, Adressvorschläge, Geocoder und zusätzliche abwählbare Straßenverzeichnisprüfung. Globale Firmensperre berücksichtigt. Geteilte Adresszeilen bleiben unverändert; Änderungen an der Hauptadresse setzen den Kundenänderungsstatus wie PHP.
- Vorschau, ausdrückliche Bestätigung, Konfliktprüfung, aktuelle Rechteprüfung, Transaktion, Audit ohne Geheimnisse und sicher wiederholbare Speicherung. Abrechnungsintervall/-typ/-modus sind in dieser PHP-Maske Zentralenfunktionen und werden Kunden hier nicht freigegeben.
- Lokal auf Port 8080 bereitgestellt und geprüft; Kundenmitarbeiterverwaltung sowie weitere Kunden-/Abrechnungsabläufe werden weiterhin ergänzt. Kein Anspruch auf vollständige Anwendungsparität.

## 17. Oktober 2026 – Kundenzugang und Auftragslisten

- **Referenz:** frisch per SSH gelesener Stand `2eb7f98`; `customer/jb_list.php` (`db2982580436d77796bb7ecccdcc7af7a763bdbe72e770dd012ffe80e652774c`), `customer/jb_detail.php` (`df256286ec2b96bcaef0405f55bafdbc82384597b8e1998d919a9691d5d2ab8d`), `customer/costcenter.php` (`55add4eefc9244736d9ffa6de69e037774dc94089d850eb1e9a958134beff09e`), `include/auth.inc.php` (`67397664c0d901e81bb6a9047905488c7bafd84be453fc7b713e2f5f751f8866`). Die PHP-Kostenstellenmaske ist im vorhandenen Zentralenzugang sichtbar; die Kundenliste leitet diesen zur Startseite zurück.
- **Nativ:** eigene Typ-2-Anmeldung mit vorhandenen Passwörtern/2FA, strikt getrennte Kundenrechte und eigener Arbeitsplatz. Listen mit Kunde/Kostenstelle/Unterkostenstellen, Kundenverbund, offen/erledigt, Datum, Nummer-/Firmen-/Kommissionssuche und Stationssuche mit Bemerkungen sowie parameterabhängigen Adressfeldern. Normale Suche ersetzt wie PHP den Zeitraum, Stationssuche behält ihn. Barzahlerzuordnung und `GLOBAL_USE_RELATED_CUSTOMER` berücksichtigt.
- **Anzeige:** 22 erlaubte PHP-Spalten, persönliche/kundenweite Vorgaben, Überschriften, Ausrichtung, Zusatzspalten, Sortierung und 50 Zeilen pro Seite. Native Details mit Stationen, Ansprechpartner, Zustellzeit/Empfänger und Kundenrechnungstext. Keine fremden Kostenstellen/Mandanten, Fuhrlohn- oder internen Bemerkungsfelder. Ungültige/cyclische Hierarchien werden abgegrenzt; aktuelle Rechte und Zuordnungen werden pro Zugriff erneut geprüft.
- **Weiter offen im Kundenportal:** Kostenstellen-/Adresspflege, Mitarbeiter-Selbstverwaltung, Erfassung/Bearbeitung/Storno, Kundenbörse, Übersicht/Abrechnung/Export/Statistik, Karten, Dokument-/Foto-/Formularabläufe und Archiv. Freie SQL-Spezialspalten werden nicht ungeprüft übernommen. Keine vollständige Kundenportal-Parität behauptet.


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

- **Referenz:** aktueller SSH-Stand `2eb7f98`, `courier/brs_jb_list.php` (`ba6b951c9e8f835faf215adbfbc612070ec359e8b2c1718ea896b188cf59cf3b`), `include/jb_list_defineoutput.inc.php` (`9c8087e29853641fca21fee5b76b0abbebad6231cb830e91a0c6f6bf3aab8a0a`) sowie Fristdarstellung in `include/mcglobal.inc.php`. Die echte PHP-Börsenseite liefert HTTP 500; ihre verlinkte Datei `jobs3/jb_detail.php` fehlt auf dem Server.
- **Nativ:** Eintrag im Transporteurportal ausschließlich bei `SYSTEM_BOURSE_MODE=1`. Status 9 und ausdrückliche Kundenbeziehung (`customercourier.cscr_relation=1`), unabhängig von der eigenen Auftragszuweisung. Eindeutiger Mandant für Auftrag und Kunde, keine Freigabe über untergeordnete Transporteure. Niederlassungen Alle/Keine/Eigene, Datum, Nummernbereich mit Datumsübersteuerung, Fahrzeugtyp, sechs Stationsfilter, 16 erlaubte PHP-Spalten mit Konfiguration, Sortierung, 100–1000 Zeilen/Seite, zehn Seiten, automatische Aktualisierung und einklappbarer Suchkopf.
- **Details:** native lesende Stationsansicht mit Kundenpreis/Fuhrlohn und Dispo-Info. Status, Kundenfreigabe und Kontozuordnung bei jedem Aufruf erneut geprüft; keine internen Freitextfelder. Auftragsannahme/Bieten werden in dieser PHP-Listenmaske nicht angeboten und daher nicht erfunden.
- **Betrieb:** Die vorhandene Datenbank hat keine aktivierte Börsenniederlassung. Schalter wurden nicht geändert. Kundenportal und die übrigen dokumentierten Bereiche werden separat fortgesetzt.

## 17. Oktober 2026 – Transporteurzugang und Auftragsabrechnung

- **Referenz:** direkt per SSH gelesener Stand `2eb7f98`: `invoice/inv_details_cr.php` (`30d54c18110614e60e2a144b0cfad0047ca96b9e9277bae878bff22a257aef47`), `invoice/inv_header.php` (`6594da19ed12437839a6ec1ec3c6e1b1d19f2780348a748838bc7456e657d243`), `courier/cr_changepwd.php`, `include/services_func.inc.php`, `invoice/inv_aux.inc.php` und `invoice/crHistoryUN.php` (`702592332670949c2ccc77329e67138bc587085b6dbb15563db11d0959197349`). Die PHP-Seite ist im vorhandenen Zentralenlogin nicht als Transporteur darstellbar; der Browser zeigt einen Serverfehler. Es wurden keine realen Zugangsdaten geändert.
- **Nativ:** Typ-3-Anmeldung mit vorhandenen Zugangsdaten/2FA; eigener Arbeitsplatz mit erledigten und parameterabhängig laufenden Aufträgen, Datumsbereich, Fahrzeugfilter, direkten Untertransporteuren, Rechnungstext, Tour/Erfasser/Zeiten, Leistungs-/Fuhrlohnausweis, provisionsfreier Spalte und Abrechnungssummen. Fahrzeugtyp, enthaltene Servicevergütung/Treibstoffzuschlag und Unvollständigkeitskennzeichen ergänzt. PHP-Regeln für Fixpreis, Stichtag, Kostensplit, Fahrzeugprovision, Sonderniederlassungen und Bargeldabrechnung übernommen.
- **Bemerkung und Passwort:** parameterabhängige Kurierbemerkung mit Revision und identischer Wiederholung. Passwortwechsel mit aktuellem Passwort, bestehender 2FA, Sitzungswiderruf und geheimnisfreien Belegen. Rechte, Kontozuordnung und Schreibvoraussetzungen werden im atomaren Vorgang erneut geprüft.
- **Historie:** Fahrzeugauswahl → Log anzeigen; kompletter zugehöriger Transporteur, erlaubte PHP-Vorgänge, Zeitraum, maximal 4000 Zeilen und begrenzte aufbereitete Details. Keine rohen vertraulichen Protokollinhalte. Konten, Fahrzeuge, Aufträge und Historie bleiben im eindeutig zugeordneten Mandanten; Zentralen-/Lagerpfade und Niederlassungsheader sind gesperrt.
- **Weiter offen:** bedingte Auftragsbörse, Kundenportal, Archivbestand und übrige dokumentierte Bereiche. Ältere Angaben zum vollständig fehlenden Transporteurportal sind damit überholt.
## 17. Oktober 2026 – Lagermitarbeiterverwaltung

- **Referenz:** frisch per SSH gelesene `admin/user_list.php?userListOfType=4`, Stand `2eb7f98`, SHA-256 `d843407cd8cc7dc7433f0ada2984dcaad4eb6be74772ab30cc131d0932ae05a0`; angemeldete PHP-Maske lesend geprüft.
- **Nativ:** Verwaltung → Lagermitarbeiter mit Niederlassungs-Mehrfachauswahl (Alle/Keine/Eigene), Suche, sieben Sortierungen, Anlage, Kontakt-/Fax-/Geburtstagsdaten, Anmeldename, Startlager, Passwortwechsel und Kontolöschung. Neue Konten besitzen ausschließlich Typ 4, keine Zentralenrechte und zunächst Lesezugriff ohne Lagerfreigaben. Nach der Anlage öffnet sich die Freigabepflege; danach ist das Startlager auswählbar.
- **Freigaben:** Hauptlager, Unterlager einschließlich Nachfolger, Lesemodus und Artikelzugang über die vorhandenen Parameter. Bei fremden freigegebenen Niederlassungen werden die Vorgaben an der Heimatniederlassung des Lagerkontos gespeichert. Beschränkte Verwalter können keine umfassenderen Freigaben erteilen; fremde Mandanten, eigene Rechte und Administratorkonten bleiben geschützt.
- **Speichern:** aktuelle Rechte, Zuordnungen und Revision erneut unter Tabellensperren geprüft. Konto, Startlager, Protokoll und Wiederholungsbeleg atomar in den bestehenden InnoDB-Tabellen. Passwortwerte gelangen nicht in Belege/Protokolle; Änderung widerruft bestehende Sitzungen. Löschung entfernt persönliche Freigaben/Startlager, erhält historische Fachdatensätze.
- **Korrigierter Prüfpunkt:** Eine Artikellöschung ist in der aktuellen PHP-Version kein aktiver Funktionsumfang: sowohl Listensteuerung (`stock/article_list.php:234`) als auch DELETE/Protokollcode (`stock/article_special.php:223`) sind auskommentiert. Dafür wird keine zusätzliche destruktive NG-Funktion eingeführt.
- **Weiter offen:** Kunden-/Transporteurportale sowie die übrigen dokumentierten Fachbereiche. Die ältere Angabe zur fehlenden Lagerkontenverwaltung ist hiermit überholt.

## 17. Oktober 2026 – Artikelpflege im Lagerportal

- **Referenz:** frischer SSH-Stand `2eb7f98`, `stock/article_list.php:20–32` (SHA-256 `7485c3273c14218505947f1015fd0fe2e2ff054bbdb5b1d0d78e68b9a8607349`), `stock/article_special.php:29–40` (`c460fde84e8a1f97371267e2125a537d5cceba916091e925a8facd559c55556d`) und `stock/atg_list.php:25–31`. Vorhandene PHP-Artikelmaske und Lageroberfläche aus den vorherigen Abgleichen bleiben die UI-Referenz.
- **Bedienung:** Bei `MASK_STK_ARTICLE_ACCESS=1` erscheint im Lagerarbeitsplatz „Artikelpflege“. Artikelsuche, Stammdaten, Neuanlage, Sichtbarkeit/Freigabe, Verpackungs-/Lagereinheiten, Gebindebestandteile, Historie und freigegebener Serienbestand nutzen die nativen Artikelabläufe. Auf die eigene Niederlassung begrenzt; die zentrale Warengruppen- und persönliche Spaltenverwaltung werden nicht freigeschaltet.
- **Berechtigung:** Kontotyp, Niederlassung, eindeutige Zuordnung und Artikelparameter werden pro Anfrage sowie erneut innerhalb der Schreibsperre geprüft. Entzug sperrt auch bereits vorbereitete und wiederholte Änderungen. Fremde Artikel/Gebindebestandteile und Niederlassungswechsel sind gesperrt. Passwörter werden weder zurückgegeben noch protokolliert.
- **Fortschreibung:** Der zuvor offene Artikelzugang des Lagerportals ist ergänzt. Native Lagermitarbeiterverwaltung ist der nächste Ausbau; die übrigen dokumentierten Fachbereiche bleiben offen.

## 17. Oktober 2026 – Eigenständiger Lagerarbeitsplatz

- **Referenz:** frisch per SSH gelesener Stand `2eb7f98`, `stock/stock.php:85–285`, `admin/user_list.php:25–125` und `include/dbglobal.inc.php:796–850`. Lageransicht zusätzlich lesend im Browser geprüft. Hash `admin/user_list.php`: `d843407cd8cc7dc7433f0ada2984dcaad4eb6be74772ab30cc131d0932ae05a0`.
- **Anmeldung:** PHP-Benutzertyp 4 mit bestehenden Zugangsdaten und gegebenenfalls 2FA. Eigener Lagerarbeitsplatz mit zugeordnetem Startlager, freigegebenen Haupt-/Unterlagern, Beständen, Seriennummern, Journal, Barcode-/Befehlslisten und Scannerbuchung. Leere oder ungültige Startzuordnung öffnet die Hauptlagerauswahl. Reiner Lesezugang bietet keine Buchung an.
- **Abgrenzung:** Keine Zentralenverwaltung, Lagerstammdatenänderung, gemeinsamen Journalspalten oder Bestands-/Journalexporte für Lagerkonten. Gespeicherte Zentralenrechte und eine zufällig passende Administratornummer erweitern den Zugang nicht. Niederlassungsheader werden abgewiesen; Kontowechsel, Passwort-/2FA-Änderung, deaktivierte Niederlassung und entzogene Lagerfreigaben greifen auch in bestehenden Sitzungen.
- **Aufträge/Buchungen:** Auftragssuche auch ohne Zentralen-Auftragsrecht, aber nur für das freigegebene Hauptlager und den PHP-Zeitraum. Manuell eingegebene Nummern durchlaufen dieselbe Prüfung; mehrdeutige Stationen werden abgewiesen. Rechte und Auftragsbezug werden unter der Schreibsperre erneut geprüft, Belege und Bestandsänderungen gemeinsam gespeichert. Identische Wiederholung ohne zweite Buchung.
- **Fortschreibung:** Der zuvor offene Lagerzugang ist ergänzt. Gesonderte Artikelpflege über `MASK_STK_ARTICLE_ACCESS` ist der nächste Ausbau; Kunden-/Kurierportale und übrige Fachbereiche bleiben offen.

## 17. Oktober 2026 – Barcodelisten, Scanner und Lagerauftragssuche

- **Referenz:** frischer SSH-Stand `2eb7f98`, `stock/stock_barcodelist.php` (`c3b0893b476ebf3d56707f28391b7a1f53ed0900752b743336233edae842a866`), `stock/stock_scancommandlist.php` (`a96aef1a358391e0a48eb7eb8fee2420777f11c2f8dff75422fcd09d4db21146`), `stock/ajaxReqScanExecution.php` (`0a9039b831f1e9f212ffe3e1d6f53c2df2d02ad1ab9572b7fd07150a936806fe`), `stock/stock.php:1715–2075`, `stock/stock_jobs.php` und `include/inc_stock.inc.php:1469,1566`. Die PHP-Barcode-/Befehlslisten wurden lesend geöffnet. Ihr referenzierter Barcode-Renderer fehlt im aktuellen Remote-Verzeichnis; die Lagerauftragssuche liefert HTTP 500. Diese Einschränkungen wurden durch den aktuellen Serverquellcode abgeglichen.
- **Listen:** aktueller Lagerort samt freigegebenen Unterlagern, zehn PHP-Befehle, zehn Zifferncodes, Löschen/Rückschritt. Native Code-39-Grafiken, beschriftete Druckvorschau, HTML-Download, Druckformat A4 quer. Leere/ungültige Barcodes werden ausdrücklich angezeigt und nicht still verändert. Keine externen Bilddienste; HTML-Ausgaben sind escaped.
- **Scanner:** Artikelbewegung → Scanner verwenden. Eingangs-/Ausgangsmodus, Reset, Zahlenpuffer, Rückschritt/Löschen, Menge, TAN, Bemerkung, Seriennummer und Auftrag. Erkennungsreihenfolge wie PHP; doppelte Treffer verlangen ausdrückliche Auswahl. Lagercode im aktuellen Hauptlager, Seriennummern nur im freigegebenen schreibbaren Bestand. Anders als die veraltbare PHP-Journalermittlung wird der tatsächliche aktuelle Serienbestand als Quelle verwendet. `MV-DISPOSAL` übernimmt die Positionen in die geprüfte atomare Buchung; Gebinde werden aufgelöst. Kein Scan speichert ungeprüft.
- **Lageraufträge:** `MV-OPENJOBS` oder „Lageraufträge suchen“ im Scanner. Offene Aufträge von vor drei Tagen bis heute, Abholadresse/Hausnummer in einem freigegebenen Ort des Hauptlagers, sieben sortierbare PHP-Spalten, 100 Zeilen je Seite. Auswahl übernimmt die Auftragsnummer. Arbeitsniederlassung und aktuelles Auftragsleserecht begrenzen die Daten; mehrdeutige Stationen sperren die Übernahme. Keine Änderung am Auftrag.
- **Offen im Lagerbereich:** eigenständiger Zugang für Lagerbenutzer (PHP-Benutzertyp 4). Scanner und Lagerauftragssuche sind jetzt im Zentralenzugang nutzbar; die übrigen dokumentierten Fachbereiche bleiben separat offen.

## 17. Oktober 2026 – Lageradresse und Kundenzuordnung

- **Referenz:** erneut direkt gelesener SSH-Stand `2eb7f98`, `stock/stock.php:611–700`, `include/global.inc.php:1214` und `admin/cs_csc_list.php:14`; PHP-Lagerdatenmaske lesend abgeglichen.
- **Adresse:** Adressvorschläge, Straße/Hausnummer/PLZ/Ort/Land, Prüfung über den Adressdienst und zusätzliche Straßenverzeichnisprüfung. Nur der zusätzliche PLZ-/Ortsabgleich lässt sich ausdrücklich ausnehmen. Bestehende passende Adressen werden wiederverwendet; gemeinsam verwendete Datensätze bleiben unverändert.
- **Kundenzuordnung:** Kostenstellensuche über freigegebene Niederlassungen, Firmen-/Kunden-/Kostenstellen- und Matchcodesuche, ausgeblendete Einträge optional, 50 Treffer je Seite, Zuordnung und Aufhebung. Zusätzlich zum Lagerrecht wird Kundenpflege- oder Auftragserfassungsrecht wie im PHP-Auswahldialog erneut geprüft.
- **Speichern:** Vorschau, Konflikterkennung, aktuelle Rechte, InnoDB, gemeinsame Tabellensperre, Audit 91/92 und identischer Wiederholungsbeleg. Netzwerkprüfung vor der Schreibsperre; keine Überschreibung anderer Lageradressen.
- **Noch offen im Lagerbereich:** Scanner/Befehle/Barcodelisten, Lageraufträge und Lagerbenutzerportal. Die nachfolgenden älteren offenen Listen werden durch diesen Abschnitt fortgeschrieben.

## 17. Oktober 2026 – Lagerjournal und eigenständige Lagerbuchungen

- **Referenz:** erneut direkt per SSH geprüfter Stand `2eb7f98`: `stock/stock.php` (`5b4e3ad6eab8e29f5837f76fb4ab6e94de09b48ab17f13e2ae6561b5758581e6`), `stock/stock_move.php` (`6894e8ad10cba44f151490b8b2794d128e75a6ef9dbb320945c7bd8f1c464b45`) und `include/inc_stock.inc.php` (`c4528b331909c57843f7eee01acaa25987854b0002bcbeaa653f6dd2abf4ce5e`). Aktuelle PHP-Oberfläche mit Buchungs- und Journalfeldern lesend abgeglichen.
- **Journal:** Datum, aktueller Ort/Unterbaum/Hauptlager/alle Freigaben, Quelle/Ziel mit Unterlagern und UND/ODER, Artikel, Warengruppe, Transaktionsnummernbereich, Bemerkung, Seriennummer, Zusatzdaten, Auftrag, Zusatzdatum sowie gemeinsame Suche. Die PHP-Ausnahmen vom Zeitraum werden sichtbar angezeigt. Filter zurücksetzen, Sortierungen, 100 Zeilen je Seite, CSV bis 10000 Zeilen. Fehlende Altartikel bleiben im Journal sichtbar; fremde Lager werden maskiert. Doppelte Gruppenmitgliedschaften vervielfachen keine Journalzeilen.
- **Journalspalten:** 17 PHP-Spaltentypen, gemeinsame Hauptlagervorgaben für Anzeige und Standardsortierung über die bestehenden `MASK_STK_JOURNAL*`-Parameter. Beschriftungen aus dem Bestand bleiben erhalten. Schreibrecht am Hauptlager, Revision, Audit, InnoDB und Vorgangsbeleg schützen die gemeinsame Änderung.
- **Buchungen:** Einlagerung, Auslagerung und Umbuchung mit freigegebener Lagerauswahl, sechs Artikelauswahlmodi, Artikel-/Barcode-Suche, Menge, Transaktionsnummer, Bemerkung, Seriennummer, optionaler Auftragsbindung und Zusatzdatum. Alle 25 Zusatzfelder können übernommen oder bearbeitet werden. Dieselbe-Lagerort-Korrekturen folgen `STOCK_ARTICLEMOVE_STKFROM_EQ_STKTO`; alte/neue Seriennummer sind getrennt. Seriennummern dürfen bei Umlagerung aus dem eigenen Quellbestand stammen, aber keine zweite Bestandskopie erzeugen.
- **Gebinde:** rekursive Auflösung einschließlich Mengenfaktoren, einzelne Serienpositionen, frei editierbare Quell-/Ziellager je Bestandteil, bis 100 Positionen. Kreise, doppelte Kanten, Überläufe, unbekannte/fremde Artikel, zu kleiner Quellbestand und fehlende Kapazität blockieren. Der gesamte Buchungssatz wird zunächst simuliert und anschließend atomar gespeichert.
- **Journalaktionen:** Rückbuchung, Weiterdisponieren und Storno gesammelter Gebindebuchungen öffnen bearbeitbare Positionen zur Prüfung. Alte PHP-Gruppen verwenden Gebinde-ID/Zeitstempel; neue NG-Gruppen zusätzlich den eindeutigen Vorgangsbezug. Rückbuchungen erzeugen neue Journalzeilen. Seriennummernkorrekturen und Auslagerungen sichern vollständige Zusatzdaten für die Wiederherstellung. Die Einträge bleiben mit den vorhandenen auftragsbezogenen Zusatzdaten kompatibel.
- **Speicherschutz:** aktuelle Lagerrechte/Mandant/Unterlagerkette, tatsächliche Bestände und Artikelvorgaben werden erneut geprüft. Revision, InnoDB, gemeinsame Tabellensperre, Audit und identischer Wiederholungsbeleg verhindern Teilbuchungen und Doppelverarbeitung nach verlorener Antwort. Die Stellplatzprüfung verwendet den tatsächlichen Mehrbedarf der Buchung; vorhandene Teilbelegung wird berücksichtigt. Das korrigiert die zu strenge PHP-Prüfung, die nur völlig freie Plätze in neue Stückzahlen umrechnet. Fremde doppelte Seriennummern werden auch bei gelockerter PHP-Serienprüfung nicht erzeugt.
- **Noch offen im Lagerbereich:** Kunden-/Kostenstellen- und Adresspflege am Lager, Scanner/Befehle/Barcodelisten, Lageraufträge und Lagerbenutzerportal. Allgemeine Portale und die übrigen dokumentierten Fachbereiche bleiben separat offen.

## 17. Oktober 2026 – Lagerorte, Bestände und Seriennummern

- **Referenz:** aktueller SSH-Stand `2eb7f98`, `stock/stock.php` (SHA256 `5b4e3ad6eab8e29f5837f76fb4ab6e94de09b48ab17f13e2ae6561b5758581e6`), `stock/article_item.php` (`1597e4736f43df02f064112041cace522e40e327044474f424723844e2224171`), `include/inc_stock.inc.php` (`c4528b331909c57843f7eee01acaa25987854b0002bcbeaa653f6dd2abf4ce5e`). Die aktuelle PHP-Lagermaske mit Hauptlager, Unterlagern, Kapazitätsdaten, Bestandsansichten und Journal wurde lesend geprüft.
- **Lagerorte:** Verwaltung → Lagerorte. Haupt-/Unterlagerwahl, Pfadnavigation, neue Lagerorte, Umbenennen, Sichtbarkeit der Unterlager, Barcode, Kapazität und Stellplatzplanung. Gleiche Namen bleiben wie PHP zulässig. Neue Hauptlager erhalten die PHP-Zusatzfeldvorgaben und die Erstellerfreigabe; Unterlager übernehmen den Kundenbezug und die Niederlassung ihres Elternlagers. Die Lagerkapazitäten berücksichtigen Geschwister, direkte Unterlager und belegte Plätze im gesamten Unterbaum. Stückzahlen bleiben davon getrennt.
- **Entfernen:** nur Unterlager ohne Kinder, Artikelzuordnung (auch Nullbestand), Seriennummern oder Objektverknüpfung. Keine versteckte Bestandsbereinigung. Die bestehende PHP-Historie bleibt bestehen. Vorschau und erneute Prüfung vor jedem Schreibvorgang; InnoDB, gemeinsame Tabellensperre, Auditcodes 87–91 und wiederholbarer Vorgangsbeleg verhindern Teiländerungen und Doppelverarbeitung.
- **Zugriff:** aktuelles Recht 14, Mandant, Hauptlagerfreigaben und Unterlagerbeschränkungen. Hauptlager können innerhalb des Mandanten niederlassungsübergreifend freigegeben sein. Beide Leseschalter und schreibgeschützte Lager in der Elternkette verhindern Änderungen. Der zusätzliche PHP-Lesefilter für freigegebene Unterlager wirkt in Bestandslisten und Belegungssummen. Ungültige Pfade/Kreise werden erkannt. Bestandsabfragen benutzen validierte Baumkennungen.
- **Bestandslisten:** aktueller Lagerort, gesamter Unterbaum, summierte Artikel, Inventurliste und Seriennummern. Suche in Artikelnummer, Name, Zusatz, Beschreibung, Barcode sowie Seriennummer und 15 Zusatzfeldern; Warengruppenfilter, Spaltensortierung, 100 Zeilen pro Seite, CSV bis 10000 Zeilen. Bestände werden bei mehrfachen Warengruppenzuordnungen nicht vervielfacht. Warengruppen werden einmal zusammengefasst; dadurch benötigt die aktuelle Datenbank keinen neuen Index. Seriennummern sind auch direkt über die entsprechende Spalte der Artikelliste erreichbar und zeigen nur freigegebene Lager.
- **Fortschreibung:** Journal und eigenständige Lagerbuchungen sind im nachfolgenden Ausbau ergänzt (Abschnitt oben). Kunden-/Kostenstellen- und Adresspflege, Scanner/Befehle/Barcodelisten, Lageraufträge und Lagerbenutzerportal bleiben offen.

## 17. Oktober 2026 – Eigenständige Artikelpflege und Warengruppen

- **Referenz:** frisch per SSH gelesener Arbeitsbaum `2eb7f98`, `stock/article_list.php`, `stock/article_special.php`, `stock/atg_list.php`, `include/inc_article.inc.php`; aktuelle PHP-Neuanlage und Warengruppenmaske im Browser geprüft. Prüfsummen: Artikelliste `7485c3273c14218505947f1015fd0fe2e2ff054bbdb5b1d0d78e68b9a8607349`, Artikelstamm `c460fde84e8a1f97371267e2125a537d5cceba916091e925a8facd559c55556d`, Warengruppen `f1bd76fbbbd337714e7a84e9c280b103fa40f76462033438f76f3fcc0d5c86bc`. Die direkten PHP-Seiten sind nutzbar; ihre Einträge im aktuellen Hauptmenü sind auskommentiert.
- **Bedienung:** Verwaltung → Artikel. Niederlassungsauswahl mit Rechteprüfung, kombinierte Präfix-/Teilwortfilter für ExtID, Name, Zusatz, Beschreibung und Barcode; ausgeblendete Artikel, paginierte Liste und Historie. Anlage und Bearbeitung einschließlich Seriennummern, Montierbarkeit, Verpackungsstückzahl/-code, Lagereinheiten, Freigabe und Sichtbarkeit. Nummernvorschlag aus den aktuellen `AT_EID_*`-Vorgaben. Artikelgewicht und weitere nicht angebotene Bestandsfelder bleiben erhalten.
- **Warengruppen:** Schlüssel/Name, Neuanlage, Umbenennung, lokale oder gemeinsame Geltung; bestehende Schlüssel unveränderlich. Zuordnung am Artikel mit Schutz vor mehrdeutigen Daten. Gemeinsame Zuordnungen werden nicht durch lokales Leeren entfernt; gemeinsame Gruppen mit fremden/gemeinsamen Zuordnungen lassen sich nicht lokal einschränken.
- **Gebinde:** Bestandteile nach ExtID hinzufügen, bestehende Mengen wie PHP addieren, einfache Bestandteile entfernen. Keine Selbstzuordnung, Kreisläufe, Seriennummernartikel, doppelte Kanten oder Mengenüberläufe. Bestandteil, der selbst Gebinde ist, bleibt wie PHP gegen Entfernung geschützt. Positive Lagerbestände verhindern die Umwandlung in ein Gebinde und den Wechsel auf Seriennummern. NG prüft positive Einzelbestände auch bei kompensierenden negativen Mengen; vorhandene Seriennummern verhindern das Abschalten. Bei abgewiesener Änderung wird nichts teilweise gespeichert.
- **Speichern:** Vorschau, vollständige Bestandsrevision, erneute Live-Rechteprüfung, globale Nummern-/Barcodeprüfung, InnoDB-Transaktion unter kurzen gemeinsamen Tabellensperren, Audit und identische Wiederholung nach Antwortverlust. Artikelbezeichnung bei Anlage global eindeutig wie PHP. Kein Harddelete (auch in PHP deaktiviert). Historie umfasst aktuelles PHP-Protokoll und noch nicht veröffentlichte NG-Einträge; lange Texte im NG-Protokoll gekürzt mit Prüfsumme. Neue Artikel werden als Vorgang 61, Stammdaten-/Gebindeänderungen als 62 und Änderungen der Freigabe/Sichtbarkeit getrennt als PHP-Vorgänge 63/64 protokolliert.
- **Artikelliste:** alle elf PHP-Spaltentypen mit persönlicher Auswahl/Reihenfolge (`MASK_AT_LIST_COLS`), neun erlaubte Sortierungen und Warengruppenanzeige. Spaltenpflege direkt aus der Liste und über Mitarbeiter → Listenparameter. Heimniederlassungs-/Standardrückfall, Konfliktprüfung, Audit und wiederholbare Speicherung.
- **Fortschreibung:** Seriennummern, Lagerverwaltung, Journal und Buchungsabläufe sind oben ergänzt. Scannerfunktionen und Lagerbenutzerportal bleiben offen. Allgemeine Artikel-Gruppenmitgliedschaften sind über die vorhandene Gruppenverwaltung pflegbar. Keine vollständige Artikel-/Lagerparität behauptet.

## 17. Oktober 2026 – Tagesübergreifende Auftragssuche in der FDS

- **Referenz:** frisch per SSH gelesene `admin/vehicle_disposition.php:169–194,552` und `include/inc_job.inc.php:20–53,466–492`, HEAD `2eb7f98`; sichtbares `eco_search`-Feld der aktiven PHP-Disposition lesend geprüft.
- **Bedienung:** Fahrzeugdisposition → Auftrag in der Disposition suchen. Exakte Auftragsnummer, Stations-Kommissionsnummer oder GDC-Suchkennung `jb_search`/`info_0`, über alle Tage der ausgewählten Niederlassung. Classic behandelt numerische Eingaben ausschließlich als interne ID. Mit `GLOBAL_USE_RELATED_CUSTOMER=1`: `/1` Grundauftrag, `/2` Folgeaufträge, ohne Suffix Grund- und Folgeaufträge. Mehrere passende Folgeaufträge werden ausdrücklich aufgelistet, statt einen unbestimmten ersten Treffer zu verwenden.
- **Navigation:** 50 Aufträge je Seite; bis 200 Fahrzeugtage je Treffer mit ausdrücklicher Begrenzungsmeldung. Tag auswählen setzt die Dispositionsfilter zurück, öffnet das zugehörige Fahrzeug und hebt den Treffer hervor. Nicht reservierte Aufträge lassen sich direkt öffnen. Fremde Arbeitsniederlassung nutzt den bereits geprüften Wechseldialog.
- **Schutz:** ausschließlich lesend, Rechte 27/4, aktuelle FDS-Niederlassungsfreigabe, parametrisierte exakte Suche ohne SQL-/Wildcard-Interpretation. Fremde Aufträge werden ausgeschlossen; fehlende/fremde Fahrzeuge verraten keine Fahrzeugkennung und lassen sich nicht öffnen. Ungültige Tage sowie fehlende/mehrdeutige Tagesdatensätze werden angezeigt und gesperrt. Kein automatischer Auftrags- oder Reservierungswechsel.
- Weitere offene Bereiche bleiben bestehen; die Suche ersetzt keine Archivdatenbank und keinen eingeschränkten FDS-/Portalzugang.

## 17. Oktober 2026 – Auftrags- und Fahrzeugöffnung aus fremder FDS-Niederlassung

- **Referenz:** frisch per SSH gelesen, HEAD `2eb7f98`, `admin/vehicle_disposition.php:1685–1740,1845–1860`; aktive PHP-Disposition lesend geprüft. Die dortigen Fahrzeugstammblatt-/Auftragsaufrufe sind nun auch aus einer fremden NG-Dispositionsniederlassung erreichbar.
- **Bedienung:** Stammblatt in der Fahrzeugzeile oder Auftrag im Fahrzeugtag öffnen. Bei abweichender Arbeitsniederlassung nennt ein Dialog den Zielort; nach Bestätigung wechselt dieser Tab und öffnet unmittelbar das Fahrzeug beziehungsweise den Auftragseditor. Abbrechen erhält die bisherige Dispositionsauswahl. Ungespeicherte Tagesnotizen und laufende/ungeklärte Vorgänge verhindern den Übergang. Bei bereits passender Arbeitsniederlassung bleiben die bisherigen direkten Dialoge erhalten.
- **Rechte:** FDS-Freigaben werden nicht in allgemeine Bearbeitungsrechte umgewandelt. Der bestehende Arbeitsplatzwechsel prüft erneut Mandant, Niederlassung, Mitarbeiter-Vektor und Rechtematrix. Die Ziel-APIs prüfen zusätzlich Auftrags-/Stammdatenrecht und Datensatzzugehörigkeit; entzogene Freigaben blockieren. Ein nur lesbarer Auftrag bleibt im Editor schreibgeschützt.
- **Weiter offen:** Classic-Tourbildung, beschränkter FDS-Zugang über Recht 28/SQL-Vorgaben, Portale und die weiteren Bereiche der Übersicht. Keine vollständige PHP-Parität behauptet.

## 17. Oktober 2026 – Spätere Mehrtagesreservierungen freigeben

- **Referenz:** frischer SSH-Stand `2eb7f98`, `admin/vehicle_disposition.php:1800–1840,2197–2210`, `include/ajaxReqDisposition.php:831–843`, `include/inc_job.inc.php:576–605`. Erneut geprüfte SHA-256-Werte: Dispositionsseite `f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`, Ajax `80d00e71eabbeac4154d5b5724fd0d81410874abbef12bf0a69aa0aca04fbea0`, Auftragshilfen `0b660ceef70176f64314cf74809fa681eac06553c534473a4690d0edf941e0c6`, Gewichtsprüfwerkzeug `59418daa454ac3546cef5f02ce173d7bbfc5c2a43aafa9251ca13954e7c51d3e`.
- **Bedienung:** Tag öffnen → Spätere Reservierungen freigeben, für angenommene Aufträge nach ihrem ursprünglichen Auftragstag. Vorschau trennt bleibende und freizugebende Tage und zeigt Dauer, Rest-Nutzlast und erforderliche Bestandskorrekturen. Die Freigabe umfasst den ausgewählten Tag und alle folgenden gespeicherten Reservierungstage. Frühere Tage bleiben unverändert.
- **Fachwirkung:** Annahmestatus, Kurier, Annahmezeit, ursprünglicher Auftragstermin, Auftragsdauer und Preise bleiben erhalten. Auch bereits früher begonnene Aufträge und die letzte verbleibende spätere Reservierung eines zeitlich mehrtägigen Auftrags sind unterstützt. Kein Versand. Ursprünglicher Auftragstag und vergangene Freigabetage sind ausgeschlossen.
- **Kapazitäten:** Anders als das reine Leeren von `jb_id` im PHP-Ajax werden freie Kundenzeitfenster und bei Artikelgewicht Rest-Nutzlast der betroffenen Tage konsistent neu berechnet. Gewichtsregel wie im aktuellen PHP-Gewichtsprüfwerkzeug und der bereits implementierten Mehrtagesplanung. Tagessperren, Unternehmerfreigaben, Stellplätze und Tagesnotizen bleiben erhalten; Verarbeitungssperren verhindern die Änderung.
- **Schutz:** Rechte, ausgewählte Niederlassung, Kunde/Kostenstelle, Abrechnung/Export/Storno, PHP-Bearbeitungssperre, vollständige Raster, fremde/fehlende Aufträge, uneindeutige Reservierungen und parallele Änderungen werden geprüft. Reservierungen, Kapazitäten, Zeitfenster, Version, Audit und Wiederholungsbeleg atomar. Keine teilweise Freigabe bei einem späten Fehler.
- **Classic-Quellenlücke:** Der aktuelle PHP-Baum ruft `copy_jobs_cartage` auf, enthält aber keine Definition dieser Funktion (auch rekursive Suche aller PHP-Dateien ohne Treffer). Zusammengefasste Classic-Tourbildung daher weiterhin nicht als abgeglichen/implementiert bestätigt. Weitere dokumentierte Bereiche bleiben offen.

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

- **Referenz:** erneut frisch per SSH gelesen, `2eb7f98`, `include/ajaxReqDisposition.php:21–24,400–479`, `admin/vehicle_disposition.php:1853–1867`. Die aktive PHP-Disposition wurde gelesen; kein lokaler PHP-Stand verwendet.
- **Bedienung:** Tag öffnen → Einzelübergabe beziehungsweise Auftrag zurückholen. Vorschau zeigt Status, bisherigen/zugewiesenen/kommenden Kurier, Fahrzeugkennung, Annahmezeit und alle Reservierungstage. Speicherung erst nach ausdrücklicher Bestätigung.
- **Gerätekurierbetrieb:** Bei eindeutig globalem `GLOBAL_USE_RELATED_CUSTOMER=1` wird ein eindeutiger, nicht gesperrter Gerätekurier zur Fahrzeugkennung derselben Niederlassung verwendet. Status 9 → 1, beide Kurierfelder und Fahrzeugkennung gesetzt, Annahmezeit auf Speicherzeitpunkt. Eine Einzelübergabe lässt andere Aufträge desselben Tages unverändert.
- **Classic:** Expliziter Wert 0 oder fehlender Parameter entspricht dem PHP-Standard. Der Einzelablauf setzt den Auftrag auf angenommen, aber mit Kurier 0 und leerer Kennung. Diese Wirkung wird ausdrücklich angezeigt; keine zusammengefasste Tour entsteht. Mehrdeutige/ungültige Vorgaben blockieren. Der Classic-Sammelpfad `copy_jobs_cartage` bleibt separat offen.
- **Rückholung:** Angenommener, zum Fahrzeug passender Auftrag → Status 9; beide Kurierfelder, Kennung und Annahmezeit geleert. Auch ohne Gerätezuordnung angenommene Classic-Aufträge unterstützt. Reservierungen, Kapazitäten und Preise bleiben erhalten. Der PHP-Einzelablauf erzeugt keinen separaten Geräte-Rückrufbefehl; NG meldet deshalb keine Empfangsbestätigung.
- **Schutz:** Rechte 27/4/7, Mandanten-/Niederlassungsgrenzen, frische Fremdniederlassungsfreigabe, Rechnungs-/Export-/Storno-/Bearbeitungsschutz, vollständige Reservierungszugehörigkeit, Verarbeitungssperren und Versand-Tagessperren. Vorschaukonflikte blockieren; Auftragsänderung, Audit und Wiederholungsbeleg atomar in InnoDB. Kein SMTP-/SMS-Versand.
- **Weiter offen:** Freigabe angenommener Mehrtagesreservierungen, Classic-Tourbildung und die weiteren dokumentierten Bereiche.

## 17. Oktober 2026 – FDS-Auftragsbemerkungen und Einzelfreigabe

- **Referenz:** erneut per SSH gelesen, `2eb7f98`, `admin/vehicle_disposition.php:1867–1955,2223–2245`, `include/ajaxReqDisposition.php:732–760`, `include/ajaxReqLib.php:36–43,257–277`. Aktive PHP-Disposition lesend geprüft; ihre aktuelle Kundenauswahl hat keine Fahrzeugzeilen. Quellen ausschließlich vom Remote-Arbeitsbaum.
- **Bedienung:** Tag öffnen → Auftragsaktionen sowie Ungeplante Aufträge → Auftragsbemerkungen. Öffentliche Bemerkung der Zustellstation (`tr_sort=2`) und separate interne Bemerkung (`jb/internal_remark`) können unabhängig geändert oder geleert werden. Ohne Zustellstation bleibt die interne Notiz verfügbar. Abgeschlossene Aufträge sind nur lesbar. Texte werden in NG als Text dargestellt; keine HTML-Ausführung.
- **Einzelfreigabe:** Für reservierte Status-9-Aufträge Übergang auf Status 0, Rücknahme auf Status 9. Wie bei den PHP-Einzelaktionen 210/110 bleiben Kurierzuordnung, Fahrzeugkennung, Reservierungen, Kapazitäten und Tagesfreigabe unverändert. Die Vorschau nennt die Wirkung über sämtliche Reservierungstage. Angenommene, angebotene, anderweitig zugeordnete und spezielle Vermittlungsaufträge sind ausgeschlossen; beim Einschalten muss der Transporteur dafür freigegeben sein.
- **Schutz:** Rechte 27/4 und für Änderungen 7, Kostenstellen-/Kunden-/Niederlassungszugehörigkeit, Rechnungs-/Export-/Stornoschutz, PHP-Bearbeitungssperre, Verarbeitungssperren, Revisionen und frische Fremdniederlassungsfreigabe. Auftrag, Tourbemerkung, interne Notiz, Audit und Wiederholungsbeleg atomar in InnoDB; fremde Aufträge, doppelte Zustellstationen/Notizen und wechselnde Reservierungen werden abgewiesen. Kein Nachrichtenversand.
- **Weiter offen:** Einzelübergabe und Rückholung vom Endgerät, Freigabe angenommener Mehrtagesreservierungen, Classic-Tourbildung und die übrigen dokumentierten Menülücken.

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

- **Referenz:** frischer SSH-Stand `2eb7f98`, `admin/vehicle_disposition.php:2167–2245` (Aktionen 105/106/109), `include/ajaxReqDisposition.php:481–519,811–827`; Quellenhashes wie im Zeitleistenabschnitt. Aktive PHP-Disposition lesend geprüft.
- **Bedienung:** Ungeplante Aufträge → Planungsdaten: Datum, Zeiteinheiten und SMS-Startzeit mit Änderungsvergleich. Datumswechsel setzt den Plantermin wie PHP auf 06:00. Ein leerer SMS-Wert löscht die Vorgabe. Die tatsächliche Datenbankspalte ist ein vorzeichenbehaftetes TINYINT: höchstens 127 Zeiteinheiten, zusätzlich die vorhandene 60-Tage-Grenze.
- **Speicherung:** Nur noch unreservierte, nicht zugewiesene/angebotene Aufträge. Rechte, Niederlassung, Bearbeitungs-/Abrechnungsschutz und frischer Bestand werden unter der bestehenden Planungssperre geprüft. Auftrag, Version, SMS-Vorgabe, mitverschobene Vermittlungsstaufrist, Audit und Wiederholungsbeleg werden gemeinsam gespeichert. Vorhandene MAIL_SENT-Kennzeichnung bleibt erhalten. Parallele Reservierungen oder abweichende Vorschauen verhindern die Änderung.
- **Abgrenzung:** Keine SMS und keine Reservierung werden ausgelöst. Reservierte Aufträge werden weiterhin über die Tages-/Mehrtagplanung verschoben. Die weiteren Spezialaktionen, Classic-Tourbildung und übrigen Menülücken bleiben offen.

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

- **Referenz:** frischer Remote-Stand `2eb7f98`, `admin/vehicle_disposition.php:625–670,1390–1485` sowie `include/inc_vehicle.inc.php:getVehicleJobList` (Modus 3) und `setAssocCrvhJb`. Quellenhashes unverändert zum Zeitleistenabschnitt. Aktive PHP-Disposition erneut gelesen; kein lokaler PHP-Altstand und keine Bestandsspeicherung verwendet.
- **Bedienung:** Verwaltung → Fahrzeugdisposition → Ungeplante Aufträge. Offene Aufträge des gewählten Tages ohne Angebot, bestehende Zuweisung oder Reservierung; optional mit aktuellem Kundenfilter. Suche nach Auftragsnummer/Kundennummer/Firma, 50 Treffer pro Seite. Anschließend Zielfahrzeug, Beginn und erster Reservierungstag wählen und alle Tage prüfen.
- **Reservierung:** Der gemeinsame Planungsdienst unterstützt nun einen ausdrücklich unreservierten Ausgangsstand. Eine bereits parallel entstandene Reservierung wird abgewiesen. Tagesraster, Sperren, Kundenbeziehung/Einsatzzeiten, Nutzlast, Liefer-/Montageabhängigkeiten, Auftragsschutz und aktuelle Rechte werden vor der atomaren Speicherung erneut geprüft. Ein- und Mehrtagesaufträge nutzen dieselbe Aufteilung wie die Umplanung. Andere Aufträge bleiben erhalten; Restnutzlast und Verfügbarkeitsblöcke werden für alle neuen Tage gemeinsam aktualisiert.
- **Abgrenzung:** Kein automatischer Kurier-/Geräteversand; dafür bestehen die getrennten bestätigten Übergabeabläufe. Vergangene Erstreservierungen und die Übernahme bestehender Unternehmerzuweisungen sind ausgeschlossen. PHP erlaubt in seinem älteren Pfad eine Überlast nach bloßem Hinweis; NG behält die bereits dokumentierte strikte Nutzlastprüfung. Erste Reservierung erfolgt über einen zugänglichen Auswahldialog, bestehende Reservierungen weiterhin auch grafisch.
- **Fortschreibung:** Erstreservierung ist ergänzt. Classic-Tourbildung, Stammdaten-/Auftragsbearbeitung aus fremder Dispositionsniederlassung, weitere Spezialaktionen und übrige Menülücken bleiben offen.

## 17. Oktober 2026 – Grafische Fahrzeugzeitleisten

- **Referenz:** frischer SSH-Arbeitsbaum `2eb7f98`, `admin/vehicle_disposition.php` insbesondere der Drag-and-drop-Ablauf; aktive PHP-Seite lesend geöffnet. SHA-256 der Dispositionsseite `f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`, `include/ajaxReqDisposition.php` `80d00e71eabbeac4154d5b5724fd0d81410874abbef12bf0a69aa0aca04fbea0`. Keine Änderungen in PHP.
- **Bedienung:** Verwaltung → Fahrzeugdisposition → Zeitleiste anzeigen. Die sichtbaren bis zu 50 Fahrzeuge erhalten eine gemeinsame 24-Stunden-Achse. Bestehende offene Reservierungen lassen sich an der gewünschten Uhrzeit desselben oder eines anderen Fahrzeugs ablegen. Der Griffpunkt innerhalb des Balkens bleibt bei der Zeitberechnung berücksichtigt. Klick oder Enter öffnet dieselbe Planung mit den gespeicherten Werten.
- **Speicherung:** Das Ablegen öffnet die bestehende atomare Mehrtagesplanung mit Ziel und Zeit als Vorschlag. Alle Reservierungstage, Gewichte, Liefer-/Montageabhängigkeiten und Hinweise müssen geprüft und bestätigt werden. Die Bewegung allein schreibt nichts. Gesperrte/fehlende Tage, nicht zugängliche Aufträge sowie angenommene/angebotene Aufträge werden nicht als verschiebbar angeboten. Der Server prüft den aktuellen Bestand erneut. Verlorene Speicherantworten verwenden dieselbe Vorgangskennung.
- **Anzeige und Rechte:** eigener lesender Sammelendpunkt, vollständige Prüfung aller Fahrzeugzugehörigkeiten; Rechte 27, für Auftragskennungen 4 und für Planung 7. Fremde Dispositionsniederlassungen benötigen die vorhandene zusätzliche Freigabe. Ohne Auftragsleserecht werden sämtliche IDs verborgen. Ungültige oder unvollständige Raster werden sichtbar gesperrt. Farben unterscheiden freie Rasterfelder, zugängliche Reservierungen und unbekannte Belegung; freie Rasterfelder allein bestätigen noch kein Kundenzeitfenster oder Gewicht.
- **Fortschreibung:** Grafische Umplanung vorhandener Reservierungen ergänzt. Erstzuordnung bisher unreservierter Aufträge, Classic-Tourbildung, fremde Stammdaten-/Auftragsbearbeitung und weitere Spezialaktionen bleiben offen.


## 17. Oktober 2026 – Verknüpfte Liefer- und Montageaufträge in der Disposition

Erneut frisch per SSH gelesen: `admin/vehicle_disposition.php:1330–1500`, `include/ajaxReqDisposition.php:160–210` und `include/inc_vehicle.inc.php:453`, Stand `2eb7f98` und dieselben Quellenhashes wie im folgenden Mehrtagesabschnitt. Die aktuelle PHP-Disposition wurde lesend geöffnet. `jb_is_installation` ist ausschließlich ein berechneter PHP-Anzeigewert; der Datenvertrag ist Dienstleistungsbit 2 in `job.jb_service` und `couriervehicle.crvh_service`.

- **Ein- und mehrtägige Umplanung:** Verknüpfte Lieferung muss strikt vor dem Montage-/Folgeauftrag beginnen, auch Gleichzeitigkeit wird abgewiesen. Ein bestätigter Sammelplan vergleicht alle neuen Startzeiten miteinander. Unveränderte verknüpfte Aufträge werden anhand ihres ersten reservierten Zeitabschnitts geprüft.
- **Niederlassungsvorgabe:** `MASK_DISPOSITION_CHECK_DELIVERY_BEFORE_SERVICE_DISABLED=1` erlaubt die abweichende Reihenfolge mit ausdrücklichem Vorschauhinweis; sonst wird der gesamte Vorgang abgewiesen. Eigene Vorgabe vor globalem Fallback, doppelte oder ungültige Vorgaben blockieren. Verknüpfungen ohne Reservierung und getrennte Fahrzeuge erscheinen als Hinweise. Fehlende oder fremde Eigentümer werden nicht still übergangen.
- **Montagefahrzeug:** Wie im PHP-Dropdialog wird eine fehlende Montagekennzeichnung am Zielfahrzeug als bestätigungspflichtiger Hinweis angezeigt. Der Bestätigungsdialog nennt nun ausdrücklich auch diese Hinweise.
- **Konflikte:** Änderungen an Verknüpfungen, ersten Reservierungszeiten, Montagekennzeichnung oder maßgeblichen Vorgaben nach der Vorschau verhindern die Übernahme. Die Prüfung erfolgt vor jeder Speicherung unter derselben vorhandenen Tabellensperre wie die Planung. Auch Aufträge, die zugleich Eltern- und Kindauftrag sind, werden in beide Richtungen geprüft; die frühe Rückkehr des PHP-Helfers wird dabei nicht übernommen.
- **Abgrenzung:** Das ergänzt die fachlichen Vorbedingungen der nativen Umplanung. Grafische Drag-and-drop-Bedienung, erstmalige Reservierung unzugeordneter Aufträge und übrige offene Dispositionsfunktionen bleiben separat aufgeführt.

## 17. Oktober 2026 – Mehrtagesplanung mit Artikelgewicht

Frischer Remote-Stand `2eb7f98`: `include/inc_vehicle.inc.php` SHA-256 `e34830c44c742c28f658e693256e0658920d0f383b9a030a188c76af7ac7b086`, `include/inc_job.inc.php` `0b660ceef70176f64314cf74809fa681eac06553c534473a4690d0edf941e0c6`, `admin/vehicle_disposition.php` `f0f6be7eea331bef81ca7044eccd35049e3c589277d86a80d83fed503b3e444e`, `include/ajaxReqDisposition.php` `80d00e71eabbeac4154d5b5724fd0d81410874abbef12bf0a69aa0aca04fbea0`, `tools/checkAndUpdateFDSVehicleWeights.php` `59418daa454ac3546cef5f02ce173d7bbfc5c2a43aafa9251ca13954e7c51d3e`. Aktuelle angemeldete PHP-Disposition gelesen; deren aktuelle Kundenauswahl enthält weiterhin keine Fahrzeugzeilen. Im echten Bestand fehlen zukünftige FDS-Tagesbestände. Keine PHP-Speicherung und kein Aufruf der Bereinigungsaktion.

- **Tag öffnen → Tage / Fahrzeug planen:** Bestehende Reservierungen können nun auch mit Artikelgewicht auf andere Tage oder Fahrzeuge übertragen werden. Bis 60 Tage, Tagesmaximum und Beginn an Folgetagen nach Kundenvorgaben. Gemeinsame alte/neue Tage werden einmal berechnet; auch der Wechsel zwischen ein- und mehrtägiger Dauer ist möglich.
- **Gewichtsregel:** Der aktuelle PHP-Mehrtagspfad belastet wiederholt den ersten Tag und gibt beim Entfernen kein Gewicht frei. NG verwendet ausdrücklich die konsistente Regel des aktuellen PHP-Gewichtsprüfwerkzeugs: `crvh_payload` minus Summe `trat_weight` aller unterschiedlichen Aufträge des Fahrzeugtags. Jedes Positionsgewicht zählt je Tag einmal, ohne zusätzliche Multiplikation mit der Stückzahl. Dies ist eine bewusste Korrektur des PHP-Mehrtagspfads.
- **Vorschau:** Für jeden betroffenen Fahrzeugtag stehen gespeicherte Rest-Nutzlast, aus dem aktuellen Bestand berechnete Rest-Nutzlast und Wert nach der Planung nebeneinander. Bestehende Abweichungen werden markiert und mit der bestätigten Planung berichtigt. Nur die betroffenen Tage werden neu berechnet; andere Auftragszeiten, Stellplätze, Tagesnotizen und Freigaben bleiben erhalten. Bei einem gewichtslosen Auftrag bleiben die Kapazitätswerte unverändert.
- **Speicherschutz:** Negative Einzelgewichte, fehlende Nutzlast oder Restkapazität, Überlast auch nur am letzten Tag und nicht speicherbare Werte verhindern die gesamte Änderung. Nutzlast und sämtliche betroffenen Artikelgewichte gehören zur Konfliktprüfung. Reservierungen, Restnutzlast, freie Kundenzeitfenster, Plantermin, Audit und Wiederholungsbeleg werden gemeinsam unter der bestehenden Tabellensperre in InnoDB gespeichert. Ein später Fehler rollt alle Tage zurück; eine identische Wiederholung belastet keinen Tag erneut.
- **Fortschreibung:** Die bisher als offen bezeichnete Gewichtsverbuchung bei der Mehrtagesumplanung ist ergänzt. Grafische Drag-and-drop-Disposition, Neuzuordnung bisher unreservierter Aufträge, Classic-Tourbildung und die übrigen offenen Bereiche bleiben Teil des Gesamtziels. Die allgemeinen Einschränkungen für angenommene/angebotene Aufträge, fremde Eigentümer und fehlende Tagesraster bleiben wirksam.

## 17. Oktober 2026 – Archivquelle erneut geprüft

Aktueller Remote-Stand `2eb7f98`: `admin/jb_list.php` und `include/global.inc.php::getDBNames` verwenden für die Archivliste `jobhistory`/`tourhistory` sowie deren Varianten 2/3. Die entsprechenden Auftrags-, Tour-, Service-, Kalkulations- und Zahlungshistorientabellen fehlen in der angebundenen Datenbank. Die angemeldete PHP-Archivliste für den 1. Januar 2021 liefert HTTP 500. Beleg: `work/archive-tables-read-probe.log`; ausschließlich SELECT und lesender UI-Aufruf. Die vollständige Archivübersicht bleibt offen, bis eine erreichbare Datenquelle samt Schema feststeht. Der bestehende separate Zugriff auf freigegebene komprimierte `job2`-Snapshots bleibt verfügbar.

## 17. Oktober 2026 – Niederlassungseinstellungen aus der aktiven PHP-Verwaltung

Aktueller SSH-Arbeitsbaum `2eb7f98`; `admin/menu.php` verweist auf `admin/hq_admin.php`, SHA-256 `f0722360b253e6e46afe450ce0adc5b8747b00b3c96ff421f358e425a423e4f0`. Alle sechs sichtbaren Bereiche in der angemeldeten PHP-Oberfläche gelesen: Standortadresse, Support-Kontakte, BWV-Hotline, GLN, DUNS und Fahrzeugklassen. Alte nummerierte PHP-Dateien sind nicht die aktive Referenz. Keine echte Speicherung vorgenommen.

- **Verwaltung → Niederlassungen:** Standortadresse mit vier Firmenzeilen, Straße/Hausnummer, PLZ und Ort; Vertrieb und Unternehmerbetreuung jeweils mit E-Mail und Telefon; bundesweite und niederlassungsbezogene Hotline-, GLN- und DUNS-Werte. Bearbeitung je Bereich und Niederlassung mit Vorher-/Nachher-Vorschau, Wiederholungsbeleg, Konfliktprüfung und Audit 199 bzw. 196. Führende Nullen und vorhandene Parameterbeschreibungen bleiben erhalten. Die Felder benutzen die aktuellen Bestandslängen; bestehende Mehrfach-Mailadressen bleiben möglich.
- **Fahrzeugklassen:** Anzahl gespeicherter Fahrzeuge je Niederlassung und Klasse, einschließlich ausgeblendeter Fahrzeuge. Ausschließlich eigener Mandant; mehrdeutige Klassentexte vervielfachen die Anzahl nicht. Anders als die unbeschränkte PHP-Zählabfrage liest NG keine anderen Mandanten.
- **Rechte:** Einstellungen werden in der Heimat-Arbeitsniederlassung geöffnet. Standort/Support lesen mit 47 oder 10, ändern mit 47; Hotline/GLN/DUNS lesen mit 45, ändern mit 47 und 45. Die Fahrzeugzählung ist für interne Mitarbeiter lesbar. Aktuelle Rechte und eindeutige Mandanten-/Niederlassungszuordnung werden erneut geprüft. Der Root-Status ersetzt das tatsächlich in PHP beim Speichern erforderliche Recht 47 nicht.
- **Gemeinsame Adressen:** Eine geteilte Anschrift wird beim Ändern für die Niederlassung kopiert; andere Firmen bleiben unverändert. Fehlende Adresse wird bei einer Änderung angelegt, fehlende/mehrdeutige oder mit Kunden/Transporteuren/anderen Niederlassungen gemeinsam verwendete Firma blockiert die Standortbearbeitung bis zur Klärung. Nicht bearbeitete Firmen-/Adressdaten bleiben erhalten. Alle Geschäftsdaten, Audit und Wiederholungsbeleg werden unter gemeinsamer Sperre atomar in bestehenden InnoDB-Tabellen gespeichert.
- **Fortschreibung:** Die sechs aktiven PHP-Bereiche der Niederlassungseinstellungen sind umgesetzt. In dieser PHP-Datei auskommentierte VPA-Ortung wird nicht als zusätzliche aktive Funktion gewertet; deren bestehende NG-Pflege bleibt separat. Ein beliebiger technischer Parametereditor ist in dieser aktiven PHP-Seite nicht enthalten. Die übrigen Tabellenzeilen bleiben Teil des Gesamtziels.

## 17. Oktober 2026 – Gewöhnliche Niederlassungsfreigaben für Auftragslisten

Frischer SSH-Stand `2eb7f98`: `admin/jb_list.php` SHA-256 `db040a7b070773da74dfbbdf3e46f3ecc55564f516f34f81dd880826221e80fc`, `include/html.inc.php` `b2c5475688f2a15e0736200c761baf586d635d96da81f5f7c2f4d5992e323aa4`, `include/global.inc.php` `ceb60bd61a1ae01729c151b78586ab8c5df301cb595e34eae8fbd923f71bcdd9`, `include/dbglobal.inc.php` `5977c0c1a9c25b8a6d28957cedeec117479fb4d0b7d70353040e30721a566b87`. Aktuelle PHP-Auftragsliste mit Niederlassungscheckboxen und Alle/Keine gelesen; keine Bestandsänderung.

- **Normale Mitarbeiter ohne CC24:** Auftragslisten, CSV und Arbeitsniederlassungswechsel verwenden das globale Auftragslistenrecht 4 und Mehrniederlassungsrecht 10, den exakten HQ-Vektor sowie Matrixrecht 5 (einsbasiert). Der eingetragene Niederlassungsadministrator benötigt keine zusätzliche Vektor-/Matrixfreigabe. Alle Ziele müssen aktiv, eindeutig und im eigenen Mandanten sein. Bestehende CC24-Regeln bleiben wirksam.
- **Fremdauftrag:** Öffnen wechselt nach Bestätigung nur diesen Browsertab in die Eigentümerniederlassung. Die wirksamen Fachrechte sind der Schnitt aus Anmelderechten, aktuellen Mitarbeiterrechten und Zielmatrix. Fremde Aufträge können nur mit dem gesondert gewährten Bearbeitungsrecht geändert werden. Entzug wirkt bei jeder Folgeanfrage; Rückkehr zur Heimatniederlassung bleibt möglich.
- **Vier Niederlassungsrollen:** Eine ausdrückliche Listenwahl berücksichtigt Eigentümer, ausführende, disponierende und vertriebliche Niederlassung. Zusätzlich muss die Eigentümerniederlassung freigegeben sein. NG übernimmt dadurch keine PHP-Treffer aus fremden Mandanten oder ohne Zugriff auf deren Auftragsdetails.
- **Fortschreibung:** Die gewöhnlichen Mehrniederlassungslisten und deren Zugriff auf fremde Aufträge sind ergänzt. Frühere Offen-Vermerke zu diesem Teil und zu inzwischen ergänzten bestätigten Auftragsmails sind überholt. Archivübersicht, Sprache, Niederlassungsparameter und übrige Fachbereiche bleiben offen.

## 17. Oktober 2026 – Vermittlungsstaufrist in Erfassung und Bearbeitung

Frischer SSH-PHP-Arbeitsbaum `2eb7f98`, ausschließlich Remote-Quellen: `jobs/job_options.php` SHA-256 `bfc6d2a725092142d36dfb93dd8ea9ae71408961c8abe5f77f82ab1e87bd9e80`, `jobs/get_saved_tour.php` `9d4bd9f4806fa861da09918b922e2a1fc8bc0677affa5a473ec7f1698a3c8cdb`, `admin/cs_csc_list.php` `d9296acc51b3073d9e4b38dd260d390eb3c30be144a0e12855e46a03024096c4`; aktives `jobs/job_edit.68.20.js` wie im vorherigen Abgleich. Aktuelle PHP-Erfassungsoberfläche gelesen; „DispoInfo“ erzeugte bei der Browserprüfung keinen sichtbaren Dialog. Die manuellen Vermittlungsstau-Schalter sind im aktuellen JavaScript auskommentiert und werden nicht als aktive Funktion nachgebaut. `automailer6.php` und der tatsächlich eingebundene Selektor `inc_automailer.inc.php` frisch gelesen.

- **Erfassung und Preisvorschau:** Der tatsächliche Zahler bestimmt Aktivierung und Minuten. Null Minuten verwenden den globalen Ad-hoc-Standard; Vorbestellungen und Daueraufträge verwenden den globalen Vorlauf vor Auftragsbeginn. Barzahlung beachtet die Auswahl des System-/Einzelzahlers. Die Vorschau zeigt Zeitpunkt, Abstand und Herkunft der Vorgabe.
- **Kopien und Serien:** Sofortauftragskopien übernehmen den gespeicherten relativen Abstand; kopierte Vorbestellungen verwenden die heutige Kundenwartezeit. Ohne vorhandene Vormerkung bleibt eine Kopie ausgeschaltet. Zahler-/Zahlungsartwechsel verwendet die neuen Kundenvorgaben. Jede Kopie und jeder vorab erzeugte Serientermin erhält seine eigene atomar gespeicherte `jb_job_jam`-Frist. Wiederholte Speicherung erzeugt keine weitere Vormerkung.
- **Auftragsbearbeitung:** Die gespeicherte Frist ist sichtbar und wird bei geänderter Auftragszeit mitgeführt. Geänderte Ausgangsdaten erfordern eine neue Vorschau bzw. Ansicht. Datum, Frist, Bearbeitungsbeleg und Audit werden gemeinsam zurückgerollt. Mehrdeutige Zeitumstellungswerte und doppelte/ungültige Fristdaten werden abgewiesen.
- **Bewusster Unterschied und Betrieb:** NG erhält bei einer Zeitänderung den bestehenden Versandstatus (`MAIL_SENT` usw.), damit bereits verarbeitete Meldungen nicht erneut ausgelöst werden. Die vorhandenen PHP-Maildienste verarbeiten die gemeinsame Vormerkung mit ihren weiteren Empfänger-/Statusregeln. Eine Vormerkung ist keine Versandbestätigung; NG startet hier keinen eigenen automatischen Versand.
- **Fortschreibung:** Die bisher offene Vermittlungsstaufrist in der NG-Erfassung ist damit ergänzt. Allgemeine Sprache, native automatische Mailverarbeitung/Betriebsumschaltung und die übrigen offenen Tabellenzeilen bleiben Bestandteil des Gesamtziels.

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

Frischer Remote-PHP-Stand `2eb7f98`; `admin/customer_special.php` SHA-256 `2159d036ac8e7c4b936c754d71270ffc6e45d8a6fe1606786fd1d0ab280dc49b` direkt per SSH gelesen. Die bestehende PHP-Kundenansicht wurde lesend betrachtet: Deutsch/Englisch, Ankunftszeit, Fußzeile, acht sichtbare Zusatzfelder sowie Vermittlungsstau-Mail und Wartezeit. Keine echte Speicherung in PHP. Die Wartezeitregel zusätzlich in `admin/cs_csc_list.php:439–446` und `jobs/get_saved_tour.php:95–104` geprüft.

- **Kunden → Bearbeiten → Kunden-Mailvorgaben:** Deutsch/Englisch, Ankunftszeit, Fußzeile, Etappenbemerkung, Rechnungstext, Kennzeichen, Kurier-/Innendienstbemerkung, Änderungsmail, Stationsabschluss-/Stornomail und Vermittlungsstau-Mail mit 0–60 Minuten in Fünferschritten. Die bereits vorhandenen Stammblattfelder für Erfassung/Abholung/Erledigung, Empfängerauswahl, Preis, Mitarbeiter und PDF bleiben dort verfügbar.
- **Gemeinsamer Datenvertrag:** `JOBDETAILS_EMAIL_LANGUAGE_<cs_id>`, `JOB_MAIL_STATION_ARRIVAL_TIME_<cs_id>`, `JOBDETAILS_EMAIL_NO_FOOTER_<cs_id>` sowie `customer.cs_jbstatusmail_fields`, `cs_jb_jam_waittime` und `cs_jb_jam_waittime_minutes`. Vorhandene positive Aktivierungswartezeit bleibt erhalten, erstmalige Aktivierung verwendet den eindeutigen HQ-/globalen PHP-Standard. Fehlender positiver Standard verhindert Aktivierung. Versteckte Bits für Mobilnummer/Fotos und unbekannte spätere Bits bleiben unverändert. Bestehende Parameterbeschreibungen bleiben erhalten; fehlende Null-Standardparameter werden nicht unnötig angelegt.
- **Speicherschutz:** Vorher/Nachher-Vorschau, Kontorechte und Arbeitsniederlassung frisch prüfen; Kunde, Parameter, Audit und Wiederholungsbeleg atomar unter gemeinsamer Tabellensperre. Die drei Schreibtabellen müssen InnoDB sein. Mehrdeutige oder falsch zugeordnete Parameter werden nicht überschrieben. Geänderte PHP-Daten oder Vorgaben nach der Vorschau erfordern erneutes Laden. Eine verlorene Antwort wird mit demselben Vorgang geklärt.
- **Bewusster Unterschied:** Ausgeschaltete Rechnungstext-/Kundenmail-Felder werden in NG ausdrücklich ausgeschaltet gespeichert; PHP kann beim nächsten Speichern seine Niederlassungsdefaults wieder einsetzen. Das zeigt der Dialog. Speichern startet keinen Mailversand; vorhandene automatische PHP-Dienste verwenden die gemeinsamen Vorgaben. Keine zusätzliche automatische NG-Verarbeitung eingeschaltet.
- **Preisberichtigung und Neukalkulation:** Beide erzeugen nun atomar denselben an Konto, Heimat-/Arbeitsniederlassung und Auftrag gebundenen Bearbeitungsbeleg wie normale Änderungen. Danach steht „Änderungsmail vorbereiten“ mit den gespeicherten Preisen bereit. Wiederholung erzeugt keinen zweiten Beleg, ein Fehler beim Beleg rollt auch die Preisänderung zurück.
- **Weiter offen:** Allgemeine Oberflächensprache, vollständiger nativer automatischer Mailbetrieb, Übernahme der kundenspezifischen Vermittlungsstaufrist in die NG-Auftragserfassung und die übrigen dokumentierten Fachbereiche. Frühere Offen-Vermerke zur Kundensprachauswahl und zu Preisänderungsbelegen sind durch diesen Abschnitt erledigt.

## 17. Oktober 2026 – Bestätigte Änderungsmail nach Auftragsbearbeitung

Aktueller Remote-Arbeitsbaum `2eb7f98`; `jobs/job_options.php` SHA-256 `bfc6d2a725092142d36dfb93dd8ea9ae71408961c8abe5f77f82ab1e87bd9e80` und tatsächlich eingebundenes `jobs/job_edit.68.20.js` `845b163033d275911b6f237e63d1313c609ab42d5ac578bd718dd5707f841aba` frisch per SSH gelesen. Die echte PHP-Erfassungsoberfläche mit getrennten Stations-/Optionsframes und Senden-Aktion wurde geöffnet, ohne Auftrag zu speichern. Den nativen Bestätigungsdialog nicht durch eine echte Änderung ausgelöst; sein aktueller Ablauf ist im eingebundenen JavaScript, Zeilen 6261–6287, geprüft.

- **Bearbeiten → Änderungen speichern → Änderungsmail vorbereiten:** Nach einer bestätigten Speicherung steht die eigene letzte Bearbeitung dauerhaft wieder zur Verfügung. Die Speicherung erzeugt atomar einen an Konto, Heimat-/Arbeitsniederlassung und Auftrag gebundenen Beleg; Rollback oder Wiederholung erzeugen keine doppelte Mailvormerkung. Ein unklarer Speicherausgang muss zuerst mit derselben Vorgangskennung geklärt werden.
- **Kundenvorgaben und Inhalt:** Empfängervorschläge verwenden dieselbe PHP-Regel wie die Erfassung, einschließlich Zusatzmail-Bit, Barzahler, persönlicher Nacherfassung, CC24 und Fahrzeugsonderregeln. Geprüfter Versand verwendet `CHANGE`, aktuelle gespeicherte Auftragsdaten und die Kundensprache. Für bereits erledigte Aufträge bleiben Nachweise, freigegebener Rechnungstext und konfigurierter PDF-Anhang erhalten; Abschluss-/Bewertungstexte und Abschlussumfrage werden nicht fälschlich als neuer Erledigungsvorgang versandt. Noch erforderliche Nachbearbeitung wird vor dem Versand angezeigt.
- **Bestätigung und Wiederholung:** Empfänger, Cc/Bcc, Mailinhalt und PDF sind separat zu prüfen. Ungespeicherte Bearbeitungen und laufende Speicher-/Mailvorgänge sperren konkurrierende Aktionen. Vor der dauerhaften Übergabe werden Konto/Rechte, Bearbeitungsbeleg, Kundenvorgaben, Inhalt und Nachweise erneut geprüft. Alle manuellen Auftragsmails teilen denselben Versandstatus; eine verlorene Antwort wird über diesen Status geklärt. SMTP folgt erst nach COMMIT, keine automatische Wiederholung. Nach bestätigt erfolgreicher SMTP-Übernahme ist eine bewusst vorbereitete weitere Mail möglich.
- **Bewusste Unterschiede:** PHP fragt vor dem Speichern in einem nativen Bestätigungsdialog und sendet danach ohne vollständige Inhaltsvorschau. NG bietet den expliziten Mailweg erst nach erfolgreichem Speichern und zeigt den tatsächlichen Inhalt. Jede eigene gespeicherte Bearbeitung darf neu geprüft werden; die Mail wird nicht automatisch nach einzelnen Änderungen versandt. Exportierte Aufträge verweisen auf den historischen Detailmailweg; Angebote und Stornos sind hier gesperrt.
- **Angebotsabgleich:** Das aktuelle `job_edit.68.20.js` kommentiert die Angebotsmail-Bestätigung ausdrücklich seit 25.02.2026 aus. NG aktiviert diese deaktivierte Bedienfunktion nicht. Der verbleibende PHP-Servercode für OFFER/OFFER_CHANGE allein ist keine aktive UI-Freigabe.
- **Weiter offen:** Native kundenspezifische Sprachauswahl, allgemeine Oberflächensprache, automatische Mailverarbeitung/Betriebsumschaltung und die übrigen dokumentierten Fachbereiche. Dieser Ausbau schließt die bestätigte Änderungsmail aus der Auftragsbearbeitung; separate Preis-/Dispositionseingriffe ohne vorherige eigene Bearbeitung erzeugen noch keinen neuen Bearbeitungsbeleg.

## 17. Oktober 2026 – Kundensprache der Auftragsmail

Aktueller SSH-Arbeitsbaum `2eb7f98`; `include/dbglobal.inc.php` SHA-256 `5977c0c1a9c25b8a6d28957cedeec117479fb4d0b7d70353040e30721a566b87`, `admin/jb_detail.php` `4f9ab54020b9285a8a7d8b8ce00c07e2a8325ef320c86fabec79bf8c2df5d039`. Live-PHP-Sprachauswahl und Detailansicht lesend betrachtet. Kein lokaler PHP-Altstand.

- Erfassungs- und manuelle Statusmails verwenden `JOBDETAILS_EMAIL_LANGUAGE_<Kunde>` und den vorhandenen `phoenix_special.language`/`languagetext`-Bestand für `admin/jb_detail.php`. Betreff, Standardtexte, Feldbezeichnungen, Nachweisüberschriften, Umfragelinktexte und PDF-Titel/Seitenfuß sind übersetzbar. Kundennamen, Leistungsnamen, Adressen und frei konfigurierte Texte werden nach den PHP-Regeln erhalten.
- Fehlende/leer hinterlegte Übersetzungen fallen wie in PHP auf den deutschen Ausgangstext zurück; die Vorschau nennt Sprache und Zahl der fehlenden Texte. Ungültige Sprachkennung, unzugänglicher Sprachbestand und widersprüchliche Übersetzungen werden gemeldet. Kein automatisches Befüllen der PHP-Wörterbücher. Der echte Bestand enthält 26 registrierte Sprachen, aber für diese Mailquelle derzeit nur 118 englische Wörterbucheinträge. Eine vollständige Übersetzung aller 26 Sprachen ist damit nicht behauptet.
- Übersetzungen sind Bestandteil der geprüften Versandrevision. Änderungen nach der Vorschau verhindern den Versand; die vorhandenen MyISAM-Sprachtabellen werden während der abschließenden Prüfung lesend gesperrt. Beide bestehenden Versandwege bleiben gegen doppelte Übergabe geschützt.
- Archivierte Mailteile behalten ihre damaligen Texte. Übersetzte und gemischtsprachige Feldbezeichnungen werden über den Sprachbestand auf die aktuellen Kundenfreigaben zurückgeführt; Innendienst-/Kuriernotizen, Rechnungstext, Telefon und Kennzeichen werden dadurch weiterhin nur nach Freigabe gezeigt. Unbekannte oder mehrdeutige Stations-/Kurierbezeichnungen blockieren die Ausgabe. Deutsch ohne Archiv benötigt keinen Sprachdatenbankzugriff.
- Noch offen: bestätigte Änderungs-/Angebotsmail aus der Bearbeitung, automatische Mailworker/Betriebsumschaltung, allgemeine Oberflächensprache, native kundenspezifische Sprachauswahl und die übrigen dokumentierten Fachbereiche. Die alten „weitere Mailsprachen“-Vermerke beziehen sich auf den Stand vor diesem Abschnitt.

## 17. Oktober 2026 – Auftragsmail aus historischen PHP-Snapshots

Frischer SSH-Arbeitsstand `2eb7f98`; `include/jb_detail_history.inc.php` SHA-256 `e85f0d42456dd84773b4495653bbff02a1687ef1231401e15a45143f65d8aeff`, `include/inc_job.inc.php` `0b660ceef70176f64314cf74809fa681eac06553c534473a4690d0edf941e0c6` und `include/glob_defs.inc.php` `9daf7316caf09c9fad1ba68439aa3b9f01e5636c5143210bdb65ddf2963ec0fb` erneut direkt gelesen. Die echte PHP-Detailansicht des exportierten Auftrags wurde erneut betrachtet. Kein lokaler PHP-Altstand verwendet.

- **Exportierte Aufträge in den vorhandenen Auftragsdetails:** Die manuelle Mail lädt den komprimierten `jb2_history_mail`-/`jb2_history_rawdata`-Snapshot. Suche zunächst in lokaler `job2`, dann lokalen Jahrestabellen absteigend, anschließend auf dem getrennten Archivserver. Vorhandene Jahrestabellen werden erkannt; keine fest verdrahtete Obergrenze 2025. Quelle wird vor dem Versand angezeigt.
- **Historischer Inhalt:** Auftrags-, Stations-, Transporteur- und Kostenbestandteile bleiben aus dem archivierten Kunden-Mailstand erhalten. Matrixdarstellung und klassische Stationstabellen werden unterstützt. Historischer Rechnungskunde/-kostenstelle und Auftragskennung werden gegengeprüft; aktuelle Zuordnung zu einem anderen Kunden wird abgewiesen. Aktuelle Kundenfreigaben können archivierte Felder weiter einschränken. Private HQ-Rohfelder und die komplette Mitarbeiterhistorie werden nicht als Kundeninhalt verwendet.
- **Nachweise/PDF:** Unterschriften werden aus den eingefrorenen Koordinaten erzeugt, Fotos aus der eindeutig zugeordneten PIC-/B2B-Station gelesen. Keine beliebigen alten Datei-/Webpfade. Fehlende Zuordnung oder ein referenzierter, nicht verfügbarer Nachweis wird gemeldet. Mail und PDF verwenden denselben geprüften Kundeninhalt. Aktuelle Gruß-/Footer-/Umfragevorgaben bleiben wie beim PHP-Mailversand wirksam. In laufenden Auftragsmails sind außerdem Erledigungszeit und der per Kundenbit freigegebene Rechnungstext ergänzt.
- **Datenqualität:** Begrenzte Raw-Deflate-Dekompression, UTF-8 sowie altes Windows-1252 einschließlich Eurozeichen, identische PHP-Doppelfelder erlaubt; widersprüchliche Felder, falsche Auftragsbindung, doppelte Snapshots, fehlender Mailbestandteil, beschädigte/überlange Daten und unbekannte Stationsstruktur werden abgewiesen. JavaScript, Formulare und externe Bilder aus gespeichertem HTML werden entfernt; interne `[[…]]`-Zusätze bleiben verborgen.
- **Versand und Rückfall:** Vor der dauerhaften Versandvormerkung wird der Snapshot erneut verglichen; Änderungen erfordern eine neue Vorschau. Lokale MyISAM-Archivtabellen werden dabei lesend gesperrt. Nur wenn in sämtlichen konfigurierten Quellen wirklich kein Snapshot existiert, wird wie in PHP der aktuelle Auftrag verwendet – mit ausdrücklichem Hinweis vor der Bestätigung. Verbindungsfehler oder beschädigte Archive werden nicht als fehlender Snapshot behandelt.
- **Archivverbindung:** `ARCHIVE_DB_URL`, `ARCHIVE_DB_USER`, `ARCHIVE_DB_PASSWORD`; aktuelle PHP-Zugangsdaten in der ignorierten `.env`, keine Geheimnisse in der Beispieldatei. Der echte Archivserver ist MySQL 5.5.58 und unterstützt `SET TRANSACTION READ ONLY` noch nicht. Deshalb akzeptiert der Archivzugriff ausschließlich drei festgelegte, begrenzte SELECT-Abfrageformen, keine Funktionen/Freiform-SQL/Mehrfachbefehle; moderne Server erhalten zusätzlich serverseitige Nur-Lese-Transaktionen. Keine Archivschreibfunktion und kein Schemaeingriff.
- **Noch offen:** Vollständige Archivlisten und Auftragsdetails ohne aktuellen `job`-Datensatz, weitere Mailsprachen, bestätigte Änderungsmail aus der Bearbeitung, automatische Mailworker/Betriebsumschaltung sowie die übrigen dokumentierten Fachbereiche. Dieser Abschnitt erweitert die vorherige Mailumsetzung; er behauptet keine vollständige Archivmigration.

## 17. Oktober 2026 – Manuelle Statusmail mit Nachweisen und PDF

Frischer SSH-Arbeitsstand `2eb7f98`, ergänzt um `admin/pdf_generic.php` SHA-256 `de6e54d5d19fa52853949a7ce9b2086a6af257fd98c74c1a92f8a7d360a6b35d`, `include/global.inc.php` `ceb60bd61a1ae01729c151b78586ab8c5df301cb595e34eae8fbd923f71bcdd9`, `include/glob_defs.inc.php` `9daf7316caf09c9fad1ba68439aa3b9f01e5636c5143210bdb65ddf2963ec0fb`. `jb_detail.php`, `jb_detail_history.inc.php` und `inc_job.inc.php` erneut direkt gelesen, Hashes unverändert zum Nachweisabschnitt. Die zuvor gelesene echte PHP-Detailansicht zeigt den manuellen Mailversand bei erledigten Aufträgen sowie PDF, Unterschriften und Fotos.

- **Auftragsdetails → Auftragsmail:** Für nicht exportierte Einzelaufträge ohne Angebot/Storno stehen Erledigungsmails sowie die je Niederlassung freigegebenen Abholungs- und Vermittlungsmails bereit. Empfänger werden wie im PHP manuell angegeben; Absender, Cc und Bcc werden aus den vorhandenen Vorgaben aufgelöst und vollständig angezeigt. Native Vorschau mit ausdrücklicher Inhalts-/Empfängerbestätigung.
- **Kundeninhalt:** Quittungsgeber, Erledigungszeit, Unterschriften und PIC-/B2B-Fotos, optionale Ankunftszeit, konfigurierte Artikelspalten/Barcodes, Abliefermeldungen und explizit freigegebene Innendienstbemerkungen. Preis- und Datenfreigaben, Abschluss-/Rezensionstexte und Ansprechpartnerdarstellung werden berücksichtigt. Interne `[[…]]`-Zusätze gelangen nicht in die Kundenmail.
- **PDF:** Bei `cs_jbstatusmail_pdf=1` hängt die Erledigungsmail ein eigenständiges, paginiertes PDF an. Vorschau aller Seiten und Download erfolgen vor dem Versand. PDF und Mail enthalten denselben freigegebenen Kundeninhalt; externe Logos werden im PDF nicht nachgeladen. Bewusste Verbesserung zum PHP: keine Preisweitergabe im PDF bei deaktivierter Kundenpreisfreigabe, passende Bild-MIME-Typen, Bilder ohne Verzerrung und Seitenumbruch statt fester überlaufender Positionen. SVG/HTML/Datei- und externe Bildquellen werden nicht ausgeführt oder aufgelöst.
- **Umfrage:** Kategorie 15, Datum/Niederlassung/Kunde bzw. Metakunde/Kurier/SID/Fahrzeug/Gruppe/Branche und `MAIL_SURVEY` werden berücksichtigt. Die Quote wird einmal pro Vorschautoken gewählt und beim Versand identisch reproduziert. Der persönliche Hash stammt aus dem bestehenden read-only Metaobjektzugriff; feste PHP-Obfuskationszahlen erzeugen die kompatible Auftragskennung. Fehlende/mehrdeutige Schlüssel oder unsichere URLs blockieren die betroffene Mail. Umfragelinks sind auch im PDF anklickbar. Es werden keine PDA-Marker geschrieben. Bestehende PDA-Regeln bleiben separat.
- **Versand:** Rechte 4+7, aktuelle Niederlassung, unveränderter Inhalt/Anhänge/Konfiguration werden vor dem dauerhaften Startbeleg erneut geprüft. Auch parallele Prozesse können dieselbe geprüfte Mail nur einmal übernehmen. SMTP startet nach COMMIT/UNLOCK. STARTED/UNCERTAIN erlauben keinen automatischen Neuversand; nach SENT ist eine weitere Mail nur über einen neuen bewussten Vorbereitungsschritt möglich. Vorschauen sind an Benutzer, Niederlassung und Auftrag gebunden, laufen nach 15 Minuten ab und sind in Anzahl/Speicher begrenzt.
- **Fortschreibung:** Exportierte Auftragssnapshots sind im nachfolgenden Ausbau ergänzt (Abschnitt oben). Offen bleiben vollständige Archivlisten, weitere Mailsprachen, bestätigte Änderungsmail aus der Bearbeitung sowie automatische Mailworker und die übrigen dokumentierten Menülücken. Diese Umsetzung behauptet keine vollständige Mail-/Archivparität.

## 17. Oktober 2026 – Native Abliefernachweise

Beim Ausbau der Auftragsmail wurde die fehlende native Anzeige der zugrunde liegenden Stationsnachweise ergänzt. Referenz ist weiterhin ausschließlich der frische SSH-Arbeitsbaum `2eb7f98`: `include/image.inc.php` SHA-256 `9048068e16aa5f9e6e004a9cdd4b92ac2612d2cda55961529a2b57a6e78c32e8`, `include/inc_job.inc.php` `0b660ceef70176f64314cf74809fa681eac06553c534473a4690d0edf941e0c6`; `jb_detail.php`/`jb_detail_history.inc.php` wie im Mailabschnitt. Die echte PHP-Detailansicht eines erledigten/exportierten Auftrags mit zwei Unterschriften und Foto wurde erneut gelesen.

- **Auftragsdetails → Abliefernachweise:** Stationen mit Ankunft, Arbeitsbeendigung, Erledigung, Quittungsgeber, Unterschrift, Fotos, Abliefercode/Statusgrund, Transporteursnotiz, Innendienstkennzeichen/-text und Artikelbarcodes. Auch noch offene Stationen bleiben sichtbar. Kundenbezogene Abliefercode-Texte verwenden die bestehende Parameterhierarchie; Code 1 wird je Stationsrichtung als Abgeholt/Abgeliefert benannt.
- **Unterschriften:** Das bestehende `A x,y;…`-Format wird in Speicher-PNG umgewandelt. Getrennte Linienzüge bleiben getrennt; der letzte Abschnitt wird mitgezeichnet (PHP lässt ihn im alten Schleifenende teilweise aus). Ungültige oder zu große Koordinaten werden abgewiesen. Kein Schreibzugriff auf PHP-Temporärverzeichnisse.
- **Fotos:** Primär `phoenix_log.pic`, nur ohne Treffer an derselben Station Rückfall auf B2B-Typen 101/102 mit sortierten CDATA-Blöcken. JPEG/PNG werden überprüft; Bildgröße und Dateigröße sind begrenzt. Bilder werden auf Wunsch geladen und können heruntergeladen werden. Ein defektes Bild blockiert die übrigen Stationsnachweise nicht; gezieltes Wiederholen ist möglich. Die Anzeige verwendet weder öffentliche PHP-Dateilinks noch externe Bildanfragen.
- **Zugriff:** Anmeldung, aktuelle Leseberechtigung und Arbeitsniederlassung werden für Übersicht und jeden einzelnen Bildabruf geprüft. Auftrag, Station und Bild müssen zusammengehören; eine beliebige Fotokennung eröffnet keinen Zugriff. Die Funktion ist vollständig lesend.
- **Mailkorrektur:** Interne Zusätze in `[[…]]` werden jetzt wie im PHP aus den für Kunden bestimmten Stationsbemerkungen entfernt. Die bestehende Erfassungsmail erhält keine zusätzlichen internen Felder.
- **Noch offen:** Einbindung dieser Daten in die bestätigte Mail für erledigte/bearbeitete Aufträge, PDF-Anhänge, historische Rechnungs-/Archivsnapshots, Foto-Workflowvorgaben und Dokumentdienst in der Detailansicht sowie die übrigen Mail-/Menübereiche. Der neue Bereich zeigt ausdrücklich aktuelle Stationsdaten und ersetzt noch keinen historischen Rechnungssnapshot.

## 17. Oktober 2026 – Bestätigte Mail nach Auftragserfassung

Aktueller SSH-Arbeitsbaum `2eb7f98`; erneut direkt gelesene Referenzen: `admin/jb_detail.php` SHA-256 `4f9ab54020b9285a8a7d8b8ce00c07e2a8325ef320c86fabec79bf8c2df5d039`, `include/jb_detail_history.inc.php` `e85f0d42456dd84773b4495653bbff02a1687ef1231401e15a45143f65d8aeff`, `include/dbglobal.inc.php` `5977c0c1a9c25b8a6d28957cedeec117479fb4d0b7d70353040e30721a566b87`; Erfassungs-JavaScript und `job_options.php` wie im Statusmail-Abschnitt. Die echte PHP-Auftragsdetailseite einschließlich Auftragsmailfeld, Unterschriften, Fotos und Scanbemerkungen wurde lesend geprüft. Keine Mail und keine Bestandsänderung ausgelöst.

- **Nach Speicherung:** Für passende Kundenvorgaben öffnet eine eigene Mailprüfung. Auftragsspeicherung ist abgeschlossen; Schließen oder Mailfehler erzeugt keinen weiteren Auftrag. Kopien und sofort erzeugte Serientermine sind einzeln auswählbar. „Gespeicherte Auftragsmails“ zeigt die letzten 20 eigenen Erfassungsvorgänge der gewählten Niederlassung, einschließlich gespeichertem Versandstatus.
- **Inhalt:** Deutsche Auftrags-/Änderungsmail für noch offene, nicht exportierte NG-Erfassungen ohne bereits dokumentierte Ablieferung. Auftragsdaten, Fahrzeug, Kurierdaten nach Freigabebits, Stationen, Referenzen, Kostenstellen, Stationsbemerkungen und Kundenpreise nach den PHP-Kundenvorgaben. Niederlassungstexte, Absender, Cc/Bcc, globale Druck-/Preisregeln, Kundenfußtext, Signatur und Pflichttext sind berücksichtigt. Auch der PHP-Erfassungspfad verwendet CHANGE; der Betreff lautet entsprechend „wurde geändert“.
- **Vorschau:** Änderbare, streng geprüfte Empfänger, sichtbare An-/Kopie-/Blindkopieliste, HTML-Inhalt in einem isolierten Frame und eigene Bestätigungscheckbox. Absender aus Niederlassungsparameter bzw. `SMTP_FROM`; Kopie/Blindkopie aus Niederlassungsparametern bzw. den optionalen `.env`-Werten `ORDER_MAIL_CC`/`ORDER_MAIL_BCC`. Diese neuen Rückfallwerte wurden nicht mit vermuteten PHP-Konstanten befüllt. Maximal 20 Empfänger insgesamt; Adressen werden fallunabhängig dedupliziert.
- **Versand:** Frische Rechte-, Niederlassungs-, Vorgangs-, Inhalts- und Empfängerprüfung. Dauerhafter Übergabebeleg und Audit werden unter Tabellensperren geschrieben; erst nach Commit/Entsperren erfolgt SMTP. Parallele Bestätigungen, einzelne Kopiebelege und wiederholte Antworten führen nicht zu einer zweiten Übergabe. Fehlende Antwort, SMTP-Ausnahme oder unbestätigter Abschluss bleiben als gestarteter/unklarer Versand sichtbar; kein automatischer Neuversand. „SMTP bestätigt“ bedeutet Annahme durch den Server, keine bestätigte Zustellung.
- **Bewusste Korrekturen:** Fremde Erfassungsbelege und unklare Stammdaten bleiben gesperrt. Aktive HTML-Inhalte werden entfernt; externe Bilder sind in der Vorschau gesperrt. Bei Bruttodarstellung wird auch die Maut mit dem Steuersatz umgerechnet, statt den PHP-Nettomautbetrag zur Bruttosumme zu addieren. Beliebige PHP-CSS-Klassen und eingebettetes Branding-HTML werden nicht ungeprüft übernommen.
- **Weiter offen:** Mail für erledigte/exportierte/historische Aufträge mit Ablieferdaten, Bildern und PDF; allgemeine manuelle Mail aus der Auftragsbearbeitung, Änderungen nach der Erstmail, weitere Sprachen und vollständige Gestaltungsvorgaben. Native automatische Mailworker und Betriebsumschaltung bleiben offen. Diese Ergänzung schließt ausschließlich den beschriebenen Erfassungsweg.

## 17. Oktober 2026 – Zusätzliche Statusmail-Empfänger in der Erfassung

Aktueller SSH-Arbeitsbaum `2eb7f98`; ausschließlich aktuelle Remote-Dateien gelesen: `include/ajaxReqJob.php` SHA-256 `2168ffc8b3a59851769fba110dfd15a1e5ed6e9798b151107f0652d046e021f2`, `jobs/job_edit.68.20.js` `845b163033d275911b6f237e63d1313c609ab42d5ac578bd718dd5707f841aba`, `jobs/job_options.php` `bfc6d2a725092142d36dfb93dd8ea9ae71408961c8abe5f77f82ab1e87bd9e80`, `include/inc_automailer.inc.php` `14e86b408c277725164ac06c27fe02a38b4bfb6eeb5e2ab3f666a02b28bf2bd2`, `include/automailer5.php` `da41a8e8e682bf984bac8573dc4340346d5493bb85a46e1b575d5afe1fb48919`. Echte PHP-Erfassung im separaten Referenztab angesehen und auf Barzahlung umgeschaltet; dort ohne gewählten Kunden kein aktives Zusatzmailfeld. Keine Speicherung oder Mailauslösung.

- **Erfassung:** Standardempfänger und aktivierte Ereignisse Erfassung/Abholung/Erledigung anzeigen; bis zu 20 zusätzliche reine E-Mail-Adressen mit Komma oder Semikolon, Dublettenbereinigung ohne Änderung der Reihenfolge. Rechnungsmail bleibt ein eigenes Feld. Für Angebote kein automatischer Statusversand.
- **Barzahlung:** Ereignisse und Standardempfänger gehören zum tatsächlichen Rechnungskonto (konfigurierter Systembarzahler), unabhängig von der Preisberechnung mit `MASK_CASH_PAYER_SELECT`. Der Empfängervorschlag für die getrennte bestätigte Auftragsmail stammt dagegen vom eigentlichen Barzahler; `MASK_IGNORE_JBSTATUSMAIL2CSC`, Änderungsbit, Nacherfassungsmodus, LKW und CC24/Sondermitarbeiter werden als eigene Regeln ausgewertet.
- **Speichern:** Revisionsprüfung der aktuellen Kundenvorgaben vor Vorschau und Anlage; konkrete zusätzliche Empfänger fließen in den Vorschaufingerabdruck ein. Speicherung als `genericdatacontainer: jb/jb_cashpayer_mail`, leerer Versandkontext, atomar mit dem Auftrag. Die bereits vorhandene `automailer5`-Semaphore bleibt Teil derselben Anlage. Kopien und sofort erzeugte Serientermine bekommen jeweils ihren eigenen Eintrag. Wiederholung einer bestätigungslosen Anfrage erzeugt keine neuen Empfänger oder Aufträge. Ältere Anfragebelege bleiben kompatibel.
- **Vorlagen:** PHP-/NG-Aufträge liefern nur die zusätzlichen Adressen in den neuen Entwurf. `MAIL_SENT`, `MAIL_NOT_SENT` und numerische Ereignisbits werden nicht kopiert. Mailvorgaben werden neu gelesen. Änderung von Zahler/Zahlungsart verwirft die Zusatzadressen im laufenden Entwurf; die bewusste Übernahme derselben Vorlage zeigt deren ursprüngliche Adressen wieder.
- **Bewusste Korrekturen:** Ungültige Adressen und fehlende Kundenkonto-/Rechnungsadressverknüpfungen werden angezeigt; mehrdeutige Rechnungskontakte/Parameter werden abgewiesen. Bei aktivierten Ereignissen darf eine zusätzliche Adresse auch dann ausdrücklich angegeben werden, wenn die Standardadresse fehlt (PHP verbirgt das Feld häufig). Diese zusätzlichen Adressen können vom vorhandenen `automailer5` verarbeitet werden. Keine Behauptung erfolgreicher Zustellung: Vormerkung und SMTP-Übergabe sind getrennte Zustände.
- **Fortschreibung:** Die bestätigte Auftragsmail für offene NG-Erfassungen ist inzwischen ergänzt (Abschnitt oben); erledigte/bearbeitete Aufträge bleiben offen. Native Übernahme/Betriebsumschaltung der automatischen PHP-Mailverarbeiter ist ebenfalls offen. Gewöhnliche Mehrniederlassungslisten und alle übrigen offenen Fachbereiche bleiben im Gesamtziel.

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

Frischer SSH-Arbeitsbaum `2eb7f98` und echte PHP-Oberfläche erneut geprüft: aufgeklapptes Niederlassungsmenü B/DD/E/F/H/HB/HH/L/S und dieselben Checkboxen mit Alle/Keine in der Auftragsliste. Referenzen: `admin/menu.php`, `admin/relogin.php`, `include/auth.inc.php`, `include/dbglobal.inc.php` (Hashes im folgenden CC24-Abschnitt); neu `admin/jb_list.php` SHA-256 `db040a7b070773da74dfbbdf3e46f3ecc55564f516f34f81dd880826221e80fc` und `include/html.inc.php` `b2c5475688f2a15e0736200c761baf586d635d96da81f5f7c2f4d5992e323aa4`. Keine PHP-Sitzungsumschaltung oder Bestandsänderung für die Prüfung.

- **Arbeitsniederlassung:** Auswahl in der Kopfzeile; ein Wechsel lädt Fachbereiche, Listen und Filter neu. Offene Bearbeitungen/Objektdialoge und laufende Schreibanfragen verhindern den Wechsel. Die Auswahl gilt pro Browsertab, wird mit Benutzer/Heimatniederlassung gebunden gespeichert und beim Neuladen erneut geprüft. Eine entzogene oder fehlerhaft gespeicherte Auswahl fällt mit Hinweis auf die Heimatniederlassung zurück. Dorthin kann auch bei entzogener CC24-Freigabe zurückgewechselt werden.
- **Servergrenzen:** `X-Workspace-Headquarters` setzt ausschließlich den Kontext der einzelnen Anfrage; die gemeinsame Login-Sitzung bleibt unverändert. Aktive, eindeutig zugeordnete Niederlassungen desselben Mandanten, exakte CC24-Mitgliedschaft und Schnitt aus Sitzungs-/Bestandsrechten werden erneut geprüft. Keine zusätzlichen Rechte durch PHP-Fremdmaske; unabhängige Lagerfreigabe bleibt erforderlich. Abgeschlossene alte Anfragen können keine Daten in den neuen Arbeitsplatz übernehmen. Recovery-/Anmeldeendpunkte sind unabhängig von der fremden Auswahl.
- **Listen:** CC24 plus Niederlassungsrecht kann je Einzelliste/Parallelfenster mehrere Niederlassungen wählen. Die explizite Auswahl berücksichtigt wie die vier PHP-UNIONs Eigentümer-, Ausführungs-, Dispositions- und Vertriebsniederlassung; der Auftragseigentümer bleibt zusätzlich auf die erlaubten aktiven Niederlassungen des Mandanten begrenzt. Treffer werden nicht vervielfacht. Gleiche Filter vor Zählung, Sortierung, Seitenbildung und CSV. Ohne explizite Auswahl gilt unverändert die aktuelle Arbeitsniederlassung. Autoranking-Sammelaktionen werden bei einer fremden/mehrfachen Auswahl nicht als Aktion auf diese Auswahl angeboten.
- **Fremde Aufträge:** Niederlassungskennzeichnung und eigener Wechsel-/Öffnendialog; nach erfolgreicher Vorprüfung wird der Auftrag im Zielkontext frisch gelesen. Tabellen, Parallelfenster und Dispositionskarten verwenden denselben Weg. Bearbeitung, Storno, Stationssortierung und Vermittlung bleiben an ihre bestehenden fachlichen Prüfungen im Zielkontext gebunden.
- **Persönliche Listenwerte:** Parameter, Parallelvorgaben und Spalten werden auch im fremden Kontext gelesen, mit bestehendem Rückfall auf Heimatwerte. Die Pflege dieser Einstellungen ist weiterhin in der Heimatniederlassung möglich; fremde Selbstansichten sind ausdrücklich lesend, fremde Mitarbeiteransichten bleiben gesperrt.
- **Noch offen:** Bestätigte Auftrags-/Änderungsmail; Zusatzempfänger und Vorschlagsregeln inzwischen ergänzt (Abschnitt oben). Gewöhnliche niederlassungsübergreifende Auftragslisten über HQ-Vektor/Rechtematrix ohne CC24 und deren Fremdauftragsbearbeitung sind separat zu ergänzen. Kunden-/Kurierportale, Sprache/Metaobjekte und übrige Fachbereiche sind dadurch nicht abgeschlossen.

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

Frischer SSH-Arbeitsbaum `2eb7f98`: `admin/employee.php` (SHA-256 `4c90cdf4e63b0861dc7780cb6fd3184f8c3b21667ba90a6e6c706c8a75037bce`), `include/auth.inc.php` (`67397664c0d901e81bb6a9047905488c7bafd84be453fc7b713e2f5f751f8866`), `include/dbglobal.inc.php` (`5977c0c1a9c25b8a6d28957cedeec117479fb4d0b7d70353040e30721a566b87`), `admin/relogin.php` (`8ee60829491f2b498dba211f937967d4d4fcc0e3e96ac21cbf8d080d526ee6c2`), `admin/menu.php` (`c55edfd0a10afb5b48b68913e9f33a299829ab70a82faaedd558d3048a7bd64c`), `jobs/job_header.php` (`d0a89510ba66a0f57ba7b75e9676c3c3539f07209b611dba47e760da0b80bb98`) und `jobs/job_options.php` (`bfc6d2a725092142d36dfb93dd8ea9ae71408961c8abe5f77f82ab1e87bd9e80`). Aktuelles PHP-Mitarbeiterpopup geöffnet, separaten „CC-24-Zugang: Ja/Nein“-Schalter gelesen; keine Speicherung.

- **Mitarbeiter → CC24:** Freigabe anzeigen, erteilen und entziehen. Zentralenrechte 3 und 34 müssen in Sitzung und aktuellem Bestand vorliegen. Zielkonto muss eindeutig einem Zentralenmitarbeiter innerhalb der administrierbaren Niederlassungen gehören. Alle Niederlassungsadministratorkonten sind geschützt. Eigene Freigabe ist für einen berechtigten Nicht-Administrator wie in PHP änderbar. Kein Umweg über einen fremden Erfassungskontext.
- **Gemeinsamer PHP-Parameter:** `HEADQUARTERS_MULTIPLE_ACCESS_EMPLOYEES` mit `emp_id=0,hq_id=0`; vollständige numerische Kennungen, keine Teiltreffer. Andere Mitarbeiterkennungen (auch fremder Mandanten), Reihenfolge und Parameter-Metadaten bleiben erhalten. Doppelte Parameter und fehlerhafte Kennungen werden abgewiesen. Revisionsprüfung, Tabellenlocks gegen PHP, atomare Parameter-/Audit-/Belegänderung, MyISAM-Schreibschutz und identische Wiederholung nach verlorener Bestätigung. Historie zeigt CC24 vorher/nachher.
- **Auftragserfassung:** CC24-Mitarbeiter können aktive, eindeutig zugeordnete Niederlassungen desselben Mandanten auswählen, auch ohne gewöhnliche Freigabe in `emp_headquarters`/`employeerights`. Gewöhnliche Freigaben bleiben weiterhin verwendbar. Die Prüfung läuft für jede Erfassungsanfrage neu. Rechte sind der Schnitt aus Sitzung und aktuellem Bestand; im fremden Bereich ohne Niederlassungsrecht zusätzlich eingeschränkt. Die alte PHP-Maske kann fehlende Einzelrechte hinzufügen; NG tut dies bewusst nicht. Lagerzugriff verlangt weiterhin das separate Lagerrecht und die passende Niederlassungsfreigabe. Es wird kein globaler Sitzungswechsel ausgelöst.
- **„An alle geeigneten Kuriere“:** `HEADQUARTERS_MULTIPLE_ACCESS_EMPLOYEES_GLOBALJOBS` enthält Niederlassungskennungen. Für CC24 und den ausschließlich hier geltenden PHP-Sondermitarbeiter `300001` wird eine nicht leere Liste in UI, Vorschau und erneut beim Speichern erzwungen. Ein leerer Wert beschränkt nicht; gewöhnliche Mitarbeiter bleiben von dieser Sonderregel unberührt. Der Sondermitarbeiter erhält dadurch keinen Niederlassungszugang.
- **Bewusste Begrenzung:** PHP bietet einzelne HQ-Auswahlen ohne Mandantenfilter und schließt im Job-Header die fest codierte HQ 10 aus, während das allgemeine Wechselmenü sie nicht ausschließt. NG hält alle Erfassungszugänge innerhalb eines eindeutigen Mandanten und aktiver Niederlassungen; es übernimmt keinen pauschalen Ausschluss einer technischen HQ-Kennung. HQ 10 existiert im verbundenen Bestand nicht.
- **Fortschreibung:** Arbeitsplatzwechsel und CC24-Auftragslistenauswahl inzwischen ergänzt (Abschnitt oben). Statusmail-Vorschlag aus `include/ajaxReqJob.php` (SHA-256 `2168ffc8b3a59851769fba110dfd15a1e5ed6e9798b151107f0652d046e021f2`) ist inzwischen als Empfängerregel ergänzt; bestätigte Auftragsmail bleibt offen (Abschnitt oben). Sprache, Metaobjekte und übrige Fachbereiche bleiben separat offen.



## 17. Oktober 2026 – Kundenmitarbeiter, Portalrechte und Kostenstellenmatrix

Aktueller SSH-Arbeitsbaum erneut geprüft (`2eb7f98`), insbesondere `admin/employee.php`, `admin/employee_csc_rights.php` und `include/inc_customer.inc.php`; Hashes im Hauptzugangsabschnitt. Kundenstamm/Kostenstellen der echten PHP-Oberfläche bleiben Referenz. Der aktuelle PHP-Matrixdialog für den gewählten Kunden antwortet mit HTTP 500 (`work/php-kostenstellenrechte-500-2026-10-17.png`); ein vollständiger visueller Vergleich dieser Maske war deshalb nicht möglich. Die getrennte Kundenmitarbeiter-Selbstverwaltung benötigt außerdem eine Kundensitzung; es wurde kein fremdes Konto angemeldet oder verändert.

- **Neu im Kundenstamm:** „Kundenmitarbeiter / Portalrechte“ mit Suche nach Name, Anmeldename und E-Mail, Stammkostenstelle, Hauptzugangskennzeichnung und bis zu 500 Treffern. Zusätzliche Konten anlegen, Kontakt-/Profildaten und Stammkostenstelle bearbeiten, Passwort wechseln, 2FA zurücksetzen und Konto nach Namensbestätigung löschen. Der Hauptzugang darf nicht gelöscht, über den Mitarbeitersatz umgezogen oder mit dessen Passwortaktionen verändert werden; seine Portalrechte sind hier separat pflegbar.
- **Kundenrechte:** alle 16 PHP-Rechte mit eigener Belegung: Kostenstellennavigation/-verwaltung, Mitarbeiter, Adressen, Aufträge, Rechnungen, Intervall, Export, Statistik, Karte, Benutzerkonten, Dokumente, Kostenstellenmatrix, Termine, Scan-Objektmanagement und Import. Die ersten 16 Positionen der Vererbungsmaske werden wie PHP an die Auswahl angeglichen; unbekannte spätere Bits bleiben erhalten. Neue zusätzliche Mitarbeiter beginnen ohne Rechte. Neu angelegte Kunden-Hauptzugänge erhalten nun die sieben PHP-Standardrechte (0–5 und 10); bestehende Konten werden nicht pauschal geändert.
- **Kostenstellenmatrix:** eigene Tabelle/Parameter werden erkannt. Die vorhandene `MASK_EMP_CSC_MATRIX_ENABLED`-Vorgabe mit HQ-/globalem Rückfall wird beachtet. Der eigene Niederlassungsadministrator kann alle passenden Unterkostenstellen pflegen; andere Bearbeiter nur ihre ausdrücklich delegierten Zellen. Fremde/geschützte bestehende Freigaben bleiben erhalten. Stammkostenstelle und neue Freigaben müssen zum Kunden gehören; zyklische/verwaiste Zuordnungen werden abgewiesen. Hauptkostenstellenfreigaben sind geschützt. Portalrechte werden nicht mit gleich nummerierten Zentralenrechten verwechselt.
- **Schreiben:** Zentralenrechte 0 und 3, auf die eigene ursprüngliche Niederlassung beschränkt, bei jeder Änderung neu gelesen. Passwort/2FA benötigen zusätzlich Recht 37/43 oder den Niederlassungsadministrator; 2FA verlangt dessen aktuelles Passwort. Globale Login-Eindeutigkeit, Revisionskonflikte, idempotente Belege und Tabellenlocks gegen PHP. Benutzer-/Mitarbeiter-/Parameteränderungen, Matrixänderungen und Audit gemeinsam transaktional; MyISAM-Schreibziele abgewiesen. Beim Löschen bleiben historische Aufträge/Protokolle erhalten. Passwort/Secret werden weder ausgegeben noch protokolliert.
- **Betriebsgrenze:** In der verbundenen Datenbank fehlt `employeecostcenter`. Profil-/Konto-/Portalrechtefunktionen bleiben trotzdem nutzbar, die Matrix ist dort gesperrt. Das explizit anzuwendende, gegen isolierte MariaDB geprüfte Skript `backend/sql/portal-costcenter-matrix.sql` liegt bereit und wurde nicht am echten Bestand ausgeführt. Es aktiviert keine Parameter. Kein automatischer Schemaeingriff.
- **Weiterhin offen:** NG-Anmeldung und eigene Portalansichten für Kunden-/Transporteurbenutzer sowie externe Konten-Metaobjekte. Die Verwaltungsfunktionen speichern kompatibel für die bestehenden PHP-Zugänge; sie beweisen noch keine vollständige Portalmigration oder produktive Matrixaktivierung.


## 17. Oktober 2026 – Kunden- und Transporteur-Hauptzugänge

Frisch geprüft: SSH-Arbeitsbaum `2eb7f98` unter `/data/0/votian-test/html`. Referenzen: `admin/customer_special.php` (`2159d036ac8e7c4b936c754d71270ffc6e45d8a6fe1606786fd1d0ab280dc49b`), `admin/courier_special.php` (`64c753ec0c7b36ef86215c5ce24f5f8cf4889334c147e746e5ec5134264accfa`), `admin/employee.php` (`4c90cdf4e63b0861dc7780cb6fd3184f8c3b21667ba90a6e6c706c8a75037bce`) und `admin/employee_csc_rights.php` (`c56532aac2db2e7e0c7534512462a1a9b8dfed43e0e6381fc3f69ffe07829db3`). Kunden- und Transporteurstammblatt in der laufenden PHP-Oberfläche einschließlich Loginfeldern und 2FA-Aktion angesehen; keine Änderung ausgelöst.

- **Neu:** Im bestehenden Kunden-/Transporteurstamm „Portal-Hauptzugang“ öffnen. Anmeldename ändern, ersten Zugang mit neuem Passwort aktivieren, Passwort wechseln, Zugang nach Eingabe des bisherigen Namens sperren und bestehende 2FA-Verknüpfung zurücksetzen. Beim Sperren werden nur Login/Passwörter geleert; Kontakt-, Rechnungs- und Zuordnungsdaten bleiben erhalten. Vorhandene 2FA bleibt bei Passwortwechsel und Sperre erhalten.
- **Schutz:** Eigene ursprüngliche Niederlassung, live neu gelesene und mit der Sitzung geschnittene Kunden-/Transporteurrechte (0/1), eindeutige Zuordnung von Kontotyp, Hauptmitarbeiter und Hauptkostenstelle. Für 2FA zusätzlich Recht 43 bzw. eigener Niederlassungsadministrator sowie dessen aktuelles Passwort. Passwort 8–128 Zeichen mit Buchstabe/Ziffer, global eindeutiger Anmeldename (höchstens 20 Zeichen). Keine Passwörter oder TOTP-Secrets in Antworten, Audit, Belegen oder `toString` der Anfragen.
- **Speichern:** Gemeinsame Tabellenlocks gegen parallele PHP-Änderungen, aktueller Revisionsabgleich und atomarer Passwort-/Audit-/Belegabschluss. Wiederholung nach verlorener Bestätigung ohne zweite Änderung; Passwortwiederholung prüft den tatsächlich gespeicherten Hash. Beide Schreibziele brauchen InnoDB. Passwortwechsel löscht den alten Legacy-Hash. Änderung von Login/Passwort oder 2FA dreht den vorhandenen TOTP-Sitzungsschlüssel. Dies ist keine Zusage, sämtliche alten PHP-Sitzungen ohne 2FA sofort abzumelden.
- **Bewusste Abweichung:** Das alte Kurierpasswort wird von PHP als schwaches `test` plus vier Ziffern erzeugt und angezeigt. NG verwendet stattdessen ein ausdrücklich eingegebenes neues Passwort und gibt es nicht zurück. Der Zugang wird weiterhin für das bestehende PHP-Portal verwaltet; NG selbst meldet weiterhin ausschließlich Zentralenbenutzer an.
- **Weiter offen:** Zusätzliche Kundenmitarbeiter, ihre Rechte und Kostenstellenmatrix, Portalansichten in NG, externe Konten-Metaobjekte. Die im aktuellen PHP referenzierte Tabelle `employeecostcenter` ist in der verbundenen Datenbank nicht vorhanden. Eine entsprechende Schema-Vorbereitung gehört zum folgenden Matrix-Baustein. Hauptzugänge benötigen diese Tabelle nicht.


## 17. Oktober 2026 – Mitarbeiter-Lagerrechte

- **Referenz:** ausschließlich frischer SSH-Arbeitsbaum `2eb7f98`, `admin/employee.php` (SHA-256 `4c90cdf4e63b0861dc7780cb6fd3184f8c3b21667ba90a6e6c706c8a75037bce`), `include/inc_stock.inc.php` (`c4528b331909c57843f7eee01acaa25987854b0002bcbeaa653f6dd2abf4ce5e`) und `stock/stock.php` (`5b4e3ad6eab8e29f5837f76fb4ab6e94de09b48ab17f13e2ae6561b5758581e6`). Aktuelle PHP-Oberfläche über Verwaltung → Niederlassungen → Mitarbeiter und Mitarbeiterpopup geöffnet: Hauptlager-Checkboxen, Unterlagerauswahl mit +/- sowie beide Ja/Nein-Schalter geprüft. Keine PHP-Speicherung.
- **Native Verwaltung:** Mitarbeiterliste → Lagerrechte. Hauptlagerzugang, Unterlager einschließlich Nachfolger, Einschränkung aufheben, Lesemodus und Artikelverwaltungsflag. Suchfilter für Hauptlager; vollständige Pfade unterscheiden gleichnamige Unterlager. Anzeige umfasst Lager des eigenen Mandanten unabhängig vom Mitarbeiterlisten-Niederlassungsfilter. Bestehende nicht änderbare und fremde Zuordnungen bleiben erhalten.
- **Delegation:** Mitarbeiterrecht 3 und live geprüfte Konten-/Niederlassungszuordnung. Eigene Rechte und Administratorkonten geschützt. Außerhalb eigener Hauptlagerfreigaben keine Änderung; eingeschränkte Bearbeiter dürfen nur abgedeckte Unterlager weitergeben und keine uneingeschränkte Freigabe erzeugen. Bereits weiter gefasste Zielrechte dürfen sie nicht überschreiben. Schreibrechte dürfen nur nicht lesebeschränkte Bearbeiter mit Lagerrecht 14 bzw. der eigene Administrator umschalten; Artikelverwaltung nur mit Lagerrecht 14 bzw. als Administrator. Das invertierte PHP-Kriterium für die Artikeldelegation wird bewusst nicht übernommen. Artikelstammpflege selbst bleibt ein separater offener Bereich; die Flagge ist PHP-kompatibel gespeichert und schränkt die Artikelauswahl in Aufträgen nicht ein.
- **Parameter:** `MASK_STK_ROOT_ACCESS`, `MASK_STK_SUBSTOCK_ACCESS`, `MASK_STK_READONLY_WHERE_DEFINED_WRITEACCESS`, `MASK_STK_ARTICLE_ACCESS`; nur aktuelle Niederlassung/Zielmitarbeiter geschrieben. PHP-kompatibler Rückfall nicht gesetzter Werte auf die Heimatniederlassung. Explizite Sperre `0` verhindert Wiederaufleben einer Heimatfreigabe; explizite `root,root`-Freigabe hebt Unterlagereinschränkungen auch bei vorhandenen Heimatvorgaben auf. `|` und `--` werden gelesen. Doppelte, ungültige und falsch mandantenzugeordnete Parameter werden abgewiesen; Beschreibungen bleiben erhalten.
- **Speicherung:** kurze PHP-kompatible Tabellenlocks auf Personen, Rechtekontext, Lagerhierarchie, Parameter und Audit/Beleg. Revision umfasst auch Bearbeiterrechte, Zielkonto, Lagerbaum und Parameter; keine veralteten Änderungen. Parameter/Audit/Wiederholungsbeleg in einer Transaktion, InnoDB erforderlich. Fehler rollen alles zurück; Wiederholung derselben Vorgangskennung erzeugt keinen zweiten Vorgang. Mitarbeiterhistorie stellt Vorher/Nachher verständlich dar. Keine Schemaänderung.
- **Lagerbuchungen:** Hauptlagerzugang, Unterlager und beide Leseschalter jetzt serverseitig bei Auswahl/Vorschau und erneut bei gesperrter Buchungsprüfung berücksichtigt. Administratorausnahme für Lagerauswahl, jedoch kein Umgehen von Leseschutz, Kundenbezug, sichtbaren/schreibbaren Lagerorten oder Niederlassungsbindung. Fehlender Hauptlagerzugang bedeutet keinen Zugang. Lesebeschränkungen werden bewusst auch serverseitig erzwungen, statt nur die PHP-Anzeige zu verändern. Suche blättert intern weiter, bevor sie auf 50 zugängliche Treffer begrenzt; kein Verlust freigegebener Lager hinter den ersten 200 Treffern.
- **Prüfung:** isolierte SQL-/Browsertests für Delegation, Unterlager, Fremdmandant, geschützte Konten, Konflikt/Retry, Rollback, MyISAM-Abweisung und Niederlassungsrückfall. Echter Bestand nur gelesen: 17 Mitarbeiterviews, 14 Hauptläger, keine fehlerhaften Parameter in dieser Stichprobe. Nachweise in `docs/PRUEFSTATUS.md`. Kundenportal-Kostenstellenmatrix, Sprache, CC24 und vollständige Lagerverwaltung bleiben separat offen.

## 17. Oktober 2026 – automatische Angebotsrunden

Verbindliche Referenz erneut direkt per SSH gelesen: Arbeitsbaum `2eb7f98`, `include/autoranking_single.php` (SHA256 `b7e49f0fcfaaf54eb7118d67479c376299b2fbf70610c226cff31b583b704d4b`), `include/inc_autoranking.inc.php` (`7097d6237436df27e84c84b062cbcd87f89fe40e4ade1ee4b41645c5245e8c24`), `include/ranking.inc.php` (`1392991c91526072919097b96033079da880d4d759acbe1c43f858914c4d5c25`) und `include/global.inc.php` (`ceb60bd61a1ae01729c151b78586ab8c5df301cb595e34eae8fbd923f71bcdd9`). Echte PHP-Auftragsliste erneut geprüft: Autoranking im gewählten Zeitraum leer. Der neue Ablauf ersetzt Hintergrundlogik; kein behaupteter visueller Nachweis eines befüllten PHP-Popups.

- **Nativer Angebotslauf:** alle 15 Sekunden, bis zu 40 Aufträge nach Auftragszeit/ID. Nur Status 8 und aktivierte Dispositionsniederlassungen. Cursor läuft über blockierte Seiten hinweg. Eigene Transaktion je Runde, danach erneutes Lesen für den nächsten konfigurierten Versuch. Reservierungen warten auf Auftragszeit minus Anfahrtszeit (mindestens 30 Minuten); potenzielle globale Angebote warten nicht. Fehlende/mehrdeutige Anfahrtszeit blockiert sichtbar.
- **Reihenfolge:** fester Reservierungs-/Dauerkurier ausschließlich; sonst Stationsfavoriten und anschließend Rechnungskundenfavoriten jeweils nach Freimeldezeit. Danach Hauptbereich und gerichtete Nachbarschaften. Modus 1 PLZ, Modus 2 alle Bereichsnachbarn als gemeinsame Gruppe, Modus 3 einzelne Ebenen bis zur konfigurierten Tiefe. Keine Runde mit anderweitigen Restkurieren. „Nur Anforderungen“, `jb_ignore_fav_only`, Stations-/Zahler-/Barzahlerbeziehungen und rückwärts gerichtete Gebietsprüfung für beschränkte Favoriten werden berücksichtigt. Die PHP-Zahlerpriorität bei der Nur-Favoriten-Regel bleibt erhalten.
- **Eignung:** Verfügbarkeit, Fahrer-/Fahrzeugbindung und Mehrfachfahrerparameter, kundenseitige Sperren, angemeldete Fahrzeugklasse, LKW-Ausnahmen, Auslagen, Maße/Zuladung, fahrzeug-/fahrerbezogene Pflichtfilter und Favoritenausnahmen, Nationalität, EG-Lizenz sowie Quarantäne einschließlich Kunden-/Branchengruppen. Zeitliche Belegung verwendet alle aktiven Tage, auch überlappende künftige Aufträge. Versuchslimit und vorhandene automatische Angebotssperre schließen weitere Angebote aus. Die in PHP auskommentierte GPS-Prüfung bleibt deaktiviert; Ortungsstatus wird nur als Historienmerkmal gespeichert, einschließlich der gesamten Endminute des konfigurierten Fensters.
- **Schreiben:** Kuriersemaphore, angebotener Auftrag (Status 0), Kennung, `jb_autoranking`, erhöhte Version, Versuchszähler/Zeit/Rangverlust und Protokoll 6 plus NG-Nachweis gemeinsam atomar. Keine zusätzliche PDA-Nachricht: auch PHP veröffentlicht neue automatische Angebote durch die Auftragsbindung für den bestehenden Geräteabruf. Ohne Treffer nach allen Runden Status 9; fest konfigurierte Kennung kann erhalten bleiben. Potenzielle globale Angebote werden stattdessen Status 0 / `jb_globaljob=1`. Freimeldezeit, Preise und Annahmezeit werden nicht verändert.
- **Schutz und bewusste Korrekturen:** keine Änderungen an stornierten, verrechneten/exportierten/gegengeschriebenen oder aktuell in PHP gesperrten Aufträgen. Eindeutiger aktiver Fahrer, sichtbares/nicht archiviertes Unternehmen und nicht gesperrter Zugang auch bei festen Kurieren/Favoriten. Mehrdeutige Rankinghistorie oder Konfiguration wird nicht geraten. Alle vier Schreibziele benötigen InnoDB; kurze Tabellenlocks schließen PHP-Schreiber während Auswahl und Speicherung aus. Stornierte aktive Aufträge belegen keinen Kurier. PLZ-Anfahrtszeiten werden ausdrücklich auf die zuständige Niederlassung begrenzt. Bei globalem Rückfall wird die tatsächlich vorhandene Spalte `jb_globaljob` verwendet; PHP schreibt dort irrtümlich `jb_global`. Der aus PHP gestartete Helfer `tools/get_job_duration.php` ist im aktuellen Serverbaum nicht vorhanden und wird nicht als funktionierende Abhängigkeit übernommen.
- **Oberfläche:** „Kurier zuweisen → Automatische / manuelle Vermittlung …“ zeigt die nächste geeignete Auswahl, Runden, Kandidaten, bisherige Angebote und Ausschlussgründe. Frühester Reservierungsbeginn, ausgeschalteter Dienst und separate Fehlerwiederholung. Rechte 4/7 und eigene Auftragsniederlassung. Diese Anzeige ist ausschließlich lesend.

**Betrieb und verbleibende Grenzen:** `AUTO_OFFER_WORKER_ENABLED=false` bleibt im Parallelbetrieb aus. Zur Ablösung den PHP-Angebotsblock abschalten, dann den NG-Angebotsdienst aktivieren. Die getrennte Rückruf-/Sperrbereinigung benötigt weiterhin entweder den PHP-Block oder `OFFER_REVOCATION_WORKER_ENABLED=true`. Geräteabruf, Auditverbraucher und produktive Betriebsumschaltung sind gesonderte Betriebs-/Restthemen. Der aktivierte Angebotslauf erneuert wie PHP nach jedem erfolgreichen Warteschlangenabruf den vorhandenen `keepalive`-Eintrag `autoranking`. Dieser einzelne, wiederholbare Zeitstempel auf MyISAM liegt außerhalb der atomaren Auftragsbuchung; andere Prozesse bleiben unverändert. Beide neuen Worker wurden schreibend nur in isolierter MariaDB geprüft. Weitere offene Menübereiche bleiben bestehen.


## 17. Oktober 2026 – zeitgesteuerte Angebotsrückrufe

Frischer SSH-Stand `2eb7f98`: `include/autoranking_main.php:81–169` (SHA256 `3e483c02cb8881963aaa5a0ea7a1769b6d3124b10320ff395032ed1d40d1b7c6`), `include/inc_autoranking.inc.php:347–490` (`7097d6237436df27e84c84b062cbcd87f89fe40e4ade1ee4b41645c5245e8c24`) und `include/dbglobal.inc.php::getParameterValue`. Dies ist ein Hintergrundablauf; die aktuelle PHP-Auftragsliste zeigt zum Prüfzeitpunkt keine offenen Angebote der geprüften Niederlassung. Die neue Fristanzeige ergänzt den bestehenden Vermittlungsdialog.

- Nativer Rückruflauf alle 15 Sekunden, getrennte Umläufe für automatische/manuelle Angebote. Verwendet `AUTORANKING_REVOCATION_ENABLED`, `AUTORANKING_REVOKE_JOB_MODE` sowie die jeweiligen Minuten-/Sekundenfristen der **Dispositionsniederlassung**, wie der PHP-Rückrufpfad ohne globalen Parameterfallback. Exakt auf der Frist noch kein Rückruf; erst danach. Kein Rückruf angenommener/erledigter/anderer Status, globaler Angebote, stornierter/verrechneter/exportierter oder aktuell in PHP bearbeiteter Aufträge.
- Automatisch angebotene Aufträge → Status 8 mit geleerten Kurierbindungen. Manuelle Angebote und Vorbestellungen/Daueraufträge mit festem Kurier → Status 9; die bisherige Kennung/Bindung bleibt wie in PHP zur Nachbearbeitung erhalten. `ar_looseranking=1` setzt die Freimeldezeit auf den Rückrufzeitpunkt, `0` erhält sie. Versuchszähler und Rankinghistorie bleiben unverändert. PDA-Befehl 4/Modus 1 nach 30 Sekunden, Protokoll 8, NG-Nachweis und Version werden gemeinsam gespeichert; Belegtstatus wird aus aktiven, nicht stornierten Einzelaufträgen ermittelt.
- Vermittlungssperre `cr_ar_jb_id` wird beim Rückruf nur freigegeben, wenn sie noch zu diesem Auftrag gehört. Der zusätzliche Bereinigungslauf entfernt verwaiste oder durch Annahme/Neuzuordnung überholte Sperren, erhält aber eine passende laufende Angebotsbindung.
- Bewusste Korrekturen: Rückruffrist und Empfänger stammen ausschließlich aus dem Rankingnachweis des **aktuell angebotenen** Kuriers. Der alte PHP-Code wählt trotz Kommentar den jüngsten Eintrag über sämtliche Fahrer und kann einen anderen Empfänger treffen. Mehrdeutige/fehlende Nachweise, widersprüchliche Fahrerbindung und ungültige/unvollständige Fristen werden sichtbar blockiert. Tabellenlocks sichern den frisch gelesenen Auftrag, Rankingnachweis und Parameter gegen PHP-Schreiber; alle tatsächlichen Schreibziele benötigen InnoDB. Die Rankinghistorie darf als ausschließlich gelesene Tabelle MyISAM bleiben. Cursor verhindern, dass eine volle Seite fehlerhafter Datensätze spätere Aufträge dauerhaft blockiert.
- Neuer lesender Fristabruf im Vermittlungsdialog mit Angebotszeit, Annahmefrist, Folgestatus, Kennungserhalt und Rangverlust. Ladefehler separat wiederholbar; Aktualisieren liest den aktuellen Stand erneut. Rechte 4/7 und eigene Auftragsniederlassung bleiben erforderlich. Browser führt für diese Anzeige keine Schreibaktionen aus.

**Betrieb:** `OFFER_REVOCATION_WORKER_ENABLED=false` ist Standard und bleibt im aktuellen Parallelbetrieb aus. Erst nach Abschalten des Rückruf-/Sperrbereinigungsblocks des alten PHP-Dienstes aktivieren; der noch benötigte PHP-Angebotslauf bleibt bis zu seiner Ablösung erhalten. Der neue Worker wurde ausschließlich in isolierter MariaDB ausgeführt. Die Kandidaten-/Favoriten-/Nachbarschaftsrunden, Versuchslimits und Neuangebote wurden anschließend ergänzt (siehe aktuellen Abschnitt oben). Die zeitgesteuerte Rücknahme ist damit implementiert; vollständiger Ersatz des Vermittlungsdienstes und übrige Menübereiche bleiben offen.


## 17. Oktober 2026 – Einzelauftrag in automatische/manuelle Vermittlung stellen

Referenz: frischer SSH-Arbeitsbaum `2eb7f98` unter `/data/0/votian-test/html`. `admin/push_autoranking.php` (SHA256 `258cd9a240c233a121f19995173514cb9685f4ecd9a67a45124c834164099c4a`), `admin/push_manual.php` (`7eb2cd57da36bf56edf39e719732f80eaa88565d1e3178fb9e062f9e93dc44d8`), aktueller Popupgenerator `jobs/job_courier.inc.php:570–635` und `include/lib_courier.6.1.js:710–717`. PHP-Auftragsliste erneut gelesen; der gewählte Autoranking-Zeitraum ist leer. Die Aktionen/Checkbox sind über den aktuellen Generator geprüft, kein neuer visueller Nachweis eines befüllten alten Popups.

- Gemeinsamer Einstieg „Automatische / manuelle Vermittlung …“ in der CLASSIC-/BWV-/manuellen Kurierauswahl, dadurch aus Auftragslisten und Auftragsbearbeitung erreichbar. Lesender Ausgangsstand, explizite Vorschau und Bestätigung. Abbrechen erhält die bisherige Fahrzeugauswahl; Erfolg verwirft ihre alte Zuweisungsvorschau und lädt den aktuellen Stand.
- Automatische Vermittlung: Status 0/8/9 → 8; angenommene Aufträge zuerst manuell zurücknehmen; BWV-Aufträge wie im PHP-Popup ausgeschlossen. Manuelle Vermittlung: Status 0/1/8/9 → 9. Beide leeren Kurier-/Angebots-ID und Kennung, setzen „An alle“ zurück und erhöhen die NG-Version. Erledigte, stornierte, exportierte, verrechnete/gegengeschriebene oder in PHP gesperrte Aufträge bleiben geschützt.
- „Nur Anforderungen“ erscheint beim entsprechenden Rechnungskunden, einschließlich Barzahler-Auflösung. Automatisch werden bisherige `jb_ignore_fav_only`-Zeilen entfernt und bei aktivierter Ausnahme durch eine eindeutige Markierung ersetzt. Manuell bleibt die Ausnahme unverändert. Der bestehende PHP-Worker überspringt mit dieser Markierung auch die bevorzugte Favoritenrunde; die Vorschau erklärt diese Wirkung. Deaktivierte automatische Vermittlung wird angezeigt, das Einreihen bleibt wie in PHP möglich.
- Vorherige unterschiedliche Kurier-IDs erhalten jeweils einen PDA-Rückruf (Befehl 4, Modus 1, Auftrag, Ausführung nach 30 Sekunden, PHP-Gültigkeitsgrenze zehn Jahre). Belegtstatus wird aus verbleibenden aktiven Aufträgen berechnet. Freimeldung und Freimeldezeit, Preise, Annahmezeit, `jb_autoranking` und Rankinghistorie bleiben erhalten. Bewusste Korrektur: Auch automatische Rücknahme erzeugt die benötigten Geräterückrufe; der alte `push_autoranking.php`-Pfad lässt sie aus.
- Rechte 4 und 7, eigene Auftragsniederlassung, Session/CSRF, Revision einschließlich Rechnungskunde/Parameter/Ausnahmemarkern, identische Wiederholungsbelege. Kurze Tabellenlocks serialisieren mit PHP-Schreibern; InnoDB ist für alle tatsächlich beschriebenen Tabellen erforderlich. Status, Markierung, Protokoll und PDA-Rückrufe werden gemeinsam zurückgerollt. Keine Bestandsänderungen durch Vorschau.

Geprüft: 840 Tests / 837 bestanden / drei optionale Live-Tests übersprungen; SQL-Parallelaufruf, spätes Rollback, Schutzregeln, Browsererfolg, identischer Retry und Konflikt. Reale Datenbank nur gelesen. Angebotsworker und zeitgesteuerte Rückrufe wurden anschließend ergänzt; die Betriebsumschaltung bleibt separat (siehe oben). Übrige offene Menübereiche bleiben bestehen.


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

Aktueller SSH-Arbeitsbaum `2eb7f98`, `jobs/job_courier.inc.php:675–715,869–978` (SHA256 `1ebad0f90ed0687eb981f1edfe257f569661292764ee7eb0f56ea6239b294525`). Echte PHP-Auftragsliste erneut gelesen; der gewählte Autoranking-Zeitraum ist leer. Der Popupgenerator ist frisch geprüft. Das alte BWV-Popup wurde wegen seiner Schreibeffekte auf echte Aufträge nicht geöffnet; ein vollständiger visueller Popup-Nachweis liegt nicht vor.

- CLASSIC, BWV und manuelle Fahrzeugauswahl bieten „Aufträge von … anzeigen“. Beim Öffnen werden aktuelle Aufträge derselben Fahrzeugkennung mit Status 0/1 gelesen. Anzeige mit Nummer, Auftragszeit, Angebot/Annahme, BWV-Kennung, Niederlassung und Stationsfolge. Erledigte Stationen sind rot und ausdrücklich als erledigt bezeichnet.
- Belegt-/Vorlauffenster verwenden dieselbe SQL-Bedingung wie die Ranglistenberechnung. Künftige Aufträge bleiben sichtbar. Stornierte und erledigte Aufträge sowie der gerade zuzuweisende Auftrag sind ausgeschlossen. Eine fehlende erste Adresse wird wie bei der Belegt-Ermittlung nicht als gültige Tour ausgegeben.
- Vollständige Liste mit 20 Aufträgen pro Seite, serverseitiger Gesamtzahl und expliziter Aktualisierung. Doppelte PLZ-/Vorlaufzuordnungen duplizieren weder Zähler noch Zeilen. Stationsfolge wird separat und in gespeicherter Reihenfolge gelesen; keine kundenspezifischen Fremdauftragsdaten in der Kurzübersicht.
- Aufträge der eigenen Niederlassung öffnen native Lesedetails mit Anschriften, Kontakt, Stationsbemerkungen und Abschlussdaten. Schließen kehrt zur unveränderten Kurierauswahl zurück. Fremde Aufträge zeigen die PHP-kompatible Dispositionsübersicht mit PLZ-Folge; vollständige Fremdniederlassungsdetails/-bearbeitung bleiben ein eigener offener Bereich.
- Alle Abrufe benötigen Auftragslese- und Dispositionsrecht, einen Auftrag der eigenen Niederlassung und die aktuell gebundene Fahrer-/Fahrzeugkombination. Fremde CLASSIC-Fahrzeuge müssen weiterhin in der aktuellen Vermittlung sichtbar sein. BWV erlaubt die bereits freigegebene bundesweite Fahrzeugauswahl. Änderungen an Anmeldung oder Freigabe werden beim Abruf erneut geprüft. Keine Datenbank- oder Geräteänderungen durch Anzeige/Aktualisierung.

**Korrektur der bisherigen Neukurier-Restposition:** `jobs/job_courier.inc.newbies.php` (SHA256 `d2e2ed63df924870e82771630a967f1dfac862b34a2958b1853acb489cb6e17d`) enthält aktuell 3.888 Zuordnungen, ausschließlich mit Wert 1. Der aktive UI-Zweig in `job_courier.inc.php:1033–1034` färbt nur vorhandene Einträge mit Wert ungleich 1; der frühere datumsbezogene Algorithmus ist auskommentiert. Im verbindlichen aktuellen PHP-Stand wird daher kein Neukurier markiert. Die bisherige Aussage einer fehlenden aktiven Sondermarkierung war zu weitgehend; es wird keine künstliche ID-Liste oder abweichende Neulingsregel eingeführt. Frühere Angebot-/Rückrufhinweise bleiben vorhanden.

Weiter offen: eigenständiger Vermittlungsworker (Einzelaktion und „Nur Anforderungen“-Übersteuerung inzwischen ergänzt, siehe oben), allgemeine Fremdniederlassungs-/Archivansichten und die übrigen Menübereiche.

## 17. Oktober 2026 – wechselnde Fahrer und Fahrzeughalter

Referenz erneut vom aktuellen SSH-Arbeitsbaum `/data/0/votian-test/html`, HEAD `2eb7f98`: `include/ranking.inc.php:86–88,355–389,864–886` (SHA256 `1392991c91526072919097b96033079da880d4d759acbe1c43f858914c4d5c25`), `jobs/job_courier.inc.php:782–795` (`1ebad0f90ed0687eb981f1edfe257f569661292764ee7eb0f56ea6239b294525`) und `include/lib_courier.6.1.js` (`8b5df3023c6686fac3d780ffe8bb2f3d2f700df347e771c7e5d3553cb22b1640`). Die echte PHP-Transporteuransicht mit SID, Name, Vorname und Fahrzeugfeldern wurde geöffnet. Keine reale Anmeldung oder Kurierzuweisung ausgeführt. Popupbindung ist anhand des aktuellen PHP/JS-Generators belegt; kein vollständiger visueller Popup-Nachweis.

- `RANKING_CR2CRVH_MULTI_RELATION=1` löst Fahrer und Fahrzeug über die aktuelle Anmeldung `courier.cr_sid=couriervehicle.crvh_sid` auf. Niederlassungseinstellung hat Vorrang vor globalem Wert; ohne Aktivierung bleibt die Eigentümerzuordnung. Fahrzeughalter wird ausdrücklich getrennt vom ausgewählten Fahrer geführt, ohne die Fahrzeugstammdaten umzuschreiben.
- CLASSIC- und BWV-Kandidaten sowie manuelle Liste zeigen den angemeldeten Fahrernamen und einen Hinweis bei abweichendem Halter. Textsuche berücksichtigt den Fahrernamen. Offline-Zuweisung an den Halter bleibt möglich, wenn auf dem Fahrzeug niemand angemeldet ist. Eine vorhandene gesperrte Anmeldung wird nicht durch den Offline-Halter ersetzt. Mehrere gleichzeitig angemeldete Fahrer sperren die Auswahl sichtbar.
- Normale Aufträge öffnen auch aus der Auftragsbearbeitung denselben Zuweisungsdialog wie die Listen; der frühere separate einfache Fahrzeugwähler entfällt. Ungespeicherte Auftrags-/Preis-/Rechnungsänderungen sperren den Einstieg weiterhin.
- Vorschau und Speicherauftrag enthalten zusätzlich die konkrete Fahrer-ID. Wechsel nach der Auswahl/Vorschau, veränderte Aktivierung oder doppelte Anmeldung verlangen eine neue Prüfung. Ältere Aufrufe ohne Fahrerbindung dürfen nicht stillschweigend einen anderen Fahrer als den Halter zuweisen. Die allgemeine Statusaktion kann diese Prüfung nicht umgehen.
- Kundensperren, Favoriten, Fahrerfilter, Staatsangehörigkeit, Niederlassung, Anmeldeposition und Freimeldezeit stammen vom tatsächlichen Fahrer; Fahrzeugmaße/-filter stammen weiterhin vom ausgewählten Fahrzeug. Die Mindestklasse in CLASSIC/BWV wird wie PHP anhand der aktuellen Fahrzeugklassen-Anmeldung des Fahrers geprüft. BWV-Routenstart, Heimatort und Zeitfenster werden mit demselben Fahrer aufgelöst. Karten-Zuweisung nutzt ebenfalls diese Bindung, bei weiterhin eigener Niederlassung.
- Speicherung setzt Angebot/Annahme, Autoranking, Belegtstatus und Protokoll auf den ausgewählten Fahrer; Fahrzeughalter und Auftragshoheit bleiben erhalten. Fahrer-ID gehört zur wiederholbaren Vorgangsabsicht. Ein bereits erfolgreicher Vorgang bleibt nach späterer Abmeldung abrufbar; dieselbe Vorgangskennung mit anderer Fahrer-ID wird zurückgewiesen. Späte Fehler rollen die Zuweisung gemeinsam zurück.
- Die vorhandenen Sichtbarkeits-/Freigabe-/App-Sperren und CLASSIC-Fremdniederlassungsregeln gelten unverändert. Anmeldung/Abmeldung selbst wird weiter über die vorhandenen Geräte-/Fahrerabläufe vorgenommen; diese Erweiterung setzt keine echten Anmeldungen und aktiviert keine Hintergrundvermittlung.

Der frische Listenpfad `admin/jb_list.php:504–524` (SHA256 `db040a7b070773da74dfbbdf3e46f3ecc55564f516f34f81dd880826221e80fc`) bestätigt die Fahrerauflösung vor dem Offline-Halter. Bei doppelter Anmeldung nimmt PHP den ersten Zeitwert; NG verlangt eine eindeutige Anmeldung.

Abgegrenzter Erfassungsablauf: `jobs/job_options.php:374–448` löst die direkte Fahrzeugvorgabe bei Neuanlage und Nacherfassung ausdrücklich über den Fahrzeughalter auf; dieses bestehende Verhalten wird durch die Vermittlungserweiterung nicht umgestellt.

Weiter offen in der Vermittlung: der eigenständige Vermittlungsworker (Einzelaktion und „Nur Anforderungen“-Übersteuerung inzwischen ergänzt, siehe oben). Die übrigen dokumentierten Menübereiche bleiben ebenfalls offen.

## 17. Oktober 2026 – CLASSIC-Kandidatenrangliste

Frischer SSH-Arbeitsstand `/data/0/votian-test/html`, HEAD `2eb7f98`. `include/ranking.inc.php` (SHA256 `1392991c91526072919097b96033079da880d4d759acbe1c43f858914c4d5c25`), `jobs/job_courier.inc.php` (`1ebad0f90ed0687eb981f1edfe257f569661292764ee7eb0f56ea6239b294525`), `jobs/job_courier.inc.lib.php` (`3b803fc8f8a319df018af656ccb51f43a49c62a9e0cd2a5d19b07ebdc76f3bed`) und `include/global.inc.php::checkCrIsOccupied` (`ceb60bd61a1ae01729c151b78586ab8c5df301cb595e34eae8fbd923f71bcdd9`). Echte PHP-Auftragsliste erneut gelesen; der aktuelle Autoranking-Zeitraum enthielt keine Aufträge. Gruppen/Regeln sind über den aktuellen Popupgenerator geprüft; kein vollständiger visueller Popup-Nachweis.

- Normale Aufträge öffnen jetzt die CLASSIC-Rangliste: bevorzugte Kuriere, Haupt-PLZ/-Bereich, gerichtete Nachbarschaften, weitere verfügbare Kuriere und sichtbare gesperrte/ungeeignete Treffer. Anzeige von Kennung, Fahrzeug, Transporteur, Niederlassung, Freimelde-PLZ/-zeit, Gruppenbegründung, bestehenden Angeboten/Rückrufen und Sperrgründen. Text-, Gruppen-, Favoriten- und Belegungsfilter; 50 Zeilen pro Seite. Manuelle Fahrzeugliste einschließlich Offline-Fahrzeugen bleibt erreichbar.
- Modus 1 verwendet die Abhol-PLZ und deren `serviceplzneighbour`. Modus 2 verwendet den Hauptbereich und `serviceplzareaneighbour`; Modus 3 verwendet die geordneten PLZ-bezogenen `serviceplzneighbourarea`. Konfigurierte Nachbarschaftstiefe, lokaler Modus mit HQ-Fallback und klare Warnung bei fehlender Zuordnung. Mehrdeutige PLZ-/Hauptbereichsdaten werden abgewiesen. Die PHP-Wiederholung sämtlicher Modus-2-Nachbarn je Stufe wird durch einmalige Zuordnung in konfigurierter Reihenfolge ersetzt.
- Reihenfolge innerhalb einer Gruppe wie PHP nach PLZ bzw. Bereichsname, dann Freimeldezeit; Kennung als stabiler Gleichstand. Optional freie vor belegten Kurieren, Favoriten innerhalb dieser Gruppen. Belegung wird aus anderen offenen/angenommenen Aufträgen desselben Fahrzeugs und dem heutigen Vorlauffenster berechnet, einschließlich Vergleich mit dem Zeitpunkt des zuzuweisenden Auftrags. Künftige Aufträge werden gezählt, machen den Kurier außerhalb dieses Fensters aber nicht belegt. Stornierte Aufträge zählen nicht. Ein abweichendes altes Belegt-Merkmal erscheint als Hinweis. Dieselbe aus Aufträgen berechnete Belegung gilt jetzt auch für die BWV-Kandidaten und deren Sortierung; das alte `cr_occupied`-Merkmal entscheidet dort nicht mehr allein.
- Favoriten-/Sperrbezüge, Filtertypen und Favoritenausnahmen, Fahrzeugklasse der Anmeldung, Auslagenlimit, Maße, Länderfreigaben und EG-Lizenzhinweis. `RANKING_USE_CRVH_RESTRICTION` steuert die zusätzliche Klasse-/Auslagen-/Maßprüfung der übrigen verfügbaren Kuriere. Nicht verfügbar gemeldete Kuriere erscheinen nur als explizite gesperrte Kundenbeziehung, nicht als Vorschlag. In der manuellen Auswahl bleiben die vorhandenen Warn-/Freigaberegeln erhalten.
- Wie PHP können Favoriten und passende Bereichs-/Nachbarschaftskuriere aus anderen Niederlassungen stammen. Ihre Zuweisung wird anhand der aktuellen Anmeldung, Position, Gebietszuordnung und Kundenvorgaben geprüft; Änderung zwischen Vorschau und Speicherung wird abgewiesen. Die allgemeine Statusaktion kann diese Freigabe nicht umgehen. Andere fremde Fahrzeuge bleiben gesperrt; Auftragshoheit bleibt bei der bisherigen Niederlassung. Die eigene manuelle Fahrzeugliste wird nicht global erweitert.
- Die gemeinsame Prüfung des Rankingverlusts unterscheidet nun Modus 2 und 3 korrekt. Modus 2 liest gerichtete Bereichsnachbarschaften; Modus 3 PLZ-Nachbarschaftsbereiche. Keine ungerichtete oder transitive Ausweitung.
- Such-/Ranglistenabruf bleibt vollständig lesend. Speicherung nutzt den bestehenden atomaren Zuweisungsablauf mit unveränderter Frachtvergütung für CLASSIC und wiederholbarer Vorgangskennung.

Wechselnde Fahrer/Fahrzeuge wurden anschließend ergänzt (siehe oben). Weiter offen in diesem Bereich: der eigenständige Vermittlungsworker (Einzelaktion und „Nur Anforderungen“-Übersteuerung inzwischen ergänzt, siehe oben). Karten-Sonderansichten und allgemeine fremde/archivierte Auftragsbearbeitung sind ebenfalls nicht durch diese Rangliste abgeschlossen. Die weiteren offenen Menüs bleiben bestehen.

## 17. Oktober 2026 – bundesweite BWV-Kandidaten und Vergütungsvergleich

Referenz ausschließlich frisch per SSH aus `/data/0/votian-test/html`, HEAD `2eb7f98`: `include/ranking.inc.php` (SHA256 `1392991c91526072919097b96033079da880d4d759acbe1c43f858914c4d5c25`), `jobs/job_courier.inc.lib.php` (`3b803fc8f8a319df018af656ccb51f43a49c62a9e0cd2a5d19b07ebdc76f3bed`), `jobs/job_courier.inc.php` (`1ebad0f90ed0687eb981f1edfe257f569661292764ee7eb0f56ea6239b294525`) und `include/lib_courier.6.1.js`. Die echte PHP-Auftragsliste wurde erneut gelesen. Der BWV-Popupgenerator schreibt beim Öffnen Koordinaten/temporäre Preise; deshalb erfolgt dieser Teil des Abgleichs über aktuellen Quellcode, ohne einen echten Auftrag zu verändern. Kein vollständiger visueller Nachweis des alten Popup-Dialogs.

- Neue Standardansicht im BWV-Zuweisungsdialog: bundesweite angemeldete Fahrzeuge, Echtzeit/Vorbestellung, automatischer oder manueller Suchradius. Lokaler `RANKING_RADIUS_KM` mit globalem Fallback, Erweiterung bis zum ersten geeigneten Treffer bzw. zum PHP-Maximum. Explizite Validierung verhindert Endlosschleifen bei fehlerhaften Radiusparametern. Suche verwendet wie PHP `hypot(Breitendifferenz, Längendifferenz) × 111` mit strikter Radiusgrenze; Straßenkilometer gehören zur getrennten Vergütungsprüfung.
- Echtzeit vereinigt aktuelle Standorte bei der Abholung sowie Heimat-/Wunschstandorte beim Ziel. Vorbestellung vereinigt Verfügbarkeits- und Wunschstartorte bei der Abholung, jeweils mit eigenem gültigem Zeitfenster. Der PHP-Fehler beim Zusammenführen der Wunschorte und die falsche Zeitfensterzuordnung werden nicht übernommen. Fehlende Heimatkoordinaten werden über die PLZ aufgelöst; verbleibende Ausfälle werden ausdrücklich als mögliche fehlende Treffer angezeigt.
- Kundenfavoriten aus Rechnungskunden/Stationen gemäß Konfiguration erscheinen auch außerhalb des Radius. Auslagenlimit, Mindestfahrzeugklasse, Kundensperren, Maß-/Filterbedingungen und deren Favoritenausnahmen werden berücksichtigt. Frei-/Belegt-Gruppierung vor Favoriten, wenn `MASK_COURIER_SORT_BY_OCCUPIED=1`; sonst Favoriten zuerst, danach PLZ und Freimeldezeit. Sperrgründe, Warnungen, Niederlassung und bisherige Angebote/Rückrufe bleiben sichtbar.
- Gemeinsamer Vergütungsvergleich aller geeigneten Treffer mit höchstens zwei gleichzeitigen Vorschauen, Fortschritt und Abbruch. Fehler eines Kandidaten sperren nur diesen und lassen sich erneut prüfen. Sieben Sortierungen entsprechend den PHP-Spalten, auf-/absteigend, Text-/Favoritenfilter und 50 Zeilen pro Seite. Auswahl übernimmt den passenden BWV-Startmodus; die verbindliche Zuweisung verlangt anschließend eine eigene aktuelle Vorschau. Die manuelle Fahrzeugliste einschließlich Offline-Fahrzeugen bleibt erreichbar.
- BWV-Zuweisung erlaubt nun auch Fahrzeuge fremder Niederlassungen. Auftrag bleibt in seiner ursprünglichen Niederlassung, bestehende Rechte und Schreibschutzprüfungen bleiben wirksam. Normale Aufträge unterstützen inzwischen zusätzlich passende Fremdniederlassungs-Kandidaten über die CLASSIC-Rangliste; die allgemeine manuelle Auswahl bleibt begrenzt. Ein belegender Auftrag aus einer fremden Niederlassung kann den Routenstart liefern; mehrdeutige Belegungen werden weiterhin abgewiesen. Kundenvorgaben/Favoritenparameter sind Teil der Vorschauprüfung und Änderungen machen alte Vorschauen ungültig.
- Kandidatensuche und Preisvergleich schreiben keine temporären Preise, Koordinaten oder PDA-Nachrichten. Explizite Zuweisung bleibt atomar und wiederholbar; die Suche erkennt zwischenzeitlich geänderte Auftrags-/Kurierdaten.

Die CLASSIC-Kandidatenrangfolge wurde anschließend ergänzt (siehe oben). Angebots-/Rückrufworker inzwischen ergänzt. Verbleibend: Betriebsumschaltung und allgemeine Archiv-/Fremdniederlassungs-Auftragsansichten. Der hier abgeschlossene BWV-Vergleich ersetzt diese eigenständigen Bereiche nicht. Gesamter Menüabgleich bleibt aktiv.

## 17. Oktober 2026 – automatischer BWV-Retourenlauf

Referenz ausschließlich frisch per SSH aus `/data/0/votian-test/html`, HEAD `2eb7f98`: `jobs/check_jb_permanent.php:1465–1510` (SHA256 `d9c35f8e2a3a0c0f0fbaa4a09924cc756356251338807cd213ae707b68776ae3`), `include/dbglobal.inc.php::insertPDACommand` (`5977c0c1a9c25b8a6d28957cedeec117479fb4d0b7d70353040e30721a566b87`) und die Preisdetails aus `include/jb_detail_history.inc.php:1598–1603` (`e85f0d42456dd84773b4495653bbff02a1687ef1231401e15a45143f65d8aeff`). Die echte PHP-Auftragsliste wurde erneut gelesen. Ein Retouren-Bestätigungsdialog existiert in diesem Ablauf nicht; er läuft im Hintergrund. Das PHP-Detail-Label „Frachtvergütung bei BWV-Anschluss“ widerspricht der tatsächlichen Worker-Bedingung: übernommen wird **ohne** angenommenen Folgeauftrag. Die native Anzeige beschreibt deshalb ausdrücklich die ausgeführte Bedingung. Der vollständige alte Retouren-Detaildialog ist nicht visuell bestätigt.

- `LonghaulReturns` verarbeitet offene `jb_cr_price_retour`-Merkmale ab 60 Minuten nach Erledigung. Angenommene BWV-Aufträge desselben Kuriers werden wie PHP über alle Niederlassungen und ohne zusätzliche Datumsgrenze berücksichtigt. Bloße Angebote zählen nicht. Anders als PHP zählen stornierte Aufträge nicht als Anschluss; NULL-Stornoflag gilt als nicht storniert.
- Ohne Anschluss werden volle Vergütung und Basis übernommen, der vorhandene Service genau einmal ergänzt und `jb_cr_subprice` konsistent aktualisiert. Mit Anschluss bleiben die Preise unverändert. PHP-kompatible Abschlusskontexte `No follow-up|Zeit` bzw. `Follow-up: ID|Zeit` verhindern erneute Verarbeitung. Ein strukturierter `ng_bwv_return`-Beleg dokumentiert jede Entscheidung.
- Preisänderung, Marker, Preisdetail, Audit 192 und PDA-Befehl 7/Modus 1 bilden eine gemeinsame InnoDB-Transaktion. PDA-Ausführung nach 20 Sekunden; Ablauf späterer Wert aus jetzt +36 Stunden und Auftragszeit +36 Stunden. Jede Nachricht enthält nur ihren eigenen Auftrag; der PHP-Fehler mit fortgeschriebenem Nachrichtentext wird nicht übernommen. Es wird nur die bestehende PDA-Warteschlange befüllt; Geräteübertragung bleibt beim Gerätedienst.
- Mehrere Workerinstanzen serialisieren sich über Niederlassungs-/Auftrags-/Kuriersperren; ein bereits verbrauchter Marker wird nicht erneut gebucht. Ein Cursor arbeitet jeweils bis zu 50 Kandidaten ab, damit frühe fehlerhafte Datensätze spätere gültige Vorgänge nicht dauerhaft blockieren. Fehler werden im Laufstatus gezählt; offene Vorgänge bleiben wiederholbar.
- Storno, Export, Rechnung, Gegenbuchung, laufende Rechnungszuordnung, PHP-Bearbeitungssperre, ungültige Beträge und mehrdeutige Preis-/Retourengrundlagen sperren die Buchung sichtbar. Bei nativen Zuweisungen wird die gespeicherte Vergütung mit dem Zuweisungsbeleg verglichen; nachträgliche Preisänderungen werden nicht überschrieben. Manuelle Fixpreisberichtigung und Neukalkulation beenden offene Retourenmerkmale in derselben Transaktion.
- Auftragsbearbeitung zeigt Termin, bisherigen und vollständigen Betrag, Serviceanteil, Anschlussanzahl, Sperrgrund und Abschlussstatus. Fremde Auftragsnummern werden nicht an den Benutzer ausgegeben. Bei einer niedrigeren Gesamtvergütung erscheint ein ausdrücklicher Hinweis. BWV-Zuweisungen sind aus der Bearbeitung jetzt über den bestehenden Vergütungsdialog erreichbar; die gewöhnliche Statuszuweisung bleibt dafür gesperrt.
- **Betriebsumschaltung:** `BWV_RETOUR_WORKER_ENABLED=false` ist der Standard und bleibt in dieser Installation aus. Erst nach Stilllegung des entsprechenden PHP-Blocks darf der native Lauf mit `true` aktiviert werden. PHP besitzt keine kompatiblen Sperren; ein gleichzeitiger Betrieb beider Verbraucher ist nicht sicher. Es wurden keine Cronjobs oder Dienste am PHP-Server geändert und keine echten Retouren gebucht.

Kandidaten-/Radius-/Favoritenauswahl, gemeinsamer Preisvergleich und niederlassungsübergreifende BWV-Zuweisung wurden anschließend ergänzt (siehe oben). Angebots-/Rückrufworker inzwischen ergänzt. Weiter offen: übrige Vermittlungssonderfälle, Betriebsumschaltung und vollständige Geräte-/Abrechnungsprozesse. Der native Retourenlauf ist implementiert und isoliert getestet; die produktive Ablösung des PHP-Verbrauchers bleibt ein gesonderter Betriebsschritt.

## 17. Oktober 2026 – BWV-Vergütung bei direkter Kurierzuweisung

Referenz ausschließlich frisch per SSH aus `/data/0/votian-test/html`, HEAD `2eb7f98`: `jobs/job_courier.inc.php` (`1ebad0f90ed0687eb981f1edfe257f569661292764ee7eb0f56ea6239b294525`), `include/services_func.inc.php` (`4bd29ac9ef3b0cdb5194091c90c56740868e9d9b4c8fdfde4229f8720a6d7a10`), `locating/xServer.inc.php` (`db74afe6f4720fd7abb4749ef3842fb40441e9f98d82dba3686ab371b833b10c`), `jobs/job_options.php` (`bfc6d2a725092142d36dfb93dd8ea9ae71408961c8abe5f77f82ab1e87bd9e80`), `admin/jb_list.php` und `include/lib_courier.6.1.js`. Die echte PHP-Auftragsliste samt Ferntouren-/Niederlassungsfiltern wurde erneut gelesen. Der BWV-Popupaufruf schreibt bereits beim Öffnen Koordinaten und temporäre Preise; er wurde daher nicht auf echten Aufträgen ausgelöst. Seine Spalten und Aktionen sind anhand des aktuellen PHP/JS-Generators abgeglichen; kein vollständiger visueller Popup-Nachweis behauptet.

- Der Listen-Zuweisungsdialog unterstützt `jb_longhaul=1`; die bundesweite Fahrzeugauswahl wurde anschließend ergänzt (siehe oben). Bestehende Rechte, Fahrzeug-/Kundensperren, Status-/Export-/Rechnungsschutz, Rankingfolge, PDA-Rückruf und Bewertungsregeln bleiben wirksam. Karten-Zuweisung bleibt auf gewöhnliche Aufträge beschränkt. Die allgemeine Statusaktion kann die BWV-Preisprüfung nicht umgehen.
- Straßenroute vom aktuellen Kurierstandort bzw. dem Ziel eines belegenden laufenden Auftrags über alle Stationen zum Heimatort. Die Belegung berücksichtigt den heutigen Auftragstag und die PHP-Vorlaufbedingung. Mehrere gleichzeitig belegende Aufträge verlangen zunächst eine eindeutige Anschlussdisposition. Belegende Aufträge fremder Niederlassungen werden inzwischen als Routenstart berücksichtigt. Alternativ Verfügbarkeitsbeginn oder BWV-Wunschort; die jeweils eigene UTC-Zeitspanne wird einschließlich Datum in Berliner Zeit geprüft. Heimatkoordinaten werden verwendet; fehlen sie, wird wie PHP die Heimat-PLZ geokodiert. Keine Koordinatenänderung durch eine Vorschau.
- Google-Straßenkilometer entsprechend dem PHP-Distance-Matrix-Vertrag, lesender Zugriff auf vorhandenen `address_geo.distance`-Cache und kurzlebiger Prozesscache. Keine Luftlinien-/Nullpreis-Ersatzwerte bei Dienstfehlern. Externe Aufrufe erfolgen vor der Schreibtransaktion. Anfahrt, Fahrzeit, Rückfahrt und gerundete Rundkilometer sind sichtbar.
- Vergleich `Rund-km × historischer Kurier-km-Satz + BWV_TSZ` mit gespeicherter PZM-Vergütungsbasis plus historischem Kurierzuschlag. Bei Gleichstand gewinnt Rund-km. Preisbezug ist die bestellte Fahrzeugklasse und Dispositionsniederlassung; fehlender Kurier-km-Satz fällt auf Kundenpreis abzüglich globalem Frachtvergütungsabschlag zurück. Der in PHP zwar gelesene, aber aus der Formel auskommentierte Grundpreis wird nicht addiert. Die Tabelle zeigt beide Zuschläge unabhängig voneinander.
- `BWV_CR_PRICE_RETOUR=1` übernimmt zunächst `round(Anfahrt + Last-km) × Rund-km-Satz` mit dem Zuschlag der gewählten Vergleichsvariante. Der volle gewählte Betrag samt Basis wird PHP-kompatibel unter `jb_cr_price_retour` gespeichert. Dieser PHP-Sonderfall kann eine höhere Hinfahrtvergütung als Gesamtvergütung erzeugen; beide Werte und ein ausdrücklicher Hinweis werden angezeigt. Die automatische Retourenentscheidung/-buchung wurde anschließend ergänzt; siehe aktuellen Abschnitt oben.
- Neue Fernaufträge und deren Neukalkulation sichern vor dem Aufschub der Vergütung `jb_cr_subtotal_last_without_service` sowie den Kurier-Servicepreis. Fehlende/mehrdeutige Altgrundlagen verlangen eine Neukalkulation. Bereits disponierte Fernaufträge müssen davor zurückgerufen werden, damit ihre bestätigte Vergütung nicht durch den aufgeschobenen Betrag null ersetzt wird.
- Speicherung gemeinsam mit der Zuweisung: `jb_cr_price`, `jb_cr_subprice`, `jobprice` 10 und Zuschlag 1/9, Retourenmerkmal, strukturierter Berechnungsbeleg und austauschbarer `~~~`-Nachweis in der internen Bemerkung. Andere Notizen bleiben erhalten; Service wird einmal ohne weiteren Zuschlag ergänzt. Vorschau bindet Tarife, Standort, Zeitfenster, Auftrags-/Kurierdaten, Bewertungsregel und Streckenergebnis. Geänderte Werte werden abgewiesen. Wiederholung derselben Vorgangskennung benötigt keinen erneuten Routenaufruf und bucht nicht doppelt.
- Bewusste Korrekturen der PHP-Fehler: kein versehentlich geleerter Servicebetrag durch `if ($jb_cr_serviceprice = "")`; keine veralteten Anfahrtswerte aus dem vorherigen Schleifendurchlauf bei belegten Kurieren; eigene Zeitfenster für Verfügbarkeit und Wunschort; Vergleichspreise behalten ihren jeweiligen statt nachträglich den gewählten Zuschlag. Retourenformel und Auswahlregel bleiben unverändert.

Kandidaten-/Radius-/Favoritenauswahl, Preisvergleich und niederlassungsübergreifende BWV-Disposition wurden anschließend ergänzt. Weiter offen: Vermittlungssonderfälle und eigenständige Vermittlungs-/Geräteprozesse. Dieser Block ist die native Preisübernahme bei bewusster einzelner Zuweisung, kein Abschluss des Gesamtmenüabgleichs.

## 17. Oktober 2026 – Bewertungs-Trigger nach Kurierzuweisung

Aktueller SSH-Stand `2eb7f98`, `include/inc_job.inc.php::checkJobForSurvey` (SHA256 `0b660ceef70176f64314cf74809fa681eac06553c534473a4690d0edf941e0c6`) und direkte Kundengruppenprüfung aus `include/inc_group.inc.php` (SHA256 `cb11026ad6d29e2cec390d3b057b56357b56514d650dd28ce4a9bc5f4b48454b`). Die echte PHP-Ansicht Verwaltung → Bewertungen wurde geöffnet; alle neun Kriterien sind sichtbar.

- `OrderSurvey` wertet vorhandene Kategorie-15-Formulare bei einer Kurierzuweisung aus: Beginn/Ende einschließlich Grenzen, Auftragsniederlassung, Rechnungskunde bzw. unmittelbarer Metakunde, angenommener Transporteur, Fahrerkennung, bestellte Fahrzeugklasse, direkte Kundengruppe und Branche. Bedingungen innerhalb einer Regel gelten gemeinsam; eine passende Regel reicht. Die erste passende Formular-ID in aufsteigender Reihenfolge wird protokolliert.
- `JOB_SURVEY_TRIGGER_ENABLED` nutzt die Niederlassungseinstellung mit globalem Fallback. Bei deaktiviertem Trigger werden vorhandene Merkmale nicht verändert. Bei Aktivierung wird `jb_pda_survey` in derselben Transaktion wie die Zuweisung auf 1 oder 0 gesetzt und bei einem Treffer Protokoll 134 über die bestehende Outbox angelegt. Wiederholung derselben Vorgangskennung erzeugt keinen zweiten Eintrag. Kein zusätzlicher E-Mail-Versand.
- Direkte Listen-Vorschau zeigt das Ergebnis und bindet aktuelle Formulardaten und Kunden-/Kurierbezüge an die Revision. Änderungen zwischen Vorschau und Speicherung verlangen eine erneute Prüfung. Die gemeinsame Zuweisungslogik berücksichtigt den Trigger auch bei einer Zuweisung aus Karte/Auftragsbearbeitung.
- Bewusste Korrekturen gegenüber dem PHP-Code: Offene Datumsgrenzen bleiben offen, statt einen leeren Wert in `--` umzuwandeln. Die Branche wird über `customer.cmp_id` gelesen; PHP verwendet an dieser Stelle irrtümlich die Kunden-ID als Firmen-ID. Ungültige Datumswerte erfüllen keine Regel; widersprüchliche doppelte Formularbedingungen werden ausdrücklich abgewiesen.
- PHP-kompatible Besonderheiten: Transporteurbedingung prüft den angenommenen `cr_id`, nicht `cr_id_order`; ein Online-Angebot erfüllt daher noch keine transporteurspezifische Bedingung. Fahrzeugklasse bezieht sich auf `job.vht_id`, nicht die tatsächliche Fahrzeugklasse. Kundengruppen werden direkt und in der aktuellen Niederlassung geprüft.

Die reale Datenbank enthält beim Lesetest 44 Regelobjekte; der Trigger war dort deaktiviert. Die Konfiguration wurde nicht geändert. PDA-Anzeige, Antwortverarbeitung und Bewertungslink in Kunden-E-Mails verbleiben bei den Bestandsdiensten; der vollständige native Geräte-/Mail-Workflow ist damit nicht abgeschlossen.


## 16. Oktober 2026 – direkte Kurierzuweisung aus den Auftragslisten

Referenz erneut aus dem aktuellen SSH-Arbeitsbaum `/data/0/votian-test/html` gelesen, HEAD `2eb7f98`: `admin/jb_list.php` (`setCourier`, SHA256 `db040a7b070773da74dfbbdf3e46f3ecc55564f516f34f81dd880826221e80fc`), `include/jb_list_defineoutput.inc.php` (SHA256 `9c8087e29853641fca21fee5b76b0abbebad6231cb830e91a0c6f6bf3aab8a0a`), `include/lib_courier.6.1.js`. Aktuelle PHP-Erfassung und Auftragsliste geöffnet; die offene Liste enthielt im geprüften Bereich keine Zeilen, deshalb kein vollständiger visueller Nachweis des Popup-Ablaufs. Kein alter lokaler PHP-Stand verwendet.

- Klick auf Fahrerkennung bzw. „Kurier wählen“ in Einzel- und Parallellisten. Ohne Fahrerspalte steht die Aktion unter Status/Details. Eigene Niederlassung, Rechte 4 und 7; das Kartenrecht ist für die Listenaktion nicht nötig.
- Aktive, freigegebene Fahrzeuge über Fahrerkennung, Kennzeichen oder Transporteur suchen; angemeldet/offline, Verfügbarkeit, Belegung, Freimelde-PLZ und -zeit anzeigen. Bis 200 Treffer mit Gesamtzahl, nach Fahrerkennung sortiert. Die später ergänzten CLASSIC-/BWV-Ranglisten und ihre verbleibenden Sonderfälle sind oben dokumentiert.
- Vorschau prüft offenen Auftragsstatus, Bearbeitbarkeit, Stationen, Fahrzeugmaße/-filter, Kundensperren, Länderregeln und ausführende Niederlassung. Online-Angebot setzt Status 0 und `cr_id_order`; Offline-Zuweisung setzt Status 1 und den angenommenen Kurier. Erneutes Angebot an denselben Online-Kurier ist zulässig; bereits angenommene Zuordnung wird abgewiesen.
- Optional bisherige Freimeldezeit auf jetzt zurücksetzen, ausschließlich für den bisher angenommenen anderen Kurier der eigenen Niederlassung. Entfernen des alten Auftrags vom PDA genau einmal je betroffenen Kurier. Transaktionale Historie, Version und wiederholbare Vorgangskennung.
- Rankingverlust folgt gerichteten PLZ-/Bereichsnachbarschaften. Bei künftigen Aufträgen wird er bis strikt nach Auftragszeit minus `max(serviceplz.srvp_traveltime,30)` aufgeschoben, sofern die PLZ eine Zuordnung zur Dispositionsniederlassung hat. Wie der aktuelle PHP-Listenpfad wird der globale PLZ-Wert verwendet, nicht der abweichende lokale `srvpt_traveltime`. Fehlende/NULL-Zuordnung löst den unmittelbaren Bereichstest aus. Veränderte Vorschauen werden beim Speichern abgewiesen.
- Bestehende Autoranking-Einträge anderer Kuriere bleiben erhalten; nur das gewählte Paar wird aktualisiert/angelegt. Temporäres `jb_cr_price_tmp` wird gelöscht. Keine manuelle Vergütungsänderung in diesem Dialog.

Ergänzt am 17. Oktober: BWV-Preisvergleich und Retouren-/Markup-Übernahme bei direkter Listen-Zuweisung, siehe neuer Prüfstand oben. Kandidatenreihenfolge und Radius-/Favoritensuche wurden inzwischen ergänzt (aktuelle Abschnitte oben). Weiter offen sind Vermittlungssonderfälle, eigenständiger Vermittlungsdienst und Archiv-/Niederlassungsübersicht.


Stand: 16. Oktober 2026. Das im angemeldeten Browser sichtbare Zentralenmenü auf test.sb.assecutor.de wurde geöffnet, einschließlich der dritten Menüebene der Verwaltung. Aktuelle Quelle ausschließlich `root@172.16.0.158:/data/0/votian-test/html`, einschließlich `admin/menu.php` und der verlinkten PHP-Seiten, der React-Oberfläche und den tatsächlich verfügbaren Backend-Endpunkten. Eine vorhandene Ansicht, ein deaktiviertes Formular oder ein Link zur Altanwendung zählt nicht als implementierter Fachprozess.

Aktualisierung Auftragserfassung: Die sechs im gesonderten aktuellen PHP-Abgleich gefundenen Abweichungen sind ergänzt: automatische PZM-Tarifwahl, 36-Monats-Grenze, Tourenoptimierung, Places-Adressvorschläge, separate PLZ-Preisanfrage und Routenkarte mit erzwungener Neuberechnung. Umfang und Integrationsgrenzen stehen in [AUFTRAGSERFASSUNG.md](AUFTRAGSERFASSUNG.md).

## Ergebnis

Die neue Anwendung ersetzt noch nicht alle Funktionen des Altmenüs. Nativ vorhanden sind die Auftragserfassung, erste Verwaltungsbereiche und die serverseitige Zeitraumstatistik, Kunden-/Transporteursberichte und der Vertriebskalender sowie das Lesen von Aufträgen, Kunden und Kurieren. Auftragsbearbeitung, Disposition, Abschluss, Storno/Gegenbuchung und Stammdatenpflege wurden nativ ergänzt. Abrechnungsübersichten, Rechnungszuordnung, CSV und PDF-Leistungsübersichten laufen über `/api/billing/*`. Ein automatischer Rechnungslauf ist im aktuellen PHP selbst als TOBEDONE vermerkt und keine nachgewiesene Paritätslücke; der alte ungenutzte Endpunkt `GET /api/invoices` bleibt nicht unterstützt.

| Altmenü / Funktion | Stand in Votian NG | Fehlender Umfang |
|---|---|---|
| Impressum | Vorhanden | Native Ansicht unter Verwaltung; Inhalt mit PHP-Ansicht abgeglichen |
| Sprache | Vorhanden | Persönliche Sprachpräferenz je Niederlassung, globale Systemvorgabe und vorhandene PHP-Wörterbücher nativ. Tatsächlich befüllt ist Englisch; fehlende Texte bleiben deutsch. |
| Abmelden | Vorhanden | Anmeldung/Abmeldung über bestehendes Konto; Logout nicht zum Prüfen ausgeführt |
| Verwaltung → Kunden | Erweitert, teilweise | Kunden-/Kostenstellenstamm, Anschriften, Bank-/Rechnungsdaten, Konditionen, Benachrichtigungen, Rollkarten-Mailadressen und Hierarchiepflege. Adressvorschläge sowie Kostenstellenanzeige/-namenssuche mit direkter Bearbeitung vorhanden. Preis-/Leistungstypzuordnungen, Servicezonen/PLZ, manuelle Radiuszuordnungen, Tageszeiten, Auslieferarten, Rabattaktionen und Versandzeitvorgaben vorhanden. Kunden-/Aktionspreisformulare 20–25, Abnahmeprotokolle und vier Abliefergrundlisten ergänzt. Automatische Radiusberechnung und CSV-Importe für Zonen, Zonenaufschläge und Radien ergänzt. Kunden–Transporteur-Beziehungen mit Sperre/Favoritenrang, Bemerkung, Mehrfachentfernung und Provisionshistorie ergänzt. Zweite Kundenseite mit Auftragsdisclaimer, Feldhistorie und Druckansicht ergänzt. Fahrzeug-Kundenzuordnungen mit Wochenzeiten/Servicezonen über den Fahrzeugstamm ergänzt. Gemeinsame Dokumentablage mit Upload/Download/Ersetzen/Entfernen/Wiederherstellen ergänzt. Grafische FDS-Disposition mit Erst- und Mehrtagesplanung vorhanden. Hauptzugang mit Aktivierung, Login-/Passwortwechsel, Sperre und 2FA-Rücksetzung ergänzt; Kundenmitarbeiter, deren Portalrechte und Kostenstellenmatrix ergänzt (Matrix benötigt fehlende Tabelle). Eigene NG-Kunden-, Lager- und Transporteurportale vorhanden; Einzelheiten zur Disposition siehe nächste Zeile. |
| Verwaltung → Transporteure | Erweitert, teilweise | Unternehmer-/Fahrzeugstamm einschließlich Kontakt, Anschrift, Abrechnung, Versicherung und Gerätestammdaten; Adressvorschläge vorhanden. Kundenbeziehungen einschließlich Favoritenrang und kundenspezifischer Provision samt Historie vorhanden. Zweite Transporteur-/Fahrzeugseite sowie konfigurierte Transporteur-Zusatzformulare mit Warndaten, Vorlagen, Historie und Druckansicht ergänzt. Fahrzeug-Kundenzuordnungen, Wochenzeiten, Servicezonen, Mehrfachentfernung und native Verfügbarkeitsneuberechnung ergänzt. Gemeinsame Dokumentablage für Transporteure und Fahrzeuge ergänzt. Hauptzugang mit Aktivierung, Login-/Passwortwechsel, Sperre und 2FA-Rücksetzung ergänzt. Fahrerprofil, Unternehmerzuordnung, App-Sperre/Geräte-Abmeldung, automatische Heimatkoordinaten, zentrale Gerätetelefon-Auswahl und bestätigte lokale Nummernübernahme ergänzt; übrige FDS-Sonderfälle siehe Fahrzeugdisposition |
| Fahrzeugdisposition | Erweitert, teilweise | Tagesbelegung, Tagessperren, Unternehmerfreigabe mit Auftragsvorschau, Tagesbemerkungen und native Stammdaten-/Auftragsnavigation ergänzt. Kundenweite Tagessperre sowie Service-/Transporteur-/Zonenfilter ergänzt. Gruppenfilter, persönliche Startauswahl und freigegebener Niederlassungswechsel einschließlich Tagesaktionen ergänzt. Standardrollkarte mit Vorschau, HTML-/PDF-Download, Browserdruck und manuellem E-Mail-Versand samt Versandverlauf sowie eintägige Umsortierung/Fahrzeugübertragung ergänzt. Bestehende Reservierungen lassen sich mit und ohne Artikelgewicht über mehrere Kalendertage neu planen und auf ein anderes Fahrzeug übertragen; Restnutzlast je Tag mit sichtbarer Bestandsberichtigung. Direkte Geräteübergabe mit Vorschau, Gerätekurierzuordnung und Annahme ergänzt (benötigt konfigurierten FDS-Modus mit zugeordneten Kunden). Grafische Umplanung bestehender Reservierungen ergänzt. Erstreservierung bisher ungeplanter Aufträge mit Suche und Mehrtagesvorschau ergänzt. Planungsdatum, Zeiteinheiten und SMS-Startzeit ungeplanter Aufträge ergänzt. Öffentliche/interne Auftragsbemerkungen und individuelle Unternehmerfreigabe/-rücknahme ergänzt. Einzelübergabe (Gerätekurier/Classic) und Rückholung ergänzt. Freigabe späterer angenommener Mehrtagesreservierungen mit Kapazitätsneuberechnung ergänzt. Auftrags-/Fahrzeugstammöffnung aus fremder Dispositionsniederlassung mit geprüftem Arbeitsniederlassungswechsel ergänzt. Tagesübergreifende exakte Auftragssuche mit Reservierungstagen und Direktsprung ergänzt. Classic-Tourbildung im aktuellen PHP wegen fehlender Funktion nicht als funktionsfähige Vorlage belegt; beschränkter Zugang über Recht 28 mit validierten SQL-Vorgaben nativ unterstützt (im Bestand derzeit unkonfiguriert); übrige Spezialaktionen bleiben im Abgleich |
| Verwaltung → Kartenübersicht | Erweitert, teilweise | Native Flottenkarte mit heutigen Ortungen, Alter/Quelle, Freimeldung, laufenden Aufträgen, Suche/Filtern, Aktualisierung, Zentrale/Lagern und Auftragsstationen. Native Stammdaten-/Auftragsöffnung und direkte Zuweisung mit Vorschau, Kundensperren, Fahrzeugprüfung und Rankingfolge. Ortungs-/Freimeldungsprüfung mit PLZ-/Nachbarschaftsabgleich, Plausibilitätskontrolle und bestätigter Übernahme ergänzt. Auftragsbezogene CLASSIC-Rangfolge, Kandidaten-/Gesamt-/zugeordnete Fahrerauswahl, Ablehnungsfarben/-historie und Sperrgründe ergänzt. Kundenzugangs-Kartenansicht mit Kunden-/Fahrzeugumfang separat vorhanden |
| Verwaltung → Berichte → Kunden | Weitgehend vorhanden | Liste, Suche, Berichtstypen, vertrauliche Einträge, Anlegen/Bearbeiten/Löschen, Statistik und CSV nativ. Folgetermine mit übernommener Kundenzuordnung und verknüpfte Formulare 101/102 mit Bearbeitung, Vorlagen, Feldhistorie und Druck/PDF vorhanden. Drei Kundenumsatzvergleiche, direkter Kundenstamm und Rechnungsnavigation mit übernommener Kundenauswahl/Zeitraum ergänzt; Abrechnung weiterhin nur für die eigene Niederlassung |
| Verwaltung → Berichte → Transporteure | Weitgehend vorhanden | Eigene Berichtstypen, Liste, Suche, Anlegen/Bearbeiten/Löschen, Vertraulichkeit, Statistik und CSV nativ. Verknüpfte Formulare 101/102 mit Bearbeitung, Feldhistorie und Druck/PDF vorhanden |
| Verwaltung → Preise → Servicepreise | Vorhanden | Allgemeine/kundenspezifische Matrix, beide Servicemodi, Frachtvergütungen, künftige Stände und Historie; Preis-/Leistungstypen mit Gruppenverwaltung |
| Verwaltung → Preise → PLZ-Preise | Vorhanden | Gerichtete Von-/Nach-Matrix, Kunden-/Fahrzeugtarife, Frachtvergütung und Historie |
| Verwaltung → Preise → Bereichspreise | Vorhanden | Tarifmatrix, Bereiche anlegen/umbenennen, PLZ-Zuordnungen und Nachbarschaften |
| Verwaltung → Rabatte → Servicerabatte | Vorhanden | Separate Rabatt-/Frachtvergütungsrabattmatrix; erhält die Preise und schreibt vollständige Tarifstände |
| Verwaltung → Rabatte → PLZ-Rabatte | Vorhanden | Rabattmatrix mit getrennten Kunden-/Kurierwerten und Historie |
| Verwaltung → Rabatte → Bereichsrabatte | Vorhanden | Bereichsrabattmatrix einschließlich allgemeiner Vergleichswerte |
| Verwaltung → Niederlassungen → Mitarbeiter | Erweitert, teilweise | Mitarbeiterliste mit Niederlassungs-Mehrfachauswahl/Suche/Sortierung, Stammdatenbearbeitung, allgemeine und vererbbare Rechte, Niederlassungsfreigaben und Rechtematrix nativ. Entzogene Rechte werden auch in laufenden NG-Sitzungen geprüft. Kontoanlage/-löschung, Passwortwechsel, 2FA-Einrichtung/-Rücksetzung, Selbstverwaltung ohne Mitarbeiterrecht und Mitarbeiterhistorie ergänzt. Globale PDA-Ortung mit täglichem Zeitfenster ergänzt. Persönliche Listenlänge, Fahrzeuggrenze, Nummernübernahme, Aktualisierungsmodus, Transporteurbemerkungen und Hintergrunddarstellung ergänzt. Persönliche Kopier-/Nacherfassungsmodi samt Dispositionsübersteuerung ergänzt. Parallele Auftragslisten mit Startstatus und eigener Filter-/Seiten-/Aktualisierungsauswahl ergänzt. Persönliche Kostenstellenspalten samt Verwendung in der Erfassung ergänzt. Kunden-/Transporteursspalten samt Verzeichnisnutzung und persönliche Auftragslistenspalten ergänzt. Hauptlager-/Unterlagerrechte, Lesemodus und Artikelverwaltungsflag samt Buchungsprüfung ergänzt. Kundenportal-Kostenstellenrechte ergänzt; Matrix-Tabelle im Bestand noch einzurichten. CC24-Verwaltung, Erfassungsfreigabe und globale Kurierverteilungsregel ergänzt; allgemeiner CC24-Arbeitsplatzwechsel und CC24-Auftragslisten ergänzt; Zusätzliche Statusmail-Empfänger samt Vorschlagsregel ergänzt; bestätigte Auftragsmail sowie gewöhnliche Mehrniederlassungslisten und Arbeitsniederlassungswechsel über Vektor/Rechtematrix ergänzt. Persönliche Sprache und zentrale Metaobjekt-Registrierung/-Bereinigung ergänzt |
| Verwaltung → Niederlassungen → Einstellungen | Vorhanden | Aktive PHP-Bereiche Standortadressen, Supportkontakte, BWV-Hotline, GLN, DUNS und Fahrzeugklassen nativ; getrennte Rechte, Änderungsvorschau, Konflikt-/Wiederholungsschutz und atomare Speicherung. Gemeinsame Adressen werden bei einer Anschriftsänderung separat kopiert. VPA-Ortung separat vorhanden. |
| Verwaltung → Feiertage | Vorhanden | Jahres-/Monatsansicht, An-/Abwahl und Namen, Übernahme aus Jahr/Default, Speichern. Vergangene Tage und heute geschützt; bestehende Zeitfenster bleiben erhalten |
| Verwaltung → Anfahrtszeiten | Vorhanden | CLASSIC je Niederlassung und zentrale BWV-Vorgaben; PLZ-Bereich, Minutenpflege und Speichern je Zeile. Leere/0-Minuten-Eingaben verwenden LATEST_TAKETIME_IN_MINUTES der Niederlassung |
| Verwaltung → Adressen → PLZ-Adressen | Vorhanden | Suche, sieben Sortierungen, Anlage und Mehrfachlöschung der Straßen-/Hausnummernzuordnungen zu Abrechnungs-PLZ je Niederlassung |
| Verwaltung → Adressen → Bereichsadr. | Vorhanden | Bereichsadresszuordnungen mit Hausnummerngrenzen und gerade/ungerade, Bereichsauffüllung und Anzeige besonderer Hausnummernzuordnungen. Tarifgebiete und Nachbarschaften werden im nativen Preisbereich gepflegt |
| Verwaltung → Gruppen | Vorhanden | Anlegen, Umbenennen, Freigabe und Mitgliederpflege; Niederlassungsauswahl im eigenen Mandanten, Löschvorschau mit Zuordnungsbereinigung und Wiederaufnahme nach Teilfehlern. System-/readonly-Gruppen bleiben geschützt |
| Verwaltung → Filter | Vorhanden | Globale Filterliste, Suche, drei Sortierungen, Langtexte, Anlegen, Langtext-/Sortierpflege und Löschen mit Zuordnungsbereinigung. Tour-/Dauerauftragsbereinigung nutzt den vorhandenen PHP-Nachtlauf |
| Verwaltung → Bewertungen | Vorhanden | Kategorie 15: Liste/Karten, Suche, alle neun Auswahlfelder, Anlegen/Bearbeiten/Löschen, Verlauf, Druck/PDF/HTML und E-Mail-Vorbereitung. Automatische Regelauswertung bei Kurierzuweisung mit PDA-Merkmal und Vorschau ergänzt. Keine eigenständige Rechenstatistik; auch das aktuelle PHP-Formular speichert Auswahlwerte |
| Verwaltung → Kessel Buntes | Teilweise | Erledigungsstatistik mit Stationsdetails, Servicezeiten, Ziel-PLZ mit/ohne Ort, Etappenpreise und Auftragsherkunft samt CSV nativ. Transporteursliste, ausländische Rechnungsanschriften, Kunden-Konserven mit Tourenliste und Konservennutzung ergänzt. Tourennamenpflege, Mehrfachentfernung und Einstieg in die Auftragsbearbeitung vorhanden. Dauerauftragsliste mit Jahreskalender, Folgeterminen und Vorgängerhistorie ergänzt. Klassische Beweisfoto-Vorgaben und kundenspezifischer Servicepreis-Ausweis mit Pflege/CSV ergänzt. Sonderkonditionen mit nativer Tarif-/Stammdaten-/Provisionsnavigation und getnow-Fahr-/Servicezeiten samt CSV ergänzt. Kundenmasken- und Kundenzugang-Listenerweiterungen mit Schalterpflege, Suche und CSV ergänzt. Mail-Verteilerübersicht und globale Vorlaufzeit-Zuschläge mit Vorschau/Validierung ergänzt. PZM-Vorgaben, Anfahrtsberechnung je Zone samt Rundungsausnahmen und globale BWV-Einstellungen ergänzt. PZM-Preisvergleich mit separater Auftragsquelle, Einzelkalkulation, Fortschritt und CSV ergänzt. Weitere Sonderfälle sind nicht als vollständige PHP-Parität bestätigt |
| Aufträge → Einzelerfassung | Weitgehend vorhanden | Umfang/Grenzen siehe AUFTRAGSERFASSUNG.md; Bearbeitung einschließlich „Text nur für die Kundenrechnung“, manuelle Preisberichtigung, Zuweisung, Rückruf, Abschluss und Storno/Gegenbuchung ergänzt; Sonderabläufe siehe unten |
| Aufträge → Listenerfassung | Kernablauf vorhanden | Bis zu 20 erledigte Fahrten, Kunde/Kostenstelle, Datum/Uhrzeit, Rechnungstext, Referenz, Fuhr-/Servicebetrag, Fahrzeug, KM, Rabatt/Zuschlag; Preisvorschau, atomare Speicherung und neue/bestehende Kundenlisten. Formatierte Kunden-/Kurierrechnungstexte, optionale CO₂e-Vorschau aus eingegebenen KM und atomare B2B-Rechnungspositionen für neue Listenbuchungen ergänzt. Bestehende einfache Listenbuchungen: Rechnungsausgabe nach Text-/Preisänderungen mit Vorher-/Nachher-Vorschau aktualisierbar, einschließlich gespeichertem Selbsterfasserrabatt bei Fixpreisen, rabattiertem Servicepreis mit Hinweis zum PHP-Rabattausweis und ausschließlich kundenbezogenem Rechnungszusatz („Text nur Rg“). Eigene Niederlassung; Grenzen zu komplexen Kalkulationen und Hintergrunddiensten siehe AUFTRAGSERFASSUNG.md |
| Listen | Teilweise | Suche, Status-/Datumsfilter, Detail und Historie vorhanden. Serverblättern mit persönlicher Listenlänge, Auftragsnummernbereich mit Datumsübersteuerung, Fahrzeugfilter/-grenze und Transporteurbemerkungen ergänzt. Bis zu vier parallele Listen mit persönlichen Startstatus, unabhängigen Filtern/Seiten/Aktualisierung und verstellbaren Höhenanteilen ergänzt. Persönliche Spalten mit 64 Feldern, serverseitiger Sortierung und CSV ergänzt. Direkte Stationssortierung samt zugeordneten Artikeln/Kalkulationen/Preisen, Vorschau und Optimierung ergänzt. Kombinierte Auftrags-, Stations-, Rechnungskunden- und Anforderungsfilter ergänzt. Warn-/Farbregeln, Etappenfortschritt, Favoritenanzeige und Unterauftrags-Sichtbarkeit ergänzt. Autoranking- und Reservierungs-Sammelaktionen sowie direkte Kurierzuweisung mit Online-/Offline-Vorschau ergänzt. Bundesweite BWV-Kandidaten mit Radien/Favoriten/Zeitfenstern, gemeinsamem Vergütungsvergleich und niederlassungsübergreifender Zuweisung ergänzt. CLASSIC-Rangliste mit drei Vermittlungsmodi, Nachbarschaftstiefe, Favoritenausnahmen, laufender Belegung und geprüfter Fremdniederlassungs-Zuweisung ergänzt. Einzelaktionen für automatische/manuelle Vermittlung und „Nur Anforderungen“-Ausnahme ergänzt. Eigenständiger Angebots- und Rückrufdienst ergänzt (im Parallelbetrieb deaktiviert); Gewöhnliche Niederlassungslisten mit vier HQ-Rollen und freigegebenem Fremdauftragszugriff ergänzt; keine funktionsfähige Archivübersicht in der aktuellen PHP-Referenz belegt |
| Rechnungen → Übersicht | Teilweise | Kunden-/Kurier-Leistungsübersichten, Zeitraum/Kostenstellen/Nummernfilter und wiederaufnehmbare Rechnungszuordnung vorhanden. Aktueller PHP-Code enthält keinen implementierten automatischen Rechnungslauf; Zuordnung und Korrekturen einschließlich exportierter Aufträge sind ergänzt. Weitere externe Buchhaltungsabläufe werden separat geprüft |
| Rechnungen → PDF-Ausgabe | Vorhanden | Aktiver PHP-Menüpunkt: PDF-Auftragsbelegsammlung je Rechnungsnummer, einschließlich Leistungs-/Stationsdaten und Nachweisen. Weitergehende externe Rechnungslayouts sind kein bestätigter Umfang dieser Menüseite. |
| Rechnungen → CSV-Ausgabe | Vorhanden | Aktiver PHP-Menüpunkt: Spezialexport 04 samt Filterung nativ; zusätzlich CSV der gefilterten Abrechnungsübersicht. Weitere zentrale Exportformate unter Datentransfer. |
| Vertrieb | Erweitert, teilweise | Tages-/Wochen-/Monats-/Jahreskalender, Terminbearbeitung, Teilnehmer/Gruppen/Bestätigung, Wiedervorlagen, Terminabschluss, Terminstatistik und Kundenberichte/Folgetermine nativ. Kontakte mit Feldhistorie und Druck/vCard, Kundenstatuswechsel mit CSV, Motivation-Counter mit Monatszielen sowie Termin-E-Mails nativ. Kunden-Neuanlage, direkter Kundenstamm und vorbelegte Kundenstatistik aus dem Kalender samt Entwurfsschutz vorhanden; weitere konfigurierte Sonderfälle bleiben im Abgleich |
| Nachrichten → Endgeräte | Weitgehend vorhanden | Historie, Filter, Empfangsbestätigung, Antwort, Einzel-/Gruppen-/Gesamtversand, Gruppen und direkte/transitive Empfängerzuordnung. PHP-Verwaltungsprotokoll 203 für Gruppenänderungen, Zuordnungen und Gesamtversand ergänzt |
| Nachrichten → Mitteilungen | Vorhanden | Zeitraum, Niederlassung/persönlicher Empfänger, Anlage, abgelaufene Einträge, berechtigtes Löschen; kein automatisches Löschen beim Lesen |
| Nachrichten → Newsletter | Weitgehend vorhanden | Bestehende Felder, Liste/Karten, Suche, Bearbeitung, Verlauf, Bilder, Vorlagenausgabe, Druck/PDF/HTML, Empfängerauswahl und SMTP-Versand. Externe Metadatenbank für persönliche Abmeldeschlüssel noch nicht live geprüft; beliebige Template-Skripte werden nicht ausgeführt |
| Datentransfer → Datenexport | Teilweise | Kundenportal-Exportprofile 110/115/120, zentrale Kunden-CSV und Stammdatenexporte 1/2/3 einschließlich Profilen, Kennzeichen und Dateiverwaltung vorhanden. Zentrale Auftrags-/Gutschriftenexporte 4/5/6 mit historischer Folgeverarbeitung ergänzt. Konfigurierte weitere Sonderformate bleiben im Abgleich. |
| Datentransfer → Datenimport | Teilweise | Allgemeine und objektbezogene Dokumentablage sowie FTP/FTPS/SFTP mit wiederaufnehmbaren Übertragungen und Wiederherstellung vorhanden. Kundenzonen-/Aufschlags-/Radiusimporte, gerichteter PLZ-Nachbarschaftsimport und Standard-Zonenauftragsimport, BMW-/ALLERGO-Import sowie TOURS-/DHL-/TIMS-Import mit Vorschau/Doppelimportschutz vorhanden. Konfigurierte Sonderzugänge und RAMP ergänzt; weitere formatbezogene Datenimporte werden noch geprüft. |
| Statistik | Erweitert, teilweise | Zeitraum-/Niederlassungsabfragen unabhängig von der Auftragsliste, fünf Vergleiche, 21 Aufteilungen einschließlich Branchen/Stationsadressen/Zielstationen und Kalkulationspositionen, KM/CO₂e, Nettowerte und CSV. SID, Auftragstyp, Erfassungsart, Maße und Anforderungsfilter ergänzt. Historische Kundenzuordnung und Leistungskalkulation mit Halbmonaten vorhanden. Kundenzeitfilter und sechs native Diagrammarten ergänzt. Gruppenkunden-/Fahrerfilter, Unternehmer-Gruppierung und bedingte Kundenservice-/Auftragsmerkmalsfilter sowie fünf Transporteur-Aktionsstatistiken ergänzt. Vier Preisvarianten mit gesonderter Zuschlagsvergütung und freigegebener pauschaler Bruttodarstellung vorhanden. Mehrfach-/statische Gruppen mit Mitarbeitern und Preistypen, Kunden-Zusatzangaben sowie Annahme-/Abholdauer mit fünf Zeitklassen ergänzt. Zusatzmontage nur/ohne und zentrale Kundenausschlüsse ergänzt. Archivauswertungen bleiben wegen fehlender Archivtabellen und fehlerhafter PHP-Referenz offen; Geräte-/Online-/Befragungsstatistiken sind im aktuellen PHP deaktiviert. |
| Formulare | Teilweise | Kategorien/Felddefinitionen/Vorlagen/Gruppenzuordnung und Feldreihenfolge nativ. Berichtsformulare 101/102 und Kundenpreisformulare 20–25 einschließlich gespeicherter Vorlagen ergänzt. Zweite Stammdatenseiten 2/3/4 und konfigurierte Transporteur-Zusatzformulare ergänzt. Weitere Objektformulare und Spezialfeld-/Skriptfunktionen fehlen |




## Persönliche Auftragslistenspalten – 16. Oktober 2026

- **Referenz:** frisch gelesener SSH-Arbeitsbaum `2eb7f98`; `admin/employee.php`, `admin/jb_list.php`, `include/jb_list_defineoutput.inc.php`, `include/mcglobal.inc.php` und `include/dbglobal.inc.php`. Die aktuelle PHP-Mitarbeiteroberfläche mit Spaltenauswahl wurde geöffnet. Keine lokalen PHP-Altquellen und keine Bestandsänderungen.
- **Pflege:** „Listenspalten“ in der Auftragsübersicht sowie Mein Konto / Mitarbeiter → Listenparameter. Auswahl, Reihenfolge, Hinzufügen, Entfernen und Standardbelegung aus 64 PHP-Listenschlüsseln (einschließlich Brutto-/Montage- und bestehender Zusatzspalten). Speicherung ausschließlich in `MASK_JB_LIST_COLS`; `MASK_JB_LIST_LEN_COLS` bleibt unangetastet, weil dessen Controls in der aktuellen PHP-Oberfläche auskommentiert sind. Vorrang persönliche aktuelle Niederlassung → Heimatniederlassung → allgemeine aktuelle Niederlassung → PHP-Standard, mit separatem Standard für zugeordnete Kunden. Keine automatische Übernahme beim Lesen.
- **Anzeige:** Einzel- und Mehrfachlisten verwenden dieselbe Konfiguration und die tatsächlichen Felder: Stationsfirma/Zusatz, erste/zweite Adresse, PLZ-/Ortsfolge mit Länderpräfix, Fahrzeug, Annahme-/Warn-/Erledigungszeit, Kennzeichen für Vorbestellung/Dauerauftrag/Kundenerfassung/Favorit, Callcenter, Kommissionsnummern, Maut, TSZ, KM/Preis-KM/CO₂ und Montagefelder. BSG-Quote und Erfassungs-/Ausführungs-BSG folgen den PHP-Formeln; die Niederlassungswerte sind Eurobeträge. Brutto nutzt den globalen Steuersatz und addiert Maut danach. Mehrfach vorhandene Preis-/Maut-/Montagequellen erzeugen einen ausdrücklichen Fehler. Transporteurbemerkungen nur bei entsprechendem Parameter, Transporteurrecht und angenommenen/erledigten Listen; Sortierungs- und Stornospalten sind statusabhängig.
- **Sortierung/CSV:** Sortierung aller Datenspalten vor der SQL-Seiteneinteilung, stabile Auftrags-ID als Zweitsortierung, keine Sortierung nur der sichtbaren Seite. CSV übernimmt Reihenfolge und Werte, dieselben Filter und Sortierung sowie vorhandenes Exportrecht und Vollständigkeitslimit. Aktionsspalten bleiben im CSV leer. UTF-8-BOM, Anführungszeichen und Schutz vor Tabellenformeln bleiben erhalten.
- **Direktaktionen:** Auftrag/Details, Bearbeitung, Storno/Gegenbuchung, Stationsfolge, Kundenberichte, Kundendokumente und Karte öffnen native NG-Dialoge. Kunde wird aus der Rechnungskostenstelle gelesen; Karte übernimmt die Auftragsnummer. Rechte werden berücksichtigt; Dokumente bleiben auf die eigene Niederlassung beschränkt. Stationsfolge nutzt inzwischen den eigenen Sortierdialog, siehe unten. Die aktuelle PHP-Zielseite prüft zusätzlich zum Listen-Sortierrecht das Bearbeitungsrecht.
- **Speicherung/Prüfung:** aktuelle Mitarbeiterberechtigung, Mandant, Revision, transaktionales Audit 203 und identische Wiederholung nach unklarer Antwort. Historie mit Spalten vorher/nachher. 724 Tests, 721 bestanden und drei optionale Live-Tests übersprungen; isolierte SQL-Prüfungen für 104 Aufträge, zweite Seite, Preisformeln, Rechte, Rollback, Konflikte, Duplikate und CSV. Browser: Reihenfolge in beiden Ansichten, Preis-Sortierung, Export und Direktbearbeitung; 503-Wiederholung und 409-Neuladen. Alle 64 SQL-Projektionen sowie persönliche Liste gegen echten Bestand ausschließlich gelesen.
- **Weiter offen:** vollständige PHP-Warn-/Farbregeln, Archiv-/Fremdniederlassungslisten, erweiterte Ranking-/Reservierungsaktionen und Spezialfilter. Für späteste Annahme bei Vorbestellungen ist eine vorhandene PLZ-Anfahrtszeit oder ein gültiger `LATEST_TAKETIME_IN_MINUTES`-Parameter erforderlich. Die übrigen offenen Menübereiche bleiben offen.

## Direkte Stationssortierung – 16. Oktober 2026

- **Referenz:** erneut live gelesener SSH-Arbeitsbaum `2eb7f98`, `admin/sort.php` (SHA-256 `a3b30dc3bc2c4a290a064e2742480949cd4945dd1015c41d85d0533147e02512`), `include/inc_job.inc.php` (SHA-256 `0b660ceef70176f64314cf74809fa681eac06553c534473a4690d0edf941e0c6`) und Listenlink in `include/jb_list_defineoutput.inc.php`. Tatsächliche PHP-Sortieroberfläche geöffnet, nur gelesen. Die Zielseite prüft Recht 7; ein vollständiger Sortierzugriff allein über Listenrecht 30 war daher keine zutreffende Paritätsanforderung.
- **Bedienung:** Listenspalte „Sortierung“ sowie Auftragsbearbeitung → „Stationsreihenfolge ändern“. Stationskarten mit Adressen, Kontakt und Erledigungsvermerk, Pfeile und Ziehgriff; Routenvorschau als eingebettete Karte. Optimierung von 4 bis 25 Stationen mit festen Endpunkten, Kilometervergleich und ausdrücklichem Speichern des Vorschlags. Geänderte Reihenfolge verwirft die bisherige Routenvorschau.
- **Zuordnung:** `tour`, `tourarticle` und `jobcalculator` folgen ihrer stabilen Stations-ID. `tourservice` und `jobpayment` werden anhand der vorherigen eindeutigen Position in einer einzigen CASE-Aktualisierung umgeordnet; auftragsweite Position 0 bleibt erhalten. Beträge, Mengen, Seriennummern, Scans und Zustellnachweise bleiben unverändert. `jb_tourdata` wird aus PLZ/Ort/Land in der neuen Reihenfolge aufgebaut; Version, Nachbearbeitungs- und Rechnungstextmarkierung, Geräteaktualisierung und Audit werden gemeinsam gespeichert. Keine automatische Preisänderung.
- **Schutz:** Rechte 4/7/30, eigene Niederlassung, Status 0/1/8/9, vollständige eindeutige Stationsmenge und gültige Adress-/Positionszuordnungen. Erledigte/stornierte/exportierte/fakturierte/gesperrte Aufträge und verschobene Stationen bereits exportierter Einnahmen bleiben geschützt. Revisionsprüfung einschließlich Artikel und Kalkulationen vor dem Schreiben sowie nach Routendienstantwort; transaktionales Rollback und identische Vorgangswiederholung. Änderungen in einem unklaren Speichervorgang bleiben gesperrt; Konflikte verlangen Neuladen mit Entwurfsschutz.
- **Prüfung:** 726 Tests, 723 bestanden, drei optionale Live-Tests übersprungen. Isolierte MariaDB prüft Zuordnung, unveränderte Nachweise/Beträge, Wiederholung, Konflikt, Rollback, ungültige/fehlende Stationen und Adressen, Rechte, Niederlassung, Export-/Rechnungs-/MyISAM-Sperren und Vorschau ohne Speicherung. HTTP-Session/CSRF geprüft. Echtes Schema und bestehender Auftrag ausschließlich gelesen; alle sechs betroffenen Fachtabellen sind InnoDB. Vollständige Listen-Warnfarben, Ranking-/Reservierungsaktionen, Spezialfilter sowie Archiv-/Fremdniederlassungslisten bleiben offen.

## Spezialfilter der Auftragslisten – 16. Oktober 2026

- **Referenz:** aktueller SSH-Arbeitsbaum `2eb7f98`, `admin/jb_list.php` (SHA-256 `db040a7b070773da74dfbbdf3e46f3ecc55564f516f34f81dd880826221e80fc`) und `include/jb_list_defineoutput.inc.php` (`9c8087e29853641fca21fee5b76b0abbebad6231cb830e91a0c6f6bf3aab8a0a`). Angemeldete PHP-Auftragsliste einschließlich erweitertem Adressbereich und Status „Erledigte Aufträge“ tatsächlich geöffnet. Nur aktuelle Serverquellen verwendet.
- **Auftragsfilter:** Zukünftige (hebt nur das Enddatum auf), Ausschluss von Daueraufträgen, Nachbearbeitung, Servicepreis, Frachtvergütung, nicht exportiert einschließlich Null-/Nulldatum, ohne Storno, Ferntouren, Angebote ein-/ausschließen, Besteller, erfassender Benutzer, Bereichsgrenzen und Rechnungs-Kommissionsnummer. Fahrerkennung sucht exakt beim Auftrag und seinen Unteraufträgen ohne doppelte Hauptaufträge. Leistungen per Bitmaske und Bezugskunden bei aktivierter Bezugsfunktion/persönlicher Dispositionsgruppe. Ferntouren erfordern zusätzlich Recht 10.
- **Station und Rechnungskunde:** Firmenname, Straße, PLZ, Ort und Land/einzelner Länderausschluss; bei Stationen zusätzlich Kontakt, Bemerkung und Kommissionsnummer, beim Rechnungskunden EID und Kostenstellenname. Stationsfelder müssen gemeinsam auf dieselbe Station passen, über alle Stationen hinweg. Der Länderausschluss sucht eine passende abweichende Station; er schließt nicht pauschal jede Tour mit einem Besuch dieses Landes aus. `D` wird wie `DE` behandelt. Rechnungskundenfilter verwenden immer `csc_id_payer`, unabhängig vom Barzahler. Alle gewählten Anforderungskürzel müssen als vollständiges Pflicht- oder Wunschkürzel vorhanden sein.
- **Listenverhalten:** Alle Kriterien werden vor Trefferzählung und Seiteneinteilung in SQL angewendet und identisch an den CSV-Export übergeben. Eigene Filter und Rücksetzung je Parallelliste, ebenfalls in Einzelliste/Disposition; Wechsel eines Filters setzt die Seite zurück. Länderentfernung löscht den zugehörigen Ausschluss. Ausgeblendete GDC-Aufträge bleiben verborgen; bei Zuweisungslisten ausgeblendete Kundenaufträge können wie im PHP ausdrücklich eingeblendet werden.
- **Bewusste Präzisierungen:** Textsuche akzeptiert auch kurze Begriffe und behandelt `%`, `_` und `!` wörtlich. Keine SQL-Wildcard-Einschleusung. Vollständige Wunschkürzel werden auch in der Mitte einer Liste gefunden; der PHP-Tippfehler in dieser Teilbedingung wird nicht übernommen. Länderwahl bietet ISO-Kürzel, keine Abhängigkeit vom optionalen PHP-Ländergruppenverzeichnis. Zusatzfilter können auch außerhalb der PHP-Statusmasken kombiniert werden.
- **Prüfung:** 729 Tests, 726 bestanden und drei optionale Live-Tests übersprungen. SQL-, Session-/Validierungs- und Browserprüfungen sowie lesender Test am echten Bestand erfolgreich. Neue Oberfläche auf Port 8080; Einzel-/Parallellisten und CSV geprüft.
- **Abgrenzung:** „Prüfung Etappenzeit“, bevorzugte Kuriere und erweiterte Etappenanzeige sind Darstellungs-/Warnfunktionen, keine weiteren Datenfilter; deren vollständige PHP-Parität bleibt offen. Ebenso Ranking-/Reservierungsaktionen, Archiv-/Fremdniederlassungslisten und die übrigen offenen Menübereiche. Dies ist keine vollständige Gesamtparität.

## Autoranking und Reservierungsranking – 16. Oktober 2026

- **Referenz:** aktueller SSH-Arbeitsbaum `2eb7f98`; `admin/jb_list.php`, SHA-256 `db040a7b070773da74dfbbdf3e46f3ecc55564f516f34f81dd880826221e80fc`, Zeilen 708–779, 1600–1603 und 2035–2048; LKW-Zuordnung aus aktuellem `include/global.inc.php:getVhtId`. Reale PHP-Liste „Zuzuweisende Aufträge“ mit den Links A/R geöffnet. Keine Aktion gegen Bestandsdaten ausgeführt.
- **Native Aktionen:** „Autoranking …“ und „Reservierungsranking …“ in der Einzelliste/Disposition und bei zuzuweisenden Parallellisten. Explizites Von-Datum, vollständige Vorschau mit Auftragsnummer, Zeit, Tour, Erfassungs-/Dispositionsniederlassung, Kurier und Sperrgrund. Die Vorschau stellt klar: Wie PHP beziehen sich diese Sammelaktionen auf alle passenden Aufträge der aktuellen Erfassungs- **oder** Dispositionsniederlassung ab dem Von-Datum, unabhängig von Suchtext, Bis-Datum, Seitennummer und übrigen Listenfiltern.
- **Auswahl:** Status 9, kein Angebot, `jb_longhaul=0`, Fahrzeugtyp unter der konfigurierten `truck_01`-Grenze (Standard 7). Normale Aufträge bis zur Vorschauzeit ohne `jb_cr_fav`/Reservierung; Reservierungen bis Vorschauzeit + 30 Minuten und mit sichtbarer Rechnungskunden-Auftragsliste. Reservierungen mit Kurierpräferenz werden wie PHP nicht zusätzlich ausgeschlossen. Der normale A-Lauf übernimmt keine zusätzliche Kunden-Sichtbarkeitsbedingung.
- **Speichern:** Status 8, globale Vermittlungsmarkierung zurücksetzen, Kurier/Kurierangebot/Kennung gemäß `JOB_GO_AUTORANKING_NOT_REMOVAL_COURIER` erhalten oder leeren. HQ-Parameter vor globalem Wert. Bestehende Autoranking-Tabellenzeilen und das separate `jb_autoranking`-Flag bleiben wie im PHP-A/R-Code erhalten. NG-Version erhöhen und Historie 56 pro Auftrag mit unterscheidbarer Beschreibung vormerken. Hierdurch wird die Warteschlange freigegeben; die anschließende Kurierauswahl benötigt weiterhin den vorhandenen Vermittlungsdienst.
- **Schutz:** Rechte 4/7, Session/CSRF, InnoDB für alle mutierten Tabellen, Revisionsprüfung der vollständigen Kandidatenmenge einschließlich relevanter Rechnungssperren und Einstellungen. Neue/geänderte Kandidaten verlangen eine neue Vorschau. Maximal 5000 Kandidaten; keine stille Kürzung. Vorschau zehn Minuten gültig. Storno, Gegenbuchung, Export, Rechnungszuordnung und aktive PHP-Bearbeitung werden sichtbar übersprungen. Atomare Ausführung, dauerhafte Vorgangskennung und identischer Wiederholungsabruf nach unbekanntem Ergebnis; verspätete Wiederholungen eines bereits bestätigten Vorgangs bleiben möglich.
- **Zusätzlicher Fehlerbefund:** Tests verwenden nun pro isolierter Fixture einen geschlossenen Verbindungspool. Das verhindert tausende kurzlebige Verbindungen und machte einen zuvor verdeckten MariaDB-Fehler sichtbar: Nach `SELECT NOW()`, Metadaten oder leeren Lesevorgängen konnte die für die nächste Transaktion gesetzte Nur-Lesen-Eigenschaft in den Pool zurückkehren. NG startet neue Lesetransaktionen daher ausdrücklich mit `START TRANSACTION READ ONLY`; der Nur-Lesen-Schutz bleibt wirksam, auch bei verschachtelten Abfragen. Regressionstest prüft leeres Lesen, Uhrzeit/Metadaten, Leseabbruch, verhinderten Schreibversuch und erfolgreiche/abgebrochene Schreibtransaktionen auf derselben Verbindung. Siehe [MariaDB-Transaktionsmodi](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/set-commands/set-transaction).
- **Prüfung:** 741 Tests, 738 bestanden und drei optionale Live-Tests übersprungen. Browserprüfung beider Aktionen einschließlich identischer Wiederholung nach unbekanntem Ergebnis; reale Datenbank nur gelesen. Port 8080 aktualisiert und ausgelieferte Dateien mit dem Build abgeglichen.
- **Abgrenzung:** keine native Portierung des gesamten automatischen Vermittlungsdienstes und keine freie fremde Niederlassungsauswahl. Die übrigen offenen Menübereiche der Tabelle bleiben offen.

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

- **Referenz:** erneut direkt gelesener SSH-Arbeitsbaum `2eb7f98`, unveränderte Prüfsummen der beiden aktuellen Listendateien aus dem vorigen Abschnitt; außerdem Farbparameter in `admin/customer_special.php`. Tatsächliche PHP-Liste „Angenommene Aufträge“ geöffnet. Im gewählten Zeitraum dort keine Auftragszeilen; die Regeln wurden anhand des aktuellen Ausgabecodes und isolierter Beispieldaten verifiziert.
- **Warnungen:** ausstehende Annahme nach Auftrag + fünf Minuten bzw. Vorbestellung minus PLZ-Anfahrtszeit/globaler Vorlaufzeit; `jb_waittime` übersteuert nur „Späteste Annahme“. Angebote sind von Annahmewarnungen ausgenommen. Angenommene Aufträge prüfen die noch offene erste Station mit getrennten niederlassungsbezogenen Ad-hoc-/Vorbestellungsfristen. Erledigungswarnzeit, Nachbearbeitung vor Abrechnung und fehlende Pflicht-Kommissionsnummer ergänzt. Konfigurierte Kopfzeilenfarben werden bei Fristüberschreitung verwendet.
- **Etappen:** vollständig erledigte, direkt aufeinanderfolgende Stationen werden gegen `MASK_JOBLIST_ALERT_LEG_TIME_SECONDS` geprüft; exakte Grenzgleichheit erzeugt keinen Hinweis, negative Intervalle schon. Fehlende Erledigungszeit wird nicht als Nullzeit interpretiert. Erledigte Stationen einer laufenden Tour erscheinen grün/unterstrichen in der PLZ-Folge; erledigte erste Station kennzeichnet den Fahrer mit Klammern. Alle Hinweise stehen zusätzlich als aufklappbarer Klartext am Auftrag, unabhängig von den gewählten Spalten.
- **Farben/Kennzeichen:** unzugewiesene, an alle Kuriere angebotene und erledigte nachzubearbeitende Aufträge, Ferntour, Dauerauftrag, Kundenerfassung und Erfassung einer anderen Niederlassung. Preisprüfung aus `jb_blink`/Nullpreis-Warnparameter, Kundenfarbe, negative Preise bei aktivierter Gutschriftfarbe und negative Deckungsbeiträge. Kein blinkender Text: dauerhafte Kennzeichnung und Klartext bleiben auch ohne Farbwahrnehmung verständlich. Nur gültige Hexfarben werden übernommen; Schriftkontrast wird angepasst. Fahrzeuganforderungen verwenden vollständige Kürzel. Mehrdeutige Farb-/Preiswarnparameter, Stationsfolgen oder Anfahrtszeiten werden gemeldet.
- **Bevorzugte Fahrer:** bei aktiviertem `MASK_JOBLIST_CR_FAVOURED` kann die Favoritenkennzeichnung auch für alle/angenommene/erledigte Listen eingeschaltet werden. Vorhandene primäre gewünschte Fahrer von Rechnungs- oder Barzahler erzeugen einen booleschen Vorschlag, auch bei mehreren Beziehungen ohne doppelte Aufträge. Diese Kennzeichnung bewertet keine aktuelle Verfügbarkeit und löst keine Zuweisung aus.
- **Unteraufträge:** außerhalb von `GLOBAL_USE_RELATED_CUSTOMER` erscheinen nur erledigte Unteraufträge mit passendem Vorzeichen zum Hauptauftrag (Null gilt als nichtnegativ). Die Regel greift vor Zählung/Seiteneinteilung/Export; fehlende Hauptaufträge können die Vorzeichenprüfung nicht erfüllen. Fahrer-Unterauftragssuche findet weiterhin den sichtbaren Hauptauftrag. Bei aktivem Bezugskundenmodus entfällt diese Einschränkung.
- **Unwirksame PHP-Schalter:** `filter_tr_time_check` wird in der aktuellen Seite nur eingelesen und ausgegeben; die Etappenprüfung hängt tatsächlich am genannten Parameter. `jobHopsToBeSearchedIn` wird berechnet, aber in dieser Seite anschließend nicht verwendet. NG prüft/sucht bereits über alle Stationen; es werden keine wirkungslosen zusätzlichen Schalter nachgebaut. Die bisher als offen geführten beiden Schalter sind damit im aktuellen Referenzstand geklärt.
- **Prüfung:** vollständiger `clean verify` mit 736 Tests, 733 bestanden und drei optionalen Live-Tests übersprungen. Ergänzende Exportprüfung bestätigt vier Zeilen ohne HTML/Farbwerte; SQL-, Grenzwert-, Vorzeichen-, Duplikat- und Browserprüfungen erfolgreich. Bestandsliste einschließlich Warnprojektion ausschließlich gelesen. Ranking-/Reservierungsaktionen, Archiv-/Fremdniederlassungslisten sowie die übrigen offenen Menübereiche bleiben offen.

## Gemeinsame Stammdatendokumente – 16. Oktober 2026

- **Referenz:** frisch gelesener SSH-Arbeitsstand `2eb7f98`, `import/data_transfer.php` (SHA256 `c57b55631bb3c94533959f368fd46e65434525473bf0b355ca0ccf4305a0e067`) und angemeldete PHP-Dateitransferoberfläche. Nativ im Kunden-/Transporteur-/Fahrzeugstamm unter „Dokumente / Dateien“ sowie über die Dokumentzählerspalten der Verzeichnisse.
- **Gemeinsame Dateien:** tatsächliches PHP-Verzeichnis `html/import/upload`, Mandantenpfad, Typverzeichnisse CS/CR/CRVH und optionaler Niederlassungs-Unterpfad aus den bestehenden Parametern. Kunden-/Transporteur-EID und Fahrzeug-ID bestimmen den Dateipräfix. Unterordner, Name, Größe, Datum, Download, Upload bis 4.000.000 Bytes, ausdrückliches Ersetzen und Entfernen. Dokumentzähler im vorhandenen `genericdatacontainer` sowie Audit 97/183 werden nachgeführt. Zähler beziehen sich entsprechend der PHP-Maske auf das bearbeitete Verzeichnis.
- **Zugriff:** eigene Niederlassung, aktuelles Stammdatenrecht 0/1 sowie getrennte Rechte 22/23; Niederlassungsadministrator ohne Mengenbegrenzung. Globale/Niederlassungs-Vorgaben für Gesamt-/Objektdateizahl und Dateiumbenennung. Unklare EID-/Mandantenpfad-Zuordnung, Pfadtraversal, symbolische Links und abweichende Wiederholungen werden abgewiesen. Dateien werden ausschließlich als Download ausgeliefert. Ausführbare Web-Dateitypen sind für neue Uploads gesperrt; reguläre Dokument-, Bild-, Office- und Archivformate erlaubt. Für Bestandsdateien gilt momentan eine 64-MB-Grenze beim Lesen/Ändern. EID-Präfixe werden durch `_`/`.` abgegrenzt, damit EID 12 keine Dateien von EID 123 erhält.
- **Wiederaufnahme:** vor dem Dateischreiben werden Vorgang und Dateiinhalt in bestehenden InnoDB-Containerzeilen festgeschrieben. Die reale `gdc_content`-Spalte ist `TEXT`; Uploaddaten verwenden deshalb Base64-Teile mit höchstens 50.000 Zeichen je Zeile, ohne Schemaänderung. Nach Abschluss werden diese Teile gelöscht. SHA256 prüft auch Änderungen mit unveränderter Dateigröße und Zeit. Offene Vorgänge erscheinen mit „Fortsetzen“; verlorene Antworten werden identisch wiederholt. Abgeschnittene Stagingdateien, nur teilweise abgeschlossene Dateiverschiebung und fehlender Abschlussbeleg sind abgedeckt. Entfernte Dateien bleiben gesichert und vom ursprünglichen Bearbeiter wiederherstellbar; ersetzte Vorgängerversionen bleiben für Fehlerklärung gesichert. Kein automatisches endgültiges Löschen der Sicherungen.
- **Koordination:** Datenbank-Advisory-Lock zwischen NG-Prozessen, kurze PHP-kompatible Containersperre für Journal/Zähler/Audit. Dateiziele werden mittels Hardlink und anschließendem Unlink ohne Überschreiben vorhandener Ziele übernommen; die SFTP-Erweiterung des tatsächlichen Servers ist vorhanden. PHP-Dateischreiber verwenden diese NG-Sperre nicht. Bei konkurrierenden Änderungen erkennt die Wiederaufnahme abweichende Inhalte und hält zur Klärung an; eine gemeinsame atomare Transaktion zwischen PHP-Dateien und SQL existiert nicht.
- **Konfiguration:** `DOCUMENTS_MODE`, `DOCUMENTS_ROOT`, `DOCUMENTS_HOST`, `DOCUMENTS_PORT`, `DOCUMENTS_USER`, `DOCUMENTS_PASSWORD`/`DOCUMENTS_KEY` und `DOCUMENTS_KNOWN_HOSTS` aus `.env`. Lokal eingebundene gemeinsame Ablage oder SFTP mit zwingender Hostschlüsselprüfung. Lokale `.env` konfiguriert, nicht versioniert; keine Geheimnisse in Quellcode oder Browser. Echte Ablage ausschließlich lesend geprüft. Allgemeiner FTP/FTPS/SFTP-Importdialog, externe Importskripte sowie Auftrags-/Mitarbeiterdokumente bleiben gesonderte offene Funktionen.


## Erweiterte Kunden-/Transporteursuche und Listenexport – 16. Oktober 2026

- **Referenz:** aktueller SSH-Arbeitsstand `2eb7f98`, `admin/customer_list.php`, `admin/courier_list.php`, `admin/customer_special.php`, `include/html.inc.php`, `include/global.inc.php`, `include/dbglobal.inc.php`; beide angemeldeten PHP-Listen mit aufgeklappter Erweiterung bzw. Transporteursoptionen gelesen. Kundenliste SHA256 `e845bee0330d777b7975c61598a2d27e7cf83c30530c443d4f1e8ebadae5d553`, Transporteursliste `370c884892740647233193ff223282f8222734a7e4192db47ac5dbb74db7aeda`.
- **Kunden:** Präfix-/Teilwortsuche, nur ausgeblendete/freigegebene, Alt-EID, mit/ohne Metakundenreferenz, Rabatt, Kundentyp, Neukundendatum, Branche, Vertriebsranking, Bank-/Steuerfelder; alle aktiven Mail-/Tracking-/Erfassungs-/Kommissions-/Abrechnungs-/Nachhaltigkeitsmerkmale des PHP-Suchblocks. Leistungs-, Rechnungs- und Abhol-/Lieferadresse separat nach Straße/PLZ/Ort. Parameterfilter über `EXISTS` verhindern doppelte Treffer bei mehrfachen Parameterzeilen.
- **Bewusste Korrekturen:** Die PHP-Adresssuche überschreibt zuvor gesetzte Bedingungen; NG verknüpft alle gesetzten Bedingungen mit UND. Sie funktioniert auch mit kurzen, präzisen Eingaben und benötigt keinen Schalter „Alle Kunden“, weil die Ergebnisse paginiert werden. Die im PHP sichtbaren, dort im Such-SQL wirkungslosen Optionen Keine Preisausgabe/Lademaße/Lademaße Pflichtfeld sind anhand der tatsächlichen Speicherparameter aus `customer_special.php` wirksam umgesetzt. Auskommentierte alte Foto-Suchfilter werden nicht als aktive Funktion übernommen.
- **Transporteure:** nur Unternehmer, freigegebene/ausgeblendete, VPA-Geräteinfo als Suchtext und zuschaltbare Spalte, kombinierbare Transporteur-/Fahrzeuganforderungen mit vollständigem Kürzelvergleich; L/B/H/Stellplätze/Nutzlast/Gesamtgewicht/Umweltstufe/CI als Mindestwerte, Maßsuche über vier Einzelwerte, Erstzulassung ab Monat, Antriebsart und Rechnungsfahrzeugtyp als Auswahl. Interne Firmen sind standardmäßig ausgeschlossen und nur für den eingetragenen Niederlassungsadministrator zuschaltbar.
- **Niederlassungen:** Mehrfachauswahl innerhalb genau eines Mandanten, deaktivierte/mehrdeutige Niederlassungen ausgeschlossen. Heimat-/Sitzungsrecht, aktuelles Mitarbeiterrecht, `emp_headquarters` und bei fremden Niederlassungen die Kunden-/Transporteurspalte in `employeerights`; Administrator wie PHP mit Mandantenzugriff. Keine zusätzliche CRM-Berechtigung erforderlich. Niederlassung erscheint bei übergreifender Auswahl als Listenspalte. Stammdaten-/Historien-/Erfassungs-/Dauerauftrags-Direktaktionen bleiben vorerst auf die eigene Niederlassung beschränkt; die übergreifende Bearbeitung bleibt ausdrücklich offen. Berichte verwenden ihre eigene Rechteprüfung.
- **CSV:** eigenständige Exportrechte Kunden 51 / Transporteure 48, zusätzlich Leserecht. Dieselben serverseitigen Filter und dieselbe Sortierung wie die letzte ausgeführte Suche, alle Treffer unabhängig von der angezeigten Seite. Spalten wählen/ordnen, Trennzeichen Semikolon/Komma/Strich/Tabulator, optionale Überschriften, UTF-8-BOM, quotierte Felder und Schutz vor Tabellenformeln. Mehr als 100.000 Zeilen erzeugen einen ausdrücklichen Fehler statt einer unvollständigen Datei. Keine Passwort-/Aktionsfelder exportierbar. Geänderte oder fehlerhafte Filter sperren den Export bis zur erfolgreichen Suche.
- **Prüfung:** 719 Tests, 716 bestanden, drei optionale Live-Tests übersprungen; Frontend gebaut. Isolierte MariaDB prüft Kombinationen, Parameterduplikate, null/0-Werte, Adressen, Maße, Anforderungen, Classic-Bestand, Rechte/Mandanten/deaktivierte Niederlassungen, vollständigen 105-Zeilen-Export und CSV-Escaping. Browserfixture prüft Filterpayload, Exportreihenfolge/Trennzeichen/Download und Korrektur ungültiger Suchwerte ohne Verlust der Filter. Echter Bestand ausschließlich gelesen: beide Verzeichnisse plus kombinierte erweiterte Abfragen über neun freigegebene Niederlassungen.
- **Noch offen:** Dokumente für weitere Objekttypen und allgemeiner Import-/Transferdialog, weitere Historienformate/Vorher-Nachher-Vergleich, native übergreifende Direktbearbeitung, detaillierte VPA-Aufbereitung/Gerätetyp-Auswahlliste, Entkopplung der Dauerauftragsnavigation vom Extras-Recht; persönliche Auftragslistenspalten wurden inzwischen ergänzt. Die übrigen offenen Menübereiche werden dadurch nicht als vollständig erklärt.

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

- **Referenz:** frisch gelesener SSH-Arbeitsstand `2eb7f98` einschließlich uncommittierter Dateien; `admin/employee.php`, `admin/customer_list.php`, `admin/courier_list.php`, `admin/history.php`, die aktuellen Kunden-/Transporteur-Logformate und beide angemeldeten PHP-Listenoberflächen. Keine lokalen PHP-Altquellen.
- **Spaltenpflege:** 34 Kunden- und 38 Transporteurspalten, Reihenfolge, Hinzufügen, Entfernen und Standardbelegung. Über „Spalten anpassen“ sowie Mein Konto / Mitarbeiter → Listenparameter. Speicherung ausschließlich in `MASK_CS_LIST_COLS` bzw. `MASK_CR_LIST_COLS`; die in PHP auskommentierten Längenparameter bleiben unverändert. Vorrang aktuelle persönliche Niederlassung → Heimatniederlassung → allgemeiner Parameter → Standard. Klassisches `cr_vh_sign` wird für die Anzeige normalisiert. Unbekannte Altspalten werden mit Hinweis ausgelassen; doppelte Parameter sperren die Pflege.
- **Verzeichnisse:** „Persönliche Spalten“ ist die Standardansicht für Kunden und Kuriere; die bisherige Kompaktansicht bleibt erreichbar. Serverseitige Gesamtsuche, kombinierbare Spaltenfilter, sichtbare entfernbare Filter, Sortierung und 100er-Seiten; kein Gesamtlimit von 500 Datensätzen. Ausgeblendete Firmen zuschaltbar, archivierte ausgeschlossen. Kundenspalten einschließlich Zahlungsbedingung, Branche, Steuern, Nachhaltigkeits-/Rechnungs-/Mahnmail, Alt-EID und Dokumentzähler; Kundenstatus als Text. Bei Kostenstellenanzeige wird die Kostenstelle vorangestellt. Fahrzeuge werden je SID aufgeführt, `CR_SID_STATUS=1` verwendet die klassische SID und das klassische Kennzeichen des Transporteurs.
- **Direktaufrufe:** Kunden-/Transporteurstamm, Kostenstelle und Fahrzeug öffnen die bestehenden nativen Editoren. „Auftrag“ liest die Hauptkostenstelle exakt per ID, prüft Niederlassung/Freigabe/Sperre/externen Zahler und übernimmt sie in die Erfassung. Beim Wechsel der Erfassungsniederlassung wird diese Vorbelegung verworfen. Berichte übernehmen Objekt und Niederlassung. Daueraufträge/Konserven öffnen die bestehenden Auswertungen mit Kunde und heutigem Stichtag; die bisherigen zusätzlichen Rechte dieser Auswertungen bleiben erforderlich.
- **Historie:** native Kunden-/Transporteurhistorie mit Zeitraum, vorhandenen Logarchiven, Vorgangsfilter (Stamm/Kostenstellenanschriften/Fahrzeuge), Autor und Telefon. Rechte 0/1 und Objekt der eigenen Niederlassung. Ausstehende NG-Ereignisse werden lesend hinzugefügt, bereits veröffentlichte nicht dupliziert. Höchstens die neuesten 2500 Einträge mit sichtbarem Begrenzungshinweis. Rohbeschreibungen und Zugangsdaten werden nicht ausgegeben; verifizierte PHP-Kontakt-/Adresspositionen, Freigabe/Sichtbarkeit und NG-Stammdatenfeldnamen sind aufbereitet. Übrige historische Detailformate und der PHP-Vorher/Nachher-Feldvergleich sind ausdrücklich noch offen.
- **Speicherung:** aktuelle Mitarbeiter-/Mandantenberechtigung, Revision, InnoDB-Transaktion, Audit 203 und identische Wiederholung nach unklarer Antwort. Die Mitarbeiterhistorie zeigt Spalten vorher/nachher. Andere Parameter werden erhalten. 409-Konflikte verlangen Neuladen; 503-Ausgänge bleiben mit derselben Vorgangskennung wiederholbar.
- **Geprüft:** echter Bestand ausschließlich lesend einschließlich beider Historienabfragen; isolierte SQL-/HTTP-/Browserprüfungen für 105 Kunden, zweite Seite, kombinierte Kostenstellen-/Ortsfilter, Wildcards, Fremdniederlassung, Fahrzeug-/Classic-Modus, Berechtigungen, Rollback, Wiederholung und Konflikt. Frontend gebaut, vollständiger Backend-Lauf: 718 Tests, 715 bestanden, drei optionale Live-Tests übersprungen.
- **Noch gesondert offen:** die nachfolgend beschriebenen Such-/Exportfunktionen wurden ergänzt; weiterhin offen sind native Verwaltung der allgemeinen Kunden-/Transporteur-/Fahrzeugdokumente (Zähler allein ist keine Dokumentverwaltung), weitergehende Historienaufbereitung, Entkopplung der Dauerauftragsnavigation vom Extras-Recht; persönliche Auftragslistenspalten wurden inzwischen ergänzt. Dieser Abschnitt schließt die übrigen offenen Stammdaten-/Disposition-/Abrechnungsbereiche nicht ab.

## Persönliche Kostenstellenspalten und Auswahlliste – 16. Oktober 2026

- **Referenz:** frischer SSH-Arbeitsbaum `2eb7f98`, `admin/employee.php`, `admin/cs_csc_list.php` und `include/dbglobal.inc.php`. Angemeldete PHP-Kostenstellenauswahl mit den tatsächlichen Spalten, Suchfeldern, Präfix/Teilwort und Niederlassungsfiltern geöffnet; keine Bestandsänderung. Ausschließlich aktuelle Serverquellen.
- **Pflege:** Mein Konto → Listenparameter → Spalten der Kostenstellenauswahl; ebenso aus der berechtigten Mitarbeiterverwaltung und direkt aus der neuen Auswahl. Bis zu 21 Spalten aus den 15 PHP-Feldern, Reihenfolge, Hinzufügen/Entfernen, Standardbelegung und Anzeigelänge 0–50. 0 zeigt vollständigen Text; gekürzte Inhalte bleiben als vollständiger Hinweis am Feld lesbar. Gleiche Spalte darf wie in PHP mehrfach vorkommen.
- **Speicherformat:** ausschließlich `MASK_CSCSC_LIST_COLS` und `MASK_CSCSC_LIST_LEN_COLS`; Schlüssel und Längen bleiben positionsgenau gekoppelt. Persönliche aktuelle Niederlassung, dann Heimatniederlassung, dann allgemeine HQ-0-Vorgabe beziehungsweise PHP-Standard. Unbekannte Altspalten/ungültige Längen werden mit Hinweis für die Anzeige ersetzt; kein Schreiben beim Lesen. Mehrdeutige Parameter oder falscher Mandant sperren die Pflege.
- **Verwendung:** Rechnungs-/Barzahler und Stationskostenstelle der Einzelerfassung verwenden die Tabelle. Globale Suche nach Firma/Firma 2, Kundennummer, Kostenstelle, Freitext oder Telefon; zusätzliche Spaltenfilter, Präfix/Teilwort, Sortierung, Rücksetzen und Serverblättern in 50er-Seiten. Filterung vor Zählung/Limit. Die bewusst gekürzte Anzeige verändert weder Suche noch übernommene Werte. Aktive Filter bleiben auch nach Ausblenden einer Spalte einzeln entfernbar.
- **Navigation:** Statistik mit exakter Kundennummer, Niederlassung, Monatsraster und Zeitraum vom 1. Januar des Vorjahres bis heute; Berechnung wird im geöffneten Statistikdialog gestartet. Kundenberichte mit Kunden-ID und Niederlassung. Beide verwenden die vorhandenen nativen Rechteprüfungen und Dialoge, kein PHP-Fenster. Fehlende Rechte deaktivieren die Aktion; Berichtsänderungen bleiben vor unbeabsichtigtem Schließen geschützt.
- **Grenzen:** Die neue Auswahl bleibt auf die gewählte Erfassungsniederlassung und aktuell auswählbare/freigegebene Kostenstellen begrenzt. Rechnungszahler sind intern, Stationen können externe Adresskostenstellen nutzen. Die alte zusätzliche Anzeige unsichtbarer/gesperrter Interessenten, beliebige Mehrfach-Niederlassungssuche und automatische Übertragung einer einzelnen ausgewählten Adresszeile sind gesondert offen; die bestehende bewusste Adressübernahme bleibt erhalten. Die Listenerfassung nutzt noch ihre kompakte Auswahl. Die persönlichen Kunden-/Transporteurspalten sind inzwischen ergänzt (siehe eigener Abschnitt); Auftragslistenspalten wurden inzwischen ergänzt (siehe eigener Abschnitt).
- **Speicherung und Prüfung:** aktueller Rechte-/HQ-/Mandantenabgleich, Revision, atomare InnoDB-Parameteränderung mit Audit 203 und Wiederholungsbeleg. Mitarbeiterhistorie zeigt Reihenfolge/Längen vorher und nachher. Isolierte SQL-/HTTP-/Browserprüfung einschließlich 60 Treffer, zweiter Seite, Kombination Telefon/Ort, Wildcardzeichen als Suchtext, Fremdniederlassung, 503-Wiederholung und 409-Neuladen. Echten Bestand ausschließlich gelesen.

## Parallele Auftragslisten und persönliche Startauswahl – 16. Oktober 2026

- **Referenz:** aktueller SSH-Arbeitsstand `2eb7f98`, `admin/employee.php`, `admin/jb_list_fs.php`, `admin/jb_list.php` und `include/dbglobal.inc.php`. Persönlicher PHP-Dialog mit Anzahl 1–4, vier getrennten Statusauswahlen und tatsächliche dreiteilige PHP-Listenoberfläche gelesen. Keine lokalen PHP-Altquellen verwendet.
- **Pflege:** Mein Konto → Listenparameter → Parallele Listen und Startstatus; ebenso berechtigt aus der Mitarbeiterliste. Speichert ausschließlich `MASK_MULTI_JOBLIST` und `MASK_JOBLIST_DEFAULTLIST`, mit allen vier Startstatus auch bei nur einer sichtbaren Liste. Persönliche Werte der aktuellen Niederlassung haben Vorrang vor der Heimatniederlassung, danach allgemeine Vorgaben beziehungsweise die PHP-Startfolge 8/9/0/1. Die konfigurierte maximale Listenanzahl wird innerhalb 1–4 berücksichtigt. Ungültige Altwerte werden mit Hinweis durch überprüfbare Vorgaben ersetzt; kein Schreiben beim Lesen.
- **Laufzeit:** Aufträge öffnet die persönliche Listenansicht. Jede Liste hat einen eigenen Status, Suchtext, Zeitraum, Nummernbereich, Kunden-/Transporteur-/Fahrzeugfilter, Serverblättern, Aktualisierung und CSV. Anzahl und Startstatus kommen aus der gespeicherten Konfiguration. „Einzelliste“ öffnet weiter die bisherige Ansicht. Nach dem Speichern der Startauswahl werden die Listen bewusst mit den neuen Vorgaben begonnen. Höhenanteile 1–4 verteilen den sichtbaren Platz; schmale Bildschirme zeigen einzelne scrollbare Bereiche untereinander.
- **Statusabgrenzung:** 0 Offene, 1 Angenommene, 2 Erledigte, 8 Autoranking, 9 Zuzuweisende, 10 Alle Aufträge. Filterung erfolgt vor Zählung und Seitenlimit, mit unveränderter eigener Niederlassungsgrenze. Status 10 entfernt den Statusfilter. Wie PHP enthält die Liste Erledigte auch stornierte erledigte Aufträge; ihre Kennzeichnung bleibt sichtbar. Die bisherige gruppierte Statusauswahl anderer Ansichten bleibt unverändert. Nummernsuche übersteuert das Datum; persönliche Fahrzeuggrenze und Transporteurbemerkungen bleiben wirksam. CSV verwendet dieselben Filter und lehnt unvollständige Exporte ab.
- **Aktualisierung:** eigener 30-Sekunden-Takt pro aktivierter Liste; die gespeicherte persönliche Refresh-Vorgabe und getrennte Sitzungsauswahl je Listenplatz werden berücksichtigt. Erledigt/Alle beginnen ohne Automatik. Änderungen an einer Liste ändern keine Filter oder Seiten der anderen. Während eines geöffneten Konten-/Auftragsdialogs pausieren die Listenabfragen; laufende Anfragen werden bei Filterwechsel/Schließen abgebrochen, veraltete Antworten ignoriert.
- **Speichern:** aktuelle Rechte einschließlich Administratorschutz, Niederlassung und Mandant; Revision, kurze PHP-kompatible Parametersperre, InnoDB, gemeinsamer Audit 203 und Wiederholungsbeleg. Verlorene Bestätigung lässt sich identisch wiederholen; Konflikte erfordern Neuladen. Mitarbeiterhistorie zeigt Anzahl und vier Startstatus. Andere persönliche Parameter bleiben unverändert.
- **Geprüft:** SQL und Browser einschließlich mehrseitiger Liste, unabhängiger Suche/Status/Refresh-Auswahl, Nummernübernahme, Exportgrenze/Export, Auftragsdetails, Höhenanteilen, vier/drei Listen, erhaltener vierter Auswahl, 503-Wiederholung und 409-Konflikt. Echter Bestand nur gelesen. Die Statusliste „Autoranking“ zeigt vorhandene Aufträge; zusätzliche Ranking-Aktionen/-Kandidaten, Spezialfilter, Fremdniederlassungslisten bleiben gesondert offen. Persönliche Spalten sind inzwischen ergänzt.

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

- **Referenz:** frischer SSH-Arbeitsstand `2eb7f98`, `admin/employee.php`, `jobs/job_options.php`, `jobs/job_edit.68.20.js` und die uncommittierte aktuelle Fassung von `jobs/get_saved_tour.php`. Die beiden Auswahlfelder Disposition/Buchhaltung im angemeldeten PHP-Parameterdialog gelesen; keine lokalen PHP-Altquellen verwendet.
- **Pflege:** Mein Konto → Listenparameter beziehungsweise berechtigt über die Mitarbeiterliste. `MODE_COPY_JOB` und `MODE_LATER_JOB` sind unabhängig einstellbar und ergänzen die sechs Listenparameter. Alle acht Werte werden gemeinsam mit Revision, aktuellen Rechten, Audit 203 und Wiederholungsbeleg gespeichert. Die Mitarbeiterhistorie zeigt auch die beiden neuen Vorher-/Nachher-Werte.
- **Nacherfassung:** Im Buchhaltungsmodus öffnet eine neue Erfassung als Nacherfassung mit leerem Ausführungsdatum. Im Dispositionsmodus startet sie als Sofortauftrag; eine anschließend ausdrücklich gewählte Nacherfassung schlägt die aktuelle Berliner Minute vor. Die bisherige Pflicht-, Vergangenheits- und 36-Monats-Prüfung bleibt maßgeblich.
- **Auftragskopie:** Der Buchhaltungsmodus lädt eine Nacherfassung mit Ausführungszeit und aktuell verfügbarem Fahrzeug der Vorlage. Ein nicht mehr freigegebenes, gesperrtes oder uneindeutiges Fahrzeug wird nicht übernommen; ein sichtbarer Hinweis verlangt die erneute Auswahl. Im Dispositionsmodus bleiben Datum und Fahrzeug leer; der unabhängige Nacherfassungsmodus bestimmt dann die Auftragsart. Kopien behalten keine alte Warnzeit oder Dauerauftrags-Endzeit. Status, Geräteübergabe, Anhänge und Lagerbewegungen werden nicht wiederholt; vor dem Anlegen ist eine neue Preisvorschau erforderlich.
- **Einzelne Erfassung:** „Für diese Erfassung Dispositionsmodus verwenden“ übersteuert beide persönlichen Vorgaben. Bei vorhandenen Eingaben verlangt der Wechsel eine ausdrückliche Bestätigung; Auftragsart, Termine und Fahrzeug werden zurückgesetzt, die übrigen Eingaben bleiben erhalten. Die persönlichen Vorgaben folgen auch bei Erfassung für eine andere Niederlassung der angemeldeten Niederlassung; die Vorlage und das Fahrzeug bleiben auf die ausgewählte Erfassungsniederlassung begrenzt.
- **Geprüft:** isolierte SQL-, Rechte- und Browserprüfungen, einschließlich unabhängiger Modi, ungültiger Fahrzeugvorlage, bestätigtem/abgebrochenem Moduswechsel, Preisvorschau und synthetischer Speicherung. Echter Bestand nur gelesen. Persönliche Spalten und Sprache bleiben offen; parallele Listen wurden anschließend ergänzt, siehe oben.

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

- **Referenz:** aktueller SSH-Arbeitsstand `2eb7f98`, `admin/employee.php`, `admin/jb_list.php` und `include/dbglobal.inc.php`; persönlicher PHP-Parameterdialog im angemeldeten Browser gelesen. Ausschließlich aktueller Serverstand, keine lokalen PHP-Altquellen.
- **Pflege:** Mein Konto → Listenparameter sowie berechtigt aus der Mitarbeiterliste. Sechs bestehende Schlüssel: `MASK_JOBLIST_BROWSE_MAX`, `MASK_JOBLIST_SHOW_UPTO_VHT`, `MASK_JOBLIST_MODE_JOB_NUM`, `MASK_JOBLIST_MODE_REFRESH`, `MASK_JOBLIST_GET_COURIER_DATA`, `MASK_CONTENT_BGCOL`. Speichert in der aktuellen eigenen Niederlassung; beim Lesen gilt PHPs Rückfall auf die Heimatniederlassung auch bei einem leeren aktuellen Wert. Fremde Parameter bleiben erhalten. Eigenes Konto ohne Mitarbeiterrecht; andere Mitarbeiter mit Recht 3 sowie Administratorstatus oder aktuellem Recht 50, geschützte Administratorkonten ausgeschlossen.
- **Listenverhalten:** 100–1000 Einträge je Seite, serverseitige Gesamtzahl/Seitenabfrage. Fahrzeugobergrenze vor dem Seitenlimit, expliziter Fahrzeugfilter übersteuert sie. Von-/Bis-Auftragsnummern einschließlich Grenzen, bei Nummernsuche kein Datumsfilter wie in PHP; alle übrigen Rechte-, Niederlassungs- und Statusfilter bleiben wirksam. Optionale Übernahme der Von-Nummer beim Verlassen des Felds. Automatische Aktualisierung bei offenen/laufenden Aufträgen stets aktiv nach Neuladen oder entsprechend der gemerkten Auswahl; alle/erledigte/stornierte Listen starten ohne automatische Aktualisierung. Blau/Grau wirkt auf die Arbeitsfläche. Bei Unterwegs/Erledigt können die ersten 20 Zeichen beider Transporteurbemerkungen erscheinen, mit zusätzlicher Transporteur-Leseberechtigung. CSV verwendet dieselben persönlichen/Nummern-/Fahrzeugfilter und verweigert weiterhin einen unvollständigen Export oberhalb des Limits.
- **Speichern:** gemeinsame Parametersperre, aktuelle Rechte, Revision über Benutzer/Parameter/Katalog, eindeutiger Mandant, InnoDB-Prüfung, atomare Parameter/Audit/Belege und identische Wiederholung bei verlorener Bestätigung. Konflikte erfordern Neuladen. Mitarbeiterhistorie enthält sechs typisierte Vorher-/Nachher-Werte unter Vorgang 203; sowohl ausstehend als auch nach Veröffentlichung sichtbar, ohne doppelte Ereignisse.
- **Noch offen:** Sprache. Persönliche Listenspalten wurden inzwischen ergänzt. Mehrere parallele Listen mit Startstatus wurden anschließend ergänzt, siehe oben. Die beiden Kopier-/Nacherfassungsmodi wurden anschließend ergänzt, siehe oben.

## Globale PDA-Ortung und Niederlassungsauswahl – 16. Oktober 2026

- **Referenz:** aktueller SSH-Arbeitsbaum, HEAD zum Abschluss `2eb7f98`; `admin/employee.php`, `admin/employee_list.php` und `include/inc_autoranking.inc.php` gegenüber Beginn `d7530c0` unverändert. PHP-Mitarbeiterliste und tatsächlicher Parameterdialog im Browser gelesen.
- **PDA-Ortung:** Verwaltung → PDA-Ortung. Status An/Aus und tägliches Von-/Bis-Zeitfenster für die eigene Niederlassung; aktuelles Recht 9 erforderlich, Mitarbeiterrecht 3 nicht nötig. Speichert die bestehenden globalen Schlüssel `LOCATING_PDA_ENABLED` und `LOCATING_PDA_INTERVAL` (`emp_id=0`, Sitzungsniederlassung); persönliche Parameter und fremde Niederlassungen bleiben erhalten. Gleiche Anfangs-/Endminute und ganzer Tag zulässig, Zeitfenster über Mitternacht abgewiesen. Der bestehende PDA-/Autorankingdienst konsumiert diese Schlüssel; dieser Schritt ergänzt keinen neuen Ortungsdienst.
- **Speichern:** beide Werte einschließlich Auditvorgang 194 und dauerhaftem Wiederholungsbeleg atomar. Gegen parallele PHP-Schreibzugriffe gesperrt, Revision geprüft, entzogene Rechte auch vor Wiederholung geprüft. Doppelte/falsch zugeordnete Parameter sperren die Pflege. Fehlender oder ungültiger Status verlangt ausdrückliche Auswahl statt stiller Aktivierung; ungültige Zeitfenster sind korrigierbar. Schreibzugriff verlangt InnoDB für Parameter und Belege.
- **Mitarbeiterliste:** beliebige Teilmenge freigegebener Niederlassungen mit Checkboxen, Alle/Keine. Ohne Auswahl gilt wie in PHP die eigene Niederlassung. API prüft die gesamte Auswahl; fremde/unbekannte oder doppelte IDs werden abgewiesen. Alter Einzel-/Alle-Parameter bleibt kompatibel.
- **Noch offen:** persönliche Listenspalten/-modi und Sprache, Lager-/Kostenstellenrechte, CC24 sowie die allgemeine Niederlassungsparameterverwaltung. Die globale PDA-Pflege ist kein Ersatz für diese Bereiche.

## Mitarbeiterhistorie – 16. Oktober 2026

- **Referenz:** ausschließlich aktueller SSH-Arbeitsbaum, bei Abschluss HEAD `47ec87d`, einschließlich der uncommitteten Änderungen in `include/inc_history.inc.php`. Mitarbeiterabschnitt und Kontodateien gegenüber `090d3d5` unverändert; die Änderungen im Historienparser betreffen Aufträge. PHP-Mitarbeiterliste und Mitarbeiterhistorie im Browser geöffnet: Zeitraum, Vorgang, Zeitpunkt, Name/Vorname des Handelnden, Telefon und Details.
- **Aufruf:** Verwaltung → Mitarbeiter → Historie. Aktuelles Mitarbeiterrecht und Recht 32 oder zuständiger Administrator; Nichtadministratoren sehen keine Historie geschützter Administratorkonten. Zielmitarbeiter wird vor Zugriff auf Protokolltabellen auf Mandant/Niederlassungsfreigabe geprüft. Auch sitzungsseitig später entzogene Rechte wirken.
- **Anzeige:** Zeitraum mit vollständigem Endtag, neueste Einträge zuerst, maximal 2500 mit ausdrücklichem Begrenzungshinweis. Aktueller Bestand und vorhandene `loghistory`, `loghistory2`, `loghistory3` separat auswählbar. Die Bestände werden aus Datenbank-Metadaten ermittelt, Anfragewerte ausschließlich aus der festen Liste angenommen. Im aktuellen Live-Historienschema sind keine Archivtabellen vorhanden.
- **Details:** PHP-Anlage-/Änderungs-/Löschangaben, Passwortänderung ohne Hashwerte, allgemeine und vererbbare Rechte, Niederlassungsfreigaben, alte und neue Matrixformate sowie NG-Profil-Vorher/Nachher und 2FA-Aktionen. Unbekannte interne Detailfelder werden nicht unverändert ausgegeben, weil alte PHP-Protokolle Passwort-Hashes enthalten können. Texte werden als React-Text gerendert. Fehlende ehemalige Benutzer erscheinen mit ihrer Benutzer-ID.
- **Protokollierung:** NG-Mitarbeiterereignisse bekommen die echte Ziel-`emp_id` im bestehenden Protokollschema. Ältere ausstehende NG-Ereignisse mit eindeutigem Mitarbeiterpräfix bleiben kompatibel; bereits veröffentlichte Einträge ohne `emp_id` werden lesend zugeordnet. Noch ausstehende Ereignisse sind sofort mit Status sichtbar. Ein bereits geschriebenes, noch nicht quittiertes Ereignis erscheint einmalig. Die Ansicht löst selbst keine Veröffentlichung aus.
- **Grenzen:** Die Historie ist aus der Liste bestehender Zentralenmitarbeiter erreichbar. Globale Protokollübersicht gelöschter Konten, zusätzliche Parameter-Detailtypen und Portalzugänge gehören zu den noch offenen Verwaltungsbereichen. Der vorhandene MyISAM-Protokolltransport bleibt bestehen; keine Schemaänderung und keine Bestandsrückschreibung beim Lesen.

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

- **Referenz:** frischer SSH-Arbeitsstand `090d3d5`; `admin/start.php`, `admin/GA_generateBarcode.php`, Mitarbeiterverwaltung und `include/global.inc.php::user2FARemove`. Die angemeldete PHP-Startseite mit Aktivierungshinweis im Browser gelesen. Das Einrichtungsformular aus dem aktuellen PHP-Markup separat mit synthetischem QR-Code gerendert, da bereits sein echter GET-Aufruf das Bestands-Secret ändern würde.
- **Mein Konto:** Profil und eigenes Passwort über das Kontosymbol in der Kopfleiste, auch ohne Mitarbeiterrecht 3. Der Server bindet alle Selbstverwaltungsrouten an den angemeldeten Mitarbeiter. Kein Zugriff auf andere Mitarbeiter oder Rechte über diesen Weg. Stammdaten- und Passwortwechsel behalten Revisionsprüfung, aktuelle Berechtigung und atomare Wiederholungsbelege.
- **Einrichtung:** aktuelles Passwort, lokal erzeugter QR-Code oder manueller Schlüssel und sechsstelliger App-Code. Keine Übermittlung des Secrets an einen QR-Dienst. Vorbereitung für zehn Minuten ausschließlich in der eigenen HTTP-Sitzung; erst erfolgreicher App-Code speichert die Aktivierung. Neuer QR-Code, Abbruch, Ablauf und maximal fünf ungültige Codes pro Einrichtung. Der Aktivierungscode ist für den anschließenden NG-Login bereits verbraucht; nach erneuter Anmeldung den nächsten App-Code verwenden.
- **PHP-Vorgaben:** erstes Flag von `USERTYPE_2FA_ENABLED` steuert die Einrichtung für Zentralenkonten. `USER_2FA_NO_DEACTIVATION` sperrt die Selbst-Deaktivierung; dies ist keine Einschreibepflicht. Bei erlaubter Selbst-Deaktivierung sind aktuelles Passwort, App-Code und exakter Anmeldename erforderlich. Verwaltungsreset über den Mitarbeiter-Zugangsbereich folgt Administrator-/Recht-43-Schutz, verlangt das aktuelle Passwort des Handelnden und den Ziel-Anmeldenamen. Fremde Administratorkonten bleiben geschützt. Eine neue Kopplung eines aktiven Kontos erfolgt nach berechtigter Rücksetzung.
- **Speichern:** frischer Konto-/Policy-Abgleich unter Kontosperre, InnoDB, atomare Rotation der Sitzungsbindung, Audit und Beleg. Aktivierung und Rücksetzung beenden bestehende NG-Sitzungen bei deren nächstem API-Zugriff; die Oberfläche führt bei eigener Änderung zurück zur Anmeldung. QR/Schlüssel werden nur während der Einrichtung ausgegeben, weder Passwörter noch Secrets gelangen in Belege oder Audit. Verlorene Antworten sperren abweichende Eingaben bis zur Klärung; ist die geänderte Sitzung bereits ungültig, klärt erneute Anmeldung den Kontostand.
- **Verbleibend:** Persönliche/globale Parameter, Lager-/Unterlager- und Kostenstellenrechte, PDA/CC24, externe Newsletter-Metaobjekte und Portalzugänge. Diese Ergänzung schließt die übrigen Verwaltungsabläufe nicht ab.

## Mitarbeiter: Kontoanlage, Zugang und Zwei-Faktor-Anmeldung – 16. Oktober 2026

- **Referenz:** frischer SSH-Stand `090d3d5`, `admin/employee.php`, `admin/employee_list.php`, `admin/login.php`, `admin/GA_verification.php`, `include/auth.inc.php` und `include/GoogleAuthenticator.php`. PHP-Anlageformular und 2FA-Bestätigung im Browser geöffnet; keinerlei Bestandskonto geändert.
- **Kontoanlage:** Verwaltung → Mitarbeiter → Neuer Mitarbeiter. Freigegebene Niederlassung, Stammdaten, weltweit innerhalb der Datenbank eindeutiger Anmeldename, Geburtstag und bestätigtes Passwort. Mitarbeiterkonto mit Heimatniederlassung und zunächst leeren allgemeinen/vererbbaren Rechten; die vier PHP-Standardspaltenkonfigurationen werden mit korrektem Mandanten angelegt. Keine automatische Rechtevererbung.
- **Zugang:** eigener Dialog pro Mitarbeiter. Passwortwechsel für das eigene Konto, berechtigte Administratoren oder Mitarbeiter mit Recht 37; fremde Administratorkonten bleiben geschützt. Eigenes Passwort nur nach Eingabe des bisherigen Passworts. Der Wechsel löscht auch den alten MySQL-Passworthash und rotiert die Sitzungsbindung. Die bei Anmeldung erfasste Bindung an Passwort-/TOTP-Stand wird bei jeder authentifizierten API-Anfrage geprüft. Änderungen über PHP werden damit ebenfalls erkannt. Es werden NG-Sitzungen beendet; PHP-Sitzungen ohne aktivierte 2FA werden durch den PHP-Code selbst weiterhin nicht gegen Passwortwechsel geprüft.
- **Löschung:** exakte Bestätigung des Anmeldenamens, kein eigenes Konto und kein Administrator. Mitarbeiter-/Benutzerzeile, Niederlassungsmatrix und eigene Parameter werden atomar entfernt. Historische Geschäftsdaten bleiben erhalten. Mehrfach verwendete Benutzerzeilen und Änderungen seit der Vorschau verhindern die Löschung.
- **2FA-Anmeldung:** Bereits aktivierte PHP-TOTP-Konten benötigen Passwort und sechsstelligen Code. Gleicher Algorithmus und aktuelles 30-Sekunden-Fenster wie PHP; unabhängige Testvektoren aus [RFC 6238](https://www.rfc-editor.org/rfc/rfc6238). Kein angemeldeter Teilzustand vor erfolgreicher Prüfung. NG speichert den zuletzt verbrauchten Zeitschritt ohne Code/Secret im bestehenden Datencontainer und verhindert erneute Verwendung auch nach Neustart. Frische Prüfung unter gemeinsamer Kontosperre, atomare Rotation des PHP-Sitzungsschlüssels und InnoDB-Prüfung. Ein erfolgreicher NG-2FA-Login beendet ältere NG-/PHP-2FA-Sitzungen. Die unveränderte PHP-Anmeldung selbst besitzt keinen gemeinsamen NG-Replay-Check.
- **Speichern und Geheimnisse:** Revisionsprüfung, aktuelle Rechte, atomare Protokollierung/Belege, Rollback und identische Wiederholung. Belege und Audit enthalten keine Passwörter, Passworthashes oder 2FA-Secrets. Bei verlorener Antwort bleiben Eingaben gesperrt und derselbe Vorgang kann erneut abgefragt werden. Nach erfolgreichem Passwortwechsel überholt ein späterer weiterer Wechsel einen früheren Wiederholungsbeleg; dieser wird abgewiesen und niemals erneut angewandt.
- **Verbleibend:** Externe Newsletter-Metaobjekte bei Kontoanlage/-löschung, Mitarbeiterparameter, Lager-/Kostenstellenmatrix, PDA und CC24 sowie Portalzugänge. Keine vollständige Migration der Zugangsverwaltung behauptet.

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

- **Referenz:** aktueller SSH-Arbeitsstand `090d3d5`; `admin/employee_list.php`, `admin/employee.php`, `admin/employee_rights.php` und `include/dbglobal.inc.php`. In der angemeldeten PHP-UI Mitarbeiterliste, leeres Anlageformular, bestehender Mitarbeiterdialog und Niederlassungsmatrix ausschließlich gelesen. Keine Bestandskonten geändert.
- **Liste und Stammdaten:** neuer Bereich „Mitarbeiter“ unter Verwaltung mit Suche nach Name, Vorname, Anmeldename, E-Mail, Telefon/Mobil sowie sechs Sortierungen. Eigene oder alle freigegebenen Niederlassungen, maximal 500 Treffer mit sichtbarem Hinweis. Name, Vorname, E-Mail, Telefon, Mobil, Anmeldename und Geburtstag bearbeitbar; Anmeldenamen werden global auf Mehrdeutigkeit geprüft. Geburtstags-Nullwerte bleiben als leeres Feld darstellbar.
- **Rechtepflege:** allgemeine Rechte und „darf Recht erteilen“, klassischer Modus einschließlich exakter VIP-Freigabe, Niederlassungsfreigaben und separate Matrix mit Zeilen-/Spaltenauswahl. Filter beschränkt die Sammelauswahl auf sichtbare, änderbare Zellen. Die tatsächlichen 53 Rechtedefinitionen stammen aus dem Bestand; Bits hinter dem Katalog sowie nicht bearbeitbare Niederlassungen/Matrixeinträge bleiben erhalten. Fehlende/falsch geordnete Definitionen, doppelte Parameter oder Matrixeinträge werden vor Änderungen abgewiesen. Bleibt keine Niederlassungsfreigabe übrig, gilt die Heimatniederlassung.
- **Berechtigung:** Recht 3, gültiger Zentralenzugang und eindeutiger Mandant. Andere Niederlassungen erfordern Recht 10 und Freigabe, beim zuständigen Administrator gilt die Mandantenliste. Eigene Rechte und Administratorkonten bleiben geschützt; eigene Administrator-Stammdaten dürfen bearbeitet werden. Vererbungsmodus: allgemeines Recht nur mit eigenem Recht und eigener Vererbungsfreigabe änderbar, Vererbung nur mit eigener Vererbungsfreigabe. Matrixrechte nur innerhalb eigener Matrixfreigabe bzw. Administratorumfang und gegebenenfalls Vererbungsfreigabe. Diese serverseitigen Grenzen übernehmen die bedienbaren PHP-Felder und verhindern manipulierte Anfragen; unsichere PHP-POST-Abkürzungen werden nicht übernommen. Klassisch ausgeblendete Vererbungsbits werden erhalten.
- **Sitzungen:** NG schneidet die bei Anmeldung vorhandenen Rechte vor jeder authentifizierten API-Anfrage mit den aktuellen Datenbankrechten. Entzug wirkt bei der nächsten Anfrage, zusätzliche allgemeine Rechte nach erneuter Anmeldung. Gelöschte/anders zugeordnete Zentralenkonten werden abgemeldet; bei nicht prüfbarer Datenbankverbindung gibt es keinen Berechtigungsrückfall. Kontext bleibt an die Anfrage gebunden, andere Tabs verändern keine Sitzungsniederlassung. Die Prüfung ergänzt einen lesenden SQL-Zugriff je authentifizierter API-Anfrage.
- **Speichern:** Revisionsvergleich schließt Stammdaten, Zielrechte, eigene Delegationsbefugnis, Definitionen, Parameter und Matrix ein. Kurze PHP-kompatible Tabellensperre und InnoDB für geschriebene Tabellen; atomare Änderung, Protokoll und Wiederholungsbeleg. Bei fehlender Speicherantwort bleibt der unveränderte Vorgang erneut abrufbar, ohne zweites Speichern. Passwort-, TOTP-, Gruppen-, Parameter- und übrige Benutzerspalten werden nicht geändert oder ausgegeben. Keine Schemaänderung.
- **Noch offen in diesem Bereich:** Externe Metaobjekt-Synchronisation neuer/gelöschter Konten, persönliche/globale Listeneinstellungen, Lager-/Unterlager- und Kostenstellenmatrix, PDA-Ortungsvorgaben, CC24 und Kundenzugänge. Die vorhandene Rechtepflege zählt nicht als Abschluss dieser übrigen Abläufe.

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

- **Referenz:** erneut frisch per SSH gelesene Dateien aus `root@172.16.0.158:/data/0/votian-test/html`, HEAD `93bf782`: `vehicle_disposition.php` Aktion 104, `ajaxReqDisposition.php::sendCartageNote` und `dbglobal.inc.php::getParameterValue`. Alte angemeldete FDS mit Datum 14.10.2026 geöffnet; aktuelle Auswahl weiterhin ohne Fahrzeugzeilen. Daher kein gefüllter alter Aktionsdialog visuell vergleichbar. Kein ursprünglicher lokaler PHP-Bestand.
- **Einstieg:** Verwaltung → Fahrzeugdisposition → **Tag öffnen** → **Rollkarte aufs Endgerät**. Rechte 27/4/7; freigegebene fremde Dispositionsniederlassungen über den bestehenden HQ-Ablauf. Vorschau zeigt Gerätekurier, Fahrzeugkennung, sämtliche Tagesaufträge, Angebote und zusätzliche Reservierungstage. Bestätigung der gesamten Übergabe erforderlich.
- **Fachablauf:** direkter PHP-Pfad für FDS mit zugeordneten Kunden. Alle Nicht-Angebote des Fahrzeugtags müssen reserviert (Status 9) und ohne bestehende Kurierzuweisung sein. Gemeinsame Zuordnung über die eindeutige Fahrzeug-SID zum Gerätekurier der ausgewählten Niederlassung, Status 1, Annahmezeit, Auftragsversion und Audit. Fahrzeughalter und Gerätekurier werden nicht verwechselt. Angebote werden sichtbar ausgelassen. Wie im PHP bleiben Reservierungen und Kapazitäten erhalten. Kein PDF-/Mailversand und keine behauptete Empfangsbestätigung vom Gerät.
- **Prüfungen:** fehlender/mehrdeutiger/gesperrter Gerätekurier, doppelte Fahrzeugkennung, vergangener/gesperrter/verarbeiteter Fahrzeugtag, Unternehmerfreigabe, unvollständiges Raster, fremde/fehlende Aufträge, weitere Fahrzeugreservierung, bestehende Zuweisung, Sondervermittlung, Storno/Export/Abrechnung und PHP-Bearbeitung verhindern die gesamte Übergabe. Mehrere Reservierungstage desselben Fahrzeugs werden angezeigt; die Annahme betrifft den gesamten Auftrag.
- **Speicherung:** erneute HQ-, Betriebsart-, Geräte-, Auftrags- und Revisionsprüfung unter PHP-kompatiblen Tabellensperren. Aufträge, Audit und Vorgangsbeleg gemeinsam in InnoDB. Fehler auch beim zweiten Auftrag rollen alles zurück. Verlorene Antwort kann mit derselben Kennung erneut abgerufen werden; abweichende Nutzdaten unter derselben Kennung werden abgewiesen.
- **Betriebsgrenze:** unterstützt den eindeutig globalen Modus `GLOBAL_USE_RELATED_CUSTOMER=1` mit HQ/Mitarbeiter/Mandant 0. Fehlende, abweichende oder mehrdeutige Konfiguration wird erklärt und blockiert die Übergabe. **Im aktuell verbundenen echten Bestand fehlt dieser Parameter**, daher ist dieser direkte Ablauf dort noch nicht freigegeben. Keine Betriebsart wurde umgestellt. Der gesonderte PHP-Classic-Pfad `copy_jobs_cartage` erzeugt eine zusammengefasste Tour und ist weiter offen.
- **Geprüft:** SQL-/HTTP-Prüfungen sowie Browserablauf mit synthetischen Daten, einschließlich Konflikt, Pflichtbestätigung, verlorener Antwort, Schließschutz und aktualisierter Tagesbelegung. Reale Daten nur gelesen; benötigte Schreibtabellen InnoDB und Gerätezuordnungen vorhanden. Keine echten Aufträge übergeben oder Geräte kontaktiert.
- **Weiter offen:** Classic-Tourbildung, echte Endgeräte-Empfangsprüfung, gewichtete Mehrtagesplanung, Drag-and-drop und die übrigen in der Übersicht bezeichneten Lücken.

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

- **Referenz:** erneut frisch per SSH gelesener Stand `93bf782` aus `/data/0/votian-test/html`: `customer_service.php`, `cartageNoteSendMail`, `getObjectBasedParameterValue` und `cron_send_cartage_note.php`. Angemeldete alte Kundenseite mit SMS-/Rollkartenzeit geöffnet; dort gibt es Zeitpflege, aber keine vier Adressfelder. Die neue Adresspflege ergänzt die tatsächlich von beiden Versandpfaden gelesenen Parameter. Keine ursprünglichen lokalen PHP-Quellen verwendet.
- **Einstieg:** Kunden → **Bearbeiten** → **Rollkarten-Mailadressen**. Eigene Niederlassung, Rechte 0 und 2 wie bei den Kunden-Servicevorgaben. Absender, An, Cc und Bcc anlegen, ändern oder gemeinsam entfernen. Aktuelle Werte und normalisierte Zielwerte in einer Vorher-/Nachher-Tabelle. Ungültige/unvollständige alte Adressen bleiben zum Korrigieren sichtbar; doppelte Parameter oder abweichende Geltungsbereiche verhindern automatisches Überschreiben.
- **Kompatibilität:** ausschließlich die vier Schlüssel `MAIL_CARTAGE_NOTE_MAIL_{SENDER,TO,CC,BCC}_<csId>` mit Mandant/HQ/Mitarbeiter 0. Kein Rückfall auf allgemeine Verteiler. Komma/Semikolon als Eingabetrenner, gespeicherte Kommalisten, strikte Adressprüfung, keine Anzeigenamen/Zeilenumbrüche, höchstens 100 Empfänger insgesamt und Deduplizierung über An/Cc/Bcc. Zeichen für Shell-Expansion/Quoting werden zusätzlich abgewiesen, weil der bestehende PHP-Verbraucher unmaskierte Adressen in doppelt zitierte Shell-Argumente einsetzt. Die neue Pflege startet selbst keinen Versand.
- **Wirkung auf PHP:** Der aktuelle automatische PHP-Pfad verwendet dieselben Parameter, kann Fahrzeughalter-Empfänger ergänzen und reservierte Aufträge als angenommen zuordnen. Zeit-, Bereits-versendet- und Fahrzeugfreigabeprüfungen sind im gelesenen PHP-Code durch `true` übergangen. Der neue Dialog erklärt diese Wirkung vor dem Speichern und verlangt ihre Bestätigung. Auch die bisherige native Rollkartenzeitpflege stellt jetzt klar, dass die Uhrzeit keinen laufenden Versanddienst stoppt. Ob ein Cron tatsächlich aktiv ist, wurde nicht geprüft; kein Dienst wurde gestartet, gestoppt oder geändert.
- **Speicherung:** erneute Kunden-/HQ-/Revisionsprüfung unter PHP-kompatiblen Tabellensperren; Parameter, Audit 203 und Wiederholungsbeleg gemeinsam in InnoDB. Beschreibungen und fremde/allgemeine Parameter bleiben erhalten. Verlorene Antwort lässt sich mit derselben Kennung erneut abrufen; andere Daten unter derselben Kennung werden abgewiesen. Nach Änderung verlangt der manuelle Versand eine neue Vorschau, weil sich dessen Empfängerrevision geändert hat.
- **Geprüft:** isolierte SQL-/HTTP-/Browserprüfung mit Anlage, Korrektur, Entfernung, Deduplizierung, Bestätigung, Rechten/HQ, konkurrierenden Änderungen, Rollback, Wiederaufnahme und direktem Lesen durch den nativen Mailverbraucher. Echten Bestand nur gelesen: Parameter/Belege InnoDB, weiterhin keine kundenspezifischen Mailadressen. Keine realen Vorgaben ergänzt und keine echten E-Mails verschickt.
- **Weiter offen:** eigener automatischer NG-Rollkartenversand, besondere Layouts, Endgeräte-/Classic-Übergabe und die übrigen ausdrücklich offenen Menüpunkte. Die bestehende PHP-Routine wurde nicht verändert.

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

- **Referenz:** frisch per SSH gelesener Stand `93bf782`, `vehicle_disposition.php` (Aktion 109), `ajaxReqDisposition.php`, `inc_vehicle.inc.php::cartageNoteSendMail`, `dbglobal.inc.php::getObjectBasedParameterValue` und `pdf_generic_function.php`. Alte angemeldete FDS mit Datum 14.10.2026 geöffnet; weiterhin keine Fahrzeugzeilen in der aktuellen Auswahl, daher kein gefülltes altes Aktionsmenü vergleichbar. Kein ursprünglicher lokaler PHP-Stand.
- **Einstieg:** Verwaltung → Fahrzeugdisposition → **Rollkarte** → **PDF herunterladen** bzw. **Per E-Mail senden**. Reservierte, angenommene oder beide Auftragsgruppen wie bisher. Rechte 27/4; fremde Dispositionsniederlassungen benötigen den bestehenden zusätzlichen Freigabeablauf. Die Rollkarte umfasst das gesamte Fahrzeug, unabhängig vom Kundenfilter.
- **PDF:** eigenständiger, serverseitiger Standardbeleg mit eingebetteter Schrift, vollständigen Auftrags-/Adress-/Artikel-/Inkassoangaben und Unterschriftszeile. Jeder Auftrag beginnt auf einer neuen Seite; lange Texte und Artikel laufen mit Auftragskennung und Seitennummern weiter. Keine externen Ressourcen oder ausführbaren Inhalte. Nicht darstellbare Zeichen werden gemeldet, nicht still ersetzt. Maximal 500 Seiten und 10 MB. Die Versandvorschau zeigt direkt gerenderte Seiten desselben PDF-Anhangs, mit Vor-/Zurückblättern und Download. Die Vorschau ist damit auch im eingebetteten Browser sichtbar. Technisch [Apache PDFBox 3.0.8](https://pdfbox.apache.org/3.0/getting-started.html), Schrift aus dessen mitgelieferten Ressourcen.
- **Versandvorgaben:** Kunde aus den tatsächlich enthaltenen Aufträgen ausdrücklich auswählbar. Wie im aktuellen PHP ausschließlich `MAIL_CARTAGE_NOTE_MAIL_TO_<csId>`, `_CC_<csId>`, `_BCC_<csId>` und `_SENDER_<csId>` mit HQ/Mitarbeiter 0; kein Rückfall auf allgemeine Empfänger oder andere Kunden. Fehlende/mehrdeutige/ungültige Angaben verhindern die Vorschau. Adressen werden unabhängig von Großschreibung über An/Cc/Bcc dedupliziert, höchstens 100 insgesamt. Bcc wird nicht im Nachrichtenkopf offengelegt. Die SMTP-Verbindung verwendet die vorhandene `.env`-Konfiguration; Absender und Antwortadresse stammen aus der kundenspezifischen Rollkartenvorgabe.
- **Vorschau und Bestätigung:** Absender, alle Empfänger einschließlich Cc/Bcc, Betreff, Anhang, Auftragszahl und alle enthaltenen Kunden sichtbar. Zwei Bestätigungen für Empfänger/bisherige Versandversuche und die Freigabe der vollständigen Rollkarte aller enthaltenen Kunden. Vorschau 15 Minuten gültig; maximal 20 gleichzeitig. Keine automatische Mail beim Öffnen, Herunterladen oder Erzeugen der Vorschau.
- **Einmaliger SMTP-Versuch:** Vor dem Versand erneute Prüfung der Rollkarteninhalte, Empfänger und HQ-Freigabe unter PHP-kompatiblen Tabellensperren. Dauerhafter Startbeleg und Audit in `genericdatacontainer` werden vor SMTP gemeinsam committed; anschließend Status `SENT` oder `UNCERTAIN`. Bei Abbruch zwischen SMTP und Statusspeicherung bleibt `STARTED`. Dieselbe Versandkennung startet auch nach Neustart keinen zweiten SMTP-Versuch. Unbestätigte Übergaben erfordern Zustellungs-/SMTP-Prüfung vor einer bewusst neuen Vorschau. `SENT` bedeutet SMTP-Annahme, keine bestätigte Zustellung. Eigene letzte zehn Versuche pro Fahrzeugtag sind auch nach Wiederöffnung sichtbar. Nur die Belegtabelle wird geschrieben und benötigt InnoDB; keine Geschäftsdatenänderung.
- **Bestandsgrenze:** echte Daten ausschließlich gelesen. `genericdatacontainer` ist InnoDB, Inhaltsspalte `TEXT`; derzeit **keine** kundenspezifischen Rollkarten-Mailparameter vorhanden. Die nötigen realen Empfänger/Absender müssen vor Nutzung hinterlegt werden. Keine echten Adressen ergänzt, keine realen Nachrichten versendet. Die native Pflege der Versandparameter wurde inzwischen ergänzt, siehe folgenden Abschnitt zur Kundenpflege. Ein eigener automatischer NG-Versandlauf bleibt offen.
- **Weiter offen:** besondere kundenspezifische Rollkartenlayouts, Übergabe an Endgeräte bzw. Erzeugung einer Classic-Tour (`sendCartageNote` verändert zusätzlich Auftragsstatus/Zuordnung), grafische Drag-and-drop-Disposition, Mehrtagesverbuchung mit Artikelgewicht und die übrigen Lücken der Übersicht.

## Fahrzeugdisposition: Mehrtagesplanung – 15. Oktober 2026

- **Referenz:** erneut frisch gelesener SSH-Stand `93bf782`: `inc_vehicle.inc.php`, `inc_job.inc.php`, `ajaxReqDisposition.php` und `vehicle_disposition.php`. Alte angemeldete PHP-UI mit vergangenem Datum geöffnet; für die aktuelle Auswahl keine Fahrzeugzeilen vorhanden. Daher kein gefüllter Mehrtagesdialog zum visuellen Vergleich. Kein ursprünglicher lokaler PHP-Bestand verwendet.
- **Einstieg:** Verwaltung → Fahrzeugdisposition → **Tag öffnen** → am reservierten Auftrag **Tage / Fahrzeug planen**. Auch beim Öffnen über einen Folgetag wird die gesamte bestehende Reservierung geladen. Ziel ist dasselbe oder ein anderes Fahrzeug derselben ausgewählten Dispositionsniederlassung. Rechte 27/4/7, bei fremder Niederlassung zusätzlich der bestehende HQ-Freigabeablauf.
- **Aufteilung:** volle Auftragsdauer auf höchstens 60 aufeinanderfolgende Kalendertage; Wochenenden werden wie im PHP mitgezählt. Tagesmaximum aus `JB_SERVICE_INSTALLAION_MAX_TIMEUNITS` mit Kunden-/HQ-/globalem Rückfall, ansonsten 48 Zeiteinheiten. Erste Startzeit wird auf das Raster aufgerundet. Folgetage verwenden `CS_DAY_TIMEUNIT_START` im PHP-Format `HH_UU` (zweite Zahl ist der Rasterindex, keine Minutenzahl), ersatzweise den Beginn des ersten Kundenzeitfensters. Restdauer bleibt vollständig erhalten; keine Kürzung bei Überlappungen oder am Tagesende.
- **Prüfung und Vorschau:** alle alten und neuen Fahrzeugtage gemeinsam; fehlendes/unvollständiges Raster, Vergangenheit, Tages-/Verarbeitungssperren, Belegung, fehlende erwünschte Kundenbeziehung und inaktive Kundeneinsatzzeiten verhindern die gesamte Änderung. Alte und neue Reservierungszeiten, Plantermin und betroffene Tageskapazitäten sichtbar. Pflichtbestätigung vor Speicherung. Ein Fahrzeugwechsel setzt Status 9 ohne bestehende Kurierzuweisung voraus; Auftragsstatus, Rechnung/Export/Storno, PHP-Bearbeitung und Sondervermittlung werden erneut geprüft.
- **Speicherung:** alle bisherigen Reservierungen des Auftrags gemeinsam ersetzen, Plantermin und Auftragsversion aktualisieren und freie Kundenblöcke für sämtliche betroffenen Tage neu berechnen. Andere Aufträge, Auftragsdauer, Gewichte/Stellplätze, Tagesbemerkungen und Freigaben bleiben erhalten. InnoDB-Schreibprüfung, gemeinsame Transaktion und Tabellenlocks gegenüber PHP, Revision aller Eingabebestände, Audit und einmaliger Vorgangsbeleg. Eine verlorene Antwort kann ohne Doppeländerung erneut abgerufen werden; bei Fehlern werden alle Tage zurückgerollt.
- **Grenzen:** zunächst bestehende Montage-/FDS-Reservierungen **ohne Artikelgewicht**. Der aktuelle PHP-Mehrtagspfad stellt beim Entfernen keine Nutzlast wieder her und belastet beim Einfügen wiederholt den ersten Tag; für gewichtete Aufträge lässt sich daraus keine konsistente Tagesverbuchung übernehmen. Jeder einzelne von null abweichende Artikelgewichtswert wird deshalb abgewiesen. Mehrere Quellfahrzeuge, unterbrochene Tagesreservierungen, fehlende Tagesbestände und angenommene/angebotene Aufträge sind nicht Teil dieses Ablaufs. Keine Neuanlage bisher unreservierter Aufträge, keine Sammelumsortierung mehrerer Mehrtagesaufträge und kein Versand.
- **Weiter offen:** Mehrtagesverbuchung mit Artikelgewicht, grafische Drag-and-drop-Disposition, Sonderzuweisungen, kundenspezifische Rollkartenlayouts und Endgeräteübergabe sowie die übrigen Lücken der Übersicht. Schreibtests ausschließlich mit isolierten Daten.

## Fahrzeugdisposition: Belegung umplanen – 15. Oktober 2026

- **Referenz:** frischer SSH-Stand `93bf782` unter `/data/0/votian-test/html`, insbesondere FDS-Menüaktionen 106/110, `sortVehicleTimelineByNewOrdertimes`, `moveCartageNote`, Reservierungs-/Verfügbarkeitshelfer und Artikelgewichts-/Mehrtageshelfer. Der auskommentierte ältere Sortierpfad wurde nicht übernommen. Alte angemeldete UI geprüft; aktuelle Auswahl ohne Fahrzeuge, daher kein gefüllter Alt-Sortierdialog sichtbar.
- **Einstieg:** Verwaltung → Fahrzeugdisposition → **Belegung umplanen** in der Fahrzeugzeile. Rechte 27/4/7, vorhandener Tagesbestand und vollständiges Raster erforderlich. Alle reservierten Aufträge des Fahrzeugtags, unabhängig vom Kundenfilter. Freigegebene andere Dispositionsniederlassungen werden über den bestehenden HQ-Ablauf geprüft.
- **Umsortierung:** Reihenfolge per Auf-/Ab-Pfeilen und Planzeit pro Auftrag. Minuten werden wie im aktuellen PHP auf das Dispositionsraster aufgerundet, danach müssen die Zeiten strikt aufsteigen. Eine überlappende Reservierung wird am nächsten Planbeginn gekürzt; `jb_timeunits` bleibt unverändert. Vorschau nennt Kürzungen und Rundungen. Gespeichert werden Plantermine und Raster, ohne bestehende zulässige Zuweisungen zu ändern.
- **Fahrzeugübertragung:** ausdrückliche Zielauswahl mit ID, Kennung und Kennzeichen innerhalb derselben Dispositionsniederlassung. Reservierungen werden mit voller Auftragsdauer an den gespeicherten Planterminen auf das Ziel gesetzt. Restnutzlast Quelle/Ziel wird um die Summe aller `trat_weight` angepasst (wie PHP ohne Mengenmultiplikation). Bereits vorhandene Zielbelegungen, andere Tage, Stellplätze, höhere Sperrbits und Bemerkungen bleiben erhalten. Verfügbarkeitsblöcke aller betroffenen Kunden werden nur für die beiden Tage neu berechnet.
- **Absicherung:** Vorschau mit Pflichtbestätigung, Optimistic-Lock-Prüfung von Fahrzeugen, Aufträgen, Reservierungen, Artikelgewichten, Kundenzuordnungen, Zeitfenstern und Parametern. Einmaliger Vorgangsbeleg ermöglicht Wiederholung nach verlorener Antwort. Schreibdaten müssen InnoDB sein; alle Änderungen samt Audit laufen gemeinsam unter Tabellenlocks gegenüber PHP. Bei Fehlern vollständiges Rollback. Vergangene/gesperrte/verarbeitete Tage, fremde oder unvollständige Raster, Rechnung/Export/Storno/PHP-Bearbeitung, Sondervermittlung und unzulässige Auftragsstatus werden abgewiesen.
- **Bewusst enger als PHP:** Fahrzeugübertragung erst nach Rücknahme einer bestehenden Zuweisung/Unternehmerfreigabe (Status 9 ohne Kurier); keine Angebote oder angenommenen Aufträge. Die Kunden müssen dem Ziel als erwünscht zugeordnet sein und die Reservierungen in aktiven Kundeneinsatzzeiten liegen. Ungenügende Restnutzlast blockiert die gesamte Übertragung, während der PHP-Helfer seinen Gewichtskonflikt teilweise toleriert. Kein stilles Entfernen von Mehrtagesreservierungen: mehrere Fahrzeuge/Tage, unterbrochene Reservierungen und Dauern über dem kunden-/HQ-/globalen `JB_SERVICE_INSTALLAION_MAX_TIMEUNITS` (Fallback 48) werden abgewiesen.
- **Weiter offen:** vollständige grafische Drag-and-drop-Disposition, Mehrtagesplanung mit Artikelgewicht, Sonderzuweisungen, kundenspezifische Rollkartenlayouts, Endgeräteübergabe sowie die übrigen Spezialaktionen der Übersicht. Diese Umsetzung versendet nichts.

## Fahrzeugdisposition: Standardrollkarten – 15. Oktober 2026

- **Referenz:** ausschließlich frisch per SSH gelesener Stand `93bf782` unter `/data/0/votian-test/html`: `admin/vehicle_disposition.php`, `admin/pdf_generic_function.php` (`getCartageNote`), `include/inc_vehicle.inc.php` (`getVehicleJobList`) und `include/inc_job.inc.php` (Zeitfenster). Die alte angemeldete Dispositions-UI mit Datum 14.10.2026 und geöffnetem Auswahlmenü wurde geprüft; die aktuelle Auswahl zeigt keine Fahrzeugzeilen, daher kein visueller Vergleich einer ausgefüllten Altrollkarte möglich.
- **Einstieg:** Verwaltung → Fahrzeugdisposition → **Rollkarte** in der Fahrzeugzeile. Rechte 27 und 4 erforderlich, auch ohne Tagesdatensatz erreichbar. Freigegebene andere Dispositionsniederlassungen nutzen dieselbe serverseitige Freigabeprüfung; die Sitzungsniederlassung bleibt erhalten.
- **Auftragsauswahl:** alle reservierten Status-0/9-Aufträge ohne Angebot am gewählten Fahrzeugtag sowie Status-1-Aufträge am gewählten Auftragsdatum, deren zugewiesener Kurier dieselbe SID wie das Fahrzeug hat. Storno-Werte null/0/1/3 und positive Zeiteinheiten wie im PHP. Reservierte und angenommene Aufträge werden als zwei Gruppen nach Planzeit sortiert; Mehrfachreservierungen ergeben keine doppelten Positionen. Beide Gruppen auch einzeln wählbar. Fahrzeug-, Kurier-, Kunden- und Auftragsniederlassung werden geprüft. Die Rollkarte umfasst das Fahrzeug unabhängig vom Kundenfilter.
- **Inhalt:** Auftrags-/Folgeauftragsnummer, Plantermin, Kostenstelle, Abhol- und Zieladresse mit Kontakt/Telefon/Etage und Bemerkung, Services, Zielartikel mit Beschreibung aus `trat_remark` und Artikelkennung aus `trat_serialno`, Menge und Packstücksumme, Zusatzinformation und Unterschriftszeile. Kundenzeitfenster unterstützen die drei PHP-Verfahren: ±2 Stunden mit Arbeitsbeginn-Korrektur, Kunden-Tagesfenster oder gespeicherter `timewindow_name`. Fehlende Termine/Fenster werden gemeldet. Fehlende oder mehrdeutige erste/zweite Stationen verhindern eine unvollständige Druckausgabe.
- **Inkasso:** wie `getCartageNote` positiver offener Nettobetrag abzüglich Zahlungen, multipliziert mit dem dort festen Faktor **1,19**. Als „Altverfahren: offener Nettobetrag einschließlich 19 %“ ausdrücklich gekennzeichnet. Das ist keine neue Steuer-/Abrechnungsberechnung. Nullbeträge und leere Packstückwerte werden verträglich behandelt.
- **Ausgabe:** geschützte HTML-Vorschau, Download desselben Standes und **Drucken / PDF über den Browserdruckdialog**. Standzeit und Auswahl stehen im Dokument; „Aktuellen Stand laden“ aktualisiert die Ausgabe. Direkter PDF-Download und E-Mail-Anhang inzwischen ergänzt, siehe Abschnitt zum Rollkartenversand oben. Leere oder fehlgeschlagene Abfragen lassen sich nicht drucken/exportieren. Texte werden maskiert; Vorschau erlaubt keine Skripte, Formulare oder externen Ressourcen. Vorschau/Download bleiben reine Leseoperationen; der separate Mailversand ist ausdrücklich zu bestätigen. Keine Reservierungs-, Zahlungs-, Auftrags- oder Tagesänderung. Maximal 300 Aufträge und 1000 Artikel je Auftrag, keine stille Kürzung.
- **Weiter offen:** besondere kundenspezifische PHP-Rollkartenlayouts (abweichende Konfiguration wird angezeigt), Endgeräteübergabe, Mehrtagesumsortierung/-übertragung mit Artikelgewicht und grafische Drag-and-drop-Disposition. Eintägige Umsortierung/Übertragung inzwischen ergänzt, siehe oben. Der Systemdruckdialog und die tatsächliche PDF-Speicherung werden nicht automatisiert bedient; Vorschau und HTML-Download sind im Browser geprüft.

## Fahrzeugdisposition: Niederlassungswechsel – 15. Oktober 2026

- **Referenz:** frischer SSH-Stand `93bf782` aus `/data/0/votian-test/html`; `admin/vehicle_disposition.php`, `include/html.inc.php`, `include/dbglobal.inc.php`, `include/auth.inc.php` und `include/global.inc.php`. Alte angemeldete Oberfläche: Niederlassungsmenü geöffnet, Wechsel B → HH am vergangenen Dispositionstag 14.10.2026 geprüft. Kein ursprünglicher lokaler PHP-Bestand verwendet und keine Tagesneuanlage ausgelöst.
- **Zugang:** volles Dispositionsrecht 27; für andere Niederlassungen zusätzlich Masterrecht 10 und exakte Mitgliedschaft in `emp_headquarters`. Der in `headquarters.hq_admin` eingetragene Administrator darf die Niederlassungen seines Mandanten wählen. Die FDS registriert in PHP keine zusätzliche Pflichtspalte in `employeerights`; die neue Auswahl übernimmt diese tatsächliche Regel. Mandantenfremde, fehlende oder mehrdeutig zugeordnete Niederlassungen werden serverseitig abgewiesen. Aktuelle Mitarbeiterrechte werden mit den Sitzungsrechten geschnitten, nicht erweitert.
- **Ansicht:** eigener Niederlassungswähler; Gruppen und gewählter Tag bleiben erhalten, Kunde/Transporteur/Zone/Suchtext werden beim Wechsel zurückgesetzt. Fahrzeug-/Kunden-/Transporteurslisten und Tagesdetails kommen ausschließlich aus der ausgewählten Niederlassung. Leere Niederlassungen bleiben leer. Die PHP-Vorgabe zur Anzeige ausgeschlossener Fahrzeuge wird weiterhin aus der ursprünglichen Niederlassung gelesen. Auswahl gilt pro Anfrage/Ansicht und verändert weder Sitzung noch andere Browser-Tabs. Rückkehr zur eigenen Niederlassung und erneutes Anwenden der persönlichen Startauswahl möglich.
- **Tagesaktionen:** Sperren/Freigaben, Bemerkungen, Unternehmerdisposition samt Auftragsvorschau und kundenweite Tagesaktion auch in freigegebenen Niederlassungen. Zielniederlassung steht im Dialogtitel. Rechte, Mitarbeiterzuordnung, Freigabeliste und Mandantengrenze werden beim Speichern erneut innerhalb der Tabellensperre geprüft. Vorschau, Revision und wiederholbarer Vorgangsbeleg bleiben an den Zielbestand gebunden; Audit enthält den ursprünglichen Benutzer und die ausgewählte Niederlassung. Verlorene Antwort erlaubt Wiederholung mit identischer Kennung; kein Wechsel während offenem Dialog/ungeklärter Speicherung.
- **Grenzen:** persönliche Startparameter werden weiterhin nur für das eigene Zentralenkonto in der ursprünglichen Niederlassung gepflegt. Stammdaten- und Auftragsdialoge sind aus einer anderen Dispositionsniederlassung noch nicht freigegeben; Auftragsnummer/Belegung bleiben sichtbar, dort ohne Bearbeitungslink. Drag-and-drop, Rollkartenübergabe an Endgeräte / Classic-Touren, Mehrtagesumsortierung/-übertragung mit Artikelgewicht, eingeschränktes Recht 28 und Unternehmerzugänge sind weiterhin offen. Die bestehende Sammelaktion lehnt Fahrzeuge mit Kundenbeziehungen über mehrere Niederlassungen ab.
- **Bestandsprüfung:** echte Daten nur gelesen; neun freigegebene Niederlassungen und 339 Fahrzeuge in der geprüften anderen Niederlassung. Keine realen Tages-, Auftrags-, Parameter- oder Schemaänderungen; alle Schreibtests gegen wegwerfbare MariaDB bzw. synthetische Browserfixture.

## Fahrzeugdisposition: Gruppen und persönliche Startauswahl – 15. Oktober 2026

- **Referenz:** frischer SSH-Stand `93bf782`, aktuelle `admin/vehicle_disposition.php`, `include/inc_group.inc.php`, Mitarbeiterparameterpflege in `admin/employee.php` sowie `getParameterValue` in `include/dbglobal.inc.php`. Alte angemeldete UI mit geöffnetem Gruppen-/Niederlassungsmenü geprüft. Ausschließlich aktuelle Serverquellen verwendet; vergangenes Dispositionsdatum vermeidet die automatische PHP-Tagesneuanlage.
- **Gruppenfilter:** Verwaltung → Fahrzeugdisposition → Dispositionsgruppe. Wie im PHP werden readonly-Gruppen des Mandanten angeboten; gleichnamige Einträge sind durch ihre Gruppennummer unterscheidbar. Gruppenmitgliedschaft über das exakte `,ID,`-Format, keine implizite Vererbung über Untergruppen. Kundenauswahl umfasst eigene Gruppenkunden mit nichtleerem/nichtnull Parent und Firmenname ungleich `EXTERN`, einschließlich Kunden ohne Fahrzeugzuordnung. Leere Gruppen liefern eine leere Fahrzeugliste. Ohne einzelnen Kunden zeigt NG die Fahrzeuge aller zulässigen Kunden dieser Gruppe; mit Kunde nur dessen Fahrzeuge. „Keine Einschränkung“ erhält die bisherige Fahrzeugübersicht. Gruppenwechsel setzt Kunde, Zone und Transporteur zurück. Maximal 1000 Gruppen und 500 Kunden/Fahrzeuge/Transporteursoptionen; keine stille Kürzung.
- **Persönliche Startauswahl:** vorhandene Schlüssel `MASK_DISPOSITION_INIT_GROUP` und `MASK_DISPOSITION_INIT_CS`, nach eigenem Mitarbeiter und eigener Niederlassung. Beim Öffnen werden gültige Vorgaben gelesen und angewendet. Dialog zeigt aktuelle und gespeicherte Auswahl; explizites Speichern, Entfernen (beide Werte 0) und erneutes Anwenden möglich. Die gleichen Parameter werden von PHP gelesen. Ein Startkunde benötigt eine passende Gruppe; auch alleinige Gruppenvorgabe möglich. Datum, Zone, Dienstleistungen, Transporteur und Suchtext werden nicht persistiert. Reine Filterwechsel führen keine Schreiboperation aus.
- **Veraltete Vorgaben:** gelöschte, nicht mehr freigegebene oder mandantenfremde Gruppe wird mit Hinweis verworfen. Nicht mehr passender/fremder Kunde wird entfernt, die gültige Gruppe bleibt. Ungültige Zahlen-/Listenwerte werden nicht ungeprüft übernommen. Doppelte Parameter verhindern die Pflege bis zur Bestandsklärung; kein automatisches Zusammenführen. Es erfolgt beim Lesen keine Reparatur im Bestand.
- **Speicherung:** Recht 27; Zielmitarbeiter und Niederlassung kommen ausschließlich aus der Sitzung. Mitarbeiter-/Benutzerzuordnung wird erneut geprüft; Rechte-, Zugangsdaten- und andere Mitarbeiterparameter werden nicht bearbeitet. Beide Schlüssel, Audit 203 und Wiederholungsbeleg werden atomar unter kurzer PHP-kompatibler Tabellensperre gespeichert. Nur `parameter` und `genericdatacontainer` werden geschrieben und benötigen InnoDB. Konfliktprüfung vor Änderung; Wiederholung nach verlorener Antwort erzeugt keinen zweiten Vorgang. Bestehende Parameterbeschreibungen und andere Metadaten bleiben erhalten. Keine Schemaänderung.
- **Prüfung/Grenzen:** echte Bestandsabfragen funktionieren mit zwölf Gruppen und 82 Fahrzeugen; geprüfte Gruppe aktuell ohne Kunden/Fahrzeuge. Echte Daten nur gelesen. Niederlassungswechsel inzwischen ergänzt, siehe oben. Eingeschränktes Recht 28, Unternehmerzugänge, Drag-and-drop-Disposition, Rollkartenübergabe an Endgeräte / Classic-Touren, Mehrtagesumsortierung/-übertragung mit Artikelgewicht und übrige Spezialaktionen bleiben offen. Die persönliche Startauswahl gilt derzeit für das eigene Zentralenkonto in seiner ursprünglichen Niederlassung.

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

- **Referenz:** erneut frisch bestätigter SSH-Stand `93bf782`, `admin/vehicle_disposition.php`, `include/ajaxReqDisposition.php`, `include/inc_vehicle.inc.php` und `mcConvertSel2Num` im aktuellen `global.inc.php`. Alte angemeldete Dispositionsoberfläche und Service-Filter aufgerufen. Ein vergangener Tag verhindert die automatische PHP-Neuanlage von Tagesrastern; keine alten Bestandsquellen verwendet.
- **Filter:** Verwaltung → Fahrzeugdisposition: Dienstleistungen mit UND-Verknüpfung der Bestandsbits, Transporteur und kundeneigene Servicezone. Zone 0 ist eine konkrete Zone. Wochen-/Tageszeitvorgaben berücksichtigen ausdrücklich inaktive Fenster (9999), konkrete Zonen und uneingeschränkte Fenster; gesperrte Beziehungen erscheinen im Zonenfilter nicht als verfügbar. Dieselben validierten Tageszeiten und Standardfenster wie in der nativen Einsatzzeitpflege. `DISPOSITION_SHOW_EXCLUDED_VEHICLES` mit Niederlassungswert und globalem Rückfall steuert ausgeschlossene Fahrzeuge. Leere Auswahl bedeutet keine Einschränkung, Zurücksetzen erhält den gewählten Kunden und Tag. Persönliche Startauswahl für Gruppe/Kunde inzwischen ergänzt, siehe oben.
- **Kundentag:** nach Kundenauswahl „Kundentag sperren / freigeben“. Die Ansicht enthält alle vorhandenen Fahrzeugzuordnungen, auch gesperrte Beziehungen und ausgeblendete Fahrzeuge. Wie im PHP-AJAX-Aufruf begrenzen sichtbare Filter die Sammelaktion nicht. Vorschau je Fahrzeug und Anzeige weiterer betroffener Kunden; ausdrückliche Bestätigung vor Speicherung. Das bestehende Kennzeichen `vha_day_blocked` wird für Kunde und Datum in `genericdatacontainer` gepflegt. Aktueller Fahrzeugstatus und Kundenkennzeichen werden getrennt angezeigt, da Einzeländerungen Abweichungen verursachen können.
- **Schreibwirkung:** ausschließlich Bit 0 von `vha_blocked` plus Kundenkennzeichen, Audit 86 und Wiederholungsbeleg. Höhere Sperrbits, Unternehmerdisposition, Aufträge, Raster, Reservierungen, Kapazitäten und Bemerkungen bleiben erhalten. Keine automatische Anlage fehlender Tage und kein Nachrichtenversand. Später hinzugefügte Fahrzeugzuordnungen werden nicht rückwirkend gesperrt; sie müssen erneut geprüft werden. Auch die PHP-Rasterneuanlage erbt das Kennzeichen nicht automatisch.
- **Konsistenz:** Recht 27 und ausschließlich eigene Niederlassung, einschließlich aller Mitzuordnungen. Mindestens eine eindeutige Zuordnung und für jedes Fahrzeug genau ein unverarbeiteter Tagesdatensatz erforderlich. Vergangenheit, fehlende/mehrdeutige Tage, ungültige Sperrwerte und doppelte Kundenkennzeichen verhindern die gesamte Aktion. Versionsprüfung umfasst alle Beziehungen, Fahrzeug-/Tagesstände und das Kundenkennzeichen. InnoDB für beide Schreibtabellen; kurze gemeinsame Tabellensperre schließt parallele PHP-Schreiber aus. Fehler rollen alle Änderungen zurück. Wiederholung nach verlorener Antwort liefert den vorhandenen Vorgangsbeleg.
- **Bestandsprüfung:** eigene Niederlassung lesend geprüft: 82 Fahrzeuge, 80 Transporteursoptionen, eine Kundenauswahl und aktuell keine zusätzlichen Dienstleistungen. Der Kundentag ist lesbar; fehlende Tagesbestände werden angezeigt. Keine realen Geschäftsdaten geändert.
- **Weiter offen:** grafische Drag-and-drop-Disposition, Rollkartenübergabe an Endgeräte / Classic-Touren, Mehrtagesumsortierung/-übertragung mit Artikelgewicht, weitere Spezialaktionen, eingeschränktes Recht 28 und Unternehmerzugänge. Die übrigen Lücken der Übersicht bleiben bestehen.

## Fahrzeugdisposition: Tagessteuerung – 15. Oktober 2026

- **Referenz:** frisch per SSH bestätigter Stand `93bf782`, ausschließlich `/data/0/votian-test/html`: `admin/vehicle_disposition.php`, `include/ajaxReqDisposition.php`, `include/inc_vehicle.inc.php` und Bemerkungsspeicherung über `ajaxReqLib.php`. Alte angemeldete Dispositionsseite samt Auswahlfenster geöffnet. Sie zeigt Datum, Kunden-/Gruppen-/Niederlassungswahl, Servicefilter, Skalierung und Tagessperre, in der aktuellen Gruppenwahl aber keine Fahrzeugzeilen. Fahrzeugaktionen und Folgewirkungen zusätzlich im aktuellen PHP geprüft.
- **Einstieg:** Verwaltung → **Fahrzeugdisposition**, uneingeschränktes Dispositionsrecht **27**, nur eigene Niederlassung. Tag wählen, nach Kundenzuordnung oder Fahrzeug/Kennzeichen/Bemerkung filtern, 50 Zeilen je Seite. Bis 500 Fahrzeuge/Kundenauswahlen; größere Ergebnisse werden gemeldet. Fahrzeugstamm direkt mit zusätzlichem Recht 1 erreichbar.
- **Tagesübersicht:** gespeicherte Restkapazität (Gewicht/Stellplätze), Tagessperre, Unternehmerdisposition, Verarbeitungssperre und Bemerkung. Detail mit 24-Stunden-Belegungsleiste und zusammenhängenden Reservierungsabschnitten, Auftragsstatus und Fahrzeugkennung; native Auftragsöffnung zusätzlich Recht 4. Fehlende/fremde Aufträge erscheinen ohne fremde Auftragsnummer als nicht zugänglich. Unbelegte Rasterzeiten werden ausdrücklich nicht als freie Kundenzeitfenster bezeichnet. Rasterlücken und Abweichung vom globalen Zeitraster werden sichtbar gemeldet.
- **Tagesaktionen:** Fahrzeug für den Tag blockieren/freigeben (Bit 0) und Bemerkung bis 255 Zeichen. Andere Sperrbits, `vha_lock`, Kapazität und Reservierungen bleiben erhalten. Änderungen nur ab dem aktuellen Datenbankdatum und bei vorhandener eindeutiger Tageszeile ohne laufende Verarbeitung. Fehlende Tagesdaten werden nicht beim Lesen angelegt; Erstellung über die bereits vorhandenen Kundenzuordnungen/Einsatzzeiten. Kapazitäten werden hier angezeigt, nicht manuell überschrieben.
- **Unternehmerdisposition:** zusätzlich Rechte 4/7; Freigabe nur für entsprechend freigeschalteten Transporteur. Bit 1 bedeutet wie in PHP **Freigabe für den Unternehmer**, trotz des missverständlichen Spaltennamens `vha_blocked`. Beim Einschalten wechseln passende reservierte Nicht-Angebotsaufträge von Status 9 auf 0 und erhalten den Transporteur/Fahrzeugkennung; beim Entziehen wechseln dessen passende Status-0-Aufträge zurück auf 9 und verlieren die Zuweisung. Angenommene/erledigte Aufträge und Angebote bleiben unverändert. Eine Vorschau zeigt jeden betroffenen Auftrag und verlangt die Bestätigung der Auswirkungen; die Wirkung betrifft das ganze Fahrzeug, auch bei gesetztem Kundenfilter. Mehrtägige Reservierungen desselben Fahrzeugs werden eigens genannt. Es werden dabei wie in den geprüften PHP-Helfern keine Endgerätebefehle oder Rollkarten versendet.
- **Schutz gegenüber Altabläufen:** fremde/fehlende Aufträge, abweichende Zuweisung, Reservierungen auf anderen Fahrzeugen, Fern-/Auto-/Globalvermittlung, Export/Rechnung/Gegenbuchung, Rechnungssperre und laufende PHP-Bearbeitung verhindern widersprüchliche Übergaben. Standard-Sperrfrist fünf Minuten, wie in der bestehenden nativen Auftragsbearbeitung. Auftragsversionen werden fortgeschrieben. Eigene Niederlassung, Raster, Belegung, Auftragsstand und Freigabe werden beim Speichern erneut geprüft; überholte Vorschauen werden abgewiesen.
- **Speicherung:** kurze PHP-kompatible Tabellensperre; Tag, Auftragsänderungen, Audit und Wiederholungsbeleg gemeinsam in vorhandenen InnoDB-Tabellen. Bei Fehlern vollständiges Rollback. Die MyISAM-Rechnungstabelle wird nur gelesen. Wiederholung nach verlorener Antwort führt denselben Vorgang nicht erneut aus; Eingaben und Schließen bleiben bis zur Klärung geschützt. Ausschließlich `DatabaseService`, keine Schemaänderungen.
- **Bestandsprüfung:** echte Daten nur gelesen. 82 Fahrzeuge und eine Kundenauswahl in der geprüften Niederlassung; für den 15.10.2026 keine vorhandenen Tageszeilen. Diese Bestandslücke wird angezeigt; die zuvor gefundene ungültige Tageszeit-Zuordnung wurde nicht eigenmächtig geändert.
- **Weiter offen:** vollständige grafische FDS mit Drag-and-drop-Zuordnung/Verschiebung, Rollkartenübergabe an Endgeräte / Classic-Touren, Mehrtagesumsortierung/-übertragung mit Artikelgewicht und den weiteren Auftragsaktionen. Recht 28 mit frei gespeichertem SQL sowie Unternehmer-Logins werden nicht über diesen Zentralenbereich freigeschaltet.

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

- **Referenz:** frisch per SSH bestätigter PHP-Stand `93bf782`, ausschließlich `/data/0/votian-test/html`: `admin/vehicle_customer.php`, `admin/courier_vehicle.php`, `include/inc_vehicle.inc.php`, `metatypeGetMappedValues` und `tools/setFDSVehicleAvailability_HTG.php`. Die angemeldete alte Zuordnungsseite lieferte für das vorhandene Fahrzeug 9912 HTTP 500. UI-Felder und Folgewirkungen deshalb zusätzlich anhand des aktuellen Servercodes geprüft.
- **Einstieg:** Kuriere → Transporteur bearbeiten → Fahrzeug → **Kundenzuordnungen / Einsatzzeiten**, Recht 1. Kundensuche, Anlegen, Sperren/Bevorzugen, Bemerkung, Liste mit Filter und Mehrfachentfernung. Favoriten werden je Kunde fortlaufend eingeordnet. Nur eigene Niederlassung; auch bestehende Mitzuordnungen und bei Neunummerierung betroffene Fahrzeuge werden auf diese Grenze geprüft.
- **Wochenplan:** Montag bis Sonntag je kundenspezifischem Tageszeitfenster, mit Standardfenstern als Rückfall. „Alle Zonen“, konkrete Servicezone einschließlich Zone 0 oder „Nicht aktiv“. Gleicher `csvh_day_times`-Bestandsaufbau; unbekannte Zonen, doppelte Zellen, ungültige Tageszeiten und mehr als 255 Zeichen werden nicht still bereinigt. Maximal 50 Kunden je Fahrzeug und zwölf Tageszeitfenster. Fehlerhafte bestehende Vorgaben bleiben als Hinweis sichtbar, ohne beim Lesen geändert zu werden.
- **Verfügbarkeit:** nach bestätigter Änderung native Neuberechnung der freien FDS-Zeitblöcke für heute plus 59 Tage. Bestehende reservierte Abschnitte sind maßgebend; Tageskapazität, Restgewicht/-stellplätze, Sperren und Bemerkungen bleiben erhalten. Neue Tage erhalten leere Raster und Fahrzeugkapazität. Zeitblöcke berücksichtigen Tageszeitgrenzen, Zonen, deaktivierte Fenster und die aktuelle Uhrzeit; zusätzlich zusammenhängende Blöcke über Tageszeitgrenzen entsprechend der PHP-Auswertung. Gesperrte Kunden erhalten keine verfügbaren Blöcke. Keine PHP-Shellaufrufe oder neu gestarteten Hintergrunddienste.
- **Entfernung:** Vorschau nennt Anzahl und IDs der betroffenen Aufträge sowie reservierte Abschnitte. Entfernt werden nur gewählte Kundenbeziehungen und deren abgeleitete Verfügbarkeit für dieses Fahrzeug. Reservierungen werden ausschließlich für dieses Fahrzeug und passende Aufträge der eigenen Niederlassung gelöst. Andere Kunden, fremde Aufträge und dasselbe Auftragskennzeichen auf anderen Fahrzeugen bleiben erhalten. Auftragsdaten selbst werden nicht verändert. Nach Wegfall der letzten Beziehung werden keine neuen Verfügbarkeitstage angelegt.
- **Speicherung:** InnoDB für `customervehicle`, `vehicledisposition`, `vehicleavailability`, `vehicleavailabilitytimeunits`, `parameter` und `genericdatacontainer`; gemeinsamer Commit/Rollback unter PHP-kompatibler Tabellensperre. Vorschau mit Versionsprüfung einschließlich Reservierungen, Kapazität, Wochenvorgaben und Parametern. Fehlende `FDS_CUSTOMER_ENABLED_CS_*`-Parameter werden wie in PHP ergänzt, vorhandene Werte bleiben erhalten. Audit 126/127/128 und dauerhafter Wiederholungsbeleg verhindern doppelte Verarbeitung nach verlorener Antwort. Stammdatenkataloge können MyISAM bleiben und werden während der Speicherung nur gelesen.
- **Bewusste Korrekturen:** einheitliches Raster aus `DISPOSITION_HOUR_TIME_UNITS` (aktuell global 20 = drei Minuten; PHP-Neuanlage verwendet dagegen fest sechs). Unpassende oder unvollständige bestehende Raster werden vor der Bestätigung gemeldet, nicht automatisch umgerechnet. Keine Übernahme der alten überbreiten Löschung von Verfügbarkeiten anderer Kunden bzw. Reservierungen anderer Fahrzeuge. Gesperrte Beziehungen liefern keine scheinbar freien Kapazitäten. Für neue und bestehende Tage gilt dieselbe Neuberechnung, statt der unterschiedlichen alten Initialisierungs-/Aktualisierungsregeln.
- **Bestandsprüfung/Grenzen:** vier FDS-/Zuordnungstabellen im echten Bestand InnoDB. Ein Fahrzeug mit bestehender Zuordnung lesend geladen; dort ist ein Tageszeit-Mapping leer und wird als Bestandsfehler angezeigt. Reale Beziehungen/Reservierungen unverändert. Die vollständige grafische FDS-Planung mit Drag-and-drop, Tagesaktionen und Vermittlungsautomatismus ist ein separater, weiterhin offener Funktionsbereich; ebenso die anderen ausdrücklich offenen Menüpunkte.

## Kartenübersicht – 15. Oktober 2026

- **Referenz:** frischer SSH-Stand **`93bf782`**, ausschließlich `/data/0/votian-test/html`: `admin/menu.php`, `locating/map.php`, `locating/map.inc.php`, `include/ajaxReqMap.php` sowie Auswahl-/Ortungslogik in `jobs/job_courier.inc.php` und `include/ranking.inc.php`. Alte Karte im angemeldeten Browser geöffnet; kein ursprünglicher lokaler PHP-Bestand verwendet.
- **Einstieg:** Verwaltung → Kartenübersicht, eigenes Recht 19. Positionen und Lager nur der eigenen Niederlassung. Aufträge und Stationsadressen zusätzlich Recht 4; Öffnen des Transporteurstamms zusätzlich Recht 1. Identische Fahrerkennungen in anderen Niederlassungen berechtigen nicht zum Zugriff auf deren Daten.
- **Flotte:** alle nichtleeren Fahrerkennungen mit Ortung nach Tagesbeginn, wie bei der PHP-Auswahl einschließlich offline gemeldeter Fahrer. Zeitbasis ist die Datenbankuhr; produktiv mit der lokalen Serverzeit abgeglichen. Gespeicherte Ortungszeit/-quelle (auch Typ 0), Telefonnummern, Freimeldungs-PLZ/-zeit, Online-/Belegtmeldung und Fahrzeugklasse. Laufende Aufträge 0/1 ohne Storno über tatsächliche Kurier-IDs, auf dieselbe Niederlassung begrenzt. Keine abgeleitete Einsatzfreigabe aus dem Vorhandensein eines Kartenpunkts.
- **Bedienung:** Suche nach Kennung/Name/PLZ, Fahrzeugklassen- und Zustandsfilter, Liste mit 50 Zeilen pro Seite, anklickbare Kartenpunkte, gemeinsame Auswahl bei überlagerten Punkten, Zoom/Verschieben und gemeinsamer Kartenausschnitt. Automatische Aktualisierung alle zehn Sekunden nach abgeschlossener Anfrage, pausiert in unsichtbaren Tabs und abschaltbar. Neue/entfernte/verschobene Positionen werden übernommen, der gewählte Ausschnitt bleibt erhalten. Bei Ladefehlern steht der Zeitpunkt des letzten erfolgreichen Stands sichtbar daneben.
- **Qualität:** Ortungsalter ab 30 Minuten blass dargestellt. Ungültige/fehlende Koordinaten, Nullpunkt 0/0, nicht darstellbare Polpositionen, mehr als fünf Minuten zukünftige Zeitstempel und Ortungstyp 9 werden nicht als nutzbare Kartenpunkte dargestellt; betroffene Fahrer bleiben mit Hinweis in der Liste. Maximal 2000 heutige Fahrer und 5000 laufende Aufträge, darüber Fehler statt stiller Kürzung.
- **Ebenen:** Zentrale und bis zu 200 Lageradressen zuschaltbar; Stationen eines gewählten Auftrags mit Reihenfolge und Erledigungsstatus. Lager-/Stationskoordinaten über die bestehende Geokodierung und deren Cache, zwei parallele Anfragen im Browser, abbrechbar beim Wechsel. Fehlende Adressen oder Dienstfehler bleiben je Adresse sichtbar und können erneut versucht werden. Kein stiller Wegfall von Stationen mit fehlender Adressverknüpfung. Höchstens 100 Stationen, darüber expliziter Fehler. Aufträge und Stammdaten öffnen ihre vorhandenen nativen Dialoge mit deren Rechten und Entwurfsschutz.
- **Kartenhintergrund:** lokal gebündeltes Leaflet, erst beim Öffnen geladen, mit OpenStreetMap-Kacheln, Attribution, Tastaturbedienung und Fehlerhinweis bei nicht erreichbarem Hintergrund. Konfigurierbar über `FLEET_MAP_TILE_URL` und `FLEET_MAP_ATTRIBUTION`; HTTPS-Vorlage mit `{z}/{x}/{y}`, keine Zugangsdaten in der URL. Kachelkonfiguration ist im Browser sichtbar. Keine vorab heruntergeladenen Karten. Grundlagen: [Leaflet-Dokumentation](https://leafletjs.com/examples/quick-start/) und [OSM-Kachelregeln](https://operations.osmfoundation.org/policies/tiles/).
- **Bestandsprüfung:** lesende Abfrage der geprüften Niederlassung erfolgreich; zum Prüfzeitpunkt keine heutigen Ortungen und keine Lageradressen. Die alte Karte zeigt ebenfalls keine Fahrzeuge. Bewegungen, gemischte Zustände und Geokodierung deshalb mit isolierten synthetischen Daten geprüft. Keine echten Geschäfts-/Schemaänderungen, keine neuen Ortungs-, Endgeräte- oder E-Mail-Befehle.
- **Inzwischen ergänzt:** direkte Marker-Zuweisung und Ortungs-/Freimeldungsprüfung mit Vorschau, Sperrprüfung und Rankingfolge, siehe folgende Abschnitte. Offen bleiben die vollständige auftragsabhängige Kandidatenrangliste, Ablehnungsfarben und spezielle Kundenzugangskarten. Farben zeigen weiterhin gespeicherte Online-/Belegtmeldungen. Google-Straßen-/Hybrid-Hintergründe werden nicht ohne konfigurierte Anbieteranbindung übernommen. Fahrzeug-Kundenzuordnungen einschließlich Verfügbarkeitsneuberechnung sind inzwischen ergänzt (siehe unten); vollständige grafische FDS-Disposition und übrige Menülücken bleiben offen.

## Kartenübersicht: direkte Zuweisung – 15. Oktober 2026

- **Referenz:** erneut frisch per SSH bestätigter Stand `93bf782`: `map.php`, `map.inc.php`, `ajaxReqMap.php`, `job_courier.inc.php`, `ranking.inc.php` und Länderprüfungen in `global.inc.php`. Angemeldete alte Kartenoberfläche erneut geöffnet; dort weiterhin keine Fahrerpositionen. Die Zuweisungsdetails wurden deshalb anhand des aktuellen Servercodes und synthetischer Daten geprüft.
- **Bedienung:** Auftrag über die Stationskarte auswählen, Transporteur auf Karte oder Liste anklicken, „Auftrag #… zuweisen“. Native Vorschau mit angemeldetem Fahrzeug, bisheriger Zuweisung, Rankingfolge und Hinweisen. Hinweise müssen bestätigt werden. Keine Änderung durch Kartenabruf/Vorschau; erst „Jetzt zuweisen“ bietet den Auftrag an. Anschließend werden Karte und laufende Aufträge aktualisiert.
- **Prüfungen:** Rechte 19/4/7, eigener Auftrag und Transporteur, eindeutiges angemeldetes Fahrzeug, freigegebene nicht archivierte Firma, App-Sperre und Online-Anmeldung. Keine Zuweisung von Angeboten, BWV-Fernaufträgen, abweichender ausführender Niederlassung, abgeschlossenen/stornierten/exportierten/abgerechneten/gesperrten Aufträgen oder Aufträgen mit fehlenden Stationsadressen. Bestehende gleiche Zuweisung wird nicht nochmals ausgelöst.
- **Eignung:** Fahrzeugklasse und Belegtmeldung als Hinweise; Zuladung/Laderaum/Stellplätze als Hinweise oder Sperre gemäß `RANKING_JB2CRVH_MEASURE`. Bekannte Pflichtfilter werden getrennt nach Fahrzeug-/Kurierkatalog geprüft, unbekannte Filter als Hinweis; exakte kommaseparierte Kürzel statt Teilworttreffer. Kundensperren für Stations- und Zahlerkostenstellen nach den vorhandenen `RANKING_BLOCKED_COURIER_FOR_*`-Vorgaben einschließlich Barzahler und globalem Fallback. Zusätzlich wird der Hauptzahler bei fehlenden Preispositionen berücksichtigt. Länderfreigaben aus `GLOBAL_NATIONALITY_*`; fehlende EG-Lizenz bei Auslandstouren wie im PHP als Hinweis.
- **Ranking:** Vergleich der Freimelde-PLZ mit erster Abhol-PLZ, gerichteten PLZ-Nachbarn bzw. eigenem Bereich und hinterlegten PLZ-Nachbarbereichen. Keine transitive Erweiterung. Ergebnis in `autoranking.ar_looseranking`, `ar_locating=0`, Protokoll 7 mit Zielkurier und `LOST_RANKING`. Die Freimeldungszeit wird durch diesen Dialog nicht verändert. Kein neuer automatischer Rankingdienst.
- **Speicherung:** vorhandener transaktionaler Auftragsablauf, erneute Prüfung der Vorschau innerhalb der Schreibtransaktion, dauerhafte Vorgangskennung, Rückrufbefehl 4 für bisherige Kuriere, angebotener Status 0. Auftrag, Autoranking, Gerätebefehle, Auditauftrag und Wiederholungsbeleg gemeinsam in InnoDB. Belegtmeldungen bleiben auch bei mehreren verbleibenden Aufträgen korrekt boolesch. Nach unbestätigter Antwort kann dieselbe Anfrage ohne zweite Zuweisung wiederholt werden. MyISAM-Kataloge/Kundenbeziehungen werden nur gelesen und erneut geprüft; sie können nicht gemeinsam mit der Auftragsänderung gegen sämtliche parallelen PHP-Schreibvorgänge gesperrt werden.
- **Ortung inzwischen ergänzt:** Die Prüfung gespeicherter Positionen mit bestätigter Freimeldungsänderung ist im folgenden Abschnitt beschrieben. Vollständige auftragsbezogene Kandidaten-/Ablehnungskarte, Kundenzugang, vollständige grafische FDS-Disposition und übrige Menülücken bleiben offen. Fahrzeug-Kundenzuordnungen sind inzwischen ergänzt.

## Kartenübersicht: Ortung und Freimeldung – 15. Oktober 2026

- **Referenz:** erneut frisch per SSH bestätigter Stand `93bf782`, insbesondere `locating/locating_D2.php`, `include/ranking.inc.php` und PLZ-Polygonfunktionen. Die alte Aktion „Neue Ortung“ wertet gespeicherte Positionen aus; der externe LBS-Versand ist auskommentiert. Der angemeldete alte Dialog lieferte beim Aufruf mit einer zuvor als nicht vorhanden geprüften Testkennung HTTP 500. Kein Aufruf mit realem Kurier, weil bereits der PHP-Seitenabruf dessen Ranking ändern kann; Details anhand des aktuellen Codes geprüft.
- **Bedienung:** Verwaltung → Kartenübersicht → Transporteur → „Ortung / Freimeldung prüfen“. Vorschau mit Ortungszeit, Quelle, Alter, ermittelter PLZ, bisheriger Freimeldung und erlaubten Nachbar-PLZ. Änderungen und Hinweise verlangen Bestätigung. Reine Prüfung protokollierbar; Vorschau/Kartenabruf ändern nichts. Keine aktive GPS- oder LBS-Anforderung.
- **PLZ und Ranking:** Polygonprüfung aus `phoenix_special.plz_geodb`/`plz_polygon` bis 50 km, sonst bzw. bei Modus 1 nächster gespeicherter `serviceplz`-Mittelpunkt nach PHP-Distanzregel. Ungültige, übergroße oder überlagerte Polygone und mehrdeutige nächste PLZ führen zu Fehlern. Freimelde-PLZ, gerichtete Nachbarn und eigene Bereiche verwenden dieselbe Regel wie die direkte Zuweisung. Innerhalb bleibt die Rankingzeit erhalten; außerhalb werden PLZ und Zeit auf den Bestätigungszeitpunkt gesetzt. Fehlende/nichtnumerische Freimeldungen werden ergänzt.
- **Plausibilität:** Online-Anmeldung, gültige Koordinaten, Quelle 0/2/3 und Alter gemäß `LOCATING_SECONDS_NEEDED_FOR_LBS_LOCATING` (Standard 900 Sekunden). Netzwerkpositionen mit Änderungswirkung benötigen eine frühere eindeutige GPS-Ortung; Geschwindigkeitsprüfung mit Genauigkeit, lokalem Erdradius und globaler `LOCATING_PLAUSIBLE_VELOCITY`. Bewusst strengere Regeln als PHP: keine ausgeschaltete Ortung, Zukunftszeit oder unplausible Netzwerkposition auch beim erstmaligen Setzen einer Freimeldung.
- **Speicherung:** Rechte 19/4, zusätzlich 7 für Übernahme/Protokollierung; nur eigene Niederlassung. Neuer Positions-/Parameter-/Gebietsstand oder inzwischen veraltete Ortung macht die Vorschau ungültig. Kurieränderung, Auditauftrag (Operation 27, ZIP_REAL/ZIP_FREE/LRANK) und dauerhafter Wiederholungsbeleg gemeinsam in InnoDB. Eine wiederholte Anfrage nach verlorener Antwort setzt die Rankingzeit nicht erneut. PLZ-Geometrie und Ortungshistorie bleiben lesende MyISAM-Zugriffe; parallele PHP-Änderungen an diesen Tabellen können nicht vollständig transaktional ausgeschlossen werden.
- **Geprüfter Umfang:** isolierte Datenbank- und Browserprüfung einschließlich Rollback, Rechte/HQ, Nachbarn/Bereiche, veralteter Vorschau, Ortungsquellen, Netzwerkplausibilität, verlorener Antwort und erneuter Übernahme. Echte Geodaten mit einem synthetischen Berliner Prüfpunkt ausschließlich gelesen: Polygonmodus 10117, Mittelpunktmodus 10179. Weitere Menübereiche bleiben in der Tabelle ausdrücklich offen.

## Kessel Buntes: PZM-Preisvergleich – 14. Oktober 2026

- **Referenz:** frischer SSH-Stand **`0702d0c`** aus `/data/0/votian-test/html`; `tools/statistic_finishment.php` Modus 19 und `include/ajaxReqKmPrice.php`. Angemeldete PHP-Auswertung mit gezielter Tages-/Kundenauswahl geprüft. Kein ursprünglicher lokaler PHP-Bestand verwendet.
- **Einstieg:** Verwaltung → Kessel Buntes → **PZM-Preisvergleich**, Recht 46. Kunde und Auftragszeitraum; höchstens 500 abgeschlossene, vollständige Aufträge, Stornostatus leer/0. Beide Datumsgrenzen einschließlich; Exportkennzeichen ist kein Ausschluss. Eigene Niederlassung auf Auftrag und Kunde. Übergrenzen werden gemeldet, niemals still abgeschnitten.
- **Getrennte Quellen:** Wie PHP Aufträge aus der separaten Live-Datenbank `172.16.0.203:3391/phoenix`, Tarife und Routenvorgaben aus der primären NG-Datenbank. Konfiguration ausschließlich `COMPARISON_DB_URL`, `COMPARISON_DB_USER`, `COMPARISON_DB_PASSWORD` in der privaten `.env`; keine Zugangsdaten im Frontend oder Git. Kunden werden über EID plus Niederlassung zugeordnet, interne IDs werden nicht zwischen Datenbanken gleichgesetzt. Fehlende/mehrdeutige Zuordnung wird abgewiesen.
- **Kalkulation:** Native PZM-/BWV-Routen- und Tarifberechnung, An-/Abfahrten, zusätzliche Adressen, Mindest-/Grundpreis und Tarifrabatte. Vergleichspreis vor Übernahmerundung, bei Fernaufträgen mit BWV-Treibstoffzuschlag. Die spezielle PHP-Regel wird für diesen Bericht beibehalten: `cs_fixprice_discount` in der Auftragsquelle ergibt ausschließlich beim Wert 1 einen Abzug von 1 %. Der Abzug steht als eigene Position in den Details. Andere Quellwerte bewirken wie im PHP-Bericht keinen solchen Abzug. Die normale Auftragspreisberechnung bleibt unverändert.
- **Kilometer:** Fahrstrecke plus bepreiste An-/Abfahrten; kostenlose An-/Abfahrten erhöhen den Vergleichswert nicht. Die zusätzliche Kennzahl in `LegacyDistancePricing` ändert keine gespeicherten Auftragspreise oder die bisherige Routeninformation. LKW-Typ 7 wird entsprechend PHP übersprungen. Ungültige Adressen, doppelte Stationspositionen, fehlende Tarife oder Routenfehler werden pro Auftrag angezeigt.
- **Bedienung:** Bestehender Grund-/Festpreis, PZM-Typ, neuer Preis, Differenz, Kilometer und Kalkulationsdetails; Fortschritt, Pause nach dem laufenden Auftrag, Fortsetzung und Neuberechnung. Auftragsdaten werden beim Start eingelesen; aktuelle Tarife je Zeile mit Kalkulationszeitpunkt. CSV exportiert den berechneten Stand inklusive Fehlern/ausstehenden Zeilen und Details, ohne neue Routenberechnung. Ein gegenüber dem Browserstand fortgeschrittenes Ergebnis sperrt den Export bis zum erneuten Laden.
- **Lebensdauer:** Maximal 32 Vergleiche im Serverprozess, zwei Stunden nach letztem Status-/Berechnungszugriff, an Benutzer und Niederlassung gebunden. Fortsetzung innerhalb der geöffneten Ansicht; Schließen beendet die automatische Verarbeitung. Neustart verliert Ergebnisse. Wiederholung einer Startkennung oder eines bereits bearbeiteten Zeilenindex rechnet nicht doppelt. Kein Hintergrundauftrag nach dem Schließen.
- **Bestandsprüfung:** Auftrag 22617875 am 14.10.2026: PHP und native Berechnung jeweils **58,41 € / 14,66 km**, einschließlich Mindestpreis und 1-%-Vergleichsrabatt. Reale Aufträge ausschließlich gelesen; keine Preis-, Stammdaten- oder Schemaänderung. Die alte Quell-DB unterstützt `SET TRANSACTION READ ONLY` nicht; der separate Zugang in `DatabaseService` erlaubt deshalb ausschließlich validierte, fest im Anwendungscode definierte SELECTs und liefert keinen Schreib-/Transaktionszugang.
- **Grenzen:** Die beiden Datenbanken und der Routendienst bilden keinen gemeinsamen atomaren Stand. Während des Laufs geänderte Tarife/Parameter können spätere Zeilen beeinflussen; Zeitpunkte sind sichtbar. Gleiche Ergebnisse sind als Stichprobe, nicht für alle Tarif-/Adresskonstellationen bewiesen. Zugangsverwaltung, Listenerfassung, vollständige Rechnungs-/FiBu-Läufe und weitere Restpunkte der Tabelle bleiben offen.

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

- **Referenz:** aktuelle SSH-Quellen aus `/data/0/votian-test/html`, Git **`3a4fdeb`**; `tools/statistic_finishment.php` Modi 18/20, `include/ajaxReqSetAttr.php` und Verbraucher in `include/ajaxReqKmPrice.php`, `include/services_func.inc.php`, `include/ranking.inc.php` sowie `jobs/job_courier.inc.php`. Beide angemeldeten PHP-Oberflächen geöffnet und mit aktuellen Parametern bzw. lesendem PZM-API-Abruf verglichen. Kein ursprünglicher lokaler PHP-Bestand verwendet.
- **Einstieg:** Verwaltung → Kessel Buntes → **PZM-Zonen und Vorgaben** bzw. **BWV-Einstellungen**. Übersichten mit CSV, getrennte Pflegedialoge mit Vorschau und Entwurfsschutz.
- **PZM-Vorgaben:** Last-KM/Rundtour, normale/kürzeste von drei/absolut kürzeste Route und Rundung auf volle Euro. Speicherung nur für die eigene Niederlassung. Fehlende/ungültige Altwerte bleiben sichtbar; mehrdeutige Parameter sperren Bearbeitung. Bezeichnungen aus `PZM_MASK_ZONES`; aktive Rundungsausnahmen über vollständige Kunden-ID, ohne den alten Sechsstellen-Abschnitt.
- **Zonen:** Anfahrtsberechnung je Zone über den vorhandenen PZM-Dienst. API-Feld `eap=true` bedeutet ausgeschlossene Anfahrtsberechnung und wird entsprechend invertiert. Dienstadresse nur aus serverseitiger Konfiguration (`PZM_URL`, sonst `URL_PZM`), keine frei eingebbaren Ziele. Unveränderliche Vorgangspläne in `genericdatacontainer` vor dem externen Schreiben; offene Vorgänge im Dialog sichtbar, Fortsetzung nur durch ursprünglichen Bearbeiter. Wiederholung prüft Vorher-/Nachherstand und schreibt bereits bestätigte Zonen nicht erneut. Bestätigte Änderungen erzeugen eine neue Routen-Cacheversion für alle NG-Prozesse.
- **BWV:** alle 18 Felder der alten Maske: TSZ für Rundkilometer, Mindestabstand, Suchradius-Schritt, Außenzonen-TSZ sowie Kilometerpreis/Frachtvergütungsabschlag für PKW, Kombi, Kastenwagen, Transporter, Transporter XL, LKW und LKW 12 To. Dezimalkomma/-punkt, leere optionale Vorgaben, positiver Suchradius-Schritt, Abschlag 0–100 %. Globale Werte unter HQ/Emp/Mandant 0; lokale Übersteuerungen und Beschreibungen bleiben erhalten.
- **Schreibschutz:** Lesen Recht 46; Ändern zusätzlich Recht 2, Session/CSRF, ausdrückliche Vorschau, Revisionsvergleich, Audit und Wiederholungsbelege. Parameteränderungen mit kurzer Tabellensperre und gemeinsamer InnoDB-Transaktion. Keine Schemaänderung; keine automatische Änderung realer Vorgaben.
- **Bestandsabgleich:** drei PZM-Schalter und drei Zonen entsprechen PHP (Zone 1 aus, Zone 2/Ausserhalb an). Alle 18 BWV-Werte geladen. Elf lokale Suchradius-Vorgaben erkannt und als Hinweis angezeigt; keine aktiven Rundungsausnahmen oder offenen PZM-Vorgänge in der geprüften Niederlassung.
- **Grenzen:** Der PZM-Dienst bietet keinen atomaren Versionsvergleich; parallele PHP-Schreibzugriffe zwischen Lesen und Schreiben lassen sich deshalb nicht vollständig ausschließen. Sichtbare Konflikte werden abgewiesen und können eine Bestandsklärung erfordern. Externe API und Datenbank bilden keine gemeinsame Transaktion; der gespeicherte Plan ermöglicht Wiederaufnahme. BWV ist hier Konfigurationspflege für bestehende Verbraucher; kein neuer autonomer Vermittlungsdienst. Die direkte native BWV-Preisübernahme wurde am 17. Oktober ergänzt; der native Retourenlauf ist inzwischen ergänzt; vollständige Abrechnung und Betriebsumschaltung bleiben offen. Bestehende Preisermittlungsregeln und Zonentarifnamen bleiben erhalten.
- **Weiter offen:** Zugangsverwaltung, Listenerfassung, vollständige Rechnungs-/FiBu-Läufe und die übrigen ausdrücklich offenen Bereiche der Übersicht.

## Kessel Buntes: Mail-Verteiler & Co. und Vorlaufzeit-Zuschläge – 14. Oktober 2026

- **Referenz:** erneut frisch gelesener SSH-Stand `24094e2`, `tools/statistic_finishment.php` Modus 13 und `include/ajaxReqSetAttr.php`. Angemeldete PHP-Oberfläche mit Verteilerliste und vier automatisch speichernden Feldern gelesen. Ursprünglicher lokaler PHP-Bestand nicht verwendet.
- **Mail-Übersicht:** eigene Niederlassung plus globale Vorgaben, lokale Vorgaben ersetzen globale desselben Schlüssels auch bei leerer Empfängerliste. Wie in PHP bleiben BCC-Station, Rezensionstext und der technische Cron-Absender ausgeschlossen. SMTP-/Authentifizierungsgeheimnisse werden nicht ausgegeben. Leere Beschreibungen erhalten eine Bezeichnung; doppelte und zusätzlich mandanten-/mitarbeiterbezogene Parameter bleiben mit Hinweis erkennbar. Empfängertexte bleiben unverändert. Native Suche, Sortierung, Seiten und vollständiger CSV-Export mit Formelpräfixschutz. Die Mail-Adressen bleiben wie in dieser alten Übersicht lesbar; kein zusätzlicher Mailversand oder Verteilereditor.
- **Vorlaufzeitpflege:** Montag–Freitag Start/Ende (auch über Mitternacht), Minutenaufschlag sowie ganztägiger Wochenendaufschlag. Alle vier bestehenden globalen Schlüssel werden gemeinsam bearbeitet. HH:mm, Endzeit auch 24:00, ganze Minuten 0–999. Fehlende Werte bleiben sichtbar und können angelegt werden; ungültiger Bestand wird mit Originalwert angezeigt und kann korrigiert werden. Doppelte oder nicht global zugeordnete Schlüssel blockieren Schreiben. Beschreibungen und andere Parameter werden erhalten.
- **Schreibschutz:** Recht 46 zum Lesen, zusätzlich Recht 2 für globale Pflege. Klarer Hinweis auf alle Niederlassungen, Vorher-/Nachher-Vorschau, Revisionsprüfung auch bei Änderungen aus anderen Niederlassungen, atomare Parameter-/Audit-/Belegänderung unter kurzer zentraler Tabellensperre, Audit 203 und wiederholbare Vorgangskennung bei verlorener Antwort. Der fehlerhafte PHP-Allzweig (`$attr = "SAT2SUN_MINUTES"`) wird nicht übernommen; der neue Endpunkt kennt ausschließlich die vier Vorlaufzeitschlüssel.
- **Abgrenzung:** Dies portiert die bestehende Einstellungsseite. Im aktuellen PHP-Git sind die vier Schlüssel nur in Verwaltung/Schreiber direkt referenziert. Eine zusätzliche native Berechnung von Abholterminen oder ein Ersatz externer Vorlaufzeit-Verarbeitung ist damit nicht behauptet; vorhandene Auftragsdaten bleiben unverändert.
- **Bestandsprüfung:** 21 Verteiler wie in der PHP-Oberfläche, Abfrage samt Vorgaben ca. 0,30 Sekunden. Wochenendwert derzeit `Absolut_kuerzeste` statt einer Minutenzahl; sichtbar gekennzeichnet, nicht automatisch geändert. Kein realer Schreib-/Versandtest und keine Schemaänderung.
- **Weiter offen:** PZM-Zonen/-Preisvergleich, BWV-Spezialeinstellungen und die übrigen in der Tabelle genannten Menüs und Hintergrundprozesse.

## Kessel Buntes: Kundenmasken und Kundenzugang-Listenerweiterungen – 14. Oktober 2026

- **Referenz:** frisch per SSH gelesener Serverstand `24094e2`, `tools/statistic_finishment.php` (Modi 3/4), `include/ajaxReqSetAttr.php` und die tatsächlichen Verbraucher in `jobs2/job_tour.php`, `jobs2/job_options.php`, `jobs/job_options.php`, `customer/jb_list.php` sowie `getParameterValue` in `include/dbglobal.inc.php`. Beide angemeldeten PHP-Listen im Browser gelesen; keine alten lokalen Quellen benutzt.
- **Kundenmasken:** alle Kunden der eigenen Niederlassung mit `cs_jbedit=1`, auch ausgeblendete. Lademaße nur lesbar; Dispo-Info, abweichender Barzahler und gespeicherte Vorgabe für manuelle Disposition bearbeitbar. Die aktuelle PHP-Kundenerfassung blendet manuelle Disposition weiterhin aus; der Dialog weist darauf hin. Dies ist Konfigurationspflege, keine neue automatische Dispositionsfunktion.
- **Kundenzugangsliste:** alle nichtleeren Logins über Kunde → Kostenstelle → Mitarbeiter, ohne zusätzliche Sichtbarkeits-/Erfassungsfilter. Kartenansicht und Stadtteilvorgabe gelten je Kunde; Ortsanzeige gilt je Mitarbeiter/Login. Stadtteil-Ort ist ein einzelner Teiltext des Stationsortes (z. B. Berlin), kein Ortskatalog; leeres Feld deaktiviert die Vorgabe.
- **Bestandserhalt:** Dispo-Info verwendet wie der tatsächliche Verbraucher `par_text`, Lademaße `par_value`. Andere Kunden in den Listen und fremde Parameter bleiben erhalten. Barzahler/Kartenansicht/manuelle Disposition berücksichtigen den gespeicherten Wert statt nur das Vorhandensein des Schlüssels. Ortsanzeige ergänzt/entfernt ausschließlich `jb_tourcities` samt passendem Titel/Ausrichtung; andere Zusatzspalten bleiben erhalten. Die PHP-Rückfallebene zur ursprünglichen Login-Niederlassung wird berücksichtigt, auch beim Entfernen der letzten globalen Spalte. Mehrdeutige Geltungsbereiche oder unvollständige Spaltentripel werden nicht automatisch überschrieben.
- **Bedienung und Schutz:** Suche nach Kunde/Kostenstelle/Login, Sortierung, 50 Zeilen pro Seite und vollständiger CSV-Export. Bis 10.000 Einträge ohne stilles Abschneiden. Lesen benötigt Recht 46, Schreiben zusätzlich 0/2. Änderungen erst nach Vorschau, mit Entwurfsschutz, Revisionsprüfung einschließlich Eigentümerzuordnung und gemeinsamen Kundenvorgaben, wiederholbaren Vorgangsbelegen und Audit 203. Während NG-Revisionsprüfung und Speicherung sind die beteiligten Tabellen zentral gesperrt; ausschließlich InnoDB-Parameter/-Belege werden verändert, referenzierte MyISAM-Tabellen bleiben lesend.
- **Bestandsprüfung:** 1.365 Kundenmasken und 6.030 Kundenzugänge wie in PHP. Fünf Kundenmasken haben doppelte Parameter und bleiben mit Bestandshinweis sichtbar; betroffene Bearbeitung gesperrt. Keine Warnungen in der Kundenzugangsliste. Beide Übersichten unter einer Sekunde in der geprüften Niederlassung. Keine realen Konfigurationsänderungen vorgenommen.
- **Weiter offen:** PZM-/BWV-Spezialeinstellungen und die weiteren Menüs der Übersicht, insbesondere Zugangsrechte, Listenerfassung und vollständige Abrechnungsläufe.

## Kessel Buntes: Sonderkonditionen und getnow – 14. Oktober 2026

- **Referenz:** frisch per SSH gelesener Serverstand `24094e2`, insbesondere `tools/statistic_finishment.php` (Modi 14/8), Tarifseiten und Ankunftsfeld `arr_tour` aus Stationshistorie/Scan-Ereignissen. Beide angemeldeten PHP-Oberflächen und ihre Listen/Links geprüft.
- **Sonderkonditionen:** sichtbare, nicht archivierte Kunden mit Kundennummer und abweichendem TSZ, Rabatt, Fixpreisrabatt, Servicepreis/-frachtvergütung, Calculator-Zuordnung, PLZ-/Bereichspreis oder Kurierprovision. Wie PHP zählen positive Preise und auch künftige Tarifstände; PLZ-/Bereichskennzeichen richten sich nach dem Abrechnungstyp. Interne Kunden-IDs verhindern die Übertragung von Kennzeichen auf Kunden mit gleicher externer Nummer. Verwaiste/fremde Transporteurzuordnungen bleiben ohne fremde Namen erkennbar.
- **Navigation:** Kennzeichen öffnen vorhandene native Preis-/Provisionseditoren; Kunde, Servicemodus und Preis-/Frachtvergütungsansicht sind vorbelegt. Direkter Kundenstamm für TSZ und Rabatte. Nach Rückkehr wird die Übersicht neu geladen. Eigener Entwurfsschutz; laufende oder unklar beantwortete Tarif-Speicherung blockiert das Schließen bis zur Klärung. Bestehende Rechte der Zielmasken gelten unabhängig von Recht 46 für die Übersicht.
- **getnow:** Kundenauswahl, Auftragszeitraum einschließlich Randsekunden, erste Zustellung (Stationsposition 2), erfasste Ankunft und Abfahrt sowie Fahrerkennung. Keine zusätzlichen Abschluss-/Storno-/Exportfilter. Fahrzeit ab der vorherigen Abfahrt bei identischem Fahrer und identischer Bestellzeit; Reihenfolge wie PHP. Native Auftragsöffnung mit Recht 4, Sortierung, Seiten und CSV.
- **Bewusste Korrekturen:** nur `arr_tour` wird als Ankunft verwendet; andere Stationszusatzdaten erzeugen keine falschen Doppelzeilen. Mehrfach-/ungültige Ankünfte bleiben mit Hinweis sichtbar, davon abhängige Dauern leer. Datum und Uhrzeit werden angezeigt; Dauern behalten Mitternachtswechsel, mehr als 24 Stunden und negative Vorzeichen. Minutengenauigkeit wie PHP, Zeitfolgefehler werden markiert. Die Zeitrechnung verwendet die gespeicherten lokalen Uhrzeiten ohne zusätzliche Zeitzonenumrechnung.
- **Prüfung am Bestand:** Sonderkonditionen wie die PHP-Liste 443 Kunden; getnow-Stichprobe mit fünf echten Ankunftsmeldungen liefert fünf statt der zehn durch andere Zusatzdaten verdoppelten PHP-Zeilen. Ausschließlich lesend über `DatabaseService`. Für beide Ergebnisse CSV mit UTF-8/BOM, Formelpräfixschutz und Grenze von 5000 Zeilen ohne stilles Abschneiden.
- **Weiter offen:** PZM-/BWV-Spezialeinstellungen und die übrigen Menüs der Übersicht.

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

- **Referenz:** erneut frisch per SSH aus `/data/0/votian-test/html`, Git **`24094e2`**. `tools/statistic_finishment.php` (Modi 10/12), `include/inc_customer.inc.php`, `include/ajaxReqSetAttr.php`, `jobs/job_options.php` und `include/caglobal.inc.php`. Beide PHP-Einstellungsseiten im angemeldeten Browser lesend geöffnet. Die aktuelle Radio-Navigation bietet 10/12 nicht mehr an, ihre Seiten/Verarbeitung bestehen weiterhin; die klassische Foto-Konfiguration ist zusätzlich im Kundenstamm enthalten.
- **Einstieg:** Verwaltung → Kessel Buntes → „Beweisfoto-Vorgaben“ bzw. „Servicepreis-Ausweis“. Bestandslisten einschließlich ausgeblendeter Kunden, Sortierung, 50 Zeilen je Seite und CSV; neue Kundenvorgabe über Kundensuche. Bearbeitung/Entfernung mit verbindlicher Vorher-/Nachher-Vorschau, eigenem Entwurfsschutz und Neuladen nach Konflikten.
- **Fotos:** keine Kundenvorgabe, gesperrt, Zentralenerfassung, Kundenerfassung oder beide Erfassungsarten. Mindestzahl 0–5 und Höchstzahl 1–5, Minimum darf Maximum nicht überschreiten; gesperrt wird als `0` und `0|0` gespeichert. 0 Mindestfotos bedeutet Kann-Foto, ab 1 Muss-Foto. Anders als die alte Kessel-Liste bleiben die bereits von der PHP-Kundenpflege unterstützten Modi 0/3 sichtbar. Fehlende Mengen bei bestehender aktiver Vorgabe werden entsprechend dem PHP-Stationsschreiber als 1/1 gelesen. Entfernen löscht nur die zwei kundenspezifischen Parameter; allgemeine Vorgaben werden wieder wirksam.
- **Servicepreis-Ausweis:** Kundenvorgabe ergänzen/aktivieren und entfernen. Vorhandene inaktive 0-Werte bleiben sichtbar. Ein aktiver allgemeiner Ausweis der eigenen Niederlassung wird im Dialog und in der Entfernungsvorschau ausdrücklich genannt und bleibt erhalten. Kunden-IDs sind nicht auf sechs Stellen begrenzt. Vorhandene Beschreibungstexte und fremde Parameter bleiben unverändert.
- **Abgrenzung:** Diese Foto-Parameter steuern das klassische Verfahren der PHP-Erfassung. Die native Erfassung verwendet weiterhin Foto-Workflow-Sets; sie erhält in diesem Block keinen zusätzlichen klassischen Foto-Pfad. Bei aktiven Workflows ignoriert auch PHP die klassischen Vorgaben. Der Servicepreis-Parameter steuert die bestehende PHP-Rechnungserstellung; vollständige native Rechnungen sind weiterhin offen. Es werden keine alten Aufträge, Fotos oder Rechnungen rückwirkend geändert.
- **Rechte/Konsistenz:** Lesen mit Recht 46, Pflege zusätzlich 0/2. Eigene Niederlassung wird auch bei Speicherwiederholungen geprüft. Zulässige Schlüssel werden ausschließlich aus Einstellungsart und validierter Kunden-ID gebildet. Abweichende Parameter-Geltungsbereiche, doppelte Schlüssel und ungültige Altdaten werden sichtbar gemeldet und nicht automatisch überschrieben. Revision umfasst Parameterwerte/-texte und die relevante allgemeine Rechnungsvorgabe. Kurze Tabellensperre serialisiert PHP-/NG-Zugriffe auf die Schlüssel ohne eindeutigen Index. Parameter, Audit und dauerhafter Wiederholungsbeleg werden gemeinsam in vorhandenen InnoDB-Tabellen gespeichert; Fehler rollen alles zurück. Keine Schemaänderung, ausschließlich `DatabaseService`.
- **Bestandsprüfung:** eigene Testniederlassung liefert 24 gültige Foto-Konfigurationen gegenüber 22 in der alten Liste; Unterschied sind die dort ausgeblendeten Modi 0/3. Der kundenspezifische Servicepreis-Ausweis ist dort leer. Die Listenabfrage beginnt gezielt bei den passenden Parametern; die anfänglich zu langsame korrelierte Kundensuche wurde ersetzt und erfolgreich am realen Bestand geprüft.
- **Weiter offen:** PZM- und BWV-Spezialeinstellungen sowie die übrigen in der Tabelle genannten Menüs und Hintergrundprozesse.

## Daueraufträge: Übersicht, Kalender und Vorgängerhistorie – 14. Oktober 2026

- Aktuelle Referenz ausschließlich per SSH, Git **`24094e2`**: `jobs/jb_special.php`, dessen HTML-Vorlage, `include/caglobal.inc.php` (`getNextOrderDate`) und Feiertagsabfrage. Alte Dauerauftragsseite und Historienumschaltung im angemeldeten Browser lesend geprüft. Der aktuelle Testbestand enthält für den geprüften Kunden keine zukünftigen Daueraufträge; Kalenderfälle zusätzlich mit synthetischen Daten geprüft.
- **Einstieg:** Verwaltung → Kessel Buntes → Daueraufträge. Kunde und Stichtag (anfangs heute), Sortierung, 50 Zeilen pro Seite, CSV. Eigene Niederlassung, Zuordnung über Zahler oder abweichenden Barzahler, letzte offene Serienaufträge ohne Nachfolger, passende Auftragszeit und Serienende. Auch Vorlagen ohne Tourname/Station bleiben sichtbar. Wie PHP werden Gutschriften mit Storno 3/4 ausgeschlossen. Zusätzlich sind die von der aktuellen PHP-Terminberechnung unterstützten Rhythmen 10/11 enthalten, die deren alte Listenauswahl auslässt.
- **Stichtag:** explizit wählbar zum Prüfen älterer Bestände. Filtert den heute gespeicherten Zustand; stellt keinen früheren Datenbankzustand wieder her. Die Niederlassungs-/Kundengrenzen gelten auch bei älteren Stichtagen. Kein stiller Rückgriff auf den letzten Keepalive-Zeitpunkt.
- **Jahreskalender:** Kalender zum Auftrag öffnen, Jahr wechseln, einzelne Tage mit Uhrzeit und verknüpften Aufträgen anzeigen. Aktueller Auftrag, berechnete Folgetermine, Vorgänger und Feiertage getrennt gekennzeichnet. Vorschau vom aktuellen Serienauftrag bis Ende seines Folgejahrs, durch das gespeicherte Serienende begrenzt. Wie PHP liegt ein berechneter Folgetermin strikt vor dem Endzeitpunkt: Ende um Mitternacht schließt diesen Tag aus, Ende 23:59:59 schließt ihn ein. Bereits angelegter aktueller Auftrag bleibt sichtbar.
- **Rhythmen/Feiertage:** alle elf Rhythmen über die vorhandene gemeinsame Serienberechnung; Tagesmaske, Feiertagsmodus mit optionalen Wochentagen, Wochen-/Vierzehntages-/Vierwochenabstand, Monatsende, 15./Monatsende und 1./16. Monatsrhythmen begrenzen den Tag auf die Monatslänge. Verschiebung über gepflegte Feiertage vorwärts bzw. bei Monatsende/15. rückwärts entsprechend PHP; Feiertagszeitfenster werden in dieser Datumsberechnung wie PHP als ganzer Tag berücksichtigt.
- **Historie:** Verknüpfung über `jb_id_copy_permanent`, seit 1. Januar des Stichtag-Vorjahres. Auftragsnummer, Auftragszeit und Status; historische Markierung bedeutet vorhandener Vorgänger, nicht automatisch erledigt. Tabelle ein-/ausblendbar und mit 50 Zeilen pro Seite. Verzweigte oder zyklische Ketten werden als Bestandsfehler gemeldet statt zufällig gekürzt. Historienbasis und Listen auf 5000 Zeilen begrenzt, größere Ergebnisse werden abgewiesen. Archivtabellen bleiben ausgeschlossen.
- **Auftragszugriff:** Kalender/Liste benötigen Recht 46, Öffnen des aktuellen oder historischen Auftrags zusätzlich 4. Die bestehende Auftragsbearbeitung schützt exportierte/stornierte Aufträge und benötigt für Änderungen weiterhin die vorhandenen Schreibrechte. Nach dortigem Speichern werden Liste und Kalender aktualisiert. Kalender selbst liest ausschließlich über `DatabaseService` und erzeugt keine Folgeaufträge; dafür läuft weiterhin die bestehende Dauerauftragsverarbeitung.
- **Offen bleiben:** PZM-Zonen/-Vergleich, übrige Sonderauswertungen/-einstellungen sowie die weiteren Menüpunkte der Übersicht.

## Gespeicherte Touren: Bearbeiten und Mehrfachentfernung – 14. Oktober 2026

- Referenz frisch per SSH aus `/data/0/votian-test/html`, Git **`24094e2`**: `jobs/jb_special.php`, zusätzlich Sperrlogik/Parameter in `jobs/get_saved_tour.php` und `sysadmin/database_wizard.php`. Alte Konservenliste mit Auswahl, Löschen und Bearbeitung im angemeldeten Browser lesend geprüft. Kein früherer lokaler PHP-Stand verwendet.
- **Einstieg:** Verwaltung → Kessel Buntes → Kunden-Konserven → Anzahl oder direkt „Gespeicherte Touren“ mit Kundenauswahl. „Auftrag öffnen“ führt in die bestehende native Auftragsbearbeitung; deren Schreib-/Abrechnungsbeschränkungen gelten unverändert.
- **Tourname:** einzelne Vorlage mit 1–50 Zeichen umbenennen, Vorschau des alten und neuen Namens, Speichern und Aktualisierung der Liste. Eigener Dialog schützt ungespeicherte Änderungen. Gleiche Namen verschiedener Vorlagen bleiben zulässig.
- **Mehrfachentfernung:** einzelne Zeilen oder aktuelle Seite wählen, Auswahl über Seitenwechsel erhalten, höchstens 200 pro Vorgang. Vorschau zeigt jeden betroffenen Auftrag. Wie PHP wird ausschließlich `jb_tourname` geleert; Auftrag, Stationen, Preise, Belege und Abrechnung bleiben erhalten. Die Vorlage verschwindet damit auch aus der Auswahl anderer zugeordneter Zahler/Barzahler. Metadatenpflege bleibt auch bei exportierten Aufträgen möglich; der Auftragseditor schützt deren übrige Daten.
- **Zugriff und Konsistenz:** Liste benötigt Recht 46, Öffnen zusätzlich 4, Metadatenänderung zusätzlich 7. Eigene Niederlassung und Zuordnung über Zahler/Barzahler werden serverseitig erneut geprüft. Namens-/Versions-/Zahlerrevision verhindert Überschreiben zwischenzeitlicher Änderungen. Aktive PHP-Bearbeitungssperren werden anhand der Datenbankzeit und `MASK_LOCKTIME_TIMEOUT` der Niederlassung geprüft (fünf Minuten bei fehlender Vorgabe). Mehrdeutige/ungültige Vorgaben verhindern die Änderung.
- **Speicherung:** gemeinsame InnoDB-Transaktion für alle ausgewählten Aufträge, Versionsfortschreibung, Audit und dauerhafte Vorgangsquittung. Fehler rollen die ganze Aktion zurück. Nach verlorener Antwort bleibt derselbe Vorgang zur erneuten Prüfung erhalten; bereits bestätigte Änderungen werden nicht doppelt ausgeführt. Auditoperation 2 zählt nicht als Konservennutzung. Zugriff ausschließlich über `DatabaseService`, keine Schemaänderung.
- **Weiterhin offen:** PZM-Zonen/-Vergleich sowie die übrigen Spezialauswertungen, Einstellungen und Menüpunkte der Übersicht.

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

- Referenz erneut direkt vom SSH-Server, Git **`24094e2`**: `tools/statistic_finishment.php` und `jobs/jb_special.php`. Alle vier alten Auswertungen und die verlinkte Tourenliste im angemeldeten Browser lesend geprüft; kein früherer lokaler PHP-Bestand verwendet.
- **Transporteursliste (PHP 9):** eine Zeile je Fahrzeug mit TT-Nummer, einschließlich ausgeblendeter Transporteure. Firmen-/Personen-/Adressdaten, E-Mail, IMEI, Mobilnummer, Rechnungs-E-Mail, App-/Betriebssystemversion und Gerätemodell. Gesperrte bzw. bevorzugte Kunden getrennt und ohne fremde Niederlassungen; andere Gerätefelder werden nicht ausgegeben. Beziehungen werden ohne `GROUP_CONCAT`-Abschneidung übernommen.
- **Auslandsrechnungen (PHP 11):** ausländische Rechnungsanschriften der Hauptkostenstelle, USt-ID und Ausblendestatus. Die Ansicht erstellt keine Rechnung. Wie PHP zählt ein leeres Länderkennzeichen als ungleich DE; NULL bleibt ausgeschlossen. Alle vier Anschriftszeilen und führende PLZ-Nullen erhalten. Eine fehlerhaft fremd zugeordnete Hauptkostenstelle wird nicht ausgelesen.
- **Kunden-Konserven (PHP 17):** Anzahl gespeicherter Touren über Zahler oder abweichenden Barzahler; dieselbe Tour zählt pro Kunde nur einmal. Eigene Niederlassung für Auftrag und Kunde, ohne Status-/Zeitfilter. Klick auf die Anzahl öffnet die native Liste mit Tourname, Auftragsnummer/-zeit, Preis, Kostenstellen, Abholfirma/-adresse, Start-/Ziel-PLZ und Fahrzeugtyp. Rückkehr zur Kundenübersicht, direkte Kundenauswahl, Spaltensortierung und CSV. Ausgeblendete Kostenstellen und unvollständige Altaufträge bleiben in dieser Bestandsliste sichtbar; bei mehrfacher Stationsposition wird die kleinste Stations-ID angezeigt. Fremde Kostenstellennamen bleiben ausgeblendet. Die zusätzliche Bearbeitungs-/Mehrfachentfernungsfunktion wurde anschließend ergänzt (siehe oben). Dauerauftragskalender/-historie aus `jb_special.php` wurden anschließend ergänzt (siehe oben).
- **Konservennutzung (PHP 15):** Zeitraum bezieht sich auf `jb_ordertime`, Zuordnung zum Zahler. Gezählt werden Historieneinträge mit Aktionen 25/1/162/163 nach dem 23.02.2024, keine unterschiedlichen Aufträge und kein zusätzlicher Zeitraumfilter auf das Logdatum. Aktuelle ungenutzte Vorlagen bleiben mit null Nutzungen sichtbar, entfernte Vorlagen mit leerer Auftragsnummer. Gleiche aktuelle Namen zeigen alle Auftragsnummern statt der zufälligen letzten PHP-Zeile. Abweichende Groß-/Kleinschreibung wird getrennt zugeordnet; Logmeldungen ohne vollständig eingeschlossenen, nichtleeren Namen werden ausgeschlossen. Historienzugriff über das konfigurierte `app.history-schema`, standardmäßig `phoenix_log`, ausschließlich über `DatabaseService`.
- **Bedienung/Zugriff:** bestehendes Recht 46; drei Bestandsübersichten ohne irreführende Datums-/Kundeneingabe, Tourenliste mit Kunde und Nutzungsstatistik mit Kunde/Datum. Tabellen mit Spaltensortierung und 50 Zeilen je Seite; vollständiger CSV-Export mit UTF-8/BOM, Dezimalkomma und Formelschutz. Interne Kunden-IDs erscheinen weder in Tabelle noch CSV. Mehr als 5000 Ergebniszeilen werden abgewiesen, nicht abgeschnitten. Ausschließlich lesende Abfragen, keine Schemaänderung.
- **Weitere offene Extras:** PZM-Zonen/-Vergleich, Kunden-/Zugangs-/Mail-/BWV-Einstellungsseiten. Die übrigen offenen Menüs stehen weiterhin in der Tabelle oben.

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

- Referenz erneut direkt per SSH: `/data/0/votian-test/html/tools/statistic_finishment.php`, Git **`24094e2`**. Die sechs betreffenden Auswahlen wurden in der angemeldeten PHP-Oberfläche angesehen; Auftragsherkunft zusätzlich mit sichtbarem Ergebnis verglichen. Kein früherer lokaler PHP-Bestand verwendet.
- **Einstieg:** Verwaltung → Kessel Buntes, bestehendes Recht **46**. Kundensuche nach Nummer/Name in der eigenen Niederlassung, Vormonat als Anfangsauswahl, frei wählbarer Zeitraum bis zehn Jahre. Auftrag und Kunde werden serverseitig auf die eigene Niederlassung begrenzt. Die alte Sonderfreigabe einer fest einprogrammierten Benutzer-ID wird nicht übernommen.
- **Erledigungsstatistik (PHP 1):** abgeschlossene Aufträge ausschließlich mit `jb_storno IS NULL`, Erledigungsdatum strikt zwischen den PHP-Randsekunden. Angeforderter Fahrzeugtyp, Fahrzeugnummer, Vorbestellung, Bestellzeit sowie Abholung und 19 Zustellungen mit PLZ, Erledigungszeit, Dauer seit Bestellung und Kommission. Fahrzeugtypen unter 7 zuerst, danach ab 7, innerhalb beider Gruppen nach erster Zustelldauer. Oberfläche mit separaten Stationsdetails; CSV mit allen 85 Fachspalten plus laufender Nummer. Keine zusätzliche Vervielfachung bei mehrfacher gleicher Stationsposition: solche Bestandskonflikte werden gemeldet. Zeitdifferenzen verwenden wie PHP `TIMEDIFF` einschließlich dessen Wertebereich.
- **Servicezeiten (PHP 2):** Servicepreis größer null, Exportdatum nicht null, Erledigungsdatum mit denselben offenen Grenzen; keine zusätzliche Status-/Stornoprüfung. Zeigt wie PHP Auftragsnummer, Bestellzeit, Service-/Auftragspreis und Fahrzeugtyp. Der Name bezeichnet in der Altanwendung keine gemessenen Standzeiten; die Oberfläche erklärt das. Doppelte Fahrzeugtypbezeichnungen vervielfachen keine Aufträge.
- **Ziel-PLZ / Ziel-PLZ und Ort (PHP 5/6):** Auftragsdatum einschließlich Randsekunden, abgeschlossene Aufträge mit Storno null/0/1/3, alle Stationen ab Position 2. Gruppierung nach Zahler, PLZ, gegebenenfalls Ort, Auftragsmonat und Fahrzeugnummer. Führende PLZ-Nullen bleiben erhalten. Die Datumsbeschriftung zeigt hier zutreffend „Auftragsdatum“.
- **Etappenpreise (PHP 7):** positive Etappenpreise mit Servicebezeichnung „Fixpreis“ oder „ nach “; echte Exportzeit ohne Null-/9999-Platzhalter, einschließlich Erledigungsgrenzen. Gruppierung nach dem ungerundeten gespeicherten Preis; Anzeige auf zwei Stellen. Anzahl PLZ, Anzahl Fix und Summe, keine zusätzliche Status-/Stornoprüfung.
- **Auftragsherkunft (PHP 16):** alle Kunden und Auftragsstatus der eigenen Niederlassung nach Auftragsdatum, Storno null/0. Bestehende Herkunftscodes 0–8 einschließlich unbekannter/fehlender Codes; numerische Normalisierung des alten Feldformats. Der geprüfte Septemberbestand liefert dieselben 76 Aufträge und Bezeichnungen wie PHP.
- **Ausgabe:** 50 Zeilen je Bildschirmseite, maximal 5000 Ergebniszeilen; größere Ergebnisse werden vollständig abgewiesen statt abgeschnitten. CSV wird serverseitig für den gesamten gewählten Zeitraum neu berechnet, mit UTF-8/BOM, Semikolon, Dezimalkomma und Schutz vor Formelinterpretation. Geänderte Filter kennzeichnen die bisherige Ergebnisliste. Keine Archivtabellen oder verdeckten Rückfragen bei separaten Datenbankservern; Datenzugriff ausschließlich über den konfigurierten `DatabaseService`, nur lesend.
- **Weiterhin offen:** PZM-Vergleich/-Zonen sowie die übrigen Kunden-/Zugangs-/Mail-/BWV-Einstellungs- und Spezialübersichten. Konservennutzung/-übersicht, Transporteursliste und ausländische Rechnungsanschriften wurden anschließend ergänzt (siehe oben).

## Kundenumsätze und Rechnungsnavigation in Berichten – 14. Oktober 2026

- Aktuelle Referenz direkt per SSH von `/data/0/votian-test/html`, Git **`24094e2`**: `groupware/report.php`, `statistic/statistic_sql.inc.php` (`getCsStatistic`) und Rechnungsrahmen/-kopf. Angemeldete alte Kundenberichts- und Rechnungsoberfläche lesend geprüft; kein Rückgriff auf den früheren lokalen PHP-Bestand.
- **Einstieg:** Verwaltung → Kundenberichte → Kunde auswählen. Drei Netto-Umsatzwerte: laufendes Jahr bis heute, Vorjahr bis zum Vergleichstag und gesamtes Vorjahr. Unabhängig vom Berichtszeitraum und dessen Seitengrenze; nur der ausgewählte Kunde, ohne Unterkunden. Wie PHP wird am 29. Februar der 1. März des nicht schaltenden Vorjahrs als Vergleichstag verwendet.
- **Berechnung:** Summe `job.jb_totalprice` nach Erledigungsdatum, `jb_status=2`, Stornostatus null/0/1/3 und Niederlassung des Kunden. `GLOBAL_USE_RELATED_CUSTOMER` bestimmt die Zuordnung über `csc_id_related` statt `csc_id_payer`. Keine zusätzlichen Angebots-/Barzahlungsfilter, keine Kostenaufteilung und keine Archivtabellen. Deshalb können die Jahreswerte von den anders gefilterten Abrechnungsleistungen abweichen; die Oberfläche erklärt dies.
- **Navigation:** „Leistungen anzeigen“ übernimmt Kunde und Zeitraum des jeweiligen Vergleichs in die native Abrechnung. „Rechnungsübersicht“ übernimmt den Kunden und den laufenden Monat bis heute. Direkte Kundenstammbearbeitung; nach Schließen bleibt die Berichtsauswahl einschließlich Filter/Liste erhalten. Ungespeicherte Rechnungszuordnungen erhalten einen Verwerfendialog; während einer laufenden oder unklar beantworteten Speicherung bleibt der Dialog bis zur erneuten Prüfung offen.
- **Rechte:** Kunden-/Berichtsrechte 0/16; andere Niederlassungen nur mit Masterrecht 10 im eigenen Mandanten. Abrechnung zusätzlich Recht 5 und eigene Niederlassung, Stammbearbeitung ebenfalls eigene Niederlassung. Fehlende Berechtigungen bzw. die Niederlassungsgrenze werden angezeigt. Neue Umsatzabfrage ausschließlich lesend über `DatabaseService`; keine Schemaänderung und kein zusätzlicher Buchungsprozess.
- Zwei echte Kunden wurden lesend mit den drei aktuellen PHP-Summen abgeglichen: Ergebnisse stimmen überein. Vollständige Rechnungserstellung, Nummern-/Buchungsläufe und übrige in der Übersicht genannte Funktionslücken bleiben separat offen.

## Zweite Stammdatenseiten und Transporteur-Zusatzformulare – 14. Oktober 2026

- Referenz frisch per SSH aus `/data/0/votian-test/html`, Git **`24094e2`**: Kunden-, Transporteur- und Fahrzeugmasken, `metafield_special.php` und `inc_metafield.inc.php`. Die drei alten Formularmasken wurden im angemeldeten Browser lesend geprüft; kein früherer lokaler PHP-Bestand als Referenz.
- **Einstieg:** Kunde/Transporteur/Fahrzeug bearbeiten → „Zusatzformulare / 2. Seite“. Kategorien 2 (Kundenhinweis/Disclaimer), 3 (Transporteur) und 4 (Fahrzeug) sowie zusätzliche Transporteurkategorien aus dem globalen Parameter `MASK_FORMS_CR`. Vorhandene Vorlagen und Feldreihenfolge, globale bzw. niederlassungsbezogene Felddefinitionen, Bearbeitung, Rücksetzen, Feldhistorie mit Folgeseiten und Druckansicht mit Browserdruck/PDF. Entwurfsschutz bei Wechsel, Neuladen und Schließen.
- **Feldtypen:** Text, mehrzeiliger Text, Zahlen einschließlich PHP-Rundung, Checkboxen, Datum, Uhrzeit und Datum/Uhrzeit. Gültigkeits-/Warndaten (`triggerdate`, `triggerdate_single`, `triggerdatetime`) bleiben im PHP-Speicherformat; `datetime` enthält ein Leerzeichen vor der Uhrzeit, `triggerdatetime` entsprechend der aktuellen PHP-Implementierung keines. Ungültige Kalenderdaten/Uhrzeiten und Zahlen werden vor dem Schreiben zurückgewiesen.
- **Vorlagen und Links:** ausgewählte automatische Firmen-, Kontakt-, Bank- und Niederlassungsfelder einschließlich Logo; aktuelle Benutzer-/Datumswerte. Automatische Daten werden nur für den zutreffenden Objekttyp aufgelöst. Falsch zugeordnete Kundendatenfelder in einer Transporteurvorlage lesen keinen zufällig gleich nummerierten Kunden. Nicht unterstützte Spezialfelder bleiben lesbar und unverändert. Konfigurierte statische Links wie „Vorort-Kontrollen“ öffnen die PHP-Zielseite; dies ist kein nativer Ersatz für die verlinkte Sonderfunktion. Aktive Skripte und beliebige Datenbankausdrücke werden nicht ausgeführt.
- **Integrität:** Kundenrecht 0 bzw. Transporteurrecht 1, jeweils eigene Niederlassung; Fahrzeugzugriff über den zugehörigen Transporteur. Kategorie-/Objekttypabgrenzung, Revisionsschutz für Werte und Schema, dauerhafter Wiederholungsbeleg. Werte, konfigurierte Feldhistorie und Auditauftrag werden gemeinsam in vorhandenen InnoDB-Tabellen gespeichert; Fehler rollen vollständig zurück. Kurze Tabellensperren sichern auch gegenüber PHP-Schreibern ohne eindeutigen EAV-Schlüssel ab. Keine Schemaänderung; alle SQL-Zugriffe über `DatabaseService`.
- **Aktueller Bestand:** Kundenformular 1 Feld, Transporteurformular 28 Felder, Fahrzeugformular 2 Felder; alle über den neuen Backendpfad erfolgreich gelesen. `MASK_FORMS_CR` ist derzeit leer, daher sind weitere Transporteurvorlagen noch nicht freigeschaltet. Die Funktion ist mit konfigurierten Zusatzvorlagen in einer isolierten Datenbank geprüft. Bestehende PHP-Hintergrundläufe verwenden die Warndaten weiterhin; NG ergänzt in diesem Block keinen eigenen Warnversand oder SAP-Exportlauf.

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

- Frische Referenz ausschließlich per SSH: `172.16.0.158:/data/0/votian-test/html`, Git `24094e2`. `admin/customer_service.php`, `include/inc_geo.inc.php`, `import/import_ZONE.php`, `import/import_ZONEAGIO.php`, `import/import_RADIUSZONE.php` und Datenübertragungsseiten gelesen. Angemeldete PHP-Serviceverwaltung und deren Importfenster lesend geprüft.
- Unter **Kunde bearbeiten → Zonen und Servicevorgaben** stehen drei CSV-Importarten und „Radien neu berechnen“ zur Verfügung. Datei oder eingefügter Inhalt, UTF-8/Windows-1252, Semikolon, ohne Kopfzeile, Anführungszeichen, Dezimalkomma/-punkt und führende deutsche PLZ-Nullen. Maximal 1 MB / 5000 Zeilen. Unbekannte oder mehrdeutige PLZ/Zonen, doppelte Zuordnungen und ungültige Werte werden mit Zeilennummer abgewiesen; keine Teilimporte.
- `ZONE`: Spalten `Zonennummer;Land;PLZ;Express;Zonenaufschlag;Zusatzwert 3`. Ersetzt nur Zuordnungen der in der Datei genannten Kundenzonen; deren vier Stammpreise bleiben erhalten. Andere Zonen bleiben bestehen. Leeres Land und `D` bedeuten `DE`; ungültige Länderkürzel werden ausdrücklich zurückgewiesen statt unbemerkt Deutschland zuzuordnen.
- `ZONEAGIO`: Spalten `PLZ;Zonenaufschlag`. Wie PHP werden die Aufschläge sämtlicher Kundenzuordnungen zurückgesetzt und danach die CSV-Werte übernommen. Vorschau zeigt auch die auf null fallenden Einträge; Express und Zusatzwert 3 bleiben erhalten.
- `RADIUSZONE`: Spalten `Radiusbereich;PLZ;Bezirk/Stadt`. Ersetzt nur genannte Radiusbereiche; neue Preise sind 0. Die falschen/mehrfach angegebenen `srvz_id`-/`srvr_zipcode`-Spalten und der falsche Formularverweis des aktuellen PHP-Imports werden nicht übernommen; stattdessen werden `srvr_radiusarea_no` und `srvr_city_district` verwendet.
- Automatische Berechnung: Abhol-/Lieferadresse (Adressart 4) der Hauptkostenstelle, ersatzweise Firmenanschrift; vorhandene native Geokodierung, Radiusintervalle `CUSTOMER_SERVICE_RADIUS_INTERVALS_<Kunde>` (Standard `1=10|2=20,10|3=30,20`), `GEO_EARTH_RADIUS` und `phoenix_special.cityradius`. Sortierte Intervallschlüssel ergeben Bereichsnummern ab 1. Kugelentfernung mit innerer Grenze einschließlich / äußerer ausschließlich, PHP-Regeln zum Unterdrücken doppelter/unspezifischer Bezirkszeilen. Ungültige/überlappende Intervalle, uneindeutige Adresse, leere Treffer oder fehlende Geodaten löschen keine bestehenden Zuordnungen.
- Alle Änderungen haben eine verbindliche Vorschau mit bisherigen und neuen Werten, inklusive entfallender Radiuspreise. Speichern berechnet/validiert erneut und prüft Bestand sowie Vorschau; zwischenzeitliche Änderungen werden nicht überschrieben. Fachänderung, Auditauftrag und Wiederholungsbeleg sind atomar in bestehenden InnoDB-Tabellen; `serviceplz`/`cityradius` werden ausschließlich gelesen. Datenzugriff nur über `DatabaseService`, keine Schemaänderungen. Rechte 0/2 und eigene Niederlassung; CSV zusätzlich Importrecht 22.
- **Aktuelle Betriebsgrenze:** `phoenix_special.cityradius` ist auf dem Bestandsserver vorhanden, aber leer. Die Berechnung ist implementiert und mit synthetischen Ortskoordinaten gegen MariaDB geprüft; reale Radiusneuberechnungen benötigen zunächst den Orts-/Bezirksbestand. Die Oberfläche meldet diese fehlende Voraussetzung und sperrt die Berechnung. Die CSV-Importe bleiben verfügbar. Allgemeiner Datentransfer, FTP/SFTP und weitere Importformate sind damit noch nicht vollständig portiert.

## Kundenpreisformulare, Abnahmeprotokolle und Abliefergründe – 14. Oktober 2026

Referenz frisch per SSH aus `/data/0/votian-test/html`, nun Git **`24094e2`**, nach `work/php-customer-special-2026-10-14` übertragen. Die PHP-Oberflächen `customer_service_acceptance_protocol.php`, `customer_service_delivery_reasons.php` (einschließlich Listenwechsel) sowie `metafield_special.php` mit Kategorien 20 und 25 wurden angemeldet gelesen. Speicherformat anhand dieser Quellen, `inc_metafield.inc.php` und `global.inc.php` abgeglichen. Keine alten lokalen PHP-Quellen verwendet.

- **Einstieg:** Kunden → Bearbeiten → „Kundenformulare und Abliefergründe“. Stammdatenentwurf vorher speichern. Formularwechsel und Schließen schützen ungespeicherte Eingaben durch den eigenen Anwendungsdialog.
- **Abnahmeprotokolle:** Auswahl aus dem allgemeinen Servicekatalog, wie PHP ohne Service Nr. 1. Fragen ergänzen, ändern, entfernen und umordnen; „Keine Mail“, „Mail bei Ja“ oder „Mail bei Nein“ bleibt der jeweiligen Frage zugeordnet. Abschlusstext je Service. Bis zu 21 bestehende Einträge entsprechend der PHP-Leseschleife. Nicht fortlaufende Servicenummern und Konfigurationen aller anderen Services bleiben erhalten. Dies pflegt die Konfiguration der vorhandenen Endgeräte-/Versandprozesse; NG löst beim Speichern keine E-Mail aus.
- **Abliefergründe:** vier unabhängige Listen mit Code/Text, Pflege und Reihenfolge. Leere Codes sind wie in PHP möglich; doppelte nichtleere Codes werden zurückgewiesen. Die in PHP auskommentierten Mail-/Textfunktionen werden nicht angeboten; entsprechende Altwerte bleiben erhalten. Entfernen aller Zeilen leert ausschließlich die ausgewählte Liste.
- **Bestandsformat:** die vorhandenen `genericdatacontainer`-Felder und PHP-Trennzeichen werden unverändert verwendet. Reservierte Trennzeichen werden mit verständlicher Meldung abgewiesen, damit keine Fragen/Gründe unbemerkt zerlegt werden. Doppelte Container bzw. mehrdeutige Schlüssel müssen vor einer Bearbeitung geklärt werden.
- **Preisformulare 20–25:** kundengebundene Werte, globale oder niederlassungsbezogene Felddefinitionen, vorhandene Vorlagen, Bearbeitung, Rücksetzen, Feldhistorie und Druckansicht mit Browserdruck/PDF. Text, mehrzeiliger Text, Zahlen, Checkboxen, Datum und Uhrzeit werden unterstützt. Nicht unterstützte Spezialfelder sind nur lesbar und bleiben erhalten; keine PHP-/JavaScript-Skripte oder beliebigen DB-Ausdrücke werden ausgeführt. Die Formulare verändern die ihnen zugeordneten Metafelder, nicht nebenbei die Servicepreismatrix.
- **Aktuelle Bestandskonfiguration:** Alle sechs Kategorien sind vorhanden, haben aber derzeit weder Feldzuordnungen noch eine verfügbare zugeordnete Vorlage. Auch der allgemeine Servicekatalog für Abnahmeprotokolle ist leer. Die native Ansicht weist darauf hin, ohne Standardfelder, Servicearten oder Preise zu erfinden. Abliefergrundlisten sind unabhängig davon verfügbar. Felddefinitionen können über die bestehende Formularverwaltung zugeordnet werden; die fachliche Servicekonfiguration muss im Bestand vorhanden sein.
- **Integrität:** Kunden-/Verwaltungsrechte 0/2, eigene Niederlassung, Revisionsschutz für Werte und Schema, dauerhafte Vorgangsbelege und Audit. Kurze Tabellensperren schützen auch vor parallelen PHP-Schreibern auf den Tabellen ohne eindeutige EAV-/Container-Schlüssel. Alle Änderungen erfolgen gemeinsam in InnoDB über `DatabaseService`; keine Schemaänderung, keine MyISAM-Geschäftsschreibzugriffe. Ein Fehler bei Feldhistorie oder Audit rollt die gesamte Änderung zurück.

Automatische Radiusberechnung und Kunden-Zonenimporte sind inzwischen ergänzt (siehe Abschnitt oben); die in der Übersicht genannten übrigen Menüs bleiben offen. Dieser Block ersetzt nicht sämtliche denkbaren Spezialfeldtypen oder beliebige Template-Skripte.

## Kunden-Servicezonen und Zeitvorgaben – 14. Oktober 2026

Referenz erneut direkt per SSH gelesen: `/data/0/votian-test/html`, Git `868db70`, 650 Einträge aus `admin` und `include` im frischen, ignorierten Snapshot `work/php-current-2026-10-14`. Aktuelle PHP-Kundenliste, Kundenstamm und Servicemaske `admin/customer_service.php` einschließlich Zonen, Radien, Tageszeiten, Rabattaktionen und Versandzeitvorgaben angesehen. Für die PHP-Ansicht wurde ein Kunde mit bereits vorhandener Auslieferart gewählt, damit deren automatische Standardanlage beim Öffnen nicht ausgelöst wird. Das Datenbankschema wurde ausschließlich lesend geprüft.

- **Einstieg:** Kunden → Bearbeiten → „Zonen und Servicevorgaben“. Vorherige Stammdatenänderungen müssen gespeichert sein. Drei Bereiche mit Suche, seitenweiser Anzeige der Zuordnungen und eigenem Entwurfsschutz.
- **Servicezonen:** anlegen, umbenennen und als Niederlassungsadministrator einschließlich zugehöriger PLZ-Verknüpfungen löschen. Feste Zonennummern; Umbenennen erhält alle vier gespeicherten Preise. Vorschau nennt bei einer Löschung die betroffene Anzahl und die Preiswerte als mitbetroffene Daten. PLZ mit Länderkürzel aus dem Basisbestand zuordnen/entfernen, kundenspezifisch eindeutige Zuordnung. Vorhandene Express-/Zuschlagswerte werden angezeigt und nicht nebenbei überschrieben.
- **Radiuszuordnungen:** manuelles Anlegen, Bearbeiten und Entfernen von deutscher PLZ, Bezirk/Stadt und Bereichsnummer. Mehrere Bezirke je PLZ möglich; identische Kombinationen werden abgefangen. Änderungen erhalten den bestehenden Radiuspreis. Die automatische geografische Neuberechnung und die Kunden-Zonenimporte wurden anschließend ergänzt (siehe oben).
- **Zeitvorgaben:** Tageszeitabschnitte und zeitabhängige Auslieferarten ergänzen/bearbeiten, nur den letzten Eintrag entfernen oder hinterlegte Standards übernehmen. Feste Nummern bleiben erhalten; Auslieferarten sind auf 0 bis 3 beschränkt. Verwendete Preis-/Zuschlagsspalten verhindern das Entfernen einer noch belegten Auslieferart. Tagesabschnitte verwenden das PHP-Format `HH:mm - HH:mm`; die Bestelluhrzeit verwendet `HH:mm`.
- **Rabattaktionen und Versandzeiten:** permanente Rabattaktionen mit Auswahl eines vorhandenen Artikelsonderpreis-Typs, Bearbeitung, Entfernen des letzten Eintrags und Standardübernahme. SMS-/Rollkarten-Uhrzeit setzen und vorhandene Standards übernehmen. Dies pflegt die Konfiguration der bestehenden PHP-Versandläufe; NG startet dadurch keinen zusätzlichen Versanddienst. Separate Aktionspreisformulare (20–25), Abnahmeprotokolle und Abliefergründe wurden anschließend ergänzt (siehe folgenden Prüfstand).
- **Rechte und Integrität:** Kundenstammrechte 0/2 und eigene Niederlassung; Tageszeiten und Zonenanlage/-umbenennung zusätzlich Recht 29 oder Niederlassungsadministrator. Zonenlöschung und Rabattaktionen ausschließlich Administrator (`headquarters.hq_admin`). Änderungen mit Vorschau, kompletter Bestandsrevision einschließlich Standards, Sperren, wiederholbarer Vorgangskennung und Audit. Geschäftsschreibzugriffe ausschließlich über `DatabaseService`, vollständig in vorhandenen InnoDB-Tabellen; keine Schemaänderung. Die PLZ-Basistabelle wird nur gelesen.

## Aktueller Serverabgleich und Ergänzungen – 13. Oktober 2026

Ausschließlich SSH-Serverquelle `/data/0/votian-test/html`; letzter dort gemeldeter Git-Commit `868db70` vom 13. Oktober 2026, 16:18:15 UTC. Verglichen wurde der tatsächlich vorhandene Dateistand einschließlich nicht eingecheckter/generierter Dateien. Die relevanten 1.199 Dateien in den Fachordnern wurden beim Übertragen per SHA-256 geprüft. Die Arbeitskopie unter `work/php-current-2026-10-13` ist ein ignorierter Server-Snapshot; der frühere lokale PHP-Bestand wird nicht mehr gelesen. Einzelne generierte `job_options_<hq>.js` ändern sich im laufenden PHP-Betrieb und wurden erneut vom Server geholt. Für den anschließenden Artikel-/Unterauftragsblock wurden 778 Einträge aus `jobs`, `admin`, `include` und `stock` erneut direkt vom Server übertragen.

- **Foto-Workflow-Sets:** Kundenfreigaben über `/sets/kunde/{id}`, gegebenenfalls allgemeine Sets über Kunde 0. Auswahl eines Sets für den Auftrag, passende Stationsflows, FIRST/MIDDLE/LAST-Vorbelegung, eine Einzelstation zählt als LAST. Mengenbereiche werden angezeigt. Setwechsel verwirft Stationsabweichungen. Set und Stationsauswahl sind Teil der Preisvorschau und werden zusammen mit dem Auftrag in einer InnoDB-Warteschlange gesichert. Übertragung über `/selection/set` und danach `/selection`; Fehler halten direkte Disposition zurück und werden erneut versucht. Vorhandene Warteschlangen ohne Set bleiben lesbar. Die PHP-Funktion `photoScopeMatches` verwendet historisch `ware=1` für PICKUP_ONLY und `ware=2` für DELIVERY_ONLY; diese tatsächliche Zuordnung wird beibehalten, obwohl die englischen Namen zur NG-Stationstypbezeichnung gegenläufig wirken.
- **Adressvorschläge:** Kunden, Transporteure und die Anschriften der Kostenstellen verwenden [Google Places Autocomplete](https://developers.google.com/maps/documentation/places/web-service/place-autocomplete) und [Place Details](https://developers.google.com/maps/documentation/places/web-service/place-details). Straße, Hausnummer, PLZ, Ort und Land werden gemeinsam übernommen; unvollständige deutsche PLZ-Präfixe bleiben leer. Schlüssel bleibt serverseitig, Suche benötigt die jeweiligen Stammdatenrechte. Manuelle Eingabe bleibt bei Dienstausfall möglich.
- **Kostenstellensuche:** Schalter „Kostenstellen anzeigen“, eigener Namensfilter, eine Zeile pro passender Kostenstelle und direkter Einstieg in ihre Pflege. Kundenfilter und Niederlassungsrechte gelten auch für diese Zeilen; deaktivierter Schalter liefert weiterhin eine Zeile pro Kunde.
- **Auftragsbearbeitung:** Stamm-/Stationsdaten, Zuweisung/Rückruf/Annahme, einzelner oder vollständiger Abschluss, manueller Fixpreis mit Begründung und Storno/Gegenbuchung. Quittungen und erledigte Stationen werden geschützt; Export/Rechnungszuordnung verhindert reguläre Änderungen. Adress-/Zeitänderungen verlangen erneute Preisprüfung. Automatische Neukalkulation für vorhandene Stationen einschließlich PLZ-/Bereichs-, Kilometer-/PZM-, Fest- und Leistungspreisen und Kostensplit ergänzt. Artikelpflege und ergänzende Lager-/Gegenbuchungen sowie gemeinsame Nachkalkulation bestehender Kurier-Unteraufträge sind ergänzt (Details unten). Erweiterung/Entfernung von Belegpaaren sowie gemeinsames Storno einschließlich Einnahmenausgleich sind inzwischen umgesetzt. Weitere Hintergrundprozesse bleiben offen.
- **Stammdaten/Abrechnung:** Historische Auftragsadressen bleiben beim Ändern eines Stamms unverändert. Rechnungszuordnungen werden vor dem nicht rückrollbaren MyISAM-Schritt gesichert und können nach Teilfehlern fortgesetzt werden. PDF ist eine Leistungsübersicht/Rechnungsanlage, keine vollständige Rechnungserstellung.

Zahlungsbedingung als Auftragssnapshot und Exportfeld umgesetzt. Der aktuelle PHP-Code benutzt `jobprice.mt_sort=16` sowohl für den Kilometerpreis als auch für die Zahlungsbedingung. NG bewahrt daher Wert und Text in separaten `genericdatacontainer`-Einträgen; alte PHP-Zahlungsbedingungen werden gelesen, Kilometerpositionen bleiben erhalten. Weitere offene Menüs und Teilfunktionen stehen in der Tabelle oben. Dies ist kein Nachweis vollständiger PHP-Parität.

## Artikel, Lager und bestehende Unternehmerverrechnung – 13. Oktober 2026

- **Artikel im Bestandsauftrag:** „Bearbeiten / Aktionen → Artikel und Lager bearbeiten“. Freie und Stammartikel hinzufügen, ändern, einer offenen Station zuordnen und entfernen. Bezeichnung, Stückzahl, Gesamtgewicht, Packstücke, Artikelwert, Seriennummer und Hinweis. Bestehende `trat_id` und Scan-Nachweise bleiben erhalten; gescannte und abgeschlossene Positionen sind geschützt. Artikelpflege löst keine automatische Lagerbuchung aus.
- **Lagerjournal am Auftrag:** Bewegungen anzeigen; Wareneingang, Auslagerung und Umlagerung mit Vorschau buchen. Gegenbuchungen ergänzen das Journal und markieren den korrigierten Eintrag. Rechte 4/7/14, Niederlassungs-/Kundenzuordnung, Lagerhierarchie, Bestand, Kapazität und Seriennummer werden geprüft. Request-ID, Revision und Transaktion verhindern doppelte oder halbe Buchungen. Bei neuen Seriennummern-Auslagerungen sichert NG die 25 Zusatzfelder in `genericdatacontainer`; eine Gegenbuchung stellt sie wieder her. Historische Zusatzdaten aus `stkmv_data` und Bündel-Gegenbuchungen innerhalb desselben Auftrags sind inzwischen unterstützt; fehlende Seriennummern-Zusatzdaten können ausdrücklich ergänzt werden. Auftragsübergreifende Bündel benötigen weiterhin die vollständige Lagerverwaltung.
- **Bestehende Kurier-Unteraufträge:** Beträge und Unternehmerfahrzeug eines vorhandenen Belegpaars im Kalkulationsbereich ändern. Kundenpreis, Frachtvergütung, Zuschläge, Servicepreis, Steuer, erster Mautanteil und beide Vorzeichen werden gemeinsam gespeichert. Auftragsnummern, Tour-IDs und Zustellnachweise bleiben erhalten. Jede beteiligte Revision wird geprüft; Rechnungszuordnung, Export, Einnahmen, Fremdniederlassungen und beschädigte Belegketten verhindern die Änderung. Voraussetzung: erledigter Inlands-Hauptauftrag und einfache, ausgeglichene Belegpaare. Neue Paare anlegen/aufheben und gemeinsame Stornoabläufe sind inzwischen ergänzt (siehe folgenden Abschnitt).
- **Referenz:** aktuelle Serverdateien `include/caglobal.inc.php`, `include/inc_stock.inc.php`, `include/inc_job.inc.php`, `admin/sort.php`; angemeldete PHP-Auftragserfassung, Auftragsdetails und Lageransicht lesend geprüft. Der separate PHP-Calculator öffnete ein durch die Browsersteuerung nicht erreichbares Popup; dessen Logik wurde anhand des aktuellen Servercodes abgeglichen.

## Unternehmerbelegpaare, gemeinsame Korrektur und Lagerzusatzdaten – 13. Oktober 2026

Referenz erneut direkt per SSH aktualisiert: Git `868db70`, 778 Einträge aus `jobs`, `admin`, `include`, `stock`. PHP-UI `admin/jb_list.php` und `stock/stock.php` einschließlich ausgewähltem Hauptlager TOSHIBA lesend angesehen. Aktive Stornologik in `admin/jb_list.php` und `jobs/job_options.php`; der alte `cancelJob`-Block in `include/inc_job.inc.php` ist auskommentiert. Weitere Quellen: `include/caglobal.inc.php`, `include/inc_stock.inc.php`, `include/services_func.inc.php`.

- **Belegpaare im Bestandsauftrag:** Unternehmer hinzufügen, Fahrzeug/Betrag ändern und Paare aufheben. Die Preisvorschau zeigt neue, geänderte und aufgehobene Belege. Stabile positive Beleg-IDs ordnen Eingaben zu; unbekannte/doppelte IDs werden abgewiesen. Entfernte Paare werden durch zwei Gegenbuchungen ausgeglichen; Originale und Zustellnachweise bleiben erhalten. Die bisherigen Elternzuordnungen werden in `ng_previous_parent` dokumentiert und aus `jb_id_parent` gelöst, da auch PHPs `getJobChildren` stornierte Zuordnungen sonst erneut einlesen würde. Es gelten weiterhin Recht 38, erledigter Inlandsauftrag, einfache ausgeglichene Paare, keine Einnahmen oder abgerechneten Belege bei der Neukalkulation.
- **Gemeinsamer Storno / Gutschrift:** eigener Dialog unter Bearbeiten / Aktionen mit allen Belegnummern, Nettobeträgen, Frachtvergütung, Maut und Einnahmen. Storno verlangt nicht abgerechnete Belege; Gutschrift erlaubt bereits exportierte/zugeordnete erledigte Originale. Recht 4/7, für Unternehmerpaare zusätzlich 38. Neue Gegenbuchungen sind unabhängige Belege. Originale mit Gutschrift sind für weitere NG-Bearbeitung gesperrt. Offene Disposition wird zurückgenommen; bestehende Dauerauftragsregel kann ausdrücklich beendet werden.
- **Einnahmen:** zusätzlich Recht 5 und ausdrückliche Bestätigung. Jede vorhandene Buchung erhält eine verknüpfte Buchung mit umgekehrtem Betrag; ursprünglicher Modus, Kostenstelle, Stationsnummer und Kassenschalter bleiben erhalten. Bereits exportierte Datensätze werden nicht überschrieben; die Gegenbuchung ist noch nicht exportiert. Dies ist ein Buchungsausgleich, keine tatsächliche Rückzahlung. Anders als PHPs Löschung nicht exportierter Einnahmen bleiben Originalbuchungen nachvollziehbar.
- **Stornogebühr:** wie der aktuelle PHP-Stornopfad ohne zusätzlichen Rabatt und ohne zusätzliche Unternehmergebühr. Die Gebühr wird centgenau auf vorhandene Kostensplit-Zahler verteilt und in der gespeicherten Nettosumme berücksichtigt. Gegenbuchungsbeträge folgen den tatsächlichen Rechnungspositionen; ohne Positionen gilt der gespeicherte Auftragspreis. Eine fehlende Ursprungsposition wird bei gebührenpflichtiger Korrektur als negative Basisposition ergänzt, damit die Abrechnung nicht nur die Gebühr enthält.
- **Lagerzusatzdaten:** TAN, Zusatzdatum und bis zu 25 Zusatzfelder; Anzeige im Journal und in der Buchungsvorschau. Einlagerungen mit Seriennummer speichern diese Angaben auch am Artikel. Gegenbuchungen verwenden gesicherte Artikeldaten, ersatzweise die historischen `<br>`-getrennten PHP-Journaldaten. Fehlende alte Angaben müssen ausdrücklich ergänzt werden. Bündel werden anhand `at_id_bundle` und Buchungszeitpunkt vollständig in umgekehrter Reihenfolge gegengebucht; alle Komponenten werden gemeinsam auf Bestand/Kapazität geprüft. Bereits teilweise korrigierte oder auftragsübergreifende Bündel werden abgewiesen, ohne Teilbuchung.
- **Integrität:** alle Geschäftsschreibzugriffe über `DatabaseService`, vorhandene InnoDB-Tabellen, keine Schemaänderung. Vorschau-Fingerprint, Versionsvergleich, Sperren, Wiederholungsbeleg und Audit innerhalb derselben Transaktion. Bei unklarer Speicherantwort wiederholt die UI denselben Vorgang. Kein fachlicher Schreibtest gegen echte Geschäftsdaten.

Offen bleiben die weiteren Menübereiche der Tabelle, insbesondere vollständige Lagerverwaltung einschließlich auftragsübergreifender Bündel, zusätzliche Sonderbeziehungen/B2B-Hintergrundprozesse, weitere kundenbezogene Spezialformulare, Zugangsverwaltung, Listenerfassung, vollständige Rechnungs-/Buchhaltungsläufe und Spezialstatistiken.

## Ergänzte Teilfunktionen – 13. Oktober 2026, weiterer Ausbau

- **Neukalkulation bestehender Aufträge:** Preisvorschau und Übernahme ohne erneute Auftragserzeugung. PLZ-/Bereichstarife, Kilometer-/PZM, Festpreise, Leistungskalkulation, Zuschläge, Steuer und Kostensplit. Versions- und Rechteprüfung, Frachtvergütungsgrenzen, Audit und Wiederholungsbelege; bereits erledigte Stationen, Fotos und Lagerbewegungen bleiben erhalten. Bestehende einfache Unternehmer-Belegpaare können inzwischen gemeinsam nachkalkuliert werden. Aufträge mit Einnahmen, abgerechneten Belegen oder Sonderverknüpfungen werden weiterhin ausdrücklich abgewiesen. Manuelle Preisänderung verwirft veraltete Kalkulationsvorgaben; Adresswechsel entfernt die alte Abrechnungs-PLZ. Einzelstationen können bearbeitet werden.
- **Zahlungsbedingung:** PHP-Wert (z. B. ZA10) und lesbarer Text werden beim Erstellen festgehalten, in Gegenbuchungen übernommen und in Abrechnung/CSV ausgegeben. Keine nachträgliche Ersetzung historischer Werte durch den aktuellen Kundenstamm.
- **Gruppen:** Niederlassungsauswahl mit Masterrecht 10 im eigenen Mandanten. Vorschau zählt betroffene Zuordnungen. Löschung entfernt ausschließlich die betreffende Mitgliedschaft, schützt System-/readonly-Gruppen und hält einen dauerhaften Wiederaufnahmeplan vor. Kurzzeitige Tabellensperren koordinieren die abschließende Bereinigung mit PHP; ein MyISAM-Teilabbruch ist wiederholbar.
- **Anfahrtszeiten:** Leer oder 0 übernimmt den gültigen Niederlassungsstandard. Fehlt dieser, wird vor dem Schreiben eine konkrete Fehlermeldung angezeigt.
- **Nachrichten:** Zusätzliche Logtyp-203-Ereignisse für Nachrichtengruppen, Mitgliederzuordnungen und Gesamtversand über die bestehende Audit-Warteschlange. Der Versandprotokolleintrag dokumentiert den Versandversuch, keine garantierte Gerätezustellung.
- **Berichtsformulare:** Kategorien 101 und 102 sind direkt an Kunden-/Transporteursberichte gebunden. Aktueller Serverbestand: 23 bzw. 109 Felder. Vorlagenbasierte Bearbeitung, Fahrzeugauswahl, Checkboxen, Datum/Uhrzeit, Freitext, automatische Kunden-/Umsatz-/Niederlassungsangaben, Feldhistorie und Druck/PDF. Berichtszugriff, Vertraulichkeit und Änderungsrechte gelten auch für diese Formulare; gleiche numerische IDs in anderen Objekttabellen vermitteln keinen Zugriff. Das Bericht-Menü nennt 102 „Fahrzeugkontrolle“, die tatsächliche Vorlage heißt „Vorortprüfung Kundenbefragung“. Vorlagenskripte werden nicht ausgeführt.
- **Kunden-Servicezuordnungen:** Auswahl und Reihenfolge von Preis-/Leistungstypen in beiden Servicemodi, inklusive Mandantenkonfiguration und Schutz veralteter Bearbeitungsstände. Änderungen an MyISAM-Zuordnungen werden vorab gesichert und nach Teilfehlern anhand des gespeicherten Plans fortgesetzt. Preis-/Leistungstypen anderer Modi bleiben beim Moduswechsel ausgewählt. Servicezonen, manuelle Radien, permanente Rabattaktionen und Spezialzeitvorgaben wurden am 14. Oktober ergänzt (siehe unten). Automatische Radiusberechnung, Kunden-Zonenimporte und die separaten Aktionspreisformulare wurden anschließend ebenfalls ergänzt.
- **Kostenstellen:** Die historische Zusatzadresse Typ 3 ist optional. Neue Stammkostenstellen verwenden die aktuellen Adresstypen 1/2/4; bestehende Zusatzadressen bleiben bearbeitbar.

Die Tabelle oben bleibt die Übersicht über den Gesamtumfang. Dieser Ausbau schließt insbesondere Rechnungserstellung/Spezialexporte, Spezialstatistiken, vollständige Listenfunktionen, Zugangsverwaltung und die ausdrücklich genannten Auftragssonderfälle noch nicht ab.

## MyISAM-Abhängigkeiten

Lesende Prüfung am 13. Oktober 2026 auf der Hauptverbindung: `phoenix` 26 MyISAM/86 InnoDB, `phoenix_group` 5/2, `phoenix_log` 15/7, `phoenix_pda` 5/1. Eine vorhandene MyISAM-Tabelle ist nicht automatisch eine von NG verwendete Tabelle. Direkt verwendet werden unter anderem `invoice`, `tax`, PLZ-/Adresszuordnungen, Kurierfilter und Kunden-Servicezuordnungen sowie Termine, Berichte, Nachrichten und Historie.

Die Häufigkeit hängt von Benutzeraktionen ab: Auftragsbearbeitung liest `invoice`, Kundenstamm lädt `tax`, Abrechnung liest `invoice` und schreibt Zuordnungen. Historienübertragung prüft alle 30 Sekunden die InnoDB-Warteschlange; MyISAM-Logzugriffe erfolgen nur für ausstehende Einträge (regelmäßig ein SELECT und bei fehlendem Eintrag ein INSERT). Die normale Listen-Autoaktualisierung ist standardmäßig ausgeschaltet und lädt bei Aktivierung alle 30 Sekunden die InnoDB-Kernlisten. Es gibt derzeit keine Messung pro Tabelle/Minute; aus Quellcode oder Tabellenanzahl lässt sich kein tatsächliches Zugriffsvolumen ableiten. Keine Engine- oder Schemaänderung durchgeführt.

## Nativ umgesetzter Verwaltungs- und Statistikblock

Die PHP-Oberflächen `admin/public_holiday.php`, `admin/traveltime.php`, `admin/group.php`, `admin/impressum.html` und `statistic/statistic.php` wurden im angemeldeten Browser angesehen und mit Quellcode, Schema und nativen Dialogen verglichen. Die Listenerfassung und Filterverwaltung wurden ebenfalls angesehen; sie sind dadurch noch nicht portiert. Kunden-/Transporteursberichte wurden im nachfolgenden Block ergänzt.

- Feiertage/Anfahrtszeiten verlangen Recht 2. Feiertage vergleichen den geladenen Jahresstand und sperren die Bestandszeilen beim Schreiben. CLASSIC ändert die lokale Zuordnung; BWV verwendet wegen MyISAM eine einzelne bedingte Aktualisierung je PLZ. Der zunächst fehlende Standardwert ist im aktuellen SSH-Abgleich aufgelöst; leer/0 übernimmt inzwischen `LATEST_TAKETIME_IN_MINUTES`.
- Gruppen benötigen Rechte 8 und 25. Änderungen an shared Gruppen verlangen zusätzlich Recht 10, einzelne Mitgliedsarten ihre jeweiligen Leserechte. System-/readonly-Gruppen sind geschützt, zyklische Gruppenbeziehungen werden abgewiesen. Mitgliedschaften verwenden die bestehenden kommaseparierten Felder und vergleichen den Bearbeitungsstand. Inzwischen ist die bestätigte Löschung belegter Gruppen mit Vorschau und wiederaufnehmbarer Zuordnungsbereinigung ergänzt (siehe aktuellen Ausbau oben).
- Statistik verlangt Recht 8, mehrere Niederlassungen zusätzlich Recht 10 und denselben Mandanten. Datumsgrundlagen: Erfassung, Buchung, Erledigung, Export, Auftrag. Raster: Gesamt, Tag, ISO-Woche, Monat, Jahr, halbe/eine/zwei Stunden. Bis zu fünf gleichzeitige Aufteilungen; maximal 5000 Ergebnisgruppen, bei Überschreitung Fehler statt Teilergebnis.
- Filter umfassen Status, Aufträge/Gutschriften, Zahlungsweise, Kunden-/Transporteursnummer und -gruppe, Nacherfassungen anhand des PHP-Protokolls, Dauer-/Fernaufträge, Uhrzeitfenster, kostenlose Stornos und zugeordnete Kunden. Nettowerte: Auftragswert, Frachtvergütung, EAU/BSG, Servicepreis/-vergütung, TSZ; KM und CO₂e mit Erfassungsabdeckung. Mehrdeutige Frachtvergütungen werden als unvollständig gekennzeichnet.
- Neue Dateien: `Administration.tsx`, `Statistics.tsx`, `AdminSupport`, `CalendarAdministration`, `GroupAdministration`, `AdministrationController`, `StatisticsService`, `StatisticsController`. Alle SQL-Zugriffe laufen über `DatabaseService`; keine Schemaänderung.

Diese Ergänzung schließt den gesamten Menüabgleich nicht ab. Die jeweils verbleibenden Teilfunktionen in Auftragsbearbeitung/Disposition/Storno, Listenerfassung, Stammdaten-/Tarifpflege, Rechnungen, Vertrieb, Nachrichten, Formularen und Datentransfer sind in der fortgeschriebenen Tabelle oben ausgewiesen.

## Kunden- und Transporteursberichte – Ergänzung vom 12. Oktober 2026

Die angemeldeten PHP-Ansichten `groupware/report.php` für `cs` und `cr` sowie die Berichtsstatistik wurden angesehen; Schreibpfade, Metatypen, Vertraulichkeit und Formularverknüpfungen wurden im Quellcode geprüft. Die native Umsetzung liegt in `Reports.tsx`, `ReportAdministration` und `ReportController` unter **Verwaltung → Kundenberichte / Transporteursberichte**.

- Eigene Berichtstypen aus `report_type` bzw. `report_type_2`, optional ohne Typ. Bestätigung des über `MASK_CS_REPORTTYPE_MISC_ITEM` konfigurierten allgemeinen Typs als Anwendungsdialog.
- Halbjahreszeitraum als Vorgabe, frei wählbarer Zeitraum, Niederlassungen, Kunde/Transporteur, Text und Berichtstyp. Hauptkunden schließen direkte Unterkunden ein. Sieben Sortierungen, 100 Einträge je Seite und Gesamtzahl statt unbemerkter Begrenzung.
- Neuanlage mit aktuellem Zeitpunkt, Benutzer und Niederlassung der Sitzung. Vorhandene Berichte bearbeiten, eigene Berichte nach Bestätigung löschen. Unveränderliche Zuordnung, Autor und Erfassungszeit. Entwurfsschutz beim Schließen, Bereichswechsel, Aktualisieren und Abmelden.
- Rechte: 16 plus 0 (Kunden) bzw. 1 (Transporteure). Bearbeiten durch Verfasser oder Recht 3; Löschen ausschließlich durch Verfasser. Niederlassungsübergreifend nur mit Recht 10 im selben Mandanten. Vertrauliche Einträge sind nur für Verfasser bzw. Recht 10 sichtbar – ausdrücklich auch bei Zählung und Statistik. Die ältere PHP-Statistik enthält diesen Vertraulichkeitsfilter nicht; die native Fassung übernimmt dieses Datenleck nicht.
- Statistik nach Niederlassung und Mitarbeiter, optional Berichtstyp und Kundentyp; vollständige Summen, maximal 5000 Gruppen mit ausdrücklichem Fehler bei Überschreitung, CSV mit Schutz vor Tabellenformeln. Statistik und Liste verwenden dieselben fachlichen Filter.
- `report_process` und `appointment` verwenden MyISAM. Aktualisierung/Löschung vergleichen deshalb sämtliche ursprünglichen Berichtsfelder in **einer** bedingten SQL-Anweisung; ein `FOR UPDATE` wäre hier kein zuverlässiger Schutz. Der optionale Terminabschluss wird nach bestätigter Anlage separat ausgeführt. Scheitert er, meldet die Oberfläche den Bericht trotzdem als gespeichert und bietet eine Wiederholung an. Diese Meldung lebt in der aktuellen Ansicht; es gibt keinen dauerhaften Wiederholungsauftrag. Kundenbezug, Berichtsniederlassung und ursprünglicher Berichtstag begrenzen den Abschluss; Kurier-IDs werden nie auf Kundentermine angewendet.
- Inzwischen ergänzt: Verkaufs-/Prüfformulare (101/102), Bearbeitung und Vorlagendruck/PDF sowie Kundenumsatzvergleiche und direkte Kundenstamm-/Rechnungsnavigation (siehe Prüfstand vom 14. Oktober oben). Offen bleiben weitere konfigurierbare Objektformulare einschließlich Upload/Template-Skripten. Der CRM-Folgetermin-Dialog wurde im folgenden Vertriebsblock ergänzt. Das Löschen entfernt wie PHP nur den Bericht, nicht separat gespeicherte Metafeldwerte. Der Berichtsteil ist daher noch kein vollständiger Ersatz sämtlicher PHP-Unterdialoge.

## Vertriebskalender und Termine – Ergänzung vom 12. Oktober 2026

Die angemeldeten PHP-Ansichten `groupware/appointment.php` (Kalender, Terminbearbeitung und Terminstatistik) wurden erneut direkt im Browser geöffnet und mit `groupware/calendar.php`, den Aktionspfaden sowie dem realen Schema und Metatypen abgeglichen. Native Umsetzung: `Appointments.tsx`, `AppointmentForm.tsx`, `AppointmentService` und `AppointmentController`; eigenes Hauptmenü **Vertrieb**.

- Tagesagenda, Wochenraster, Monatskalender und Jahresübersicht mit Wechsel zum Tag/Monat, Vor-/Zurücknavigation und Heute. Mehrtägige Termine erscheinen an jedem betroffenen Tag; die Statistik zählt jeden Quelldatensatz einmal. Ein Jahresabruf umfasst höchstens 5000 Termine; darüber erfolgt eine ausdrückliche Fehlermeldung. Statistik maximal zehn Jahre / 5000 Kategoriegruppen.
- Gemeinsame Filter nach Niederlassung, Ersteller/Teilnehmer, Kunde/Interessent, Status, Terminart, Kontrolle, Text und den fünf Sichtbarkeitsgruppen. Statistik nach allen vier Kategorien einschließlich unbekannter Bestandswerte und Kategorien ohne Treffer. Vorgabe wie PHP: eigene Niederlassung, eigener Benutzer und heutiger Tag; Statistik vom Jahresanfang bis zum gewählten Tag.
- Anlage/Bearbeitung mit Beginn/Ende, Text, Geschäfts-/Privatstatus, Sichtbarkeit, Terminart und Überwachung. Kategorien und globale Labelüberschreibungen stammen aus dem Bestand. Kunden-/Interessentensuche, Mitarbeiter und Teilnehmergruppen, Auswahl/Abwahl der angezeigten Gruppe. Allgemeine Terminart verlangt die konfigurierte Rückfrage als Anwendungsdialog.
- Eigene Teilnahme bestätigen; erledigen mit optionaler Prüfung eines sichtbaren Kundenberichts von heute; Wiedervorlage als separater Termin mit erhaltenem Text/Kunden-/Kontaktbezug und Teilnehmern. Erledigte Vorlagen werden wieder überwacht, Teilnahmebestätigungen der neuen Vorlage sind leer. Bei Verschiebung oder Entfernung eines Teilnehmers werden die betroffenen Bestätigungen zurückgesetzt.
- Im Vertrieb allgemeine oder kundenbezogene Berichte öffnen. In Kundenberichten Folgetermin aus einer vorhandenen Zeile oder nach dem Speichern anlegen. Die Kundenzuordnung wird übernommen; vertraulicher Berichtstext wird nicht automatisch in den Kalender kopiert. Beim Schließen der Berichte wird der Kalender aktualisiert.
- Rechte 0 und 11 sind gemeinsam erforderlich. Andere Niederlassungen benötigen Recht 10 und denselben Mandanten. Private Termine bleiben auf den Ersteller beschränkt, Teilnehmertermine auf Ersteller und Teilnehmer, öffentliche Termine auf den freigegebenen Niederlassungsbereich. Dies wird auch bei Statistik und direkten Änderungsendpunkten serverseitig erzwungen. PHP verwendet die Sichtbarkeit überwiegend als abwählbaren Suchfilter; diese Lücke wird nicht übernommen. Recht 3 oder 10 umgehen die private Sichtbarkeit nicht.
- Bearbeiten: Ersteller, Teilnehmer oder Recht 3, jeweils nur bei sichtbarem Termin. Löschen: Ersteller oder Recht 3. Anders als beim alten Speichern bleiben ursprünglicher Autor, Niederlassung und vorhandene Kontakt-/Kostenstellenverknüpfungen erhalten. Bei solchen Verknüpfungen ist die Kundenzuordnung gesperrt. Neue Termine/Wiedervorlagen erhalten Autor/Niederlassung der Sitzung.
- Die MyISAM-Tabelle `phoenix_group.appointment` wird ohne Schemaänderung verwendet. Jede Aktualisierung/Löschung vergleicht alle ursprünglichen Felder einschließlich binärem Textvergleich in derselben SQL-Anweisung. Keine Folgeabfrage nach erfolgreicher Anlage, die einen bereits gespeicherten Datensatz fälschlich als fehlgeschlagen melden könnte. Sämtliche Zugriffe über `DatabaseService`.
- Entwurfsschutz beim Schließen, Bereichswechsel und Aktualisieren mit React-Dialogen. Inzwischen ergänzt (13. Oktober): Kontakte, Kundenstatuswechsel, Motivation-Counter und Termin-E-Mails; siehe folgenden Abschnitt. Noch offen: allgemeine Formularverwaltung, Kunden-Neuanlage und weitere CRM-Popups. Das Hauptmenü Vertrieb ist deshalb noch nicht vollständig portiert.

## Kontakte und Vertriebs-Counter – Ergänzung vom 13. Oktober 2026

Die angemeldeten PHP-Oberflächen Kontakte (`appointment.php`), Kontaktbearbeitung (`metafield_special.php`, Kategorie 1), `customer_switch_counter.php`, `motivationcounter.php` und die E-Mail-Optionen der Terminbearbeitung wurden im Browser geprüft. Implementierung: `SalesWorkspace.tsx`, `CrmContacts.tsx`, `SalesCounters.tsx`, `AppointmentNotification.tsx`, `ContactService`, `SalesAnalytics`, `AppointmentNotifications` und zugehörige Controller.

- **Kontakte:** Karten-/Listenansicht, Teilwort-/Präfixsuche, Nachnamensinitiale, Kunden- und Niederlassungsfilter; Neuanlage, Bearbeitung, Löschen, Telefon-/Mail-Links, vCard und Druckansicht mit PDF über den Browserdruck. Alle 30 im Bestand konfigurierten Felder der Kategorie 1 werden aus Metafeldern gelesen, einschließlich Kundenbeziehung, Datumsangaben und Freitext. Feldhistorie folgt `mtfck_history`; keine neuen Tabellen. Änderungen prüfen sowohl Felddefinitionen als auch gespeicherte Werte auf Konflikte. Eine kurze exklusive Metafeld-Tabellensperre schützt MAX+1-ID-Vergabe und mehrteilige Änderungen; nur InnoDB wird dafür akzeptiert. Das DB-Konto benötigt dafür `LOCK TABLES`. Die allgemeine PHP-Template-/Skript-Engine und deren beliebige Spezialfeldtypen sind weiterhin kein Bestandteil des Kontakteditors.
- **Kundenstatuswechsel:** Auswertung von Logtyp 95 und `SRC/OLD/NEW`, getrennt nach Auftrag/Kundenstamm und Interessent/Potential-/Wunschkunde. Erfasst ausschließlich Wechsel zum Kunden (Status 0), keine Neuanlagen ohne vorherigen Status. Einzelkundenumsätze, zugeordnete Bestandskunden und Vorjahreszuwachs; CSV mit Schutz vor Tabellenformeln. Umsatzregeln entsprechen `getCsStatistic`, einschließlich Stornozuständen, Abschlussdatum, `GLOBAL_USE_RELATED_CUSTOMER` und PHP-Schaltjahrvergleich. Die Funktion ist wie im Altmenü eine Auswertung, keine neue Kundenstammbearbeitung.
- **Motivation-Counter:** Monatsumsatz, Auftragszahl, Ziel, Restbetrag/Überschreitung, Prozentanzeige, Niederlassungsvergleich und optionaler Vormonat in den ersten neun Monatstagen. `MOTIVATIONCOUNTER_EXCLUDED_CS` und monatliche Parameter werden gelesen; `MOTIVATIONCOUNTER_MODE=1` bestimmt die anfängliche Mehrfachauswahl. Die native Oberfläche erlaubt anschließend eine eigene Niederlassungsauswahl. Zielvorgaben werden mit dem vorhandenen niederlassungsbezogenen Counter-Passwort gelesen und geändert; vergangene Monate bleiben unveränderbar. Passwortversuche sind begrenzt; Konflikte werden vor dem Schreiben geprüft. Im geprüften Bestand existiert derzeit kein `MOTIVATIONCOUNTER_PASSWORD`, daher bleibt die Zielpflege dort bis zur Konfiguration gesperrt. Die Umsatzanzeige ist nutzbar.
- **E-Mail-Benachrichtigungen:** Nach Termin-Neuanlage/-Änderung optional den Versand vorbereiten oder aus den Termindetails öffnen. Teilnehmer/Kopie an sich selbst, zusätzliche externe Adressen, Anrede/Grußformel und Nachrichtenarten Neu/Änderung/Absage. Vor dem Senden werden alle Empfänger, fehlende Teilnehmeradressen, Absender, Betreff und Text angezeigt. Versand erfolgt erst auf „E-Mail jetzt senden“, Empfänger stehen in BCC. Eine Absage per Mail löscht den Termin nicht; Kalenderlöschung bleibt eine eigene Aktion. Anders als PHP führt die Auswahl ausschließlich externer Empfänger nicht trotzdem zu Teilnehmermails.
- **SMTP-Konfiguration:** PHP-Relay `smtp.pop-i.de:25` ohne Authentifizierung in `.env` übernommen; Einstellungen werden über `SMTP_HOST`, `SMTP_PORT`, `SMTP_USERNAME`, `SMTP_PASSWORD`, `SMTP_STARTTLS`, `SMTP_SSL`, `SMTP_FROM` gelesen. Leeres FROM verwendet die Mailadresse des angemeldeten Mitarbeiters. SMTP-Verbindungen haben Zeitlimits. Plaintext-Mail verhindert ungeprüftes HTML aus Termintexten. Optionales PHP-Logo/HTML-Layout wird nicht übernommen.
- **Versandfehler:** Der Termin ist vor dem Versand gespeichert. Ein Mailfehler darf keine erneute Termin-Neuanlage auslösen. Eine 15 Minuten gültige Vorschau ist an Benutzer, Niederlassung und Terminrevision gebunden; dieselbe Vorschau wird auch bei wiederholter Bestätigung höchstens einmal an SMTP übergeben. Unklare/teilweise SMTP-Zustellung wird als solche gemeldet und nicht automatisch wiederholt. Vorschauen leben nur im laufenden Serverprozess; es gibt keine persistente Warteschlange oder automatische Zustellbestätigung.
- **Berechtigungen:** Kundenrecht 0 und Vertriebsrecht 11; zusätzliche Niederlassungen nur mit Masterrecht 10 innerhalb desselben Mandanten. Termin-E-Mails beachten zusätzlich Termin-Sichtbarkeit und Bearbeitungsrecht; Absagen benötigen Löschrecht. Alle SQL-Zugriffe bleiben in `DatabaseService`.

## Prüfgrenzen und Quellen

- Sichtbare Untermenüs wurden angeklickt; Listen, Vertrieb, Statistik und Formulare zusätzlich als Seiten angesehen. Die fünf Verwaltungsuntermenüs mit dritter Ebene wurden separat geöffnet.
- Impressum und Sprache öffneten beim Klick keinen sichtbaren neuen Dialog/Tab. Ziel und Funktion wurden deshalb über `lib/project/js/menu.js.php`, `admin/impressum.html` und `admin/language.php` bestätigt.
- Keine Bestandsdaten bearbeitet, keine Nachrichten verschickt, keine Rechnungen erzeugt und keine Import-/Exportläufe mit Buchungswirkung gestartet.
- Der Umfang gilt für das sichtbare Zentralenkonto. Weitere rollen- oder mandantenspezifische Menüs können hinzukommen. Dies ist ein Funktionsabgleich, keine fachliche Abnahme jedes PHP-Unterdialogs.
- Neue Implementierung: `frontend/src/App.tsx`, `frontend/src/OrderEntryForm.tsx`, `backend/src/main/java/de/stadtbote/votian/ApiController.java`, `LegacyUser.java` und `OrderEntry*`.

## Sinnvolle Reihenfolge der weiteren Portierung

1. Aufträge bearbeiten, dispositionieren, abschließen und stornieren einschließlich Fahrerkommunikation und Gegenbuchungen; Listenerfassung.
2. Kunden-/Kostenstellen- und Unternehmer-/Fahrzeugpflege; Tarif-/Rabattpflege.
3. Rechnungen, PDF/CSV und Buchhaltungsexporte.
4. Verwaltung, Formulare, Vertrieb/Nachrichten sowie vollständige Statistik und Datenimport.

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

Referenz sind die angemeldeten PHP-Oberflächen `admin/mf_history.php`, `admin/newsticker.php`, `admin/metafield_editor.php`, `admin/metafield_template.php` sowie `metafield_list.php`/`metafield_special.php` für Kategorien 10 und 15. Die Newsletter-Adressatenauswahl in `include/email_send.php` und die Regeln in `inc_metafield.inc.php`/`inc_group.inc.php` wurden zusätzlich abgeglichen.

- **Endgeräte:** Zeitraum, Nachrichtenart, Priorität, Zustellstatus und Kurierfilter; Lesen markieren und Antworten. Empfänger sind einzeln, per Nachrichtengruppe einschließlich transitiver allgemeiner Gruppen oder alle zuletzt aktiven Transporteure wählbar. Vorschau zeigt die tatsächlich ausgewählten Benutzer; unterschiedliche Kurierzuordnungen desselben Benutzerkontos erzeugen nur eine Nachricht. Rechte 4, Gruppenpflege zusätzlich 52, Gesamtversand zusätzlich 10. Eigene Niederlassung bzw. freigegebene Niederlassungen desselben Mandanten.
- **MyISAM-Nachrichten:** Jede bestätigte Einfügung wird separat erfasst. Bei Verbindungsfehler bleibt die nächste Übergabe unklar; übrige Empfänger werden nicht versucht. Derselbe Vorschautoken wiederholt keinen Versand. Antworten beanspruchen den Ausgangseintrag wie PHP durch eine bedingte Zustandsänderung vor der Einfügung, damit parallele PHP-/NG-Antworten nicht doppelt versenden. Bei anschließendem Fehler bleibt der Antwortstatus gesetzt und die UI verlangt eine Prüfung der tatsächlichen Übergabe. Keine Zustellgarantie oder persistente Versandwarteschlange behauptet.
- **Mitteilungen:** Recht 18, eigene/empfangene bzw. niederlassungsbezogene Sichtbarkeit, optional abgelaufene Einträge. Persönliche Empfänger haben Vorrang vor Niederlassungen; globale Sendungen werden auf die freigegebenen Niederlassungen des Mandanten begrenzt. Zeitraum und Textlänge folgen Bestandsparametern. Löschen nur als Verfasser oder zuständiger Niederlassungsadministrator, mit Konfliktprüfung.
- **Formulardefinitionen:** Recht 15. Kategorien, Feldnamen/-typen, Vorlagen und allgemeine Gruppenzuordnungen; zugeordnete Felder sortieren oder ergänzen. Bestehende Feld-IDs und Werte bleiben erhalten. Individuelle Niederlassungsdefinitionen folgen `SYSTEM_FORM_SINGLE_HQ` und der jeweiligen Kategorieeinstellung. Globale Vorlagen/Definitionen werden entsprechend ihrem tatsächlichen Bestandsumfang bearbeitet. Vorlageninhalt wird vollständig geladen und exakt gespeichert; bestehende doppelte Namen oder alte Typdefinitionen verhindern keine unveränderte Übernahme. UTF-8- und SQL-Längen sowie Referenzzyklen werden geprüft.
- **Newsletter:** Rechte 0 und 17. Die 20 aktuell konfigurierten Text-/Bildfelder werden aus Kategorie 10 gelesen. Kategoriegebundene IDs, Konfliktschutz und Feldhistorie verwenden denselben exklusiven EAV-Schreibpfad wie Kontakte. Löschen berührt nur die zugehörigen Werte, nicht gleich nummerierte Objekte anderer Kategorien. Listen-/Kartenansicht, Präfix-/Teilwortsuche, Vorschau, Browserdruck/PDF und HTML-Download.
- **Vorlagen/Bilder:** Nummerierte Platzhalter, verschachtelte `CHK_EMPTY`/`REMOVE_EMPTY`-Blöcke und vorhandene Layouttabellen werden ausgewertet. Ausführbarer PHP-/JavaScript-Code wird nicht übernommen; unbekannte Spezialplatzhalter verursachen einen ausdrücklichen Fehler. Upload PNG/JPEG/GIF bis 300000 Bytes, tatsächliches Bildformat und Pixelgrenzen geprüft; serverseitige UUID-Dateinamen. Neue Bilder erscheinen als eingebettete Daten bzw. MIME-Inline-Anhänge. Vorhandene Bilder werden von der konfigurierten PHP-URL geladen. `FORM_IMAGES_DIRECTORY` ist standardmäßig `data/form-images` relativ zum gestarteten Backend; für gemeinsame PHP-/NG-Bildnutzung muss es auf das gemeinsame Bildverzeichnis zeigen. Nicht zugeordnete Uploads werden derzeit nicht automatisch entfernt.
- **Newsletter-Mail:** Manuelle Adressen; mit Recht 20 zusätzlich Kundentypen/Branchen oder Gruppen. Newsletterfreigabe und vorhandene DSGVO-Einstellung werden beachtet. Cc/Bcc je Einzelmail erfordern eine ausdrückliche Auswahl. Vorschau mit Absender, Antwortadresse, Empfängerliste und Inhalt; erst der Sendeknopf startet SMTP. Persönliche Abmeldeschlüssel stammen aus `meta_object.metaobject`, identifiziert über Datenbankinstanz und Empfängerobjekt. Fehlt ein Schlüssel oder die Verbindung, wird die Vorschau abgewiesen. `META_DB_URL`, optional `META_DB_USER`/`META_DB_PASSWORD`; sonst PHP-Parameter `EXTERNAL_DB_METAOBJECT` und PHP-Fallbackadresse mit bestehenden DB-Zugangsdaten. Diese zweite Datenbank wurde nicht live getestet.
- **Versandstatus:** Hintergrundversand mit bis zu 5000 Empfängern, Status erneut aufrufbar. Bei unbestätigter SMTP-Übergabe wird angehalten, ohne automatische Wiederholung. Vorschauen 15 Minuten, gestartete Aufträge 24 Stunden im Serverprozess; nach Neustart sind SMTP-Protokolle maßgeblich. Kein realer Newsletter und keine echte Endgerätenachricht wurden zur Prüfung verschickt.
- **Bewertungen:** Rechte 0 und 8, Kurier-/Fahrzeugauswahl zusätzlich 1. Die neun Felder aus Kategorie 15 entsprechen der sichtbaren alten Maske: Beginn/Ende, Niederlassungen, Kunden-EID, Transporteur-EID, Fahrzeugkennung, Fahrzeugklasse, Gruppe und Branche. Datumswerte bleiben `TT.MM.JJJJ`, Niederlassungen kommasepariert. Liste/Karten, Bearbeitung, Verlauf, Ausgabe und E-Mail-Vorbereitung. Der aktuelle Bestand hat dafür keine hinterlegte Spezialvorlage; daher erfolgt eine beschriftete Feldausgabe.

Offen bleiben die in der Tabelle genannten Stammdaten-/Tarif-, Auftragsbearbeitungs-, Rechnungs-, Transfer- und Statistikbereiche. „Kessel Buntes“ wurde inzwischen in der PHP-UI geöffnet und enthält 18 sichtbare Spezialansichten; die Portierung dieses Bereichs steht noch aus. Formularverwaltung bedeutet weiterhin nicht, dass alle beliebigen objektspezifischen PHP-Formulare und Template-Skripte ersetzt sind.

## Auftragsfilter – Ergänzung vom 13. Oktober 2026

Die angemeldete PHP-Ansicht `admin/filter.php` wurde mit eingeschalteter Verwaltung und Langtextanzeige geprüft. Quellen: `admin/filter.php`, `include/inc_filters.inc.php`, `admin/sort.php` und Bereinigungsabschnitt in `jobs/check_jb_permanent.php`. Native Umsetzung unter Verwaltung → Auftragsfilter (`FilterAdministration`, `FilterController`, `Filters.tsx`).

- Globaler Katalog; Lesen mit Recht 0, Änderungen zusätzlich Recht 32. Kürzel, Bezeichnung, Fahrzeug-/Transporteursart und Pflicht-/Optionalstatus bei Neuanlage; bestehende Klassifikation bleibt wie in der PHP-UI unverändert. Langtext und Sortiernummer bearbeitbar; Kürzel-/Namensduplikate bei Neuanlage abgewiesen.
- Löschen entfernt das Kürzel aus aktiven Kunden/Transporteuren und allen Fahrzeugen, ohne deren Änderungszeit zu verändern. Bei bereits vorhandenen doppelten Kürzeln bleiben gemeinsame Zuordnungen bestehen, solange ein weiterer Katalogeintrag existiert.
- Tour- und geeignete offene Dauerauftragsvorlagen werden über den vorhandenen Parameter `FILTER_TO_BE_DELETED` und den PHP-Nachtlauf nachgeführt; historische Einzelaufträge bleiben unberührt. Das Kürzel ist bis zur Bearbeitung der Warteschlange für native Neuanlage gesperrt. Der Betrieb dieses vorhandenen Nachtlaufs ist Voraussetzung für diese Nachführung.
- `courierfilter` und Protokoll sind MyISAM. Eine dauerhafte Vorgangskennung im bestehenden `genericdatacontainer` schützt native Wiederholungen. Nach Teilfehlern zeigt die Oberfläche offene Vorgänge mit Fortsetzen-Aktion; Anlage, Änderung und Löschung werden samt Protokoll 168–171 wiederaufgenommen. Die Zuordnungsbereinigung und Markierung als abgeschlossen erfolgen gemeinsam in einer InnoDB-Transaktion. Ein Konflikt mit parallelen PHP-Änderungen wird angezeigt und nicht überschrieben. Solche Konflikte können eine manuelle Klärung des Bestands erfordern. Keine neuen Tabellen.
- Isolierter MariaDB-Test deckt Anlegen, identische Wiederholung, Konflikte, Änderungen, Löschung, Archivschutz, Zeitstempel, Kürzelsperre, doppelte Bestandskürzel und Abbruch nach MyISAM-Schreibzugriff mit Fortsetzung ab. Browserprüfung mit reinem Speicher-Fixture: Anlage, Langtext/Sortierung und Wiederaufnahme. Keine fachlichen Schreibtests in der Bestandsdatenbank.

## PLZ- und Bereichsadressen – Ergänzung vom 13. Oktober 2026

Die angemeldeten PHP-Masken `admin/srvpa_list.php` und `admin/srvpaa_list.php` wurden unmittelbar vor der Umsetzung angesehen. Gegenprüfung mit deren Anlage-/Such-/Löschpfaden und `include/services_func.inc.php`. Nativ: `AddressAdministration`, `AddressController`, `AddressMappings.tsx`; zwei eigene Verwaltungsbereiche.

- Recht 2 und eigene Niederlassung wie im Altprogramm. Suche nach Abrechnungsziel, Straßenpräfix, PLZ, Ort, Land, Grenzen sowie zusätzlich Hausnummernmodus; sieben Sortierungen, Gesamtzahl und 100 Einträge pro Seite. Anders als PHP liefert ein ungültiges Abrechnungsziel keine ungefilterte Liste.
- Anlage mit Straße, realer PLZ, Abrechnungs-PLZ/Bereich, Ort, Land, numerischen Hausnummerngrenzen und Alle/Gerade/Ungerade. Bereichsnamen folgen `ZIPCODEAREA_PADLENGTH`. Vorhandene identische Adressen und Zuordnungen werden wiederverwendet. Leerer Ort wird nur aus eindeutigen vorhandenen Adressen ergänzt, andernfalls ist eine Eingabe erforderlich; kein stilles Speichern von „???“.
- Mehrfachlöschung nach Vorschau mit Vergleich des geladenen Stands; zentrale Adressdatensätze werden nicht gelöscht. MyISAM-Zuordnungen verwenden dauerhaft gesicherte, wiederaufnehmbare Vorgänge in `genericdatacontainer`. Neue InnoDB-Adressen und Vorgang werden vor dem Zuordnungsschreiben gemeinsam festgeschrieben, damit ein Abbruch keine Zuordnung ohne Adresse hinterlässt. Bereits entfernte Zuordnungen bleiben bei Teilfehlern entfernt; der Vorgang lässt sich wiederaufnehmen. Keine Schemaänderung.
- Besondere Hausnummern aus `MASK_AREA_ID_FROM_ADDRESS_<id>` werden mit Zielbereich angezeigt. Wie in der alten Adressmaske ist diese Parameterkonfiguration hier nicht editierbar.
- Zusätzlich Preisberechnung und Speicherung der Vermittlungs-PLZ vereinheitlicht (`LegacyAddressTariffs`): engster einschließender Hausnummernbereich, Gerade/Ungerade, Landeszuordnung und besondere alphanumerische Hausnummern. Die vorherige native PLZ-Ermittlung ignorierte Grenzen/Parität. Ausdrücklich gewählte Abrechnungs-PLZ hat weiterhin Vorrang.
- Echte Daten nur gelesen: drei PLZ-Zuordnungen und 11.524 Bereichsadressen im geprüften Niederlassungsbereich. Schreibabläufe, konkurrierender Stand, fremde Niederlassungen und Verbindungsabbruch mit Wiederaufnahme in wegwerfbarer MariaDB geprüft. Browser-Fixture ohne echte DB: Neuanlage, Suche, Bereichswechsel und Ausnahmeanzeige; Löschdialog nur geöffnet/abgebrochen.


## Servicepreise und Servicerabatte – Ergänzung vom 13. Oktober 2026

Referenzen: angemeldete PHP-UI `admin/services.php` in beiden Servicemodi und im Rabattmodus, Typverwaltung am Seitenende sowie `admin/groupmembers.php?itemType=srv`. Quellen: `admin/services.php`, `admin/groupmembers.php`, vorhandenes Schema und `services_func.inc.php`. Native Menüpunkte unter Verwaltung → **Servicepreise / Servicerabatte**.

- Allgemeine und kundenspezifische Preis-/Rabattmatrizen; getrennte Frachtvergütungswerte, einzeln einblendbar. Fahrzeugtarife (Modus 0) und Leistungen (Modus 1), Kundenfilter, Zeilenfilter, feststehende Tabellenköpfe. `MANDATOR_SERVICE_ENABLED`, `MANDATOR_SERVICE2_ENABLED`, `SERVICE_DISPLAY_MODE_DEFAULT` und spaltenweise `RIGHTS_TABLE_SERVICE` werden ausgewertet. Modus 1 berücksichtigt allgemeine zugewiesene und eigene Kundentypen.
- Modus 0: aktuelle Werte sowie künftige Stände bis Ende des nächsten Kalenderjahres. Die künftige Ansicht zeigt wie PHP ausschließlich am ausgewählten Tag gespeicherte Werte; unbelegte Zellen sind 0. Änderungen schreiben nur die tatsächlich bearbeiteten Zellen. Preise erhalten Rabatte und umgekehrt. Historieneinträge enthalten stets alle vier Werte und den Benutzer. Ab Wirksamkeit wird der neueste gültige Historienstand gelesen; reine Lesezugriffe verändern die aktuelle Preiscache-Tabelle nicht.
- Aktuelle Matrix, Historie und Wiederholungsschutz werden gemeinsam in vorhandenen InnoDB-Tabellen gespeichert. Keine neuen Tabellen. Bearbeitungsstand und Definitionen werden vor dem Schreiben erneut geprüft und gesperrt. Mehrdeutige Bestandszellen bleiben sichtbar, sind jedoch gesperrt. Zwei aktuelle Änderungen derselben Zelle in derselben Sekunde werden nicht als mehrdeutige Historie geschrieben; die zweite Anfrage verlangt erneutes Laden nach einer Sekunde.
- Modus 1: Preis-/Leistungstypen anlegen, umbenennen und löschen. Löschung entfernt wie PHP ausschließlich den Katalogtyp; Preis-/Auftragshistorien bleiben bestehen. Gruppen über vorhandene Zuordnungsfelder, geschützte/unzugängliche Gruppen bleiben erhalten. Geänderte Typen aktualisieren die Matrix.
- Rechte: Verwaltung 2, allgemeine Servicetarife zusätzlich 29; kundenspezifisch zusätzlich Kundenrecht 0 und eigene Niederlassung. Typenlöschung zusätzlich 31. Gruppenbearbeitung folgt den vorhandenen nativen Verwaltungsrechten 8 und 25, bei globalen Typen zusätzlich 10. Dies ist enger als der generische PHP-Gruppendialog (Recht 1).
- PHP-Protokolltypen 57–60 und 131–132 werden übernommen. Da das externe Log MyISAM verwendet, wird der Typ zuerst zusammen mit einem dauerhaften Protokollauftrag gespeichert. Fehlt die Logverbindung, meldet die UI die fachliche Änderung als gespeichert und bietet „Protokoll übernehmen“ an. Wiederholungen erzeugen weder einen zweiten Typ noch einen zweiten bestätigten Protokolleintrag.
- Noch gesondert offen: die Zuweisung allgemeiner Leistungstypen in der vollständigen Kundenstammpflege. Die bestehenden Zuweisungen werden bereits berücksichtigt.


## PLZ-/Bereichstarife und Bereichspflege – 13. Oktober 2026

- Referenzen: angemeldete PHP-Oberflächen `admin/services_plz.php` und `admin/services_plz_area.php`, jeweils Preis- und Rabattmodus; Quellcode einschließlich `getServiceVehicleTypeMappingId` in `include/global.inc.php`.
- Vier native Verwaltungsseiten: PLZ-Preise, PLZ-Rabatte, Bereichspreise, Bereichsrabatte. Gerichtete Von-/Nach-Matrizen mit 10 × 10 Einträgen, getrennten Startwerten und unabhängiger Blätterfunktion. Gültige PLZ, Bereiche der eigenen Niederlassung; PLZ-Auswahl zeigt das Land zur eindeutigen Zuordnung.
- Allgemeine und kundenspezifische Werte, Vergleich mit allgemeinen Tarifen in Klammern, getrennte Anzeige/Eingabe der Kunden- und Kurierwerte. Fahrzeugauswahl folgt `SERVICE_VEHICLE_TYPE_ENABLED`, `MASK_EXCLUDE_VHT_IDS` und `SERVICE_VEHICLE_TYPE_MAPPING`; die wirksame Zuordnung wird angezeigt.
- Speicherung erhält jeweils die anderen beiden Werte und schreibt alle vier Beträge mit Benutzer und Zeit in die vorhandene Historie. Die unterschiedlichen FLOAT-Spaltengrenzen werden geprüft. Doppelte Bestandszellen sind sichtbar und schreibgeschützt; veraltete Revisionen, gleichzeitige Historienzeitpunkte und ungeklärte künftige Historien werden zurückgewiesen. Wiederholung derselben Anfrage erzeugt keine zweite Änderung.
- Bereiche anlegen/umbenennen (maximal zehn Zeichen, eindeutiger Name je Niederlassung), vorhandene PLZ zuordnen/Verknüpfungen entfernen. Eine PLZ kann je Niederlassung nur einem Bereich angehören; Umhängen erfordert zuerst die bisherige Verknüpfung zu entfernen. Keine Bereichslöschung vorgesehen, entsprechend der PHP-Maske.
- PLZ- und Bereichsnachbarschaften werden in beiden Richtungen angelegt/entfernt, ohne transitive Erweiterung. Alte einseitige Beziehungen können vervollständigt werden. Entfernen erfolgt nach einer Vorschau im anwendungseigenen Dialog.
- Rechte: wie PHP Verwaltungsrecht 2, zusätzlich Kundenrecht 0 für Kundentarife; konsequente Niederlassungsabgrenzung. Alle fachlichen Schreibvorgänge einschließlich Wiederholungsbeleg erfolgen gemeinsam in den bestehenden InnoDB-Tabellen über `DatabaseService`. Keine Schemaänderungen.


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

Referenz ist der frisch per SSH gelesene PHP-Serverstand **`24094e2`**: `admin/customer_courier.php`, `admin/courier_customer.php`, `admin/sort.php` sowie die zugehörigen Kunden-/Kurier-/Auftragsfunktionen. Beide Beziehungsmasken wurden in der angemeldeten PHP-Oberfläche gelesen; im dortigen Benutzerkonto war die Provisionsbearbeitung nicht freigeschaltet. Rechteprüfung und historische Provisionsablage wurden daher zusätzlich im aktuellen Servercode geprüft.

- **Beide Einstiege:** Kundenstamm → Transporteursbeziehungen und Transporteurstamm → Kundenbeziehungen. Suche nach Name/EID, beim Transporteur zusätzlich SID; Status-/Textfilter, Anzahl, Seitennavigation und Einzel-/Mehrfachauswahl.
- **Pflege:** Gesperrt (0) oder Besonders erwünscht (1), Bemerkung bis 255 Zeichen, vorhandene Beziehung ändern, Favoritenrang je Kunde setzen und bis zu 100 Beziehungen gemeinsam entfernen. Verbleibende Favoriten werden fortlaufend ab 1 nummeriert. Doppelte Paare werden abgewiesen. Änderungen haben eine Vorschau und einen Entwurfsschutz ohne nativen Browserdialog.
- **Provision:** Bestehende Werte sichtbar; Änderung nur mit Recht 39 zusätzlich zu Recht 1. Werte 0–100 % mit zwei Nachkommastellen, ausschließlich bei bevorzugten Beziehungen. Neue geänderte Werte werden PHP-kompatibel in `servicepricehistory` mit `cr`, `cscr_prov` und Kunden-ID als Kontext gespeichert. Auch ein bei der Neuanlage eingegebener, von null abweichender Satz erhält direkt einen Historieneintrag. Unveränderte Sätze bleiben erhalten; Entfernen oder Sperren einer Beziehung löscht wie PHP keine Provisionshistorie. Historie ist je Paar einsehbar. Bestehende Aufträge werden nicht automatisch neu berechnet.
- **Grenzen und Rechte:** Recht 1 für die Beziehungspflege, eigene Niederlassung für beide Stammdatensätze. Kundenstamm selbst benötigt weiterhin Kundenrecht 0. Änderung der Provision wird serverseitig geprüft; unberechtigte Requests können den schreibgeschützten UI-Wert nicht umgehen. Bis 1000 Beziehungen je Ansicht/Kunde; größere Bestände werden ausdrücklich gemeldet. Veraltete Revisionen und Historienänderungen werden abgewiesen.
- **MyISAM:** `customercourier` ist im Bestand weiterhin MyISAM. Vor der ersten Mutation wird ein unveränderlicher Plan in `genericdatacontainer` (`ngcscr`) verbindlich gespeichert. Kurze Tabellensperren schützen vor konkurrierenden PHP-/NG-Schreibvorgängen. Wiederaufnahme akzeptiert je Paar nur den gesicherten Vorher- oder Nachherstand; externe Änderungen werden nicht überschrieben. Historie, Audit und Abschlussbeleg bleiben zusammen transaktional. Nur der ursprüngliche Bearbeiter mit den weiterhin nötigen Rechten darf offene Vorgänge fortsetzen.

Separat offen bleiben Fahrzeug-/Kunden-/FDS-Zuordnungen aus `vehicle_customer.php`, die zugehörigen B2B-Hintergrundprozesse, Zugangsverwaltung und weitere Spezialformulare. Die Beziehungspflege ergänzt keinen eigenständigen Autoranking-/Reservierungsrankingdienst und schließt die übrigen offenen Menübereiche der Tabelle nicht ab.