Hypersoft Verfahren mit SOT

Self Order Kiosk (SOT) fiskalische Anforderungen

Das Hypersoft Programm Self Order Kiosk SOT wird für Selbstbedienungsterminals eingesetzt, wie sie in der LösungeCommerce Self-Order Kiosk (SOT) beschrieben sind. Grundsätzlich gelten auch für das SOT die Beschreibungen im Kapitel Hypersoft Verfahren im eCommerce. Die Anbindung am POS erfolgt inklusive TSE Signierung und Ausgabe der Buchungen beim KassenSichV Export nach DSFinV-K. Die Signierung erfolgt beim Aufruf der Zahlung und Übergabe an ein Zahlungsterminal.

Da am SOT die User selbst buchen, wird nicht immer und sofort alles protokolliert, was am SOT getippt wird. Wird aber eine Bestellung an das Kassensystem übermittelt, so ist diese sicher gespeichert (in Deutschland auch TSE signiert, in Österreich auch RKSV gesichert). Trotzdem bietet das Hypersoft Kassensystem alle Möglichkeiten des Storno und Trace, um Fehler und Missverständnisse von Kunden so zu behandeln, dass alles nachvollziehbar bleibt. Wenn ein Gast jedoch die bargeldlose Zahlung aufruft, muss davon ausgegangen werden, dass die Bestellung abgeschlossen ist. Nun müssen die Buchungen gesichert werden, damit die Zahlung am Zahlungsterminal ausgelöst werden kann. Aufgrund dieser Sondersituation werden die Bestellbons aber noch zurückgehalten, bis die Zahlung tatsächlich erfolgt ist. In dem Moment, in dem die Zahlung positiv bestätigt wird, werden die Buchungen sofort an die Produktionseinheiten wie Küche und Bar weitergeleitet. Kommt es zu der Situation, dass die Zahlung nicht erfolgt (Ablehnung durch das Rechenzentrum oder Abbruch durch den Benutzer), so muss der Vorgang mit dem Status Storno vor Order gegengebucht werden. Sie erhalten dann in den Auswertungen Storno vor Order Buchungen, um den steuerlichen Anforderungen gerecht zu werden. Nachfolgend erhalten Sie weitere Details und technische Hintergründe hierzu.

TSE, RKSV und unbezahlte SOT Vorgänge...

SOT Vorgänge werden im Kassenjournal abgelegt und damit auch mit der TSE bzw. der RKSV gefordert im Standard signiert. Unbezahlte SOT Vorgänge stehen dem POS System zur Verfügung, diese Buchungen und deren Storni werden darüber hinaus auch in der TSE signiert.

Ausnahme Vorgangsabbruch Am SOT...

Im Standard wird ein Vorgangsabbruch an einem Hypersoft POS System signiert und exportiert. Anders als unter Vorgangsabbruch in der Ordnungsvorschrift beschrieben, werden solche Buchungen (als Buchungen von Usern) am SOT nicht signiert und nicht exportiert. Das SOT hat einen Timer und fragt nach Ablauf dessen, "ob ein User noch am SOT da ist":

Nach einem weiteren Timer ohne Eingabe "bemerkt" das SOT , dass keine User mehr anwesend ist und der Vorgang wird zurückgesetzt. In diesem Fall wird der Vorgang nicht vorher signiert, nicht storniert und nicht gegengebucht. Hierbei betrachtet die Situation wie Buchungen eines Users im Webshop, da auch dort nicht Inhaber oder Mitarbeiter, sondern Kunden, Gäste oder User die Buchungen vornehmen, so dass auch ist kein Fraud-Motiv ursächlich oder denkbar ist. In der Praxis kommt es regelmäßig zu solchen "Spaßbuchungen", die andernfalls das TSE System und den Export unnötig belasten und verfälschen würden.

Besonderheit Zahlungsabbruch am SOT...

Wenn Buchungen zum Zahlungsterminal am SOT gesandt werden, agiert das System im Standard wie mit Zahlungsterminals im Vordergrund beschrieben. Hierfür wird im POS System beim Übergeben des Zahlungsauftrages an das Zahlungsterminal ein offener Vorgang angelegt. Kann die Zahlung durchgeführt werden, dann werden die Buchungen und die Zahlung signiert und der Beleg kann erstellt werden. Kommt es zu am Zahlungsterminal zu einem Abbruch beziehungsweise kann der Zahlungsauftrag nicht gebucht werden, erhält der User einen Abfrage am SOT:

  1. Bei erneut versuchen wird der Zahlungsauftrag erneut an das Zahlungsterminal übertragen. Der offenen Vorgang am POS System ist dann bereits vorhanden.

  2. Bei der Auswahl an der Kasse bezahlen werden die Buchungen signiert und der offene Vorgang wartet auf Bearbeitung beziehungsweise Bezahlung an der Kasse.

  3. Mit Bestellung abbrechen werden alle Buchungen im Vorgang als Storno vor Order storniert, danach werden die Buchungen und der Vorgang signiert, dies alles ergibt dann 0,- (0). Weiterführende Dokumentation: Umstellung der Stornostufe mit SP 16...

Unbezahlte SOT Vorgänge mit Status Zahlung am POS

Es in diesem Zusammenhang kommt es vor, dass die User Vorgänge mit dem Status Zahlung an der Kasse abschließen, aber der Vorgang niemals abgeschlossen und bezahlt wird, da sie mit dem Beleg nicht zur Kasse gehen. Für diesen Fall gibt es Lösungen: Natürlich können Sie die Option Zahlung an der Kasse abschalten. Andernfalls gibt es Einstellungen für die Vorgangsnummernbereich des SOT, wenn dieser mit 900000 gestartet wurde, sollten alle unbezahlten Vorgänge ab dort aufwärts vom SOT stammen. Sie können diese stornieren und abschließen.

Diese Tätigkeit lässt sich wie üblich automatisieren: Best Practice Tagesabschluss automatisieren. Die unbezahlten und damit offenen SOT Vorgänge werden hierfür wie Tischvorgänge behandelt und beim Tagesabschluss wie gewünscht ausgebucht.

Wenn Sie wie oben beschrieben die Order vor der Bezahlung auslösen und hierdurch Verluste entstehen, können Sie diese Verluste auch automatisch buchen lassen, bevor der Vorgang storniert wird. Ansonsten genügen automatische Storni vor Order zum Vorgangsabschluss.

Zahlungen vom SOT stornieren (Refund)

SOT Zahlungen sind in der Regel bargeldlose Zahlungen mit einem Zahlungsterminal, die der Kunde in einer Selbstbedienungssituation ausführt. Bei der Nachbearbeitung (Storno bzw. Refund, bzw. Rückzahlung an den Knden) bietet Hypersoft je nach Zahlungssystem unterschiedliche Lösungen an. Im Standard werden diese hier beschrieben: Bargeldlose Zahlungen am POS stornieren und bearbeiten

Umstellungen und Fehlerkorrekturen

Umstellung der Stornostufe mit SP 16...

Die automatische Stornofunktion im SOT, die bei Zahlungsabbruch oder Timeout während des Zahlungsvorgangs ausgelöst wird, wurde mit dem SP 16 vom Status Storno nach Order auf Storno vor Order geändert. Alle vorangegangenen Stornierungen dieser Art sind daher noch als Storno nach Order vorhanden.


Weiterführende Dokumentation: Hypersoft Verfahren im eCommerce

Zurück zur übergeordneten Seite: Fiskalgesetz zum Anwendungserlass zu § 146a AO