Welches Format für XML-Import?

[Tommi M.]

Ich möchte Überweisungen und Sammelaufträge via XML importieren. Vielerorts ist von SEPA-XML die Rede. Doch SM13dL unterstützt (leider) nur den Import. Könnte ich eine bereits durchgeführte Überweisung exportieren, könnte ich den beispielhaften Aufbau sehen. Schon die erste Zeile in welcher das Format genannt wird, würde mir helfen. Das dafür vorgesehene Format pain.001.002.xx verweigert SM mit der Meldung, die Datei hätte ein ungültiges Format.

Meine Frage an Experten und Kundige: Welches Format erwartet SM für Überweisungen?

Vielen Dank und viele Grüße
Thomas

[ebi_f]

In einem parallelen Thread schreibst du, dass du von SM auf ein anderes Programm umsteigst, weil das "vieles besser kann", darunter auch "XML-Ex- und -Import": viewtopic.php?p=188176#p188176

Und 10 Minuten später fragst du hier nach dem Aufbau von XML-Dateien für SM13 ??? Warum machst du das dann nicht mit deinem neuen Programm? Das erscheint mir, als wüsstest du selbst noch nicht, was du willst.

Welches Format erwartet SM für Überweisungen?

Für den Import selbstredend das SEPA-XML-Format. Das ist klar definiert (mit kleinen Versionsänderungen im Laufe der Jahre) und für alle Programme gleich. Das ist aber nichts, um sich das selbst zu erstellen. Wenn du kein entsprechendes Programm hast (z.B. Buchhaltungssoftware), aus dem die XML-Dateien exportiert werden können um sie dann in eine Bankingsoftware zu übernehmen, nützt dir das gar nichts.

Wenn du nur eine Vorstellung davon bekommen möchtest, wie das Format ausschaut, dann kannst du dir hier die technischen Spezifikationen der Deutschen Bundesbank zu SEPA-Überweisungen anschauen: https://www.bundesbank.de/resource/blob ... 1-data.pdf

Viel Spaß damit!

[Tommi M.]

Hallo ebi_f,

vielen Dank für deine Unterstützung. Der Link zum Dokument der Bundesbank hat mir sehr geholfen. Das Schema camt.055 in der aktuell gültigen Fassung camt.055.001.05 wird also erwartet. Das war die Antwort, die ich gesucht habe.

Und 10 Minuten später fragst du hier nach dem Aufbau von XML-Dateien für SM13 ??? Warum machst du das dann nicht mit deinem neuen Programm? Das erscheint mir, als wüsstest du selbst noch nicht, was du willst.

Im Grunde genommen brauche ich mich dir gegenüber nicht erklären; nicht darüber, welche Artikel ich wie beantworte, nicht über meine Vorhaben und meine Zukunft und auch nicht, ob ich selbst wüsste, was ich wolle. Es erschließt sich mir auch noch nicht, was dich dazu ermächtigt, zu urteilen, wer was wo posten darf. Aber lass mich im Detail auf deine Zuschreibungen eingehen. Vielleicht hilft es dir ja, mehr Klarheit zu bekommen.

Es ist richtig, dass ich den von dir verlinkten Thread wie du es zussammengefast hast, kommentiert habe. Jameica mit dem Plugin Hibiscus beherrscht eine beliebig abgestufte Kategorienstruktur. Das ist ein Teil, wofür ich Hibuscus nutze. Natürlich ist es möglich, in Starmoney alle Kategorien zu löschen und eigene anzulegen, jedoch mit nur jeweils einer Unterkategorie.

Auch das Vertragsmanagement ist in Jameica mit dem Plugin ContractManager wesentlich besser umgesetzt als der Vertragsmanager in Starmoney. Die Verwaltung ist - ohne weitere Umschweife - komfortabler. Und auch Vorlagen für Kündigungsschreiben werden von einem lokalen Speicherort aufgerufen. Für diesen Ablauf bemüht Starmoney einen Internetdienst (konkret: aboalarm) und schickt an diesen Personen bezogene Daten - wie man sieht, vollkommen ohne Not.

Als Basis für meine Verträge und monatlichen Zahlungen dient eine langjährig gewachsene Kalkulationsarbeitsmappe (wer es genau wissen will: LibreOffice Calc). Mithilfe "meiner" Tabellen habe ich einen Überblick, welche Verträge wann gekündigt werden müssen, wer meine Vertragspartner sind und welche Zahlungen wann anstehen. So kann ich monatlich einen Betrag X auf ein zweites Girokonto schieben und habe den Restbetrag auf dem Gehaltskonto frei zur Verfügung. Und ich kann anhand der Arbeitsmappe sehen, welchen Betrag ich monatlich auf ein Rücklagenkonto schieben muss. Bevor jetzt das Argument kommt, "dieser Ansparbetrag ändert sich ja nicht", nehme ich im nächsten Atemzug den Wind aus den Segeln: Doch, das tut er leider, denn es werden bspw. Versicherungsbeiträge angepasst und bei jährlicher Zahlweise kommt es praktisch jeden zweiten Monat vor, dass ein Beitrag angepasst wird. Für diese monatlichen Zahlungen erstelle ich mir eine XML und importiere sie in Hibiscus. Das funktioniert wunderbar - mit SM leider nicht.

