MABEA/GESAMTDOKUMENT.md

# MABEA (Material-Bestands-App) – Digitales Materialmanagement Rettungsdienst / KatS

Automatisch zusammengestellt aus allen Arbeitskarten und Prompt-Ergebnissen, Stand 2026-09-03, inkl. Korrekturen aus Gesamtprüfung + Verifikationsrunde.

---

## Teil A – Arbeitskarten (Klärungsstand)


---

# Arbeitskarten – Index

Status: entstanden aus Klärungsrunde vor Prompt 01. Jede Karte = ein entschiedener oder offener Punkt, mit Bezug zu `prompts.md`.

| Nr | Karte | Status | Bezug |
|----|-------|--------|-------|
| 01 | [Rollen & Zuordnung](01_rollen_zuordnung.md) | entschieden | Prompt 05 |
| 02 | [Rechte: Stammdaten vs. Ist-Menge](02_rechte_stammdaten.md) | entschieden | Prompt 05 |
| 03 | [Sollmengen-Recht Materialverantwortlicher](03_sollmengen_recht.md) | entschieden | Prompt 04, 05 |
| 04 | [Organisationsstruktur / Zuständigkeiten](04_organisationsstruktur.md) | entschieden, Detail offen | Prompt 05, 06 |
| 05 | [Benachrichtigungen](05_benachrichtigungen.md) | entschieden | Prompt 12 |
| 06 | [Geräteanforderung PC/Mobil](06_geraet_pc_mobil.md) | entschieden | Prompt 11, 17 |
| 07 | [Sofort-Nachfüllung während Kontrolle](07_sofort_nachfuellung.md) | entschieden | Prompt 02, 03 |
| 08 | [Mindermengen-Gültigkeit](08_mindermenge_gueltigkeit.md) | entschieden | Prompt 04 |
| 09 | [Authentifizierung](09_authentifizierung.md) | entschieden | Prompt 05, 19 |
| 10 | [QR-Code / Barcode](10_qr_barcode.md) | Roadmap, Datenmodell-Vorbereitung nötig | Prompt 06, 24 |
| 11 | [Systemumfang: generisches Ressourcenmanagement](11_systemumfang_ressourcenmanagement.md) | entschieden, grundlegend | Prompt 06, 07 |
| 12 | [Eskalation offener Fehlbestände](12_eskalation.md) | Roadmap, Datenmodell-Vorbereitung nötig | Prompt 03, 24 |
| 13 | [Hauptserver mit Satelliten-Servern](13_satelliten_server.md) | entschieden, Betrieb Roadmap, Datenmodell-Vorbereitung nötig | Prompt 17, 19, 20 |

Nächster Schritt: Prompt `01_anforderungsanalyse` unter Berücksichtigung aller entschiedenen Karten bearbeiten.

**Hinweis (Gesamtprüfung):** Wiki-Link-Aliase (`[[name]]`) sind uneinheitlich benannt (z. B. Datei `10_individuelle_beladung.md` wird teils als `[[10_individuelle_beladung]]`, teils sinngemäß referenziert). Vor Code-Umsetzung/Migration einmal Alias-Konsistenz gegen tatsächliche Dateinamen prüfen.

---

# Karte 01 – Rollen & Zuordnung

**Status:** entschieden

## Entscheidung
Grundsätzlich darf jeder Mitarbeiter jedes Rucksack/Fahrzeug kontrollieren (keine feste Pflichtzuordnung). Zusätzlich können Verantwortliche gezielt zuweisen – entweder an eine Einzelperson oder an eine Gruppe.

## Konsequenz für Datenmodell / Fachkonzept
- Zuweisung ist optional, nicht Pflichtfeld.
- Zuweisungsmodell muss sowohl Einzelperson als auch Gruppe unterstützen (z. B. Tabelle Zuweisung: Objekt ↔ Benutzer ODER Objekt ↔ Gruppe).
- UI: Mitarbeiter sieht alle Objekte, ggf. zugewiesene hervorgehoben/priorisiert.

## Offen
- Muss Zuweisung fällige Kontrollen "erzwingen" (Pflichtkontrolle) oder ist sie nur Empfehlung/Sichtbarkeit? → bei Prompt 02/05 klären.

---

# Karte 02 – Rechte: Stammdaten vs. Ist-Menge

**Status:** entschieden

## Entscheidung
Mitarbeiter/Kontrollorgan darf nur die tatsächliche Ist-Menge melden. Materialstammdaten (Bezeichnung, Artikelnummer usw.) sind für diese Rolle gesperrt.

## Konsequenz
- Rechtematrix (Prompt 05): Mitarbeiter = Ist-Menge erfassen, keine Stammdaten-Schreibrechte.
- Stammdatenpflege bleibt Administration bzw. ggf. Materialverantwortlichem vorbehalten (siehe Karte 03).

---

# Karte 03 – Sollmengen-Recht Materialverantwortlicher

**Status:** entschieden

## Entscheidung
Materialverantwortlicher darf Sollmengen (Beladungsvorlagen) selbst ändern – nicht nur Mindermengen genehmigen.

## Konsequenz
- Rechtematrix (Prompt 05): Materialverantwortlicher = Mindermengen genehmigen UND Sollmengen/Vorlagen bearbeiten.
- Prompt 08 (Beladungsvorlagen): Vorlagenänderung muss diese Rolle als Berechtigten vorsehen, nicht nur Administration.
- Historie/Audit (Prompt 13): Sollmengenänderungen durch Materialverantwortlichen müssen protokolliert werden (wer, wann, alt/neu).

---

# Karte 04 – Organisationsstruktur / Zuständigkeiten

**Status:** entschieden, Detail noch offen

## Entscheidung
Keine starre zentrale ODER dezentrale Struktur vorgeben. Administrator muss Zuständigkeiten (welcher Verantwortliche für welchen Standort/welches Objekt) flexibel selbst einteilen können.

## Konsequenz für Datenmodell
- Zuständigkeit ist eigene, konfigurierbare Zuordnung: Verantwortlicher(e) ↔ Standort und/oder Objekt (Rucksack/Fahrzeug), n:m-Beziehung.
- Kein Hardcoding von "eine Wache = ein Verantwortlicher".
- Administration benötigt UI/Funktion zum Verwalten dieser Zuordnungen (Prompt 05).

## Offen
- Kann ein Objekt mehrere Verantwortliche gleichzeitig haben? (Vermutlich ja, klären bei Prompt 05/06.)
- Vererbt sich Zuständigkeit vom Standort auf alle Objekte am Standort automatisch, oder muss sie separat je Objekt gesetzt werden?

---

# Karte 05 – Benachrichtigungen

**Status:** entschieden

## Entscheidung
Bei neuem Fehlbestand wird Verantwortlicher benachrichtigt über:
- Dashboard (Portal)
- E-Mail

Kein Push/App in V1.

## Konsequenz
- Prompt 12 (Dashboard): Dashboard-Anzeige ist Pflichtbestandteil.
- Technische Architektur (Prompt 19): E-Mail-Versand-Komponente einplanen (z. B. Trigger bei Statuswechsel "offen").
- Push/App bleibt spätere Ausbaustufe (Roadmap, Prompt 24).

---

# Karte 06 – Geräteanforderung PC/Mobil

**Status:** entschieden

## Entscheidung
Kontrolle muss sowohl auf PC als auch auf Smartphone/Tablet funktionieren – kein "mobile-only" oder "PC-only".

## Konsequenz
- Prompt 11 (Mitarbeiter-UI): Responsive Design, keine reine Mobile-App-Annahme.
- Prompt 17 (Mobile/Offline): Offline-Fähigkeit bleibt separat zu bewerten, unabhängig von Geräteklasse.
- Technische Architektur (Prompt 19): Web-basiert sinnvoll, um beide Geräteklassen mit einer Codebasis abzudecken.

---

# Karte 07 – Sofort-Nachfüllung während Kontrolle

**Status:** entschieden

## Entscheidung
Wenn Besatzung Fehlmenge noch während laufender Kontrolle direkt aus Lager nachfüllt, gilt: Fehlbestand entsteht trotzdem als Vorgang und wird im selben Moment als erledigt markiert. Kein "verschwindet spurlos".

## Konsequenz
- Prompt 03 (Fehlbestandsmanagement): Statuswechsel "offen" → "erledigt" muss auch innerhalb derselben Kontrollsitzung möglich sein (nicht nur über mehrere Kontrollen hinweg).
- Historie (Prompt 13) muss diesen Fall abbilden: Fehlmenge festgestellt, Fehlbestand angelegt, Nachfüllung, erledigt – alles mit Zeitstempel, auch wenn zeitlich sehr nah beieinander.

---

# Karte 08 – Mindermengen-Gültigkeit

**Status:** entschieden

## Entscheidung
Genehmigte Mindermenge gilt automatisch nur bis zur nächsten Kontrolle des betroffenen Objekts – kein festes Ablaufdatum, kein unbefristetes Gelten.

## Konsequenz
- Prompt 04 (Mindermengen): Genehmigung ist an "nächste Kontrolle" gekoppelt, nicht an Kalenderdatum.
- Bei nächster Kontrolle: Ist-Menge wird neu erfasst; ist die Abweichung weiterhin vorhanden, muss neu entschieden werden (neuer Genehmigungsvorgang oder Fehlbestand wieder aktiv).
- Datenmodell: Genehmigung referenziert die Kontrolle, ab der sie NICHT mehr automatisch gilt (z. B. "gültig_bis_kontrolle_id" oder Statuslogik beim Kontrollabschluss).

---

# Karte 09 – Authentifizierung

**Status:** entschieden

## Entscheidung
Version 1 benötigt echte Benutzerkonten mit Login (Passwort/PIN) – keine einfache Namensauswahl ohne Absicherung.

## Konsequenz
- Prompt 05 (Rollen/Rechte) und Prompt 19 (Architektur): Authentifizierungskomponente ist Pflichtbestandteil des MVP, nicht optional.
- Zurechenbarkeit von Kontrollen/Genehmigungen/Änderungen (Prompt 13, Historie) basiert auf echtem Login, nicht auf Selbstauskunft.

---

# Karte 10 – QR-Code / Barcode

**Status:** Roadmap-Feature, Datenmodell-Vorbereitung schon in V1 nötig

## Entscheidung
QR/Barcode-Scan ist gewünschte spätere Funktion:
- Objekt-Code (Rucksack/Fahrzeug) → Direktsprung ins Kontroll-Screen (statt Portal → Standort → Fahrzeug → Rucksack suchen).
- Geräte-Code (Einzelgerät) → automatische Seriennummer-Erkennung.

## Konsequenz für V1 (jetzt schon vorsehen)
- Prompt 06 (Datenmodell): Objekt (Rucksack/Fahrzeug) und Einzelgerät bekommen je ein eindeutiges Code-/ID-Feld, auch wenn Scan-UI erst später kommt.
- Kein Schema-Umbau später nötig, nur Scan-Funktion (Kamera/Reader) ergänzen.

## Umsetzung
- Eigentliche Scan-Funktion → Prompt 24 (Roadmap), nicht MVP.

## Barcode-Format (Nutzerentscheidung)
- Standard: **Code128**, eindimensional, weit verbreitet.
- Bewusste Wahl statt proprietärem/2D-Format, um Geräteauswahl offen zu halten.
- Konsequenz Datenmodell: Code-Feld (Objekt/Gerät) muss Code128-kompatiblen Zeichensatz aufnehmen können (alphanumerisch, keine Sonderzeichen-Einschränkung nötig, Code128 deckt ASCII ab).
- Zusatzanforderung: Code muss per Tablet-/Smartphone-Kamera lesbar sein (Software-Scan). Code128 ist per Kamera grundsätzlich lesbar, aber empfindlicher gegenüber Druckqualität/Abstand/Winkel als 2D-Codes wie QR. Konsequenz: Drucklayout (Größe, Kontrast) muss auf Kamera-Scan getestet werden.

## Label-Design (offener Punkt, Prompt 24 vertiefend)
- Physisches Label-Design (Größe, Material, Kontrast, Schriftgröße Klartext unter Code, Anbringungsort am Objekt) muss mit aufgenommen werden, nicht nur der Code-Inhalt selbst.
- Anforderungen an Label aus Einsatzumfeld: witterungsbeständig/abriebfest (Rucksäcke/Fahrzeuge im Rettungsdiensteinsatz), Kontrast/Größe für zuverlässigen Kamera-Scan (siehe oben).
- Klartext-Fallback auf Label empfohlen (Code + lesbare Objekt-ID), falls Scan mal ausfällt.
- Konkretes Layout/Material erst bei Umsetzung (Prompt 24) final festlegen, hier nur als Anforderung vermerkt.

---

# Karte 11 – Systemumfang: generisches Ressourcenmanagement

**Status:** entschieden, grundlegend (beeinflusst Benennung + Datenmodell)

## Entscheidung
System wird konzeptionell nicht als "Rettungsdienst-Materialverwaltung" gedacht, sondern als generisches **Ressourcen- und Materialmanagement**. Rettungsdienst/KatS sind ein Bereich davon, nicht der gesamte Scope.

Perspektivisch zu verwaltende Objekttypen (Beispiele, nicht abschließend):
Fahrzeuge, Rucksäcke, Zelte, Feldbetten, Stromerzeuger, Funkgeräte, Aggregate, Sanitätsmaterial, Betreuungsmaterial.

## Konsequenz für Datenmodell (Prompt 06/07)
- "Bereich" bzw. "Kategorie" wird eigene Dimension über dem Objekttyp – nicht Rettungsdienst hartcodiert.
- Objekt-Entität (aktuell "Rucksack/Fahrzeug") sollte generisch als "Ressource"/"Ausrüstungsobjekt" modelliert werden, mit Typ als Attribut/Unterklasse statt eigener Tabelle je Objektart.
- Materialstamm (Prompt 07) muss über Sanitätsmaterial hinaus erweiterbar bleiben (z. B. Betreuungsmaterial, technisches Material).

## Auswirkung auf bestehende Prompts
- Prompt 01 (Anforderungsanalyse): Scope-Beschreibung entsprechend generisch formulieren, nicht auf Rettungsdienst verengen.
- Prompt 06 (Datenmodell): "Bereich" als Grunddimension explizit einführen.

---

# Karte 12 – Eskalation offener Fehlbestände

**Status:** Roadmap-Feature, Datenmodell-Vorbereitung schon in V1 sinnvoll

## Entscheidung
Später gewünscht: automatische Eskalation bei lange offenen Fehlbeständen, z. B.:
- Erinnerung nach X Tagen (🟡)
- Eskalation an Leitungsverantwortlichen nach Y Tagen (🔴)

Zeitschwellen konfigurierbar, nicht fix.

## Konsequenz für V1
- Prompt 03 (Fehlbestandsmanagement): Fehlbestand-Entität muss Zeitstempel "entstanden am" führen, damit "Alter" später berechenbar ist, ohne Modelländerung.
- Kein Eskalationsmechanismus selbst in V1/MVP (Prompt 18) – nur Datenbasis dafür vorhalten.

## Umsetzung
- Eskalationslogik (Jobs, Schwellenwerte, Empfängerlogik) → Prompt 24 (Roadmap).

---

# Karte 13 – Hauptserver mit Satelliten-Servern

**Status:** Entschieden (Architektur-Erweiterung), betrifft Prompt 17 (Offline) und Prompt 19 (Architektur).

## Entscheidung
Zusätzlich zum Hauptserver können **Satelliten-Server** existieren, die lokal (am Einsatzort/an einer Wache) laufen und temporär vom Hauptserver getrennt sind.

## Einsatzfälle
1. KatS-Einsatzlage (Zeltlager/Einsatzort ohne Internet) – Satellit läuft autark vor Ort.
2. Wache mit dauerhaft schlechter Anbindung – Satellit als Regelbetrieb, nicht nur Notfall.
3. Reiner Ausfallschutz – Satellit übernimmt nur bei Komplettausfall Hauptserver/Internet.

## Autark-Dauer
Bewusst **nicht zeitlich begrenzt** – System darf keine feste Obergrenze annehmen (z. B. "nach 3 Tagen zwingend Sync nötig"). Trennung kann Stunden bis mehrere Tage/unbestimmt dauern.

## Mehrbenutzerfähigkeit am Satelliten
Satellit ist funktional ein vollwertiger, kleiner Hauptserver-Klon (gleiche Software/API), kein reiner Cache. Mehrere Mitarbeiter können gleichzeitig am selben Satelliten arbeiten – braucht keine eigene Konfliktlösung, da er wie der Hauptserver selbst funktioniert.

## Konfliktvermeidung (statt Konfliktlösung)
Zentrale Design-Entscheidung: Konflikte beim Zurücksynchronisieren **sollen strukturell nicht vorkommen**, nicht nachträglich aufgelöst werden.
- Jedes Objekt (Rucksack/Fahrzeug) ist während einer Trennung **fest genau einem Server zugeordnet** – entweder Hauptserver oder ein bestimmter Satellit, nie beiden gleichzeitig.
- Objekte, die einem Satelliten zugeteilt sind, werden am Hauptserver für Schreibzugriffe gesperrt/als "ausgelagert" markiert, bis Rücksynchronisation erfolgt ist.
- Dadurch kein "wer gewinnt"-Problem – es gibt pro Objekt nur eine schreibende Quelle zu jedem Zeitpunkt.

## Konsequenz für Datenmodell/Architektur (Vorbereitung, Details Prompt 19/20 zu vertiefen)
- Objekt braucht Feld "aktuell zugeordneter Server" (Hauptserver-ID oder Satelliten-ID).
- Zuordnung ändert sich nur durch bewussten Vorgang ("Objekt X an Satellit Y auslagern" / "Objekt X zurückholen"), nicht automatisch.
- Historie/Fehlbestände/Kontrollen, die am Satelliten entstehen, tragen von Anfang an die eindeutigen IDs des Gesamtsystems (nicht lokal generierte, kollisionsanfällige IDs) – Voraussetzung für widerspruchsfreies Zusammenführen beim Sync.
- Synchronisation überträgt beim Reconnect neu entstandene Datensätze (Kontrollen, Nachfüllungen, Historie, neue Objektpositionen/Zuständigkeiten) per Insert **und** am Satelliten geänderte, bereits vorher existierende Zeilen (Objektpositionen, offene Fehlbestände, aktive Mindermengen-Genehmigungen) per Upsert an den Hauptserver – kein reiner Append-Vorgang (konkretes SQL/Reihenfolge siehe [[20_datenbank_schema]] Punkt 10). Danach wird die Objekt-Zuordnung zurückgesetzt.

## Offene Punkte für weitere Ausarbeitung
- Wie wird eine Auslagerung technisch ausgelöst/verwaltet (manuell durch Administration vor einem Einsatz, oder automatisch bei Verbindungsverlust)?
- Muss der Satellit vorab mit den relevanten Stammdaten bestückt werden, bevor er getrennt wird? Dazu gehören: Materialstamm, Vorlagen, betroffene Objekte/Objektpositionen, **sowie deren offene Fehlbestände und aktive Mindermengen-Genehmigungen** (ohne diese kann am Satelliten weder korrekt nachgefüllt noch genehmigt werden).
- Was passiert, wenn beim Auslagern bereits eine Kontrolle am Hauptserver „in Bearbeitung" ist, bzw. wenn ein Objekt zurückgeholt werden soll, während am Satelliten noch eine Kontrolle läuft? – noch keine Regel definiert, vor Umsetzung zu klären (Vorschlag: Auslagerung/Rückholung nur bei Kontrollstatus „nicht gestartet" oder „abgeschlossen" zulassen).
- Erzwingung von `objektposition.zuletzt_geaendert_am`: aktuell nur Spalten-Default, keine Garantie, dass jeder UPDATE-Pfad den Wert tatsächlich aktualisiert. Vorschlag: DB-Trigger `BEFORE UPDATE` statt Anwendungsdisziplin, um stillschweigend übersehene Änderungen beim Delta-Sync auszuschließen.
- Hardware-Anforderung an Satelliten-Server (kleiner lokaler Rechner/Mini-PC vor Ort, Prompt 19 zu ergänzen).

## Referenzen
Bezug: [[17_mobile_offline]], [[19_technische_architektur]]

---

## Teil B – Prompt-Ergebnisse 01-23


---

# Prompt 01 – Anforderungsanalyse

Projekt: Ressourcen- und Materialmanagement, Bereich Rettungsdienst/KatS als erster Anwendungsfall ([[11_systemumfang_ressourcenmanagement]]). Noch keine technische Umsetzung — reine fachliche Zusammenfassung.

