Hallo,

ich habe beim Upgrade gleich auf CAMT mit umgestellt. Es hieß ja, dass vorübergehend bei der Umstellung doppelte Einträge entstehen können und ich habe diese dann nach dem ersten Abruf bereinigt, indem ich die Vorgänger gelöscht habe.
Das ist jetzt schon etliche Tage her.

Gestern hatte ich einen Abruf durchgeführt und einer der Buchungen hatte ich mit einem Kommentar im Notizfeld versehen.
Daher ist mir heute nach dem heutigen Abruf eingefallen, das doch schon getan hatte und dann darauf hin diesen und einen weiteren Eintrag doppelt gefunden habe.

Eigentlich hatte ich erwartet, dass das mit den doppelten Einträgen nur bei der Umstellung passiert.
Woran kann es liegen das immer mal wieder doppelte Einträge erstellt werden?

In diesen Fall ist es mein Postbank-Girokonto.

Danke schon mal

Leider habe ich heute wieder doppelte Umsätze gefunden. Betroffen ist wieder das Postbank Girokonto.
Den Letzten Umsatzabruf hatte ich am 12.02.2026. Die 4 doppelten Einträge die heute nochmal eingetragen wurden waren 4 von 8 Einträgen.
Die ersten drei waren mit dem Abruf vom 12. eingetragen worden aber älter, dann die 4 doppelten am 12.02. vom 12.02. und heute wurde die 4 doppelten und ein weiterer erst mit dem heutigen Abruf ergänzt.

die Kontoumsätze mal 1:1 vergleichen, hier gibt es bestimmt Unterschiede
in der Vergangenheit wurde von der PB bereits Anreicherungen des Kontoumsatz/Datensatzes vorgenommen

Werde ich mal genauer vergleichen.

Früher ist mir das aber nie aufgefallen. Ist das erst seit CAMT so?

Sollte da nicht eher die alte Buchung dann überschrieben/gelöscht werden?

Eine automatische Löschung von Buchungen, die der Juser ggf. schon händisch weiterverarbeitet hat, ist eine wenig hilfreiche Idee...

Ja, Du hast recht. Da hatte ich nicht dran gedacht. Ich ergänze ja eigentlich immer nur die Notiz-Zeile aber es wäre blöd wenn meine Notiz im Nirwana verschwindet.

Die doppelten Buchungen kommen daher das beim ersten Abruf die Prima/Nota gefüllt ist und bei den nachfolgenden Abrufen nicht mehr.
Es scheint auch nur die Postbank betroffen zu sein.

Ah, scheint auch mal anders herum zu sein. Gerade habe ich einen 2. Abruf gemacht und die gerade davor aufgetauchten Buchungen ohne Prima/Nota sind nochmals, nun mit Prima/Nota gefüllt aufgetaucht.

Wenn die Bank untertägig Änderungen an den Buchungen vornimmt, hilft es in der Regel, bei diesen Banken die Umsätze nur einmal am Tag abzurufen.

Dabei kommt es aber immer noch zu solchen Problemen da dann die Nachrichten zwischenzeitlich vom letzten abgerufenen Tag nochmals neu angelegt werden.
Ich weiss ja nicht was FinTS so mit liefert aber wäre es nicht sinnvoll die Änderungen nach Identifizierung ggf. zu übernehmen statt neu anzulegen?
Vielleicht kann man ja die geänderten Einträge über eine Vielzahl von Merkmalen eindeutig identifizieren.
Die Notizen sind das Einzige was ich eintrage und die sollte das nicht betreffen.
Was mich wundert ist aber insbesondere das das erst seit dem Upgrade mit der gleichzeitig von mir vorgenommenen CAMT-Umstellung auffällt.
Ich denke ich werde CAMT mal ausschalten um zu sehen ob das Problem dann noch auftritt. Vielleicht kommen da mehr genau die Merkmale zusätzlich mit welche sich immer ändern.

Die Identifizierung ist ja genau das Problem. Sonst würde es nicht zu den Dopplern kommen. Wenn sich die Buchungen hinreichend ändert, erkennt Hibiscus nicht mehr, dass die Buchung bereits vorhanden ist.

Bei MT940 gibt es keine Buchungs-Identifier. Hibiscus muss die Buchungen daher anhand der Eigenschaften erkennen. Bei CAMT gibt es zwar eine ID. Die verwenden aber nicht alle Banken.

@IchBins
wie bereits o.e. hatten wir das Problem doch auch früher (ohne camt) - bei der PB sogar ganz früher vor Umstellung auf DB

Es liegt am Lieferanten, dh. nicht nur PB, auch andere Player (IN.., DK..,Cb, cd, apo, S..da, .. o.ä.) waren früher (sehr) gut und heute ...
Hier hilft doch nur wechseln - denn es kann doch nicht sein, dass jeder Entwickler "Sonderlocken" einbaut, die er dann in wenigen Stunden/Tagen/Wochen/Monaten wieder zurückbauen muss.

