UC01 – Equipment erfassen
Stand: 01.08.2026 14:55
Branch: docs/einheitliche-kopfbereiche
Status: Spezifikation
| Datum, Uhrzeit |
Version |
Änderung |
Autor |
| 01.08.2026 14:55 |
0.2 |
Kopfbereich vereinheitlicht |
David Mittig |
| Mai 2026 |
0.1 |
Initiale UC01-Spezifikation angelegt; generische Equipment-Erfassung als Core-Basis definiert; typabhängige Erweiterungen und offene Entscheide dokumentiert |
David Mittig |
| Mai 2026 |
0.2 |
Hybrid-Modell festgelegt; V1-Equipment-Typen übernommen; Pflicht- und Empfehlungsfelder ergänzt; Datenqualität, QR-Vorbereitung, Foto-Upload, strukturierte Notizen, Offline-Erfassung und Verleih-Vorbereitung ergänzt |
David Mittig |
Spezifikationsdatei – Leitdokument für Entwicklung, Testing und Abnahme
Review: offen
Status-Übersicht
| Schritt |
Bezeichnung |
Status |
Kommentar |
| 1 |
Steckbrief |
✅ Abgeschlossen |
Grundstruktur erstellt |
| 2 |
Scope & Abgrenzung |
✅ Abgeschlossen |
Generische Equipment-Basis definiert |
| 3 |
Ablaufbeschreibung |
🟡 In Bearbeitung |
Happy Path und Alternativen als Entwurf vorhanden |
| 4 |
Datenmodell |
🟡 In Bearbeitung |
Hybrid-Modell fachlich festgelegt |
| 5 |
Backend (NestJS) |
⬜ Offen |
Nach fachlicher Freigabe |
| 6 |
Prisma / Supabase |
⬜ Offen |
Nach finalem Schema-Delta |
| 7 |
Frontend (React) |
⬜ Offen |
Nach Screen-Flow |
| 8 |
Testing |
⬜ Offen |
Nach API- und UI-Entscheid |
Legende: ✅ Abgeschlossen | 🟡 In Bearbeitung | 🔴 Blockiert | ⬜ Offen
1. Steckbrief
1.1 Übersicht
| Feld |
Inhalt |
| UC-ID |
UC01 |
| Name |
Equipment erfassen |
| Version |
V1 |
| Zielgruppe |
Tauchschule |
| Primärakteur |
mitarbeiter |
| Sekundärakteur |
tenant_admin |
| Reifegrad V1 |
Vollständig |
| Priorität |
Hoch – Core-Basis für alle weiteren equipmentbezogenen Use Cases |
1.2 Ziel
UC01 definiert die generische Equipment-Erfassung als Core-Funktion. Jedes Equipment wird tenant-isoliert, eindeutig identifizierbar, optional einem Kunden zuordenbar und als Grundlage für spätere Use Cases nutzbar gespeichert.
Die generische Equipment-Erfassung bildet die Basis für alle konkreten Ausrüstungstypen, zum Beispiel Tauchflaschen, Atemregler, Jackets, Tauchcomputer, Tauchanzüge, Masken, Flossen, Kompasse, Lampen und weiteres Zubehör.
1.3 Grundprinzip
UC01 trennt strikt zwischen:
| Ebene |
Inhalt |
Beispiel |
| Basis-Erfassung |
Gemeinsame Stammdaten jedes Equipments |
Typ, Hersteller, Modell, Seriennummer, Kunde, Status, Notizen, Foto |
| Typabhängige Zusatzdaten |
Spezifische Felder je Equipment-Typ |
Flasche: Volumen, Druck, Material; Tauchcomputer: Firmware; Anzug: Grösse, Dicke |
| Spezifische Workflows |
Prozesse auf Basis des Equipments |
TÜV, Service, Füll-Abo, Fristen, Export, Kundenportal, Verleih |
1.4 Vorbedingungen
| # |
Bedingung |
| V1 |
Benutzer ist eingeloggt |
| V2 |
Benutzer gehört zu genau einem Tenant |
| V3 |
Benutzer hat Rolle tenant_admin oder mitarbeiter |
| V4 |
Tenant ist aktiv |
| V5 |
Equipment-Typen sind systemseitig verfügbar |
1.5 Nachbedingungen im Erfolgsfall
| # |
Bedingung |
| N1 |
Equipment-Datensatz ist in der DB angelegt |
| N2 |
Equipment ist dem korrekten Tenant zugeordnet |
| N3 |
Equipment ist eindeutig identifizierbar |
| N4 |
Optionaler Kundenbezug ist gespeichert, falls ausgewählt |
| N5 |
Status ist gesetzt |
| N6 |
Datenqualität ist gesetzt |
| N7 |
Audit-Felder sind befüllt |
| N8 |
Equipment kann nach vollständiger Erfassung von späteren Use Cases referenziert werden |
2. Scope & Abgrenzung
2.1 Gehört zu UC01
| Bereich |
Enthalten |
| Equipment-Typ auswählen |
Ja |
| Basisdaten erfassen |
Ja |
| Zuordnung erfassen |
Ja: intern, Kunde oder unbestimmt |
| Kunde zuordnen |
Ja, wenn Zuordnungstyp customer gewählt wird |
| Mitarbeiter-Equipment abbilden |
Ja, über Kundendatensatz mit besonderem Merkmal |
| Status setzen |
Ja |
| Datenqualität setzen |
Ja: complete, incomplete, needs_review |
| Notizen erfassen |
Ja, als strukturierte Notizen mit Datum/Zeit und Benutzerbezug |
| Hauptfoto erfassen |
Ja, falls technisch ohne grossen Zusatzaufwand umsetzbar |
| QR-Code vorbereiten |
Ja |
| Typabhängige Zusatzfelder |
Ja, als Erweiterung zur Basis-Erfassung |
| Tenant-Isolation |
Ja |
| Eindeutigkeit innerhalb des Tenants |
Ja |
| Audit- und Änderungsprotokoll |
Ja |
| Offline-Erfassung |
Ja, für Basisdaten und spätere Ergänzung |
2.2 Gehört nicht zu UC01
| Bereich |
Zuständiger UC |
| Externe TÜV-Inspektion einreichen |
UC02 |
| Füll-Abo & Füllkarten-Verwaltung |
UC03 |
| Inhouse-Service durchführen |
UC04 |
| Fristen-Dashboard |
UC05 |
| Kundenportal |
UC06 |
| Benachrichtigungen |
UC07 |
| Berichte & Export |
UC09 |
| Equipment-Verleih |
Eigenes späteres Modul, noch nicht nummeriert |
2.3 Fachliche Leitentscheidung
UC01 ist die stabile Core-Basis. Neue Ausrüstungstypen erweitern UC01 über typabhängige Zusatzdaten, ohne die Basis-Erfassung selbst zu ersetzen oder zu duplizieren.
Beispiel:
Equipment
├── Gemeinsame Basisdaten
├── Optionale typabhängige Zusatzdaten
└── Spätere Workflows auf Basis des Equipment-Datensatzes
3. Ablaufbeschreibung
Status: Entwurf. Die Detailabläufe werden in einem nächsten Schritt weiter ausgearbeitet.
3.1 Happy Path – Equipment erfassen
1. Benutzer öffnet Equipment-Bereich.
2. Benutzer klickt auf "Neues Equipment erfassen".
3. System zeigt Basisformular an.
4. Benutzer wählt Equipment-Typ aus.
5. System zeigt allgemeine Basisfelder an.
6. System zeigt bei Bedarf typabhängige Zusatzfelder an.
7. Benutzer erfasst Basisdaten.
8. Benutzer wählt Zuordnung: intern, Kunde oder unbestimmt.
9. Benutzer ordnet bei Bedarf einen Kunden zu.
10. Benutzer ergänzt Foto, Notizen und Standort, falls verfügbar.
11. Benutzer speichert den Datensatz.
12. System validiert Pflichtfelder und Eindeutigkeit.
13. System setzt Datenqualität auf `complete`, `incomplete` oder `needs_review`.
14. System legt Equipment-Datensatz tenant-isoliert an.
15. System schreibt Audit-Informationen.
16. Benutzer sieht Bestätigung und Equipment-Detailansicht.
3.2 Alternative Pfade
| ID |
Situation |
Verhalten |
| A1 |
Benutzer bricht Erfassung ab |
Kein Datensatz wird gespeichert |
| A2 |
Seriennummer ist im Tenant beim gleichen Equipment-Typ bereits vorhanden |
System zeigt Validierungsfehler |
| A3 |
Kunde ist noch nicht vorhanden |
Benutzer speichert mit Zuordnung unassigned oder startet Kundenanlage |
| A4 |
Typabhängige Zusatzdaten fehlen |
Datensatz wird mit data_quality_status = incomplete gespeichert |
| A5 |
Foto wird nicht hochgeladen |
Equipment kann ohne Foto gespeichert werden |
| A6 |
Equipment-Typ ist nicht passend |
Benutzer kann Equipment-Typ vor dem Speichern ändern |
| A7 |
Passender Equipment-Typ existiert nicht |
Benutzer wählt other und erfasst freie Typbezeichnung |
| A8 |
Equipment-Typ ist zunächst unbestimmt |
Datensatz erhält unbestimmten Typ und Zufalls-ID; Workflow-Nutzung ist blockiert |
| A9 |
Erfassung erfolgt offline |
Datensatz wird lokal gespeichert und später synchronisiert |
3.3 Fehlerfälle
| ID |
Fehler |
Verhalten |
| F1 |
Pflichtfeld fehlt |
Formular-Fehler mit konkretem Hinweis |
| F2 |
Benutzer hat keine Berechtigung |
Zugriff verweigert |
| F3 |
Tenant ist deaktiviert |
Speichern wird blockiert |
| F4 |
Seriennummer verletzt Eindeutigkeitsregel |
Speichern wird blockiert |
| F5 |
Datenbankfehler beim Speichern |
System zeigt Fehlermeldung und schreibt System-Log |
| F6 |
Tenant-Isolation verletzt |
Zugriff wird technisch blockiert |
| F7 |
Offline-Konflikt nach Synchronisierung |
Datensatz erhält sync_status = conflict und muss geprüft werden |
4. Geschäftsregeln
| ID |
Regel |
| G1 |
Jedes Equipment gehört genau zu einem Tenant |
| G2 |
Equipment wird über eine UUID identifiziert |
| G3 |
Keine sequenziellen IDs in URLs |
| G4 |
Equipment-Typ ist Pflicht, ausser bei bewusster Erfassung als unbestimmt |
| G5 |
Bei unbestimmtem Equipment-Typ wird eine systemseitige Zufalls-ID erzeugt |
| G6 |
Ein unbestimmter Equipment-Typ darf keinem spezifischen Workflow zugeordnet werden |
| G7 |
Workflows auf Basis reiner Equipment-Basisdaten können später gesondert erlaubt werden |
| G8 |
Seriennummer oder Inventarnummer ist erforderlich, sobald das Equipment qualifiziert erfasst wird |
| G9 |
Seriennummer soll pro Tenant und Equipment-Typ eindeutig sein |
| G10 |
Für other muss eine freie Typbezeichnung gepflegt werden |
| G11 |
Hersteller und Modell sind empfohlene Basisfelder |
| G12 |
Kundenbezug ist optional |
| G13 |
Zuordnung muss internal, customer oder unassigned sein |
| G14 |
Mitarbeiter-Equipment wird über Kundendatensatz mit besonderem Merkmal abgebildet |
| G15 |
Status ist Pflicht und startet standardmässig mit active, sofern fachlich passend |
| G16 |
Datenqualität ist Pflicht und startet je nach Vollständigkeit mit complete, incomplete oder needs_review |
| G17 |
Equipment mit data_quality_status = incomplete darf nicht für spezifische Workflows genutzt werden |
| G18 |
Typabhängige Zusatzdaten erweitern die Basis-Erfassung |
| G19 |
Workflow-Logik gehört nicht in UC01 |
| G20 |
Equipment darf später von anderen Use Cases referenziert werden |
| G21 |
Änderungen werden auditierbar gespeichert |
| G22 |
Soft-Delete / Archivierung ersetzt physisches Löschen |
| G23 |
Offline-Erfassung muss bei der Feldstruktur berücksichtigt werden |
| G24 |
Notizen werden strukturiert mit Datum/Zeit und Benutzerbezug erfasst |
| G25 |
Zustand im Verleih wird nicht als einfacher Stammdatenwert behandelt, sondern bei Ausgabe und Rückgabe gesondert protokolliert |
5. Betroffene Datenbank-Tabellen
| Tabelle |
Operation |
Zweck |
equipment |
INSERT / UPDATE / READ |
Generische Equipment-Basisdaten |
customers |
READ |
Optionale Kundenzuordnung |
cylinder_details |
INSERT / UPDATE / READ |
Typabhängige Zusatzdaten für Flaschen, sofern im UC01-Flow erfasst |
regulator_details |
INSERT / UPDATE / READ |
Typabhängige Zusatzdaten für Atemregler, sofern im UC01-Flow erfasst |
audit_log |
INSERT |
Änderungsprotokoll |
access_log |
INSERT |
Lesezugriffe, falls aktiviert |
system_log |
INSERT |
Technische Fehler |
equipment_notes |
INSERT / READ |
Strukturierte Notizen mit Datum/Zeit und Benutzerbezug, falls als eigene Tabelle umgesetzt |
equipment_identifiers |
INSERT / READ |
QR-Code und spätere Kennzeichnungen, falls als eigene Tabelle umgesetzt |
5.1 Datenmodell-Prinzip
Die Tabelle equipment ist die stabile Basis. Detailtabellen oder flexible Zusatzdaten hängen am Equipment-Datensatz.
equipment
├── cylinder_details
├── regulator_details
├── custom_data
├── equipment_notes
├── equipment_identifiers
└── spätere Detailstrukturen
5.2 Entscheidungen
| ID |
Entscheidung |
Status |
| DM1 |
V1 nutzt ein Hybrid-Modell aus equipment, wichtigen Detailtabellen und custom_data |
Festgelegt |
| DM2 |
Nicht jeder Equipment-Typ erhält automatisch eine eigene Detailtabelle |
Festgelegt |
| DM3 |
Alle vorgeschlagenen Pflicht- und Empfehlungsfelder werden in UC01 übernommen |
Festgelegt |
| DM4 |
Eigene Equipment-Typen werden für spätere Ausbaustufe vorbereitet, aber in V1 nicht frei durch Tenants angelegt |
Festgelegt |
5.3 Hybrid-Modell
UC01 nutzt in V1 das Hybrid-Modell:
| Bereich |
Umsetzung |
| Gemeinsame Basisdaten |
Feste Felder in equipment |
| Wichtige prüf- oder service-relevante Typen |
Eigene Detailtabellen, z. B. cylinder_details, regulator_details |
| Seltene oder zunächst weniger kritische Typen |
Flexible Zusatzdaten über custom_data |
| Spätere SaaS-Ausbaustufe |
Konfigurierbare Equipment-Typen und eigene Zusatzfelder |
5.4 V1-Equipment-Typen
| Technischer Typ |
Anzeigename |
V1 |
Hinweis |
cylinder |
Tauchflasche |
Ja |
Zentral für TÜV, Fristen, Bestand |
regulator |
Atemregler |
Ja |
Zentral für Service und Inhouse-Wartung |
bcd |
Jacket / BCD |
Ja |
Häufiges Schul- und Verleihmaterial |
computer |
Tauchcomputer |
Ja |
In Schulung und Verleih relevant |
suit |
Tauchanzug |
Ja |
Verleih- und Schulbetrieb |
mask |
Maske |
Ja |
Häufiges Verleihmaterial |
fins |
Flossen |
Ja |
Häufiges Verleihmaterial |
compass |
Kompass |
Ja |
Ausbildung / Navigation |
lamp |
Lampe |
Ja |
Verleih, Nacht- und Spezialtauchgänge |
weight |
Blei / Bleisystem |
Ja |
Praxisnah, besonders für Verleih und Schulbestand |
smb |
Boje / SMB |
Ja |
Ausbildungsrelevant |
other |
Sonstiges |
Ja |
Auffangtyp für seltene Fälle |
5.5 Basisfelder für alle Equipment-Typen
| Feld |
Pflicht in V1 |
Bemerkung |
| Equipment-Typ |
Ja |
Zentrale Klassifikation; Ausnahme: bewusst unbestimmt |
| Anzeigename |
Ja |
Für Listen, Suche und Praxisbetrieb |
| Zuordnungstyp |
Ja |
internal, customer, unassigned |
| Status |
Ja |
Fachlicher Equipment-Status |
| Datenqualität |
Ja |
complete, incomplete, needs_review |
| Seriennummer oder Inventarnummer |
Ja |
Mindestens eines von beiden, sobald qualifiziert erfasst |
| Tenant-ID |
Ja |
Systemseitig |
| UUID |
Ja |
Systemseitig |
| Erfassungsdatum |
Ja |
Systemseitig |
| Erfasst durch |
Ja |
Systemseitig |
| Hersteller |
Nein, empfohlen |
Für Suche und Identifikation wichtig |
| Modell |
Nein, empfohlen |
Für Suche und Identifikation wichtig |
| Kunde |
Nur bei Zuordnung customer |
Sonst leer |
| Standort / Lagerort |
Nein, empfohlen |
Für internes Equipment und Verleih wichtig |
| Foto |
Nein, empfohlen |
Ein Hauptfoto in V1 vorgesehen |
| Notizen |
Nein, empfohlen |
Strukturiert mit Datum/Zeit und Benutzerbezug |
| Kaufdatum |
Nein, empfohlen |
Garantie, Historie, Bestand |
| Zustand |
Nein, empfohlen |
Stammdaten-Zustand; Verleih-Zustand wird zusätzlich pro Ausgabe/Rückgabe protokolliert |
| Farbe / Kennzeichnung |
Nein, empfohlen |
Praktisch für Lager und Verleih |
5.6 Notizen
Notizen sollen nicht nur als einzelnes Freitextfeld geführt werden. Sinnvoll ist eine strukturierte Notizhistorie.
Empfohlenes Modell:
| Feld |
Bedeutung |
equipment_id |
Bezug zum Equipment |
note_text |
Inhalt der Notiz |
created_at |
Datum/Zeit der Notiz |
created_by |
Benutzer, der die Notiz erstellt hat |
note_type |
Optional: allgemein, Zustand, Servicehinweis, Verleihhinweis, Prüfung |
Vorteile:
| Vorteil |
Erklärung |
| Nachvollziehbarkeit |
Es ist klar, wer wann was notiert hat |
| Kein Überschreiben |
Frühere Notizen bleiben erhalten |
| Praxisnah |
Hinweise aus Lager, Werkstatt oder Verleih bleiben historisch sichtbar |
| Audit-nah |
Ergänzt Audit-Log um fachliche Kommentare |
5.7 Zustand und späterer Verleih
Das Feld condition kann einen aktuellen Stammdaten-Zustand abbilden, zum Beispiel neu, gut, gebraucht, beschädigt, prüfen.
Für Verleih ist zusätzlich ein eigener Zustandsverlauf nötig. Der Zustand bei Ausgabe und Rückgabe darf nicht nur den Stammdatensatz überschreiben, sondern muss pro Verleihvorgang protokolliert werden.
Beispiel für späteres Verleih-Modul:
| Zeitpunkt |
Beispiel |
| Ausgabe |
Zustand: gut, Foto vor Ausgabe, Notiz: kleine Gebrauchsspuren |
| Rückgabe |
Zustand: beschädigt, Foto nach Rückgabe, Notiz: Schnalle defekt |
Vorteil: Der Tenant kann später nachvollziehen, ob ein Schaden bereits vor Ausgabe vorhanden war oder bei Rückgabe neu festgestellt wurde.
6. API-Endpunkte (Planung)
| Methode |
Endpoint |
Akteur |
Beschreibung |
GET |
/equipment |
tenant_admin, mitarbeiter |
Equipment-Liste abrufen |
POST |
/equipment |
tenant_admin, mitarbeiter |
Neues Equipment erfassen |
GET |
/equipment/:id |
tenant_admin, mitarbeiter |
Equipment-Detail anzeigen |
PATCH |
/equipment/:id |
tenant_admin, mitarbeiter |
Equipment bearbeiten |
DELETE |
/equipment/:id |
tenant_admin |
Equipment archivieren oder soft-deleten |
GET |
/equipment/types |
tenant_admin, mitarbeiter |
Verfügbare Equipment-Typen abrufen |
GET |
/customers/search |
tenant_admin, mitarbeiter |
Kunden für Zuordnung suchen |
POST |
/equipment/:id/photo |
tenant_admin, mitarbeiter |
Hauptfoto hochladen oder ersetzen |
POST |
/equipment/:id/notes |
tenant_admin, mitarbeiter |
Strukturierte Notiz ergänzen |
GET |
/equipment/:id/notes |
tenant_admin, mitarbeiter |
Notizhistorie anzeigen |
GET |
/equipment/:id/qrcode |
tenant_admin, mitarbeiter |
QR-Code-Daten abrufen oder erzeugen |
7. Entscheidungen und offene Fragen
| ID |
Frage |
Entscheidung / Status |
| OE1 |
Welche Equipment-Typen sind in V1 auswählbar? |
Festgelegt gemäss V1-Katalog in 5.4 |
| OE2 |
Ist ein Kunde bei der Erfassung Pflicht oder optional? |
Optional; Zuordnung über internal, customer, unassigned |
| OE3 |
Gilt Eindeutigkeit der Seriennummer pro Tenant oder pro Tenant + Equipment-Typ? |
Pro Tenant + Equipment-Typ; Sonderlogik für other und unbestimmt |
| OE4 |
Welche Basisfelder sind für alle Equipment-Typen Pflicht? |
Festgelegt gemäss 5.5 |
| OE5 |
Welche typabhängigen Felder werden in V1 direkt im Formular angeboten? |
Festgelegt gemäss 7.1 |
| OE6 |
Wird Foto-Upload in V1 umgesetzt oder nur vorbereitet? |
In V1 als einfaches Hauptfoto umsetzen, falls technisch ohne grossen Zusatzaufwand möglich |
| OE7 |
Werden Barcode, QR-Code oder NFC bereits in V1 vorbereitet? |
QR-Code vorbereiten; NFC nicht in V1 |
| OE8 |
Darf Equipment ohne vollständige Detaildaten gespeichert werden? |
Ja, mit data_quality_status = incomplete und completion_notes |
| OE9 |
Wie werden retired, inactive, archived und deleted fachlich getrennt? |
Festgelegt gemäss 7.4 |
| OE10 |
Welche Aktionen müssen offline möglich sein? |
Basis-Erfassung, Bearbeitung, Foto und spätere Ergänzung sollen offline möglich sein |
| OE11 |
Equipment-Verleih wieder aufnehmen? |
Ja, als eigenes späteres Modul, nicht als UC03 |
7.1 Typabhängige Felder in V1
Tauchflasche
| Feld |
V1 |
| Material |
Ja |
| Volumen in Liter |
Ja |
| Arbeitsdruck bar |
Ja |
| Gewinde |
Ja |
| Ventiltyp / Ventilform |
Ja |
| Letzte Prüfung |
Ja |
| Nächste Prüfung |
Ja |
| Normreferenz |
Ja |
| Prüfstelle |
Optional |
| Markierung / Stempel |
Optional |
Atemregler
| Feld |
V1 |
| Anzahl Stufen |
Ja |
| Anschluss DIN / INT |
Ja |
| Letzte Revision |
Ja |
| Nächste Revision |
Ja |
| Serviceintervall Monate |
Ja |
| Seriennummer 1. Stufe |
Falls getrennt relevant |
| Seriennummer 2. Stufe |
Optional |
| Oktopus vorhanden |
Optional |
Jacket / BCD
| Feld |
V1 |
| Grösse |
Ja |
| Typ, z. B. ADV, Wing, Reisejacket |
Ja |
| Auftriebsklasse / Volumen |
Optional |
| Letzte Sichtprüfung |
Optional |
| Inflator-Service |
Optional |
Tauchcomputer
| Feld |
V1 |
| Batterietyp |
Ja |
| Luftintegration |
Ja/Nein |
| Sender vorhanden |
Ja/Nein |
| Firmware-Version |
Optional |
| Letzte Batterieprüfung |
Optional |
Tauchanzug
| Feld |
V1 |
| Typ: Nass, Halbtrocken, Trocken |
Ja |
| Grösse |
Ja |
| Dicke mm |
Ja |
| Schnitt / Passform |
Optional |
| Zustand |
Optional |
Maske
| Feld |
V1 |
| Grösse / Passform |
Optional |
| Optische Gläser |
Ja/Nein |
| Dioptrien |
Falls optische Gläser |
| Farbe / Kennzeichnung |
Optional |
Flossen
| Feld |
V1 |
| Grösse |
Ja |
| Typ: Geräteflosse / Vollfussflosse |
Ja |
| Farbe / Kennzeichnung |
Optional |
Kompass
| Feld |
V1 |
| Bauform: Handgelenk / Konsole / Retractor |
Ja |
| Zustand |
Optional |
Lampe
| Feld |
V1 |
| Akkutyp |
Ja |
| Ladegerät vorhanden |
Ja/Nein |
| Leistung / Lumen |
Optional |
| Letzte Ladeprüfung |
Optional |
7.2 Equipment-Typ other und unbestimmter Typ
Wenn der passende Equipment-Typ in V1 nicht existiert, gilt:
- Benutzer wählt
other.
- Benutzer erfasst eine freie Typbezeichnung, z. B. Scooter, Analyzer, Stage Rigging.
- System speichert den Datensatz mit
equipment_type = other.
- Die freie Typbezeichnung wird zusätzlich gespeichert.
- Später kann daraus ein offizieller Equipment-Typ werden.
Wenn selbst der Typ noch nicht bestimmbar ist, kann das Equipment als unbestimmt erfasst werden.
Vorschlag für unbestimmtes Equipment:
| Feld |
Wert |
equipment_type |
unknown oder interner Platzhalter |
temporary_identifier |
Zufalls-ID / temporäre Inventarnummer |
data_quality_status |
incomplete |
workflow_eligible |
Nein |
completion_notes |
Freitext zur späteren Klärung |
Bewertung der Zufalls-ID-Variante
| Aspekt |
Bewertung |
| Vorteil |
Sehr praxisnah für schnelle Lagererfassung, wenn Typ oder Seriennummer noch nicht klar ist |
| Vorteil |
Verhindert Blockade bei Massenerfassung oder schlechter Lesbarkeit |
| Vorteil |
Datensatz kann später sauber qualifiziert werden |
| Nachteil |
Temporäre Datensätze können Dubletten erzeugen |
| Nachteil |
Workflows müssen zuverlässig blockiert werden |
| Nachteil |
Späterer Bereinigungsprozess ist zwingend nötig |
Empfohlene Regel:
Ein unbestimmtes Equipment darf gespeichert, fotografiert, kommentiert und später ergänzt werden. Es darf aber keinem spezifischen Workflow zugeordnet werden, solange kein qualifizierter Equipment-Typ und keine ausreichende Identifikation vorhanden sind.
Mögliche Alternative:
| Alternative |
Bewertung |
| Erfassung nur mit gültigem Typ erlauben |
Höhere Datenqualität, aber weniger praxisnah im Lager |
Immer other statt unknown verwenden |
Einfacher, aber fachlich unschärfer |
| Temporärer Erfassungsmodus / Inventurmodus |
Sehr praxisnah, aber für V1 eventuell zusätzlicher Aufwand |
Empfehlung für V1:
other für bekannten, aber nicht katalogisierten Typ.
unknown oder temporärer Inventurmodus für noch nicht bestimmbaren Typ.
7.3 QR-Code, Barcode und NFC
Für V1 wird QR-Code vorbereitet. NFC wird in V1 nicht umgesetzt.
QR-Code in V1
| Funktion |
V1 |
| QR-Code-ID je Equipment vorbereiten |
Ja |
| QR-Code in Detailansicht anzeigen |
Optional |
| QR-Code als Etikett / PDF exportieren |
Später oder V1.1 |
| QR-Code scannen und Equipment öffnen |
Wenn einfach möglich, sonst V1.1 |
| NFC |
Nein |
NFC-Bewertung für Tauchequipment
NFC kann grundsätzlich für Ausrüstung sinnvoll sein, aber nicht als V1-Startpunkt.
| Punkt |
QR-Code |
NFC |
| Kosten |
Sehr niedrig |
Höher wegen Tags |
| Umsetzung |
Einfach |
Aufwendiger |
| Lesegerät |
Smartphone-Kamera reicht |
Smartphone mit NFC nötig |
| Sichtbarkeit |
Sichtbar und kontrollierbar |
Unsichtbar, Tag muss gezielt platziert sein |
| Unterwasser-Nutzung |
QR unter Wasser nur eingeschränkt sinnvoll |
NFC unter Wasser ebenfalls nicht als Primärszenario sinnvoll |
| Druck / Wasser |
Etikett muss mechanisch robust sein |
Tag muss wasserdicht und druckbeständig eingebettet oder verklebt sein |
| Vorteil |
Einfach, günstig, gut für Lager und Verleih |
Robust, wenn Tag geschützt verbaut ist; keine Sichtlinie nötig |
| Nachteil |
Kann verkratzen oder verschmutzen |
Tag kann ausfallen, Position muss bekannt sein, höhere Kosten |
Empfehlung:
QR-Code in V1 vorbereiten. NFC frühestens später prüfen, wenn robuste, wasserdichte und druckgeeignete Tags für den konkreten Einsatz wirtschaftlich sinnvoll sind.
7.4 Status, Datenqualität und Löschung
Fachlicher Status und Datenqualität werden getrennt geführt.
| Feld |
Zweck |
Werte |
equipment_status |
Fachlicher Nutzungsstatus |
active, inactive, retired, archived |
data_quality_status |
Vollständigkeit / Prüfreife der Daten |
complete, incomplete, needs_review |
deleted_at |
Technisches Soft-Delete |
Zeitstempel oder leer |
Fachliche Bedeutung
| Status |
Bedeutung |
Sichtbar? |
Änderbar? |
Für Workflows nutzbar? |
active |
In Betrieb / nutzbar |
Ja |
Ja |
Ja, wenn Datenqualität complete |
inactive |
Vorübergehend nicht in Nutzung |
Ja |
Ja |
Nein oder eingeschränkt |
retired |
Dauerhaft ausgemustert |
Ja |
Eingeschränkt |
Nein |
archived |
Historisch aufbewahrt |
Nur mit Filter |
Nein oder stark eingeschränkt |
Nein |
deleted |
Soft-deleted / gelöscht markiert |
Normal nicht sichtbar |
Nein |
Nein |
Datenqualität
| Status |
Bedeutung |
Darf gespeichert werden? |
Darf in spezifische Workflows? |
complete |
Alle für den Typ nötigen Daten vorhanden |
Ja |
Ja |
incomplete |
Daten fehlen noch |
Ja |
Nein |
needs_review |
Datensatz muss geprüft werden |
Ja |
Nein oder eingeschränkt |
Zusätzlich wird completion_notes geführt, damit klar ist, welche Angaben später ergänzt oder geprüft werden müssen.
7.5 Offline-Regel
Offline-Erfassung ist für UC01 praxisrelevant. Neues Equipment soll direkt vor Ort, z. B. im Lager, Keller, Schulungsraum, Kompressorraum oder am Tauchplatz, erfasst werden können.
| Aktion |
Offline in V1 |
Bemerkung |
| Neues Equipment erfassen |
Ja |
Auch unvollständig |
| Basisdaten bearbeiten |
Ja |
Spätere Synchronisierung |
| Foto aufnehmen |
Ja |
Lokal zwischenspeichern |
| Kunde zuordnen |
Eingeschränkt |
Nur aus lokal synchronisierter Kundenliste |
Zuordnung unassigned speichern |
Ja |
Wichtig für Praxisbetrieb |
| Typabhängige Daten ergänzen |
Ja |
Soweit Formular lokal verfügbar |
| QR-Code scannen |
Ja |
Wenn Code lokal auflösbar ist |
| Workflows starten |
Eher nein |
Nur bei vollständigem und synchronisiertem Equipment |
| Löschen / Archivieren |
Eher online |
Wegen Konfliktrisiko |
Empfohlenes Feld:
sync_status = local_only | pending_sync | synced | conflict
8. Schema-Delta
Status: Noch nicht final. Erst nach technischer Prüfung festlegen.
Aktueller Zielzustand:
equipment bleibt generische Core-Tabelle.- Typabhängige Daten werden entweder über Detailtabellen oder
custom_data ergänzt.
- UC01 erzeugt keine Workflow-Logik.
- Spätere UC referenzieren Equipment über
equipment.id.
- Datenqualität und Workflow-Fähigkeit werden explizit abgebildet.
- QR-Code wird vorbereitet.
- Foto-Upload für ein Hauptfoto wird in V1 angestrebt.
- Strukturierte Notizen werden fachlich empfohlen.
Mögliche spätere Ergänzungen:
| Feld / Struktur |
Zweck |
Status |
assignment_type |
Zuordnung: intern, Kunde, unbestimmt |
Für V1 prüfen |
display_name |
Anzeigename für Listen und Suche |
Für V1 prüfen |
inventory_number |
Interne Inventarnummer |
Für V1 prüfen |
location |
Lagerort / Standort |
Für V1 prüfen |
condition |
Aktueller Stammdaten-Zustand |
Für V1 prüfen |
data_quality_status |
Vollständigkeit / Prüfreife |
Für V1 übernehmen |
completion_notes |
Hinweise zu fehlenden Daten |
Für V1 übernehmen |
workflow_eligible |
Darf für spezifische Workflows genutzt werden |
Prüfen, ggf. berechnet |
sync_status |
Offline-Synchronisationsstatus |
Für V1 prüfen |
qr_code_value |
QR-Code-Wert |
Für V1 prüfen |
equipment_type_label |
Freie Bezeichnung bei other |
Für V1 prüfen |
temporary_identifier |
Zufalls-ID für unbestimmtes Equipment |
Für V1 prüfen |
equipment_notes |
Strukturierte Notizhistorie |
Empfohlen |
equipment_identifiers |
QR, Barcode, NFC, externe Referenzen |
Prüfen |
equipment_photos |
Mehrere Fotos pro Equipment |
Später |
equipment_type_config |
Konfigurierbare Equipment-Typen je Tenant oder systemweit |
V2-Kandidat |
equipment_custom_fields |
Eigene Zusatzfelder |
V2-Kandidat |
9. Abhängigkeiten
| Abhängigkeit |
Typ |
Status |
| Authentifizierung |
Technisch |
Offen |
| Tenant-Isolation / RLS |
Technisch |
Offen |
| Prisma-Schema |
Technisch |
Vorhanden, zu prüfen |
| Equipment-Core-Tabelle |
Datenmodell |
Vorhanden, zu prüfen |
| Kundenverwaltung |
Fachlich |
Für Kundenzuordnung nötig |
| Upload-/Storage-Konzept |
Technisch |
Nötig für Hauptfoto |
| Offline-Sync |
Technisch |
Zu berücksichtigen |
| QR-Code-Erzeugung |
Technisch |
Für V1 vorbereiten |
| Späteres Verleih-Modul |
Fachlich |
Als eigenes Modul vormerken |
10. Screen-Flow & Wireframes
Status: Offen. Vorschlag für erste Screen-Struktur.
| Screen |
Bezeichnung |
Akteur |
Status |
| EQ-01 |
Equipment-Liste |
tenant_admin, mitarbeiter |
Offen |
| EQ-02 |
Neues Equipment erfassen |
tenant_admin, mitarbeiter |
Offen |
| EQ-03 |
Equipment-Detail |
tenant_admin, mitarbeiter |
Offen |
| EQ-04 |
Equipment bearbeiten |
tenant_admin, mitarbeiter |
Offen |
| EQ-05 |
Kunde zuordnen / wechseln |
tenant_admin, mitarbeiter |
Offen |
| EQ-06 |
Equipment archivieren |
tenant_admin |
Offen |
| EQ-07 |
Notiz erfassen |
tenant_admin, mitarbeiter |
Offen |
| EQ-08 |
Foto erfassen / ersetzen |
tenant_admin, mitarbeiter |
Offen |
| EQ-09 |
QR-Code anzeigen |
tenant_admin, mitarbeiter |
Offen |
| EQ-10 |
Unvollständige Datensätze prüfen |
tenant_admin, mitarbeiter |
Offen |
10.1 UI-Prinzip
Die Erfassung soll zuerst die gemeinsame Basis zeigen. Nach Auswahl des Equipment-Typs werden passende Zusatzfelder eingeblendet.
1. Basisdaten
2. Zuordnung
3. Typabhängige Zusatzdaten
4. Standort, Zustand, Foto, Notizen
5. Datenqualität prüfen
6. Speichern
11. Testing
11.1 Test-Kategorien
| Kategorie |
Tool |
Umfang |
| Unit-Tests |
Jest |
Validierung, Eindeutigkeit, Rollenlogik |
| Integration-Tests |
Jest + Supertest |
API-Endpunkte für Equipment |
| E2E-Tests |
Cypress |
Equipment erfassen, bearbeiten, anzeigen |
| Sicherheits-Tests |
Manuell / automatisiert |
Tenant-Isolation, Rollenprüfung, UUID-Zugriff |
| Offline-Tests |
Cypress / manuell |
Lokale Erfassung, Sync-Status, Konflikte |
11.2 Pflicht-Testfälle (Planung)
| ID |
Testfall |
Typ |
| T01 |
Mitarbeiter erfasst neues Equipment mit Basisdaten |
E2E |
| T02 |
Tenant-Admin erfasst Equipment und ordnet Kunden zu |
E2E |
| T03 |
Doppelte Seriennummer beim gleichen Equipment-Typ wird blockiert |
Integration |
| T04 |
Benutzer ohne Berechtigung darf kein Equipment erfassen |
Sicherheit |
| T05 |
Tenant A sieht Equipment von Tenant B nicht |
Sicherheit |
| T06 |
Equipment ohne Pflichtfeld wird als unvollständig gespeichert oder abgelehnt, je nach Feldregel |
Unit |
| T07 |
Equipment-Typ steuert Zusatzfelder korrekt |
E2E |
| T08 |
Equipment kann archiviert, aber nicht physisch gelöscht werden |
Integration |
| T09 |
UUID-Routing funktioniert ohne sequenzielle IDs |
Sicherheit |
| T10 |
Audit-Log wird bei Änderung geschrieben |
Integration |
| T11 |
Unvollständiges Equipment ist nicht workflow-fähig |
Integration |
| T12 |
Equipment mit unbestimmtem Typ erhält temporäre ID |
Integration |
| T13 |
Strukturierte Notiz speichert Datum/Zeit und Benutzer |
Integration |
| T14 |
Hauptfoto kann gespeichert und ersetzt werden |
E2E |
| T15 |
QR-Code-Wert wird erzeugt oder abgerufen |
Integration |
| T16 |
Offline erfasstes Equipment erhält Sync-Status |
Offline |
12. Änderungshistorie
13. Was in CLAUDE.md übernommen wird
In CLAUDE.md übernehmen
- UC01 = Equipment erfassen
- UC01 ist die generische Equipment-Basis für alle equipmentbezogenen Use Cases
- Typabhängige Zusatzdaten erweitern UC01, ersetzen die Basis-Erfassung aber nicht
- V1 nutzt ein Hybrid-Modell aus
equipment, wichtigen Detailtabellen und custom_data
- V1-Equipment-Typen: Tauchflasche, Atemregler, Jacket / BCD, Tauchcomputer, Tauchanzug, Maske, Flossen, Kompass, Lampe, Blei / Bleisystem, Boje / SMB, Sonstiges
- Equipment-Zuordnung: intern, Kunde oder unbestimmt
- Unvollständige Equipment-Datensätze sind speicherbar, aber nicht für spezifische Workflows nutzbar
- QR-Code wird in V1 vorbereitet; NFC nicht in V1
- Equipment-Verleih wird als eigenes späteres Modul vorgemerkt
- Workflow-Logik bleibt in separaten UC-Spezifikationen
Nicht in CLAUDE.md übernehmen
- Detaillierte Ablaufbeschreibungen
- Vollständige Geschäftsregeln
- Testfälle
- Screen-Flow-Details