## 1. Ausgangslage
Heute: Papierlisten pro Rucksack/Fahrzeug (Beispiele: Handball Rucksack, Rettungsrucksack, Rucksack PAX SEG). Mitarbeiter kontrolliert, zählt, tauscht abgelaufenes Material, trägt Abweichung ein, unterschreibt, Papier wird abgeheftet. Ziel: dies weitgehend digital ersetzen, ohne dass Fehlbestände vergessen werden können.

## 2. Funktionale Anforderungen

### Muss
- Digitale Erfassung von Materialbeständen je Ressource (Rucksack, Fahrzeug, später weitere Objekttypen).
- Digitale Durchführung von Kontrollen: Ist-Menge je Position erfassen, Abweichungen sichtbar machen.
- Automatisches Anlegen eines Fehlbestand-Vorgangs bei jeder festgestellten Mindermenge — auch bei sofortiger Nachfüllung (Karte 07: entsteht + wird sofort erledigt, mit Historie).
- Fehlbestand bleibt als eigener, offener Vorgang bestehen, unabhängig vom Abschluss der Kontrolle.
- Besatzung kann fehlendes Material selbst aus dem Lager nachfüllen und dies dokumentieren.
- Fehlbestand gilt erst als erledigt, wenn tatsächlicher Bestand wieder vollständig ist (nicht durch bloße Genehmigung).
- Genehmigung von Mindermengen durch berechtigte Rollen (Materialverantwortlicher/Leitungsverantwortlicher), OHNE dass sich dadurch die tatsächliche Ist-Menge ändert (Karte 08: Genehmigung gilt automatisch bis zur nächsten Kontrolle).
- Materialverantwortlicher kann Sollmengen/Beladungsvorlagen ändern (Karte 03).
- Mitarbeiter meldet nur Ist-Menge, keine Stammdaten-Änderung (Karte 02).
- Administration verwaltet Ressourcen, Vorlagen, Materialstamm, Benutzer, Zuständigkeiten (Karte 04: Zuständigkeiten flexibel durch Admin einteilbar, n:m Verantwortlicher↔Standort/Objekt).
- Duplizieren von Ressourcen/Vorlagen als Grundlage für neue Objekte, mit anschließend voller Editierbarkeit; Zustandsdaten (Bestand, SN, Chargen, offene Fehlbestände, Historie) werden NICHT mitkopiert.
- Individuelle Abweichung eines konkreten Objekts von seiner Vorlage muss möglich und nachvollziehbar sein.
- Verantwortlichen-Dashboard mit offenen Fehlbeständen, genehmigten Mindermengen, Filtermöglichkeiten (Standort, Objekt, Material, Alter).
- Benachrichtigung bei neuem Fehlbestand: Dashboard + E-Mail (Karte 05).
- Vollständige Historie/Audit: wer, was, wann, alter/neuer Wert, Begründung.
- Echtes Benutzerkonto mit Login (Passwort/PIN) für alle Rollen (Karte 09).
- Bedienbarkeit sowohl auf PC als auch auf Smartphone/Tablet (Karte 06).
- Zuweisung von Kontrollverantwortung an Einzelperson oder Gruppe möglich, ohne dass dies andere Mitarbeiter von der Kontrolle ausschließt (Karte 01).

### Soll
- Ablaufdaten/Chargen-Unterstützung inkl. Warnzeiträume (Prompt 14, später vertieft).
- Erweiterbarkeit des Materialstamms um Medikamente, Geräte mit Seriennummer, Chargen.
- Objekt- und Geräte-Code-Feld (ID für spätere QR/Barcode-Nutzung) bereits im Datenmodell vorsehen (Karte 10).
- Zeitstempel "Fehlbestand entstanden am" für spätere Eskalationslogik vorsehen (Karte 12).

### Kann (spätere Ausbaustufen, nicht MVP)
- QR-/Barcode-Scan für Direktzugriff auf Objekt bzw. automatische SN-Erkennung (Roadmap, Karte 10).
- Automatische Eskalation offener Fehlbestände an Leitungsverantwortliche nach konfigurierbaren Fristen (Roadmap, Karte 12).
- Lagerverwaltung mit eigenen Lagerorten/Mindestbeständen, getrennt von Objektbestand (Prompt 15).
- Offline-fähige mobile Nutzung mit Synchronisierung (Prompt 17).
- Push-Benachrichtigungen (bewusst nicht in V1, Karte 05).
- Generische Ausweitung auf weitere Ressourcentypen (Zelte, Feldbetten, Stromerzeuger, Funkgeräte, Betreuungsmaterial) über bereits vorbereitete Bereichs-/Kategorie-Dimension (Karte 11).

## 3. Nichtfunktionale Anforderungen
- Nachvollziehbarkeit/Auditierbarkeit hat hohe Priorität (Rettungsdienst-/KatS-Kontext, Verantwortlichkeit im Einsatzfall).
- Bedienung muss im Einsatzumfeld schnell und mit wenig Tipparbeit möglich sein (Prompt 11).
- System muss für mehrere Standorte/Wachen gleichzeitig nutzbar sein, mit flexibler, nicht starrer Organisationsstruktur (Karte 04).
- Erweiterbarkeit ohne Grundmodell-Umbau ist ausdrückliches Designziel (Medikamente, Geräte, Prüfungen, Lagerbestände, weitere Ressourcentypen).
- Datensicherheit: echte Authentifizierung, Rollen-/Rechtetrennung.
- Verfügbarkeit auf gängigen Endgeräten (PC, Smartphone, Tablet) ohne getrennte Codebasis-Pflicht.

## 4. Angenommene Rahmenbedingungen (Annahmen)
- Rettungsdienst/KatS ist der erste produktive Bereich, System aber von Anfang an bereichsoffen modelliert (Karte 11).
- Es gibt mehrere Standorte/Wachen mit potenziell unterschiedlichen Verantwortlichkeiten (Karte 04).
- Mengenangaben aus bestehenden Excel-Listen (Artikel, Menge, Artikelnummer, teils Seriennummer) bilden den fachlichen Ausgangsdatensatz für Materialstamm und Vorlagen.
- Netzabdeckung im Einsatzumfeld ist nicht durchgängig gesichert (Offline-Frage bleibt in Prompt 17 vertiefend zu klären).

## 5. Risiken
- Vermischung von "genehmigter Mindermenge" und "tatsächlichem Bestand" wäre fachlich falsch und sicherheitskritisch (ausdrücklich zu verhindern, siehe `reihenfolge.md`) — hohe Sorgfalt bei Statusmodell in Prompt 03/04 nötig.
- Zu frühes technisches Design (Datenbank/UI) vor Abschluss 01–05 kann zu Fehlannahmen führen, die teuren Umbau erfordern (deswegen strikte Reihenfolge).
- Generischer Ressourcenansatz (Karte 11) kann Komplexität erhöhen, wenn nicht sauber von MVP-Umfang (Prompt 18) getrennt.
- Fehlende/inkonsistente Netzabdeckung im Einsatz kann Datenverlust oder Doppelerfassung verursachen, falls Offline-Konzept (Prompt 17) nicht sauber gelöst wird.
- Kein Push in V1 (Karte 05) kann bei zeitkritischen Fehlbeständen zu Verzögerung führen, falls Verantwortlicher E-Mail/Dashboard nicht zeitnah prüft — als bekanntes Risiko für Roadmap (Eskalation, Karte 12) vermerkt.

## 6. Offene Fragen (vor Prompt 02–05 weiter zu klären)
- Muss zugewiesene Kontrollverantwortung (Karte 01) eine Pflichtkontrolle erzwingen, oder bleibt sie reine Sichtbarkeits-/Priorisierungshilfe?
- Kann ein Objekt mehrere gleichzeitig zuständige Verantwortliche haben, und vererbt sich Zuständigkeit vom Standort automatisch auf alle dortigen Objekte (Karte 04)?
- Wie granular soll der Objekttyp/Kategorie-Baum sein (Karte 11) — flache Liste (Rettungsdienst, Betreuung, Technik, ...) oder hierarchisch mit Unterkategorien?
- Welche Kontrollintervalle/Fristen sind organisatorisch vorgesehen (täglich, wöchentlich, nach Einsatz)? — relevant für Prompt 02 und spätere Eskalation.

## Referenzen
Arbeitskarten: [[01_rollen_zuordnung]], [[02_rechte_stammdaten]], [[03_sollmengen_recht]], [[04_organisationsstruktur]], [[05_benachrichtigungen]], [[06_geraet_pc_mobil]], [[07_sofort_nachfuellung]], [[08_mindermenge_gueltigkeit]], [[09_authentifizierung]], [[10_qr_barcode]], [[11_systemumfang_ressourcenmanagement]], [[12_eskalation]]

---

# Prompt 02 – Kontrollprozess vollständig definieren

Bezug: [[01_anforderungsanalyse]], Karten [[01_rollen_zuordnung]], [[07_sofort_nachfuellung]], [[08_mindermenge_gueltigkeit]], [[06_geraet_pc_mobil]].

## 1. Status einer Kontrolle
- **nicht gestartet** – Objekt wartet auf Kontrolle
- **in Bearbeitung** – Mitarbeiter hat Kontrolle geöffnet, noch nicht abgeschlossen
- **abgeschlossen** – Kontrolle beendet (kann trotzdem offene Fehlbestände als eigene Vorgänge hinterlassen, siehe Prompt 16)
- **abgebrochen** – Mitarbeiter hat Kontrolle gestartet, aber nicht zu Ende geführt (z. B. Einsatzalarmierung); keine Ist-Werte werden übernommen, Objekt bleibt „nicht gestartet“/vorherigen Stand

## 2. Ablauf (Normalfall, keine Abweichung)
1. Mitarbeiter öffnet Ressource (Rucksack/Fahrzeug) – frei wählbar oder aus zugewiesener Liste (Karte 01).
2. System zeigt Positionen nach Kategorie/Fach gegliedert (siehe Struktur der bestehenden Excel-Listen: Fach → Artikel → Sollmenge).
3. Für jede Position: einfache Bestätigung „passt“ (Ist = Soll) per einem Tap, oder Eingabe abweichender Ist-Menge.
4. Bestätigte Positionen benötigen keine weitere Eingabe.
5. Nach letzter Position: Kontrolle abschließen (Prompt 16), System speichert Kontrollnachweis (wer, wann, Objekt, Ergebnis je Position).

## 3. Ablauf bei Abweichung (Ist < Soll)
1. Mitarbeiter trägt Ist-Menge ein, System berechnet Fehlmenge automatisch (Soll − Ist).
2. System legt automatisch einen Fehlbestand-Vorgang an, Status „offen“, mit Zeitstempel „entstanden am“ (Vorbereitung Eskalation, Karte 12).
3. Mitarbeiter wird gefragt: „Direkt aus Lager nachfüllen?“
   - **Ja, sofort nachgefüllt:** Ist-Menge wird auf Soll korrigiert, Fehlbestand-Vorgang wird im selben Moment auf Status „erledigt“ gesetzt, Historieneintrag zeigt beide Ereignisse mit Zeitstempel (Karte 07).
   - **Nein, nicht verfügbar:** Fehlbestand bleibt „offen“, Kontrolle kann trotzdem fortgesetzt/abgeschlossen werden (Prompt 16).
4. Optional: Mitarbeiter kann Ursache/Bemerkung zum Fehlbestand hinterlegen (z. B. „Verbrauch im Einsatz“, „nicht auffindbar“).

## 4. Ablauf bei Ist > Soll (Überbestand)
- Wird ebenfalls erfasst und als Abweichung protokolliert (informativ), löst aber keinen Fehlbestand-Vorgang aus. Keine Genehmigungspflicht nötig, da kein Sicherheitsrisiko wie bei Mindermenge.

## 5. Nachfüllung außerhalb der Kontrolle
- Ein offener Fehlbestand kann jederzeit unabhängig von einer laufenden Kontrolle nachgefüllt werden (z. B. Lieferung trifft später ein).
- Nachfüllung erfasst: nachgefüllte Menge, wer, wann. Ist die Sollmenge danach wieder vollständig erreicht → Fehlbestand-Vorgang wird automatisch auf „erledigt“ gesetzt.
- Teilnachfüllung: Fehlbestand bleibt „offen“, Fehlmenge wird reduziert, Historieneintrag dokumentiert Teilschritt.

## 6. Mindermengen-Genehmigung im Ablauf
- Bei offenem Fehlbestand kann Materialverantwortlicher/Leitungsverantwortlicher eine Ausnahme genehmigen (Prompt 04).
- Genehmigung ändert NICHT die Ist-Menge, sondern setzt einen zusätzlichen Status/Vermerk „Mindermenge genehmigt“ neben dem weiterhin bestehenden Fehlbestand.
- Genehmigung gilt automatisch nur bis zur nächsten Kontrolle desselben Objekts (Karte 08) – bei dieser nächsten Kontrolle wird die Position erneut regulär bewertet.

## 7. Sonderfälle
- **Material nicht mehr im Bestand des Materialstamms vorhanden** (z. B. Position wurde durch Vorlagenänderung entfernt): Kontrolle zeigt Hinweis, Position wird als „entfällt“ markiert statt als Fehlbestand.
- **Individuelle Abweichung vom Vorlagen-Soll** (Prompt 10): Kontrolle rechnet gegen die objektindividuelle Sollmenge, nicht gegen die ursprüngliche Vorlage.
- **Mehrere Mitarbeiter gleichzeitig an derselben Kontrolle:** ausgeschlossen durch Objekt-Sperre nach Scan/Kontrollstart (siehe Punkt 8), nicht durch reine Konvention.
- **Gerätewechsel (PC ↔ mobil) mitten in einer Kontrolle:** Kontrollstatus „in Bearbeitung“ muss geräteunabhängig fortsetzbar sein (Karte 06), da Login-basiert und nicht gerätegebunden.

## 8. Objekt-Sperre bei aktiver Kontrolle (Nutzerentscheidung)
Ergänzung zum Sonderfall „mehrere Mitarbeiter gleichzeitig": Sobald ein Objekt gescannt bzw. eine Kontrolle daran gestartet wird, gilt es für andere Mitarbeiter als **gesperrt**, solange die Kontrolle „in Bearbeitung“ ist.

**Wichtige Klarstellung zum Geltungsbereich:** Die Sperre gilt ausschließlich **pro einzelnem Objekt**, nicht für eine ganze Kontrollrunde/Kampagne. Mehrere Mitarbeiter können jederzeit **gleichzeitig verschiedene Objekte** kontrollieren (z. B. eine ganze Fahrzeugflotte wird parallel von mehreren Personen kontrolliert, je eine Person pro Fahrzeug/Rucksack). Gesperrt ist immer nur das konkrete Objekt, an dem gerade eine Kontrolle läuft – nicht das System oder ein größerer Bereich.

- **Sperre auslösen:** automatisch bei Scan/Kontrollstart (Prompt 11, Screen 1/2).
- **Zweiter Zugriffsversuch:** System zeigt klare Meldung „wird gerade von [Name] kontrolliert, seit [Zeitpunkt]" statt stillschweigend zu blockieren.
- **Übernahme möglich:** zweiter Mitarbeiter kann nach dieser Meldung bewusst „trotzdem übernehmen" wählen (z. B. wenn erster Kollege erwiesenermaßen nicht mehr dran ist, Akku leer, Einsatzalarmierung). Kein automatischer Timeout nötig, da menschliche Entscheidung die Übernahme freigibt.
- **Protokollierung:** jede Übernahme wird als Historieneintrag festgehalten (wer hat wem die laufende Kontrolle entzogen, wann, Prompt 13) – Nachvollziehbarkeit bleibt gewahrt.
- **Freigabe der Sperre:** automatisch bei Abschluss oder Abbruch der Kontrolle (Prompt 16), zusätzlich jederzeit durch Übernahme gemäß obigem Mechanismus.
- Getrennt vom Server-Zuordnungs-Mechanismus für Satelliten (Karte 13): diese Sperre wirkt innerhalb eines Servers (Haupt- oder Satellit) zwischen einzelnen Benutzern, die Server-Zuordnung wirkt zwischen Haupt- und Satelliten-Server als Ganzes.

## 9. Trennung der vier Kernbegriffe (verbindlich)
| Begriff | Bedeutung | Ändert Ist-Menge? |
|---|---|---|
| Kontrolle | Erfassungsvorgang zu einem Zeitpunkt | nein, nur Erfassung |
| Fehlbestand | Automatisch entstandener Vorgang bei Ist < Soll | nein, dokumentiert nur |
| Nachfüllung | Tatsächliches Auffüllen aus Lager | ja, korrigiert Ist-Menge |
| Mindermengen-Genehmigung | Fachliche Ausnahmeentscheidung | nein, niemals |

Diese Trennung ist die zentrale Leitplanke aus `reihenfolge.md` und darf bei Prompt 03/04/06 nicht aufgeweicht werden.

## Offene Fragen für Prompt 03/04
- Braucht „abgebrochene“ Kontrolle eine Aufbewahrung als Teil-Historie, oder wird sie komplett verworfen?
- Soll Bemerkungsfeld beim Fehlbestand Pflicht oder optional sein?

---

# Prompt 03 – Fehlbestände und Aufgaben definieren

Bezug: [[02_prozess_kontrolle]], Karten [[07_sofort_nachfuellung]], [[08_mindermenge_gueltigkeit]], [[12_eskalation]].

## 1. Statusmaschine Fehlbestand

```
                 ┌────────────────────────────────────┐
                 │                                      │
  entdeckt ──▶ offen ──▶ in Bearbeitung ──▶ nachgefüllt ──▶ erledigt
                 │            │
                 │            └──▶ Mindermenge genehmigt ─┐
                 │                                          │ (bleibt weiterhin
                 └──────────────────────────────────────────┘  als Fehlbestand sichtbar,
                                                                bis tatsächlich erledigt)
```

**Status-Definitionen:**
- **offen** – Fehlmenge festgestellt, noch keine Reaktion.
- **in Bearbeitung** – jemand kümmert sich aktiv (z. B. Bestellung ausgelöst, Ersatzteil unterwegs); optionaler Zwischenstatus, kein Pflichtdurchlauf.
- **Mindermenge genehmigt** – zusätzlicher Vermerk/Substatus, KEIN Ersatz für „offen“; Fehlbestand bleibt fachlich offen, nur die Bewertung/Sichtbarkeit ändert sich (Karte 08). Läuft automatisch aus bei nächster Kontrolle des Objekts.
- **nachgefüllt (teilweise)** – Ist-Menge wurde erhöht, aber Soll noch nicht vollständig erreicht; Fehlmenge reduziert sich. Technisch eigener Status `nachgefuellt_teilweise` (Prompt 20), fachlich zählt er weiterhin als „offen" – Dashboard-Kennzahlen (Prompt 12) müssen `offen`, `in_bearbeitung` UND `nachgefuellt_teilweise` gemeinsam als „offen" aggregieren.
- **erledigt** – Ist-Menge = Soll-Menge erreicht, unabhängig davon ob durch sofortige Nachfüllung (Karte 07) oder spätere Lieferung.

**Wichtigste Regel (aus `reihenfolge.md`):** „Mindermenge genehmigt“ ist niemals gleichbedeutend mit „erledigt“. Ein Fehlbestand gilt ausschließlich als erledigt, wenn der tatsächliche Bestand wieder vollständig ist.

## 2. Pflichtattribute eines Fehlbestand-Vorgangs
| Feld | Beschreibung |
|---|---|
| Material | Referenz auf Materialstamm-Position |
| Ressource | Rucksack/Fahrzeug/Objekt, an dem Fehlbestand festgestellt wurde |
| Standort | zum Zeitpunkt der Feststellung |
| Sollmenge | zum Zeitpunkt der Feststellung (kann sich später durch Vorlagenänderung ändern, Vorgang bleibt an ursprünglichem Wert dokumentiert) |
| Istmenge | zum Zeitpunkt der Feststellung |
| Fehlmenge | Soll − Ist, wird bei Teilnachfüllung neu berechnet |
| Entstanden am | Zeitstempel, Grundlage für spätere Eskalation (Karte 12) |
| Festgestellt von | Mitarbeiter/Kontrolle, die den Fehlbestand ausgelöst hat |
| Ursache | optional (z. B. Verbrauch, nicht auffindbar, beschädigt) |
| Maßnahme(n) | Historie von Aktionen (Nachfüllung, Genehmigung, Bemerkungen) |
| Verantwortlicher | zuständiger Materialverantwortlicher (aus Zuständigkeits-Zuordnung, Karte 04) |
| Erledigt am | Zeitstempel, wenn Status „erledigt“ erreicht |
| Historie | vollständiger Verlauf aller Statuswechsel mit wer/wann/alt→neu |

