Hypersoft Verfahren für Zahlungsart ändern

Im Hypersoft // System gibt es die Funktionen Zahlungsart ändern und Zahlungsart modifizieren. Beide agieren im Sinn dieser Beschreibung gleich. Das Ändern der Zahlungsarten wird vom POS System bzw- dem (technisch identischen) Subsystem eines mPOS Systems ausgeführt, somit bezieht sich die Beschreibung Zahlungsart ändern auf beide Begriffe. Das Ändern einer Zahlungsart kommt zum Beispiel häufig vor, wenn man einem Kunden einen Rechnung im Standard in Bar vorlegt und dieser dann bargeldlos bezahlt. Selbst wenn der Bediener wüsste, dass der Kunde (im Full-Service am Tisch) bargeldlos bezahlen möchte, kann er diesem kein vervollständigen Zahlungsbeleg vorlegen, da erst beim tatsächlichen bargeldlosen Bezahlen die  Zahlungsart (giropay, Mastercard etc.) feststeht und aus Sicherheitsgründen in der Regel automatisiert im dem Zahlungsterminal die Zahlung verbucht wird.

Beispiele für Signierungen aus der Full-Service Praxis

Ein Beispiel für Zahlungsart ändern:

  1. Ein Kunde verlangt im Full Service die Rechnung. TSE wird signiert, Beleg erstellt.

  2. Der Kunde sagt beim Vorliegen der Rechnung am Tisch, dass er bargeldlos zahlen möchte. Der Bediener informiert, dass er nun das Zahlungsterminal holt.

  3. Der Bediener nutzt die Funktion Zahlungsart ändern, da sich die Artikelbuchungen nicht mehr verändern. Das Payment erhält einen Gegenbuchung (Stornierung), da die Barzahlung nicht erfolgte.

  4. Das Payment wird erneut, aber diesmal auf Bargeldlose Zahlung abgeschlossen. In unserem Beispiel mit einem angeschlossenen Zahlungsterminal mit der Variante Zahlung im Hintergrund.  Die TSE Signierung erfolgt auf unbar, damit ein Beleg erstellt werden kann.

  5. Beim Gast erfolgt die Zahlung bargeldlos inkl. Trinkgeld, die TSE Signierung wird gegengebucht, eine neue TSE Signierung erfolgt als unbare Zahlung inkl. Trinkgeld. Der über die spezielle Methode bei Zahlung im Hintergrund noch verfügbare Vorgang erhält die Trinkgeldzahlung als Buchung. Das Trinkgeld wird im Payment mit der Gesamtsumme auf das entsprechende /SchemeGeschlossen Die Scheme (gesprochen Skiem) sind die jeweiligen Kartensysteme der Inhaber wie z.B. VISA oder Mastercard. Scheme Fees sind die Gebühren, welche die Kreditkartenmarken erhalten. gebucht und der neue Zahlungsbeleg wird erstellt.

Bei einem Kunden der beim Schritt II. getrennt bezahlt werden dann entsprechend der einzelnen Zahlungen einzelne Vorgänge abgeschlossen.

Vergleichsbeispiel, bei dem mit Vorgang bearbeiten nicht nur das Payment aktualisiert wird, sondern auch alle anderen Buchungen:

  1. Ein Kunde verlangt im Full Service die Rechnung. TSE wird signiert, Beleg erstellt.

  2. Der Kunde sagt beim Vorliegen der Rechnung am Tisch, dass er bargeldlos zahlen möchte. Der Bediener informiert, dass er nun das Zahlungsterminal holt. Der Kunden bestellt bei der Gelegenheit doch noch 3 Kaffee.

  3. Der Bediener muss den Vorgang bearbeiten, da nun 3 Kaffee hinzukommen. Mit dem Bearbeiten werden die Signaturen gegengebucht. Das Hypersoft // System muss die Artikel alle gegen buchen (stornieren), da der Vorgang wieder geöffnet wird. Das Payment erhält auch eine Gegenbuchung (Stornierung), da die Barzahlung nicht erfolgte.

  4. Der Vorgang wird erneut auf Bargeldlose Zahlung abgeschlossen. In unserem Beispiel mit einem angeschlossenen Zahlungsterminal mit der Variante Zahlung im Hintergrund. Damit ein Beleg erstellt werden kann erfolgt zuvor die TSE Signierung als "unbar" (die TSE kennt die genaue Kartenzahlung nicht).

  5. Beim Gast erfolgt die Zahlung bargeldlos, die Buchungen inkl. Trinkgeld werden gebucht, die TSE Signierung der Zahlung wird erneut gegengebucht, damit eine neue TSE Signierung der Zahlung inklusive Trinkgeld auf unbar erstellt werden kann, das Payment wird mit der Gesamtsumme auf das entsprechende /SchemeGeschlossen Die Scheme (gesprochen Skiem) sind die jeweiligen Kartensysteme der Inhaber wie z.B. VISA oder Mastercard. Scheme Fees sind die Gebühren, welche die Kreditkartenmarken erhalten. gebucht und der neue Zahlungsbeleg wird erstellt.

