votianng/docs/ALTSYSTEM-ANALYSE.md

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

Die Neuentwicklung soll die tägliche Auftragserfassung und Disposition in React und Spring Boot abbilden. Der Bestand umfasst jedoch zusätzlich eine umfangreiche Tarif-, Berechtigungs-, Abrechnungs- und Integrationslogik. Die nachfolgend als Ziel erster Umsetzung bezeichneten Funktionen sind ein geplanter Umfang und kein Nachweis ihres Implementierungsstands. Vollständige fachliche Parität oder Produktionsreife wird mit diesem Bericht nicht behauptet.

Aktuelle Umsetzungsentscheidung: Die erste Anbindung soll über lesende JDBC-Adapter auf das unveränderte Bestandsschema, vorhandene Benutzerkonten und Verweise auf bestehende PHP-Aktionen erfolgen. Das betrifft insbesondere Erfassung, Bearbeitung und weitere schreibende Geschäftsprozesse, deren Regeln nicht ungeprüft durch direkte SQL-Schreibzugriffe ersetzt werden. Ein PHP-Verweis ist keine React-/Spring-Portierung dieses Ablaufs. Wegen des derzeit nicht nachgewiesenen Datenbankzugriffs bleiben Live-Funktion, Spaltenverträglichkeit, Authentisierung und vollständige Portierung offen; dieser Bericht weist sie nicht als getestet aus.

1. Quellen und Aussagekraft

Quellenangaben haben die Form votian/pfad/datei.php:Zeile und beziehen sich auf den untersuchten Bestand. Zeilennummern markieren den Einstieg in die betreffende Funktion oder den relevanten Codeblock. Historische Kopien und nummerierte Dateivarianten kommen häufig vor; als Grundlage wurden überwiegend die unnummerierten, von den Hauptseiten referenzierten Dateien verwendet. Aus dem bloßen Vorhandensein einer Datei folgt nicht, dass die Funktion heute produktiv genutzt wird.

Die tatsächliche Ausprägung hängt von Datenbankparametern, Niederlassung, Kunde, Fahrzeugtyp, Zeitpunkt und Mitarbeiterrechten ab. Ohne diese Konfiguration und fachlich freigegebene Beispieldaten lassen sich die aktiven Regeln nicht vollständig bestimmen. Einzelne Codekommentare dienen als Hinweis; entscheidende Aussagen wurden soweit möglich mit ausführbarem Code abgeglichen.

Zentrale Quellen:

Bereich	Quellen
Auftragsmaske und Benutzerkontext	votian/jobs/job_edit.php:20, :38, :81
Auftrags- und Stationsspeicherung	votian/jobs/job_options.php:208, :421, :2290
Disposition und Listen	votian/admin/jb_list.php:505, :708, :957, :1376
Fachliche Feldlisten	votian/include/mcglobal.inc.php:145, :169, :177, :198, :217
Tarifberechnung	votian/include/services_func.inc.php:24, :89, :168, :371, :538
Storno	votian/include/inc_job.inc.php:1242
Berechtigungen	votian/include/auth.inc.php:208, :264, :285, :315
Abrechnung	votian/invoice/inv.inc.php:28, votian/invoice/inv_aux.inc.php:264

2. Fachliches Datenmodell

Kunden, Kostenstellen und Niederlassungen

Die Struktur ist company → customer → costcenter. Eine Firma enthält den Unternehmensstamm; der Kunde ergänzt die kaufmännischen Einstellungen. Kostenstellen bilden eine Hierarchie über csc_pre_id und csc_path. Sie haben eigene Sichtbarkeit, Sperren und Rechnungsparameter. Kostenstellenadressen unterscheiden unter anderem Abhol-, Rechnungs- und Serviceadressen.

Wichtige Felder:

• Kunde: cs_id, cmp_id, hq_id, externe/interne Kundennummer, Hauptkostenstelle, Standardzahler, übergeordneter/zugehöriger Kunde, Rabatt, Festpreisrabatt, Provision, Rechnungsmodus, Kommissionsnummer, Zuschlag, Zahlungsziel, Auftrags-/Tracking-Einstellungen.
• Kostenstelle: csc_id, cs_id, Name, Elternreferenz, Pfad, extern/intern, gesperrt, sichtbar, Rechnungsintervall und Rechnungsart.
• Adresse: Straße, Hausnummer, PLZ, Ort, Land, Firmenzusätze, Ansprechpartner, Telefon und Bemerkung.

Quellen: votian/include/mcglobal.inc.php:130, :145, :147, :200, :217.

Konsequenz: Ein einzelner Kundenname am Auftrag ersetzt die Kostenstellenstruktur nicht. Auftraggeber und Rechnungsempfänger müssen unterscheidbar bleiben. Niederlassungszugehörigkeit ist außerdem eine fachliche Zugriffsgrenze.

Kuriere und Fahrzeuge

Kurier und Fahrzeug sind getrennte Entitäten. In der Disposition wird häufig die Fahrzeug-SID verwendet. Ein angebotener Kurier (cr_id_order) ist vom tatsächlich annehmenden Kurier (cr_id) zu unterscheiden.

• Kurier: Unternehmen und Benutzer, SID/Nummer, Fahrzeugtyp, Merkmale/Filter, Maximalgewicht, mögliche Auslage, Verfügbarkeit, Verfügbarkeitszeit und Standort-PLZ.
• Fahrzeug: Kurierbezug, Fahrzeug-SID, Kennzeichen, Fahrzeugtyp, Nutzlast, Gesamtgewicht, Länge/Breite/Höhe, Stellplätze, Eigenschaften, Provision und Aktivierung.

Quellen: votian/include/mcglobal.inc.php:198, :206; Zuweisung über SID in votian/admin/jb_list.php:515.

Auftrag, Stationen und Leistungen

