Files

T

patrickandClaude Sonnet 5 dbc30356f6 Sprintplan MVP ergänzen (Sprints 0-8, E1-E6 fixierte Entscheidungen, Abnahmekriterien)

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L85hmKbvX7Cqkq47KnQhFt

2026-09-03 22:26:06 +02:00

153 KiB

Raw Permalink Blame History

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

Automatisch zusammengestellt aus allen Arbeitskarten und Prompt-Ergebnissen, Stand 2026-09-03.

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	entschieden	Prompt 05
02	Rechte: Stammdaten vs. Ist-Menge	entschieden	Prompt 05
03	Sollmengen-Recht Materialverantwortlicher	entschieden	Prompt 04, 05
04	Organisationsstruktur / Zuständigkeiten	entschieden, Detail offen	Prompt 05, 06
05	Benachrichtigungen	entschieden	Prompt 12
06	Geräteanforderung PC/Mobil	entschieden	Prompt 11, 17
07	Sofort-Nachfüllung während Kontrolle	entschieden	Prompt 02, 03
08	Mindermengen-Gültigkeit	entschieden	Prompt 04
09	Authentifizierung	entschieden	Prompt 05, 19
10	QR-Code / Barcode	Roadmap, Datenmodell-Vorbereitung nötig	Prompt 06, 24
11	Systemumfang: generisches Ressourcenmanagement	entschieden, grundlegend	Prompt 06, 07
12	Eskalation offener Fehlbestände	Roadmap, Datenmodell-Vorbereitung nötig	Prompt 03, 24
13	Hauptserver mit Satelliten-Servern	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.

Geklärt (vormals offen)

Zuweisung erzwingt KEINE Pflichtkontrolle – reine Empfehlung/Sichtbarkeit/Priorisierung. Schutz vor Doppelarbeit übernimmt die Objekt-Sperre nach Scan/Kontrollstart (Prompt 02.8), nicht die Zuweisung.

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

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

Geklärt (vormals offen)

Ein Objekt kann mehrere Verantwortliche gleichzeitig haben (n:m, kein Limit).
Zuständigkeit vererbt sich vom Standort automatisch auf alle Objekte an diesem Standort. Zusätzliche objektspezifische Zuordnung (zustaendigkeit.objekt_id gesetzt) ist eine feinere Ergänzung obendrauf, kein Ersatz – Auswertelogik: ein Benutzer ist für ein Objekt zuständig, wenn ENTWEDER eine Standort-Zeile für dessen Standort ODER eine Objekt-Zeile für das Objekt selbst existiert (Vereinigung, keine Überschreibung).

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

KatS-Einsatzlage (Zeltlager/Einsatzort ohne Internet) – Satellit läuft autark vor Ort.
Wache mit dauerhaft schlechter Anbindung – Satellit als Regelbetrieb, nicht nur Notfall.
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 & Querschnittsdokumente

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?~~ Geklärt: reine Sichtbarkeits-/Priorisierungshilfe, kein Zwang. Schutzmechanismus gegen Doppelarbeit ist die Objekt-Sperre (Prompt 02.8), nicht die Zuweisung.
~~Kann ein Objekt mehrere gleichzeitig zuständige Verantwortliche haben, und vererbt sich Zuständigkeit vom Standort automatisch auf alle dortigen Objekte (Karte 04)?~~ Geklärt: ja, mehrere Verantwortliche gleichzeitig möglich (n:m). Standort-Zuordnung vererbt sich automatisch auf alle Objekte an diesem Standort; zusätzliche objektspezifische Zuordnung ist eine feinere Ergänzung, kein Widerspruch.
Wie granular soll der Objekttyp/Kategorie-Baum sein (Karte 11) — flache Liste (Rettungsdienst, Betreuung, Technik, ...) oder hierarchisch mit Unterkategorien? (weiterhin offen, unkritisch für Schema — Kategorie hat bereits optionale Selbstreferenz für Hierarchie, Prompt 20)
~~Welche Kontrollintervalle/Fristen sind organisatorisch vorgesehen (täglich, wöchentlich, nach Einsatz)?~~ Geklärt: V1 hat KEINE eigene Kontrollintervall-/Fälligkeitslogik. Einzige System-getriebene Aufforderung zur Kontrolle ist der bereits bestehende Ablaufdatum-Mechanismus (Prompt 14: bald ablaufend/abgelaufen). Reguläre Kontrollintervalle bleiben rein organisatorisch (Dienstplan/Anweisung), vom System nur dokumentiert (Zeitpunkt letzte Kontrolle sichtbar), nicht berechnet oder erzwungen.

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)

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

3. Ablauf bei Abweichung (Ist < Soll)

Mitarbeiter trägt Ist-Menge ein, System berechnet Fehlmenge automatisch (Soll − Ist).
System legt automatisch einen Fehlbestand-Vorgang an, Status „offen“, mit Zeitstempel „entstanden am“ (Vorbereitung Eskalation, Karte 12).
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).
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

