Eindeutige ID von Kontoumsätzen

Ich habe mit HBCI4Java ein kleines Modul entwickelt, das Kontoauszüge abholt und in eine SQL-Datenbank speichert (PostgreSQL oder MSSQL).

Mein Problem ist folgendes: Umsätze die ich einmal abgeholt habe, möchte ich nicht mehr löschen, da an den IDs der Umsätze weitere Aktionen hängen (Buchungen in der Finanzbuchhaltung).

Da ich in den Umsatzzeilen (GVRKUms.UmsLine) keine eindeutige ID des einzelnen Umsatzes finden konnte, erzeugte ich beim Speichern des Umsatz eine eigene ID.

Beim nächsten Abholen der Umsätze wiederholt das System die Umsatzabfrage für den aktuellsten gespeicherten Umsatztag bis zum heutigen Tag.

Leider ist es jetzt so, dass beim erneuten Abholen der Umsätze diese u.U. nicht mehr in der gleichen Reihenfolge vorliegen (und sich damit auch der Saldo der einzelnen Zeile ändert), in der sie zuvor vorlagen und somit eine eindeutige Identifzierung nicht möglich ist.

Gibt es eine Möglichkeit einen Umsatz eindeutig zu identifzieren?

Danke

Jepp, ueber die Checksumme loese ich das in Hibiscus auch:

Ich bilde sie aus Text, Betrag,Konto,Gegenkonto,Customerref, Primanota,Saldo, Zweck und Datum.

Strings wandle ich vorher noch mit toUpperCase() in Grossbuchstaben.

Gruss
Olaf

Noch eine Frage:

Wieviele Tage rückwirkend können sich die Umsätze denn verändern?

Aber innerhalb des gleichen Buchungstages kann es vorkommen, habt Ihr das auch schon mal erlebt? D.h. wenn ich Mittags die Auszüge abhole, kann es sein, dass Abends die Reihenfolge der Bewegungen nicht mehr mit der Mittags übereinstimmt.

Ich könnte mir vorstellen, dass bei einigen Banken die Umsätze bei der Abfrage "on demand" erzeugt werden, so dass sich das durchaus ändern kann im Laufe des Tages. Genaues weiss ich allerdings nicht, sorry.

Ja, im Prinzip schon. Allerdings verwende ich nicht String#hashCode() sondern CRC32. Frag mich nicht, warum ;)



Also ich hatte bisher keine Probleme damit. Und wenn User Probleme damit haetten, haette sich bestimmt mal einer gemeldet.



Ich glaube, genau aus dem Grund hab ich den Saldo in die Quersumme mit reingenommen. Denn selbst wenn die Buchungen ansonsten absolut identisch sind - zusammen mit dem Saldo sind sie es nicht mehr ;)

Gruss
Olaf

Ich bin auch Kunde der StSpk MÜnchen und habe genau dies auch festgestellt. D.h. der Saldo einer Kontobewegung am Vormittag kann ein anderer sein als der Saldo der genau gleichen Buchung am Abend. Somit kann per HashCode diese Buchung nicht mehr identifziert werden (gespeichert ist ja der Hashcode der Vormittagsbuchung).

Moin,

@subsembly
Genau so ist es. Es können also Sollzinsen anfallen, obwphl das Konto scheinabr im Haben ist - gilt natürlich umgekehrt auch für Habenzinsen

@Anton Fend
Genau wegen dieser Problematik verarbeiten alle mir bisher bekannten FiBu Programme auch nur komplett abgeschlossene Tage - sprich bis einschlich Gestern. Tagesaktuelle Umsätze können hier mit "Kundenmitteln" kaum vernünftig verarbeitet werden. Elegant wäre es, wenn die Bank pro Umsatz ein Kennzeichen hat "Umsatz bereits übermittelt" - Das gibt es aber nur bei den juristischen Auszügen; und nicht jede Bank stellt diese zur Verfügung - wenn dann meistens als pdf und für Geschäftskunden nur mit "Haftungsfreistellung der Bank" wg. evtl. verlorener Vorsteuerabzüge gegenüber dem Finanzamt.

Die Erfahrung hat einfach gezeigt: Tagesaktuelle Verbuchung nur aufwendig auf Kundenseite realisierbar und sehr fehleranfällig.
Wobei jede Bank (Inst-Gruppe) einzeln angepasst werden muß.
Automatische Verbuchung "bis Gestern" geht ohne Probleme.

Ich frage mich halt nur, wie groß das Rad sein soll, an dem hier gedreht wird...

Aber laßt Euch nicht entmutigen

Od

Hallo Odin,

weisst Du ob es möglich ist am gleichen Tag eine identische Buchung (gleicher Betrag, gleicher Empfänger, gleicher Verwendungszweck etc.) aufzugeben. Z.B. eine Lastschrift versehentlich zweimal einziehen (Überweisung doppelt geht bei der Sparkasse nicht).

Ich hab das konkret mit der NetBank schon mal erfolgreich so provoziert. Einfach zwei genau identische Überweisungen mit ein paar Stunden Abstand durchgeführt. Bei einem sehr kurzen Abstand kann es sein, dass der Server das als versehentliche "Doppeleinreichung" wertet und ablehnt, bei längerem Abstand geht es normalerweise.

Ergebnis: Zwei absolut identische Posten in den Umsatzdaten. Viel Spaß damit