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