Offener Fehlbestand existiert (Prompt 03, Status „offen“ oder „in Bearbeitung“).
Berechtigte Rolle öffnet Fehlbestand, wählt „Mindermenge genehmigen“.
Pflichtfeld: Begründung (Freitext), z. B. „Lieferengpass Hersteller, Ersatz bestellt, Lieferung erwartet KW38“.
System setzt Vermerk „Mindermenge genehmigt“, verknüpft mit der aktuellen Kontrolle des Objekts.
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:

Materialstamm – was für Material gibt es grundsätzlich (Prompt 07).
Beladungsvorlage – welches Material soll in welcher Menge in einem Objekttyp sein (Prompt 08).
Konkretes Objekt – ein tatsächlicher Rucksack/Fahrzeug/Ressource mit eigener ID.
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

Standard-Verbrauchsmaterial – einfache Zähl-/Mengenware ohne Ablauf/SN. Beispiele: Rettungsdecken, Kompressen, Verbandspäckchen.
Material mit Ablaufdatum/Charge – Verbrauchsmaterial mit Haltbarkeit. Beispiele: Infusionssysteme, Medikamente (später), sterile Sets.
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

Verantwortlicher/Administration wählt Quelle: bestehendes Objekt ODER Beladungsvorlage direkt.
System zeigt Vorschau: welche Positionen werden übernommen (Struktur/Soll), Hinweis „Ist-Bestände und Historie werden NICHT übernommen".
Pflichteingabe für neues Objekt: neuer Name/Bezeichnung, Standort, neuer Code (QR/Barcode, Karte 10).
Optional: Zuständigkeits-Zuordnung direkt mit anlegen oder später durch Administration.
Neues Objekt wird angelegt mit Status „neu, noch nicht kontrolliert" – erste Kontrolle erforderlich, um echten Ist-Bestand zu erfassen.
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

Sollmengen-Override – Material aus Vorlage vorhanden, aber andere Sollmenge (Beispiel: Vorlage 10 BZ-Messtreifen, Fahrzeug braucht 15).
Zusätzliches Material – Position, die in der Vorlage nicht existiert, nur bei diesem Objekt.
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.

7. Klarstellung: keine Kontrollintervall-Fälligkeit in V1

