Erweitere Workflows und Statusmails und bereinige Stadtbote-Tasks

Übernehme die PHP-Fachanpassungen für Foto-Workflows, Mail-Empfänger, Fahrzeugdaten, Nachbearbeitung und PZM-Festpreise.

Beschränke Cron-Funktionen auf Stadtbote, verbessere Java-Typsicherheit und Nullbehandlung und aktualisiere Tests und Dokumentation.

Erhöhe die Backend-Version auf 0.2.1 und passe Maven-Ressourcen sowie VS-Code-Projekteinstellungen an.

docs/CRON-MIGRATION.md

@@ -1,235 +1,136 @@
-# PHP-Crontab → Spring Boot
+# PHP-Crontab → Stadtbote-Spring-Tasks
 
-Stand: 27.10.2026. Grundlage sind die am 26.10.2026 per SSH gelesenen Dateien
-unter `172.16.0.158:/data/0/votian-test/html` sowie ergänzend
-`/data/0/votian-test-2/html`. Der Zeitplan stammt aus
-`sysadmin/votian_admin/crontab_20211207.sav`. Der Betreiber hat diese Crontab
-als aktuell bestätigt und angekündigt, auf dem Testsystem keine PHP-Cronjobs
-mehr auszuführen. Der frühere lokale PHP-Bestand wurde nicht verwendet.
+Stand: 27.10.2026. Grundlage der Zeitpläne ist die vom Betreiber bestätigte
+`sysadmin/votian_admin/crontab_20211207.sav`. Die Geschäftsregeln wurden mit
+den aktuellen Serverquellen unter `172.16.0.158:/data/0/votian-test/html`
+abgeglichen. Der frühere lokale PHP-Bestand wurde nicht verwendet.
 
-## Native Implementierung
+## Verbleibender Stadtbote-Umfang
 
 | PHP-Aufruf | NG-Gruppe | Termin Europe/Berlin | Verhalten |
 |---|---|---|---|
 | `do_auto_logout_by_autorevokes` | `courier-logout` | Jede halbe Stunde | NL 3, mindestens zwei automatische Entzüge in 30 Minuten, keine Annahme/Ablehnung, numerische Standort-PLZ; Belegungsprüfung, `LOGOUT`, PDA-Kommando mit 16 Stunden Gültigkeit, Audit 143. |
 | `do_cron_STB_MAILS` | `stb-compliance` | Mo–Fr 04:00 | 78 getrennte Tasks: 1710, 1623, 1717–1720, 1629 für NL 1–11; 1715 nur NL 8. Datumswarnungen und PBSG/COV/FZ/GDP/BMS-Filterpflege. |
-| `do_cron_export_SB` | `sb-master-export` | Täglich 20:45 | 30 Tasks: Debitoren, Kreditoren, Fahrzeuge für NL 1–9 und 11. Originale Benutzer, RETRANS-Profile, Nummern und Dateinamen. Dauerhafte Dateispeicherung, Änderungskennzeichen, FTP-Übergabe über die vorhandenen nativen Exportdienste. |
-| `do_cron_special_HHA` | `hha-safebags` | Täglich 09:40 | Safebags Artikel 4285, Kennzeichen 28=1, mindestens sieben Tage alt; HTML-Bericht bei Treffern. |
-| `mysql_status.php` | `mysql-status` | Alle fünf Minuten | Zähler der konfigurierten Anwendungsdatenbank, Gesamtraten und Intervallraten; persistente Historie für 62 Tage, monatlicher CSV-Download. |
-| `do_bzip2.php` | `file-maintenance` | Täglich 00:01 | Native bzip2-Kompression der älteren `mps2-bin.0*`-Dateien und der Logdateien des Vormonats; Löschung regulärer Dateien aus expliziten temporären Verzeichnissen. |
-| `do_cron_monitor_replication` | `replication-monitor` | Alle 15 Minuten | Fachliche Zählervergleiche mit PHP-Toleranzen: STB 4, HTG/HTM/HTM_OLD/HHA 2, INT 7, MUH 1. Alarm bei Rückstand oder Nichterreichbarkeit. |
-| `do_cron_soap_1` | `hha-soap-master` | Täglich 05:10 | PTnova-Gerätestammdaten und Betriebsmeldungen; neue Serviceunits, Objektlager und Container-Lagerbestände. |
-| `do_cron_soap_0` | `hha-soap-status` | Täglich 05:20 | PTnova-Gerätestatus, offene Betriebsmeldungen, Geld- und Kartenbestände, Tageshistorie um 03:00. |
+| `do_cron_export_SB` | `sb-master-export` | Täglich 20:45 | 30 Tasks: Debitoren, Kreditoren, Fahrzeuge für NL 1–9 und 11. Originale Benutzer, RETRANS-Profile, Nummern und Dateinamen; Dateispeicherung, Änderungskennzeichen und FTP-Übergabe. |
+| `mysql_status.php` | `mysql-status` | Alle fünf Minuten | Zähler der konfigurierten Anwendungsdatenbank, Gesamt-/Intervallraten, 62 Tage Historie, monatlicher CSV-Download. |
+| `do_cron_monitor_replication` · STB | `replication-monitor` | Alle 15 Minuten | Vergleich erledigter Stadtbote-Aufträge; Alarm bei mehr als vier fehlenden Aufträgen oder Nichterreichbarkeit. |
 
-Damit sind alle neun weiterhin benötigten PHP-Cron-Aufrufe als
-115 einzeln protokollierte Spring-Tasks implementiert. Die zwei weiteren Aufrufe
-der bestätigten Crontab entfallen gemäß Betreiberentscheidung vom 27.10.2026.
-Kein Task startet PHP, Shell-Kommandos
-oder eine alte HTTP-Oberfläche. Die getrennt vorhandenen sechs NG-Dauerdienste
-(Auftragsabschluss, Daueraufträge, Statusmail, Angebote, Angebotsentzug,
-BWV-Retouren) behalten ihre bisherigen Konfigurationsschalter.
+Das sind **111 einzeln protokollierte Tasks in fünf Gruppen**. Die sechs
+separaten NG-Dauerdienste (Auftragsabschluss, Daueraufträge, Statusmail,
+Angebote, Angebotsentzug, BWV-Retouren) behalten ihre bisherigen Schalter.
+Allgemeine Lager-, Artikel-, Kundenportal- und Abrechnungsfunktionen bleiben erhalten.
 
