SEPA Komponente gesucht

[Union]

Das ist verständlich. Aber wenn SEPA es nicht zuläßt? Das ist der Preis der Vereinheitlichung. Das kann man ja nicht Deiner Software anlasten. Man könnte es als Option pro Bank hinterlegen, welche Art der Umwandlung dort nötig ist. Und auch DTAUS0 hatte ja Einschränkungen, es waren z.b. weder Doppelpunkt noch Unterstrich noch Apostroph oder Kleinbuchstaben zugelassen. Dein Kunde kann Dir nicht anlasten was Du nicht zu vertreten hast.

[arnof]

Zitat von Union:

Das ist verständlich. Aber wenn SEPA es nicht zuläßt? Das ist der Preis der Vereinheitlichung. Das kann man ja nicht Deiner Software anlasten. Man könnte es als Option pro Bank hinterlegen, welche Art der Umwandlung dort nötig ist. Und auch DTAUS0 hatte ja Einschränkungen, es waren z.b. weder Doppelpunkt noch Unterstrich noch Apostroph oder Kleinbuchstaben zugelassen. Dein Kunde kann Dir nicht anlasten was Du nicht zu vertreten hast.

Ja mit dem Unterstrich: bei Onlinebanking geht das auch nicht, da hier unsere EXE AFS_BANK hieß, deshalb ging keine Auslandsüberweisung (SEPA Vorgänger), keiner konnte helfen incl. Rechnenzentrum der VR Banken. Bis ich mal unsere EXE in AFSBANK umbenannt habe (Name des Programms wird immer mit übertragen) und schon ging alles. Das ist halt Banane die beim Entwickler reift und beim Kunden hoffentlich schön Gelb ist und nicht mehr Grün

[arnof]

Hallo,

ich habe einige PN bekommen, die Fragen wie weit ich bin. Zur Info, wenn ich den Code raus gebe muss ich mir ja etwas mehr mühe geben, wie wenn es nur für mich ist.

Was kann die Komponente ?:

- Überweisung, Lastschriften (Privat und Firmenlastschrift), mit allen Subarten.
- Anbindung von einzelnen Belegobjekten (manuell anzulegen, so wie bei den anderen DLL's hier)
- Direkte Anbindung an ein TDataSet, d.h. man mach vorher eine Abfrage mit den durchzuführenden belegen, in der Komponente eine Feldzuordnung) und sagt mach mal ....
- IBAN Berechnung aus Kontonr+Blz
- BIC Ermittlung aus Blz (eine aktuelle Bankenliste ist dafür dabei, falls man das möchte)

Lieferung erfolgt im Quelltext, aktuell mache ich das für XE2 und auch für Delphi 5, ein eigener Stringtype ist definiert, so das das an einer zentralen stelle auf die eigenen Bedürfnisse angepasst werden kann!

Stand der Dinge: eigentlich fertig, ich teste es aber erst ausführlich mit meinem Onlinebanking Programmierer und dann nochmals mit dem EDV-Leiter meiner Hausbank. Also diese Woche wird es fertig werden!

[knight]

Hallo,