Entität	Fachlich relevante Felder
Auftrag job	Nummer, Version, Auftraggeber-Kostenstelle, Zahler-Kostenstelle, Niederlassungen für Disposition/Ausführung/Vertrieb, Besteller, Kommission, gewünschter/tatsächlicher Fahrzeugtyp, Gewicht/Maße, Auftrags-/Annahme-/Abschluss-/Warnzeit, Reservierung, Dauerauftrag, Tourname, Status, Storno, Angebot, unvollständig, Fernfahrt, Freitext, Dispositionshinweis, übergeordneter Auftrag, Preise, Buchungs-/Exportdaten
Station tour	Auftragsbezug, Reihenfolge, Kostenstelle, Firma/Firmenzusatz, Adresse, Person, Telefon, Bemerkung, Kommission, Zusatzkilometer/-leistung, Abhol-/Lieferart, Status, Signatur, Empfängername, Abschlusszeit
Stationsleistung tourservice	Station, Leistung/Leistungsart, Leistungsbezeichnung, Preis, Rabatt, zahlende Kostenstelle
Artikelposition tourarticle	Artikel, Menge, Sortierung, Preis, Packstücke, Gewicht, Seriennummer, Zustand, Bemerkung
Artikelbearbeitung tourarticleprocess	Positionsbezug, Vorgangsart, Status, Bemerkung, Zeitpunkt
Preiskomponente jobprice	Auftragsbezug, Art der Komponente und Betrag; zusätzliche Informationen zu Kunden-/Kurierberechnung

Quellen: votian/include/mcglobal.inc.php:169, :177, :179, :181, :183; weitere Maße und Bearbeitungsfelder in votian/jobs/job_options.php:208; Preiskomponenten in votian/include/caglobal.inc.php:1663.

3. Statusmodell und Arbeitsabläufe

Auftragsstatus

Legacywert	Bedeutung	Übertragung
9	Manuelle Disposition, noch zuzuteilen	Eigener fachlicher Status
8	Autoranking	Eigener Zustand, dessen automatische Bearbeitung einen separaten Dienst benötigt
0	Offen / anzunehmen	Kurierangebot und Annahme unterscheiden
1	Angenommen / laufend	Laufende Ausführung
2	Erledigt	Regulärer Abschluss oder Abschluss durch Storno; Stornoflag zusätzlich prüfen
99	Interner Zustand im Zusammenhang mit Börsen-/Globalauftrag	Kein normaler Benutzerstatus ohne weitere Prüfung des Börsenablaufs
10 bzw. ALL	Alle Aufträge	Ausschließlich Listenfilter

Quellen: votian/jobs/job_options.php:421, :439, :451; votian/admin/jb_list.php:79, :516.

Storno ist eine eigene Dimension: jb_storno=1 bedeutet kostenpflichtig, 2 kostenfrei. Stornierung setzt jb_status=2, den Abschlusszeitpunkt und den stornierenden Benutzer. Ein vereinfachtes neues Enum darf diese Information nicht verlieren. Quelle: votian/include/inc_job.inc.php:1242.

Die dazugehörigen Gegenbuchungsaufträge verwenden jb_storno=3 für die Gutschrift zu einem kostenpflichtigen Storno bzw. 4 für die Gutschrift zu einem kostenfreien Storno. Der Code kopiert und negiert dabei Preise/Leistungen und verknüpft den Originalauftrag über jb_id_copy. Solche Datensätze sind nicht einfach weitere reguläre Touren. Quelle: votian/jobs/job_options.php:662.

Stationsstatus und Stationsart

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

Kernablauf

1. Erfassen: Die Zentrale wählt eine Kostenstelle. Beim Kundenbenutzer wird die auftraggebende Kostenstelle aus dem Mitarbeiterkonto abgeleitet. Die Auftragsmaske erlaubt Kurieren und Systemadministratoren in diesem Kontext keine normale Erfassung. Quelle: votian/jobs/job_edit.php:38.
2. Route anlegen: Mehrere Stationen mit Abhol-/Lieferkennzeichen, Adressen, Ansprechpartnern, Hinweisen und optionalen Artikeln/Leistungen erfassen. Quellen: votian/include/mcglobal.inc.php:177, votian/jobs/job_options.php:236.
3. Zeit und Leistung festlegen: Sofortfahrt, Reservierung oder Dauerauftrag; Fahrzeuganforderung, Gewicht, Maße und besondere Leistungen festlegen.
4. Preis bestimmen: Tarifberechnung oder manueller Festpreis; Kundenpreis und Kuriervergütung separat behandeln. Quellen: votian/jobs/job_options.php:942, :1811.
5. Disponieren: Ohne Kurier abhängig vom Niederlassungsmodus Status 9 oder 8; mit Kurier üblicherweise 0. Offline-Disposition kann direkt 1 setzen. Quellen: votian/jobs/job_options.php:421, votian/admin/jb_list.php:516.
6. Ausführen: Annahme, Stationsabschlüsse und Zustellnachweis; anschließend Gesamtabschluss. Quellen: votian/include/mcglobal.inc.php:169, :177, votian/jobs/job_options.php:2335.
7. Nachbearbeiten: Kopieren/Nacherfassen, Versionsänderung, Änderungsprotokoll und gegebenenfalls Information an das Fahrergerät. Quellen: votian/jobs/job_options.php:185, :2366.
8. Stornieren und abrechnen: Kostenpflicht prüfen, bestehende Buchungen/Exporte beachten und erforderlichenfalls Gegenbuchungen erzeugen. Quelle: votian/include/inc_job.inc.php:1242.

Reservierungen, Daueraufträge und Vorlagen

Die Wiederholungslogik unterstützt Werktage, Werktage mit Samstag, täglich, wöchentlich, vierzehntäglich, monatlich, Monatsende, 15./Monatsende, 1./16., vierwöchentlich und Feiertage. Eine siebenstellige Maske enthält die ausgewählten Wochentage Montag bis Sonntag. Feiertagsverschiebungen unterscheiden sich je nach Wiederholungsart. Ein Enddatum begrenzt Serien. Quelle: votian/include/caglobal.inc.php:2304.

