Problem bei Abholung der Umsätze mittels HBCI

[Micha_2025]

Guten Morgen,

seit gestern Abend gibt es ein Problem bei der Abholung der Umsätze mittels HBCI 🤔
Hier der Auszug aus dem Protokoll:

> Abholen Kontoumsätze für Konto Girokonto
> Amount value has too many significant digits, the maximal display length is 15.
> Abmeldung von der Bank erfolgt.

Das Abholen erfolgt mit dem Lexware Finanzmanager 2026 (Version 33.14, DDBAC 5.10.86.0).

Gestern war davon auch das Girokonto betroffen, dieses funktioniert aber seit heute wieder.

Beim Tagesgeldkonto tritt der Fehler nach wie vor auf!?
Wo liegt da das Problem?

Gruß Micha

[SMT_Chris]

@Dennis_B 

Sorry mit deinen Links kann ich hier nichts anfangen. Ich verweise nochmals auf meine hier geäußerte Bitte: 

• Welcher HBCI Software wird verwendet?
• Welche Version?
• Gibt es Log-Dateien?

Ohne diese Angabe (hier, in diesem Forum), kann ich kein Ticket bei der Fachabteil erstellen. Links zu anderen Foren helfen mir nicht - u.A. weil ich keine Rückfragen stellen kann. 

@Thorsten_ 

Und nein, das hat nichts mit meinem Mindset zu tun. Ich helfe, wo ich nur kann. Aber ich benötige schlichtweg konkrete Daten, um handeln zu können. Und da es, wie erwähnt, bei anderen Apps klappt, muss es irgendwo ein Problemchen geben. Wo das liegt, können wir aber nur anhand der oben benötigten Angaben nachvollziehen - die , ich wiederhole mich gerne, hier in dieser Community gemacht werden müssen. 

Und die Wortmeldungen betrafen u.A. auch veraltete FM von Lexware, bei dem vom Hersteller der ausdrückliche Hinweis kam, man möge bitte ein Update vornehmen. 

Danke

Christoph

[SMT_Chris]

@DiviMike 

Wenn du zu den Betroffenen gehörst, bitte ich hier oder via PN um entsprechende Angabe: 

• Welcher HBCI Software wird verwendet?
• Welche Version?
• Gibt es Log-Dateien?

Danke. 

Christoph

[SMT_Chris]

Update aus dem technischen Service. 

Der Einfachheit halber, sollen sich betroffene Kunden bitte beim technischen Support melden: 04106 - 708 25 00. Dort kann anhand der Kundendaten und weiteren Angaben konkrete das Problem besprochen und ggf. ein Ticket bei der IT erstellt werden. 

Vielen Dank

Christoph

[Thorsten_]

---

@SMT_Chris  schrieb:

@Thorsten_ 

Und nein, das hat nichts mit meinem Mindset zu tun. Ich helfe, wo ich nur kann. Aber ich benötige schlichtweg konkrete Daten, um handeln zu können. Und da es, wie erwähnt, bei anderen Apps klappt, muss es irgendwo ein Problemchen geben. Wo das liegt, können wir aber nur anhand der oben benötigten Angaben nachvollziehen - die , ich wiederhole mich gerne, hier in dieser Community gemacht werden müssen. 

Eine maßgebliche Info findet sich in diesem Thread. Mehrfach.

Zum Thema "andere Apps gehen aber" ist m. E. auch alles gesagt.

Ich bin raus... Sorry.

[SMT_Chris]

Eine maßgebliche Info findet sich in diesem Thread. Mehrfach.

Wenn du das Datumsformat meinst, dass habe ich auch an die Kollegen weitergeleitet. Diese benötigen jedoch weiteren Input. Daher habe ich um die entsprechenden Angaben gebeten. Aber wenn nichts kommt, kann ich auch nichts machen. Ich bin nur Vermittler und kein ITler, der das Problem lösen kann. 

VG

Christoph

[p-schneider]

Das Datumsformat mit Zeitzonenangabe ist zwar vielleicht etwas unerwartet (und wenn die Rede von UTC ist, dann auch nicht logisch), aber zumindest laut XSD-Check korrekt, wenn man die XML-Datei anhand der camt.052.001.02.xsd validiert.
"Dt" verweist in der XSD-Datei auf "ISODate", was wiederum als "xs:date" spezifiziert ist. Und laut https://www.data2type.de/xml-xslt-xslfo/xml-schema/datentypen-referenz/xs-date wäre ein Datum auch mit Zeitzonen-Angabe zulässig.

Ich habe in der Sparkassen-App, die ich verwende, auch keinen konkreten Hinweis in den Protokollen finden können was fehlschlägt. Die im Verlauf der Kommentare hier genannte Problematik beim parsen dieses Datums war bei einer anderen App/Anwendung und von einem anderen User gemeldet worden. (Ich hatte das Thema in einem meiner letzten Kommentare nur noch mal aufgegriffen, da es aufgrund der Äußerungen bgzl. UTC fehlerhaft wirkte.) 

Wenn man die komplette XML-Datei, die beim Abruf in meinem Fall übertragen wird, anhand der XSD-Datei validiert, werden allerdigns 3 Fehler in den CAMT XML-Daten, die (Stand gestern Mittag) vom comdirect Server geliefert werden, angemängelt:

