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