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