Ein gespeicherter Tourname dient auch dem Wiederverwenden einer Tour; die Preisermittlung kann beim Wiederverwenden auf aktuelle Tarife zugreifen. Quellen: votian/jobs/job_options.php:231, :1799.

4. Preislogik und Abrechnung

Der Bestand besitzt keine einzelne universelle Formel. Wesentliche Einflussgrößen sind Niederlassung, Kunde, Fahrzeugtyp, Auftragszeit, Leistung, PLZ-Paar, PLZ-Gebiet, Zusatzleistungen und Zahlungsart.

Regelbereich	Beleg	Für Parität benötigter Nachweis
Zeitlich gültige Leistungs-/Kundentarife	votian/include/services_func.inc.php:24, :371	Aktive Tarifstände und erwartete Auswahl bei Überschneidungen
PLZ-Paar-/Gebietstarife	votian/include/services_func.inc.php:89, :168	Gebietsdefinitionen, Richtung, Prioritäten, Sonderadressen
Treibstoffzuschlag Kunde/Kurier	votian/include/services_func.inc.php:430, :494	Gültigkeitsstände und zuschlagsfähige Komponenten
Leistungspreise, Rabatt, Kostenaufteilung	votian/include/services_func.inc.php:538	Reihenfolge, Zahlerzuordnung, Rundung und Ausnahmen
Manuelle Fest-/Servicepreise	votian/jobs/job_options.php:1050, :1067, :1828	Einbeziehung von Rabatt und Zuschlag; Eingabepreis netto/brutto
Separate Kuriervergütung	votian/include/services_func.inc.php:766, :794, :813	Provision, Fernfahrt-, Fahrzeug- und Unternehmerregeln
Summen-/Rundungsfolge	votian/jobs/job_options.php:1811	Referenzfälle mit identischen Einzel- und Endsummen
Umsatzsteuer/Maut	votian/jobs/job_options.php:2140	Satz, Leistungsdatum und steuerliche Zuordnung je Fall
Storno und bereits exportierte Buchungen	votian/include/inc_job.inc.php:1286	Gegenbuchungs- und Exportregeln, keine Doppelabrechnung

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.

Die native Auftragserfassung unterstützt inzwischen PLZ-/Gebietstarife sowie Festpreise; Details und Grenzen stehen in 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.

Die Rechnungsansicht unterscheidet Kunden- und Kurierabrechnung und berücksichtigt Kostenstellen, Barzahlungen und bereits exportierte Aufträge. Barzahlungen werden im betreffenden Zweig nicht als gewöhnliche Kundenrechnung behandelt. Quellen: votian/invoice/inv.inc.php:28, :200; votian/invoice/inv_aux.inc.php:264, :319, :357.

Eine neue Rechnungsübersicht oder ein CSV-Export ist daher zunächst eine Übersicht/Ausgabe. Gleichwertige Fakturierung, Korrekturbelege, Buchhaltungsexporte oder rechtliche Rechnungsanforderungen sind damit noch nicht nachgewiesen.

5. Benutzerrechte und fachliche Grenzen

Die Benutzertypen sind 1=Zentrale, 2=Kunde, 3=Kurier, 4=Lager. Darüber hinaus existiert gesonderte Systemadministratorbehandlung in verschiedenen Seiten. Quelle: votian/include/dbglobal.inc.php:786; Beispiel für Typ 0 in votian/invoice/inv.inc.php:52.

Mitarbeiterrechte werden zusätzlich über eine positionsbasierte Rechtemaske ausgewertet. Die Zugriffsprüfung unterscheidet Zentrale, Kunde und Kurier; Kundenrechte sind an Kostenstellen gebunden. Im Rechnungsmodul wird zusätzlich das Rechnungsrecht geprüft und die ausgewählte Kostenstelle auf den erlaubten Teilbaum beschränkt.

Quellen: votian/include/auth.inc.php:208, :214, :264, :285, :315; votian/invoice/inv.inc.php:36.

Erforderliche Nachweise vor produktiver Ablösung:

• Rollen- und Aktionsmatrix für Lesen, Erfassen, Ändern, Disponieren, Stornieren, Preise, Rechnungen und Export.
• Mandanten-/Niederlassungsgrenzen und erlaubte Kostenstellen-Teilbäume.
• Nachweis serverseitiger Prüfung bei direkten API-Aufrufen, nicht nur ausgeblendeter Navigation.
• Trennung zwischen Stammdaten eines Kuriers, angemeldetem Fahrer und zugewiesenem Fahrzeug.
• Historie mit Akteur, Zeitpunkt und relevanter Änderung; Schutz vor konkurrierenden Status-/Preisänderungen.

Eine Anmeldung mit wenigen Rollen kann die erste Umsetzung absichern, ersetzt aber die vorhandene Rechte- und Teilbaummatrix noch nicht.

6. Schnittstellen und Hintergrundverarbeitung

