Alright, but I really don’t understand what’s happening here. December and January booked just fine, why should the last two transactions be set back to November? Any ideas what could cause this?
Möglicherweise lässt sich mehr sagen, wenn wir die Meta-Daten der Transaktion einsehen können. Dazu müssten wir aber tatsächlich mal aus dem Support Kanal ran.
Ich habe mal den Support per Mail kontaktiert, werde dann hier Updates geben.
2 „Gefällt mir“
Leider noch keinerlei Reaktion vom Support.
Hey @Eric, wir sind weiter an der Sache dran. Sorry, dass du noch nicht von uns zurück gehört hast, wir haben dich jedoch nicht vergessen! 
1 „Gefällt mir“
Danke für die Info, Vinz hatte vor Kurzem auch noch Rückmeldung per Mail gegeben, dass ihr an der Sache dran seid.
1 „Gefällt mir“
Update: am 15. wurde wieder abgebucht und heute früh hab ich gesehen, dass es dieses Mal tatsächlich korrekt im April verbucht wurde 
1 „Gefällt mir“
@Eric Ich habe jetzt noch mal rein geschaut in den Fall und Rücksprache mit dem Backend gehalten. Ich denke, jetzt fühle ich mich sicher, hier ein Statement abzugeben. Folgende Hintergrundinfo, was bei uns passiert:
- Bei eingehenden Buchungen bekommen wir Metadaten zur Transaktion. Enthalten die Metadaten die transaction time, wird diese ans Frontend (Tomorrow App) weitergegeben. Liegt die transaction time nicht vor, zeigen wir das transaction date an. Für den vorliegenden Fall spielt das transaction date aber keine Rolle mehr. So viel nur als Hintergrund.
- Ich habe mir ein paar Fälle meiner eigenen Buchungen angesehen und festgestellt, dass bei mir so etwas in einem Fall auch mal passiert ist. Jetzt das spannende Insight:
- Bei meinem Fall wurde immer die transaction time angezeigt, die in der Regel auch immer das Datum ist, zu dem die Belastung entsteht (also monatlich der Stichtag). Nur bei einer Buchung (die Fehlerhafte), wurde uns in den Metadaten der Transaktion das ursprüngliche Datum des Vertragsabschlusses als transaction time übermittelt.
Fazit: Ausgehend von dem obigen Fall von mir schließe ich darauf, dass der Fehler auch hier an den übermittelten Daten liegt. Die kommen aber weder von der Solarisbank, noch von uns. Möglicherweise ist da beim Sender ein Fehler unterlaufen.
Liebe Grüße und einen frohen Wochenstart an alle!
1 „Gefällt mir“
Danke für die Rückmeldung und fürs Nachhaken! Ich werde mich hier wieder einklinken, falls das oder etwas ähnliches wieder passieren sollte.
1 „Gefällt mir“
Wieso baut Ihr auf diese Daten auf und nicht, wann es korrekt bei der Solrisbank verbucht wurde?
Die Daten stammen sogar von der Solarisbank… Und weiter noch: Sie stammen gar nicht von der Solarisbank, sondern vom Zahlungsabwickler, würde ich jetzt behaupten, ohne das im Detail zu wissen. Wir bilden im Prinzip nur die Daten in der App ab, die wir von Solaris bekommen.
Es ist schon wieder geschehen. 
Nach der Auflösung der Reservierung ist die Buchung aus meiner Mai-Historie verschwunden.
Aufgetaucht ist sie dieses Mal allerdings nicht im November, sondern im Mai 2020.
Kann ich so von den Buchungsdaten bestätigen Wir werden ein Ticket dafür erstellen. Die Idee wäre, einen Check einzubauen, der prüft, ob das Transaktionsdatum und die Transaktionszeit >2 Wochen auseinander liegen. Falls das der Fall ist, würden wir den Fallback auf das Transaktionsdatum anzeigen. Damit sollte das Problem umgehen werden. Vermutlich wirst du aber noch eine Weile mit diesem Thema leben müssen, bis das Backend das umsetzen kann.
2 „Gefällt mir“
Frohe Kunde bei diesem Thema. Wir haben einen Fix eingebaut. @Eric Bitte halte mal die Augen offen, ob das für zukünftige Zahlungen funktioniert.
Folgende Anpassung hier: Wir zeigen für zukünftige Kartenzahlungen immer das transaction_date + die transaction_time an. Sprich: wir unterdrücken bei der transaction_time das mitgelieferte Datum und nutzen jenes des transaction_date, welches in diesen Fällen bisher immer korrekt ist. Werden also vom Händler falsche Meta-Daten mitgeliefert für eine wiederkehrende Zahlung, wird das in Zukunft kein Problem mehr sein.
4 „Gefällt mir“
Update: diesen Monat wurde wieder korrekt verbucht die angezeigte Uhrzeit weicht dieses Mal zwar um zwei Stunden von der Uhrzeit der eigentlichen Buchung ab (23:57 statt eigentlich 21:57), aber was solls. Hauptsache die Buchung landet nicht mehr irgendwo im Vorjahr 
2 „Gefällt mir“
Hätte ich jetzt auch drauf getippt. Computer und Zeitzonen… 
@digitle danke für den Tipp. Ich gucke mal nach, was ich dazu finden kann und melde mich dann wieder bei euch.
Moin. Tatsächlich konnte ich herausfinden, dass das hat mit den unterschiedlichen UTC-Zeitverschiebungen zu tun hat, die den Unterschied in Stunden und Minuten zur Coordinated Universal Time (UTC) angeben.
Die Solarisbank liefert uns die Karten-Transaktionszeit mit der UTC-Zeitverschiebung +00:00 (siehe UTC±00:00)
Da wir 2 Stunden addieren, gehe ich stark davon aus, dass wir sie auf die entsprechende Zeit in Deutschland umrechnen, die derzeit Mitteleuropäische Sommerzeit (MESZ) ist, was UTC+02:00 entspricht.
Das bedeutet, dass die in der App angezeigte Zeit die deutsche Zeit ist.
Dieses Mal stimmt sowohl Datum als auch Uhrzeit. Ich vermute mal, dass sich die Geschichte damit erledigt hat. Danke fürs fixen
1 „Gefällt mir“