Erweitere VoTiAn NG um Auftrags-, Stamm- und Verwaltungsfunktionen

Ergänzt Auftragserfassung und -bearbeitung, Unternehmerbelege, Stornos, Lagerkorrekturen, Stammdaten, Abrechnung, CRM, Formulare, Berichte und Preisverwaltung auf Basis der aktuellen PHP-Anwendung.

Enthält Integrations- und Oberflächentests sowie dokumentierte Abgleiche und Prüfstände.

docs/ALTSYSTEM-ANALYSE.md

@@ -1,5 +1,8 @@
 # Analyse des PHP-Altsystems votian
 
+**Quellenvorgabe ab 13. Oktober 2026:** Ausschließlich den aktuellen Stand per SSH `root@172.16.0.158:/data/0/votian-test/html` verwenden. Nicht mehr den früheren lokalen PHP-Ordner verwenden. Die folgende ursprüngliche Analyse ist historisch; aktueller Funktions-/Prüfstand steht in MENUE-ABGLEICH.md und PRUEFSTATUS.md. Zugangsdaten gehören nicht in diese Dokumentation.
+
+Aktualisierung 12. Oktober 2026: Die ursprüngliche Analyse beschreibt auch den vorherigen Lesestand. Für die inzwischen native Auftragserfassung einschließlich Fotoworkflows, Fernverkehrskalkulation und Auslandsabholung ist [AUFTRAGSERFASSUNG.md](AUFTRAGSERFASSUNG.md) maßgeblich.
 Stand: 01.10.2026. Auftraggeberkontext: Stadtbote GmbH. Grundlage ist eine statische, lesende Analyse des Quellbestands im Verzeichnis `votian/`. Es wurden keine produktiven Datenbanken, Fahrergeräte oder externen Dienste angesprochen. Dieser Bericht enthält keine produktiven Kundendatensätze oder Zugangsdaten.
 
 **Verbindliche Datenbankvorgabe:** Die Neuentwicklung verwendet die bereits vorhandene MySQL-Datenbank und deren bestehendes Schema. Es wird keine eigene Datenbank angelegt und keine Schemaänderung vorgenommen. DDL, automatische Schemaerzeugung, Schemaaktualisierung und ungefragte Initialbefüllung sind ausgeschlossen.
@@ -89,7 +92,7 @@ Die dazugehörigen Gegenbuchungsaufträge verwenden `jb_storno=3` für die Gutsc
 
 Stationen sind einzeln offen (`tr_status=0`) oder erledigt (`1`). Bei vollständig erledigten Stationen kann der Gesamtauftrag abgeschlossen werden. Das Entfernen einer noch offenen Station kann ebenfalls einen Abschluss auslösen. Bei nachträglichen Stationsänderungen sind vorhandene Abschlussdaten zu erhalten.
 
-`tr_ware_from_to` unterscheidet `1=Abholung`, `2=Anlieferung`, `3=Anlieferung und Abholung`. `0` leitet die Standardart aus der Stationsposition ab. Die neue Oberfläche sollte eindeutige, explizite Arten verwenden.
+`tr_ware_from_to` wird im aktiven Speicher- und Ladepfad (`jobs/job_options.php`, `jobs/get_saved_tour.php`) als `2=Abholung`, `1=Anlieferung`, `3=Anlieferung und Abholung` behandelt. Der Texthelfer `get_tr_ware_from_to_text` in `caglobal.inc.php` enthält dazu widersprüchlich vertauschte Beschriftungen. `0` leitet die Standardart aus der Stationsposition ab. Die neue Oberfläche sollte eindeutige, explizite Arten verwenden.
 
 Quellen: `votian/jobs/job_options.php:2290`, `:2335`, `:2356`; `votian/include/caglobal.inc.php:1355`.
 
@@ -128,7 +131,7 @@ Der Bestand besitzt keine einzelne universelle Formel. Wesentliche Einflussgrö
 
 Bei Festpreisen wirken im untersuchten Zweig ein Zuschlag, ein separat gerundeter Selbstbedienungsrabatt und anschließend ein Kundenrabatt. Servicepreise erhalten nicht automatisch denselben Zuschlag; ihre Rabattfähigkeit ist konfigurierbar. Die Kuriervergütung wird gesondert ermittelt. Deshalb reicht ein pauschales Feld „Gesamtpreis“ nicht zum Nachweis gleicher Abrechnung.
 
-Für eine spätere native Schreibumsetzung ist manuelle Preisangabe mit nachvollziehbaren Werten ein sinnvoller begrenzter Umfang. Im aktuellen lesenden Ansatz sollen Preise aus vorhandenen Aufträgen angezeigt und Preisänderungen über die geprüfte PHP-Funktion vorgenommen werden. Es müssen jedoch Währung, Netto-/Bruttobedeutung, Steuersatz und Rundung klar sein. Beispielpreise sind als Beispieldaten zu behandeln. Die vollständige Altpreisberechnung ist damit nicht ersetzt.
+Die native Auftragserfassung unterstützt inzwischen PLZ-/Gebietstarife sowie Festpreise; Details und Grenzen stehen in [AUFTRAGSERFASSUNG.md](AUFTRAGSERFASSUNG.md). Änderungen bestehender Preise erfolgen weiterhin über PHP. Es müssen jedoch Währung, Netto-/Bruttobedeutung, Steuersatz und Rundung klar sein. Beispielpreise sind als Beispieldaten zu behandeln. Die vollständige Altpreisberechnung ist damit nicht ersetzt.
 
 Für Spring Boot sollten Geldbeträge als `BigDecimal` und passend zu den vorhandenen Datenbanktypen gelesen und geschrieben werden; Schemaänderungen sind ausgeschlossen. Der Auftrag benötigt einen unveränderlich nachvollziehbaren Preisstand mit Herkunft und Komponenten. Eine spätere Tarifänderung darf historische Beträge nicht stillschweigend verändern. Dies sind Empfehlungen für die Neuentwicklung, keine Behauptungen über deren aktuellen Code.
 
@@ -183,7 +186,7 @@ Diese Matrix trennt vorhandene Fachlichkeit von dem vorgesehenen Einstieg. **Sie
 
 | Modul/Funktion | Bestand | Ziel erster Umsetzung | Noch zu belegende Parität / Priorität |
 |---|---|---|---|
-| Aufträge | Umfangreiche Felder, Listen, Kopien, Nacherfassung | Lesen/Filtern über JDBC; Erstellen/Bearbeiten als PHP-Verweis | Pflichtfelder, abgeschlossene/exportierte Aufträge und Historie; P0 |
+| Aufträge | Umfangreiche Felder, Listen, Kopien, Nacherfassung | Lesen/Filtern und native Erfassung über JDBC; Bearbeiten als PHP-Verweis | Pflichtfelder, abgeschlossene/exportierte Aufträge und Historie; P0 |
 | Mehrstopp-Tour | Beliebige Stationsfolge mit Einzelstatus und Nachweisen | Vorhandene Stationsfolge lesen; Bearbeitung im PHP-Ablauf | Gemischte Stationen, Stationsabschluss, Empfänger/Signatur; P0 |
 | Disposition | Manuell, Autoranking, Börse, Offline-Zuweisung | Dispositionsdaten lesen; Zuweisung/Status als PHP-Aktion | Angebot gegenüber Annahme, Rücknahme, Konkurrenz; P0 |
 | Storno | Kostenpflichtig/kostenfrei, Buchungsfolgen | Storno anzeigen; Aktion im bestehenden PHP-Prozess | Altflags, Beträge, Export-/Gegenbuchungsfälle; P0 |
@@ -196,7 +199,7 @@ Diese Matrix trennt vorhandene Fachlichkeit von dem vorgesehenen Einstieg. **Sie
 | Daueraufträge/Vorlagen | Wiederholungsmuster, Feiertage, Enddatum, gespeicherte Tour | Nicht als abgedeckt voraussetzen | Scheduler und Serien-/Vorlagenabnahme; P1 |
 | Zugriffsrechte | Rolle, Einzelaktion, Niederlassung und Kostenstelle | Bestehende Benutzerkonten, HQ-Mitarbeiterbezug und Leserechte; noch live nachzuweisen | Vollständige serverseitige Rechte-/Sichtbarkeitsmatrix; P0 |
 | Kunden-/Fahrerportal | Unterschiedliche Ansichten und mobile Kommunikation | Nicht als abgedeckt voraussetzen | Eigene Datenbegrenzung, Geräteprotokoll und Offlinefälle; P1 |
-| Artikel/Lager | Artikelpositionen, Packstücke, Bearbeitungsstatus | Nicht als abgedeckt voraussetzen | Lager-/Scanprozesse und Bestandsintegration; P2 nach Nutzungsnachweis |
+| Artikel/Lager | Artikelpositionen, Packstücke, Bearbeitungsstatus | Native Erfassung vorhandener Artikel und ausdrückliche Ein-/Aus-/Umlagerung; siehe AUFTRAGSERFASSUNG.md | Live-Abnahme der Buchungen; Stammdaten-, Lager-/Scanprozesse außerhalb der Erfassung bleiben PHP |
 | Routing/GPS/Autoranking | Externe Routen- und Ortungsinformationen | Nicht als abgedeckt voraussetzen | Dienstintegration, Rankingregeln, Ausfallbetrieb; P2/P1 je Betrieb |
 | Bestandsanbindung | Bestehendes MySQL-Schema mit verknüpften Bestands-/Archivdaten | Direkte, kompatible Anbindung ohne eigene Datenbank | Feld-, Status-, Transaktions- und Berechtigungsabgleich; keine DDL/Schemaänderung; P0 |
 

docs/AUFTRAGSERFASSUNG.md

@@ -0,0 +1,145 @@
+# Native Auftragserfassung
+
+Aktualisierung 13. Oktober 2026: Foto-Workflow-Sets einschließlich Freigaben, Stationsregeln und wiederaufnehmbarer Übertragung sind ergänzt. Verbindliche PHP-Quelle ist ausschließlich der aktuelle SSH-Serverstand unter `/data/0/votian-test/html`; Details im Menüabgleich und Prüfstatus.
+
+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, 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; keine Übernahme von Status, Zuweisung, 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 **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 und `MASK_STK_SUBSTOCK_ACCESS` werden serverseitig geprüft. 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.

docs/MENUE-ABGLEICH.md

