votianng/docs/MENUE-ABGLEICH.md

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