votianng/docs/AUFTRAGSERFASSUNG.md

Native Auftragserfassung

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

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

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

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

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

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

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

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

2026-10-19 · Zusatzmontage und gefundene Archivquellen

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

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

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

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

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

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

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

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

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

2026-10-19 · Zahlungskontrolle und Sammelzahlungen

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

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

2026-10-19 · Zahlungseingänge und Restbetragsbuchung

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

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

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

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

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

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

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

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

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

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

2026-10-19 · Fahrzeuganforderung der Vorbestellung

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

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

2026-10-19 · Kontakte aus Kundenstammdaten und Vorbelegung

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

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

2026-10-19 · Fahrzeugänderung nach Abschluss

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

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

2026-10-19 · Haupt-/Unterauftragsnummer

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

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

19. Oktober 2026 – Frachtvergütungs-Warnschwelle

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

19. Oktober 2026 – Datumswahl beim manuellen Auftragsabschluss

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

19. Oktober 2026 – Zusätzliche Kommissionsnummernpflicht beim Abschluss

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

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

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

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

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

19. Oktober 2026 – Gesamtsumme der erledigten Kundenaufträge

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

19. Oktober 2026 – Weitere Preisspalten der Kunden-Auftragsliste

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

19. Oktober 2026 – Rabattdarstellung bestehender Listenbuchungen

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

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

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

19. Oktober 2026 – Fahrzeuglager und vererbte Stellplatzplanung

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

19. Oktober 2026 – Fahrzeug entfernen

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

19. Oktober 2026 – Fahrzeugbilder und Fotodienst

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

19. Oktober 2026 – Interner Fahrzeugkurier

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

19. Oktober 2026 – Bedingtes Abrechnungsfahrzeug und Fahrzeuglager

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

19. Oktober 2026 – Aktives Fahrzeug bei Stammdatenänderungen

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

19. Oktober 2026 – Fahrzeugkopie

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

19. Oktober 2026 – Fahrzeug-Pflichtangaben und eindeutige Nummern

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

19. Oktober 2026 – Dispositionskapazitäten bei Fahrzeugpflege

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

19. Oktober 2026 – Fahrzeug einem Fahrerkollegen zuordnen

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

19. Oktober 2026 – Fahrzeugfilter und Leistungen

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

19. Oktober 2026 – Erweiterte Fahrzeugstammdaten

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

19. Oktober 2026 – Niederlassungsvorgaben der Kuriermaske

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

19. Oktober 2026 – Online-Status in den Kurierstammdaten

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

19. Oktober 2026 – Abweichende Rechnungsanschrift der Hauptkostenstelle

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

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

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

19. Oktober 2026 – Kundenspezifische Stationsnummern

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

19. Oktober 2026 – Kundenstammblatt als PDF

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

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

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

19. Oktober 2026 – Kundenstammblatt als neuen Kunden kopieren

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

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

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

19. Oktober 2026 – Startzahler in der Kundenerfassung

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

19. Oktober 2026 – Drittzahler und übergeordneter Kunde

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

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

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

19. Oktober 2026 – Kundentyp bei Neuanlage und Bearbeitung

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

19. Oktober 2026 – Alte Kundennummer und Umfirmierung

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

19. Oktober 2026 – Kommissionsnummer-Untervorgaben

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

19. Oktober 2026 – Startvorgaben bei Kunden-Neuanlage

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

19. Oktober 2026 – Kundenerfassungsvorgaben im Kundenstamm

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

19. Oktober 2026 – Kunden-Ähnlichkeitssuche

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

19. Oktober 2026 – Firmenprüfung und Verrechnungskundenhinweis

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

19. Oktober 2026 – Kundenangaben in Kostenstellen übernehmen

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

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

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

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

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

19. Oktober 2026 – Persönliche Mitteilungen

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

19. Oktober 2026 – Native Anmeldungshistorie und gemeinsamer Gesamtlauf

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

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

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

19. Oktober 2026 – Native Kundenakte

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

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

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

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

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

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

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

• Aktive admin/metafield_list.php (511e3581655f501c4547122c0837e3c288729ba92d9f8264853920d7eedadcd4), vCard-Klasse und include/email_send.php frisch per SSH gelesen; aktuelle PHP-Kontaktoberfläche geöffnet. vCard-Vorschau, Download und bestätigter E-Mail-Anhang ergänzt. Firma, Website, Geburtstag, Anschrift, private/geschäftliche Nummern und einzelne E-Mail-Adressen werden ausgegeben. Firmen werden ausschließlich im berechtigten Niederlassungsumfang und bei sichtbaren/authentifizierten Stammdaten aufgelöst.
• Globale Namens-/Adressfeldzuordnungen werden berücksichtigt. Ohne Adressvorgabe verwendet NG weiterhin die echten beschrifteten Adressfelder; die PHP-Vorgabe 8,9 würde im vorhandenen Formular Mobilnummern als Straße/Hausnummer ausgeben. Die eigene E-Mail-Adresse wird als Empfänger vorgeschlagen. Absender folgt der vorhandenen Mailkonfiguration. Vorschau und Anhang sind identisch; Änderungen an Kontakt, Zuordnung oder Absender verlangen erneute Vorbereitung.
• Dauerhafter Versandbeleg und Audit werden vor SMTP gemeinsam gespeichert. Wiederholung, Neustart, parallele Aufrufe und verlorene Bestätigung senden denselben Vorgang nicht doppelt. Persönlicher Versandverlauf und klare Anzeige ungewisser Zustellung vorhanden. Tests ausschließlich mit Mock-Transport bzw. lokalem SMTP-Testserver; keine realen Mails.
• Gesamtbasis: 1420 Tests, 1417 bestanden, drei übersprungen, keine Fehler (work/contact-vcard-verification.json, 1041 Dateien). Anschließende vCard-Formatkorrektur für Website- und E-Mail-Parameter mit allen 13 betroffenen Backendprüfungen erneut bestanden (work/contact-vcard-format-verification.json). Formatabgleich anhand RFC 2426. 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.

Vermittlungsstaufrist – 17. Oktober 2026

Die Preisvorschau zeigt jetzt die vom tatsächlichen Zahler abgeleitete Vermittlungsstaufrist. Sofortaufträge verwenden die Kundenwartezeit, Vorbestellungen und Daueraufträge den globalen Vorlauf vor Auftragsbeginn. Kopien berücksichtigen die vorhandene Vormerkung; ein Zahlerwechsel lädt die neue Regel. Gleiche Aufträge und vorab angelegte Serientermine speichern jeweils ihre eigene Frist zusammen mit dem Auftrag. Geänderte Vorgaben zwischen Vorschau und Speichern erfordern eine neue Berechnung.

In der Auftragsbearbeitung wird die gespeicherte Frist angezeigt und bei Zeitänderungen mitgeführt. Bereits verarbeitete Mailvormerkungen bleiben verarbeitet. Die vorhandenen PHP-Dienste übernehmen weiterhin den automatischen Versand nach ihren Empfänger- und Statusregeln. Es gibt keine zusätzliche manuelle Fristüberschreibung, da diese Schalter im aktuellen PHP-JavaScript auskommentiert sind. Die frühere Offen-Markierung für die Vermittlungsstaufrist ist damit erledigt.

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

Unter Kunden → Bearbeiten → Kunden-Mailvorgaben sind Deutsch/Englisch, Ankunftszeit, Fußzeile, die acht sichtbaren PHP-Mailfelder und Vermittlungsstau-Vorgaben pflegbar. Änderungen werden vor dem Speichern verglichen und gemeinsam mit Audit/Wiederholungsbeleg gespeichert. Versteckte Bestandsoptionen bleiben erhalten. Der Dialog startet keinen Mailversand; automatische Verarbeitung läuft weiterhin über die eingerichteten PHP-Dienste.

Auch eine gespeicherte manuelle Preisberichtigung oder Neukalkulation bietet jetzt „Änderungsmail vorbereiten“ an. Alle bestehenden Regeln zu Empfängervorschlägen, Vorschau, explizitem Versand und sicherer Wiederholung gelten unverändert. Die Kundensprachauswahl und der Mailbeleg für diese Preisänderungen sind damit ergänzt. Die Vermittlungsstaufrist in der eigentlichen NG-Auftragserfassung bleibt separat offen.

Änderungsmail nach Bearbeitung – 17. Oktober 2026

Nach „Änderungen speichern“ steht im Bearbeitungsdialog „Änderungsmail vorbereiten“ bereit. Der eigene letzte gespeicherte Bearbeitungsvorgang bleibt auch nach erneutem Öffnen erreichbar. Die Kundenvorgaben liefern Empfängervorschläge; Inhalt, sämtliche Empfänger und der gegebenenfalls konfigurierte PDF-Anhang werden vor dem Versand ausdrücklich geprüft. Auch erledigte Aufträge behalten ihre Abliefernachweise. Ungespeicherte Änderungen sperren die Mailaktion.

Speichern und Mailversand sind unabhängig: Eine fehlende Speicherantwort wird über denselben Bearbeitungsvorgang wiederholt, eine fehlende Versandantwort über den dauerhaften Versandstatus geklärt. Ein unsicherer Mailausgang löst keinen automatischen zweiten Versand aus. Angebote/Stornos bleiben gesperrt; inzwischen exportierte Aufträge verwenden die historische Mail in den Auftragsdetails. Kundensprachauswahl, allgemeine Oberflächensprache und automatische Mailworker bleiben separate offene Bereiche. Quellen und Prüfungen im aktuellen Menüabgleich/Prüfstatus.

Kundensprache der Auftragsmail – 17. Oktober 2026

Erfassungs- und manuelle Auftragsmails berücksichtigen jetzt die konfigurierte Kundensprache aus dem PHP-Sprachbestand. Betreff, Standardtexte, Feldbezeichnungen und PDF-Texte werden übersetzt, Kundendaten bleiben unverändert. Wo ein Wörterbucheintrag fehlt, bleibt wie in PHP der deutsche Text stehen; die Vorschau weist darauf hin. Der aktuelle Bestand enthält für diese Mailquelle englische Übersetzungen. Historische Inhalte behalten ihre gespeicherte Sprache und die aktuellen Kundenfreigaben.

Geänderte Übersetzungen machen eine bereits erstellte Versandvorschau ungültig. Eine native Kundensprachauswahl, die allgemeine Oberflächensprache und der Versand nach Bearbeitung bleiben separate offene Bereiche. Prüfungen und genaue Grenzen stehen im aktuellen Menüabgleich/Prüfstatus.

Historische Auftragsmails – 17. Oktober 2026

Auch exportierte Aufträge in der vorhandenen Auftragsliste bieten jetzt die manuelle Mail mit historischen PHP-Daten. Preise, Stations- und Transporteurangaben kommen aus dem gespeicherten Kunden-Mailstand; vor dem Versand ist die konkrete Archivquelle sichtbar. Unterschriften und Fotos werden in die Vorschau und den konfigurierten PDF-Anhang eingebunden. Aktuelle Kundenfreigaben gelten weiterhin. Bei geänderten, mehrdeutigen oder beschädigten Snapshots ist eine erneute Prüfung nötig.

Die Suche berücksichtigt lokale und entfernte Jahrestabellen. Nur bei nachweislich fehlendem Snapshot folgt NG dem PHP-Rückfall auf aktuelle Auftragsdaten und zeigt dies ausdrücklich an. Verbindungsfehler führen zu keinem stillen Rückfall. Vollständige historische Auftragslisten ohne aktuellen Datensatz, zusätzliche Mailsprachen und die übrigen Mailwege bleiben separat offen. Details und Tests stehen im Menüabgleich/Prüfstatus.

Manuelle Auftragsmail – 17. Oktober 2026

In den Auftragsdetails gibt es jetzt „Auftragsmail“. Für aktuelle, nicht exportierte Aufträge lassen sich Erledigungsmails sowie freigegebene Abholungs-/Vermittlungsmails mit Empfängerprüfung versenden. Die Vorschau enthält nach Kundenvorgaben Unterschriften, Fotos, Ankunft/Erledigung, Quittungsgeber, Meldungen, Artikelbarcodes, Preise und Ansprechpartner. Der konfigurierte PDF-Anhang ist vorab seitenweise sichtbar und herunterladbar. Passende Kundenumfragen verwenden die bestehenden Regeln und persönlichen Links.

