UC04 – Inhouse-Service erfassen
Stand: 01.08.2026 14:55
Branch: docs/einheitliche-kopfbereiche
Status: Spezifikation
| Datum, Uhrzeit |
Version |
Änderung |
Autor |
| 01.08.2026 14:55 |
0.1 |
Kopfbereich vereinheitlicht |
David Mittig |
Spezifikationsdatei – Leitdokument für Entwicklung, Testing und Abnahme
Review: offen
Status-Übersicht
| Schritt |
Bezeichnung |
Status |
Kommentar |
| 1 |
Steckbrief |
✅ Erstellt |
fachlicher Rahmen für UC04 definiert |
| 2 |
Scope & Abgrenzung |
✅ Erstellt |
einfacher V1-Inhouse-Service abgegrenzt |
| 3 |
Rollenmodell |
✅ Erstellt |
tenant_admin und mitarbeiter beschrieben |
| 4 |
Serviceobjekte |
🟡 In Bearbeitung |
Regler, Jacket und weitere Equipment-Typen vorbereitet |
| 5 |
Statusmodell |
🟡 In Bearbeitung |
einfacher Workflowstatus beschrieben |
| 6 |
Datenmodell-Vorbereitung |
🟡 In Bearbeitung |
Prisma-Zielschema v3 konzeptionell ausreichend |
| 7 |
Screen-Flow IS-01 bis IS-08 |
⬜ Offen |
Screen-Dokumente noch nicht erstellt |
| 8 |
Review / Quality Gate |
⬜ Offen |
GEM-Review später durchführen |
Legende: ✅ Erstellt | 🟡 In Bearbeitung | 🔴 Blockiert | ⬜ Offen
1. Steckbrief
| Feld |
Inhalt |
| UC-ID |
UC04 |
| Name |
Inhouse-Service erfassen |
| Version |
V1 MVP |
| Zielgruppe |
Tauchschule |
| Primärakteur |
mitarbeiter |
| Sekundärakteur |
tenant_admin |
| Betroffener Akteur |
kunde |
| Systemakteur |
Workflow- und Fristenlogik |
| Reifegrad V1 |
fachliche Spezifikation gestartet |
| Priorität |
Hoch |
1.1 Ziel
UC04 ermöglicht Tauchschulen, intern durchgeführte Servicearbeiten an Equipment zu erfassen, zu dokumentieren und nachvollziehbar abzuschliessen.
Der Fokus von V1 liegt auf einem einfachen, praxistauglichen Inhouse-Service-Workflow. Besonders relevant sind Atemregler, Jackets / BCDs und weitere Equipment-Typen, die von der Tauchschule selbst geprüft, gewartet oder intern bearbeitet werden.
UC04 ergänzt UC01 Equipment erfassen und liefert Serviceinformationen für UC05 Fristen-Dashboard.
2. Gesicherte fachliche Grundlage
| Punkt |
Status |
| UC04 ist in der Roadmap als V1-Use-Case vorgesehen |
gesichert |
| Name laut Roadmap |
Inhouse-Service erfassen |
| Primärer fachlicher Zweck |
interne Servicearbeiten dokumentieren |
| Hauptbezug |
Equipment, Reglerdetails, Workflow, Workflow-Historie |
| V1-Abdeckung im Prisma-Zielschema v3 |
konzeptionell abbildbar |
| Eigene Service-Checklisten-Tabelle |
nicht vorhanden |
| Ersatzteile / Arbeitspositionen |
nicht V1-abgebildet |
| Dokumente / Fotos |
bewusst späterer Umfang |
3. Scope & Abgrenzung
3.1 Gehört zu UC04 V1
| Bereich |
Enthalten |
| Inhouse-Service für vorhandenes Equipment starten |
Ja |
| Service an Atemreglern erfassen |
Ja |
| Service an Jacket / BCD vorbereiten |
Ja |
| Service an sonstigem Equipment vorbereiten |
Ja |
| Kunde / Eigentümer anzeigen |
Ja |
| zuständigen Mitarbeiter zuweisen |
Ja |
| Status eines Servicevorgangs pflegen |
Ja |
| Ergebnisdatum erfassen |
Ja |
| Ergebnisnotiz erfassen |
Ja |
| Kostenbetrag erfassen |
Ja |
| Währung erfassen |
Ja |
| Servicehistorie je Equipment anzeigen |
Ja |
| Fristenbezug für nächsten Service vorbereiten |
Ja |
| Auditierbare Änderungen |
Ja |
| Korrekturhinweis bei abgeschlossenen Vorgängen |
Ja, vorbereitet |
3.2 Gehört nicht zu UC04 V1
| Bereich |
Hinweis |
| vollständige Service-Checklisten je Hersteller |
später prüfen |
| Ersatzteilverwaltung |
nicht V1 |
| Arbeitspositions- / Materialkalkulation |
nicht V1 |
| Rechnungsstellung |
nicht Bestandteil von UC04 V1 |
| Dokument-Upload von Servicebelegen |
späterer Umfang |
| Foto-Upload zum Service |
späterer Umfang |
| automatische Herstellerintervall-Datenbank |
nicht V1 |
| externe Prüfstellen-Integration |
nicht UC04 |
| TÜV-Inspektion von Flaschen |
UC02 |
| Equipment-Stammdatenerfassung |
UC01 |
| Fristen-Dashboard |
UC05 |
| Kundenportal-Anzeige |
UC06 |
| Benachrichtigungsversand |
UC07 |
4. Bezug zu anderen Use Cases
| UC |
Bezug |
| UC01 – Equipment erfassen |
liefert Equipment-Stammdaten, Typ, Kunde und Reglerdetails |
| UC02 – TÜV-Inspektion einreichen |
fachlich getrennt: externe Flaschenprüfung statt interner Service |
| UC03 – Füll-Abo & Füllkarten-Verwaltung |
kein direkter V1-Bezug |
| UC05 – Fristen-Dashboard |
zeigt kommende, laufende und überfällige Servicefristen |
| UC06 – Kunden einladen & Portal |
kann später Serviceinformationen reduziert anzeigen |
| UC07 – Benachrichtigungen |
nutzt Servicefristen später als Auslöser |
| UC08 – Benutzerverwaltung |
regelt Benutzer und Rollen für Servicebearbeitung |
| UC09 – Berichte & Export |
kann Servicehistorien und Listen später exportieren |
5. Rollenmodell V1
| Rolle |
Bedeutung für UC04 |
tenant_admin |
sieht alle Inhouse-Servicevorgänge des eigenen Tenants, darf Vorgänge prüfen, korrigieren und auswerten |
mitarbeiter |
startet, bearbeitet und schliesst Servicevorgänge operativ ab |
kunde |
ist betroffener Equipment-Eigentümer, nutzt in UC04 aber keine interne Ansicht |
superadmin |
kein Zielnutzer des Tenant-Serviceprozesses |
| System |
speichert Workflowstatus, Historie, Fristenbezug und Auditinformationen |
5.1 Rollenrechte V1
| Aktion |
tenant_admin |
mitarbeiter |
kunde |
| Serviceübersicht öffnen |
Ja |
Ja |
Nein |
| Servicevorgang starten |
Ja |
Ja |
Nein |
| Servicevorgang bearbeiten |
Ja |
Ja |
Nein |
| Mitarbeiter zuweisen |
Ja |
Ja / offen |
Nein |
| Service abschliessen |
Ja |
Ja |
Nein |
| Kosten erfassen |
Ja |
Ja / offen |
Nein |
| abgeschlossenen Vorgang korrigieren |
Ja |
Nein / offen |
Nein |
| Servicehistorie anzeigen |
Ja |
Ja |
Nein |
| Export auslösen |
Ja / später |
Nein / offen |
Nein |
6. Serviceobjekte V1
6.1 Unterstützte Equipment-Typen
| Equipment-Typ |
V1-Status |
Hinweis |
| Atemregler |
Ja |
über Reglerdetails fachlich am besten abbildbar |
| Jacket / BCD |
Ja, einfach |
ohne eigene Detailtabelle, über Equipment und Notizen |
| Tauchcomputer |
vorbereitet |
einfacher Service- oder Prüfhinweis möglich |
| Sonstiges Equipment |
vorbereitet |
über generische Inhouse-Service-Notiz |
| Tauchflasche |
Nein für UC04-Kern |
Flaschenprüfung gehört primär zu UC02 |
6.2 Regler-Service
Für Atemregler können vorhandene Reglerdetails genutzt werden.
| Information |
V1-Nutzung |
| Anzahl Stufen |
anzeigen / prüfen |
| Anschlussart DIN / INT |
anzeigen |
| Seriennummer erste Stufe |
anzeigen |
| Seriennummer zweite Stufe |
anzeigen |
| Oktopus vorhanden |
anzeigen |
| letzter Service |
anzeigen / aktualisieren |
| nächster Service |
berechnen / setzen |
| Serviceintervall Monate |
Grundlage für nächste Frist |
6.3 Jacket / BCD-Service
Für Jackets / BCDs gibt es in V1 keine eigene Detailtabelle. Die Erfassung erfolgt daher einfach über Equipment, Workflow, Ergebnisnotiz und Servicefrist.
Beispielhafte Notiz:
Inflator geprüft, Dichtheit geprüft, Ablassventile geprüft, Sichtprüfung durchgeführt.
Diese Notiz ist bewusst nicht als verpflichtende Hersteller-Checkliste zu verstehen.
7. Vorbedingungen und Nachbedingungen
7.1 Vorbedingungen
| ID |
Vorbedingung |
| UC04-VB01 |
Tenant existiert und ist aktiv |
| UC04-VB02 |
Benutzer ist authentifiziert |
| UC04-VB03 |
Benutzer gehört zum Tenant |
| UC04-VB04 |
Benutzer hat Rolle tenant_admin oder mitarbeiter |
| UC04-VB05 |
Equipment existiert im eigenen Tenant |
| UC04-VB06 |
Equipment ist nicht archiviert oder gelöscht |
| UC04-VB07 |
Kunde / Eigentümer ist vorhanden, falls das Equipment kundenbezogen ist |
7.2 Nachbedingungen
| ID |
Nachbedingung |
| UC04-NB01 |
Servicevorgang ist gespeichert |
| UC04-NB02 |
Workflowstatus ist nachvollziehbar dokumentiert |
| UC04-NB03 |
Workflow-Historie enthält Statusänderungen |
| UC04-NB04 |
Ergebnisdatum und Ergebnisnotiz sind gespeichert, falls Service abgeschlossen wurde |
| UC04-NB05 |
Kosten sind gespeichert, falls erfasst |
| UC04-NB06 |
nächste Servicefrist ist vorbereitet oder aktualisiert |
| UC04-NB07 |
Audit-Log enthält relevante Änderungen |
8. Fachliche Ablaufbeschreibung
8.1 Servicevorgang starten
1. Benutzer öffnet die Inhouse-Service-Übersicht.
2. Benutzer wählt Equipment oder scannt später optional einen QR-Code.
3. System zeigt Equipment, Kunde, Equipment-Typ und vorhandene Serviceinformationen.
4. Benutzer startet neuen Inhouse-Service.
5. Benutzer wählt Serviceart, zuständigen Mitarbeiter und optional geplantes Datum.
6. System legt einen Workflow mit Status offen / in Bearbeitung an.
7. System schreibt den ersten Eintrag in die Workflow-Historie.
8.2 Servicevorgang bearbeiten
1. Benutzer öffnet einen laufenden Servicevorgang.
2. Benutzer ergänzt Notizen, Zwischenergebnis oder Kosten.
3. Benutzer ändert bei Bedarf den Status.
4. System speichert jede relevante Statusänderung in der Workflow-Historie.
5. System stellt sicher, dass nur Daten des eigenen Tenants verändert werden.
8.3 Service abschliessen
1. Benutzer öffnet den laufenden Servicevorgang.
2. Benutzer erfasst Ergebnisdatum und Ergebnisnotiz.
3. Benutzer bestätigt den Abschluss.
4. System setzt den Workflow auf abgeschlossen.
5. System aktualisiert bei Bedarf letzter Service und nächste Servicefrist.
6. System sperrt den abgeschlossenen Workflow gegen unbemerkte Änderung.
7. Korrekturen erfolgen später nur mit Korrekturhinweis.
8.4 Service nicht bestanden / Nacharbeit
1. Benutzer markiert den Service als nicht bestanden oder Nacharbeit erforderlich.
2. Benutzer erfasst eine Pflichtnotiz.
3. System kennzeichnet den Vorgang als offen für Nacharbeit.
4. Equipment kann fachlich als gesperrt oder prüfbedürftig markiert werden, sofern diese Statuslogik im Equipment-Core vorgesehen ist.
5. UC05 kann den Vorgang später als kritisch oder laufend anzeigen.
9. Statusmodell V1
9.1 Serviceworkflow-Status
| Status |
Bedeutung |
draft |
vorbereitet, noch nicht aktiv gestartet |
open |
Servicevorgang ist eröffnet |
in_progress |
Service wird bearbeitet |
waiting_for_parts |
wartet auf Teile oder Rückmeldung, V1 optional |
rework_required |
Nacharbeit erforderlich |
completed |
Service abgeschlossen |
cancelled |
Vorgang abgebrochen |
corrected |
abgeschlossener Vorgang wurde fachlich korrigiert |
9.2 Serviceergebnis
| Ergebnis |
Bedeutung |
passed |
Service erfolgreich abgeschlossen |
failed |
Service nicht bestanden |
rework_required |
Nacharbeit erforderlich |
not_applicable |
Ergebnis nicht anwendbar |
cancelled |
Vorgang abgebrochen |
Hinweis: Falls das vorhandene Prisma-Statusmodell weniger Werte enthält, ist für V1 eine saubere Abbildung auf die vorhandenen Enum-Werte erforderlich.
10. Fachliche Regeln
| ID |
Regel |
| UC04-R01 |
Ein Inhouse-Service darf nur für Equipment des eigenen Tenants erfasst werden |
| UC04-R02 |
Ein Servicevorgang benötigt immer einen Equipment-Bezug |
| UC04-R03 |
Ein Servicevorgang benötigt einen verantwortlichen Benutzer oder einen Ersteller |
| UC04-R04 |
Regler-Service nutzt vorhandene Reglerdetails, sofern vorhanden |
| UC04-R05 |
Jacket- und sonstiger Service werden in V1 über generische Workflowdaten und Notizen abgebildet |
| UC04-R06 |
Ergebnisnotiz ist bei Abschluss verpflichtend |
| UC04-R07 |
Ergebnisdatum ist bei Abschluss verpflichtend |
| UC04-R08 |
Kostenangaben sind optional, aber bei Erfassung mit Währung zu speichern |
| UC04-R09 |
Statusänderungen werden historisiert |
| UC04-R10 |
Abgeschlossene Vorgänge dürfen nicht still überschrieben werden |
| UC04-R11 |
Korrekturen benötigen einen Korrekturhinweis |
| UC04-R12 |
Servicefristen müssen tenant-isoliert berechnet oder gespeichert werden |
| UC04-R13 |
UC04 versendet in V1 keine Benachrichtigungen selbst |
| UC04-R14 |
UC04 erzeugt keine Rechnung |
| UC04-R15 |
UC04 ersetzt keine normativ relevante externe Flaschenprüfung |
11. Datenmodell-Vorbereitung
11.1 Benötigte Datenobjekte
| Bedarf |
Datenobjekt / Feld |
V1-Bewertung |
| Equipment-Stammdatensatz |
Equipment |
vorhanden |
| Reglerdetails |
RegulatorDetails |
vorhanden |
| Workflow |
UsecaseWorkflow |
vorhanden |
| Workflow-Typ Regler-Service |
regulator_service |
vorhanden |
| Workflow-Typ Inhouse-Service |
inhouse_service |
vorhanden |
| Workflow-Historie |
WorkflowHistory |
vorhanden |
| ausführender Mitarbeiter |
assignedToId |
vorhanden |
| Ergebnisnotiz |
resultNotes |
vorhanden |
| Ergebnisdatum |
resultDate |
vorhanden |
| Kostenbetrag |
costAmount |
vorhanden |
| Währung |
costCurrency |
vorhanden |
| Sperr- / Korrekturlogik |
isLocked, correctionOfId, correctionNote |
vorhanden |
| Audit |
AuditLog |
vorhanden |
11.2 Kein eigenes V1-Objekt
| Objekt |
Entscheidung |
| Service-Checklisten |
nicht V1 |
| Ersatzteile |
nicht V1 |
| Arbeitspositionen |
nicht V1 |
| Dokumente |
späterer Umfang |
| Fotos |
späterer Umfang |
| Hersteller-Servicekatalog |
nicht V1 |
12. Sicherheits- und Zugriffsregeln
| ID |
Regel |
| UC04-SEC-R01 |
Tenant-Isolation ist zwingend |
| UC04-SEC-R02 |
Ein Tenant sieht nur eigene Equipment-, Kunden- und Workflowdaten |
| UC04-SEC-R03 |
Kunde sieht UC04 nicht direkt |
| UC04-SEC-R04 |
superadmin greift nicht operativ in Tenant-Servicevorgänge ein |
| UC04-SEC-R05 |
Abgeschlossene Vorgänge sind gegen unbemerkte Änderung zu schützen |
| UC04-SEC-R06 |
Korrekturen sind auditierbar zu speichern |
| UC04-SEC-R07 |
Kostenfelder dürfen nur berechtigten Rollen angezeigt oder bearbeitet werden, falls diese Einschränkung später festgelegt wird |
13. Screen-Flow IS-01 bis IS-08
| Screen |
Bezeichnung |
Zweck |
| IS-01 |
Inhouse-Service-Übersicht |
Liste laufender, geplanter und abgeschlossener Servicevorgänge |
| IS-02 |
Servicevorgang starten |
Equipment auswählen und Service eröffnen |
| IS-03 |
Servicevorgang Detail |
Status, Kunde, Equipment, Notizen und Verlauf anzeigen |
| IS-04 |
Service bearbeiten |
Notizen, Status, Mitarbeiter und Kosten pflegen |
| IS-05 |
Service abschliessen |
Ergebnis, Datum, nächste Frist und Abschluss bestätigen |
| IS-06 |
Nacharbeit / nicht bestanden |
Nacharbeit erfassen und Risiko sichtbar machen |
| IS-07 |
Servicehistorie je Equipment |
vergangene Servicevorgänge anzeigen |
| IS-08 |
Korrektur abgeschlossener Service |
Korrektur mit Pflichtgrund dokumentieren |
14. Akzeptanzkriterien UC04 V1
| ID |
Kriterium |
| UC04-AC01 |
tenant_admin kann Inhouse-Servicevorgänge des eigenen Tenants sehen |
| UC04-AC02 |
mitarbeiter kann Inhouse-Servicevorgänge des eigenen Tenants sehen |
| UC04-AC03 |
Benutzer kann für vorhandenes Equipment einen Servicevorgang starten |
| UC04-AC04 |
System speichert Equipment-Bezug, Kunde, Ersteller und Status |
| UC04-AC05 |
Benutzer kann einen laufenden Servicevorgang bearbeiten |
| UC04-AC06 |
System historisiert relevante Statusänderungen |
| UC04-AC07 |
Benutzer kann Ergebnisdatum und Ergebnisnotiz erfassen |
| UC04-AC08 |
Benutzer kann einen Servicevorgang abschliessen |
| UC04-AC09 |
System schützt abgeschlossene Vorgänge vor unbemerkter Änderung |
| UC04-AC10 |
Korrekturen benötigen einen Pflichtgrund |
| UC04-AC11 |
Kosten können optional mit Währung erfasst werden |
| UC04-AC12 |
Servicehistorie je Equipment ist abrufbar |
| UC04-AC13 |
UC04 verändert keine Daten fremder Tenants |
| UC04-AC14 |
UC04 löst in V1 keine Benachrichtigung direkt aus |
| UC04-AC15 |
UC04 erzeugt in V1 keine Rechnung |
15. Offene Fragen / Restentscheidungen
| ID |
Frage |
Vorschlag / Status |
| UC04-O01 |
Soll Jacket / BCD in V1 aktiv unterstützt oder nur vorbereitet werden? |
Vorschlag: einfacher V1-Service über Notizmodell |
| UC04-O02 |
Gibt es eine verpflichtende Standard-Service-Checkliste für Regler? |
offen, aktuell nicht V1 |
| UC04-O03 |
Darf mitarbeiter Kosten erfassen? |
offen |
| UC04-O04 |
Darf mitarbeiter abgeschlossene Vorgänge korrigieren? |
Vorschlag: Nein, tenant_admin |
| UC04-O05 |
Wird waiting_for_parts in V1 benötigt? |
optional |
| UC04-O06 |
Wird bei nicht bestandenem Service Equipment automatisch gesperrt? |
offen, abhängig vom Equipment-Statusmodell |
| UC04-O07 |
Wird nächste Servicefrist automatisch aus Intervall berechnet oder manuell gesetzt? |
Vorschlag: automatische Vorbelegung, manuell prüfbar |
| UC04-O08 |
Sollen Servicekosten später an UC09 Export übergeben werden? |
Ja, vorbereitet |
| UC04-O09 |
Sollen Hersteller- oder Modell-spezifische Serviceintervalle gepflegt werden? |
nicht V1 |
| UC04-O10 |
Wird ein QR-Code-Einstieg in UC04 V1 benötigt? |
sinnvoll, abhängig von UC01 |
16. Nächster Schritt
Als nächstes sollten die Screen-Vorgaben unter folgendem Ordner angelegt werden:
docs/developer/uc04/screens/
Start mit:
IS-01 – Inhouse-Service-Übersicht
Je Screen werden analog zu den bestehenden UC-Ordnern drei Dateien vorbereitet:
17. Review-Hinweise
Für den späteren UC04-Review sind insbesondere folgende GEM-Rollen relevant:
| GEM |
Grund |
| GEM01 Software-Architekt |
Workflow- und Modulabgrenzung prüfen |
| GEM03 Compliance-Wächter |
Dokumentations- und Nachweispflichten prüfen |
| GEM04 Norm & Compliance Engine |
Abgrenzung zu TÜV- und Servicepflichten prüfen |
| GEM05 Mobile-Workflow-Expert |
Bedienung am Equipment und QR-Code-Einstieg prüfen |
| GEM09 UX/UI Designer |
Service-Flow und Screen-Logik prüfen |
| GEM12 Security-Experte |
Rollen, Tenant-Isolation und Korrekturschutz prüfen |
| GEM13 Datenbank-Administrator |
Workflow-, Historien- und Korrekturmodell prüfen |
| GEM14 Dokumentations-Manager |
Konsistenz zu Roadmap, UC05 und Index prüfen |