From 96f69933b0966e6d738650b1933ef03686a8390f Mon Sep 17 00:00:00 2001 From: patrick Date: Thu, 3 Sep 2026 17:26:40 +0200 Subject: [PATCH] Dateien nach "/" hochladen --- 15_lager.md | 26 ++++++++++++++++++++ 16_kontrollabschluss.md | 39 ++++++++++++++++++++++++++++++ 17_mobile_offline.md | 44 ++++++++++++++++++++++++++++++++++ 18_version_1.md | 53 +++++++++++++++++++++++++++++++++++++++++ 4 files changed, 162 insertions(+) create mode 100644 15_lager.md create mode 100644 16_kontrollabschluss.md create mode 100644 17_mobile_offline.md create mode 100644 18_version_1.md diff --git a/15_lager.md b/15_lager.md new file mode 100644 index 0000000..a8501f4 --- /dev/null +++ b/15_lager.md @@ -0,0 +1,26 @@ +# 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) diff --git a/16_kontrollabschluss.md b/16_kontrollabschluss.md new file mode 100644 index 0000000..c25d6f4 --- /dev/null +++ b/16_kontrollabschluss.md @@ -0,0 +1,39 @@ +# Prompt 16 – Kontrolle abschließen + +Bezug: [[02_prozess_kontrolle]], [[03_fehlbestandsmanagement]], [[11_kontroll_ui]]. + +## 1. Wann gilt eine Kontrolle als abgeschlossen +Eine Kontrolle gilt als abgeschlossen, wenn Mitarbeiter jede Position mindestens einmal bewertet hat (bestätigt „passt" oder Ist-Menge eingetragen) und aktiv „Kontrolle abschließen" bestätigt (Prompt 11, Screen 6). Offene Fehlbestände sind KEIN Blocker für den Abschluss. + +## 2. Verhalten bei offenen Abweichungen +- Kontrolle wird trotz offener Fehlbestände abgeschlossen (Status „abgeschlossen"). +- Jeder offene Fehlbestand bleibt als eigenständiger, von der Kontrolle entkoppelter Vorgang bestehen (Prompt 03) – Abschluss der Kontrolle ändert seinen Status nicht. +- Während der Kontrolle nachgefülltes Material: wird als behobene Abweichung dokumentiert (Fehlbestand entsteht und wird im selben Moment erledigt, Historieneintrag zeigt beide Ereignisse, Karte 07/Prompt 02). + +## 3. Abschlussanzeige (Screen 6, Prompt 11 vertieft) +- Zusammenfassung: Gesamtzahl Positionen, davon ok, davon abweichend, davon sofort nachgefüllt, davon weiterhin offen. +- Liste der weiterhin offenen Fehlbestände mit direktem Link zur Detailansicht (Dashboard, Prompt 12). +- Deutlicher Hinweis: „X Fehlbestände bleiben offen und sind für Verantwortliche sichtbar" – kein falscher Eindruck von „alles erledigt". + +## 4. Bestätigung +- Einmalige, eindeutige Bestätigungsaktion (Button „Kontrolle abschließen"), kein Doppel-Abschluss möglich (Status-Übergang „in Bearbeitung" → „abgeschlossen" ist einmalig terminal für diese Kontrollinstanz). +- Nach Abschluss keine Änderung an bereits erfassten Kontrollpositionen mehr möglich (Snapshot-Prinzip, Prompt 06/13) – Korrekturen nur durch neue Kontrolle oder durch separate Nachfüllung/Fehlbestand-Bearbeitung außerhalb der Kontrolle. + +## 5. Kontrollnachweis +- Nach Abschluss automatisch erzeugtes, unveränderliches Dokument/Datensatz: wer, wann, Objekt, Ergebnis je Position (Snapshot), Liste ausgelöster Fehlbestände. +- Standard-Nachweis: Login-gebundene Zuordnung (wer eingeloggt war und die Aktion ausgeführt hat) gilt als Unterschriftsersatz, kein Zusatzschritt nötig. +- Optional/konfigurierbar (Nutzerentscheidung): **Touch-Unterschrift** (Zeichenfeld auf Tablet/Smartphone, als Bild mit Kontrolle verknüpft gespeichert) einschaltbar, falls von übergeordneter Stelle (z. B. Kreisverband, Behörde) gefordert. Kein Zwang für alle Standorte – als abschaltbare Option pro Organisation/Standort vorgesehen, nicht MVP-Pflicht, aber Datenmodell sollte optionales Signaturbild-Feld am Kontrollnachweis vorsehen (kein Schema-Umbau später nötig). +- Dient als digitaler Ersatz der bisherigen Papier-Unterschrift (Prompt 23 vertieft Migration). +- Einsehbar in Objekt-Historie (Prompt 13) und für Audit-Zwecke durch Verantwortliche/Administration. + +## 6. Abgebrochene Kontrolle (Antwort auf offene Frage aus Prompt 02) +**Frage war:** Braucht abgebrochene Kontrolle eine Aufbewahrung als Teil-Historie, oder wird sie komplett verworfen? + +**Entscheidung:** Abgebrochene Kontrolle wird NICHT komplett verworfen, aber auch nicht als gültiger Kontrollnachweis gezählt: +- Status „abgebrochen" bleibt als Datensatz erhalten (wer hat wann begonnen und abgebrochen), rein zur Nachvollziehbarkeit (z. B. „warum wurde Rucksack X seit 3 Tagen nicht fertig kontrolliert"). +- Keine Ist-Werte aus der abgebrochenen Kontrolle werden auf das Objekt übernommen, kein Fehlbestand wird daraus ausgelöst. +- Objekt bleibt im Zustand vor Kontrollbeginn (bzw. „nicht kontrolliert seit Datum X"), zählt weiterhin als fällig für Kontrolle. +- Grund für Abbruch optional erfassbar (Freitext, z. B. „Einsatzalarmierung"). + +## Referenzen +Bezug: [[02_prozess_kontrolle]], [[03_fehlbestandsmanagement]], [[11_kontroll_ui]], [[13_historie_audit]] diff --git a/17_mobile_offline.md b/17_mobile_offline.md new file mode 100644 index 0000000..5c937bd --- /dev/null +++ b/17_mobile_offline.md @@ -0,0 +1,44 @@ +# 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]] diff --git a/18_version_1.md b/18_version_1.md new file mode 100644 index 0000000..91db248 --- /dev/null +++ b/18_version_1.md @@ -0,0 +1,53 @@ +# 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