Bereich	Im Quellbestand erkennbar	Quelle	Grenze der ersten Umsetzung
Fahrer-/Mobile-Kommunikation	XML-Verarbeitung mit Modulen für Aufträge, Kuriere, Artikel, Fahrzeuge und weitere Funktionen	votian/mobile/serviceXML.php:15, :1668	Eine neue REST-API ist nicht automatisch kompatibel zu vorhandenen Fahrergeräten
Änderungen laufender Aufträge	Erzeugung zeitgesteuerter Gerätekommandos	votian/jobs/job_options.php:2366	Bestätigung, Wiederholung, Offlinebetrieb und Konfliktbehandlung benötigen eigene Tests
Routing/Geokodierung	Adresssuche und Tour-/Zeitfensterplanung; PTV-Bezug im XML	votian/import/xServer.inc.php:35, :101, :195	Lizenz, Endpunkt, Koordinatensystem, Distanz-/Zeitgrundlage und Fehlerfälle sind offen
Kilometer-/Routenpreis	Geokodierung, gespeicherte Routen, Optimierungsinformationen	votian/include/ajaxReqKmPrice.php:5, :161, :259, :376	Keine belastbare automatische Distanz- oder Preisberechnung ohne Dienst und Tarifabnahme
Dateiimporte	Allgemeine und kundenspezifische Importstrecken	votian/import/import_STANDARD_01.php:12, votian/import/import_TIMS.php:18	Feldmapping, Dublettenschutz und Fehlerrückmeldung je aktivem Format prüfen
Dateitransfer	FTP-bezogene Funktionen für Import-/Exportdateien	votian/import/data_transfer.php:94, :767, :772	Transporteinstellungen werden nicht aus dem Altsystem übernommen
Datenexport	Eigenständiges Exportmodul mit Rechteprüfung über Menüeinträge	votian/admin/menu.php:265, :331	CSV-Ausgabe ist kein Ersatz aller bestehenden Vertragsschnittstellen
Wiederholungsaufträge	Datums-/Feiertagslogik für nächste Ausführung	votian/include/caglobal.inc.php:2304	Ausführung, Eindeutigkeit und Neustartverhalten eines neuen Schedulers belegen

Für jede tatsächlich genutzte Integration sind Verantwortlicher, Format-/Protokollversion, Testzugang, Beispieldaten, Authentisierung, Fehlerrückmeldung, Wiederholungsstrategie und Abnahmekriterium zu erfassen. Alte Zugangsdaten werden nicht migriert oder in die neue Anwendung kopiert. Der Bericht dokumentiert keine geheimen Konfigurationswerte.

7. Optik und Bedienung

Das Altsystem nutzt überwiegend kompakte, tabellarische Masken. Die Auftragserfassung ist in Kopf, Stationsmaske, Optionen und Stationsliste gegliedert; im Bestand erfolgt dies über Frames. Quelle: votian/jobs/job_edit.php:81.

Die erkennbaren Standardfarben sind Hellblau #CDD9FD, dunkles Blau #1b12b9 und Akzentblau #4e45ec. Die Standardschrift ist Verdana mit Arial/Helvetica als Ersatz, häufig in 8 pt. Quellen: votian/css/navigation.css.php:28, :33, :35, :52; votian/css/phoenix.css.php:22.

Ziel der React-Oberfläche ist eine wiedererkennbare blaue Gestaltung mit klarer Navigation, dichten Auftragstabellen, sichtbaren Statusangaben und kurzer Erfassung. Lesbarkeit, Tastaturbedienung und responsive Darstellung können modernisiert werden. Die Übernahme der Frames, der kleinen historischen Schriftgröße oder jedes pixelgenauen Abstands ist kein fachliches Erfordernis. Visuelle Gleichheit ist ohne Screenshots der aktiven Installation nicht nachgewiesen.

8. Modul-Abdeckungsmatrix

Diese Matrix trennt vorhandene Fachlichkeit von dem vorgesehenen Einstieg. Sie ersetzt keine Prüfung des tatsächlich implementierten Codes und der Tests.

Modul/Funktion	Bestand	Ziel erster Umsetzung	Noch zu belegende Parität / Priorität
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
Kunden	Firmen, Kostenstellenhierarchie, Zahler, Parameter	Kundenstammdaten lesen; Pflege über PHP-Verweis	Kostenstellen und abweichender Rechnungsempfänger; P0/P1
Kuriere/Fahrzeuge	Getrennte Modelle, SID, Verfügbarkeit und Merkmale	Kurierstammdaten lesen; Pflege über PHP-Verweis	Fahrzeugzuordnung, Eignung, Verfügbarkeit; P1
Preise	Historisierte Tarife, PLZ-/Gebiete, Leistungen, Rabatte, Zuschläge	Vorhandene Preiswerte lesen; Kalkulation/Änderung im PHP-Prozess	Tarifmatrix und getrennte Kurierabrechnung; vor automatischer Preisnutzung P0
Rechnungen	Kunden-/Kurieransicht, Kostenstellen, Bar-/Exportregeln	Vorhandene Abrechnungswerte lesen bzw. PHP-Rechnungsansicht öffnen	Fakturierung, Korrekturen, Nummernkreise, Steuern und Exportstatus; vor Abrechnung P0
Export	Rechtegebundene und kundenspezifische Ausgaben	Lesende Ausgabe bzw. vorhandener PHP-Export; Umsetzung separat belegen	Schnittstellenverträge, Kodierung, Dubletten und Wiederholung; P1
Reservierungen	Zukünftige Auftragszeit und Dispositionsregeln	Vorhandenen Termin anzeigen; Änderung im PHP-Prozess	Zeitzone, Warn-/Vorbereitungszeit; P1
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	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

Prioritäten: P0 verhindert die fachlich sichere Ablösung des betroffenen Kernablaufs; P1 ist als nächster operativer Ausbau einzuplanen; P2 hängt von der nachgewiesenen produktiven Nutzung ab. Nicht jede Funktion muss vor einer begrenzten Pilotnutzung verfügbar sein; der Pilotumfang muss die vorhandenen Einschränkungen ausdrücklich berücksichtigen.

Die besonders dringenden Ergänzungen über ein einfaches CRUD hinaus sind: getrennte Kostenstellen/Zahler, einzelne Stationsabschlüsse, echte Stornobedeutung, Trennung Angebot/Annahme, serverseitige Zugriffsgrenzen und nachvollziehbare Änderungen. Diese Aspekte beeinflussen den täglichen Kernprozess unmittelbar.

9. Bestehende Datenbank anbinden, ohne Schemaänderung

Die ausdrückliche Vorgabe lautet, die vorhandene Datenbank zu verwenden. Es gibt deshalb keinen Plan zur Anlage einer neuen Datenbank, zur Erstellung neuer Tabellen oder zum Import der Bestandsdaten in ein neues Schema. „Mapping“ bezeichnet ausschließlich die Abbildung bestehender Spalten auf Java-/API-Modelle. Eine rein lesende Schemaanalyse ist von Datensatzänderungen zu unterscheiden.

