FA-07 – Verbrauch / Guthaben buchen
Stand: 12.10.2026 11:23
Branch: main
Status: erster Vorschlag
Änderungshistorie anzeigen
Use Case: UC03 – Füll-Abo & Füllkarten-Verwaltung
Screen: FA-07
Wireframe
Zum Vergrössern auf das Bild klicken; es öffnet sich in voller Grösse.
1. Zweck
FA-07 ist der verbindliche Buchungsschritt für einen Füllvorgang. Der Screen zeigt die Verbrauchsvorschau mit Restguthaben vorher und nachher, prüft Sperren und Konflikte und erzeugt nach Bestätigung die wirksame Ledger-Buchung.
FA-07 ist damit der fachlich kritische Punkt, an dem aus einem vorbereiteten Füllvorgang eine verbindliche Verbrauchsbuchung wird.
2. Primäre Nutzer
| Rolle |
Nutzung |
mitarbeiter |
prüft und bestätigt den Verbrauch im Tagesbetrieb |
tenant_admin |
kann Sonderfälle prüfen und berechtigte Korrekturwege einleiten |
kunde |
indirekt betroffen; bei Self-Service ggf. Auslöser des Abrufs |
3. Einstieg / Auslöser
| Einstieg |
Beschreibung |
| FA-04 |
Füllvorgang wurde vorbereitet |
| FA-06 |
Gasart und Verbrauchsdaten wurden erfasst |
| FA-12 |
offener Kundenabruf wurde zur Bestätigung geöffnet |
| Self-Service |
Kunde hat Abruf gestartet, Mitarbeiter bestätigt |
4.1 Kontext
| Feld |
Beschreibung |
| Kunde |
ausgewählter Kunde |
| Füllkonto |
Karte, Bonuskarte, Punktekarte oder Abo |
| Modell |
z. B. 10+3 Bonuskarte Luft |
| Status |
aktiv, pending_sync, conflict, leer, gesperrt |
| Self-Service |
mitarbeitergeführt, kundeninitiiert oder echter Self-Service |
4.2 Verbrauchsvorschau
| Feld |
Beschreibung |
| Gasart |
Luft oder Nitrox |
| Nitrox-Variante |
z. B. Nitrox 32 / 36 / 40 |
| FO₂ |
optional erfasster Sauerstoffanteil |
| Verbrauch |
Füllungen oder Punkte |
| Restguthaben vorher |
aktueller Stand vor Buchung |
| Restguthaben nachher |
Vorschau nach Buchung |
| Buchungstyp |
consume |
| Ledger-Wirkung |
Reduktion von current_balance |
4.3 Prüfhinweise
| Prüfung |
Bedeutung |
| Guthaben ausreichend |
Buchung darf nur erfolgen, wenn Verbrauch gedeckt ist |
kein pending_sync |
neue Kundenabbuchung nur ohne offene Offline-Buchungen |
| kein Konflikt |
Konflikte müssen vorher gelöst werden |
| Status aktiv |
gesperrte, leere oder abgelaufene Konten blockieren Buchung |
| Analysehinweis |
bei Nitrox optional sichtbare Analyseinformationen |
5. Eingaben / Aktionen
| Aktion |
Beschreibung |
| Buchung bestätigen |
erzeugt Ledger-Eintrag consume |
| Zurück zu FA-06 |
Verbrauchsdaten ändern |
| Als Entwurf speichern |
Füllvorgang ohne Ledger-Buchung speichern |
| Abbrechen |
Vorgang verwerfen |
| Korrekturpfad öffnen |
nur falls vor Bestätigung ein Fehler erkannt wird |
6. Verbindliche Buchungslogik
6.1 Online-Buchung
Für UC03 V1 gilt:
Online-Buchungen werden in einer Datenbank-Transaktion mit Row Lock verarbeitet.
Ablauf:
1. Füllkonto-Zeile sperren
2. aktuellen Saldo erneut prüfen
3. Verbrauch gegen verfügbares Guthaben prüfen
4. Ledger-Eintrag `consume` erzeugen
5. `current_balance` aktualisieren
6. Transaktion committen
6.2 Offline-Buchung
Offline-Buchungen werden nicht endgültig abgezogen, sondern vorgemerkt:
Offline-Buchungen erhalten `pending_sync`.
Der endgültige Abzug erfolgt erst nach Online-Abgleich, Berechnung und Prüfung.
6.3 Ledger-Regel
Bereits synchronisierte Ledger-Einträge werden nicht geändert.
Fehler werden später nur über `reverse` oder `correction` korrigiert.
7. Validierungen / Regeln
| ID |
Regel |
| FA07-R01 |
Vor Buchung muss der aktuelle Saldo serverseitig erneut geprüft werden |
| FA07-R02 |
Online-Buchungen nutzen Datenbank-Transaktion mit Row Lock |
| FA07-R03 |
Verbrauch darf das verfügbare Guthaben nicht überschreiten |
| FA07-R04 |
Bei pending_sync sind neue Kundenabbuchungen gesperrt |
| FA07-R05 |
Bei conflict ist Buchung gesperrt |
| FA07-R06 |
Gesperrte, leere oder abgelaufene Füllkonten dürfen nicht bebucht werden |
| FA07-R07 |
Nach Bestätigung wird ein Ledger-Eintrag consume erzeugt |
| FA07-R08 |
current_balance wird bei erfolgreicher Buchung synchron aktualisiert |
| FA07-R09 |
Manuelle Übersteuerungen müssen Pflichtgrund und Auditdaten enthalten |
| FA07-R10 |
Bei Self-Service mit Mitarbeiterbestätigung wird die Buchung erst nach Freigabe wirksam |
8. Status- und Fehlermeldungen
| Situation |
Meldung / Darstellung |
| Buchung möglich |
„Verbrauch kann gebucht werden.“ |
| Guthaben reicht nicht |
„Restguthaben reicht für diesen Verbrauch nicht aus.“ |
| pending_sync vorhanden |
„Nicht synchronisierte Buchungen vorhanden. Neue Abbuchung gesperrt.“ |
| Konflikt vorhanden |
„Konflikt muss vor Buchung gelöst werden.“ |
| Füllkonto gesperrt |
„Füllkonto ist gesperrt.“ |
| parallele Buchung erkannt |
„Saldo hat sich geändert. Bitte Verbrauch erneut prüfen.“ |
| Buchung erfolgreich |
„Verbrauch wurde gebucht.“ |
9. Bezug zu Datenmodell / Ledger
| Bereich |
Bezug |
| Füllkonto |
fill_accounts |
| Füllvorgang |
fill_transactions |
| Ledger-Eintrag |
fill_ledger_entries |
| Buchungstyp |
entry_type = consume |
| Saldo vorher |
balance_before |
| Saldo nachher |
balance_after |
| aktuelles Guthaben |
current_balance |
| Sync |
sync_status |
| Self-Service |
confirmation_status, confirmed_by_user_id |
| Audit |
created_by, created_at, ggf. Pflichtgrund |
10. Self-Service-Bezug
FA-07 kann eine kundeninitiierte Buchung abschliessen.
| Fall |
Bedeutung |
| kundeninitiierter Abruf |
Kunde hat Abruf gestartet, Mitarbeiter bestätigt |
| Mitarbeiterbestätigung erforderlich |
Standardmodus für V1 |
| echter Self-Service |
Buchung kann tenant-spezifisch direkt oder als pending_confirmation verarbeitet werden |
| Bestätigung abgelehnt |
keine Ledger-Buchung; Vorgang wird abgebrochen oder abgelehnt gespeichert |
11. Akzeptanzkriterien
| ID |
Kriterium |
| FA07-AC01 |
Mitarbeiter sieht Verbrauchsvorschau mit Restguthaben vorher und nachher |
| FA07-AC02 |
Mitarbeiter kann Buchung verbindlich bestätigen |
| FA07-AC03 |
System prüft vor Buchung den aktuellen Saldo erneut |
| FA07-AC04 |
System verhindert Buchung bei zu geringem Guthaben |
| FA07-AC05 |
System sperrt Buchung bei pending_sync oder conflict |
| FA07-AC06 |
System erzeugt nach Bestätigung einen Ledger-Eintrag consume |
| FA07-AC07 |
System aktualisiert current_balance synchron nach Buchung |
| FA07-AC08 |
Bei paralleler Änderung wird der Benutzer zur erneuten Prüfung aufgefordert |
| FA07-AC09 |
Kundeninitiierte Abrufe können durch Mitarbeiter bestätigt werden |
12. Offene Punkte
| ID |
Frage |
Status |
| FA07-O01 |
Wird bei erfolgreicher Buchung sofort ein Beleg / Quittung vorbereitet? |
nicht V1 |
| FA07-O02 |
Wird nach Buchung automatisch FA-08 oder FA-09 angeboten? |
Vorschlag: ja, als Schnellaktion |
| FA07-O03 |
Wie wird parallele Saldoänderung im UI genau visualisiert? |
offen |
| FA07-O04 |
Darf eine Buchung offline überhaupt bestätigt oder nur vorgemerkt werden? |
V1: nur vormerken mit pending_sync |
Ä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 |