Re: [Hbci4java-help] GVRKUms.UmsLine.instref ändert sich?

[HBCI4Java (S. Palme) <hbc...@ka...>]

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-