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

[matthias]

Hallo zusammen,

ich bereite die Übergabe der Kasse an meine Nachfolgerin vor dazu gehört auch die SEPA Umstellung möglichst gut vorzubereiten. (Wirklich viel Zeit bleibt ja nicht mehr). Die Version wie sie zur Zeit in JVerein (Nightly) implementiert ist, ist für uns extrem ungünstig, da hier angenommen wird, dass Mandatsreferenz == Datenbank-ID des Mitglieds. Wir benutzen aber in unserem Verein eine durch die Obergruppierung vergebene Mitgliedsnummer, so dass die DB-ID ansonsten für unsere Mitglieder und mich als Kassierer keine Bedeutung hat.

Zusätzlich gibt es Gerüchte, dass die Mandatsreferenz bei einem Widerruf ihre Gültigkeit verliert:

https://www.kreissparkasse-heinsberg.de ... ferenz.pdf

und durch eine neue Nummer bzw. ID (es ist ein 35 Zeichen langer String) ersetzt werden muss (vgl. Folie 17 unten).

Meine Intention:

1. Ermögliche Benutzung der externen Mitgliedsnummer als Basis für die Mandatsreferenz und
2. Editierbarkeit der Mandatsreferenz um der Anforderung des Sparkassen Dokuments genüge zu tun. Ich würde das pragmatisch so lösen:
   Das erste Mandat erhält abhängig von der Vorauswahl aus Punkt 1 automatisch die Mitgliedsnummer (JVerein/Extern), bei Neuerteilung des Mandats, wird einfach "-1" angehängt, weitere dann mit höheren Postfixen.

Sollte eine Kassierer nun eine ganz eigene Variante nutzen, so kann er auch diese durch Eintragung überschreiben.

Ich habe den zugehörigen Patch an diesen Beitrag angehängt. Eine Nightlybuild habe ich hier bereitgestellt:

http://www.doppel-helix.eu/jverein-2.5. ... derbar.zip

Ich hatte den Patch bereits direkt an Heiner geschickt, welcher aber klar gemacht hat, dass er ihn so nicht akzeptieren wird. Seine Argumente:

1. Die Mandatsreferenz muss eindeutig sein
2. Die Mandatsreferenz darf nicht mit zukünfigen Defaults kollidieren können

Ich meine, dass beide Punkte nicht greifen:

Zu Punkt 1: Eine Eindeutigkeit kann durch keine Software abgesichert werden, außer es sind _alle_ Mandate hinterlegt (unwahrscheinlich, da diese schon aus Datenschutzgründen nach Auslaufen der Aufbewahrungsfrist vernichtet werden sollten IMHO). Bei einem Wechsel des Programms wird es mit hoher Wahrscheinlichkeit keine komplette Neuerfassung geben (schon aus Bequemlichkeit) => Kollisionen sind nicht zu verhindern, wenn der Kassierer nicht mitarbeitet. Gleiches gilt für die Frage was passiert beim Wechsel des Verwaltungsprogramms - hier bin ich an die Nummerierung von JVerein gebunden, was passiert, wenn ich schon Mandate anders vergeben habe? Entweder kann ich dann JVerein nicht einsetzen, oder muss eine neue Mandatsreferenz mitteilen.

Zu Punkt 2: Kollision mit zukünfigen Defaults (Mitgliedsnummern): Ja als Kassierer kann ich mir bei Änderungen der Mandatsreferenz ins Knie schießen, dass geht aber mindestens genauso gut, mit IBAN/BIC/Abschreibefehler oder ähnliches.

Nein mein Patch ist ganz sicher nicht die beste Lösung (bin gerne für Vorschläge offen), ich hätte aber gerne eine Perspektive, da ich eine vollständige Mandatsverwaltung (die wäre für die beiden Kritikpunkte unbedingt notwendig) für unrealistisch halte. Gerade wenn ich Kosten/Nutzen abwäge.

