🚗 Fuhrpark (Fleet Manager)

ℹ️ Zweck: Webbasiertes System zur Verwaltung des Firmenfuhrparks — von Fahrzeug- und Fahrerstammdaten über Kostenkalkulation und Kilometerauswertung bis zu automatisierter Ersatzbeschaffungs-Planung (Handlungsbedarf) und monatlicher Abrechnung.

Auf dieser Seite

• 🚗 Fuhrpark (Fleet Manager)
  • Übersicht
  • Technologie-Stack
  • Projektstruktur
  • Hauptfunktionen
    • Fahrzeuge verwalten
    • Fahrer verwalten
    • Kilometer-Daten
    • Kalkulation
    • Handlungsbedarf
    • Dashboard
    • Benutzerverwaltung (Admin)
    • Kalkulationsparameter
    • Export & Berichte
  • Routing
  • Datenzugriff
  • Backend
  • Architektur
  • Server
  • Hinweise

Übersicht

Fuhrpark unterstützt den gesamten Lebenszyklus eines Firmenfahrzeugs: Anlage und Zuordnung, laufende Kostenkalkulation, Kilometer-Tracking, Handlungsbedarf/Ersatzbeschaffung bis zur monatlichen Abrechnung und Kostenstellen-Umbuchung. Fahrzeug- und Fahrerstammdaten werden aus dem unternehmensweiten RIMO-System (SQL-Server-DWH) synchronisiert, Kilometerstände automatisiert über GPS-/Tesla-Anbindung und SharePoint importiert.

Das Projekt wurde von einer Streamlit-Monolith-Anwendung auf eine FastAPI-Backend- + React-Frontend-Architektur umgestellt.

Technologie-Stack

Frontend: React 18 · Vite · React Router · React Query (TanStack Query) · Axios · eigene UI-Komponentenbibliothek (kein UI-Framework wie MUI/shadcn)

Backend: FastAPI (Python) · SQLite (WAL-Modus) · Pandas · python-jose (JWT) · passlib/bcrypt · pyodbc (SQL-Server-Anbindung)

Externe Anbindungen:

• RIMO / SQL-Server (ai.sdmperson, rimo.sdmtool): täglicher Fahrer-/Line-Manager-Sync, Datumsermittlung für Nachkorrekturen
• Microsoft Fabric: KM-Formular-E-Mails, SharePoint-Listenabgleich
• GPS-AT / Tesla: automatischer Kilometerstand-Import

Projektstruktur

fuhrpark/
├── _bootstrap.py                          Gemeinsames Setup für alle Skripte
├── 1_import_users_drivers.py              Täglicher Fahrer-/Line-Manager-Sync (Cron)
├── 2_import_vehicles.py                   Einmaliger Fahrzeug-Erstimport
├── 3_import_vehicle_data.py                Manueller Excel-Import (Fahrzeugdaten)
├── 4_import_km_history.py                  Manueller Excel-Import (KM-Historie)
├── import_km.py                            KM-Stand-Import (gpsat/tesla/sharepoint)
├── repair_stale_line_manager_assignments.py  Einmaliges Reparatur-Skript (Altlasten)
├── docker-compose.yml
├── .env                                    Secrets für Docker (SECRET_KEY, CORS)
├── data/                                   fleet.db, fleet_demo.db (nicht in Git)
├── abrechnungen/                           Export-Ablage (nicht in Git)
├── backend/
│   ├── Dockerfile
│   ├── .env                                Secrets für Cron-Skripte (CONN_STR, SP_*, SMTP_*)
│   ├── requirements.txt
│   └── app/
│       ├── main.py                         FastAPI-Einstiegspunkt, Hintergrund-Jobs
│       ├── config.py                       Zentrale Konfiguration (ENV-Variablen)
│       ├── db.py                           Schema, Migrationen, Indizes
│       ├── auth.py                         JWT/Passwort-Logik
│       ├── services.py                     Geschäftslogik (Kalkulation, Zuordnung, ...)
│       └── routers/                        vehicles, drivers, users, dashboard, calc_params, auth
└── frontend/
    ├── Dockerfile
    ├── nginx.conf                          Reverse-Proxy zu /api, SPA-Routing
    └── src/
        ├── api/                            zentraler Axios-Client
        ├── context/                        AuthContext
        ├── components/                     VehicleFormModal, DriverFormModal, ui/, ...
        └── pages/                          Dashboard, Fahrzeuge, Fahrer, KM-Dashboard, ...

