RFC: Erweiterung Mandats-Handling für SEPA-Lastschrift

[carsten]

Ich schau mir grad den Brief meiner Bank an, die zukünftig per SEPA Geld einzieht.
Die Mandatsreferenz ist in meinen Augen sinnvoll aufgebaut:
1. Ein Buchstabe (keine Ahnung, wofür der steht)
2-11: Die Vertragsnummer
12-21: Mandatsdatum im Format xx.yy.zzzz
22-25: laufende Nummer, z.B. 0001

Ich denke, dass man mit solch einem Aufbau so ziemlich alles erschlägt was so kommen kann: Änderungen in der Bankverbindung, mehrfache Abbuchungen bei Familien, ungültige Mandate etcpp.
Die Anzahl der Stellen kann ja noch gewählt werden, aber ich finds logisch. Und 35 Stellen hat man ja.

und wenn ich mir so die Diskussion zum Thema im Onlinebanking-Forum anschaue zur Mandatsverwaltung ist es halt nicht mit der Verwendung der Mitgliedsnummer getan.

Grüße
Carsten

[matthias]

Ein Mandat gilt für mehrere Mitglieder - Wie oben schon geschrieben ist das bei uns mehrheitlich der Fall (Familien). Bislang ziehe ich die getrennt ein, weil das besser auf die nächste Gliederungsebene abgebildet werden kann.

Ich bin der Meinung, dass dein Vorgehen so nicht korrekt ist. Entweder gibt es einen Familienbeitrag, für das ein Mitglied ein Mandat erteilt hat oder es gibt einen Beitrag pro Familienmitglied. Dann muss aber auch für jedes Familienmitglied ein Mandat (ggfls. vom gleichen Kontoinhaber) vorliegen. Wenn ansonsten ein Familienmitglied die Mitgliedschaft kündigt, wird das Mandat für alle ungültig.

Du übersiehst einen Fall: Der Zahler und damit Mandatsgeber ist nicht Mitglied. In diesem Fall greift leider keine der Möglichkeiten in JVerein. Situation: Zwei Kindet werden Mitglied bei uns, die Eltern treten nicht ein - wir erhalten ein Mandat zur Abbuchung bei beiden Kindern (so aktuell geregelt). Ich sehe nicht warum das nicht auch in Zukunft funktionieren sollte, denn durch die Kündigung von einem Kind (nicht des Mandats!), würde ja das Mandat seine Wirkung behalten. Im Grunde ist das der Fall, der im Rahmen von Firmen diskutiert wird: Mandat pro Auftrag oder pro Kunde -- du pochst auf das Mandat pro Auftrag (wären hier die beiden Kinden), während ich sage, dass ich lieber eine Mandat pro Kunde haben möchte. Beide Fälle werden in der Literatur an der ich vorbei gekommen bin jeweils mit Vor- und Nachteilen dargestellt, aber beide sind denkbar!

Achso - die Eltern (bzw. den Zahler) als Pseudomitglied aufzunehmen, funktioniert auch nicht, weil ich für den keine Mitgliedsnummer habe (Modell: Externe Mitgliedsnummer).

Wechsel zu JVerein mit bestehendem Mitgliedsstamm, die Wahrscheinlichkeit, das die vergebenen Mandatsreferenzen ein anderes Schema benutzt ist hoch

Das ist tatsächlich noch eine Herausforderung. Die gibt es aber bei einem Wechsel zwischen anderen Systemen genau so.

Hä? Bislang hätte ich im Notfall alle Daten von Hand neuerfassen können und wäre fertig gewesen. Umstieg erfolgreich. Mein Patch machte keine Annahme über die Struktur der Mandatsreferenz, sondern nur einen Defaultvorschlag, und damit hätte ich bei einem Wechsel einfach die Referenzen übernehmen können, ebenfalls fertig. Deine Autogenerierung verhindert das Nachhaltig - ich _muss_ damit jedes Mitglied über neue Mandatsreferenzen informieren.