Vor dem Versand werden Auftragsdaten, Nachweise und Rechte erneut geprüft. Ein unklarer Ausgang wird dauerhaft angezeigt; wiederholtes Klicken oder ein verlorener Browseraufruf startet keine zweite Mail. Erst nach bestätigter SMTP-Übernahme steht eine ausdrücklich neu vorbereitete weitere Mail zur Verfügung. Die Tests verwenden ausschließlich lokale SMTP-Senken bzw. Simulationen. Fortschreibung: Exportierte Auftragssnapshots sind inzwischen ergänzt (Abschnitt oben); weitere Sprachen und vollständige Archivlisten bleiben offen.

Abliefernachweise in den Auftragsdetails – 17. Oktober 2026

Gespeicherte Aufträge bieten in ihrer Detailansicht den Bereich „Abliefernachweise“. Er zeigt Stationszeiten, Quittungsgeber, Unterschriften, Fotos, Meldungen und Artikelbarcodes aus dem aktuellen Bestand. Bilder werden mit erneuter Berechtigungsprüfung gelesen; Fehler lassen sich je Bild erneut prüfen. Es werden keine Bestandsdaten oder PHP-Temporärdateien geschrieben.

Die Erfassungsmail entfernt nun interne Stationszusätze in [[…]] entsprechend der aktuellen PHP-Regel. Die Zusammenführung der neuen Nachweisdaten mit den Mailwegen für erledigte/bearbeitete Aufträge und PDF bleibt der nächste Schritt. Quellen und Prüfgrenzen stehen im aktuellen Menüabgleich.

Bestätigte Auftragsmail – 17. Oktober 2026

Nach erfolgreicher Anlage kann die separat bestätigte Auftragsmail geprüft und versandt werden. Der Dialog zeigt die einzelnen Aufträge einschließlich Kopien/Serienterminen, änderbare Empfänger, sämtliche Kopien/Blindkopien und den tatsächlichen HTML-Inhalt. Eine eigene Inhalts-/Empfängerbestätigung ist erforderlich. Speichern und Versand sind getrennt; Schließen und verlorene Mailantworten lösen keine erneute Auftragsanlage aus. Eigene letzte Erfassungsvorgänge sind über „Gespeicherte Auftragsmails“ erneut erreichbar.

Umgesetzt ist der deutsche Mailpfad für noch offene, nicht exportierte NG-Aufträge ohne Ablieferdaten. Kundenfreigaben für Preise, Kurier- und Stationsdaten sowie Niederlassungstexte werden erneut geprüft. SMTP findet erst nach der verbindlichen Übergabevormerkung außerhalb der Datenbanktransaktion statt. Ein gestarteter oder unklarer Versand wird nicht automatisch wiederholt. Vorhandene automatische Statusmails bleiben davon unabhängig.

Details, Quellen, bewusste PHP-Korrekturen und die noch offenen Wege für erledigte/bearbeitete/historische Aufträge, PDF, Sprachen und automatische Worker stehen im aktuellen Menüabgleich. In den Prüfungen wurde keine echte Mail verschickt.

Statusmail-Empfänger – 17. Oktober 2026

Die Auftragserfassung zeigt die Standardempfänger und die aktiven Ereignisse. Zusätzliche Adressen werden nach erneuter Prüfung zusammen mit dem Auftrag in die bestehende PHP-Statusmailverarbeitung übernommen. Vorschau, Barzahler, Kopien/Serientermine, Vorlagen und Wiederholung ohne Doppelanlage sind berücksichtigt. Für Angebote wird kein automatischer Versand vorgemerkt. Fehlende Standardadressen erscheinen als Hinweis; mehrere zusätzliche Empfänger werden validiert. Details und aktuelle Remote-Quellen stehen im Menüabgleich.

Die separat bestätigte Mail für offene NG-Erfassungen ist inzwischen ergänzt (Abschnitt oben); erledigte/bearbeitete Aufträge bleiben offen. Es wurde keine echte Mail als Test versandt.

CC24-Erfassung – 17. Oktober 2026

Der globale PHP-CC24-Schalter wird jetzt nativ unter Verwaltung → Mitarbeiter → CC24 gepflegt. Er erweitert die Erfassungsniederlassungen um aktive, eindeutig zugeordnete Niederlassungen desselben Mandanten. Rechteentzug wird pro Anfrage geprüft; der Wechsel erweitert keine fachlichen Rechte. Die PHP-Sonderliste für globale Kurierverteilung wird im Formular, bei der Vorschau und vor dem Schreiben geprüft. Gewöhnliche Niederlassungsfreigaben und unabhängige Lagerrechte bleiben wirksam. Details und bewusste Sicherheitsabweichungen: aktueller CC24-Abschnitt in MENUE-ABGLEICH.md.

Der allgemeine CC24-Arbeitsplatzwechsel und die CC24-Mehrniederlassungsauswahl der Auftragslisten sind ebenfalls ergänzt. Der Arbeitskontext bleibt tabbezogen; der gesonderte Erfassungskontext kann weiterhin ausdrücklich gewählt werden. Zielniederlassung und Rechte werden pro Anfrage erneut geprüft. Zusätzliche Statusmail-Empfänger und Vorschlagsregeln sind ergänzt; die separat bestätigte Auftragsmail bleibt offen. Details, gewöhnliche HQ-Matrixlisten und Prüfgrenzen im aktuellen Menüabgleich.

Stand 17. Oktober 2026: Kunden-/Transporteur-Hauptzugänge können aus dem jeweiligen Stammblatt verwaltet werden (Aktivierung, Anmeldename, Passwort, Sperre und 2FA-Rücksetzung). Dies ändert keine Auftragsdaten und ergänzt noch keine eigenständige NG-Kundenportal-Erfassung. Zusätzliche Kundenmitarbeiter, Portalrechte und Kostenstellenfreigaben sind ebenfalls pflegbar. Die Matrix benötigt die im aktuellen Bestand fehlende Tabelle; Vorbereitung und Betriebsgrenzen stehen im Menüabgleich.

17. Oktober 2026 – automatische Angebotsrunden

Im Vermittlungsdialog ist jetzt die Kandidatenprüfung des nativen Angebotsdienstes sichtbar: Favoriten, Bereiche/Nachbarschaften, feste Reservierungen, Versuchszähler, Ausschlussgründe und gegebenenfalls frühester Beginn. Die Anzeige verteilt keine Aufträge. Der Hintergrunddienst setzt bei Aktivierung geeignete Angebote atomar; nach ausgeschöpften Runden folgt manuelle oder konfigurierte globale Vermittlung. Regeln und PHP-Korrekturen stehen im Menüabgleich. AUTO_OFFER_WORKER_ENABLED=false bleibt während des Parallelbetriebs aus; Geräteverbraucher und Betriebsumschaltung sind gesondert zu behandeln.

17. Oktober 2026 – Annahmefristen und Angebotsrückrufe

Der Vermittlungsdialog zeigt jetzt die Annahmefrist eines offenen Fahrerangebots, den Folgestatus bei Rückruf und die Auswirkung auf die Freimeldezeit. Der native Hintergrundlauf verarbeitet abgelaufene automatische/manuelle Angebote mit den Fristen der Dispositionsniederlassung, ruft das Fahrergerät zurück und bereinigt überholte Vermittlungssperren. Er bleibt während des PHP-Parallelbetriebs deaktiviert (OFFER_REVOCATION_WORKER_ENABLED=false). Der Angebotslauf mit Kandidatenrunden wurde anschließend ergänzt; verbleibende Betriebs- und Menüthemen siehe Menüabgleich. Rückrufregeln, bewusste Korrektur falscher historischer Empfänger und Umschaltung sind dort dokumentiert.

17. Oktober 2026 – Vermittlungswechsel bei bestehenden Aufträgen

Die gemeinsame Kurierauswahl bietet „Automatische / manuelle Vermittlung …“ mit Vorschau, Bestätigung und geschützter Wiederholung. Automatisch wird Status 8, manuell Status 9 gesetzt; bisherige Kurierbindungen werden zurückgerufen. Beim Rechnungskunden mit „Nur Anforderungen“ kann die Ausnahme für diesen Auftrag beim automatischen Einreihen gesetzt oder entfernt werden. Angenommene Aufträge müssen zuerst manuell zurückgenommen werden; erledigte/verrechnete/gesperrte Aufträge bleiben geschützt. Freimeldezeiten, Preise und Rankinghistorie bleiben erhalten. Details, PHP-Referenzen und bewusste Korrektur der Geräterückrufe im Menüabgleich. Angebots-/Rückrufworker wurden anschließend ergänzt; die Betriebsumschaltung bleibt gesondert.

17. Oktober 2026: Die native Kurierauswahl in Listen/Auftragsbearbeitung zeigt zusätzlich laufende Aufträge mit Termin, Stationsfolge und erledigten Stationen. Eigene Auftragsdetails öffnen lesend über der Auswahl; der Zuweisungsentwurf bleibt erhalten. CLASSIC, BWV und manuelle Liste verwenden denselben aktuellen, paginierten Abruf. Vollständige Fremdniederlassungsdetails bleiben gesondert offen; siehe Menüabgleich.

Die Zuweisung aus Listen und Karte berücksichtigt jetzt außerdem wechselnde Fahrer bei aktiviertem RANKING_CR2CRVH_MULTI_RELATION: Fahrzeug und angemeldeter Fahrer werden getrennt angezeigt und vor Speicherung erneut gemeinsam geprüft. CLASSIC-Kundenvorgaben und BWV-Standortdaten beziehen sich auf den angemeldeten Fahrer. Der Fahrzeughalter bleibt unverändert; Offline-Zuweisung ist bei fehlender Anmeldung weiterhin möglich.

BWV-Vergütungsbasis – 17. Oktober 2026

Neue Fernaufträge sichern die berechnete Frachtvergütung ohne Service vor deren Aufschub unter dem PHP-Feld jb_cr_subtotal_last_without_service. Der separate Kurier-Servicepreis bleibt für die spätere Zuweisung erhalten. Die direkte Listen-Kurierzuweisung vergleicht jetzt Rundkilometer- und PZM-Vergütung und übernimmt Zuschläge, Service und Retourenwerte atomar. Inzwischen bietet sie eine bundesweite Kandidatenliste mit Radius, Favoriten, Echtzeit-/Vorbestellungsfenstern und gemeinsamem Vergütungsvergleich. Die bewusste BWV-Zuweisung kann einen Kurier aus einer anderen Niederlassung verwenden; die Auftragshoheit bleibt unverändert. Für normale Bestandsaufträge gibt es außerdem die CLASSIC-Rangliste mit PLZ-/Bereichs-/Nachbarschaftsgruppen und geprüften Fremdniederlassungs-Kandidaten; auch dabei bleibt die Auftragshoheit unverändert. Details, Quellen und verbleibende BWV-Sonderabläufe stehen im aktuellen Abschnitt von MENUE-ABGLEICH.md. Eine Neukalkulation erneuert die Grundlage; bereits disponierte Fernaufträge benötigen dafür vorher einen Rückruf. Die Auftragsbearbeitung zeigt inzwischen auch den Status der automatischen Retourenprüfung nach 60 Minuten. Offene Retourenmerkmale werden bei manueller Preisberichtigung/Neukalkulation beendet. Der native Hintergrundlauf ist implementiert, während des PHP-Parallelbetriebs aber standardmäßig deaktiviert; Umschaltung und Prüfgrenzen stehen im Menüabgleich.

Persönliche Erfassungsmodi – 16. Oktober 2026

Die aktuellen PHP-Vorgaben MODE_COPY_JOB und MODE_LATER_JOB werden über Mein Konto → Listenparameter gepflegt und beim Öffnen der Auftragserfassung gelesen. Referenz ist der erneut per SSH gelesene Arbeitsstand 2eb7f98 einschließlich der uncommittierten jobs/get_saved_tour.php und des tatsächlichen PHP-Parameterdialogs.

