Ich kann das beobachtete Verhalten exakt bestätigen und habe mal etwas genauer getestet.
Kurzfassung
Bei mir sind die Zwischenstände korrekt, wenn ich in den Konto-Synchronisierungsoptionen das CAMT-Format deaktiviere.
Langfassung
Ich hatte ursprünglich vermutet, dass das Problem an den zwei verschiedenen Saldo-Einträgen lag, aber der erste Eintrag ist anscheinend für das vorherige Saldo, der zweite Eintrag für das aktuelle.
Stattdessen: Möglicherweise wird das Saldo des ersten Eintrag bei der Zwischensummenbildung verwendet, selbst wenn das Datum der Transaktionen vor dem Saldodatum liegt und darin schon berücksichtigt ist?
Code
<Bal>
<Tp>
<CdOrPrtry>
<Cd>PRCD</Cd>
</CdOrPrtry>
</Tp>
<CdtLine>
<Incl>false</Incl>
<Amt Ccy="EUR">0.00</Amt>
</CdtLine>
<Amt Ccy="EUR">300.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<Dt>
<Dt>2023-10-20</Dt>
</Dt>
</Bal>
<Bal>
<Tp>
<CdOrPrtry>
<Cd>CLBD</Cd>
</CdOrPrtry>
</Tp>
<CdtLine>
<Incl>false</Incl>
<Amt Ccy="EUR">0.00</Amt>
</CdtLine>
<Amt Ccy="EUR">300.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<Dt>
<Dt>2023-10-23</Dt>
</Dt>
</Bal>
Zusammen mit folgenden Überweisungen
führt das dann zu
Zitat
10/5/23 10/5/23 null:null 100.00 EUR
saldo: 10/5/23, 12:00 AM 400.00 EUR
code null
text:Gutschrift
primanota:null
usage: VWZ
konto: (EUR)
addkey:null
10/12/23 10/12/23 null:null 200.00 EUR
saldo: 10/12/23, 12:00 AM 600.00 EUR
code null
text:Gutschrift
primanota:null
usage: VWZ
konto: (EUR)
addkey:null
Das lässt sich auch mit dem bestehenden Testcase testen, indem man in hbci4java
- in der Test-Ressource test-camt-parse-05200102.xml jeweils BookgDt und ValDt der beiden Ntrys von 2018 auf 2017 verschiebt.
- und dann TestCamtParse.test004() laufen lässt.
In der Tat scheint ParseCamt05200102.createDay() genau den ersten Saldo-Eintrag als Start-Saldo zu verwenden, wenn er beispielsweise vom Typ PRCD ist. Und in createLine() werden dann zum Start-Saldo immer die neuen Transaktionswerte summiert, unabhängig vom Datum.