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
184 lines
8.5 KiB
Markdown
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.
|