MABEA/arbeitskacheln/04_assets.md

Epic 04 — Assets

Details zu ASSET-001 … ASSET-010. ASSET-010 ergänzt am 2026-09-09 aus Open-Source-Vergleich (Shelf.nu Custody-Feature), noch offen/ungeplant.

---

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.
• Referenz (Open-Source-Vergleich 2026-09-09): Shelf.nu (shelf-nu/shelf.nu) nennt dasselbe Konzept „Kits" — Assets zu einer wiederverwendbaren Einheit bündeln (Laptop+Charger+Dock). Bestätigt den Bedarf, löst aber keine MABEA-spezifische Frage zusätzlich (Set-Aufbau bleibt wie hier beschrieben).

ASSET-010 — Custody/Ausgabe an Person (P2, neu, vollständig ausgearbeitet 2026-09-09)

• Ziel: Nachvollziehen, welche Person ein bestimmtes Einzelgerät aktuell persönlich in Verwahrung hat — unabhängig vom Standort-/Objekt-bezogenen ZUST-001 und von der reinen Kontroll-Zuständigkeit in ZUST-002.
• Abgrenzung zu ZUST-002 (geklärt 2026-09-09): ZUST-002 sagt „Max soll den Notfallkoffer #12 kontrollieren" — das Objekt bleibt am Standort, jeder darf es trotzdem kontrollieren, reine Empfehlung ohne Zugriffssperre. ASSET-010 sagt „Max hat Funkgerät #7 heute persönlich dabei" — das Gerät wandert physisch mit der Person, bis sie es zurückgibt; danach kann es an jemand anderen ausgegeben werden. Unterschiedliche Konzepte (Kontroll-Zuständigkeit vs. physischer Besitz), echter Bedarf bestätigt — kein Duplikat.
• Ziel-Entität (geklärt 2026-09-09): GeraetInstanz, nicht generisches Objekt. GeraetInstanz hängt an einer Objektposition und trägt die eigene Seriennummer (backend/app/models/geraet_instanz.py) — genau das einzelne, seriennummerpflichtige Gerät (Funkgerät, Atemschutzgerät), das eine Person persönlich mitführt. Ein ganzes Objekt (z.B. ein Fahrzeug oder ein Materiallager) wird nicht „mitgeführt" — dafür ist Custody nicht gedacht.
• Beschreibung: Ausgabe-/Rücknahme-Vorgang je GeraetInstanz an eine Person (PERS-001), mit Zeitstempel, Bestätigungsmechanismus (siehe unten) und Verlauf.
• Benutzerwert: Bei Verlust/Defekt sofort klar, wer das Gerät zuletzt hatte, ohne Rückfrage-Runde.
• Bestätigungsmechanismus bei Ausgabe (überarbeitet 2026-09-09, final 2026-09-09 — Unterschrift OPTIONAL pro Ausgabe, cross-device per QR-Scan):
  • Unterschrift/Protokoll ist keine Pflicht für jede Ausgabe, sondern eine Entscheidung der ausgebenden Stelle im Moment der Ausgabe — Toggle „Mit Protokoll+Unterschrift" im Ausgabe-Dialog. Ohne Toggle: einfache, formlose Ausgabe wie ursprünglich geplant (nur Custody-Zeile, kein PDF, kein QR-Signier-Flow) — schnelle Übergabe für den Alltag. Mit Toggle: voller Signier-Flow inkl. PDF-Protokoll, gedacht für kritisches/hochwertiges Material oder wenn die ausgebende Stelle es für nötig hält.
  • Ablauf (nur wenn „Mit Protokoll" gewählt): Portal (Tablet/Desktop der ausgebenden Stelle) zeigt nach Auswahl von Gerät+Empfänger einen QR-Code an, der auf eine einmalig gültige, kurzlebige Signier-Seite verweist (Token-basiert, kein Login nötig — die Legitimation ist der physische Besitz des Tablets der ausgebenden Stelle + der QR-Code selbst). Empfänger scannt den QR-Code mit dem eigenen Handy, öffnet die Signier-Seite, unterschreibt dort per Touch-Canvas auf dem eigenen Gerät (hygienischer/praktischer als eine geteilte Tablet-Oberfläche), sendet ab. Das Portal erkennt den Abschluss (Polling auf den Ausgabe-Status) und zeigt „unterschrieben ✓" an, danach gilt die Ausgabe als abgeschlossen.
  • Signier-Token: einmalig verwendbar, kurze Lebensdauer (z.B. 5 Minuten), an genau einen Ausgabevorgang gebunden — verhindert Wiederverwendung/Weitergabe des Links.
  • Aus Signatur + Geräte-/Personendaten + Zeitstempel wird automatisch ein Ausgabeprotokoll (PDF) generiert und über den DOC-001-Mechanismus am Custody-Eintrag UND in der Akte des Geräts abgelegt.
  • Bei Rücknahme: dieselbe Wahl gilt spiegelbildlich — wurde die Ausgabe mit Protokoll gemacht, läuft die Rücknahme ebenfalls über QR-Code→eigenes Handy→Unterschrift→Rückgabeprotokoll. Wurde die Ausgabe formlos gemacht, ist auch die Rücknahme formlos (kein nachträglicher Zwang zum Protokoll).
• Sicherheitsanforderungen (Security-Review 2026-09-09, owasp-top10-expert — verbindlich für die Implementierung, kein Nice-to-have):
  1. Token: secrets.token_urlsafe(32) (256 Bit), serverseitig nur als SHA-256-Hash gespeichert (wie ein Passwort-Reset-Token) — Klartext existiert nur im QR-Code/URL, nie in Logs. Access-Logs dieser Route ohne Query-String protokollieren.
  2. Route: Token als Pfad-Parameter (/signieren/{token}), nicht Query — Query-Strings landen häufiger in Logs/Referrer/Browser-History. slowapi-Rate-Limit pro IP UND pro Token (z.B. 10/Minute). Lookup ausschließlich über Token-Hash, niemals über fortlaufende Custody-ID (IDOR).
  3. Race Condition: Token-Verwendung als atomares DB-Update, nicht Read-then-Write — UPDATE ... WHERE token_hash=$1 AND status='ausstehend', Rowcount prüfen statt separatem Check+Write.
  4. QR-Abfoto-Risiko: bewusst akzeptiertes Restrisiko, kein zusätzlicher PIN-Schritt (Entscheidung 2026-09-09 — Reibung im Feldeinsatz wiegt schwerer, Ausgabe findet ohnehin unter Aufsicht der ausgebenden Stelle statt, die den Vorgang beobachtet). 5-Minuten-Ablauf + Einmalverwendung des Tokens bleiben als Grundschutz bestehen.
  5. Transport: HTTPS zwingend (ohnehin nur über nginx-TLS erreichbar). VITE_API_BASE_URL bleibt relativ (/api/v1) — Empfänger-Handy nutzt dieselbe Domain/dasselbe TLS-Zertifikat. Explizit auf echtem Fremdgerät testen, nicht nur localhost.
  6. Datensparsamkeit (DSGVO): GET-Endpunkt der Signier-Seite liefert nur Minimaldaten (Gerätebezeichnung, Empfängername, Zeitfenster) — keine vollständige Custody-Historie, keine internen IDs. Bei ungültigem/ abgelaufenem/bereits verwendetem Token identische generische Fehlermeldung (kein Enumerieren des Status). Signatur/PDF nach Abschluss nicht mehr über denselben Token abrufbar — Download nur im authentifizierten Portal-Bereich.
  7. PDF-Generierung: falls HTML-basiert (weasyprint) — Jinja2-Autoescape aktiv lassen, kein |safe auf Nutzereingaben. Signatur-Bild serverseitig validieren (Magic-Bytes/Größe/Dimensionen), bevor es ins PDF eingebettet wird — keine beliebigen Datei-URLs oder SVG mit Skript zulassen.
• Abhängigkeiten: ASSET-003, PERS-001, DOC-001 (Ausgabeprotokoll-PDF), FOUND-002 (Signier-Token braucht eigene, kurzlebige Tabelle/Cache)
• Datenmodell: geraet_instanz_custody (geraet_instanz_id → geraet_instanz.id, person_id, ausgegeben_am, ausgegeben_von_benutzer_id, mit_protokoll: bool (Toggle-Entscheidung der ausgebenden Stelle), ausgabeprotokoll_dokument_id nullable FK auf dokument (nur bei mit_protokoll=true), zurueckgegeben_am nullable, zurueckgenommen_von_benutzer_id nullable, rueckgabeprotokoll_dokument_id nullable) — aktuelle Inhaberschaft = Zeile mit zurueckgegeben_am IS NULL. signier_token (token, custody_id, ablauf_am, verwendet: bool) — nur relevant wenn mit_protokoll=true, kurzlebig, kann nach Ablauf/Verwendung gelöscht werden (kein Langzeit-Speicherbedarf).
• Backend: Ausgabe-Endpoint verzweigt nach mit_protokoll — false: Custody- Zeile direkt als abgeschlossen anlegen (formlose Ausgabe, wie ursprünglich geplant); true: Custody-Zeile unsigniert anlegen + Signier-Token erzeugen, QR-Code-Inhalt zurückgeben, öffentlicher (token-authentifizierter, kein Login) Signier-Endpoint nimmt Signatur-PNG entgegen, erzeugt PDF, markiert Custody als abgeschlossen, Status-Polling-Endpoint fürs Portal. In beiden Fällen: verhindert Doppel-Ausgabe (GeraetInstanz nur an eine Person gleichzeitig, DB-Constraint: max. eine offene Zeile je geraet_instanz_id); bei mit_protokoll=true zusätzlich Token-Ablauf serverseitig erzwungen (abgelaufene Tokens/unsignierte Ausgaben nach Timeout verwerfen)
• Frontend: Ausgabe-Dialog am Gerät — Person auswählen, Toggle „Mit Protokoll+Unterschrift"; bei aktiviertem Toggle QR-Code anzeigen → Warten-auf-Signatur-Status, sonst sofortiger Abschluss. Separate mobile Signier-Seite (eigenständige Route, kein Admin-Layout, funktioniert auf jedem Handy-Browser ohne Login) nur relevant bei aktiviertem Toggle.
• Mobile: Ausgabe-Start per QR-Scan am Gerät selbst (wie gehabt), Signatur läuft auf dem Empfänger-Handy über die separate Signier-Seite
• QR-Code: zwei unterschiedliche QR-Codes im Spiel — (1) Geräte-QR zum Auswählen des Geräts (bestehender Mechanismus), (2) neuer Signier-Token-QR zum Öffnen der Signier-Seite auf dem Empfänger-Handy
• Seriennummer/Inventarnummer: nutzt bestehende GeraetInstanz-Identität
• Akte: eigener Custody-Verlauf im Akte-Historienbereich (FILE-005)
• Rechte: Ausgabe/Rücknahme: Mitarbeiter+; Korrektur: Materialverantwortlicher+
• Audit: jede Ausgabe/Rücknahme geloggt, inkl. Zeitpunkt der Signatur
• Akzeptanzkriterien: Gerät kann nicht an zwei Personen gleichzeitig ausgegeben sein; formlose Ausgabe (mit_protokoll=false) ist sofort abgeschlossen, kein Signier-Flow ausgelöst; Ausgabe mit Protokoll ohne abgeschlossene Signatur gilt nicht als abgeschlossen (Gerät bleibt bis zur Signatur „in Ausgabe schwebend", nicht schon fest zugeordnet); abgelaufener/bereits verwendeter Signier-Token wird abgelehnt; Ausgabeprotokoll- PDF enthält Geräte-, Personen-, Zeit- und Signaturdaten; Verlauf zeigt lückenlose Kette.
• Tests: Doppel-Ausgabe-Ablehnung, abgelaufener-Token-Ablehnungstest, bereits- verwendeter-Token-Ablehnungstest, PDF-Generierungstest, Ausgabe→Signatur→ Rücknahme→Signatur→Neuausgabe-Zyklus, Race-Condition-Test (paralleler Request auf denselben Token, nur einer darf gewinnen), Rate-Limit-Test, IDOR-Test (Token-Lookup nur über Hash, keine ID-Erratbarkeit), Signatur-Bild-Validierungs- test (ungültige/manipulierte Datei wird abgelehnt).
• DoD: offen — Design vollständig geklärt (2026-09-09), bereit für Implementierung. Referenz (Open-Source-Vergleich 2026-09-09): Shelf.nu (shelf-nu/shelf.nu, AGPL-3.0 — nur Konzeptvorbild, keine Codeübernahme wegen Copyleft) — „Custody"-Feature, Kernaussage „know who has what at all times".

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