Habs analyisert. Ich halte es für einen formalen Fehler der Bank. Das Antwort-Segment "HISAL" mit dem Saldo enthält in Segment-Version 7 u.a. zwei Salden. Einmal den gebuchten Saldo und einmal den Saldo der vorgemerkten Umsätze. Diese beiden Salden sind vom Typ "sdo". Die Definition des Typs "sdo" findet sich in "FinTS_3.0_Messages_Geschaeftsvorfaelle_2022-04-15_final_version.pdf" in Kapitel B.4. Das Datenelement "Datum" ist dort als "m" (mandatory) - also Pflicht definiert. Lediglich die Uhrzeit ist optional. In dem Segment der DKB fehlt aber das Datum:
HISAL:5:7:3+DE12345678901234567890:BYLADEM1001:1234567890::280:12030000+Girokonto+EUR+C:123,00:EUR++100,:EUR'
Das Datum müsste hinter dem "123,00:EUR" stehen, fehlt dort aber.
Ich gehe davon aus, dass andere Bankingprogramme das halt tolerieren und in dem Fall dann das aktuelle Datum als Saldodatum annehmen. Oder es gibt eine neuere Spezifikation, von der ich nichts weiss. Auf fints.de finde ich jedenfalls nichts. Ich kann mir auch nicht vorstellen, dass ein vormals als Pflicht definiertes Element zu einem optionalen erklärt wird. Wenn es solche Änderungen gab, sind bisher immer auch neue Versionen der Datentypen oder Segmente eingeführt worden, um die Abwärtskompatibilität sicherzustellen.
Code
HISAL:5:7:3+DE12345678901234567890:BYLADEM1001:1234567890::280:12030000+Girokonto+EUR+C:123,00:EUR++100,:EUR'
Das Datum müsste hinter dem "123,00:EUR" stehen, fehlt dort aber.
Ich gehe davon aus, dass andere Bankingprogramme das halt tolerieren und in dem Fall dann das aktuelle Datum als Saldodatum annehmen. Oder es gibt eine neuere Spezifikation, von der ich nichts weiss. Auf fints.de finde ich jedenfalls nichts. Ich kann mir auch nicht vorstellen, dass ein vormals als Pflicht definiertes Element zu einem optionalen erklärt wird. Wenn es solche Änderungen gab, sind bisher immer auch neue Versionen der Datentypen oder Segmente eingeführt worden, um die Abwärtskompatibilität sicherzustellen.