-## Bewusst entfallene HHA-Aufrufe
+## Entfernte Funktionen
 
-Der Betreiber hat am 27.10.2026 bestätigt, dass diese beiden Funktionen keine
-Rolle mehr spielen und in NG entfallen dürfen:
+Auf Betreiberwunsch wurden am 27.10.2026 vollständig aus der neuen Anwendung
+entfernt: HHA-Safebag-Berichte, beide PTnova-SOAP-Importe, Replikationsprüfungen
+für HTG/HTM/HTM_OLD/HHA/INT/MUH sowie Kompression und Bereinigung der alten
+PHP-/mps2-Serverdateien. Dazu gehören Implementierungen, Zeitpläne,
+Konfigurationsfelder und ausschließlich dafür benötigte Abhängigkeiten.
+Die zwei schon zuvor verworfenen HHA-Aufrufe für Disposition und Export
+bleiben ebenfalls ausgeschlossen. Diese Punkte sind keine offenen Migrationen.
 
-* 02:15 `do_cron_vht_dispo_days_HHA` → `include/cron_vht_dispo_days_HHA.php`.
-* 04:30 `do_cron_export_HHA` → `export/export_illt_MC.php`, Modi 101/102/103.
+Entfernte Gruppen können nicht mehr über `SPRING_TASK_GROUPS` aktiviert werden;
+eine solche veraltete Gruppenauswahl verhindert den Start mit einer Fehlermeldung.
+Die Replikationskonfiguration akzeptiert ausschließlich den Schlüssel `STB`.
+Fremde Gruppen werden vor Datenbankzugriff oder Alarmversand abgewiesen.
+Bereits vorhandene Daten und historische Laufbelege werden nicht gelöscht.
 
-Sie sind keine offenen Migrationspunkte mehr und erscheinen nicht mehr als
-fehlende Funktionen im Betriebsstatus. Für diese Aufrufe werden keine NG-Tasks
-registriert. Die Entscheidung betrifft nur diese beiden Aufrufe; die beiden
-PTnova-SOAP-Importe und die HHA-Safebag-Prüfung bleiben enthalten.
-Die Implementierung der weiterhin benötigten PHP-Cron-Aufrufe ist damit
-vollständig. Das Docker-Image aktiviert die Tasks künftig beim Start; Produktionskonfiguration und Bereitstellung auf dem Zielserver stehen noch aus.
+## Docker-Betrieb ohne Cron
 
-## Grundlage der SOAP-Übernahme und Abgrenzung
+Das Image setzt `SPRING_TASK_GROUPS` auf die fünf Stadtbote-Gruppen und plant
+beim Start 111 Aufgaben im Spring-`ThreadPoolTaskScheduler` ein. Der
+Hauptprozess ist `java -jar /app/app.jar`; es werden kein Cron-Daemon,
+keine Crontab, kein PHP und keine Shell-Wrapper für die Aufgaben verwendet.
+Die Cron-Ausdrücke sind lediglich das Zeitplanformat innerhalb von Spring Boot.
 
-Die beiden SOAP-Modi wurden anhand von
-`/data/0/votian-test-2/html/sysadmin/soap/soap.php` und dessen aktiven
-Datenbankpfaden portiert (SHA256
-`b4e8580d63c1f2545870ca596dfca820adc452879af05b709b2e4578dc5fb407`).
-Die Wrapper nennen zwei frühere Instanzen unter `/home/mps2/hha` und
-`/home/mps2/hha_test`. Eine NG-Instanz verarbeitet ihre konfigurierte Datenbank
-und SAP-Umgebung; es erfolgt kein zusätzlicher automatischer Produktionslauf.
+Die Image-Vorgabe lässt sich überschreiben:
 
-`ping`, `certbot`, `/sbin/handle_log` und der aktive Shell-Wrapper `do_rsync`
-sind Betriebssystemaufgaben, keine PHP-Cronjobs. Sie werden durch diese Änderung
-nicht übernommen oder abgeschaltet. Der auskommentierte `do_rsync.php` und
-andere nicht aktive Skriptvarianten werden ebenfalls nicht aktiviert.
+* `-e SPRING_TASK_GROUPS=mysql-status`: ausschließlich Datenbankdiagnose.
+* `-e SPRING_TASK_GROUPS=`: alle fünf zeitgesteuerten Gruppen deaktivieren.
+* Eine kommagetrennte Auswahl aktiviert nur die genannten Gruppen.
 
-## Konfiguration und Inbetriebnahme
+`SPRING_TASK_GROUPS` hat Vorrang vor `LEGACY_CRON_JOBS`. Ein leerer alter
+`LEGACY_CRON_JOBS`-Eintrag in einer `.env` schaltet die Image-Vorgabe nicht ab.
+Beim direkten Java-Start ohne `SPRING_TASK_GROUPS` gilt der bisherige Fallback
+`LEGACY_CRON_JOBS`, standardmäßig leer.
 
-Das Docker-Image setzt `SPRING_TASK_GROUPS` auf alle neun Gruppen und plant
-beim Start 115 Tasks direkt im Spring-`ThreadPoolTaskScheduler` ein.
-Der Container startet ausschließlich `java -jar /app/app.jar` als Hauptprozess.
-Es werden weder Cron-Daemon noch Crontab, PHP-Prozesse oder Shell-Wrapper
-für diese Aufgaben benötigt. Die Cron-Ausdrücke sind nur das Zeitplanformat
-innerhalb von Spring Boot.
-
-`SPRING_TASK_GROUPS` kann als Container-Umgebungsvariable mit einer
-kommagetrennten Auswahl überschrieben werden. Beispiel für ausschließlich
-Diagnose: `-e SPRING_TASK_GROUPS=mysql-status`. Ein ausdrücklich leerer Wert
-(`-e SPRING_TASK_GROUPS=`) deaktiviert alle neun Gruppen.
-Die Variable hat Vorrang vor dem bisherigen `LEGACY_CRON_JOBS`; dessen leerer
-Eintrag in einer bestehenden `.env` deaktiviert die Image-Vorgabe deshalb nicht.
-Beim direkten Java-Start ohne `SPRING_TASK_GROUPS` gilt weiterhin
-`LEGACY_CRON_JOBS` (standardmäßig leer). Die sechs gesonderten NG-Dauerdienste
-behalten ihre bisherigen eigenen Schalter.
-
-Die Vorlage `.env.example` enthält die Produktionsparameter. Ohne passende
-SAP-Zugänge, SMTP-Konfiguration, Exportprofile, Replikationsziele oder
-Dateimounts können die betreffenden Tasks nicht erfolgreich arbeiten und
-melden die fehlenden Voraussetzungen im Betriebsstatus. Eine eingeplante
-Aufgabe ist noch kein Nachweis einer erfolgreichen fachlichen Ausführung.
-Der Startlog nennt Anzahl und Gruppen der tatsächlich eingeplanten Aufgaben.
+Startlogs nennen Anzahl und Gruppen der tatsächlich eingeplanten Aufgaben.
 Beim Herunterfahren werden noch nicht fällige Aufgaben verworfen; laufende