• Modus Nacherfassung = Buchhaltung: neue Eingabe beginnt als Nacherfassung; der Ausführungszeitpunkt bleibt bewusst leer. Disposition beginnt als Sofortauftrag. Wird dort ausdrücklich auf Nacherfassung gewechselt, wird die aktuelle Berliner Minute vorgeschlagen.
• Modus Auftragskopie = Buchhaltung: Kopie beginnt als Nacherfassung und schlägt den Zeitpunkt sowie das aktuell freigegebene Fahrzeug der Vorlage vor. Die Zuordnung wird gegen aktuelle Niederlassung, Unternehmer und Fahrzeugstatus geprüft. Ohne eindeutiges verfügbares Fahrzeug bleiben Auswahl und Pflichtprüfung offen; ein Hinweis erklärt die erforderliche Neuauswahl. Auch aus noch nicht angenommenen Vorlagen wird der vorgesehene Unternehmer berücksichtigt.
• Disposition für diese Erfassung: temporäre Checkbox übersteuert beide persönlichen Vorgaben, ohne sie zu speichern. Ein Wechsel bei bestehenden Eingaben benötigt die Bestätigung im Dialog; er verwirft Preisvorschau, Termine und Fahrzeugwahl, erhält aber die übrigen Eingaben. Die Kopierabfrage berücksichtigt dieselbe Übersteuerung. Persönliche Modi folgen bei niederlassungsübergreifender Erfassung der angemeldeten Niederlassung; Vorlage und Fahrzeug weiterhin der gewählten Erfassungsniederlassung.
• Neue Buchung: Warn- und Endzeit werden beim Kopieren nicht übernommen. Bestehende Status-, Geräte-, Lager- oder Fotoabläufe werden nicht erneut ausgeführt. Preisvorschau, gültiger Zeitpunkt, Kostenstelle, Fahrzeug und die übrigen normalen Speicherprüfungen bleiben erforderlich; ein ungültiges altes Datum wird nicht stillschweigend korrigiert.

Isolierte SQL- und Browserprüfungen decken beide Modi einzeln und gemeinsam, die Dispositionsübersteuerung, nicht mehr verfügbare Fahrzeuge sowie eine synthetische Kopie bis Preisvorschau/Speicherung ab. Gegen den echten Bestand wurden ausschließlich Konfiguration und Optionen gelesen.

Listenerfassung – 16. Oktober 2026

Einstieg über Aufträge → Listenerfassung (Erfassungsrecht 7). Grundlage ist die am 16. Oktober erneut direkt gelesene Serverdatei /data/0/votian-test/html/jobs/jb_edit_batch.php und die angemeldete PHP-Oberfläche. Der ursprüngliche lokale PHP-Bestand wurde nicht verwendet.

• Tabellarische Eingabe von bis zu 20 abgeschlossenen Fahrten: Kunde/Kostenstelle, Datum/Uhrzeit, Tourenverlauf/Rechnungstext, Referenz, Fuhrbetrag, Servicebetrag, Fahrzeug, Kilometer und Rabatt-/Zuschlagswahl. Datumsvorbelegung und Zurücksetzen einzelner Zeilen; Fahrzeugnummern-/Namens-/Kennzeichensuche. Reine Servicefahrten funktionieren mit Fuhrbetrag 0.
• Neue Kundenliste oder bestehende Liste öffnen und ergänzen; laufende Nummern werden im Speichertransactionsschritt vergeben. Listenbestand in Seiten zu 50 Listen, höchstens 1000 Aufträge je geöffneter Liste. Vorhandene Zeilen zeigen Erledigung, Referenz, Kostenstelle, Fahrzeug, Kilometer, Kundenpreis, Serviceanteil, Zuschlag und Kurierlohn. Berechtigte Auftragsbearbeiter können einen gespeicherten Auftrag öffnen.
• Vorschau berücksichtigt cs_discount, JB_EDITBATCH_DISCOUNT_DISABLED, cs_markup, historische Treibstoffzuschläge und MASK_CR_PRICE_MODE. Die spezielle PHP-Listenformel bleibt erhalten: Die rabattierte Fracht plus Service bildet die Kurierlohnbasis; der daraus ermittelte Servicefuhrlohn wird zusätzlich aufgeschlagen. Die Vorschau nennt diese Besonderheit ausdrücklich. Die normale Einzelauftragsformel wurde nicht geändert.
• Buchung mit Status 2, Herkunft 7, Besteller „Listenbuchung“, Versandkennzeichen 997 und einer erledigten neutralen Station auf der Firmenadresse. Speicherung in jobbatch/jobbatchlist, tourservice, jobprice (Typen 1/3/10/11, Kilometerkennung jbb), Zahlungsbedingungs-Snapshot und Audit-Outbox. Keine zusätzliche Kurierzuweisung oder automatische Erledigungsnachricht.
• Alle ausgefüllten Zeilen werden vor dem Schreiben geprüft; jeder Fehler rollt die gesamte Buchung zurück. Listenpositionen und Preise werden beim Speichern unter Tabellensperren erneut geprüft. Stabile Vorgangskennung mit Ergebnisbeleg schützt vor Doppelbuchungen; bei unklarem Speicherergebnis bleibt die Eingabe bis zur Wiederholungsprüfung gesperrt. Sämtliche beschriebenen Tabellen müssen InnoDB sein; der aktuelle Bestandsstand erfüllt dies. Es wird keine Schemaänderung ausgeführt.

Bewusste Grenzen: eigene Kontoniederlassung, aktive/freigegebene Kostenstellen und Fahrzeuge, eindeutige Berliner Zeiten ab 2000 bis jetzt, nichtnegative Beträge/Kilometer bis 99.999,99 mit zwei Nachkommastellen. Zukünftige Fahrten gehören in die normale Reservierung; die PHP-Warnung mit möglichem Mailversand wurde nicht übernommen. Der allgemeine PHP-Hintergrundaufruf zur Entfernungsberechnung bleibt offen. B2B-Rechnungspositionen werden bei neuen Listenbuchungen inzwischen nativ geschrieben. Die manuell erfassten Kilometer werden unverändert gespeichert. Rechnungstexte und optionale CO₂e-Berechnung sind wie unten beschrieben ergänzt.

Ergänzung: Rechnungstexte und CO₂e

Erneuter Abgleich am 16. Oktober mit der angemeldeten PHP-Listenerfassung und frisch per SSH gelesenen include/caglobal.inc.php, tools/co2e_sendReq.php, tools/get_job_distance.php und locating/xServer.inc.php.

• Vorschau und gespeicherte Listen zeigen die erzeugten Kunden- und Kurierrechnungstexte. Rabatt (als negativer Abzugsbetrag), Treibstoffzuschlag und Servicepreis folgen dem PHP-Listenpfad; der Kuriertext enthält den Tourenverlauf ohne Kundenpreisergänzungen. Relevante Vorgaben: INV_PRINT_DISCOUNT, MASK_MARKUP_MODE, INV_SHOW_MARKUP_BATCH, INV_PRINT_SRVPRICE, globales INV_PRINT_SRVPRICE_<Kunden-ID>, INV_JB_INVOICE_CR und INV_USE_EURO_SIGN. Mehrdeutige oder anders abgegrenzte Kundenvorgaben werden abgewiesen.
• INV_MAXCOLS, INV_MAXLINES, INV_MAXCOLS_EXPORT und INV_PRINT_REMARK steuern Umbruch, Exportauffüllung und Leerzeilen. Wenn explizite Umbrüche nicht passen, werden sie wie im PHP zu Semikolons zusammengezogen. Bewusste Abweichungen: Unicode-Zeichen zählen als Zeichen, SQL-Apostrophe werden nicht im Text maskiert, und zu lange Wörter/Texte lösen einen Fehler statt stiller Kürzung aus. Nicht konfigurierte Breite/Zeilenzahl verwenden 80/20, Exportbreite 0. Bestandsparameter wurden nur lesend geprüft (überwiegend 70/50/70). Anzeige entfernt lediglich abschließende Leerzeilen; gespeichert wird der formatierte Text.
• Option CO₂e aus eingegebenen Kilometern berechnen verwendet den bestehenden, aus .env konfigurierten Dienst. Explizit wählbar, standardmäßig aus. Gewicht ist wie beim PHP-Ersatzwert die halbe Fahrzeugnutzlast; Fahrzeugtyp und Umweltplakette bestimmen MLP. Kilometer 0 ergeben keinen CO₂e-Wert; eine fehlende Nutzlast bei positiven Kilometern verhindert die Vorschau. Nicht konfigurierter Dienst deaktiviert die Auswahl.
• Der Dienstaufruf erfolgt in der Vorschau außerhalb einer Datenbanktransaktion. Berechnungen sind fünf Minuten gültig, nach Benutzer/Niederlassung/Vorgang/Zeile und Eingaben getrennt. Speicherung verwendet ausschließlich das bereits geprüfte Ergebnis; abgelaufene Ergebnisse oder geänderte Stammdaten/Druckvorgaben verlangen eine neue Vorschau. Wiederholung einer bereits gebuchten Anfrage funktioniert auch ohne Berechnungscache.
• CO₂e und historische Partnerprovision werden als jobprice 12/14 gespeichert, der vollständige Berechnungsbeleg zusätzlich als ng_co2_calculation im bestehenden genericdatacontainer; das alte Bemerkungsfeld bleibt auf 50 Zeichen begrenzt. Rechnungstexte, CO₂e, Provision, Aufträge und Quittungen gehören zur selben Transaktion. Keine Datenbankmigration und keine Testbuchungen im Bestand.

Nicht enthalten sind automatische Hintergrund-Neuberechnung, Adress-Geocodierung aus dem freien Tourenverlauf und PHP-Warnmails. Die CO₂e-Vorschau ist eine gezielte native Ergänzung; sie bildet den gesamten PHP-Hintergrundlauf nicht nach.

Ergänzung: B2B-Rechnungspositionen

Abgleich am 16. Oktober mit frisch gelesenen jobs/jb_edit_batch.php, include/caglobal.inc.php::mk_jb_invtext/checkDiscountStr und include/services_func.inc.php::getJobCosts (Serverstand 93bf782) sowie der angemeldeten alten Listenmaske. Schema nur lesend geprüft: phoenix_log.b2b_objects ist InnoDB, keine Bestandsdaten verändert.

• Neue Listenbuchungen schreiben ihre Rechnungspositionen in das über HISTORY_DB_SCHEMA konfigurierte Historienschema, Tabelle b2b_objects. PHP-Vertrag: Typ 300, Version/Status 0, Auftrag in bo_ext_id0, Niederlassung in bo_ext_id1, bo_ext_id2=0, Buchungszeit und JSON-Array ["c", Faktor/Menge, "s", Leistung, "p", Basis, "t", Betrag]. Zahlenwerte sind Zeichenketten mit zehn signifikanten Stellen; negative Rabattbeträge bleiben negativ.
• Treibstoffzuschlag, Rabatt und separater Servicepreis folgen denselben Druckvorgaben wie die Rechnungstexte. Zusätzlich berücksichtigt die native Formatierung jetzt MASK_INVOICE_SHOW_SERVICES_<Kunden-ID>: bei Kunden mit Abrechnungsmodus ungleich 0 kommen die bereits rabattierte Fixpreiszeile und der Servicebetrag als Detailzeilen hinzu. Bei PZM-Kunden unterdrückt der aktuelle PHP-Code diese beiden Listenpositionen; dies wird übernommen.
• Der detaillierte Serviceausweis und der separate Servicepreis-Ausweis sind unabhängige PHP-Zweige. Deshalb kann Servicepreis zweimal erscheinen, und Detailzeilen enthalten bereits Rabatt/Zuschlag. Die Positionen sind keine eigenständige Summe der Rechnung. Die Oberfläche nennt diese Besonderheit und zeigt Faktor/Menge, Leistung, Basis und Betrag neben beiden Rechnungstexten in Vorschau und gespeicherter Liste.
• Schreibvorgang, Exportpositionen, Audit und Wiederholungsbeleg werden auf derselben Datenbankverbindung gemeinsam unter Tabellensperren committed. Beide Schemata müssen auf demselben Server erreichbar sein; B2B-Zieltabelle muss InnoDB sein. Fehlende/ungeeignete Tabelle verhindert Vorschau und Buchung. Speicherfehler rollen auch bereits geschriebene Exportpositionen zurück. Neue Vorgänge erzeugen neue Aufträge; vorhandene Typ-300-Datensätze werden weder gelöscht noch ersetzt.
• Die Listenansicht liest nur Positionen der vorher vollständig geprüften Auftragsliste und der eigenen Niederlassung; andere Typ-300-Formate wie Scan-/Statusmeldungen werden nicht als Rechnungspositionen angezeigt. Geänderte Druck-/Kundenvorgaben verlangen vor dem Speichern eine neue Vorschau. Wiederholungsanfragen schreiben keine zweiten Exportpositionen.

Abgrenzung: bereitgestellte Rechnungspositionen für neue Listenbuchungen, keine Bestätigung einer Verarbeitung durch externe BI-Systeme. Kein automatisches Nachbefüllen älterer Listen, kein eigener BI-Transportdienst, keine vollständige Rechnungserstellung. Die nachfolgend beschriebene Aktualisierung deckt bestehende einfache Listenbuchungen ab; allgemeine Kalkulationssonderfälle und der PHP-Hintergrundlauf bleiben gesonderte Restpunkte.

