JVerein

Liebe Community,

ich benutze JVerein jetzt schon seit einer Weile für einen kleinen Verein. Speziell für Nicht-Sepa-Vereine kommt mir JVerein bei der Verwaltung der Mitgliedsbeiträge umständlich vor. Ich habe mir deshalb ein alternatives Beitragsmodell überlegt, das ich hier vorstellen möchte. Es gibt schon eine prototypische Implementierung.

In dem Verein machen wir, wie gesagt, keinen SEPA-Bankeinzug, sondern jeder überweist seine Beiträge jährlich (oder auch nicht, falls das Geld mal knapp wird). Viele kleinere Vereine lösen dieses Problem mit einer Excel-Tabelle pro Jahr. Beispielsweise so:
Beim Durchgehen der Bankauszüge werden einfach die Kreuzchen entsprechend gesetzt.

Nun will ich den Aufwand mal mit JVerein vergleichen:

• Erst muss ein Abrechnungslauf erstellt werden. Nehmen wir an, dieser wird immer als jährliche Abrechnung erstellt.
• Dann wird die CSV von der Bank importiert.
• Im Allgemeinen stimmen bei SEPA-Vereinen die Soll-Buchungen und die tatsächlichen Ist-Buchungen nun überein und es kann eine 1:1 Zuordnung vorgenommen werden.
• Bei Nicht-SEPA-Vereinen gehen nun allerdings die Probleme los. Da einige Mitglieder generell "so bezahlen, wie sie wollen", stimmen Ist-Buchungen und Soll-Buchungen nicht überein.
• Szenario A: Das Mitglied überweist in größeren Beträgen, allerdings z.B. Februar 2018 - März 2019. Um das bei Abrechnungsläufen die jeweils im Januar terminiert sind, zuzuordnen, muss die Ist-Buchung in mehrere Splitbuchungen aufgeteilt werden. Jede einzelne Splitbuchung muss dann separat der jeweiligen Ist-Buchung zugeordnet werden.
• Szenario B: Das Mitglied überweist in kleineren Intervallen, also zB. 10€ pro Monat. Eine Soll-Buchung ist damit mehreren Ist-Buchungen zugeordnet.
• Szenario C: Ein Mitglied zahlt schon Beiträge für das Jahr 2020 im Voraus, wo noch gar kein Abrechnungslauf vorhanden ist. Dieser kann auch noch nicht angelegt werden, da ja im Laufe des Jahres 2019 noch weitere Mitglieder eintreten könnten, die ja sonst im Abrechnungslauf später nicht berücksichtigt werden würden.
• Szenario A ist zeitaufwändig. Szenario B wird gut abgebildet wird. Szenario C ist schlecht bis gar nicht abbildbar.
• Nachträglicher Eintritt: Tritt nun ein Mitglied im Mai 2019 ein, ist für ihn keine Ist-Buchung für Mai 2019 - Dezember 2019 angelegt. Das muss manuell für jedes neue Mitglied als Zusatzbuchung gemacht werden. Vergisst man diese Buchung anzulegen, kann es gut passieren, dass es nie mehr auffällt. Ab 2020 wird er dann jeden Januar korrekt mit abgebucht.

Ich fasse zusammen, dass die Komplexität der Überlegungen, die man momentan bei JVerein treffen muss, viel höher ist als bei der obigen Excel-Liste.

Den Arbeitsablauf versuche ich in einem neuen, alternativen Beitragsmodell zu verbessern. Ich habe das Feature jetzt erst mal "EasyBeitrag" genannt, was aber nur ein Entwicklungsname ist.

In der Buchungsliste gibt es eine neue Spalte "EasyMitglied":
Über das Menü im Rechtsklick kommt man zu der Zuordnung:
Anhand des Kontoinhabers wird automatisch das Mitglied geraten und im Dropdown vorausgewählt. Man kann erkennen, dass ich im Oktober 2019 in den Verein eingetreten bin, und die Beiträge schon bis Februar 2018 zugeordnet bzw. bezahlt wurden. Man kann nun per Klick die jeweiligen Monate abhaken. Es werden in einer späteren Version auch Kästen für die Zukunft angeboten. Durch drücken des "Auto-Assign" Knopfes werden automatisch so viele Häkchen gesetzt, wie nach jetzigem Beitragssatz des Mitglieds von der Ist-Buchung bezahlt werden können:
In der Rechnung rechts wird ebenfalls eine der momentane Beitragssatz zu Grunde gelegt. Man kann also sehen, ob man genug Haken ausgewählt hat. Werden mehr Haken ausgewählt, als nach Beitragssatz bezahlt werden könnten, kann momentan trotzdem gespeichert werden. Später soll in diesem Fall noch eine "Bist du wirklich sicher?"-Ebene eingebaut werden, wenn die Differenz nicht null ist.