-Aufgaben erhalten bis zu 30 Sekunden zum Abschluss. Für Docker deshalb
-`--stop-timeout 40` setzen. Unterbrochene Läufe behalten ihren dauerhaften Beleg.
-
-Die Aktivierung ist für den späteren Docker-Betrieb vorbereitet. Es wurde
-keine Produktionsinstanz gestartet und keine vorhandene lokale `.env`
-verändert. Echte Empfänger, FTP-/SAP-Endstellen und Bestandsverzeichnisse
-wurden nicht für Funktionstests verwendet.
-
-* **STB:** SMTP muss eingerichtet sein; Empfänger werden aus
-  `MAIL_CRON_106_TO_ADDRESS` bzw. für EG-Lizenz aus `MAIL_CRON_102_TO_ADDRESS`
-  gelesen (NL, dann global). Absender ist `SMTP_FROM`. Die in PHP hart
-  codierten Entwickler-Fallbacks und Bcc-Adressen werden nicht übernommen.
-* **HHA-Safebags:** `LEGACY_CRON_HHA_MAIL_TO` und optional
-  `LEGACY_CRON_HHA_MAIL_BCC` explizit setzen. Absender aus NL-Parameter
-  `MAIL_SENDER_ADDRESS`, sonst `SMTP_FROM`.
-* **Export:** Bestehende Exportablage, FTP-Parameter, Exportkonten und Rechte
-  müssen verfügbar sein. Fehlende Profile oder Felddefinitionen sperren den
-  jeweiligen Task. NL 90 bleibt wie im PHP-Quelltext auskommentiert.
-* **PTnova/SOAP:** `LEGACY_CRON_SOAP_URL`, `_USER`, `_PASSWORD` für den
-  zu dieser Instanz gehörenden SAP-Endpunkt setzen. HTTPS-Zertifikate werden
-  geprüft, Weiterleitungen nicht verfolgt; fünf Minuten Gesamtzeit und 32 MiB
-  Antwortgröße begrenzen den Abruf. `_HEADQUARTERS` ist standardmäßig 1,
-  `_CONTAINER_STOCK` 1000 wie in PHP. Der Betriebsdatenbankbenutzer braucht
-  Zugriff auf `articleitemhistory` im konfigurierten `HISTORY_DB_SCHEMA` sowie
-  die Bestands-, Artikel-, Parameter- und Laufbelegtabellen. SAP-Zugänge bleiben
-  außerhalb des Quellcodes. Die beiden Gruppen getrennt aktivieren.
-* **Replikation:** `LEGACY_CRON_REPLICATION_TARGETS` ist ein JSON-Objekt,
-  z. B. `{"STB":["primary.example:3391","replica.example:3391"]}`.
-  Erster Eintrag ist der Primärserver. Zugänge ausschließlich über
-  `LEGACY_CRON_REPLICATION_USER` / `_PASSWORD`, Alarmempfänger über `_MAIL_TO`.
-  Kein automatischer Zugriff auf die fest codierten Produktionsserver aus PHP.
-  TT ist im aktuellen PHP deaktiviert und wird nicht registriert.
-* **Dateiwartung:** Die drei `LEGACY_CRON_*_DIRECTORIES`-Variablen nennen
-  ausschließlich hierfür eingebundene Altverzeichnisse. Temporäre Verzeichnisse
-  werden vollständig von regulären Dateien geleert, wie im PHP-Aufruf.
-  Keine NG-Dokument- oder Exportablage eintragen. Verzeichnisse dürfen sich
-  nicht überlappen; Symlinks werden nicht verfolgt. Die neueste Binlogdatei
-  (einschließlich Gleichständen) und aktuelle Monatslogs bleiben erhalten.
-  Vor dem Entfernen einer Quelle wird das Archiv sicher veröffentlicht;
-  vorhandene abweichende Archive werden nicht überschrieben.
-* **MySQL-Status:** Verwendet `DB_URL` statt PHPs festem lokalen Port 3391.
-  Originale Zähler und abgeleitete Raten sind als CSV unter
-  `/api/administration/cron/database-status?month=2026-10` abrufbar.
-  Nach Serverneustart oder bei fehlender Vorgängermessung bleiben
-  Intervallraten leer. Werte liegen in `genericdatacontainer` statt unter `/root`.
-
-Cron-Ausdrücke lassen sich pro Gruppe über die in `.env.example` genannten
-Variablen überschreiben. Sie haben sechs Felder inklusive Sekunden.
+Aufgaben erhalten bis zu 30 Sekunden zum Abschluss. Für Docker
+`--stop-timeout 40` setzen. Verpasste Termine werden nicht nachgeholt.
 `Europe/Berlin` gilt unabhängig von der JVM-/Container-Zeitzone.