Hauptfunktionen

Fahrzeuge verwalten

Fahrzeuge werden initial aus RIMO importiert und danach in der App gepflegt (Rückschreiben nach RIMO ist geplant, aktuell nicht implementiert). Anlegen erfordert MAT-ID, Marke und Modell als Pflichtfelder; Fahrer und Line Manager können direkt zugewiesen werden (Line Manager wird bei Fahrer-Auswahl automatisch ergänzt, ist aber weiterhin manuell überschreibbar). Zuordnungen mit befristetem Zeitraum kehren nach Ablauf automatisch zum vorherigen Fahrer zurück — ohne Enddatum bleibt die Zuordnung bestehen, bis sie aktiv geändert wird. Fahrzeuge können auf inaktiv gesetzt (bleiben sichtbar) oder archiviert werden (wandern in die Archiv-Ansicht, von dort reaktivierbar). Ein gesetztes „Deactivation Date" deaktiviert und archiviert das Fahrzeug automatisch zum entsprechenden Datum. Komponenten: FahrzeugePage, VehicleFormModal, VehicleDrawer.

Fahrer verwalten

Fahrer werden täglich um 4:00 Uhr gegen RIMO abgeglichen (Neuanlage bei unbekannter Personalnummer, sonst Aktualisierung von Stammdaten, Kostenstelle und Line Manager). Externe Fahrer können manuell angelegt und bearbeitet werden; Stammdaten interner (per RIMO importierter) Fahrer sind schreibgeschützt. Komponenten: FahrerPage, DriverFormModal.

Kilometer-Daten

Kilometerstände werden automatisiert importiert: GPS-AT täglich um 4:00, Tesla montags um 4:00, jeweils zum Monatsende. Für Fahrzeuge ohne automatische Anbindung wird 3 Tage vor Monatsende täglich eine Erinnerungsmail verschickt, bis ein Wert in der SharePoint-Liste eingetragen ist; sobald die Liste vollständig ist, wird sie automatisch übernommen. Berechnet werden Differenzen, Jahreskilometer und aktuelle Laufleistung, einsehbar im KM-Dashboard — inklusive korrekter Zeitraum-Begrenzung bei unterjährigem Fahrer-/Line-Manager-Wechsel. Komponente: KmDashboardPage.

Kalkulation

Pro Fahrzeug wird eine Kostenkalkulation aus Anschaffungskosten, laufenden Kosten (Versicherung, Wartung etc.) sowie Verbrauch und Energiepreisen erstellt. Ergebnis: Kosten pro Monat, Jahr und Kilometer. Beim Anlegen eines Fahrzeugs werden die Default-Parameter aus „Kalkulationsparameter" nach Fahrzeugtyp übernommen; die verbleibenden individuellen Felder werden in „Kalkulation" ergänzt und per „Aktualisieren" neu berechnet. Komponente: KalkulationPage.

Handlungsbedarf

Hochrechnungen werden bei jedem KM-Stand-Import neu berechnet. Ein neu bestelltes Fahrzeug wird zunächst über das Häkchen „Bestellt" markiert — erst danach kann es im System angelegt werden. Nach Anlage steht die Funktion „Geliefert" zur Verfügung; sobald ein Fahrzeug als geliefert markiert wird, entfällt es automatisch aus der Handlungsbedarfsliste, der Beschaffungsprozess gilt als abgeschlossen. Neu angelegte sowie aus dem Handlungsbedarf stammende Fahrzeuge erscheinen automatisch im Forecast; Ersatzfahrzeuge enthalten dort eine Referenz auf das ursprüngliche (ersetzte) Fahrzeug. Komponente: HandlungsbedarfPage.

Dashboard

Zentrale Übersicht: Anzahl Fahrzeuge, Kostenübersicht und relevante Kennzahlen zum aktuellen Fuhrparkstatus. Komponente: DashboardPage.

Benutzerverwaltung (Admin)

Admins können Benutzer anlegen, Passwörter ändern sowie Fahrer und Fahrzeuge zuweisen. Änderungen an Line Manager und Kostenstelle werden nachvollziehbar protokolliert (driver_attribute_history), sowohl bei manueller Änderung als auch beim täglichen RIMO-Sync. Komponente: BenutzerPage.

