Wie bereits heruntergeladene Umsätze ignorieren?

 
Neuling
Avatar
Geschlecht: keine Angabe
Beiträge: 1
Dabei seit: 10 / 2015
Betreff:

Wie bereits heruntergeladene Umsätze ignorieren?

 · 
Gepostet: 04.10.2015 - 22:34 Uhr  ·  #1
Ich verwende aqbanking-cli, version 5.3.5 unter Ubuntu 14.04.

Ich habe mir ein Shellskript geschrieben, dass automatisiert per cron 1x pro Tag die neuesten Umsätze (aqbanking-cli request --transactions ...) bei meiner Bank runterlädt. Diese werden in einer CTX Datei mit Datumsstempel gespeichert. Anschliessend erfolgt die Konvertierung nach CSV. Ich hätte nun gerne eine einzige grosse CSV Datei, in die alle Umsätze reingeschrieben werden, ohne dass dabei doppelte Einträge entstehen.

Ist es mit aqbanking-cli möglich irgendwo auf der Strecke bank -> ctx -> csv bereits bekannte Umsätze auszufiltern?

Ich weiss, es gibt beim Herunterladen die Möglichkeit die Optionen --fromdate und --todate zu setzen. Da mein Laptop nicht unbedingt jeden Tag in Benutzung ist, würde ich gerne zur Sicherheit jedesmal wenn mein Script läuft z.B. alle Umsätze der letzten 7 Tage abrufen, sodass mir Umsätze eventuell "versäumter" Tage nicht verloren gehen. Wenn nun aber das Skript an aufeinanderfolgenden Tagen läuft, werden zwangsläufig Umsätze mehrfach herunter geladen. Wie kann ich das vermeiden?

Hoffe, ich konnte mein Problem verständlich machen.

Gruss + Dank!
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 8040
Dabei seit: 08 / 2002
Betreff:

Re: Wie bereits heruntergeladene Umsätze ignorieren?

 · 
Gepostet: 06.10.2015 - 08:17 Uhr  ·  #2
Die Erkennung doppelter Umsätze ist ein Problem jeder Zahlungsverkehrssoftware. Ich kenne jetzt aqbanking nur von einigen Tests, ich würde annehmen, dass der Export aus der aqbanking-Datenbank nach der Dublettenerkennung am sinnvollsten ist und dann sollten nur die "abgeschlossenen Tage" exportiert werden.
Hilft dir das?
Gruß
Raimund
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 12
Dabei seit: 10 / 2015
Betreff:

Re: Wie bereits heruntergeladene Umsätze ignorieren?

 · 
Gepostet: 26.10.2015 - 15:38 Uhr  ·  #3
Ich mache das ganz einfach: ich lösche alles was Datum >= (vor 10 Tagen) hat und da ich aqbanking-cli request --fromdate=(vor 10 Tagen) mache, kommt auch nichts doppelt rein.

Beachte, das ich jeden Umsatz, der im "date" größergleich (>=) vor 10 tagen ist, lösche, aber --fromdate eben GENAU(vor 10 Tagen) anfängt.

Ich mache das allerdings nicht mit csv sondern in einer SQL-Datenbank...

Mein Script läuft täglich, allerdings niemals in der Nähe von 0/24 Uhr, da eventuell dass datum für Löschen und request nicht gleich sind
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 7
Dabei seit: 05 / 2020
Betreff:

Re: Wie bereits heruntergeladene Umsätze ignorieren?

 · 
Gepostet: 01.09.2020 - 20:39 Uhr  ·  #4
Ich importiere alle abgerufenen Daten in eine SQL Datenbank und mache die Weiterverbeitung von dort aus.

Beim Import berechne ich eine TransactionID (ein hash über das Datum, den Betrag und die Kontonummern) und nur wenn diese eindeutig ist, wird der Vorgang in die Datenbank geschrieben. Damit stelle ich sicher, dass nur neue Umsätze beachtet werden was bestens funktioniert.
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 19
Dabei seit: 05 / 2021
Betreff:

Re: Wie bereits heruntergeladene Umsätze ignorieren?

 · 