-Verpasste Termine während eines Stillstands werden nicht nachgeholt.
+
+## Produktionskonfiguration
+
+Die Vorlage `.env.example` enthält die benötigten Einstellungen. Eine
+Einplanung bestätigt noch keine erfolgreiche fachliche Ausführung. Fehlende
+Voraussetzungen erscheinen beim Lauf im Betriebsstatus.
+
+* **STB-Berichte:** SMTP und `SMTP_FROM` einrichten. Empfänger kommen aus
+  `MAIL_CRON_106_TO_ADDRESS`, für EG-Lizenz aus `MAIL_CRON_102_TO_ADDRESS`
+  (NL, dann global). Entwickler-Fallbacks und feste PHP-Bcc-Adressen werden
+  nicht übernommen.
+* **SB-Exporte:** Exportablage, FTP-Parameter, Konten, Rechte, RETRANS-Profile
+  und Felddefinitionen müssen vorhanden sein. Fehlende Voraussetzungen sperren
+  den betreffenden Task. NL 90 bleibt wie in PHP ausgeschlossen.
+* **STB-Replikation:** `LEGACY_CRON_REPLICATION_TARGETS` ist beispielsweise
+  `{"STB":["primary.example:3391","replica.example:3391"]}`. Der erste Eintrag
+  ist der Primärserver, weitere Einträge sind Replikate. Zugang über
+  `LEGACY_CRON_REPLICATION_USER` / `_PASSWORD`, Alarmempfänger über `_MAIL_TO`.
+  Es werden keine fest codierten Produktionsserver aus PHP übernommen.
+* **MySQL-Status:** Nutzt `DB_URL`. Daten und Raten liegen in
+  `genericdatacontainer`, nicht im Dateisystem. Download:
+  `/api/administration/cron/database-status?month=2026-10`.
+  Ohne Vorgängermessung oder nach Datenbankneustart bleiben Intervallraten leer.
+
+Die fünf Zeitpläne können über die in `.env.example` dokumentierten
+Variablen überschrieben werden; Spring erwartet sechs Felder mit Sekunden.
 
 ## Laufkontrolle und Wiederanlauf
 
-Der Betriebsstatus zeigt die Tasks, feste Termine, nächsten Lauf und Ergebnisse. Laufbelege liegen unter
-`genericdatacontainer.gdc_obj_type='ngcron'`. Der vor der Verarbeitung
-gespeicherte Beleg und eine datenbankweite Sperre verhindern doppelte
-Verarbeitung durch mehrere NG-Instanzen. Wartende Tasks behalten ihren
-ursprünglichen Termin auch bei ausgelasteten Scheduler-Threads.
+Verwaltung → Betriebsstatus zeigt nur die registrierten Stadtbote-Aufgaben,
+Termine und Ergebnisse. Belege liegen in
+`genericdatacontainer.gdc_obj_type='ngcron'`. Vor der Verarbeitung gespeicherte
+Belege und datenbankweite Sperren verhindern doppelte Verarbeitung durch
+mehrere NG-Instanzen. Wartende Aufgaben behalten ihren ursprünglichen Termin.
 
 Ein unterbrochener Lauf bleibt `RUNNING` oder `UNCERTAIN` und wird auch am
 nächsten Tag nicht automatisch wiederholt. Vor Freigabe mögliche Teilwirkungen
-prüfen (SMTP-Logs, gespeicherte Exportdatei, FTP-Eingang, PTnova-Bestände und Tageshistorie). Exportvorgänge können
-über die bestehende Datentransfer-Oberfläche unter dem jeweiligen Exportkonto
-fortgesetzt werden. Danach im Betriebsstatus „Bisherige Teilwirkungen und
-Versandprotokolle geprüft“ markieren und „Nächsten Termin freigeben“ wählen.
-Die entsprechende API lautet:
+prüfen, insbesondere SMTP-Logs, Exportdateien und FTP-Eingang. Exportvorgänge
+lassen sich im Datentransfer unter dem jeweiligen Exportkonto fortsetzen.
+Danach im Betriebsstatus „Bisherige Teilwirkungen und Versandprotokolle geprüft“
+markieren und „Nächsten Termin freigeben“ wählen.
 
-`POST /api/administration/cron/{id}/review`
+Die API `POST /api/administration/cron/{id}/review` erwartet
+`{"slot":"<slot aus Betriebsstatus>","reviewed":true}` sowie Sitzung und
+CSRF-Token. Sie prüft Mitarbeiterverwaltungsrecht, Laufversion und laufende
+Ausführung und protokolliert die Freigabe. Freigegeben wird nur der nächste
+reguläre Termin, kein sofortiger Neuversand.
 
-mit `{"slot":"<slot aus Betriebsstatus>","reviewed":true}` und gültiger
-Sitzung/CSRF-Token. Erfordert Mitarbeiterverwaltungsrecht in der ursprünglichen
-Niederlassung, prüft die Laufversion und protokolliert die Freigabe. Ein aktuell
-laufender Task lässt sich nicht freigeben. Die Freigabe erlaubt nur den nächsten
-regulären Termin, keinen sofortigen Neuversand.
+Bewusste Korrekturen gegenüber PHP: ungültige Kalenderdaten blockieren den Lauf;
+Filterupdates erhalten fremde Tokens und verwenden die richtige Kurier-ID statt
+des PHP-Tippfehlers `crvid`. Bei fehlenden PLZ-Fahrzeiten verwendet die
+Belegungsprüfung 30 Minuten. Leere Fristen ändern keine Filter. Führungszeugnis
+plus sechs Monate behält den PHP-Monatsüberlauf. Skript 1629 prüft wie im aktuellen
+PHP-Code Feld 441.
 
-Bekannte bewusste Korrekturen gegenüber PHP: ungültige Kalenderdaten blockieren
-den Lauf; Filterupdates erhalten fremde Tokens und verwenden die richtige
-Kurier-ID statt des in den PHP-Prüfskripten vorkommenden `crvid`-Tippfehlers.
-Die Belegungsprüfung verwendet bei fehlenden PLZ-Fahrzeiten 30 Minuten,
-damit ein aktiver Fahrer nicht wegen eines SQL-NULL-Ergebnisses abgemeldet wird.
-Leere Fristen verändern keine Filter. Führungszeugnisdatum plus sechs Monate
-verwendet den PHP-Monatsüberlauf. Das Skript mit Dateiname 1629 prüft im
-aktuellen Quelltext Feld **441**, was auch NG übernimmt.
+## Prüfung und Bereitstellung
 
-## PTnova-Importverhalten
+Nach Entfernung der fachfremden Funktionen wurde am 27.10.2026 ein vollständiges
+`clean verify` gegen eine isolierte MariaDB ausgeführt: 1.637 Tests bestanden,
+drei ausschließlich für eine Bestandsdatenbank vorgesehene Prüfungen ausgelassen,
+keine Fehler. Die Prüfungen umfassen Scheduler, Gruppenauswahl, Ablehnung fremder
+Replikationsgruppen und die verbliebenen Datenbankabläufe. Im neu gebauten JAR
+sind die entfernten SOAP- und Dateiwartungsklassen nicht mehr enthalten.
 
