Thread: Re: [Hbci4java-help] GVRKUms.UmsLine.instref ändert sich?
Brought to you by:
kleiner77
Menu
▾
▴
hbci4java-help
|
From: Olaf W. <hbc...@wi...> - 2009-04-22 10:31:21
|
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
|
|
From: Jan B. <ja...@mu...> - 2009-04-22 11:21:14
|
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
|
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-22 11:34:11
|
> Zurück zum grauen Alltag bzw. dem roten Tuch: > ... > 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. <sarkasmus-mode-on> Das ist wohl "security by locality". Da es unwahrscheinlich ist, dass jemand sein deutsches Konto aus dem Ausland mit einer "späteren" Zeitzone abfragen will (da kommen ja praktisch nur die Ostblock-Staaten, Asien etc. infrage), und das auch noch zu einer Uhrzeit in der Nähe des Datumswechsels, wird es sich in einem solchen Fall wohl mit ziemlicher Sicherheit um einen Hacker-Angriff handeln. Und einen solchen wehrt man halt am besten ab mit der Fehlermeldung "Enddatum liegt in der Zukunft"... > Oder kurz vor Mitternacht mit einer leicht vorgehenden Uhr? Da schlafen > doch alle! "security by accuracy". Wer so heikle Sachen machen möchte, wie mitten in der Nacht (zur besten Hackerzeit) seinen Kontostand online abfragen, sollte auf genau gehende Uhren achten - das steht in jedem besseren wie-sichere-ich-meinen-PC-Heftchen. ;-) </sarkusmus-mode-off> -stefan- |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-22 11:21:27
|
Hallo Olaf, danke für die Infos! > Derzeitiges Verfahren bei mir: > ... > 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. Wenn Du die Zwischensumme entfernen würdest, hätte das den Effekt, dass zwei identische Buchungen auch die selbe Checksumme hätten (weil alle anderen Werte ja tatsächlich identisch sein KÖNNTEN). Aus diesem Blickwinkel halte ich das Einbringen des aktuellen Saldos für gar nicht mal so schlecht. Wäre halt nur blöd, wenn es tatsächlich passieren kann, dass zusätzliche Buchungen INMITTEN schon existierender Buchungen auftauchen, dann wären nämlich alle nachfolgenden Salden und damit auch die Checksummen nachfolgender Buchungen falsch... :) Aber wie Du schon sagtest - man kann da wahrscheinlich unendlich viel Aufwand betreiben, um alle möglichen und unmöglichen Fälle abzudecken. Grüße -stefan- |
|
From: Olaf W. <hbc...@wi...> - 2009-04-22 11:45:14
|
Hi, > Wenn Du die Zwischensumme entfernen würdest, hätte das den Effekt, dass > zwei identische Buchungen auch die selbe Checksumme hätten (weil alle > anderen Werte ja tatsächlich identisch sein KÖNNTEN). Stimmt. Jetzt wo du's sagst, erinnere ich mich wieder. Genau das war der Grund, warum ich das mit reingenommen hatte. Es macht die Buchung innerhalb des Tages nahezu eindeutig. > Aus diesem Blickwinkel halte ich das Einbringen des aktuellen Saldos > für gar nicht mal so schlecht. Wäre halt nur blöd, wenn es tatsächlich > passieren kann, dass zusätzliche Buchungen INMITTEN schon existierender > Buchungen auftauchen, dann wären nämlich alle nachfolgenden Salden und > damit auch die Checksummen nachfolgender Buchungen falsch... :) Und genau das war der Grund, warum ich es wieder entfernen wollte ;) Naja, wie man es macht... Gruss Olaf |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-22 12:15:42
|
> > Wenn Du die Zwischensumme entfernen würdest, hätte das den Effekt, > > dass zwei identische Buchungen auch die selbe Checksumme hätten (weil > > alle anderen Werte ja tatsächlich identisch sein KÖNNTEN). > > Zwei identische Buchungen können ja auch den selben Saldo haben > wenn zwischendurch der negative Betrag bewegt wird. Stimmt, soweit hatte ich dann nicht mehr gedacht :-) -stefan- |
|
From: Olaf W. <hbc...@wi...> - 2009-04-22 12:29:04
|
On Wednesday 22 April 2009 14:15:12 HBCI4Java (Stefan Palme) wrote: > > > Wenn Du die Zwischensumme entfernen würdest, hätte das den Effekt, > > > dass zwei identische Buchungen auch die selbe Checksumme hätten (weil > > > alle anderen Werte ja tatsächlich identisch sein KÖNNTEN). > > > > Zwei identische Buchungen können ja auch den selben Saldo haben > > wenn zwischendurch der negative Betrag bewegt wird. > > Stimmt, soweit hatte ich dann nicht mehr gedacht :-) Ist aber auf jeden Fall erheblich unwahrscheinlicher als die Zwischensumme gleich komplett wegzulassen ;) Gruss Olaf |