1. Dem Element <BkToCstmrAcctRpt> <Rpt> fehlt ein Unterelement <CreDtTm> was hinter <Id> und vor <FrToDt> kommen müsste.
2. In <BkToCstmrAcctRpt> <Rpt> <Ntry> <BkTxCd> <Prtry> sind manchmal <Issr></Issr>, dieses Feld darf aber nicht leer sein (ist aber optional und könnte alternativ wohl einfach weggelassen werden).
3. In <BkToCstmrAcctRpt> <Rpt> <Ntry> <NtryDtls> <TxDtls> <RltdPties> <CdtrAcct> ist manchmal eine leere <Id/>, dieses Feld darf aber nicht leer sein (das Vaterelement CdtrAcct wäre optional).

(Die passende XSD-Datei zum validieren der XML-Sturktur ist beispielsweise unter https://github.com/vgoldin/lba-unifi-litas-esis/blob/master/unifi-litas-esis-parent/unifi-litas-esis... verfügbar, man kann aber auch einfach im Internet nach "camt.052.001.02.xsd" suchen und würde auch andere Quellen dafür finden.)

@SMT_Chris wollen die IT-Kollegen meine ungeschwärzten und somit sensiblen CAMT XML-Daten sehen die ich beim Abruf bekomme um das nachvollziehen zu können, oder stehen den Entwicklern Testkonten/Testdaten zur Verfügung womit man das validieren kann? (Und wenn ja, wäre eine PM im Forum der korrekte Übertragungsweg?)

Eine XML-Datei anhand einer dafür vorgesehenen XSD-Datei zu verifizieren wäre ja ein normaler Vorgang, aber ich verstehe auch, dass die Entwickler sich möglicherweise oft mit schlechten Testdaten rumplagen müssen, da echte (=sensible) Daten vielleicht nicht einfach jedem Entwickler zugänglich gemacht werden (dürfen).

Und um auf die 3 oft genannten Fragen zurückzukommen

• Welcher HBCI Software wird verwendet? Android-App der Sparkasse
• Welche Version? 8.1.0
• Gibt es Log-Dateien? Ja, kann ich bei Bedarf bereitstellen

… aber diese 3 Punkte sind für meine oben genannten Punkte nicht so relevant, es geht ja darum, dass die XML-Daten wohl nicht vollständig konform sind zum CAMT-Standard, und das ist sicher unabhängig davon welche HBCI-Software verwendet wird.

LG

PS

[SMT_Chris]

Hallo @p-schneider,

danke für die Details. Ich habe auf Basis dieser Informationen ein Ticket bei den Kollegen eröffnet und warte auf Feedback. Bei Rückfragen und Updates melde ich mich hier. 

VG

Christoph

[ItsMe4711]

Hallo zusammen,

@SMT_Chris wie bereits die Vorredner schon festgestellt haben sollte das Problem nicht an der Endanwendung liegen, sondern an dem falschen Datumsformat bei der Übertragung.

Das CAMT.052 Protokoll sieht folgende Definitionen vor:

1. Das Feld <Dt> (Date)

Dieses Feld wird verwendet, wenn lediglich ein Kalendertag ohne spezifische Uhrzeit erforderlich ist (z. B. für das Valutadatum).

• Format: YYYY-MM-DD
• Beispiel: <Dt>2023-10-27</Dt>
• Zulässige Werte: Ein gültiges Datum gemäß gregorianischem Kalender.

2. Das Feld <DtTm> (DateTime)

Dieses Feld wird für präzise Zeitstempel verwendet, insbesondere bei der Erstellung der Nachricht (CreDtTm) oder bei untertägigen Statusänderungen.

• Format: YYYY-MM-DDThh:mm:ss.sssZ
  • T: Trenner zwischen Datum und Uhrzeit.
  • ss.sss: Sekunden und optional Millisekunden.
  • Z: Zeitzonenkennzeichen (UTC) oder Offset (z. B. +01:00).
• Beispiel: <DtTm>2023-10-27T14:30:05.000Z</DtTm>

Im Protokoll der Übertragung von der Comdirect Schnittstelle zur Endanwendung ist zu lesen: siehe Anhang.

Im Ergebnis bleibt, dass die <DtTm> Funktion korrekt angegeben wird, aber die <Dt> Funktion durch Angabe der „+01:00“ zu einem nicht interpretierbaren Wert der Endanwendung führt.

Das müsste durch die IT der Comdirekt korrigiert werden, damit das korrekte und genormte Format wieder übermittelt wird. Damit sollten hier alle Probleme behoben sein.

Viele Grüße

[Joerg78]

Hallo @ItsMe4711 ,

willkommen in der Community und danke für deinen ersten tollen Beitrag!

Dass da die IT der comdirect nicht draufgekommen ist, ist schon etwas schwach - zumindest hätte man nach den ersten Kundenbeschwerden nochmal einen Abgleich mit der Spezifikation machen müssen.

Da du sie jetzt aber darauf hingestupst hast und @SMT_Chris das Thema sicher zeitnah weiterleiten wird, hoffen wir mal auf einen Fix mit dem nächsten Update.

Viele Grüße,

Jörg

[CurtisNewton]

Falls dies tatsächlich die Ursache sein sollte: die Vorstellung, dass die zweitgrößte Privatbank in Deuzschland es nicht schafft, in einem Produktivsystem ein XML gegen ein Schema zu validieren macht mir Unbehagen.