SEPA Komponente gesucht

[obel-X]

Ich weiß nicht, wie professionell du es brauchst, ich muß nur aus Überweisungs- bzw. Lastschrift-Datensätzen eine SEPA-XML-Datei zum Import in eine Onlinebanking-Software bauen. Und nach Überfliegen der Spezifikation sieht das nicht wirklich dramatisch aus. Beispiel für zwei Überweisungen:

Code:

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.002.03"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:pain.001.002.03
pain.001.002.03.xsd">
   <CstmrCdtTrfInitn>
      <GrpHdr>
         <MsgId>Message-ID-4711</MsgId>
         <CreDtTm>2010-11-11T09:30:47.000Z</CreDtTm>
         <NbOfTxs>2</NbOfTxs>
         <InitgPty><Nm>Initiator Name</Nm></InitgPty>
      </GrpHdr>
      <PmtInf>
         <PmtInfId>Payment-Information-ID-4711</PmtInfId>
         <PmtMtd>TRF</PmtMtd>
         <BtchBookg>true</BtchBookg>
         <NbOfTxs>2</NbOfTxs>
         <CtrlSum>6655.86</CtrlSum>
         <PmtTpInf><SvcLvl><Cd>SEPA</Cd></SvcLvl></PmtTpInf>
         <ReqdExctnDt>2010-11-25</ReqdExctnDt>
         <Dbtr><Nm>Debtor Name</Nm></Dbtr>
         <DbtrAcct><Id><IBAN>DE87200500001234567890</IBAN></Id></DbtrAcct>
         <DbtrAgt><FinInstnId><BIC>BANKDEFFXXX</BIC></FinInstnId></DbtrAgt>
         <ChrgBr>SLEV</ChrgBr>
         <CdtTrfTxInf>
            <PmtId><EndToEndId>OriginatorID1234</EndToEndId></PmtId>
            <Amt><InstdAmt Ccy="EUR">6543.14</InstdAmt></Amt>
            <CdtrAgt><FinInstnId><BIC>SPUEDE2UXXX</BIC></FinInstnId></CdtrAgt>
            <Cdtr><Nm>Creditor Name</Nm></Cdtr>
            <CdtrAcct><Id><IBAN>DE21500500009876543210</IBAN></Id></CdtrAcct>
            <RmtInf><Ustrd>Unstructured Remittance Information</Ustrd></RmtInf>
         </CdtTrfTxInf>
         <CdtTrfTxInf>
            <PmtId><EndToEndId>OriginatorID1235</EndToEndId></PmtId>
            <Amt><InstdAmt Ccy="EUR">112.72</InstdAmt></Amt>
            <CdtrAgt><FinInstnId><BIC>SPUEDE2UXXX</BIC></FinInstnId></CdtrAgt>
            <Cdtr><Nm>Other Creditor Name</Nm></Cdtr>
            <CdtrAcct><Id><IBAN>DE21500500001234567897</IBAN></Id></CdtrAcct>
            <RmtInf><Ustrd>Unstructured Remittance Information</Ustrd></RmtInf>
         </CdtTrfTxInf>
      </PmtInf>
   </CstmrCdtTrfInitn>
</Document>

[Union]

Tja, die Struktur heisst nicht umsonst pain Blöd nur wenn man Kunden im EU-Ausland hat - es gibt nämlich keinen SEPA-Standard. Jedes Land und einige Banken erfinden eigene Strukturen sowie Validierungen. Damit sichern sie sich eine leichtere Migration, sind aber untereinander komplett inkompatibel.

[Kostas]

Hallo Union,

das verstehe ich nicht. SEPA soll doch genau das Europaweit standardisieren!

SEPA selbst umzusetzen halte ich nicht für Sinnvoll da es permanent Erweiterungen
gibt. An die Informationen muss man zuerst herankommen. Das ist nicht so selbstverständlich. Außerdem bekommt man bei Sepa-Tool die Möglichkeit die IBAN und
BIG aus der KontoNr und BLZ zu generieren. Auch die Reihenfolge wie Lastschriften
in dem XML-File abgelegt werden ist nicht egal. Sie müssen vorher gruppiert werden.
Und noch viel mehr Schweinereien sind da enthalten.

