Beantwortet Kassenschnitt auf Tagesabschluss ist nicht korrekt/scheint nicht wirklich vom Terminal zu stammen

[LarsW]

Die nach Kartenart aufgeschlüsselten Zahlungen auf dem per Variable integrierten Kassenschnitt des EC-Terminals scheinen nicht wirklich aus dem EC-Terminal zu stammen, sondern einfach nur anhand der Zahlungsdaten in JTL-POS generiert zu werden. Die stimmen aber nicht notwendig überein, wenn das Terminal einen Fehler macht/einen Verbindungsfehler hat.

Bei einer Zahlung am mit OPI angeschlossenen Kartenterminal Ingenico Desk\3500 hat sich dieses aufgehängt. Die Zahlung war in JTL-POS nicht abgeschlossen. Wir haben das EC-Gerät neu gestartet und der Kunde hat die Zahlung wiederholt. Es war genau zu Ladenschluss und wir haben für den Kunden sicherheitshalber direkt überprüft, ob die Zahlung vielleicht doppelt erfolgt ist und haben direkt den Tagesabschluss durchgeführt. Auf unserem Tagesabschluss stimmten Kassenschnitt und Karten-Umsatz überein. Es sollte also nicht zu einer doppelten Buchung gekommen sein. Ist es aber doch. Der auf unser Konto für die Umsätze des fraglichen Tages übertragene Betrag weicht von dem Kassenschnitt ab und der Kunde hat entsprechend 2 Abbuchungen von uns.

Meine Vermutung ist nun, dass die mit der Variable $card_payments$ ausgegebenen Werte eben kein echter Kassenschnitt de Terminals sind, sondern lediglich die Terminal-ID gezogen wird und alle anderen Werte einfach den mit der Kasse durchgeführten Verkäufe entsprechen. Die können aber offensichtlich von der Anzahl und Summe der mit dem Terminal durchgeführten Transaktionen abweichen, wenn das Terminal einen Verbindungsfehler hat. Und es ist eben auch einfach nicht korrekt als Kassenschnitt Daten auszugeben, die offensichtlich gar nicht aus dem Terminal stammen. Das ist ja vermutlich auch nicht nur bei diesem Terminal so, sondern bei allen anderen auch, oder ist der Rückgriff auf Daten aus JTL-POS nur ein Fallback für den Fall, dass das Terminal keine Zahlungsdaten übermittelt?

 

[Shahne]

Moin moin @LarsW ,

Das ist in der Tat so gewollt, die Angaben werden aus den in der Kasse mit TSE-Signaturen signierten Bons gebildet. In der Zahlungsart über die das Terminal angebunden ist kann ein Slider gesetzt werden, der beim Kassenschnitt das übliche OPI-Kommando an's Terminal schickt einen Kassenschnitt auszugeben. Das kann entweder die JTL-POS selbst erledigen, oder dem Terminal den entsprechenden Befehl geben.

Der Tagesabschluss wird aber immer auf Basis der Buchungsdatenbank gebildet, denn nur diese haben wir nach den gängigen Maßstäben der Manipulationssicherheit entsprechend komplett mit Signaturen "abgesichert". Das Terminal nicht mit der TSE.

Natürlich führt das genau in dem Fall, dass das Terminal die Zahlung durchführt, aber uns in der Kasse nicht mehr über OPI zurückmeldet zu einer Desynchronisierung. Für diese Fälle gibt es die Möglichkeit eine extra Zahlungsart wie z.B. "Korrekturbuchung Terminal" oder "Störung OPI" anzulegen mit denselben Buchungskonten wie deine ursprüngliche Zahlungsart, nur ohne angeschlossenes Terminal, damit der Bon dann entsprechend mit dieser zweiten Zahlungsart abgeschlossen werden kann, wenn das Terminal aufgrund eines technischen Fehlers nicht antwortet.

