Hallo,
wir sind eine Hochschule und haben bisher von jedem Studenten eine Einzugsermächtigung online bekommen (Student setzt einen Haken für die Einzugsermächtigung und bestätigt dies mit der Eingabe seiner BLZ, Kontonummer und Kontoinhaber).
Meine Frage ist nun, was müssen wir beachten, wenn wir auf SEPA umstellen? Ich habe gelesen, dass man die bisherigen Einzugsermächtigungen u.U. für das Mandat weiterverwenden kann? Nur was sind diese Umstände? Muss ich jeden Studenten dennoch informieren? Wenn ja, welche Informationen muss ich ihm mitteilen, bzw. welche Infos benötige ich von dem Studenten?
Ferner interessiert mich dann, welches <DtOfSgntr> ich für das Mandat verwenden muss und ob <AmendmentIn-dicator> dann auf true oder false stehen muss in der SEPA Datei.

Es wäre nett, wenn mir jemand weiterhelfen könnte, da ich nicht eindeutige Informationen dazu gefunden habe.

Vielen Dank.
Viele Grüße
mc

Hallo mc,
wenn Du die Formalitäten einhalten willst, brauchst Du von allen Studenten ein neues Mandat. Leider ist nämlich gesetzlich festgelegt worden, dass Mandate SCHRIFTLICH vorliegen müssen. Bestehende Einzugsermächtigunen können migriert werden, wenn der Zahlungsempfänger (also Du) den Zahlungspflichtigen (also den Studenten) vor der ersten SEPA-Lastschrift die Gläubiger-ID und die Mandatsreferenz mitteilt. Voraussetzung ist natürlich auch hier eine SCHRIFTLICH vorliegende Einzugsermächtigung.

Wenn Du das nicht machst, dann hast Du kein gültiges Mandat. In der Folge verlängert sich die Widerspruchsfrist für Deine Studenten von 8 Wochen auf 13 Monate.

VG
Frank

Hallo mc,

formal habt ihr von den Studenten keine gültige Einzugsermächtigung. Da diese nicht schriftlich vorliegt.
Damit entfällt für euch formal die Möglichkeit von der Umdeutungslösung gebrauch zu machen.

Wenn ihr Einzugsermächtigungen schriftlich vorliegen habt, ist der Ablauf wie folgt:
Ihr informiert den Schuldner darüber, dass Ihr die Einzugsermächtigung als SEPA Mandat weiter nutzen werdet. Dazu müsst ihr in der Umdeutung angeben, ab wann ihr das macht, welche Mandatsreferenz ihr dazu verwendet und was eure Gläubiger ID ist.

Das Datum der Mandatssignatur ist dann das Datum der Information. Den Indikator lasst ihr auf false, da es keine Mandatsänderung ist. Dafür muss der Sequenztyp aber auf FRST stehen, da es die erste SEPA Lastschrift ist, die gezogen wird. Achtung, damit muss die Lastschrift auch spätestens 5 Tage vor dem geplanten Belastungsdatum bei der Bank des Schuldners sein (sprich Wochenende und Feiertage unbedingt beachten!)

Bei der Umdeutung ürde ich ggf. auch die Vorabankündigung für dne Einzug von 14 Tage auf ggf. einen Tag reduzieren.

Viele Grüße

Holger

Vielen Dank für die schnellen Antworten.

Dann sind mir da noch 2 Fragen in den Sinn gekommen:
1. Muss ich die Sequenzen FRST - FNAL IMMER von Anfang bis Ende durchlaufen?
Das hieße nämlich ich müsste immer wissen, wann ich die letzte Abbuchung vornehme. Das kann sich bei einem Studenten ja schnell ändern (Prüfung nicht bestanden -> 1 Semester länger -> nochmal abbuchen)

2. Sind die Felder <OrgnlDbtrAcct> und <OrgnlDbtrAgt> immer mit anzugeben, wenn sich diese Informationen geändert haben oder handelt es sich dabei um rein informative Felder?
Das würde nämlich bedeuten, dass wir von jedem Studenten auch die alte Bankverbindung etc. speichern müssten, um sie an dieser Stelle mitzugeben.