In einem anderen Bereich, kann man dann nachvollziehen, bei wem noch wie viele Monatsbeiträge ausständig sind:



Die Anzahl der Soll-Beiträge wird als Anzahl der Monate zwischen Eintrittsdatum und Austrittsdatum (bzw. zwischen Eintrittsdatum und Heute) berechnet.

Soweit was ich mir bisher an Gedanken gemacht habe.

Ich fasse nochmal zusammen, was ich nun als Vorteile sehe:

• Es müssen keine Abrechnungsläufe mehr erstellt werden.
• Ein Mitglied kann jederzeit eingefügt werden, ohne dass noch eine Buchung angelegt werden muss.
• Es kann nicht mehr "vergessen" werden ein Mitglied abzurechnen.
• Seltsame Zahlungsrythmen sind einfach abzubilden.
• Der Benutzer muss sich nicht für ein Zahlungsmuster (jährlich/monatlich/...) entscheiden, bzw. es muss nicht als "Zahlungstermin" bei jedem Nutzer einzeln gepflegt werden.
• Der Arbeitsablauf ist freier und dem Excel-Flow sehr ähnlich.
• Die Reihenfolge der Arbeitsschritte ist egal. Oft wenn ich JVerein (mit dem bisherigen Modell) starte, muss ich überlegen in welcher Reihenfolge ich Arbeitsschritte mache. Fange ich beispielsweise an einen Abrechnungslauf zu erstellen, importiere Kontobewegungen der Sparkasse und fange an die Buchungen den Mitgliedern zuzuordnen. Mitten dabei fällt mir auf, dass ich vergessen habe, das Mitglied, das im Dezember eingetreten ist, hinzuzufügen. Dieses Mitglied hätte natürlich im Abrechnungslauf berücksichtigt werden müssen. Nun muss ich den Abrechnungslauf nochmal löschen, neu erstellen und mit der Zuordnung von vorn anfangen. Bei dem neuen Modell ist das nicht mehr relevant, da es keine Abrechnungsläufe gibt. Wird ein Mitglied nachträglich hinzugefügt, zeigt die EasyBeitragsliste dieses Mitglied sofort an und berechnet auch die Soll-Monatsbeiträge richtig.

Falls jemand die Neuerung testen mag, findet man sie in meinem Github-Repository:

https://github.com/lemoer/jverein

Intern wird keine Datenbankstruktur verändert, sondern nur eine neue, zusätzliche Tabelle hinzugefügt.

Ich bin auf euer Feedback gespannt.

Viele Grüße
Leo

Hallo Leo,

es gibt keinen Grund, einen Abrechnungslauf zu löschen, weil ein Mitglied noch nicht erfasst war. Dafür gibt es den Modus "eingetretene Mitglieder", damit können nur die Mitglieder abgerechnet werden, die nach einem vorgegebenen Datum erfasst wurden. Ein nachträglicher Eintritt ist also kein Problem. Szenario C auch nicht. Das einzige, was tatsächlich mühsam ist, ist Szenario A. Aber gerade bei kleinen Vereinen gehe ich davon aus, dass es nur eine Handvoll Fälle im Jahr gibt.

Es gibt zwei Fälle, mit denen Deine Variante nicht gut umgehen kann: Zahlungen, die keine Vielfachen von Monatsbeiträgen sind, und Beitragsänderungen.

Generell fände ich es wünschenswert, die Implikationen für alle, die das Verfahren nicht nutzen wollen (ich vermute, dass das die Mehrheit der Nutzer ist), möglichst gering zu halten. Insbesondere muss die zusätzliche Spalte in der Buchungsliste deaktivierbar sein. Sonst werden für jede Zeile eine überflüssige Datenbankabfrage gestartet und ein GUI-Element erzeugt, was für kleine Vereine nicht so schlimm ist, aber bei großen Vereinen Performance und Speicherverbrauch unnötig beeinträchtigt.

Viele Grüße
Reinhard

Für die Problematik fällt mir eine einfacher Lösung ein:

1. Rechnungsläufe bei Fälligkeit wie gehabt
2. Zahlungseingänge werden einem Mitglied zugeordnet
3. Für Mahnungen werden dann die Fälligkeiten und Zahlungen aufsummiert

Rechtlich muss man dafür voraussetzen, dass jede Zahlung der ältesten Forderung zugeordnet werden kann - könnte für die Frage der Verjährung wichtig werden, wenn ein weiter zurückliegender Beitrag eingefordert werden muss und die Beiträge der Folgejahre jeweils bezahlt wurden.

Alternativ könnte man das auch so abändern, dass Überzahlungen einer Fälligkeit automatisch auf die nächsten Fälligkeit aufgeteilt werden.