MABEA/arbeitskacheln/07_warehouse.md

Epic 07 — Warehouse

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

---

WH-001 — Lager-Stammdaten (Hierarchie)

• Ziel: Mehrstufige Standort-Hierarchie statt flacher Standort-Liste.
• Beschreibung: Organisation→Standort→Gebäude→Raum→Lager als Baum, nicht nur ein flaches „Standort"-Feld.
• Benutzerwert: Größere Organisationen mit mehreren Gebäuden/Lagern pro Standort abbildbar.
• Abhängigkeiten: FOUND-002
• Datenmodell: lagerort (id, name, parent_id, typ: organisation/standort/gebaeude/raum/lager)
• Backend: CRUD, Baum-Query
• Frontend: Baum-/Breadcrumb-Navigation
• Mobile: einfache Auswahl
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: Standortbereich referenziert Lagerort statt flachen Standort
• Rechte: Administrator
• Audit: Änderung geloggt
• Akzeptanzkriterien: mehrstufige Hierarchie anlegen und navigieren.
• Tests: Baum-Test (Kind/Eltern-Beziehungen korrekt).
• DoD: mind. 3 Ebenen tief angelegt und funktionsfähig. Lücke gegenüber MABEA: Standort ist flach (kein Parent) — echte strukturelle Erweiterung, kein reiner Nachzug.

WH-002 — Lagerplätze

• Ziel: Feingranulare Position innerhalb eines Lagers (Regal/Fach/Box).
• Beschreibung: Lagerplatz als unterste Hierarchieebene (oder eigenes Konzept unterhalb WH-001), mit eigenem Code/QR.
• Benutzerwert: „Wo genau im Regal" statt nur „irgendwo im Lager X".
• Abhängigkeiten: WH-001
• Datenmodell: lagerplatz (id, lagerort_id, code, bezeichnung)
• Backend: CRUD
• Frontend: Verwaltung
• Mobile: Scan-Unterstützung
• QR-Code: eigener QR je Lagerplatz (IDENT-001-Konzept gilt auch für Lagerplätze, nicht nur physische Assets — deckt die Ursprungs-Anforderung /lager/HALLE-01 ab)
• Seriennummer/Inventarnummer: nein
• Akte: Lagerplatz kann eigene „Akte" haben (was liegt hier) — Sonderfall des Akte-Konzepts
• Rechte: Materialwart/Administrator
• Audit: Änderung geloggt
• Akzeptanzkriterien: Lagerplatz anlegen mit eigenem Code, QR generierbar.
• Tests: CRUD-Test.
• DoD: QR-Scan eines Lagerplatzes zeigt dessen Inhalt (Kopplung zu WH-003).

WH-003 — Bestand je Lagerplatz

• Ziel: Wissen, wie viel wovon an welchem Lagerplatz liegt.
• Beschreibung: Bestandstabelle (Consumable-/Asset-Menge je Lagerplatz).
• Benutzerwert: Grundlage für Einlagerung/Auslagerung/Inventur.
• Abhängigkeiten: WH-002, INV-003
• Datenmodell: bestand (lagerplatz_id, material_id, menge) — lagerplatz-spezifisch statt nur „irgendein Standort" wie in INV-003
• Backend: Bestandsabfrage je Lagerplatz
• Frontend: Lagerplatz-Detailansicht mit Inhalt
• Mobile: Anzeige beim Scan
• QR-Code: Scan Lagerplatz zeigt Bestand
• Seriennummer/Inventarnummer: nein
• Akte: Lagerplatz-Akte
• Rechte: wie Lese-Recht
• Audit: nein (Bewegungen selbst werden in WH-004/007 geloggt)
• Akzeptanzkriterien: Bestand je Lagerplatz korrekt abfragbar.
• Tests: Abfragetest.
• DoD: konsistent mit INV-003 (kein Doppelbestand-Tracking).

WH-004 — Einlagerung/Auslagerung

• Ziel: Material einem Lagerplatz zubuchen/abbuchen.
• Beschreibung: Aktionen, die Bestand (WH-003) verändern und dabei protokolliert werden (WH-007).
• Benutzerwert: Kernaktion im Lageralltag.
• Abhängigkeiten: WH-003
• Datenmodell: keins neu (nutzt bestand + WH-007-Protokoll)
• Backend: Ein-/Auslagerungs-Endpunkte
• Frontend: Aktion in Lagerplatz-/Material-Ansicht
• Mobile: scan-gestützt (Lagerplatz scannen, Menge eingeben)
• QR-Code: zentral für den mobilen Ablauf
• Seriennummer/Inventarnummer: nein
• Akte: Bestandsverlauf
• Rechte: Mitarbeiter+ (Materialwart für Korrekturen)
• Audit: jede Bewegung geloggt (WH-007)
• Akzeptanzkriterien: Einlagerung erhöht, Auslagerung verringert Bestand korrekt, negativer Bestand unmöglich.
• Tests: Grenzwerttest.
• DoD: funktioniert scan-gestützt im Feldtest.

WH-005 — Umlagerung