@@ -0,0 +1,226 @@
+# Menüabgleich Altanwendung / Votian NG
+
+Stand: 13. Oktober 2026. Das im angemeldeten Browser sichtbare Zentralenmenü auf test.sb.assecutor.de wurde geöffnet, einschließlich der dritten Menüebene der Verwaltung. Aktuelle Quelle ausschließlich `root@172.16.0.158:/data/0/votian-test/html`, einschließlich `admin/menu.php` und der verlinkten PHP-Seiten, der React-Oberfläche und den tatsächlich verfügbaren Backend-Endpunkten. Eine vorhandene Ansicht, ein deaktiviertes Formular oder ein Link zur Altanwendung zählt nicht als implementierter Fachprozess.
+
+## Ergebnis
+
+Die neue Anwendung ersetzt noch nicht alle Funktionen des Altmenüs. Nativ vorhanden sind die Auftragserfassung, erste Verwaltungsbereiche und die serverseitige Zeitraumstatistik, Kunden-/Transporteursberichte und der Vertriebskalender sowie das Lesen von Aufträgen, Kunden und Kurieren. Auftragsbearbeitung, Disposition, Abschluss, Storno/Gegenbuchung und Stammdatenpflege wurden nativ ergänzt. Abrechnungsübersichten, Rechnungszuordnung, CSV und PDF-Leistungsübersichten laufen über `/api/billing/*`. Die vollständige Rechnungserstellung ist weiterhin offen; der alte ungenutzte Endpunkt `GET /api/invoices` bleibt nicht unterstützt.
+
+| Altmenü / Funktion | Stand in Votian NG | Fehlender Umfang |
+|---|---|---|
+| Impressum | Vorhanden | Native Ansicht unter Verwaltung; Inhalt mit PHP-Ansicht abgeglichen |
+| Sprache | Fehlt | Sprachauswahl und Benutzer-Sprachpräferenz; Oberfläche derzeit Deutsch |
+| Abmelden | Vorhanden | Anmeldung/Abmeldung über bestehendes Konto; Logout nicht zum Prüfen ausgeführt |
+| Verwaltung → Kunden | Erweitert, teilweise | Kunden-/Kostenstellenstamm, Anschriften, Bank-/Rechnungsdaten, Konditionen, Benachrichtigungen und Hierarchiepflege. Adressvorschläge sowie Kostenstellenanzeige/-namenssuche mit direkter Bearbeitung vorhanden. Preis-/Leistungstypzuordnungen mit Sortierung und Wiederaufnahme vorhanden. Konten/Zugangsrechte, weitere Service-Sonderdialoge, Sonderbeziehungen und kundenspezifische Zusatzformulare offen |
+| Verwaltung → Transporteure | Erweitert, teilweise | Unternehmer-/Fahrzeugstamm einschließlich Kontakt, Anschrift, Abrechnung, Versicherung und Gerätestammdaten; Adressvorschläge vorhanden. Zugangsverwaltung, Spezialzuordnungen und Zusatzformulare offen |
+| Verwaltung → Kartenübersicht | Fehlt | Flotten-/Dispositionsübersicht; Stationskartenauswahl in der Erfassung ersetzt diese nicht |
+| Verwaltung → Berichte → Kunden | Weitgehend vorhanden | Liste, Suche, Berichtstypen, vertrauliche Einträge, Anlegen/Bearbeiten/Löschen, Statistik und CSV nativ. Folgetermine mit übernommener Kundenzuordnung vorhanden; Verknüpfte Formulare 101/102 mit Bearbeitung, Vorlagen, Feldhistorie und Druck/PDF vorhanden; zusätzliche Kundenumsatz-/Rechnungsnavigation fehlt |
+| Verwaltung → Berichte → Transporteure | Weitgehend vorhanden | Eigene Berichtstypen, Liste, Suche, Anlegen/Bearbeiten/Löschen, Vertraulichkeit, Statistik und CSV nativ. Verknüpfte Formulare 101/102 mit Bearbeitung, Feldhistorie und Druck/PDF vorhanden |
+| Verwaltung → Preise → Servicepreise | Vorhanden | Allgemeine/kundenspezifische Matrix, beide Servicemodi, Frachtvergütungen, künftige Stände und Historie; Preis-/Leistungstypen mit Gruppenverwaltung |
+| Verwaltung → Preise → PLZ-Preise | Vorhanden | Gerichtete Von-/Nach-Matrix, Kunden-/Fahrzeugtarife, Frachtvergütung und Historie |
+| Verwaltung → Preise → Bereichspreise | Vorhanden | Tarifmatrix, Bereiche anlegen/umbenennen, PLZ-Zuordnungen und Nachbarschaften |
+| Verwaltung → Rabatte → Servicerabatte | Vorhanden | Separate Rabatt-/Frachtvergütungsrabattmatrix; erhält die Preise und schreibt vollständige Tarifstände |
+| Verwaltung → Rabatte → PLZ-Rabatte | Vorhanden | Rabattmatrix mit getrennten Kunden-/Kurierwerten und Historie |
+| Verwaltung → Rabatte → Bereichsrabatte | Vorhanden | Bereichsrabattmatrix einschließlich allgemeiner Vergleichswerte |
+| Verwaltung → Niederlassungen → Mitarbeiter | Fehlt | Mitarbeiterpflege und Rechteverwaltung |
+| Verwaltung → Niederlassungen → Einstellungen | Fehlt | Niederlassungs-/Parameterverwaltung; Erfassung in freigegebenen Niederlassungen ist ein separater Funktionsumfang |
+| Verwaltung → Feiertage | Vorhanden | Jahres-/Monatsansicht, An-/Abwahl und Namen, Übernahme aus Jahr/Default, Speichern. Vergangene Tage und heute geschützt; bestehende Zeitfenster bleiben erhalten |
+| Verwaltung → Anfahrtszeiten | Vorhanden | CLASSIC je Niederlassung und zentrale BWV-Vorgaben; PLZ-Bereich, Minutenpflege und Speichern je Zeile. Leere/0-Minuten-Eingaben verwenden LATEST_TAKETIME_IN_MINUTES der Niederlassung |
+| Verwaltung → Adressen → PLZ-Adressen | Vorhanden | Suche, sieben Sortierungen, Anlage und Mehrfachlöschung der Straßen-/Hausnummernzuordnungen zu Abrechnungs-PLZ je Niederlassung |
+| Verwaltung → Adressen → Bereichsadr. | Vorhanden | Bereichsadresszuordnungen mit Hausnummerngrenzen und gerade/ungerade, Bereichsauffüllung und Anzeige besonderer Hausnummernzuordnungen. Tarifgebiete und Nachbarschaften werden im nativen Preisbereich gepflegt |
+| Verwaltung → Gruppen | Vorhanden | Anlegen, Umbenennen, Freigabe und Mitgliederpflege; Niederlassungsauswahl im eigenen Mandanten, Löschvorschau mit Zuordnungsbereinigung und Wiederaufnahme nach Teilfehlern. System-/readonly-Gruppen bleiben geschützt |
+| Verwaltung → Filter | Vorhanden | Globale Filterliste, Suche, drei Sortierungen, Langtexte, Anlegen, Langtext-/Sortierpflege und Löschen mit Zuordnungsbereinigung. Tour-/Dauerauftragsbereinigung nutzt den vorhandenen PHP-Nachtlauf |
+| Verwaltung → Bewertungen | Vorhanden | Kategorie 15: Liste/Karten, Suche, alle neun Auswahlfelder, Anlegen/Bearbeiten/Löschen, Verlauf, Druck/PDF/HTML und E-Mail-Vorbereitung. Keine eigenständige Rechenstatistik; auch das aktuelle PHP-Formular speichert Auswahlwerte |
+| Verwaltung → Kessel Buntes | Fehlt | Sonderauswertungen aus `tools/statistic_finishment.php` |
+| Aufträge → Einzelerfassung | Weitgehend vorhanden | Umfang/Grenzen siehe AUFTRAGSERFASSUNG.md; Bearbeitung, manuelle Preisberichtigung, Zuweisung, Rückruf, Abschluss und Storno/Gegenbuchung ergänzt; Sonderabläufe siehe unten |
+| Aufträge → Listenerfassung | Fehlt | Eigenständige tabellarische Massenerfassung aus `jobs/jb_edit_batch.php`; Mehrfachkopien ersetzen sie nicht |
+| Listen | Teilweise | Suche, Status-/Datumsfilter, Detail und Historie vorhanden; parallele Listenfenster, Autoranking, Reservierungsranking, vollständige Spezialfilter und Niederlassungsübersicht fehlen |
+| Rechnungen → Übersicht | Teilweise | Kunden-/Kurier-Leistungsübersichten, Zeitraum/Kostenstellen/Nummernfilter und wiederaufnehmbare Rechnungszuordnung vorhanden. Vollständige Rechnungserstellung, automatische Nummernvergabe und Buchungsläufe offen |
+| Rechnungen → PDF-Ausgabe | Teilweise | Native Rechnungsanlage/Leistungsübersicht vorhanden. Vollständige Rechnung mit alten Layouts und Spezialformaten offen |
+| Rechnungen → CSV-Ausgabe | Teilweise | CSV der gefilterten Abrechnungsübersicht vorhanden; alle FiBu-/Bestandsformate offen |
+| Vertrieb | Erweitert, teilweise | Tages-/Wochen-/Monats-/Jahreskalender, Terminbearbeitung, Teilnehmer/Gruppen/Bestätigung, Wiedervorlagen, Terminabschluss, Terminstatistik und Kundenberichte/Folgetermine nativ. Kontakte mit Feldhistorie und Druck/vCard, Kundenstatuswechsel mit CSV, Motivation-Counter mit Monatszielen sowie Termin-E-Mails nativ. Kunden-Neuanlage vorhanden; weitere CRM-Sonderdialoge offen |
+| Nachrichten → Endgeräte | Weitgehend vorhanden | Historie, Filter, Empfangsbestätigung, Antwort, Einzel-/Gruppen-/Gesamtversand, Gruppen und direkte/transitive Empfängerzuordnung. PHP-Verwaltungsprotokoll 203 für Gruppenänderungen, Zuordnungen und Gesamtversand ergänzt |
+| Nachrichten → Mitteilungen | Vorhanden | Zeitraum, Niederlassung/persönlicher Empfänger, Anlage, abgelaufene Einträge, berechtigtes Löschen; kein automatisches Löschen beim Lesen |
+| Nachrichten → Newsletter | Weitgehend vorhanden | Bestehende Felder, Liste/Karten, Suche, Bearbeitung, Verlauf, Bilder, Vorlagenausgabe, Druck/PDF/HTML, Empfängerauswahl und SMTP-Versand. Externe Metadatenbank für persönliche Abmeldeschlüssel noch nicht live geprüft; beliebige Template-Skripte werden nicht ausgeführt |
+| Datentransfer → Datenexport | Teilweise | Einfacher Auftrags-CSV vorhanden; fachliche Bestands-/Buchhaltungsexporte fehlen |
+| Datentransfer → Datenimport | Fehlt | Datenimport und Transferverarbeitung |
+| Statistik | Erweitert, teilweise | Zeitraum-/Niederlassungsabfragen unabhängig von der Auftragsliste, fünf Vergleiche, zwölf Aufteilungen, KM/CO₂e, Nettowerte und CSV vorhanden. Archivtabellen, Service-/Jobcalc-Auswertungen, historische Kundenkonsolidierung und weitere PHP-Spezialfilter fehlen |
+| Formulare | Teilweise | Kategorien/Felddefinitionen/Vorlagen/Gruppenzuordnung und Feldreihenfolge nativ. Berichtsformulare 101/102 einschließlich aktueller Servervorlagen ergänzt. Weitere Objektformulare und Spezialfeld-/Skriptfunktionen fehlen |
+
+
+## Aktueller Serverabgleich und Ergänzungen – 13. Oktober 2026
+
+Ausschließlich SSH-Serverquelle `/data/0/votian-test/html`; letzter dort gemeldeter Git-Commit `868db70` vom 13. Oktober 2026, 16:18:15 UTC. Verglichen wurde der tatsächlich vorhandene Dateistand einschließlich nicht eingecheckter/generierter Dateien. Die relevanten 1.199 Dateien in den Fachordnern wurden beim Übertragen per SHA-256 geprüft. Die Arbeitskopie unter `work/php-current-2026-10-13` ist ein ignorierter Server-Snapshot; der frühere lokale PHP-Bestand wird nicht mehr gelesen. Einzelne generierte `job_options_<hq>.js` ändern sich im laufenden PHP-Betrieb und wurden erneut vom Server geholt. Für den anschließenden Artikel-/Unterauftragsblock wurden 778 Einträge aus `jobs`, `admin`, `include` und `stock` erneut direkt vom Server übertragen.
+
+- **Foto-Workflow-Sets:** Kundenfreigaben über `/sets/kunde/{id}`, gegebenenfalls allgemeine Sets über Kunde 0. Auswahl eines Sets für den Auftrag, passende Stationsflows, FIRST/MIDDLE/LAST-Vorbelegung, eine Einzelstation zählt als LAST. Mengenbereiche werden angezeigt. Setwechsel verwirft Stationsabweichungen. Set und Stationsauswahl sind Teil der Preisvorschau und werden zusammen mit dem Auftrag in einer InnoDB-Warteschlange gesichert. Übertragung über `/selection/set` und danach `/selection`; Fehler halten direkte Disposition zurück und werden erneut versucht. Vorhandene Warteschlangen ohne Set bleiben lesbar. Die PHP-Funktion `photoScopeMatches` verwendet historisch `ware=1` für PICKUP_ONLY und `ware=2` für DELIVERY_ONLY; diese tatsächliche Zuordnung wird beibehalten, obwohl die englischen Namen zur NG-Stationstypbezeichnung gegenläufig wirken.
+- **Adressvorschläge:** Kunden, Transporteure und die Anschriften der Kostenstellen verwenden [Google Places Autocomplete](https://developers.google.com/maps/documentation/places/web-service/place-autocomplete) und [Place Details](https://developers.google.com/maps/documentation/places/web-service/place-details). Straße, Hausnummer, PLZ, Ort und Land werden gemeinsam übernommen; unvollständige deutsche PLZ-Präfixe bleiben leer. Schlüssel bleibt serverseitig, Suche benötigt die jeweiligen Stammdatenrechte. Manuelle Eingabe bleibt bei Dienstausfall möglich.
+- **Kostenstellensuche:** Schalter „Kostenstellen anzeigen“, eigener Namensfilter, eine Zeile pro passender Kostenstelle und direkter Einstieg in ihre Pflege. Kundenfilter und Niederlassungsrechte gelten auch für diese Zeilen; deaktivierter Schalter liefert weiterhin eine Zeile pro Kunde.
+- **Auftragsbearbeitung:** Stamm-/Stationsdaten, Zuweisung/Rückruf/Annahme, einzelner oder vollständiger Abschluss, manueller Fixpreis mit Begründung und Storno/Gegenbuchung. Quittungen und erledigte Stationen werden geschützt; Export/Rechnungszuordnung verhindert reguläre Änderungen. Adress-/Zeitänderungen verlangen erneute Preisprüfung. Automatische Neukalkulation für vorhandene Stationen einschließlich PLZ-/Bereichs-, Kilometer-/PZM-, Fest- und Leistungspreisen und Kostensplit ergänzt. Artikelpflege und ergänzende Lager-/Gegenbuchungen sowie gemeinsame Nachkalkulation bestehender Kurier-Unteraufträge sind ergänzt (Details unten). Erweiterung/Entfernung von Belegpaaren sowie gemeinsames Storno einschließlich Einnahmenausgleich sind inzwischen umgesetzt. Weitere Hintergrundprozesse bleiben offen.
+- **Stammdaten/Abrechnung:** Historische Auftragsadressen bleiben beim Ändern eines Stamms unverändert. Rechnungszuordnungen werden vor dem nicht rückrollbaren MyISAM-Schritt gesichert und können nach Teilfehlern fortgesetzt werden. PDF ist eine Leistungsübersicht/Rechnungsanlage, keine vollständige Rechnungserstellung.
+
+Zahlungsbedingung als Auftragssnapshot und Exportfeld umgesetzt. Der aktuelle PHP-Code benutzt `jobprice.mt_sort=16` sowohl für den Kilometerpreis als auch für die Zahlungsbedingung. NG bewahrt daher Wert und Text in separaten `genericdatacontainer`-Einträgen; alte PHP-Zahlungsbedingungen werden gelesen, Kilometerpositionen bleiben erhalten. Weitere offene Menüs und Teilfunktionen stehen in der Tabelle oben. Dies ist kein Nachweis vollständiger PHP-Parität.
+
+## Artikel, Lager und bestehende Unternehmerverrechnung – 13. Oktober 2026
+
+- **Artikel im Bestandsauftrag:** „Bearbeiten / Aktionen → Artikel und Lager bearbeiten“. Freie und Stammartikel hinzufügen, ändern, einer offenen Station zuordnen und entfernen. Bezeichnung, Stückzahl, Gesamtgewicht, Packstücke, Artikelwert, Seriennummer und Hinweis. Bestehende `trat_id` und Scan-Nachweise bleiben erhalten; gescannte und abgeschlossene Positionen sind geschützt. Artikelpflege löst keine automatische Lagerbuchung aus.
+- **Lagerjournal am Auftrag:** Bewegungen anzeigen; Wareneingang, Auslagerung und Umlagerung mit Vorschau buchen. Gegenbuchungen ergänzen das Journal und markieren den korrigierten Eintrag. Rechte 4/7/14, Niederlassungs-/Kundenzuordnung, Lagerhierarchie, Bestand, Kapazität und Seriennummer werden geprüft. Request-ID, Revision und Transaktion verhindern doppelte oder halbe Buchungen. Bei neuen Seriennummern-Auslagerungen sichert NG die 25 Zusatzfelder in `genericdatacontainer`; eine Gegenbuchung stellt sie wieder her. Historische Zusatzdaten aus `stkmv_data` und Bündel-Gegenbuchungen innerhalb desselben Auftrags sind inzwischen unterstützt; fehlende Seriennummern-Zusatzdaten können ausdrücklich ergänzt werden. Auftragsübergreifende Bündel benötigen weiterhin die vollständige Lagerverwaltung.
+- **Bestehende Kurier-Unteraufträge:** Beträge und Unternehmerfahrzeug eines vorhandenen Belegpaars im Kalkulationsbereich ändern. Kundenpreis, Frachtvergütung, Zuschläge, Servicepreis, Steuer, erster Mautanteil und beide Vorzeichen werden gemeinsam gespeichert. Auftragsnummern, Tour-IDs und Zustellnachweise bleiben erhalten. Jede beteiligte Revision wird geprüft; Rechnungszuordnung, Export, Einnahmen, Fremdniederlassungen und beschädigte Belegketten verhindern die Änderung. Voraussetzung: erledigter Inlands-Hauptauftrag und einfache, ausgeglichene Belegpaare. Neue Paare anlegen/aufheben und gemeinsame Stornoabläufe sind inzwischen ergänzt (siehe folgenden Abschnitt).
+- **Referenz:** aktuelle Serverdateien `include/caglobal.inc.php`, `include/inc_stock.inc.php`, `include/inc_job.inc.php`, `admin/sort.php`; angemeldete PHP-Auftragserfassung, Auftragsdetails und Lageransicht lesend geprüft. Der separate PHP-Calculator öffnete ein durch die Browsersteuerung nicht erreichbares Popup; dessen Logik wurde anhand des aktuellen Servercodes abgeglichen.
+
+## Unternehmerbelegpaare, gemeinsame Korrektur und Lagerzusatzdaten – 13. Oktober 2026
+
+Referenz erneut direkt per SSH aktualisiert: Git `868db70`, 778 Einträge aus `jobs`, `admin`, `include`, `stock`. PHP-UI `admin/jb_list.php` und `stock/stock.php` einschließlich ausgewähltem Hauptlager TOSHIBA lesend angesehen. Aktive Stornologik in `admin/jb_list.php` und `jobs/job_options.php`; der alte `cancelJob`-Block in `include/inc_job.inc.php` ist auskommentiert. Weitere Quellen: `include/caglobal.inc.php`, `include/inc_stock.inc.php`, `include/services_func.inc.php`.
+
+- **Belegpaare im Bestandsauftrag:** Unternehmer hinzufügen, Fahrzeug/Betrag ändern und Paare aufheben. Die Preisvorschau zeigt neue, geänderte und aufgehobene Belege. Stabile positive Beleg-IDs ordnen Eingaben zu; unbekannte/doppelte IDs werden abgewiesen. Entfernte Paare werden durch zwei Gegenbuchungen ausgeglichen; Originale und Zustellnachweise bleiben erhalten. Die bisherigen Elternzuordnungen werden in `ng_previous_parent` dokumentiert und aus `jb_id_parent` gelöst, da auch PHPs `getJobChildren` stornierte Zuordnungen sonst erneut einlesen würde. Es gelten weiterhin Recht 38, erledigter Inlandsauftrag, einfache ausgeglichene Paare, keine Einnahmen oder abgerechneten Belege bei der Neukalkulation.
+- **Gemeinsamer Storno / Gutschrift:** eigener Dialog unter Bearbeiten / Aktionen mit allen Belegnummern, Nettobeträgen, Frachtvergütung, Maut und Einnahmen. Storno verlangt nicht abgerechnete Belege; Gutschrift erlaubt bereits exportierte/zugeordnete erledigte Originale. Recht 4/7, für Unternehmerpaare zusätzlich 38. Neue Gegenbuchungen sind unabhängige Belege. Originale mit Gutschrift sind für weitere NG-Bearbeitung gesperrt. Offene Disposition wird zurückgenommen; bestehende Dauerauftragsregel kann ausdrücklich beendet werden.
+- **Einnahmen:** zusätzlich Recht 5 und ausdrückliche Bestätigung. Jede vorhandene Buchung erhält eine verknüpfte Buchung mit umgekehrtem Betrag; ursprünglicher Modus, Kostenstelle, Stationsnummer und Kassenschalter bleiben erhalten. Bereits exportierte Datensätze werden nicht überschrieben; die Gegenbuchung ist noch nicht exportiert. Dies ist ein Buchungsausgleich, keine tatsächliche Rückzahlung. Anders als PHPs Löschung nicht exportierter Einnahmen bleiben Originalbuchungen nachvollziehbar.
+- **Stornogebühr:** wie der aktuelle PHP-Stornopfad ohne zusätzlichen Rabatt und ohne zusätzliche Unternehmergebühr. Die Gebühr wird centgenau auf vorhandene Kostensplit-Zahler verteilt und in der gespeicherten Nettosumme berücksichtigt. Gegenbuchungsbeträge folgen den tatsächlichen Rechnungspositionen; ohne Positionen gilt der gespeicherte Auftragspreis. Eine fehlende Ursprungsposition wird bei gebührenpflichtiger Korrektur als negative Basisposition ergänzt, damit die Abrechnung nicht nur die Gebühr enthält.
+- **Lagerzusatzdaten:** TAN, Zusatzdatum und bis zu 25 Zusatzfelder; Anzeige im Journal und in der Buchungsvorschau. Einlagerungen mit Seriennummer speichern diese Angaben auch am Artikel. Gegenbuchungen verwenden gesicherte Artikeldaten, ersatzweise die historischen `<br>`-getrennten PHP-Journaldaten. Fehlende alte Angaben müssen ausdrücklich ergänzt werden. Bündel werden anhand `at_id_bundle` und Buchungszeitpunkt vollständig in umgekehrter Reihenfolge gegengebucht; alle Komponenten werden gemeinsam auf Bestand/Kapazität geprüft. Bereits teilweise korrigierte oder auftragsübergreifende Bündel werden abgewiesen, ohne Teilbuchung.
+- **Integrität:** alle Geschäftsschreibzugriffe über `DatabaseService`, vorhandene InnoDB-Tabellen, keine Schemaänderung. Vorschau-Fingerprint, Versionsvergleich, Sperren, Wiederholungsbeleg und Audit innerhalb derselben Transaktion. Bei unklarer Speicherantwort wiederholt die UI denselben Vorgang. Kein fachlicher Schreibtest gegen echte Geschäftsdaten.
+
+Offen bleiben die weiteren Menübereiche der Tabelle, insbesondere vollständige Lagerverwaltung einschließlich auftragsübergreifender Bündel, zusätzliche Sonderbeziehungen/B2B-Hintergrundprozesse, Kunden-Servicezonen und Spezialzeitvorgaben, Zugangsverwaltung, Listenerfassung, vollständige Rechnungs-/Buchhaltungsläufe und Spezialstatistiken.
+
+## Ergänzte Teilfunktionen – 13. Oktober 2026, weiterer Ausbau
+
+- **Neukalkulation bestehender Aufträge:** Preisvorschau und Übernahme ohne erneute Auftragserzeugung. PLZ-/Bereichstarife, Kilometer-/PZM, Festpreise, Leistungskalkulation, Zuschläge, Steuer und Kostensplit. Versions- und Rechteprüfung, Frachtvergütungsgrenzen, Audit und Wiederholungsbelege; bereits erledigte Stationen, Fotos und Lagerbewegungen bleiben erhalten. Bestehende einfache Unternehmer-Belegpaare können inzwischen gemeinsam nachkalkuliert werden. Aufträge mit Einnahmen, abgerechneten Belegen oder Sonderverknüpfungen werden weiterhin ausdrücklich abgewiesen. Manuelle Preisänderung verwirft veraltete Kalkulationsvorgaben; Adresswechsel entfernt die alte Abrechnungs-PLZ. Einzelstationen können bearbeitet werden.
+- **Zahlungsbedingung:** PHP-Wert (z. B. ZA10) und lesbarer Text werden beim Erstellen festgehalten, in Gegenbuchungen übernommen und in Abrechnung/CSV ausgegeben. Keine nachträgliche Ersetzung historischer Werte durch den aktuellen Kundenstamm.
+- **Gruppen:** Niederlassungsauswahl mit Masterrecht 10 im eigenen Mandanten. Vorschau zählt betroffene Zuordnungen. Löschung entfernt ausschließlich die betreffende Mitgliedschaft, schützt System-/readonly-Gruppen und hält einen dauerhaften Wiederaufnahmeplan vor. Kurzzeitige Tabellensperren koordinieren die abschließende Bereinigung mit PHP; ein MyISAM-Teilabbruch ist wiederholbar.
+- **Anfahrtszeiten:** Leer oder 0 übernimmt den gültigen Niederlassungsstandard. Fehlt dieser, wird vor dem Schreiben eine konkrete Fehlermeldung angezeigt.
+- **Nachrichten:** Zusätzliche Logtyp-203-Ereignisse für Nachrichtengruppen, Mitgliederzuordnungen und Gesamtversand über die bestehende Audit-Warteschlange. Der Versandprotokolleintrag dokumentiert den Versandversuch, keine garantierte Gerätezustellung.
+- **Berichtsformulare:** Kategorien 101 und 102 sind direkt an Kunden-/Transporteursberichte gebunden. Aktueller Serverbestand: 23 bzw. 109 Felder. Vorlagenbasierte Bearbeitung, Fahrzeugauswahl, Checkboxen, Datum/Uhrzeit, Freitext, automatische Kunden-/Umsatz-/Niederlassungsangaben, Feldhistorie und Druck/PDF. Berichtszugriff, Vertraulichkeit und Änderungsrechte gelten auch für diese Formulare; gleiche numerische IDs in anderen Objekttabellen vermitteln keinen Zugriff. Das Bericht-Menü nennt 102 „Fahrzeugkontrolle“, die tatsächliche Vorlage heißt „Vorortprüfung Kundenbefragung“. Vorlagenskripte werden nicht ausgeführt.
+- **Kunden-Servicezuordnungen:** Auswahl und Reihenfolge von Preis-/Leistungstypen in beiden Servicemodi, inklusive Mandantenkonfiguration und Schutz veralteter Bearbeitungsstände. Änderungen an MyISAM-Zuordnungen werden vorab gesichert und nach Teilfehlern anhand des gespeicherten Plans fortgesetzt. Preis-/Leistungstypen anderer Modi bleiben beim Moduswechsel ausgewählt. Kunden-Servicezonen, Radien, Aktionen und Spezialzeitvorgaben sind separate, weiterhin offene Unterdialoge.
+- **Kostenstellen:** Die historische Zusatzadresse Typ 3 ist optional. Neue Stammkostenstellen verwenden die aktuellen Adresstypen 1/2/4; bestehende Zusatzadressen bleiben bearbeitbar.
+
+Die Tabelle oben bleibt die Übersicht über den Gesamtumfang. Dieser Ausbau schließt insbesondere Rechnungserstellung/Spezialexporte, Spezialstatistiken, vollständige Listenfunktionen, Zugangsverwaltung und die ausdrücklich genannten Auftragssonderfälle noch nicht ab.
+
+## MyISAM-Abhängigkeiten
+
+Lesende Prüfung am 13. Oktober 2026 auf der Hauptverbindung: `phoenix` 26 MyISAM/86 InnoDB, `phoenix_group` 5/2, `phoenix_log` 15/7, `phoenix_pda` 5/1. Eine vorhandene MyISAM-Tabelle ist nicht automatisch eine von NG verwendete Tabelle. Direkt verwendet werden unter anderem `invoice`, `tax`, PLZ-/Adresszuordnungen, Kurierfilter und Kunden-Servicezuordnungen sowie Termine, Berichte, Nachrichten und Historie.
+
+Die Häufigkeit hängt von Benutzeraktionen ab: Auftragsbearbeitung liest `invoice`, Kundenstamm lädt `tax`, Abrechnung liest `invoice` und schreibt Zuordnungen. Historienübertragung prüft alle 30 Sekunden die InnoDB-Warteschlange; MyISAM-Logzugriffe erfolgen nur für ausstehende Einträge (regelmäßig ein SELECT und bei fehlendem Eintrag ein INSERT). Die normale Listen-Autoaktualisierung ist standardmäßig ausgeschaltet und lädt bei Aktivierung alle 30 Sekunden die InnoDB-Kernlisten. Es gibt derzeit keine Messung pro Tabelle/Minute; aus Quellcode oder Tabellenanzahl lässt sich kein tatsächliches Zugriffsvolumen ableiten. Keine Engine- oder Schemaänderung durchgeführt.
+
+## Nativ umgesetzter Verwaltungs- und Statistikblock
+
+Die PHP-Oberflächen `admin/public_holiday.php`, `admin/traveltime.php`, `admin/group.php`, `admin/impressum.html` und `statistic/statistic.php` wurden im angemeldeten Browser angesehen und mit Quellcode, Schema und nativen Dialogen verglichen. Die Listenerfassung und Filterverwaltung wurden ebenfalls angesehen; sie sind dadurch noch nicht portiert. Kunden-/Transporteursberichte wurden im nachfolgenden Block ergänzt.
+
+- Feiertage/Anfahrtszeiten verlangen Recht 2. Feiertage vergleichen den geladenen Jahresstand und sperren die Bestandszeilen beim Schreiben. CLASSIC ändert die lokale Zuordnung; BWV verwendet wegen MyISAM eine einzelne bedingte Aktualisierung je PLZ. Der zunächst fehlende Standardwert ist im aktuellen SSH-Abgleich aufgelöst; leer/0 übernimmt inzwischen `LATEST_TAKETIME_IN_MINUTES`.
+- Gruppen benötigen Rechte 8 und 25. Änderungen an shared Gruppen verlangen zusätzlich Recht 10, einzelne Mitgliedsarten ihre jeweiligen Leserechte. System-/readonly-Gruppen sind geschützt, zyklische Gruppenbeziehungen werden abgewiesen. Mitgliedschaften verwenden die bestehenden kommaseparierten Felder und vergleichen den Bearbeitungsstand. Inzwischen ist die bestätigte Löschung belegter Gruppen mit Vorschau und wiederaufnehmbarer Zuordnungsbereinigung ergänzt (siehe aktuellen Ausbau oben).
+- Statistik verlangt Recht 8, mehrere Niederlassungen zusätzlich Recht 10 und denselben Mandanten. Datumsgrundlagen: Erfassung, Buchung, Erledigung, Export, Auftrag. Raster: Gesamt, Tag, ISO-Woche, Monat, Jahr, halbe/eine/zwei Stunden. Bis zu fünf gleichzeitige Aufteilungen; maximal 5000 Ergebnisgruppen, bei Überschreitung Fehler statt Teilergebnis.
+- Filter umfassen Status, Aufträge/Gutschriften, Zahlungsweise, Kunden-/Transporteursnummer und -gruppe, Nacherfassungen anhand des PHP-Protokolls, Dauer-/Fernaufträge, Uhrzeitfenster, kostenlose Stornos und zugeordnete Kunden. Nettowerte: Auftragswert, Frachtvergütung, EAU/BSG, Servicepreis/-vergütung, TSZ; KM und CO₂e mit Erfassungsabdeckung. Mehrdeutige Frachtvergütungen werden als unvollständig gekennzeichnet.
+- Neue Dateien: `Administration.tsx`, `Statistics.tsx`, `AdminSupport`, `CalendarAdministration`, `GroupAdministration`, `AdministrationController`, `StatisticsService`, `StatisticsController`. Alle SQL-Zugriffe laufen über `DatabaseService`; keine Schemaänderung.
+
+Diese Ergänzung schließt den gesamten Menüabgleich nicht ab. Die jeweils verbleibenden Teilfunktionen in Auftragsbearbeitung/Disposition/Storno, Listenerfassung, Stammdaten-/Tarifpflege, Rechnungen, Vertrieb, Nachrichten, Formularen und Datentransfer sind in der fortgeschriebenen Tabelle oben ausgewiesen.
+
+## Kunden- und Transporteursberichte – Ergänzung vom 12. Oktober 2026
+
+Die angemeldeten PHP-Ansichten `groupware/report.php` für `cs` und `cr` sowie die Berichtsstatistik wurden angesehen; Schreibpfade, Metatypen, Vertraulichkeit und Formularverknüpfungen wurden im Quellcode geprüft. Die native Umsetzung liegt in `Reports.tsx`, `ReportAdministration` und `ReportController` unter **Verwaltung → Kundenberichte / Transporteursberichte**.
+
+- Eigene Berichtstypen aus `report_type` bzw. `report_type_2`, optional ohne Typ. Bestätigung des über `MASK_CS_REPORTTYPE_MISC_ITEM` konfigurierten allgemeinen Typs als Anwendungsdialog.
+- Halbjahreszeitraum als Vorgabe, frei wählbarer Zeitraum, Niederlassungen, Kunde/Transporteur, Text und Berichtstyp. Hauptkunden schließen direkte Unterkunden ein. Sieben Sortierungen, 100 Einträge je Seite und Gesamtzahl statt unbemerkter Begrenzung.
+- Neuanlage mit aktuellem Zeitpunkt, Benutzer und Niederlassung der Sitzung. Vorhandene Berichte bearbeiten, eigene Berichte nach Bestätigung löschen. Unveränderliche Zuordnung, Autor und Erfassungszeit. Entwurfsschutz beim Schließen, Bereichswechsel, Aktualisieren und Abmelden.
+- Rechte: 16 plus 0 (Kunden) bzw. 1 (Transporteure). Bearbeiten durch Verfasser oder Recht 3; Löschen ausschließlich durch Verfasser. Niederlassungsübergreifend nur mit Recht 10 im selben Mandanten. Vertrauliche Einträge sind nur für Verfasser bzw. Recht 10 sichtbar – ausdrücklich auch bei Zählung und Statistik. Die ältere PHP-Statistik enthält diesen Vertraulichkeitsfilter nicht; die native Fassung übernimmt dieses Datenleck nicht.
+- Statistik nach Niederlassung und Mitarbeiter, optional Berichtstyp und Kundentyp; vollständige Summen, maximal 5000 Gruppen mit ausdrücklichem Fehler bei Überschreitung, CSV mit Schutz vor Tabellenformeln. Statistik und Liste verwenden dieselben fachlichen Filter.
+- `report_process` und `appointment` verwenden MyISAM. Aktualisierung/Löschung vergleichen deshalb sämtliche ursprünglichen Berichtsfelder in **einer** bedingten SQL-Anweisung; ein `FOR UPDATE` wäre hier kein zuverlässiger Schutz. Der optionale Terminabschluss wird nach bestätigter Anlage separat ausgeführt. Scheitert er, meldet die Oberfläche den Bericht trotzdem als gespeichert und bietet eine Wiederholung an. Diese Meldung lebt in der aktuellen Ansicht; es gibt keinen dauerhaften Wiederholungsauftrag. Kundenbezug, Berichtsniederlassung und ursprünglicher Berichtstag begrenzen den Abschluss; Kurier-IDs werden nie auf Kundentermine angewendet.
+- Inzwischen ergänzt: Verkaufs-/Prüfformulare (101/102), Bearbeitung und Vorlagendruck/PDF. Offen bleiben weitere konfigurierbare Objektformulare einschließlich Upload/Template-Skripten sowie ergänzende Kundenumsatz-/Rechnungslinks. Der CRM-Folgetermin-Dialog wurde im folgenden Vertriebsblock ergänzt. Das Löschen entfernt wie PHP nur den Bericht, nicht separat gespeicherte Metafeldwerte. Der Berichtsteil ist daher noch kein vollständiger Ersatz sämtlicher PHP-Unterdialoge.
+
+## Vertriebskalender und Termine – Ergänzung vom 12. Oktober 2026
+
+Die angemeldeten PHP-Ansichten `groupware/appointment.php` (Kalender, Terminbearbeitung und Terminstatistik) wurden erneut direkt im Browser geöffnet und mit `groupware/calendar.php`, den Aktionspfaden sowie dem realen Schema und Metatypen abgeglichen. Native Umsetzung: `Appointments.tsx`, `AppointmentForm.tsx`, `AppointmentService` und `AppointmentController`; eigenes Hauptmenü **Vertrieb**.
+
+- Tagesagenda, Wochenraster, Monatskalender und Jahresübersicht mit Wechsel zum Tag/Monat, Vor-/Zurücknavigation und Heute. Mehrtägige Termine erscheinen an jedem betroffenen Tag; die Statistik zählt jeden Quelldatensatz einmal. Ein Jahresabruf umfasst höchstens 5000 Termine; darüber erfolgt eine ausdrückliche Fehlermeldung. Statistik maximal zehn Jahre / 5000 Kategoriegruppen.
+- Gemeinsame Filter nach Niederlassung, Ersteller/Teilnehmer, Kunde/Interessent, Status, Terminart, Kontrolle, Text und den fünf Sichtbarkeitsgruppen. Statistik nach allen vier Kategorien einschließlich unbekannter Bestandswerte und Kategorien ohne Treffer. Vorgabe wie PHP: eigene Niederlassung, eigener Benutzer und heutiger Tag; Statistik vom Jahresanfang bis zum gewählten Tag.
+- Anlage/Bearbeitung mit Beginn/Ende, Text, Geschäfts-/Privatstatus, Sichtbarkeit, Terminart und Überwachung. Kategorien und globale Labelüberschreibungen stammen aus dem Bestand. Kunden-/Interessentensuche, Mitarbeiter und Teilnehmergruppen, Auswahl/Abwahl der angezeigten Gruppe. Allgemeine Terminart verlangt die konfigurierte Rückfrage als Anwendungsdialog.
+- Eigene Teilnahme bestätigen; erledigen mit optionaler Prüfung eines sichtbaren Kundenberichts von heute; Wiedervorlage als separater Termin mit erhaltenem Text/Kunden-/Kontaktbezug und Teilnehmern. Erledigte Vorlagen werden wieder überwacht, Teilnahmebestätigungen der neuen Vorlage sind leer. Bei Verschiebung oder Entfernung eines Teilnehmers werden die betroffenen Bestätigungen zurückgesetzt.
+- Im Vertrieb allgemeine oder kundenbezogene Berichte öffnen. In Kundenberichten Folgetermin aus einer vorhandenen Zeile oder nach dem Speichern anlegen. Die Kundenzuordnung wird übernommen; vertraulicher Berichtstext wird nicht automatisch in den Kalender kopiert. Beim Schließen der Berichte wird der Kalender aktualisiert.
+- Rechte 0 und 11 sind gemeinsam erforderlich. Andere Niederlassungen benötigen Recht 10 und denselben Mandanten. Private Termine bleiben auf den Ersteller beschränkt, Teilnehmertermine auf Ersteller und Teilnehmer, öffentliche Termine auf den freigegebenen Niederlassungsbereich. Dies wird auch bei Statistik und direkten Änderungsendpunkten serverseitig erzwungen. PHP verwendet die Sichtbarkeit überwiegend als abwählbaren Suchfilter; diese Lücke wird nicht übernommen. Recht 3 oder 10 umgehen die private Sichtbarkeit nicht.
+- Bearbeiten: Ersteller, Teilnehmer oder Recht 3, jeweils nur bei sichtbarem Termin. Löschen: Ersteller oder Recht 3. Anders als beim alten Speichern bleiben ursprünglicher Autor, Niederlassung und vorhandene Kontakt-/Kostenstellenverknüpfungen erhalten. Bei solchen Verknüpfungen ist die Kundenzuordnung gesperrt. Neue Termine/Wiedervorlagen erhalten Autor/Niederlassung der Sitzung.
+- Die MyISAM-Tabelle `phoenix_group.appointment` wird ohne Schemaänderung verwendet. Jede Aktualisierung/Löschung vergleicht alle ursprünglichen Felder einschließlich binärem Textvergleich in derselben SQL-Anweisung. Keine Folgeabfrage nach erfolgreicher Anlage, die einen bereits gespeicherten Datensatz fälschlich als fehlgeschlagen melden könnte. Sämtliche Zugriffe über `DatabaseService`.
+- Entwurfsschutz beim Schließen, Bereichswechsel und Aktualisieren mit React-Dialogen. Inzwischen ergänzt (13. Oktober): Kontakte, Kundenstatuswechsel, Motivation-Counter und Termin-E-Mails; siehe folgenden Abschnitt. Noch offen: allgemeine Formularverwaltung, Kunden-Neuanlage und weitere CRM-Popups. Das Hauptmenü Vertrieb ist deshalb noch nicht vollständig portiert.
+
+## Kontakte und Vertriebs-Counter – Ergänzung vom 13. Oktober 2026
+
+Die angemeldeten PHP-Oberflächen Kontakte (`appointment.php`), Kontaktbearbeitung (`metafield_special.php`, Kategorie 1), `customer_switch_counter.php`, `motivationcounter.php` und die E-Mail-Optionen der Terminbearbeitung wurden im Browser geprüft. Implementierung: `SalesWorkspace.tsx`, `CrmContacts.tsx`, `SalesCounters.tsx`, `AppointmentNotification.tsx`, `ContactService`, `SalesAnalytics`, `AppointmentNotifications` und zugehörige Controller.
+
+- **Kontakte:** Karten-/Listenansicht, Teilwort-/Präfixsuche, Nachnamensinitiale, Kunden- und Niederlassungsfilter; Neuanlage, Bearbeitung, Löschen, Telefon-/Mail-Links, vCard und Druckansicht mit PDF über den Browserdruck. Alle 30 im Bestand konfigurierten Felder der Kategorie 1 werden aus Metafeldern gelesen, einschließlich Kundenbeziehung, Datumsangaben und Freitext. Feldhistorie folgt `mtfck_history`; keine neuen Tabellen. Änderungen prüfen sowohl Felddefinitionen als auch gespeicherte Werte auf Konflikte. Eine kurze exklusive Metafeld-Tabellensperre schützt MAX+1-ID-Vergabe und mehrteilige Änderungen; nur InnoDB wird dafür akzeptiert. Das DB-Konto benötigt dafür `LOCK TABLES`. Die allgemeine PHP-Template-/Skript-Engine und deren beliebige Spezialfeldtypen sind weiterhin kein Bestandteil des Kontakteditors.
+- **Kundenstatuswechsel:** Auswertung von Logtyp 95 und `SRC/OLD/NEW`, getrennt nach Auftrag/Kundenstamm und Interessent/Potential-/Wunschkunde. Erfasst ausschließlich Wechsel zum Kunden (Status 0), keine Neuanlagen ohne vorherigen Status. Einzelkundenumsätze, zugeordnete Bestandskunden und Vorjahreszuwachs; CSV mit Schutz vor Tabellenformeln. Umsatzregeln entsprechen `getCsStatistic`, einschließlich Stornozuständen, Abschlussdatum, `GLOBAL_USE_RELATED_CUSTOMER` und PHP-Schaltjahrvergleich. Die Funktion ist wie im Altmenü eine Auswertung, keine neue Kundenstammbearbeitung.
+- **Motivation-Counter:** Monatsumsatz, Auftragszahl, Ziel, Restbetrag/Überschreitung, Prozentanzeige, Niederlassungsvergleich und optionaler Vormonat in den ersten neun Monatstagen. `MOTIVATIONCOUNTER_EXCLUDED_CS` und monatliche Parameter werden gelesen; `MOTIVATIONCOUNTER_MODE=1` bestimmt die anfängliche Mehrfachauswahl. Die native Oberfläche erlaubt anschließend eine eigene Niederlassungsauswahl. Zielvorgaben werden mit dem vorhandenen niederlassungsbezogenen Counter-Passwort gelesen und geändert; vergangene Monate bleiben unveränderbar. Passwortversuche sind begrenzt; Konflikte werden vor dem Schreiben geprüft. Im geprüften Bestand existiert derzeit kein `MOTIVATIONCOUNTER_PASSWORD`, daher bleibt die Zielpflege dort bis zur Konfiguration gesperrt. Die Umsatzanzeige ist nutzbar.
+- **E-Mail-Benachrichtigungen:** Nach Termin-Neuanlage/-Änderung optional den Versand vorbereiten oder aus den Termindetails öffnen. Teilnehmer/Kopie an sich selbst, zusätzliche externe Adressen, Anrede/Grußformel und Nachrichtenarten Neu/Änderung/Absage. Vor dem Senden werden alle Empfänger, fehlende Teilnehmeradressen, Absender, Betreff und Text angezeigt. Versand erfolgt erst auf „E-Mail jetzt senden“, Empfänger stehen in BCC. Eine Absage per Mail löscht den Termin nicht; Kalenderlöschung bleibt eine eigene Aktion. Anders als PHP führt die Auswahl ausschließlich externer Empfänger nicht trotzdem zu Teilnehmermails.
+- **SMTP-Konfiguration:** PHP-Relay `smtp.pop-i.de:25` ohne Authentifizierung in `.env` übernommen; Einstellungen werden über `SMTP_HOST`, `SMTP_PORT`, `SMTP_USERNAME`, `SMTP_PASSWORD`, `SMTP_STARTTLS`, `SMTP_SSL`, `SMTP_FROM` gelesen. Leeres FROM verwendet die Mailadresse des angemeldeten Mitarbeiters. SMTP-Verbindungen haben Zeitlimits. Plaintext-Mail verhindert ungeprüftes HTML aus Termintexten. Optionales PHP-Logo/HTML-Layout wird nicht übernommen.
+- **Versandfehler:** Der Termin ist vor dem Versand gespeichert. Ein Mailfehler darf keine erneute Termin-Neuanlage auslösen. Eine 15 Minuten gültige Vorschau ist an Benutzer, Niederlassung und Terminrevision gebunden; dieselbe Vorschau wird auch bei wiederholter Bestätigung höchstens einmal an SMTP übergeben. Unklare/teilweise SMTP-Zustellung wird als solche gemeldet und nicht automatisch wiederholt. Vorschauen leben nur im laufenden Serverprozess; es gibt keine persistente Warteschlange oder automatische Zustellbestätigung.
+- **Berechtigungen:** Kundenrecht 0 und Vertriebsrecht 11; zusätzliche Niederlassungen nur mit Masterrecht 10 innerhalb desselben Mandanten. Termin-E-Mails beachten zusätzlich Termin-Sichtbarkeit und Bearbeitungsrecht; Absagen benötigen Löschrecht. Alle SQL-Zugriffe bleiben in `DatabaseService`.
+
+## Prüfgrenzen und Quellen
+
+- Sichtbare Untermenüs wurden angeklickt; Listen, Vertrieb, Statistik und Formulare zusätzlich als Seiten angesehen. Die fünf Verwaltungsuntermenüs mit dritter Ebene wurden separat geöffnet.
+- Impressum und Sprache öffneten beim Klick keinen sichtbaren neuen Dialog/Tab. Ziel und Funktion wurden deshalb über `lib/project/js/menu.js.php`, `admin/impressum.html` und `admin/language.php` bestätigt.
+- Keine Bestandsdaten bearbeitet, keine Nachrichten verschickt, keine Rechnungen erzeugt und keine Import-/Exportläufe mit Buchungswirkung gestartet.
+- Der Umfang gilt für das sichtbare Zentralenkonto. Weitere rollen- oder mandantenspezifische Menüs können hinzukommen. Dies ist ein Funktionsabgleich, keine fachliche Abnahme jedes PHP-Unterdialogs.
+- Neue Implementierung: `frontend/src/App.tsx`, `frontend/src/OrderEntryForm.tsx`, `backend/src/main/java/de/stadtbote/votian/ApiController.java`, `LegacyUser.java` und `OrderEntry*`.
+
+## Sinnvolle Reihenfolge der weiteren Portierung
+
+1. Aufträge bearbeiten, dispositionieren, abschließen und stornieren einschließlich Fahrerkommunikation und Gegenbuchungen; Listenerfassung.
+2. Kunden-/Kostenstellen- und Unternehmer-/Fahrzeugpflege; Tarif-/Rabattpflege.
+3. Rechnungen, PDF/CSV und Buchhaltungsexporte.
+4. Verwaltung, Formulare, Vertrieb/Nachrichten sowie vollständige Statistik und Datenimport.
+
+## Nachrichten, Formularverwaltung, Newsletter und Bewertungen – 13. Oktober 2026
+
+Referenz sind die angemeldeten PHP-Oberflächen `admin/mf_history.php`, `admin/newsticker.php`, `admin/metafield_editor.php`, `admin/metafield_template.php` sowie `metafield_list.php`/`metafield_special.php` für Kategorien 10 und 15. Die Newsletter-Adressatenauswahl in `include/email_send.php` und die Regeln in `inc_metafield.inc.php`/`inc_group.inc.php` wurden zusätzlich abgeglichen.
+
+- **Endgeräte:** Zeitraum, Nachrichtenart, Priorität, Zustellstatus und Kurierfilter; Lesen markieren und Antworten. Empfänger sind einzeln, per Nachrichtengruppe einschließlich transitiver allgemeiner Gruppen oder alle zuletzt aktiven Transporteure wählbar. Vorschau zeigt die tatsächlich ausgewählten Benutzer; unterschiedliche Kurierzuordnungen desselben Benutzerkontos erzeugen nur eine Nachricht. Rechte 4, Gruppenpflege zusätzlich 52, Gesamtversand zusätzlich 10. Eigene Niederlassung bzw. freigegebene Niederlassungen desselben Mandanten.
+- **MyISAM-Nachrichten:** Jede bestätigte Einfügung wird separat erfasst. Bei Verbindungsfehler bleibt die nächste Übergabe unklar; übrige Empfänger werden nicht versucht. Derselbe Vorschautoken wiederholt keinen Versand. Antworten beanspruchen den Ausgangseintrag wie PHP durch eine bedingte Zustandsänderung vor der Einfügung, damit parallele PHP-/NG-Antworten nicht doppelt versenden. Bei anschließendem Fehler bleibt der Antwortstatus gesetzt und die UI verlangt eine Prüfung der tatsächlichen Übergabe. Keine Zustellgarantie oder persistente Versandwarteschlange behauptet.
+- **Mitteilungen:** Recht 18, eigene/empfangene bzw. niederlassungsbezogene Sichtbarkeit, optional abgelaufene Einträge. Persönliche Empfänger haben Vorrang vor Niederlassungen; globale Sendungen werden auf die freigegebenen Niederlassungen des Mandanten begrenzt. Zeitraum und Textlänge folgen Bestandsparametern. Löschen nur als Verfasser oder zuständiger Niederlassungsadministrator, mit Konfliktprüfung.
+- **Formulardefinitionen:** Recht 15. Kategorien, Feldnamen/-typen, Vorlagen und allgemeine Gruppenzuordnungen; zugeordnete Felder sortieren oder ergänzen. Bestehende Feld-IDs und Werte bleiben erhalten. Individuelle Niederlassungsdefinitionen folgen `SYSTEM_FORM_SINGLE_HQ` und der jeweiligen Kategorieeinstellung. Globale Vorlagen/Definitionen werden entsprechend ihrem tatsächlichen Bestandsumfang bearbeitet. Vorlageninhalt wird vollständig geladen und exakt gespeichert; bestehende doppelte Namen oder alte Typdefinitionen verhindern keine unveränderte Übernahme. UTF-8- und SQL-Längen sowie Referenzzyklen werden geprüft.
+- **Newsletter:** Rechte 0 und 17. Die 20 aktuell konfigurierten Text-/Bildfelder werden aus Kategorie 10 gelesen. Kategoriegebundene IDs, Konfliktschutz und Feldhistorie verwenden denselben exklusiven EAV-Schreibpfad wie Kontakte. Löschen berührt nur die zugehörigen Werte, nicht gleich nummerierte Objekte anderer Kategorien. Listen-/Kartenansicht, Präfix-/Teilwortsuche, Vorschau, Browserdruck/PDF und HTML-Download.
+- **Vorlagen/Bilder:** Nummerierte Platzhalter, verschachtelte `CHK_EMPTY`/`REMOVE_EMPTY`-Blöcke und vorhandene Layouttabellen werden ausgewertet. Ausführbarer PHP-/JavaScript-Code wird nicht übernommen; unbekannte Spezialplatzhalter verursachen einen ausdrücklichen Fehler. Upload PNG/JPEG/GIF bis 300000 Bytes, tatsächliches Bildformat und Pixelgrenzen geprüft; serverseitige UUID-Dateinamen. Neue Bilder erscheinen als eingebettete Daten bzw. MIME-Inline-Anhänge. Vorhandene Bilder werden von der konfigurierten PHP-URL geladen. `FORM_IMAGES_DIRECTORY` ist standardmäßig `data/form-images` relativ zum gestarteten Backend; für gemeinsame PHP-/NG-Bildnutzung muss es auf das gemeinsame Bildverzeichnis zeigen. Nicht zugeordnete Uploads werden derzeit nicht automatisch entfernt.
+- **Newsletter-Mail:** Manuelle Adressen; mit Recht 20 zusätzlich Kundentypen/Branchen oder Gruppen. Newsletterfreigabe und vorhandene DSGVO-Einstellung werden beachtet. Cc/Bcc je Einzelmail erfordern eine ausdrückliche Auswahl. Vorschau mit Absender, Antwortadresse, Empfängerliste und Inhalt; erst der Sendeknopf startet SMTP. Persönliche Abmeldeschlüssel stammen aus `meta_object.metaobject`, identifiziert über Datenbankinstanz und Empfängerobjekt. Fehlt ein Schlüssel oder die Verbindung, wird die Vorschau abgewiesen. `META_DB_URL`, optional `META_DB_USER`/`META_DB_PASSWORD`; sonst PHP-Parameter `EXTERNAL_DB_METAOBJECT` und PHP-Fallbackadresse mit bestehenden DB-Zugangsdaten. Diese zweite Datenbank wurde nicht live getestet.
+- **Versandstatus:** Hintergrundversand mit bis zu 5000 Empfängern, Status erneut aufrufbar. Bei unbestätigter SMTP-Übergabe wird angehalten, ohne automatische Wiederholung. Vorschauen 15 Minuten, gestartete Aufträge 24 Stunden im Serverprozess; nach Neustart sind SMTP-Protokolle maßgeblich. Kein realer Newsletter und keine echte Endgerätenachricht wurden zur Prüfung verschickt.
+- **Bewertungen:** Rechte 0 und 8, Kurier-/Fahrzeugauswahl zusätzlich 1. Die neun Felder aus Kategorie 15 entsprechen der sichtbaren alten Maske: Beginn/Ende, Niederlassungen, Kunden-EID, Transporteur-EID, Fahrzeugkennung, Fahrzeugklasse, Gruppe und Branche. Datumswerte bleiben `TT.MM.JJJJ`, Niederlassungen kommasepariert. Liste/Karten, Bearbeitung, Verlauf, Ausgabe und E-Mail-Vorbereitung. Der aktuelle Bestand hat dafür keine hinterlegte Spezialvorlage; daher erfolgt eine beschriftete Feldausgabe.
+
+Offen bleiben die in der Tabelle genannten Stammdaten-/Tarif-, Auftragsbearbeitungs-, Rechnungs-, Transfer- und Statistikbereiche. „Kessel Buntes“ wurde inzwischen in der PHP-UI geöffnet und enthält 18 sichtbare Spezialansichten; die Portierung dieses Bereichs steht noch aus. Formularverwaltung bedeutet weiterhin nicht, dass alle beliebigen objektspezifischen PHP-Formulare und Template-Skripte ersetzt sind.
+
+## Auftragsfilter – Ergänzung vom 13. Oktober 2026
+
+Die angemeldete PHP-Ansicht `admin/filter.php` wurde mit eingeschalteter Verwaltung und Langtextanzeige geprüft. Quellen: `admin/filter.php`, `include/inc_filters.inc.php`, `admin/sort.php` und Bereinigungsabschnitt in `jobs/check_jb_permanent.php`. Native Umsetzung unter Verwaltung → Auftragsfilter (`FilterAdministration`, `FilterController`, `Filters.tsx`).
+
+- Globaler Katalog; Lesen mit Recht 0, Änderungen zusätzlich Recht 32. Kürzel, Bezeichnung, Fahrzeug-/Transporteursart und Pflicht-/Optionalstatus bei Neuanlage; bestehende Klassifikation bleibt wie in der PHP-UI unverändert. Langtext und Sortiernummer bearbeitbar; Kürzel-/Namensduplikate bei Neuanlage abgewiesen.
+- Löschen entfernt das Kürzel aus aktiven Kunden/Transporteuren und allen Fahrzeugen, ohne deren Änderungszeit zu verändern. Bei bereits vorhandenen doppelten Kürzeln bleiben gemeinsame Zuordnungen bestehen, solange ein weiterer Katalogeintrag existiert.
+- Tour- und geeignete offene Dauerauftragsvorlagen werden über den vorhandenen Parameter `FILTER_TO_BE_DELETED` und den PHP-Nachtlauf nachgeführt; historische Einzelaufträge bleiben unberührt. Das Kürzel ist bis zur Bearbeitung der Warteschlange für native Neuanlage gesperrt. Der Betrieb dieses vorhandenen Nachtlaufs ist Voraussetzung für diese Nachführung.
+- `courierfilter` und Protokoll sind MyISAM. Eine dauerhafte Vorgangskennung im bestehenden `genericdatacontainer` schützt native Wiederholungen. Nach Teilfehlern zeigt die Oberfläche offene Vorgänge mit Fortsetzen-Aktion; Anlage, Änderung und Löschung werden samt Protokoll 168–171 wiederaufgenommen. Die Zuordnungsbereinigung und Markierung als abgeschlossen erfolgen gemeinsam in einer InnoDB-Transaktion. Ein Konflikt mit parallelen PHP-Änderungen wird angezeigt und nicht überschrieben. Solche Konflikte können eine manuelle Klärung des Bestands erfordern. Keine neuen Tabellen.
+- Isolierter MariaDB-Test deckt Anlegen, identische Wiederholung, Konflikte, Änderungen, Löschung, Archivschutz, Zeitstempel, Kürzelsperre, doppelte Bestandskürzel und Abbruch nach MyISAM-Schreibzugriff mit Fortsetzung ab. Browserprüfung mit reinem Speicher-Fixture: Anlage, Langtext/Sortierung und Wiederaufnahme. Keine fachlichen Schreibtests in der Bestandsdatenbank.
+
+## PLZ- und Bereichsadressen – Ergänzung vom 13. Oktober 2026
+
+Die angemeldeten PHP-Masken `admin/srvpa_list.php` und `admin/srvpaa_list.php` wurden unmittelbar vor der Umsetzung angesehen. Gegenprüfung mit deren Anlage-/Such-/Löschpfaden und `include/services_func.inc.php`. Nativ: `AddressAdministration`, `AddressController`, `AddressMappings.tsx`; zwei eigene Verwaltungsbereiche.
+
+- Recht 2 und eigene Niederlassung wie im Altprogramm. Suche nach Abrechnungsziel, Straßenpräfix, PLZ, Ort, Land, Grenzen sowie zusätzlich Hausnummernmodus; sieben Sortierungen, Gesamtzahl und 100 Einträge pro Seite. Anders als PHP liefert ein ungültiges Abrechnungsziel keine ungefilterte Liste.
+- Anlage mit Straße, realer PLZ, Abrechnungs-PLZ/Bereich, Ort, Land, numerischen Hausnummerngrenzen und Alle/Gerade/Ungerade. Bereichsnamen folgen `ZIPCODEAREA_PADLENGTH`. Vorhandene identische Adressen und Zuordnungen werden wiederverwendet. Leerer Ort wird nur aus eindeutigen vorhandenen Adressen ergänzt, andernfalls ist eine Eingabe erforderlich; kein stilles Speichern von „???“.
+- Mehrfachlöschung nach Vorschau mit Vergleich des geladenen Stands; zentrale Adressdatensätze werden nicht gelöscht. MyISAM-Zuordnungen verwenden dauerhaft gesicherte, wiederaufnehmbare Vorgänge in `genericdatacontainer`. Neue InnoDB-Adressen und Vorgang werden vor dem Zuordnungsschreiben gemeinsam festgeschrieben, damit ein Abbruch keine Zuordnung ohne Adresse hinterlässt. Bereits entfernte Zuordnungen bleiben bei Teilfehlern entfernt; der Vorgang lässt sich wiederaufnehmen. Keine Schemaänderung.
+- Besondere Hausnummern aus `MASK_AREA_ID_FROM_ADDRESS_<id>` werden mit Zielbereich angezeigt. Wie in der alten Adressmaske ist diese Parameterkonfiguration hier nicht editierbar.
+- Zusätzlich Preisberechnung und Speicherung der Vermittlungs-PLZ vereinheitlicht (`LegacyAddressTariffs`): engster einschließender Hausnummernbereich, Gerade/Ungerade, Landeszuordnung und besondere alphanumerische Hausnummern. Die vorherige native PLZ-Ermittlung ignorierte Grenzen/Parität. Ausdrücklich gewählte Abrechnungs-PLZ hat weiterhin Vorrang.
+- Echte Daten nur gelesen: drei PLZ-Zuordnungen und 11.524 Bereichsadressen im geprüften Niederlassungsbereich. Schreibabläufe, konkurrierender Stand, fremde Niederlassungen und Verbindungsabbruch mit Wiederaufnahme in wegwerfbarer MariaDB geprüft. Browser-Fixture ohne echte DB: Neuanlage, Suche, Bereichswechsel und Ausnahmeanzeige; Löschdialog nur geöffnet/abgebrochen.
+
+
+## Servicepreise und Servicerabatte – Ergänzung vom 13. Oktober 2026
+
+Referenzen: angemeldete PHP-UI `admin/services.php` in beiden Servicemodi und im Rabattmodus, Typverwaltung am Seitenende sowie `admin/groupmembers.php?itemType=srv`. Quellen: `admin/services.php`, `admin/groupmembers.php`, vorhandenes Schema und `services_func.inc.php`. Native Menüpunkte unter Verwaltung → **Servicepreise / Servicerabatte**.
+
+- Allgemeine und kundenspezifische Preis-/Rabattmatrizen; getrennte Frachtvergütungswerte, einzeln einblendbar. Fahrzeugtarife (Modus 0) und Leistungen (Modus 1), Kundenfilter, Zeilenfilter, feststehende Tabellenköpfe. `MANDATOR_SERVICE_ENABLED`, `MANDATOR_SERVICE2_ENABLED`, `SERVICE_DISPLAY_MODE_DEFAULT` und spaltenweise `RIGHTS_TABLE_SERVICE` werden ausgewertet. Modus 1 berücksichtigt allgemeine zugewiesene und eigene Kundentypen.
+- Modus 0: aktuelle Werte sowie künftige Stände bis Ende des nächsten Kalenderjahres. Die künftige Ansicht zeigt wie PHP ausschließlich am ausgewählten Tag gespeicherte Werte; unbelegte Zellen sind 0. Änderungen schreiben nur die tatsächlich bearbeiteten Zellen. Preise erhalten Rabatte und umgekehrt. Historieneinträge enthalten stets alle vier Werte und den Benutzer. Ab Wirksamkeit wird der neueste gültige Historienstand gelesen; reine Lesezugriffe verändern die aktuelle Preiscache-Tabelle nicht.
+- Aktuelle Matrix, Historie und Wiederholungsschutz werden gemeinsam in vorhandenen InnoDB-Tabellen gespeichert. Keine neuen Tabellen. Bearbeitungsstand und Definitionen werden vor dem Schreiben erneut geprüft und gesperrt. Mehrdeutige Bestandszellen bleiben sichtbar, sind jedoch gesperrt. Zwei aktuelle Änderungen derselben Zelle in derselben Sekunde werden nicht als mehrdeutige Historie geschrieben; die zweite Anfrage verlangt erneutes Laden nach einer Sekunde.
+- Modus 1: Preis-/Leistungstypen anlegen, umbenennen und löschen. Löschung entfernt wie PHP ausschließlich den Katalogtyp; Preis-/Auftragshistorien bleiben bestehen. Gruppen über vorhandene Zuordnungsfelder, geschützte/unzugängliche Gruppen bleiben erhalten. Geänderte Typen aktualisieren die Matrix.
+- Rechte: Verwaltung 2, allgemeine Servicetarife zusätzlich 29; kundenspezifisch zusätzlich Kundenrecht 0 und eigene Niederlassung. Typenlöschung zusätzlich 31. Gruppenbearbeitung folgt den vorhandenen nativen Verwaltungsrechten 8 und 25, bei globalen Typen zusätzlich 10. Dies ist enger als der generische PHP-Gruppendialog (Recht 1).
+- PHP-Protokolltypen 57–60 und 131–132 werden übernommen. Da das externe Log MyISAM verwendet, wird der Typ zuerst zusammen mit einem dauerhaften Protokollauftrag gespeichert. Fehlt die Logverbindung, meldet die UI die fachliche Änderung als gespeichert und bietet „Protokoll übernehmen“ an. Wiederholungen erzeugen weder einen zweiten Typ noch einen zweiten bestätigten Protokolleintrag.
+- Noch gesondert offen: die Zuweisung allgemeiner Leistungstypen in der vollständigen Kundenstammpflege. Die bestehenden Zuweisungen werden bereits berücksichtigt.
+
+
+## PLZ-/Bereichstarife und Bereichspflege – 13. Oktober 2026
+
+- Referenzen: angemeldete PHP-Oberflächen `admin/services_plz.php` und `admin/services_plz_area.php`, jeweils Preis- und Rabattmodus; Quellcode einschließlich `getServiceVehicleTypeMappingId` in `include/global.inc.php`.
+- Vier native Verwaltungsseiten: PLZ-Preise, PLZ-Rabatte, Bereichspreise, Bereichsrabatte. Gerichtete Von-/Nach-Matrizen mit 10 × 10 Einträgen, getrennten Startwerten und unabhängiger Blätterfunktion. Gültige PLZ, Bereiche der eigenen Niederlassung; PLZ-Auswahl zeigt das Land zur eindeutigen Zuordnung.
+- Allgemeine und kundenspezifische Werte, Vergleich mit allgemeinen Tarifen in Klammern, getrennte Anzeige/Eingabe der Kunden- und Kurierwerte. Fahrzeugauswahl folgt `SERVICE_VEHICLE_TYPE_ENABLED`, `MASK_EXCLUDE_VHT_IDS` und `SERVICE_VEHICLE_TYPE_MAPPING`; die wirksame Zuordnung wird angezeigt.
+- Speicherung erhält jeweils die anderen beiden Werte und schreibt alle vier Beträge mit Benutzer und Zeit in die vorhandene Historie. Die unterschiedlichen FLOAT-Spaltengrenzen werden geprüft. Doppelte Bestandszellen sind sichtbar und schreibgeschützt; veraltete Revisionen, gleichzeitige Historienzeitpunkte und ungeklärte künftige Historien werden zurückgewiesen. Wiederholung derselben Anfrage erzeugt keine zweite Änderung.
+- Bereiche anlegen/umbenennen (maximal zehn Zeichen, eindeutiger Name je Niederlassung), vorhandene PLZ zuordnen/Verknüpfungen entfernen. Eine PLZ kann je Niederlassung nur einem Bereich angehören; Umhängen erfordert zuerst die bisherige Verknüpfung zu entfernen. Keine Bereichslöschung vorgesehen, entsprechend der PHP-Maske.
+- PLZ- und Bereichsnachbarschaften werden in beiden Richtungen angelegt/entfernt, ohne transitive Erweiterung. Alte einseitige Beziehungen können vervollständigt werden. Entfernen erfolgt nach einer Vorschau im anwendungseigenen Dialog.
+- Rechte: wie PHP Verwaltungsrecht 2, zusätzlich Kundenrecht 0 für Kundentarife; konsequente Niederlassungsabgrenzung. Alle fachlichen Schreibvorgänge einschließlich Wiederholungsbeleg erfolgen gemeinsam in den bestehenden InnoDB-Tabellen über `DatabaseService`. Keine Schemaänderungen.

docs/PRUEFSTATUS.md

@@ -1,6 +1,169 @@
-# Prüfstatus der ersten Bestandsanbindung
+# Prüfstatus
 
-Stand: 1. Oktober 2026.
+## Belegpaarpflege, gemeinsamer Storno und Lagerkorrekturen – 13. Oktober 2026
+
+- Serverquelle erneut per SSH aktualisiert (`868db70`); aktuelle PHP-Auftragsliste und Lageransicht mit Hauptlagerwahl angesehen. Nur der aktuelle Server-Snapshot wurde als PHP-Referenz verwendet.
+- Frontend-Produktionsbuild und Maven `package` mit vollständigem Backend-Testlauf erfolgreich: **430 Tests, 427 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Nach abschließenden Kompatibilitätskorrekturen gezielte Integrationsprüfungen und den vollständigen Paketbau erneut ausgeführt. Bekannt bleibt der Hinweis auf das Frontend-Bundle über 500 kB.
+- Reale Transaktionen in einer wegwerfbaren MariaDB 11.4: zusätzliche Belegpaare, Aufhebung samt Gegenbuchungen, PHP-kompatible Trennung alter Elternzuordnungen, stabile Stationsnachweise, gemeinsame Gutschrift von drei Belegen, exportierte/unexportierte Einnahmen und centgenaue Stornogebühr. Auch angebotener Auftrag mit Dauerauftragsende, Erhalt der Kurierzuordnung, Gebührenkorrektur ohne alte Preispositionen, doppelte Requests, fehlende Rechte, Export-/Rechnungsschutz und Rollback nach dem letzten Beleg geprüft.
+- Lagerprüfungen: ganzes Bündel, Wiederholung, Rollback mitten in einer Gegenbuchung, Ablehnung auftragsübergreifender Bündel, historische PHP-Zusatzdaten mit leeren Zwischenfeldern, Wiederherstellung von Seriennummerndaten, TAN und Zusatzdatum. Keine Teilbuchungen bei Fehlern.
+- Browserfixture `127.0.0.1:18744` schreibt ausschließlich synthetische Daten im Arbeitsspeicher: Belegpaar entfernen/hinzufügen, Fahrzeug suchen, Vorschau und Speichern; TAN, Zusatzdatum und Zusatzfeld erfassen, buchen und im Journal wiederfinden; gemeinsame Stornovorschau mit Einnahmenbestätigung und Speichern. Keine Browser-Konsolenfehler. Prüfbild: `work/gemeinsamer-storno-vorschau.png`.
+- Anwendung um 20:25 Uhr mit dem abschließend geprüften JAR auf Port 8080 neu gestartet. Healthcheck `UP`, Bestandsdatenbank verbunden, ausgelieferte JS-/CSS-Dateien bytegleich mit dem Produktionsbuild. Vorhandener Anwendungstab neu geladen. Temporäre Browserfixture und wegwerfbare MariaDB beendet.
+- Keine Teständerungen in der Bestandsdatenbank, keine Nachrichten an Fahrer und kein E-Mail-Versand. Offene fachliche Sonderfälle sind in [MENUE-ABGLEICH.md](MENUE-ABGLEICH.md) fortgeschrieben; vollständige PHP-Parität wird nicht behauptet.
+
+## Artikel-/Lagerbearbeitung und bestehende Unternehmerbelege – 13. Oktober 2026
+
+- Aktuelle Quelle erneut direkt von `172.16.0.158:/data/0/votian-test/html` gelesen: Git-Stand `868db70`, 13.10.2026 16:18:15 UTC. Auftragserfassung, Auftragsdetails und Lageransicht der angemeldeten PHP-UI lesend geprüft. Das separat geöffnete Calculator-Popup war für die Browsersteuerung nicht erreichbar; dessen Verrechnungslogik wurde im aktuellen Servercode geprüft. Kein Rückgriff auf den früheren lokalen PHP-Bestand.
+- Frontend-Produktionsbuild erfolgreich. Gesamter Backend-Testlauf: **430 Tests, 427 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. Nach den letzten Korrekturen gezielte Artikel-/Lager-/Unterauftrags- und SQL-Architekturprüfungen erneut erfolgreich. Maven-Paket erstellt. Bekannter Buildhinweis: Frontend-Bundle über 500 kB.
+- Neue Integration gegen wegwerfbare MariaDB 11.4 mit aktuellen Spaltendefinitionen: stabile Artikel-IDs, Scanschutz, fremde Stations-/Artikel-IDs, veraltete Revisionen, Lagerbestand und Kapazität, Seriennummernduplikate, Aus-/Gegenbuchung einschließlich aller 25 Zusatzdatenfelder, wiederholte Request-IDs, Rechte-/Niederlassungsgrenzen und vollständiger Rollback bei Fehlern. Hauptauftrag 170 Euro, Unternehmerbeleg 60 Euro, Gegenbeleg −60 Euro inklusive Servicepreis/Zuschlag geprüft. Erhalt von Tour-IDs und Zustellnachweisen, zwischenzeitliche Gegenbelegänderung, abgerechneter Gegenbeleg und Rücknahme aller Änderungen bei einem Fehler am zweiten Beleg geprüft.
+- Browserprüfung am ausschließlich lokalen Testserver `127.0.0.1:18744`: Artikel bearbeiten/speichern, geschützte Positionen, Stammartikelauswahl und erneuter Wechsel, Lagereingang mit Vorschau und Gegenbuchung, Unternehmerfahrzeug wechseln, gemeinsame Kalkulation anzeigen/übernehmen. Keine Konsolenfehler. Backend-Buchungen werden durch die Datenbanktests geprüft; der UI-Server verwendet synthetische Antworten und schreibt ausschließlich in den Arbeitsspeicher. Screenshot: `work/artikel-lager-bestandsauftrag.png`.
+- Anwendung um 18:50 Uhr auf Port 8080 neu gestartet. HTTP/Health erfolgreich; ausgeliefertes JavaScript stimmt bytegenau mit dem neuen Frontend-Build überein. Der offene Browser-Tab wurde neu geladen.
+- Keine Schreibprobe gegen Geschäftsdaten. Kein Versand an Fahrer, E-Mail-Empfänger oder externe Fachdienste. Die Testdatenbank enthält ausschließlich synthetische Stammdaten und Aufträge.
+- Grenzen dieses früheren Prüfstands (inzwischen erweitert, siehe oben): einfache bestehende Unternehmerpaare können geändert werden; zusätzliche Paare, Entfernung und gemeinsames Storno bleiben offen. Lagerkorrekturen erfolgen durch zusätzliche Journalbuchungen. Historische Seriennummern-Auslagerungen ohne gesicherte Zusatzdaten, Bündel- und Spezialbewegungen benötigen weiterhin die vollständige Lagerverwaltung. Weitere offene Menübereiche stehen in [MENUE-ABGLEICH.md](MENUE-ABGLEICH.md).
+
+
+## Ergänzte Teilfunktionen – 13. Oktober 2026
+
+- Aktuelle SSH-Quellen und angemeldete PHP-Oberflächen für Auftrag, Gruppen, Anfahrtszeiten, Berichte/Formulare und Kunden-Servicezuordnung geprüft. Ausschließlich Server-Snapshot `work/php-current-2026-10-13`; keine Verwendung des ursprünglichen lokalen PHP-Bestands.
+- Frontend-Produktionsbuild und Maven `package` mit isolierter MariaDB 11.4 erfolgreich: **429 Tests, 426 bestanden, 0 Fehler, 3 optionale Live-Prüfungen übersprungen**. SQL-Architekturprüfung erfolgreich; verbleibender Hinweis auf die Frontend-Bundlegröße.
+- Integrationen: reale Neukalkulation vorhandener Aufträge ohne zusätzliche Aufträge/Stationen, Zahlungsbedingung neben Kilometerposition 16, Speichern/Wiederholen, Berichtsformularrechte und Vertraulichkeit, unveränderte fremde Kategorien, Rollback bei Historienfehler, veraltete Revisionen. Gruppenlöschung und Kunden-Servicezuordnungen jeweils mit künstlichem Fehler nach bereits erfolgtem MyISAM-Schreiben und erfolgreichem Fortsetzen geprüft.
+- Lesend am echten Bestand: Zahlungsbedingungscodes/-texte, Niederlassungs-Anfahrtsstandards, beide Berichtsformulare (23/109 Felder) nativ gerendert, Kunden-Serviceauswahl mit 34 Preis- und 22 Leistungstypen über beide Modi geladen.
+- Isolierte Browserfixture: Kalkulation speichern, 0-Minuten-Fallback, Niederlassungswechsel und Gruppen-Löschvorschau; Berichtsvorlagen mit Eingaben/Checkboxen speichern; Kunden-Serviceauswahl ändern, sortieren und speichern. Schreibtests ausschließlich gegen disposable MariaDB bzw. simulierte Browser-API. Keine echten Aufträge, Nachrichten, Lagerbewegungen oder Stammdaten zu Testzwecken verändert.
+- Abschließende Layoutkorrektur: mehrzeilige CSS-Selektoren aus den PHP-Vorlagen erhalten; Klassenregeln im Formulareditor auf dessen eigenes Element begrenzt. Speichern und erneutes Öffnen mit sichtbaren Werten im Browser geprüft.
+- Prüfbilder: `work/teilfunktionen-kalkulation.png`, `work/teilfunktionen-gruppen.png`, `work/teilfunktionen-berichtsformular.png`, `work/teilfunktionen-kundenservices.png`.
+- Anwendung am 13. Oktober 2026 um 18:11 Uhr mit dem abschließend geprüften JAR auf Port 8080 neu gestartet. Healthcheck `UP`, Bestandsdatenbank verbunden, ausgelieferte JS-/CSS-Dateien identisch zum Produktionsbuild. Vorhandener Browser-Tab neu geladen; Anmeldemaske zeigt die verbundene Datenbank. Temporäre Browserfixture und disposable MariaDB beendet.
+- Die verbleibenden Funktionslücken stehen im aktuellen Menüabgleich; dieser Stand behauptet keine vollständige PHP-Parität.
+
+
+## Auftragsbearbeitung, Stammdaten, Abrechnung und aktueller Serverabgleich – 13. Oktober 2026
+
+- PHP-Referenz ausschließlich per SSH von `root@172.16.0.158:/data/0/votian-test/html`. Angemeldete PHP-Auftragsdetails, Stammmasken, Rechnungsübersicht/-zuordnung und Foto-Set-Auswahl angesehen; Kundenlisten-Schalter zusätzlich geöffnet. Keine fachlichen Teständerungen in der Altanwendung gespeichert.
+- Maven `verify` mit isolierter MariaDB 11.4: **412 Tests, 409 bestanden, 0 Fehler, 3 optionale Bestandsprüfungen übersprungen**. Frontend-Produktionsbuild erfolgreich; verbleibender Hinweis auf Bundlegröße über 500 kB. SQL-Architekturprüfung erfolgreich.
+- Integrationsprüfungen: Kunden/Kurier/Fahrzeug/Kostenstellen anlegen/ändern, historische Adressen erhalten, Hierarchiezyklen und fremde Niederlassungen abweisen; Auftragsbearbeitung, Preisberichtigung, Abschluss, alte Empfänger erhalten, Storno-Gegenbuchung, Rechnungszuordnung mit künstlichem Verbindungsfehler nach MyISAM-Insert, Fortsetzen/Abbruch, Konflikte mit nachträglicher Bestandsänderung, CSV/PDF und Audit-Wiederholung.
+- Neue Foto-Prüfungen: Freigaben, Setgrenzen, globale Rückfallebene, Positionsvorrang/Einzelstation, PHP-Stationskennzeichen, Set zuerst/Overrides danach, Wiederholung und Fehler ohne Dispositionsfreigabe. Adressprüfungen: unabhängige Stammdatenrechte, Schlüssel ausschließlich serverseitig, vollständige/fehlende Komponenten, fremde Länder, deutsche PLZ-Präfixe und externe Fehler. Kostenstellensuche auch gegen die isolierte DB mit Teilwort, SQL-Sonderzeichen, Kunden-/Niederlassungsgrenzen und mehreren Kostenstellen.
+- Lesend am Bestand geprüft: neue Stamm-/Auftrags-/Abrechnungsabfragen, vier freigegebene Foto-Sets mit insgesamt 16 Workflows, fünf begrenzte Kunden-/Kostenstellenzeilen mit IDs. Google-Suche mit öffentlicher Adresse „Pariser Platz 1 Berlin“: drei Vorschläge; Auswahl liefert Straße, Hausnummer, PLZ, Ort und Land. Keine Fotos/Set-Zuordnungen an den echten Fotodienst geschrieben.
+- Browser unter `127.0.0.1:18744` mit isolierter API-Fixture: Auftragsänderung und Abschluss, Stammdaten und Kostenstellenadresse speichern, Rechnungsnummer zuordnen, PDF herunterladen; anschließend Kostenstelle suchen/direkt öffnen, Google-Vorschlag simuliert übernehmen/speichern, Foto-Set wechseln, Stationsabweichung wählen, Preisvorschau und Auftrag speichern. Requestprüfung bestätigt Foto-Set 2 und Stationsauswahl 0/null. Keine Konsolenfehler/-warnungen. Nachweise: `work/abrechnung-ui-test.jpg`, `work/kostenstellensuche-ui.jpg`, `work/stammdaten-adressvorschlag-ui.jpg`, `work/foto-sets-ui.jpg`.
+- Grenzen: Geschäftsdatenschreibtests ausschließlich disposable DB bzw. Browserfixture. Echte Fahrergeräte, Fotoübertragung, vollständige Rechnungsausgabe und Buchhaltung nicht live schreibend geprüft. Die dokumentierten offenen Teilfunktionen im Menüabgleich bleiben offen.
+- Anwendung am 13. Oktober 2026 um 16:45 Uhr mit dem aktuellen JAR auf Port 8080 neu gestartet. Enthaltene Frontend-Datei entspricht dem Produktionsbuild; Healthcheck `UP`, Bestandsdatenbank verbunden, keine Schemaänderungen. Vorhandener Browser-Tab neu geladen und Anmeldemaske geprüft.
+
+## Parameterdatenbank und Google-Geokodierung – 13. Oktober 2026
+
+- Bereitgestellten Zugang zu `172.16.0.111:3711/phoenix` getrennt vom Hauptdatenbankzugang in der ignorierten lokalen `.env` gespeichert; Dateirechte 0600.
+- Anmeldung und fester SELECT auf den Google-Parameter erfolgreich. Einmaliger Kompatibilitätsimport für `mysql_old_password` und den alten Server ohne READ-ONLY-Transaktionen; alle SQL-Abfragen über `DatabaseService`, keine Schreibanweisungen. Laufenden Anwendungstreiber und dessen Schutzmechanismen unverändert gelassen.
+- Schlüssel als `GOOGLE_MAPS_API_KEY` übernommen. Öffentliche Beispieladresse Brandenburger Tor, Berlin über Google Geocoding per HTTPS geprüft: `OK`, ein Ergebnis. Kein Auftragsdatensatz angelegt, keine Zugangsdaten ausgegeben.
+
+## PLZ-/Bereichspreise, Rabatte und Bereichspflege – 13. Oktober 2026
+
+- Alle vier angemeldeten PHP-Masken und ihre Speicher-/Zuordnungsregeln vor der Umsetzung geprüft. Echtes Schema und Daten nur lesend: PLZ und Bereiche jeweils 10 × 10 Zellen, keine mehrdeutigen Tarifzellen; erster Bereich mit zwei PLZ-Zuordnungen wie in der Altmaske. Lesezeit im Probeaufruf ca. 268 bzw. 110 ms.
+- Frontend-Produktionsbuild und vollständiges Maven `clean verify` mit isolierter MariaDB 11.4 erfolgreich: **391 Tests, 388 bestanden, 0 Fehler, 3 optionale Bestandsprüfungen übersprungen**. SQL-Architekturprüfung unverändert.
+- Neue Tests prüfen Zugriffsrechte/CSRF, Feldpräzision, Kunden-/Niederlassungsgrenzen, Fahrzeugzuordnung, Blättern, Richtungstrennung, Preis-/Rabatt-Erhalt, Historie, veraltete Revisionen, doppelte Zeilen und Wiederholungsbelege. Bereichsnamen, eindeutige PLZ-Zuordnung je Niederlassung, symmetrische und nicht transitive Nachbarschaften, Reparatur einseitiger Verknüpfungen sowie Rollback bei fehlendem Rückweg bzw. Beleg getestet.
+- Isolierte Browserfixture auf Port 18744: PLZ-Preis und Frachtvergütung speichern/erneut lesen, Zeilen blättern; Bereich anlegen/umbenennen, PLZ verknüpfen/entfernen, Nachbarn hinzufügen und auf Gegenseite kontrollieren sowie entfernen. Kundenspezifische Bereichsrabatte einschließlich Fahrzeugzuordnung und Vergleichswerten gespeichert. Entwurfsschutz über eigenen Dialog bestätigt, keine Konsolenwarnungen/-fehler. Nachweise: `work/bereichsrabatte-ui-test.png`, `work/bereichspflege-ui-test.png`.
+- Anwendung um 15:00 Uhr mit dem geprüften JAR auf Port 8080 neu gestartet. Der vorhandene Browser-Tab zeigt die Anmeldung.
+- Geschäftsdatenschreibtests ausschließlich gegen disposable MariaDB bzw. Browserfixture. Keine Teständerungen in der Bestandsdatenbank. Die vorhandenen InnoDB-Schreibtabellen wurden ohne Schemaänderung weiterverwendet.
+
+## Servicepreise, Servicerabatte und Typverwaltung – 13. Oktober 2026
+
+- Alte angemeldete PHP-Matrizen in beiden Servicemodi, Rabattmodus, Preis-/Leistungstypverwaltung und Gruppenmaske mit Quellen abgeglichen.
+- Bestandsdatenbank nur lesend geprüft: Modus 0 mit 9 × 20 Zellen, Modus 1 mit 13 × 14 Zellen; keine mehrdeutigen Zellen. Typverwaltung liest 14 Preistypen, 13 Leistungstypen und 239 freigegebene Gruppen. Kundensuche liefert die begrenzte Auswahl von 100 Bestandskunden.
+- Frontend-Produktionsbuild und vollständiges Maven `clean verify` mit isolierter MariaDB erfolgreich: **383 Tests, 380 bestanden, 0 Fehler, 3 optionale Bestandsprüfungen übersprungen**. Zusätzliche Integrationsprüfungen decken Preis-/Rabatt-Erhalt, Wirksamkeitsdatum, Kunden-/Niederlassungsgrenzen, Konflikte, doppelte Bestandszeilen, Rollback, wiederholte Speicherung, Typenpflege und Protokollwiederaufnahme vor und nach erfolgtem MyISAM-Insert ab.
+- Isolierter Browser-Test auf Port 18744: deutsche Dezimaleingaben, Preis-/Rabatt-Speicherung, Kundenauswahl, Zukunftsdatum, Anzeigeumschalter, Typ-Neuanlage mit Gruppe, Umbenennung, Löschvorschau und Entwurfsschutz. Keine Konsolenwarnungen oder -fehler. Nachweis: `work/servicepreise-ui-test.png`. Keine fachlichen Schreibtests gegen die Bestandsdatenbank.
+- Anwendung am 13. Oktober 2026 um 14:28 Uhr mit dem geprüften JAR auf Port 8080 neu gestartet; Start erfolgreich. Der vorhandene Browser-Tab zeigt die Anmeldung.
+- Grenzen: Browser-Schreibtest mit API-Fixture, Datenbank-Schreibtest mit disposable MariaDB; keine behauptete Live-Schreibprüfung. PLZ-/Bereichstarifpflege wurde anschließend ergänzt (siehe neuesten Prüfstand oben).
+
+## Auftragsfilter und Adresszuordnungen – 13. Oktober 2026
+
+- Vorheriger abgeschlossener Build: **374 Tests, 371 bestanden, 3 optionale Live-Prüfungen übersprungen**.
+- Angemeldete PHP-Filterverwaltung mit Langtexten sowie PLZ-/Bereichsadressmasken und Quellen geprüft. Bestandsabfragen: 92 Filter, 0 offene Filtervorgänge, 3 PLZ-Adresszuordnungen und 11.524 Bereichsadresszuordnungen (erste 100 geladen).
+- Isolierte UI- und MariaDB-Tests prüfen Filterpflege, wiederaufnehmbare MyISAM-Vorgänge, Hausnummernbereiche/Parität, Bereichsauffüllung, Ausnahmezuordnung und Löschvorschau. Nachweise: `work/filter-ui-test.png`, `work/plz-adressen-ui-test.png`, `work/bereichsadressen-ui-test.png`.
+
+
+## Nachrichten, Formulardefinitionen, Newsletter und Bewertungen – 13. Oktober 2026
+
+- Angemeldete alte PHP-Masken und Aktionspfade vor der Umsetzung geprüft. Echte Datenbank ausschließlich lesend: Nachrichten-/Mitteilungstabellen samt Engine, 39 Formularkategorien, 580 Felddefinitionen, 28 Vorlagen; Newsletter 20 Felder, Bewertungen neun Felder. Alle sechs Bewertungsauswahlen liefern Bestandsdaten; Bewertungsvorlage im Bestand leer (ID 0).
+- Frontend-Produktionsbuild erfolgreich. Maven `verify` mit isolierter MariaDB 11.4: **362 Tests, 359 bestanden, 0 Fehler, 3 optionale Bestandsprüfungen übersprungen**. SQL-Architekturprüfung unverändert. Kontakt- und Bewertungsabläufe gegen die isolierte DB prüfen IDs, Kategorienabgrenzung, Historie, Konflikte, Löschung und Rollback.
+- Nachrichtenprüfungen: unabhängige Rechte, Niederlassungs-/Empfängergrenzen, veraltete Revisionen, MyISAM-Teilfehler, derselbe Versandtoken, Benutzer-Deduplizierung, konkurrierende Antwortbestätigung und Gruppenlöschung mit Mitgliedern. Keine echten Endgerätenachrichten geschrieben.
+- Newsletterprüfungen: UTF-8 und Bildformat/-größe, Kategorien-/Feldabgrenzung, Vorlagen-Sanitizing, verschachtelte Leerblöcke, persönliche Abmeldeschlüssel, Einwilligungen/Empfängerauswahl, fremde Tokens, geänderter Inhalt und unklare SMTP-Zustellung. HTML, Textalternative, Inline-Bilder sowie Cc/Bcc per SMTP ausschließlich an lokalen Testserver übergeben. Keine externe E-Mail; zentrale Metadatenbank für Newsletter-Abmeldeschlüssel nicht live geprüft.
+- Isolierte UI-Fixture auf Port 18744: Endgeräteantwort und Mitteilung, Nachrichtengruppe mit allgemeiner Gruppe anlegen und direkten Transporteur zuordnen; Formulardefinitionen sortieren/ergänzen, Vorlageninhalt speichern/erneut lesen; Newsletter bearbeiten, Ausgabe, Versandvorschau und Ergebnis; Bewertung mit Zeitraum, Niederlassung und Kunde anlegen/erneut öffnen/ausgeben. UI-Mailversand simuliert, ohne SMTP. Bild-Upload-Dialog nicht per Browser bedient; Bildvalidierung automatisiert geprüft.
+- Prüfbilder: `work/nachrichten-ui-test.jpg`, `work/nachrichtengruppen-ui-test.png`, `work/formulare-ui-test.png`, `work/newsletter-ui-test.png`, `work/newsletter-versand-ui-test.png`, `work/bewertungen-ui-test.png`.
+- Verbliebene Funktionslücken und betriebliche Grenzen stehen im [Menüabgleich](MENUE-ABGLEICH.md). Der gesamte Menüumfang ist weiterhin nicht abgeschlossen.
+
+## Kontakte, Kundenstatuswechsel, Motivation-Counter und E-Mail – 13. Oktober 2026
+
+- PHP-Oberflächen und Source für alle vier Bereiche abgeglichen; echtes Schema und Metafelddefinitionen ausschließlich lesend geprüft. Berlin besitzt 30 Kontaktfelder; im aktuellen Bereich keine Kontakte. Der native Motivation-Counter liefert wie die PHP-Seite 2 abgeschlossene Aufträge und 82,98 € für Oktober 2026.
+- `npm --prefix frontend run build` erfolgreich. `CRM_INTEGRATION_URL=jdbc:mariadb://127.0.0.1:33079/crm_qa backend/mvnw -q -f backend/pom.xml verify`: **293 Tests, 290 bestanden, 0 Fehler, 3 optionale Bestandsprüfungen übersprungen**. Die Architekturprüfung bleibt unverändert: Raw-JDBC nur im eigenen `DatabaseServiceTest`; alle Geschäftsabläufe benutzen `DatabaseService`.
+- Separate temporäre MariaDB 11.4 ausschließlich für Tests: Kontakt-Neuanlage mit zwei parallelen Schreibern, eindeutige IDs, Aktualisierung, Konfliktschutz, Feldhistorie, Löschung und vollständiges Rollback nach Teiländerung geprüft. Keine Schema- oder Geschäftsdatenänderungen in der vorhandenen VoTiAn-Datenbank.
+- Benachrichtigungen: Empfängerabgrenzung, Deduplizierung, fehlende Adressen, Header-Injection, geänderte Terminrevision, falscher Benutzer, doppelte Bestätigung und SMTP-Fehler automatisiert geprüft. Echte SMTP-Protokollkommunikation nur gegen einen lokalen Testserver, mit UTF-8 und BCC-Empfängern. **Keine echte E-Mail gesendet; Relay-Zugang/Zustellung extern nicht getestet.**
+- Isolierte Browserfixture auf Port 18744: Kontakte anlegen/ändern, Verlauf, Entwurfsschutz, Druckansicht, Kundenstatusauswertung, Niederlassungsvergleich, passwortgeschützte Zielpflege sowie Benachrichtigung nach Termin-Neuanlage und Versandvorschau/Versandergebnis bedient. Keine Konsolenfehler. Abnahmebilder: `work/crm-motivation-ui.jpg`, `work/crm-mail-ui.jpg`.
+- Aktuelles JAR mit identischem Frontend-Build auf Port 8080 neu gestartet. Bestehende Anmeldung wiederverwendet; Verbindung zum Bestand und neue Kontaktfelder/Umsatzansicht im Browser geprüft. Die Statusauswertung über alle freigegebenen Niederlassungen zeigt die im PHP-Abgleich vorhandenen Bestandskundenzuordnungen für DD, HB und L. Keine Browser-Konsolenfehler. Die Zielpflege erfordert den im Bestand noch fehlenden Parameter `MOTIVATIONCOUNTER_PASSWORD`.
+- Funktionsumfang und bewusste Unterschiede stehen im [Menüabgleich](MENUE-ABGLEICH.md).
+
+
+## Vertriebskalender und Termine – 12. Oktober 2026
+
+- Alte PHP-Kalender-, Bearbeitungs- und Statistikoberfläche im angemeldeten Browser angesehen; Aktionspfade, Tabellenengine, Teilnehmerformat, Metatypen und Parameter anhand von PHP/Schema geprüft.
+- Frontend-Produktionsbuild und Maven `verify` erfolgreich: **265 Backend-Tests bestanden, 3 optionale Live-Tests übersprungen, keine Fehler**. 21 neue Prüfungen für Rechte/CSRF, unverzichtbare Sichtbarkeit in Liste und Statistik, Mandantengrenzen, Zeitraum/Überlappung, Teilnehmer, UTF-8-Länge, unveränderliche Altverknüpfungen, Revision/MyISAM-Konflikte, eigene Bestätigung, Terminabschluss und Wiedervorlage.
+- Echte Datenbank ausschließlich gelesen: Optionen mit 151 Mitarbeitern und sechs verfügbaren Gruppen, Kundensuche, Jahresliste und Statistik 2026 (0) sowie 2025 (1) für die eigene Niederlassung erfolgreich. Die Zahlen sind auf die Sichtbarkeit dieses Kontos beschränkt, keine globale Bestandszählung.
+- Isolierter Browser-Server ohne DB-Anbindung: Tag/Woche/Monat/Jahr, mehrtägiger Termin, Bestätigung der eigenen Teilnahme, Bearbeitung/Terminverschiebung, Entwurf behalten, Termin erledigen, Wiedervorlage, Folgetermin aus Kundenbericht samt Teilnehmergruppe und Rückfrage für allgemeinen Terminartwert geprüft. Die Statistik zählt vier Testtermine, obwohl ein Termin in zwei Tageszellen erscheint. Keine echten Geschäftsdaten angelegt, geändert oder gelöscht.
+- Datumseingaben im eingebetteten Browser verwenden native Input-Ereignisse; geänderte Uhrzeiten wurden nach dem Speichern erneut angezeigt. Löschrechte, unzugängliche Termine und konkurrierende Änderungen sind automatisiert gegen Mocks geprüft. Die eigenständige Playwright-Suite wurde nicht ausgeführt.
+- Finales JAR mit dem aktuellen Frontend neu gestartet. Bestehende Browser-Anmeldung wiederverwendet, DB-Status verbunden; Vertriebskalender 2025 zeigt den vorhandenen sichtbaren Termin, Tagesansicht wieder auf heute gesetzt. Keine Browser-Konsolenfehler. Abnahmebild mit isolierten Testdaten: `work/vertrieb-ui-test.jpg`.
+- Offener Funktionsumfang und bewusste Unterschiede zur PHP-Fassung: [MENUE-ABGLEICH.md](MENUE-ABGLEICH.md), Abschnitt Vertriebskalender.
+
+## Kunden- und Transporteursberichte – 12. Oktober 2026, weiterer Verwaltungsblock
+
+- PHP-Oberflächen für beide Berichtsarten und die Berichtsstatistik im angemeldeten Browser angesehen, Quellcode und reale Metatypen/Tabellenschemata abgeglichen.
+- Frontend-Produktionsbuild und Maven `verify` erfolgreich: **244 Backend-Tests bestanden, 3 optionale Live-Tests übersprungen, keine Fehler**. 16 zusätzliche Prüfungen sichern Berichtsrechte, CSRF, Mandantengrenzen, Vertraulichkeit in Liste/Zählung/Statistik, Hauptkundenbezug, SQL-Parameter, UTF-8-Länge, Revisionen und konkurrierende MyISAM-Änderungen ab. Der Fehlerfall beim nachgelagerten Terminabschluss darf keine doppelte Berichtsanlage auslösen.
+- Echte Datenbank ausschließlich per SELECT geprüft: beide Optionen-/Objektsuchen und sämtliche sieben Sortierungen, Statistik mit Aufteilung. Ergebnis für eigene Niederlassung und 01.07.–12.10.2026: drei Kundenberichte / null Transporteursberichte; Liste und Statistik stimmen mit der alten Oberfläche überein.
+- Isolierter Browser-Server ohne Datenbank: vorhandenen Kundenbericht bearbeitet und vertraulich gemacht; Abbrechen/Weiterbearbeiten erhält den Entwurf; neuen Transporteursbericht angelegt, allgemeiner Berichtstyp ausdrücklich bestätigt; Berichtsstatistik nach Typ/Kundentyp und CSV-Datei inhaltlich geprüft. Keine echten Berichte oder Termine angelegt, geändert oder gelöscht. Löschrechte und konkurrierende Löschung sind automatisiert mit Mock-Daten geprüft.
+- Anwendung mit dem gebauten JAR neu gestartet. Bestehende Anmeldung verwendet, Datenbankstatus verbunden; native Kundenberichtsliste mit drei Einträgen und Berichtsstatistik im echten Backend angezeigt, keine Browser-Konsolenfehler.
+- Umsetzungsgrenzen, insbesondere Zusatzformulare (CRM-Termin-Neuanlage im späteren Vertriebsblock ergänzt), stehen im [MENUE-ABGLEICH.md](MENUE-ABGLEICH.md). Die automatisierte Playwright-Suite wurde nicht ausgeführt; Bedienprüfungen erfolgten über den integrierten Browser.
+
+## Verwaltung und Zeitraumstatistik – 12. Oktober 2026
+
+- Die alten PHP-Ansichten für Feiertage, Anfahrtszeiten, Gruppen, Impressum und Statistik wurden vor der Portierung im angemeldeten Browser geprüft. Listenerfassung, Filter und Berichte wurden ebenfalls angesehen und waren in diesem Prüfstand noch offen; der spätere Berichtsblock ist oben dokumentiert. Umfang und Abweichungen: [MENUE-ABGLEICH.md](MENUE-ABGLEICH.md).
+- Frontend-Produktionsbuild erfolgreich; Backend: **228 Tests bestanden, 3 optionale Live-Tests übersprungen**, keine Fehler. Die 23 zusätzlichen Tests prüfen unter anderem Revisionen, Rechte, geschützte Tage/Systemgruppen, Zeitfenster, Gruppenzyklen, SQL-Parameter, getrennte Statistikrechte und CSRF.
+- Isolierter Browsertest ohne DB: Feiertage aus Vorlage übernehmen/speichern, CLASSIC-/BWV-Trennung und einzelne Anfahrtszeit speichern, Gruppe anlegen, Mitglied hinzufügen/entfernen, Vergleichsstatistik mit 1234 Aufträgen und CSV-Download. Der Schutz ungespeicherter Eingaben wurde als Anwendungsdialog geprüft. Keine Löschaktion gegen den echten Bestand.
+- Echte SELECT-Prüfungen: Feiertagsansicht, Gruppenliste, alle elf Mitgliedsarten, CLASSIC/BWV sowie alle zwölf Statistikaufteilungen erfolgreich. Ein Zeichensatzkonflikt bei Fahrzeugtypnamen wurde dabei gefunden und korrigiert. Keine echten Verwaltungsdaten geschrieben.
+- Die bestehenden Browsertests wurden auf die serverseitige Statistik umgestellt; die automatisierte Playwright-Suite wurde in diesem Durchlauf nicht ausgeführt. Die genannten Bedienprüfungen erfolgten über den integrierten Browser.
+
+## Freie Artikel, Tastenkürzel, Nachhaltigkeit und Niederlassungen – 12. Oktober 2026
+
+- Frontend-Build erfolgreich; Backend: **205 bestanden, 3 optionale Live-Tests übersprungen**, keine Fehler. Prüfung von freien Artikeln/Vorlagen, Eingabegrenzen, CO₂e-Vertrag/Cache/Preiszeilen, Niederlassungsrechten und isoliertem Anfragekontext.
+- Isolierte Browserprüfung: freie Artikel, manuelle Nachhaltigkeitsvorschau, Alt+E/G/S/L, Unterdialogschutz und bestätigter Niederlassungswechsel. Speichern am Fixture-Server gesperrt. Gewünschte Hinweisbox entfernt.
+- Sieben neue Rechte-/Fahrzeugspalten und neun freigegebene Niederlassungen des Zentralenkontos per SELECT bestätigt. Keine echten Aufträge/Lagerbuchungen angelegt.
+- CO₂e-Zugangsdaten und PZM-Endpunkt autorisiert in lokale ignorierte `.env` übernommen. Aktiver Google-Schlüssel aus separater PHP-Parameterquelle wegen Zugriffsverweigerung nicht abrufbar. Kein erfolgreicher Live-Lauf externer Berechnungsdienste behauptet.
+- Altmenü mit Untermenüs im Browser und PHP geprüft: [vollständiger Menüabgleich](MENUE-ABGLEICH.md).
+
+
+## Kostensplit, Unteraufträge, Artikel/Lager und Karte – 12. Oktober 2026
+
+- Die vier Funktionen sind in der nativen Erfassung implementiert. Fachliche Grenzen und Bestandsparameter: [AUFTRAGSERFASSUNG.md](AUFTRAGSERFASSUNG.md).
+- Frontend-Produktionsbuild und Maven-Testlauf erfolgreich: **190 Tests bestanden**, 3 optionale Live-Integrationstests übersprungen, keine Fehler. Die Tests umfassen Kostenrundung, Unteraufträge/Gegenbuchungen, Rechte, Idempotenz, Lagerbestände und Sperren, Seriennummern, Rollback, Vorlagenkopien und Kartenkoordinaten.
+- Browserprüfung mit isolierten API-Antworten: Eingabe und Vorschau aller vier Funktionen, Lagerauswahl, Kartenfehler/Übernahme und stabile Artikelzuordnung beim Umordnen der Stationen. Speichern am Fixture-Server gesperrt.
+- Bestandsprüfung ausschließlich mit SELECT: Artikel-/Lagerspalten und InnoDB, Kartenparameter und technische Verrechnungskostenstellen. Keine echten Auftrags-, Verrechnungs- oder Lagerbuchungen angelegt. Eine reale fachliche Abnahme mit PHP-Abrechnung bleibt erforderlich.
+- Die folgenden Abschnitte dokumentieren frühere Prüfstände.
+
+## Sonderprozesse der Auftragserfassung – 12. Oktober 2026
+
+- Fotoworkflows je Kunde/Station, automatische Kilometer-/PZM-Kalkulation, Fernverkehr/ASAP und Auslandsabholung sind implementiert; Details und Dienstkonfiguration: [AUFTRAGSERFASSUNG.md](AUFTRAGSERFASSUNG.md).
+- Frontend-Build und Maven `verify`: erfolgreich. **145 Backend-Tests bestanden**, 3 optionale Live-Integrationstests deaktiviert. Neue Tests prüfen unter anderem Fotoübertragung mit wiederaufnehmbaren Leases ohne HTTP unter Datenbanksperren, Stationsauswahl/Barzahler, PHP-Preismarker, Mindestpreise, Fernverkehr, Auslands-Rundfahrten, fehlerhafte Dienstantworten und begrenzte HTTP-Antworten.
+- **36 Playwright-Prüfungen bestanden**, darunter 11 Erfassungsprüfungen. Die Sonderprozess-Vorschau wurde zusätzlich visuell geprüft. Browser-APIs sind vollständig simuliert; der Testserver verwendet ausdrücklich eine unerreichbare Datenbankadresse.
+- **28 Python-Tests bestanden.**
+- Ausschließlich lesend gegen den Bestand geprüft: benötigte HQ-Spalten, PLZ-Geodaten/-Polygone und Vorhandensein der Foto-, Fernverkehrs- und PZM-Parameter. Keine Parameterwerte mit Zugangsdaten wurden ausgegeben. Der Geocache und lokale PZM-/Google-Verbindungsparameter sind in der erreichbaren DB nicht vorhanden; `PZM_URL` und `GOOGLE_MAPS_API_KEY` müssen über die Umgebung bereitgestellt werden.
+- Keine produktiven Aufträge oder Fotoauswahlen angelegt. Ein echter Durchlauf mit PZM, Fotodienst, PHP-Disposition, Fahrergerät und Abrechnung steht noch aus.
+
+## Auftragserfassung – 12. Oktober 2026
+
+Die native Erfassung ist für Sofortaufträge, Vorbestellungen, Daueraufträge, Barzahlung, Fahrzeugzuweisung und Nacherfassung implementiert. Fachlicher Umfang und verbleibende Grenzen: [AUFTRAGSERFASSUNG.md](AUFTRAGSERFASSUNG.md).
+
+- Frontend-Produktionsbuild und Maven `verify`: erfolgreich. 117 Backend-Tests bestanden; die 3 ausdrücklich optionalen Live-Integrationstests waren in diesem Build deaktiviert.
+- Playwright: alle 32 Browserprüfungen bestanden, davon 7 neue Erfassungsabläufe. Isolierte API-Antworten, ausdrücklich unerreichbare DB für den Browser-Testserver.
+- Python: alle 28 Tests bestanden.
+- Zusätzliche echte SELECT-Prüfungen: Tabellen/Datentypen/Engines, Erfassungsoptionen, Kostenstellen, gespeicherte Adressen, Fahrzeuge, Vermittlungs-/Filterabfragen sowie eine Festpreisvorschau erfolgreich. Ein nicht vorhandener Kundenparameter wurde dabei korrigiert: `CUSTOMER_MASK_JB_INCOMPLETE_<id>` ist eine Parametereinstellung, keine Kundenspalte.
+- Transaktionsgrenzen, Rollback, Wiederholungen nach fehlender Speicherantwort, Preisänderungen, Recht 7/38/39, CSRF und MyISAM-Protokollwiederholung sind automatisiert ohne Bestandsänderungen geprüft.
+- Kein produktiver Auftrag wurde zum Test angelegt oder geändert. Eine reale fachliche Abnahme einschließlich PHP-Hintergrundverarbeitung, Fahrergerät und Abrechnung steht aus.
+
+Die neue Anwendung ist nicht mehr generell schreibgesperrt: Neuanlagen mit Recht 7 besitzen einen eigenen transaktionalen Schreibpfad. Andere Bestandsänderungen bleiben deaktiviert. Die folgenden Abschnitte dokumentieren historische Prüfstände und sind für den heutigen Erfassungsumfang durch den obigen Nachtrag ergänzt.
+
+## Erste Bestandsanbindung – 1. Oktober 2026
 
 ## Aktuelle Umstellung auf den zentralen Datenbankservice