Ergänzung: Rechnungsausgabe nach Änderungen aktualisieren

Am 16. Oktober erneut direkt vom SSH-Server abgeglichen: jobs/jb_edit_batch.php:452–514 (Bearbeitung gespeicherter Listenaufträge), jobs/job_options.php:1900–1903 (Rechnungsausgabe nach Speichern), include/caglobal.inc.php:1011–1245,1485–1598 und include/services_func.inc.php:883–969. Alte angemeldete Listenmaske im Browser geöffnet; kein echter Auftrag zur Bearbeitung gesperrt oder geändert.

• In Auftrag bearbeiten → Rechnungsausgabe der Listenbuchung lassen sich Kunden-/Kurierrechnungstext und B2B-Positionen aus dem gespeicherten Auftrag neu erzeugen. Vorher-/Nachher-Vorschau und ausdrückliche Übernahme, weil manuelle Rechnungstextänderungen sonst überschrieben würden. Das ist eine gezielte Aktualisierung; kein stiller Hintergrundlauf. Nach Änderungen am Freitext oder an Stationsreferenzen sowie nach einer Preisberichtigung wird die Ausgabe als zu aktualisieren markiert; Neukalkulation setzt bereits dieselbe Markierung.
• Verwendet werden die gespeicherten Fuhr-/Servicepositionen, deren Rabatt und Zuschlag sowie die aktuellen Druckvorgaben. Keine erneute Tarifberechnung und keine Änderung von Auftragssumme, Frachtvergütung, Zustellnachweisen oder Kilometern. Maut und Stationsreferenzen kommen wie im PHP-Listenpfad in beide Basistexte. Bei deaktiviertem Kuriertext-Ausweis bleibt der vorhandene Kuriertext erhalten. Leerer PHP-Calculator (²²²) wird korrekt als leer erkannt.
• Gilt für eindeutig einer Kundenliste zugeordnete Herkunft-7-Aufträge mit Fixpreis (auch manuell berichtigt) und optionalem Servicepreis einschließlich gespeichertem Servicerabatt; auch ältere PHP-Listenbuchungen können einzeln aktualisiert werden. Preispositionen müssen zur Auftragssumme passen. Zusätzliche Tarif-/PZM-/Calculatorpositionen, unterschiedliche von null abweichende Rabattprozentsätze für Fuhr- und Servicepreis, Kostensplit, Barzahlung und verbundene Unteraufträge bleiben außerhalb dieses Aufbereitungszweigs und werden mit einer konkreten Meldung abgewiesen.
• Gespeicherter Selbsterfasserrabatt bei gewöhnlichen Fixpreisen wird berücksichtigt: jobprice.mt_sort=13 enthält den Prozentsatz und in jbprc_remark den ursprünglichen Fuhrbetrag einschließlich Zuschlag. Der Rabatt steckt bereits im gespeicherten Fuhrpreis und wird nicht nochmals abgezogen. Die Zuschlagsposition verwendet den ursprünglichen Betrag; der gewöhnliche Kundenrabatt verwendet den bereits um den Selbsterfasserrabatt verminderten Fuhrpreis. Der Selbsterfasserrabatt erscheint auch bei ausgeschaltetem allgemeinem Rabattausweis; Kuriertext und unabhängige Servicepreiszweige behalten ihr bisheriges Verhalten.
• Rabattmetadaten müssen eindeutig und mit den gespeicherten Centbeträgen konsistent sein. Fehlende/ungültige Basis, doppelte Einträge, negative Prozentsätze und 100 % oder mehr werden abgewiesen. Eine manuelle Preisberichtigung entfernt die überholten Metadaten des Selbsterfasserrabatts atomar mit der Preisänderung; Zahlungsbedingungen und andere nicht ersetzte Zusatzdaten bleiben erhalten. Die Aktualisierung berechnet weiterhin keine Preise neu.
• Vorschau umfasst Auftrag, Preise, bisherige B2B-Ausgabe und Druckvorgaben. Änderungen daran entwerten die Übernahme. Exportierte, abgerechnete, stornierte oder aktuell in PHP gesperrte Aufträge sowie laufende Rechnungszuordnungen sind gesperrt. Bereits verarbeitete B2B-Zeilen (Status/Version/weitere Zuordnung ungleich 0) werden nicht ersetzt.
• Ersetzt werden ausschließlich erkannte Rechnungs-JSONs des Auftrags und seiner Niederlassung. Scan-/Statusmeldungen wie REF|501, fremde Niederlassungen und andere Typen bleiben erhalten. Ausgabe, Auftragsversion, Markierung, Audit und Wiederholungsbeleg werden auf derselben Verbindung über beide Schemas atomar geschrieben. Beide Schreibtabellen plus HQ/Belege müssen InnoDB sein. Ein Fehler nach Löschen/Teilneuschreiben oder beim Audit stellt den alten Zustand vollständig wieder her; identische Wiederholungen und gleichzeitige Aufrufe erzeugen keine Duplikate.
• Der JDBC-Zugriff liest die numerische Auftragsherkunft ausdrücklich als Zahl, da MariaDB TINYINT(1) sonst auch für Herkunft 7 als Boolean zurückliefert.

Ergänzung: Rabattierter Servicepreis in bestehenden Listenbuchungen

Am 16. Oktober direkt vom SSH-Serverstand 090d3d5 und den ausgelieferten Arbeitsdateien abgeglichen: jobs/job_options.php:1069–1078,1846–1856, include/caglobal.inc.php:1075–1125,1203–1229,1485–1598 und include/services_func.inc.php:883–969. Die aktuelle PHP-Erfassung zeigt Servicepreis und „Kundenrabatt beim Fest- und Servicepreis berücksichtigen“. Fünf feste Beispiele wurden mit der frisch gelesenen PHP-Funktion und rein synthetischen Datenbank-/Schreib-Stubs direkt auf dem Server ausgewertet; keine echten Aufträge oder Ausgaben verändert.

• Die Aktualisierung akzeptiert jetzt auch rabattierte Servicepositionen. Maßgeblich sind die bereits gespeicherten Prozentsätze, nicht die inzwischen geltenden Kundenvorgaben. Fuhr- und Servicebetrag werden für den Summenabgleich jeweils separat auf Cent gerundet; so bleiben auch zwei halbe Cent kompatibel mit der PHP-Speicherung. Zwei unterschiedliche, von null abweichende Rabattsätze werden wegen des mehrdeutigen PHP-Gesamtrabattausweises weiterhin abgewiesen.
• Der detaillierte Serviceausweis verwendet den rabattierten Wert, einschließlich ungerundeter B2B-Präzision gemäß getJobCosts. Der separat zuschaltbare Servicepreis-Ausweis verwendet weiterhin jb_serviceprice vor Rabatt. Beide Druckschalter bleiben unabhängig. Servicefahrten ohne Fuhrpreis, 100 % Servicerabatt, Selbsterfasserrabatt und deaktivierter Kuriertext sind berücksichtigt.
• Besonderheit der bestehenden PHP-Ausgabe: checkDiscountStr addiert die einzeln gerundeten Beträge Preis × (1 + Rabatt) aller rabattierten Positionen, zieht diese Summe aber nur vom Fuhrpreis ab. Bei 120 € Fuhrpreis und 10 € Service, jeweils 10 % Rabatt, lautet die Rabattzeile daher −23 €, obwohl die gespeicherte Auftragssumme korrekt 117 € beträgt. Bei ausschließlich rabattiertem Service kann die Zeile sogar positiv sein. Die native Ausgabe bildet diesen bestehenden Text-/B2B-Vertrag ab und zeigt vor der ausdrücklichen Übernahme einen Hinweis. Es wird keine neue finanzielle Berechnung daraus abgeleitet; gespeicherte Preise bleiben unverändert.
• Änderungen an einer Servicepreiszeile nach der Vorschau entwerten die Übernahme. Vollständiger Rollback bei einem Fehler nach dem zweiten B2B-Insert sowie identische Wiederholung sind geprüft. Fremde Exportdaten und Zustellnachweise bleiben erhalten.

Ergänzung: Text nur für die Kundenrechnung

Am 16. Oktober erneut direkt vom SSH-Serverstand 090d3d5 abgeglichen: jobs/job_options.php:227,1990–1993,2270 und include/caglobal.inc.php:1203–1205,1343. Die aktuelle PHP-Erfassungsmaske zeigt Text nur Rg. Ihr Popup ließ sich im isolierten Tab wegen eines vorhandenen JavaScript-Fehlers beim Zugriff auf top nicht öffnen; Speicherung und Verwendung wurden daher im aktuellen Serverquellcode geprüft.

• Auftrag bearbeiten → Abrechnung → Text nur für die Kundenrechnung ergänzt die bereits vorhandene Eingabe bei der Neuerfassung. Der Zusatz kann mit Erfassungsrecht bearbeitet und geleert werden; maximal 20.000 Zeichen. Nichtleerer Text einschließlich Zeilenumbrüchen wird unverändert unter dem PHP-Schlüssel jb_hiddenFreetext_1 gespeichert. Andere Zusatzdaten bleiben erhalten; ältere Clients ohne dieses Feld überschreiben den Zusatz nicht.
• Bei der Rechnungsaktualisierung einfacher Listenbuchungen steht der Zusatz nach Freitext/Maut/Stationsreferenzen und vor den Preisdetails ausschließlich im Kundenrechnungstext. Er erscheint weder im Kurierabrechnungstext noch als zusätzliche B2B-Preisposition. Druckformat und Zeilenlimit werden weiterhin geprüft; Preise werden nicht geändert.
• Änderungen markieren die Rechnungsausgabe als zu aktualisieren. Für Listenbuchungen erfolgt die Übernahme ausdrücklich über Vorschau und Bestätigung. Bei anderen Auftragsarten bleibt die eigentliche Rechnungsaufbereitung im bisherigen Verarbeitungslauf; diese Ergänzung erweitert nicht die native Rechnungserzeugung auf sämtliche Kalkulationsarten.
• Der Zusatz gehört zum Revisionsstand: zwischenzeitliche PHP-Änderungen auch ohne neue Auftragsversion verhindern das Überschreiben. Mehrdeutige doppelte Zusatzdatensätze werden gemeldet. Speicherung, Audit und Wiederholungsbeleg sind atomar; fehlgeschlagene und wiederholte Anfragen erzeugen keine Teiländerungen oder Duplikate.
• Unveränderte formatierte Kunden-/Kuriertexte behalten beim Bearbeiten anderer Felder ihre vollständigen Leerzeilen. Der bisherige allgemeine Eingabeabgleich hatte diese entfernt. Die bestehende Kopiervorlage übernimmt den Rechnungszusatz; die separate Eingabegrenze der Neuerfassung bleibt unverändert.

Offen bleiben die automatische Aktualisierung ohne Einzelprüfung, die Aufbereitung komplexer Kalkulationen und die allgemeine PHP-Hintergrundverarbeitung samt eigenem BI-Transport/Empfangsbestätigung.

Der Selbsterfasserrabatt wurde am 16. Oktober erneut mit include/caglobal.inc.php:1485–1598 und jobs/job_options.php:1053,1846–1849,1897–1898 direkt vom SSH-Serverstand 090d3d5 abgeglichen. Quellcode und Tests dieser Ergänzung stammen von Qwen 3.8: zunächst qwen3.8-27b-mlx im LM Studio, nach dem Serverwechsel qwen3.8-27b auf 192.168.180.3:8000; fachliche Prüfung, Patchübernahme und Testausführung erfolgten durch Codex. Protokolle der delegierten Aufträge liegen lokal unter work/qwen-self-discount/ (nicht versioniert).

Aktualisierung 15. Oktober 2026: Die sechs beim aktuellen PHP-Abgleich gefundenen Abweichungen sind nativ ergänzt. Verbindliche PHP-Quelle bleibt ausschließlich der aktuelle SSH-Serverstand unter /data/0/votian-test/html.

Ergänzungen nach dem Abgleich vom 15.10.2026