-Anfrage und SOAPAction entsprechen den SAP-Operationen `ZPtnWstpMasterdata`
-und `ZPtnWstpStatusdata`. Die Lesemarken bleiben kompatibel zu PHP:
-`genericdatacontainer`, Objekt `hq`, Feld `pt_nova`, Kontext `1` bzw. `0`.
-Abgerufen wird ab der neueren Marke aus gespeichertem Lauf und gestern 00:00.
-Die neue Marke wird erst nach gültiger Antwort und abgeschlossenen Schreibvorgängen
-auf die Startzeit des Abrufs gesetzt. Bei HTTP-/XML-Fehlern bleibt sie unverändert.
+Das daraus gebaute Docker-Image wurde ohne Netzwerk, Produktionszugänge,
+eingebundene Verzeichnisse oder veröffentlichte Ports gestartet. Das Startlog
+bestätigt 111 von 111 eingeplante Tasks in den fünf Stadtbote-Gruppen, auch bei
+leerem `LEGACY_CRON_JOBS`. Java läuft als PID 1; PHP, `cron` und `crond` sind
+nicht vorhanden. Das Herunterfahren erfolgt ohne Scheduler-Timeout. Beide
+Testcontainer wurden anschließend entfernt.
 
-Bestehende Geräte werden über die Seriennummer gefunden und im Stammdatenlauf
-nicht überschrieben. Neue Geräte erhalten wie im aktiven PHP-Code das
-Containerlager, ein Objektlager und einen erhöhten Stückbestand. Betriebsmeldungen
-werden je Artikeltyp/Code aktualisiert. Statusdaten übernehmen offene Meldungen,
-`NominalAmnt` für BEK/MEK/ZGS/RGS sowie `NominalStock` für KARTEN bei
-STU/STH/STB/STVS. Kartenbestände überschreiben Feld 09 nach der Geldübernahme.
-Karten allein erzeugen wie in PHP keine neue Tageshistorie. Unbekannte Artikeltypen
-oder Geräte werden gezählt und übersprungen.
-
-Beide Modi teilen eine datenbankweite Importsperre. Die anschließenden Schreibvorgänge
-verwenden Tabellensperren, damit auch MyISAM-Tabellen berücksichtigt sind.
-MyISAM-Änderungen sind nicht rückrollbar: Fehler während der Schreibphase markieren
-den Lauf deshalb als `UNCERTAIN`, behalten die alte Lesemarke und erfordern die
-beschriebene Prüfung. SOAP-Netzwerkzugriffe erfolgen vor den Tabellensperren.
-
-Bewusste Korrekturen: SOAP-Fehler mit HTTP 200 gelten nicht als Erfolg;
-DTD/externe XML-Entitäten sind gesperrt; auch Geräte-Stammdaten werden auf
-HHA/HDAG und die angefragten Gerätetypen begrenzt. Mehrdeutige Seriennummern,
-Artikelzuordnungen und fremde Niederlassungslager lösen einen Fehler aus.
-Die von PHP undefiniert übergebene Meldungspriorität wird bei Neuanlage mit 0
-belegt. Deaktivierte PHP-Blöcke für automatische Standortpflege und weitere
-Statusattribute werden nicht als zusätzliche Schreibaktionen aktiviert.
-
-## Prüfung
-
-Automatisierte Prüfungen decken Crontab-Zuordnung, Wochenenden/Zeitumstellung,
-dauerhafte Laufbelege, parallele Starts, unbestätigten Versand, Datums-/Filterregeln,
-Dateikompression mit Konflikten und Symlinks sowie Datenbank- und Replikationszähler
-ab. Eine isolierte MariaDB prüft die tatsächlichen SQL-Schreibpfade einschließlich
-PDA-Abmeldung, Filterpflege und der Wiederanlaufsperre. Ergänzende SOAP-Tests prüfen
-Anfragen, sichere XML-Auswertung, Größenlimit, Importwiederholungen,
-Bestands-/Historienzuordnung und einen absichtlich ausgelösten MyISAM-Teilabbruch. Echte SAP-, SMTP- und
-FTP-Endstellen sowie produktive Dateimounts sind damit nicht abgenommen.
-
-Abschlussprüfung am 26.10.2026: vollständiges `mvn verify` erfolgreich mit
-1646 Backendtests, keinen Fehlern und 3 umgebungsabhängig übersprungenen Tests.
-Die 19 gezielten Cron-/SOAP-Prüfungen einschließlich isolierter MariaDB bestanden
-ebenfalls. Die zuvor geprüfte Oberfläche ist unverändert (44 Frontendtests).
-Der ausführbare Backend-Build 0.2.0 liegt unter
-`backend/target/votian-backend-0.2.0.jar`; der Hashabgleich bestätigte denselben
-Quellstand wie beim Testlauf. Es erfolgte keine Aktivierung der Jobs im Test-
-oder Produktionsbetrieb. Die lokale MariaDB-Testinstanz wurde danach entfernt.
-
-Nach Betreiberentscheidung am 27.10.2026: offene HHA-Meldungen entfernt,
-12 bestehende Cron-Tests erfolgreich und Backend-Paket neu gebaut. Zu diesem
-Zeitpunkt waren die Jobs noch deaktiviert; die PHP-Serverdateien wurden nicht verändert.
-
-Container-Aktivierung vorbereitet und geprüft am 27.10.2026: Das Image aktiviert
-alle neun Gruppen über `SPRING_TASK_GROUPS`. 14 gezielte Tests bestanden,
-einschließlich Konfigurationsvorrang und vollständigem Scheduler-Shutdown.
-Ein lokal gebauter Container ohne Netzwerk und ohne Produktionszugänge startete
-mit Java als PID 1 und meldete „115 von 115 eingeplant“. `cron`, `crond` und
-`php` sind im Laufzeit-Image nicht vorhanden. Der Container wurde anschließend
-sauber beendet und entfernt. Das Image wurde nicht veröffentlicht und auf dem
-späteren Produktionsserver wurde keine Instanz gestartet.
+Die Produktionsbereitstellung steht weiterhin aus. Eine fachliche Ausführung
+mit Produktionsdiensten wurde nicht getestet; laufende Fremdprojekte wurden
+nicht neu gestartet.