1. Verbindung und Bestand feststellen. Autorisiert bereitgestellte Verbindungsparameter außerhalb des Quellcodes konfigurieren. Datenbankversion, Tabellen, Spaltentypen, Schlüssel, Archivtabellen, Kodierung und aktive Parameter lesend ermitteln. Zugangsdaten nicht in Ausgaben oder Repository schreiben.
2. Automatische Strukturänderungen abschalten. Keine H2-Ersatzdatenbank, keine neue MySQL-Datenbank, keine DDL, keine Flyway-/Liquibase-Migrationen und keine automatische Seed-Befüllung. Bei JPA darf die DDL-Einstellung keine Erzeugung oder Änderung auslösen. Explizites JDBC mit kontrolliertem SQL ist ebenfalls möglich.
3. API-/Feldmapping erstellen. Für jede verwendete API-Eigenschaft die vorhandene Tabelle, Spalte, Join-Bedingung, Bedeutung, Nullbehandlung und Schreibregel dokumentieren. Auftraggeber/Zahler, Kunde/Kostenstelle, Kurier/Fahrzeug und Auftrag/Station bleiben unterscheidbar.
4. Bestand lesend prüfen. Fachliche Stichproben, Objektanzahlen, Fremdschlüsselbeziehungen, Statuswerte und Summen abgleichen. Verwaiste Referenzen, doppelte Nummern und widersprüchliche Daten melden, ohne sie automatisch zu korrigieren. Die alte Oberfläche deklariert ISO-8859-1 (votian/jobs/job_edit.php:67); der tatsächliche Datenbankzeichensatz und JDBC-Transport sind separat zu prüfen.
5. Kompatibles Schreiben entwickeln. Bestehende Schlüsselerzeugung, erforderliche Spalten, Status-/Stornofelder, Zeitstempel, Historie und Nebentabellen berücksichtigen. Ein fachlicher Speichervorgang benötigt eine Transaktion. Unbekannte Altspalten nicht durch vollständiges Ersetzen eines Datensatzes verlieren. Die Existenz aller SQL-Spalten vor Schreibfreigabe nachweisen.
6. Schreiben gezielt verifizieren. Autorisierte Testdatensätze oder eine ausdrücklich bereitgestellte Testinstanz des unveränderten Bestandsschemas verwenden. Keine eigenmächtige Testdatenbankanlage. Produktive Datensätze nicht als Testmaterial ändern. Auftragserfassung ist mehr als ein INSERT INTO job: Stations-, Preis-, Zuweisungs- und eventuell Historieneinträge müssen fachlich zusammenpassen.
7. Parallelbetrieb prüfen. PHP und Spring Boot können dieselben Datensätze sehen. Konkurrierende Bearbeitung, Nummernvergabe, Statuswechsel und Hintergrundprozesse dürfen sich nicht überschreiben. Bereits vorhandene Versions-/Sperrkonzepte sind auf Kompatibilität zu untersuchen. Serienaufträge, Benachrichtigungen und Exporte dürfen nicht doppelt ausgelöst werden.
8. Abgleich und Freigabe. Lesen über PHP und neue API anhand identischer IDs vergleichen. Nach erlaubten Testschreibvorgängen Sichtbarkeit und Bedeutung im Altsystem prüfen. Disposition und Abrechnung bestätigen die relevanten Fälle; verbleibende Grenzen bleiben dokumentiert.

Falls ein bestehender Datentyp oder eine fehlende Spalte die gewünschte Funktion nicht abbildet, darf daraus keine automatische Schemaänderung folgen. Zunächst vorhandene fachliche Speicherorte untersuchen, dann die Einschränkung konkret benennen. Ein neuer API-Begriff ist kein Auftrag, eine gleichnamige Spalte anzulegen.

Authentisierung muss zum vorhandenen Benutzermodell passen. Alte Passwortwerte dürfen weder in API-Antworten noch in Logs gelangen. Eine Änderung von Passwortformaten, Kontoaktivierungen oder Benutzerrechten ist eine eigene fachliche Änderung und nicht Teil der bloßen Anbindung. Signaturen, Fotos und Dokumente bleiben an ihren vorhandenen Daten-/Dateibeziehungen; sie werden nicht ungefragt kopiert oder verschoben.

10. Fachliche Abnahme und technische Nachweise

Abnahmeszenario	Erwartung
Sofortauftrag mit zwei Stationen	Pflichtfelder, Preisbedeutung und initialer Status stimmen; Auftrag nach Neustart vorhanden
Mehrstopp mit Abholung, Lieferung und gemischter Station	Reihenfolge bleibt erhalten; Teilabschluss beendet nicht vorzeitig den Gesamtauftrag
Zuweisen, annehmen, zurücknehmen	Kurierangebot und Annahme sind nachvollziehbar; ungültige Übergänge werden serverseitig abgewiesen
Zwei Disponenten bearbeiten denselben Auftrag	Keine unbemerkte Überschreibung; Versionskonflikt ist verständlich lösbar
Reservierung und Warnzeit	Lokale Zeitdarstellung und Speicherung stimmen, auch bei Zeitumstellung
Kostenpflichtiges/kostenfreies Storno	Zustand, Preisfolgen und Historie bleiben eindeutig; abgeschlossene/exportierte Fälle geprüft
Abweichender Zahler und Unterkostenstelle	Rechnungszuordnung korrekt; unberechtigter Benutzer kann fremde Daten auch per API nicht erreichen
Festpreis mit Rabatt, Zuschlag, Service und Steuer	Beträge und Rundungsfolge anhand freigegebener Referenzfälle exakt geprüft
Historischer Auftrag nach Tarifänderung	Historischer Preis bleibt nachvollziehbar und unverändert, sofern keine ausdrückliche Neukalkulation erfolgt
Abrechnung und Wiederholung des Exports	Keine Doppelabrechnung; Exportinhalt und Status sind reproduzierbar
Fehlende externe Dienste	Verständliche Fehler, keine stillen Fantasiepreise oder falschen Statusbestätigungen
Bestandsanbindung und Parallelbetrieb	Identische fachliche Daten in PHP und neuer API; keine DDL, keine verlorenen Felder und keine doppelten Hintergrundaktionen