• An/Ab ohne Auswahl: Je Station ist zusätzlich „Weder Abholung noch Zustellung“ auswählbar (NONE, Bestandswert tr_ware_from_to=0). Dieser Zustand bleibt beim Anlegen, Anzeigen, Kopieren, Bearbeiten und Neukalkulieren erhalten. Die Fotoauswahl berücksichtigt ihn wie der aktuelle PHP-Code: ALL, EXCEPT_PICKUP und EXCEPT_DELIVERY sind zulässig, reine Abhol-/Zustellregeln nicht. Ein Wechsel der Stationsart setzt die explizite Fotoauswahl auf die passende Set-Vorgabe zurück.
• Automatische Preisermittlung: Standard ist „Automatisch nach Kundenabrechnungsmodus“. Der Server wählt bei Modus 0 PZM, sonst PLZ-/Gebietstarif; Kostenstellen-Overrides werden berücksichtigt. Expliziter Festpreis, Kilometerpreis und Leistungskalkulation bleiben auswählbar. Preisrelevante Änderungen an geladenen Festpreistouren eines PZM-Kunden schalten wieder auf automatische Berechnung. Wiederholungen bereits gespeicherter AUTO-Anfragen verwenden weiterhin die ursprüngliche Anfragekennung, auch bei inzwischen geänderten Kundenvorgaben.
• Rückdatierung: Die 36-Monats-Grenze wird vor Preisprüfung und Speicherung serverseitig mit Berliner Uhrzeit geprüft; die Nacherfassungsmaske zeigt zusätzlich die untere Datumsgrenze.
• Tourenoptimierung: 4–25 vollständige Stationen, Start fest; Endstation wahlweise fest oder frei. PZM optimiert die Zwischenstationen, bei freiem Ende werden die möglichen Endstationen verglichen. Nur eine kürzere, vollständig geprüfte Reihenfolge wird zur Übernahme angeboten. Kassierstation, Anhänge, Artikel und explizite Stationsdaten bleiben über ihre Stationsidentität zugeordnet; der Preis muss danach neu geprüft werden.
• Adressvorschläge: Debouncete Google-Places-Suche direkt am Straßenfeld. Übernahme von Straße, Hausnummer, PLZ, Ort und Land, Löschen einer zuvor abweichenden Rechnungs-PLZ; unvollständige Adressbestandteile werden nicht aus der alten Adresse ergänzt. API-Schlüssel bleiben auf dem Server. Erfassungsrecht genügt; Stammdatenrechte werden nicht erweitert. Ausbleibende Vorschläge blockieren die manuelle Eingabe nicht.
• PLZ-Preisanfrage: Eigenständiger Dialog für 2–6 PLZ, abweichende Rechnungs-PLZ, Fahrzeugtyp und optionalen Treibstoffzuschlag. Allgemeine Niederlassungstarife ohne Kundenkonditionen, Grundpreis einmal und alle Teilstrecken separat. Berlin zeigt Bereichs- und PLZ-Tarif. Fehlende/mehrdeutige Tarife werden ausdrücklich gemeldet. Kein Besteller, Zahler oder vollständiger Auftrag erforderlich; keine Auftragsanlage.
• Routenkarte/Aktualisierung: Eingebettete Karte mit Stationsnummern und getrennten Linien für Transport, An- und Abfahrt sowie Zeitpunkt der Routenberechnung. „Route neu berechnen“ umgeht den NG-Routencache und erneuert die Preisvorschau. Fehlende Geometrie wird kenntlich gemacht. Kartenanzeige und Abrufzeit verändern den Preisfingerprint nicht; umfangreiche Kartenlinien werden nicht im Bestands-Routenbeleg gespeichert.

Die externen Dienste (Places, PZM, Kartenkacheln) müssen weiterhin erreichbar und passend konfiguriert sein. Die dokumentierte Speicherabweichung bei Zahlungsbedingungen und der PHP-B2B-Exportpfad bleiben separate Integrationsgrenzen; sie gehören nicht zu den sechs hier behobenen Funktionslücken.

Ausgangsbefund des PHP-Abgleichs vom 15.10.2026 (vor Umsetzung)

Quelle und Prüfumfang: Frisch per SSH aus root@172.16.0.158:/data/0/votian-test/html gelesene Erfassungsdateien und eingebundene Preis-/Speicherlogik. Remote-HEAD ist 93bf782 vom 14.10.2026; die tatsächlich ausgelieferten Dateien enthalten zusätzlich uncommittete Änderungen, insbesondere in ajaxReqKmPrice.php, caglobal.inc.php, inc_job.inc.php, job_edit.68.20.js, job_header.php und job_options.php. Verglichen wurden diese Arbeitsdateien, nicht nur der Commit. Acht Kerndateien wurden mittels SHA-256 gegen den Server geprüft. Der alte lokale PHP-Stand wurde nicht verwendet. Der nur lokal gehaltene Prüfstand mit Hashmanifest liegt unter work/php-order-audit-2026-10-15/.

Im Browser geprüft: die aktuelle PHP-Erfassung mit ihren Frames, die separate PHP-Preisanfrage und die laufende native Erfassung unter localhost:8080. Die folgenden Unterschiede sind durch Oberfläche und Quellcode belegt; es wurden keine echten Aufträge angelegt, Dateien hochgeladen oder Nachrichten versendet.

Priorität	Funktion	Aktuelles PHP	Native Erfassung	Auswirkung / Fundstellen
Hoch	Automatische PZM-Auswahl	checkJob() berechnet für den Abrechnungsmodus 0 ohne Fixpreis automatisch den PZM-Preis und übernimmt ihn; auch bestimmte Änderungen geladener Touren erzwingen eine Neuberechnung.	Die Maske startet mit TARIFF. Die Kundenvorgaben liefern keinen Abrechnungsmodus an das Formular. TARIFF mit Modus 0 endet in einer Fehlermeldung, statt auf PZM umzuschalten. Manuelles Auswählen von ZONE ist vorhanden.	Unterschied im regulären Erfassungsablauf, kein grundsätzlich fehlender PZM-Rechner. PHP job_edit.68.20.js:6216; NG OrderEntryForm.tsx:110, OrderEntryCatalog.java:95, LegacyOrderPricing.java:81.
Hoch	Maximale Rückdatierung	Die korrigierte Datumsprüfung blockiert ein Auftragsdatum, das mehr als drei Jahre / 36 Monate zurückliegt.	Nacherfassung prüft Vergangenheit und allgemein Jahr ≥ 2000, aber keine 36-Monats-Grenze.	Beispielsweise wird ein Termin aus 2022 im Oktober 2026 von dieser NG-Datumsvalidierung nicht abgewiesen. PHP job_edit.68.20.js:6301; NG OrderEntryService.java:132, OrderEntryService.java:166, OrderEntryForm.tsx:299.
Mittel	Tour automatisch optimieren	Für neue/disponierbare Touren mit 4–25 vollständigen Stationen erscheint „Optimieren“. Wahlweise bleibt die Endstation bestehen oder wird einbezogen; anschließend wird die bessere Reihenfolge übernommen.	Stationen lassen sich manuell verschieben/vertauschen. Eine automatische Optimierung und die Option zum Festhalten der Endstation fehlen.	PHP job_edit.68.20.js:2353, job_edit.68.20.js:6538, ajaxReqKmPrice.php:342, job_tour.php:1114; NG OrderEntryForm.tsx und OrderRoutingService.java.
Mittel	Adressvorschläge während der Eingabe	Google Places Autocomplete in beiden Straßenfeldern mit Übernahme der Adressbestandteile.	Freie Straßenfelder; separate Suche in bisherigen Auftragsadressen und eingebettete Kartenauswahl. Kein Places-Autocomplete in der Auftragserfassung.	Die bereits vorhandene Places-Suche in den Stammdaten deckt diesen Erfassungsablauf nicht ab. PHP job_tour.php:230; NG OrderEntryForm.tsx:65 und :72; vorhandener Baustein MasterAddressLookup.tsx.
Mittel	Separate PLZ-Preisanfrage	„Preisanfrage“ öffnet eine eigenständige Kalkulation für bis zu sechs PLZ, Fahrzeugtyp und Treibstoffzuschlag, ohne vollständigen Auftrag und ohne Zahlerauswahl.	Die Preisvorschau verlangt einen vollständigen Auftrag mit Zahler, Besteller und Stationsadressen. Keine entsprechende separate PLZ-Preisanfrage in der Erfassung.	„Als Angebot erfassen“ und der PZM-Preisvergleich bestehender Aufträge sind andere Abläufe. PHP job_edit.68.20.js:5757, jobs/price_query.php; NG OrderEntryForm.tsx.
Mittel	Routenkarte und erzwungene Aktualisierung	Die Kilometerangabe öffnet Google-Routen bzw. map_pzm.php; bei einer wiederverwendeten Route werden deren Stand und „Aktualisieren“ (zoneForceNew) angeboten.	Die Routenvorschau zeigt Entfernung, Fahrzeit, Berechnungsstrecke und Niederlassung als Text. Keine Karte der berechneten Route, kein Routenstand und keine explizite Umgehung des bis zu fünf Minuten gültigen Routencaches.	Die Karte zur Auswahl einer einzelnen Stationsadresse ist bereits vorhanden. PHP job_edit.68.20.js:6533 und :6589; NG OrderEntryForm.tsx:385, OrderRoutingService.java:182.

Bereits vorhanden, daher keine neuen Lücken: Sofortauftrag/Vorbestellung/Dauerauftrag/Nacherfassung, Kostenstellen- und Rechnungs-PLZ-Suche, Kostensplit, Kurier-Unteraufträge, Artikel/Lager und freie Positionen, Foto-Workflow-Sets, Tastenkürzel, Nachhaltigkeit, niederlassungsübergreifende Erfassung, Kilometer-/PZM-Preise, An-/Abfahrt, BWV-/Fernverkehrsregeln und Niederlassungsvergleich. Die neueren PZM-Schritte (Prüfung einschließlich An-/Abfahrt, weitere Niederlassungen entlang der Route, Auswahl der kürzesten Berechnungsstrecke) sind im nativen Routing grundsätzlich enthalten. Das ist kein Nachweis identischer Beträge für sämtliche realen Tarife.

Bewusste Speicherabweichung / Integrationsgrenze: Das aktuelle PHP verwendet jobprice.mt_sort=16 sowohl für den Kilometerpreis als auch für einen Zahlungsbedingungstext. NG speichert die Zahlungsbedingung getrennt als ng_payment_term und ng_payment_term_label, liest zusätzlich vorhandene PHP-Zahlungsbedingungen und verwendet den Snapshot in der nativen Abrechnung. Das Feld fehlt somit nicht; die gegenseitige Weiterbearbeitung in PHP und NG wurde in diesem Abgleich nicht durch einen echten Schreib-/Lesezyklus bestätigt. PHPs überarbeitete B2B-Rechnungstext-Erzeugung in caglobal.inc.php bleibt außerdem eine externe Weiterverarbeitung: NG setzt jb_invtext_dirty, ein vollständig nativer Ersatz dieses PHP-Exportpfads wurde hier nicht nachgewiesen.

Verifikation: 72 Tests aus OrderEntryServiceTest, OrderEntryCatalogTest, OrderRoutingServiceTest, LegacyOrderPricingTest, LegacyDistancePricingTest und OrderPaymentTermsTest erfolgreich, ohne Fehler oder übersprungene Tests. Der vorhandene Test missingRouteTariffsNeverBecomeFreeOrders bestätigt ausdrücklich die native Fehlermeldung bei TARIFF und Abrechnungsmodus 0. Die Tests bestätigen das derzeitige NG-Verhalten, nicht die Vollständigkeit gegenüber PHP. Keine Anwendungscodeänderungen, kein Neustart und kein produktiver Schreibtest für diesen Abgleich.

Stand: 13. Oktober 2026. Die neue Erfassung schreibt über den zentralen DatabaseService in das unveränderte Bestandsschema. Die PHP-Dateien wurden nicht geändert. Diese Umsetzung ersetzt die unten beschriebenen Erfassungsabläufe, nicht sämtliche Sonderfunktionen der PHP-Auftragsmaske.

Fachlicher Umfang

