Hallo,

bin der Neue.

Ich stelle gerade ein in Perl selbstgeschriebenes Vereinsverwaltungsprogramm auf SEPA-Basislastschriften um und bin damit auch schon im Prinzip fertig. Einige Fragen sind jedoch bisher noch offen, und vielleicht kann dazu jemand etwas sagen (wäre nett):

Wieso genügen bei Lastschriften, die in Banking-Software manuell erfaßt werden, scheinbar so wenige Angaben (in ALF BanCo 5 fehlt z.B. das Mandats-Unterschriftsdatum, der Sequenztyp und sämtliche <AmdmntInfDtls>), während in der XML-Datei viel mehr Angaben gemacht werden müssen?

Wieso dürfen Erstlastschriften nur max. 14 Kalendertage vor dem Ausführungstermin eingereicht werden, während die Vorabinformation *mindestens* 14 Tage vor dem Ausführungstermin zu erfolgen hat? Normalerweise werden ja die Erstellung von Anschreiben und Lastschrift-Datei zusammen erledigt, was aber unter Einhaltung der o.g. Fristen nicht mehr funktionieren *kann*, d.h. man müßte sich nach Erstellung des Anschreibens mit der Vorabinformation extra noch einen Termin für in 7 Tagen für die Erzeugung der Lastschrift-Datei einstellen...

Erst- und Folgelastschriften: Bei Erstlastschriften muß das Ausführungsdatum mindestens 6 Tage hinter dem Einreichdatum liegen, bei Folgelastschriften 3 Tage. Wenn jetzt 2 Lastschriften hintereinander erstellt werden (was normalerweise allerdings nicht vorkommt, aber theoretisch möglich wäre), gilt dann die zweite Lastschrift als Folgelastschrift? Wenn ja, wäre dann läge ja das Auführungsdatum der Folgelastschrift vor dem Auführungsdatum der Erstlastschrift... Wie kann eine Software die korrekten Auführungstermine bestimmen?

Einzellastschriften: Ein Mitglied hat einem Verein ein Mandat für Lastschriften erteilt. Hierüber werden die jährlichen Mitgliedsbeiträge und ggf. Spenden eingezogen. Bestellt nun ein Mitglied z.B. Vortragsmitschitte und möchte den Kaufpreis dafür ebenfalls einziehen lassen, ist dann diese Lastschrift im Sinne von SEPA eine Folge- oder eine Einzellastschrift?

Wenn ein Lastschriftzahler eine andere Kontonummer beim selben Bankinstitut erhält, muß dies lt. Spezifikation in <AmdmntInfDtls> mitgeteilt werden; der <SeqTp> kann dabei RCUR bleiben. Wechselt er dagegen die Bank, muß <SeqTp> auf FRST gesetzt werden. Wie lassen sich Änderungen des Bankinstituts erkennen, wenn die BIC künftig wegfällt?

Viele Grüße und ein schönes WE!

Stefan

Die BIC darf m.W. nur innerhalb Deutschlands weg gelassen werden. Und bei deutschen Instituten ist immer die alte BLZ in der IBAN enthalten, die sich dann auf jeden Fall ändert. Daran könnte man es erkennen.
Und ich meine auch gelesen zu haben, dass das Weglassen der BIC nur eine temporäre Regelung wäre. Würde ich eine Software programmieren, würde ich die BIC zu keiner Zeit weg lassen. Ich würde sie zumindest intern speichern. Zur Not unter Zuhilfenahme externer BIC-Rechner mit SOAP/XML-Schnittstelle wie z.B. www.iban-rechner.de maschinell zusteuern

OK, dann muß ein Programm also auch noch die länderspezifischen Eigenheiten berücksichtigen und - im Falle von Deutschland - die BLZ aus den Stellen 5-12 der BIC heraus-"substring"-en... ist ja ganz großes Tennis.

Hallo Stefan,

dann versuchen wir mal deine Fragen trotz des komplexen Themas mal so verständlich wie möglich zu beantworten.

Dafür gibt es in der Regel zwei Gründe:
1. Die SEPA Umsetzung ist noch nicht vollständig (Der Aufwand -für KnowHow Aufbau und Umsetzung ist auch für kommerzielle Anbieter nicht ohne).
2. Einige Details ergeben sich ggf. aus der Bedienlogik und werden davon abgeleitet
ok, es gibt eigentlich noch einen dritten Grund:
Du hast die fehlenden Möglichkeiten noch nicht gefunden...

