SEPA Komponente gesucht

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