Kalkulationsparameter

Anpassungen hier wirken sich auf alle Fahrzeuge des jeweiligen Typs aus. Dem Controlling vorbehalten (Rollen admin, demo, controlling). Komponente: KalkParamsPage.

Export & Berichte

Monatliche Abrechnungen und Kostenstellen-Umbuchungen werden auf Klick erstellt und als CSV exportiert, zur Weiterverarbeitung in Excel. Gefahrene Kilometer sowie die vollständige Fahrzeugliste (inkl. Kalkulationsaufschlüsselung) können als Excel-Datei heruntergeladen werden.

Routing

Datenzugriff

Der Zugriff erfolgt über einen zentralen Axios-Client (api/index.js) in Verbindung mit React Query für Caching, Invalidierung und Hintergrund-Aktualisierung. Jede Seite bindet die für sie relevanten REST-Endpunkte des FastAPI-Backends ein (vehiclesApi, driversApi, usersApi, calcParamsApi).

Backend

Authentifizierung: JWT (python-jose), OAuth2-Password-Flow, 8-Stunden-Tokens. Rollen: admin, demo, controlling, Benutzer (Line Manager/Fahrer). Sichtbarkeit von Fahrzeugen/Fahrern für normale Nutzer richtet sich nach Line-Manager-Zuordnung.

Datenbank: SQLite im WAL-Modus. Schema und nicht-destruktive Migrationen in db.py. Änderungen an Fahrzeugen, Fahrern, Kalkulationsparametern und Passwörtern werden inklusive verantwortlicher Person nachvollzogen (updated_by); Zuordnungsänderungen (Fahrzeug↔Fahrer, Fahrer↔Line-Manager/Kostenstelle) führen eine vollständige, zeitlich abgegrenzte Historie (vehicle_assignment_history, driver_attribute_history).

Externe Anbindung: SQL-Server-Zugriff über pyodbc (CONN_STR) für den täglichen RIMO-Sync sowie Datumsermittlung bei nachträglichen Korrekturen (rimo.sdmtool.last_update). Microsoft-Fabric-Anbindung für KM-Formular-E-Mails und SharePoint-Abgleich.

Architektur

flowchart TD
    A[React Frontend] --> B[React Query / Axios-Client]
    B --> C[nginx Reverse-Proxy]
    C --> D[FastAPI Backend]
    D --> E[(SQLite<br/>fleet.db)]
    D --> F[JWT Auth]

    G[Cron-Skripte<br/>Projekt-Root] --> E
    G --> H[SQL-Server / RIMO<br/>ai.sdmperson, rimo.sdmtool]
    G --> I[Microsoft Fabric<br/>SharePoint / KM-Mails]
    G --> J[GPS-AT / Tesla APIs]

Die Cron-Skripte laufen unabhängig von der FastAPI-App direkt auf dem Server (nicht im Docker-Container), schreiben aber in dieselbe fleet.db wie das Backend.

Server

Die App läuft auf 192.168.208.2, per Docker Compose (Services backend + frontend), und liegt unter /mnt/data/fleet-manager/fuhrpark.

Deployment bei Codeänderungen (manuell auf dem Server auszuführen):

sudo -u www-data git pull
docker compose up -d --build

Cronjobs: sudo -u www-data crontab -e, Logs unter /mnt/data/fleet-manager/fuhrpark/logs. Enthält u. a. den täglichen Fahrer-Sync (1_import_users_drivers.py) und die KM-Stand-Importe (gpsat/tesla/sharepoint über import_km.py).

Erreichbar unter http://fleetmanager.spl-tele.com:8501 — mit VPN und im SPL-TELE-Netzwerk.

Hinweise

• Änderungen im Demo-Modus werden nicht gespeichert.
• Benutzerrechte bestimmen die Sichtbarkeit der Daten (Line-Manager-Zuordnung).
• Regelmäßige Datenpflege (z. B. Fahrerzuordnung) ist wichtig für korrekte Auswertungen.
• backend/data/ bzw. data/ (Projekt-Root) enthält die produktive Datenbank und ist nicht Teil des Git-Repos — ein git pull verändert die Datenbank nie.