MABEA/arbeitskacheln/10_maintenance.md

Epic 10 — Maintenance

Details zu MAINT-001 … MAINT-007. MAINT-001-004+006 vollständig, MAINT-005 P3 zurückgestellt, MAINT-007 ergänzt am 2026-09-09 aus Open-Source-Vergleich (FleetMS), ebenfalls P3/offen.

---

MAINT-001 — Wartungspläne

• Ziel: Definierte Wartungsvorgaben je AssetType/Asset.
• Beschreibung: Wartungsplan-Stammdaten mit Bezug zu AssetType, Liste vorgesehener Wartungsarten (z.B. „Ölwechsel", „Filterwechsel").
• Benutzerwert: Standardisierte Wartungsvorgaben statt Herstellerhandbuch jedes Mal nachschlagen.
• Abhängigkeiten: ASSET-002
• Datenmodell: wartungsplan (id, asset_type_id, name), wartungsplan_position (plan_id, wartungsart, beschreibung)
• Backend: CRUD
• Frontend: Verwaltung
• Mobile: Anzeige
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: Wartungsbereich
• Rechte: Materialwart/Administrator
• Audit: Änderung geloggt
• Akzeptanzkriterien: Wartungsplan mit mehreren Positionen anlegen.
• Tests: CRUD-Test.
• DoD: umgesetzt (2026-09-06). wartungsplan/wartungsplan_position je Objekttyp, POST/GET /wartungsplaene, Admin-Tab "Wartungspläne".

MAINT-002 — Wartungsintervalle