Gruß Kostas

[Union]

Zitat von Kostas:

Hallo Union,
das verstehe ich nicht. SEPA soll doch genau das Europaweit standardisieren!

Ja, so war es gedacht. Aber realistisch: EU-Direktive, Banken bilden Arbeitsgruppen und diskutieren das auf Länderebene und danach wird das dann von JEDER Bank oder Bankengruppe von deren Programmierern umgesetzt und in den Workflow eingebunden. Es gibt also wahrscheinlich mehrere 1000 SPEA-Implementierungen. Da werden Dinge einfach anders gemacht (z.b. das eigentlich standardisierte Datumsformat) oder Programmierer lassen gern mal eine falsche URN aus internen Tests stehen bzw. prüfen gegen diese usw. Und da man ja nett zueinander sein will, werden diese Fehler nicht bemängelt sondern für Einzelfälle umgangen. Aus dem Grund ist es auch besser ein fertiges Produkt für Einreichungen einzusetzen, denn dann erfolgen die Nachbesserungen wenigstens auf dieses bezogen zentral.

[Kostas]

ah, sehr interessant.
Da bin ich froh die richtige Komponente eingekauft zu haben.
Mich hat die 600 Seiten Doku abgeschreckt und bis deshalb auf der Suche gegangen.
Interessanterweise gibt es sehr wenig Tools obwohl der Markt dafür recht groß sein sollte.

Gruß Kostas

[mkinzler]

Zitat:

Interessanterweise gibt es sehr wenig Tools obwohl der Markt dafür recht groß sein sollte.

Das ändert sich vielleicht demnächst, spätestens Anfang nächstes Jahres.

[sh17]

Zitat von Union:

Tja, die Struktur heisst nicht umsonst pain Blöd nur wenn man Kunden im EU-Ausland hat - es gibt nämlich keinen SEPA-Standard. Jedes Land und einige Banken erfinden eigene Strukturen sowie Validierungen. Damit sichern sie sich eine leichtere Migration, sind aber untereinander komplett inkompatibel.

Grundsätzlich sollte der von obel-X genannte Ansatz aber doch funktionieren? Wenn ich eine solche SEPA-Datei für Überweisung und Lastschrift erzeuge, muss die doch immer gleich interpretiert werden. Oder machen die genannten Tools einen Unterschied, bei welcher Bank die Datei eingereicht wird?

Sepa-Tools finde ich im Vergleich zu sevDTA 2.0 doch recht teuer, was kann es denn mehr/besser? Hat das jemand im Überblick?

[Union]

Das weiss ich nicht ob die das unterscheiden. Sollten sie aber. Nur z.b. für Österreich:

• Der XML-Header sieht ganz anders aus
• <CstmrCdtTrfInitn> muss in <pain.001.001.02> umbenannt werden
• Das Zeitformat muß ohne ms sein und darf nicht mit Z enden
• <Grpg>MIXED</Grpg> ist vorgeschrieben
• <NbOfTxs> darf NICHT gefüllt sein bzw. gar nicht vorhanden
• <PmtId><EndToEndId> darf keine echte ID beinhalten sondern muß mit der Konstante NOTPROVIDED gefüllt werden

Zitat von Bank Austria:

Bei Ihrer Datei handelt es sich um ein deutsches Format, das auch in Hinkunft nicht verarbeitet werden kann.

[sh17]

Grrrh, ok, danke

Ich Frage mich immer, was für D.pp.n diese Schnittstellen entwerfen, da denkt man, das müsste jeder Programmierer besser können.

[Union]

Zitat von sh17:

Ich Frage mich immer, was für D.pp.n diese Schnittstellen entwerfen, da denkt man, das müsste jeder Programmierer besser können.

Der Schnittstellenentwurf ist ok, aber die Implementierung macht scheinbar jeder wie er will.