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

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

Hallo Olaf,

nein, diesen Parallelthread gibt es nicht (s. meine letzte Mail) Sorry  
für die Verwirrung.
Ich kann es auch noch immer kaum fassen, dass so etwas wesentliches  
wie eine eindeutige ID schlicht fehlt. Fast bekommt man den Eindruck,  
die Banken würden die externe Archivierung bewusst erschweren. Es wäre  
da sowieso mal Zeit für einen internationalen Standard, der bitte  
nicht wieder von Banken intern erdacht wird sondern per RFC. Betreff  
mit Groß- und Kleinschreibung! Unicode! XML!

Zurück zum grauen Alltag bzw. dem roten Tuch:
Dein Verfahren scheint quasi identisch mit dem zu sein, was ich mir  
ausgedacht habe. Die Identitätsprüfung würde ich ebenfalls über eine  
Checksumme lösen. Mir war nicht klar, dass das Enddatum optional ist.  
Das werde ich dann auch weg lassen, schon weil ich irgendwo von der  
genialen Fehlermeldung einer Sparkasse gelesen habe: "Enddatum liegt  
in der Zukunft". Ja? Und? Wo ist das Problem? Warum kann man auf diese  
Anfrage nicht einfach alle Umsätze ab dem Startdatum schicken?  
Natürlich weil es dann nicht so lustige Probleme mit Clients und  
Servern in verschiedenen Zeitzonen gäbe. Es geht ja um Deutschland.  
Und wer will schon sein Konto aus dem Ausland abfragen? Oder kurz vor  
Mitternacht mit einer leicht vorgehenden Uhr? Da schlafen doch alle!  
Manchmal fragt man sich wirklich ...

Stark bleiben!
Jan

On 22.04.2009, at 12:31, Olaf Willuhn wrote:

> Hi,
>
>>> antwortet Captain FRAG (Zitat mit freundlicher Genehmigung):
>>>> die Reihenfolge muss in der Tat nicht chronologisch sein.
>
> Gibts hier einen Parallel-Thread beim Online-Banking-Forum?
> Ich finde die Aussagen voin Captain FRAG nicht ;)
>
>> Ich glaube, Olaf hat in Hibiscus einen ähnlichen Algorithmus
>> implementiert, und Hibiscus wird von wesentlich mehr Leuten  
>> verwendet.
>> Vllt. kann er ja mal kurz was dazu sagen (Wie ist der Algorithmus?  
>> Sind
>> Synchronisierungsprobleme in dieser Richtung bekannt?)
>
> Das Thema ist fuer mich eigentlich ein rotes Tuch ;)
> Die Tatsache, dass es in HBCI keine eindeutigen Identifier
> fuer die Umsaetze gibt, hat sicher schon so vielen graue Haare
> gekostet, dass ich mich frage, warum daran bis heute niemand
> was geaendert hat.
> In Hibiscus hab ich im Laufe der Zeit immer wieder mit verschiedenen
> Varianten experimentiert. Das aktuelle Verfahren ist keineswegs
> 100%ig sicher - hin und wieder meldet mir mal ein Kunde, dass es
> bei ihm zu Umsatz-Dopplern in der Datenbank gekommen ist. Meist
> stellt sich dann raus, dass die Bank die Umsaetze nachtraeglich
> tatsaechlich nochmal geaendert hat. In einem Fall hatte sie
> den Verwendungszweck mit deutschen Umlauten geliefert (üöä). Stunden
> spaeter waren die ploetzlich gegen "ue","oe", "ae" ersetzt.
> Da es sich hier aber um Einzelfaelle handelt, fasse ich den
> Algo in Hibiscus deswegen nicht nochmal an. Ich bin heilfroh, dass
> er bei ueber 99% der Faelle funktioniert.
>
> Derzeitiges Verfahren bei mir:
>
> 1) In der Datenbank wird beim Konto das Datum des letzten
>   Umsatzabrufes gespeichert.
> 2) Beim ersten Umsatzabruf werden also alle verfuegbaren geholt.
>   Anschliessend nur noch die ab dem letzten Abruf. Das Datum kann
>   bei Bedarf vom User zurueckgesetzt werden.
> 3) Bei Default wird kein Offset fuer das Datum verwendet. Wenn
>   also am 21.04. das letzte mal erfolgreich abgerufen wurde, wird
>   beim naechsten mal als Start-Datum der 21.04. verwendet.
>   Mittels eines Parameters in einer Config-Datei kann man jedoch
>   ein Offset ("umsatz.startdate.offset") definieren, um von dem
>   Startdatum immer noch X Tage abzuziehen (damit rueckwirkend
>   auch nochmal die X letzten Tage geholt werden).
> 4) Da der User die Umsaetze in Hibiscus aendern kann (durch  
> Kommentare,
>   Kategorie-Zuordnungen oder sogar durch Aendern der Kerndaten
>   eines Umsaetzes) und auch Umsaetze via CSV, MT940, XML, etc.
>   eigene importieren kann, darf ich die ueberschneidenden Umsaetze
>   nicht einfach loeschen.
> 5) Daher bildet Hibiscus eine Checksumme fuer jeden Umsatz. Sie
>   enthaelt:
>
>   - Buchungsdatum
>   - Valuta
>   - Art der Buchung (Umsline.text) (case-insensitive)
>   - Betrag
>   - Checksumme des eigenen Kontos
>   - Kundenreferenz
>   - Gegenkonto (BLZ, Kontonummer, Name (case insensitive))
>   - Primanota
>   - Zwischensumme (Umsline.saldo)
>   - Verwendungszweck 1
>   - Verwendungszweck 2
>
>   Eigentlich wuerde ich die Zwischensumme gern entfernen. Kann ich
>   aber nicht ohne weiteres, weil sich dadurch die Checksumme
>   aendern wuerde und bei allen Hibiscus-Usern fuer einen gewissen
>   Zeitraum Doppler entstehen wuerden.
>
> 6) Damit ein User die Umsaetze aendern kann, wird die Checksumme
>   beim Anlegen des Datensatzes einmal berechnet und direkt in der
>   Datenbank gespeichert. Auch wenn der User anschliessend den
>   Umsatz aendert, hab ich damit anschliessend noch die originale
>   Checksumme.
>
> 7) Beim Abgleich der neu abgerufenen Umsaetzen mit den bereits
>   in der Datenbank existierenden wird per Default ein Merge-Fenster
>   von 30 Tagen verwendet. Es werden also die Umsaetze aus der
>   Datenbank geladen, deren Datum max. ${Startdatum - 30 Tage}
>   ist. Die werden via Checksumme mit den neuen verglichen.
>   Stimmt die Checksumme ueberein, wird der Umsatz ignoriert.
>   Ist sie anders, wird er neu angelegt.
>
> 8) Ein End-Datum beim Umsatzabruf verwendet Hibiscus nicht.
>
>
>
> Wie gesagt. Ich glaube nicht, dass das der beste Weg ist
> (der Autor von Subsembly treibt da IMHO noch viel mehr Aufwand).
> Aber zumindest scheint er seinen Zweck zu erfuellen ;)
>
> Gruss
> Olaf
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Hbci4java-help mailing list
> Hbc...@li...
> https://lists.sourceforge.net/lists/listinfo/hbci4java-help