Ich habe das hier hin geschrieben, da ich nicht möchte dass der Patch verloren geht - wie ich bei uns weitermache weiß ich noch nicht.

Beste Grüße

Matthias

[carsten]

Ich hatte schon vor längerer Zeit geschrieben, dass ich die Mandatsnummer gerne editierbar hätte.
Also vorbelegt meinetwegen mit der Mitgliedsnummer, aber wer mag ändert sie sich nach seinem Schema händisch ab.

Da es aber scheinbar kein eigenes Feld für die Mandatsnummer gibt sondern einfach das der Mitgliedsnummer genommen wird gehts nicht.

Mich störts zur Zeit (noch) nicht, kann mir aber durchaus Fälle vorstellen, wo es dann eben doch geändert werden muss.

Grüße

[mmueller]

N'Abend!

Mir wäre eine editierbare Mandatsnummer auch viel lieber. Aber ich könnte auch mit folgendem Kompromiss leben, der zumindest die von Heiner geforderte Eindeutigkeit gewährleistet:
Von den 35 möglichen Stellen werden die ersten 6 Zeichen (das reicht zwar nicht für den ADAC aber bequem für FC Bayern) mit der internen ID belegt (evt. mit Nullen aufgefüllt). Der Rest (29 Zeichen) kann frei belegt werden.

Das Migrationsproblem von einer Software zu einer anderen bleibt dabei allerdings bestehen.
Wenn hingegen eine Bank fordert, dass eine verbrauchte Mandatsnummer für alle Zeit gestorben ist, dann ist das durch die frei editierbaren Felder auch machbar.

Gruß,
Markus

[heiner]

Mit dem Vorschlag von Markus könnte ich mich anfreunden.

Heiner

[matthias]

Ein Alternativvorschlag mit zwei Komponenten:

1. Mache es möglich die Mandatsreferenz aus der externen Mitgliedsnummer zu generieren (auf externer Mitgliedsnummer liegt ein Unique-Index, sodass keine Kollisionen auftreten können)
2. Füge in "Einstellungen" eine Checkbox hinzu: "Ich bin Kassierer mit Hirn und habe verstanden, dass die Mandatsreferenz eindeutig sein muss, ich möchte sie aber editieren können/ich muss sie editieren können". Falls die Ironie nicht rüberkommt - die Options sollte natürlich formaler heißen: "Erlaube Überschreiben der automatisch vergebenen Mandatsreferenz".

Mögliche Umsetzung:

• Übernahme der Änderungen gemäß Patch als Basis, aber folgende Änderungen:
• Einbau der Option b im Einstellungen Menü
• Default ist, die Option aus b ist nicht gesetzt. In diesem Fall wird die Mandatsreferenz im Mitglied iund den Kursteilnehmern zwar angezeigt, ist aber nicht änderbar. In der Datenbank ist zu diesem Zeitpunkt kein Wert in dem Feld "MandatsID" hinterlegt. Es greifen die Fallbacks auf die Mitgliedsnummern.
• Durch das Setzen der Option aus b, werden die Felder editierbar und der Kassierer kann die Mandatsreferenz überschreiben
• Beim Setzen der Option wird der Kassierer über die Folgen und Anforderungen nochmal informiert: Eindeutigkeit der Mandatsreferenz
• Wird die Option wieder deaktiviert, wird der Kassierer gefragt, ob er
  1. Die von Hand gesetzten Mandatsreferenzen behalten oder
  2. löschen will.
  Wählt der Kassierer "Löschen", so werden die Werte für alle Mitglieder und Kursteilnehmer auf null/leer String zurückgesetzt, nachdem der Kassierer nochmals auf die Folgen hingewiesen wurde. Wählt der Kassierer behalten, so wird keine Änderung an der DB vorgenommen. In beiden Fällen sind die Mandatsreferenz Felder nun wieder read-only.

Vorteile:

