Re: [Hbci4java-help] GVRKUms.UmsLine.instref ändert sich?
Brought to you by:
kleiner77
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-22 06:34:20
|
Hallo, > Um zu testen, ob eine Kontobewegung bereits in der Datenbank steht, > brauche ich eine Möglichkeit der eindeutigen Identifizierung einer > Kontobewegung. > > ... > > Was habe ich übersehen? Nichts. Die Daten, die bei den Kontoauszügen zurückgemeldet werden, lassen sich NICHT eindeutig identifzieren (es gibt einfach kein Merkmal bzw. kein Tupel von Merkmalen, welches PRIMARY KEY Charakter hätte). Wie Du schon sagtest - im worst case kann es passieren, dass zwei Buchungen EXAKT identisch sind (die INSTREF ist glaube ich nur ein Kennzeichen der Bank, die die Buchung angestoßen hat - weiß ich aber nicht sicher. In jedem Fall ist das Feld nicht sinnvoll für die eindeutige Identifizierung von Buchungen zu verwenden). Es gibt aber einen anderen Weg, um Dein Problem zu lösen. Beim Abholen von Kontoauszügen gibt es eine nützliche Eigenschaft: Daten, die Du einmal bekommen hast, bekommst Du beim nächsten Abruf des selben Zeitraumes exakt genau so. Es kann nicht passieren, dass sich zwischen zwei Buchungen A und C, die beim ersten Abruf direkt aufeinander folgten, auf einmal eine zusätzliche Buchung B DAZWISCHEN befindet. Es kann höchstens passieren, dass neue Buchungen angehängt werden. Wenn Du also z.B. heute einen Kontoauszug abholst mit Zeitbereich 10.4. bis 22.4., erhälst Du z.B. folgendes: ... 20.4.: Transaktion 1 20.4.: Transaktion 2 21.4.: Transaktion 3 21.4.: Transaktion 4 Ich gehe jetzt davon aus, dass diese Daten nun also in Deiner DB stehen. Später holst Du nochmal Kontoauszüge ab. Du empfängst: ... 20.4.: Transaktion 1 20.4.: Transaktion 2 21.4.: Transaktion 3 21.4.: Transaktion 4 21.4.: Transaktion 5 22.4.: Transaktion 6 Um nun sauber zu "erkennen", welche Transaktionen Du neu importieren musst (T5 und T6) gehst Du wiefolgt vor: 1) Du suchst Dir das Datum der letzten Transaktion, die Du schon in Deiner DB hast (21.4.) 2) Du zählst, WIE VIELE Transaktionen vom 21.4. bereits in Deiner DB enthalten sind (2 Stück, nämlich T3 und T4) 3) Bei den abgeholten Kontoauszügen überspringst Du alle Transaktionen mit Datum vor dem 21.4. (T1 und T2) - denn die hast Du schon in Deiner DB. 4) Bei den Transaktionen vom 21.4. überspringst Du die ersten zwei (T3+T4 - die hast Du auch schon). 5) Alles, was danach folgt, importierst Du als neue Buchungen in Deine DB. Du brauchst beim Abholen von Kontoauszügen eine "Überlappung" mit den bereits existierenden Daten. Du kannst als Startdatum für GVKUmsAll also das größte bereits in Deiner DB bekannte Buchungsdatum verwenden. Im Beispiel hättest Du beim zweiten Abruf als Startdatum anstelle des 10.4. auch den 21.4. verwenden können... Dieses Vorgehen setzt (wie oben geschrieben) voraus, dass einmal abgeholte Kontoauszüge praktisch "fest" sind, sich also nachträglich nicht mehr ändern. Das ist zwar insofern einleuchtend, dass man Konto- auszüge ja theoretisch auch "offline" abholen kann (Kontoauszugs- drucker), und es dort auch nicht möglich ist, dass beim nächsten Ausdruck auf einmal Daten aus der Vergangenheit anders sind. Aber im Onlinebankingforum (http://onlinebanking-forum.de) habe ich von einem Fall gehört, dass beim HBCI-Abruf von Kontoauszügen wohl nachträglich irgendwelche Buchungen auf einmal anders waren. Das SOLLTE ein Einzelfall und ein Fehler gewesen sein - ich denke, man kann davon ausgehen, dass obiger Algorithmus funktioniert. In wallstreet9 benutze ich ein dazu äquivalentes Verfahren seit 2004 ohne Probleme... Viele Grüße -stefan- |