Die erste Lieferung ist anhand ihrer tatsächlich vorhandenen Endpunkte, Bedienwege und Tests gegen diese Matrix zu prüfen. Bestehende Backend-Tests, ein erfolgreicher Frontend-Build und ein erfolgreicher Start sind technische Nachweise; sie ersetzen weder Tarifvergleich noch Benutzerrechteprüfung, Schnittstellenabnahme und Datenabgleich.

Ein zunächst auf job.hq_id = user.hq_id begrenzter Lesezugriff zeigt nur Aufträge der eigenen Erfassungsniederlassung. Die Legacy-Liste berücksichtigt zusätzlich Ausführungs-, Dispositions- und Vertriebsniederlassung über eine Vereinigung erlaubter HQ-Mengen (votian/admin/jb_list.php:1101, :1363). Die engere neue Sicht ist als Einschränkung auszuweisen: Ein in einer anderen Niederlassung erfasster, der eigenen Disposition zugehöriger Auftrag kann fehlen. Zugriffsbereiche dürfen ohne passende Rechteabbildung nicht pauschal erweitert werden.

Eine vollständige Ablösung kann erst bestätigt werden, wenn Stadtbote die aktiv genutzten Module bestimmt hat, die zugehörigen Regeln in der neuen Anwendung kompatibel umgesetzt oder ausdrücklich stillgelegt sind und die relevanten Referenzfälle bestanden wurden.

Anhang A. Konkrete Zuordnung bestehender Tabellen zu API-Modellen

Die API-Feldnamen in der linken Spalte sind Vorschläge für die Java-/JSON-Abbildung. Die rechten Spalten sind im PHP-Code belegte bestehende Datenbanknamen. Die tatsächlichen Typen, Nullmöglichkeiten und Indizes müssen über die vorhandene Datenbank lesend geprüft werden. Die folgenden SQL-Formen dienen nur der Implementierungsanalyse und wurden nicht gegen eine Datenbank ausgeführt.

Kunde und Firmenstamm

API-Feld	Bestehende Spalte / Ausdruck	Beziehung
customer.id	customer.cs_id	Fachlicher Kundenschlüssel, nicht cmp_id
customer.number	customer.cs_eid	Im Bearbeitungsablauf auf Eindeutigkeit geprüft
customer.internalNumber	customer.cs_sid	Weitere interne Nummer
customer.companyId	customer.cmp_id	customer.cmp_id = company.cmp_id
customer.name	company.cmp_comp	Firmenzusätze cmp_comp2 bis cmp_comp4 separat
customer.headquarterId	customer.hq_id	Sichtbarkeit nach erlaubtem Niederlassungs-/Mandantenbereich
customer.defaultCostCenterId	customer.csc_id	Hauptkostenstelle
customer.payerCostCenterId	customer.csc_id_payer	Abweichender Standardzahler
customer.contact.firstName/lastName	user.usr_firstname, user.usr_name	customer.cs_admin = employee.emp_id, dann employee.usr_id = user.usr_id
customer.phone/email	user.usr_phone, user.usr_email	Wie Kontakt; Telefon nicht aus company erfinden
customer.address.street	address.ad_street	company.ad_id = address.ad_id
customer.address.houseNumber	company.cmp_hsno	Hausnummer liegt hier außerhalb der Adresstabelle
customer.address.postalCode/city/country	address.ad_zipcode, ad_city, ad_country	Wie Straße
customer.visible/archived/authorized	company.cmp_visible, cmp_archived, cmp_authenticated	Drei unterschiedliche Zustände
customer.discount/fixedPriceDiscount	customer.cs_discount, cs_fixprice_discount	Prozentwerte; historische Tarif-/Änderungslogik zusätzlich prüfen
customer.paymentTerm	customer.cs_payment_term	Vorhandene Bedeutung/Einheit am Bestand verifizieren

Lese-Joins: votian/include/inc_customer.inc.php:31, :70; vollständige Feldliste votian/include/mcglobal.inc.php:217. Eindeutigkeitsprüfung votian/admin/customer_special.php:797.

Bestehende Anlagefolge in votian/include/inc_customer.inc.php:678: costcenter anlegen, user vom Typ 2, employee mit Kostenstellen-/Rechtebezug, company, customer, anschließend costcenter.cs_id zurückverknüpfen, Adresse verknüpfen und mehrere costcenteraddress-Arten anlegen (:746, :757, :762). Eine alleinige Anlage in customer wäre zu dieser Fachlichkeit nicht kompatibel. Die Feldlisten für Änderungen stehen in votian/admin/customer_special.php:823, :840, :844; sie aktualisieren Firma, Kunde und Kontaktbenutzer separat. Das ist eine Analyse der Altlogik, keine Aufforderung zu Teständerungen am Bestand.

Kostenstelle und Kostenstellenadresse

API-Feld	Bestehende Spalte
costCenter.id/customerId/name	costcenter.csc_id, cs_id, csc_name
costCenter.parentId/path	costcenter.csc_pre_id, csc_path
costCenter.visible/blocked/external	costcenter.csc_visible, csc_blocked, csc_is_extern
costCenter.invoiceInterval/invoiceType	costcenter.csc_inv_interval, csc_inv_type
costCenterAddress.typeId/addressId	costcenteraddress.adt_id, ad_id
costCenterAddress.company/houseNumber/contact/phone/email	cscad_comp, cscad_hsno, cscad_person, cscad_phone, cscad_email
costCenterAddress.street/postalCode/city	address.ad_street, ad_zipcode, ad_city über costcenteraddress.ad_id = address.ad_id

