Guten Tag Zusammen,

seit Jahren nutzen wir den o.a. CAMT-Export, um diesen in unser Abrechnungssystem einzulesen. Das Abrechnungssystem kann ausschließlich das CAMT-Format lesen. Das hat bisher auch immer problemlos funktioniert (noch unter der alten Version SMB 10). Den Export erstellen wir über Verwaltung -> Datenexport -> CAMT-Format. Letztes Jahr haben wir begonnen, einige Konten aus Gründen der Zuverlässigkeit des Rechenzentrums und der enormen, negativen xxxxxxx bei der Volksbank (VR-Banken) von der VR zu der DKB zu wechseln. Das folgende Problem betrifft diese neuen Konten (und zwar alle bei der DKB).

Die Umsätze bei der DKB werden überwiegend per EBICS abgerufen. Wenn ich nun unter SMB11 einen Export bei der DKB Bank erstelle - z.B. mit der Datumsauswahl 01.01.2023 bis 01.08.2024, dann erzeugt der Export nicht wie früher EINE EINZIGE xml-Datei, sondern - z.B. bei dem Konto xxxxxxx191 - insgesamt 80 (!!!) Dateien für den o.a. Buchungszeitraum.

Der Import einer EINZIGEN xml-Datei in unser Abrechnungssystem dauert rund 20 Minuten. D.h. bei 80 Dateien wäre das ein Zeitaufwand von rund 27 Stunden. Völlig unmachbar. Auch wenn ich andere DKB-Konten exportiere, erhalte ich IMMER eine Vielzahl von xml-Dateien. Sind es wenige Umsätze, dann sind es entsprechend wenig xml-Dateien (aber immer mindestens 8, 9, … 11), sind aber viele Kontoumsätze vorhanden, so sind es auch entsprechend viele xml-Dateien (beim Konto xxxxxxxx1375 DKB z.B. 107 Dateien !!).

Wenn ich jedoch bei den alten VR-Konten nach gleichem Ablauf einen Export erzeuge (z.B. Konto DE35xxxxxxxxxx1390 VR-Bank Zeitraum 01.01.2023 - 30.08.2024), so wird korrekterweise NUR EINE EINZIGE Datei erzeugt. Das gleiche gilt für andere VR-Bankkonten. Die Umsätze werden bei der VR-Bank per HBCI (Signatur-Datei) abgerufen.


Ich hatte sowohl hier im Forum, als auch im web gesucht, ob irgend jemand die gleichen Probleme hat. Hierzu konnte ich nichts finden.

Ein verwandter Beitrag hatte sich damit beschäftigt, dass man in SMB im Konto im Reiter „EBICS“ auch das automatische Speichern der CAMT-Dateien im Zuge der Auszugsabholungen via EBICS auf dem Filesystem aktivieren kann. Das war bei uns bereits schon seit Jahren aktiviert und funktioniert auch. Allerdings ist das auch keine Lösung, da dort ja auch für jeden einzelnen Abruftag via EBICS eine separate Datei erzeugt wird. Das sind also im Jahr auch über 100 Dateien.

Wir müssen Abrechnungen für den Jahresabschluss 2023 fahren und hierfür müssen wir zwingend vorher die CAMT-xml-Dateien mit den Kontoumsätzen 01.01.2023 - 31.12.2023 importieren. Und genau das geht nicht. Merkwürdigerweise hatte der o.a. CAMT-Export mit den VR-Konten seit über 5 Jahren problemlos funktioniert.

Ich habe keine Idee, was dort die Ursache sein kann.

Vielen Dank für eine Hilfestellung, beste Grüße,

Die DKB hängt an FI, dem Rechenzentrum der Sparkassen. Dieses Rechenzentrum erzeugt generell pro Konto pro Buchungstag eine XML-Datei. Somit erklärt sich die Vielzahl der Dateien. Ich gehe davon aus, dass B4 evtl. nicht selbsterstellte XML-Dateien erzeugt, insbesodere bis vor einigen Tagen B4 überhaupt keine CAMT.053 erzeugen konnte sondern nur CAMT.052. Der Export für 053 wurde in der Betaversion auf Wunsch eines Nutzers vor kurzem neu eingebaut.

Ich gehe davon aus, dass B4 bisher die originalen vom RZ abgeholten Dateien (egal ob via EBICS oder HBCI) ausgibt. Du solltest es mal mit der aktuellen Beta probieren - und da nicht mit dem "normalen Export" sondern mit dem Export zur Buchhaltung. Dort ist die neue Erzeugung von 053 eingebaut worden. Dies gilt aber soweit ich weiß nur für Banking ZV und nicht für die "normale" Version...

Dass das bei Daten der VR-Banken anders war ist übrigens nicht verwunderlich, denn das RZ ATRUVIA liefert nicht eine Datei pro Tag sondern insgesamt eine Datei (so wie Du es gerne haben willst). Es liegt also an den "Gewohnheiten" des RZ.

Das ist einfach zu erklären und liegt am Abruf.

Beim camt053 sieht sie EBICS Spezifikation vor, dass es eine camt Datei pro Buchungstag gibt, die bei mehreren Tagen in einen Zip Container zusammen gepackt werden können.

