Vorweg: Ich benutze Hibiscus seit ca.13 Jahren und bin damit SEEEHR zufrieden.

Die wertvollen Hinweise im Hibiscus-Wiki und in diesem Forum habe ich schon studiert und angewendet.
Leider ohne Erfolg, aber dafür mit einem HBCI-Trace, das es mir ermöglichte das Problem etwas zu analysieren:

Das Problem:

Im Augenblick habe ich ein Problem, das darin besteht, dass von zwei völlig identischen eingehenden Umsätzen bei einem DKB - Konto an ein und demselben Tag nur ein Umsatz von den beiden Umsätzen importiert wird.
Beide Umsätze sind im HBCI-Trace zu sehen. Anfangssaldo und Endsaldo und die Umsätze passen im HBCI-Trace auch einwandfrei zusammen.

Da aber beide eingehenden Umsätze den genau gleichen Betrag, Verwendungszweck, Absender, Bankverbindung ,... haben und auch am gleichen Tag zur Buchung bei der Bank angefallen sind, sieht es für mich so aus, als ob nur ein Umsatz zur Buchung verwendet wird und der andere Umsatz als Duplikat verworfen wird. Das ist allerdings falsch, wenn man nur mal den Anfangssaldo und die Umsätze des Buchungstages addiert und mit dem im HBCI-Trace gemeldeten Endsaldo des Buchungstages vergleicht. Die jeweiligen Zwischensummen in der Konto-Detail-Anzeige von Hibiscus stimmen dann von einem Buchungstag zum nächsten Buchungstag auch nicht und weisen einen "magischen" Sprung um genau den nicht ausgewiesenen Betrag aus dem fehlenden Umsatz auf.

Gibt es für solch ein (zugegebenermassen) seltenes Szenario evtl. ein Duplicate-Record-Problem bei der Datenbank, so dass der 2. (identische) Umsatz es dann nicht in die Umsatzliste schafft, oder wird hier aktiv nach Duplikaten im Eingangsdatenstrom gesucht? Nun weiss ich nicht, ob von Banken öfter fehlerhaft duplizierte Umsatzdatensätze gemeldet werden. Wenn die von einer Bank gemeldeten Umsätze auch völlig identisch aussehen, aber zu den gemeldeten Anfangs- und Endsalden passen, sollte (meiner laienhaften Meinung nach) erwogen werden, sie ernst zu nehmen.

Falls meine Schilderung nicht klar genug sind, würde ich auch noch einen Ausschnitt aus dem HBCI-Trace nachsenden.

Vielen Dank und viele Grüsse aus der Rhön!

Ha! Und ich dachte schon ich spinne Genau das gleiche ist mir vor ein paar Tagen mit dem nightly build auch passiert. Allerdings bei einem Kreditkartenkonto, das ich per scripting-plugin abrufe. Ich hatte das plugin in Verdacht. Ist dann wohl doch eher hibiscus. Von zwei absolut identischen Geschäftsvorfällen kam nur einer in der DB an. Ich habe erstmal einen zweiten Abruf gestartet, ohne Erfolg. Ich habe den GF dann als workaround ex- und wieder importiert, um das Konto richtig zu haben...

Bei mir war es ein ganz normaler Abruf per FinTS/HBCI. Das Phänomen ist auch unabhängig von der Hibiscus-Version: ich hatte erst eine etwas ältere Version (2.8.6) in Betrieb, habe dann mal auf die (noch) neueste Version 2.8.13 aktualisiert - der Effekt blieb gleich. Bei der Bank sind die Daten in Ordnung (zuerst hatte ich einen Schreck bekommen), die HBCI-Antwort der Bank bei der Abfrage enthält die Daten auch korrekt, nur das scheinbare Duplikat kommt nicht in den Hibiscus-Umsätzen an. Wenn der Effekt beim Scripting ähnlich ist, liegt das Problem wohl hinter den Schnittstellen.
Gibt es eigentlich eine Möglichkeit, den (einen) fehlenden Umsatz per Hand einzutragen? Ich gehe mal nicht von einem schnellen Fix des Problems aus (im Augenblick gibt es bei so einer Banking-Software sicherlich wichtigere stressige Themen) und dann sind die HBCI-Daten bei der Bank möglicherweise schon aus dem Zeitfenster von 90 Tagen verschwunden...

Du musst den einen bereits in der Datenbank vorhandenen Umsatz löschen, danach Saldo und Datum zurücksetzen und anschließend die Umsätze rückwirkend neu abrufen. Hierbei sollten dann alle beide angelegt werden.