docs/FUNKTIONSABGLEICH-2026-11-09.md

@@ -0,0 +1,117 @@
+# PHP-Serveränderungen: Abgleich und Übernahme – 9. November 2026
+
+Die sechs beim Quellcode-Abgleich festgestellten Abweichungen wurden im lokalen NG-Arbeitsbaum umgesetzt. Der PHP-Server und das bereitgestellte Image wurden nicht verändert.
+
+## Umsetzung
+
+| Befund | Umsetzung in NG |
+| --- | --- |
+| Standard-Mail-Empfänger ersetzen | Checkbox bei Auftragserfassung und in der Statusmail-Ansicht bestehender Aufträge. `996` sperrt Standardmails und Stationsmails; zusätzliche Empfänger bleiben aktiv. Beim Aufheben bleiben vorherige Versandkennzeichen erhalten. Kopien und Daueraufträge übernehmen die Auswahl. |
+| Externe Workflow-Verwaltung | Kundenbezogener, acht Stunden gültiger HMAC-SHA256-Link; eingebetteter Editor und neuer Tab. Speichermeldungen werden auf Herkunft und Fenster geprüft. Neue Kundenkopien übertragen keine alten Workflow-Einstellungen mehr. Alte REST-Schreibwege sind für neue Vorgänge geschlossen; bestehende Übertragungsbelege bleiben abgleichbar. |
+| Globaler Foto-Schalter | Nur der Parameterwert `true` aktiviert Workflows. Ansonsten gelten klassische kundenspezifische Fotoanforderungen, Sperren und allgemeine Foto-Vorgaben; gespeichert als `tr_photo`. Keine Workflow-Service-Aufrufe im klassischen Modus. Bereits wartende Übertragungen bleiben bis zur Wiederaktivierung erhalten. |
+| Tragkraft Hebemittel | `crvh_working_load_limit_lift` im Fahrzeugstamm, ganzzahlig 0–99999 kg, einschließlich Speicherung und Fahrzeugkopie. |
+| Nachbearbeitung manuell aufheben | Freigabe ohne zugeordneten Transporteur wird vor Änderungen abgewiesen, auch bei noch offenen Aufträgen. |
+| Übernommener Festpreis | Die PZM-Herkunft wird getrennt ermittelt. Manuelle Festpreise bleiben bei Änderungen erhalten; für übernommene PZM-Preise gibt es nach Neukalkulation eine ausdrückliche Beibehaltungsoption. |
+
+Für die externe Verwaltung muss `WORKFLOW_MANAGEMENT_SECRET` als Laufzeit-Secret mit demselben Schlüssel wie im Workflow-Editor gesetzt werden. `WORKFLOW_MANAGEMENT_URL` kann die vollständige Editor-URL ohne Query enthalten; andernfalls wird `/wf/workflows/index.html` am Ursprung von `LEGACY_APP_URL` verwendet. Es wurde kein Schlüssel in Quellcode oder Beispieldateien übernommen.
+
+Der Workflow-Schalter wird in NG konsistent für Auswahl, Speicherung und Wiederholungsübertragung angewendet. Im aktuellen PHP ist der Schalter in `ajaxReqJob.php` vorhanden, während `job_options.php` ihn weiterhin fest auf `true` setzt.
+
+## Ausgangsbefunde vor der Umsetzung
+
+Die folgenden Feststellungen beschreiben den Zustand **vor** der Übernahme. Die genannten PHP-Fundstellen und Bestandsnachweise bleiben die Vergleichsbasis.
+
+## Historische Befunde des Abgleichs
+
+### 1. Standard-Mail-Empfänger pro Auftrag ersetzen – hohe Priorität
+
+PHP bietet jetzt „Standard-Mailempfänger für diesen Auftrag ersetzen“. Bei eingetragener Auftrags-Mailadresse setzt das Speichern `jb_automailsent`, `jb_automailsent2` und `jb_automailsent3` auf `996`; beim Aufheben der Option werden sie gegebenenfalls wieder auf `0` gesetzt. Beim Laden wird die Auswahl wiederhergestellt. Die Standard-Automailer für Erfassung, Abholung, Erledigung und Stationsmeldungen schließen `996` aus. Der getrennte Versand an die Auftragsadresse bleibt davon unberührt.
+
+NG besitzt zusätzliche Empfänger, aber weder die Ersetzen-Option noch die Behandlung von `996`. `AutomaticOrderMailPolicy` sperrt `998`/`999`, bei Erledigung zusätzlich `997`; `AutomaticStationMail` prüft ebenfalls nur `997`/`998`/`999`. Ein in PHP entsprechend markierter Auftrag kann bei aktiver NG-Mailverarbeitung deshalb weiterhin an die ausdrücklich ersetzten Standardempfänger versendet werden, sofern die übrigen Bedingungen erfüllt sind. Ein tatsächlicher Fehlversand wurde nicht ausgelöst oder behauptet.
+
+- PHP: `jobs/job_tour.php:1098`, `jobs/job_options.php:2011`, `jobs/get_saved_tour.php:374`, `jobs/job_edit.68.20.js:457`; Ausschlüsse in `include/inc_automailer.inc.php:63`, `:153`, `:246`, `:345` und den jeweiligen Barzahler-Abfragen.
+- NG: `backend/src/main/java/de/stadtbote/votian/OrderEntryMail.java:17`, `AutomaticOrderMailPolicy.java:51`, `AutomaticStationMail.java:36`.
+- Damals offen: Auswahl, Speicherung, Wiederherstellung und Aufhebung sowie die Sperre in allen betroffenen Standardversandwegen. Zusätzliche Empfänger dürfen dabei nicht pauschal gesperrt werden.
+
+### 2. Neue externe Sets-/Workflow-Verwaltung – fehlt
+
+PHP hat am 09.11. die bisherige Bearbeitung der Foto-Set-/Flow-Freigaben im Kundenformular ersetzt. „Sets/Flows bearbeiten“ öffnet die externe Verwaltung unter `/wf/workflows/index.html` für den gewählten Kunden über einen signierten, zeitlich begrenzten Link. Dialog und neuer Tab sind vorgesehen. Die bisherigen Schreibblöcke für Fotoeinstellungen beim Anlegen und Speichern des Kunden sind auskommentiert.
+
+NG verwendet weiterhin den eigenen `CustomerPhotoSettings`-Dialog und überträgt Änderungen an `/settings/kunde/{customer}`. Der neue Einstieg und die Rückmeldung aus der externen Verwaltung fehlen. Offen ist die neue Verwaltung, nicht die Fotoauswahl insgesamt. Ob der bisherige Service-Endpunkt weiterhin unterstützt wird, wurde nicht durch einen Schreibaufruf getestet.
+
+- PHP: `admin/customer_special.php:694`, `:1235`, `:3593`, `:3636`, `:3648`, `:3678`.
+- NG: `frontend/src/CustomerPhotoSettings.tsx:12`, Einbindung in `frontend/src/BusinessForms.tsx`; `backend/src/main/java/de/stadtbote/votian/CustomerPhotoSettings.java:14` und `:122`.
+- Damals offen: neuen Einstieg samt Berechtigungs-/Signaturvertrag anbinden und bisherigen Bearbeitungsweg entsprechend ablösen. Schlüsselwerte sind nicht Bestandteil dieses Berichts.
+
+### 3. Globaler Schalter `TR_PHOTO_WORKFLOW` – wird nicht berücksichtigt
+
+Seit 05.11. liest PHP den globalen Parameter `TR_PHOTO_WORKFLOW`; nur `true` aktiviert den Set-/Workflow-Zweig. Andernfalls liefert PHP die älteren kundenbezogenen Foto-Vorgaben aus `getCsPhotoConf`.
+
+NG entscheidet in `OrderPhotoWorkflows.options` ausschließlich anhand der konfigurierten Service-URL. Eine Auswertung von `TR_PHOTO_WORKFLOW` fehlt im NG-Anwendungscode. Bei ausgeschaltetem oder fehlendem Parameter weicht das Verhalten deshalb ab. Der tatsächlich gesetzte Datenbankwert wurde nicht geprüft.
+
+- PHP: `include/ajaxReqJob.php:13`, `:123`.
+- NG: `backend/src/main/java/de/stadtbote/votian/OrderPhotoWorkflows.java:28` und `:33`.
+- Damals offen: Umschaltung und vorgesehenen älteren Foto-Modus abbilden; eine vorhandene URL allein genügt nicht mehr als Aktivierungsbedingung.
+
+### 4. Fahrzeugfeld „Tragkraft Hebemittel“ – fehlt
+
+PHP liest und schreibt seit 30.10. `crvh_working_load_limit_crane` und `crvh_working_load_limit_lift`. Im aktuellen Formular ist „Tragkraft Hebemittel“ (`…_lift`) aktiv. Das Kranfeld ist mit `if (false)` ausgeblendet und wird nicht als zweites fehlendes aktives Eingabefeld gezählt.
+
+NGs Felddefinitionen enthalten beide Felder nicht. Der Hebemittelwert kann deshalb nicht angezeigt oder gepflegt werden und wird von der feldbasierten Fahrzeugkopie nicht übernommen. Das Vorhandensein der Spalten in der tatsächlich angeschlossenen Datenbank ist vor einer Umsetzung zu prüfen.
+
+- PHP: `admin/courier_vehicle.php:1069`, `:1649`; `include/inc_vehicle.inc.php:22`, `:210`, `:265` sowie die INSERT-/UPDATE-Feldlisten des Formulars.
+- NG: `backend/src/main/java/de/stadtbote/votian/MasterData.java:48`, `VehicleMasterSettings.java:13`, `VehicleCopy.java:29`.
+- Damals offen: aktives Feld, Werteprüfung, Speicherung und Kopierverhalten ergänzen. Das abgeschaltete Kran-Eingabefeld nicht ungeprüft aktivieren.
+
+### 5. Nachbearbeitungsmarkierung ohne Transporteur aufheben – nur teilweise abgesichert
+
+PHP verweigert seit 04.11. das manuelle Setzen von `jb_incomplete=0`, solange `cr_id` fehlt oder `0` ist. Die Prüfung ist nicht auf erledigte oder nicht stornierte Aufträge beschränkt.
+
+NG prüft den fehlenden Kurier in `OrderCompletionChecks.reasons` nur bei `jb_status=2` und `jb_storno=0`. Bei einem noch nicht erledigten Auftrag ohne Transporteur kann die Bearbeitung somit „Nachbearbeitung erforderlich“ aufheben, wenn die übrigen Prüfungen erfüllt sind. Der reguläre Abschluss über `COMPLETE`/`COMPLETE_STOP` verlangt in NG bereits einen Kurier und ist keine neue Lücke.
+
+- PHP: `admin/jb_detail.php:1711`.
+- NG: `backend/src/main/java/de/stadtbote/votian/OrderCompletionChecks.java:27`, `OrderOperations.java:68` und `:91`.
+- Damals offen: neue Bedingung für die manuelle Freigabe nachziehen; automatische Abschlussprüfungen und Stornofälle dabei bewusst unterscheiden.
+
+### 6. Übernommener manueller Festpreis bei PZM-Kunden – abweichende Neukalkulation
+
+PHP prüft einen bereits gefüllten Festpreis beim Absenden wegen geänderter Angaben nun nur erneut, wenn `fixprice_was_zone` gesetzt ist, der übernommene Preis also aus der PZM stammt. Der Benutzer kann den neuen Preis außerdem ablehnen und mit dem bisherigen Preis erneut absenden.
+
+NG setzt `templatePriceActive` beim Laden für jeden positiven Festpreis. `recalculateTemplate` schaltet bei einem PZM-Kunden daraufhin auf `AUTO`, ohne die Preisquelle zu unterscheiden. Eine Adressänderung nach dem Laden einer Vorlage mit manuell vereinbartem Festpreis führt damit ebenfalls zu automatischer Neukalkulation. Der Benutzer kann wieder auf „Festpreis“ umstellen; die neue PHP-Unterscheidung wird dadurch nicht automatisch übernommen.
+
+- PHP: `jobs/job_edit.68.20.js:6261`, `:6264`, `:6706`; Herkunftserkennung in `jobs/get_saved_tour.php:265`.
+- NG: `frontend/src/OrderEntryForm.tsx:202`, `:207`, `:245`, `:263`; ergänzend `backend/src/main/java/de/stadtbote/votian/OrderTemplatePricing.java:11`.
+- Damals offen: Preisursprung erhalten und nur den passenden übernommenen PZM-Preis automatisch neu ermitteln; bewusste Beibehaltung eines vereinbarten Festpreises ermöglichen.
+
+## Bereits abgedeckt oder keine neue Fachlücke
+
+- **Gruppenzuordnung:** PHP korrigiert NULL-Behandlung und doppeltes Anhängen der Gruppenliste. NG verwendet bereits eine deduplizierte ID-Menge und ersetzt den Wert per parametriertem UPDATE (`GroupAdministration.java:98`).
+- **Auftragslisten:** Die Umbenennung von `Ref.` zu `Refresh` ist keine neue Fachfunktion.
+- **Drittland-/Kommissionsprüfung und regulärer Abschluss:** Entsprechende NG-Prüfungen sind vorhanden. Die engere Abweichung beim manuellen Aufheben der Nachbearbeitung steht oben.
+- **Generierte Kataloge:** Elf geänderte `jobs/job_options_<NL>.js` enthalten Katalogvariablen, keine neuen Funktionsdefinitionen. NG liest die zugehörigen Kataloge aus der gemeinsamen Datenbank, unter anderem in `OrderEntryCatalog`. Alte generierte Inhalte waren nicht für alle gespeicherten Prüfsummen rekonstruierbar; eine vollständige Datenparität ihrer Werte wird nicht behauptet.
+- **Versions-/Sicherungskopien:** Neue Git-Pfade sind teilweise nachweislich Kopien bekannter Stände, etwa `customer_special_.php`, `group_31.php`, `jb_list_03.php`, `inc_vehicle_19.inc.php` und `inc_automailer_13.inc.php`. Sie wurden nicht allein wegen eines neuen Dateinamens als neue Funktionen gezählt. Die übrigen bereits inventarisierten aktiven Cron-/Autoranking-Dateien sind unverändert.
+- **Ausgeschlossener Umfang:** Classic-Sammelübergabe und die dokumentiert ausgeschlossenen HHA-/PTnova-/fremden Replikations- und PHP-Dateiwartungsfunktionen bleiben außerhalb der Restliste.
+
+## Umfang und Nachweise
+
+Frische Inventur am **09.11.2026 um 15:24 Uhr Europe/Berlin**: 2.710 Quell- und Hilfsdateien, keine Lesefehler oder während eines einzelnen Lesevorgangs instabilen Dateien. Die Zahl umfasst auch Bibliotheken, SQL-Dateien, Sicherungen und Verwaltungsdateien; sie ist keine Zahl von Fachfunktionen.
+
+Vergleichsbasis sind 1.363 eindeutige Pfade aus dem allgemeinen Abgleich vom 20.10., dessen Ergänzung und den Cron-Prüfbeständen vom 26./27.10.: **1.335 unverändert, 23 verändert, fünf entfernt.** Geändert sind elf PHP-Dateien, eine fachliche JavaScript-Datei und elf generierte JavaScript-Kataloge. Die fünf entfernten Dateien sind frühere Automailer-/Testvarianten.
+
+Alle zwölf geänderten fachlichen PHP-/JavaScript-Dateien wurden gegen exakt zur alten SHA-256-Prüfsumme passende Vorstände verglichen. Für `job_edit.68.20.js` wurde der passende alte Inhalt aus der Server-Git-Historie rekonstruiert. Zusätzlich wurden Git-Historie seit 20.10. einschließlich neuer Pfade und der aktuelle Server-Arbeitsbaum geprüft. Die 1.352 erstmals im erweiterten Inventar enthaltenen Dateien wurden nicht pauschal als seit Oktober neu entstanden gewertet.
+
+Server-HEAD: `f567b835974774c21260e30f781d9a89c475697c`. Abschließend wurden 27 gelesene Dateien außerhalb der regelmäßig generierten Kataloge erneut geprüft: **keine Änderung während des Abgleichs**.
+
+Nachweise unter `work/php-audit-2026-11-09/`: `server-manifest.json`, `comparison.json`, `server-git.json`, `download-manifest.json`, `baseline-files.json`, `baseline-git.json`, `diff/`, `current/`, `final-source-check.json`. Die ursprüngliche vorläufige Berichtsfassung liegt dort als `previous-report.md`.
+
+Dies ist ein Quellcode-Differenzabgleich, keine erneute vollständige Abnahme aller historischen PHP-Funktionen. Datenbankwerte, laufende Dienste, tatsächlicher Mailversand, externe Workflow-Oberfläche und bereitgestelltes Image wurden nicht funktional getestet. Der früher offene Kategorie-9-/RETRANS-903-Abgleich wurde nicht neu als Datenbankbefund bewertet.
+
+Bei der anschließenden Umsetzung wurden ausschließlich lokale Anwendungsdateien, Tests und Dokumentation geändert. Datenbanktests verwenden eine isolierte lokale MariaDB und synthetische Daten; Mailtransport und externe Dienste werden simuliert. Keine Serverdateien oder produktiven Geschäftsdaten wurden geändert, keine echten Mails versendet und kein Deployment ausgelöst.
+
+## Validierung der Umsetzung
+
+- Frontend: TypeScript-/Vite-Produktionsbuild und alle 44 Frontend-Tests erfolgreich.
+- Backend: `./mvnw -q clean verify` erfolgreich; 1.404 ausgeführte Tests, 242 ohne Integrationstest-Umgebung übersprungen.
+- Alle zehn ausgewählten MariaDB-Integrationstests erfolgreich: Auftragserfassung/-bearbeitung, Mailversandregeln, Kunden-/Fahrzeugkopie, Hebemittel-Tragkraft, Workflow-Verwaltung, klassische Fotos und Daueraufträge. Sie liefen mit `CRM_INTEGRATION_URL=jdbc:mariadb://127.0.0.1:33079/crm_qa` gegen eine isolierte Testdatenbank.
+- Nachweise: `work/php-parity-final-build.log`, `work/php-parity-unit-result.json`, `work/php-parity-final-integration.log`, `work/php-parity-integration-result.json`, `work/php-parity-frontend.log`, `work/php-parity-frontend-tests.log`.
+- Die tatsächliche externe Editor-Oberfläche, das gemeinsame Laufzeit-Secret und die produktive Datenbank wurden nicht funktional geprüft. Die Fahrzeugspalte muss wie im aktuellen PHP-Schema bereits existieren; es gibt keine produktive Schemaänderung.