SEPA Komponente gesucht

[Kostas]

Hallo Zusammen,

ich bin auf der Suche nach einer SEPA Komponente um Inlands- Lastschriften und Überweisungen ausführen zu können.
Zu diesem Thema komme ich immer wieder auf die Firma JAM. Doch leider hat JAM die Weiterentwicklung der Delphi Komponenten
eingestellt und vertreibt ein eigenes Programm. Die Doku zu SEPA ist etwa 600 Seiten schmal und beschreibt noch nicht einmal alles
was geht. Es ist auch nicht in einem Zusammenhang beschrieben was genau benötigt wird für Lastschriften und was für Überweisungen.
Falls jemand eine Bezugsquelle kennt natürlich auch Kommerziell wäre ich sehr Dankbar für einen Hinweis.
Gruß Kostas

[musicman56]

Hallo,

schau dir doch mal die Black Box von Windata (www.windata.de) an.

[Memo]

Zitat:

Zitat von musicman56 (Beitrag 1206835)

schau dir doch mal die Black Box von Windata (www.windata.de) an.

Das Produkt Windata basiert auf dem Hersteller DDBAC, der die kompletten Protokolle auflöst. Ende 2011 habe ich mir das SDK zuletzt runtergeladen. Da waren zum ersten mal auch Delphi-Beispiele (leider nicht ganz fehlerfrei) dabei.
Können als Typbibliothek importiert werden.
Ich brauchte das für eine Insellösung(also kein anschließender Verkauf) und habe mit dem Hersteller direkt gesprochen. Sie waren sehr entgegenkommend(preislich).

[sh17]

Kennt jemand auch anderweitige Komponenten?

[Kostas]

Ich habe mich auf die SepaTools von J.Schliffenbacher eingeschossen.
http://www.sepa-tool.de/
-Bestes Preis/Leistungsverhältnis
-Bester Support
-Produkt funktioniert auf Anhieb einwandfrei.

Gruß Kostas

[vagtler]

http://www.delphipraxis.net/1183565-post7.html

[Patrick444]

Guten Tag,

ich bin auf dies Forumsbeiträge gestossen, da ich momentan auf der Suche nach einer Delphi-Implementierung der SEPA-Datenformats (XML) für SEPA-Überweisungen und SEPA-Lastschriften bin.
Nach längerer Suche bei Google & Co. bin ich bis auf die Spezifikationen nicht auf wirklich viel hierzu gestoßen.
Kann mir jemand hierzu Quellen / Beispielcode, etc. nennen?

[vagtler]

Was gefällt Dir an den oben schon genannten Lösungsansätzen ganz genau nicht?

[arnof]

Zitat:

Zitat von Kostas (Beitrag 1216501)

Ich habe mich auf die SepaTools von J.Schliffenbacher eingeschossen.
http://www.sepa-tool.de/
-Bestes Preis/Leistungsverhältnis
-Bester Support
-Produkt funktioniert auf Anhieb einwandfrei.

Gruß Kostas

ich habe mir auf deinen Tipp hin das mal angeschaut, sieht ganz gut aus und der Preis ist auch OK

[vagtler]

Ich kann nur die schon erwähnte sevDTA-DLL empfehlen, die preislich viel attraktiver ist und in einem unserer Standardprodukte seit Jahren ihren Dienst klaglos versieht.

[Kostas]

Ja, das freut mich.

Ich habe einen persönlichen Kontakt zum Programmierer von "sepa-tool"
Er ist sehr umgänglich und die Produkte funktionieren einfach.
Das SEPA XML-Format selbst zu schreiben ist absolut unrentabel.
Die Dokumentation ist ca. 600 Seiten dünn und beschreibt die kompletten
Schnittstelle für alle SEPA Transaktionen die die Banken durchführen müssen.
Lastschrift ist ja nur ein kleiner Teil davon. Außerdem wird sich noch einige
ändern. Man benötigt die entsprechende Connections die der Herr Schliffenbacher
von sepa-tool einfach hat. Dann benötigt man noch die Datenbank für den Abgleich
der BLZ,KTO und IBAN und BIG. Sicherlich kann man das alles selber machen. Doch die
Zeit wird knapp und es ist eine Menge Arbeit.

Schöne Grüße Kostas

[vagtler]

Ich habe nichts gegen die SepaTools. Die sevDTA-DLL erfüllt halt unsere Anforderungen an sämtliche SEPA-Transaktionen bestens und das zu einem Bruchteil der Kosten (regelmäßiger Update des Datenbestands ist auch hier inklusive).

Tatsächlich haben wir so eine Standard-Anwendung mit weit über 25.000 Installationen innerhalb kürzester Zeit (<10 PWochen) um alle für uns relevanten SEPA-Geschäftsvorfälle erweitern können.

[Kostas]

