# Epic 09 — Inspections

Details zu INSP-001 … INSP-006 (vollständig).

---

## INSP-001 — Prüfarten-Stammdaten

- **Ziel:** Generische Definition, welche Prüfarten es gibt (UVV/HU/Medizinprodukt/
  Elektro/PSA/Sichtprüfung/...).
- **Beschreibung:** Stammdatentabelle Prüfart mit Name, Bezug zu AssetType(en), evtl.
  gesetzliche Grundlage als Freitext.
- **Benutzerwert:** Einheitliche Verwaltung statt für jede Prüfart eigenen Code.
- **Abhängigkeiten:** ASSET-002
- **Datenmodell:** `pruefart` (id, name, beschreibung)
- **Backend:** CRUD
- **Frontend:** Verwaltung
- **Mobile:** Anzeige
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** Prüfbereich
- **Rechte:** Administrator
- **Audit:** Änderung geloggt
- **Akzeptanzkriterien:** mehrere Prüfarten anlegen, an AssetType koppelbar.
- **Tests:** CRUD-Test.
- **DoD:** mind. 3 unterschiedliche Prüfarten (UVV, Medizinprodukt, Elektro) anlegbar.
  **Lücke:** MABEA hat nur zwei hartcodierte Prüftypen (generische Geräteprüfung +
  Fahrzeug-HU/UVV als Sonderfall), keine generische Prüfart-Stammdatentabelle.

## INSP-002 — Prüfintervalle

- **Ziel:** Wie oft muss eine Prüfart bei einem Asset wiederholt werden.
- **Beschreibung:** Intervall in Monaten (oder Tagen) je Asset/AssetType+Prüfart-
  Kombination.
- **Benutzerwert:** Automatische Berechnung des nächsten Fälligkeitstermins statt manuell
  nachhalten.
- **Abhängigkeiten:** INSP-001
- **Datenmodell:** `pruefintervall` (asset_id oder asset_type_id, pruefart_id,
  intervall_monate)
- **Backend:** Berechnung `naechste_pruefung = letzte_pruefung + intervall`
- **Frontend:** Intervall-Einstellung
- **Mobile:** Anzeige
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** Prüfbereich
- **Rechte:** Materialwart/Administrator
- **Audit:** Änderung geloggt
- **Akzeptanzkriterien:** Intervall setzen, nächster Termin korrekt berechnet.
- **Tests:** Berechnungstest (inkl. Monatsende-Sonderfall, z.B. 31.1. + 1 Monat).
- **DoD:** deckt sich mit MABEA (`pruefintervall_monate` an Objektposition,
  `_plus_monate()`-Hilfsfunktion bereits vorhanden) — bisher nur implizit „die eine
  Geräteprüfung", nicht an eine generische Prüfart gekoppelt.

## INSP-003 — Prüfdurchführung/-ergebnis

- **Ziel:** Tatsächliche Durchführung einer Prüfung erfassen.
- **Beschreibung:** Prüfergebnis (bestanden/nicht bestanden), Prüfer, Datum, Bemerkung.
- **Benutzerwert:** Nachweis, dass geprüft wurde, nicht nur „wann wäre es fällig
  gewesen".
- **Abhängigkeiten:** INSP-002
- **Datenmodell:** `pruefung` (asset_id, pruefart_id, geprueft_am, pruefer_id, ergebnis,
  bemerkung)
- **Backend:** Erfassen-Endpunkt, aktualisiert `naechste_pruefung`
- **Frontend:** Erfassungsformular
- **Mobile:** Erfassung im Feld
- **QR-Code:** Scan Asset startet Prüferfassung
- **Seriennummer/Inventarnummer:** nein
- **Akte:** Prüfbereich
- **Rechte:** Materialwart/Prüfer-Rolle
- **Audit:** Prüfung geloggt
- **Akzeptanzkriterien:** Prüfung erfassen aktualisiert nächsten Fälligkeitstermin
  korrekt.
- **Tests:** Erfassungstest.
- **DoD:** deckt sich mit MABEA (`GeraetInstanz.pruefdatum`/status, Fahrzeug-HU/UVV-Felder)
  — aber ohne strukturiertes Ergebnis-/Prüfer-Feld, nur Statuswechsel.

## INSP-004 — Status-Ampel (VALID/DUE_SOON/OVERDUE/FAILED)

