Zwischensumme ungleich zur Saldo

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

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…

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?

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).

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.

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?

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.

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

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

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