Ablauf	Verhalten
Sofortauftrag	Aktuelle Berliner Uhrzeit, Status aus HQ-Arbeitsmodus und Fahrzeugzuweisung
Vorbestellung	Zukünftiger Abholtermin, Reservierungsflag, optionale Warnzeit
Dauerauftrag	Alle 11 bestehenden Rhythmuscodes, Wochentagsmaske, optionales einschließliches Enddatum; wahlweise sofortige Anlage bis zum Serienende mit Vorschau aller Termine und Preise; sonst erzeugt der bestehende Dauerauftragsdienst die Folgen
Barzahlung	Technischer Systembarzahler und tatsächlicher Zahler getrennt, wählbare Kassierstation, Netto/Steuer/Brutto und Bestandsmarker im Stationshinweis
Fahrzeugzuweisung	Suche über SID, Kuriername oder Kennzeichen; bestehende Fahrzeug-/Kurier-ID und Vorbelegung werden gespeichert; Status gemäß PHP-Eingangspfad
Nacherfassung	Ausführendes Fahrzeug erforderlich, Datum in der Vergangenheit; Auftrag erledigt und Stationen abgeschlossen, separate Buchungszeit
Stationen	Kostenstellen- und Adresssuche, freie Adressen, beliebig umordnen, 1–100 Stationen, Abholung/Zustellung/beides/weder noch, Kontakt, Telefon, Referenz und Hinweis
Preis	PLZ-/Gebietsmatrix oder Festpreis; historische Gültigkeiten, Grundpreis, Kundensonderkonditionen, Rabatt, Kraftstoffzuschlag, Servicepreis, Frachtvergütungsabschlag, Steuer, Dezimalrundung
Foto-Workflow-Sets	Freigegebene Sets des zahlenden Kunden, globale Rückfallebene, Standards nach Stationsposition/-art, abweichende Auswahl je Station einschließlich Nummer 0, gesicherte Übertragung mit Wiederholung
Fernverkehr	Automatische Kilometer-/PZM-Kalkulation, Mindestpreise, An-/Abfahrt, Fernverkehrsgrenze pro Streckenabschnitt, BWV-Sonderkonditionen und bewusste ASAP-Auswahl
Auslandsabholung	Vergleich der gesamten Rundfahrt für die jeweils drei nächsten Niederlassungen an Start und Ziel; günstigste Fahrstrecke bestimmt die Disposition
Disposition	HQ-Zuordnung, Vermittlungsbereiche einschließlich wählbarer Rechnungs-PLZ, Kunden-/Pflichtfilter und zusätzliche Kurierfilter, Wunschkurierregel, manuelle Disposition, Annahmefrist und Storno bei Nichtverfügbarkeit
Alle Kuriere / Börsenmodus	Bestands-Ausschlussliste aus Länderfreigaben und EG-/Gewichtsprüfung wird vor der Freigabe in derselben Transaktion gespeichert; Fotoübertragung hält den Auftrag gegebenenfalls zunächst zurück
Kopieren / Tourvorlagen	HQ-begrenzte Suche, Übernahme als neuer Auftrag, Tourname und ausdrücklich bestätigtes Überschreiben; persönlicher Buchhaltungsmodus mit Ausführungszeit und erneut geprüftem Fahrzeugvorschlag, Dispositionsübersteuerung; keine Übernahme von Status, Geräteübergabe, Anhängen oder Versicherung
Mehrfachaufträge	1–10 gleiche Aufträge in einer Transaktion; Wiederholung liefert dieselbe Gruppe
Herkunft / Angebot	Telefon, Mail oder Sonstiges; Angebot in manueller Disposition und zur Nachbearbeitung
Rechnung	Kunden-Steuerschlüssel, erforderlicher Besteller und kundenabhängige Referenz, getrennte Rechnungstexte, Maut/Auslagen einschließlich Steuer und Barbetrag, Rechnungsmail anzeigen/mit ausdrücklicher Auswahl aktualisieren
Leistungskalkulation	Kundenspezifische oder globale Leistungs-/Typkombinationen, Mengen und historische Preise; Pflichtkalkulation; PHP-Kalkulationsformat in jb_freetext_2 und eine zusammengefasste Preisbuchung
Höherversicherung	Bestands-Prämienberechnung mit Mindestbetrag/Aufrundung, separater verknüpfter Versicherungsauftrag und technischer Kurier; Sonderfall offen
Adressen / Dateien	Abhol-/Lieferadresse der Kostenstelle (adt_id=4), Suche in bisherigen Aufträgen, eingebettete Kartenauswahl mit Rückübernahme, Prüfung neuer Adressen mit ausdrücklicher Übersteuerung, Upload-Dienst je Station
Kostensplit	Gleiche, centgenaue Verteilung auf unterschiedliche interne Stationskostenstellen und den gewählten Zahler; Vorschau je Empfänger
Kurier-Unteraufträge	Unternehmerverrechnung bei Nacherfassungen im Inland, bis zu 20 Unternehmer, positive Unteraufträge und Gegenbuchungen
Artikel / Lager	Artikel je Station, Mengen, Gewicht, Packstücke und Seriennummer; ausdrücklich ausgewählte Ein-, Aus- und Umlagerung mit Bestandsprüfung und Journal
Freie Artikelpositionen	Freie Bezeichnung, Menge, Gesamtgewicht, Packstücke, Artikelwert, Seriennummer und Hinweis ohne Artikelstamm; keine Lagerbewegung
Tastenkürzel	Alt + Buchstabe nach PHP-Belegung, Hilfe im Formular, Schutz bei Unterdialogen und laufenden/unklaren Speicheranfragen
Nachhaltigkeitsdaten	Bei Nacherfassung automatische CO₂e-Berechnung oder geprüfte manuelle Kilometer-/CO₂e-Werte; Vorschau und Bestandsspeicherung
Niederlassungsübergreifende Erfassung	Auswahl freigegebener Niederlassungen desselben Mandanten; Erfassungsdaten/Preisprüfung/Speicherung im Zielbereich, unveränderte Sitzung
Eingabeschutz	Bestätigung beim Schließen/Ersetzen ungespeicherter Eingaben; Browser-Neuladeschutz; keine dauerhafte Speicherung der Entwürfe im Browser

Preisbedingungen können gemäß cs_jbcond von der Abholkostenstelle stammen. Der Rechnungszahler bleibt separat. Fehlende Tarife werden als Fehler ausgewiesen. Servicezuschläge nach Straße, kundenspezifische Unvollständigkeits-/Referenzregeln und die rückwirkende Kurierprovision werden berücksichtigt. Historische, im PHP-Code fest hinterlegte Kundenzuschläge wurden in legacy-markup-history.json übernommen; Änderungen dieser PHP-Liste müssen auch hier nachvollzogen werden.

Quellen: aktuelle Dateien unter /data/0/votian-test/html auf 172.16.0.158, insbesondere jobs/job_options.php, jobs/get_saved_tour.php, jobs/job_edit.68.20.js, include/services_func.inc.php, include/ajaxReqKmPrice.php, include/ajaxReqJob.php, locating/xServer.inc.php, include/pnpoly.inc.php, include/caglobal.inc.php, include/global.inc.php und admin/cs_csc_list.php. Der alte lokale PHP-Ordner ist keine Referenz mehr.

Die Richtungsbits sind gemäß aktivem PHP-Speicher- und Ladepfad 0=weder noch, 2=Abholung, 1=Zustellung, 3=beides. Der alte Rechnungstext-Helfer beschriftet 1/2 umgekehrt. Der neue Leseadapter und die Erfassung verwenden konsistent den Speicherpfad; PHP selbst wurde nicht korrigiert.

API und Berechtigungen

GET /api/orders/entry/options, /cost-centers?q=, /cost-centers/{id}/addresses, /cost-centers/{id}/photo-workflows und /vehicles?q= liefern Erfassungsdaten. Alle benötigen Recht 7 und begrenzen Kostenstellen/Fahrzeuge auf die gewählte Erfassungsniederlassung. Stammdaten-Leserechte 0/1 sind dafür nicht erforderlich. Die Suchergebnisse sind auf 50 beschränkt.

POST /api/orders/quote validiert Eingaben und berechnet den Preis ausschließlich lesend. POST /api/orders ermittelt externe Routendaten und Fotooptionen vor der Schreibtransaktion und rechnet Tarife innerhalb der Schreibtransaktion erneut und verlangt denselben quoteFingerprint. Abweichungen liefern 409. Das Formular verwirft die Vorschau bei jeder Eingabeänderung.

GET /api/orders/entry/articles?q= sucht freigegebene Artikel der eigenen Niederlassung; /stocks?payerId=…&articleId=…&q= liefert zugängliche Lagerorte samt Artikelbestand und benötigt zusätzlich Recht 14. /features liefert den konfigurierten Kartenendpunkt und die Lagerberechtigung. Die nur lesenden POSTs /map/locate und /map/address zentrieren die Karte beziehungsweise lösen einen gewählten Punkt auf.

Alle POSTs benötigen Sitzung und CSRF-Token. Manuelle Frachtvergütung und Kurier-Unteraufträge benötigen Recht 38, eine ausdrücklich bestätigte Überschreitung von JB_CR_PRICE_BLOCK Recht 39. HQ, Bearbeiter, Status und berechnete Summen kommen ausschließlich vom Server. Unbekannte JSON-Felder werden abgewiesen. createOrders ist unabhängig von dem weiterhin deaktivierten writeOrders für Bestandsänderungen.

Speicherung und Betrieb

Job, Stationen, Adressen, tourservice, jobprice, Bestandssemaphoren und Audit-Outbox werden gemeinsam gespeichert. Vor dem Schreiben werden die beteiligten Tabellen auf InnoDB geprüft. Ein Fehler rollt die fachliche Transaktion zurück. Keine DDL-Anweisungen, Schemaänderungen, Seed-Daten oder separaten Datenbanken.

Eine UUID pro Erfassungsdialog wird unter ng_order_request in der bestehenden Semaphortabelle abgelegt. Eine Sperre auf dem Benutzer serialisiert parallele Wiederholungen. Identische Wiederholung liefert denselben Auftrag (200 statt 201); andere Nutzdaten mit derselben UUID liefern 409. Bei unklarer Netzwerkantwort hält die Oberfläche die ursprüngliche Anfrage fest und bietet „Speicherstatus prüfen“ an.

phoenix_log.log ist im geprüften Bestand MyISAM. Deshalb wird das Protokoll erst nach erfolgreichem Commit veröffentlicht. Eine transaktionale Outbox in genericdatacontainer hält ausstehende Ereignisse fest. Ein Hintergrundlauf versucht sie nach einer Minute und anschließend alle 30 Sekunden erneut; eine stabile Ereigniskennung verhindert doppelte Logeinträge auch nach Teilfehlern. Die Bestands-Protokolltabelle muss INSERT erlauben. Die Erfassung benötigt zusätzlich INSERT in die genannten Tabellen und UPDATE auf Kurierbelegung/Outbox; bei ausdrücklich ausgewählter Rechnungsmailänderung werden user.usr_inv_email und der Exportmarker company.cmp_modify_status aktualisiert. Dafür muss auch company InnoDB verwenden.

Die bestehende PHP-Verarbeitung bleibt erforderlich für Dauerauftragskopien/Feiertage, automatische Disposition und Fahrergeräte, Automailer sowie die endgültige Rechnungstextaufbereitung. Die Erfassung initialisiert die vorhandenen Semaphoren und jb_invtext_dirty. Es gibt keinen zweiten Java-Dauerauftragsscheduler. Bei der ausdrücklich ausgewählten sofortigen Serienanlage werden die gepflegten Feiertage aus publicholiday und die elf PHP-Rhythmen verwendet. Die Vorschau bindet alle Termine und Einzelpreise; beim Speichern entstehen getrennte Vorgänger-/Nachfolgerketten pro Mehrfachserie (jb_id_copy, jb_id_copy_permanent). Die sofortige Anlage ist auf zwei Jahre, 500 Aufträge und 10.000 Stationen pro Anfrage begrenzt. Ohne diese Auswahl bleibt die Fortführung beim bestehenden Dienst. Aufträge können durch diese Bestandsdienste nach dem Speichern weiterverarbeitet werden.

Kostensplit, Unternehmerverrechnung und Lager

Der Kostensplit ist bei direkt abgerechneten Rechnungsaufträgen verfügbar. Teilnehmer sind die unterschiedlichen internen Stationskostenstellen und der ausgewählte Rechnungszahler; mindestens zwei sind erforderlich. Die Preisgrundlage bleibt der ausgewählte Zahler beziehungsweise die bestehende Abholkondition. Jede rabattierte Preiskomponente und Maut werden gleich verteilt; Restcents gehen in stabiler Kostenstellenreihenfolge an die ersten Empfänger. Die Vorschau weist Netto, Maut, Steuer und Brutto je Empfänger aus. Die Speicherung setzt jb_payment=1, schreibt die verteilten Nettokomponenten in tourservice mit Rabatt 0 (bereits eingerechnet) und den Beleg unter ng_cost_split.

