diff --git a/arbeitskacheln/00_index.md b/arbeitskacheln/00_index.md index 2ae38b7..77b7d65 100644 --- a/arbeitskacheln/00_index.md +++ b/arbeitskacheln/00_index.md @@ -209,6 +209,8 @@ eigenes Modul (MAINT-\*, MABEA hat nur Prüfung, keine Wartung)**. | `02_identity.md` | IDENT-001, 002, 004, 005 … 010 | | `03_digital_file.md` | FILE-001 … FILE-007 (vollständig) | | `04_assets.md` | ASSET-001 … ASSET-008 (vollständig) | +| `05_fleet.md` | FLEET-001 … FLEET-006 (vollständig) | +| `06_inventory.md` | INV-001 … INV-004 | -Restliche Kacheln (FLEET, INV, WH, LOAD, INSP, MAINT, DEFECT, PERS, READY, DOC, MOBILE, +Restliche Kacheln (INV-005…007, WH, LOAD, INSP, MAINT, DEFECT, PERS, READY, DOC, MOBILE, OPS): nur Zeile in der Tabelle oben, Details folgen nach Freigabe. diff --git a/arbeitskacheln/05_fleet.md b/arbeitskacheln/05_fleet.md new file mode 100644 index 0000000..b92b09f --- /dev/null +++ b/arbeitskacheln/05_fleet.md @@ -0,0 +1,136 @@ +# Epic 05 — Fleet + +Details zu FLEET-001 … FLEET-006 (vollständig). + +--- + +## FLEET-001 — Fahrzeugtypen + +- **Ziel:** Fahrzeugspezifische Typebene oberhalb AssetType. +- **Beschreibung:** Fahrzeugtyp-Stammdaten (z.B. „GW-San", „MTW"), verweist auf AssetType. +- **Benutzerwert:** Vorlage für Fahrzeug-Anlage, ähnliche Fahrzeuge gruppiert. +- **Abhängigkeiten:** ASSET-002 +- **Datenmodell:** `fahrzeugtyp` (id, asset_type_id, ...) oder Erweiterungsfelder an + `asset_type` +- **Backend:** CRUD +- **Frontend:** Verwaltung +- **Mobile:** Anzeige +- **QR-Code/Seriennummer/Inventarnummer:** nein +- **Akte:** Stammdatenbereich +- **Rechte:** Materialwart/Administrator +- **Audit:** Änderung geloggt +- **Akzeptanzkriterien:** Fahrzeugtyp anlegen, Verknüpfung zu AssetType. +- **Tests:** CRUD-Test. +- **DoD:** mind. ein Fahrzeugtyp angelegt. + +## FLEET-002 — Fahrzeuge (Kennzeichen/Funkrufname) + +- **Ziel:** Fahrzeug-Spezialfelder am Asset. +- **Beschreibung:** Kennzeichen, Fahrgestellnummer, Funkrufname als 1:1-Erweiterungstabelle + zu Asset. +- **Benutzerwert:** Fahrzeuge sind die wichtigste Ressourcenklasse im Rettungsdienst — eigene + Kennfelder sind Pflicht. +- **Abhängigkeiten:** ASSET-003, FLEET-001 +- **Datenmodell:** `fahrzeugdetails` (asset_id, kennzeichen, fahrgestellnummer, + funkrufname) +- **Backend:** CRUD/Upsert +- **Frontend:** Formular +- **Mobile:** Anzeige +- **QR-Code:** Kennzeichen kann Klartext-Fallback auf dem Label sein +- **Seriennummer/Inventarnummer:** ergänzend, siehe Asset-Kernfelder +- **Akte:** Fahrzeug-spezifischer Stammdatenbereich +- **Rechte:** Materialwart/Administrator +- **Audit:** Änderung geloggt +- **Akzeptanzkriterien:** Felder setzen/anzeigen funktioniert. +- **Tests:** CRUD-Test. +- **DoD:** deckt sich mit MABEA `fahrzeugdetails` (bereits umgesetzt, diente hier als + Vorbild). + +## FLEET-003 — Kilometerstand/Betriebsstunden + +- **Ziel:** Nutzungsgrad des Fahrzeugs erfassen (Basis für km-/std-abhängige + Wartungsintervalle, MAINT-002). +- **Beschreibung:** Felder + Erfassungsverlauf (nicht nur aktueller Wert, sondern Verlauf + der Meldungen). +- **Benutzerwert:** Grundlage für Wartungsplanung. +- **Abhängigkeiten:** FLEET-002 +- **Datenmodell:** `fahrzeugdetails.kilometerstand`/`betriebsstunden` (aktuell) + + optional `km_stand_historie` +- **Backend:** Update-Endpoint mit Plausibilitätsprüfung +- **Frontend:** Eingabefeld bei Kontrolle/Rückkehr +- **Mobile:** Eingabe im Feld (nach Fahrt) +- **QR-Code/Seriennummer/Inventarnummer:** nein +- **Akte:** Stammdatenbereich +- **Rechte:** jeder Fahrzeugnutzer darf melden (breiter als reine Materialwart-Rechte), + Korrektur nur Administrator +- **Audit:** Änderung geloggt +- **Akzeptanzkriterien:** Wert kann nur steigen (Validierung gegen Rückwärtslauf, außer + Admin-Korrektur-Override). +- **Tests:** Validierungstest (Rückwärtslauf abgelehnt, Override funktioniert). +- **DoD:** funktioniert, Validierung greift nachweisbar. + +## FLEET-004 — Fahrzeugstatus (5-stufig) + +- **Ziel:** Fahrzeug-spezifische Verfeinerung von ASSET-004. +- **Beschreibung:** einsatzbereit/eingeschränkt/nicht einsatzbereit/in Wartung/außer Dienst + — die ersten drei rechnerisch aus der Readiness-Engine (READY-002), die letzten zwei + manuell gesetzt. +- **Benutzerwert:** Differenziertere Aussage als der generische Asset-Status. +- **Abhängigkeiten:** FLEET-002, READY-002 +- **Datenmodell:** kein Extra-Feld nötig, wenn ASSET-004 generisch genug + + Readiness-Overlay reicht — sonst eigenes Statusfeld +- **Backend:** Statuswechsel + Readiness-Kopplung +- **Frontend:** Status-Anzeige/-Dropdown +- **Mobile:** Anzeige +- **QR-Code/Seriennummer/Inventarnummer:** nein +- **Akte:** Stammdatenbereich +- **Rechte:** manuelle Zustände (Wartung/außer Dienst) nur Materialwart/Administrator +- **Audit:** Statuswechsel geloggt +- **Akzeptanzkriterien:** 5 Zustände korrekt unterscheidbar, rechnerischer vs. manueller + Anteil klar getrennt. +- **Tests:** Statustest je Zustand. +- **DoD:** deckt sich vollständig mit MABEA (bereits umgesetzt: `ObjektStatus` inkl. + `in_wartung` + Readiness-Berechnung im Dashboard). + +## FLEET-005 — Fahrzeug-Dokumente + +- **Ziel:** Fahrzeugpapiere/Zulassung digital anhängen. +- **Beschreibung:** Nutzt DOC-001 generisch, hier nur die Fach-Kopplung/Anzeige in der + Fahrzeug-Akte. +- **Benutzerwert:** Zulassungsbescheinigung/Versicherungsnachweis griffbereit. +- **Abhängigkeiten:** FLEET-002, DOC-001 +- **Datenmodell:** keins neu (nutzt Dokument-Polymorphie) +- **Backend:** keins zusätzlich +- **Frontend:** Dokumente-Panel in der Fahrzeug-Akte +- **Mobile:** Anzeige +- **QR-Code/Seriennummer/Inventarnummer:** nein +- **Akte:** Dokumentenbereich +- **Rechte:** wie DOC-001 +- **Audit:** wie DOC-001 +- **Akzeptanzkriterien:** Dokument an Fahrzeug hochladen/anzeigen. +- **Tests:** Integrationstest mit DOC-001. +- **DoD:** entspricht MABEA (DokumentePanel bereits generisch wiederverwendbar, + funktioniert unverändert für Fahrzeuge). + +## FLEET-006 — Fahrzeug-Einsatzhistorie (Platzhalter, P3) + +- **Ziel:** Welche Einsätze ein Fahrzeug gefahren ist. +- **Beschreibung:** Platzhalter-Kachel — echte Umsetzung hängt vom noch nicht entworfenen + Operations-Epic ab. +- **Benutzerwert:** Nutzungsnachweis/Auslastungsstatistik. +- **Abhängigkeiten:** FLEET-002, OPS-002 +- **Datenmodell / Backend / Frontend / Mobile / QR / SN / Inv / Akte / Rechte / Audit:** + TBD — nicht sinnvoll spezifizierbar vor OPS-001/002. +- **Akzeptanzkriterien:** TBD. +- **Tests:** TBD. +- **DoD:** **DECISION REQUIRED:** diese Kachel bleibt bewusst Platzhalter, erst bei + tatsächlichem Angehen des Operations-Epics neu aufsetzen statt jetzt blind zu spezifizieren. + +--- + +**MABEA-Ist-Stand-Abgleich:** FLEET-001…005 sind praktisch 1:1 in MABEA vorhanden +(Objekttyp mit `ist_zugfahrzeug`, `fahrzeugdetails`-Tabelle, 5-stufiger `ObjektStatus`, +generisches DokumentePanel). Einzige offene Lücke: FLEET-003s Plausibilitätsprüfung +(„Kilometerstand darf nicht sinken") ist in MABEA **nicht** validiert — reiner +Zahlen-Input ohne Rückwärtslauf-Schutz. Kleine, konkrete Nachbesserung, keine neue Kachel +nötig. FLEET-006 ist in MABEA (noch) nicht relevant, da kein Operations-Epic existiert. diff --git a/arbeitskacheln/06_inventory.md b/arbeitskacheln/06_inventory.md new file mode 100644 index 0000000..00567d7 --- /dev/null +++ b/arbeitskacheln/06_inventory.md @@ -0,0 +1,102 @@ +# Epic 06 — Inventory + +Details zu INV-001 … INV-004. INV-005…007 noch nicht detailliert, siehe +`00_index.md`-Tabelle. + +--- + +## 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). + +--- + +**MABEA-Ist-Stand-Abgleich:** INV-001…003 vollständig vorhanden. **INV-004 ist die erste +Kachel in diesem Backlog, die einen echten strukturellen Umbau in MABEA bedeuten würde** +(Mehrfach-Chargen je Position), nicht nur eine Ergänzung — vor Umsetzung separat einschätzen +lassen, ob das fachlich überhaupt gebraucht wird (bisher kein Nutzer-Bedarf dafür geäußert).