Re: [Hbci4java-help] impossible saldo-values in org.kapott.hbci.GV_Result.GVRKUms.UmsLine
Brought to you by:
kleiner77
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-04-27 09:40:11
|
> 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- |