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

[Jan B. <ja...@mu...>]

Hallo Stefan,

vielen Dank für Deine sehr hilfreiche Antwort. In der Tat habe ich  
heute morgen schon mit genau diesem Vorgehen experimentiert und mir  
(bzw. Captain FRAG) exakt die Fragen gestellt, die Du im Folgenden  
beantwortest.
Dass Du dieses Verfahren seit 2004 ohne Probleme einsetzt, stimmt mich  
natürlich sehr zuversichtlich! Etwas macht mich allerdings stutzig:

On 22.04.2009, at 08:34, HBCI4Java (Stefan Palme) wrote:
> 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.

Auf meine Frage:
"Ist es möglich, dass für den aktuellen Tag, der ja in der HKKAZ- 
Antwort nicht komplett sein muss bei einer zweite Abfrage Umsätze  
nicht nur am Ende dazu kommen, sondern auch an anderen Stellen  
(zwischen zwei bereits bekannten Umsätzen oder am Anfang z.b.) Sprich:  
kann man sich auf die Reihenfolge innerhalb eines MT904 verlassen?"

antwortet Captain FRAG (Zitat mit freundlicher Genehmigung):
> die Reihenfolge muss in der Tat nicht chronologisch sein. In unserem  
> System kann ich abweichen vom Standard (=Chronologisch) auch andere  
> Sortierungen für eine Umsatzausgabe hinterlegen. Manchmal sind so  
> Besonderheiten wie eine Sortierung nach Betrag gewünscht. Regulär  
> ist aber eine chronologische Ausgabe. Nachvollziehen kann man das  
> über die Umsatzanlieferung über HBCI allerdings nicht, da dort keine  
> Uhrzeiten stehen. Ich kenne auch mind. 2 Banksysteme die nicht mal  
> für den Bankmitarbeiten an der Oberfläche eine Uhrzeit der Buchung  
> darstellen.


Das würde bedeuten, dass zumindest für den "offenen" Buchungstag  
tatsächlich theoretisch Einträge ZWISCHEN oder VOR bereits bekannten  
Einträgen auftauchen können. Mir ist aufgefallen, dass bei comdirect  
die instrefs eines Tages stets kleiner als die des Folgetages sind,  
innerhalb eines Buchungstages jedoch *absteigen*. Ich werte das als  
Indiz, dass bei comdirect die Sortierung innerhalb eines Buchungstages  
absteigend chronologisch ist, neue Buchungen also *oben* auftauchen.  
(ein Experiment zur Bestätigung dieser Annahme steht noch aus)

Man könnte diese Unsicherheit ausschliessen, indem man noch "offene"  
Buchungstage einfach ignoriert und erst zu einem späteren Zeitpunkt  
auswertet.

Da stellt sich die nächste Frage: Ab wann kann ein Buchungstag als  
unveränderlich angesehen werden?
Reicht es, das sein Datum in der Vergangenheit liegt (maximal  
gestern), bekommt man also schon 1 Sekunde nach Mitternacht garantiert  
den unveränderlichen gestrigen Buchungstag?
Oder kann die Bank eventuell mehrere Tage hinterher sein? Dann könnte  
man eventuell davon ausgehen, dass der Tag mit dem aktuellsten Darum  
in der HBCI-Antwort offen ist und alle anderen fix.
Diese Annahme zerbricht allerdings, wenn die Bank z.B. Buchungen  
macht, die in der Zukunft liegen.

Zur Zeit favorisiere ich folgendes Verfahren, das mir recht robust  
erscheint:

1. Buchungsdatum in der Datenbank aufsteigend sortieren
2. Den drittletzten (z.B.) Eintrag aus dieser Liste als Startdatum  
verwenden
3. Das aktuelle Datum als Enddatum verwenden
4. Kontoauszüge für Startdatum bis Enddatum per HBCI abfragen
5. Für jeden Buchungstag in der HBCI-Antwort
6.		Aus der Datenbank die Liste aller Buchungen für diesen Tag als  
temporäre Liste (a) lesen
7.		Die Buchungen aus der HBCI-Antwort als temporäre Liste (b) lesen
8.		Für jeden Eintrag in Lise (b)
9.			Ist ein Eintrag in Liste (a) vorhanden, der exakt identisch ist?
10.			In diesem Fall: Eintrag aus beiden Listen löschen
11.		Die übrigen Einträge in Liste (b) als neue Datensätze in die  
Datenbank schreiben
12.		Ist Liste (a) nicht leer, sind Buchungen verschwunden oder  
modifiziert worden -> Warnung ausgeben und entsprechenden Datensatz in  
der Datenbank mit einem Flag als inaktiv markieren.

Dieses Verfahren hat folgende Eigenschaften:
- Es werden keine Annahmen über die Reihenfolge der einzelnen  
Buchungen eines Tages gemacht.
- Es kann ein Zeitfenster von n Tagen als "offen" gelten. Diese Tage  
werden auch nachträglich noch abgefragt und Änderungen werden erkannt.
- Die Datensätze können zusätzliche, vom User gefüllte Felder  
enthalten, die intakt bleiben, solange die Bank die entsprechende  
Buchung nicht nachträglich modifiziert. Sollte sie das tun  
(esoterischer Fall), sind diese Felder wieder leer und die vorherigen  
Inhalte sind weiterhin in einem als inaktiv markierten Datensatz  
gespeichert.

Freue mich über Gedanken hierzu. Und Vielen Dank für die kompetenten  
Antworten!
Jan