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-