scripte/MABEA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
81a727151ab2c07a2930f9c83cbdc604e4f60925
MABEA/arbeitskacheln/09_inspections.md
T
patrickandClaude Sonnet 5 81a727151a
CI / backend-tests (push) Failing after 1m52s
Details
CI / frontend-build (push) Successful in 17s
Details
docs: Inspections-Epic komplettiert (INSP-001..006) 
Funktional großteils abgedeckt (Intervall-Berechnung, Fälligkeits-Ampel,
Prüftermin-Dashboard bereits produktiv), aber konzeptionell nicht generisch:
keine Prüfart-Stammdatentabelle, keine strukturierte Ergebnis-/Prüfer-
Erfassung, kein datumsunabhängiger FAILED-Zustand.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KC8HYvv6UkCVYheYiTw9DD
2026-09-05 15:31:15 +02:00

6.7 KiB
Raw Blame History

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.

Reference in New Issue View Git Blame Copy Permalink