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:
- Ermögliche Benutzung der externen Mitgliedsnummer als Basis für die Mandatsreferenz und
- 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.
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:
- Die Mandatsreferenz muss eindeutig sein
- Die Mandatsreferenz darf nicht mit zukünfigen Defaults kollidieren können
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