UC02 Screen TÜV-04 – Status aktualisieren
Stand: 12.10.2026 11:23
Branch: main
Status: Entwurf
Änderungshistorie anzeigen
UC: UC02 – TÜV-Inspektion einreichen (extern)
Screen: TÜV-04 – Status aktualisieren
Wireframe
Zum Vergrössern auf das Bild klicken; es öffnet sich in voller Grösse.
1. Ziel des Screens
TÜV-04 dient dazu, den Status eines externen Prüfauftrags nachvollziehbar und auditierbar zu aktualisieren. Der Screen wird aus TÜV-03 geöffnet und schreibt bei jeder Änderung einen Eintrag in die Workflow-Historie.
Der Statuswechsel betrifft den Prüfauftrag als Ganzes. Ergebnisse einzelner Equipment-Positionen werden in TÜV-05 oder TÜV-06 erfasst.
2. Primäre Aufgaben
| Aufgabe |
Beschreibung |
| aktuellen Status anzeigen |
bisheriger Status des Prüfauftrags |
| Zielstatus wählen |
neuer Workflow-Status |
| Auswirkung anzeigen |
Sperrwirkung, nächste Aktion, Bearbeitbarkeit |
| Notiz erfassen |
fachliche Begründung / Statushinweis |
| Status speichern |
Änderung auditierbar speichern |
| Verlauf fortschreiben |
Workflow-Historie append-only ergänzen |
| Zurück zu TÜV-03 |
nach Speicherung oder Abbruch |
3. Statusmodell
| Status |
Bedeutung |
Typische Folgeaktion |
draft |
Auftrag vorbereitet, noch nicht eingereicht |
Einreichen |
submitted |
Auftrag bei Prüfstelle / Dienstleister eingereicht |
warten oder in_progress setzen |
in_progress |
Prüfung läuft oder Rückmeldung steht aus |
Ergebnis erfassen |
passed |
Auftrag abgeschlossen, alle relevanten Positionen bestanden |
TÜV-05 prüfen |
failed |
Mindestens eine Position nicht bestanden |
TÜV-06 |
rework_required |
Nacharbeit erforderlich |
TÜV-06 |
cancelled |
Auftrag storniert |
Sperren / Auswirkungen prüfen |
4. Screen-Aufbau
┌────────────────────────────────────────────────────────────┐
│ TÜV-Inspektion › Status aktualisieren │
│ [Abbrechen] [Status speichern]│
├────────────────────────────────────────────────────────────┤
│ Prüfauftrag-Kopf │
│ Aktueller Status │
│ Zielstatus wählen │
│ Auswirkungen / Sperrwirkung │
│ Pflichtnotiz / Statusnotiz │
│ Bestätigung bei kritischem Status │
└────────────────────────────────────────────────────────────┘
5. Felder
| Feld |
Pflicht |
Beschreibung |
| Prüfauftrag-ID |
Ja |
Systemseitig aus Kontext |
| aktueller Status |
Ja |
read-only |
| Zielstatus |
Ja |
Auswahl |
| Statusnotiz |
Bedingt |
Pflicht bei failed, rework_required, cancelled und Status-Rückschritten |
| Bestätigung |
Bedingt |
Pflicht bei kritischen Statusänderungen |
| geändert am |
Ja |
systemseitig |
| geändert durch |
Ja |
systemseitig |
6. Erlaubte Statuswechsel V1
| Von |
Nach |
Erlaubt? |
Hinweis |
draft |
submitted |
Ja |
Einreichung wird bestätigt |
submitted |
in_progress |
Ja |
Prüfung läuft |
submitted |
cancelled |
Ja |
Pflichtnotiz |
in_progress |
passed |
Ja |
nur wenn Ergebnisse plausibel sind |
in_progress |
failed |
Ja |
Pflichtnotiz, TÜV-06 empfohlen |
in_progress |
rework_required |
Ja |
Pflichtnotiz, TÜV-06 empfohlen |
passed |
failed |
Eingeschränkt |
nur mit Audit / Korrekturgrund |
failed |
rework_required |
Ja |
Nacharbeit konkretisieren |
rework_required |
in_progress |
Ja |
Nacharbeit erneut eingereicht |
cancelled |
anderer Status |
Eingeschränkt |
ggf. neuer Auftrag sinnvoller |
7. Auswirkungen
| Zielstatus |
Auswirkung |
submitted |
operative Nutzung der Positionen wird gesperrt oder markiert |
in_progress |
Sperrwirkung bleibt bestehen |
passed |
Sperrwirkung kann nach Ergebnisprüfung aufgehoben werden |
failed |
betroffene Positionen werden needs_review / inactive, Details in TÜV-06 |
rework_required |
betroffene Positionen bleiben gesperrt, Nacharbeit dokumentieren |
cancelled |
Sperrwirkung prüfen; Positionen ggf. wieder freigeben |
8. Validierung
| ID |
Regel |
| V01 |
Zielstatus muss vom aktuellen Status abweichen |
| V02 |
Statuswechsel muss erlaubt sein |
| V03 |
Kritische Statuswechsel benötigen Statusnotiz |
| V04 |
Kritische Statuswechsel benötigen Bestätigung |
| V05 |
Statuswechsel schreibt Workflow-Historie |
| V06 |
Ergebnisdaten einzelner Positionen werden nicht in TÜV-04 erfasst |
| V07 |
Tenant-Isolation muss eingehalten werden |
| V08 |
Abgeschlossene Ergebnisse dürfen nicht ohne Audit korrigiert werden |
9. Aktionen
| Aktion |
Rolle |
Beschreibung |
| Status speichern |
tenant_admin, mitarbeiter |
Speichert Statuswechsel und Historie |
| Abbrechen |
tenant_admin, mitarbeiter |
Zurück zu TÜV-03 ohne Änderung |
| Zu TÜV-05 |
tenant_admin, mitarbeiter |
Prüfergebnis erfassen |
| Zu TÜV-06 |
tenant_admin, mitarbeiter |
Nacharbeit / nicht bestanden dokumentieren |
| Verlauf anzeigen |
tenant_admin, mitarbeiter |
Rückkehr zu TÜV-03 |
10. Akzeptanzkriterien
| ID |
Kriterium |
| AC01 |
Benutzer sieht aktuellen Prüfauftrag und Status |
| AC02 |
Benutzer kann einen zulässigen Zielstatus auswählen |
| AC03 |
Unzulässige Statuswechsel werden blockiert |
| AC04 |
Kritische Statuswechsel verlangen eine Pflichtnotiz |
| AC05 |
Kritische Statuswechsel verlangen eine Bestätigung |
| AC06 |
Statuswechsel wird in Workflow-Historie gespeichert |
| AC07 |
Nach Speicherung kehrt Benutzer zu TÜV-03 zurück |
| AC08 |
Ergebnis je Equipment-Position wird nicht in TÜV-04 erfasst |
| AC09 |
Tenant-Isolation wird eingehalten |
| AC10 |
Sperrwirkung wird vor Speicherung angezeigt |
11. Artefakte und Querverweise
| Typ |
Datei |
| Spezifikation |
tuev-04-status-aktualisieren.md |
| Statisches Wireframe |
tuev-04-status-aktualisieren.svg |
| Interaktives Wireframe |
tuev-04-status-aktualisieren.jsx |
Querverweise:
| Ziel |
Bedeutung |
| TÜV-03 |
Prüfauftrag-Detail und Verlauf |
| TÜV-05 |
Prüfergebnis je Position erfassen |
| TÜV-06 |
Nacharbeit / nicht bestanden dokumentieren |
| EQ-03 |
Equipment-Detail der Positionen |
| UC05 |
Fristen und Sperrwirkungen sichtbar machen |
12. Offene UI-Details
| ID |
Frage |
Status |
| UI1 |
Wird TÜV-04 als Modal oder eigene Seite umgesetzt? |
Empfehlung: Modal auf Desktop, eigene Seite mobil |
| UI2 |
Werden unzulässige Zielstatus ausgeblendet oder deaktiviert? |
Empfehlung: deaktiviert mit Begründung |
| UI3 |
Soll direkt nach failed automatisch TÜV-06 geöffnet werden? |
Empfehlung: Hinweis und Button anbieten |
| UI4 |
Wie werden Status-Rückschritte dargestellt? |
Mit Warnung und Pflichtnotiz |
| UI5 |
Wer darf abgeschlossene Status korrigieren? |
Rollen-/Audit-Entscheid später prüfen |
Änderungshistorie
| Datum, Uhrzeit |
Version |
Änderung |
Autor |
| 12.10.2026 11:23 |
0.7 |
Leere Überschrift «13. Änderungshistorie» aus der Zeit vor dem einheitlichen Dokumentaufbau entfernt; Abschnitt «Wireframe» mit klickbarem Bild des Screens ergänzt |
Claude |
| 12.10.2026 11:01 |
0.6 |
Versionsnummern der Änderungshistorie chronologisch durchgehend nummeriert (4 Einträge angepasst; Datum, Änderung und Autor unverändert) |
Claude |
| 12.10.2026 10:19 |
0.5 |
Datum und Uhrzeit von 1 älteren Historieneinträgen aus der Git-Historie ergänzt (Zeitpunkt des Commits, der den Eintrag eingeführt hat) |
Claude |
| 12.10.2026 09:58 |
0.4 |
Änderungshistorie ans Dokumentende verschoben und Sprunglink «Änderungshistorie anzeigen» unter dem Kopf ergänzt (einheitlicher Dokumentaufbau gemäss AGENTS.md) |
Claude |
| 12.10.2026 09:08 |
0.3 |
Branch-Angabe im Kopfbereich auf main korrigiert |
Claude |
| 01.08.2026 14:55 |
0.2 |
Kopfbereich vereinheitlicht |
David Mittig |
| 06.05.2026 10:04 |
0.1 |
Initialer Screen-Vorschlag für TÜV-04 Status aktualisieren erstellt |
David Mittig |