Berücksichtigung der externen Mitgliedsnummer (aktuell ist die interne ID ja nichtmal sichtbar, wenn "externe Migliedsnummer" aktiviert ist

Wofür muss hier die externe Mitgliedsnummer her? Bei einer Mandats-ID handelt es sich um eine beliebige eindeutige Zeichenfolge, die dem Mitglied mitgeteilt wird, um theoretisch die Buchungen zuordnen zu können. Eine Frage: Kennst du alle Vertragsnummern deiner Versicherungsverträge mit den zugehörigen Mandatsnummern auswändig? Ich vermute mal nicht. Bei den Mitgliedsnummern/Mandatsnummern sieht es doch auch so aus.

Ok - mir egal - es wäre einfacher gewesen einen Serienbrief zu generieren, weil ich in meiner aktuellen Serienbriefdatenbank die notwendigen Informationen gehabt hätte - das ist mir aber die Diskussion nicht wert. Weiterhin wäre es auch einfacher gewesen auf das Mitglied zurückzuschließen. Für mich hatte die DBID in JVerein nie eine Bedeutung und ich hätte gerne Beibehalten, dass die externe Nummer an die Stelle der internen tritt. Wenn das nicht gewünscht ist (anders kann ich diese Diskussion nicht interpretieren), muss ich halt nachziehen.

Neue Version (Version 2.5.0 Rev. 402)
Beim Blick in die aktuelle Version (ich habe mir nur die Oberfläche angeschaut) stelle ich aber fest, das ich mir jetzt (mit generierten Daten) wunderbar selbst ins Bein schießen kann. Einmal verklickt und ich ziehe illegal ein. Fall: Revision 2 ist die gültige Mandatsreferenz. Ich arbeite im Mitglied und verklicke mich, bemerke das nicht und ziehe ein: Es war eine falsche Revision drin (1 oder 3).

Ich sehe hier keinen Vorteil gegenüber einer generierten Vorgabe, die dann geändert werden kann. Sobald der Kassierer eingreift, kann beides genauso schief gehen.

[Holger Fischer]

Hallo Zusammen,

durch einen Forumsbeitrag vom Carsten zu hibiscus in Homebanking-Hilfe bin ich hier auf die Diskussion zur Mandatsverwaltung gestoßen.
Ich selber kenne jverein nicht, aber beim Durchfliegen der Diskussion hier zur Mandatsverwaltung sind mir ein paar Dinge aufgefallen, bei denen ich den Eindruck habe, dass sie zu mindestens nicht ganz sauber verstanden/umgesetzt wurden. Daher komme ich der Bitte/Aufforderung von Carsten nach und poste mal hier ein paar Dinge, die mir aufgefallen sind.

Das Wichtigste zuerst: Was ist eigentlich das Mandat
Das Mandat ist die Erlaubnis von einem Konto Geld einzuziehen (wie bei der Einzugsermächtigung). Nicht mehr und nicht weniger. Das eigentliche Mandat hat keinen –direkten- Bezug zu irgendeinem Vertrag/irgendeiner Mitgliedschaft! Umgekehrt schon. Ich kann mich in einem Vertrag auf ein Mandat beziehen und mitteilen, dass ich fällige Gelder auf Grundlage dieses Mandats einziehe.

Das Mandat liegt immer schriftlich vor! D.h. für das Mandat habe ich immer ein Stück Papier in der Hand. Jede Änderung die ich bezüglich des Mandats vornehme muss ich dokumentieren und falls die Bank es verlangt vorlegen können. Kann ich das nicht, liegt kein gültiges Mandat vor und Kontobelastungen können 13 Monate rückwirkend zurückgegeben werden (auch wenn das Mandat ungültig war, sagt das nichts über die Gültigkeit des Rechtsgeschäfts aus für das das Mandat genutzt wird. Ist derjenige immer noch Mitglied, schuldet er das Geld weiterhin)
Das gilt auch für die Einzugsermächtigungen: Die können nur als Mandat weiter genutzt werden, wenn diese schriftlich vorliegen und die erfolgte Umdeutung als Mandat nachgewiesen werden kann! Ist das nicht der Fall: neues schriftliches Mandat.

Während bisher die Einzugsermächtigung einmal eingeholt wurde und dann nie wieder benötigt wurde (außer bei Reklamationen), lebt das Mandat bei SEPA. Bei jedem Einzug werden die vorliegenden Mandatsinformationen elektronisch mit eingereicht. Das bedeutet auch, dass die Daten auf dem Papier identisch mit den elektronischen Daten sein müssen und jede Änderung für das Papier, wie auch elektronisch dokumentiert wird!

Mal eben, weil man es organisatorisch braucht, die Mandatsreferenz ändern bedeutet, die Änderung elektronisch mit in den Datensatz einzutragen und schriftlich dokumentieren, dass man die Änderung durchgeführt hat und der Schuldner über die neue Referenz informiert wurde.
Macht man das nicht, bedeutet die neue Mandatsreferenz ein neues Mandat (muss schriftlich vorliegen), der erste Einzug mit der Referenz hat die Sequenz FRST und die Vorlaufzeit beträgt wieder 5 (TARGET) Tage + 1 Bankarbeitstag.

Wechsel der Bank.
Wechsel der Bank ist möglich ohne dass ein neues Mandat notwendig ist. Aber dies ist wieder eine Mandatsänderung. Sprich ich benötige die schriftliche Dokumentation dass eine Änderung erfolgt (in der Regel wird das in dem fall die Info des Mitglieds sein, dass eine andere Bankverbindung genutzt werden soll) und ich muss die Änderung mit in den Datensatz eintragen.
Bei der Änderung der Bank erfolgt eine besondere Kennzeichnung (SMDA= Gleiches Mandat neue Bank) , die Sequenz wird wieder auf FRST gesetzt und es gelten wieder die Fristen für die Ersteinreichung.
Ist das zu kompliziert: Neues Mandat (neue Mandatsreferenz), neue Unterschrift.

Zur Eindeutigkeit der Mandatsreferenz:
Ziel ist es, dass sowohl der Lastschrifteinreicher (aufgrund seiner Nachweispflicht), wie auch der Schuldner jederzeit ein Mandat sowohl elektronisch, wie auch papierhaft eindeutig identifizieren kann. Wie das Ziel erreicht wird, interpretieren viele sehr unterschiedlich. Wer auf der sicheren Seite sein möchte macht das einfach wirklich eindeutig (was alles wirklich geht und was nicht werden vielleicht irgendwann mal Gerichte entscheiden. Bis dahin muss man an diesem Prozess ja nicht unbedingt beteiligt sein)

Ein Mandat mehrere Mitglieder
Wie geschrieben ist das Mandat unabhängig von den Verträgen. D.h. ich kann von mehreren Leuten die Mitgliedsbeiträge auf Basis eines Mandats einziehen. Dabei ist es völlig egal, ob ich den Betrag in einer Summe oder für jeden einzeln einziehe. Wenn ich das so mache, sollte ich aber bei Kündigungen aufpassen, dass nicht versehentlich auch das Mandat gekündigt wird. Denn dann darf ich für keins der Mitglieder mehr einziehen (war bei der Einzugsermächtigung aber auch nie anders)

Wie schon geschrieben kenne ich jverein nicht, daher nur kurz was die Mandatsverwaltung meiner Meinung/Erfahrung nach rein organisatorisch für SEPA mindestens leisten können muss:
Verwalten der Sequenz
Erste und Wiederkehrend (ggf. einmalig) inklusive automatische Anpassung. Sprich der erste Einzug mit diesem Mandat wird als erster gekennzeichnet. Ist der erfolgreich – automatische Änderung auf wiederkehrend bzw. ist der nicht erfolgreich Änderung zurück auf erste.
Verwaltung der Änderungen
Änderungen, die elektronisch übergeben werden müssen, müssen erkannt und eingestellt werden. Auch hier Kontrolle, ob erfolgreich oder nicht und ggf. zurück drehen der Änderung.
Wer glaubt braucht man nicht: Es gibt Banken, die bereits zum Start die Einhaltung dieser Dinge prüfen und Lastschriften –kostenpflichtig- zurück gehen lassen.

Verwalten von mehreren Mandaten zu einem Mitglied

Verwalten von mehreren Mitgliedern zu einem Mandat

Bei der Erstellung der SEPA Aufträge muss zusätzlich min. beachtet werden
Einhaltung der Vorlaufzeiten.
Die Aufträge müssen rechtzeitig erzeugt werden, damit die Belastung zu dem festgelegten Termin erfolgen kann (anders als bei der IZV Lastschrift wird das feste Datum der Belastung und nicht das Datum der Einreichung angegeben, so dass die Datei rechtzeitig vorher bei der Bank sein muss). Die Vorlaufzeiten sind durchaus komplizierter. Da es unterschiedliche Regeln für die SEPA Vorlaufzeit und die Verarbeitungszeit der annehmenden Bank gibt.
Da die meisten wohl per HBCI aufliefern (Datenträger gibt es unter SEPA nicht mehr (wenn es die eine oder andere Bank noch anbietet, läuft das außerhalb jeder Spezifikation!), muss dafür gesorgt werden, dass es ggf. mehrere Dateien geben muss (eine Datei je Belastungsdatum und je Sequenztyp)
Da ein Verpassen der Vorlaufzeiten organisatorisch einiges nach sich zieht, sollte man die Einzüge vor dem spätesten Versanddatum erzeugen und versenden können. Das entspannt das ganze deutlich.

Die SEPA Formatversion
Unter SEPA gibt es für Lastschriften derzeit 2 ab November 3 Spezifikationsversionen wie die Lastschrift aufgebaut sein muss. Nicht jede Bank unterstützt jede dieser möglichen Spezifikationen. Möchte man die also sicher versenden können, muss im Zweifel die richtige Version erzeugt werden können.

Soweit spontan mal ein paar Anmerkungen zu den Dingen die mir hier aufgefallen sind. Bei Fragen gerne auch direkt an mich (am besten per Mail, da ich hier nicht so oft rein schaue).

Viele Grüße

Holger

[carsten]

Danke Holger

Wenn ich mir die erzeugte Datei xml anschaue wird immer FRST genutzt und man hat die längere Vorlaufzeit.
Ich habe es ja nun schon zweimal genutzt und die Bank hat es gefressen ...

[Holger Fischer]

Hi Carsten,

in Deutschland prüft aktuell praktisch keine Bank auf Einhaltung der richtigen Sequenzreihenfolge. Bei einer großen Bank in Deutschland wird auf Seite des Schuldners aber bereits auf Einhaltung geprüft und die Lastschrift zurückgegeben. Im Ausland ist diese Prüfung schon häufiger vertreten. Da der europäische Bankenverband (epc) alle Banken dazu aufgefordert hat, dass diese gemäß den Regularien die Einhaltung überwachen müssen, ist damit zu rechnen, dass das in absehbarer Zeit die Regel sein wird. Da zudem die Banken verpflichtet sind dem Schuldner die Möglichkeit zu geben, einzelne Mandate nach bestimmten Kriterien zu sperren oder zu erlauben, ist es nur eine Frage der Zeit, bis die Banken entsprechende Datenbanken für jeden Kontoinhaber haben, in der sie erkennen, ob die richtige Sequenz eingehalten wurde.

Ich hatte für mich auch mal überlegt nur wiederkehrend zu machen und die FRST gar nicht erst zu nehmen (erleichtert das Handling deutlich....), habe das aber nach diesen Informationen wieder verworfen.

Viele Grüße

Holger

[carsten]

Na, dann steckt SEPA hier trotz aller Fortschritte noch in den Kinderschuhen. Es fehlt die komplette Mandatsverwaltung.

Da stellt sich die Frage nach der Schnittstelle jverein/hibiscus, was da übergeben wird. Eine komplett geprüfte XML inkl Mandatsverwaltung oder nur Daten zum Einzug und hibiscus erledigt den Rest inkl. Mandatsverwaltung (womit die Diskussion hier hinfällig wäre)

[heiner]

Hallo,

die Ausführungen von Holger klingen plausibel. Wenn das alles erforderlich ist, wird das das Ende von JVerein sein. Das kann ich allein aus Zeitgründen nicht leisten. Neben JVerein habe ich auch noch einen Job, der mich in Anspruch nimmt. Vor dem Hintergrund, dass es bei Olaf Willuhn mit Hibiscus ähnlich auszusehen scheint, war es das dann wohl.

Heiner

[carsten]

Heiner,

ich kann diesen Frust verstehen über ein Bürokratiemonster.
Ich habe diese Diskussion forciert, weil ich genau sowas vermutet habe und hoffe, dass es ein gemeinsames Vorgehen mit Olaf und anderen Helfern gibt, das zu stemmen.

Leider kann ich nicht (mehr) coden (zuletzt Assembler unter Z80), aber die Grundlagen sind mir schon klar.

Für mich wäre ein Lösungsansatz, dass jverein die Zahlungsdaten an hibiscus übergibt und parallel dazu die Mandatsdaten, und hibiscus die Mandatsverwaltung und die Erzeugung der XML übernimmt, denn dort wird es unabhängig von jverein sowieso benötigt.

Vielleicht könnt ihr euch da auf eine Schnittstelle einigen.
Hibiscus soll ja schon in die Richtung gegangen sein (alles Gerüchte). Schließt euch doch mal kurz.

Kopf hoch

[matthias]

Versuch einer Anforderungsanalyse für eine Mandatsverwaltung (Erstmal Hibiscus ausgeklammert):

1. Pro Mandat ist ein Eintrag zu pflegen/anzulegen - Inhalt:
   • Mandatsreferenz (vorgeschlagen, kann überschrieben werden, es erfolgt eine Prüfung)
   • Name des Kontoinhabers (nach Vorlage Lastschriftmandat)
   • Adressdaten des Kontoinhabers (nach Vorlage Lastschriftmandat)
   • Konto des Zahlungspflichtigen (IBAN)
   • Kreditinstitut des Zahlungspflichtigen (BIC)
   • Unterschriftsdatum
   • Gültigkeit des Mandats (d.h. wurde es gekündigt?)
   • Wann das Mandat schon für einen Einzug benutzt? (-> ist es noch gültig + ist es ein Ersteinzug)
   • Optional kann ein Scan des Mandats angehängt werden (sollte ausreichen für die Archivierungspflicht)
2. Bei Erstellung einer Abrechnung wird das Mandat als "benutzt" markiert => Potentielles Problem: Eine Abrechnung kann nicht einfach wiederholt werden. (Hier wäre eine Einbindung in Hibiscus wirklich hilfreich => nach erfolgreichem HBCI Transfer, ist das Mandat benutzt)
3. Den Lastschrift Mitgliedern und Kursteilnehmern wird ein Mandat zugeordnet, die Eingabe von Kontodaten entfällt, da im Mandat Inbegriffen.
4. Beim Vorbereiten der XML Stuktur muss die Gültigkeit des Mandats abgefragt werden, ggfs. wird das Mitglied nicht eingezogen -- eine Warnung mit den übersprungenen Mitgliedern ist auszugeben
5. Fristen würde ich so wählen, dass immer der Worst-Case einreichbar ist => der Kassierer ist auf der sicheren Seite

Ggfs. bitte ergänzen.

Ich habe gerade bei unserer Sparkasse geschaut und da kann ich von Hand Sepa-Lastschriften eingeben (ist was für jemanden der Mutter+Vater erschlagen hat) - wenn hibiscus das vergleichbar aufbaut (d.h. ohne Mandatsverwaltung), braucht es eine getrennte Verwaltung in JVerein.

[carsten]

Anbei die Beschreibung zum Programm "Vereinsmeister", wie es dort gelöst ist.
So weit ich es sehe ein praktikabler Weg.
Mal sehen, was Holger sagt.

http://www.vereinsmeister.de/files/Vere ... d_SEPA.pdf

Grüße
Carsten