Gepostet: 15.05.2021 - 12:48 Uhr  ·  #5
Die bisher genannten Ansätze können in bestimmten Zusammenhängen ausreichen, scheinen mir aber als Allgemeinlösung unzufriedentstellend: Datum-Betrag-Kontonummern ist (generell) nicht unbedingt eindeutig. Datensätze in bestimmten Zeiträumen löschen und erneut herunterladen ist keine Lösung, wenn man sich auf die erhaltenen Datensätze in anderen Stellen bezieht.

Es ist mir unbegreiflich, dass man die einzelnen Posten nicht identifizieren kann. Gibt es wirklich keine Möglichkeit, von der Bank eine TransaktionsId oder andere Kennzahl zu jedem Posten zu erhalten? Dann muss es eine Möglichkeit geben, die Posten jeweils nur einmal zu erhalten. Denn ich kann mir nicht vorstellen, dass die Welt funktionieren kann, wenn die Software Bankbewegungen nicht eindeutig identifizieren kann.

Hinweise auf einen Denkfehler in meiner Meinung nehme ich gern entgegen.
Benutzer
Avatar
Geschlecht:
Beiträge: 5968
Dabei seit: 06 / 2008
Betreff:

Re: Wie bereits heruntergeladene Umsätze ignorieren?

 · 
Gepostet: 15.05.2021 - 17:51 Uhr  ·  #6
@baconian
wenn es so einfach wäre, würden es die Entwickler doch umsetzen oder nicht?

der wichtigste Punkt hast du gelesen:
Zitat geschrieben von Raimund Sichmann
... dann sollten nur die "abgeschlossenen Tage" exportiert werden.
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 19
Dabei seit: 05 / 2021
Betreff:

Re: Wie bereits heruntergeladene Umsätze ignorieren?

 · 
Gepostet: 15.05.2021 - 18:27 Uhr  ·  #7
Meine Frage zielt auf die Protokolle HBCI/FinTS eher als auf AqBanking — gibt das Protokoll das überhaupt her? Es scheint nicht, das ist es, was mich so wundert.
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 8872
Dabei seit: 03 / 2005
Betreff:

Re: Wie bereits heruntergeladene Umsätze ignorieren?

 · 
Gepostet: 16.05.2021 - 08:11 Uhr  ·  #8
Zitat geschrieben von baconian

Meine Frage zielt auf die Protokolle HBCI/FinTS eher als auf AqBanking — gibt das Protokoll das überhaupt her? Es scheint nicht, das ist es, was mich so wundert.


Darüber hat sich bisher noch jeder Entwickler gewundert, der sich mit dem Thema beschäftigt hat.

Die Umsätze wurden in FinTS bisher üblicherweise im Swift MT940-Format übertragen. Dort ist kein Identifier für einzelne Buchungen vorgesehen. Siehe https://de.wikipedia.org/wiki/MT940
Das Format ist steinalt - es stammt gefühlt ungefähr aus den 70ern.

Seit ungefähr SEPA gibt es mit CAMT ein neues XML-basiertes Format, in dem es einige Stellen gibt, die u.U. als Transaktionsidentifier verwendet werden können. "<Prtry><Ref>" bzw. "<AcctSvcrRef>". 100%ig verlassen kann man sich darauf aber auch nicht. Wenn die fehlen, muss man wie gehabt Konto/Betrag/Datum verwenden.
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 59
Beiträge: 6626
Dabei seit: 03 / 2007
Betreff:

Re: Wie bereits heruntergeladene Umsätze ignorieren?

 · 
Gepostet: 16.05.2021 - 13:49 Uhr  ·  #9
Zitat geschrieben von baconian

Meine Frage zielt auf die Protokolle HBCI/FinTS eher als auf AqBanking — gibt das Protokoll das überhaupt her? Es scheint nicht, das ist es, was mich so wundert.
Du kannst das ruhig glauben. Das ist wirlich so, wie es ist. Ich war Anfang der 90er Jahre bei der Firma angestellt, die das einzige damals vorhandene Kundenprodukt entwickelt und angeboten hat. Damals wurde noch über BTX übertragen und es wurden ausschließlich via ScreenScraper die für Handbedienung vorgesehenen Bildschirmseiten ausgelesen. Irgendwann kam man - damals zählte noch die Onlinezeit für die Gebühren - darauf, dass man die Übertragung beschleunigen möchte. Deswegen haben wir mit einigen großen Banken zusammen (ich glaube das waren damals Commerz-, Dresdner- und Bayerische Vereinsbank) die Übertragung über reine "Datenseiten" entwickelt. Sichbare Seiten mussten es sein, weil ein großer Teil der eingesetzten BTX-Decoder die binäre Übertragung (die für sog. Telesoftware damals üblich war) nicht beherrscht haben.