oh sorry,
wir habe fast gleichzeitig geantwortet. Ich wollte dem Patrick444 darauf hinweisen dass es sich das überlegen soll ob er SEPA selbst umsetzt oder eine fertige Komponente verwendet wie SEPA-Tool oder sevDTA-DLL oder sonst eine andere Komponente. SEPA ist sehr umfangreich. Ich kenne sevDTA-DLL leider nicht, kann also nichts dazu sagen.

Gruß Kostas

[arnof]

Zitat:

Zitat von vagtler (Beitrag 1220086)

Ich kann nur die schon erwähnte sevDTA-DLL empfehlen, die preislich viel attraktiver ist und in einem unserer Standardprodukte seit Jahren ihren Dienst klaglos versieht.

sevDTA-DLL; gibt es hier auch die DLL einbindung für Delphi (Strukturen, Funktionsaufrufe), oder mus man die sich selbst zusammenbasteln aus dem VB Code ?

Weiterer Nachteil: als Partner steht ein Webbewerber von uns dabei :?

====================================

Also ich denke an einem Tag macht man die XML Ausgabe für SEPA selbst ...

Für die SEPA-Tools spricht die automatische IBAN und BIC Ermittlung und die Referenzliste deutet auf ein ausgereiftes Produkt hin, dort ist z.B. das Rechenzentrum der Raiffeisenbanken als Referenzkunde dabei, so das ich Montag wahrscheinlich die Bestellen werde!

[vagtler]

Zitat:

Zitat von arnof (Beitrag 1220105)

[...] sevDTA-DLL; gibt es hier auch die DLL einbindung für Delphi (Strukturen, Funktionsaufrufe), oder mus man die sich selbst zusammenbasteln aus dem VB Code ? [...]

Den DLL-Wrapper haben wir uns in wenigen Stunden selbst gebaut, allerdings nicht anhand des VB-Codes sondern anhand der Dokumentation...

Zitat:

[...] Also ich denke an einem Tag macht man die XML Ausgabe für SEPA selbst ... [...]

Sicher...