Kurier-Unteraufträge folgen saveJobChildren aus caglobal.inc.php: nur Nacherfassungen im Inland mit ausführendem Fahrzeug, keine Sammelabrechnung oder Fernverkehr. Die Verrechnungsbeträge werden mit Kundenzuschlag, optionalem INV_CHILDREN_DISCOUNT, Servicepreis je Unternehmer und gegebenenfalls MASK_CHILDREN_TAX_HARDCODED berechnet. Die Summe darf den Kundenpreis vor Zuschlag ohne Servicepreis nicht überschreiten. Je Unternehmer entstehen ein positiver Unterauftrag und eine Gegenbuchung beim ausführenden Kurier; Maut wird beim ersten Paar berücksichtigt. Der Hauptauftrag erhält jb_id_parent=-1 und die summierte Frachtvergütung. Der technische Zahler kommt ausschließlich aus CSC_ID_PAYER_CALCULATOR der eigenen Niederlassung. Nur für diese serverseitig bestimmte Kostenstelle sind die im Bestand üblichen versteckten oder nicht authentifizierten Verrechnungskonten zulässig; HQ-Grenze, Sperr- und Archivprüfung gelten weiter. Manuelle Einzelvergütungen können nicht gleichzeitig verwendet werden.

Artikel werden als tourarticle mit stabiler Stationszuordnung gespeichert. Sie ändern den Transportpreis nicht. Kopien und geladene Vorlagen übernehmen Artikel und Mengen, aber keine Seriennummern oder Lagerbewegungen; diese müssen neu gewählt werden. Freie Artikelpositionen verwenden articleId=0 und freeArticle mit Bezeichnung (max. 30 Zeichen), Gesamtgewicht (3 Nachkommastellen), Packstückzahl und Artikelwert (2 Nachkommastellen). Sie werden ohne Artikelstammsatz als tourarticle.at_id=0 gespeichert und lassen keine Lagerbuchung zu. Mengen vervielfachen das eingegebene Gesamtgewicht nicht. Artikelstamm-/Lagerstammdaten werden hier nicht neu angelegt.

Lagerbewegungen benötigen Recht 14 und eine ausdrückliche Auswahl von Quelle und Ziel. Ein- und Auslagerung verwenden 0 für außerhalb des Lagers. Sichtbarkeit, Schreibschutz, Kundenbezug, Lagerhierarchie, Hauptlagerzugang (MASK_STK_ROOT_ACCESS), Unterlager (MASK_STK_SUBSTOCK_ACCESS) sowie MASK_STK_READONLY_WHERE_DEFINED_WRITEACCESS und MASK_STK_READONLY werden serverseitig geprüft. Fehlender Hauptlagerzugang sperrt die Buchung; die Administratorausnahme für Lagerbereiche umgeht keinen Leseschutz. Entzug und Lesebeschränkungen werden bei der gesperrten Buchungsprüfung erneut gelesen. Die Auswahl begrenzt erst nach der Rechteprüfung auf 50 Treffer und durchsucht dafür auch weitere interne Seiten. Die Vorgaben lassen sich unter Verwaltung → Mitarbeiter → Lagerrechte bearbeiten. Mengen werden über alle Positionen und Mehrfachkopien summiert; Seriennummern, vorhandener Bestand, Lagerplatzumrechnung und aktivierte Kapazitätsplanung werden geprüft. Vor dem Speichern werden die Lager- und Artikelzeilen gesperrt und die aktuellen Bestände erneut gelesen. stockarticle, articleitem und stockmove werden zusammen mit dem Auftrag in derselben Transaktion geändert; Seriennummern-Umlagerungen erhalten vorhandene Artikelmetadaten. Die Bewegung erfolgt sofort beim Speichern, auch bei Vorbestellungen. Angebote, Daueraufträge und die gleichzeitige Speicherung als Tourvorlage lassen keine Lagerbewegung zu. Artikelpositionen ohne Bewegung bleiben dort möglich.

Die Tabellen article, tourarticle, stock, stockarticle, stockmove und articleitem wurden im Bestand ausschließlich lesend auf Spalten und InnoDB geprüft. Nicht transaktionsfähige Tabellen führen vor dem Schreiben zum Abbruch. Es wurden keine echten Lagerbewegungen oder Verrechnungsaufträge zur Prüfung angelegt.

Foto-, Routen- und Fernverkehrsdienste

Die Fotooptionen kommen wie im aktuellen PHP über URL_CS_PHOTO_WORKFLOW/sets/kunde/{cs_id}. Freigaben werden gefiltert; ohne freigegebenes Kundenset wird /sets/kunde/0 gelesen. Der Server prüft Set und Stationsauswahl erneut vor dem Speichern. Bei Barzahlung gehört die Fotoauswahl zum tatsächlichen Kunden, auch wenn die Preisberechnung den technischen Systembarzahler verwendet. Ohne explizite Setauswahl gilt der Kundenstandard, sonst das erste Set. Innerhalb des Sets bestimmen Stationsposition und Stationsart den Standard; eine einzelne Station zählt wie in PHP als LAST. Nummer 0 ist eine gültige Workflow-Auswahl. Min-/Max-Fotoanzahl wird angezeigt; die Bildprüfung bleibt beim Fotodienst. Ein ausgefallener konfigurierter Fotodienst wird als Fehler gemeldet und nicht als „keine Fotos“ behandelt. Fehlt der Parameter vollständig, stehen keine Fotoworkflows zur Verfügung. Die abweichende PHP-Bedeutung der Stationsrichtungskennzeichen für Foto-Scope-Regeln ist im Menüabgleich dokumentiert und wird übernommen.

Nach dem Commit erfolgt zuerst POST /selection/set mit jbId, setNumber, danach das Lesen bestehender Stationsauswahlen und gegebenenfalls je Tourstation POST /selection mit jbId, trId, number. Set und Stationsauswahl stehen vorher atomar unter ng_photo_selection in genericdatacontainer. Ein Wiederholungsversuch setzt dasselbe Set erneut und liest anschließend GET /selection?jbId=..., um bestätigte Kombinationen aus tr_id und number zu überspringen beziehungsweise vom Set zurückgesetzte Abweichungen wiederherzustellen. Bis zur Übertragung werden neu zu disponierende Aufträge in Status 9 gehalten; die vorgesehene Fahrzeugfreigabe erfolgt erst nach Erfolg. Nachträgliche Bearbeiteränderungen, Storno und Statusänderungen werden dabei nicht überschrieben. Nacherfassungen bleiben erledigt. photoSyncPending in der Speicherantwort und der Hinweis in der Oberfläche kennzeichnen eine noch ausstehende Übertragung. Kurze, erneuerbare Datenbank-Leases verhindern parallele Übertragungen; während HTTP-Aufrufen werden keine Datenbanktransaktionen oder Auftragssperren gehalten. Verwaiste Leases laufen nach 45 Sekunden aus. Wiederholung erfolgt nach einer Minute und anschließend alle 30 Sekunden. Der Fotodienst bleibt für Bildanzahl, Aufnahme und Verarbeitung der eigentlichen Fotos zuständig.

Für Routing muss PZM_URL den vollständigen vorhandenen /api/pzm-Endpunkt enthalten; alternativ wird der globale Parameter URL_PZM gelesen. PZM_FALLBACK_URL kann einen zweiten Dienst angeben. GOOGLE_MAPS_API_KEY kommt aus der Umgebung oder dem gleichnamigen globalen Bestandsparameter. Im PHP-Code gespeicherte Zugangsdaten und Schlüssel werden nicht übernommen. Geokoordinaten werden zunächst aus einem zugänglichen, ausreichend aktuellen address_geo-Bestand gelesen; ansonsten dient Google-Geokodierung als Rückfall. Mehrdeutige, nur ortsgenaue oder teilweise passende Adressen werden abgewiesen. Der Geobestand wird nicht verändert. HTTP-Aufrufe haben Verbindungs-/Anfragezeitlimits, begrenzte Antwortgrößen und folgen keinen Weiterleitungen. Routen und Geokodierungen werden maximal fünf Minuten in einem begrenzten Speicher zwischengespeichert.

Die Kilometerkalkulation übernimmt km-Preis, Grundpreis, weitere Adressen, Mindestpreis und globale Frachtvergütungsabschläge. Der Kundenbasispreis wird wie in PHP auf volle Euro aufgerundet; die Vergütung bleibt centgenau. PZM verwendet PZM_MASK_ZONES, zonenweise Kilometer-/Fixpreise und An-/Abfahrt einschließlich der Rundfahrtsonderregel. Die Rundung richtet sich nach PZM_MASK_ROUND und PZM_MASK_DONT_ROUND_<cs_id>. Zuschläge und Festpreisrabatt werden anschließend auf den kalkulierten Basispreis angewendet. Die berechnete Basis wird als Bestands-Fixpreis gespeichert; der nachvollziehbare Rechenbeleg liegt unter ng_route_calculation. PHP-kompatible Kilometerparameter sowie preisneutrale tourservice-Zonendetails mit Typ z bleiben für das spätere Öffnen in der Altmaske erhalten. Eine manuell eingegebene Entfernung ersetzt keine automatische Berechnung.

Bei aktivierter Fernverkehrserkennung (LONGHAUL_ACTIVE, für automatische Kilometer-/PZM- und Auslandsrouten zusätzlich streckenbezogen) gilt LONGHAUL_KM als Grenze der mittleren Abschnittslänge. Für PZM wird zunächst die kürzeste Strecke einschließlich An-/Abfahrt bewertet. Im Fernverkehr werden weitere Niederlassungen entlang der alle zwei Kilometer betrachteten Routenpunkte anhand der vorhandenen PLZ-Polygone aus phoenix_special verglichen. BWV_ACTIVE, BWV_AUSSERHALB_TSZ, fahrzeugbezogene BWV_*-Tarife und PZM_ROUNDTRIPKM werden berücksichtigt. Ein gewählter Fernauftrag erhält jb_longhaul=1, optionalen Filter BWV, manuelle Disposition und bei Neuanlage zunächst keine Frachtvergütung. Die weitere Fernverkehrsbearbeitung bleibt beim bestehenden Dienst. ASAP speichert bei erreichter Grenze den PHP-Marker longhaul_deselected.

Bei Auslandsabholung entscheidet die kürzeste vollständige Rundfahrt (Niederlassung → alle Stationen → Niederlassung) über hq_id_dispo. Ein Fehler bei einem Kandidaten bricht den Vergleich ab, statt unvollständige Ergebnisse zu übernehmen. Auftragsinhaber und Zugriffsrechte bleiben bei der angemeldeten Niederlassung. Preisniederlassung und Dispositionsniederlassung werden separat geführt. Vorschau, Fingerprint und Rechenbeleg enthalten die Route, Fotoauswahlen und den Niederlassungsvergleich.

Die lesende Bestandsprüfung vom 12.10.2026 bestätigte PLZ-Polygone, Niederlassungskoordinaten, Foto-URL-Parameter und Fernverkehrs-/Zonenparameter. address_geo, ein lokaler Parameter URL_PZM und ein lokaler Parameter GOOGLE_MAPS_API_KEY waren dort nicht verfügbar. Daher müssen PZM-Endpunkt und Google-Schlüssel für diese Installation über die Umgebung konfiguriert werden. Ein produktiver Auftrags-/Foto-POST wurde nicht ausgeführt.

Abgleich mit der geöffneten Altmaske am 12.10.2026

Die Oberfläche unter test.sb.assecutor.de/jobs/job_edit.php wurde samt Frames gelesen und mit dem lokalen PHP verglichen. Korrigiert wurden insbesondere der falsche Adresstyp (zuvor 1/3 statt 4), der starre Steuerschlüssel, der fehlende Pflichtbesteller, der Zwei-Stationen-Zwang und der Verlust ungespeicherter Eingaben beim Schließen. Die oben ergänzten Abläufe verwenden die vorhandenen Tabellen und Parameter; echte Aufträge wurden bei dieser Prüfung nicht angelegt.

Am 13.10.2026 aufgelöst: Der aktuelle SSH-Serverstand belegt den Vertrag von tr_photo_set / photoSetChanged(). Die Set-Auswahl einschließlich Stationsregeln und Übertragung ist inzwischen umgesetzt (siehe oben). Der lokale PHP-Stand wird nicht mehr verwendet.

Dateianhänge verwenden URL_DOC_UPLOAD mit /upload?ref=…&readonly=… und den bestehenden upload-success-/delete-success-Ereignissen. Die Oberfläche prüft Absenderfenster, Origin und Session; der Server akzeptiert Dateilinks nur vom konfigurierten Upload-Origin und ordnet die Metadaten erst beim Speichern den neuen Tourstationen zu. Ein Upload gegen den echten Dienst wurde nicht ausgeführt.

