Hallo zusammen.
Habe beim Abruf der Kontobewegungen mittels FinService.DownloadStatement(SwiftDate tFromDate) das Problem, dass egal welches
"bis"-Datum ich beim FinAcctMvmtsSpecifiedPeriodBuilder angebe, immer alle Bewegungen bis zum Heutigen Tag
zurück kommen.
Hat jemand eine Idee, woran das liegen könnte?


LG Pana

Ich gehe davon aus, daß die allermeisten Banken kein bis-Datum verarbeiten sondern grundsätzlich vom von-Datum ab alles liefern.

Scheint tatsächlich daran zu liegen... Dann halt selber selektieren
Danke.

Hallo zusammen, hätte zum Thema Kontoauszüge noch eine andere Frage, vielleicht hat auch @msa eine Antwort darauf
Und zwar möchte ich, nachdem ich mir die Statements geholt habe, prüfen, ob ich Datensätze von diesem Tag schon mal abgerufen habe.

Beispiel:
Ich hole mir die Kontobewegungen vom 20.06.2016 bis heute. Eine Woche später dann vom letzten Abruftag (21.06.2016) bis zum aktuellen Tag.
Nun möchte ich wissen, ob evtl. neue Datensätze am 21.06.2016 gekommen sind oder ob ich schon alle gesehen habe.
Gibt es irgendeinen Key, der jedes Statement einzigartig macht? Habe bisher nur das PackedDate gesehen, eine laufende Nummer die bei jedem neuen EntryDate wechselt.
Würde ungern nur die strings auf Gleichheit prüfen, da man ja rein theoretisch zwei Überweisungen am gleichen Tag mit gleichem Betrag, Absender, Empfänger, VWZ usw. tätigen kann.

Danke und LG

Kommt drauf an, wie Du abrufst, also in welchem Format - was natürlich wiederum davon abhängt, was Deine Bank liefert.

Die meisten Banken verwenden noch das Vor-SEPA-Format MT940. Die zusätzlichen SEPA-Felder werden nach bestimmten Regeln mit Feldschlüsseln davor in den Verwendungszweck gepackt. In diesem Format gibt es keine Eindeutigkeit in den Buchungen, man muß selbst tricksen, um bereits abgerufene Buchungen zu erkennen. Entweder man ruft grundsätzlich erst dann ab, wenn der Buchungstag unwiderruflich zu Ende ist - also man verwendet für die echte Verarbeitung am 14. nur die Umsätze bis 13. usw. Oder man löscht grundsätzlich den laufenden und den letzten Buchungstag aus der eigenen Datenbank und ersetzt sie durch den Neuabruf. Komplizierter wird es, wenn man das Ganze am laufenden Tag schon weiterverarbeitet oder in den einzelnen Buchungen bereits Notizen angebracht hat, so daß das Löschen keine Option mehr ist. Dann bleibt eigentlich nichts weiter übrig, als der feldweise Vergleich, um einen Umsatz, den man schon hatte, auszuschließen. Die beiden gleichen Überweisungen an einem Tag stellen da kein Hindernis dar, wenn man es klug anstellt. Beispiel: Wir haben bereits 5 Umsätze und bekommen beim nächsten Abruf insgesamt sieben. Ich vergleiche also den ersten neuen Umsatz mit den vorhandenen. Wenn ich eine Gleichheit feststelle, verwerfe ich den neuen Umsatz. Dann vergleiche ich den zweiten neuen Umsatz - aber nur noch mit den verbleibenden vier alten Umsätzen - den bereits abgeglichenen verwende ich natürlich nicht wieder. Wenn also jetzt nochmal ein Umsatz mit exakt den gleichen Daten vorkommen würde, dann würde es mir wieder eine Gleichheit liefern - aber eben nur so oft, wie es schon gleiche Umsätze im Altbestand gibt. Wenn es im Neuabruf einen zweiten identischen Umsatz gibt, im Altbestand aber nur einer vorhanden war, dann wird beim zweiten Vergleich mit 4 Altumsätzen keine Gleichheit mehr auftauchen und man würde den zweiten neuen Umsatz übernehmen... Du glaubst nicht, was in den letzten 25 Jahre für Klimmzüge von den Programmierern ersonnen wurden, um da gescheite Lösungen zu finden. So alt ist nämlich das MT940 Format aus BTX-Zeiten... Damals, als das Format definiert wurde, gab es eigenltich nur Batch-Verarbeitung auf den Bankrechnern. Man bekam am Morgen die Umsätze des Vortages und aus. Somit konnte man eh immer nur bis zum Vortag abrufen und der Vortag war erledigt, also konnte es zu den Problemen garnicht kommen.

Das Ganze kann man sich sparen, wenn die Bank die Umsätze bereits im neuen SEPA-Format als XML-Datei liefert. CAMT heißt dieses neue Format. In dem gibt es bei jeder Buchung einen Bankrechnerseitigen Zeitstempel, der sich nicht mehr ändert, an dem kann man dann einen Umsatz eindeutig erkennen. Umsätze in CAMT können z.B. vom Rechenzentrum FI (Sparkassen) abgerufen werden.

Hallo msa,

keiner deiner (durchaus guten) Vorschläge funktioniert leider so pauschal für jede Bank......
Der Abgleich der neu gelieferten (ich schätze das meintest Du mit den neuen Umsätzen - wenn man wüsste, dass die neu sind, wäre das Problem ja gelöst führt nicht zwangsweise zum Erfolg, da sich hier durchaus Daten schon mal nachträglich ändern z.B. Buchungstexte.

Das mit dem camt und dem Zeitstempel wäre eine schöne Sache, aber auch hier ist es nicht sicher gestellt, dass dieser immer eindeutig ist.
Für die FI und auch Fiducia und GAD IT AG ist es wohl so, dass die eine eindeutige UmsatzID vergeben. Bei der FI hat sich der TAG (das XML Feld) in der die ID abgelegt wurde -ich mneine in diesem Jahr- geändert, so dass solche IDs im Zweifel auch nicht immer so einfach zum Auswerten sind.

Insgesamt ist die Identifizierung der Abgleich von Umsätzen einer der sportlicheren Aufgaben......

Viele Grüße

Holger

Danke für eure Antworten und Vorschläge, werde mir diese mal näher anschauen und versuche mal das ein oder andere umzusetzen.

vielleicht schilderst du einfach mal den angedachten Einsatzzweck, evtl. gibt es ja Alternativen