Dateien nach "/" hochladen

This commit is contained in:
2026-09-03 17:26:12 +02:00
parent a5255fbacc
commit 41e5c648e1
5 changed files with 293 additions and 0 deletions
+117
View File
@@ -0,0 +1,117 @@
# Prompt 06 Erweiterbares Datenmodell
Bezug: alle Ergebnisse 01-05, Karten [[04_organisationsstruktur]], [[10_qr_barcode]], [[11_systemumfang_ressourcenmanagement]], [[08_mindermenge_gueltigkeit]].
Reine fachliche Modellierung (Entitäten/Beziehungen), noch kein DB-Schema (folgt Prompt 20).
## 1. Grundprinzip der Trennung
Vier klar getrennte Schichten, dürfen nicht vermischt werden:
1. **Materialstamm** was für Material gibt es grundsätzlich (Prompt 07).
2. **Beladungsvorlage** welches Material soll in welcher Menge in einem Objekttyp sein (Prompt 08).
3. **Konkretes Objekt** ein tatsächlicher Rucksack/Fahrzeug/Ressource mit eigener ID.
4. **Ist-Bestand** tatsächlicher Zustand eines konkreten Objekts zu einem Zeitpunkt.
## 2. Kernentitäten
### Bereich (Karte 11)
- Fachliche Domäne, z. B. „Rettungsdienst/KatS". Oberste Gliederungsebene, macht System bereichsoffen.
- Attribute: Name, Beschreibung.
### Kategorie
- Gliedert Objekttypen/Material innerhalb eines Bereichs (z. B. „Rucksäcke", „Fahrzeuge", „Zelte").
- Kann hierarchisch sein (Kategorie → Unterkategorie), Granularität final in Prompt 07/11 vertiefen.
- Attribute: Name, Bereich-Referenz, übergeordnete Kategorie (optional).
### Standort
- Physischer Ort/Wache.
- Attribute: Name, Adresse (optional).
### Objekttyp / Ressourcentyp
- Generischer Oberbegriff statt „Rucksack" fest zu verdrahten (Karte 11): Rucksack, Fahrzeug, Zelt, Feldbett, Stromerzeuger, Funkgerät, ...
- Attribute: Name, Bereich-Referenz, Kategorie-Referenz.
### Beladungsvorlage
- Vorlage für einen Objekttyp (z. B. „Rucksack Handball Standard").
- Enthält Liste von Vorlagenpositionen (Material + Sollmenge).
- Versionierbar (Prompt 08 vertieft).
- Attribute: Name, Objekttyp-Referenz, Version, gültig ab.
### Vorlagenposition
- Materialstamm-Referenz + Sollmenge innerhalb einer Vorlage.
- Attribute: Vorlage-Referenz, Material-Referenz, Sollmenge, Kategorie/Fach (z. B. „Fach 1").
### Objekt (konkreter Rucksack/Fahrzeug/Ressource)
- Konkrete, physische Instanz.
- Attribute: eindeutige Objekt-ID, Code-Feld für QR/Barcode (Karte 10, Code128-kompatibel), Name/Bezeichnung, Objekttyp-Referenz, Beladungsvorlage-Referenz (Basis), Standort-Referenz, Status (aktiv/außer Dienst).
- Zuständigkeits-Zuordnung: n:m-Beziehung zu Verantwortlichen (Karte 04), nicht starr an Standort gekoppelt.
### Objektposition (Ist-Soll je Objekt)
- Individuelle Ist-Situation je Material innerhalb eines konkreten Objekts.
- Sollmenge kann von Vorlage abweichen (individuelle Anpassung, Prompt 10) → eigenes Feld „Sollmenge-Override", sonst Vorlagenwert.
- Attribute: Objekt-Referenz, Material-Referenz, aktuelle Sollmenge (effektiv), aktuelle Istmenge, optional Sollmenge-Override-Flag.
### Materialstamm-Position (Detail in Prompt 07)
- Stammdaten eines Materials (Name, Artikelnummer, Einheit, Materialtyp: Standard/Ablaufdatum-Charge/Gerät-mit-SN).
- Bei Materialtyp „Gerät": eigenes Code-Feld für QR/Barcode-SN-Erkennung (Karte 10).
### Kontrolle
- Ein Kontrollvorgang zu einem Zeitpunkt an einem Objekt.
- Attribute: Objekt-Referenz, durchgeführt von (Benutzer), Start, Ende, Status (nicht gestartet/in Bearbeitung/abgeschlossen/abgebrochen).
- Enthält Kontrollpositionen (Snapshot je Material: Soll zum Zeitpunkt, Ist erfasst, Abweichung ja/nein).
### Kontrollposition
- Snapshot-Ergebnis je Material innerhalb einer Kontrolle (unveränderlich nach Abschluss, für Historie).
### Fehlbestand (Prompt 03)
- Eigenständiger Vorgang, entkoppelt vom Kontrollabschluss.
- Attribute: siehe Prompt 03 (Material, Objekt, Standort, Soll, Ist, Fehlmenge, entstanden am, festgestellt von, Ursache, Verantwortlicher, erledigt am).
- Statusmaschine wie in Prompt 03 definiert.
### Nachfüllung
- Ereignis, das Ist-Menge eines Objekts erhöht.
- Attribute: Objekt-Referenz, Material-Referenz, Menge, wer, wann, verknüpfter Fehlbestand (falls vorhanden).
### Mindermengen-Genehmigung (Prompt 04)
- Eigene Entität, verknüpft mit Fehlbestand + auslösender Kontrolle.
- Attribute: Fehlbestand-Referenz, genehmigt von, Begründung, Zeitstempel, gültig bis (nächste Kontrolle desselben Objekts), Status (aktiv/abgelaufen/durch Erledigung beendet).
- NIEMALS Schreibzugriff auf Ist-Menge.
### Benutzer
- Attribute: Name, Login-Kennung, Passwort-Hash/PIN (Karte 09), Rollen (n:m, Prompt 05), aktiv/inaktiv.
### Rolle
- Mitarbeiter/Kontrollorgan, Materialverantwortlicher, Leitungsverantwortlicher, Administration (Prompt 05). Erweiterbar für Roadmap-Rollen.
### Zuständigkeits-Zuordnung
- n:m zwischen Benutzer (mit Rolle Materialverantwortlicher/Leitungsverantwortlicher) und Standort/Objekt (Karte 04), von Administration gepflegt.
### Historieneintrag (Prompt 13 vertieft)
- Generisches Audit-Log: wer, was (Entität+ID), wann, alter Wert, neuer Wert, Begründung (optional), Aktionstyp.
## 3. Zentrale Beziehungen (vereinfacht)
```
Bereich 1───n Kategorie
Bereich 1───n Objekttyp
Objekttyp 1───n Beladungsvorlage 1───n Vorlagenposition n───1 Materialstamm-Position
Objekttyp 1───n Objekt
Beladungsvorlage 1───n Objekt (Basis-Referenz)
Objekt 1───n Objektposition n───1 Materialstamm-Position
Objekt n───m Benutzer (Zuständigkeits-Zuordnung)
Objekt 1───n Kontrolle 1───n Kontrollposition
Objektposition/Kontrolle 1───n Fehlbestand
Fehlbestand 1───n Nachfüllung
Fehlbestand 1───0..n Mindermengen-Genehmigung (i.d.R. max. 1 aktive)
Benutzer n───m Rolle
Alles ───1 Historieneintrag (generisch, polymorph auf Entität+ID)
```
## 4. Erweiterbarkeit ohne Schema-Umbau (Designziel)
- Materialtyp als eigenes Attribut in Materialstamm-Position (nicht als Tabellen-Fork) → Medikamente/Chargen/SN später als Zusatzfelder/Zusatztabellen andockbar (Prompt 07).
- Lagerbestand (Prompt 15) als eigene Entität analog „Objekt", nur mit Lagerort statt Kontrolle/Fehlbestand-Workflow gleiche Materialstamm-Basis wiederverwendbar.
- Prüfungen (Geräte-TÜV o. ä., Prompt 24) als eigene Entität mit Referenz auf Materialstamm-Position/Objektposition, unabhängig vom Kern-Fehlbestandsmodell.
- Code-Feld bereits in Objekt UND Materialstamm-Position vorgesehen (Karte 10), keine Migration nötig, wenn Scan-Funktion kommt.
- „Entstanden am" in Fehlbestand bereits vorgesehen (Karte 12) für Eskalation.
## Referenzen
Arbeitskarten: [[04_organisationsstruktur]], [[10_qr_barcode]], [[11_systemumfang_ressourcenmanagement]], [[08_mindermenge_gueltigkeit]], [[09_authentifizierung]]
+67
View File
@@ -0,0 +1,67 @@
# Prompt 07 Materialstamm definieren
Bezug: [[06_datenmodell]], Karten [[10_qr_barcode]].
## 1. Grundprinzip
Nicht jedes Material braucht dieselben Felder. Materialstamm-Position hat **Basisfelder (immer)** + **typspezifische Zusatzfelder (je Materialtyp)**, statt für jeden Typ eine eigene Tabelle.
## 2. Materialtypen
1. **Standard-Verbrauchsmaterial** einfache Zähl-/Mengenware ohne Ablauf/SN. Beispiele: Rettungsdecken, Kompressen, Verbandspäckchen.
2. **Material mit Ablaufdatum/Charge** Verbrauchsmaterial mit Haltbarkeit. Beispiele: Infusionssysteme, Medikamente (später), sterile Sets.
3. **Einzelobjekt/Gerät mit Seriennummer** nicht stückzahlbasiert, sondern individuell identifiziert. Beispiele: Pulsoxymeter, Blutzuckermessgerät, Beatmungsbeutel (falls mit SN geführt).
Typ ist ein Attribut der Materialstamm-Position, keine getrennte Tabelle neue Typen später ohne Schema-Umbau ergänzbar (Designziel Prompt 06).
## 3. Basisfelder (Pflicht, für alle Typen)
| Feld | Beschreibung |
|---|---|
| Name | Bezeichnung, z. B. „Kompresse steril 10x10" |
| Artikelnummer | interne oder Hersteller-Artikelnummer (aus bestehenden Excel-Listen übernehmbar) |
| Einheit | Stück, Packung, Paar, ... |
| Materialtyp | Standard / Ablaufdatum-Charge / Gerät-mit-SN |
| Bereich/Kategorie-Referenz | Einordnung (Karte 11) |
| Aktiv/inaktiv | ob Material noch beschafft/verwendet wird |
## 4. Optionale Basisfelder (für alle Typen, aber nicht zwingend befüllt)
- Hersteller
- Beschreibung/Hinweistext
- Bild (Roadmap, nicht MVP)
- Code-Feld für QR/Barcode-Erkennung (Karte 10) bei Typ „Gerät-mit-SN" faktisch Pflicht für spätere SN-Erkennung, bei anderen Typen optional (z. B. Materialstamm-Etikett).
## 5. Typspezifische Zusatzfelder
### Standard-Verbrauchsmaterial
- keine Zusatzfelder nötig (nur Basisfelder).
### Material mit Ablaufdatum/Charge
- Chargennummer (je konkreter Bestandseinheit, nicht im Stammsatz selbst, sondern in der Objektposition/Bestandseinheit Stammsatz definiert nur „hat Ablauf/Charge: ja")
- Warnzeitraum-Vorgabe (Standardwert, konfigurierbar, Prompt 14 vertieft)
- Lagerbedingungen (optional, Freitext, z. B. „kühl lagern")
### Einzelobjekt/Gerät mit Seriennummer
- Seriennummer wird nicht im Stammsatz geführt (der Stammsatz beschreibt das Gerätemodell, z. B. „Pulsoxymeter Modell X"), sondern je konkretem Exemplar in der Objektposition/eigenen Geräte-Instanz.
- Prüfintervall-Vorgabe (optional, Vorbereitung Prompt 24 „Prüfungen")
- Zubehör/Kompatibilitätshinweis (optional, Freitext)
## 6. Abgrenzung Stammsatz vs. konkrete Instanz
Wichtig, um Prompt 06 konsistent zu bleiben:
- **Materialstamm-Position** = abstrakte Beschreibung („was ist das für ein Material").
- **Objektposition** (in einem konkreten Rucksack/Fahrzeug) = konkrete Menge/Instanz, dort leben Chargennummer, Ablaufdatum, Seriennummer der jeweiligen physischen Einheit.
- Ein Stammsatz „Pulsoxymeter Modell X" kann in mehreren Objekten vorkommen, mit jeweils eigener Seriennummer je Instanz.
## 7. Pflichtfelder-Zusammenfassung
| Materialtyp | Pflicht im Stammsatz | Pflicht in Objektposition/Instanz |
|---|---|---|
| Standard | Name, Artikelnummer, Einheit, Kategorie | Ist-Menge |
| Ablaufdatum/Charge | Name, Artikelnummer, Einheit, Kategorie, „hat Ablauf: ja" | Ist-Menge, Ablaufdatum, Chargennummer |
| Gerät mit SN | Name, Artikelnummer, Einheit=„Stück", Kategorie, „hat SN: ja" | Seriennummer, Status (vorhanden/defekt/fehlt) |
## 8. Spätere Erweiterungsmöglichkeiten (Roadmap, nicht MVP)
- Medikamente als eigener Materialtyp mit Betäubungsmittel-Kennzeichnung, Dosierungseinheit (Prompt 24).
- Bild-Upload je Material.
- Verknüpfung zu Lieferanten/Bestellinformationen (Prompt 15/24).
- Mehrsprachige Bezeichnung (falls organisationsübergreifend genutzt).
## Referenzen
Arbeitskarten: [[10_qr_barcode]]
Bezug: [[06_datenmodell]]
+37
View File
@@ -0,0 +1,37 @@
# 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]]
+38
View File
@@ -0,0 +1,38 @@
# Prompt 09 Rucksäcke und Fahrzeuge duplizieren
Bezug: [[06_datenmodell]], [[08_beladungsvorlagen]].
## 1. Grundprinzip
Duplizieren erzeugt neues Objekt, übernimmt Struktur/Sollmengen, aber NIE Zustandsdaten. Grundprinzip aus `prompts.md`: „Duplizierte Objekte müssen anschließend individuell bearbeitbar sein."
## 2. Was wird kopiert
- Objekttyp-Referenz
- Beladungsvorlage-Referenz (aktuelle Version)
- Objektpositionen-Struktur: Material + Sollmenge (inkl. bestehender individueller Sollmengen-Abweichungen, falls Quelle=konkretes Objekt statt Vorlage)
- Zuständigkeits-Zuordnung: optional übernehmbar (Abfrage), da neues Objekt evtl. anderer Standort/Verantwortlicher
## 3. Was NICHT kopiert wird
- Aktuelle Ist-Bestände (Istmenge wird auf 0 oder „nicht kontrolliert" gesetzt, nicht auf Soll)
- Seriennummern konkreter Geräte-Instanzen
- Chargennummern/Ablaufdaten
- Offene Fehlbestände
- Kontrollhistorie
- Genehmigte Mindermengen
- Code-/QR-Feld (Karte 10): neues Objekt braucht eigenen, neuen Code, kein Duplikat des Quell-Codes (Eindeutigkeit)
## 4. Ablauf
1. Verantwortlicher/Administration wählt Quelle: bestehendes Objekt ODER Beladungsvorlage direkt.
2. System zeigt Vorschau: welche Positionen werden übernommen (Struktur/Soll), Hinweis „Ist-Bestände und Historie werden NICHT übernommen".
3. Pflichteingabe für neues Objekt: neuer Name/Bezeichnung, Standort, neuer Code (QR/Barcode, Karte 10).
4. Optional: Zuständigkeits-Zuordnung direkt mit anlegen oder später durch Administration.
5. Neues Objekt wird angelegt mit Status „neu, noch nicht kontrolliert" erste Kontrolle erforderlich, um echten Ist-Bestand zu erfassen.
6. Neues Objekt ist ab sofort vollständig individuell editierbar (Sollmengen-Overrides, Vorlage wechseln, etc. Prompt 10).
## 5. Duplizieren als Vorlagen-Erstellung (Verweis Prompt 08)
- Duplizieren eines Objekts kann auch als Ausgangspunkt für eine **neue Beladungsvorlage** dienen (z. B. „dieses individuell angepasste Fahrzeug soll neuer Standard werden") separate Aktion, nicht automatisch, Administration entscheidet bewusst.
## 6. Sonderfall: mehrfaches Duplizieren (Serie)
- Möglich, z. B. 5 gleiche Rucksäcke auf einmal anlegen: einmalige Struktur-Auswahl, aber je Kopie eigener Name/Code/Standort-Eingabe (Pflicht, da Eindeutigkeit).
## Referenzen
Bezug: [[06_datenmodell]], [[08_beladungsvorlagen]], Karte [[10_qr_barcode]]
+34
View File
@@ -0,0 +1,34 @@
# Prompt 10 Individuelle Anpassungen
Bezug: [[06_datenmodell]], [[08_beladungsvorlagen]], [[09_duplizieren]].
## 1. Grundprinzip
Konkretes Objekt darf von seiner Vorlage abweichen, ohne die Vorlage selbst zu verändern. Abweichung wird auf Ebene der Objektposition gespeichert, nicht in der Vorlage.
## 2. Arten von Abweichungen
1. **Sollmengen-Override** Material aus Vorlage vorhanden, aber andere Sollmenge (Beispiel: Vorlage 10 BZ-Messtreifen, Fahrzeug braucht 15).
2. **Zusätzliches Material** Position, die in der Vorlage nicht existiert, nur bei diesem Objekt.
3. **Entferntes Material** Vorlagenposition wird bei diesem Objekt bewusst nicht geführt (Soll = 0, als „entfernt" markiert, nicht einfach gelöscht).
## 3. Speicherung
- Objektposition hat Feld „Sollmenge effektiv" + Flag „Override: ja/nein" + optional „Override-Grund" (Freitext).
- Ist Override = nein → Sollmenge wird aus aktueller Vorlagenversion übernommen (dynamisch).
- Ist Override = ja → Sollmenge kommt aus der Objektposition selbst, unabhängig von Vorlagenänderungen, bis Override manuell aufgehoben wird.
- Zusätzliches Material: Objektposition ohne zugehörige Vorlagenposition, aber mit Materialstamm-Referenz, klar als „nur bei diesem Objekt" markiert.
- Entferntes Material: Objektposition mit Status „entfernt/nicht geführt" statt physischer Löschung bleibt in Historie sichtbar, warum es fehlt.
## 4. Anzeige
- Kontroll-UI (Prompt 11) markiert abweichende Positionen deutlich (Symbol „individuell angepasst"), damit Kontrollperson nicht denkt, es handle sich um Standard.
- Bei Override: Anzeige beider Werte auf Wunsch (Vorlage: 10, dieses Objekt: 15) für Nachvollziehbarkeit.
## 5. Vorlagenänderung trifft individuell abweichendes Objekt
- Direkter Bezug zu Prompt 08, Punkt 6: Wird die Vorlage geändert (z. B. Sollmenge einer Position erhöht), betrifft das nur NICHT-Override-Positionen automatisch (da dynamisch referenziert).
- Override-Positionen bleiben unberührt, außer Verantwortlicher hebt den Override bewusst auf ("wieder auf Vorlage zurücksetzen").
- Neue Vorlagenpositionen (komplett neues Material in Vorlage): System bietet an, sie bei bestehenden Objekten zu ergänzen (Diff-Ansicht, Prompt 08), Verantwortlicher entscheidet pro Objekt/Position.
- Entfernte Vorlagenpositionen: bei Objekten mit „entfernt"-Markierung ohnehin irrelevant; bei Objekten ohne eigene Abweichung wird Position ebenfalls zur Übernahme als „entfernen?" vorgeschlagen, nicht automatisch gelöscht.
## 6. Nachvollziehbarkeit
- Jede Abweichung (Override gesetzt/aufgehoben, Material hinzugefügt/entfernt) erzeugt Historieneintrag: wer, wann, alter/neuer Wert, Begründung (Prompt 13).
## Referenzen
Bezug: [[06_datenmodell]], [[08_beladungsvorlagen]], [[09_duplizieren]]