## 3. Übergangsregeln
- **offen → in Bearbeitung**: manuell durch Verantwortlichen, rein informativ, keine Pflicht.
- **offen/in Bearbeitung → Mindermenge genehmigt**: nur durch Materialverantwortlicher/Leitungsverantwortlicher (Prompt 04), niemals durch Mitarbeiter/Kontrollorgan selbst.
- **jeder Status → erledigt**: ausschließlich automatisch durch das System, wenn Ist = Soll erreicht wird (nie manuell durch Setzen eines Häkchens ohne Mengenabgleich).
- **Mindermenge genehmigt → offen**: automatisch beim Start der nächsten Kontrolle desselben Objekts (Ablauf der Genehmigung, Karte 08), sofern die Abweichung dort weiterhin besteht.
- Sofortige Nachfüllung während der Kontrolle: Übergang offen → erledigt geschieht ohne Zwischenstatus, aber mit vollständigem Historieneintrag beider Ereignisse (Karte 07).

## 4. Sichtbarkeit
- Mitarbeiter: sieht offene Fehlbestände seiner kontrollierten/zugewiesenen Objekte, kann nachfüllen.
- Materialverantwortlicher/Leitungsverantwortlicher: sieht alle Fehlbestände seines Zuständigkeitsbereichs (Karte 04), kann genehmigen, Sollmengen anpassen.
- Administration: sieht alles, verwaltet Stammdaten/Struktur.

## 5. Vorbereitung für Roadmap-Feature Eskalation (Karte 12)
- Feld „entstanden am“ ist Pflicht, damit späteres Eskalationsjob (Prompt 24) Alter berechnen kann, ohne Modelländerung.
- Kein Eskalationsmechanismus selbst in V1 – nur Datenbasis.

## Offene Fragen für Prompt 04
- Bemerkungsfeld beim Fehlbestand: aus Prompt 02 offen – Pflicht oder optional? → Empfehlung: optional, aber bei Genehmigung einer Mindermenge zwingend (Begründungspflicht), siehe Prompt 04.
- Muss ein Fehlbestand einem bestimmten Verantwortlichen fest zugeordnet werden, oder reicht "sichtbar für alle Verantwortlichen des Zuständigkeitsbereichs"? → Im Schema (Prompt 20) als `verantwortlicher_id` NULLABLE umgesetzt: NULL bedeutet „sichtbar für alle Verantwortlichen des Zuständigkeitsbereichs" (Standardfall), gesetzter Wert bedeutet feste Zuordnung. Beide Fälle vom Modell abgedeckt, keine weitere Entscheidung nötig.

---

# Prompt 04 – Mindermengen-Ausnahmen

Bezug: [[03_fehlbestandsmanagement]], Karten [[03_sollmengen_recht]], [[08_mindermenge_gueltigkeit]].

## 1. Grundprinzip
Eine genehmigte Mindermenge ist eine **fachliche Bewertung**, kein Bestandsvorgang. Beispiel: Soll 10, Ist 8, Fehlbestand 2 → nach Genehmigung bleibt Ist weiterhin 8, Fehlbestand weiterhin 2, nur die Einstufung ändert sich von „unbewertet offen“ zu „bewusst akzeptiert, aber weiterhin offen“.

## 2. Wer darf genehmigen
- Materialverantwortlicher (Karte 03: darf auch Sollmengen ändern).
- Leitungsverantwortlicher (vermutlich gleiche oder erweiterte Rechte, final in Prompt 05 zu bestätigen).
- Mitarbeiter/Kontrollorgan: darf Abweichung feststellen und dokumentieren, NIEMALS selbst genehmigen.

## 3. Genehmigungsprozess
1. Offener Fehlbestand existiert (Prompt 03, Status „offen“ oder „in Bearbeitung“).
2. Berechtigte Rolle öffnet Fehlbestand, wählt „Mindermenge genehmigen“.
3. Pflichtfeld: Begründung (Freitext), z. B. „Lieferengpass Hersteller, Ersatz bestellt, Lieferung erwartet KW38“.
4. System setzt Vermerk „Mindermenge genehmigt“, verknüpft mit der aktuellen Kontrolle des Objekts.
5. Genehmigung ändert nicht Ist-Menge, nicht Fehlmenge, nicht den zugrundeliegenden „offen“-Zustand des Fehlbestands als Faktum.

## 4. Gültigkeitsdauer (Karte 08 – bereits entschieden)
- Genehmigung gilt automatisch nur **bis zur nächsten Kontrolle** desselben Objekts – kein Kalenderdatum, kein manuelles Ablaufen nötig.
- Bei Start der nächsten Kontrolle: Position wird regulär neu bewertet. Besteht die Abweichung weiterhin, ist eine neue, eigenständige Genehmigung erforderlich (alte Genehmigung erlischt automatisch, wird aber in der Historie sichtbar archiviert, nicht gelöscht).
- Wird die Abweichung bei nächster Kontrolle behoben (nachgefüllt), erledigt sich sowohl Fehlbestand als auch Genehmigungs-Vermerk gemeinsam.

## 5. Anzeige
- Im Kontroll-Screen: Position mit genehmigter Mindermenge zeigt deutliches Symbol „genehmigte Abweichung, gültig bis nächste Kontrolle“ + Begründung, damit Mitarbeiter nicht denkt, hier bestehe kein Handlungsbedarf.
- Im Dashboard: eigener Filter „genehmigte Mindermengen“, getrennt von unbewerteten offenen Fehlbeständen (Prompt 12).
- Fehlbestand-Zähler (z. B. für KPIs) muss genehmigte UND ungenehmigte offene Fehlbestände weiterhin als „offen“ zählen – Genehmigung ist keine Erledigung.

## 6. Verhalten nach Ablauf
- Kein separater „Ablauf-Job“ nötig, da Ablauf an Kontrollstart gekoppelt ist (kein Zeit-Trigger notwendig für V1, vereinfacht MVP).
- Falls später ein zusätzliches zeitbasiertes Ablaufen gewünscht wird (z. B. Genehmigung verfällt auch ohne neue Kontrolle nach X Tagen) → das wäre eine Erweiterung, aktuell nicht gefordert.

## 7. Historie/Audit
Jede Genehmigung protokolliert: wer, wann, Begründung, betroffene Kontrolle, und – beim automatischen Erlöschen – Zeitpunkt/Kontrolle, die sie beendet hat.

## Offene Fragen für Prompt 05
- Gibt es einen Unterschied in den Genehmigungsrechten zwischen Materialverantwortlichem und Leitungsverantwortlichem (z. B. Eskalationsstufen, Genehmigung ab bestimmter Fehlmengenhöhe nur durch Leitung)?

---

# Prompt 05 – Benutzerrollen und Rechte

Bezug: [[01_anforderungsanalyse]], [[02_prozess_kontrolle]], [[03_fehlbestandsmanagement]], [[04_mindermengen]], Karten [[01_rollen_zuordnung]], [[02_rechte_stammdaten]], [[03_sollmengen_recht]], [[04_organisationsstruktur]], [[09_authentifizierung]].

## 1. Rollen
- **Mitarbeiter/Kontrollorgan** – führt Kontrollen durch, füllt nach, meldet Abweichungen.
- **Materialverantwortlicher** – fachlich zuständig für Material eines Zuständigkeitsbereichs (Standort/Objekt, Karte 04), genehmigt Mindermengen, pflegt Sollmengen/Vorlagen.
- **Leitungsverantwortlicher** – übergeordnete Verantwortung, gleiche Rechte wie Materialverantwortlicher plus organisatorische/eskalierende Sicht (siehe 3.).
- **Administration** – verwaltet Stammdaten, Struktur, Benutzer, Zuständigkeiten.

Mehrfachrollen pro Person möglich (z. B. Mitarbeiter UND Materialverantwortlicher).

## 2. Berechtigungsmatrix

| Aktion | Mitarbeiter | Materialverantwortlicher | Leitungsverantwortlicher | Administration |
|---|---|---|---|---|
| Kontrolle durchführen/abschließen | ✅ | ✅ | ✅ | ✅ |
| Ist-Menge erfassen | ✅ | ✅ | ✅ | ✅ |
| Nachfüllung dokumentieren | ✅ | ✅ | ✅ | ✅ |
| Fehlbestand einsehen (eigener Zuständigkeitsbereich) | ✅ (nur zugewiesene/kontrollierte Objekte) | ✅ | ✅ | ✅ (alles) |
| Mindermenge genehmigen | ❌ | ✅ | ✅ | ❌ (Admin genehmigt fachlich nicht, reine Stammdatenrolle) |
| Sollmenge/Vorlage ändern | ❌ | ✅ (Karte 03) | ✅ | ✅ |
| Zuständigkeiten zuordnen (wer verantwortet was) | ❌ | ❌ | ❌ | ✅ (Karte 04) |
| Objekte/Ressourcen anlegen, duplizieren | ❌ | ❌ | ❌ | ✅ |
| Materialstamm pflegen | ❌ | ❌ | ❌ | ✅ |
| Benutzer/Rollen verwalten | ❌ | ❌ | ❌ | ✅ |
| Kontrollverantwortung zuweisen (Einzelperson/Gruppe) | ❌ | ✅ (eigener Bereich) | ✅ | ✅ |
| Historie/Audit einsehen (eigener Bereich) | ✅ (eigene Aktionen) | ✅ | ✅ | ✅ (alles) |
| Dashboard mit offenen Fehlbeständen/Mindermengen | ❌ (nicht nötig, sieht nur eigene Objekte in Kontroll-UI) | ✅ | ✅ | ✅ |

## 3. Offene Frage aus Prompt 04 – geklärt
**Frage:** Unterschied in Genehmigungsrechten zwischen Materialverantwortlichem und Leitungsverantwortlichem?

**Entscheidung:** In V1 **keine** fachliche Einschränkung – beide dürfen jede Mindermenge in ihrem Zuständigkeitsbereich genehmigen, unabhängig von Fehlmengenhöhe. Kein Eskalationsstufen-Zwang beim Genehmigen selbst.
Begründung: Materialverantwortlicher ist die fachlich nähere, schnellere Instanz; Leitung soll nicht zum Flaschenhals werden. Eskalation (Karte 12) ist ein separater, zeitbasierter Mechanismus für *unbearbeitete* Fehlbestände, keine Genehmigungshierarchie.
Für spätere Ausbaustufe denkbar, aber nicht MVP: Schwellenwert (z. B. hohe Fehlmengen nur durch Leitung genehmigbar) – als Roadmap-Notiz vermerkt, kein Datenmodell-Zwang jetzt.

## 4. Feingranulare Rechte (zusätzlich identifiziert)
- Lesen vs. Schreiben pro Bereich (z. B. Leitungsverantwortlicher kann bereichsübergreifend lesen, aber nur in zugewiesenem Bereich schreiben – abhängig von Zuständigkeits-Zuordnung Karte 04).
- Eigene Aktionen vs. fremde Aktionen einsehen (Mitarbeiter sieht nur eigene Historie, Verantwortliche sehen Historie ihres Bereichs).
- Genehmigen vs. Sollmenge ändern sind zwei getrennte Rechte (nicht zwingend gekoppelt), falls später feinere Rollen gewünscht (z. B. "nur genehmigen, keine Vorlagenänderung").

## 5. Mögliche zukünftige Rollen (Roadmap, nicht MVP)
- **Lagerverantwortlicher** (Prompt 15 – separate Lagerbestände, getrennt vom Objektbestand).
- **Prüforgan/Medizinprodukteverantwortlicher** (Prompt 14/24 – Prüfungen, Ablaufdaten, Medizinprodukte-Konformität).
- **Bereichsleitung** oberhalb Leitungsverantwortlicher, falls generischer Ressourcenansatz (Karte 11) mehrere Bereiche mit eigener Leitung erfordert.
- **Read-only-Auditor** (z. B. externe Prüfung/Revision) – nur Historie/Audit einsehen, keine Aktionen.

## Referenzen
Arbeitskarten: [[01_rollen_zuordnung]], [[02_rechte_stammdaten]], [[03_sollmengen_recht]], [[04_organisationsstruktur]], [[09_authentifizierung]]

---

# Prompt 06 – Erweiterbares Datenmodell

Bezug: alle Ergebnisse 01-05, Karten [[04_organisationsstruktur]], [[10_qr_barcode]], [[11_systemumfang_ressourcenmanagement]], [[08_mindermenge_gueltigkeit]].

Reine fachliche Modellierung (Entitäten/Beziehungen), noch kein DB-Schema (folgt Prompt 20).

## 1. Grundprinzip der Trennung
Vier klar getrennte Schichten, dürfen nicht vermischt werden:
1. **Materialstamm** – was für Material gibt es grundsätzlich (Prompt 07).
2. **Beladungsvorlage** – welches Material soll in welcher Menge in einem Objekttyp sein (Prompt 08).
3. **Konkretes Objekt** – ein tatsächlicher Rucksack/Fahrzeug/Ressource mit eigener ID.
4. **Ist-Bestand** – tatsächlicher Zustand eines konkreten Objekts zu einem Zeitpunkt.

## 2. Kernentitäten

### Bereich (Karte 11)
- Fachliche Domäne, z. B. „Rettungsdienst/KatS". Oberste Gliederungsebene, macht System bereichsoffen.
- Attribute: Name, Beschreibung.