Als Format wurde dann das bis vor kurzem übliche MT940/STA-Format entwickelt, welches auf Grundlage des SWIFT-Formates kreiert wurde. Allerdings wurde SWIFT wiederum nicht 1:1 übernommen, sondern es wurden einerseits "unnötige" Dinge rausgelassen und BTX- und kundenspezifische Erweiterungen hinzugenommen. Und nun kommt's: Zu dieser Zeit gab es bei allen Banken ausschließlich die Batch-Verarbeitung in der Nacht. Man konnte also Umsätze eines Tages grundsätzlich erst am nächsten Morgen nach Ende der Batch-Verarbeitung sehen. Somit bekam man also auch bei xmaliger Abfrage an einem Tag immer nur die Umsätze des Vortages übertragen. Damit war das Datum von/bis, das man abfragte, die kleinste mögliche Einheit und man bekam immer den kompletten Buchungstag ausgeliefert. Damals haben die Programme auch eine zweite Abfrage an einem Tag nicht durchgeführt, wenn dieser Buchungstag schon mal abgefragt worden war. So einfach war das. Damals hat niemand dran gedacht, dass es mal sowas wie Real-Time-Booking geben würde und man alle 5min weitere neue Umsätze dazu bekommen könnte. Das war einfach nicht vorgesehen. Das Übertragungsformat wurde dann später nach HBCI 1:1 übernommen und als Container in HBCI-Datensätze eingestellt, weil die Verarbeitungslogik für MT940 auf Bank- und Kundenseite bereits da war und man nur die reine Übertragung geändert hat. Vor Kurzem wurde dann das Format mit der SEPA-Einführung von MT940 auf SEPA-XML geändert. Wobei aber natürlich wieder nicht alle Banken die Umstellung mit gemacht haben, sondern es noch viele gibt, die die SEPA-Daten mit dem großen Hammer in MT940 einstellen, obwohl es da viele Felder für SEPA-Neuerungen gar nicht gibt. Es bleibt abzuwarten, wie lange es dauert, bis alle Banken das umgestellt haben. Hintergrund: Die Datenformate für Zahlungsaufträge wurden "von oben" vorgeschrieben, es war also ab dem endgültigen Startdatum SEPA verboten, noch Zahlungen in den alten Formaten anzunehmen - deswegen wurden da bei allen Banken die neuen Formate umgesetzt (oder HBCI in dem Bereich ersatzlos komplett stillgelegt), bei der Umsatzauslieferung gab es keinen Zwang, deswegen kann man da einfach weiterwursteln.

Und nun kam es wie es kommen musste. Banken-Rechenzentren sind sehr erfindungsfreudig und haben viel Selbstbewusstsein. Es gibt gibt zwar die div. Festlegungen (in HBCI und im Datenformat). Fast jedes Bank-RZ findet dann aber irgendwas, was sie "doof" finden und was sie viel besser können, also wird es einfach anders implementiert. Weiterhin gibt es welche, die es einfach nicht schaffen, das so zu implementieren, wie es Standard ist - also machen sie es so, wie sie es gerade hinkriegen oder wie sie es verstanden haben. Und auch wenn alle anderen eine gewisse Sache regelkonform machen, dann beharren sie trotzdem drauf, dass das Blödsinn ist und man selbst das viel besser gelöst hat und alle anderen falsch liegen.

Unterm Strich kommt dabei raus, dass HBCI bestenfalls ein netter Vorschlag ist, jedes Bank-RZ setzt ihn anders um. Deswegen müssen die "armen" Programmierer für Software auf der Kundenseite viele viele Sonderbehandlungen für einzelne Banken einbauen, da das Ganze sonst nicht läuft.