• Ziel: Material von einem Lagerplatz zu einem anderen verschieben (auch über Lager hinweg), in einem Schritt statt Aus+Ein manuell.
• Beschreibung: Kombinierte Aktion: Auslagerung an Quelle + Einlagerung an Ziel atomar, mit Grund.
• Benutzerwert: Ein Klick statt zwei fehleranfällige Einzelschritte.
• Abhängigkeiten: WH-004
• Datenmodell: keins neu (nutzt WH-004 zweifach in einer Transaktion + WH-007-Eintrag mit Von/Nach)
• Backend: Umlagerungs-Endpunkt (transaktional)
• Frontend: „Verschieben"-Aktion
• Mobile: Scan Quelle + Scan Ziel
• QR-Code: zentral
• Seriennummer/Inventarnummer: nein
• Akte: Bewegungshistorie
• Rechte: Materialwart+
• Audit: WH-007-Eintrag
• Akzeptanzkriterien: Umlagerung schlägt fehlerfrei fehl oder läuft komplett durch (keine halbe Buchung).
• Tests: Transaktions-Test (Fehler führt zu Rollback, keine Teilbuchung).
• DoD: deckt sich konzeptionell mit MABEA Lagerbewegung, aber auf Lagerplatz- statt nur Standort-Ebene (MABEA kennt keine Lagerplätze, nur Standorte).

WH-006 — Inventur & Bestandskorrektur

• Ziel: Periodischer Abgleich Soll-Bestand (System) vs. Ist-Bestand (gezählt).
• Beschreibung: Inventurlauf je Lager/Lagerplatz, Erfassung Ist-Menge, automatische Korrekturbuchung bei Abweichung mit Begründung.
• Benutzerwert: Systematische Fehlerkorrektur statt stiller Bestandsdrift über Zeit.
• Abhängigkeiten: WH-003
• Datenmodell: inventur (id, lagerort_id, gestartet_am, status), inventur_position (inventur_id, material_id, soll, ist)
• Backend: Inventur starten/erfassen/abschließen
• Frontend: Inventur-Erfassungsmaske
• Mobile: scan-gestützte Zählung
• QR-Code: Lagerplatz/Material scannen während der Inventur
• Seriennummer/Inventarnummer: Erfassung bei SN-pflichtigen Gütern inkl. SN-Abgleich
• Akte: Korrekturen erscheinen im Bestandsverlauf
• Rechte: Materialwart+ startet/schließt, Mitarbeiter+ erfasst
• Audit: jede Korrekturbuchung mit Begründung geloggt
• Akzeptanzkriterien: Abweichung erzeugt nachvollziehbare Korrekturbuchung, keine stille Anpassung ohne Log.
• Tests: Inventur-Zyklus-Test mit Abweichung.
• DoD: ein vollständiger Inventurzyklus durchgeführt. Lücke: MABEA hat kein Inventur-Konzept, nur Kontrolle (Soll/Ist je Objekt, nicht als eigener Lagerlauf mit Korrekturbuchung).

WH-007 — Materialbewegungsprotokoll

• Ziel: Vollständige, lückenlose Historie aller Bestandsbewegungen.
• Beschreibung: Append-only Protokoll (Was/Menge/Von/Nach/Wer/Wann/Warum), Basis für WH-004/005/006 und ASSET-006.
• Benutzerwert: Nachvollziehbarkeit, Diebstahl-/Schwund-Erkennung.
• Abhängigkeiten: WH-004, FOUND-006
• Datenmodell: materialbewegung (material_id, menge, von_lagerplatz_id, nach_lagerplatz_id, benutzer_id, zeitpunkt, grund)
• Backend: log-Funktion, von WH-004/005/006 aufgerufen
• Frontend: Bewegungs-Liste/Filter
• Mobile: nur Anzeige
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: Historienbereich
• Rechte: wie Lese-Recht (Verantwortliche)
• Audit: eigenständiges Fach-Protokoll (analog ASSET-006, nicht generisches FOUND-006-JSON — strukturierte Von/Nach-Felder gebraucht)
• Akzeptanzkriterien: jede Bestandsbewegung erzeugt genau einen Eintrag.
• Tests: Vollständigkeitstest (keine Bewegung ohne Protokolleintrag).
• DoD: deckt sich konzeptionell mit MABEA Lagerbewegung (dort schon vorhanden, aber objekt-/standort-bezogen statt material-/lagerplatz-bezogen).

---

MABEA-Ist-Stand-Abgleich: Das gesamte Warehouse-Epic ist in MABEA nur flach umgesetzt — Standort ohne Hierarchie (WH-001-Lücke), kein Lagerplatz-Konzept (WH-002/003 fehlen komplett), Lagerbewegung deckt WH-004/005/007 nur auf Objekt-/Standort-Ebene ab (nicht auf Material-/Lagerplatz-Ebene — MABEA verschiebt ganze Objekte, nicht einzelne Materialmengen zwischen Lagerplätzen), Inventur (WH-006) fehlt komplett. Dieses Epic hat den größten Abstand zwischen Backlog-Anspruch und MABEA-Ist-Stand aller bisher abgeglichenen Epics — am ehesten vergleichbar mit dem komplett fehlenden Digital-File-Epic.