Ok, mir kommt es halt so vor als würde sich seit dem ich das Update Mitte Januar mit der Umstellung auf CAMT diese Probleme haben.
Die ganzen Jahre vorher ist mir das nicht (in diesem Maße) aufgefallen (da ich mich nicht an einen Fall erinnere.)

Was mir aber noch aufgefallen ist das es früher diese vorläufigen Buchungen bei der Postbank gegeben hat, wie sie noch bei der DKB üblich sind.
Ich bin mir nicht sicher, aber ich glaube das ich keine mehr sehe. Möglicherweise sind es genau diese die nun Probleme machen da diese nicht mehr als vorläufig erkannt werden?

Moin, ich habe CAMT wieder abgeschaltet. Mir ist sofort aufgefallen das da wesentlich weniger Felder gefüllt werden. Scheinbar insb. die oben sich gerne ändernden Felder scheinen da nicht gefüllt zu werden und daher kommt es unter MT vermutlich nie oder sehr selten zu doppelten Buchungen.

Das ist nicht schön da sicher auf Dauer es keinen Weg an CAMT vorbei gibt.
Wie wäre es mit einer Vergleichsabfrage beim Eintragen?
Man kann doch beim Abruf nach einer möglichen schon vorhandenen Buchung suchen und die Abweichungen anzeigen lassen z.B. indem man die Werte nebeneinander stellt und den User fragt, ob geändert oder neu eingetragen werden soll. Das wäre vielleicht eine nette Erweiterung für die Zukunft.
Vielleicht auch ein Filter der Änderungen automatisch übernimmt wenn bestimmte Felder sich ändern bzw. man gibt an welche als Identifikationsfelder für schon vorhandene Buchungen gelten sollen.
Ich gebe gerne was extra zu meiner monatlichen Spende dazu. Vielleicht eine Umfrage?

MfG

Es könnte auch als Workaround helfen das man für bestimmte Problemkonten einfach nur bis zum Vortag die Buchungen abruft. Das sollte untertägige Änderungen vorhindern in der Hoffnung das sich Buchungen sich dann nicht mehr ändern.
Gibt es eine Möglichkeit das jetzt schon zu nutzen?

https://www.willuhn.de/wiki/do…tze_fehlen

umsatz.startdate.offset=1

Dann fehlen danach aber Buchungen.

Nochmal: Um herauszufinden, ob sich Felder geändert haben, musst du überhaupt erstmal herausfinden, welche zwei Buchungen (je aus vorhandenem Bestand und aus aktuellem Abruf) zusammenpassen. Bei den CAMT-Umstätzen senden die meisten Banken eine Transaktions-ID(*) mit, was diesen Abgleicht sehr einfach macht und dafür sorgt, dass es keine Duplikate mehr gibt, weil anhand dieser ID abgeglichen werden kann. Die Postbank sendet diese ID entweder gar nicht oder in einem anderen/unbekannten Feld oder sie ändert sie. Dann bleibt nur noch der Abgleich über die Eigenschaften der Buchung. Und wenn sich die ändern, woran willst du dann festmachen, ob es noch die gleiche (aber geänderte) Buchung ist oder doch eine andere?

Beim Vergleich per Eigenschaften verwendet Hibiscus diese:

- Buchungsart
- Betrag
- Kundenreferenz
- Gegenkonto
- Primanota
- Verwendungszweck
- Datum
- Valuta

Wenn sich irgendwas davon ändert, wird die Buchung als neu interpretiert.

Wie gesagt: Viele andere Banken senden bei CAMT inzwischen einen vernünftigen Identifier, weshalb das Problem dort gar nicht mehr existiert. Und wie infoman schon schrieb, fehlt mir eigentlich die Zeit, hier irgendwelche Sonderlocken für die Postbank einzubauen, die sich in ein paar Monaten (wenn die dann doch noch IDs senden) wieder erledigt haben.

(*): Die Transaktions-ID kommt im CAMT aus "NtryDtls/TxDtls/Refs/Prtry/Ref" oder als Fallback "AcctSvcrRef" oder als weiterer Fallback aus "NtryDtls/TxDtls/Refs/AcctSvcrRef".

Wir können das Thema jetzt bitte beenden.

Danke, schaue ich mir an.

Aber Inwiefern? Doch nur die dann nicht erwarteten vom aktuellen Tag, oder?

Die müssten dann ja beim nächsten Abruf nachgeladen werden.

Das wäre zumindest für mich ein Workaround bis die Postbank das behoben hat.

PS: Ein Kaffee mit Kuchen für Dich als Spende für Deine Zeit kommt.

Wieso muss das denn die Postbank beheben und nicht die von dir eingesetzte Software?
Das hier beschriebene Problem besteht z.B. mit Banking überhaupt nicht. Dort werden vorgemerke Umsätze problemlos abgerufen und es gibt auch keine doppelten Einträge. Abruf erfolgt schon seit vielen Monaten via CAMT, kein Umschaltegefrickel zwischen MT940/CAMT nötig und auch kein umsatz.startdate.offset-Gebastel...

was soll das gebashe, das steht doch hier schon!