Der Kunde könnte auch Trinkgeld in Bar geben und diese kann nachträglich hinzugebucht werden.

Weiterführende Dokumentation:

Hypersoft Verfahren für Zahlungsterminals

Hypersoft Verfahren mit Trinkgeldbuchungen

Vorgang bearbeiten aus fiskalischer Sicht

Payment Datenbank bei Zahlungsart ändern

Die ursprüngliche (originale) Buchungen bleiben erhalten und werden mit einem Satz Buchungen und der Nummer (NH_GVNO+1) gegengebucht, um den Wert der ursprüngliche Buchung zu neutralisieren. Anschließend wird unter der (NH_GVNO+2) ein neuer Payment Datensatz mit der aktualisierten Zahlungsart erneut gebucht:

 

Die Transaction Datenbank erhält diese NH_GVNO Nummer als die aktuelle NH_GVNO-Nummer:

Im Journal wird ein Datensatz zu dem Bestehenden Vorgang (TransactionID) dazu gebucht, (Trinkgeld Nachträglich mit der entsprechenden Summe) diese erhält die neue NH_GVNO Nummer:

In der AddOn Tabelle wird die Signierung zu den jeweiligen NH_GVNO nummern gespeichert:

ID 28 – NH_GVNO = 0 die ursprüngliche Signierung

ID 29 – NH_GVNO = 1 die Neutralisierung (Stornierung) der ursprünglichen Signierung.

ID 30 _ NH_GVNO = 2 die neue Signierung mit der neuer Zahlungsart.

In der Info Tabelle wird der Vorgang (Zahlung Modifizieren oder Zahlungsart ändern) dokumentiert:

Status = 20 = Zahlungsart ändern

Status= 23 = Zahlung modifizieren

IntVal1 = Datum der Aktion

IntVal2 = Zeit der Aktion

IntVal3 = SigTransNo aus der TSE für die Signierung der Neutralisierung

IntVal4 = SigTransNo aus der TSE für die neue Signierung

DblVal3 = TSE-ID der Neutralisierung (gehört zu IntVal3 TSE Einheit der Neutralisierung)

DblVal4 = TSE-ID der Neu Signierung (gehört zu IntVal4 TSE Einheit der Neusignierung)

NH_GVNO = Geschäftsvorfall Nummer

Payment Datenbank und Journal bei Vorgang bearbeiten

Transaction Datenbank:

Nach dem wieder öffnen des Vorgangs, entsteht eine Gutschrift und es werden die Artikel gegengebucht. Es gibt also einen ursprünglichen Vorgang und einen Vorgang der Gegenbuchungen. Beide Vorgänge werden mit gegenseitigem Verweis in der Spalte RefID markiert. Der Vorgang ist nun wieder als offener Vorgang im System und dieser wird erneut nach Abschluss eingefügt:

Payment Datenbank:

Nach wieder öffnen wird auch im Payment die Gutschrift erzeugt und dann wird mit dem erneuten Abschluss des Vorgangs erneut ein Payment Datensatz erzeugt. In diesem Fall wurde Trinkgeld dazu gebucht und der Vorgang auf Kredit abgeschlossen:

Verkettungen zur Nachvollziehbarkeit des tatsächlichen Abschlusses...

Wenn das Hypersoft // System Vorgänge gegenbucht, dann stellt sich bei Prüfungen die Frage, ob (und wo genau) der Vorgang dann wirklich abgeschlossen wurde. Vom Programmkonzept muss der Vorgang erneut abgeschlossen werden, hier zeigen wir die Verkettung dieser Vorgänge zur Nachvollziehbarkeit auf.

Im Journal werden die Buchungen entsprechend storniert und erneut gebucht. Bei dem zweiten Vorgang ist in der Spalte NH_RefID ersichtlich, welcher Vorgang der Ursprung war. Das Trinkgeld, welches nachgebucht wurde, ist auch ersichtlich, da dabei kein NH_RefID enthalten ist.

Die Spalte InterfaceRef_aus_D_Trn ist hier nur informative dargestellt. Die Werte befinden sich in der D_Transaction Tabelle:

In der AddOn Tabelle wird die Signierung der einzelnen Vorgänge gespeichert:

Weiterführende Dokumentation:

Zahlungsart Modifikationsreport

Fraud Protection mit Hypersoft Trace

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