MABEA/arbeitskacheln/06_inventory.md

Epic 06 — Inventory

Details zu INV-001 … INV-007 (vollständig).

---

INV-001 — Materialarten/Kategorien

• Ziel: Grobe Materialarten-Gliederung innerhalb Inventory.
• Beschreibung: Unterscheidet sich von ASSET-001 durch Fachlichkeit (Medizin/ Sanitätsmaterial/Funk/Strom/...) statt technischer Asset-Kategorie — Entscheidung: ASSET-001 wiederverwenden, keine Doppelstruktur.
• Benutzerwert: Konsistente Kategorien app-weit statt zwei parallele Systeme.
• Abhängigkeiten: ASSET-001
• Datenmodell: keins neu (Wiederverwendung von asset_category)
• Backend/Frontend/Mobile: keins zusätzlich
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: nein direkt
• Rechte: wie ASSET-001
• Audit: wie ASSET-001
• Akzeptanzkriterien: keine doppelte Kategorie-Verwaltung im UI.
• Tests: keine zusätzlichen.
• DoD: Entscheidung dokumentiert (kein neuer Code nötig) — MABEA macht das bereits so (Material nutzt dieselbe Kategorie/Bereich-Struktur wie Objekte).

INV-002 — Einzelgeräte (SN-pflichtig)