Aktuell schlägt hier tatsächlich die Doppler-Erkennung falsch an. Hibiscus vergleicht die empfangenen Umsätze mit den in der Datenbank vorhandenen. Da der eine augenscheinlich bereits vorhanden ist, überspringt Hibiscus sie. Wenn er aber noch nicht vorhanden ist, werden alle beide von der Bank übertragenen angelegt. Dieser "Edge-Case" passiert genau dann, wenn diese zwei Buchungen ursprünglich nicht innerhab *eines* Abrufes in der Datenbank gelandet sind sondern einzeln bei zwei getrennten Abrufen. Also: Buchung 1a kam bei Abruf 1, Buchung 1b bei Abruf 2. Hibiscus kann dann nicht erkennen, dass es sich bei 1b *nicht* um 1a handelt. Kommen aber 1a und 1b alle beide bei Abruf 1, dann *erkennt* Hibiscus, dass es ja zwei Buchungen sein *müssen*.

Wäre es insofern nicht gescheiter, nicht nach Dopplern zu suchen, sondern immer ALLE Umsätze des zuletzt abgerufenen Tages zu löschen und neu einzutragen? Ich habe sowas vor vielen Jahren mal so gemacht und das so gelöst. Nachdem es in meinem Programm aber vorkommen konnte, dass schon Kontierungen vorgenommen worden waren (an den zu löschenden Umsätzen), habe ich bei den neu abgerufenen Umsätzen verglichen, ob es den gleichen Umsatz in den gelöschten schon gab und habe dann die lokalen Zusatzfeldinhalte übernommen. Bei weiteren Umsätzen wurde dann der alte Umsatz, der seine Zusatzdaten schon "an den Mann gebracht hatte", nicht weiter berücksichtigt. Somit konnte es auch bei absolut identischen weiteren Umsätzen nicht passieren, dass die dann alle die Kontierung/Zusatzdaten geerbt haben. Der erste neue Umsatz wurde mit den Zusatzdaten des schon vorhandenen gelöschten Altumsatzes angereichert, der nächste identische Neuumsatz wurde NICHT angereichert, weil die Daten des ersten Altumsatzes ja schon "benutzt" waren. Somit kommen zuverlässig immer ALLE Umsätze in der Datenbank an und es gibt trotzdem keine Doppler. Und Bearbeitungen von Zusatzfeldern bleiben auch erhalten - und zwar auch immer nur in der schon gemachten Anzahl.

@harvey: Die von mir beschriebene Doppler-Erkennung gilt nur für HBCI/FinTS. Wenn du die Daten über ein Hibiscus-Addon oder Scripting-Plugin abrufst, muesstest du dich zwecks Doppler-Erkennung an den jeweiligen Autor wenden.

@msa: Beim Loeschen der Umsaetze wuerden sich aber deren IDs jedesmal aendern. Es gibt User, die z.Bsp. per MySQL direkt auf die Daten zugreifen. Deren Zuordnungen wuerden dann verloren gehen. Hinzu kommt, dass auch das Fibu-Plugin SynTAX Referenzen auf die Buchungen speichert, die dann verlorengehen wuerden.

Ist letztlich aber auch egal. Die Notwendigkeit einer Doppler-Prüfung ist ja nur beim Abruf im alten MT940-Format nötig. Seit CAMT gibt es ja eine endeutige ID. Ich habe jetzt keinen Überblick, wieviele Konten CAMT noch nicht anbieten. Ich konnte bei meinen Konten jedenfalls inzwischen komplett auf CAMT umstellen.

Olaf,


danke für die Klarstellung. Deswegen habe ich mich hier ja auch zuerst nicht gemeldet. Nach meiner letzten (versuchten) Fehlermeldung im Scripting-Forum habe ich es aufgegeben, dafür etwas zu melden. Wenn deine Posts einfach gelöscht werden, verlierst du schnell die Lust - ich zumindest

Danke für deine Mühe
Gruß
Harvey

Die Lösung von Olaf hat super funktioniert! Vielen Dank!
Habe auch gleich auf die neue Version 2.8.14 aktualisiert und auf CAMT umgestellt. Ich konnte keinerlei Verdopplungen irgendwelcher Datensätze beobachten. Sauber! Vielen Dank für die gute Arbeit.

Mit so einer schnellen Antwort hatte ich gar nicht gerechnet!