@SMT_Chris
Danke für die Rückmeldung.
Der Hinweis auf StarMoney ist aus technischer Sicht allerdings nur sehr eingeschränkt aussagekräftig und erklärt das Problem leider nicht – im Gegenteil: StarMoney ist dafür bekannt, bei FinTS/CAMT sehr tolerant zu sein und auch nicht spezifikationskonforme Inhalte stillschweigend zu akzeptieren. Das ist eine bewusste Designentscheidung zugunsten von Robustheit, aber kein Nachweis dafür, dass die gelieferten Daten normkonform sind.
Andere Programme wie Lexware FinanzManager, Hibiscus, Banking4 etc. halten sich deutlich strenger an die FinTS- bzw. ISO-20022-Spezifikation. Wenn diese bei CAMT-Umsätzen mit “Amount value has too many significant digits” abbrechen, ist das exakt das erwartete Verhalten bei zu vielen signifikanten Stellen im <Amt>-Feld.
Dass eure internen Logs „nichts Auffälliges“ zeigen, passt leider ebenfalls ins Bild:
Ein Spezifikationsverstoß ist kein technischer Fehler, sondern formal gesehen „gültig erzeugtes XML mit fachlich ungültigem Inhalt“. Genau solche Fälle fallen oft nicht durch rein technische Prüfungen.
Kurz gesagt:
StarMoney „funktioniert“ weil es toleriert
Andere Programme brechen ab weil sie korrekt prüfen
Das spricht nicht für unterschiedliche Fehlerbilder, sondern für ein gemeinsames, serverseitiges CAMT-Problem
Der im Nachbarforum von Olaf Willuhn (Hibiscus) beschriebene Punkt zu Dezimalstellen und Signifikanz deckt sich exakt mit den hier geposteten Beispielen (z. B. Beträge mit >2 bzw. extrem vielen Nachkommastellen).
Ich bin ebenfalls zuversichtlich, dass ihr das lösen könnt – wollte aber helfen, den StarMoney-Vergleich technisch korrekt einzuordnen, damit die Analyse nicht in die falsche Richtung läuft.
Gruß Crazyalex