Eine Abweichung zwischen den Werten aus deinem Terminal und der JTL-POS kann es ja aber nur genau dann geben, wenn eben bei genau diesem letzten Schritt der Zahlungsbestätigung die OPI-Verbindung abreißt und die JTL-POS die Bestätigung nie erhält. Auf anderen Wegen als einer alternativen Zahlungsart kriegen wir die dann auch nicht in diesen Bon rein, denn er muss ja immer noch TSE-signiert werden können nach der bestätigten Zahlung.

Mit freundlichen Grüßen,
Shahne

 

[LarsW]

Moin moin @LarsW ,

Das ist in der Tat so gewollt, die Angaben werden aus den in der Kasse mit TSE-Signaturen signierten Bons gebildet. In der Zahlungsart über die das Terminal angebunden ist kann ein Slider gesetzt werden, der beim Kassenschnitt das übliche OPI-Kommando an's Terminal schickt einen Kassenschnitt auszugeben. Das kann entweder die JTL-POS selbst erledigen, oder dem Terminal den entsprechenden Befehl geben.

Der Tagesabschluss wird aber immer auf Basis der Buchungsdatenbank gebildet, denn nur diese haben wir nach den gängigen Maßstäben der Manipulationssicherheit entsprechend komplett mit Signaturen "abgesichert". Das Terminal nicht mit der TSE.

Natürlich führt das genau in dem Fall, dass das Terminal die Zahlung durchführt, aber uns in der Kasse nicht mehr über OPI zurückmeldet zu einer Desynchronisierung. Für diese Fälle gibt es die Möglichkeit eine extra Zahlungsart wie z.B. "Korrekturbuchung Terminal" oder "Störung OPI" anzulegen mit denselben Buchungskonten wie deine ursprüngliche Zahlungsart, nur ohne angeschlossenes Terminal, damit der Bon dann entsprechend mit dieser zweiten Zahlungsart abgeschlossen werden kann, wenn das Terminal aufgrund eines technischen Fehlers nicht antwortet.

Eine Abweichung zwischen den Werten aus deinem Terminal und der JTL-POS kann es ja aber nur genau dann geben, wenn eben bei genau diesem letzten Schritt der Zahlungsbestätigung die OPI-Verbindung abreißt und die JTL-POS die Bestätigung nie erhält. Auf anderen Wegen als einer alternativen Zahlungsart kriegen wir die dann auch nicht in diesen Bon rein, denn er muss ja immer noch TSE-signiert werden können nach der bestätigten Zahlung.

Mit freundlichen Grüßen,
Shahne

Danke für die Erklärung. So ganz kann ich ihr allerdings nicht folgen. Ich bin ja eigentlich verpflichtet die Kassenschnitte des Karten-Terminals 10 Jahre aufzubewahren. Der von JTL-POS ausgegebene "Kassenschnitt" ist wiederum offensichtlich kein echter Kassenschnitt. Damit komme ich der Verpflichtung nicht nach. Und gerade so wie es ist sind Abweichungen zur TSE eben nicht erkennbar, ohne das man die eigehenden Zahlungen auf dem angeschlossenen Bankkonto kontrolliert. Bei LS-POS und vermutlich auch anderen Kassen sieht man diese Abweichungen immer schon direkt auf dem Tagesabschluss bzw. auch auf einem Zwischenbericht.

Ich verstehe auch nicht, wie das Problem nachträglich mit einer extra Zahlungsart korrigiert werden könnte. In dem Moment, wo das Problem aufgetreten ist, ist der Mitarbeiter ja davon ausgegangen, dass die Zahlung eben nicht durchgegangen ist und der Bon war in JTL-POS noch offen. Gerade weil JTL-POS keinen richtigen Kassenschnitt macht, kann das ja auch nicht kurzfristig kontrolliert werden. Einzige Möglichkeit wäre eben den Kassenschnitt nicht über JTL-POS zu drucken. Dann werden aber - zumindest bei unserem Terminal (Ingenico Desk\3500) - alle Belege immer vom Terminal gedruckt, also auch die eigentlich in den Kassenbon integrierten Kundenbelege der Zahlung.