Nach vielen Schleifen in der Abstimmung zwischen Finanzverwaltung, BMF und der DFKA-Feldtestgruppe gibt es zwei wesentliche Workflows für das Absichern von Vorgängen: 

  • Kurze Bestellvorgänge wie wir sie z.B. in der Verkehrsgastronomie oder im Einzelhandel (Stichwort Scannerkasse) haben. 
  • Länger andauernde Bestellvorgänge. Das klassische Beispiel ist hier die Vollgastronomie. Der Kellner geht mehrmals an einen Tisch, um Bestellungen aufzunehmen, der Gast verweilt über Stunden im Restaurant. 

Für beide Workflows stehen leicht unterschiedliche Wege der Absicherung über eine TSE zur Verfügung. 

Was allen gemeinsam ist: 


Das Erfassen des ersten Artikels löst den Vorgangsbeginn aus. Sie müssen also eine Transaktion in der TSE starten, aber ohne Daten. Also kein ProcessTyp und keine ProcessData. Dadurch kann man nun entscheiden, ob man diese Transaktion als Bestellung oder als Kassenbeleg absichern will.

Nun kommt es darauf an, ob es ein kurzer Bestellvorgang ist oder ein länger andauernder Bestellvorgang.


Wie sich die beiden Workflows unterscheiden: 


Kurze Bestellvorgänge

Die Transaktion wird erst mit dem Rechnungsdruck geschlossen. Es gibt also nur eine Transaktion für diesen Vorgang in der TSE. Zum Beispiel geht man in einen Supermarkt einkaufen, hat 10 Artikel, welche über die Scannerkasse geschoben werden. Mit der Erfassung des ersten Artikels wird die Transaktion ohne Daten geöffnet und beim Druck der Rechnung als Typ "Kassenbeleg-V1" + Rechnungsdaten geschlossen. 

Länger andauernde Bestellvorgänge

Die Transaktion wird mit dem Ende der Bestellung geschlossen. Das kann sein, wenn z.B. der Tischspeicher geleert wird. Es sitzen zum Beispiel zwei Personen an einem Tisch. Der Kellner kommt und nimmt den ersten Artikel auf. Daraufhin wird die Transaktion ohne Daten gestartet. Die zweite Person bestellt auch etwas, der Kellner nimmt diese auf und schließt die Bestellung ab. Nun wird die Transaktion geschlossen, als Typ "Bestellung-V1" und den Daten der zwei Artikel, so formatiert, wie in der DSFinV-K angegeben. Nun bestellen beide Kunden noch etwas. Auch hier wird die Transaktion mit dem Erfassen des ersten neuen Artikels gestartet und mit dem Abschicken der Bestellung geschlossen. Das kann beliebig oft passieren. 

Danach bezahlen die beiden Kunden. Beim Rechnungsdruck wird die Transaktion ohne Daten geöffnet und mit ProcessTyp "Kassenbeleg-V1" und den Rechnungsdaten (Steuercontainer und Zahlungsarten) geschlossen. Auch hier wieder so formatiert, wie in der DSFinV-K angegeben.


Ein Sonderfall kann beim sogenannten "Durchbedienen" auftreten. Mit Durchbedienen ist der typische Fall beim Bäcker beschrieben, bei der Verkäufer an der ersten Kasse die ersten Artikel boniert, dann zur zweiten Kasse weiter geht und die nächsten Artikel aufnimmt und an der dritten Kasse dann die Rechnung erstellt wird. 

Hier gibt es Systemarchitekturen, die mit dem eigentlich für diesen Fall gedachten Workflow ohne Bestellungen nicht umgehen könnten, da hier die erste Kasse die Transaktion bereits an der TSE eröffnen müsste, an der sie dann später auch abgeschlossen wird. Sonst würde man eine nicht abgeschlossene Transaktion erzeugen. Einige Architekturen erlauben es aber auch nicht, an jeder Kasse eine separate Bestell-Transaktion durchzuführen, da die an jeder Kasse bonierten Deltas nicht zur Verfügung stehen. 

In diesem speziellen Fall kann man an der ersten Kasse eine Transaktion vom Typen "SonstigerVorgang" ausführen, um die Startzeit abzusichern. An der letzten Kasse wird dann, wie in der Gastronomie, eine Beleg-Transaktion gestartet und abgeschlossen. Der Zusammenhang wird dann in der DSFinV-K über das Feld "ABRECHNUNGSKREIS" abgebildet.


Warum der ganze Aufwand? Man könnte doch auch einfach nur den Beleg absichern? 

Mit der Absicherung der Startzeit soll eine beliebte Manipulation unterbunden werden. Der Fall, dass ein Kunde eine Reihe von Artikeln bestellt, den zu zahlenden Betrag nur auf einem Display sieht und die Aufrechnung/der Bon anschließend in der Kasse verworfen wird, findet man leider sehr häufig. Muss man verpflichtend den Zeitpunkt der ersten Erfassung eines Artikels und das Ende des Vorgangs absichern und auf den Beleg drucken, so kann ein Prüfer leicht erkennen, ob ein Beleg erst "am Ende, falls der Kunde ihn möchte" erzeugt wurde, oder die Daten korrekterweise gleich am Anfang an die TSE geschickt wurden. Werden Belege häufig abgebrochen so fällt dies durch häufige leere Transaktionen bzw. Bestellungen ohne Beleg auf. Einer der Hauptmanipulationswege kann so unterbunden werden. 


Die drei oben beschriebenen Möglichkeiten noch einmal in einer grafischen Darstellung: