hbci4java-help — all questions concerning hbci4java

Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

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

> mmh... Wenn der Stack-Trace das verrät, 

MUSS nicht, KÖNNTE aber. Hängt vom Fehler ab...

> warum wird dann an den verschiedenen Stellen die gleiche
> Message in die Exception gepackt. ;)

Erwischt. Das Error-Handling-System in HBCI4Java-2 ist...
- sagen wir mal, "suboptimal" ;-)

Ich verspreche Besserung in HBCI4Java-3.


> Hat HBCI irgendwelche Timing-Einschränkungen?

Ja, aber die liegen eher im Minuten-Bereich - sollte
als nicht wirklich ein Problem werden...

Grüße
-stefan-

Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

[Marcus W. <Ma...@Wo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

HBCI4Java (Stefan Palme) schrieb:
>
> Wenn Du den kompletten Exception-Trace geschickt hättest, wüsste
> ich wohl eher was kaputt sein könnte. Der von Dir genannte Fehler
> trat auf, als HBCI4Java versucht hat, die System-ID zu
> synchronisieren.
>
> Das kann viele Ursachen haben: die Bank antwortete nicht, die Bank
> hat mir einer Nachricht geantwortet, die HBCI4Java nicht parsen
> konnte, die Bank hat gerade selbst ein Problem, Du hast die falsche
> HBCI-Version verwendet, Du hast die falsche PIN eingegeben, ...
>
> Ist ungefähr so als gehst Du in die Auto-Werkstatt und sagst "Hier
> blinkt ein rotes Licht. Wo liegt der Fehler?" ;-)


mmh... Wenn der Stack-Trace das verrät, warum
wird dann an den verschiedenen Stellen die gleiche
Message in die Exception gepackt. ;)

Ich schau mal obs an der DSL-Leitung auch auftritt.
Log wird nicht gehen, da ich das in der Entwicklungs-
Umgebung nur per remote-debugging starten kann
(das  Java Plugin Framework spielt viel mit den Classloadern
rum.) aber den Stack-Trace müsste ich liefern können.

Hat HBCI irgendwelche Timing-Einschränkungen?
Das war mal wieder GPRS im ICE bei 120+, da dauert
alles etwas länger.

Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn3PzAACgkQf1hPnk3Z0cRUvgCeJsaGS7+jhkUEgpx6hU2QF6NT
2rEAoN9ddCztxUYC/qTwf51O8M0rXuIo
=NW5n
-----END PGP SIGNATURE-----

Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

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

> Verbesserungsvorschlag erstmal:
> Bessere Fehlermeldungen die
> a)
> ein User verstehen würde und
> 
> b)
> genau genug sagen was kaputt
> ist ohne die Situation mit erhöhrem
> Log-Level nochmal provozieren zu
> müssen. (Das kann ich machen, ein
> normaler User aber nicht.)

Wenn Du den kompletten Exception-Trace geschickt hättest, 
wüsste ich wohl eher was kaputt sein könnte. Der von Dir 
genannte Fehler trat auf, als HBCI4Java versucht hat, die 
System-ID zu synchronisieren.

Das kann viele Ursachen haben: die Bank antwortete nicht,
die Bank hat mir einer Nachricht geantwortet, die HBCI4Java
nicht parsen konnte, die Bank hat gerade selbst ein Problem,
Du hast die falsche HBCI-Version verwendet, Du hast die
falsche PIN eingegeben, ...

Ist ungefähr so als gehst Du in die Auto-Werkstatt und
sagst "Hier blinkt ein rotes Licht. Wo liegt der Fehler?" ;-)

Grüße
-stefan-

Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

[Marcus W. <Ma...@Wo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

HBCI4Java (Stefan Palme) schrieb:
>> Ich bekomme immer "org.kapott.hbci.exceptions.ProcessException:
>> Fehler beim Ermitteln einer neuen System-ID"
>>
>> kann das mal jemand in`s Deutsche übersetzen? ;)
>
> Wenn Du einen komplettes Log (am besten Level 5) liefern kannst,
> ist das sicherlich möglich ;-)

Verbesserungsvorschlag erstmal:
Bessere Fehlermeldungen die
a)
ein User verstehen würde und

b)
genau genug sagen was kaputt
ist ohne die Situation mit erhöhrem
Log-Level nochmal provozieren zu
müssen. (Das kann ich machen, ein
normaler User aber nicht.)

Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn3PDkACgkQf1hPnk3Z0cQxRACgoDNSxEIie/lYaz8mydcwFVN0
NAQAnj+n6SYn6FwN5jUUXotzMI8gh30u
=B7aF
-----END PGP SIGNATURE-----

Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

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

> Ich bekomme immer
> "org.kapott.hbci.exceptions.ProcessException: Fehler beim Ermitteln
> einer neuen System-ID"
> 
> kann das mal jemand in`s Deutsche übersetzen? ;)

Wenn Du einen komplettes Log (am besten Level 5) liefern kannst,
ist das sicherlich möglich ;-)

-stefan-

Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

[Marcus W. <Ma...@Wo...>]

Ich bekomme immer
"org.kapott.hbci.exceptions.ProcessException: Fehler beim Ermitteln
einer neuen System-ID"

kann das mal jemand in`s Deutsche übersetzen? ;)

Marcus

Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

[Marcus W. <Ma...@Wo...>]

On Tue, 28 Apr 2009 09:05:05 +0200, "HBCI4Java (Stefan Palme)"
<hbc...@ka...> wrote:
>> FinPad zeigt nur ein Endsaldo an, unter "Kontoumsätze" sind keine
>> Saldi am Ende eines Tages zu sehen. Wo müssten diese auftauchen?
> 
> Kann ich nicht sagen, ich kenne FinPad nicht. 

Ich dachte auch eher an eine Antwort von Rolf. ;)

>> Für GVRKUms.BTag habe ich heute im Zug das HBCI-Plugin von
>> jGnucashLib erweitert um auf Wunsch auch nur die Saldo-Buchungen
>> anzulegen. 
> 
> Was sind "Saldo-Buchungen"?


Wie vorher im Thread geschrieben erzeuge ich 0-Buchungen am Ende
jedes Tages an dem was automatisch imporiert wurde, die in ihrer
Beschreibung den Saldo, wie er sein sollte nennen.

Das Programm ist dazu da Buchungen zwischen der Bank und der
lokalen Fibu abzugleichen. Also fehlende zu importieren, bestehende
mit minimal falschem Datum zu verschieben und auf der Bank nicht
existierende in der Fibu zu markieren.
Die Saldo-Buchungen dienen dazu, dass ein Nutzer nach dem
automatischen und nicht interaktivem Lauf schnell zu der Stelle
findet, wo etwas nicht stimmt bzw. eine Bestätigung hat dass der
Salso von Bank und Fibu übereinstimmen.

Ich rede hier von 1-3 Monaten an Daten und sowas wie 100 in
der Fibu automatisch erstellte Buchungen aus eingehenden
Abrechnungs-Dokumenten(pdf,csv,...), Webshop-Bestellungen,
Belegen, Rechnungs-Emails, Inventuren, ... bzw. eben Scripten
die auf das Auftauchen von Buchungen in der HBCI-fähigen Bank
welche bestimmten regulären Ausdrücken genügen reagieren.

Das ganze ist ein Werkzeug speziell für die Automatisierung von
massenhaften und sich wiederholenden Fibu-Aufgaben für Leute die
Gnucash oder eine Fibu mit dem Gnucash-Dateiformat nutzen.
So komplett mit sauber dokumentierter API, Scripting-Fähigkeit
in 10+ Sprachen, Plugin-Schnittstellen, ... .

Nutze ich seid Jahren sehr erfolgreich. Ich möchte sowas echt nicht
mehr missen. ;)

Marcus

Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

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

Hallo,

> Also, kurzes Update:
> 
> FinPad zeigt nur ein Endsaldo an, unter "Kontoumsätze" sind keine
> Saldi am Ende eines Tages zu sehen. Wo müssten diese auftauchen?

Kann ich nicht sagen, ich kenne FinPad nicht. 

> Für GVRKUms.BTag habe ich heute im Zug das HBCI-Plugin von
> jGnucashLib erweitert um auf Wunsch auch nur die Saldo-Buchungen
> anzulegen. 

Was sind "Saldo-Buchungen"?

Grüße
-stefan-

Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

[Marcus W. <Ma...@Wo...>]

Also, kurzes Update:

FinPad zeigt nur ein Endsaldo an, unter "Kontoumsätze" sind keine
Saldi am Ende eines Tages zu sehen. Wo müssten diese auftauchen?

Für GVRKUms.BTag habe ich heute im Zug das HBCI-Plugin von
jGnucashLib erweitert um auf Wunsch auch nur die Saldo-Buchungen
anzulegen. Leider war 5min bevor der endlich alles für einen Testlauf
bereit war die Mobilfunk-Verbindung weg. Evtl. klappts heute Abend
auf der Rückfahrt. (die typischen config-Probleme mit HBCI4Java.
Nicht dran gedacht dass die HBCI-URL keine URL ist sondern man
das https:// abschneiden muss. Die Kontonummer das erste mal ohne
die + "00" für das korrekte Unterkonto angegeben, ... sowas hält
halt auf.)

Marcus

Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

[Marcus W. <Ma...@Wo...>]

On Mon, 27 Apr 2009 09:14:41 +0200, "HBCI4Java (Stefan Palme)"
<hbc...@ka...> wrote:
> Hallo Marcus,
> 
> On Sun, 2009-04-26 at 21:14 +0200, Marcus Wolschon wrote:
>> I'm getting my transactions just fine but the saldo-values
>> I get in the org.kapott.hbci.GV_Result.GVRKUms.UmsLine
>> instances are just crazy.
>> What is the best strategy to trace this issue to
>> it`s source?
> 
> Lass Dir die zurückgemeldeten Buchungungen am besten mal
> tageweise zurückgeben (gvrresult.getDataPerDay) - damit
> erhälst Du eine Liste von GVRKUms.BTag-Objekten. 

Danke für das Feedback,

ich probiere heute Abend mal die fintstools. Hab grad den
Download-Link bekommen.
Die GVRKUms.BTag -Geschichte war mir noch nicht bekannt.
Könnte den Buchungs-Abgleichs-Batch deutlich vereinfachen.
(HBCI-import in Gnucash mittels jGnucashLib
 http://apps.sourceforge.net/mediawiki/jgnucashlib/index.php?title=Main_Page
 mit Ausführung von Scripten bei Import/Zuordnung
 komplexerer Buchungen.)

Die Saldi nutze ich halt indem am Ende jedes Tages für den
eine noch fehlende Buchung importiert wurde oder eine
bestehende Buchung verschoben wurde eine 0-Buchung mit dem
Saldo angelegt wird. Damit kann man manuell nach so einem
Lauf fehlerhafte Buchungen leicht erkennen. Ohne ist das
ein **** manueller Aufwand, da mir die Bank im Web nur
das Salso vor 90, vor 30 und vor 10 Tagen nennt. Also potentiell
ein 60 Tage Zeitraum mit so 5-20 Buchungen pro Tag manuell
durchzusehen ist wenn irgendwo der Saldo nicht stimmt.

Marcus

Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

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

> Die GVRKUms.BTag -Geschichte war mir noch nicht bekannt.
> Könnte den Buchungs-Abgleichs-Batch deutlich vereinfachen.
> ...

Ja, für Deine Anwendung scheint die Auswertung der BTage 
sinnvoll zu sein.

Wenn ich das jetzt richtig aus dem Kopf weiß, funktioniert
das in HBCI4Java so: Der Saldo, der als btag.start bzw. btag.end
in HBCI4Java verfügbar ist, ist der, der direkt von der Bank
im MT940 drin steht - ein Fehler in diesen Daten wäre also
ein Fehler der Bank (oder ein MT940-Parsing-Problem).

Die Salden, die an den einzelnen Buchungen dran stehen 
(umsline.saldo), errechnen sich kumulativ aus dem Startsaldo
des jeweiligen BTages +/- den "values" der einzelnen Buchungen.
Hier können also Fehler entstehen, wenn mal ein komischer
Betrag für eine Buchung dabei ist...

Wenn an einer Buchung also mal ein falscher Saldo dransteht,
müsste sich dieser Fehler theoretisch durch alle nachfolgenden
Buchungen DES SELBEN BUCHUNGSTAGES fortsetzen. Für den nächsten
Buchungstag sollte wieder alles in Ordnung sein (es sei denn,
für den nächsten Buchungstag ist der Wert von BTAG.start 
ebenfalls irgendwie "broken").

Wenn Du die Ursache findest wäre ich jedenfalls interessiert
daran. Spontan fällt mir dazu ein, dass die Bank z.B. "vergessen"
könnte, für jeden Tag einen Startsaldo mitzuliefern. Da
HBCI4Java aber davon ausgeht, dass ein solcher immer vorhanden
ist (ist in MT940 ein PFLICHT-Feld), kann es sein, dass HBCI4Java
beim Fehlen eines solchen Startsaldos den Wert "0" annimmt -
was möglicherweise zu dem von Dir beobachteten Effekt führt...

Diesen bankseitigen Fehler könnte ich in HBCI4Java nämlich
noch abfangen: fehlt der Startsaldo, könnte HBCI4Java einfach
mit dem bisher errechneten Saldo weitermachen und eine dicke
fette Warnung ausgeben, dass hier kaputte Daten von der Bank
geliefert werden :-)

Grüße
-stefan-

Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

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

Hallo Marcus,

On Sun, 2009-04-26 at 21:14 +0200, Marcus Wolschon wrote:
> I'm getting my transactions just fine but the saldo-values
> I get in the org.kapott.hbci.GV_Result.GVRKUms.UmsLine
> instances are just crazy.
> What is the best strategy to trace this issue to
> it`s source?

Lass Dir die zurückgemeldeten Buchungungen am besten mal
tageweise zurückgeben (gvrresult.getDataPerDay) - damit
erhälst Du eine Liste von GVRKUms.BTag-Objekten. 

In einem solchen BTag-Objekt könntest Du zunächst mal
den "start"-Saldo ausgeben, danach alle darin enthaltenen
Buchungssätze (UmsLine) mit ihren jeweiligen Beträgen und
dem Saldo, und am Ende den "end"-Wert des BTages.

Irgendwo da muss der Fehler zu sehen sein.

Grüße
-stefan-

Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

[Rolf V. <ro...@we...>]

> -----Ursprüngliche Nachricht-----
> Von: "Marcus Wolschon" <Ma...@Wo...>
> Gesendet: 26.04.09 21:15:38
> An: hbc...@li...
> Betreff: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

> Hello,
>
> I'm getting my transactions just fine but the saldo-values
> I get in the org.kapott.hbci.GV_Result.GVRKUms.UmsLine
> instances are just crazy.
> Sometimes they are right but sometimes they are lie
> -8094 eur  while the account actually was way > 0 and
> has never ever been below zero.
>
> Did anyone else get this?
> What is the best strategy to trace this issue to
> it`s source?
> btw, my bank is Comdirect Bank AG.

Hallo,
(Zunächst: Ich antworte einfach mal auf deutsch, weil das auf dieser Mailingliste so üblich ist, und es ja laut deiner Homepage sowieso deine Muttersprache ist, ich hoffe, damit ist jeder einverstanden.)

Zum eigentlichen Problem: Ich würde testweise mal ein anderes Programm einsetzen, aber den gleichen HBCI-Zugang (gleiches Konto, gleiche Zugangsdaten etc.). Dann dürfe sich schnell zeigen, ob die Daten ganz einfach falsch von der Bank geliefert werden, oder ob HBCI4Java die Bankdaten nur falsch auswertet. Spontan würden mir die Subsembly FinTS Tools einfallen, die gibt es auf http://fints-api.de/fintstools.html, und die sind laut der Homepage für private Zwecke kostenlos (wenn auch nicht im Quellcode verfügbar). Man muss zunächst mit dem FinAdmin den Zugang einrichten, und kann dann z. B. mit dem FinPad auf das Konto zugreifen. Hierbei wird auch ein Trace erstellt, der die Kommunikation mit der Bank auf niedriger Abstraktionsebene beschreibt. Falls die Software die gleichen Werte liefert, wie HBCI4Java, kann es sich eigentlich nur um einen Fehler der Bank handeln, in dem Fall müsste man halt Kontakt zu dieser aufnehmen, und hoffen, dass die Bank sich nicht querstellt. Falls die Software alles richtig abrufen sollte, hat HBCI4Java evtl. einen Bug.

> Marcus

Rolf

[Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine

[Marcus W. <Ma...@Wo...>]

Hello,

I'm getting my transactions just fine but the saldo-values
I get in the org.kapott.hbci.GV_Result.GVRKUms.UmsLine
instances are just crazy.
Sometimes they are right but sometimes they are lie
-8094 eur  while the account actually was way > 0 and
has never ever been below zero.

Did anyone else get this?
What is the best strategy to trace this issue to
it`s source?
btw, my bank is Comdirect Bank AG.

Marcus

Re: [Hbci4java-help] Algos zur Duplikaterkennung (was: GVRKUms.UmsLine.instref ändert sich?)

[Rolf V. <ro...@we...>]

> -----Ursprüngliche Nachricht-----
> Von: "Martin Preuss" <aqu...@gm...>
> Gesendet: 22.04.09 23:12:49
> An: hbc...@li...
> CC: "HBCI4Java (Stefan Palme)" <hbc...@ka...>
> Betreff: Re: [Hbci4java-help] Algos zur Duplikaterkennung (was: GVRKUms.UmsLine.instref ändert sich?)

> On Mittwoch, 22. April 2009, HBCI4Java (Stefan Palme) wrote:
> [...]
> > Ich denke mal, Du antwortest Dir hier selbst. Das Problem liegt
> > nicht in der HBCI-Spezifikation - so komplex die auch werden mag, hier
> > werden ja die Kontoauszüge nur als binäre, nicht "interpretierte"
> > Daten in einem quasi-proprietären Format - nämlich SWIFT-MT940
> > - transportiert.
> [...]
>
> Ist mir ja klar. Allerdings: An anderer Stelle hat man sich dazu
> durchgerungen, ein eigenes Format zu verwenden, naemlich bei den
> Zahlungsauftraegen (und bei Dauerauftraegen. Und bei terminierten Auftraegen).
>
> In diesem Fall werden zwar fuer Sammelauftraege immer noch DTAUS-Daten
> verwendet (so wie halt SWIFT MT940 beim Umsatzabruf), aber fuer
> Einzelauftraege gibt es eigene Segmente...
>
> Soll heissen: Voellig unmoeglich kann es nicht sein, HBCI-eigene Formate zu
> verwenden...
>
> Und fuer SEPA-Auftraege stellt man ja auch wieder andere Daten ein... Es kann
> ja keine unloesbare Aufgabe fuer Entwickler von Bankservern sein, hier Daten
> in einem anderen Format als MT940 zu versenden... Von daher verstehe ich
> nicht, wo die Blockade eigentlich liegt.

Ich habe keine harten Fakten zur Hand, aber eine recht simple Vermutung, an deren Wahrheit ich trotzdem glaube: Banken rechnen scharf, und geben nur Geld aus (und seien es auch nur "Peanuts"), wenn es irgendwelche handfesten Vorteile bringt, alles, was die Bankkunden nicht allzusehr stört, bleibt einfach so, wie es ist. Das ist technisch oftmals nicht sehr wünschenswert (um die ganzen derben Begriffe mal nicht zu verwenden), aber vermutlich ganz einfach billiger, als irgendwas zu ändern. Beispiele für Ärgerlichkeiten in Banksystemen gibt es mehr als genug:

-> Warum wandeln manche Banken/Rechenzentren (z. B. FIDUCIA) alle Zeichen der Verwendungszwecke in Großbuchstaben um?
-> Warum verwenden so viele Bankportale kaputtes HTML (in dem Sinne, dass es nicht valide ist, und oft auch nicht Textbrowserkompatibel)?
-> Warum kann man bei einigen Banken (z. B. einige Sparkassen) keine längere PIN, als 5 Zeichen verwenden, oder zumindest nicht per HBCI?
-> Warum zeigen manche Banken im Portal (gleiches Problem z. T. auch per HBCI) bei eingehenden Zahlungen nicht die Bankverbindung des Zahlungssenders an?
-> Warum kann man bei der GAD per HBCI keine Liste mit Konten bekommen, auf die man zugreifen kann und darf, bei allen anderen Banken/Rechenzentren ist das ja schließlich auch möglich?
-> Warum kommt es immer wieder vor, das eine Information (z. B. Kreditrahmen, aktuell verfügbarer Betrag, etc.) entweder nur im Portal, oder nur per HBCI verfügbar ist, aber nicht auf beiden Wegen, selbst wenn man die gleichen Credentials zum Login verwenden kann?
-> Warum kam es in der Übergangszeit von nichtindizierten TANs zu indizierten TANs bei manchen Banken vor, dass man im Portal nach einer bestimmten TAN gefragt wurde, man jedoch per HBCI einfach eine beliebige TAN eingeben konnte (was den Sicherheitsgewinn von iTANs irgendwie als ziemliche Makulatur erscheinen lässt ...)?
-> Warum kann man bei manchen Banken ein Alias zum Login vergeben, dieses jedoch nur im Portal verwenden, nicht per HBCI (z. B. FIDUCIA)?

Alles das macht meiner Meinung nach rein technisch gesehen wirklich absolut keinen Sinn, aber Banksysteme sind wohl oft historisch gewachsen, und wer weiß, vielleicht sind manche Komponenten so alt, dass es schwierig ist, diese überhaupt noch zu verändern, weil Code und Doku nur noch von ganz wenigen Personen im Unternehmen überhaupt noch verstanden werden.

Und solange sich nicht genug Kunden der Bank beschweren, und drohen, zur Konkurrenz zu wechseln, werden diese Punkte von den Entscheidungsträgern vermutlich nicht als lösenswertes Problem angesehen.

Außerdem könnte ich mir vorstellen, dass viele Banken intern wohl recht viel Bürokratie angehäuft haben, das dürfte selbst kleinere Überarbeitungen des Programmcodes der Banksysteme viel teurer und zeitraubender machen, als eine wesentlich größere Überarbeitung eines OpenSouce-Projektes oder eines kleinen, agilen ClosedSource-Projektes.

> Oder kann da eventuell ein Kenner der Banken-IT-Welt naeheres zu sagen?
>
> Aber ich bin hier aehnlich pessimistisch wie Du: Da wir uns schon so lange mit
> dem Problem der fehlenden ID in Umsatzdaten herumschlagen muessen - und sicher
> nicht nur wir - und es bis heute keine Loesung gibt, vermute ich auch nicht,
> dass es in naher Zukunft eine geben wird...
>
> Gruss
> Martin

Rolf Viehmann

Re: [Hbci4java-help] Algos zur Duplikaterkennung (was: GVRKUms.UmsLine.instref ändert sich?)

[Martin P. <aqu...@gm...>]

On Mittwoch, 22. April 2009, HBCI4Java (Stefan Palme) wrote:
[...]
> Ich denke mal, Du antwortest Dir hier selbst. Das Problem liegt
> nicht in der HBCI-Spezifikation - so komplex die auch werden mag, hier
> werden ja die Kontoauszüge nur als binäre, nicht "interpretierte"
> Daten in einem quasi-proprietären Format - nämlich SWIFT-MT940
> - transportiert.
[...]

Ist mir ja klar. Allerdings: An anderer Stelle hat man sich dazu 
durchgerungen, ein eigenes Format zu verwenden, naemlich bei den 
Zahlungsauftraegen (und bei Dauerauftraegen. Und bei terminierten Auftraegen).

In diesem Fall werden zwar fuer Sammelauftraege immer noch DTAUS-Daten 
verwendet (so wie halt SWIFT MT940 beim Umsatzabruf), aber fuer 
Einzelauftraege gibt es eigene Segmente...

Soll heissen: Voellig unmoeglich kann es nicht sein, HBCI-eigene Formate zu 
verwenden...

Und fuer SEPA-Auftraege stellt man ja auch wieder andere Daten ein... Es kann 
ja keine unloesbare Aufgabe fuer Entwickler von Bankservern sein, hier Daten 
in einem anderen Format als MT940 zu versenden... Von daher verstehe ich 
nicht, wo die Blockade eigentlich liegt.

Oder kann da eventuell ein Kenner der Banken-IT-Welt naeheres zu sagen?

Aber ich bin hier aehnlich pessimistisch wie Du: Da wir uns schon so lange mit 
dem Problem der fehlenden ID in Umsatzdaten herumschlagen muessen - und sicher 
nicht nur wir - und es bis heute keine Loesung gibt, vermute ich auch nicht, 
dass es in naher Zukunft eine geben wird...


Gruss
Martin

-- 
"Things are only impossible until they're not"

Martin Preuss - http://www2.aquamaniac.de/
AqBanking - http://www.aqbanking.de/
LibChipcard - http://www.libchipcard.de/

Re: [Hbci4java-help] Algos zur Duplikaterkennung (was: GVRKUms.UmsLine.instref ändert sich?)

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

> Mich aergert aber vor allem, dass es bis in die neuesten Versionen der 
> HBCI-/FinTS-Specs scheinbar nicht moeglich war, sich darauf zu verstaendigen, 
> ein solches Feld - wie auch immer - einzufuehren.
> 
> Man einigt sich ja auch auf immer komplexere Pin-TAN-Verfahren, da muesste 
> doch auch Raum fuer eine so wirklich *essentielle* Forderung sein...
> 
> Letztlich muss man sonst sagen: Fuer eine wirklich sichere Automatisierung ist 
> HBCI nicht geeignet. EBICS dann aber uebrigends auch nicht, denn auch hier 
> kommt SWIFT MT940 zum Einsatz... Und das kann ja wohl nicht das letzte Wort 
> sein...

Ich denke mal, Du antwortest Dir hier selbst. Das Problem liegt
nicht in der HBCI-Spezifikation - so komplex die auch werden mag, hier
werden ja die Kontoauszüge nur als binäre, nicht "interpretierte"
Daten in einem quasi-proprietären Format - nämlich SWIFT-MT940 
- transportiert.

Das Problem wäre also das MT940-Format - und das wird an so vielen
anderen Stellen (neben HBCI) auch noch verwendet, dass eine
entsprechende Änderung/Erweiterung wohl nicht zu erwarten ist...

Eine Möglichkeit wäre evtl, in die Antwortsegmente zu einer Umsatz-
anfrage nicht die binären MT940-Daten einzustellen, sondern "richtige"
HBCI-Segmente, wobei z.B. jeweils ein "HITRA"-Segment (= Transaktion)
genau EINE Buchung beschreibt, jeweils mit eigenen DEGs für die
beteiligten Konten, Betrag, Verwendungszwecke etc - also alles schön
in HBCI-Syntax.

Ich vermute aber, dass das 
  a) evtl. die Nachrichtengröße sprengen könnte (obwohl - soviel größer
     als MT940-Datenblöcke wäre ein äquivalentes Segment auch nicht), 
     und/oder

  b) <böse-mode> die HBCI-Spez-Macher und kommerziellen Server-Implementierer 
     keine Lust haben, so was zu basteln </böse-mode> - vllt. sollte ich
     im HBCI4Java-Demo-Server mal so einen proprietären GV implementieren,
     nur um zu zeigen, dass es technisch geht...

Andere (technische) Gründe für das Fehlen von "sauberen" HBCI-Segmenten
für Kontoauszugsdaten sehe ich im Moment irgendwie nicht - aber möglicherweise
fehlt mir da auch der Durchblick in der Bankenwelt. Letztendlich wird
die offizielle Begründung für diesen Mangel wohl lauten, dass das ganze
"historisch gewachsen" ist und die MT940-Daten niemals direkt für die
Verarbeitung durch Kundensysteme gedacht waren...

Wie auch immer - solange wir keine eigene groooße Bank betreiben und/oder
eine Software herstellen, die Geld kostet und von Banken gekauft wird, haben
wir da wohl auch kein Mitspracherecht - wie überall stehen hier wohl
kommerzielle Interessen über technisch sinnvollen Lösungen.

Und bevor ich jetzt noch mehr Frust bekomme hör ich lieber auf, weiter
darüber nachzudenken :-)

-stefan-

Re: [Hbci4java-help] Algos zur Duplikaterkennung (was: GVRKUms.UmsLine.instref ändert sich?)

[Martin P. <aqu...@gm...>]

Moin,

On Mittwoch, 22. April 2009, HBCI4Java (Stefan Palme) wrote:
[...]
> Allerdings - ähnlich wie alle anderen "Ausrutscher" der Banken bzw.
> selten vorkommende UseCases (wer hat schon mehrmals am Tag exakt
> gleiche Buchungen).
>
> Aber "wasserdicht" ist Dein Algorithmus damit auch nicht ;-)
[...]

Du kannst immer Faelle finden, auf die gar kein Vorgehen passt. Das 
schlimmste, was Dir allerdings in diesem Fall mit meinem Algo passieren kann, 
ist, dass Duplikate entstehen, vor denen Du auch noch gewarnt wirst. 
Wenn man dann noch beruecksichtigt, dass es ohnehin schon selten ist, dass 
mehrere gleiche Umsaetze an einem Tag auftauchen, und es noch seltener ist, 
dass  die Bank das Format ihrer Umsaetze aendert, kann man schon sagen, dass 
der Algo wasserdicht ist ;-)

Zumindest aber Spritzwasser-geschuetzt ;-)

[...]
> > Man koennte natuerlich auch die Vergleiche etwas laxer handhaben, so dass
> > man beispielsweise den Verwendungszweck nicht so scharf vergleicht.
>
> Kommt drauf an, wie man diese "Unschärfe" implementiert. Wenn ich z.B.
> massenweise Auszahlungen an das selbe Konto von 1 cent mache und im
[...]

Ich habe ja schon geschrieben, dass dies unsicherer ist als das, was ich 
bisher mache. Und weil solche Faelle sehr selten sind, ist der Aufwand fuer 
den Benutzer so wie es jetzt ist deutlich geringer als mit einer Unschaerfe 
(bei der es immer mehr falsch positive Faelle gibt als mit der bisherigen 
Methode).

[...]
> auch nur um einen Zählerwert ("Auszahlung #001", "Auszahlung #002"),
[...]

Das ist noch einer der einfacheren Faelle: Hier tauchen jeweils 2 "Woerter" 
auf, von denen eines 100% gleich ist und das andere 75% (natuerlich mit 
abnehmender Aehnlichkeit beim 2. Wort, wenn der Zaehler um mehr als eine 
Stelle steigt).

Aber der von Dir geschilderte Fall, dass wilde Kombinationen aus Buchstaben 
und Zahlen im Verwendungszweck auftauchen (z.B. Rechnungsnummern, und das ist 
ja nicht selten), ist halt damit ueberhaupt nicht zu greifen.

Da muesste man dann noch weitere Informationen dazunehmen, im Idealfall z.B. 
die Kontoverbindung der Gegenseite. Aber genau die wird von manchen Banken 
halt nicht geliefert, also kann man dieses Vorgehen auch nicht 
verallgemeinern.

[...]
> Viiiiel einfach wäre es, wenn die Bank eine eindeutige ID für jede
> Buchung verwalten würde (tut sie intern bestimmt) und diese ID auch
> über HBCI kommunizierbar wäre (geht wahrscheinlich deshalb nicht, weil
> SWIFT-MT940 halt kein Feld dafür vorsieht).
[...]

Naja, gut, man koennte dafuer aber ja einfach eines der bestehenden aber meist 
ungenutzten Felder verwenden, oder man definiert einfach ein weiteres ?xx-
Element im Tag :86: oder so... Also moeglich waere das auf jeden Fall.

Mich aergert aber vor allem, dass es bis in die neuesten Versionen der 
HBCI-/FinTS-Specs scheinbar nicht moeglich war, sich darauf zu verstaendigen, 
ein solches Feld - wie auch immer - einzufuehren.

Man einigt sich ja auch auf immer komplexere Pin-TAN-Verfahren, da muesste 
doch auch Raum fuer eine so wirklich *essentielle* Forderung sein...

Letztlich muss man sonst sagen: Fuer eine wirklich sichere Automatisierung ist 
HBCI nicht geeignet. EBICS dann aber uebrigends auch nicht, denn auch hier 
kommt SWIFT MT940 zum Einsatz... Und das kann ja wohl nicht das letzte Wort 
sein...


Gruss
Martin


-- 
"Things are only impossible until they're not"

Martin Preuss - http://www2.aquamaniac.de/
AqBanking - http://www.aqbanking.de/
LibChipcard - http://www.libchipcard.de/

Re: [Hbci4java-help] Algos zur Duplikaterkennung (was: GVRKUms.UmsLine.instref ändert sich?)

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

> > Das einzige Problem, was Du damit nicht abfangen kannst, ist das, was
> > Olaf erwähnt hat. An einem Tag kommen bei der Buchung X die Verwendungs-
> > zweckzeilen mit "äöü", am nächsten Tag enthält die SELBE Buchung statt
> > dessen auf einmal ae, oe, ue.
> Das stimmt, allerdings ist dieser Fall hoechst selten.

Allerdings - ähnlich wie alle anderen "Ausrutscher" der Banken bzw.
selten vorkommende UseCases (wer hat schon mehrmals am Tag exakt
gleiche Buchungen). 

Aber "wasserdicht" ist Dein Algorithmus damit auch nicht ;-)

> Bestehende Umsaetze werden bei mir niemals entfernt. Der Benutzer hat ja 
> eventuell schon Informationen mit dem gespeicherten Umsatz verbunden, d.h. 
> diese Info einfach zu loeschen faellt weg (sie kann ja auch auf anderem Weg 
> erzeugt worden sein, z.B. durch einen Dateiimport).

Genau - das ist das eigentliche Kernproblem. Dass man schon abgeholte
Umsätze evtl. anderweitig referenziert, dieser Umsatz in neu abgeholten
Kontoauszügen auf einmal nicht mehr zu finden ist und die Anwendung dann
nicht weiß, welcher evtl. neue Umsatzeintrag diesem alten entspricht 
(denn dass eine Transaktion tatsächlich mal ohne Ersatz verschwindet
habe ich wirklich noch NIE gehört).

> Man koennte natuerlich auch die Vergleiche etwas laxer handhaben, so dass man 
> beispielsweise den Verwendungszweck nicht so scharf vergleicht. 

Kommt drauf an, wie man diese "Unschärfe" implementiert. Wenn ich z.B.
massenweise Auszahlungen an das selbe Konto von 1 cent mache und im
Verwendungszweck immer nur einen Zähler erhöhe, so dass sich zwischen
diesen Buchungen praktisch NUR der Verwendungszweck unterscheidet, und
auch nur um einen Zählerwert ("Auszahlung #001", "Auszahlung #002"),
dann wäre das schon schwierig - außer man beschränkt die Unschärfe
auf Buchstaben und/oder Sonderzeichen - dann wären aber zwei
Überweisungen mit Rechnungsnummer "KA12345" und "KB12345" an das
selbe Konto mit selben Betrag auch "identisch" - obwohl sie in
Wirklichkeit zwei tatsächlich verschiedene Buchungen sind.

Besser wäre dann sicherlich eine Art "Normalisierung" in der Art, dass
man sagt, dass alle Umlaute prinzipiell nach "ae oe ue" konvertiert
werden, dass sonderzeichen komplett rausgelöscht werden usw. - und erst
diese normalisierten Verwendungszwecke dann verglichen werden. Aber
auch das hat seine Tücken...

Wie schon gesagt - man kann da beliebig viel Aufwand betreiben und
trotzdem nicht jeden Fall abdecken :-) 
Viiiiel einfach wäre es, wenn die Bank eine eindeutige ID für jede
Buchung verwalten würde (tut sie intern bestimmt) und diese ID auch
über HBCI kommunizierbar wäre (geht wahrscheinlich deshalb nicht, weil
SWIFT-MT940 halt kein Feld dafür vorsieht).


> BTW: Wenn ich QBankManager nach Duplikaten suchen lasse, vergleiche ich die 
> Verwendungszwecke nicht direkt, sondern mache stattdessen Fuzzy-Vergleiche mit 
> einem einstellbaren Schwellwert.

Siehe oben - das kann auch kräftig nach hinten losgehen. Hängt also
immer von den konkreten Daten ab - und einem Nutzer auch noch die
Auswahl zu ermöglichen, ob er Fuzzy-Modul #1, #2 oder #3 verwenden
will, wäre schon irgendwie zuviel verlangt vom armen Anwender :)


Grüße
-stefan-

Re: [Hbci4java-help] Algos zur Duplikaterkennung (was: GVRKUms.UmsLine.instref ändert sich?)

[Martin P. <aqu...@gm...>]

Moin,

On Mittwoch, 22. April 2009, HBCI4Java (Stefan Palme) wrote:
[...]
> Das einzige Problem, was Du damit nicht abfangen kannst, ist das, was
> Olaf erwähnt hat. An einem Tag kommen bei der Buchung X die Verwendungs-
> zweckzeilen mit "äöü", am nächsten Tag enthält die SELBE Buchung statt
> dessen auf einmal ae, oe, ue.
[...]

Das stimmt, allerdings ist dieser Fall hoechst selten. Allerdings ist mir 
dieser Fall auch schon untergekommen, und zwar ueber die Jahre mehrmals: 
Naemlich dann, wenn die Bank die Software entsprechend geaendert hatte und 
ploetzlich andere Umsatzinfos gesendet hat (also mit besagten Aenderungen bei 
den Umlauten etc).

[...]
> Was passiert eigentlich in diesem Fall (bei Dir Fall (c)): wird dann
> NUR diese Warnung ausgegeben, oder wird diese auf einmal scheinbar
> fehlende Buchung aus den lokalen Buchungsdatensätzen gelöscht? In dem
> Beispiel von Olaf wäre letzteres natürlich richtig (weil die "äöü"-
> Buchung durch eine "aeoeue"-Buchung "ersetzt" wurde).
[...]

Bestehende Umsaetze werden bei mir niemals entfernt. Der Benutzer hat ja 
eventuell schon Informationen mit dem gespeicherten Umsatz verbunden, d.h. 
diese Info einfach zu loeschen faellt weg (sie kann ja auch auf anderem Weg 
erzeugt worden sein, z.B. durch einen Dateiimport).

In einem solchen Fall entstehen also bei mir tatsaechlich Duplikate. Ich nehme 
das momentan noch hin, weil man solche sehr, sehr selten auftretende Duplikate 
zumindest in QBankManager recht einfach entfernen lassen kann.

Man koennte natuerlich auch die Vergleiche etwas laxer handhaben, so dass man 
beispielsweise den Verwendungszweck nicht so scharf vergleicht. Das ginge 
dann, wenn man z.B. immer die Kontoverbindungen des Zahlers im MT940 haette. 
Leider gibt es aber wie Du ja auch weisst immer noch Banken, die nur extrem 
rudimentaere Umsatzdaten senden, also insbesondere ohne Kontoverbindungen. 

In diesem Fall sind die einzigen verwertbaren Daten fast ausschliesslich im 
Verwendungszweck zu finden :-(


BTW: Wenn ich QBankManager nach Duplikaten suchen lasse, vergleiche ich die 
Verwendungszwecke nicht direkt, sondern mache stattdessen Fuzzy-Vergleiche mit 
einem einstellbaren Schwellwert.

Soetwas in der Art koennte man natuerlich auch beim Import machen, aber diese 
Methode ist deutlich weniger praezise als der Algo, den QBankManager derzeit 
fuer den Import verwendet.

Bisher ist es mir in den Jahren aber erst zweimal vorgekommen, dass die Bank 
die Umsatzdaten hinterruecks geaendert hat.


Gruss
Martin


-- 
"Things are only impossible until they're not"

Martin Preuss - http://www2.aquamaniac.de/
AqBanking - http://www.aqbanking.de/
LibChipcard - http://www.libchipcard.de/

Re: [Hbci4java-help] Algos zur Duplikaterkennung (was: GVRKUms.UmsLine.instref ändert sich?)

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

Hallo Martin,

dank auch für Dein Feedback ;-)

In Anbetracht der Tatsache, dass meine ursprünglichen Annahmen von 2004
wohl doch nicht immer alle erfüllt werden, sollte ich wohl auch meinen
Algorithmus noch ein klein wenig anpassen ;-)

Jedenfalls erscheint mir eine auf diesem Prinzip funktionierende
Vorgehensweise EINIGERMAßEN zuverlässig.

Das einzige Problem, was Du damit nicht abfangen kannst, ist das, was
Olaf erwähnt hat. An einem Tag kommen bei der Buchung X die Verwendungs-
zweckzeilen mit "äöü", am nächsten Tag enthält die SELBE Buchung statt
dessen auf einmal ae, oe, ue. 

Mit Deinem Algorithmus würde diese Buchung erkannt werden als "neu,
habe ich noch nicht" und zur Sammlung der Buchungen hinzugefügt werden,
wobei die "alte" Buchung mit "äöü" auf einmal nicht mehr in den
Kontoauszügen erscheint und somit die von Dir genannte Warnung aus-
gegeben wird... 

Was passiert eigentlich in diesem Fall (bei Dir Fall (c)): wird dann
NUR diese Warnung ausgegeben, oder wird diese auf einmal scheinbar
fehlende Buchung aus den lokalen Buchungsdatensätzen gelöscht? In dem
Beispiel von Olaf wäre letzteres natürlich richtig (weil die "äöü"-
Buchung durch eine "aeoeue"-Buchung "ersetzt" wurde). 

In einige Fällen kann es aber sicherlich auch sein, dass die auf einmal
nicht mehr in den Kontoauszügen zurückgemeldete Buchung tatsächlich 
existiert und somit in den lokalen Datenbeständen erhalten bleiben
sollte...

Grüße
-stefan-

On Wed, 2009-04-22 at 18:14 +0200, Martin Preuss wrote:
> Moin,
> 
> On Mittwoch, 22. April 2009, Jan Bölsche wrote:
> [...]
> > Zur Zeit favorisiere ich folgendes Verfahren, das mir recht robust
> > erscheint:
> [...]
> 
> In QBankManager - wo wir ja mit dem gleichen Problem zu kaempfen haben - loese 
> ich das bisher so:
> 
> 1. Frage einen beliebigen Zeitraum ab
> 
> 2. betrachte die empfangenen Daten: fuer jeden Tag, fuer den wir Daten 
> empfangen haben, tue dies:
> 2.a: lade alle Umsaetze dieses Tages aus der DB zur Referenz
> 2.b: fuer jeden abgeholten Umsatz dieses Tages: Zaehle, wie oft dieser Umsatz 
> in der DB fuer diesen Tag schon vorhanden ist
> 2.c: zaehle, wie oft dieser Umsatz in den abgeholten Daten fuer diesen Tag 
> vorhanden ist
> 2.d: vergleiche beide Zaehler. Hier gibt es dann theoretisch 3 Moeglichkeiten:
> a) die Anzahl der passenden Umsaetze in der DB fuer diesen Tag ist kleiner als 
> die der abgeholten, gleichen Umsaetze
> b) die Anzahl in beiden Stapeln ist gleich
> c) die Anzahl der passenden Umsaetze in der DB fuer diesen Tag ist groesser 
> als die der abgeholten, gleichen Umsaetze
> 
> Im Fall a) wird der betrachtete abgeholte Umsatz einfach hinzugefuegt.
> Im Fall b) wird der betrachtete abgeholte Umsatz ignoriert (weil er ja schon 
> vorhanden ist)
> Und der Fall c) kann eigentlich gar nicht auftreten, denn das wuerde bedeuten, 
> dass die Bank in einer frueheren Message einen Umsatz gemeldet hat, den sie 
> jetzt in der aktuellen Message nicht mehr sendet, d.h. bei der Bank ist ein 
> Umsatz verschwunden.
> 
> Dieses Verfahren ist nach meiner Erfahrung wasserdicht und wird inzwischen 
> seit mehreren Jahren erfolgreich verwendet.
> 
> Es hat die folgenden positiven Eigenschaften:
> 1) es macht keine Annahmen ueber den Zeitraum, den man abruft. D.h. man kann 
> es fuer jeden Zeitraum verwenden, funktioniert insbesondere auch fuer den 
> aktuellen Tag
> 2) es fuegt zuverlaessig solche Eintraege hinzu, die wirklich mehrfach 
> aufgetreten sind, die also wirklich mehrere gleiche Buchungen darstellen.
> 3) es macht keine Annahmen ueber die Reihenfolge der Umsaetze
> 4) es entfernt zuverlaessig Duplikate
> 
> Dieser Algorithmus fusst auf der Annahme, dass die Bank keine Umsaetze 
> verschwinden laesst. D.h. wenn eine Buchung bei einem Abruf auftaucht, muss 
> sie auch im naechsten Abruf fuer den gleichen Zeitraum auftauchen.
> 
> Bei allen Absonderlichkeiten mancher Server-Implementierungen: An diese Regel 
> halten sich bisher offensichtlich wirklich alle Banken ;-)
> 
> Der Algo ist aber auch fuer den Fall gewappnet, dass sich ein Server nicht 
> daran haelt: Dann naemlich gibt z.B. QBankManager eine Warnung aus.
> 
> 
> Gruss
> Martin
> 
> 

Re: [Hbci4java-help] Algos zur Duplikaterkennung (was: GVRKUms.UmsLine.instref ändert sich?)

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

Hallo Martin,

vielen Dank für diese Information. Ich glaube, Dein Verfahren ist  
funktional äquivalent zu meinem Vorschlag. Ich zähle die Einträge  
nicht sondern verwende eine temporäre Liste. Das Ergebnis ist aber  
identisch.
Schön daran ist auch, dass man es erkennt, falls die Bank tatsächlich  
Einträge löscht oder ändert.

Schönen Abend!
   Jan

On 22.04.2009, at 18:14, Martin Preuss wrote:

> Moin,
>
> On Mittwoch, 22. April 2009, Jan Bölsche wrote:
> [...]
>> Zur Zeit favorisiere ich folgendes Verfahren, das mir recht robust
>> erscheint:
> [...]
>
> In QBankManager - wo wir ja mit dem gleichen Problem zu kaempfen  
> haben - loese
> ich das bisher so:
>
> 1. Frage einen beliebigen Zeitraum ab
>
> 2. betrachte die empfangenen Daten: fuer jeden Tag, fuer den wir Daten
> empfangen haben, tue dies:
> 2.a: lade alle Umsaetze dieses Tages aus der DB zur Referenz
> 2.b: fuer jeden abgeholten Umsatz dieses Tages: Zaehle, wie oft  
> dieser Umsatz
> in der DB fuer diesen Tag schon vorhanden ist
> 2.c: zaehle, wie oft dieser Umsatz in den abgeholten Daten fuer  
> diesen Tag
> vorhanden ist
> 2.d: vergleiche beide Zaehler. Hier gibt es dann theoretisch 3  
> Moeglichkeiten:
> a) die Anzahl der passenden Umsaetze in der DB fuer diesen Tag ist  
> kleiner als
> die der abgeholten, gleichen Umsaetze
> b) die Anzahl in beiden Stapeln ist gleich
> c) die Anzahl der passenden Umsaetze in der DB fuer diesen Tag ist  
> groesser
> als die der abgeholten, gleichen Umsaetze
>
> Im Fall a) wird der betrachtete abgeholte Umsatz einfach hinzugefuegt.
> Im Fall b) wird der betrachtete abgeholte Umsatz ignoriert (weil er  
> ja schon
> vorhanden ist)
> Und der Fall c) kann eigentlich gar nicht auftreten, denn das wuerde  
> bedeuten,
> dass die Bank in einer frueheren Message einen Umsatz gemeldet hat,  
> den sie
> jetzt in der aktuellen Message nicht mehr sendet, d.h. bei der Bank  
> ist ein
> Umsatz verschwunden.
>
> Dieses Verfahren ist nach meiner Erfahrung wasserdicht und wird  
> inzwischen
> seit mehreren Jahren erfolgreich verwendet.
>
> Es hat die folgenden positiven Eigenschaften:
> 1) es macht keine Annahmen ueber den Zeitraum, den man abruft. D.h.  
> man kann
> es fuer jeden Zeitraum verwenden, funktioniert insbesondere auch  
> fuer den
> aktuellen Tag
> 2) es fuegt zuverlaessig solche Eintraege hinzu, die wirklich mehrfach
> aufgetreten sind, die also wirklich mehrere gleiche Buchungen  
> darstellen.
> 3) es macht keine Annahmen ueber die Reihenfolge der Umsaetze
> 4) es entfernt zuverlaessig Duplikate
>
> Dieser Algorithmus fusst auf der Annahme, dass die Bank keine Umsaetze
> verschwinden laesst. D.h. wenn eine Buchung bei einem Abruf  
> auftaucht, muss
> sie auch im naechsten Abruf fuer den gleichen Zeitraum auftauchen.
>
> Bei allen Absonderlichkeiten mancher Server-Implementierungen: An  
> diese Regel
> halten sich bisher offensichtlich wirklich alle Banken ;-)
>
> Der Algo ist aber auch fuer den Fall gewappnet, dass sich ein Server  
> nicht
> daran haelt: Dann naemlich gibt z.B. QBankManager eine Warnung aus.
>
>
> Gruss
> Martin
>
>
> -- 
> "Things are only impossible until they're not"
>
> Martin Preuss - http://www2.aquamaniac.de/
> AqBanking - http://www.aqbanking.de/
> LibChipcard - http://www.libchipcard.de/
>

[Hbci4java-help] Algos zur Duplikaterkennung (was: GVRKUms.UmsLine.instref ändert sich?)

[Martin P. <aqu...@gm...>]

Moin,

On Mittwoch, 22. April 2009, Jan Bölsche wrote:
[...]
> Zur Zeit favorisiere ich folgendes Verfahren, das mir recht robust
> erscheint:
[...]

In QBankManager - wo wir ja mit dem gleichen Problem zu kaempfen haben - loese 
ich das bisher so:

1. Frage einen beliebigen Zeitraum ab

2. betrachte die empfangenen Daten: fuer jeden Tag, fuer den wir Daten 
empfangen haben, tue dies:
2.a: lade alle Umsaetze dieses Tages aus der DB zur Referenz
2.b: fuer jeden abgeholten Umsatz dieses Tages: Zaehle, wie oft dieser Umsatz 
in der DB fuer diesen Tag schon vorhanden ist
2.c: zaehle, wie oft dieser Umsatz in den abgeholten Daten fuer diesen Tag 
vorhanden ist
2.d: vergleiche beide Zaehler. Hier gibt es dann theoretisch 3 Moeglichkeiten:
a) die Anzahl der passenden Umsaetze in der DB fuer diesen Tag ist kleiner als 
die der abgeholten, gleichen Umsaetze
b) die Anzahl in beiden Stapeln ist gleich
c) die Anzahl der passenden Umsaetze in der DB fuer diesen Tag ist groesser 
als die der abgeholten, gleichen Umsaetze

Im Fall a) wird der betrachtete abgeholte Umsatz einfach hinzugefuegt.
Im Fall b) wird der betrachtete abgeholte Umsatz ignoriert (weil er ja schon 
vorhanden ist)
Und der Fall c) kann eigentlich gar nicht auftreten, denn das wuerde bedeuten, 
dass die Bank in einer frueheren Message einen Umsatz gemeldet hat, den sie 
jetzt in der aktuellen Message nicht mehr sendet, d.h. bei der Bank ist ein 
Umsatz verschwunden.

Dieses Verfahren ist nach meiner Erfahrung wasserdicht und wird inzwischen 
seit mehreren Jahren erfolgreich verwendet.

Es hat die folgenden positiven Eigenschaften:
1) es macht keine Annahmen ueber den Zeitraum, den man abruft. D.h. man kann 
es fuer jeden Zeitraum verwenden, funktioniert insbesondere auch fuer den 
aktuellen Tag
2) es fuegt zuverlaessig solche Eintraege hinzu, die wirklich mehrfach 
aufgetreten sind, die also wirklich mehrere gleiche Buchungen darstellen.
3) es macht keine Annahmen ueber die Reihenfolge der Umsaetze
4) es entfernt zuverlaessig Duplikate

Dieser Algorithmus fusst auf der Annahme, dass die Bank keine Umsaetze 
verschwinden laesst. D.h. wenn eine Buchung bei einem Abruf auftaucht, muss 
sie auch im naechsten Abruf fuer den gleichen Zeitraum auftauchen.

Bei allen Absonderlichkeiten mancher Server-Implementierungen: An diese Regel 
halten sich bisher offensichtlich wirklich alle Banken ;-)

Der Algo ist aber auch fuer den Fall gewappnet, dass sich ein Server nicht 
daran haelt: Dann naemlich gibt z.B. QBankManager eine Warnung aus.


Gruss
Martin


-- 
"Things are only impossible until they're not"

Martin Preuss - http://www2.aquamaniac.de/
AqBanking - http://www.aqbanking.de/
LibChipcard - http://www.libchipcard.de/

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

[Olaf W. <hbc...@wi...>]

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

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

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

> > 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-