1. Kassierer, die sich mit dem Thema nicht auseindersetzen, können weiterhin halbwegs arbeiten (ob das so besser ist, als wenn sie gegen die Wand laufen, lasse ich mal dahin gestellt).
2. Hat ein Mensch nicht explizit auf die Hilfe durch JVerein verzichtet (vgl. Option b), so ist Heiners Anforderung erfüllt (Eindeutigkeit, keine Kollisionen), gleichzeitig könnten auch wir (mein Verein) so starten (vgl. Möglichkeit der Nutzung der externen Mitgliedsnummer).
3. Kassierer die Migrieren/andere Schemata nutzen, können dies (unter Beachtung der Gefahren) tun. (Ich sehe hier bspw. getrennte Einzüge für Kinder, die über ein Mandat abgedeckt sind, welches die Eltern erteilt haben - in diesem Fall kann die Mandatsreferenz gar nicht eindeutig sein)

Von einer teilweisen Editierbarkeit halt ich nichts - damit habe ich nicht genug flexibilität und kann mir trotzdem noch ins Bein schießen (bspw. für ein Mitglied ein neues Mandat mit verbrannter Mandatsreferenz erfassen (=> soweit die denn wirklich ihre Gültigkeit verlieren)).

[DIG]

Mit dem Vorschlag von Markus könnte ich mich anfreunden.

Heiner

Hallo Heiner,

Markus' Vorschlag finde auch ich grundsätzlich gut. Wenn in JVerein externe Mitgliedsnummern verwendet werden, dann sollte die (obligatorische und eindeutige) externe Mitgliedsnummer für die MandatsID herangezogen werden, sonst die interne ID von JVerein.

Viele Grüße,
Carsten

[matthias]

Anbei ein aktualisierter Patch - Änderungen gegenüber der Urversion:

- Build-System (build/build.xml) kann ab jetzt benutzt werden, inkl. Netbeans Projektdefinition
- Abhängigkeitskorrekt plugin.xml => Das Plugin braucht zwinged eine 2.5er Version von hibiscus und jameica
- Die Änderbarkeit wird nur aktiviert, wenn der User dies unter "Einstellungen" explizit auswählt (vgl. Screenshot)
- Geänderte Mandatsreferenzen können zurückgesetzt werden.

[2013-09-30] Der Testbuild ist auch aktualisiert: http://www.doppel-helix.eu/jverein-2.5. ... derbar.zip

[heiner]

Hallo,

ich habe mir jetzt noch etwas zur Lösung des Problems einfallen lassen:

Zu jedem Mitglied wird eine "Mandatsversion" gespeichert. Das ist eine Ganzzahl, die üblicherweise auf 1 steht. Sobald für ein Mitglied ein neues Mandat vorliegt, muss die Nummer um 1 erhöht werden. Bei der Lastschrift wird dann die Mandats-ID nach dem Schema (mitgliedsnummer-mandatsversion, z. B. 4711-1) gebildet.

Wird mit der nächsten Version ausgeliefert.

Heiner

[matthias]

Zu jedem Mitglied wird eine "Mandatsversion" gespeichert. Das ist eine Ganzzahl, die üblicherweise auf 1 steht. Sobald für ein Mitglied ein neues Mandat vorliegt, muss die Nummer um 1 erhöht werden. Bei der Lastschrift wird dann die Mandats-ID nach dem Schema (mitgliedsnummer-mandatsversion, z. B. 4711-1) gebildet.

Folgende Fälle/Herausforderungen sehe ich weiterhin:

• 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.
• Wechsel zu JVerein mit bestehendem Mitgliedsstamm, die Wahrscheinlichkeit, das die vergebenen Mandatsreferenzen ein anderes Schema benutzt ist hoch
• Berücksichtigung der externen Mitgliedsnummer (aktuell ist die interne ID ja nichtmal sichtbar, wenn "externe Migliedsnummer" aktiviert ist

[heiner]

Hallo 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.

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.

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.

Heiner