Deine Information sind so nicht ganz "sauber".
Bei den Fristen der SEPA Lastschriften musst Du immer unterscheiden zwischen
- Fristen bei der Bank des Zahlers,
- Fristen bei der Bank des Empfängers
- Fristen gegenüber dem Zahler
Die 14 Tage Einreicherfrist beziehen sich seitens der SEPA Regularien auf die Bank des Zahlers. Sprich die Lastschrift darf fürhstens 14 Tage vorher bei dieser Bank sein. Wenn die Bank des Empfängers in der Lage ist solche Lastschriften "zu parken" können die Lastschriften auch schon früher eingereicht werden. Bei den meisten Banken geht das in Abhängigkeit vomÜbertragungsverfahren.
Für die PreNotification gibt es die Möglichkeit diese auf bis zu 1 Tag abzubedingen (dann hat man die seltsame Konstellation, dass die Erstlastschrift 5 Tage vorher bei der Bank des Schuldners liegt,ich den Schuldner aber erst einen Tag vorher davon in Kenntniss setzen muss....

Exakt, solche Überholer kann es in der Praxis geben. Eine Software weiß dass nur durch den eigenen Versand einer Lastschrift. Die Lastschrift die als erstes eingereicht wird und als erstes bei der Bank des Schuldners ist hat den Sequenztyp FRST

Die Sequenz bezieht sich immer auf das Mandat zu dem die Lastschrift eingezogen wurde. Die Fachlichkeit für was eingezogen wird ist uninteressant. Wichtig ist nur, dass das Mandat nicht nur für einmalige Lastschriften ausgestellt ist. Damit gilt wieder das von oben: Die Lastschrift, die zu diesem Mandat als erstes eingereicht wurde, hat die Sequenz FRST, alle weiteren RECUR.

In Deutschland an der IBAN. Hier ist noch die BLZ drinn geschlüsselt. Ansonsten macht man eine Änderung ja nicht einfach aus einer Laune herraus, sondern nach einer Benachrichtigung durch den Schuldner. Da hängt es dann schlicht von der Qualität dieser Info ab und was man damit macht.

Viele Grüße

Holger

Hallo Holger,

danke erstmal für die umfangreichen und hilfreichen Antworten auf die Fragen eines SEPA-Neulings. Soweit ist - erstmal - alles klar, nur zwei kurze Nachfragen:



Wer kann das entscheiden - der Zahlungsempfänger einfach so für sich, oder muß das auf dem Mandat vermerkt sein?



Das soll ja das Programm anhand den Daten (IBAN, BIC) selbständig erkennen können und dann automatisch entsprechende XMLs generieren, ohne daß der Anwender da manuell eingreifen muß. D.h. bei deutschen IBANs könnte man einen Bankwechsel noch einigermaßen sicher erkennen, aber bei ausländischen Banken dann nicht mehr (es sei denn, man implementiert für alle 27 (?) teilnehmenden EU-Länder einen individuellen Erkennungsalgorithmus).

Andererseits, wenn das ganze System so kompliziert gemacht ist, daß es programmmäßig nicht mehr einfach zu händeln ist, dann frage ich mich, wie streng das dann in der Praxis von den Banken gehandhabt wird, wenn z.B. aufgrund eines softwaremäßig nicht erkannten Bankenwechsels der Sequenztyp auf RCUR statt FRST gesetzt ist...

Gruß,
Stefan

So, ich habe mir nochmal ein paar warme Gedanken zu <AmdmntInfDtls> gemacht und bin für mich zu folgendem Ergebnis gekommen (hier als "Pseudo-Programmcode" dargestellt):



Ist das fachlich so korrekt, oder habe ich was falsch verstanden? Bitte um Kommentare...

Stefan

Edit: Oder muß "<OrgnlDbtrAgt><FinInstnId><Othr><Id> = SMNDA" unabhängig davon gesetzt werden, ob die Mandatsreferenz geändert wurde oder nicht...?

Gute Frage. Der Code sieht jedenfalls plausibel aus. Hast du es mal mit Testdaten in einer Software ausprobiert und die XML-Dateien verglichen?

Nein, leider habe ich kein anderes Programm, mit dem ich das testen könnte.

Wenn du willst, kannst du mir mal Testdateien schicken. Dann checke ich die mal.

Danke, aber ich glaube, das würde so nicht viel bringen. Die von meinem Programm erzeugten XML-Dateien validieren fehlerfrei gegen die XSDs, und "SEPA-Explorer" und "ALF BanCo" lesen sie fehlerfrei ein (abgesehen vom Container-Format, aber das scheint ja für Endkunden eh nicht gedacht zu sein).

Interessanter wäre die fachliche Richtigkeit der erzeugten Dateien. Ein sinnvoller Test sähe m.E. so aus, daß man zuerst verschiedene Testfälle entwirft (Lastschriften mit neuem Mandat, dann weitere Lastschriften mit Änderung verschiedener Daten gegenüber der letzten Lastschrift wie Mandatsreferenz, die in der IBAN codierten Angaben Kontonummer, BLZ, Land, die BIC, die Gläubiger-ID - jeweils in verschiedenen Kombinationen), und diese Testfälle dann mit beiden Programmen - dem zu testenden Programm und einem Referenzprogramm - "durchspielt" und die dabei erzeugten XML-Dateien vergleicht. Wobei das natürlich nicht viel heißen muß, denn das Referenzprogramm könnte ja auch Fehler enthalten...

Ich denke, ich suche bei Gelegenheit mal nach entsprechender Software, die es vielleicht als Free- oder Demoversion zum Download gibt...

Stefan: Diese Fälle kannst du doch mit deinem eigenen Konto testen. Setze einfach als Auftraggeber und Empfänger dein und das selbe Konto mit 1 Euro ein. Dann siehst du beide Seiten auf deinem Konto. Thema Wechsel der Bankverbindung dann zwischen Vereins- und Privatkonto hin und her buchen.
Gläubiger-ID hast du schon, dann nur noch bei der Bank eine Inkassovereinbarung abschließen, dann kannst du normalerweise einreichen nach Belieben.
Zur Bank hochladen entweder mit der Starmoney/SFirm Testversion (kostenfrei) oder über das Webbanking der Bank - falls angeboten.
Zumindest SFirm kann "Fremddaten versenden". Heißt, es wird nicht importiert sondern nur "locker" geprüft und dann abgeschickt. Man kann sich aber sicher sein, dass nichts an den Daten geändert wird. Und hat daher eine verlässliche Aussage zur Verbuchbarkeit der Daten durch die Bank. Das hat - denke ich - die beste Aussagekraft.

nur so zur Sicherheit: Nicht jede Bank schaltet "mal so eben" die LS-Einreichung frei. Da kann auch schon mal eine Bonitätsprüfung dran hängen oder ein Wechsel des Kontenmodells.

Gruß
Raimund

Hallo Stefan,

dein Code ist soweit ich das von hier überblicken kann (habe aktuell kein Zugriff auf meine Daten) fachlich richtig. Man könnte die Spec zwar auch so auslegen, dass SMDA (gleiches Mandat neue Bank) mit einer neuen Referenz und einer dahingehenden zusätzlichen Mandatsänderung möglich ist, aber darauf würde ich zum Einen nicht setzen und zum Anderen würde ich für diesen so extrem unwahrscheinlichen Praxisfall da ein neues Mandat verwenden.

Viele Grüße

Holger

Hallo Holger,

ich hab's jetzt mal so umgesetzt wie in meinem "Pseudo-Code" dargestellt plus dem Zusatz im "Edit"-Nachtrag, und zwar daß bei einem Wechsel der Bank immer SMNDA gesendet wird, da ich davon ausgehe, daß in diesem Fall das bestehende Mandat weiter gültig ist. Bei einem komplett neu erteilten Mandat wird dagegen immer eine Erstlastschrift gemacht (<SeqTp> = FRST), egal, ob die Bank gewechselt hat oder nicht, und da wäre SMNDA m.E. fachlich falsch.

Eine Änderung der Bank kann ich bei fehlender BIC allerdings nur zuverlässig bei deutschen IBANs feststellen, in denen die BLZ codiert ist, und einen Kontowechsel bei einer ausländischen Bank nur "vermuten" und somit darauf reagieren, wenn sich die IBAN ändert und die BIC gleichbleibt.

Ich würde ja gerne mal wissen, wie andere das machen. Werden da echt all die einzelnen IBAN-Codierungsarten der verscheidenen Länder individuell berücksichtigt...?

Gruß,
Stefan

Braucht ja nicht. Bei einem Kontowechsel ändert sich entweder nur die IBAN bei einem reinen Kontowechsel oder IBAN+BIC bei einem Bankwechsel. Mit der deutschen Besonderheit, die BIC weglassen zu können hat das eigentlich garnichts zu tun.

Klar, wenn das Weglassen der BIC nur auf D-Land zutrifft (ist das denn tatsächlich so?), dann stellt sich dieses Problem natürlich nicht.

http://www.bundesbank.de/Redak…version%5D


Zwei Sätze davor:


Bitte interpretiere es selbst, ich war nicht dabei als das beschlossen wurde. Ich bin der Meinung, dass "Übergangsbestimmungen" alles nur noch komplizierter machen ops:

Meines Wissens wird ibanonly auch 2016 sepaweit kommen...

edit... sorry....Beitrag 2te seite von onlbanker übersehen..... aber das gibt meiner Erinnerung recht

Also stellt sich die Frage ja doch, wie man bei IBAN-Änderungen ohne BIC feststellen kann, ob es sich um einen Bank- oder nur um einen Kontowechsel handelt.

In D-Land ist die Sache klar: DEpp bbbbbbbb kkkkkkkkkk (bbbbbbbb = BLZ, kkkkkkkkkk = Kontonummer).

In den anderen 26 Ländern kann die Zusammensetzung der IBAN anders aussehen.

Müssen also für jedes Land die speziellen IBAN-Regeln und -Ausnahmen implementiert werden? Und immer wenn sich an diesen Regeln und -Ausnahmen etwas ändert, muß das nachimplementiert werden? - Kann ja wohl nicht sein...

Stefan, was hindert dich, bei Feststellung einer Ungleichheit im Stringvergleich der alten mit der neuen IBAN den Benutzer zu befragen, ob es sich dabei um einen formellen Kontowechsel handelt?
Verstehe dein Problem nicht so ganz.