Vielen vielen Dank schonmal.
Gruß
mc

Wenn Du nicht sicher bist, dass es 100% der FNAL Einzug ist, würde ich das nicht setzen. Hast Du einmal FNAL genutzt, ist das Mandat formal nicht mehr gültig. Ansonsten FRST und RCUR sollten in der richtigen Reihenfolge verwendet werden. Banken sind vom EPC angehalten, dies bereits bei der Einreichung zu prüfen, so dass man davon ausgehen kann, dass es hier zu Ablehnungen kommt (wenn die Prüfungen noch nicht umgesetzt sind, würde ich aber damit rechnen, dass diese kommen werden).



Die Informationen werden nur angegeben, wenn auch eine Mandatsänderung eingereicht wird.
<OrgnlDbtrAcct> nur bei Änderungen der Kontoverbindung innherhalb einer Bank.
OriginalDebtorAgent> nur beim Wechsel der Bank. Dann wird es aber auch direkt spannend: Hier muss zusätzlich angegeben werden, dass es ein bestehendes Mandat ist, aber die Bank gewechselt hat und der Sequenztyp muss wieder auf FRST gesetzt werden.

Willkommen in den Tücken einer Mandatsverwaltung.

Viele Grüße

Holger

Hallo Holger,

ich habe da mal eine Zwischenfrage - ich hoffe McBain ist nicht sauer.

Was wäre denn im folgenden Fall?
A reicht heute zum ersten Mal eine Lastschrift ein. Zahlungspflichtiger ist B. Fälligkeitsdatum ist der 30.06. --> Sequenz First

In einer Woche zieht A eine weitere Lastschrift von B. Fälligkeitsdatum soll der 28.06 sein. Was nun? OK - seeehr hypothetisch, aber geht das überhaupt?

Der Fall ist weniger hypothetisch als Du glaubst. Der Fall ist so viel sauberer als es auf den ersten Blick aussieht.

Du reichst die Lastschrift mit dem Sequenztyp "FRST" als erstes ein und die Zweite später mit dem Sequenztyp RCUR. Das heißt du hast sie unter einbehaltungd er Sequenz richtig eingereicht.


Solche Überholer kann es z.B. im Versandhandel geben. Beispiel ich gebe einem Handler ein Mandat, damit ich wenn ich in seinem Shop etwas bestelle, er diese per Lastschrift einziehen kann. Jetzt nehme ich meine Lieblingstermine um das zu veranschaulichen:
Wir schreiben das Jahr 2012
Ich bestelle am 04.04.2012 das erstemal im Shop. Die Lastschrift wird sofort (Sequenztyp FRST) erstellt und auch bei der Bank eingereicht.
Mein Konto kann aber erst am 16.04 belastet werden!

Ich bestelle dann am 05.04 noch mal. Die Lastschrift wird sofort (Sequenztyp RCUR) erstellt und auch bei der Bank eingereicht.
Mein Konto kann kann jetzt bereits am 11.04 belastet werden!

Bestelle ich am 10.04, kann mein Konto bereits am 13.04 belastet werden!

Wie kommt es dazu? Bei der ersten Lastschrift muss die Lastschrift 5 TARGET Tage (europäische Bankarbeitstage) vor dem Belastungstag bei der Bank des Schuldners sein. Zusammen mit einem Tag Verarbeitungszeit, die die annehmende Bank vermutlich benötigt sind das 6 Tage. Daraus ergibt sich für den 04.04.2012:
Mi. 04.04 ist der Tag 0
Do. 05.04 ist der Tag 1
Fr. 06.04 ist Karfreitag zählt nicht
Sa. & So. zählen auch nicht
Mo. 09.04 ist Ostermontag zählt auch nicht
Di. 10.04 ist Tag 2
Mi. 11.04 ist der Tag 3
Do. 12.04 ist der Tag 4
Fr. 13.04 ist der Tag 5
Sa. & So. zählen nicht
Mo. 15.04 ist der Tag 6 D.h. frühstens hier kann die Belastung erfolgen.

Kaufe ich am 10.04, ist der Sequenztyp RCUR und die Vorlaufzeit beträgt nur noch 2+1 Tag
Mi. 11.04 ist der Tag 1
Do. 12.04 ist der Tag 2
Fr. 13.04 ist der Tag 3

Durch Wochenende und Feiertage kann es also durchaus dazu kommen, das früher eingereichte Lastschiften erst später belastet werden können.

Viele Grüße

Holger

OK, ich wusste nicht, dass eine wiederkehrende Lastschrift "problemlos" vor der ersten Lastschrift gebucht werden kann. Coole Sache...

Ich habe nicht geschrieben, dass es ohne Probleme so laufen wird
Rein formal, gibt es aber genügen Konstellationen, bei denen es genau so dazu kommen kann.

Wir werden dann im nächsten Jahr mal schauen, was wer vergessen hat, oder anders ausgelegt hat. Bis das alles rund läuft, werden wir sicherlich einige Monate/Jahre weiter sein. Bei den wiederkehrenden Lastschriften sit auf jeden Fall ein größeres Umdenken notwendig.

Viele Grüße

Holger

Diese Diskussion finde ich sehr aufschlussreich, hat mir bisher schon gut weitergeholfen.
Mir ist gestern aber noch folgendes in den Sinn gekommen.
Das Feld <SeqTp> muss ja auf FRST gesetzt werden, sobald sich bei einer Lastschrift die Bank geändert hat.
Aber da das Feld ja global auf Sammler-Ebene definiert wird und nicht auf Ebene der entsprechenden Einzel-Lastschrift, hieße dies ja, dass ich immer darauf achten müsste innerhalb einer SEPA-Lastschriften-Datei nur Lastschriften mit der gleichen Sequenz zu generieren.
Oder sehe ich das falsch?

Ach ja, schließen sich die beiden Felder <OrgnlDbtrAgt> (Neue Bank) und <OrgnlDbtrAcct> (Neue IBAN) eigentlich gegenseitig aus? Oder seht ihr auch Konstellationen, indenen beide Tags innerhalb eines Mandats vorkommen können?

Wäre für eure Meinung wieder dankbar.
Vielen Dank.
Viele Grüße
mc

Hallo Holger,
großartiges Beispiel, ich freue mich schon sooooo sehr auf SEPA ...

Aber hast Du hier nicht noch die Pre-Notification vergessen?
Und wenn sich der Betrag ändert (was ja im Versandhandel der Fall ist) muß ja erneut eine Pre-Notification rausgegeben werden.

Gilt denn der Typ RCUR tatsächlich wenn sich der Betrag der Lastschrift ändert? Ist das nicht jedesmal eine Erstlastschrift?

ob eine lastschrift eine wiederkehrende iost, hängt einzig und allein davon ab, ob das zugrundeliegende mandat bei der bank des zahlungspflichtigen bereits schon einmal verwendet wurde.
das mandat ist vollkommen unabhängig von dem grund der belastung.

auch wenn ein kunde z.b. einen weiteren vertrag (nicht mandat) abschließt, ist sofern das bereits vorhandene mandat genutzt und bereits verwendet wurde, der erste einzug zu diesem neuen vertrag eine wiederkehrende zahlung.

Hallo Zusammen,


Nicht falsch, aber nicht präzise genug.
Kurzer Exkurs: Schematischer Aufbau einer SEPA Datei
Kopf
Sammler
Transaktion
(Mandatsinformationen)
Transaktion
Sammler
Transaktion

Der Sequenztyp ist auf Sammlerebene definiert, nicht auf Dateiebene. Damit könnten auch verschiedene Sequenztypen in einer Datei versendet werden. Es müssen nur mehrere Sammler (Paymeninformation Blöcke) verwendet werden. Da es unter HBCI/FinTS aber die Einschränkung gibt, dass es hier nur einen Paymeninformation Block geben darf kann man das nur unter EBICS so machen. Wer also verschieden Wege nutzt, oder auf Nummer sicher gehen möchte, für den gilt in der Tat diese Einschränkung.


Die beiden Tags <OrgnlDbtrAgt> und <OrgnlDbtrAcct> bezeichnen nicht die neue Bank/den neuen IBAN, sondern die alten (Original) Daten. Wenn ich die Bank wechsle habe ich immer auch einen neuen IBAN. Aber in der Spezifikation ist die Angabe des alten IBANs beim Wechsel der Bank nicht erlaubt (Der neuen Bank geht es ja auch nichts an, wo vorher mein Konto war)


Nein, bewusst weggelassen. Ich gehe aber in dem Beispiel davon aus, dass die Frist für die Prenotification vorher sauber reduziert wurde. Wenn das nicht der Fall ist und man alles formal richtig machen würde, würde sich das Beispiel natürlich deutlich ändern. Aber da die Prenotification eine reine Sache zwischen Schuldner und Empfänger ist und auf die Gültigkeit der Einzüge keinerlei Auswirkung hat, habe ich mir das gespart.



Exakt!



Die gute und richtige Erklärung von problem7 noch mal in anderen Worten:
Das Mandat ist die rechtliche Vereinbarung zwischen Schuldner und Empfänger, dass der Empfänger vom Konto einziehen darf, mit der Weisung an das Kreditinstitut diesen Einzug zuzulassen.

Es hat keinerlei Bezug zu dem Rechtsgeschäft, für das der Empfänger einzieht.
Daher ist die erste Lastschrift zu dem Mandat mit FRST und die weiteren Lastschriften zu dem Mandat mit RCUR zu kennzeichnen.

Daher bedeutet die Rückgabe wegen einem fehlerhaften Mandat auch nicht, dass der Schuldner dem Empfänger das Geld nicht geben muss. Es sagt nur aus, dass der Empfänger nicht die Erlaubnis hatte einzuziehen.
Mandat und das Rechtsgeschäft sind also zwei völlig unterschiedliche Sachen.

Viele Grüße

Holger
[marq=right]

Hallo Holger, hast Du dazu eine Quelle ?

Und dazu auch eine Quelle ?

öffentlich zugängig z.B.: SEPA FAQ von den Seiten der Deutschen Kreditwirtschaft (die FAQ sind mal richtig gut und auch praxisnah. Das kann man von der DK sonst nicht immer so klar behaupten....) Da steht was das Mandat im rechtlichen Sinn ist



In der FinTS Spezifikation Kapitel SEPA Zahlungsverkehr in der Einleitung Einzelaufträge und in der Einleitung Sammelaufträge.

Viele Grüße

Holger

Danke! Die DK-FAQs sind wirklich gut. Und in die FinTS-Spezi hatte ich bisher nie reingeschaut, ich habe immer nur die Anlage 3 Datenformate beachtet.

Hallo Holger,



Wäre nicht die Verwendung von Containern (conxml) eine praktikable Möglichkeit, eine physische Datei mit mehreren pain-Nachrichten zu verwenden?

Gruß,
Stefan

Technisch ja, praktisch nein. Container sind - zumindest in D - nur für Rechenzentren (z.B. für POS Abrechnung) und im Interbankenverkehr zugelassen, nicht für Kunden.

Na super... und ein weiteres Mal bestätigt sich die Kundenfreundlichkeit des ganzen SEPA-Konzepts...

Aber ein Banking-Programm könnte doch eigentlich eine Container-Datei intern wieder in mehrere Sammellastschriften aufteilen. Ich kenne allerdings nur ALF BanCo, aber das schmeißt beim Import einer conxml-Datei nur einen Fehler aus. Naja, vielleicht kommt das Feature ja noch... wie sieht es denn diesbezüglich bei anderen Banking-Programmen aus?