Bei der DKB erhaltet ihr also vermutlich die original Dateien der Bank.

FinTS kennt keinen camt053 Umsatzabruf (stimmt nicht ganz, es gibt einen speziellen GV, mit denen camt053 Dateien analog zu EBICS abgerufen werden können. Das können aber nach meinem Stand nur zwei Programme)
Es werden hier camt052 Umsätze abgerufen. Wenn eine Software eine camt053 Datei ausgibt, konvertiert sie also die empfangenen Daten. Und wenn nicht die Orginaldsteien ausgegeben werden, kann man auch die Umsätze von mehreren Tagen in eine Datei packen.

Nachteil hier, es fehlen Informationen, die es in der Regel nur im camt053 gibt.

Hallo Zusammen,

@msa, @Holger Fischer: vielen Dank für die schnelle Rückmeldung. Da ich fast das gesamte Wochenende mit dem o.g. Problem im Büro verbracht habe, hatte ich dann gestern Abend schon im Büro Schluss gemacht, als die Antworten kamen. Insofern bitte ich, die späte Rückmeldung zu entschuldigen.

Zunächst einmal "........"

---> mir ist nicht ganz klar, was "B4" bedeutet. Heißt das Business Four ? Ist damit StarMoney Business 11 (SMB11) gemeint ?

Also, jedenfalls SMB11, bzw. auch SMB10 (und wohl auch SMB9) davor, kann durchaus schon länger Exporte im Format CAMT.053.001.02 und CAMT.053.001.08 erzeugen. Ich habe das eben nochmals überprüft: die ersten CAMT-Exporte aus StarMoney Business heraus haben wir am 18.09.2020 erzeugt. Das hatte auch immer wunderbar funktioniert.

@msa: Sprechen wir hier eventuell von verschiedenen Anwendungen (B4 sagt mir nichts) ?

"......."

---> dem ist nicht so. Ich habe mir die gesamten Spezifikationen der Bundesbank sowohl zu EBICS-CAMT-Formaten, als auch zu dem Format CAMT.053.001.02 durchgelesen. Demnach unterscheiden sich die beiden Formate minimal (u.a. in der Tiefe der Hirachien). Das konnte ich auch wunderbar daran erkennen, dass ich eine EBICS-CAMT-Datei, die im Rahmen des EBICS-Abrufes gesichert wurde, mit einer in SMB11 erzeugten Export-CAMT-Datei verglichen habe. Da sind die Unterschiede eindeutig feststellbar und die Unterschiede entsprechen auch den Spezifikationen der Bundesbank.

SMB11 erzeugt ganz offensichtlich die Datensätze für die CAMT-Export-Datei dynamisch zur Laufzeit des Exportes aus der Datenbank. Das kann man auch daran verifizieren, dass die CAMT-Export-Datei zu einer Buchung auch ein zusätzliches Kommentarfeld in die xml-Datei einfügt, wenn es in SMB11 einen kundenspezifischen Kommentar enthält (Hinweis: in SMB11 (und auch Vorversionen) kann man in der Umsatzanzeige, bzw. den Umsatzdetails einen kundenspezifischen Kommentar einfügen und speichern.). Diesen Kommentar, bzw. dieses Kommentarfeld findet man dann auch in der exportierten CAMT-Datei. Insofern muss die CAMT-Export-Datei dynamisch aus der Datenbank erzeugt werden, dann zum Abrufzeitpunkt der Umsätze - und zwar egal, ob über EBICS oder HBCI - war dieser Kommentar ja noch gar nicht vorhanden. Also kann es nicht sein, dass SMB11 einfach nur die originalen xml-Datensätze aus der alten Abrufdatei Eins-zu-Eins übernimmt. Dann wäre das Kommentarfeld ja nicht vorhanden.

"............."

---> die Dateien, die beim Kontoabruf erstellt werden, sind ja nicht das Problem. Das sind ja physisch andere Dateien, als die von SMB11 erzeugten Exportdateien. Die Kontoabrufdateien müssen ja logischerweise immer nur genau die Buchungen enthalten, die seit dem letzten Kontoabruf übermittelt werden. Insofern ist klar, dass die Abrufdateien immer nur die Buchungssequenz enthalten, die seit dem letzten Abruf auf dem Girokonto gebucht worden sind. Mein Problem liegt ja auch nicht auf der Seite der Abrufdateien, sondern auf der anderen Seite der Export-Schnittstelle in SMB11.

@Holger Fischer: "..........."

---> nein, das ist nicht der Fall. Ich hatte das am Wochenende bereits fest gestellt und eben nochmals überprüft (siehe auch oben): die Original-Dateien der DKB über den EBICS-Abruf werden lokal gespeichert und weisen definitiv einen anderen Datei-Datensatzaufbau im xml auf, als der Export der SMB11-Exportschnittstelle. Das kann ich im Vergleich der EBICS-Abruf-xml und der CAMT-Export-xml eindeutig im Satzaufbau fest stellen.

"..........."

