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 Workflow stehen  leicht unterschiedliche Wege der Absicherung über eine TSE zur Verfügung. 

Was allen gemeinsam ist: 

Nach Eingabe der Zahlart werden die Brutto-Summen und Beträge auf den Zahlarten an die TSE geschickt um diese mit dem ProcessType "Beleg" signieren zu lassen. Diese Signatur muss zusammen mit dem Vorgangsstart und Vorgangsende auf den Prüfbaren Beleg. Für die spätere, technische Implementierung kann man sich schon einmal merken, dass diese "wichtigste" Aktion dem Aufruf von finish() der Transaktion mit dem ProcessType "Beleg" entspricht. 

Wie sich die beiden Workflows unterscheiden: 

Der große Unterschied liegt im Absichern des Vorgangsstarts. Geht man von einer Kurzen Zeitspanne zwischen dem Vorgangsstart und der Zahlung (Vorgangsende) aus, so wird an der TSE mit dem Erfassen des ersten Artikels eine Transaktion in der TSE geöffnet (für später, start() aufrufen). Diese Transaktion wird so lange offen gehalten, bis die Zahlung erfolgt ist und die Rechnung gedruckt wird. Dies kann an einer Supermarktkasse durchaus auch mal ein paar (wenige) Minuten dauern. Wichtig ist, dass die Transaktion mit dem ersten Artikel gestartet wurde. 

Bei lang andauernden Bestellvorgängen wird der erste erfasste Artikel nicht mit dem ProcessType "Beleg" erfasst, sondern mit dem ProcessType "Bestellung".  Mit dem ersten Artikel wird hier in der TSE eine Transaktion mit dem ProcessType "Bestellung" eröffnet, alle Artikel aufgenommen und mit Abschluss der Bestellung an die TSE geschickt und die Transaktion abgeschlossen. Dieser Bestellvorgang stellt also eine eigene Transaktion dar. Kommt es nun zur Zahlung, so wird in diesem Moment eine Transaktion mit dem ProcessType "Beleg" an der TSE eröffnet und gleich wieder mit den relevanten Daten geschlossen. Auf dem Kassenbon steht als Start des Vorgangs der abgesicherte Startzeitpunkt der ersten Bestellung. 


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 leere Bestell-Transaktion ausführen (und auch abschließen), um die Startzeit abzusichern. An der letzten Kasse wird dann wie in der Gastronomie eine Beleg-Transaktion gestartet und abgeschlossen.


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 eine 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: