Hallo,

heute habe ich meine Konten wieder mal abgerufen und sehe eine Unstimmigkeit zwischen Zwischensumme und Saldo des Kontos.
Trotz abgehender Beträge wurde eine steigende Zwischensumme für die letzten beiden Buchungen angezeigt…
Bei einem anderen Konto wird ebenfalls eine zu hohe Zwischensumme angezeigt, die also mit dem aktuellen Kontosaldo nicht übereinstimmt.

Was kann ich tun, damit das wieder korrekt angezeigt (berechnet?) wird? Bisher hatte ich solche Probleme trotz jahrelanger Nutzung nicht gesehen.

Der Punkt aus der FAQ "Umsätze rückwirkend abrufen" hat leider nicht geholfen.

"Saldo neu berechnen" hat leider nach der (gefühlt) letzten "korrekten" Berechnung (als geprüft markiert) eine zu niedrige Zwischensumme errechnet. Entfernen der "geprüft" Markierung hat keinen Unterschied gemacht. Da muss also vorher auch schon mal was schief gegangen sein.

Gibt es irgendeine Möglichkeit, den korrekten Saldo in der Zwischensumme wieder herzustellen?

Bank: Sparda Hessen

Software-Version: 2.10.15
HBCI4Java-Version: 3.1.72
Datenbank-Version: 70
Build: 379 [Datum 20231103]

Hallo @All,

seit dem letzten Update habe ich das selbe Problem. Die Zwischensummen werden absolut falsch berechnet. Manchmal steigen Sie, manchmal Fallen Sie, und das was da drin steht, stimmt rein garnicht mit dem überein, wie es sein sollte. Das macht die Spalte "Zwischensumme" zu einer Nicht-Vertrauenswürdige Angabe.

Software ist auf dem gleichen Stand wie mein Vor-Poster. (Sprich: Aktuell)

Gibt es eine Möglichkeit der "Neuberechnung" bzw. einer "Von-Jetzt-Rückwärts-Neuberechnen" Funktion?


JimJim
XUN

Das hat nichts mit dem Update zu tun. Das enthält keinerlei Änderungen an diesen Stellen. Handelt es sich vielleicht um die Sparda-Bank? Die liefern neuerdings angeblich die Umsätze falsch rum. Matrica hat hierzu auf der Webseite auch was stehen.

Zum Thema "Zwischensummen neu berechnen" habe ich mal einen FAQ-Eintrag angelegt: https://www.willuhn.de/wiki/do…tze_falsch

Wie im Start dieses Threads schon geschrieben, hatte der Weg, wie in der FAQ beschrieben, nicht geholfen.

Neulich hatte ich abgerufen und der letzte Umsatz war eine Einzahlung, da passte die Zwischensumme und ich dachte schon, dass es nur ein einmaliger "Schluckauf" war.

Heute habe ich wieder Umsätze abgerufen (nur Abgänge) und die Zwischensumme ist inzwischen total absurd. Die Abweichung zum Saldo beträgt jetzt mehrere Tausend Euro.

Schon die Start-Zwischensumme hat zur alten Zwischensumme (ZwS) eine sehr große Abweichung von mehreren Tausend Euro trotz eines Buchungsbetrags von weniger als 20 € zwischen beiden Buchungseinträgen.

Die Summe der Buchungen entspricht aber korrekt der Differenz der letzten korrekten Zwischensumme und dem aktuellen Saldo.

Spannend ist, dass die Zwischensumme zwischen den einzelnen Buchungen anscheinend korrekt berechnet wird.
Wenn ich aber die Differenz zwischen der letzten Zwischensumme und der ersten Zwischensumme seit der letzten korrekten Zwischensumme berechne, stimmt diese Zahl nicht mit der Summe der Einzelbuchungen überein.

Die Summe der Buchungen laut Zwischensumme entspricht der Differenz des alten und neuen Kontosaldos minus der ersten Buchungssumme. Es gibt da also eine "virtuelle Zwischensumme" (ZwS_virt) von der der erste Buchungsbetrag abgezogen wurde.

Ich habe ein wenig mit den Zahlen gespielt und diese Zusammenhänge gefunden:

• (Saldo_alt - Saldo_neu) - (ZwS_alt - ZwS_neu) = Saldo_neu - ZwS_neu
  
• Saldo_neu - letzte_ZwS = ZwS_alt - ZwS_virt
  
• ZwS_virt = letzte_ZwS + Buchungen = ZwS_neu + erste_Buchung
  

Der Offset zur alten Zwischensumme (ZwS_alt - ZwS_neu) ist mir aber nicht ersichtlich geworden, trotz längerem hin und her mit den Zahlen.

Wenn die Sparda da was geändert hat, und das anscheinend so bleibt, wird Hibiscus da wohl nachziehen müssen…

Nein. Die Sparda hat das zu korrigieren. Die Bank wird doch wohl in der Lage sein, die Umsätze in det richtigen Reihenfolge zu liefern. Alle anderen Banken können das. Was wird wohl passieren, wenn ich Hibiscus anpasse und die Umsätze rückwärts lese? Dann ist es bei allen anderen Banken falsch. Und wenn es die Bank irgendwann korrigiert, ist es danach bei allen Banken falsch.

Wie die Umsätze übertragen werden, ist in FinTS standardisiert. Hierfür gibt es zwei Möglichkeiten. MT940 oder CAMT. An keinem der beiden Formate wurde irgendwas geändert. Wenn es bei der Sparda also bis vor kurzem noch funktioniert hat, am Standard nichts geändert wurde und es jetzt bei der Bank nicht mehr passt, dann überträgt die Bank die Daten jetzt nicht mehr gemäß Standard.

Hallo @hibiscus,

vielen Danke für deine Einschätzung.
Aber wie ist jetzt der korrekte Weg nach vorn?
Gibt es für sowas einen geregelten Meldeweg oder wie läuft sowas?
Soll ich mich bei meiner Bank melden?
Was soll ich denen sagen? Wie kann ich das technisch unterfüttern?
Gibt's ein Log, das ich aus Hibiscus exportieren kann?

Du glaubst doch nicht im Ernst, dass das Sparda RZ irgendwas auf eine Meldung von einem Bankkunden gibt? Noch dazu mit einem Log, das von einem nicht von der Bank vertriebenen Kundenprogramm stammt. Einzige Chance ist, zu warten, bis sich da von selbst was tut, weil das RZ selbst drauf kommt. Das kann aber beim Sparda RZ lang dauern, wenn man schaut, wie da frühere Probleme in den letzten 10 Jahren gehandelt wurden.

Oben im Menü kannst du unter "Hibiscus->Erweitert->HBCI-Protokoll speichern..." die von der Bank empfangenen Daten im Roh-Format exportieren. Aber wie msa schon schrieb: Ich glaube auch nicht, dass die Bank da kurzfristig etwas fixen wird. DIe werden das Problem gar nicht bei sich sehen (war in der Vergangenheit immer so).

PS: Wenn du schon Probleme hast, den Soll-Zustand zu rekonstruieren, wie soll das ein Programm dann anhand der übertragenen Daten automatisch machen? Du kannst aber mal auf der Webseite der Bank schauen und die angezeigte Reihenfolge dort mit der in Hibiscus vergleichen. Vielleicht ist da ja ein Muster erkennbar.

PPS: EIgentlich ist das MT940-Format, welches die Bank verwendet, ohnehin veraltet. Viele Banken bieten inzwischen das neue SEPA-fähige Format CAMT an. Im Wiki unter https://www.willuhn.de/wiki/do…ormat_camt ist beschrieben, wie man es aktivieren kann, falls die Bank es unterstützt (ich bin skeptisch, ob die Sparda es kann).

Oh je, bin bei der Sparda Hessen und habe gerade das gleiche Problem hier beobachtet. Die sind leider noch nicht bei der atruvia - werden aber zukünftig dahin wechseln. Allzu lange wird das Problem also nicht mehr bestehen (spätestens 2026 sind alle Spardas bei der atruvia). Vielleicht merken die es irgendwann selber. Aber in deren RZ läuft wohl mittlerweile so manches schief. Wohl schon erste Auflösungserscheinungen. Die Moral wird nicht mehr so dolle sein ... . Dann werde ich das Konto wohl bis auf weiteres stilllegen. Da muss man ja froh sein, wenn am Ende überhaupt noch irgendwas stimmt.

Update: Salden neu berechnen hat bei mir auch nicht funktioniert

Die Sparda hat im übrigen auch die Inhalte dessen geändert, was übertragen wird. Der bisherige Eintrag " SEPA-BASISLASTSCHRIFT EREF" z.B. erscheint nicht mehr - nur noch reiner Payload ist jetzt zu sehen.
Im Rahmen dieser Umstellung hatte ich auch zwei Transaktionen doppelt.

Update 2:
Das Neuberechnen der Salden hat jetzt doch funktioniert. Man muss nach "Datum sortieren" einstellen in der Liste - dann passt es - nicht nach Index. Evtl. hätte es auch ohne neu berechnen gepasst, wenn man nach Datum sortieren schon vorher aktiviert hätte. Muss ich das nächste mal mal drauf achten.

Noch was: CAMT wird nicht unterstützt ...

Hallo,

auch ich bin bei der Sparda (Augsburg).

Und, auch ich hatte das Problem, das ich erst vor kurzem eine Doppelte Buchung empfangen habe. 2x Geldeingang von einem Kunden, was auch gleich zu viel Verwirrung zwischen uns geführt hatte.

Vor kurzem habe ich auch gelesen, bzw. einen Brief der Sparda erhalten, in der angekündigt wurde, dass diese (Sparda) aktuell eine größere Umstellung durchführen, in mehreren Schritten und mehrere Monate hinweg. Möglicherweise kam es diesbezüglich zu den Fehlern.

JimJim
XUN


PS: Ich habe angenommen, das die Zwischensummen von hibiskus berechnet werden?! .. ist ja eigentlich nur ein +- Spiel der einzelnen Elemente.

Ich habe mir jetzt mal die Rohdaten aus dem Export angesehen und mit der Berechnung verglichen. Es scheint in der Tat so, das hier ein Problem in Hibiscus vorliegt, und nicht in den Bank-Daten.

Diese liefert in meinem Falle mehrere :61: ... davon werden von Hibiscus jedoch nur die "berücksichtigt", welche noch nicht bekannt sind. Jedoch wird die Zwischensummenberechnung anhand der :60x: durchgeführt, ohne eben die zusätzlichen Zeilen zu berücksichtigen. Ein Nachrechnen hat dann gezeigt, das genau dieser Fehler hierbei entsteht.


Ein kurzes (Fiktives) Erklär-Beispiel:

:60F:C231205EUR000000001000,00
:61:2312051205D10,00...
'...
:61:2312051205D20,00...
'...
:61:2312051205D30,00...
'...
:61:2312051205D40,00...
'...
:61:2312051205D50,00...
'...
:62F:C231205EUR00000000850,00

Der Abruf liefert 5 Umsatzzeile. Die letzten 3 davon sind Hibiscus bereits aus einem vorherigem Abruf bekannt. Die Folge ist, das Hibiscus das Anfangssaldo zur Berechnung der Zwischensummen verwendet (1000,00) und davon nur die ersten beiden Umsatzzeilen abzieht.
Daraus ergibt sich dann auch der Fehlbetrag in den Zwischensummen sowie der Fehlstand zwischen dem Schlußsaldo und dem Tatsächlich berechnetem.

Im Tree->Konten wird vermutlich das :62F: genutzt, da hier der Wert nach einem Abruf immer richtig dargestellt wird, unabhängig der Fehler im Tree->Umsätze. Führe ich eine Umsatzneuberechnung mit den Fehlerhaften Werten in der Umsatzliste aus, dann ändert sich auch Tree->Konten entsprechend Falsch, bis ein neuer Abruf erfolgt (Auch ohne neue Umsatzzeilen).


Dies Phänomen konnte ich auch, exakt so, Nachvollziehen und Nachrechnen.


JimJim
XUN

Nein. Für die Berechnung der Zwischensummen werden alle enthaltenen Buchungen verwendet-unabhängg davon, ob sie in Hibiscus enthalten sind oder nicht. Das liegt einfach daran, weil das in HBCI4Java passiert - der von Hibiscus intern verwendeten Bibliothek für HBCI. Dort drin ist überhaupt noch nicht bekannt, welche Umsatzbuchungen bereits vorhanden sind und welche nicht. Das heisst: Die Zwischensummen der Buchungen werden exakt genauso berechnet, wie du geschrieben hast. 60F liefert den Startsaldo. Anschließend werden die Buchungsbeträge in der angegebenen Reihenfolge abgezogen/addiert und die Zwischensummen gebildet.
Das passiert hier: https://github.com/hbci4j/hbci….java#L603

Hibiscus selbst berechnet anschließend gar nichts mehr sondern übernimmt von den Umsätzen dann jene, die noch nicht in Hibiscus enthalten sind. Ohne dabei die Zwischensumme anzufassen.

Wenn das Problem damit zusammenhängen würde, wäre der einzige mögliche Grund, dass die Umsätze mit den falschen Zwischensummen schon in einem vorherigen Abruf von der Bank geliefert wurden und die Bank sie jetzt erneut liefert - diesmal aber mit anderen Zwischensummen. Äh, ja. Genau das hast du ja geschrieben. Dass die Umsätze aus einem vorherigen Abruf stammen. Wie kann es sein, dass die Bank die Umsätze in einem späteren Umsatz erneut liefert (das darf sie) - diesmal aber mit anderen Zwischensummen? Das Szenario kann nur dann eintreten, wenn die Bank nachträglich nochmal Umsatzbuchungen dazwischen einsortiert, die die Zwischensummen der nachfolgenden Buchungen ändern. Sollte man nicht annehmen, dass eine Buchung als gebucht gilft, wenn sie nicht als Vormerkbuchung kommt sondern als final valutierte Buchung? Was würde wohl passieren, wenn man mal mehrere Tage rückwirkend abruft? Finden sich dann noch mehr Buchungen, die plötzlich andere Zwischensummen haben? Welchen Wert haben die Umsätze der Bank, wenn man sich nicht drauf verlassen kann, dass die so bleiben?

Noch zur Ergänzung: Das Problem des falschen Zwischenstand (Kontostands?) tritt selbst dann auf, wenn nur eine einzige Transaktion übertragen wurde ... .

Heute habe ich wieder Buchungen abgerufen und zwischen letzter alter Zwischensumme und neuer erster Zwischensumme gab es wieder einen Sprung, der nicht der ersten Buchung entsprach, aber der Differenz zwischen altem Saldo und "erster" Buchung entspricht.
Die letzte Zwischensumme entspricht auch nicht dem aktuellen Kontosaldo.

Das Datum der Buchungen wird korrekt angegeben, aber die letzte Buchung nach Datum hat die erste Hibiscus-Nummer bekommen und die erste Buchung die letzte Nummer, was der Aussage entspricht, dass die Buchungen "verkehrt herum" gemeldet werden.

Im HBCItrace sehe ich, dass eine Buchung vom 11.12. aus dem alten Abruf nochmal im neuen Abruf auftaucht.
Und daher korrekterweise vom "Altsaldo" des neuen Abrufs ebenfalls abgezogen werden müsste, obwohl sie als Buchung im alten Abruf auch schon abgerechnet wurde.

Also meiner Meinung nach ist jeder Abruf für sich stimmig: Alt-Saldo - Buchungen = Neu-Saldo.

Jetzt frage ich mich natürlich, wenn hibiscus dafür verständlicherweise keine Ausnahme einbauen will, wie ich das der Sparda klarmachen kann, dass das anscheinend kein sauberes Verhalten ist.

PS: durch das ganze Neuberechnen und Neuabrufen der Salden in den letzten zwei Wochen ist bei mir die ganze Darstellung zerschossen. Wenn ich nach Datum sortiere, passen zwar die Buchungen, aber nicht die Zwischensummen. Wenn ich nach Index sortiere, sind die Daten total durcheinander. Von September springt es dann plötzlich auf Dezember…

PPS: vielleich wäre es ja hilfreich, wenn der Index sich am Buchungsdatum orientieren würde und nicht an der Reihenfolge der Meldung? Ich kenne mich mit diesen Bank-Spezifikationen leider nicht aus, wieviel da auch Interpretationsspielraum ist. Ich weiß nur bei anderen Normen, dass es da häufig zwei gültige Lesweisen gibt, je nachdem aus welchem Blickwinkel man auf den Sachverhalt schaut.

Ich habe mich jetzt auch noch mal (querlesend) durch die FinTS Spezifikation gewühlt. https://www.hbci-zka.de/dokume…ersion.pdf

Leider scheint mir diese auch nicht sonderlich spezifisch zu sein. Gesucht nach "Reihenfolge" sehe ich diese Treffer, wo häufig "Reihenfolge egal" drin steht. Ist für Hibiscus womöglich B.6.3 relevant?:

B.6.1 Allgemeiner Nachrichtenaufbau
Bezüglich der Reihenfolge der in die Nachricht einzustellenden Aufträge wird keine Vorgabe getroffen.

B.6.2 Aufträge
Die Segmentfolge enthält die in [Messages] definierten Auftragssegmente des Kunden. Jedes Segment kann dabei beliebig oft und in beliebiger Reihenfolge auftreten.

B.6.3 Abholauftrag
Die Einträge werden dem Kunden stets in aufsteigender Reihenfolge rückgemeldet.

F.3.1 Abruf von Umsätzen
Im Idealfall sollte jeder Umsatz pro Kundenprodukt nur einmal abgerufen und dann lokal im Kundenprodukt gespeichert werden

Erlaubte Geschäftsvorfälle
Die Reihenfolge der Geschäftsvorfälle ist unerheblich.

nur mal so zur Info, betrifft auch andere Programme
https://hilfe.starmoney.de/hc/…y-Business

@vader Vielen Dank für diese Info.
Dann hilft wohl leider nur warten.

Das bezieht sich nur auf den allgemeinen Nachrichten-Aufbau bei FinTS.


Das bezieht sich auf die Umsätze.


Genau das macht Hibiscus.

Danke für den Link! Und insbesondere super zu hören, dass das Problem beim Rechenzentrum bekannt und an einer Lösung gearbeitet wird.

oder die Bank wechseln, zumal ja ein Wechsel der RZ erst noch ansteht

Behoben: Fehlerhafte Umsatzdarstellung bei Sparda Banken
.. im Sparda Rechenzentrum behoben somit für alle Mitbewerber/-Produkte relevant
Quelle Fremdprodukt