SEPA XML basiert auf der ISO 20022 XML. Je nachdem, was ihr hier importieren wollt, müsste pain.001 (SEPA-Überweisung), pain008 (SEPA-Lastschrift) oder camt.052/053/054 (Kontoinformationen) verwendet werden.
Ob das der richtige Weg ist, kann ich so weder mit ja noch nein beantworten.
Euer geplantes Vorgehen hat Vor- und Nachteile. Die Nachteile sind hier die Kosten für die Umsetzung und ggf. Folgekosten, wenn Änderungen an der Verwaltungssoftware auch Änderungen im Skript zur XML Erzeugung nach sich ziehen. Vorteile ist der geringere Arbeitsaufwand um die Buchungen zu erzeugen und auszuführen und keine Medienbrüche.
Alternativ kann man in Mein Geld mit Vorlagen oder Daueraufträgen arbeiten. Hier kann der Aufwand relativ hoch werden, wenn es von Monat zu Monat oft Unterschiede im Betrag gibt oder Zahlungen ausgesetzt werden müssen.
Aus meiner Sicht kommt es darauf an, wie viele Kunden ihr Verwaltet und wie teuer eine Umsetzung für die XML Variante wird. Auch die Pflege der Umsetzung muss sicher gestellt sein. Sonst steht ihr später wieder vor dem gleichen Problem.
Ich haben leider nichts auf der Webseite von Wiso dazu gefunden was ich für welchen Zweck verwende.
Das hängt einfach davon ab, was Du hast: Du hast zwei Möglichkeiten, Aufträge ins Onlinecenter zum importieren, um sie von da an die Bank zu schicken - als CSV oder als SEPA-XML. Welche Du nimmst, hängt einfach davon ab, was Du hast.
kann alles beide programmieren lassen aber die Frage welches ist einfacher und nicht so anfällig.
Ich persönlich halte XML für vorteilhafter, da hier auch Datengruppen verwendet werden und Fehler beim Import sofort erkennbar sind. Besonders, wenn ganze Datensätze fehlen. Also von eigentlich 200 Buchungen nur 150 importiert werden. Bei CSV würde das ohne Fehler durchlaufen und die Buchungen fehlen. Bei XML scheitert der gesamte Import.
Hallo,
ich kann alles beide programmieren lassen aber die Frage welches ist einfacher und nicht so anfällig.
einfacher ist definitiv der Weg über CSV. Das XML-Format ist deutlich komplexer und was ich viel schlimmer finde, das Format ist nicht statisch. Da gibt es regelmäßig neue PAIN-Versionen und wer weiß ob irgendwann die alten Formate beim Import noch unterstützt werden. Bestenfalls reicht es dann einen neue Versionsnummer einzutragen, aber es ist ein lebendes Format.
Bei CSV würde das ohne Fehler durchlaufen und die Buchungen fehlen.
Wo hast du das denn her? Das Fehlerhandling hat doch erstmal mit dem Format nichts zu tun. Wenn für XML eine Standardkomponente verwendet wird, ist die Wahrscheinlichkeit dafür höher, mehr aber auch nicht. Also ich habe mir den Spaß gemacht und das mit der Beispieldatei einfach mal getestet und fehlerhafte Datensätze werden beim Import direkt angemeckert.
LG
Also von eigentlich 200 Buchungen nur 150 importiert werden.
Das war meine Aussage. Bei CSV erkannt man nicht, wenn nicht der gesamte Inhalt eingelesen wurde. Und sollte der letzte Datensatz selbst nicht fehlerhaft geworden sein weil Daten fehlen, ist der gesamt Import fehlerfrei.
Wo hast du das denn her?
Ist nun mal so, dass fehlende Datensätze bei CSV nicht erkannt werden.
Ist nun mal so, dass fehlende Datensätze bei CSV nicht erkannt werden.
Die Aussage ist so schlicht falsch. Falls du dich darauf beziehst, dass Datensätze ggf. gar nicht in der CSV-Datei sind, dann ist das zwar richtig, aber eine Liste von Knoten im XML verhält sich genauso.
Wie ich oben schrieb habe ich es sogar explizit getestet und du bekommst einen konkreten Hinweis, wenn ein Datensatz fehlerhaft ist. Also wie wär's wenn du es einfach selbst testest?
LG
Hier gibt es auch Beispiel XML Dateien.