Nun hat auch Starmoney seine Stärken: Beispielsweise funktioniert der Abruf von Kreditkarten unter Starmoney wesentlich besser. Ebenso können verschiedene Kundenbeziehungsabonnements (bspw. Payback) abgefragt werden. Und nicht zuletzt kann Starmoney mit mehr Banken umgehen. So werde ich wohl nicht ohne Einbußen vollständig auf Hibiscus setzen können. So werde ich wohl die Goodies aus beiden Welten nutzen und aus diesem Grund möchte ich kompatibel bleiben.

Wenn du kein entsprechendes Programm hast (z.B. Buchhaltungssoftware), aus dem die XML-Dateien exportiert werden können um sie dann in eine Bankingsoftware zu übernehmen, nützt dir das gar nichts.

Das möchte ich so nicht unterschreiben. Für das Erstellen einer XML-Datei ist beileibe keine Buchhaltungssoftware nötig - nur etwas Wissen. Wenn ich hier schreibe, dass eine XML-Datei eine simple Textdatei und nichts Binäres ist, erzähle ich von einem alten Hut. Ich könnte nun bspw. in Lazaraus die Komponenten für XML und ODF installieren und dann bei der Erstellung auf diese zurückgreifen. Ich kann aber auch in LiberOffice ein Makro dafür schreiben, oder wer MS-Produkte einsetzt für Excel ein VBA-Makro. In meinem Fall habe ich das unter LibreOffice getan. War gar nicht viel Aufwand (für mich, weil ich es kann). Ich musste nur die XML-Struktur kennen. Hibiscus hat mir dabei sehr unter die Arme gegriffen, weil es Sammelaufträge in eine XML-Datei exportieren kann (Schema pain.001.002.01 - pain.001.002.08). Ich habe mich aus unterschiedlichen Gründen für das Schema pain.001.002.03 entschieden. Doch beim Import dieser Datei(en) meint Starmoney, es handele sich um ein nicht unterstütztes Format. Und SEPA-XML ist mit Verlaub nicht spezifiziert (auch das ist in deiner Antwort, wenn man es genau nimmt, eine falsche Behauptung). Spezifiziert ist vielmehr das Schema camt.055.001.xx, welches Starmoney (und zahlreiche Banken übrigens auch) als SEPA-XML bezeichnen.

Das Dokument "Technische Spezifikationen der Deutschen Bundesbank für die Abwicklung von SEPA-Überweisungen im Kunde-Bank-Verkehr", auf welches du verlinkst, enthält übrigens keinen konkreten Hinweis auf den Aufbau des XML-Headers und auch keine einzige Beispieldatei. Diesbezüglich kann dieses Dokument hier mehr Aufschluss geben. Hierin ist der Aufbau des Schemas camt.055 übrigens auch beschrieben.

Dennoch bedanke ich mich bei dir für deine Antwort. Dein Link zum Dokument der Bundesbank hat mir sehr geholfen. Aber das sagte ich ja bereits.

Viele Grüße
Thomas

P.S.: @ebi_f: In der Regel ist es anders als man selber denkt.

[EDIT 13.10.2022 06:28]
Mit camt.055 lag ich falsch. Das von mir im Topic erwähnte Format (Schema) pain.001.002.xxx war und ist schon das richtige Format. Die Ursache lag wo anders. Dazu weiter unten mehr.

[ebi_f]

Wenn du dein Problem mit dem XML-Format genauer beschrieben hättest, hätte ich vielleicht auch genauer darauf antworten können. Aber das war ja so allgemein, dass ich da nur raten konnte. Und Sätze wie "Vielerorts ist von SEPA-XML die Rede" ließen mich nicht vermuten, dass da genauere Kenntnisse vorhanden sind.

Wenn mein Link aber hilfreich war, freut es mich.

P.S. Ich kann übrigens XML-Dateien im Format pain.001.002.03 problemlos in SM importieren. Da muss es ein anderes Problem geben.

[Tommi M.]

Ah! Danke für deinen Hinweis, dass es bei dir funktioniert. Jetzt lohnt es sich wieder zu anlysieren, wenn es prinzipell das Schema der Wahl ist. Mein nächster Ansatzt ist dann anstelle ISO-8859-1 (welches Hibiscus übrigens verarbeiten kann) doch utf-8 einzusetzen und alle Umlaute in der Textdatei probehalber gegen "herkömmliche" ASCII-Zeichen zu ersetzen.

Dieser Hinweis war sehr wertvoll für mich.

Viele Grüße
Thomas

[ebi_f]

Für Umlaute ist UTF-8 zwingend erforderlich, dann klappt es vermutlich auch mit dem Import in SM.

[Tommi M.]

"Try and Error" - Habe den Fehler gefunden: Im Element <PmtInf> wird das Datum der Ausführung <ReqdExctnDt> im Format YYYY-MM-DD erwartet. In meinem Quellcode lieferte die Funktion "Date" das Datum jedoch im Format DD.MM.YYYY (typisch deutsch) zurück.

Wie ich seit gestern weiß, kann Starmoney durchaus mit ISO-8859-1 und Umlauten umgehen.

Vielen Dank für deine Hinweise.

Viele Grüße
Thomas