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?
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?