• Ziel: Materialtyp, der als Asset (nicht Consumable) geführt wird, mit Pflicht-SN.
• Beschreibung: Kennzeichnung am AssetType („materialtyp=geraet_sn"), erzwingt SN-Erfassung bei Instanzanlage.
• Benutzerwert: Geräte wie Pulsoxymeter/Defibrillator korrekt als Einzelstücke mit Prüfhistorie führen.
• Abhängigkeiten: ASSET-003, IDENT-004
• Datenmodell: asset_type.materialtyp (enum: standard/ablauf_charge/geraet_sn)
• Backend: Validierung SN-Pflicht bei diesem Typ
• Frontend: Formular passt sich Materialtyp an
• Mobile: Erfassung im Feld
• QR-Code: eigener QR je Instanz (IDENT-006)
• Seriennummer: hier Pflichtfeld
• Inventarnummer: ergänzend
• Akte: Stammdatenbereich
• Rechte: Materialwart+
• Audit: Änderung geloggt
• Akzeptanzkriterien: Anlage ohne SN bei diesem Typ wird abgelehnt.
• Tests: Validierungstest.
• DoD: deckt sich mit MABEA materialtyp=geraet_sn + GeraetInstanz (bereits umgesetzt).

INV-003 — Verbrauchsmaterial (Mengen)

• Ziel: Mengenbasierte Führung statt Einzel-Instanz.
• Beschreibung: Consumable-Bestand als Zahl+Einheit statt Liste von Objekten.
• Benutzerwert: Verbandsmaterial/Medikamente ohne unnötigen Verwaltungsaufwand pro Stück.
• Abhängigkeiten: ASSET-008
• Datenmodell: bestand (consumable_id, standort_id, menge, einheit)
• Backend: Mengenanpassung (Zu-/Abgang)
• Frontend: Mengenfeld statt Instanzliste
• Mobile: Mengenerfassung bei Kontrolle
• QR-Code: nein direkt
• Seriennummer: entfällt
• Inventarnummer: ggf. je Charge (INV-004), nicht je Stück
• Akte: vereinfachte Bestandsansicht
• Rechte: Mitarbeiter darf melden, Materialwart verwaltet Struktur
• Audit: Mengenänderung geloggt
• Akzeptanzkriterien: Menge erhöhen/verringern, negative Menge unmöglich.
• Tests: Grenzwerttest (0, negativ abgelehnt).
• DoD: deckt sich mit MABEA Objektposition.istmenge (materialtyp=standard/ablauf_charge).

INV-004 — Chargenverwaltung

• Ziel: Mehrere Chargen desselben Verbrauchsmaterials unterscheidbar führen.
• Beschreibung: Chargennummer + Ablaufdatum je Teilbestand statt nur am Gesamtbestand.
• Benutzerwert: Rückrufaktionen chargen-genau möglich, unterschiedliche Ablaufdaten pro Charge korrekt abgebildet.
• Abhängigkeiten: INV-003
• Datenmodell: charge (consumable_bestand_id, chargennummer, ablaufdatum, menge)
• Backend: CRUD je Charge
• Frontend: Chargen-Liste je Verbrauchsmaterial
• Mobile: Erfassung bei Wareneingang
• QR-Code: nein
• Seriennummer: entfällt
• Inventarnummer: Chargennummer ist eine Art Sub-Identität
• Akte: Bestandsverlauf-Detailebene
• Rechte: Materialwart+
• Audit: Änderung geloggt
• Akzeptanzkriterien: mehrere Chargen mit unterschiedlichem Ablaufdatum gleichzeitig führbar.
• Tests: Mehrfach-Chargen-Test.
• DoD: echte MABEA-Lücke: MABEA führt chargennummer+ablaufdatum nur EINFACH je Objektposition (ein Wert, keine Liste) — mehrere Chargen gleichzeitig an derselben Position sind aktuell NICHT abbildbar. Diese Kachel wäre in MABEA kein reiner Nachzug, sondern ein Datenmodell-Umbau (1:1 → 1:n).

INV-005 — Ablaufdaten & Warnschwellen

• Ziel: Frühwarnung vor Ablauf von Verbrauchsmaterial/Chargen.
• Beschreibung: Warnschwelle (Tage vor Ablauf) je Material oder global konfigurierbar, Statusberechnung (gültig/bald ablaufend/abgelaufen).
• Benutzerwert: Materialwart erkennt rechtzeitig, bevor Material abläuft, kann rotieren/nachbestellen.
• Abhängigkeiten: INV-004
• Datenmodell: warnzeitraum_tage (an Material oder global als Default) — Status wird berechnet, nicht gespeichert
• Backend: Berechnungsfunktion + Endpoint „bevorstehende Ablaufdaten"
• Frontend: Dashboard-Kachel/Liste
• Mobile: Anzeige
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: Bestandsverlauf-Detailebene
• Rechte: wie Lese-Recht (Verantwortliche)
• Audit: nein (reine Berechnung)
• Akzeptanzkriterien: korrekte Einteilung gültig/bald_ablaufend/abgelaufen nach Schwelle.
• Tests: Schwellenwert-Tests (Randfälle: genau am Schwellenwert, exakt heute).
• DoD: deckt sich mit MABEA (bevorstehende_ablaufdaten(), Dashboard-Kachel) — bereits vollständig umgesetzt.

INV-006 — Mindestbestände & Fehlbestandserkennung

• Ziel: Automatische Erkennung, wenn Ist < Soll.
• Beschreibung: Sollmenge je Material/Ort, Vergleich mit Istmenge, automatischer Fehlbestand-Vorgang bei Abweichung. Sonderfall Sofort-Nachfüllung (übernommen aus arbeitskarten/07_sofort_nachfuellung.md, Karte 07): füllt die Besatzung eine Fehlmenge noch während der laufenden Kontrolle direkt aus dem Lager nach, entsteht der Fehlbestand-Vorgang trotzdem und wird im selben Moment als erledigt markiert — kein "verschwindet spurlos", Statuswechsel offen→erledigt muss auch innerhalb derselben Kontrollsitzung möglich sein, mit vollständiger Zeitstempel-Historie.
• Benutzerwert: Kern der ganzen Bestandskontrolle — keine manuelle Dauerüberwachung nötig.
• Abhängigkeiten: INV-003, LOAD-001 (Soll kommt oft aus dem Beladungsplan)
• Datenmodell: fehlbestand (material_id, ort_id, sollmenge, istmenge, fehlmenge, status, entstanden_am)
• Backend: Erkennungslogik bei Kontrolle/Bestandsänderung
• Frontend: Fehlbestand-Liste, Nachfüll-Aktion
• Mobile: Nachfüllen im Feld
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: eigener Bereich bzw. Teil des Bestandsverlaufs
• Rechte: Melden/Nachfüllen: Mitarbeiter+; Mindermenge genehmigen: Verantwortliche. Genehmigte Mindermenge (übernommen aus arbeitskarten/08_mindermenge_gueltigkeit.md, Karte 08) gilt automatisch nur bis zur nächsten Kontrolle des betroffenen Objekts — kein festes Ablaufdatum, kein unbefristetes Gelten. Bei nächster Kontrolle wird die Ist-Menge neu erfasst; besteht die Abweichung weiterhin, muss neu entschieden werden (neue Genehmigung oder Fehlbestand wieder aktiv).
• Audit: Entstehung/Erledigung geloggt
• Akzeptanzkriterien: Abweichung erzeugt Fehlbestand automatisch, Nachfüllung reduziert Fehlmenge korrekt, bei 0 automatisch erledigt — auch wenn Entstehung und Erledigung in derselben Kontrollsitzung liegen.
• Tests: Erkennungstest, Nachfüll-Test, Mindermenge-Sonderfall, Sofort-Nachfüllung innerhalb derselben Kontrollsitzung.
• DoD: deckt sich 1:1 mit MABEA (Fehlbestand-Kernmodul inkl. Mindermenge-Genehmigung und Sofort-Nachfüllung-Sonderfall) — eines der am weitesten ausgereiften Module im gesamten Projekt, bereits vollständig umgesetzt.

INV-007 — Ausgabe/Rückgabe

• Ziel: Verbrauchsmaterial/Leihgeräte gezielt an Person/Einsatz ausgeben und zurücknehmen, nicht nur pauschal Bestand ändern.
• Beschreibung: Ausgabevorgang mit Empfänger (Person/Einheit/Einsatz), Rückgabe schließt den Vorgang, offene Ausgaben bleiben sichtbar.
• Benutzerwert: Nachvollziehbarkeit „wer hat was gerade" — z.B. Leihgeräte, Schlüssel, Funkgeräte.
• Abhängigkeiten: INV-003
• Datenmodell: ausgabe (material_id/asset_id, menge, empfaenger_id, ausgegeben_am, rueckgabe_am, status offen/zurück)
• Backend: Ausgabe-/Rückgabe-Endpunkte
• Frontend: Ausgabe-Formular, Liste offener Ausgaben
• Mobile: Ausgabe im Feld erfassen
• QR-Code: Scan des Assets kann Ausgabevorgang direkt starten
• Seriennummer/Inventarnummer: Anzeige, keine neue Logik
• Akte: Bewegungs-/Historienbereich — „aktuell ausgegeben an" als Sonderfall von Standort (Person statt Lagerplatz)
• Rechte: Mitarbeiter+ für Ausgabe/Rückgabe
• Audit: jeder Vorgang geloggt
• Akzeptanzkriterien: Ausgabe erzeugt offenen Vorgang, Rückgabe schließt ihn, überfällige Rückgaben erkennbar.
• Tests: Ausgabe-/Rückgabe-Test, Überfällig-Test.
• DoD: umgesetzt (2026-09-06). Modell ausgabe (Material + optional geraet_instanz_id), POST /ausgaben, GET /ausgaben?status_filter=&empfaenger_id=, POST /ausgaben/{id}/rueckgabe. Frontend als Admin-Tab "Ausgabe/Rückgabe" (Empfänger-Auswahl braucht die Benutzerliste, die nur Verantwortliche laden dürfen - Backend selbst erlaubt jedem eingeloggten Nutzer Ausgabe/Rückgabe, Feld-Erfassung durch Mitarbeiter wäre ein späterer Ausbauschritt mit eigener Namenssuche statt vollem /benutzer-Endpunkt). Vollständiger Ausgabe-Rückgabe-Zyklus + Doppel-Rückgabe-Schutz getestet.

---

MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-06): INV-001…003 sowie INV-005/006/007 vollständig vorhanden — INV-006 (Fehlbestand+Mindermenge) ist eines der am weitesten ausgereiften Module im gesamten Projekt, INV-007 (Ausgabe/Rückgabe) beantwortet jetzt "wer hat gerade das Funkgerät". Nur INV-004 (echter struktureller Umbau, siehe oben) fehlt noch.