DKB Buchungslogik vs. Umsatzliste

[peterspahn]

Hallo,
es ist mir schon mehrfach aufgefallen, dass es offensichtlich Probleme bei der "Interpretation" der DKB-(VISA)-Buchungsätze gibt. Ich vermute ! mal, dass es mit den vorgemerkten bzw. tatsächlich gebuchten Sätzen zusammenhängt bzw. mit Konstellationen, bei denen es zu einer Buchung (noch) beide Buchungssätze gibt. Es gibt zumindest Konstellationen, die zu merkwürdigen (unsinnigen) Listausgaben (Saldo !) in der Umsatzliste führen. Diese "Fehler" lassen sich i.d.R. durch Löschen der Buchungszeilen & Neueinlesen beseitigen, es ist also nichts Substantielles, aber lästig und dem "Normalverbraucher" schwer zu vermitteln. Ich habe euch mal ein Beispiel vor/nach dem Neueinlesen der Umsätze angehängt.
Danke & Gruß
Peter

vor Neuladen

ALF_Buchungslogik_1.JPG (78.54 KiB) 3740 mal betrachtet

nach Neuladen

ALF_Buchungslogik_2.JPG (84.54 KiB) 3740 mal betrachtet

[ALF]

Hallo,

die DKB übermittelt beim Kreditkartenkonto (Screenscraping) leider keinen Saldo zu den jeweiligen Buchungen (wie bei HBCI), sondern nur den aktuellen Gesamt-Saldo.
ALF-BanCo nimmt diesen Saldo und rechnet dann anhand der Buchungen rückwärts die übrigen Salden dazwischen aus.

In diesen aktuellen Gesamt-Saldo fließen vermutlich auch noch nicht gebuchte Umsätze ein, so dass dieser nicht immer mit den gebuchten Umsätzen übereinstimmt.
ALF-BanCo kann dies nicht wissen und eine Änderung dürfte hier schwierig sein.

Wir werden dies nochmal mit unserem DKB-Konto prüfen und testen.

Gruß,
ALF

[peterspahn]

Hallochen,
ich habe das Thema noch mal an konkreten Beispielen untersucht: M.E. liegt die fehlerhafte Saldenberechnung an der Nichtberücksichtigung des DATUMS des Saldosatzes, die DKB bucht zwar schon weitere Sätze, schreibt aber selbst offensichtlich das Saldo nicht synchron fort. So kann es passieren, dass es schon gebuchte Umsätze NACH dem Saldo-Datum gibt, ihr rechnet aber immer so, an wenn auch diese dort auch schon berücksichtigt sind. Da bei "nur neue Umsätze lesen" dann auch nicht automatisch korrigiert wird (das wäre allerdings auch schwierig), bleiben die falschen Saldos selbst bei Eintreffen der (richtigen) Lastschrift und des (von der DKB) aktualisierten Saldo-Satzes stehen. Das Problem ist nur zu lösen, indem alle Sätze seit (incl.) der vorherigen Lastschrift gelöscht werden und dann neu eingelesen wird ... denn dann hat der letzte Saldosatz wieder das höchste Datum von allen Buchungen und es funktioniert. Der Fehler tritt also nur dann auf, wenn es Buchungen nach dem letzten Saldodatum gibt ... das seht ihr in der Online-Übersicht der DKB incl. dem Wert, von dem ALF anfängt, die Saldos neu zu berechnen. Deshalb erscheint der Fehler auch sporadisch, er ist von der "zufälligen" Datenkonstellation abhängig. Ich schicke euch per Support mal die ausführliche Analyse incl. Vorschlag für den Algorithmus, der das Problem lösen sollte, allerdings über die Supportmail, ein upload über den Dateianhang ist mir bisher leider nicht gelungen, es werden wohl nur .jpg oder .txt-Dateien unterstützt?
LG
Peter

[peterspahn]

Kleine Ergänzung:
Dateianhänge <> .jpg oder .txt über mail an Support -> OK, kein Problem
Ich habe inzwischen erfahren, dass wohl hier ( DKB ? ) nicht mit screenscrapping sondern mit dem download der .csv der Umsätze gearbeitet wird ?, ich wurde zumindest aufgefordert, Beispiele als .csv zu liefern. Ich werde das also mal unter diesem Aspik verfolgen und dem Support zur Verfügung stellen ... und melde mich dann noch mal. Wird aber nicht "morgen" sein, ein paar Beispiele sollten es schon sein
VGP