nur mal interessehalber: Wie gehst du mit den sich alle paar Wochen ändernden Datenformaten (siehe z.B. http://www.ebics.de./index.php?id=77 ) um?

Gruß knight

[Kostas]

Hallo arnof,

ich hoffe du hast bemerkt dass SEPA nicht einfach nur XML Dateien erzeugen ist, und dass du
auch an die richtigen Informationen herankommst um sie umsetzen zu können!
Deine Kunden werden es einfach verlangen!
Das ist ein Aufwand der sich "Sie" Schreibt. So einfach wie DTA ist das mit Sicherheit nicht. Es ist durchaus berechtigt dass die anderen Anbieter ein Service Vertrag mit den Kunden abschließen um das Produkt auch ernsthaft weiterentwickeln zu können.
Ich meine nur, wenn du es machst und dafür Geld verlangst, dann aber auch bitteschön richtig. Dann würde auch nichts dagegensprechen!

Gruß Kostas

[arnof]

Zitat von knight:

Hallo,

nur mal interessehalber: Wie gehst du mit den sich alle paar Wochen ändernden Datenformaten (siehe z.B. http://www.ebics.de./index.php?id=77 ) um?

Gruß knight

Version 2.7 vom 25.3.2013
gültig ab 4. November 2013
Final Version

Änderungen zwischen V2.6 zu V2.7 betreffen die Schnittstelle kaum und die Anpassungen kommen gerade, weil die Banane z.Z. bei den banken erst gelb wird....

Banken stellen dieses Jahr erst um (meine bessere Hälfte ist in der Auslandsabt. einer Bank).

Wenn was geändert werden muss, dann kann man, wenn man eine Komponente im Quellcode hat, selbst Änderungen machen, bei einer DLL geht das nun mal nicht ....

[sh17]

Also in Wochenabständen ändern werden sie wohl kaum etwas können. Aber vielleicht kann sich arnof doch noch dazu durchringen, das ganze nach einer anfänglichen Gebühr unter OpenSource zu veröffentlichen, damit alle was daran tun können. Also ich zahl die 99 EUR und es wird dann veröffentlicht. Vielleicht finden sich noch ein paar mehr. Oder er hat eine andere Idee, wie gemeinsam der Quellcode gewartet werden kann, wenn er das möchte. Auf die Wartungsschiene aufspringen fände ich jetzt nicht so prickelnd.

[musicman56]

Hallo,

so schön der Open-Source-Gedanke im Ansatz ja ist, aber für diesen sensiblen Bereich (es geht ja um Geld, noch dazu um's Geld unserer Kunden) würde ich niemals auf ein Open-Source-Projekt setzen. Da geht es schlichtweg um Verantwortung. Verantwortung für die ordnungsgemäße Funktion. Im Schadensfall haut mir nämlich mein Kunde den Wartungsvertrag um die Ohren, und verklagt mich. Dann ist es aus mit "lustig". Da muss ich mich hundertprozentig auf meine Zulieferer verlassen können. Bei einem Open-Source-Projekt das nicht unter der Verantwortung eines Projektleiters steht, der auch entscheidet was rein kommt, wer supportet, wer die Verantwortung hat, was geändert wird usw. sehe ich diese Anforderungen als nicht erfüllt, und demzufolge für den Einsatz beim Kunden nicht geeignet.

Etwas anders sieht es aus, wenn sich ein paar Leute zusammentun und gemeinsam Ressourcen in ein Projekt stecken, mit dem Ziel das Rad nicht jedesmal neu erfinden zu müssen. Aber auch dann muss das ordnungsgemäß geregelt sein, insbesonders die Zuständigkeiten und die Verantwortung.

Vielleicht sehe ich das etwas eng, aber es geht wie gesagt um Geld anderer leute, und da hört der Spass auf. Darum würde ich persönlich sowohl Zeit als auch Geld nur in ein SEPA-Tool investieren, das die vorgenannten Kriterien erfüllt. Darumj von meiner Seite aus: Interesse ja, aber wenn dann alles sauber und ordentlich geregelt. Mit der Veröffentlichung eines Sourcecode allein ist es nicht getan.

Aber, nehmt es jetzt nicht persönlich, only my 2 cents

[sh17]

Ich möchte hier keine Grundsatzdiskussion auslösen, aber OpenSource würde in dem Falle zumindest eine Kontrolle des Codes ermöglichen. Haftung liegt dann natürlich in der Verwantwortung des Nutzers des Codes.

Und zur Haftung/Qualität der genannten Tools oben. Wer sagt das diese korrekt funktionieren? Die sind nicht zertifiziert und der Quellcode kann auch nicht geprüft werden. Sepa-Tools ist noch nicht mal eine GmbH, wenn es dumm kommt und keine Versicherung besteht, bekommst Du gar keinen Ersatz. Zumal die Haftung für Fehler z.B. in der IBAN-Berechnung in den AGB des Anbieters sogar ausgeschlossen werden.

Aber das ist meine Meinung, jeder wie er möchte.

[Jens01]

Zitat:

Sepa-Tools ist noch nicht mal eine GmbH

Du weißt, was GmbH heißt!?