FA-10 – Korrektur / Storno
Stand: 12.10.2026 11:23
Branch: main
Status: erster Vorschlag
Änderungshistorie anzeigen
Use Case: UC03 – Füll-Abo & Füllkarten-Verwaltung
Screen: FA-10
Wireframe
Zum Vergrössern auf das Bild klicken; es öffnet sich in voller Grösse.
1. Zweck
FA-10 dient zur fachlich korrekten Korrektur oder Stornierung bereits erfasster Buchungen eines Füllkontos.
Der Screen ist bewusst streng geregelt, da synchronisierte Ledger-Einträge nicht direkt verändert werden dürfen. Fehlerhafte Buchungen werden stattdessen über neue Gegenbuchungen oder Korrekturbuchungen fachlich berichtigt.
FA-10 ist damit der kontrollierte Korrekturpfad für UC03.
2. Primäre Nutzer
| Rolle |
Nutzung |
mitarbeiter |
darf fehlerhafte Buchungen stornieren oder korrigieren |
tenant_admin |
prüft Sonderfälle, Konflikte und fachlich heikle Korrekturen |
kunde |
keine direkte Nutzung |
3. Einstieg / Auslöser
| Einstieg |
Beschreibung |
| FA-08 |
Korrektur / Storno aus Kundenhistorie |
| FA-09 |
Korrektur / Storno aus Füllkonto-Historie |
| FA-03 |
Korrekturpfad aus Detailansicht |
| Prüffall |
nach Feststellung einer Fehlbuchung |
4. Fachliche Grundregel
Für UC03 gilt:
Bereits synchronisierte Ledger-Einträge werden nicht verändert.
Fehler werden über reverse oder correction berichtigt.
| Typ |
Bedeutung |
reverse |
ursprüngliche Buchung soll fachlich vollständig aufgehoben werden |
correction |
ursprüngliche Buchung bleibt historisch bestehen, wird aber durch eine Korrekturbuchung angepasst |
5.1 Ursprungsbuchung
| Feld |
Beschreibung |
| Füllkonto |
betroffene Karte / Abo / Punktekarte |
| Kunde |
zugeordneter Kunde |
| Datum / Zeit |
Zeitpunkt der Ursprungsbuchung |
| Buchungstyp |
z. B. consume, topup, bonus |
| Gasart |
Luft, Nitrox-Variante |
| Wert |
gebuchter Verbrauch oder Guthabenwert |
| Saldo vorher |
Guthaben vor Ursprungsbuchung |
| Saldo nachher |
Guthaben nach Ursprungsbuchung |
| Auslöser |
Mitarbeiter, Kunde, Self-Service |
| Status |
gebucht, pending_sync, conflict, storniert, korrigiert |
5.2 Korrekturbereich
| Feld |
Beschreibung |
Pflicht |
| Aktionstyp |
reverse oder correction |
Ja |
| Korrekturwert |
relevanter Wert der Gegen- oder Korrekturbuchung |
bei correction Ja |
| Begründung |
Pflichtgrund für Korrektur / Storno |
Ja |
| Bemerkung |
optionale Zusatznotiz |
Nein |
| durch Benutzer |
automatisch aus aktuellem Benutzer |
Ja |
| Datum / Zeit |
automatisch |
Ja |
5.3 Vorschau
| Feld |
Beschreibung |
| Wirkung auf Saldo |
zeigt Saldoänderung durch Korrektur |
| Bezug auf Ursprungsbuchung |
referenzierter Ledger-Eintrag |
| neuer Eintrag |
reverse oder correction |
| Audit-Hinweis |
Pflichtgrund und Benutzerstempel werden gespeichert |
6. Eingaben / Aktionen
| Aktion |
Beschreibung |
reverse wählen |
vollständige Gegenbuchung vorbereiten |
correction wählen |
fachliche Anpassung vorbereiten |
| Pflichtgrund erfassen |
Begründung der Änderung |
| Vorschau prüfen |
zeigt neue Saldenwirkung |
| Änderung bestätigen |
erzeugt neuen Ledger-Eintrag |
| Abbrechen |
ohne Änderung zurück |
| Ursprungsbuchung öffnen |
zurück zur referenzierten Buchung |
7. Validierungen / Regeln
| ID |
Regel |
| FA10-R01 |
Ursprungsbuchung wird niemals direkt geändert |
| FA10-R02 |
Korrektur oder Storno erzeugt immer einen neuen Ledger-Eintrag |
| FA10-R03 |
Pflichtgrund ist immer erforderlich |
| FA10-R04 |
Datum/Zeit und Benutzerstempel müssen immer gespeichert werden |
| FA10-R05 |
reverse hebt die Ursprungsbuchung fachlich vollständig auf |
| FA10-R06 |
correction darf nur den erforderlichen Differenzwert buchen |
| FA10-R07 |
Die neue Buchung muss auf die Ursprungsbuchung verweisen |
| FA10-R08 |
Bei pending_sync oder conflict muss klar erkennbar sein, ob eine Korrektur zulässig ist |
| FA10-R09 |
Die Saldenwirkung muss vor Bestätigung sichtbar sein |
| FA10-R10 |
Korrektur / Storno offline ist in V1 gesperrt |
8. Status- und Fehlermeldungen
| Situation |
Meldung / Darstellung |
| keine Ursprungsbuchung geladen |
„Bitte eine gültige Ursprungsbuchung auswählen.“ |
| Pflichtgrund fehlt |
„Bitte einen Grund für die Korrektur / Stornierung erfassen.“ |
| ungültiger Korrekturwert |
„Der Korrekturwert ist fachlich nicht zulässig.“ |
| Konflikt vorhanden |
„Konflikt muss vor der Korrektur geprüft werden.“ |
| Offline |
„Korrektur / Storno ist offline in V1 nicht zulässig.“ |
| erfolgreich |
„Korrektur / Storno wurde als neuer Ledger-Eintrag gespeichert.“ |
9. Bezug zu Datenmodell / Ledger
| Bereich |
Bezug |
| Füllkonto |
fill_accounts |
| Ledger |
fill_ledger_entries |
| Ursprungsbezug |
related_ledger_entry_id oder vergleichbares Feld |
| Eintragstyp |
reverse oder correction |
| Audit |
created_by, created_at, reason, note |
| Sync |
sync_status |
| Saldo |
balance_before, balance_after |
10. Self-Service-Bezug
FA-10 muss auch Buchungen korrigieren können, die kundeninitiiert oder über Self-Service ausgelöst wurden.
| Fall |
Bedeutung |
| kundeninitiierte Buchung |
Auslöser Kunde bleibt historisch sichtbar |
| Mitarbeiterbestätigung |
bestätigender Mitarbeiter bleibt sichtbar |
| fehlerhafter Self-Service-Abruf |
Korrektur erfolgt trotzdem nur über reverse oder correction |
| Audit |
ursprünglicher und korrigierender Benutzer müssen nachvollziehbar bleiben |
11. Akzeptanzkriterien
| ID |
Kriterium |
| FA10-AC01 |
Mitarbeiter kann eine Ursprungsbuchung für Korrektur oder Storno öffnen |
| FA10-AC02 |
System zeigt alle relevanten Daten der Ursprungsbuchung |
| FA10-AC03 |
Mitarbeiter kann zwischen reverse und correction wählen |
| FA10-AC04 |
Pflichtgrund ist erforderlich |
| FA10-AC05 |
System zeigt die Saldenwirkung vor Bestätigung |
| FA10-AC06 |
System erzeugt einen neuen Ledger-Eintrag statt die Ursprungsbuchung zu überschreiben |
| FA10-AC07 |
Der neue Eintrag verweist auf die Ursprungsbuchung |
| FA10-AC08 |
Audit-Daten werden gespeichert |
| FA10-AC09 |
Offline-Korrektur / -Storno ist in V1 gesperrt |
12. Offene Punkte
| ID |
Frage |
Status |
| FA10-O01 |
Darf mitarbeiter jede Buchung korrigieren oder nur bestimmte Typen? |
aktuell offen |
| FA10-O02 |
Soll bei reverse automatisch der Gegenwert vorbelegt werden? |
Vorschlag: ja |
| FA10-O03 |
Soll ein zweiter Hinweisdialog vor Bestätigung erscheinen? |
Vorschlag: ja |
| FA10-O04 |
Wie werden Konfliktfälle mit pending_sync fachlich priorisiert? |
offen |
Änderungshistorie
| Datum, Uhrzeit |
Version |
Änderung |
Autor |
| 12.10.2026 11:23 |
1.3 |
Abschnitt «Wireframe» mit klickbarem Bild des Screens ergänzt |
Claude |
| 12.10.2026 09:58 |
1.2 |
Ä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 |
1.1 |
Branch-Angabe im Kopfbereich auf main korrigiert |
Claude |
| 01.08.2026 14:55 |
1.0 |
Kopfbereich vereinheitlicht |
David Mittig |