Die eingebettete Karte verwendet den vorhandenen globalen Parameter URL_GEOCORDS und dessen PHP-Vertrag (lat/lng, geocords-confirmed, geocords-closed). Ereignisse werden auf Karten-Origin, Absenderfenster und gültige Koordinaten geprüft. Ein gewählter Punkt wird vor der ausdrücklichen Übernahme angezeigt; eine Änderung verwirft die Preisvorschau. Solange die Karte geöffnet ist, bleibt Speichern gesperrt. Google-Rückwärtsgeokodierung benötigt GOOGLE_MAPS_API_KEY. Ohne Schlüssel bleibt die Punktübernahme mit dem PHP-kompatiblen GPS (lat,lng)-Straßenmarker möglich; die Oberfläche weist auf manuell zu prüfende Adressfelder hin. Koordinatenmarker werden bei der weiteren Routenberechnung direkt ausgewertet. Die aktive Belegung aus job_accesskeys.inc.php ist als Alt + Buchstabe im Formular verfügbar; die auskommentierten PHP-Kürzel B/T wurden nicht als aktive Bestandsfunktionen übernommen.

Grenzen dieser Umsetzung

• Änderungen an Bestandsaufträgen, Storno einschließlich seiner Gegenbuchungen und Rechnungserzeugung bleiben PHP-Funktionen. Die hier beschriebenen Verrechnungsunteraufträge sind Teil der Neuanlage. Lagerstammdatenpflege, Scanner- und nachträgliche Lagerprozesse bleiben im Bestand.
• Kundenspezifische Zusatzprozesse außerhalb der Fotoworkflows bleiben PHP-Funktionen. PLZ-/Gebietsmatrizen bleiben auf deutsche Strecken begrenzt; Auslandsstrecken verwenden Kilometer, PZM oder Festpreis.
• Niederlassungsübergreifende Erfassung ist umgesetzt; die allgemeinen Listen bleiben auf den ursprünglichen Bereich begrenzt. Kunden-/Kurierportale bleiben außerhalb dieser Erfassung. Die weitere Vermittlung und die Zustellung an Fahrergeräte übernehmen weiterhin die Bestandsdienste.
• Eine Nacherfassung setzt Annahme und Abschluss auf den angegebenen Ausführungszeitpunkt. Ohne gewählte Nachhaltigkeitsberechnung bleiben die späteren CO₂e-/Kilometerberechnungen beim Bestandsdienst; wenn der Kunde Werte benötigt, wird der Auftrag ohne Werte weiterhin unvollständig markiert.

Nachhaltigkeit, Niederlassungen und Tastatur

Nacherfassungen können sustainability.mode=AUTO oder MANUAL enthalten. Manuell werden gefahrene Kilometer und Gesamt-CO₂e in kg gemeinsam verlangt. Automatisch hat die eingegebene Entfernung Vorrang; andernfalls werden Routendaten verwendet. Gewicht und Fahrzeug-/Umweltklassen folgen tools/co2e_sendReq.php (ohne Sendungsgewicht: halbe Fahrzeugnutzlast). Die vorhandene HTTPS-API erhält den PHP-Datenvertrag mit einer numerischen Berechnungsreferenz. Referenz, Anzahl und positive Emissionswerte werden geprüft; Fehler liefern keine erfundenen Werte. Externe Aufrufe erfolgen vor der Schreibtransaktion, Quote/Speichern teilen einen begrenzten fünfminütigen Ergebnis-Cache. Geänderte Fahrzeug-/Berechnungsdaten erfordern eine neue Vorschau. Gespeichert werden jobprice.mt_sort=11/12 samt Berechnungsbeleg und wie im PHP die historische Partnerprovision unter 14. Es werden keine Nachhaltigkeits-E-Mails durch den neuen Code versendet.

GET /api/orders/entry/headquarters liefert die erlaubte Auswahl. X-Order-Headquarters gilt ausschließlich für Erfassungsendpunkte und die Neuanlage. Die Freigabe wird je Anfrage aus Mandantenzuordnung, emp_headquarters, employeerights (Recht 8, einsbasiert), Root-Administrator und eingeschränkten Callcenterrechten geprüft. Lager benötigt zusätzlich die passende Freigabe. Der Filter stellt den ursprünglichen SecurityContext nach jeder Anfrage wieder her. Beim Wechsel werden nach Rückfrage alle Entwurfsdaten und der Preis verworfen. Die Vorschau ist an die Erfassungsniederlassung gebunden; der Schreibpfad sperrt das ursprüngliche Benutzerkonto und schreibt in die gewählte Niederlassung. Andere Tabs und Listen ändern ihren Bereich nicht.

Die Tastenkürzelhilfe listet die PHP-Belegung im Erfassungsdialog. Alt+S berechnet zunächst den Preis und speichert erst mit gültiger Vorschau; Pflichtfeldprüfung gilt weiterhin. Alt+L/R fragen vor dem Leeren der Stationsdaten nach. Alt+X/Y wechseln die fokussierte Station, Alt+Z vertauscht die aktuelle mit der nächsten Station unter Erhalt der Artikel- und Kassierzuordnung. AltGr, gedrückte Wiederholung, IME, Unterdialoge und gesperrte Speicherung lösen keine Kürzel aus.

Lokale Dienstzugänge

Der Launcher liest .env über scripts/env_config.py ohne Shellauswertung; Prozessvariablen haben Vorrang. application.yml liest CO2_URL, CO2_USERNAME, CO2_PASSWORD, PZM_URL, PZM_FALLBACK_URL und GOOGLE_MAPS_API_KEY. Auf ausdrücklichen Auftrag wurden die aktiven CO₂e-Zugangsdaten und der PZM-Endpunkt aus dem PHP in die ignorierte lokale .env übernommen; vorhandene befüllte Werte blieben erhalten, Dateimodus 0600. Die alternative PZM-Konstante ist im PHP leer.

Der aktive Google-Schlüssel wird aus der separaten PHP-Parameterdatenbank geladen. Mit den am 13. Oktober bereitgestellten Zugangsdaten für 172.16.0.111:3711/phoenix wurde er erfolgreich gelesen und als GOOGLE_MAPS_API_KEY in der lokalen .env gespeichert. Der Zugang zur Parameterquelle liegt getrennt unter PARAM_DB_URL, PARAM_DB_USER und PARAM_DB_PASSWORD; die Hauptdatenbankverbindung bleibt eigenständig. Der einmalige Import verwendete wegen mysql_old_password einen isolierten kompatiblen JDBC-Treiber. Die alte Parameterquelle unterstützt keine serverseitigen READ-ONLY-Transaktionen; im Import wurde ausschließlich der feste, durch DatabaseService geprüfte SELECT ausgeführt. Treiber und erzwungene Lesetransaktionen der laufenden Anwendung wurden nicht verändert. Der laufende Server liest den übernommenen Schlüssel direkt aus der Umgebung.

Ein HTTPS-Geokodierungsaufruf für die öffentliche Beispieladresse Brandenburger Tor, Berlin, lieferte OK mit einem Ergebnis. Das bestätigt Schlüssel und Geocoding-Freigabe; ein vollständiger Auftrags-/PZM-Durchlauf ist damit weiterhin nicht abgenommen. Keine Zugangsdaten gehören in Git oder Logausgaben.

Verifikation

Aktueller Erweiterungslauf: 208 Backend-Tests, davon 205 bestanden und 3 optionale Live-Tests übersprungen, keine Fehler. Frontend-Build erfolgreich. Neue Tests prüfen freie Artikel/Vorlagen, Eingabegrenzen, Kilometer/CO₂e/Partnerprovision, API-Vertrag/Cache/Fehler, Niederlassungsrechte, Kontextwiederherstellung, ursprüngliche Kontosperre und an die Niederlassung gebundene Vorschau. Im Browser mit isolierten Antworten geprüft: freie Artikel, manuelle Nachhaltigkeitsvorschau, Alt+E/G/S/L, Schutz im Unterdialog und Niederlassungswechsel mit verworfenem Entwurf. Sieben benötigte Rechte-/Fahrzeugspalten und die Freigaben des Zentralenkontos wurden mit echten SELECTs bestätigt; keine Auftrags- oder Lagerbuchung erzeugt. Kein erfolgreicher Live-CO₂e-/PZM-Durchlauf behauptet.

Vorheriger Stand:

Erweiterungslauf 12.10.2026: Frontend-Produktionsbuild erfolgreich; Maven-Testlauf mit 193 Tests, davon 190 erfolgreich und 3 vorhandene Integrationstests übersprungen, keine Fehler. Die übersprungenen Tests erfordern einen gesonderten Bestandsdatenbank-Zugang. git diff --check ohne Befund.

Zusätzliche Tests prüfen die centgenaue Kostenverteilung, Unteraufträge/Gegenbuchungen samt wiederholbarer Neuanlage, den eng begrenzten technischen Verrechnungszahler, Mengen-/Kapazitätsprüfung über mehrere Positionen und Kopien, aktuelle Lagerbestände nach Sperren, Seriennummernerhalt, Lagerrechte, Rollback sowie Kartenkoordinaten, Rückwärtsgeokodierung und API-Rechte.

Automatisierte Backend-Prüfungen decken Foto-Standard-/Stationsauswahl, wiederholbare Übertragung und Dispositionssperre, Auslands-Rundfahrten, Kilometer-/Zonentarife, Fernverkehrs-/ASAP-Grenzen, externe Fehlerfälle und HTTP-Verträge sowie Preis-/Rabattregeln, Statuszweige, Reservierungen, Daueraufträge, Barzahler, Nacherfassung, Pflichtfilter, Preisänderungen, Rechte/CSRF, Idempotenz, Transaktionsrollback und MyISAM-Protokollwiederholung ab. Diese Tests verwenden gemockte Datenzugriffe und erzeugen keine Testdatenbank.

Die vorhandene Playwright-Suite wurde an Pflichtbesteller und neue Lookup-Endpunkte angepasst; sie wurde bei diesem Erweiterungslauf nicht über die CLI ausgeführt. Die ergänzte Oberfläche wurde stattdessen über die Browsersteuerung im Codex-In-App-Browser mit isolierten lokalen API-Antworten geprüft (Steuervorbelegung, Pflichtreferenz, Einzelstation, mehrzeilige Hinweise, Rechnungs-PLZ, Leistungspositionen, Mehrfachvorschau und Abbruchschutz). Im aktuellen Lauf zusätzlich geprüft: Kostensplit, Unternehmerauswahl, Seriennummernartikel mit Umlagerung, die drei Vorschautabellen, stabile Artikelzuordnung nach Stationswechsel sowie gültige/ungültige Kartenpunkte und die Übernahme in die Station. Speichern war am lokalen Fixture-Server gesperrt. Backend-Tests prüfen zusätzlich die tatsächliche Berechnungs- und Speicherlogik mit gemocktem DatabaseService. Der gestartete Backend-Testprozess erhält ausdrücklich eine nicht erreichbare Datenbankadresse. Echte Schema- und Lookup-Abfragen wurden separat ausschließlich lesend geprüft. Eine reale Neuanlage samt Verarbeitung durch PHP, Fahrergerät und Abrechnung wurde nicht gegen den produktiven Bestand ausgeführt. Diese fachliche Abnahme ist noch erforderlich; erfolgreiche Unit-/Browserprüfungen ersetzen sie nicht.

Bestehende Aufträge neu kalkulieren – 13. Oktober 2026

Unter „Bearbeiten / Aktionen“ ist eine Preisvorschau mit anschließender Übernahme verfügbar. Berechnet werden die gespeicherten Stationen zur vorhandenen Auftragszeit; angeboten werden Tarif-, Kilometer-/PZM-, Fest- und Leistungspreise sowie Kostensplit. Aufträge mit bereits verbundenen Unternehmeraufträgen oder vorhandenen Einnahmen sind noch nicht für diese Nachkalkulation freigegeben. Die Vorschau enthält Alt-/Neupreise, Bestandteile und gegebenenfalls Verteilung. Rechte, Versionen und Frachtvergütungsgrenzen werden beim Speichern erneut geprüft; ein wiederholter Speicheraufruf erzeugt keine zusätzliche Buchung. Lagerbewegungen, Fahrerstatus, Fotos und Quittungen werden nicht wiederholt. Unabhängige Unfertig-Gründe werden durch die Neukalkulation nicht aufgehoben.

Neue Aufträge erhalten den Wert und Text der Zahlungsbedingung als separaten Snapshot in genericdatacontainer; jobprice.mt_sort=16 bleibt für vorhandene Kilometerpositionen unangetastet. Abrechnung und CSV lesen vorrangig diesen Snapshot, bei Altaufträgen die vorhandene PHP-Zahlungsbedingung. Fehlt ein historischer Wert, wird keiner aus dem aktuellen Kundenstamm erfunden.