Abweichung zwischen Buchung und erwarteter Buchung

1. offizieller Beitrag

    Ich benötige eure Hilfe bei einem Problem mit einem Girokonto DiBa; Zugangsart "FinTS (HBCI) PIN/TAN"; Umsatzparameter wie folgt:



    Wenn ich im Supermarkt z. B. am 21.04.2017; 17:43 Uhr (gemäß Kassenzettel) einen Einkauf mit meiner VISA-Karte bezahle und noch am gleichen Tag eine Umsatzabfrage durchführe, taucht in der Buchungsliste im Programm eine erwartete Buchung auf, in der als Wertstellung der 21.04.2017 und als Buchungsdatum der 27.04.2017 eingetragen ist. Im Verwendungszweck steht jedoch eine abweichende Zeit - im Beispiel "... Zeit: 15:43 ..."


    Frage 1: Womit kann die reproduzierbar abweichende, sicher bankseitig gelieferte Zeitangabe erklärt werden?



    Bei einer neuen Umsatzabfrage einige tage später, z. B. am 25.04.2017, gibt es dann in der Buchungsliste - zusätzlich zur oben beschriebenen erwarteten Buchung - eine "normale" Buchung mit dem selben Betrag, Wertstellung am 28.04.2017; Buchungsdatum 25.04.2017, geringfügig abweichendem Empfänger und ebenso geringfügig abweichendem Verwendungszweck. Auffällig ist, dass die Zeitangabe in dieser Buchung "174324" lautet und somit der Angabe auf dem Kassenzettel entspricht. Wieso sich die Wertstellung und das Buchungsdatum bei der Bank nun geändert hat, ist mir ein Rätsel.
    Insgesamt entspricht die "normale" Buchung im Programm nun exakt den Daten, wie sie auch auf der Bankseite in der Umsatzanzeige stehen.
    Die erwartete und die "normale" Buchung sehen im Programm in der Buchungsliste wie folgt aus:



    Die erwartete Buchung wird nicht automatisch der "normalen" Buchung zugewiesen. Des muss ich manuell erledigen. Alternativ kann ich natürlich die erwartete Buchung löschen.


    Frage 2: Die sich auf der Bankseite ändernden Daten kann ich nicht beeinflussen. Kann ich statt dessen das Programm so einstellen, dass die erwartete Buchung entweder vermieden oder aber - was besser wäre - automatisch der "normalen" Buchung zugewiesen wird.



    Viele Grüße und vielen Dank im Voraus


    Sven

    Zitat von js.boettcher

    Womit kann die reproduzierbar abweichende, sicher bankseitig gelieferte Zeitangabe erklärt werden?

    Keine Ahnung. Ist bei mir genauso. Anfangs dachte ich das Greenwich Zeit genutzt wird, was aber nicht der Fall ist.

    Zitat von js.boettcher

    zusätzlich zur oben beschriebenen erwarteten Buchung

    Die erste Buchung ist eine vorgemerkte Buchung.

    Zitat von js.boettcher

    Kann ich statt dessen das Programm so einstellen, dass die erwartete Buchung entweder vermieden oder aber - was besser wäre - automatisch der "normalen" Buchung zugewiesen wird.

    Ich habe das gleiche Problem mit Aldi. Suche am besten alle Real-Adressen in der Adressverwaltung und füge sie zusammen und nenne die Adresse anschließend am besten einfach nur Real. Die vorgemerkte Buchung sollte beim Abruf dann automatisch dieser Adresse zugeordnet werden. Im Idealfall funktioniert das dann auch mit der endgültigen Buchung. Falls nicht, dann weise die erwartete der Bankbuchung zu. Wenn alle Bankbezeichnungen bei der Adresse hinterlegt sind, funktioniert die Zuordnung automatisch.

    • Offizieller Beitrag
    Zitat von js.boettcher

    Frage 1: Womit kann die reproduzierbar abweichende, sicher bankseitig gelieferte Zeitangabe erklärt werden?

    Muß man die Bank fragen - die liefern den VWZ.

    Zitat von Sven

    Keine Ahnung. Ist bei mir genauso. Anfangs dachte ich das Greenwich Zeit genutzt wird, was aber nicht der Fall ist.

    Wieso nicht? Plus 1 h Sommerzeit.

    Zitat von js.boettcher

    Kann ich statt dessen das Programm so einstellen, dass die erwartete Buchung entweder vermieden oder aber - was besser wäre - automatisch der "normalen" Buchung zugewiesen wird.

    Nein, hier wird ja primär keine erwartete Buchung erzeigt, sondern eine vorgemerkte abgerufen.

    Zitat von Billy

    Wieso nicht? Plus 1 h Sommerzeit.

    Ich hatte bei Google nur nach "Greenwich zeit" gesucht und die war nur eine Stunde zurück. Zwischen Greenwich und GMT scheint aber auch noch eine Stunde Unterschied zu sein. Also dürfte es doch passen.

    Zitat von Billy

    Nein, hier wird ja primär keine erwartete Buchung erzeigt, sondern eine vorgemerkte abgerufen.

    Als erstes wird die vorgemerkte Buchung ohne VISA... abgerufen. Wenn dann die endgültige Buchung von der Bank kommt, die dann VISA... als Auftraggeber enthält, wird die VISA... Buchung in die BuLi übernommen und die ursprüngliche wieder entfernt und als erwartete Buchung ausgewiesen, da das System davon ausgeht, dass diese verschwunden ist. Dies passiert aber nur, solange sich die Adressen nicht finden. Wenn beide Auftraggeber einer Adresse als Bankbezeichnung zugewiesen sind, dann funktioniert auch die Zuordnung und es wird auch keine erwartete Buchung mehr erzeugt.

    • Offizieller Beitrag
    Zitat von Sven

    Als erstes wird die vorgemerkte Buchung ohne VISA... abgerufen. Wenn dann die endgültige Buchung von der Bank kommt, die dann VISA... als Auftraggeber enthält, wird die VISA... Buchung in die BuLi übernommen und die ursprüngliche wieder entfernt und als erwartete Buchung ausgewiesen, da das System davon ausgeht, dass diese verschwunden ist. Dies passiert aber nur, solange sich die Adressen nicht finden. Wenn beide Auftraggeber einer Adresse als Bankbezeichnung zugewiesen sind, dann funktioniert auch die Zuordnung und es wird auch keine erwartete Buchung mehr erzeugt.

    Korrekt. :thumbsup:

    Zitat von Sven

    Ich hatte bei Google nur nach "Greenwich zeit" gesucht und die war nur eine Stunde zurück. Zwischen Greenwich und GMT scheint aber auch noch eine Stunde Unterschied zu sein. Also dürfte es doch passen.

    Differenz von UTC zu MEST ist -2h, zu MET -1h


    Wobei UTC hier im "militärischen Sinn" zu betrachten ist. UK verhält sich dann noch abweichend. Siehe beispielhaft auch https://www.timeanddate.com/time/united-kingdom-bst.html


    Falk

    Hallo Sven, hallo Billy,


    vielen Dank für eure Unterstützung. :)


    Ich werde die Adressen zusammenführen, so wie es Sven beschrieben hat - das jeweils für Stellen, an denen ich regelmäßig die Karte einsetze. Ich melde mich, wenn ich meine Tests abgeschlossen habe.


    Mit der Greenwich-time muss ich mich erst mal auseinandersetzen - besonders was die Sommerzeit betrifft, die ja am beispielhaften 21.04.2017 noch gar nicht gilt. ?(


    Am Rande hat sich mir nun eine neue weitere Frage gestellt:
    Kann man programmseitig unterdrücken, dass erwartete Buchungen von der Bank abgeholt werden? Das sollte das Problem doch ebenso lösen, wenn man den Blindflug über die paar Tage, bis die Bank die "normale" Buchung bereitstellt, in Kauf nimmt?

    Ja. Aber nur durch seltenere Abfragen. Die Vormerkung ist in den SEPA Regelungen explizit vorgesehen, um dem Kunden die Möglichkeit zu geben, evtl. auftetende Deckungslücken des Kontos aufzufüllen oder unberechtigte Forderungen früh genug abzuwehren. Sonst wird die geplatzte Buchung nämlich eine Ecke teurer und führt ggf. auch noch zu einer Negativmeldung an Wirtschaftsauskunfteien (Schufa etc.). Folgen ?


    Falk

    Zitat von js.boettcher

    Kann man programmseitig unterdrücken, dass erwartete Buchungen von der Bank abgeholt werden?

    Bitte nicht die Begriffe durcheinander werfen. Die Bank liefert keine erwarteten Buchungen. Diese gibt es nur im Programm. Die Bank liefert vorgemerkte Buchungen. Das ist ein Unterschied. Die Abholung der vorgemerkten Buchungen lässt sich nicht unterdrücken, ist aber, wenn alles erst einmal "eingerichtet" ist auch nicht notwendig.

    Zitat von Falk1

    Die Vormerkung ist in den SEPA Regelungen explizit vorgesehen, um dem Kunden die Möglichkeit zu geben, evtl. auftetende Deckungslücken des Kontos aufzufüllen oder unberechtigte Forderungen früh genug abzuwehren.

    Der Vollständigkeit halber muss man aber erwähnen, dass die Diba vorgemerkte Buchungen nur bei bestimmten Kartenzahlungen liefert und nicht bei "normalen" Lastschriften - leider.

    Zitat von js.boettcher

    Ich werde die Adressen zusammenführen, so wie es Sven beschrieben hat - das jeweils für Stellen, an denen ich regelmäßig die Karte einsetze. Ich melde mich, wenn ich meine Tests abgeschlossen habe.

    Genau dies hatte ich gestern für die verschiedenen real-Adressen erledigt. Bei meiner heutigen erneuten Umsatzabfrage wurde die erwartet Buchung automatisch der "normalen" Buchung zugewiesen. Das funktioniert also wie erwartet. :thumbup:


    Unschön ist nun aber, dass die Buchung einen gedoppelten Verwendungszweck enthält, der aus den beiden Verwendungszwecken der zusammengeführten Buchungen besteht, wobei der Verwendungszweck mit dem Text der erwarteten Buchung beginnt - erkennbar insbesondere an der falschen Zeit:


    :(


    Ich werde nun einmal probieren, diese drei fehlerhaften/überflüssigen Zeilen mit einer Regel zu entfernen. Wenn ich annehme, dass der Verwendungszweck bei vorgemerkten Buchungen von real immer dreizeilig geliefert wird, habe ich aber noch keine Idee, wie ich die Regel dazu bringen kann, dass die ersten drei Zeilen nur bei der Buchung gelöscht werden sollen, welche nach der Zusammenführung übrig bleibt. Sicher habt ihr auch dafür einen Lösungsansatz?

    Zitat von js.boettcher

    Unschön ist nun aber, dass die Buchung einen gedoppelten Verwendungszweck enthält, der aus den beiden Verwendungszwecken der zusammengeführten Buchungen besteht

    Unschön ist es, aber da nicht bekannt ist, welche Informationen des VWZ für den Nutzer relevant sind, werden diese aneinander gefügt und nicht überschrieben. Mich stört es nicht, da ich mir nicht so häufig vergangene Buchungen ansehe.

    Zitat von js.boettcher

    Ich werde nun einmal probieren, diese drei fehlerhaften/überflüssigen Zeilen mit einer Regel zu entfernen. Wenn ich annehme, dass der Verwendungszweck bei vorgemerkten Buchungen von real immer dreizeilig geliefert wird, habe ich aber noch keine Idee, wie ich die Regel dazu bringen kann, dass die ersten drei Zeilen nur bei der Buchung gelöscht werden sollen, welche nach der Zusammenführung übrig bleibt. Sicher habt ihr auch dafür einen Lösungsansatz?

    Das geht meines Wissens nicht.