• Ziel: Wann eine Wartungsposition fällig wird (zeit-, km- oder betriebsstundenabhängig).
• Beschreibung: Intervall-Typ (Zeit/km/Betriebsstunden) + Wert, nutzt ASSET-009 für den Zähler-Abgleich.
• Benutzerwert: Automatische Fälligkeitsberechnung statt Herstellervorgabe manuell im Kopf behalten.
• Abhängigkeiten: MAINT-001, ASSET-009
• Datenmodell: wartungsintervall (wartungsplan_position_id, typ: zeit/km/betriebsstunden, wert)
• Backend: Fälligkeitsberechnung, kombiniert ggf. mehrere Kriterien („je nachdem was zuerst eintritt")
• Frontend: Intervall-Einstellung
• Mobile: Anzeige
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: Wartungsbereich
• Rechte: Materialwart/Administrator
• Audit: Änderung geloggt
• Akzeptanzkriterien: alle drei Intervall-Typen einzeln und kombiniert korrekt berechnet.
• Tests: Berechnungstest je Typ + Kombinationstest („je nachdem was zuerst eintritt").
• DoD: umgesetzt (2026-09-06), abgewandelt: wartungsintervall (zeit/km/ betriebsstunden je Position, mehrere kombinierbar). Statt eines eigenen Zähler-Abgleich-Konzepts (ASSET-009 existiert in MABEA nicht) werden die bereits vorhandenen Fahrzeugdetails.kilometerstand/betriebsstunden genutzt — für Geräte ohne Fahrzeugdetails wirkt nur das Zeit-Intervall. GET /objekte/{id}/faellige-wartungen berechnet je Position, welches Kriterium zuerst eintritt; nie durchgeführt gilt immer als fällig. Getestet: alle drei Typen einzeln + Kombination ("km vor Zeit fällig").

MAINT-003 — Wartungsauftrag

• Ziel: Konkrete Durchführung einer fälligen Wartung beauftragen/nachverfolgen.
• Beschreibung: Auftrag mit Status (offen/in Arbeit/erledigt), zugeordnet zu Wartungsplan-Position + Asset.
• Benutzerwert: Werkstattauftrag nachvollziehbar statt Zettelwirtschaft.
• Abhängigkeiten: MAINT-002
• Datenmodell: wartungsauftrag (id, asset_id, wartungsplan_position_id, status, erstellt_am, erledigt_am, durchgefuehrt_von)
• Backend: CRUD + Statuswechsel
• Frontend: Auftragsliste/-formular
• Mobile: Statuswechsel im Feld
• QR-Code: Scan Asset zeigt offene Aufträge
• Seriennummer/Inventarnummer: nein
• Akte: Wartungsbereich
• Rechte: Materialwart/Administrator erstellt, Werkstatt/Fahrzeugwart erledigt
• Audit: Statuswechsel geloggt
• Akzeptanzkriterien: Auftrag anlegen, Status durchlaufen bis erledigt.
• Tests: Statuswechsel-Test.
• DoD: umgesetzt (2026-09-06). wartungsauftrag (Objekt + optional Geräte-Instanz + optional Wartungsplan-Position — auch ad-hoc ohne Plan, z.B. "kleinere Reparatur"), Status offen/in_arbeit/erledigt, **werkstatt_intern
  • werkstatt_name** (beantwortet die Nutzerfrage nach externer Werkstatt), Kosten optional. Zyklus offen→in_arbeit→erledigt getestet, inkl. ad-hoc- Auftrag ohne Plan.

MAINT-004 — Wartungshistorie

• Ziel: Nachvollziehen, welche Wartungen wann durchgeführt wurden.
• Beschreibung: Liste erledigter Wartungsaufträge je Asset.
• Benutzerwert: Wartungsnachweis (auch für Garantie/Weiterverkauf relevant).
• Abhängigkeiten: MAINT-003, FOUND-006
• Datenmodell: keins neu (aus MAINT-003-Daten)
• Backend: Abfrage je Asset
• Frontend: Anzeige in der Akte
• Mobile: Anzeige
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: Historien-/Wartungsbereich
• Rechte: wie Lese-Recht
• Audit: zeigt Audit-relevante Daten
• Akzeptanzkriterien: chronologische Liste korrekt.
• Tests: Anzeigetest.
• DoD: umgesetzt (2026-09-06). Kein neuer Endpunkt nötig - GET /wartungsauftraege?objekt_id= liefert offene+erledigte, Akte zeigt beide getrennt in der neuen "Wartung"-Sektion.

MAINT-005 — Ersatzteile/Kosten (P3, umgesetzt 2026-09-08)

• Ziel: Welche Teile/Kosten bei einer Wartung angefallen sind.
• Beschreibung: Ersatzteilliste + Kostenfeld je Wartungsauftrag.
• Benutzerwert: Kostenübersicht/Budgetplanung.
• Abhängigkeiten: MAINT-003
• Datenmodell: wartungsauftrag_teil (auftrag_id, bezeichnung, menge, kosten)
• Backend: CRUD
• Frontend: Positionsliste im Auftrag
• Mobile: Erfassung
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: Wartungsbereich
• Rechte: Materialwart/Administrator
• Audit: Änderung geloggt
• Akzeptanzkriterien: Teile/Kosten erfassen, Summe korrekt.
• Tests: Summen-Test.
• DoD: ✅ umgesetzt (2026-09-08) — WartungsauftragTeil (Migration 0033), /wartungsauftraege/{id}/teile-CRUD, UI in WartungSection.tsx.

MAINT-006 — Wartungsdokument-Anbindung

• Ziel: Wartungsbericht/Rechnung an den Auftrag anhängen.
• Beschreibung: Nutzt DOC-001, entitaet_typ=wartungsauftrag.
• Benutzerwert: Beleg griffbereit.
• Abhängigkeiten: MAINT-003, DOC-001
• Datenmodell: keins neu
• Backend: keins zusätzlich
• Frontend: Dokumente-Panel am Auftrag
• Mobile: Anzeige
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: Wartungsbereich
• Rechte: wie DOC-001
• Audit: wie DOC-001
• Akzeptanzkriterien: Dokument anhängen.
• Tests: Integrationstest.
• DoD: umgesetzt (2026-09-06). entitaet_typ=wartungsauftrag zur Whitelist ergänzt, DokumentePanel in der Wartung-Sektion der Akte je Auftrag.

MAINT-007 — Tankbuch/Kraftstoffverbrauch (P3, neu)

• Ziel: Kraftstoffbetankungen je Fahrzeug erfassen, Verbrauch (l/100km) ableiten.
• Beschreibung: Betankungs-Log (Datum, Menge, Kosten, Kilometerstand zum Betankungszeitpunkt) je Fahrzeug, Verbrauchsberechnung aus aufeinanderfolgenden Einträgen.
• Benutzerwert: Budgetplanung, Auffälligkeiten (Mehrverbrauch als früher Hinweis auf technisches Problem) erkennbar.
• Abhängigkeiten: FLEET-002 (Fahrzeugdetails.kilometerstand) — nicht ASSET-009, das laut eigenem Ist-Stand-Abgleich in 04_assets.md weiterhin fehlt (kein generischer Zähler vorhanden, nur das Fahrzeug-Feld direkt)
• Datenmodell: tankbuch_eintrag (objekt_id → objekt.id, datum, menge_liter, kosten, kilometerstand) — kein asset-Modell in MABEA, real heißt die Tabelle objekt
• Backend: CRUD, Verbrauchsberechnung zwischen zwei Einträgen
• Frontend: Tankbuch-Liste je Fahrzeug, Verbrauchsanzeige
• Mobile: Erfassung nach dem Tanken
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: Wartungs-/Fahrzeugbereich
• Rechte: jeder Nutzer darf erfassen, Korrektur Materialwart+
• Audit: Änderung geloggt
• Akzeptanzkriterien: zwei Einträge ergeben korrekten l/100km-Wert.
• Tests: Verbrauchsberechnungstest.
• DoD: offen, P3 — kein MVP-Bestandteil, analog MAINT-005-Priorisierung. Referenz (Open-Source-Vergleich 2026-09-09): FleetMS (jmnda-dev/fleetms, Elixir/Phoenix, AGPL-3.0 — Projekt selbst laut eigenem README unreif/Prototyp, nur als Ideengeber, kein Vorbild für Codequalität) führt ein einfaches Fuel-Log als eigenständiges Fahrzeug-Modul — Konzept übertragbar, MABEA hat aktuell keinerlei Kraftstoff-Tracking.

---

MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-09): MAINT-001..006 vollständig umgesetzt — echtes Wartungskonzept existiert jetzt (Wartungspläne, Intervalle, Werkstattaufträge intern/extern, Historie, Dokument-Anhang, Ersatzteile/Kosten je Auftrag seit 2026-09-08). MAINT-007 (Tankbuch) neu ergänzt am 2026-09-09, offen/ungeplant.