Leseabfragen: votian/include/inc_customer.inc.php:973, :998. Anlage in votian/customer/costcenter.php:77 prüft kundenspezifisch eindeutige Namen, setzt cs_id, csc_pre_id, csc_name, csc_path, csc_visible und übernimmt Adressen/Rechnungsintervall der Hauptkostenstelle. Umbenennen/Anzeige/Rechnungsdaten werden separat aktualisiert (:172, :193, :375). csc_path enthält im untersuchten Aufbau Namen und Trenner; nicht ohne Nachweis als reine ID-Liste interpretieren.

Kurier, Kontakt und Fahrzeug

API-Feld	Bestehende Spalte / Beziehung
courier.id/number/dispatchSid	courier.cr_id, cr_eid, cr_sid
courier.companyId/userId/headquarterId	courier.cmp_id, usr_id, hq_id
courier.companyName	company.cmp_comp über courier.cmp_id = company.cmp_id
courier.firstName/lastName/phone/email	user.usr_firstname, usr_name, usr_phone, usr_email über courier.usr_id = user.usr_id
courier.vehicleTypeId	courier.vht_id; nicht mit vht_id_inv für Abrechnung verwechseln
courier.available/availableAt/locationPostalCode	courier.cr_available, cr_availabletime, cr_locationzipcode
courier.maxWeight/outlayLimit	courier.cr_maxweight, cr_outlay
courier.disposition/appBlocked	courier.cr_disposition, cr_app_blocked
vehicle.id/courierId/dispatchSid/typeId	couriervehicle.crvh_id, cr_id, crvh_sid, vht_id
vehicle.licensePlate/payload	couriervehicle.crvh_vh_sign, crvh_payload

Lese-Joins: votian/include/inc_courier.inc.php:32, :68; Fahrzeugfelder: votian/include/mcglobal.inc.php:206.

Anlage erzeugt zuerst user vom Typ 3, dann company, courier und Adresse (votian/include/inc_courier.inc.php:645, :653, :682, :694). Die Änderungsmaske schreibt Firma, Kurier und Benutzer getrennt (votian/admin/courier_special.php:486, :525, :549). Der aktuelle Kommentar vor dem Kurier-Update weist ausdrücklich darauf hin, dass cr_sid aus diesem allgemeinen Update entfernt wurde (:524); SID deshalb nicht ungeprüft als frei editierbares Stammdatenfeld behandeln. Änderungen an der Gerätenummer können weitere Zuordnungen beeinflussen; für einen einfachen Kontakt-Edit ist usr_phone maßgeblich, nicht automatisch cr_mobile_pda.

Authentisierung und Autorisierung

Zweck	Bestehende Felder / Beziehungen
Kontosuche	user.usr_account; Ergebnis usr_id, hq_id, usr_type
Passwortprüfung	user.usr_password, gegebenenfalls usr_password_old; nur intern verwenden, nie API-Ausgabe
Mitarbeiterbezug	employee.usr_id = user.usr_id; emp_id, csc_id, emp_rights, emp_heritable_rights
Rollen	usr_type: 1 Zentrale, 2 Kunde, 3 Kurier, 4 Lager; Typ 0 separat prüfen
Niederlassungszugriff	user.hq_id, Mitarbeiterkontext und besondere Freigaben; nicht nur Rolle
Erweiterte Niederlassungsrechte	employeerights.emp_id, hq_id, rgt_id
Kundenzulassung	employee.csc_id → costcenter.cs_id → customer.cmp_id → company.cmp_authenticated
Kurierzuordnung	courier.usr_id = user.usr_id

Der untersuchte Login prüft gegen die Datenbankfunktionen PASSWORD() und OLD_PASSWORD() (votian/admin/login.php:484, :494), und cryptDbPassword ruft ebenfalls PASSWORD() auf (votian/include/dbglobal.inc.php:458). Ein pauschaler BCrypt-Vergleich wäre deshalb nicht mit diesem Legacyzweig kompatibel. Passwortwerte oder Formate wurden hier nicht aus der Datenbank gelesen. Die konkret eingesetzte Datenbankversion und die vorhandenen Hashformate müssen vor Implementierung der Prüfung sicher geklärt werden. Die im Altlogin enthaltene automatische Passwortänderung wird bei einer rein lesenden Anbindungsprüfung nicht übernommen.

Die Benutzer-/Mitarbeiterbeziehung wird beim Login aufgelöst (votian/admin/login.php:531). Kunden müssen zusätzlich freigeschaltet sein (:545). Aktionsrechte werden über employee.emp_rights geprüft, können beim Niederlassungswechsel eingeschränkt werden und werden durch eine separate Niederlassungsrechtematrix ergänzt (votian/include/dbglobal.inc.php:815, :841; votian/include/auth.inc.php:315). Ein erfolgreiches Passwort allein berechtigt daher nicht zum Zugriff auf sämtliche Aufträge.

Präzisierungen für einen lesenden HQ-Zugang

Für einen Zugang als Zentralenmitarbeiter (usr_type=1) benötigt der Legacy-Prüfpfad eine existierende, positive emp_id mit employee.usr_id = user.usr_id. Der Niederlassungsschlüssel stammt aus user.hq_id, nicht aus einem unbelegten Feld employee.hq_id. Zunächst ist der eigene HQ-Bereich zu verwenden; Mehrfachzugriff setzt besondere Freigaben und Rechtebeschränkungen voraus (votian/include/auth.inc.php:214; votian/include/dbglobal.inc.php:815).

Der Login-Join fordert eine existierende headquarters-Zeile (votian/admin/login.php:494). Die allgemeine Authentisierungsinitialisierung verlangt außerdem einen gültigen Mandantenbezug über mandatorheadquarters.hq_id → md_id (votian/include/auth.inc.php:115). In den untersuchten Dateien admin/login.php, include/auth.inc.php, admin/employee.php, admin/user_list.php und include/dbglobal.inc.php wurde keine Loginprüfung anhand von usr_active, usr_disabled, usr_deleted, emp_active oder emp_disabled gefunden; diese Felder dürfen nicht in SQL erfunden werden. Das belegt nicht ihre Abwesenheit in jedem Datenbankstand. hq_disabled existiert als Auswahlfilter (votian/jobs/job_header.php:79), wird aber im untersuchten Passwort-Login nicht geprüft. Ob die neue Anmeldung eine deaktivierte HQ ausdrücklich ablehnt, ist als eigene Regel festzulegen und gegen den Bestand zu prüfen.

