Files
MABEA/arbeitskacheln/10_maintenance.md
T
patrickandClaude Sonnet 5 9c6426190e docs(arbeitskacheln): Open-Source-/HiOrg-Vergleich ausgewertet, 14 neue Kacheln ausgearbeitet
Vergleich mit InvenTree, Snipe-IT, Grocy, Shelf.nu, Resgrid, KP Front, FleetMS,
HiOrg-Server ergibt neue Kacheln (ASSET-010 Custody, FILE-008 Hash-Audit-Journal,
FILE-009 Notizen, NOTIF-003, MAINT-007 Tankbuch, ZUST-003 Standort-Scoping,
FOUND-007 Import/Export, FOUND-008 Fristen-Dienst, READY-006 Statistik-Dashboard,
UI2-006..010) sowie Referenz-Ergänzungen bei bestehenden Lücken. Alle Design-
Entscheidungen (Datenmodell, Sicherheitsanforderungen bei ASSET-010) geklärt.

Neues Epic 23 (Flutter-Begleit-App, Sondierungs-Prototyp FLUT-001) inkl. geklärtem
TLS-Blocker (Domain mabea.perlbach-edv.de mit Let's-Encrypt-Zertifikat statt
selbstsigniertem Server-Zertifikat).

Alle Kacheln bleiben offen/ungeplant, nur ausgearbeitet, keine Implementierung.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CVgbozhYmuEhiEJHffRXCV
2026-09-10 00:49:32 +02:00

184 lines
8.5 KiB
Markdown

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