MABEA/arbeitskacheln/04_assets.md

# Epic 04 — Assets

Details zu ASSET-001 … ASSET-008 (vollständig).

---

## ASSET-001 — AssetCategory

- **Ziel:** Oberste Gliederungsebene für Ressourcentypen.
- **Beschreibung:** Kategorie-Stammdaten (z.B. „Medizin", „Fahrzeuge", „Funk").
- **Benutzerwert:** Navigierbare Struktur beim Anlegen/Suchen.
- **Abhängigkeiten:** FOUND-002
- **Datenmodell:** `asset_category` (id, name)
- **Backend:** CRUD
- **Frontend:** Verwaltung Kategorie
- **Mobile:** nur Anzeige/Filter
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** nein direkt
- **Rechte:** Administrator
- **Audit:** Änderung geloggt
- **Akzeptanzkriterien:** Kategorie anlegen/umbenennen/löschen (nur wenn unbenutzt).
- **Tests:** CRUD-Test, Löschschutz-Test bei Verwendung.
- **DoD:** mind. 3 Beispielkategorien angelegt.

## ASSET-002 — AssetType

- **Ziel:** Konkreter Typ innerhalb einer Kategorie (z.B. „AED Philips FRx").
- **Beschreibung:** Typ-Stammdaten, verweist auf Kategorie + Hersteller/Modell (IDENT-005).
- **Benutzerwert:** Wiederverwendbare Vorlage für alle Exemplare dieses Typs.
- **Abhängigkeiten:** ASSET-001
- **Datenmodell:** `asset_type` (id, category_id, name, hersteller_id, modell)
- **Backend:** CRUD
- **Frontend:** Verwaltung
- **Mobile:** Anzeige
- **QR-Code/Seriennummer/Inventarnummer:** nein direkt
- **Akte:** Stammdatenbereich referenziert den Typ
- **Rechte:** Materialwart/Administrator
- **Audit:** Änderung geloggt
- **Akzeptanzkriterien:** Typ anlegen mit Kategorie- und Hersteller-Verknüpfung.
- **Tests:** CRUD- + Verknüpfungstest.
- **DoD:** mind. ein Typ je Kategorie angelegt.

## ASSET-003 — Asset/AssetInstance

- **Ziel:** Das konkrete Einzelobjekt (physische Ressource) — Kernentität der Plattform.
- **Beschreibung:** Instanz eines AssetType mit eigener Objekt-ID, Inventarnummer,
  Seriennummer.
- **Benutzerwert:** „Ein Ding, ein Datensatz" — Grundlage für praktisch alle anderen Epics.
- **Abhängigkeiten:** ASSET-002, IDENT-001/002/004
- **Datenmodell:** `asset` (id, asset_type_id, inventarnummer, seriennummer, status, ...)
- **Backend:** CRUD
- **Frontend:** Anlegen-Formular, Liste
- **Mobile:** Anzeige/Anlage im Feld
- **QR-Code:** wird für diese Instanz erzeugt (IDENT-006)
- **Seriennummer/Inventarnummer:** hier verortet
- **Akte:** 1:1 Grundlage der Akte
- **Rechte:** Materialwart/Administrator schreibt, alle lesen
- **Audit:** Anlage/Änderung geloggt
- **Akzeptanzkriterien:** Asset anlegen mit Typ-Referenz, Inventarnummer/SN eindeutig im
  jeweiligen Scope.
- **Tests:** CRUD-Test, Eindeutigkeits-Constraint-Test.
- **DoD:** durchgängig mit IDENT-001/002/004 verzahnt getestet.

## ASSET-004 — Asset-Status-Modell

- **Ziel:** Genereller Lebenszyklus-Status, den alle Ressourcentypen teilen.
- **Beschreibung:** Enum z.B. AKTIV/IN_WARTUNG/AUSSER_DIENST — Erweiterungspunkt für
  Readiness; spezifische Module wie Fleet dürfen feiner erweitern (FLEET-004).
- **Benutzerwert:** Einheitliche Sprache über alle Ressourcentypen hinweg.
- **Abhängigkeiten:** ASSET-003
- **Datenmodell:** `asset.status` (enum)
- **Backend:** Statuswechsel-Endpoint
- **Frontend:** Status-Dropdown
- **Mobile:** Anzeige/Änderung
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** Stammdatenbereich (Status-Badge)
- **Rechte:** Materialwart/Administrator
- **Audit:** Statuswechsel geloggt
- **Akzeptanzkriterien:** Statuswechsel möglich, ungültige Übergänge (falls modelliert)
  abgelehnt.
- **Tests:** Statuswechsel-Test.
- **DoD:** Status fließt sichtbar in FILE-002 ein.

## ASSET-005 — Asset-Suche & Liste

- **Ziel:** Ressourcen wiederfinden, ohne ihre Akte-ID einzeln zu kennen.
- **Beschreibung:** Liste mit Filter (Kategorie/Typ/Status) + Volltextsuche
  (Name/Inventarnummer/SN).
- **Benutzerwert:** Alltagswerkzeug für Materialwart/Helfer.
- **Abhängigkeiten:** ASSET-003
- **Datenmodell:** keins neu
- **Backend:** Such-/Filter-Query-Parameter am Listen-Endpunkt
- **Frontend:** Listen-Seite mit Suchfeld/Filtern
- **Mobile:** kompakte Listenansicht
- **QR-Code:** nein
- **Seriennummer/Inventarnummer:** Suchfelder
- **Akte:** Sprungziel je Zeile
- **Rechte:** wie Lese-Recht
- **Audit:** nein
- **Akzeptanzkriterien:** Suche nach Inventarnummer/SN/Name liefert korrekte Treffer.
- **Tests:** Suchtest mit kombinierten Kriterien.
- **DoD:** Performance akzeptabel bei realistischer Datenmenge (Index statt
  Volltabellen-Scan).

## ASSET-006 — Asset-Bewegungshistorie

- **Ziel:** Generisches Standortwechsel-Protokoll für jedes Asset, nicht nur
  fahrzeug-/warehouse-spezifisch.
- **Beschreibung:** Bewegung(asset_id, von, nach, wer, wann, warum) — Basis für
  WH-007/FILE-003.
- **Benutzerwert:** Nachvollziehbarkeit „wo war das Ding wann".
- **Abhängigkeiten:** ASSET-003, WH-001
- **Datenmodell:** `asset_bewegung`
- **Backend:** Bewegung erzeugen bei Standortwechsel
- **Frontend:** Verschieben-Aktion
- **Mobile:** ggf. später (P2)
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** Standort- und Historienbereich
- **Rechte:** Materialwart+
- **Audit:** eigenständiges Fach-Protokoll (nicht generisches Audit-JSON, da Von/Nach-Felder
  strukturiert gebraucht werden — bewusst getrennt von FOUND-006)
- **Akzeptanzkriterien:** Standortwechsel erzeugt Bewegungseintrag korrekt.
- **Tests:** Bewegungstest.
- **DoD:** funktional deckungsgleich mit dem in MABEA bereits existierenden
  Lagerbewegung-Modell (dient hier als Vorbild/Referenzimplementierung).

## ASSET-007 — AssetSet

- **Ziel:** Mehrere Assets als ein handhabbares Bündel (Materialset) verwalten.
- **Beschreibung:** Set-Entität mit Mitgliedsliste (Assets oder Consumables in bestimmter
  Menge).
- **Benutzerwert:** z.B. „Verbandsset" als eine Ausgabeeinheit statt Einzelteile einzeln zu
  handhaben.
- **Abhängigkeiten:** ASSET-003
- **Datenmodell:** `asset_set`, `asset_set_mitglied`
- **Backend:** CRUD Set + Mitglieder
- **Frontend:** Set-Zusammenstellung
- **Mobile:** Anzeige
- **QR-Code:** Set kann eigene Identität/eigenen QR bekommen (IDENT-001 anwendbar)
- **Seriennummer/Inventarnummer:** Set selbst kann eigene Inventarnummer haben
- **Akte:** eigene Akte für das Set
- **Rechte:** Materialwart+
- **Audit:** Änderung der Mitgliederliste geloggt
- **Akzeptanzkriterien:** Set anlegen, Mitglieder hinzufügen/entfernen.
- **Tests:** CRUD-Test.
- **DoD:** mind. ein Set mit 2+ Mitgliedern funktionsfähig. **Lücke gegenüber MABEA:**
  Beladungsvorlage ist konzeptionell ähnlich, aber fest ans Objekt gebunden — kein
  eigenständiges, wiederverwendbares Set-Konzept.

## ASSET-008 — Consumable

- **Ziel:** Verbrauchsmaterial als eigenes Konzept vom Einzelgerät abgrenzen.
- **Beschreibung:** Consumable-Typ mit Mengenführung statt Einzelinstanz-pro-Objekt-ID.
- **Benutzerwert:** Verbandsmaterial/Medikamente etc. sinnvoll ohne künstliche Einzel-IDs je
  Stück verwalten.
- **Abhängigkeiten:** ASSET-002
- **Datenmodell:** `consumable` (asset_type_id, ...) — im Unterschied zu Asset keine 1:1
  Objekt-ID pro Stück, sondern Menge an einem Ort (Ausbau folgt in INV-003)
- **Backend:** Grundmodell
- **Frontend:** Unterscheidung im AssetType-Formular („ist Verbrauchsmaterial")
- **Mobile:** Anzeige
- **QR-Code/Seriennummer:** Consumables i.d.R. ohne SN, ggf. Charge (INV-004)
- **Inventarnummer:** i.d.R. nicht je Stück, ggf. je Charge
- **Akte:** vereinfachte Akte (Bestandsverlauf statt Einzelverlauf)
- **Rechte:** Materialwart+
- **Audit:** Änderung geloggt
- **Akzeptanzkriterien:** Consumable-Typ anlegen, unterscheidet sich klar von Asset im
  Datenmodell (keine Einzel-Instanzen entstehen).
- **Tests:** Abgrenzungstest.
- **DoD:** Grundlage für INV-003 gelegt.

## ASSET-009 — Nutzungszähler (Kilometer/Betriebsstunden generisch)

- **Nachtrag (Nutzer-Fund):** ursprünglich fälschlich als FLEET-003 fahrzeug-gebunden
  geplant. Betriebsstunden brauchen aber auch Stromerzeuger, Pumpen und andere Geräte
  (explizit in der Ursprungs-Anforderung Modul 14 „Wartung": „kilometerabhängige UND
  betriebsstundenabhängige Wartung" — nicht auf Fahrzeuge beschränkt). Generischer
  Nutzungszähler gehört daher ins Assets-Epic, nicht ins Fleet-Epic.
- **Ziel:** Nutzungsgrad JEDES Assets erfassen, das einen Zähler hat (Kilometer ODER
  Betriebsstunden ODER beides) — Basis für zähler-abhängige Wartungsintervalle (MAINT-002).
- **Beschreibung:** generisches Zählerfeld je Asset (Typ: km/Betriebsstunden/keins),
  Erfassungsverlauf (nicht nur aktueller Wert, sondern Verlauf der Meldungen).
- **Benutzerwert:** Fahrzeuge (km), aber auch Stromerzeuger/Pumpen/Kompressoren
  (Betriebsstunden) bekommen dieselbe Wartungslogik, ohne dass jedes Modul sein eigenes
  Zählerfeld neu erfindet.
- **Abhängigkeiten:** ASSET-003
- **Datenmodell:** `asset.zaehler_typ` (enum: keiner/kilometer/betriebsstunden),
  `asset.zaehlerstand` (aktuell), optional `zaehlerstand_historie`
- **Backend:** Update-Endpoint mit Plausibilitätsprüfung (nur steigend, Override nur
  Administrator)
- **Frontend:** Eingabefeld bei Kontrolle/Rückkehr bzw. nach Nutzung
- **Mobile:** Eingabe im Feld
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** Stammdatenbereich
- **Rechte:** jeder Nutzer darf melden, Korrektur nur Administrator
- **Audit:** Änderung geloggt
- **Akzeptanzkriterien:** Wert kann nur steigen (Validierung gegen Rückwärtslauf, außer
  Admin-Override); funktioniert gleichermaßen für ein Fahrzeug (km) und ein Gerät
  (Betriebsstunden).
- **Tests:** Validierungstest je Zählertyp, Test mit einem Nicht-Fahrzeug-Asset
  (z.B. Stromerzeuger).
- **DoD:** mind. ein Fahrzeug UND ein Gerät (z.B. Stromerzeuger) nutzen denselben
  Mechanismus nachweisbar.

---

**MABEA-Ist-Stand-Abgleich:** ASSET-001…004 entsprechen `Bereich`/`Kategorie`,
`Objekttyp`, `Objekt`, `ObjektStatus` — vollständig vorhanden, inkl. des 5-stufigen
Fahrzeug-Status als Beispiel für ASSET-004-Erweiterung. ASSET-005 (Suche/Filter) vorhanden
in ObjektListPage/ObjektSection. ASSET-006 (Bewegungshistorie) vorhanden als
`Lagerbewegung` (diente hier sogar als Vorbild). **ASSET-007 (AssetSet) und ASSET-008
(Consumable als eigenständiges Konzept) fehlen** — echte Lücken, wie schon in der
Gap-Analyse vorher notiert. **ASSET-009 (generischer Nutzungszähler) fehlt ebenfalls:**
MABEA hat Kilometerstand/Betriebsstunden nur an `fahrzeugdetails` (1:1 zu Objekt mit
`ist_zugfahrzeug`), Geräte wie Stromerzeuger/Pumpen (`GeraetInstanz`) haben aktuell KEIN
Betriebsstunden-Feld — echte Lücke, wenn Wartung künftig betriebsstundenabhängig geplant
werden soll (MAINT-002, Wartungs-Epic in MABEA ohnehin noch komplett offen).