[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:

Zitat von Kostas (Beitrag 1223744)

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:

Zitat von Union (Beitrag 1223742)

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:

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:

Zitat von sh17 (Beitrag 1224463)

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.

[mkinzler]

Man hat also einen europäischen Standard geschaffen, welcher im jedem land wieder anders interpretiert/implementiert wird :gruebel: Eigentlich hat man den Standard doch entworfen, um zu vereinheitlichen.

[vagtler]

Zitat:

Zitat von sh17 (Beitrag 1224459)

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

Ich kann nur sagen, dass wir uns beide angeschaut haben und das günstigere Tool alle unsere Anforderungen erfüllt hat und noch immer erfüllt.

[Lemmy]

Zitat:

Zitat von mkinzler (Beitrag 1224465)

Man hat also einen europäischen Standard geschaffen, welcher im jedem land wieder anders interpretiert/implementiert wird :gruebel: Eigentlich hat man den Standard doch entworfen, um zu vereinheitlichen.

mag schon sein, aber International hat sich für Standard die Bedeutung "Ja, aber..." durchgesetzt...

[musicman56]

Klar ist, der Standard implementiert nicht das technisch machbare, sondern den größten gemeinsamen Nenner unter den europäischen Banken.

In Anbetracht der Gegebenheiten und der vorhandenen Strukturen im europäischen Geldmarkt müssen alle (auch wir...die IT'ler) froh sein, dass dieser Standard überhaupt zustande gekommen ist. Ich jedenfalls bin froh darüber, dass z.B. eine Softwarepflege-Lastschrift für meine österreichischen Kunden keine 4 Euronen mehr kostet.

[arnof]

Ich habe nun eine Entscheidung getroffen und werde die SEPA Komponente nun selbst machen (in Delphi Quellcode).

Überweisung+Lastschrift+IBAN und BIC Ermittlung

Gund: beide hier vorgestellten DLL's sind einmal DLL's (muss ja nicht sein), zweitens können die soweit ich das gelesen haben definitiv nur Deutschland und kein Österreich!

Da ich auch Österreich anbieten will, muss ich sowieso manuell ran.


Wer interesse hat kann die Komponente von mir für 99,- EUR+MwSt haben.

Die deutsche Version sollte morgen verfügbar sein!

[Union]

Na dann wünsche ich Dir viel Spass und Erfolg. Zum Testen registriere Dich am besten hier.

[sh17]

Zitat:

Zitat von Union (Beitrag 1225826)

Na dann wünsche ich Dir viel Spass und Erfolg. Zum Testen registriere Dich am besten hier.

Fett:

Zitat:

Eine bis zum 31. Dezember 2014 gültige Nutzungslizenz erlaubt das manuelle Prüfen unbegrenzt vieler XML Dateien. Die Gebühr für eine Nutzungslizenz beträgt 1000 €.

[Union]

Man kann es natürlich auch ungetestet an die Kunden weitergeben :evil:

[arnof]

Zitat:

Zitat von Union (Beitrag 1225829)

Man kann es natürlich auch ungetestet an die Kunden weitergeben :evil:

Bei manchen der hier vorgestellten sachen kommt es mir so vor :pale:

Ich habe mir die Demos runtergeladen und wollte das ding bei VB-Tools bestellen, es ging aber keiner ans Tel: mehrmals über den Tag hin versucht .....

Dann habe ich mir die Demo runtergeladen und mal mit dem Beispielprogramm getestet: deutsche Umlaute gehen nicht, einem Renè wird der letzte Buchstabe geklaut, sorry das kann man nicht anbieten!

Die andere Komponente habe ich nicht ausführlichst getestet, da ich keine Lust habe 200,-EUR Wartung zu bezahlen (das alte DTA-Format hat sich seit ich es Umgesetzt habe (1995) nicht geändert).

Wenn man eine Hausbank hat, dann testen die das für einem direkt, ob alles passt!

[Union]

Ja nur bräuchtest Du dann eine Hausbank in jedem Land für das Du es anbieten möchtest. Mit den Umlauten ist korrekt. Es wird in SEPA zwar UTF-8 verwendet aber die Banken machen mit den Sonderzeicchen was sie wollen. Deshalb gibt es da verschiedene Varianten, mit VOr- und Nachteilen:
- Ersetzen der Umlaute durch "Erweitern", z.b. Ä -> AE. Nachteil: Tauchen mehrere Umlaute im <USTRD> auf, kann dieser zu lang werden und muss abgeschnitten werden.
- Ersetzen der Umlaute durch "Ersetzen", z.b. Ä -> A (oder evtl. durch _). Nachteil: Evtl. nicht mehr verständlich, speziell im Ausland.
- Überspringen der Umlaute, z.b. Übergrößenträger -> bergrentrger. Nachteil: Evtl. nicht mehr verständlich.
- Nichts ändern. Nachteil: Die jeweilige Bank macht die Konvertierung selber oder lehnt die Verarbeitung ab. Oder es wird unkonvertiert weitergereicht und die Konvertierung erfolgt auf dem Weg bis zum Empfänger u.U. mehrfach nach unterschiedlichen Verfahren. Es kommt dann z.b. +berg&oeuml\tr_ger beim Empfänger an.

[sh17]

Arbeitest Du bei der Validierungsbude? Selbst wenn es verschiedene Interpretationen der Schnittstelle je Land gibt, DAS hat mit Schnittstelle nichts zu tun, das ist ne Richtlinie.

[Union]

Nein ich arbeite nicht bei denen. Und mit der Schnittstelle hat das schon zu tun, denn es betrifft die Gültigkeit bzw. Zulässigkeit der transferierten Inhalte. Da ich das programmieren musste, habe ich mich damit beschäftigt.

Zitat:

Zitat von DKW DFÜ-Abkommen S. 23f

Zeichensatz
Für die Erstellung von SEPA-Nachrichten, d. h. der Nutzdaten, sind die folgenden Zeichen in der Kodierung gemäß UTF-8 bzw. ISO-8859 zugelassen. Die Verwendung von Byte Order Marks (BOM) ist nicht zulässig.

Zugelassener Zeichencode Zeichen Hexcode

Numerische Zeichen 0 bis 9 X'30' – X'39'

Großbuchstaben A bis Z X'41' – X'5A'

Kleinbuchstaben a bis z X'61' – 'X'7A'

Apostroph "'" X'27'

Doppelpunkt ":" X'3A'

Fragezeichen "?" X'3F'

Komma "," X'2C'

Minus "-" X'2D'

Leerzeichen " " X'20'

Linke Klammer "(" X'28'

Pluszeichen "+" X'2B'

Punkt "." X'2E'

Rechte Klammer ")" X'29'

Schrägstrich "/" X'2F'

Das Kreditinstitut ist berechtigt, bei Verwendung von Zeichen außerhalb dieses Zeichenvorrats die unzulässigen Zeichen z. B. durch Leerzeichen oder durch bedeutungsähnliche Zeichen aus dem definierten Zeichensatz zu ersetzen oder gegebenenfalls auch die gesamte Datei zurückzuweisen

[arnof]

Wie es zu Codieren ist, steht neben der Doku (DFÜ-Abkommen) in der XML encoding="UTF-8"?

[Union]

Ja, das ist eine der wenigen Geimeinsamkeiten: <?xml version="1.0" encoding="UTF-8"?>. Wir daber auch beim Weglassen des Encoding meistens verarbeitet.

[arnof]

Zitat:

Zitat von Union (Beitrag 1225858)

Weglassen des Encoding meistens verarbeitet.

Aha, das meistens stört mich an der Aussage. Jeder Kunde bei dem "meistens" nicht geht ist ein unzufriedener Kunde und macht einen Supportfall auf :cheer:

Und es soll sogar Kunden geben, die auf die korrekte Schreibweise Ihres Namens/Firmennamens -> Verwendungszwecks wert legen und wenn die dann gesagt bekommen das kann meine Software nicht ist das i.d.R. nicht gerade Image fördernd!