[Geschlossen] N26: Fehlerhafte Umsatzabfrage (bei vorgemerkten Umsätzen)

[tidenhub]

Bei N26 sind mir gerade 2 Fehler in der Umsatzabfrage aufgefallen:

Ich habe die Umsatzabfrage gemacht, als eine Mastercard Zahlung in Doller noch nicht abschließend gebucht war. Jetzt ist die Zahlung in N26 gebucht mit einem leicht anderen Betrag und ich habe erneut eine Umsatzabfrage gemacht, die Buchung erscheint nun 2 Mal in Hibiscus. Der aktualisierte Umsatz erscheint auch mit einer falschen Zwischensumme von 0€.

Ich habe die Umsatzabfrage gemacht, als eine (andere) Mastercard Erstattung in Doller noch nicht abschließend gebucht war. Die Erstattung wurde nicht vollständig abgeschlossen und wieder gelöscht. Ich habe erneut eine Umsatzabfrage gemacht, und die Buchung ist in Hibiscus immer noch vorhanden, obwohl sie in N26 gelöscht ist.

Mit dem Log in Jameica kann ich leider nicht helfen, da ich es bei der Überprüfung gemerkt haben. Das jameica.log könnte ich senden.

Software-Version: 0.8.9-nightly
Datenbank-Version: 58
Build: 303 [Datum 20180902]

[Hibiscus-Scripter]

Dann lösche die falsche Buchung einfach selbst raus.
Hibiscus macht das nicht und Hibiscus kann dies auch nicht merken, dass die Bank nachträglich Beträge von Buchungen ändert!
Das hab ich noch nie gehört und darf auch nicht sein!
Wenn nicht jede Buchung eine eindeutige ID mit bringt, wie sollte man da auch drauf reagieren?!
Hibiscus selbst kann das nicht wissen und somit ist dieser für Hibiscus natürlich ein völlig neuer Umsatz.

Wenn es zwei Sachen gibt die bei einem Umsatz, die immer gleich bleiben sollten, dann das Buchungsdatum und der Betrag.
Dass sich mal der Verwendungszweck im Aufbau ändern, kann schon vorkommen, dafür hab ich auch verschiedene voll-automatische Migrationsroutinen.
Aber das Ändern des Betrags selbst ist so gravierend, dass man dies nur abfangen kann wenn die Transaktion auch eine eindeutige ID hat, wie z. B. bei PayPal oder früher bei der Fidor
Ansonsten könnte dieser ja auch einen Umsatz mit gleichem Verwendungszweck am selben Tag darstellen, dies ist nicht darstellbar. Und ich denke das kann auch keine andere Software.

Also musst du das selbst korrigieren und dich bei der Bank beschweren ...

Abschließen kann man aber sagen: Solch ein Problem könnte man wunderbar durch eine (die) API der N26 lösen da hier die Umsätze gezwungener Maßen ja eine eindeutige ID haben müssen! Nur ist die wohl nirgends, offiziell dokumentiert, sonst hätte ich die eh schon umgesetzt.
Alternativ kann man die Bank nur bitten diese ID auch im CSV mit anzugeben, oder halt einfach solche nachträglichen Änderungen zu unterlassen.

Gruß

[tidenhub]

..., dass die Bank nachträglich Beträge von Buchungen ändert!
Das hab ich noch nie gehört und darf auch nicht sein!

Ich habe N26 gerade auch als Bank gewählt, weil die Buchungen angezeigt werden, bevor sie eigentlich gebucht werden. Und das hat mir gerade im Ausland schon öfters nachträglich Ärger erspart, weil ich sofort gesehen habe, dass ein falsche Betrag oder der Betrag doppelt abgebucht werden sollte.
Das sich der Betrag ändert, kommt durch die Änderung des Wechselkurses und lässt sich nicht vermeiden, wenn die Buchung frühzeitig angezeigt wird.

In der App kann ich auch sehen, welche Buchung final ist, und welche nicht. (In dem alten Webdesign von N26 war das auch noch integriert.)

Ich werde versuchen mal mit N26 Kontakt aufzunehmen, und eine Lösung zu finden. (evtl. ID in CSV, oder API-Doku,...)

[Hibiscus-Scripter]

ja das mit dem Wechselkurs dachte ich mir schon als Grund, ob das rechtens ist fragte ich mich dann aber auch.
Nur jetzt hast du es gesagt, wenn angezeigt werden würde "vorläufig" und "final" oder sowas, dann wäre das ja wieder abgebildet.

"noch nicht gebuchte" oder "vorgemerkte" Umsätze gibts ja auch bei anderen Banken, darauf kann man dann wunderbar reagieren und die wenn notwendig auch aus dem Kontosaldo raus rechnen ...

Wünsch dir viel Glück

Also sind es nun drei Lösungsansätze für die Bank

1. CSV mit eindeutiger Transaktions-ID bei jedem Umsatz
2. API-Doku falls diese eine B2C-API ist, aber bei OpenAPI denke ich schon (die sind ja doch nicht so doof wie die Fidor )
3. Marker für "vorgemerkte" noch nicht endgültige Umsätze oder extra aufgeführt z. B. ohne Datum (wieder in der CSV)

Gruß