---> ja, genau so scheint offensichtlich die Export-Schnittstelle von SMB11 (bzw. SMB10 und SMB9) zu funktionieren: die Datensätze für den CAMT-Export werden zur Laufzeit aus der Datenbank ermittelt und in eine einzige Datei (pro Konto - also eine Datei für jedes Konto) geschrieben - jedenfalls bei den VR-Konten und eben nicht bei den DKB-Konten. Man kann allerdings in der Export-Schnittstelle von SMB11 immer nur ein einziges Konto in einem Exportprozess exportieren. Das ist aber weiter unproblematisch. Wir haben in der Vergangenheit einfach für jedes einzelne Konto einmal im Folgejahr das gesamte Buchungsjahr vom 01.01. bis 31.12. exportiert. D.h. wir haben genau so viele Exportdateien pro Geschäftsjahr erzeugt, wie die Anzahl der Girokonten ist. Der Aufwand war immer relativ gut zu handhaben, da wir mit diesem Prozess pro Geschäftsjahr einmalig einen Exportaufwand in SMB11 und einen Importaufwand in unserem Abrechnungssystem von insgesamt rund 20 Minuten hatten. Das war immer unproblematisch.

Warum aber SMB11 nun bei offensichtlich dem gleichen Exportprozess bei einer Bank (VR-Bank) eine einzige Export-Datei erstellt, aber bei der anderen Bank, der DKB, Unmengen von Einzeldateien (die überhaupt nicht identisch zu den originären EBICS-Abrufdateien sind) erzeugt, ist mir völlig schleierhaft.

Ein weiteres Indiz, dass SMB11 eben nicht die originären EBICS-Abrufdateien der DKB für den CAMT-Export nutzt, ist der Sachverhalt, dass bei den CAMT-Export-Dateien immer ein oder zwei Dateien dabei sind, die Buchungen über einen relativ langen Zeitraum beinhalten.

Beispiel:

Ich habe für zwei verschiedene DKB-Konten ( xxxxxxxxx919 und xxxxxxxxx6736) in SMB11 einen CAMT.053.001.02-Export für den Zeitraum

01.01.2023 bis 30.08.2024

erzeugt.

Konto xxxxxxxxx919:

Es werden insgesamt 80 (!!) Dateien erzeugt. Die Datei Nr. 78 enthält aber Buchungen für den Zeitraum 03.07.2024 bis 12.08.2024

Das passt also überhaupt nicht zu den Zeitpunkten, wo Umsatzabrufe erfolgt waren. Die Kontenabrufe erfolgen bei uns mit einem zeitlichen Abstand von maximal 3 Kalendertagen für dieses Konto. Das lässt sich auch über die gespeicherten Abrufdateien nachvollziehen, die genau diesen Rhythmus für dieses Konto bestätigen.

Konto xxxxxxxxx6736:

Es werden insgesamt 7 Dateien erzeugt. Die Datei Nr. 1 enthält aber Buchungen für den Zeitraum 01.01.2023 bis 05.10.2023.

Das passt also ebenfalls wie beim 1. Konto (s.o.) überhaupt nicht zu den Zeitpunkten, wo Umsatzabrufe erfolgt waren. Die Kontenabrufe erfolgen bei uns mit einem zeitlichen Abstand von maximal 3 Kalendertagen für dieses Konto. Das lässt sich auch über die gespeicherten Abrufdateien nachvollziehen, die genau diesen Rhythmus für dieses Konto bestätigen.

Bei einem weiteren Konto hat SMB11 sogar über 200 (!!) xml-Dateien für den Zeitraum 01.01.2023 - 30.08.2024 erzeugt.

Ich hoffe, irgend jemand hat noch eine Idee, was hier schief läuft oder wie man den Export pro Girokonto in genau eine Export-Datei hinbekommt.

Vielen Dank für Unterstützung, beste Grüße,

unabhängig bietet der Hersteller ja

telefonischer und schriftlicher Premiumsupport:

https://www.starmoney.de/kundenbereich/hilfe-support/
https://www.starmoney.de/konta…-business/ (ganz nach unten scrollen)

Verweis auf Fremdforum, da dort https://www.starmoney.de/forum/viewforum.php?f=235 (viele Fach-/Software-) User sind.

Hallo infoman,

vielen Dank für den Hinweis. Aber das ist mir bekannt. Auf dem Forum konnte ich gestern keine Anfrage stellen, da eine Registrierung beim Forum offensichtlich erst händisch von einem Mitarbeiter frei gegeben werden muss. Das wurde gestern natürlich nichts.

Der telefonische Support ist momentan für mich nicht erreichbar, da ewig lange Warteschleifen laufen und ich kundenbedingt nicht permament die Leitung blockieren kann. Schriftliche Supportanfragen dauern lange und die erste Rückmeldung geht erfahrungsgemäß meist an der Problemstellung vorbei. Die Zeit haben wir bei dem Problem nicht. Daher hatte ich hier das Problem geschildert und gehofft, dass hier jemand schneller helfen kann.

Sollte eine Lösung von dritter Seite kommen, werde ich hier natürlich berichten, damit andere user auch von der Lösung profitieren können.

Beste Grüße, hk