- **Ziel:** Auf einen Blick erkennen, wie es um eine Prüfung steht.
- **Beschreibung:** Berechneter Status aus `naechste_pruefung` + Warnzeitraum + letztem
  Ergebnis.
- **Benutzerwert:** Ampel-Logik statt Datum im Kopf ausrechnen müssen.
- **Abhängigkeiten:** INSP-003
- **Datenmodell:** keins neu (berechnet)
- **Backend:** Statusberechnung (analog MABEA `_ablauf_status()`)
- **Frontend:** Farbcodierte Anzeige
- **Mobile:** Anzeige
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** Prüfbereich
- **Rechte:** wie Lese-Recht
- **Audit:** nein
- **Akzeptanzkriterien:** alle vier Zustände korrekt unterscheidbar (inkl. FAILED bei
  „nicht bestanden" unabhängig vom Datum).
- **Tests:** Statustest je Zustand.
- **DoD:** deckt sich mit MABEA-Berechnungsmuster (`_ablauf_status`:
  gueltig/bald_ablaufend/abgelaufen). **FAILED als eigener Zustand fehlt in MABEA:** kein
  strukturiertes Prüfergebnis vorhanden, daher kein „nicht bestanden" unabhängig vom
  Datum abbildbar.

## INSP-005 — Prüfdokument-Anbindung

- **Ziel:** Prüfprotokoll/-bescheinigung an die Prüfung anhängen.
- **Beschreibung:** Nutzt DOC-001 generisch, Kopplung an Prüfung statt nur an Asset.
- **Benutzerwert:** Nachweisdokument griffbereit bei Kontrolle/Audit.
- **Abhängigkeiten:** INSP-003, DOC-001
- **Datenmodell:** keins neu (Dokument-Polymorphie, `entitaet_typ=pruefung`)
- **Backend:** keins zusätzlich
- **Frontend:** Dokumente-Panel an der Prüfung
- **Mobile:** Anzeige
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** Prüfbereich
- **Rechte:** wie DOC-001
- **Audit:** wie DOC-001
- **Akzeptanzkriterien:** Dokument an eine konkrete Prüfung anhängen.
- **Tests:** Integrationstest.
- **DoD:** entspricht dem MABEA-Muster (DokumentePanel generisch wiederverwendbar) — die
  Whitelist der `entitaet_typ`-Werte im Dokumente-Modul kennt „pruefung" aktuell nicht,
  kleine Erweiterung nötig, kein struktureller Umbau.

## INSP-006 — Prüftermin-Übersicht

- **Ziel:** Zentrale Liste aller bald fälligen/überfälligen Prüfungen über alle Assets
  hinweg.
- **Beschreibung:** Dashboard-Kachel, sortiert nach Dringlichkeit.
- **Benutzerwert:** Planungswerkzeug für Materialwart/Prüfer — „was steht diese Woche
  an".
- **Abhängigkeiten:** INSP-004
- **Datenmodell:** keins neu
- **Backend:** Abfrage über alle Assets/Prüfarten hinweg
- **Frontend:** Dashboard-Kachel
- **Mobile:** Anzeige
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** nein (übergreifende Sicht, nicht je Akte)
- **Rechte:** Verantwortliche
- **Audit:** nein
- **Akzeptanzkriterien:** korrekte Sortierung nach verbleibenden Tagen, überfällige
  zuerst.
- **Tests:** Sortierungstest.
- **DoD:** deckt sich mit MABEA (`dashboard.bevorstehende_prueftermine()`, bereits
  umgesetzt inkl. Geräte- und Fahrzeug-HU/UVV gemischt in einer Liste).

---

**MABEA-Ist-Stand-Abgleich:** Inspections ist in MABEA **funktional großteils abgedeckt**
(Intervall-Berechnung, Fälligkeits-Ampel, Prüftermin-Dashboard-Kachel — alle bereits
produktiv), aber **konzeptionell nicht generisch**: es gibt keine Prüfart-Stammdatentabelle
(INSP-001 fehlt), Prüfungen sind nur als Statuswechsel ohne strukturiertes Ergebnis/Prüfer-
Feld erfasst (INSP-003 unvollständig), und FAILED als eigener, datumsunabhängiger Zustand
fehlt (INSP-004 unvollständig). Die Berechnungsmechanik (Intervall→Fälligkeit→Ampel) ist
aber ausgereift und direkt wiederverwendbar, sobald die generische Prüfart-Struktur
nachgezogen wird.