Was nun die Identifizierbarkeit des einzelnen Umsatzes betrifft: Es wurde gegenüber den Anfängen niemals was geändert in dem Bereich. Erstens haben die Banken selbst damit kein Problem - also packen sie es sowieso nicht an. Und die Hersteller von Kundensoftware konnten nicht drauf warten, dass die Bank das Problem löst (als es erstmal mit Real-Time-Booking aufkam) sondern mussten sich selbst was einfallen lassen, um sofort weiterarbeiten zu können. Und dann lief es ja wieder - und so blieb es bis zum heutigen Tag.

Wie hibiscus schrieb, wurde mit dem CAMT-Format für SEPA ein eindeutiger Zeitstempel pro Umsatz eingeführt. Aber der ist nur ein KANN-Feld und kein MUSS-Feld. Deswegen wurde das nur sehr vereinzelt auf Bankseite umgesetzt. Man muss sich das so vorstellen, dass die HBCI-Übertragung meistens nur so ein "Rucksack" ist, der am Kernbanksystem dranhängt. Der HBCI-Server erhält Daten vom Kernbanksystem, setzt diese entsprechend um und gibt sie an das Kundensystem nach außen weiter. Er ist letztlich darauf angewiesen, vom Kernbanksystem die Daten zu bekommen, die er benötigt. Sprich, einen eindeutigen Zeitstempel. Wenn es sowas im Kernbanksystem aber nicht gibt, dann kann der HBCI-Server nicht viel machen. Er könnte selbst einen generieren - nur hilft das nichts, weil er bei der nächsten Abfrage die Daten wieder neu vom Kernbanksystem erhält - wieder ohne Stempel. Und seinen eigenen Stempel vom letzten Mal kennt er nicht mehr. Somit wäre diese Kunstprogrammierung für die Erkennung quasi nur vom Kundensystem auf das Banksystem verlagert. Und darauf lassen sich BankEDVler natürlich niemals ein :-) Also weiterhin ohne.

Die einzige Gruppe, die ich kenne, die den Zeitstempel zuverlässig unterstützen ist das Rechenzentrum FI der Sparkassen. Bei allen anderen fehlt er oder ist er nicht zuverlässig - jedenfalls nicht so, dass ein Kundenprodukt sich darauf stützen könnte. Oder man macht wieder einen Sonderfall: Wenn Quelle = Sparkasse dann Dopplererkennung per Zeitstempel ansonsten per Kunstprogrammierung. Wird natürlich auch niemand machen, der nicht gerade eine Software schreibt, die ausschließlich mit Sparkassen kommuniziert.

Im Übrigen ist die Dopplererkennung nicht so schwierig. Dazu gibt es hier einige Abhandlungen im Forum. Unter anderem auch von mir.
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 19
Dabei seit: 05 / 2021
Betreff:

Re: Wie bereits heruntergeladene Umsätze ignorieren?

 · 
Gepostet: 17.05.2021 - 08:12 Uhr  ·  #10
Danke hibiscus für die Infos!

@msa: Dein Beitrag über die historischen Umstände ist sehr aufschlußreich!
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Fritzlar
Beiträge: 266
Dabei seit: 12 / 2005
Betreff:

Re: Wie bereits heruntergeladene Umsätze ignorieren?

 · 
Gepostet: 30.10.2021 - 15:17 Uhr  ·  #11
Zitat geschrieben von baconian

Danke hibiscus für die Infos!

@msa: Dein Beitrag über die historischen Umstände ist sehr aufschlußreich!


Ebenfalls vielen Dank für die ausführliche historische Schilderung

Wir haben es so gelöst das wir die Posten eines Tages fortlaufend numerieren.
Dumm ist/war nur das die Banken bereits heruntergeladene Umsätze manchmal in anderer Reihenfolge liefern.
Besonders beim Monatswechsel bei Konto-Gebühren/Zinsen ist/war das der Fall.
Mir kam das so vor als ob bankseitig bei einer SQL-Abfrage eine ORDER-Anweisung vergessen wurde (=unsortiert), die jetzt aber anscheinend drin ist.
Ist jetzt aber gefühlt die letzten 1-2 Jahre nicht mehr vorgekommen.
Gewählte Zitate für Mehrfachzitierung:   0