Nutzerentscheidung (Prompt 01, offene Frage geklärt): V1 berechnet KEINE eigene Kontrollfälligkeit/„überfällige Kontrolle"-Kennzahl. Die einzige system-getriebene Aufforderung zur (Wieder-)Kontrolle ist der bestehende Ablaufdaten-Mechanismus (Punkt 2/„bevorstehende Ablaufdaten", Prompt 14). Reguläre Kontrollrhythmen bleiben rein organisatorisch, vom System nur dokumentiert (letzter Kontrollzeitpunkt je Objekt sichtbar), nicht berechnet oder als Kennzahl geführt.

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.
- V1-Vereinfachung (Vermerk): Datenmodell hat bereits das Feld kontrolle.signatur (Prompt 20) – eine eigene Einstellungs-Entität „Signatur pro Standort/Organisation ein/aus" existiert in V1 NICHT. Für V1 reicht: Feld ist da und wird nur befüllt, wenn UI eine Unterschrift anbietet; echte Ein/Aus-Konfigurierbarkeit pro Standort ist Roadmap (Prompt 24).
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") – rein informativ, keine automatische Fälligkeits-/Überfällig-Logik in V1 (siehe Prompt 12.7).
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

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

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)

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

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

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

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

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)

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):
```
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:

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 → entschieden: erlauben (kein 422), Response kennzeichnet den Fall als „Überbestand"-Info (Prompt 02.4), löst keinen Fehlbestand aus.
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

Sprint-Plan MVP (V1)

Bezug: 18_version_1, 22_testkonzept, testphasen.md (Phase 0–5; Phase S = Satellit, Roadmap), reihenfolge.md, Karten 01_rollen_zuordnung, 04_organisationsstruktur, 13_satelliten_server.

Grundprinzip: fachliche Abhängigkeitskette bauen, Domänenlogik vor UI, Leitplanke „Mindermenge ≠ erledigt" früh beweisen. Kein Feature ohne Test (CI-Gate greift ab Sprint 0). Satelliten-Betrieb ist NICHT Teil dieses Plans (eigene Phase S in testphasen.md).

0. Fixierte Entscheidungen (bindend)

#	Entscheidung	Konsequenz
E1	Keine Kontrollfälligkeit/-intervalle in V1. Einzige zeitgetriebene Sichtbarkeit: Ablaufdaten (Prompt 14). Kontrolle wird organisatorisch angewiesen, System dokumentiert nur Durchführung (letzter Kontrollzeitpunkt sichtbar).	Kein Fälligkeitsfeld im Schema, keine „überfällig"-Kennzahl. Dashboard-Zeitkennzahl bleibt nur „bevorstehende Ablaufdaten" (Prompt 12.7). Fälligkeitslogik = Roadmap-Kandidat (verwandt mit Eskalation, Karte 12).
E2	Zuständigkeit vererbt sich vom Standort auf alle dortigen Objekte. Standort-Zuordnung impliziert alle Objekte am Standort; objektspezifische Zeilen (`zustaendigkeit.objekt_id`) sind feinere Ergänzung, kein Ersatz.	Auswertelogik: Benutzer ist für Objekt zuständig, wenn ENTWEDER Standort-Zeile für dessen Standort ODER Objekt-Zeile existiert (Vereinigung, keine Überschreibung). Mehrere Verantwortliche je Objekt möglich (n:m). (Karte 04)
E3	Kontrollverantwortung ist nur Sichtbarkeit/Priorisierung, keine Pflichtkontrolle. Zugewiesene Objekte werden im UI hervorgehoben, schließen andere Mitarbeiter nicht aus.	Screen 1 (Prompt 11): zugewiesene Objekte zuerst/hervorgehoben, darunter „alle Objekte". Keine Sperrlogik durch Zuweisung – Schutz vor Doppelarbeit ist die Objekt-Sperre (Prompt 02.8). (Karte 01)
E4	Nachfüllung über Soll hinaus ist erlaubt, wird als Überbestand protokolliert (informativ), erzeugt keinen Fehlbestand und keinen Fehler (Prompt 02.4 / 21.9).	API: kein 422, Response kennzeichnet den Fall als „Überbestand"-Info.
E5	Touch-Signatur: Datenmodell-Feld vorhanden (`kontrolle.signatur`, Prompt 20), UI dafür Roadmap. V1 nutzt Login-gebundenen Kontrollnachweis als Unterschriftsersatz (Prompt 16.5).	Keine Einstellungs-Entität „Signatur pro Standort ein/aus" in V1; Konfigurierbarkeit erst mit Signatur-UI (Roadmap).
E6	V1-Seed: genau ein `systemknoten`-Datensatz (typ='haupt') per Alembic-Migration angelegt; Backend liest dessen ID aus Config (z. B. Umgebungsvariable `SYSTEMKNOTEN_ID`) und setzt sie bei jedem Insert in `erzeugt_von_server_id`/`zustaendiger_server_id`.	Verhindert NOT NULL-Verletzungen ab dem allerersten Datensatz (Details/Begründung: `testphasen.md` Phase 0); Satelliten kommen später als weitere Zeilen dazu.

1. Sprint-Übersicht

Sprint	Inhalt	Fachbasis	Tests
0 Fundament	FastAPI-Skeleton, SQLAlchemy/Alembic, PostgreSQL, CI (pytest + Coverage-Gate 50 %); Auth (JWT, Passwort-Hashing bcrypt/argon2) + Rollen-Dependency; Schema-Grundgerüst inkl. `systemknoten` + UUID-Tabellen (Karte-13-Vorbereitung, kein späterer Umbau); Seed Hauptserver (E6)	Prompt 19/20, Karte 09	Testphase 0 komplett
1 Stammdaten	Bereich, Kategorie, Standort, Objekttyp, Material (3 Typen); Benutzer/Rollen/Zuständigkeiten inkl. Vererbungslogik (E2); Admin-API 7a (Prompt 21)	Prompt 06/07, Karte 04	Testphase 2 für diese Endpunkte; parametrisierter Rollenmatrix-Test angelegt
2 Vorlagen & Objekte	Beladungsvorlagen + Versionierung, Objekte anlegen/duplizieren, Objektpositionen + Override-Logik	Prompt 08/09/10	U8, U9, U10
3 Kontroll-Kern	Kontroll-Statusmaschine, Objekt-Sperre + Übernahme (protokolliert), Abschluss/Abbruch, Kontrollnachweis, automatische Fehlbestand-Erzeugung; Mitarbeiter-UI Screens 1–6 inkl. Zuweisungs-Hervorhebung (E3)	Prompt 02/11/16	U1, U11, U12; Sperr-/409-Tests
4 Fehlbestand & Nachfüllung	Fehlbestand-Statusmaschine komplett, Nachfüllung sofort/später/teilweise, Überbestand-Regel (E4)	Prompt 03	U3, U4, U5, U13
5 Mindermengen & Historie	Genehmigung + automatischer Ablauf bei nächster Kontrolle; Historie-Vervollständigung (alle Ereignistypen), Audit-Suche/-UI	Prompt 04/13	U2, U6, U7, U14 – Leitplanke final bewiesen; Testphase 3 startet (S7–S9, S15)
6 Dashboard, Ablaufdaten, E-Mail	Kennzahlen mit Aggregationsregel (offen + in_bearbeitung + nachgefuellt_teilweise = offen), Filter, Ablauf-Warnungen (einzige Zeit-Sicht, E1), asynchroner E-Mail-Versand bei neuem Fehlbestand	Prompt 12/14, Karte 05	Testphase 3 weiter
7 Offline-Härtung & E2E	Service Worker / lokale Pufferung, Abschluss blockiert bei ungesendeten Positionen, Idempotenz, Statusanzeige	Prompt 17	Testphase 3 komplett (S1–S17), Testphase 4 (Playwright, Viewports, Praktiker-Session)
8 Pilotvorbereitung	Excel-Import der 3 Ist-Listen, Test-Deployment auf VPS, Parallelbetrieb Papier, Go/No-Go	Prompt 23	Testphase 5

Nicht im Plan (bewusst, Prompt 18 Abschnitt 4): QR-Scan-Funktion, Eskalation, Lagerverwaltung, Push, Satelliten-Betrieb (Phase S).

2. Regeln übergreifend

Historie ab Sprint 1 mitbauen: jeder schreibende Endpunkt protokolliert ab seiner Entstehung (wer/wann/alt→neu); Sprint 5 komplettiert nur Ereignistypen und Audit-UI. Keine nachträgliche Nachrüstung.
Testphasen 1+2 laufen IN den Sprints (kein Merge ohne Test, CI-Gate), Phasen 3–5 sind die Endphasen.
Kein UI vor Domänenlogik – erste nennenswerte UI in Sprint 3, weil dort erstmals ein Mitarbeiter-Flow existiert (direkte Umsetzung der reihenfolge.md-Philosophie).

3. Größenordnung

9 Sprints × 2 Wochen ≈ 4–5 Monate bei Vollzeit-ähnlicher Kapazität; als Nebenbei-Projekt entsprechend länger. Engstellen: Sprint 3 (größter UI-Block), Sprint 7 (Offline-Verhalten technisch am fummeligsten).

4. Abnahmekriterien je Sprint

S0: CI grün, Login funktioniert, Rollen-Dependency greift auf einem Test-Endpunkt, Seed systemknoten vorhanden und vom Backend verwendet (E6).
S1: Alle Stammdaten-Endpunkte + Admin-API per Tests abgedeckt; Vererbungslogik (E2) durch Test bewiesen (Standort-Zuordnung → Sicht enthält alle Objekte des Standorts, Vereinigung mit Objekt-Zeilen).
S2: Vorlagen-Versionierung + Duplizieren + Override durch U8/U9/U10 bewiesen.
S3: Komplette Kontrolle digital durchspielbar inkl. Sperre/Übernahme/Abbrechen; Fehlbestand entsteht automatisch bei Ist < Soll.
S4: Fehlbestand-Lebenszyklus komplett (U3/U4/U5/U13); Überbestand protokolliert ohne Fehlbestand (E4).
S5: U2/U6/U7/U14 grün; Historie-Kette S15 vollständig referenziert und chronologisch korrekt.
S6: Dashboard-Kennzahlen stimmen mit Aggregationsregel überein; E-Mail kommt bei neuem Fehlbestand an (Test-Mailserver).
S7: Netzausfall-Szenario S16 grün, keine Datenverluste; Praktiker-Session ohne kritische UX-Befunde.
S8: Echtdaten importiert, Parallelbetrieb ohne fachliche Diskrepanz → Go/No-Go-Entscheidung.

5. Excel-Import (Sprint 8)

Das detaillierte Spalten-Mapping, der Import-Ablauf und die bekannten Lücken (Einheiten-Nachpflege, Artikelnummer-Abgleich, Deployment-Regel) sind in testphasen.md, Abschnitt „Excel-Import-Mapping" ausgearbeitet und dort verbindlich – hier bewusst kein Duplikat, um Divergenz zu vermeiden.

Kurzfassung für die Sprint-Planung: einmaliges idempotentes CLI-Import-Skript (Abgleich über Artikelnummer) erzeugt Bereich/Kategorie, je Excel-Datei einen Objekttyp + Beladungsvorlage Version 1 mit Vorlagenpositionen; konkrete Objekte werden danach über die UI aus den Vorlagen angelegt (Prompt 09-Flow), erste Kontrolle erfasst den Ist-Bestand (= Übergang Papier → digital, Prompt 23). Review-Schritt für die Materialtyp-Zuordnung (standard/geraet_sn; ablauf_charge kommt in den drei Quell-Listen nicht vor) ist Pflicht.

Referenzen

Bezug: 18_version_1, 22_testkonzept, 19_technische_architektur, 20_datenbank_schema, 21_api, Karten 01_rollen_zuordnung, 04_organisationsstruktur, 05_benachrichtigungen, 09_authentifizierung, 13_satelliten_server, testphasen.md

Testphasen – MABEA V1

Bezug: 22_testkonzept, 18_version_1, 02_prozess_kontrolle, 03_fehlbestandsmanagement, 04_mindermengen, 05_rollen_rechte, 17_mobile_offline, 21_api.

Grundprinzip: Tests werden phasenweise aufgebaut, parallel zur Implementierung – nicht als Block am Ende. Jede Phase hat Einstiegs- und Abnahmekriterien. Der Satelliten-Betrieb (Karte 13) ist bewusst nicht Teil der V1-Testphasen, sondern eigene spätere Phase S (Roadmap).

Phase 0 – Testinfrastruktur (vor erstem Feature-Code)

Ziel: Gerüst steht, bevor Logik entsteht – verhindert „Tests schreiben wir später".

pytest + pytest-asyncio + httpx (AsyncClient für FastAPI) im Projekt
pytest-cov mit Regressions-Gate: --cov-fail-under=50 als Startwert in pytest.ini (Erfahrungswert: lieber niedrig starten und hochschrauben als gar kein Gate)
Separate Test-Datenbank (eigene PostgreSQL-Datenbank, Schema via Alembic-Migrationen aufgesetzt, nie gegen Dev-/Produktiv-DB)
Test-Fixtures: frische DB pro Testklasse (Transaction-Rollback oder Drop/Create), Standard-Stammdaten-Set (1 Bereich, 2 Standorte, 3 Objekttypen, ~10 Materialien aller 3 Typen, 1 Vorlage mit Positionen, 2 Objekte, 4 Benutzer = 1 je Rolle)
CI-Job (Gitea Actions): install → migrate → pytest → Coverage-Report; Blocker bei Rot
Seed-Datensatz systemknoten: objekt.zustaendiger_server_id, kontrolle.erzeugt_von_server_id, fehlbestand.erzeugt_von_server_id, historie.erzeugt_von_server_id sind NOT NULL (Prompt 20) – V1 braucht daher zwingend einen Seed-Datensatz systemknoten (typ='haupt') VOR dem ersten Datensatz jeder Art, plus eine Konfigurations-Referenz im Backend (z. B. Umgebungsvariable/Settings-Wert SYSTEMKNOTEN_ID), die der Anwendungscode bei jedem Insert einsetzt. Ohne diesen Seed schlägt der allererste Insert fehl – gehört in die Migrations-/Setup-Reihenfolge von Phase 0, nicht erst bei Satelliten-Umsetzung (Phase S) relevant.

Abnahmekriterium: pytest läuft grün (auch wenn erst 1 Smoke-Test existiert), CI schlägt bei Testfehler fehl.

Phase 1 – Domänenlogik (Unit-Tests, keine API, keine UI)

Ziel: Die fachlichen Leitplanken sind bewiesen, bevor irgendein Endpoint existiert. Reine Python-Tests gegen den Service-Layer (Prompt 19 Punkt 2), DB über Fixtures.

Kritischste Regeln zuerst (aus reihenfolge.md und Prompt 03/04):

#	Test	Herkunft
U1	Fehlbestand entsteht automatisch bei Ist < Soll	Prompt 02.3
U2	Mindermengen-Genehmigung ändert NIEMALS Ist-Menge und setzt Fehlbestand NIEMALS auf erledigt	Leitplanke, Prompt 04.1
U3	Fehlbestand → erledigt AUSSCHLIESSLICH wenn Ist = Soll (nie manuell)	Prompt 03.3
U4	Sofort-Nachfüllung in Kontrolle: Fehlbestand entsteht + wird erledigt, 2 Historieneinträge	Karte 07
U5	Teilnachfüllung: Status `nachgefuellt_teilweise`, Fehlmenge reduziert, zählt weiter als offen	Prompt 03/12
U6	Genehmigung läuft bei nächster Kontrolle des Objekts automatisch ab	Karte 08, Prompt 04.4
U7	Genehmigung + Behebung vor nächster Kontrolle → beides gemeinsam beendet	Prompt 04.4
U8	Soll-Auflösung: Override auf Objektposition schlägt Vorlagenwert; Vorlagenänderung wirkt nur auf Positionen ohne Override	Prompt 10
U9	Duplizieren: Struktur/Soll ja, Ist/SN/Chargen/Fehlbestände/Historie nein, neuer Code	Prompt 09
U10	Vorlagenänderung erzeugt neue Version, alte Version bleibt lesbar (Snapshot-Historie)	Prompt 08
U11	Kontrolle abschließen mit unbestätigten Positionen → Fehler	Prompt 16.1
U12	Abgebrochene Kontrolle: keine Ist-Übernahme, kein Fehlbestand, Objekt bleibt unkontrolliert	Prompt 16.6
U13	Überbestand (Ist > Soll): protokolliert, aber KEIN Fehlbestand	Prompt 02.4
U14	Historie ist append-only: jeder fachliche Schritt erzeugt Eintrag mit wer/wann/alt→neu	Prompt 13

Einstiegskriterium: Phase 0 fertig. Abnahmekriterium: U1–U14 grün, Coverage Service-Layer ≥ 80 % (Domänenlogik ist der sicherheitskritische Kern).

Phase 2 – API-Integrationstests (HTTP gegen Test-DB)

Ziel: Jeder Endpoint aus Prompt 21 verhält sich spezifikationsgemäß, inkl. Rollenmatrix und Fehlerfälle.

Auth: Login ok/falsch (401), Token abgelaufen, auth/me liefert korrekte Rollen
Rollenmatrix (Prompt 05): parametrisierter Test – jede Rolle × jede kritische Aktion → erwarteter Status (200er/403). Das ist EIN Test mit Tabelle, deckt Matrix vollständig ab
Fehlerfälle aus Prompt 21.9: Genehmigung ohne Begründung → 422; Genehmigung durch Mitarbeiter → 403; Abschluss mit offenen Positionen → 409 + Liste; Code-Duplikat beim Anlegen/Duplizieren → 409
Idempotenz PUT Kontrollposition: derselbe PUT zweimal gesendet → identischer Endzustand, kein doppelter Fehlbestand (Vorbereitung Prompt 17)
Zuständigkeitsfilter (Karte 04): Verantwortlicher sieht nur Fehlbestände seines Bereichs, Administration alles
Objekt-Sperre (Prompt 02.8): Kontrolle auf Objekt A aktiv → zweiter Benutzer bekommt „wird kontrolliert von …", Übernahme erzeugt Historieneintrag; parallele Kontrollen auf Objekt B bleiben möglich
Admin-API (7a): Benutzer/Zuständigkeiten/Kontrollverantwortung anlegen, ändern, löschen

Einstiegskriterium: Phase 1 grün. Abnahmekriterium: alle Endpunkte aus Prompt 21 durch Tests abgedeckt, Gesamt-Coverage ≥ 50 % (Gate greift).

Phase 3 – Prozess-Szenarien (E2E über API, komplette fachliche Ketten)

Ziel: Die 17 Testfälle aus 22_testkonzept als durchspielbare Szenarien – hier wird bewiesen, dass die Einzelteile zusammenwirken.

S1–S17 = exakt die Testfälle 1–17 aus Prompt 22 (Normalfall, Fehlbestand, Sofort-Nachfüllung, Nachfüllung später, Teilnachfüllung, Dauer-offen, Genehmigung, Ablauf Genehmigung ×2, Ablaufdatum, Duplizieren, Override, Vorlagenänderung mit Override, Rollenmatrix, Historie-Kette, Kurzzeit-Netzausfall, Abbruch)
Besonderheit S15 (Historie-Kette): komplette Kette aus Prompt 13.3 durchlaufen und Reihenfolge + Referenzen aller Historieneinträge prüfen
Besonderheit S16 (Netzausfall): clientseitig simuliert – PUT zweimal absetzen bzw. verzögert, Server-Verhalten muss identisch sein

Einstiegskriterium: Phase 2 grün. Abnahmekriterium: S1–S17 grün, zweimal reproduzierbar (kein Flaky).

Phase 4 – Frontend/PWA-Tests

Ziel: Die Einsatzumfeld-Anforderungen (Prompt 11, 17) sind bewiesen.

Kurzzeit-Netzausfall: Eingabe wird lokal gepuffert, nach Reconnect automatisch übertragen, Abschluss blockiert solange ungesendete Positionen existieren (Prompt 17.3) – Browser-Test mit Netzwerk-Throttling/Offline-Toggle (Playwright)
Responsivität: Kernscreens (Screen 1–6) auf PC + Tablet + Smartphone-Viewport bedienbar, Touch-Ziele groß genug
Fortschrittsanzeige + Gerätewechsel: Kontrolle auf Gerät 1 begonnen, auf Gerät 2 fortgesetzt (login-/objektgebunden, Karte 06)
Statusfarben/Markierungen: genehmigte Mindermenge, individuelle Abweichung, Ablaufdatum-Warnung sichtbar unterscheidbar
Manuelle Explorations-Session: 2–3 Praktiker aus dem Rettungsdienst klicken ohne Anleitung durch eine Kontrolle – Beobachtung dokumentieren (UX-Fallen)

Einstiegskriterium: Phase 3 grün, PWA bedienbar auf Test-Deployment. Abnahmekriterium: Netzausfall-Test grün, keine kritischen UX-Befunde offen.

Phase 5 – Pilotphase mit Echtdaten (organisatorisch, kein Code-Test)

Ziel: Realitätsabgleich, bevor Papier abgeschaltet wird.

Testdaten aus den echten Excel-Listen (Handball Rucksack.xlsx, Rettungsrucksack.xlsx, Rucksack PAX SEG.xlsx im Repo) als initiale Vorlagen/Materialstamm importieren (Mapping siehe Abschnitt „Excel-Import-Mapping" unten)
1–2 Wochen Parallelbetrieb: Kontrolle digital UND Papier wie bisher, danach Abgleich (findet das System alles, was Papier fand?)
Dedizierte Übungskontrollen mit vorher verabredeten Abweichungen („versteckte Fehlmenge") – prüft, ob Mitarbeiter den digitalen Weg korrekt durchlaufen
E-Mail-Benachrichtigung (Karte 05) mit realem Mailserver verifizieren
Feedback-Runde → kleinteilige UI-Nachjustierung

Einstiegskriterium: Phase 4 grün, Echtdaten importiert, Test-Deployment erreichbar. Abnahmekriterium (Go/No-Go für V1): Parallelbetrieb ohne fachliche Diskrepanz, keine Datenverluste, Akzeptanz bei Pilotnutzern vorhanden.

Excel-Import-Mapping (Detail zu Phase 5)

Grundlage: die drei bestehenden Listen im Repo (Handball Rucksack.xlsx, Rettungsrucksack.xlsx, Rucksack PAX SEG.xlsx), Struktur laut Ausgangsanalyse (Prompt 01): Fach-Überschriftzeile, darunter Zeilen mit Artikel/Menge/Artikelnummer, teils Seriennummer-Spalte.

Mapping-Tabelle

Excel-Spalte/Struktur	Ziel im Datenmodell (Prompt 06/20)	Hinweis
Datei selbst (z. B. „Handball Rucksack")	`objekttyp.name` + `beladungsvorlage.name` (z. B. „Rucksack Handball Standard")	Ein Import-Lauf pro Datei erzeugt einen Objekttyp + eine Vorlage Version 1
Fach-Überschriftzeile (z. B. „Fach 1")	`vorlagenposition.fach`	Freitext übernehmen wie in Excel geschrieben, keine Normalisierung nötig
Artikel-Spalte	`material.name` (neu anlegen, falls Name noch nicht im Materialstamm existiert)	Abgleich über Artikelnummer, nicht über Namensgleichheit (Tippfehler-Gefahr)
Artikelnummer-Spalte	`material.artikelnummer`	Primärer Abgleichsschlüssel beim Import: gleiche Artikelnummer über mehrere Listen hinweg → derselbe Materialstamm-Eintrag, nicht dubliziert anlegen
Menge-Spalte	`vorlagenposition.sollmenge`	Numerisch parsen, Fehleinträge (z. B. „ca. 5") vor Import manuell bereinigen
Seriennummer-Spalte (falls vorhanden)	Materialtyp-Erkennung: Vorhandensein einer SN-Spalte bei dieser Zeile → `material.materialtyp = 'geraet_sn'`, sonst `'standard'`	Ablaufdatum/Charge kommt in den bestehenden Listen nicht vor → für diese drei Listen entfällt Typ `ablauf_charge` beim Erstimport, wird später manuell ergänzt (z. B. Infusionssysteme)
Einheit	nicht in Excel vorhanden	Beim Import Standardwert „Stück" setzen, danach manuell korrigieren wo nötig (z. B. „Paar", „Packung")
Kategorie/Bereich	nicht in Excel vorhanden	Einmalig vor Import anlegen: 1 Bereich „Rettungsdienst/KatS", grobe Kategorie „Rucksäcke" für alle drei Objekttypen

Ablauf des Imports (Vorschlag, Umsetzung Phase 5)

Bereich + Kategorie einmalig anlegen (Administration, manuell oder Skript).
Je Excel-Datei: Objekttyp + Beladungsvorlage Version 1 anlegen.
Zeilen einlesen (stdlib zipfile/xml.etree.ElementTree wie bei der Erstanalyse, siehe Prompt 01 – kein openpyxl nötig): Fach, Artikel, Artikelnummer, Menge, optionale SN-Spalte.
Je Zeile: Material anhand Artikelnummer suchen oder neu anlegen, dann Vorlagenposition mit Sollmenge und Fach erzeugen.
Konkrete Objekte (z. B. „Rucksack Handball 12", „Rucksack Handball 17") werden NICHT aus Excel importiert (Excel enthält nur die Soll-Struktur, keine konkreten Instanzen) – Administration legt sie danach manuell an, je mit Code (Karte 10) und Vorlagen-Referenz.
Erste Kontrolle je neu angelegtem Objekt erfasst den tatsächlichen Ist-Bestand (Objekte starten „nicht kontrolliert", analog Duplizieren-Regel Prompt 09) – dies IST der Übergang vom Papier- zum Digitalbetrieb (Prompt 23).

Bekannte Lücken, vor Import zu klären

Einheiten pro Material sind in den Excel-Listen nicht erfasst – vor Import Liste durchgehen und einmalig ergänzen (einmaliger manueller Aufwand, keine Systemfrage).
Uneindeutige/fehlende Artikelnummern in den Quell-Listen (falls vorhanden) verhindern automatischen Abgleich – in diesen Fällen manuelle Zuordnung beim Import nötig.
Import-Skript selbst ist Code (Prompt-19-Deployment-Regel gilt: bei Umsetzung nur Skript-Datei erzeugen, Ausführung gegen Test-DB erst auf Zielsystem/Test-Deployment, nicht lokal).

Regeln übergreifend

Kein Feature ohne Test: jeder Endpoint/jede Domänenregel wird erst mit Test gemerged (CI-Gate).
Leitplanke-Doppelschutz: U2/U3 (Mindermenge ≠ erledigt) laufen zusätzlich als Phase-3-Szenario (S7) – bei Bruch dieser Regel sofortiger Release-Blocker.
Coverage-Hochschraubung: nach V1-Release Gate schrittweise 50 → 60 → 70 % erhöhen.
Testdaten niemals Produktivdaten: Pilotphase läuft auf Test-Deployment, echte Inbetriebnahme erst nach Go/No-Go.

Phase S – Satelliten-Betrieb (spätere Erweiterung, NICHT V1)

Roadmap-Phase, erst nach stabiler V1. Eigener Testplan nötig, mindestens:

PoC mit zwei lokalen PostgreSQL-Instanzen (Docker oder zwei Datenbanken): Objekt auslagern → Kontrolle + Fehlbestand + Nachfüllung + Genehmigung am „Satelliten" → zurücksyncen → Hauptserver-Stand vollständig und ohne Duplikate
Sync-Fälle 1–3 aus Prompt 20.10 einzeln beweisen (Insert neue Zeilen, Upsert Objektpositionen, Upsert Fehlbestand/Genehmigung)
Bestückungsregel testen: Objekt mit offenem Fehlbestand auslagern → am Satelliten nachfüllen → zurücksyncen → genau EIN Fehlbestand, erledigt
Schreibzugriff am Hauptserver auf ausgelagertes Objekt → muss abgelehnt werden
Offene Punkte aus Karte 13 vorher entscheiden: Pre-Sync-Check laufender Kontrollen, DB-Trigger für zuletzt_geaendert_am, Bestückungs-Details

Referenzen

Bezug: 22_testkonzept, 18_version_1, 01_anforderungsanalyse, 09_duplizieren, 23_papieraloesung, 13_satelliten_server

153 KiB Raw Permalink Blame History Unescape Escape

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

Teil A – Arbeitskarten (Klärungsstand)

Arbeitskarten – Index

Karte 01 – Rollen & Zuordnung

Entscheidung

Konsequenz für Datenmodell / Fachkonzept

Geklärt (vormals offen)

Karte 02 – Rechte: Stammdaten vs. Ist-Menge

Entscheidung

Konsequenz

Karte 03 – Sollmengen-Recht Materialverantwortlicher

Entscheidung

Konsequenz

Karte 04 – Organisationsstruktur / Zuständigkeiten

Entscheidung

Konsequenz für Datenmodell

Geklärt (vormals offen)

Karte 05 – Benachrichtigungen

Entscheidung

Konsequenz

Karte 06 – Geräteanforderung PC/Mobil

Entscheidung

Konsequenz

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

Entscheidung

Konsequenz

Karte 08 – Mindermengen-Gültigkeit

Entscheidung

Konsequenz

Karte 09 – Authentifizierung

Entscheidung

Konsequenz

Karte 10 – QR-Code / Barcode

Entscheidung

Konsequenz für V1 (jetzt schon vorsehen)

Umsetzung

Barcode-Format (Nutzerentscheidung)

Label-Design (offener Punkt, Prompt 24 vertiefend)

Karte 11 – Systemumfang: generisches Ressourcenmanagement

Entscheidung

Konsequenz für Datenmodell (Prompt 06/07)

Auswirkung auf bestehende Prompts

Karte 12 – Eskalation offener Fehlbestände

Entscheidung

Konsequenz für V1

Umsetzung

Karte 13 – Hauptserver mit Satelliten-Servern

Entscheidung

Einsatzfälle

Autark-Dauer

Mehrbenutzerfähigkeit am Satelliten

Konfliktvermeidung (statt Konfliktlösung)

Konsequenz für Datenmodell/Architektur (Vorbereitung, Details Prompt 19/20 zu vertiefen)

Offene Punkte für weitere Ausarbeitung

Referenzen

Teil B – Prompt-Ergebnisse & Querschnittsdokumente

Prompt 01 – Anforderungsanalyse

1. Ausgangslage

2. Funktionale Anforderungen

Muss

Soll

Kann (spätere Ausbaustufen, nicht MVP)

3. Nichtfunktionale Anforderungen

4. Angenommene Rahmenbedingungen (Annahmen)

5. Risiken

6. Offene Fragen (vor Prompt 02–05 weiter zu klären)

Referenzen

Prompt 02 – Kontrollprozess vollständig definieren

1. Status einer Kontrolle

2. Ablauf (Normalfall, keine Abweichung)

3. Ablauf bei Abweichung (Ist < Soll)

4. Ablauf bei Ist > Soll (Überbestand)

5. Nachfüllung außerhalb der Kontrolle

6. Mindermengen-Genehmigung im Ablauf

7. Sonderfälle

8. Objekt-Sperre bei aktiver Kontrolle (Nutzerentscheidung)

9. Trennung der vier Kernbegriffe (verbindlich)

Offene Fragen für Prompt 03/04

Prompt 03 – Fehlbestände und Aufgaben definieren

153 KiB

Raw Permalink Blame History