Guten Tag,

wir entwickeln Software, die für BANKING-Software generell gültige SEPA-XML-Dateien erzeugt (erzeugen soll).

Also: Ich erstelle SEPA-XML-Dateien und überlasse es dann unseren Kunden, ob und wie er diese zur Bank schafft - z.B. mit Multicash, Proficash, Windata, SFirm etc. etc. Wir wissen NICHT was unsere Kunden einsetzen - es ist ihnen selber überlassen.
---
Ich finde zu diesem Sachverhalt - also für Entwickler - keine guten, tauglichen, Verbindlichen, "alles umfassenden" Regelungen für "alle" Fälle.

Anlage 3 ZK ist bekannt, Version 2.6. bis 2.8. sind runtergeladen und analysiert, auch z.B. die Postbank-spezifische Doku der Anlage 3 (Version 2.6.)

Da steht aber nichts drin zu unserem Problem lt. Betreff. Dazu finde ich nur Forumseinträge, wo jeder schreiben kann was er will / weiss / denkt.
---
Aus diesem Umfeld würde ich folgendes gerne geklärt haben:

Die aktuelle Praxisfrage an einem Beispiel: Ich erzeuge im Moment EINE SEPA-XML-Datei in der 2 PmtInf-Blöcke vorhanden sind - Grund sind 2 unterschiedliche Ausführungsdatumsangaben.

SEPA-XML-Checker meldet: "Ein direkter Versand per FinTS/HBCI ist nicht möglich, da mehrere logische Dateien <PmtInf> in den Geschäftsvorfällen nicht erlaubt sind"

Lt. dem Forumseintrag "http://www.onlinebanking-forum.de/forum/topic.php?t=15897" scheint das bekannt zu sein ("Bei EBICS ist das möglich, HBCI/FinTS hingegen erlaubt nur einen Paymentinformationblock")

Multicash Version 3.23 (bei einem konkreten Anwender) akzeptiert die Datei hingegen.

Ich würde gerne wissen:

1. Ist es tatsächlich so, das man lt. allgemeinen gültigen Regeln bei FinTS eben NICHT mehrere PmtInf-Blöcke schicken kann? Wenn ja: Wo ist das "offizielle" Dokument dazu zu finden / der "offizielle" Text?

2. Wie finden wir/unsere Kunden heraus, ob sie per FinTS/HBCI/EBICS verschicken und kann man das evtl. umschalten z.B. in Muticash/SFirm o.ä.?

3. Was ist euer Tipp: Sollten wir sicherheitshalber immer nur eine XML-Datei je PmtInf-Block erzeugen - oder ist "davon auszugehen" das "alle" Banking-Pakete eine XML mit mehr als einem PmtInf-Block akzeptieren und ggfls. vor der Versand intern in "n" Teile aufteilen?!?

Danke!

zu 1. - Das sollte sich über www.hbci-zka.de herausfinden lassen. Ist aber wirklich soll. Aktuell geht mit FinTs nur ein Payment information Block je Datei.
zu 2. - Eigentlich nur dadurch, dass sie Euch das sagen. Grundsätzlich kann man das in der jeweiligen Software aber auch umschalten. SFirm z.B. fragt beim Versand einer Fremddatei (also wie von Euch extern erzeugte Dateien) wie der versand erfolgen soll. Voraussetzung: Es sind mehrere Übertragungsverfahren eingerichtet. Ansonsten wird standardmäßig das eingerichtete genommen.
zu 3. - SFirm erkennt aber beim einem solchen Versand und der Auswahl von HBCI mehrere Blöcke und "teilt" die Datei dann entsprechend in einzelne Auftragsdateien. Wie sich andere Anwendungen verhalten, mag ich nicht beurteilen. ist aber sicher nicht immer so. Wirkliche Sicherheit hättest Du nur dann, wenn Du direkt mehrere Dateien erzeugst.

Hallo Burkahrd,

in der Anlage 3 sind die SEPA Formate spezifiziert, so wie sie in Deutschland gültig sind.
In der FinTS Spezifikation (www.fints.org) findest Du dann die FinTS spezifischen Einschränkungen die Wesehntlichen:
- nur ein PmtInf Block
- Ausührungsdatum bei Überweisungen 1.1.1999
Dazu kommt, dass bei FinTS deutlich weniger Transaktionen in eienr Datei enthalten sein dürfen

Da EBICS (FTAM gibt es nicht mehr) meist mit zusätzlichen Kosten verbunden ist, wirst Du den Kunden nicht so einfach zu einer Umstellung bewegt bekommen.
Bei den mir bekannten Produkten heilt aber immer der Import einer XML Datei die Verfahrensspezifischen Restriktionen.
Anders sieht es bei den Weblösungen aus, da gibt es keine all gemeingültige Aussage, welche Restriktionen es dazu gibt.

Nur ein PmtInf Auszugeben löst daher nur ein Teil der Restriktionen. Aktive Aufklärung und Information ist daher vermutlich der bessere Weg.

Viele Grüße

Holger

Hallo Burkhard,

hinzu kommt, dass nicht alle Banken über alle Verfahren alle SEPA-Versionen (pain-Formate) unterstützen. Lediglich bei EBICS kann man davon ausgehen, dass XML-Dateien mit mehreren PmtInf Blöcken in der jeweils aktuellen Formatversion funktionieren.

Bei der HBCI-Übertragung sollte das jeweils eingesetzte Zahlungsverkehrsprogramm in die Bresche springen. D.h. das Programm sollte jede XML-Datei zunächst einlesen, die formal in Ordnung ist und vor dem Versand so umbauen, wie es die Bank für HBCI haben möchte. Diese Informationen liefert die Bank per BPD (BankParameterDatei) der Software zurück. Die Software wird dann z.B.
- Je PmtInf Block einen eigenen HBCI-Auftrag erzeugen, weil dies die HBCI-Spezifikation vorgibt
- Bei sofort fälligen Aufträgen das Pseudodatum 01.01.1999 eintragen
- Ggfs. Umlaute entfernen, wenn die Bank noch nicht aktuelle pain-Formate unterstützt