### Kategorie
- Gliedert Objekttypen/Material innerhalb eines Bereichs (z. B. „Rucksäcke", „Fahrzeuge", „Zelte").
- Kann hierarchisch sein (Kategorie → Unterkategorie), Granularität final in Prompt 07/11 vertiefen.
- Attribute: Name, Bereich-Referenz, übergeordnete Kategorie (optional).

### Standort
- Physischer Ort/Wache.
- Attribute: Name, Adresse (optional).

### Objekttyp / Ressourcentyp
- Generischer Oberbegriff statt „Rucksack" fest zu verdrahten (Karte 11): Rucksack, Fahrzeug, Zelt, Feldbett, Stromerzeuger, Funkgerät, ...
- Attribute: Name, Bereich-Referenz, Kategorie-Referenz.

### Beladungsvorlage
- Vorlage für einen Objekttyp (z. B. „Rucksack Handball Standard").
- Enthält Liste von Vorlagenpositionen (Material + Sollmenge).
- Versionierbar (Prompt 08 vertieft).
- Attribute: Name, Objekttyp-Referenz, Version, gültig ab.

### Vorlagenposition
- Materialstamm-Referenz + Sollmenge innerhalb einer Vorlage.
- Attribute: Vorlage-Referenz, Material-Referenz, Sollmenge, Kategorie/Fach (z. B. „Fach 1").

### Objekt (konkreter Rucksack/Fahrzeug/Ressource)
- Konkrete, physische Instanz.
- Attribute: eindeutige Objekt-ID, Code-Feld für QR/Barcode (Karte 10, Code128-kompatibel), Name/Bezeichnung, Objekttyp-Referenz, Beladungsvorlage-Referenz (Basis), Standort-Referenz, Status (aktiv/außer Dienst).
- Zuständigkeits-Zuordnung: n:m-Beziehung zu Verantwortlichen (Karte 04), nicht starr an Standort gekoppelt.

### Objektposition (Ist-Soll je Objekt)
- Individuelle Ist-Situation je Material innerhalb eines konkreten Objekts.
- Sollmenge kann von Vorlage abweichen (individuelle Anpassung, Prompt 10) → eigenes Feld „Sollmenge-Override", sonst Vorlagenwert.
- Attribute: Objekt-Referenz, Material-Referenz, aktuelle Sollmenge (effektiv), aktuelle Istmenge, optional Sollmenge-Override-Flag.

### Materialstamm-Position (Detail in Prompt 07)
- Stammdaten eines Materials (Name, Artikelnummer, Einheit, Materialtyp: Standard/Ablaufdatum-Charge/Gerät-mit-SN).
- Bei Materialtyp „Gerät": eigenes Code-Feld für QR/Barcode-SN-Erkennung (Karte 10).

### Kontrolle
- Ein Kontrollvorgang zu einem Zeitpunkt an einem Objekt.
- Attribute: Objekt-Referenz, durchgeführt von (Benutzer), Start, Ende, Status (nicht gestartet/in Bearbeitung/abgeschlossen/abgebrochen).
- Enthält Kontrollpositionen (Snapshot je Material: Soll zum Zeitpunkt, Ist erfasst, Abweichung ja/nein).

### Kontrollposition
- Snapshot-Ergebnis je Material innerhalb einer Kontrolle (unveränderlich nach Abschluss, für Historie).

### Fehlbestand (Prompt 03)
- Eigenständiger Vorgang, entkoppelt vom Kontrollabschluss.
- Attribute: siehe Prompt 03 (Material, Objekt, Standort, Soll, Ist, Fehlmenge, entstanden am, festgestellt von, Ursache, Verantwortlicher, erledigt am).
- Statusmaschine wie in Prompt 03 definiert.

### Nachfüllung
- Ereignis, das Ist-Menge eines Objekts erhöht.
- Attribute: Objekt-Referenz, Material-Referenz, Menge, wer, wann, verknüpfter Fehlbestand (falls vorhanden).

### Mindermengen-Genehmigung (Prompt 04)
- Eigene Entität, verknüpft mit Fehlbestand + auslösender Kontrolle.
- Attribute: Fehlbestand-Referenz, genehmigt von, Begründung, Zeitstempel, gültig bis (nächste Kontrolle desselben Objekts), Status (aktiv/abgelaufen/durch Erledigung beendet).
- NIEMALS Schreibzugriff auf Ist-Menge.

### Benutzer
- Attribute: Name, Login-Kennung, Passwort-Hash/PIN (Karte 09), Rollen (n:m, Prompt 05), aktiv/inaktiv.

### Rolle
- Mitarbeiter/Kontrollorgan, Materialverantwortlicher, Leitungsverantwortlicher, Administration (Prompt 05). Erweiterbar für Roadmap-Rollen.

### Zuständigkeits-Zuordnung
- n:m zwischen Benutzer (mit Rolle Materialverantwortlicher/Leitungsverantwortlicher) und Standort/Objekt (Karte 04), von Administration gepflegt.

### Historieneintrag (Prompt 13 vertieft)
- Generisches Audit-Log: wer, was (Entität+ID), wann, alter Wert, neuer Wert, Begründung (optional), Aktionstyp.

## 3. Zentrale Beziehungen (vereinfacht)

```
Bereich 1───n Kategorie
Bereich 1───n Objekttyp
Objekttyp 1───n Beladungsvorlage 1───n Vorlagenposition n───1 Materialstamm-Position
Objekttyp 1───n Objekt
Beladungsvorlage 1───n Objekt (Basis-Referenz)
Objekt 1───n Objektposition n───1 Materialstamm-Position
Objekt n───m Benutzer (Zuständigkeits-Zuordnung)
Objekt 1───n Kontrolle 1───n Kontrollposition
Objektposition/Kontrolle 1───n Fehlbestand
Fehlbestand 1───n Nachfüllung
Fehlbestand 1───0..n Mindermengen-Genehmigung (i.d.R. max. 1 aktive)
Benutzer n───m Rolle
Alles ───1 Historieneintrag (generisch, polymorph auf Entität+ID)
```

## 4. Erweiterbarkeit ohne Schema-Umbau (Designziel)
- Materialtyp als eigenes Attribut in Materialstamm-Position (nicht als Tabellen-Fork) → Medikamente/Chargen/SN später als Zusatzfelder/Zusatztabellen andockbar (Prompt 07).
- Lagerbestand (Prompt 15) als eigene Entität analog „Objekt", nur mit Lagerort statt Kontrolle/Fehlbestand-Workflow – gleiche Materialstamm-Basis wiederverwendbar.
- Prüfungen (Geräte-TÜV o. ä., Prompt 24) als eigene Entität mit Referenz auf Materialstamm-Position/Objektposition, unabhängig vom Kern-Fehlbestandsmodell.
- Code-Feld bereits in Objekt UND Materialstamm-Position vorgesehen (Karte 10), keine Migration nötig, wenn Scan-Funktion kommt.
- „Entstanden am" in Fehlbestand bereits vorgesehen (Karte 12) für Eskalation.

## Referenzen
Arbeitskarten: [[04_organisationsstruktur]], [[10_qr_barcode]], [[11_systemumfang_ressourcenmanagement]], [[08_mindermenge_gueltigkeit]], [[09_authentifizierung]]

---

# Prompt 07 – Materialstamm definieren

Bezug: [[06_datenmodell]], Karten [[10_qr_barcode]].

## 1. Grundprinzip
Nicht jedes Material braucht dieselben Felder. Materialstamm-Position hat **Basisfelder (immer)** + **typspezifische Zusatzfelder (je Materialtyp)**, statt für jeden Typ eine eigene Tabelle.

## 2. Materialtypen
1. **Standard-Verbrauchsmaterial** – einfache Zähl-/Mengenware ohne Ablauf/SN. Beispiele: Rettungsdecken, Kompressen, Verbandspäckchen.
2. **Material mit Ablaufdatum/Charge** – Verbrauchsmaterial mit Haltbarkeit. Beispiele: Infusionssysteme, Medikamente (später), sterile Sets.
3. **Einzelobjekt/Gerät mit Seriennummer** – nicht stückzahlbasiert, sondern individuell identifiziert. Beispiele: Pulsoxymeter, Blutzuckermessgerät, Beatmungsbeutel (falls mit SN geführt).

Typ ist ein Attribut der Materialstamm-Position, keine getrennte Tabelle – neue Typen später ohne Schema-Umbau ergänzbar (Designziel Prompt 06).

## 3. Basisfelder (Pflicht, für alle Typen)
| Feld | Beschreibung |
|---|---|
| Name | Bezeichnung, z. B. „Kompresse steril 10x10" |
| Artikelnummer | interne oder Hersteller-Artikelnummer (aus bestehenden Excel-Listen übernehmbar) |
| Einheit | Stück, Packung, Paar, ... |
| Materialtyp | Standard / Ablaufdatum-Charge / Gerät-mit-SN |
| Bereich/Kategorie-Referenz | Einordnung (Karte 11) |
| Aktiv/inaktiv | ob Material noch beschafft/verwendet wird |

## 4. Optionale Basisfelder (für alle Typen, aber nicht zwingend befüllt)
- Hersteller
- Beschreibung/Hinweistext
- Bild (Roadmap, nicht MVP)
- Code-Feld für QR/Barcode-Erkennung (Karte 10) – bei Typ „Gerät-mit-SN" faktisch Pflicht für spätere SN-Erkennung, bei anderen Typen optional (z. B. Materialstamm-Etikett).

## 5. Typspezifische Zusatzfelder

### Standard-Verbrauchsmaterial
- keine Zusatzfelder nötig (nur Basisfelder).

### Material mit Ablaufdatum/Charge
- Chargennummer (je konkreter Bestandseinheit, nicht im Stammsatz selbst, sondern in der Objektposition/Bestandseinheit – Stammsatz definiert nur „hat Ablauf/Charge: ja")
- Warnzeitraum-Vorgabe (Standardwert, konfigurierbar, Prompt 14 vertieft)
- Lagerbedingungen (optional, Freitext, z. B. „kühl lagern")

### Einzelobjekt/Gerät mit Seriennummer
- Seriennummer wird nicht im Stammsatz geführt (der Stammsatz beschreibt das Gerätemodell, z. B. „Pulsoxymeter Modell X"), sondern je konkretem Exemplar in der Objektposition/eigenen Geräte-Instanz.
- Prüfintervall-Vorgabe (optional, Vorbereitung Prompt 24 „Prüfungen")
- Zubehör/Kompatibilitätshinweis (optional, Freitext)

## 6. Abgrenzung Stammsatz vs. konkrete Instanz
Wichtig, um Prompt 06 konsistent zu bleiben:
- **Materialstamm-Position** = abstrakte Beschreibung („was ist das für ein Material").
- **Objektposition** (in einem konkreten Rucksack/Fahrzeug) = konkrete Menge/Instanz, dort leben Chargennummer, Ablaufdatum, Seriennummer der jeweiligen physischen Einheit.
- Ein Stammsatz „Pulsoxymeter Modell X" kann in mehreren Objekten vorkommen, mit jeweils eigener Seriennummer je Instanz.

## 7. Pflichtfelder-Zusammenfassung
| Materialtyp | Pflicht im Stammsatz | Pflicht in Objektposition/Instanz |
|---|---|---|
| Standard | Name, Artikelnummer, Einheit, Kategorie | Ist-Menge |
| Ablaufdatum/Charge | Name, Artikelnummer, Einheit, Kategorie, „hat Ablauf: ja" | Ist-Menge, Ablaufdatum, Chargennummer |
| Gerät mit SN | Name, Artikelnummer, Einheit=„Stück", Kategorie, „hat SN: ja" | Seriennummer, Status (vorhanden/defekt/fehlt) |

## 8. Spätere Erweiterungsmöglichkeiten (Roadmap, nicht MVP)
- Medikamente als eigener Materialtyp mit Betäubungsmittel-Kennzeichnung, Dosierungseinheit (Prompt 24).
- Bild-Upload je Material.
- Verknüpfung zu Lieferanten/Bestellinformationen (Prompt 15/24).
- Mehrsprachige Bezeichnung (falls organisationsübergreifend genutzt).

## Referenzen
Arbeitskarten: [[10_qr_barcode]]
Bezug: [[06_datenmodell]]

---

# Prompt 08 – Beladungsvorlagen entwickeln

Bezug: [[06_datenmodell]], [[07_materialstamm]].

## 1. Grundprinzip
Vorlage = Soll-Struktur für einen Objekttyp, unabhängig von konkretem Objekt. Beispiele: „Rucksack Handball Standard", „RTW Standard", „NEF Standard". Konkrete Objekte referenzieren eine Vorlage als Basis, dürfen individuell abweichen (Prompt 10).

## 2. Aufbau einer Vorlage
- Name, Objekttyp-Referenz, Version, gültig ab, Status (aktiv/veraltet).
- Enthält Kategorien/Fächer (z. B. „Fach 1", „Fach 2" – analog Struktur bestehender Excel-Listen).
- Je Kategorie/Fach: Liste von Vorlagenpositionen (Materialstamm-Referenz + Sollmenge).

## 3. Erstellung
- Nur Administration/Materialverantwortlicher (Prompt 05) darf Vorlagen erstellen.
- Neue Vorlage entweder leer oder durch Duplizieren einer bestehenden Vorlage/eines bestehenden Objekts als Startpunkt (Verknüpfung zu Prompt 09).

## 4. Änderung und Versionierung
- Vorlage wird nicht direkt überschrieben, sondern es entsteht bei inhaltlicher Änderung (Sollmengen, Positionen hinzu/entfernt) eine **neue Version** derselben Vorlage.
- Alte Version bleibt für bereits abgeschlossene Kontrollen/Historie unverändert nachvollziehbar (welche Soll-Werte galten zum Zeitpunkt X).
- Objekte referenzieren die Vorlage lose (Name/ID), lösen aber „aktuelle Version" auf, sofern keine individuelle Abweichung (Prompt 10) diese überschreibt.

## 5. Zuweisung zu Objekten
- Bei Anlage eines neuen Objekts: eine Vorlage als Basis wählen → Objektpositionen werden aus Vorlagenpositionen initial übernommen (Sollmengen kopiert als Startwert).
- Ein Objekt kann seine Vorlagen-Basis auch nachträglich wechseln (z. B. Fahrzeug wird umgerüstet) – Administration/Materialverantwortlicher-Aktion, mit Hinweis auf Auswirkung auf bestehende individuelle Abweichungen.

## 6. Vorlagenänderung auf bestehende Objekte anwenden
- Wenn Vorlage geändert wird (neue Version), betroffene Objekte NICHT automatisch überschrieben (Gefahr: individuelle Abweichungen gehen verloren).
- Stattdessen: System bietet Verantwortlichen an „Vorlagenänderung übernehmen?" pro betroffenem Objekt, mit Diff-Anzeige (was ändert sich), Entscheidung pro Position möglich (übernehmen/behalten), Details in Prompt 10.

## 7. Individuelle Abweichungen (Verweis)
Details in Prompt 10 – hier nur Schnittstelle: Objektposition kann Sollmengen-Override gegenüber Vorlage haben, Vorlage selbst bleibt unverändert.

## 8. Löschen/Deaktivieren einer Vorlage
- Vorlage wird nie hart gelöscht, wenn bereits Objekte oder Kontrollen darauf verweisen (Historie-Integrität) – nur Status „veraltet/inaktiv", nicht mehr für neue Objekte wählbar.

## Referenzen
Bezug: [[06_datenmodell]], [[07_materialstamm]]

---

# Prompt 09 – Rucksäcke und Fahrzeuge duplizieren

Bezug: [[06_datenmodell]], [[08_beladungsvorlagen]].

## 1. Grundprinzip
Duplizieren erzeugt neues Objekt, übernimmt Struktur/Sollmengen, aber NIE Zustandsdaten. Grundprinzip aus `prompts.md`: „Duplizierte Objekte müssen anschließend individuell bearbeitbar sein."

## 2. Was wird kopiert
- Objekttyp-Referenz
- Beladungsvorlage-Referenz (aktuelle Version)
- Objektpositionen-Struktur: Material + Sollmenge (inkl. bestehender individueller Sollmengen-Abweichungen, falls Quelle=konkretes Objekt statt Vorlage)
- Zuständigkeits-Zuordnung: optional übernehmbar (Abfrage), da neues Objekt evtl. anderer Standort/Verantwortlicher

## 3. Was NICHT kopiert wird
- Aktuelle Ist-Bestände (Istmenge wird auf 0 oder „nicht kontrolliert" gesetzt, nicht auf Soll)
- Seriennummern konkreter Geräte-Instanzen
- Chargennummern/Ablaufdaten
- Offene Fehlbestände
- Kontrollhistorie
- Genehmigte Mindermengen
- Code-/QR-Feld (Karte 10): neues Objekt braucht eigenen, neuen Code, kein Duplikat des Quell-Codes (Eindeutigkeit)

## 4. Ablauf
1. Verantwortlicher/Administration wählt Quelle: bestehendes Objekt ODER Beladungsvorlage direkt.
2. System zeigt Vorschau: welche Positionen werden übernommen (Struktur/Soll), Hinweis „Ist-Bestände und Historie werden NICHT übernommen".
3. Pflichteingabe für neues Objekt: neuer Name/Bezeichnung, Standort, neuer Code (QR/Barcode, Karte 10).
4. Optional: Zuständigkeits-Zuordnung direkt mit anlegen oder später durch Administration.
5. Neues Objekt wird angelegt mit Status „neu, noch nicht kontrolliert" – erste Kontrolle erforderlich, um echten Ist-Bestand zu erfassen.
6. Neues Objekt ist ab sofort vollständig individuell editierbar (Sollmengen-Overrides, Vorlage wechseln, etc. – Prompt 10).

## 5. Duplizieren als Vorlagen-Erstellung (Verweis Prompt 08)
- Duplizieren eines Objekts kann auch als Ausgangspunkt für eine **neue Beladungsvorlage** dienen (z. B. „dieses individuell angepasste Fahrzeug soll neuer Standard werden") – separate Aktion, nicht automatisch, Administration entscheidet bewusst.

## 6. Sonderfall: mehrfaches Duplizieren (Serie)
- Möglich, z. B. 5 gleiche Rucksäcke auf einmal anlegen: einmalige Struktur-Auswahl, aber je Kopie eigener Name/Code/Standort-Eingabe (Pflicht, da Eindeutigkeit).

## Referenzen
Bezug: [[06_datenmodell]], [[08_beladungsvorlagen]], Karte [[10_qr_barcode]]

---

# Prompt 10 – Individuelle Anpassungen

Bezug: [[06_datenmodell]], [[08_beladungsvorlagen]], [[09_duplizieren]].

## 1. Grundprinzip
Konkretes Objekt darf von seiner Vorlage abweichen, ohne die Vorlage selbst zu verändern. Abweichung wird auf Ebene der Objektposition gespeichert, nicht in der Vorlage.

## 2. Arten von Abweichungen
1. **Sollmengen-Override** – Material aus Vorlage vorhanden, aber andere Sollmenge (Beispiel: Vorlage 10 BZ-Messtreifen, Fahrzeug braucht 15).
2. **Zusätzliches Material** – Position, die in der Vorlage nicht existiert, nur bei diesem Objekt.
3. **Entferntes Material** – Vorlagenposition wird bei diesem Objekt bewusst nicht geführt (Soll = 0, als „entfernt" markiert, nicht einfach gelöscht).

## 3. Speicherung
- Objektposition hat Feld „Sollmenge effektiv" + Flag „Override: ja/nein" + optional „Override-Grund" (Freitext).
- Ist Override = nein → Sollmenge wird aus aktueller Vorlagenversion übernommen (dynamisch).
- Ist Override = ja → Sollmenge kommt aus der Objektposition selbst, unabhängig von Vorlagenänderungen, bis Override manuell aufgehoben wird.
- Zusätzliches Material: Objektposition ohne zugehörige Vorlagenposition, aber mit Materialstamm-Referenz, klar als „nur bei diesem Objekt" markiert.
- Entferntes Material: Objektposition mit Status „entfernt/nicht geführt" statt physischer Löschung – bleibt in Historie sichtbar, warum es fehlt.

## 4. Anzeige
- Kontroll-UI (Prompt 11) markiert abweichende Positionen deutlich (Symbol „individuell angepasst"), damit Kontrollperson nicht denkt, es handle sich um Standard.
- Bei Override: Anzeige beider Werte auf Wunsch (Vorlage: 10, dieses Objekt: 15) für Nachvollziehbarkeit.

## 5. Vorlagenänderung trifft individuell abweichendes Objekt
- Direkter Bezug zu Prompt 08, Punkt 6: Wird die Vorlage geändert (z. B. Sollmenge einer Position erhöht), betrifft das nur NICHT-Override-Positionen automatisch (da dynamisch referenziert).
- Override-Positionen bleiben unberührt, außer Verantwortlicher hebt den Override bewusst auf ("wieder auf Vorlage zurücksetzen").
- Neue Vorlagenpositionen (komplett neues Material in Vorlage): System bietet an, sie bei bestehenden Objekten zu ergänzen (Diff-Ansicht, Prompt 08), Verantwortlicher entscheidet pro Objekt/Position.
- Entfernte Vorlagenpositionen: bei Objekten mit „entfernt"-Markierung ohnehin irrelevant; bei Objekten ohne eigene Abweichung wird Position ebenfalls zur Übernahme als „entfernen?" vorgeschlagen, nicht automatisch gelöscht.

## 6. Nachvollziehbarkeit
- Jede Abweichung (Override gesetzt/aufgehoben, Material hinzugefügt/entfernt) erzeugt Historieneintrag: wer, wann, alter/neuer Wert, Begründung (Prompt 13).

## Referenzen
Bezug: [[06_datenmodell]], [[08_beladungsvorlagen]], [[09_duplizieren]]

---

# Prompt 11 – Benutzeroberfläche für Mitarbeiter

Bezug: [[02_prozess_kontrolle]], [[10_individuelle_beladung]], Karte [[06_geraet_pc_mobil]], [[10_qr_barcode]].

## 1. Grundprinzip
Minimaler Tippaufwand. Normalfall = ein Tap pro Position. Zusatzfragen nur bei Abweichung. Große Touchflächen, klare Farben, für Einsatzumfeld/Handschuhe geeignet.

## 2. Screen-Ablauf

### Screen 1 – Standort/Objekt wählen
- Liste zugewiesener Objekte zuerst (Karte 01), darunter „alle Objekte" durchsuchbar.
- Alternative: QR-/Barcode-Scan (Kamera, Karte 10) → Direktsprung zu Screen 3, sobald Feature verfügbar (Roadmap).
- Suchfeld, Filter nach Standort.

### Screen 2 – Kontrollstart
- Objekt-Info (Name, Typ, Standort, letzte Kontrolle wann/von wem).
- Button „Kontrolle starten" → Status wechselt zu „in Bearbeitung", Objekt wird gesperrt (Prompt 02, Punkt 9).
- Hinweis, falls offene Fehlbestände aus vorheriger Kontrolle noch bestehen (informativ, kein Blocker).
- **Ist Objekt bereits gesperrt** (jemand kontrolliert es aktiv, per Scan/Start ausgelöst): statt „Kontrolle starten" erscheint Meldung „wird gerade von [Name] kontrolliert, seit [Zeitpunkt]" + Button „trotzdem übernehmen" (Prompt 02, Punkt 9). Übernahme erfordert Bestätigung (zweiter Tap), um versehentliches Entziehen zu vermeiden.

### Screen 3 – Kategorien/Fächer-Übersicht
- Liste der Fächer/Kategorien der Vorlage (z. B. „Fach 1", „Fach 2"), mit Fortschrittsanzeige (X von Y Positionen erledigt) je Fach.
- Tap auf Fach → Screen 4.

### Screen 4 – Materialpositionen (Kernscreen)
- Je Position: Name, Sollmenge, großer Bestätigungs-Button „passt" (ein Tap, entspricht Ist=Soll).
- Alternative: Zahlenfeld/Stepper für abweichende Ist-Menge, direkt sichtbar ohne extra Screen wechseln.
- Individuell angepasste Positionen (Prompt 10) mit eigenem Symbol markiert.
- Bereits bestätigte Positionen visuell abgehakt (grün), offene Positionen neutral, abweichende Positionen rot/gelb markiert.
- Bei Materialtyp „Gerät mit SN" (Prompt 07): zusätzliches Feld/Scan für Seriennummer, falls nicht bereits erfasst.
- Bei Materialtyp „Ablaufdatum/Charge": Anzeige Ablaufstatus (Prompt 14), Warnfarbe bei bald ablaufend/abgelaufen, auch wenn Menge stimmt.

### Screen 5 – Abweichung (erscheint nur bei Ist < Soll)
- Anzeige Fehlmenge automatisch berechnet.
- Frage: „Direkt aus Lager nachfüllen?" – Ja/Nein als große Buttons (Karte 07).
  - Ja → Mengeneingabe (vorbelegt mit Fehlmenge, editierbar bei Teilnachfüllung), Bestätigung → Fehlbestand+Nachfüllung im Hintergrund verbucht (Prompt 02/03).
  - Nein → optionales Bemerkungsfeld (Ursache), Fehlbestand bleibt offen, zurück zu Screen 4.

### Screen 6 – Kontrollabschluss (Prompt 16 vertieft)
- Zusammenfassung: Anzahl Positionen ok, Anzahl Abweichungen, Anzahl noch offener Fehlbestände.
- Bestätigungs-Button „Kontrolle abschließen".
- Hinweis, falls offene Fehlbestände bestehen bleiben („bleiben als eigene Vorgänge sichtbar").

## 3. Bedienprinzipien
- Touch-Ziele mindestens fingerspitzengerecht groß (Einsatzumfeld, ggf. Handschuhe).
- Statusfarben konsistent: grün=ok, gelb=abweichend/in Bearbeitung, rot=kritisch/offen, grau=neutral/nicht bearbeitet.
- Keine Pflicht-Freitexteingabe im Normalfall (nur bei Mindermengen-Begründung/Ursache optional).
- Fortschritt jederzeit sichtbar (X von Y Positionen), damit Unterbrechung (Einsatzalarmierung) klar erkennbar bleibt, wo man stand.
- Geräteunabhängig fortsetzbar (Karte 06): Status „in Bearbeitung" ist login-/objektgebunden, nicht gerätegebunden.

## 4. Offene Punkte für spätere Prompts
- Genaues Verhalten bei „Kontrolle abbrechen" (Screen-Ebene) final in Prompt 16.
- Offline-Verhalten der UI (Netzausfall mitten in Kontrolle) final in Prompt 17.

## Referenzen
Bezug: [[02_prozess_kontrolle]], [[10_individuelle_beladung]]
Arbeitskarten: [[06_geraet_pc_mobil]], [[07_sofort_nachfuellung]], [[10_qr_barcode]]

---

# Prompt 12 – Dashboard für Verantwortliche

Bezug: [[03_fehlbestandsmanagement]], [[04_mindermengen]], [[05_rollen_rechte]], Karte [[05_benachrichtigungen]], [[12_eskalation]].

## 1. Zielgruppe
Materialverantwortlicher, Leitungsverantwortlicher, Administration (Prompt 05). Sicht nach Zuständigkeitsbereich gefiltert (Karte 04), Administration sieht alles.

## 2. Kennzahlen (Übersicht oben)
- Anzahl offener Fehlbestände (gesamt, im Zuständigkeitsbereich) – **zählt die Status `offen`, `in_bearbeitung` UND `nachgefuellt_teilweise` gemeinsam als „offen"** (Prompt 03/20 – technischer Substatus ist keine Erledigung).
- davon genehmigte Mindermengen (separat gezählt, Prompt 04: gilt weiterhin als offen)
- Anzahl kürzlich erledigter Fehlbestände (z. B. letzte 7 Tage)
- Anzahl bevorstehender Ablaufdaten (Prompt 14, Vorschau)
- Anzahl fälliger Prüfungen (Roadmap-Feld, Prompt 24, falls Daten vorhanden)
- Anzahl problematischer Objekte (Objekte mit ≥1 offenem Fehlbestand, als Kennzahl „X von Y Objekten ohne Beanstandung")

## 3. Hauptlisten/Tabellen

### Offene Fehlbestände
- Spalten: Material, Objekt, Standort, Fehlmenge, Status (offen/in Bearbeitung/Mindermenge genehmigt), Alter (Tage seit „entstanden am", Vorbereitung Eskalation Karte 12), Verantwortlicher.
- Filter: Standort, Objekt, Material, Alter (z. B. „älter als 7 Tage"), Status.
- Sortierung standardmäßig nach Alter absteigend (älteste zuerst) – unterstützt Eskalationsgedanken auch ohne automatisierten Job.
- Aktion direkt aus Liste: Mindermenge genehmigen, Nachfüllung erfassen, Detail öffnen.

### Genehmigte Mindermengen
- Eigener Filter/Tab, getrennt von unbewerteten (Prompt 04, Punkt 5).
- Spalten wie oben plus Begründung, genehmigt von, gültig bis (nächste Kontrolle).

### Kürzlich erledigte Fehlbestände
- Spalten: Material, Objekt, erledigt am, erledigt durch (Nachfüllung wer).
- Dient als „Erfolgs"-Sicht, keine Aktion nötig.

### Bevorstehende Ablaufdaten (Verweis Prompt 14)
- Kompakte Vorschau, Link zu vollständiger Ablauf-Ansicht.

## 4. Detailansicht (Klick auf Fehlbestand)
- Vollständige Historie (Prompt 13): Kontrolle, die ihn ausgelöst hat, alle Nachfüllungen/Teilschritte, Genehmigungen, aktueller Status.
- Aktionsbuttons je nach Rolle/Status: genehmigen, Nachfüllung erfassen, Sollmenge anpassen (Karte 03).

## 5. Suchmöglichkeiten
- Globale Suche über Objekte/Material (Name, Artikelnummer, Code/QR-ID).
- Schnellzugriff auf ein bestimmtes Objekt unabhängig vom Fehlbestand-Kontext.

## 6. Vorbereitung Eskalation (Karte 12, Roadmap)
- Alter-Spalte und -Filter bereits jetzt vorhanden (siehe oben), liefert Datenbasis.
- Kein automatischer Eskalations-Trigger/Benachrichtigung an Leitung in V1 (Karte 05: kein Push, nur Dashboard+E-Mail bei Entstehung), aber visuelle Hervorhebung alter offener Fehlbestände (z. B. rote Markierung ab konfigurierbarer Schwelle) als einfache Vorstufe sinnvoll und ohne Zusatzaufwand umsetzbar.

## Referenzen
Bezug: [[03_fehlbestandsmanagement]], [[04_mindermengen]], [[05_rollen_rechte]]
Arbeitskarten: [[04_organisationsstruktur]], [[05_benachrichtigungen]], [[12_eskalation]]

---

# Prompt 13 – Historie und Nachvollziehbarkeit

Bezug: [[06_datenmodell]] (Historieneintrag), [[03_fehlbestandsmanagement]], [[04_mindermengen]], [[10_individuelle_beladung]].

## 1. Grundprinzip
Jede fachlich relevante Aktion erzeugt einen unveränderlichen Historieneintrag: wer, was, wann, vorheriger Wert, neuer Wert, Begründung (falls vorhanden). Kein Löschen/Überschreiben von Historie, nur Anhängen.

## 2. Protokollierte Ereignistypen
| Ereignis | Ausgelöst durch | Gespeicherte Werte |
|---|---|---|
| Kontrolle gestartet/abgeschlossen/abgebrochen | Mitarbeiter | Objekt, Zeitpunkt, Status-Wechsel |
| Ist-Menge erfasst (je Position) | Mitarbeiter | Material, Soll, alter Ist, neuer Ist |
| Fehlbestand entstanden | System (automatisch) | Material, Objekt, Soll, Ist, Fehlmenge, entstanden am |
| Nachfüllung | Mitarbeiter/Verantwortlicher | Material, Objekt, Menge, wer, wann, verknüpfter Fehlbestand |
| Fehlbestand erledigt | System (automatisch bei Ist=Soll) | Zeitpunkt, auslösende Nachfüllung |
| Mindermenge genehmigt | Materialverantwortlicher/Leitung | Fehlbestand, Begründung, wer, wann, gültig bis |
| Mindermenge abgelaufen/beendet | System (automatisch) | Fehlbestand, Zeitpunkt/Kontrolle, die sie beendet hat |
| Sollmenge geändert (Vorlage oder Override) | Materialverantwortlicher/Administration | Material, Objekt/Vorlage, alter Wert, neuer Wert |
| Vorlage geändert (neue Version) | Administration/Materialverantwortlicher | Vorlage, Version alt/neu, geänderte Positionen |
| Individuelle Abweichung gesetzt/aufgehoben | Materialverantwortlicher | Objekt, Material, Override ja/nein, Begründung |
| Objekt dupliziert/angelegt | Administration | Quelle, neues Objekt, Zeitpunkt |
| Benutzer-/Rollenänderung | Administration | Benutzer, alte/neue Rolle(n) |
| Zuständigkeits-Zuordnung geändert | Administration | Benutzer, Standort/Objekt, alt/neu |

## 3. Beispiel-Kette (aus Prompt-Vorgabe)
Soll 10, Ist 8 → Fehlbestand entstanden (Fehlmenge 2) → keine Nachfüllung möglich (Status offen) → Mindermenge genehmigt (Begründung, gültig bis nächste Kontrolle) → später 2 Stück nachgefüllt → Ist wieder 10 → Fehlbestand automatisch erledigt, Mindermengen-Genehmigung automatisch beendet (verknüpft mit derselben Erledigung).
Jeder dieser Schritte ist ein eigener, zeitlich geordneter Historieneintrag, alle auf denselben Fehlbestand referenziert.

## 4. Darstellung

### Für Mitarbeiter
- Eigene Aktionen einsehbar (was habe ich wann bei welchem Objekt erfasst) – Prompt 05: keine fremde Historie sichtbar.
- Objektbezogene Detailansicht (Prompt 11 Screen 4/6): Verlauf der letzten Kontrollen dieses Objekts.

### Für Verantwortliche/Administration
- Vollständige Timeline je Fehlbestand (Dashboard-Detail, Prompt 12): chronologische Liste aller Ereignisse mit Icon je Typ.
- Filterbare globale Historie (z. B. „alle Änderungen an Vorlage X", „alle Genehmigungen von Benutzer Y") – v. a. für Administration/Audit-Zwecke.

## 5. Technische/fachliche Anforderungen an Historie
- Unveränderlich (Append-only), kein Update/Delete bestehender Einträge.
- Referenzintegrität auch bei gelöschten/inaktiven Stammdaten erhalten (z. B. Material wird deaktiviert, Historie zeigt trotzdem den Namen von damals – Snapshot-Prinzip wie bei Kontrollpositionen, Prompt 06).
- Zeitstempel immer serverseitig, nicht durch Client vorgebbar (Manipulationsschutz, Nachvollziehbarkeit im Rettungsdienst-/KatS-Kontext).

## Referenzen
Bezug: [[06_datenmodell]], [[03_fehlbestandsmanagement]], [[04_mindermengen]], [[10_individuelle_beladung]], [[05_rollen_rechte]]

---

# Prompt 14 – Ablaufdaten und Warnungen

Bezug: [[07_materialstamm]], [[11_kontroll_ui]], [[12_verantwortlichen_dashboard]].

## 1. Grundprinzip
Ablaufdatum lebt auf Ebene der konkreten Bestandseinheit (Objektposition/Charge), nicht im Materialstamm (Prompt 07, Punkt 6). Materialstamm definiert nur „hat Ablauf: ja" + Standard-Warnzeitraum.

## 2. Zustände
- **gültig** – Ablaufdatum liegt außerhalb Warnzeitraum.
- **bald ablaufend** – innerhalb konfigurierbarem Warnzeitraum (z. B. 30 Tage vor Ablauf).
- **abgelaufen** – Ablaufdatum überschritten.

Berechnung rein serverseitig anhand aktuellem Datum, kein manueller Status.

## 3. Warnzeiträume
- Standardwert je Materialstamm-Position hinterlegbar (z. B. 30 Tage), überschreibbar je Objektposition/Charge falls nötig (z. B. kritisches Material braucht längeren Vorlauf).
- Administration/Materialverantwortlicher pflegt Standardwerte.

## 4. Anzeige im Kontrollprozess (Prompt 11)
- Screen 4 (Materialpositionen): Position mit Ablaufdatum zeigt Status-Farbe zusätzlich zur Mengen-Bestätigung (gelb=bald ablaufend, rot=abgelaufen), auch wenn Menge korrekt ist – Mitarbeiter darf „passt" trotzdem nicht bestätigen, ohne den Ablauf-Hinweis gesehen zu haben.
- Austauschprozess: Mitarbeiter tauscht abgelaufenes Material aus wie in Alltagspraxis (Prompt 23 Papierablösung) → neues Exemplar mit neuem Ablaufdatum erfasst, altes wird wie Verbrauch behandelt (Ist-Menge bleibt gleich, nur Charge/Datum aktualisiert, kein Fehlbestand nötig sofern Menge stimmt).
- Ist bei Austausch kein Ersatz verfügbar (Lager leer) → behandelt wie normale Abweichung, Fehlbestand-Vorgang (Prompt 03).

## 5. Dashboard-Warnungen (Prompt 12)
- Kennzahl „bevorstehende Ablaufdaten" bereits vorgesehen.
- Eigene filterbare Liste: Material, Objekt, Ablaufdatum, verbleibende Tage, Status.
- Sortierung nach verbleibenden Tagen aufsteigend (dringendste zuerst).

## 6. Spätere Erweiterung: Chargen und Medikamente (Roadmap, Prompt 24)
- Chargenverwaltung mit mehreren Ablaufdaten pro Material innerhalb eines Objekts (z. B. zwei Packungen unterschiedlicher Charge gleichzeitig im Bestand) – V1 vereinfacht auf ein Ablaufdatum je Objektposition, Mehrfach-Chargen als Ausbaustufe.
- Medikamente mit Betäubungsmittel-Sonderregeln (Dokumentationspflichten) – eigener Materialtyp später, nutzt dieselbe Ablauf-Logik als Basis.

## Referenzen
Bezug: [[07_materialstamm]], [[11_kontroll_ui]], [[12_verantwortlichen_dashboard]]

---

# Prompt 15 – Zukünftige Lagerintegration

Bezug: [[06_datenmodell]], [[07_materialstamm]], [[02_prozess_kontrolle]]. Status: Roadmap-Konzept, NICHT MVP (V1 bleibt bewusst einfach).

## 1. Grundprinzip
Klare Trennung: Fahrzeug-/Rucksackbestand (Objektposition, operativ) vs. Lagerbestand (zentral, disponierend). V1 kennt nur „aus dem Lager nachgefüllt" als Aktion, ohne echte Lagerbestandsführung.

## 2. Zukünftige Lager-Entität (analog Objekt)
- **Lagerort** – eigener Standort-Typ, z. B. „Zentrallager Wache 1".
- **Lagerbestand** – Materialstamm-Referenz + Lagerort-Referenz + Menge, gleiche Materialstamm-Basis wie Objektpositionen (Prompt 06 Designziel: keine Duplizierung der Stammdaten).

## 3. Prozesse (Roadmap)
- **Materialentnahme**: Nachfüllung eines Objekts (Prompt 02) bucht künftig automatisch vom Lagerbestand ab, statt nur zu dokumentieren „nachgefüllt". Fehlt Lagerbestand → System warnt vor Entnahme, statt sie zu blockieren (keine harte Sperre, damit Einsatzfähigkeit nie durch Software blockiert wird).
- **Nachfüllung des Lagers selbst**: eigener Vorgang, Bestellung/Wareneingang erhöht Lagerbestand (Details Prompt 24).
- **Mindestbestände**: je Lagerbestand konfigurierbarer Schwellenwert, System warnt Lagerverantwortlichen (Roadmap-Rolle, Prompt 05) bei Unterschreitung.
- **Automatische Hinweise**: Dashboard-Erweiterung (Prompt 12) um „Lager unter Mindestbestand", analog zu Fehlbestand-Logik, aber eigener Vorgangstyp (nicht zu verwechseln mit Fehlbestand am Fahrzeug/Rucksack).

## 4. Warum nicht in V1
- Erfordert zusätzliche Prozesse (Wareneingang, Bestellwesen, Mindestbestands-Pflege), die den MVP-Umfang sprengen (Grundprinzip: „Version 1 soll bewusst klein und praxistauglich bleiben").
- V1-Nachfüllung bleibt bewusst simpel: Mitarbeiter bestätigt „habe nachgefüllt", ohne dass System prüft, ob Lager das hergibt.

## 5. Vorbereitung im Datenmodell (falls sinnvoll, ohne V1 zu verkomplizieren)
- Keine zwingende Vorbereitung nötig, da Lagerbestand strukturell wie ein weiteres „Objekt" mit eigenem Bestand modellierbar ist (Wiederverwendung Prompt 06) – kein Schema-Umbau bei späterer Einführung erwartet, nur neue Entität „Lagerort/Lagerbestand" + neuer Prozess „Entnahme bucht ab".

## Referenzen
Bezug: [[06_datenmodell]], [[07_materialstamm]], [[02_prozess_kontrolle]], [[05_rollen_rechte]] (Roadmap-Rolle Lagerverantwortlicher)

---

# Prompt 16 – Kontrolle abschließen

Bezug: [[02_prozess_kontrolle]], [[03_fehlbestandsmanagement]], [[11_kontroll_ui]].

## 1. Wann gilt eine Kontrolle als abgeschlossen
Eine Kontrolle gilt als abgeschlossen, wenn Mitarbeiter jede Position mindestens einmal bewertet hat (bestätigt „passt" oder Ist-Menge eingetragen) und aktiv „Kontrolle abschließen" bestätigt (Prompt 11, Screen 6). Offene Fehlbestände sind KEIN Blocker für den Abschluss.

## 2. Verhalten bei offenen Abweichungen
- Kontrolle wird trotz offener Fehlbestände abgeschlossen (Status „abgeschlossen").
- Jeder offene Fehlbestand bleibt als eigenständiger, von der Kontrolle entkoppelter Vorgang bestehen (Prompt 03) – Abschluss der Kontrolle ändert seinen Status nicht.
- Während der Kontrolle nachgefülltes Material: wird als behobene Abweichung dokumentiert (Fehlbestand entsteht und wird im selben Moment erledigt, Historieneintrag zeigt beide Ereignisse, Karte 07/Prompt 02).

## 3. Abschlussanzeige (Screen 6, Prompt 11 vertieft)
- Zusammenfassung: Gesamtzahl Positionen, davon ok, davon abweichend, davon sofort nachgefüllt, davon weiterhin offen.
- Liste der weiterhin offenen Fehlbestände mit direktem Link zur Detailansicht (Dashboard, Prompt 12).
- Deutlicher Hinweis: „X Fehlbestände bleiben offen und sind für Verantwortliche sichtbar" – kein falscher Eindruck von „alles erledigt".

## 4. Bestätigung
- Einmalige, eindeutige Bestätigungsaktion (Button „Kontrolle abschließen"), kein Doppel-Abschluss möglich (Status-Übergang „in Bearbeitung" → „abgeschlossen" ist einmalig terminal für diese Kontrollinstanz).
- Nach Abschluss keine Änderung an bereits erfassten Kontrollpositionen mehr möglich (Snapshot-Prinzip, Prompt 06/13) – Korrekturen nur durch neue Kontrolle oder durch separate Nachfüllung/Fehlbestand-Bearbeitung außerhalb der Kontrolle.

## 5. Kontrollnachweis
- Nach Abschluss automatisch erzeugtes, unveränderliches Dokument/Datensatz: wer, wann, Objekt, Ergebnis je Position (Snapshot), Liste ausgelöster Fehlbestände.
- Standard-Nachweis: Login-gebundene Zuordnung (wer eingeloggt war und die Aktion ausgeführt hat) gilt als Unterschriftsersatz, kein Zusatzschritt nötig.
- Optional/konfigurierbar (Nutzerentscheidung): **Touch-Unterschrift** (Zeichenfeld auf Tablet/Smartphone, als Bild mit Kontrolle verknüpft gespeichert) einschaltbar, falls von übergeordneter Stelle (z. B. Kreisverband, Behörde) gefordert. Kein Zwang für alle Standorte – als abschaltbare Option pro Organisation/Standort vorgesehen, nicht MVP-Pflicht, aber Datenmodell sollte optionales Signaturbild-Feld am Kontrollnachweis vorsehen (kein Schema-Umbau später nötig).
- Dient als digitaler Ersatz der bisherigen Papier-Unterschrift (Prompt 23 vertieft Migration).
- Einsehbar in Objekt-Historie (Prompt 13) und für Audit-Zwecke durch Verantwortliche/Administration.

## 6. Abgebrochene Kontrolle (Antwort auf offene Frage aus Prompt 02)
**Frage war:** Braucht abgebrochene Kontrolle eine Aufbewahrung als Teil-Historie, oder wird sie komplett verworfen?

**Entscheidung:** Abgebrochene Kontrolle wird NICHT komplett verworfen, aber auch nicht als gültiger Kontrollnachweis gezählt:
- Status „abgebrochen" bleibt als Datensatz erhalten (wer hat wann begonnen und abgebrochen), rein zur Nachvollziehbarkeit (z. B. „warum wurde Rucksack X seit 3 Tagen nicht fertig kontrolliert").
- Keine Ist-Werte aus der abgebrochenen Kontrolle werden auf das Objekt übernommen, kein Fehlbestand wird daraus ausgelöst.
- Objekt bleibt im Zustand vor Kontrollbeginn (bzw. „nicht kontrolliert seit Datum X"), zählt weiterhin als fällig für Kontrolle.
- Grund für Abbruch optional erfassbar (Freitext, z. B. „Einsatzalarmierung").

## Referenzen
Bezug: [[02_prozess_kontrolle]], [[03_fehlbestandsmanagement]], [[11_kontroll_ui]], [[13_historie_audit]]

---

# Prompt 17 – Mobile und Offline-Nutzung

Bezug: [[11_kontroll_ui]], Karte [[06_geraet_pc_mobil]]. Rein fachliches Konzept, keine Technologiewahl (folgt Prompt 19).

## 1. Ausgangslage
Rettungsdienst/KatS-Umfeld: wechselnde Fahrzeuge/Wachen, Netzabdeckung nicht durchgängig gesichert (Annahme aus Prompt 01). Kontrolle darf nicht an fehlendem Netz scheitern.

## 2. Bewertung: braucht V1 echtes Offline?
- Voll-Offline (mehrstündig, mit späterer Synchronisierung inkl. Konfliktlösung) ist komplex und erhöht MVP-Umfang erheblich (Grundprinzip: V1 klein halten).
- Praxisrelevanter Fall ist eher **kurzzeitiger Netzausfall/-lücke während einer laufenden Kontrolle**, nicht stundenlange Komplett-Offline-Nutzung ganzer Wachen.
- Entscheidung: V1 unterstützt **robuste Kurzzeit-Unterbrechung** (siehe 3.), aber KEIN vollwertiges Offline-Konzept mit Mehrgeräte-Konfliktlösung. Vollwertiges Offline = Roadmap (Prompt 24).

## 3. Konzept für V1 (Kurzzeit-Netzausfall)
- Eingaben in der Kontroll-UI (Prompt 11) werden lokal im Gerät zwischengespeichert, sobald eingegeben – nicht erst bei Übertragung an Server verworfen, wenn Verbindung kurz fehlt.
- Bei wiederhergestellter Verbindung: automatische Übertragung der zwischengespeicherten Eingaben, ohne dass Mitarbeiter erneut eintippen muss.
- Deutliche Statusanzeige in der UI: „nicht gespeichert/wird übertragen" vs. „gespeichert" je Position, damit Mitarbeiter erkennt, ob Eintrag schon serverseitig gesichert ist.
- Kontrolle kann nicht abgeschlossen werden (Prompt 16), solange nicht alle Positionen serverseitig bestätigt gespeichert sind – Abschluss-Button wartet/blockiert mit Hinweis, statt fälschlich „abgeschlossen" bei unvollständiger Übertragung zu melden.

## 4. Was V1 NICHT leisten muss
- Mehrstündige Offline-Nutzung ohne jede Verbindung.
- Bearbeitung derselben Kontrolle durch mehrere Geräte gleichzeitig mit Konfliktauflösung (ohnehin in Prompt 02 ausgeschlossen: eine Kontrolle = eine Person zu einem Zeitpunkt).
- Vollständige lokale Kopie des Materialstamms/aller Objekte für Offline-Betrieb.

## 5. Kennzeichnung nicht synchronisierter Daten
- Solange lokale Zwischenspeicherung nicht bestätigt an Server übertragen ist: eindeutiges visuelles Merkmal (z. B. Uhr-Symbol) an betroffenen Positionen/Kontrolle in der UI.
- Kein „stiller" Datenverlust: Verbindungsabbruch mitten in Eingabe darf Eingabe nicht kommentarlos verwerfen.

## 6. Roadmap-Erweiterung (Prompt 24)
- Echtes Offline-Modell (z. B. ganze Schicht ohne Netz arbeiten, spätere Synchronisierung mehrerer Geräte, Konfliktbehandlung bei parallelen Änderungen) als spätere Ausbaustufe, sobald reale Nutzung zeigt, ob Bedarf über Kurzzeit-Unterbrechung hinausgeht.
- Technisch möglicher Weg dahin (unverbindliche Notiz, Entscheidung erst Prompt 19): App (native oder PWA mit Service Worker) mit lokaler Datenhaltung auf dem Gerät, Synchronisierung bei wiederhergestellter Verbindung. Erfordert lokale Kopie relevanter Stammdaten (Materialstamm/Objekte des Nutzers) sowie Konfliktlösung bei paralleler Bearbeitung.

## 7. Erweiterung: Satelliten-Server bei längerem/vollständigem Internetausfall (Karte 13, Nutzerentscheidung)
Über die reine Kurzzeit-Unterbrechung (Punkt 3) hinaus wurde eine zweite, unabhängige Lösung für **längere oder vollständige Trennung vom Hauptserver** entschieden – relevant vor allem für KatS-Einsatzlagen (Zeltlager/Einsatzort ohne Internet) und Wachen mit dauerhaft schlechter Anbindung.

- **Ansatz:** Kein Client-seitiges Offline-Caching für diesen Fall, sondern ein **Satelliten-Server** – ein vollwertiger, kleiner Klon des Hauptservers (gleiche Software/API/Datenbank), der lokal am Einsatzort/an der Wache läuft.
- **Autark-Dauer:** bewusst nicht zeitlich begrenzt (kann Stunden bis mehrere Tage/unbestimmt sein) – kein System-Zwang zur Rücksynchronisation nach fester Frist.
- **Mehrbenutzerfähigkeit:** mehrere Mitarbeiter können gleichzeitig am selben Satelliten arbeiten, da dieser funktional wie ein eigener Hauptserver arbeitet (keine reine Cache-Lösung).
- **Konfliktvermeidung statt Konfliktlösung:** jedes Objekt ist während der Trennung exakt einem Server (Haupt- oder Satellit) fest zugeordnet und am jeweils anderen für Schreibzugriffe gesperrt. Dadurch entstehen strukturell keine Synchronisationskonflikte.
- Details, offene Punkte (Auslagerungs-Auslöser, Stammdaten-Vorbereitung des Satelliten, Hardware) siehe [[13_satelliten_server]].
- Abgrenzung zu Punkt 3: Kurzzeit-Pufferung im Browser bleibt für kurze Netzlücken während einer einzelnen Kontrolle; Satelliten-Server ist die Lösung für ganze Standorte/Einsatzorte über längere Zeiträume.

## Referenzen
Bezug: [[11_kontroll_ui]]
Arbeitskarten: [[06_geraet_pc_mobil]], [[13_satelliten_server]]

---

# Prompt 18 – MVP definieren

Bezug: alle Ergebnisse 01-17. Letzter fachlicher Prompt vor der Technikphase (19-22).

## 1. Ziel MVP
Papierlisten bei Rucksack-/Fahrzeugkontrollen möglichst weitgehend ersetzen, Grundprinzip: „Version 1 soll bewusst klein und praxistauglich bleiben."

## 2. Must-have (zwingend für V1)

| Bereich | Umfang |
|---|---|
| Materialstamm | Alle 3 Materialtypen (Standard, Ablaufdatum/Charge, Gerät-mit-SN), Basisfelder (Prompt 07) |
| Kategorien/Bereich | Bereichsoffenes Modell (Karte 11), aber V1 produktiv nur Rettungsdienst/KatS befüllt |
| Rucksäcke/Fahrzeuge (Objekte) | Anlegen, Duplizieren (Prompt 09), Code-Feld für QR/Barcode vorbereitet (nicht Scan-Funktion selbst) |
| Beladungsvorlagen | Erstellen, Versionieren, Zuweisen (Prompt 08) |
| Individuelle Anpassungen | Sollmengen-Override, Material hinzufügen/entfernen je Objekt (Prompt 10) |
| Digitale Kontrolle | Voller Workflow inkl. Statusmaschine, Abweichung, Nachfüllung während Kontrolle (Prompt 02, 11) |
| Automatische Fehlbestände | Vollständige Statusmaschine (Prompt 03) |
| Nachfüllung | Innerhalb und außerhalb der Kontrolle (Prompt 02) |
| Mindermengen-Ausnahmen | Genehmigung, Gültigkeit bis nächste Kontrolle, Historie (Prompt 04) |
| Rollen/Rechte | Alle 4 Rollen, Berechtigungsmatrix (Prompt 05) |
| Verantwortlichen-Dashboard | Kennzahlen, Listen, Filter (Prompt 12) |
| Historie/Audit | Vollständige Protokollierung aller Ereignistypen (Prompt 13) |
| Ablaufdaten | Warnzeiträume, 3 Zustände, Anzeige in Kontrolle+Dashboard (Prompt 14) |
| Kontrollabschluss | Regeln, Kontrollnachweis, abgebrochene Kontrolle (Prompt 16) |
| Authentifizierung | Echtes Login (Passwort/PIN), Karte 09 |
| Benachrichtigung | Dashboard + E-Mail bei neuem Fehlbestand, kein Push (Karte 05) |
| Bedienbarkeit | PC und Smartphone/Tablet, responsive statt getrennte Codebasen (Prompt 11) |
| Netzstabilität | Robuste Kurzzeit-Unterbrechung, keine Datenverluste bei kurzem Netzausfall (Prompt 17) |

## 3. Should-have (wünschenswert, aber verschiebbar ohne V1 zu gefährden)
- Feingranulare Zusatzrechte über Basismatrix hinaus (Prompt 05, Punkt 4) – Basismatrix reicht für V1.
- Standard-Warnzeiträume je Material individuell überschreibbar (Prompt 14) – globaler Standardwert reicht zunächst.
- Serien-Duplizieren mehrerer Objekte auf einmal (Prompt 09, Punkt 6) – Einzel-Duplizieren ist Pflicht, Serie ist Komfort.

## 4. Später/Roadmap (bewusst NICHT in V1, siehe jeweilige Prompts)
- QR-/Barcode-Scan-Funktion selbst (Karte 10) – nur Datenmodell-Vorbereitung in V1.
- Label-Design/Druck-Umsetzung (Karte 10) – Anforderung dokumentiert, Umsetzung Prompt 24.
- Automatische Eskalationslogik (Karte 12) – nur Datenbasis („entstanden am") in V1, Alter-Sortierung im Dashboard als einfache Vorstufe.
- Generische Ausweitung auf weitere Ressourcentypen über Rettungsdienst/KatS hinaus (Karte 11) – Modell ist offen, aber V1 befüllt nur einen Bereich.
- Lagerverwaltung mit eigenen Lagerorten/Mindestbeständen (Prompt 15).
- Vollwertiges Offline-Konzept mit Mehrgeräte-Sync/Konfliktlösung (Prompt 17).
- Satelliten-Server-Betrieb (Auslagerung/Synchronisation, Karte 13) – Datenmodell bereits vorbereitet (UUID-Primärschlüssel auf sync-relevanten Tabellen, Objekt-Zuordnungsfeld), tatsächlicher Betrieb/UI für Auslagern-Zurückholen ist Roadmap.
- Push-Benachrichtigungen (Karte 05).
- Medikamente/Betäubungsmittel-Sonderregeln, Mehrfach-Chargen (Prompt 14).
- Prüfungen/Prüfintervalle als eigener Vorgangstyp (vorbereitet in Prompt 07, nicht umgesetzt).
- Roadmap-Rollen: Lagerverantwortlicher, Prüforgan, Bereichsleitung, Read-only-Auditor (Prompt 05).

## 5. Abgrenzung zur bisherigen Papierlösung
V1 deckt den kompletten heutigen Papierprozess ab (Kontrolle, Abweichung, Nachfüllung, Unterschrift-Äquivalent = Kontrollnachweis) und fügt zusätzlich automatische Fehlbestandsverfolgung + Mindermengen-Historie hinzu, was auf Papier nicht bestand. Vertiefende Migrationsbetrachtung folgt in Prompt 23.

## Referenzen
Bezug: Ergebnisse 01-17, alle Arbeitskarten

---

# Prompt 19 – Technische Architektur

Bezug: alle fachlichen Ergebnisse 01-18. Erste Technikentscheidung, Basis für Prompt 20-22.

## 0. Techstack-Entscheidung (Nutzer)
- Backend: **Python, FastAPI**
- Datenbank: **PostgreSQL**
- Frontend: **Responsive Web-App/PWA** zuerst, native App (iOS/Android) als mögliche spätere Ergänzung
- Hosting: **normaler Linux-Server/VPS**, noch kein konkreter Anbieter — Architektur muss anbieterunabhängig/portabel sein; Docker dabei optional, keine Pflicht (siehe 9.)
- Deployment-Regel (Merkregel): ab hier nur Code/Konfigurationsdateien erzeugen, keine lokale Installation/Ausführung, Ziel ist externer Host.

## 1. Frontend
- Responsive PWA (Progressive Web App): eine Codebasis für PC, Tablet, Smartphone.
- PWA-Eigenschaften nutzen: Installierbarkeit auf Homescreen, Kamera-Zugriff für QR-/Barcode-Scan (Karte 10) via Browser-API (`getUserMedia`), Service Worker für Kurzzeit-Netzausfall-Pufferung (Prompt 17).
- Framework-Wahl offen für Umsetzungsphase (z. B. React/Vue), hier nur Architekturebene: Single-Page-App, spricht ausschließlich mit Backend über die API (Prompt 21).
- Native App (Roadmap) würde später dieselbe API nutzen, keine Backend-Änderung nötig — Grund, warum API-first-Ansatz (siehe 3.) architektonisch wichtig ist.

## 2. Backend
- Python, FastAPI (asynchron, automatische OpenAPI-Doku passt zu Prompt 21).
- Schichtenmodell: API-Layer (FastAPI Routen) → Service-/Domänenlogik-Layer (Statusmaschinen Kontrolle/Fehlbestand/Mindermenge, Prompt 02-04) → Datenzugriffs-Layer (ORM, z. B. SQLAlchemy) → PostgreSQL.
- Domänenlogik zentral gekapselt (z. B. eigenes Modul „Fehlbestand-Statusmaschine"), damit die zentrale Leitplanke „Mindermenge ≠ erledigt" (reihenfolge.md) an genau einer Stelle im Code durchgesetzt wird, nicht verstreut in mehreren Endpunkten.
- Authentifizierung (Karte 09): eigenes Auth-Modul, Passwort-Hashing (z. B. bcrypt/argon2), Session/Token-basiert (JWT oder Server-Session, Detail Prompt 21).

## 3. API-first-Prinzip
- Backend bietet ausschließlich eine dokumentierte REST-API (Prompt 21), kein serverseitiges HTML-Rendering.
- Vorteil: Web-PWA und später native App sind austauschbare Clients derselben API, kein Doppelaufwand bei Geschäftslogik.

## 4. Datenbank
- PostgreSQL, passend zum stark strukturierten, relationalen Datenmodell (Prompt 06): klare Entitäten, Fremdschlüssel, Historie/Audit-Anforderungen (Prompt 13) profitieren von ACID-Transaktionen.
- Migrationswerkzeug vorgesehen (z. B. Alembic) für versionierte Schemaänderungen, wichtig bei Vorlagen-Versionierung (Prompt 08) und künftigen Erweiterungen (Medikamente, Lager, Prüfungen).

## 5. Rollen/Rechte technisch
- Rollenmodell (Prompt 05) als Middleware/Dependency in FastAPI: jede Route deklariert benötigte Rolle(n)/Rechte, zentrale Prüfung statt verstreuter if-Abfragen.
- Zuständigkeits-Zuordnung (Karte 04) als Datenbank-gestützte Prüfung (n:m Benutzer↔Standort/Objekt), nicht hart codiert.

## 6. Historie/Auditierung technisch
- Eigene Tabelle(n) für Historieneinträge (Prompt 13), Append-only durch Anwendungslogik erzwungen (kein UPDATE/DELETE-Recht auf Historie-Tabellen für die Anwendung, nur INSERT).
- Serverseitige Zeitstempel (`now()` in der Datenbank oder Server-Uhrzeit im Backend, nie Client-Wert).

## 7. Benachrichtigungen
- E-Mail bei neuem Fehlbestand (Karte 05): asynchroner Versand (z. B. Hintergrundtask in FastAPI oder einfache Queue), damit Kontroll-Workflow nicht durch E-Mail-Versand blockiert wird.
- Kein Push in V1 (Karte 05) – kein zusätzlicher Dienst (Push-Server) nötig.

## 8. Offline-Unterstützung (Prompt 17)
- Kurzzeit-Pufferung im Frontend (Service Worker/lokaler Speicher im Browser), Übertragung an Backend bei wiederhergestellter Verbindung – rein clientseitiges Konzept, keine Backend-Sonderlogik nötig außer normalen, idempotenten API-Aufrufen.

## 9. Deployment-Architektur (anbieterunabhängig)
- Docker ist keine Priorität (Nutzerentscheidung) – Deployment stattdessen direkt auf dem Linux-Server/VPS: Backend als Python-Prozess (z. B. Uvicorn hinter systemd-Service), PostgreSQL als regulär installierter Dienst auf demselben oder separatem Server, Reverse-Proxy (z. B. nginx) für HTTPS/Routing.
- Statische PWA-Dateien vom Reverse-Proxy oder vom Backend selbst ausgeliefert – Detailentscheidung bei Umsetzung.
- Docker bleibt als spätere Option offen (z. B. falls Hosting-Umgebung es verlangt), ist aber kein Architekturzwang mehr.
- Wichtig (Merkregel): in dieser Konversation werden nur Code-/Konfigurationsdateien erzeugt, kein lokaler Serverstart, keine lokale DB-Installation – Zielsystem ist der externe Host.

## 10. Modularität für zukünftige Erweiterungen
- Neue Domänen (Medikamente, Lager, Prüfungen, weitere Ressourcentypen, Karte 11/Prompt 15/24) werden als zusätzliche Service-/Router-Module ergänzt, ohne Kernmodule (Kontrolle/Fehlbestand/Mindermenge) anzufassen — direkte Umsetzung des Designziels aus Prompt 06.

## 11. Hardware-Anforderungen

### Endgeräte (Mitarbeiter/Verantwortliche)
- Tablet/Smartphone mit Kamera (Barcode-Scan Code128 per Kamera, Prompt 17/Karte 10) – kein Spezialgerät, handelsübliches Gerät mit aktuellem Browser reicht (PWA-Ansatz).
- PC/Notebook für Dashboard/Administration – normaler Browser reicht, keine Installation nötig.

### Server (extern, Zielsystem)
- Linux-VPS, Größe skaliert mit Nutzerzahl; für V1/kleine-mittlere Organisation grobe Hausnummer 2 vCPU/4GB RAM, konkret erst bei Umsetzung/Lasttest zu verifizieren.
- PostgreSQL auf demselben oder separatem Server.
- Kein Docker-Zwang (siehe 9.), Backend läuft direkt als Python-Prozess (Uvicorn/systemd).

### Sonstiges
- Label-Drucker für QR-/Barcode-Labels (Karte 10, Roadmap Prompt 24) – Anforderung an Druckqualität/Kontrast dort bereits vermerkt.
- Kein USB-Handscanner nötig (Entscheidung Karte 10: Kamera-Scan statt Hardware-Scanner).

### Satelliten-Server (Karte 13, Erweiterung)
- Kleiner lokaler Rechner/Mini-PC vor Ort (Einsatzort/Wache), betreibt dieselbe Software wie der Hauptserver (identisches Backend+DB-Schema), keine reduzierte Sonderversion.
- Muss vor Trennung mit den relevanten Stammdaten (Materialstamm, Vorlagen der betroffenen Objekte) bestückt sein – Vorbereitung Teil der Auslagerung, Detail offen (siehe Karte 13).
- Anforderung eher gering (lokales Mehrbenutzer-Team, kein großer Lastfall) – z. B. Mini-PC/NUC-Klasse ausreichend, konkrete Spezifikation bei Umsetzung.

## 12. Mehrserver-Architektur: Hauptserver + Satelliten (Karte 13)
Ergänzung zur reinen Ein-Server-Architektur (Punkt 9): Neben dem zentralen Hauptserver können **Satelliten-Server** betrieben werden – vollwertige Klone derselben Anwendung, temporär vom Hauptserver getrennt einsetzbar (Details fachlich in [[17_mobile_offline]] Punkt 7, [[13_satelliten_server]]).

- **Objekt-Zuordnung als Kernmechanismus:** jedes Objekt trägt ein Feld „aktuell zuständiger Server" (Hauptserver oder eine bestimmte Satelliten-ID). Nur der zuständige Server nimmt Schreiboperationen für dieses Objekt an – der jeweils andere lehnt sie ab bzw. zeigt es nicht als bearbeitbar.
- **Eindeutige IDs von Anfang an:** damit am Satelliten neu erzeugte Datensätze (Kontrollen, Fehlbestände, Nachfüllungen, Historie) beim Zusammenführen nicht mit Hauptserver-IDs kollidieren, werden global eindeutige IDs verwendet (z. B. UUID statt fortlaufender Integer-Primärschlüssel für sync-relevante Tabellen) – Abweichung vom reinen `SERIAL`-Schema aus Prompt 20 für genau diese Tabellen, bei Umsetzung zu berücksichtigen.
- **Synchronisation:** bei wiederhergestellter Verbindung überträgt der Satellit neu entstandene Datensätze per Insert UND geänderte, bereits vor der Auslagerung existierende Zeilen (Objektpositionen, Fehlbestände, Mindermengen-Genehmigungen) per Upsert an den Hauptserver – kein reiner Append-Vorgang (Details/SQL siehe [[20_datenbank_schema]] Punkt 10). Kein Merge/Konfliktlösung nötig, da Objekt-Zuordnung Überschneidungen strukturell ausschließt. Danach wird die Objekt-Zuordnung wieder auf den Hauptserver zurückgesetzt.
- **Kein Zeitlimit:** Architektur darf keine Annahme über maximale Trennungsdauer treffen (Nutzervorgabe) – Synchronisationslogik muss auch nach Tagen/unbestimmter Zeit funktionieren.

## Referenzen
Bezug: alle Ergebnisse 01-18, [[13_satelliten_server]]

---

# Prompt 20 – Datenbankschema

Bezug: [[06_datenmodell]], [[07_materialstamm]], [[08_beladungsvorlagen]], [[09_duplizieren]], [[10_individuelle_beladung]], [[03_fehlbestandsmanagement]], [[04_mindermengen]], [[05_rollen_rechte]], [[13_historie_audit]]. Basis: PostgreSQL (Prompt 19).

Konkretes relationales Schema, abgeleitet aus dem fachlichen Datenmodell. Migrationstool (z. B. Alembic) wird bei Code-Umsetzung eingesetzt, hier reines Ziel-Schema.

**Update (Karte 13 – Satelliten-Server):** Tabellen, die auch an einem getrennten Satelliten-Server neue Zeilen erzeugen können (Kontrolle, Kontrollposition, Fehlbestand, Nachfüllung, Mindermengen-Genehmigung, Historie, **sowie Objektposition**), verwenden `UUID` statt `SERIAL` als Primärschlüssel, damit beim späteren Zusammenführen keine ID-Kollisionen zwischen Hauptserver und Satellit entstehen. Reine Stammdaten-Tabellen (Bereich, Kategorie, Standort, Objekttyp, Material, Vorlage, Benutzer, Objekt selbst) bleiben `SERIAL`, da sie nur zentral am Hauptserver gepflegt werden. `gen_random_uuid()` ist seit PostgreSQL 13 fest eingebaut, keine Extension nötig (bei älteren Versionen `CREATE EXTENSION pgcrypto`).

**Korrektur nach Gesamtprüfung (siehe Punkt 10/11):** Reines Batch-Insert reicht als Sync-Mechanismus NICHT aus, da am Satelliten auch bestehende `objektposition`-Zeilen per UPDATE verändert werden (Ist-Menge, Seriennummer, Ablaufdatum, Chargennummer). Details siehe Punkt 10.

## 1. Stammdaten

```sql
CREATE TABLE bereich (
    id              SERIAL PRIMARY KEY,
    name            TEXT NOT NULL UNIQUE,
    beschreibung    TEXT
);

CREATE TABLE kategorie (
    id                  SERIAL PRIMARY KEY,
    bereich_id          INTEGER NOT NULL REFERENCES bereich(id),
    name                TEXT NOT NULL,
    ueberkategorie_id   INTEGER REFERENCES kategorie(id),
    UNIQUE (bereich_id, name)
);

CREATE TABLE standort (
    id      SERIAL PRIMARY KEY,
    name    TEXT NOT NULL UNIQUE,
    adresse TEXT
);

CREATE TABLE objekttyp (
    id          SERIAL PRIMARY KEY,
    bereich_id  INTEGER NOT NULL REFERENCES bereich(id),
    kategorie_id INTEGER REFERENCES kategorie(id),
    name        TEXT NOT NULL,
    UNIQUE (bereich_id, name)
);

CREATE TYPE materialtyp AS ENUM ('standard', 'ablauf_charge', 'geraet_sn');

CREATE TABLE material (
    id              SERIAL PRIMARY KEY,
    name            TEXT NOT NULL,
    artikelnummer   TEXT,
    einheit         TEXT NOT NULL,
    materialtyp     materialtyp NOT NULL,
    kategorie_id    INTEGER REFERENCES kategorie(id),
    hersteller      TEXT,
    beschreibung    TEXT,
    code            TEXT UNIQUE,              -- QR/Barcode, Code128 (Karte 10)
    warnzeitraum_tage INTEGER,                 -- Standard-Vorwarnung bei Ablaufdatum (Prompt 14)
    aktiv           BOOLEAN NOT NULL DEFAULT TRUE
);
```

## 2. Vorlagen

```sql
CREATE TYPE vorlage_status AS ENUM ('aktiv', 'veraltet');

CREATE TABLE beladungsvorlage (
    id              SERIAL PRIMARY KEY,
    objekttyp_id    INTEGER NOT NULL REFERENCES objekttyp(id),
    name            TEXT NOT NULL,
    version         INTEGER NOT NULL,
    gueltig_ab      TIMESTAMPTZ NOT NULL DEFAULT now(),
    status          vorlage_status NOT NULL DEFAULT 'aktiv',
    UNIQUE (objekttyp_id, name, version)
);

CREATE TABLE vorlagenposition (
    id              SERIAL PRIMARY KEY,
    vorlage_id      INTEGER NOT NULL REFERENCES beladungsvorlage(id),
    material_id     INTEGER NOT NULL REFERENCES material(id),
    fach            TEXT,                     -- Kategorie/Fach innerhalb der Vorlage
    sollmenge       NUMERIC NOT NULL,
    UNIQUE (vorlage_id, material_id)
);
```

## 3. Objekte (Rucksäcke/Fahrzeuge/Ressourcen)

```sql
CREATE TYPE knoten_typ AS ENUM ('haupt', 'satellit');

CREATE TABLE systemknoten (
    id              SERIAL PRIMARY KEY,
    name            TEXT NOT NULL UNIQUE,       -- z. B. 'Hauptserver', 'Satellit Einsatzort Nord'
    typ             knoten_typ NOT NULL DEFAULT 'satellit'
);
-- genau eine Zeile mit typ='haupt' vorgesehen.

CREATE TYPE objekt_status AS ENUM ('aktiv', 'ausser_dienst');

CREATE TABLE objekt (
    id                      SERIAL PRIMARY KEY,
    code                    TEXT NOT NULL UNIQUE,      -- QR/Barcode, Code128 (Karte 10)
    name                    TEXT NOT NULL,
    objekttyp_id            INTEGER NOT NULL REFERENCES objekttyp(id),
    vorlage_id              INTEGER REFERENCES beladungsvorlage(id),
    standort_id             INTEGER NOT NULL REFERENCES standort(id),
    status                  objekt_status NOT NULL DEFAULT 'aktiv',
    zustaendiger_server_id  INTEGER NOT NULL REFERENCES systemknoten(id)  -- Karte 13: aktuell schreibberechtigter Knoten
);

-- objektposition ist UUID (nicht SERIAL): kann am Satelliten sowohl per UPDATE (Ist-Menge/SN/Ablauf)
-- als auch per INSERT (neues Material am Objekt hinzugefügt, Prompt 10) verändert werden.
CREATE TYPE objektposition_status AS ENUM ('aktiv', 'entfernt');

CREATE TABLE objektposition (
    id                  UUID PRIMARY KEY DEFAULT gen_random_uuid(),  -- Karte 13: sync-relevant
    objekt_id           INTEGER NOT NULL REFERENCES objekt(id),
    material_id         INTEGER NOT NULL REFERENCES material(id),
    sollmenge_override  NUMERIC,                    -- NULL = folgt Vorlage dynamisch
    ist_status          objektposition_status NOT NULL DEFAULT 'aktiv', -- korrigiert: Standard ist 'aktiv', nicht 'entfernt' (Prompt 10)
    istmenge            NUMERIC NOT NULL DEFAULT 0,
    seriennummer        TEXT,                       -- nur Materialtyp geraet_sn
    ablaufdatum         DATE,                        -- nur Materialtyp ablauf_charge
    chargennummer       TEXT,                        -- nur Materialtyp ablauf_charge
    zuletzt_geaendert_am TIMESTAMPTZ NOT NULL DEFAULT now(),  -- Basis für Delta-Sync (Punkt 10)
    UNIQUE (objekt_id, material_id)
);
```

## 4. Zuständigkeiten, Benutzer, Rollen

```sql
CREATE TABLE benutzer (
    id              SERIAL PRIMARY KEY,
    name            TEXT NOT NULL,
    login           TEXT NOT NULL UNIQUE,
    passwort_hash   TEXT NOT NULL,
    aktiv           BOOLEAN NOT NULL DEFAULT TRUE
);

CREATE TYPE rolle_typ AS ENUM ('mitarbeiter', 'materialverantwortlicher', 'leitungsverantwortlicher', 'administration');

CREATE TABLE benutzer_rolle (
    benutzer_id     INTEGER NOT NULL REFERENCES benutzer(id),
    rolle           rolle_typ NOT NULL,
    PRIMARY KEY (benutzer_id, rolle)
);

-- zustaendigkeit/kontrollverantwortung sind UUID: Administration könnte theoretisch auch am
-- Satelliten Zuordnungen anlegen/ändern (z. B. Kontrollverantwortung vor Ort neu vergeben).
CREATE TABLE zustaendigkeit (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    benutzer_id     INTEGER NOT NULL REFERENCES benutzer(id),
    standort_id     INTEGER REFERENCES standort(id),
    objekt_id       INTEGER REFERENCES objekt(id),
    CHECK (standort_id IS NOT NULL OR objekt_id IS NOT NULL)
);

CREATE TABLE kontrollverantwortung (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    objekt_id       INTEGER NOT NULL REFERENCES objekt(id),
    benutzer_id     INTEGER REFERENCES benutzer(id),   -- Einzelperson, ODER
    gruppe          TEXT                                -- Gruppe (frei benannt, V1-Vereinfachung ohne eigene Gruppen-Entität; echte Gruppen-Verwaltung Roadmap), Karte 01
);
```

## 5. Kontrolle

```sql
CREATE TYPE kontroll_status AS ENUM ('nicht_gestartet', 'in_bearbeitung', 'abgeschlossen', 'abgebrochen');

CREATE TABLE kontrolle (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),  -- Karte 13: sync-relevant
    erzeugt_von_server_id INTEGER NOT NULL REFERENCES systemknoten(id),
    objekt_id       INTEGER NOT NULL REFERENCES objekt(id),
    benutzer_id     INTEGER NOT NULL REFERENCES benutzer(id),
    status          kontroll_status NOT NULL DEFAULT 'in_bearbeitung',
    gestartet_am    TIMESTAMPTZ NOT NULL DEFAULT now(),
    beendet_am      TIMESTAMPTZ,
    abbruch_grund   TEXT,
    signatur        BYTEA  -- optionales Touch-Signaturbild am Kontrollnachweis (Prompt 16), nullable, standardmäßig ungenutzt
);

CREATE TABLE kontrollposition (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),  -- Karte 13: sync-relevant
    kontrolle_id    UUID NOT NULL REFERENCES kontrolle(id),
    material_id     INTEGER NOT NULL REFERENCES material(id),
    sollmenge_snapshot  NUMERIC NOT NULL,
    istmenge_erfasst    NUMERIC NOT NULL,
    abweichung          BOOLEAN NOT NULL
);
```

## 6. Fehlbestand, Nachfüllung, Mindermenge

```sql
CREATE TYPE fehlbestand_status AS ENUM ('offen', 'in_bearbeitung', 'nachgefuellt_teilweise', 'erledigt');

CREATE TABLE fehlbestand (
    id                  UUID PRIMARY KEY DEFAULT gen_random_uuid(),  -- Karte 13: sync-relevant
    erzeugt_von_server_id INTEGER NOT NULL REFERENCES systemknoten(id),
    objekt_id           INTEGER NOT NULL REFERENCES objekt(id),
    material_id         INTEGER NOT NULL REFERENCES material(id),
    standort_id         INTEGER NOT NULL REFERENCES standort(id),
    sollmenge           NUMERIC NOT NULL,
    istmenge             NUMERIC NOT NULL,
    fehlmenge            NUMERIC NOT NULL,
    entstanden_am         TIMESTAMPTZ NOT NULL DEFAULT now(),  -- Basis Eskalation, Karte 12
    festgestellt_von      INTEGER NOT NULL REFERENCES benutzer(id),
    kontrolle_id          UUID REFERENCES kontrolle(id),
    ursache               TEXT,
    verantwortlicher_id   INTEGER REFERENCES benutzer(id),
    status                fehlbestand_status NOT NULL DEFAULT 'offen',
    erledigt_am           TIMESTAMPTZ
);

CREATE TABLE nachfuellung (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),  -- Karte 13: sync-relevant
    fehlbestand_id  UUID REFERENCES fehlbestand(id),
    objekt_id       INTEGER NOT NULL REFERENCES objekt(id),
    material_id     INTEGER NOT NULL REFERENCES material(id),
    menge           NUMERIC NOT NULL,
    benutzer_id     INTEGER NOT NULL REFERENCES benutzer(id),
    zeitpunkt       TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TYPE mindermenge_status AS ENUM ('aktiv', 'abgelaufen', 'beendet_durch_erledigung');

CREATE TABLE mindermengen_genehmigung (
    id                  UUID PRIMARY KEY DEFAULT gen_random_uuid(),  -- Karte 13: sync-relevant
    fehlbestand_id      UUID NOT NULL REFERENCES fehlbestand(id),
    genehmigt_von        INTEGER NOT NULL REFERENCES benutzer(id),
    begruendung          TEXT NOT NULL,
    genehmigt_am          TIMESTAMPTZ NOT NULL DEFAULT now(),
    ausloesende_kontrolle_id UUID NOT NULL REFERENCES kontrolle(id),
    status                mindermenge_status NOT NULL DEFAULT 'aktiv',
    beendet_am            TIMESTAMPTZ,
    beendende_kontrolle_id UUID REFERENCES kontrolle(id)
);
```

## 7. Historie/Audit

```sql
CREATE TABLE historie (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),  -- Karte 13: sync-relevant
    erzeugt_von_server_id INTEGER NOT NULL REFERENCES systemknoten(id),
    zeitpunkt       TIMESTAMPTZ NOT NULL DEFAULT now(),
    benutzer_id     INTEGER REFERENCES benutzer(id),   -- NULL bei System-Ereignissen
    ereignistyp     TEXT NOT NULL,                     -- z. B. 'fehlbestand_entstanden', 'mindermenge_genehmigt', ...
    entitaet_typ    TEXT NOT NULL,                      -- z. B. 'fehlbestand', 'objektposition', 'vorlage'
    entitaet_id     TEXT NOT NULL,                       -- TEXT statt INTEGER: referenzierte Entität kann INTEGER- oder UUID-ID haben
    alter_wert      JSONB,
    neuer_wert      JSONB,
    begruendung     TEXT
);
-- Append-only: Anwendungs-DB-Rolle erhält nur INSERT-Recht auf diese Tabelle, kein UPDATE/DELETE.
```

## 8. Indizes (Auswahl, wichtigste Zugriffspfade)

```sql
CREATE INDEX idx_fehlbestand_status ON fehlbestand(status);
CREATE INDEX idx_fehlbestand_objekt ON fehlbestand(objekt_id);
CREATE INDEX idx_fehlbestand_entstanden ON fehlbestand(entstanden_am);  -- für Alter-Sortierung, Prompt 12
CREATE INDEX idx_objektposition_objekt ON objektposition(objekt_id);
CREATE INDEX idx_historie_entitaet ON historie(entitaet_typ, entitaet_id);
CREATE INDEX idx_zustaendigkeit_benutzer ON zustaendigkeit(benutzer_id);
```

## 9. Wichtige Constraints/Prinzipien
- Kein Fremdschlüssel-Löschen mit CASCADE auf historie-relevante Tabellen (fehlbestand, kontrolle, historie) – Löschung von Stammdaten (Material/Objekt) erfolgt nur über `aktiv = false`, nie physisches DELETE, damit Historie referenzierbar bleibt (Prompt 13).
- `mindermengen_genehmigung` referenziert Fehlbestand 1:0..n, in der Praxis max. 1 mit Status `aktiv` gleichzeitig – wird auf Anwendungsebene erzwungen (kein reiner DB-Constraint, da Historie mehrerer vergangener Genehmigungen erhalten bleiben muss).
- `objektposition.sollmenge_override IS NULL` bedeutet: Sollmenge wird zur Laufzeit aus aktueller `vorlagenposition` der referenzierten Vorlage berechnet (Prompt 10).

## 10. Satelliten-Server – Objekt-Sperre und Synchronisation (Karte 13)
- `objekt.zustaendiger_server_id` bestimmt, welcher Server (Haupt oder ein bestimmter Satellit) aktuell Schreibrechte für dieses Objekt hat. Anwendungslogik (nicht reiner DB-Constraint) prüft vor jedem Schreibzugriff auf `kontrolle`, `fehlbestand`, `nachfuellung`, `mindermengen_genehmigung`, `objektposition`, ob der ausführende Server mit `objekt.zustaendiger_server_id` übereinstimmt.
- „Objekt auslagern" (Platzhalter `:satelliten_id`/`:objekt_id` durch konkrete Werte ersetzen):
  ```sql
  UPDATE objekt SET zustaendiger_server_id = :satelliten_id WHERE id = :objekt_id;
  ```
  Ab diesem Zeitpunkt lehnt der Hauptserver Schreibzugriffe auf dieses Objekt ab.
- **Synchronisation ist NICHT reines Batch-Insert** (Korrektur nach Gesamtprüfung): drei unterschiedliche Sync-Fälle müssen unterschieden werden:
  1. **Neue Zeilen** (Kontrolle, Kontrollposition, Nachfüllung, Historie, neu hinzugefügte Objektposition, neue Zuständigkeits-/Kontrollverantwortungs-Zuordnung, falls am Satelliten durch Administration vergeben): einfacher Insert am Hauptserver, da UUID bereits eindeutig vergeben – keine Kollision möglich.
  2. **Geänderte bestehende Zeilen** (`objektposition`: Ist-Menge, Seriennummer, Ablaufdatum, Chargennummer – vom Hauptserver vor Auslagerung an den Satelliten kopiert, dort per UPDATE verändert): werden beim Sync per **Upsert** übertragen (`INSERT ... ON CONFLICT (id) DO UPDATE`), nicht als reiner Insert. `zuletzt_geaendert_am` dient als Erkennungsmerkmal, welche Zeilen sich am Satelliten geändert haben.
  3. **Fehlbestand und Mindermengen-Genehmigung, die bereits vor der Auslagerung existierten** (offener Fehlbestand am Objekt, evtl. aktive Genehmigung) und am Satelliten weiterbearbeitet werden (Nachfüllung, neue Genehmigung, Statuswechsel auf `erledigt`): ebenfalls **Upsert**, nicht reiner Insert – dieselben UUIDs, `status`/`istmenge`/`erledigt_am` bzw. `status`/`beendet_am` können sich am Satelliten ändern.
  - Da ein Objekt während der Auslagerung exklusiv einem Server zugeordnet ist (siehe Objekt-Sperre), gibt es keine gleichzeitige Änderung derselben Zeile an zwei Orten – Upsert ist damit konfliktfrei, kein Merge nötig.
  - Reihenfolge beim Sync: zuerst Objektpositionen-Upsert, danach Fehlbestand/Mindermengen-Genehmigung-Upsert, danach neue Kontrollen/Nachfüllungen/Historie per Insert (referenzielle Integrität).
- Nach vollständiger Übertragung:
  ```sql
  UPDATE objekt SET zustaendiger_server_id = :hauptserver_id WHERE id = :objekt_id;
  ```
- **Einschränkung für Struktur­änderungen am Satelliten:** Anlegen komplett neuer Vorlagen/Materialstamm-Einträge bleibt dem Hauptserver vorbehalten (diese Tabellen sind SERIAL, nicht sync-fähig). Am Satelliten sind nur Änderungen an bereits vorhandenen `objektposition`-Zeilen, das Hinzufügen individueller Zusatzpositionen (Prompt 10, eigene UUID-Zeile) sowie neue Zuständigkeits-/Kontrollverantwortungs-Einträge möglich.
- Benötigte PostgreSQL-Version: ≥ 13 für eingebautes `gen_random_uuid()` (siehe oben).
- **Vorab-Bestückung des Satelliten (Klärung L2):** neben Materialstamm, Vorlagen und den betroffenen Objekten/Objektpositionen müssen auch **offene Fehlbestände und aktive Mindermengen-Genehmigungen** der ausgelagerten Objekte in die Satelliten-Kopie übernommen werden – sonst kann am Satelliten weder nachgefüllt noch genehmigt werden, ohne einen Duplikat-Fehlbestand zu erzeugen. Details der Bestückungslogik bleiben offen (siehe [[13_satelliten_server]]).

## Referenzen
Bezug: [[06_datenmodell]], [[19_technische_architektur]], [[13_satelliten_server]]

---

# Prompt 21 – API-Konzept

Bezug: [[19_technische_architektur]], [[20_datenbank_schema]], [[05_rollen_rechte]]. Basis: FastAPI, REST, API-first (Web-PWA + spätere native App als Clients).

## 1. Grundprinzipien
- REST, JSON, versioniert unter `/api/v1/...`.
- Auth: Login liefert Token (JWT), jede weitere Anfrage mit Header `Authorization: Bearer` gefolgt vom Token-String.
- Jede Route deklariert benötigte Rolle(n) (Prompt 05) über FastAPI-Dependency, zentral geprüft.
- Fehlerformat einheitlich: `{ "error": { "code": "...", "message": "..." } }`, HTTP-Status passend (400/401/403/404/409/422).
- Historieneinträge (Prompt 13) werden serverseitig automatisch bei jeder relevanten Statusänderung erzeugt, nicht über eigene API-Aufrufe des Clients.

## 2. Auth

| Methode | Pfad | Rolle | Zweck |
|---|---|---|---|
| POST | /api/v1/auth/login | - | Login (Login-Name+Passwort/PIN), liefert Token |
| POST | /api/v1/auth/logout | alle | Token invalidieren |
| GET | /api/v1/auth/me | alle | eigene Benutzerdaten+Rollen |

## 3. Stammdaten (Ressourcen)

| Methode | Pfad | Rolle | Zweck |
|---|---|---|---|
| GET/POST | /api/v1/bereiche | Administration (POST), alle (GET) | Bereiche |
| GET/POST | /api/v1/kategorien | Administration (POST), alle (GET) | Kategorien |
| GET/POST | /api/v1/standorte | Administration (POST), alle (GET) | Standorte |
| GET/POST | /api/v1/objekttypen | Administration (POST), alle (GET) | Objekttypen |
| GET/POST/PATCH | /api/v1/materialien | Administration | Materialstamm (Prompt 07) |
| GET | /api/v1/materialien/{id} | alle | Detail |

## 4. Beladungsvorlagen

| Methode | Pfad | Rolle | Zweck |
|---|---|---|---|
| GET | /api/v1/vorlagen | alle | Liste, filterbar nach Objekttyp/Status |
| POST | /api/v1/vorlagen | Administration, Materialverantwortlicher | neue Vorlage/Version anlegen (Prompt 08) |
| GET | /api/v1/vorlagen/{id} | alle | Detail inkl. Positionen |
| POST | /api/v1/vorlagen/{id}/positionen | Administration, Materialverantwortlicher | Position hinzufügen |
| PATCH | /api/v1/vorlagen/{id}/positionen/{pos_id} | Administration, Materialverantwortlicher | Sollmenge ändern (führt zu neuer Version, Prompt 08) |
| GET | /api/v1/vorlagen/{id}/diff-vorschlaege | Materialverantwortlicher, Leitung | Diff zu bestehenden Objekten (Prompt 08 Punkt 6) |

## 5. Objekte

| Methode | Pfad | Rolle | Zweck |
|---|---|---|---|
| GET | /api/v1/objekte | alle | Liste, Filter Standort/Typ, Suche nach Code |
| GET | /api/v1/objekte/{id} | alle | Detail inkl. Objektpositionen |
| GET | /api/v1/objekte/code/{code} | alle | Lookup per QR/Barcode-Code (Karte 10) — Route muss in FastAPI VOR `/objekte/{id}` registriert werden, sonst greift die generische ID-Route zuerst |
| POST | /api/v1/objekte | Administration | neu anlegen |
| POST | /api/v1/objekte/{id}/duplizieren | Administration | Duplizieren (Prompt 09), Body: neuer Name/Code/Standort |
| PATCH | /api/v1/objekte/{id}/positionen/{pos_id} | Materialverantwortlicher | Sollmengen-Override/Material hinzufügen/entfernen (Prompt 10) |

## 6. Kontrolle

| Methode | Pfad | Rolle | Zweck |
|---|---|---|---|
| POST | /api/v1/objekte/{id}/kontrollen | Mitarbeiter+ | Kontrolle starten (Prompt 02) |
| GET | /api/v1/kontrollen/{id} | Mitarbeiter+ | Status/Fortschritt |
| PUT | /api/v1/kontrollen/{id}/positionen/{material_id} | Mitarbeiter+ | Ist-Menge erfassen/bestätigen (idempotent, wichtig für Prompt 17 Wiederholung nach Netzausfall) |
| POST | /api/v1/kontrollen/{id}/abschliessen | Mitarbeiter+ | Abschluss (Prompt 16), löst Kontrollnachweis aus |
| POST | /api/v1/kontrollen/{id}/abbrechen | Mitarbeiter+ | Abbruch (Prompt 16), optional Grund im Body |

## 7. Fehlbestand / Nachfüllung / Mindermenge

| Methode | Pfad | Rolle | Zweck |
|---|---|---|---|
| GET | /api/v1/fehlbestaende | Materialverantwortlicher, Leitung, Administration | Liste, Filter Standort/Objekt/Material/Alter/Status (Prompt 12) |
| GET | /api/v1/fehlbestaende/{id} | s.o. + Mitarbeiter (eigene) | Detail inkl. Historie |
| POST | /api/v1/fehlbestaende/{id}/nachfuellungen | Mitarbeiter+ | Nachfüllung erfassen (Prompt 02), aktualisiert Fehlmenge/Status automatisch |
| POST | /api/v1/fehlbestaende/{id}/mindermenge | Materialverantwortlicher, Leitung | Mindermenge genehmigen, Body: Begründung (Prompt 04) |
| DELETE | /api/v1/fehlbestaende/{id}/mindermenge | - | NICHT vorgesehen – Genehmigung läuft nur automatisch ab (Prompt 04), kein manuelles Löschen |

## 7a. Verwaltung (Administration) – ergänzt nach Gesamtprüfung
Fehlte bisher, obwohl in der Berechtigungsmatrix (Prompt 05) gefordert.

| Methode | Pfad | Rolle | Zweck |
|---|---|---|---|
| GET/POST | /api/v1/benutzer | Administration | Benutzer verwalten |
| PATCH | /api/v1/benutzer/{id} | Administration | Rollen zuweisen, aktiv/inaktiv setzen |
| GET/POST | /api/v1/zustaendigkeiten | Administration | Zuständigkeits-Zuordnung (Karte 04) |
| DELETE | /api/v1/zustaendigkeiten/{id} | Administration | Zuordnung entfernen |
| GET/POST | /api/v1/kontrollverantwortung | Administration, Materialverantwortlicher (eigener Bereich) | Kontrollverantwortung zuweisen (Karte 01) |
| GET/POST | /api/v1/systemknoten | Administration | Satelliten-Server anlegen/verwalten (Karte 13) |
| POST | /api/v1/objekte/{id}/auslagern | Administration | Objekt einem Satelliten zuordnen |
| POST | /api/v1/objekte/{id}/zurueckholen | Administration | Rücksynchronisation anstoßen, Zuordnung zurück auf Hauptserver |

## 8. Dashboard/Historie

| Methode | Pfad | Rolle | Zweck |
|---|---|---|---|
| GET | /api/v1/dashboard/kennzahlen | Materialverantwortlicher, Leitung, Administration | Kennzahlen (Prompt 12) |
| GET | /api/v1/dashboard/ablaufdaten | s.o. | bevorstehende Ablaufdaten (Prompt 14) |
| GET | /api/v1/historie | s.o. (gefiltert nach Zuständigkeit) | globale Audit-Suche (Prompt 13) |
| GET | /api/v1/objekte/{id}/historie | alle (eigene Objekte) | objektbezogene Historie |

## 9. Validierung/Fehlerfälle (Beispiele)
- Mindermenge genehmigen ohne Begründung → 422, Feld `begruendung` Pflicht (Prompt 04).
- Mindermenge genehmigen durch Mitarbeiter-Rolle → 403 (Prompt 05).
- Nachfüllung mit Menge, die Ist über Soll hebt → 422 oder Warnung (fachlich zu entscheiden bei Umsetzung, aus Prompt 02 nicht explizit als Fehler definiert – konservativ: erlauben, aber als „Überbestand“-Info kennzeichnen, kein Fehlbestand).
- Kontrolle abschließen, obwohl Positionen unbearbeitet → 409, Liste fehlender Positionen im Response.
- Doppeltes Duplizieren mit gleichem Code → 409 (Code muss eindeutig sein, Prompt 09).

## 10. Auditierung auf API-Ebene
- Jede schreibende Aktion protokolliert automatisch Server-Zeitstempel + Benutzer-ID aus Token (nie Client-Wert) in `historie` (Prompt 13/20).

## Referenzen
Bezug: [[19_technische_architektur]], [[20_datenbank_schema]], [[05_rollen_rechte]]

---

# Prompt 22 – Testfälle

Bezug: alle Ergebnisse 01-21. Letzter Prompt der Technikphase (19-22).

Format je Testfall: Ausgangssituation → Aktion → erwartetes Ergebnis → Fehlerfall (falls zutreffend).

## 1. Vollständige Kontrolle (Normalfall)
- **Ausgang:** Objekt „Rucksack Handball 17", alle Positionen Soll=Ist im Bestand.
- **Aktion:** Mitarbeiter startet Kontrolle, bestätigt jede Position „passt", schließt ab.
- **Erwartet:** Kontrolle Status „abgeschlossen", keine Fehlbestände erzeugt, Kontrollnachweis mit allen Positionen gespeichert (Prompt 16).
- **Fehlerfall:** Abschluss-Versuch mit unbestätigten Positionen → 409, Liste fehlender Positionen (Prompt 21).

## 2. Fehlbestand entsteht (keine Nachfüllung möglich)
- **Ausgang:** Soll 10, Ist im Lager tatsächlich 8.
- **Aktion:** Mitarbeiter trägt Ist=8 ein, wählt „nicht verfügbar".
- **Erwartet:** Fehlbestand-Vorgang Status „offen", Fehlmenge=2, `entstanden_am` gesetzt, Kontrolle kann trotzdem abgeschlossen werden (Prompt 03/16).

## 3. Nachfüllung während der Kontrolle (Sofort-Nachfüllung)
- **Ausgang:** Wie Test 2, aber Ersatz im Lager vorhanden.
- **Aktion:** Mitarbeiter wählt „ja, sofort nachgefüllt".
- **Erwartet:** Fehlbestand entsteht UND wird im selben Moment auf „erledigt" gesetzt, zwei Historieneinträge mit Zeitstempel (Karte 07, Prompt 02).

## 4. Nachfüllung nach der Kontrolle
- **Ausgang:** Offener Fehlbestand aus vorheriger, bereits abgeschlossener Kontrolle.
- **Aktion:** Verantwortlicher/Mitarbeiter erfasst Nachfüllung außerhalb einer laufenden Kontrolle, Menge = volle Fehlmenge.
- **Erwartet:** Fehlbestand Status „erledigt", `erledigt_am` gesetzt, Ist-Menge im Objekt aktualisiert (Prompt 02/03).

## 5. Teilnachfüllung
- **Ausgang:** Fehlmenge 5.
- **Aktion:** Nachfüllung von 2 erfasst.
- **Erwartet:** Fehlbestand bleibt „offen" (bzw. „nachgefuellt_teilweise"), Fehlmenge neu 3, Historieneintrag zeigt Teilschritt (Prompt 03).

## 6. Nicht vorhandenes Lagergut (Sonderfall)
- **Ausgang:** Fehlbestand offen, keine Verfügbarkeit im Lager absehbar.
- **Aktion:** Kein Eingriff über längeren Zeitraum.
- **Erwartet:** Fehlbestand bleibt „offen", zählt in Dashboard-Alter-Filter, kein automatischer Statuswechsel ohne echte Nachfüllung/Genehmigung (Prompt 03/12).

## 7. Genehmigte Mindermenge
- **Ausgang:** Offener Fehlbestand, Soll 10, Ist 8.
- **Aktion:** Materialverantwortlicher genehmigt mit Begründung.
- **Erwartet:** Status-Vermerk „Mindermenge genehmigt", Ist-Menge bleibt 8, Fehlbestand bleibt fachlich offen, zählt weiterhin als offen in Kennzahlen (Prompt 04/12).
- **Fehlerfall:** Mitarbeiter versucht Genehmigung → 403 (Prompt 05/21). Genehmigung ohne Begründung → 422.

## 8. Ablauf einer Ausnahme
- **Ausgang:** Aktive Mindermengen-Genehmigung aus Test 7.
- **Aktion:** Nächste Kontrolle desselben Objekts wird gestartet, Abweichung besteht weiterhin.
- **Erwartet:** Genehmigung automatisch Status „abgelaufen", Position erneut regulär als offene Abweichung bewertet, neue Genehmigung nötig falls gewünscht (Prompt 04, Karte 08).

## 9. Ablauf einer Ausnahme, Abweichung ist bei nächster Kontrolle behoben
- **Ausgang:** Wie Test 8, aber zwischenzeitlich vollständig nachgefüllt.
- **Aktion:** Nächste Kontrolle bestätigt Ist=Soll.
- **Erwartet:** Fehlbestand UND Genehmigung gemeinsam auf „erledigt"/„beendet_durch_erledigung" (Prompt 04, Punkt 4).

## 10. Ablaufdatum
- **Ausgang:** Material mit Ablaufdatum in 5 Tagen, Warnzeitraum 30 Tage.
- **Aktion:** Kontrolle öffnet Position.
- **Erwartet:** Status „bald ablaufend" angezeigt, auch wenn Menge korrekt (Prompt 14). Nach Austausch: neues Ablaufdatum erfasst, keine Fehlbestand-Erzeugung, sofern Ersatz vorhanden.
- **Fehlerfall:** kein Ersatz vorhanden → normale Abweichung/Fehlbestand (Prompt 14, Punkt 4).

## 11. Duplizieren eines Rucksacks
- **Ausgang:** Bestehendes Objekt mit Ist-Bestand, offenen Fehlbeständen, Historie.
- **Aktion:** Administration dupliziert mit neuem Namen/Code/Standort.
- **Erwartet:** Neues Objekt mit identischer Struktur/Sollmengen, Ist-Menge=0/„nicht kontrolliert", keine offenen Fehlbestände, keine Historie übernommen, neuer eindeutiger Code (Prompt 09).
- **Fehlerfall:** Code-Kollision → 409 (Prompt 21).

## 12. Individuelle Abweichung von Vorlage
- **Ausgang:** Vorlage definiert 10 BZ-Messtreifen.
- **Aktion:** Materialverantwortlicher setzt Override auf 15 für ein Objekt.
- **Erwartet:** Objektposition zeigt Sollmenge effektiv=15, Vorlage selbst unverändert, andere Objekte auf derselben Vorlage bleiben bei 10 (Prompt 10).

## 13. Änderung einer Vorlage (mit individuell abweichenden Objekten)
- **Ausgang:** Vorlage wird geändert (neue Version, Sollmenge einer Position erhöht), ein Objekt hat für diese Position bereits einen Override.
- **Aktion:** Vorlagenänderung gespeichert.
- **Erwartet:** Objekte OHNE Override übernehmen neuen Wert automatisch (dynamische Referenz), Objekt MIT Override bleibt unverändert, bis Override manuell aufgehoben wird (Prompt 08/10).

## 14. Rollenrechte (Berechtigungsmatrix)
- **Ausgang:** Vier Rollen aus Prompt 05.
- **Aktion:** Jede Rolle versucht jede kritische Aktion (Genehmigen, Sollmenge ändern, Zuständigkeit zuordnen, Benutzer verwalten).
- **Erwartet:** Nur laut Matrix erlaubte Aktionen gelingen (200er), alle anderen 403 (Prompt 05/21).

## 15. Historie/Nachvollziehbarkeit (Beispiel-Kette)
- **Ausgang:** Wie Prompt 13, Beispiel-Kette (Soll 10, Ist 8 → Fehlbestand → Genehmigung → Nachfüllung → erledigt).
- **Aktion:** Vollständige Kette durchlaufen.
- **Erwartet:** Jeder Schritt als eigener, chronologisch korrekter Historieneintrag mit korrektem wer/wann/alt/neu, alle auf denselben Fehlbestand referenziert (Prompt 13).

## 16. Kurzzeit-Netzausfall während Kontrolle
- **Ausgang:** Kontrolle „in Bearbeitung", Verbindung bricht nach Eingabe einer Position ab.
- **Aktion:** Eingabe wird clientseitig gepuffert, Verbindung kommt zurück.
- **Erwartet:** Position wird automatisch nachträglich übertragen (idempotenter PUT, Prompt 21), keine doppelte Erfassung, keine Datenverlust-Anzeige mehr nach erfolgreicher Übertragung (Prompt 17).

## 17. Abgebrochene Kontrolle
- **Ausgang:** Kontrolle „in Bearbeitung", einige Positionen erfasst.
- **Aktion:** Mitarbeiter bricht ab (z. B. Einsatzalarmierung).
- **Erwartet:** Kontrolle Status „abgebrochen", KEINE Ist-Werte auf Objekt übernommen, kein Fehlbestand ausgelöst, Objekt bleibt „nicht kontrolliert seit vorherigem Datum" (Prompt 16).

## Referenzen
Bezug: Ergebnisse 01-21

---

# Prompt 23 – Papierlisten ablösen

Bezug: [[01_anforderungsanalyse]], [[02_prozess_kontrolle]], [[11_kontroll_ui]], [[16_kontrollabschluss]], [[14_ablaufdaten]].

## 1. Ausgangssituation (heutiger Papierprozess)
Mitarbeiter nimmt Rucksack, kontrolliert Papierliste, zählt Material, tauscht abgelaufenes Material aus, trägt Abweichungen ein, unterschreibt, Papier wird abgeheftet.

## 2. Digitale Entsprechung je Papierschritt

| Papierprozess | Digitale Entsprechung | Prompt |
|---|---|---|
| Papierliste je Rucksack (Fach → Artikel → Sollmenge) | Beladungsvorlage + Objektpositionen, angezeigt in Kontroll-UI | 08, 11 |
| Material zählen, Häkchen setzen | Ein-Tap-Bestätigung „passt" je Position | 11 |
| Abgelaufenes Material austauschen, handschriftlich vermerken | Digitale Ablauf-Warnung + Austauscherfassung (neues Ablaufdatum) | 14 |
| Abweichung handschriftlich eintragen | Ist-Menge-Eingabe, automatische Fehlmengenberechnung, automatischer Fehlbestand-Vorgang | 02, 03 |
| Unterschrift als Nachweis „ich habe kontrolliert" | Digitaler Kontrollnachweis: Benutzer (Login-gebunden), Zeitstempel, vollständiges Ergebnis je Position, unveränderlich gespeichert | 16, 13 |
| Papier abheften/archivieren | Historie/Audit-Datenbank, dauerhaft und durchsuchbar, kein Papierarchiv nötig | 13, 20 |
| Verantwortlicher blättert Papierlisten durch, um Mängel zu finden | Verantwortlichen-Dashboard mit automatischer Fehlbestand-Übersicht | 12 |
| Mündliche/telefonische Meldung an Verantwortlichen bei Fehlbestand | Automatische E-Mail-Benachrichtigung + Dashboard-Eintrag | Karte 05 |

## 3. Prozesse mit weiterhin denkbarem Papier-/Druck-Fallback
- **Totalausfall IT/Netz am Standort:** Kein digitaler Zugriff möglich → Papier-Notfallliste als Rückfallebene sinnvoll (gedruckte Kopie der aktuellen Vorlage, ohne Live-Ist-Werte), bewusst nicht Teil des Systems selbst, sondern organisatorische Fallback-Maßnahme außerhalb der Software.
- **Label/QR-Code-Druck:** physisches Label am Objekt (Karte 10) ist selbst „Papier"/Aufkleber – bleibt bestehen, ist aber Träger des digitalen Codes, kein Rückschritt.
- **Rechtliche/organisatorische Nachweispflicht mit Unterschrift auf Papier**, falls von übergeordneter Stelle (z. B. Kreisverband, Behörde) zwingend gefordert – zu klären außerhalb dieses Systems, ggf. digitaler Kontrollnachweis als PDF exportierbar/ausdruckbar als Ergänzung (Roadmap, Prompt 24).

## 4. Nachvollziehbarkeit im Vergleich zu Papier
- Digital deutlich besser: durchsuchbar, keine Verlustgefahr, automatische Fehlbestandsverfolgung (auf Papier oft „vergessen", expliziter Grundsatz aus `prompts.md`: „Fehlbestände dürfen nicht vergessen werden").
- Risiko: Akzeptanz/Schulung der Mitarbeiter beim Umstieg – organisatorische Begleitung nötig, kein technisches Thema dieses Konzepts.

## 5. Organisatorische Anforderungen beim Umstieg
- Übergangsphase denkbar: digitale Erfassung parallel zu Papier, bis Vertrauen in System besteht (organisatorische Entscheidung, kein Systemzwang).
- Alle bestehenden Excel-Listen (Handball Rucksack, Rettungsrucksack, Rucksack PAX SEG) dienen als Datenbasis für initiale Beladungsvorlagen (Prompt 08) und Materialstamm (Prompt 07) bei Einführung.

## Referenzen
Bezug: [[01_anforderungsanalyse]], [[02_prozess_kontrolle]], [[11_kontroll_ui]], [[16_kontrollabschluss]], [[14_ablaufdaten]]