Die folgende HQ-Rechtematrix verwendet nullbasierte Indizes in employee.emp_rights. Sie gilt nicht automatisch für Kundenbenutzer:

Zugriff	Bitindex	Quelle
Kunden	0	votian/admin/menu.php:214
Kuriere/Transporteure	1	votian/admin/menu.php:215
Auftragslisten	4	votian/admin/menu.php:206
Rechnungsübersicht, PDF-/CSV-Ausgabe	5	votian/admin/menu.php:254, :258, :259
Allgemeiner Datenexport	6	votian/admin/menu.php:265
Auftragserfassung	7	votian/admin/menu.php:246
Statistik	8	votian/admin/menu.php:211

Diese Zugriffe müssen auch bei einer lesenden API serverseitig geprüft werden. Dashboard-Zahlen und Preiszusammenfassungen unterliegen ebenfalls den passenden Lese-/Abrechnungsrechten. Vorhandene PHP-Links besitzen ihre eigene Sitzung und Authentisierung; aus einem erfolgreichen Login der neuen Oberfläche folgt noch keine automatisch angemeldete PHP-Sitzung.

Anhang B. Geprüfte PHP-Modulziele

Die folgenden Pfade sind relativ zur konfigurierten Basis-URL der vorhandenen votian-Installation. Sie öffnen Module und übermitteln keine Speicher-, Lösch-, Storno- oder Importausführungsaktion. Die Funktionsprüfung erfolgte am Quelltext; eine aktive PHP-Sitzung, Berechtigungen und eine laufende Installation bleiben Voraussetzung.

Ziel	Relativer Pfad	Quellbeleg
Neuer Auftrag	jobs/job_edit.php	votian/admin/menu.php:248
Auftrag auswählen/bearbeiten	admin/jb_list.php	votian/admin/jb_list.php:33
Kundenverwaltung	admin/customer_list.php	votian/admin/menu.php:214
Kurierverwaltung	admin/courier_list.php	votian/admin/menu.php:215
Rechnungsübersicht	invoice/invoice.php	votian/admin/menu.php:254
Servicepreise	admin/services.php?mode=price	votian/admin/menu.php:268
PLZ-Preise	admin/services_plz.php?mode=price	votian/admin/menu.php:269
Datenimport/-transfer	import/data_transfer.php	votian/admin/menu.php:266
Datenexport	export/export.php	votian/admin/menu.php:265
Statistik	statistic/statistic.php	votian/admin/menu.php:211

Objektbezogene Links werden im Bestand normalerweise als jobs/job_edit.php?jb_id=ec(jb_id), admin/customer_special.php?companyId=ec(cmp_id) und admin/courier_special.php?companyId=ec(cmp_id) erzeugt. companyId ist der Firmenschlüssel cmp_id, nicht die Kunden-ID cs_id und nicht die Kurier-ID cr_id. Quellen: votian/include/jb_list_defineoutput.inc.php:665, votian/admin/customer_list.php:854, votian/admin/courier_list.php:712.

ec() hängt von HTTP_VARS_SEC_STATE, einer Markierungssequenz und dem PHP-Sitzungskontext ab. getSecHttpVars("1", …) ruft dc() auf. Die untersuchte Implementierung von dc() lässt unmarkierte Werte unverändert; Klartext-IDs sind daher auf Quelltextebene nicht grundsätzlich ungültig. Eine eigene Nachbildung der Codierung oder ein beliebig erzeugter codierter Wert ist trotzdem kein nachgewiesen funktionsfähiger Link. Quellen: votian/include/global.inc.php:57, :846, :868.

Für die erste Anbindung sind Module ohne Objektparameter die belastbarere Option. Direkte Objektlinks benötigen eine Prüfung mit der tatsächlichen PHP-Konfiguration und einem erlaubten Testkonto. Es werden keine schreibenden f_act-Parameter konstruiert.

Anhang C. Bei der Adapterprüfung besonders zu beachtende Bedeutungen

• job.jb_totalprice enthält den Kundenpreis einschließlich der dort angewendeten Zuschläge, während jb_subtotalprice im untersuchten Festpreiszweig den Zuschlag nicht enthält. Die Steuer wird gesondert berechnet. Eine Anzeige des vollständigen Nettopreises darf deshalb nicht ungeprüft auf jb_subtotalprice zugreifen (votian/jobs/job_options.php:1828, :1886, :2140).
• job.jb_service wird als Bitmaske verwendet. Im Filter wird 2^mt_sort getestet; ein einfacher Gleichheitsjoin metatype.mt_sort = job.jb_service ist für Kombinationen falsch (votian/admin/jb_list.php:1158). Fahrzeugtypen verwenden hingegen tatsächlich metatype.mt_sort = job.vht_id (:1177).
• Kilometer werden im untersuchten Speicherpfad als jobprice.jbprc_price mit mt_sort=11 gespeichert. Ein Feld job.jb_km darf daraus nicht abgeleitet werden (votian/jobs/job_options.php:224, :2097).
• Packstücke werden über SUM(tourarticle.trat_packingpieces) ermittelt, Artikelgewichte über SUM(tourarticle.trat_weight); job.jb_weight ist daneben ein vorhandenes Auftragsfeld (votian/include/inc_job.inc.php:91, :112).
• Die Historie liegt im untersuchten Zugriff unter phoenix_log.log. Eine nicht verfügbare Historienanbindung darf nicht als nachgewiesen leere Historie erscheinen; sie benötigt eine ausdrückliche Kennzeichnung (votian/include/caglobal.inc.php:2254).