Mitglieder mit CiviCRM verwalten

Ein Verein möchte wissen, wer Mitglied ist, seit wann die Mitgliedschaft besteht, welcher Beitrag vereinbart wurde und ob dieser Beitrag bezahlt ist. Er möchte neue Mitglieder aufnehmen, Kündigungen nachvollziehen und ehemalige Mitglieder nicht einfach aus der Datenbank löschen. Vielleicht sollen Beiträge per SEPA eingezogen werden. Vielleicht bezahlt auch einmal eine andere Person den Beitrag für ein Mitglied. Im Folgenden wird dazu angeleitet, CiviCRM zur Bearbeitung solcher Aufgaben zu konfigurieren.

Inhaltsverzeichnis

1. Ziel dieser Anleitung
2. Das Denkmodell: Was verwalten wir eigentlich?
3. Die beteiligten Komponenten
4. Anleitung
5. Mit der Mitgliederverwaltung arbeiten

1. Ziel dieser Anleitung

Mitgliederverwaltung klingt zunächst nach einer einfachen Mitgliederliste.

In einer Tabellenkalkulation könnte eine Zeile ungefähr so aussehen:

Name	Eintrittsdatum	Status	Beitrag	Zahlungsweise	Austrittsdatum
Anna Müller	01.09.2026	Mitglied	36 €	Überweisung

Für einen kleinen Verein kann eine solche Tabelle lange funktionieren. Sie verbirgt aber mehrere unterschiedliche Sachverhalte in einer einzigen Zeile.

Anna Müller ist zunächst eine Person. Sie besitzt eine Mitgliedschaft. Für diese Mitgliedschaft wurde ein Beitrag vereinbart. Der Beitrag kann zu bestimmten Zeitpunkten fällig werden. Davon wiederum zu unterscheiden ist, ob und wann tatsächlich Geld eingegangen ist. Schließlich kann dieses Geld per Überweisung, bar oder später per SEPA-Lastschrift gezahlt worden sein.

Solange alles glatt läuft, fällt die Unterscheidung von Person, Mitgliedschaft, Beitrag, Zahlungsart und Status der Zahlung kaum auf. Interessant wird eine solche Unterscheidung bei den Ausnahmen:

Ein Mitglied hat noch nicht bezahlt, ist aber trotzdem weiterhin Mitglied.
Ein Mitglied hat bereits gekündigt, die Kündigung wird aber erst zum Ende eines bestimmten Zeitraums wirksam.
Eine Person zahlt freiwillig mehr als den vorgesehenen Mindestbeitrag.
Eine Person zahlt den Beitrag für eine andere Person – zum Beispiel im Falle von Ehepaaren.
Ein Mitglied zahlt monatlich, ein anderes jährlich.
Ein Verein kennt statt eines Jahresbeitrags einen einmaligen Mitgliedsbeitrag.
Ein ehemaliges Mitglied bleibt als Spender oder Ansprechpartner im CRM erhalten.

Eine Mitgliederverwaltung muss solche Fälle unterscheiden können.

Deshalb unterscheidet CiviCRM den Kontakt von dessen Mitgliedschaft, dessen Beitragspflicht, der Zahlung und dem Zahlungsweg als verschiedene Dinge. Genau darin liegt die Stärke von CiviCRM – und zugleich der Grund, weshalb die Einrichtung zunächst komplizierter wirkt als eine einfache Mitgliederliste.

Am Ende dieser Anleitung soll eine CiviCRM-Instanz so eingerichtet sein, dass ein typischer deutscher Verein seine Mitgliedschaften strukturiert verwalten kann.

Dabei wollen wir insbesondere erreichen:

Personen und Organisationen bleiben normale CiviCRM-Kontakte.
Die Mitgliedschaft wird als eigenständige Sache geführt. Denn ein Kontakt kann ja in ein und demselben Verein mehrere Arten von Mitgliedschaften besitzen.
Beginn, Ende und Status jeder Mitgliedschaft werden nachvollziehbar gespeichert.
Eine Mitgliedsnummer kann automatisch vergeben werden.
Kündigungseingang und tatsächliches Mitgliedschaftsende bleiben unterscheidbar.
Beiträge können monatlich, quartalsweise, jährlich oder einmalig vereinbart werden.
Die Beitragshöhe kann pro Mitgliedschaft festgelegt werden.
Tatsächliche Zahlungen bleiben von der Beitragspflicht getrennt.
Überweisung, Barzahlung und SEPA o.ä. können als Zahlungswege unterschieden werden.
Ausbleibende Zahlungen beenden nicht automatisch die Mitgliedschaft.
Eine bereits gekündigte Mitgliedschaft kann bis zu ihrem tatsächlichen Ende weiterhin als aktiv gelten.
CiviSEPA kann später ergänzt werden, ohne das Datenmodell neu aufzubauen.

2. Das Denkmodell: Was verwalten wir eigentlich?

Bevor wir CiviMember konfigurieren, sollten wir uns ansehen, welche Dinge in unserem Modell vorkommen.

2.1 Der Kontakt

Der Kontakt beantwortet die Frage: Wer ist das?

Bei einer natürlichen Person gehören hierher beispielsweise

Vorname und Nachname
Anschrift
Telefonnummern
E-Mail-Adressen
Geburtsdatum
Kommunikationspräferenzen

Eine Person wird nicht deshalb zu einem Kontakt, weil sie Mitglied wird oder austritt. Wenn Anna Müller aus dem Verein austritt, bleibt Anna Müller derselbe Kontakt. Das ist wichtig, weil sie vorher oder auch später noch beispielsweise

Spenderin
Teilnehmerin einer Veranstaltung
Ansprechpartnerin einer Schule oder
ehemalige Funktionsträgerin

sein kann.

Die Mitgliedschaft ist deshalb keine Eigenschaft, die wir einfach mit einem Feld Status = Mitglied am Kontakt abbilden.

2.2 Die Mitgliedschaft

Die Mitgliedschaft beantwortet eine andere Frage: In welchem Mitgliedschaftsverhältnis steht dieser Kontakt zur Organisation?

Dafür gibt es in CiviCRM eine eigene Entität: die Mitgliedschaft (englisch „Membership“).

Eine Mitgliedschaft (Membership) kann beispielsweise enthalten:

Mitgliedschaftstyp
Beitrittsdatum
Startdatum
Enddatum
Status
Mitgliedsnummer
Kündigungsinformationen
Angaben zur Beitragsvereinbarung

Damit können auch mehrere Mitgliedschaften desselben Kontakts historisch nachvollzogen werden.

2.3 Die Beitragspflicht

Nun kommt ein zweiter Sachverhalt hinzu: Was soll dieses Mitglied zahlen?

Die Art des Beitrags, die Höhe des Beitrags und der Zahlungsrythmus des Beitrags können dabei von Mitgliedschaft zu Mitgliedschaft variieren. Deshalb ist die Beitragsvereinbarung eine Eigenschaft jeder einzelnen Mitgliedschaft. Alle Personen können denselben Mitgliedschaftstyp besitzen (z.B. Fördermitgliedschaft) und trotzdem unterschiedliche Beitragsvereinbarungen haben.

2.4 Die Zahlung

Die nächste Frage lautet: Was wurde tatsächlich bezahlt?

Eine Zahlung ist in CiviCRM eine Zuwendung (englisch „Contribution“) und technisch gesehen ein eigener Datensatz. Wenn ein Mitglied jährlich 60 Euro zahlen soll, unterscheiden wir deshalb zwei Aussagen:

Soll: 60 € Jahresbeitrag
Ist: 60 € am 14.03.2027 eingegangen

Diese Trennung ist elementar. Denn es können daraus ganz unterschiedliche Fälle entstehen. Gezahlt werden sollen 60 €, aber gezahlt wurden in einem Fall 0 €, in einem anderen Fall nur 30€, in einem dritten Fall vielleicht sogar 100 €. Keine dieser Situationen sagt für sich allein aus, ob die Person noch Mitglied ist.

2.5 Der Zahlungsweg

Schließlich gibt es noch die Frage: Wie wurde bezahlt?

Mögliche Zahlungswege sind beispielsweise

Überweisung
Barzahlung
SEPA-Lastschrift

Der Mitgliedsbeitrag ist für den Verein eine Art von Zuwendung (im Unterschied z.B. zu einer Spende), der Zahlungsweg eine Zahlungsmethode. Diese Unterscheidung zwischen Finanzart und Zahlungsart wird später bei der Konfiguration noch wichtig.

3. Die beteiligten Komponenten

In CiviCRM gibt es nicht „die eine Mitgliederverwaltungsfunktion“. Es handelt sich vielmehr um ein Zusammenspiel mehrerer CiviCRM-Komponenten, die vereinfacht so aussieht:

Kontakt
Mitgliedschaft (Mitgliedsnummer, Status, Beitragsvereinbarung, Kündigung)
Project60 Membership (Beitrags- und Zahlungsverknüpfung)
CiviContribute (tatsächliche Zahlungen)
Optional: CiviSEPA (Lastschrifteinzug)

3.1 CiviMember: Die Mitgliedschaft selbst

CiviMember ist die CiviCRM-Komponente für Mitgliedschaften. Sie gestattet es, einem Kontakt ein oder mehrere Mitgliedschaftsverhältnisse zuzuordnen.

CiviMember kennt außerdem:

Mitgliedschaftsarten (Membership Types),
Regeln zur Setzung eines Mitgliedschaftsstatus abhängig vom Zeitpunkt (Membership Status Rules)
Start- und Enddaten,
Verlängerungen,
Verbindungen zu Zuwendungen (Contributions).

Damit lässt sich das Mitgliedschaftsverhältnis selbst bereits mit CiviMember abbilden.

Für unseren Anwendungsfall ist dabei wichtig, zwischen zwei verschiedenen Vorstellungen von Mitgliedschaft zu unterscheiden.

CiviMember kann Mitgliedschaften mit einer festgelegten oder regelmäßig zu verlängernden Laufzeit verwalten. Es kann aber ebenso eine Mitgliedschaft führen, für die bei der Aufnahme kein zukünftiges Enddatum feststeht. Für unsere Anleitung verwenden wir diese zweite Möglichkeit.

Eine Person wird nach ihrer Aufnahme Mitglied und bleibt es, bis ein Beendigungsgrund eintritt. Erst wenn ein solcher Grund feststeht, wird das tatsächliche Enddatum der Mitgliedschaft eingetragen.

Die Mitgliedschaft wird deshalb nicht jährlich verlängert. Auch der Eingang oder das Ausbleiben eines Mitgliedsbeitrags entscheidet nicht darüber, ob die Mitgliedschaft fortbesteht.

Exkurs: Mitgliedschaft und Beitragszahlung sind zwei verschiedene Dinge

Gerade im Vereinskontext ist es wichtig, Mitgliedschaft und Beitragszahlung nicht miteinander gleichzusetzen.

Eine Person kann einen offenen Beitrag haben und trotzdem weiterhin Mitglied sein. Ebenso kann eine Kündigung bereits eingegangen sein, obwohl die Mitgliedschaft erst zu einem späteren Zeitpunkt endet.

Für unser Modell bedeutet das beispielsweise:

Kündigung eingegangen: 15.05.
Ende der Mitgliedschaft: 31.07.

Bis einschließlich 31. Juli besteht die Mitgliedschaft weiter.

CiviMember kann dieses fortbestehende Mitgliedschaftsverhältnis grundsätzlich selbst abbilden: Die Membership besitzt zunächst kein vorausberechnetes Enddatum. Ein Enddatum wird erst eingetragen, wenn das Ende der Mitgliedschaft feststeht.

Damit ist aber noch nicht alles gelöst. Für die praktische Vereinsarbeit benötigen wir zusätzliche Informationen und Verknüpfungen, die CiviMember allein nicht bereitstellt.

3.2 Project60 Membership: Mitgliedschaft und Beiträge miteinander verknüpfen

Die Erweiterung Project60 Membership setzt auf CiviMember auf. Sie ersetzt die dort geführte Mitgliedschaft nicht und wird auch nicht benötigt, um eine unbefristet fortbestehende Mitgliedschaft überhaupt erst möglich zu machen.

Project60 ergänzt vielmehr Funktionen für die Verknüpfung der Mitgliedschaft mit Beitrags- und Zahlungsvorgängen sowie zusätzliche Angaben, die für die Vereinsverwaltung nützlich sind.

Dazu gehören beispielsweise:

Mitgliedsnummern,
Kündigungsdatum,
Kündigungsgrund,
erwarteter Jahresbeitrag,
Zahlungsfrequenz,
wiederkehrender Zahlungsvertrag,
Rate je Zahlungszyklus,
Fremdzahler

Damit bleiben zwei Ebenen voneinander unterscheidbar:

CiviMember beschreibt das Mitgliedschaftsverhältnis.
Project60 ergänzt Informationen und Mechanismen zur Beitrags- und Zahlungsverknüpfung.

Die tatsächlichen Zahlungen selbst werden in CiviContribute geführt.

3.3 CiviContribute: Finanzvorgänge erfassen

CiviContribute verwaltet Zuwendungen und Zahlungen. Hier landen beispielsweise

Mitgliedsbeiträge
Spenden
Teilnahmegebühren

In einer CiviCRM-Standardinstallation sind bereits bestimmte Zuwendungsarten vordefiniert, darunter Member Dues (Mitgliedsbeiträge) und Donation (Spenden). Die von CiviCRM intern verwendeten Namen lassen wir bestehen, um unerwartete Wechselwirkungen innerhalb der Software zu vermeiden. Wir ändern lediglich die sichtbaren deutschen Bezeichnungen. Das ist wichtig, weil es sehr verführerisch ist, neue Finanzarten mit den Namen „Mitgliedsbeitrag“ oder „Spende“ anzulegen. Denn dann existieren anschließend zwei verschiedene Finanzarten, die in der Oberfläche gleich heißen.

3.4 CiviSEPA: Lastschrift als möglicher Zahlungsweg

Im Rahmen dieser Anleitung richten wir noch nicht die Möglichkeit ein, Zahlungen per Lastschrift zu erhalten. Jedoch sei hier kurz erwähnt, dass ein von Project60 Membership vorgesehener Weg darin besteht, die Erweiterung CiviSEPA zur Verwaltung und Einreichung von SEPA Lastschriftmandaten zu verwenden. Dazu verwaltet CiviSEPA Daten wie diese:

IBAN
Mandat
Mandatsreferenz
Lastschriftgruppen
wiederkehrende Einzüge.

Wir bauen unsere Mitgliederverwaltung deshalb so auf, dass CiviSEPA später ergänzt werden kann.

Ein Verein kann aber zunächst genauso gut ausschließlich mit Überweisungen arbeiten.

4. Anleitung

Für den in dieser Anleitung beschriebenen Pfad benötigen wir:

CiviMember als aktivierte Komponente
CiviContribute als aktivierte Komponente
Project60 Membership als zusätzlich installierte Erweiterung
- Administrative Zugriffsrechte auf
- Custom Fields,
- Membership Types,
- Membership Status Rules,
- Finanzarten,
- Zahlungsarten,
- Project60-Konfiguration.
Die Erweiterung CiviSEPA ist keine Voraussetzung.

Wo wird was konfiguriert?

Die Einrichtung der Mitgliederverwaltung verteilt sich in CiviCRM auf mehrere Konfigurationsoberflächen. Das liegt daran, dass Mitgliedschaft, Zahlungen, zusätzliche Datenfelder und die von Project60 bereitgestellten Funktionen technisch verschiedenen Komponenten zugeordnet sind.

Die wichtigsten Stellen, die wir in dieser Anleitung benötigen, sind:

Aufgabe	Navigation
Komponenten aktivieren	Administration → Systemeinstellungen → Komponenten
Erweiterungen installieren	Administration → Systemeinstellungen → Erweiterungen
Zahlungsmethoden bearbeiten	Administration → CiviContribute → Zahlungsmethoden
Zuwendungsarten bearbeiten	Administration → CiviContribute → Zuwendungsarten
Mitgliedschaftstypen bearbeiten	Administration → CiviMember → Mitgliedstypen
Mitgliedsstatusregeln bearbeiten	Administration → CiviMember → Mitgliedsstatusregeln
Benutzerdefinierte Felder anlegen	Administration → Daten und Anzeigen anpassen → Benutzerdefinierte Felder
Project60 Membership konfigurieren	direkter Aufruf: `https://sub.domain.xy/civicrm/admin/setting/membership`

Die Project60-Konfiguration bildet dabei eine Besonderheit: Die Erweiterung stellt eine eigene Konfigurationsoberfläche bereit, trägt diese jedoch nicht zuverlässig in das CiviCRM-Navigationsmenü ein. Auf diese Oberfläche greifen wir deshalb später über ihren direkten Pfad zu.

Schritt 1: Zahlungsarten aufräumen

Bevor wir neue Strukturen anlegen, sehen wir uns die Zahlungsarten an. Eine Zahlungsart beschreibt: Wie kam das Geld zu uns?

Öffnen Sie die Einstellungen unter Administration → CiviContribute → Zahlungsmethoden. Auf der Seite Zahlungsmethoden verwaltet CiviCRM die möglichen Wege, auf denen eine Zahlung eingehen kann.

Für einen typischen Förderverein genügen zunächst „Barzahlung“ und „Überweisung“. Später kommt gegebenenfalls noch „SEPA-Lastschrift“ hinzu.

CiviCRM bringt bereits verschiedene Zahlungsarten mit, die wir möglicherweise nicht benötigen. Wir löschen diese Werte ausdrücklich nicht, weil das an anderer Stelle innerhalb von CiviCRM zu unerwünschten Wechselwirkungen führen kann. Stattdessen deaktivieren wir unbenutzte Zahlungsarten.

Der Grund ist einfach: Ein ausgeblendeter Core-Wert stört nicht. Ein gelöschter Core-Wert kann dagegen bestehende Referenzen oder Erweiterungen beschädigen.

Konfigurieren Sie wie folgt:

interner Wert	Anzeige
Cash	Barzahlung
EFT	Überweisung

Schritt 2: Finanzarten prüfen

Jetzt betrachten wir einen anderen Begriff: Zuwendungsart

Öffnen Sie die Einstellungen unter Administration → CiviContribute → Zuwendungsarten. Auf dieser Seite wird festgelegt, welcher Art ein finanzieller Vorgang ist.

Dabei ist die Zuwendungsart von der zuvor bearbeiteten Zahlungsart zu unterscheiden: Die Zuwendungsart beschreibt, was für Geld eingeht; die Zahlungsart beschreibt, wie das Geld eingeht.

Für Mitgliedsbeiträge verwenden wir die bereits vorhandene Core-Finanzart „Member Dues“ (Mitgliedsbeiträge). Falls die englische Bezeichnung angezeigt wird, ändern Sie nur die Beschriftung in „Mitgliedsbeitrag“.

Für Spenden verwenden wir „Donation“ und beschriften ggf. mit dem sichtbaren Label „Spende“.

Wir legen keine zusätzlichen gleichnamigen Zuwendungsarten an. Die Zuwendungsart Mitgliedsbeitrag werden wir später in Project60 dem Mitgliedschaftstyp Fördermitglied zuordnen.

Schritt 3: Den Mitgliedschaftstyp anlegen

Nun benötigen wir einen oder mehrere Mitgliedschaftstypen (Membership Types). Öffnen Sie die Einstellungen unter Administration → CiviMember → Mitgliedstypen.

Auf der Seite Mitgliedstypen wird festgelegt, welche Arten von Mitgliedschaften eine Organisation grundsätzlich kennt. Für das hier beschriebene Beispiel eines Fördervereins legen wir einen Mitgliedschaftstyp mit der Bezeichnung „Fördermitglied“ an.

Der Mitgliedschaftstyp beschreibt das Mitgliedschaftsverhältnis selbst. Er beschreibt ausdrücklich nicht die Zahlungsweise. Deshalb legen wir keine Mitgliedschaftstypen wie

Jahresmitglied,
Monatsmitglied,
SEPA-Mitglied oder
Barzahler

an.

Ordnen Sie dem Mitgliedschaftstyp als Mitgliedsorganisation den Verein zu, dessen Mitgliedschaften verwaltet werden sollen.

Als Zuwendungsart wählen Sie die bereits vorhandene Zuwendungsart Mitgliedsbeitrag beziehungsweise den zuvor entsprechend beschrifteten Core-Eintrag Member Dues. Diese Zuordnung am Mitgliedschaftstyp ist die CiviMember-Konfiguration. Project60 benötigt zusätzlich ein eigenes Financial Type Mapping, das wir in Schritt 8 einrichten.

Eine feste Beitragshöhe tragen wir am Mitgliedschaftstyp nicht ein. Die konkrete Beitragshöhe und der Zahlungsrhythmus sollen Eigenschaften der jeweiligen Mitgliedschaft sein. Zwei Personen können also denselben Mitgliedschaftstyp „Fördermitglied“ besitzen und dennoch unterschiedlich hohe Beiträge oder unterschiedliche Zahlungsrhythmen vereinbart haben.

Die Mitgliedschaft unseres Beispielvereins besitzt keine regelmäßig zu erneuernde Laufzeit. Nach der Aufnahme besteht sie fort, bis ein in der Satzung vorgesehener Grund für ihre Beendigung eintritt.

Wählen Sie deshalb bei der Dauer des Mitgliedschaftstyps die CiviCRM-Einstellung Lifetime.

Die Bezeichnung „Lifetime“ ist dabei etwas missverständlich. Sie bedeutet in unserem Modell nicht, dass die Mitgliedschaft zwingend bis zum Tod bestehen muss. Wir verwenden diese Einstellung technisch für eine zunächst unbefristete Mitgliedschaft: Beim Eintritt wird kein zukünftiges Enddatum vorausberechnet.

Das tatsächliche Enddatum wird erst eingetragen, wenn ein Grund für die Beendigung der Mitgliedschaft feststeht. Das kann beispielsweise das Ende des Schuljahres nach einer Kündigung, das Ende des Schulbesuchs oder der Tod des Mitglieds sein.

Eine jährliche Verlängerung der Mitgliedschaft findet deshalb nicht statt. Auch die Zahlung eines Beitrags oder einer Spende verlängert die Mitgliedschaft nicht.

Schritt 4: Die Beitragsvereinbarung modellieren

CiviMember kennt die Mitgliedschaft als eigenes Objekt, enthält aber nicht alle Angaben, die wir für unsere konkrete Form der Mitgliedschaft benötigen. Diese Angaben ergänzen wir als benutzerdefinierte Felder.

CiviCRM organisiert benutzerdefinierte Felder in Feldgruppen. Eine Feldgruppe ist zunächst nur ein Behälter für mehrere zusammengehörige Felder. Wir legen deshalb zuerst eine Feldgruppe für unseren Mitgliedschaftstyp an und füllen sie anschließend mit den benötigten Feldern.

Öffnen Sie Administration → Daten und Anzeigen anpassen → Benutzerdefinierte Felder.

Sie sehen dort die bereits vorhandenen Feldgruppen. Wählen Sie die Schaltfläche „Gruppe benutzerdefinierter Felder hinzufügen“

Geben Sie der neuen Feldgruppe die Bezeichnung „Mitgliedschaft Förderverein“. Wählen Sie bei Verwendet für beziehungsweise Used for „Mitgliedschaften“. CiviCRM bietet Ihnen dann dort unter Mitgliedschaften anschließend die Möglichkeit, die Feldgruppe entweder für alle Mitgliedschaften oder nur für einen bestimmten Mitgliedschaftstyp zu verwenden. Wählen Sie hier den zuvor angelegten Mitgliedschaftstyp „Fördermitglied“. Speichern Sie die Feldgruppe.

Damit haben wir noch keine neuen Eingabefelder angelegt, sondern wir haben nur festgelegt, dass die folgenden zusätzlichen Angaben zu Mitgliedschaften des Typs „Fördermitglied“ gehören.

Der Unterschied ist wichtig. Wenn später beispielsweise zusätzlich eine Ehrenmitgliedschaft oder eine institutionelle Mitgliedschaft eingerichtet wird, erscheinen dort nicht automatisch die besonderen Felder für Fördermitglieder.

Öffnen Sie nun bei der Feldgruppe Mitgliedschaft Förderverein die Funktion Benutzerdefinierte Felder anzeigen und bearbeiten. Auf dieser Seite legen wir die einzelnen Felder an.

Beitragsrhythmus

Wählen Sie Benutzerdefiniertes Feld hinzufügen.

Geben Sie als Bezeichnung ein: „Beitragsrhythmus“

Wählen Sie als Datentyp Alphanumerisch und als Eingabeart eine Auswahlliste.

Legen Sie anschließend folgende Auswahlmöglichkeiten an:

monatlich
quartalsweise
jährlich
einmalig
beitragsfrei

Speichern Sie das Feld.

Der Beitragsrhythmus beschreibt, in welchem zeitlichen Abstand der vereinbarte Beitrag zu leisten ist.

Beitrag je Intervall

Bleiben Sie in der Feldgruppe Mitgliedschaft Förderverein und wählen Sie erneut Benutzerdefiniertes Feld hinzufügen.

Legen Sie das Feld „Beitrag je Intervall“ als Feld für einen Geldbetrag an und speichern Sie es.

Hier wird später der Betrag eingetragen, der für den gewählten Beitragsrhythmus vereinbart wurde.

Beispielsweise:

5 € monatlich
36 € jährlich

Erst die Kombination aus Beitragsrhythmus und Beitrag je Intervall beschreibt also die konkrete Beitragsvereinbarung.

Beitragspflicht ab

Legen Sie in derselben Feldgruppe ein weiteres benutzerdefiniertes Feld an: Beitragspflicht ab

Wählen Sie als Datentyp Datum.

Hier kann festgehalten werden, ab welchem Zeitpunkt die Beitragsvereinbarung gilt.

Beitragspflicht bis

Legen Sie anschließend ein weiteres Datumsfeld an: Beitragspflicht bis

Dieses Feld kann bei einer konkreten Mitgliedschaft leer bleiben, wenn die Beitragspflicht kein gesondertes Ende besitzt.

Nach diesem Schritt enthält eine Mitgliedschaft des Typs Fördermitglied zusätzlich die Angaben:

Beitragsrhythmus
Beitrag je Intervall
Beitragspflicht ab
Beitragspflicht bis

Andere Mitgliedschaftstypen bleiben davon unberührt.

Schritt 5: Aufnahme und Leistungsbezug

Neben der Beitragsvereinbarung können zu einer Mitgliedschaft weitere Angaben gehören, die ihren organisatorischen Verlauf beschreiben. Auch diese Informationen speichern wir an der konkreten Mitgliedschaft und nicht am Kontakt.

Öffnen Sie dazu unter Administration → Daten und Anzeigen anpassen → Benutzerdefinierte Felder erneut die Feldgruppe Mitgliedschaft Förderverein und wählen Sie Benutzerdefinierte Felder anzeigen und bearbeiten.

Wir ergänzen die bereits vorhandene Feldgruppe um weitere Felder.

Beitrittsantrag am

Wählen Sie Benutzerdefiniertes Feld hinzufügen und legen Sie ein Feld mit der Bezeichnung Beitrittsantrag am an.

Wählen Sie als Datentyp Datum und speichern Sie das Feld.

Dieses Datum hält fest, wann der Antrag auf Mitgliedschaft beim Verein eingegangen ist. Es ist nicht notwendigerweise mit dem Beginn der Mitgliedschaft identisch. Sieht die Satzung beispielsweise vor, dass über die Aufnahme zunächst entschieden werden muss, können Antrag und tatsächlicher Beginn der Mitgliedschaft zeitlich auseinanderliegen.

Aufnahme beschlossen am

Legen Sie ein weiteres Datumsfeld mit der Bezeichnung Aufnahme beschlossen am an.

Hier kann festgehalten werden, wann die Aufnahme durch das dafür zuständige Vereinsorgan beschlossen wurde.

Damit lassen sich drei verschiedene Zeitpunkte auseinanderhalten:

Eingang des Beitrittsantrags,
Entscheidung über die Aufnahme,
tatsächlicher Beginn der Mitgliedschaft.

Diese Unterscheidung ist nicht für jeden Verein erforderlich. Sie ist aber dann sinnvoll, wenn das Aufnahmeverfahren laut Satzung mehrere Schritte kennt.

Ende des Leistungsbezugs

Bei manchen Vereinen hängt der Anlass für eine Mitgliedschaft mit einem bestimmten Lebensabschnitt oder Leistungsbezug zusammen.

Bei einem Schulförderverein ist dies beispielsweise häufig der Schulbesuch eines Kindes.

Legen Sie für unseren Beispielfall deshalb ein weiteres Datumsfeld an, zum Beispiel

Schulbesuch des Kindes endet am

Hier kann festgehalten werden, wann der unmittelbare Bezug zur Schule voraussichtlich oder tatsächlich endet.

Dieses Datum ist wiederum nicht automatisch das Enddatum der Mitgliedschaft. Eine Person kann auch nach dem Schulende ihres Kindes Mitglied des Fördervereins bleiben. Endet nach der Satzung mit dem Schulbesuch zugleich die Mitgliedschaft, wird dieses Datum zum Anlass genommen, das tatsächliche Enddatum der Mitgliedschaft einzutragen. Hat das Mitglied dagegen die Fortführung der Mitgliedschaft beantragt, bleibt die Membership ohne Enddatum bestehen.

Mitgliedschaft nach Ende des Leistungsbezugs fortführen

Legen Sie deshalb zusätzlich ein Feld an, zum Beispiel mit der Bezeichnung „Mitgliedschaft nach Schulende fortführen“.

Verwenden Sie dafür ein Ja/Nein-Feld.

Damit kann ausdrücklich festgehalten werden, dass die Mitgliedschaft auch nach dem Ende des Schulbesuchs weiterbestehen soll.

Die beiden zuletzt genannten Felder sind keine allgemein notwendigen Bestandteile einer Mitgliederverwaltung. Sie ergeben sich aus unserem Beispiel eines Schulfördervereins. Bei einem anderen Verein können diese Felder entfallen oder durch Angaben ersetzt werden, die dessen organisatorischem Zusammenhang entsprechen.

Nach diesem Schritt enthält die Feldgruppe Mitgliedschaft Förderverein neben den Angaben zur Beitragsvereinbarung nun auch Informationen über Antrag, Aufnahme und gegebenenfalls das Ende des mit der Mitgliedschaft verbundenen Leistungsbezugs.

Schritt 6: Mitgliedsnummer einrichten

Project60 Membership kann einer Mitgliedschaft automatisch eine Mitgliedsnummer zuweisen. Dafür benötigt die Erweiterung zunächst ein benutzerdefiniertes Feld, in dem diese Nummer gespeichert werden kann.

Öffnen Sie unter Administration → Daten und Anzeigen anpassen → Benutzerdefinierte Felder erneut die Feldgruppe Mitgliedschaft Förderverein und wählen Sie Benutzerdefinierte Felder anzeigen und bearbeiten.

Wählen Sie Benutzerdefiniertes Feld hinzufügen und legen Sie ein neues Feld an.

Verwenden Sie folgende Einstellungen:

Bezeichnung: Mitgliedsnummer
Datentyp: Alphanumerisch
Eingabeart: Text
Durchsuchbar: ja

Speichern Sie das Feld.

Damit haben wir zunächst nur einen Speicherort für die Mitgliedsnummer geschaffen. CiviCRM weiß noch nicht, dass dieses Feld von Project60 als Mitgliedsnummer verwendet werden soll. Diese Zuordnung nehmen wir später auf der Konfigurationsseite von Project60 Membership vor.

Dort können wir außerdem festlegen, nach welchem Muster neue Mitgliedsnummern erzeugt werden sollen. Für unsere Anleitung verwenden wir beispielsweise das Muster M-{mid+10000}. Dadurch können Mitgliedsnummern entstehen wie z.B.

M-10001
M-10002
M-10003

Das genaue Nummernschema ist keine Vorgabe von CiviCRM oder Project60. Ein Verein kann stattdessen ein eigenes Präfix oder eine andere Systematik verwenden.

Wichtig ist an dieser Stelle vor allem das Prinzip: Die Feldgruppe stellt das Feld bereit.
Project60 Membership bekommt anschließend mitgeteilt, dass genau dieses Feld die Funktion Mitgliedsnummer übernehmen soll.

Schritt 7: Kündigungen richtig abbilden

Für die Bearbeitung von Kündigungen benötigen wir zwei weitere benutzerdefinierte Felder an der konkreten Mitgliedschaft: das Datum, an dem die Kündigung eingegangen ist, und einen Kündigungsgrund.

Wählen Sie Benutzerdefiniertes Feld hinzufügen und legen Sie zunächst ein Datumsfeld an.

Bezeichnung: Kündigung eingegangen am
Datentyp: Datum

Speichern Sie das Feld.

Dieses Feld hält fest, wann die Kündigung beim Verein eingegangen ist.

Legen Sie anschließend ein weiteres benutzerdefiniertes Feld an.

Bezeichnung: Kündigungsgrund
Datentyp: Alphanumerisch
Eingabeart: Auswahlliste

Als Auswahlmöglichkeiten können Sie beispielsweise verwenden:

Austritt
Ende des Schulbesuchs
Tod
sonstiger Grund

Speichern Sie auch dieses Feld.

Wichtig ist die Unterscheidung zwischen Kündigungseingang und Ende der Mitgliedschaft.

Wenn eine Kündigung beispielsweise am 15. Mai eingeht, die Mitgliedschaft laut Satzung aber erst zum 31. Juli endet, werden zwei unterschiedliche Angaben gespeichert:

Kündigung eingegangen am: 15.05.
Enddatum der Mitgliedschaft: 31.07.

Das Kündigungsdatum beschreibt also den Eingang der Erklärung. Das Enddatum beschreibt dagegen den Zeitpunkt, zu dem die Mitgliedschaft tatsächlich endet.

Genau diese Trennung ermöglicht es uns, eine Kündigung zu dokumentieren, ohne den gegenwärtigen Mitgliedsstatus zu verändern. Die Person bleibt bis zum tatsächlichen Enddatum Aktiv. Erst nach Erreichen des Enddatums wechselt die Mitgliedschaft in den Status Beendet.

Auch diese beiden Felder sind zunächst nur normale benutzerdefinierte Felder von CiviCRM. Im nächsten Schritt teilen wir Project60 Membership mit, dass genau diese Felder für Kündigungsdatum und Kündigungsgrund verwendet werden sollen.

Schritt 8: Die Beitragsverknüpfung von Project60 einrichten

Project60 Membership benötigt noch einige weitere Angaben, um die Mitgliedschaft mit einem wiederkehrenden Zahlungsvertrag und den daraus entstehenden Beiträgen zu verknüpfen. Dazu legen wir zunächst weitere benutzerdefinierte Felder an. Anschließend teilen wir Project60 mit, welches dieser Felder welche Funktion übernehmen soll.

Feldeigenschaften für Project60

Project60 kann nicht jedes beliebige benutzerdefinierte Feld für jede Funktion verwenden. Die Erweiterung bietet ein Feld in ihrer Konfigurationsoberfläche nur dann zur Auswahl an, wenn Datentyp und weitere Eigenschaften den Anforderungen der jeweiligen Funktion entsprechen.

Achten Sie deshalb beim Anlegen der folgenden Felder auf diese Einstellungen:

Feld	Datentyp	Durchsuchbar	Nur Ansicht
Zahlungsvertrag	Ganzzahl	ja	ja
Erwarteter Jahresbeitrag	Geldbetrag	ja	nein
Rate je Zahlungszyklus	Geldbetrag	ja	ja
Differenz Jahresbeitrag/Zahlungsvertrag	Geldbetrag	ja	ja
Zahlungsfrequenz	Alphanumerisch / Auswahlliste	ja	ja
Zahlender Kontakt	Kontaktreferenz	ja	nein

Alle Felder müssen außerdem aktiv sein und zur Feldgruppe einer Mitgliedschaft gehören.

Für Zahlungsfrequenz verwenden Sie eine Auswahlliste mit den internen Werten:

1 – monatlich
3 – quartalsweise
6 – halbjährlich
12 – jährlich

Project60 erwartet genau diese Werte, um den Zahlungsabstand auswerten zu können.

Zahlungsvertrag

Legen Sie ein benutzerdefiniertes Feld Zahlungsvertrag an. Wählen Sie als Datentyp Ganzzahl und aktivieren Sie Durchsuchbar sowie Nur Ansicht. Project60 speichert hier die ID der zugehörigen wiederkehrenden Zuwendung.

Erwarteter Jahresbeitrag

Legen Sie anschließend ein Feld mit der Bezeichnung Erwarteter Jahresbeitrag an. Wählen Sie als Datentyp Geldbetrag und aktivieren Sie Durchsuchbar. Das Feld bleibt bearbeitbar; Nur Ansicht wird also nicht aktiviert.

Hier wird festgehalten, welcher Gesamtbeitrag für ein Jahr aufgrund der Beitragsvereinbarung erwartet wird. Dieses Feld kann bei der Mitgliedschaft bearbeitet werden.

Rate je Zahlungszyklus

Legen Sie ein weiteres Feld Rate je Zahlungszyklus mit dem Datentyp Geldbetrag an. Aktivieren Sie Durchsuchbar und Nur Ansicht.

Project60 kann hier aus dem Zahlungsvertrag abbilden, welcher Betrag jeweils pro Zahlungsintervall anfällt. Bei einem Jahresbeitrag von 120 Euro und monatlicher Zahlung wären das beispielsweise „10 € je Zahlungszyklus“.

Dieses Feld wird von Project60 ermittelt und sollte deshalb nicht manuell bearbeitet werden.

Zahlungsfrequenz

Legen Sie ein Auswahlfeld mit der Bezeichnung Zahlungsfrequenz an.

Wählen Sie als Datentyp Alphanumerisch und als Eingabeart Auswahlliste. Aktivieren Sie Durchsuchbar und Nur Ansicht.

Project60 verwendet für die Frequenz Abstände in Monaten. Legen Sie deshalb folgende, von Project60 ausdrücklich festgelegte Auswahlmöglichkeiten an:

1 – monatlich
3 – quartalsweise
6 – halbjährlich
12 – jährlich

Auch dieses Feld wird später von Project60 gepflegt.

Differenz Jahresbeitrag/Zahlungsvertrag

Legen Sie ein Geldbetragsfeld Differenz Jahresbeitrag/Zahlungsvertrag an. Aktivieren Sie Durchsuchbar und Nur Ansicht.

Project60 kann darin die Differenz zwischen dem erwarteten Jahresbeitrag und dem Betrag festhalten, der sich aus dem hinterlegten Zahlungsvertrag ergibt.

Auch dieses Feld dient der Berechnung und soll nicht manuell verändert werden.

Zahlender Kontakt

Legen Sie schließlich ein Feld Zahlender Kontakt an. Wählen Sie als Datentyp Kontaktreferenz und aktivieren Sie Durchsuchbar. Das Feld bleibt bearbeitbar; Nur Ansicht wird nicht aktiviert.

Damit kann bei einer Mitgliedschaft festgehalten werden, dass nicht das Mitglied selbst, sondern ein anderer Kontakt den Beitrag bezahlt. Das Mitglied und die zahlende Person bleiben dadurch zwei verschiedene Kontakte mit unterschiedlichen Rollen.

Die Felder Project60 zuordnen

Bis hierher haben wir lediglich zusätzliche Felder in CiviCRM angelegt. Project60 weiß noch nicht, welches davon beispielsweise die Mitgliedsnummer, das Kündigungsdatum oder den Zahlungsvertrag enthält.

Diese Zuordnung erfolgt auf der eigenen Konfigurationsseite von Project60 Membership.

Anders als viele andere Erweiterungen bindet Project60 Membership diese Seite nicht zuverlässig in das Navigationsmenü von CiviCRM ein. Suchen Sie deshalb nicht vergeblich unter Administration. Rufen Sie die Konfigurationsseite direkt auf:

https://IHRE-CIVICRM-DOMAIN/civicrm/admin/setting/membership

Die Seite trägt die Bezeichnung Konfiguration der Mitgliedschafts-Extension. Ordnen Sie dort die zuvor angelegten Felder den entsprechenden Funktionen zu:

Einstellung in Project60	Benutzerdefiniertes Feld
Mitgliedsnummer	Mitgliedsnummer
Kündigungsdatum	Kündigung eingegangen am
Kündigungsgrund	Kündigungsgrund
Zahlungsvertrag	Zahlungsvertrag
Jahresbeitrag	Erwarteter Jahresbeitrag
Ratenbetrag	Rate je Zahlungszyklus
Jahresdifferenz	Differenz Jahresbeitrag/Zahlungsvertrag
Zahlungsfrequenz	Zahlungsfrequenz
Zahlender Kontakt	Zahlender Kontakt

Zuwendungsart und Mitgliedschaftstyp miteinander verknüpfen

Project60 muss außerdem wissen, welche Zuwendungsart zu welchem Mitgliedschaftstyp gehört. Diese Zuordnung verwendet die Erweiterung, um eingegangene Beiträge einer passenden Mitgliedschaft zuordnen zu können.

Bleiben Sie auf der Seite Konfiguration der Mitgliedschafts-Extension und suchen Sie den Bereich Financial Type Mapping beziehungsweise Zuordnung der Zuwendungsarten.

Ordnen Sie Mitgliedsbeitrag / Member Dues → Fördermitglied zu.

Damit legen wir fest, dass eine Zuwendung der Art „Mitgliedsbeitrag“ grundsätzlich zu einer Mitgliedschaft des Typs „Fördermitglied“ gehört.

Diese Zuordnung ist insbesondere für Zahlungen wichtig, die nicht bereits über einen mit der Mitgliedschaft verbundenen Zahlungsvertrag eindeutig zugeordnet sind. Project60 kann solche Contributions anhand der Zuwendungsart der passenden Membership zuordnen.

Project60 empfiehlt grundsätzlich, für unterschiedliche Mitgliedschaftstypen auch unterschiedliche Zuwendungsarten zu verwenden, wenn deren Beiträge zuverlässig voneinander unterschieden werden müssen. In unserem einfachen Hauptpfad existiert nur der Mitgliedschaftstyp Fördermitglied, sodass die vorhandene Zuwendungsart Member Dues / Mitgliedsbeitrag dafür ausreicht.

Wichtig ist die Richtung der Zuordnung:

Zuwendungsart → Mitgliedschaftstyp

also:

Mitgliedsbeitrag → Fördermitglied

Für die Mitgliedsnummer tragen Sie außerdem das bereits vorgesehene Nummernmuster ein, beispielsweise so:

M-{mid+10000}

Wenn die Mitgliedsnummer auch in den Mitgliedschaftsübersichten angezeigt werden soll, aktivieren Sie dort außerdem die entsprechende Anzeigeoption.

Ein Stolperstein der Project60-Oberfläche

Einige Bereiche der Konfigurationsseite können zunächst leer oder unvollständig wirken. Das betrifft insbesondere die Einstellungen für abgeleitete Felder.

Wählen Sie deshalb zuerst das zuvor angelegte Feld Zahlungsvertrag als Zahlungsvertragsfeld aus.

Erst wenn Project60 ein gültiges Feld für den Zahlungsvertrag kennt, werden die davon abhängigen Zuordnungen vollständig angeboten.

Hinweis zur Zahlungsart

Für den hier beschriebenen Hauptpfad verwenden wir die bereits in CiviContribute vorhandenen Zahlungsmethoden. Eine tatsächliche Zuwendung kann dort beispielsweise als Überweisung, Barzahlung oder später als SEPA-Lastschrift gekennzeichnet werden.

Project60 bietet zusätzlich die Möglichkeit, ein eigenes Feld Payment Type Field zu verwenden. Dieses ist vor allem dann sinnvoll, wenn mehrere technische Zahlungsmethoden zu einer gemeinsamen Kategorie zusammengefasst werden sollen – beispielsweise mehrere unterschiedliche SEPA-Zahlungsmethoden unter dem Oberbegriff „SEPA-Lastschrift“.

Für diesen Anwendungsfall wäre zusätzlich ein Payment Type Field Mapping einzurichten. Da wir eine solche Zusammenfassung in unserem Hauptpfad nicht benötigen, verwenden wir dieses zusätzliche Feld hier nicht.

Schritt 9: Die Standard-Statuslogik von CiviMember anpassen

CiviMember verwendet Mitgliedsstatus, um den gegenwärtigen Zustand einer Mitgliedschaft abzubilden. Einige Status werden automatisch aus Start- und Enddatum berechnet, andere können bewusst durch die Verwaltung gesetzt werden.

Öffnen Sie Administration → CiviMember → Mitgliedsstatusregeln.

In einer Standardinstallation finden Sie dort unter anderem die Status:

Pending
New
Current
Grace
Expired
Cancelled
Deceased

CiviCRM wertet die Statusregeln von oben nach unten aus und verwendet die erste Regel, die zum jeweiligen Start- und Enddatum der Mitgliedschaft passt. Die beiden reservierten Status Pending und Deceased können über diese Oberfläche nicht wie normale Status bearbeitet werden.

Für unseren Hauptpfad verwenden wir als fachlich relevante Status:

Beantragt
Aktiv
Beendet
Verstorben

Der von CiviCRM mitgelieferte Status Pending bleibt dabei technisch bestehen. Wir verwenden ihn jedoch nicht für unseren vereinsinternen Aufnahmeprozess.

Beantragt

Ein Beitrittsantrag ist noch keine bestehende Mitgliedschaft. Wir benötigen deshalb einen administrativen Status, der bewusst gesetzt werden kann und nicht automatisch aus Datumswerten entsteht.

Wählen Sie auf der Seite Mitgliedsstatusregeln die Funktion Mitgliedsstatus hinzufügen.

Legen Sie einen neuen Status mit folgenden Einstellungen an:

Name: Beantragt
Startereignis: Beginn der Mitgliedschaft
Anpassung des Beginn-Auslösers: leer
Beendigungs-Auslöser: leer
Aktuelle Mitgliedschaft?: nein
Nur für Administrator?: ja

Speichern Sie den Status.

Das Startereignis ist in der CiviCRM-Oberfläche ein Pflichtfeld. Für einen Status, bei dem Nur für Administrator? aktiviert ist, hat es jedoch keine automatische Wirkung: CiviCRM weist einen solchen Status nicht selbst anhand seiner Datumsregeln zu.

Der Status Beantragt wird stattdessen beim Anlegen oder Bearbeiten einer Mitgliedschaft über Status überschreiben bewusst ausgewählt.

CiviCRM behandelt eine Mitgliedschaft mit aktivierter Statusüberschreibung nicht mehr nach den normalen Statusregeln. Wird die Aufnahme beschlossen, muss die Statusüberschreibung deshalb wieder entfernt werden. Anschließend kann CiviMember den regulären Status der Mitgliedschaft automatisch bestimmen.

Aktiv

Bearbeiten Sie den vorhandenen Status Current.

Ändern Sie seine sichtbare Bezeichnung in „Aktiv“. Verwenden Sie als Startereignis „Beginn der Mitgliedschaft“ und als Beendigungs-Auslöser „Ablaufdatum der Mitgliedschaft“. Kennzeichnen Sie den Status als Aktuelle Mitgliedschaft.

Für unseren Mitgliedschaftstyp bedeutet das: Solange kein Enddatum eingetragen ist, besteht die Mitgliedschaft fort. Wird später ein Enddatum eingetragen, bleibt sie bis einschließlich dieses Tages aktiv.

Beendet

Bearbeiten Sie anschließend den vorhandenen Status Expired und ändern Sie seine sichtbare Bezeichnung in „Beendet“.

Als Startereignis verwenden Sie „Ablaufdatum der Mitgliedschaft“ und tragen als Anpassung „1 Tag danach“ ein. Ein Beendigungs-Auslöser ist nicht erforderlich.

Der Status zählt nicht als aktuelle Mitgliedschaft. Eine Mitgliedschaft mit dem Enddatum 31.07. kann damit ab dem 01.08. automatisch den Status Beendet erhalten.

Damit solche datumsabhängigen Statuswechsel auch ohne manuelle Bearbeitung stattfinden, muss der geplante CiviCRM-Job zur Aktualisierung der Mitgliedschaftsstatus regelmäßig ausgeführt werden. Darauf kommen wir bei der Automatisierung zurück.

Verstorben

Den vorhandenen Core-Status Deceased verändern wir nicht.

Dieser Status ist von CiviCRM reserviert und wird automatisch verwendet, wenn ein Kontakt als verstorben gekennzeichnet wird. In einer deutschsprachigen Oberfläche kann er entsprechend als Verstorben angezeigt werden.

Der reservierte Status Pending

Auch Pending bleibt unverändert bestehen.

CiviCRM verwendet diesen Status insbesondere bei Mitgliedschaften, bei denen ein zugehöriger Zahlungsvorgang noch nicht abgeschlossen ist. Er ist deshalb nicht dasselbe wie unser vereinsrechtlich verstandener Zustand Beantragt.

Wir legen für unseren Aufnahmeprozess bewusst einen eigenen administrativen Status Beantragt an und lassen den reservierten Core-Status Pending unangetastet.

Schritt 10: Nicht benötigte Standard-Status deaktivieren

Für unser Mitgliedschaftsmodell benötigen wir einige der von CiviMember standardmäßig angelegten Status nicht.

Öffnen Sie erneut Administration → CiviMember → Mitgliedsstatusregeln.

Deaktivieren Sie dort die folgenden Status:

New
Grace
Cancelled

Löschen Sie diese Status nicht.

Die Status gehören zur Standardstruktur von CiviMember und können an anderer Stelle referenziert werden. Für unseren Hauptpfad genügt es, sie zu deaktivieren. Dadurch verschwinden sie aus der normalen Verwendung, ohne dass bestehende technische Bezüge beschädigt werden.

Nach diesem Schritt arbeiten wir mit folgendem Statusmodell:

Beantragt
Aktiv
Beendet
Verstorben

Für unseren vereinsinternen Arbeitsablauf verwenden wir die Status Beantragt, Aktiv, Beendet und Verstorben. Der reservierte Core-Status Pending bleibt daneben für CiviCRM-interne beziehungsweise zahlungsbezogene Abläufe bestehen.

Schritt 11: Project60 mitteilen, welche Mitgliedschaften aktiv sind

Rufen Sie erneut die Konfigurationsseite von Project60 Membership auf:

https://IHRE-CIVICRM-DOMAIN/civicrm/admin/setting/membership

Suchen Sie dort die Einstellung Aktive Status.

Wählen Sie „Aktiv“. Damit weiß Project60, welche Mitgliedschaften als laufende Mitgliedschaften behandelt werden sollen.

Eine bereits ausgesprochene Kündigung ändert daran zunächst nichts: Solange das eingetragene Enddatum noch nicht erreicht ist, bleibt die Mitgliedschaft Aktiv.

Speichern Sie anschließend die Einstellung.

Schritt 12: Wann endet ein Zahlungsvertrag?

Project60 kann einen mit der Mitgliedschaft verbundenen Zahlungsvertrag beenden, wenn die Mitgliedschaft einen bestimmten Status erreicht.

Bleiben Sie auf der Konfigurationsseite von Project60 Membership und suchen Sie die Einstellung Bei folgenden Status beenden.

Wählen Sie:

Beendet
Verstorben

Damit wird ein zugeordneter Zahlungsvertrag erst dann beendet, wenn auch die Mitgliedschaft tatsächlich beendet ist beziehungsweise das Mitglied verstorben ist.

Speichern Sie die Einstellung.

Schritt 13: Auto-Renewal ausblenden

CiviMember kennt eine eigene Logik zur automatischen Verlängerung von Mitgliedschaften. Für unser Modell wollen wir jedoch vermeiden, dass der Eindruck entsteht, die Mitgliedschaft werde durch einen Zahlungsvorgang begründet oder verlängert.

Bleiben Sie deshalb auf der Konfigurationsseite von Project60 Membership.

Aktivieren Sie die Einstellung „Automatische Verlängerung verstecken“. Damit wird die entsprechende CiviMember-Funktion in der normalen Bearbeitung ausgeblendet.

Die Einstellung „Mitgliedschaft verlängern, wenn Zuwendung abgeschlossen“ aktivieren wir dagegen nicht, weil der Eingang eines Mitgliedsbeitrags nicht darüber entscheidet, ob die Mitgliedschaft besteht. Eine Person kann Mitglied sein, obwohl ein Beitrag noch offen ist. Umgekehrt darf eine Zahlung nicht automatisch die rechtliche beziehungsweise satzungsgemäße Laufzeit der Mitgliedschaft verändern.

Speichern Sie anschließend die Project60-Konfiguration.

Schritt 14: Zahlungen automatisch Mitgliedschaften zuordnen

Project60 kann eingegangene Mitgliedsbeiträge automatisch der passenden Mitgliedschaft zuordnen. Dies ist insbesondere bei Zahlungen sinnvoll, die als normale Zuwendungen in CiviContribute erfasst oder importiert werden – beispielsweise Überweisungen oder Daueraufträge.

Die Zuordnung beruht auf dem zuvor eingerichteten Financial Type Mapping. Eine Zuwendung der Art Mitgliedsbeitrag kann dadurch einer aktiven Mitgliedschaft des Typs Fördermitglied zugeordnet werden.

Sie können die Zuordnung zunächst manuell aufrufen. Öffnen Sie dazu Mitgliedschaften → Zahlungen synchronisieren und starten Sie die Synchronisation.

Wenn dieser Abgleich regelmäßig automatisch erfolgen soll, öffnen Sie Administration → Systemeinstellungen → Geplante Jobs und richten Sie dort einen geplanten Job für

MembershipPayment → synchronize

ein.

Dieser Job ordnet vorhandene Zuwendungen den passenden Mitgliedschaften zu. Er verändert dabei nicht die Laufzeit der Mitgliedschaft. Project60 berücksichtigt für die Zuordnung unter anderem die zuvor eingerichtete Zuordnung von Zuwendungsart und Mitgliedschaftstyp.

Den Job Membership → process richten wir für unseren Hauptpfad dagegen nicht ein. Dieser Job dient unter anderem dazu, Mitgliedschaften aufgrund zugeordneter Zahlungen in weitere Mitgliedschaftsperioden zu verlängern. Eine solche zahlungsabhängige Verlängerung entspricht nicht unserem Mitgliedschaftsmodell.

Öffnen Sie außerdem Administration → Systemeinstellungen → Geplante Jobs und prüfen Sie, ob der CiviCRM-Job zum Aktualisieren der Mitgliedschaftsstatus aktiviert ist und mindestens einmal täglich ausgeführt wird.

Dieser Job wertet die unter Administration → CiviMember → Mitgliedsstatusregeln eingerichteten Regeln aus. Ist beispielsweise als Enddatum einer Mitgliedschaft der 31.07. eingetragen, kann CiviCRM die Mitgliedschaft ab dem 01.08. auf Beendet setzen

5. Mit der Mitgliederverwaltung arbeiten

Nach der Einrichtung können Sie Mitgliedschaften nun entlang ihres tatsächlichen Verlaufs verwalten. Die folgenden Beispiele zeigen die wichtigsten Handgriffe im Vereinsalltag.

5.1 Ein neues Mitglied aufnehmen

Suchen Sie zunächst den Kontakt der Person und öffnen Sie ihn. Falls die Person noch nicht in CiviCRM vorhanden ist, legen Sie zunächst einen neuen Kontakt an.

Wechseln Sie anschließend beim Kontakt zum Bereich Mitgliedschaften und wählen Sie Mitgliedschaft hinzufügen.

Wählen Sie als Mitgliedschaftstyp:

Fördermitglied

Tragen Sie das tatsächliche Startdatum der Mitgliedschaft ein.

Das Enddatum bleibt bei der Aufnahme leer. Die Mitgliedschaft ist nicht für einen im Voraus festgelegten Zeitraum abgeschlossen. Ein Enddatum wird erst eingetragen, wenn später ein Beendigungsgrund feststeht.

Die Mitgliedschaft erhält den Status Aktiv.

In der Feldgruppe Mitgliedschaft Förderverein können Sie außerdem die konkrete Beitragsvereinbarung eintragen, beispielsweise:

Beitrag je Intervall: 36 €
Beitragsrhythmus: jährlich

Speichern Sie die Mitgliedschaft.

Eine tatsächliche Zahlung muss zu diesem Zeitpunkt noch nicht vorhanden sein. Die Mitgliedschaft und die Zahlung des Beitrags sind zwei verschiedene Sachverhalte.

5.2 Einen Beitrittsantrag erfassen

Wenn über einen Beitritt zunächst noch entschieden werden muss, öffnen Sie den betreffenden Kontakt und wechseln Sie zum Bereich Mitgliedschaften.

Legen Sie die Mitgliedschaft an und aktivieren Sie beim Status die manuelle Überschreibung. Wählen Sie anschließend den administrativen Status Beantragt.

Wird die Aufnahme beschlossen, entfernen Sie die Statusüberschreibung wieder. CiviMember kann dann anhand der Statusregeln den regulären Status Aktiv bestimmen.

So bleiben Antrag, Aufnahmeentscheidung und Beginn der Mitgliedschaft voneinander unterscheidbar.

5.3 Beitragszahlungen nachvollziehen

Die vereinbarte Beitragshöhe finden Sie an der Mitgliedschaft selbst.

Öffnen Sie dazu beim Kontakt den Bereich Mitgliedschaften und dort die betreffende Mitgliedschaft. In der Feldgruppe Mitgliedschaft Förderverein finden Sie beispielsweise:

Beitrag je Intervall: 60 €
Beitragsrhythmus: jährlich

Die tatsächlich eingegangenen Zahlungen werden dagegen in CiviContribute als Zuwendungen geführt.

Wechseln Sie beim Kontakt zum Bereich Zuwendungen, um zu prüfen, welche Mitgliedsbeiträge tatsächlich eingegangen sind.

Damit bleiben zwei Fragen voneinander getrennt:

Was soll das Mitglied zahlen?
→ steht an der Mitgliedschaft.

Was wurde tatsächlich bezahlt?
→ steht bei den Zuwendungen.

Ein noch nicht gezahlter Beitrag verändert den Mitgliedsstatus nicht automatisch. Eine Person kann also weiterhin Aktiv sein, obwohl noch keine entsprechende Zahlung erfasst wurde.

5.4 Einen Fremdzahler hinterlegen

Soll eine andere Person den Beitrag für das Mitglied bezahlen, muss dieser Kontakt ebenfalls in CiviCRM vorhanden sein.

Öffnen Sie anschließend beim eigentlichen Mitglied den Bereich Mitgliedschaften und dort die betreffende Mitgliedschaft.

Suchen Sie in der Feldgruppe Mitgliedschaft Förderverein das Feld Zahlender Kontakt und wählen Sie dort die Person aus, die den Beitrag übernimmt.

Die Mitgliedschaft bleibt weiterhin dem eigentlichen Mitglied zugeordnet. Der zahlende Kontakt wird lediglich zusätzlich als Zahler hinterlegt.

So müssen Mitgliedschaft und Zahlung nicht künstlich derselben Person zugeordnet werden.

5.5 Unterschiedliche Beitragsrhythmen verwenden

Öffnen Sie beim betreffenden Kontakt den Bereich Mitgliedschaften und bearbeiten Sie die Mitgliedschaft Fördermitglied.

In der Feldgruppe Mitgliedschaft Förderverein können Sie Beitragsrhythmus und Beitrag je Intervall unabhängig voneinander festlegen.

Beispiele:

36 € jährlich
10 € quartalsweise
5 € monatlich
20 € einmalig
beitragsfrei

Der Mitgliedschaftstyp bleibt in allen Fällen derselbe:

Fördermitglied

Dadurch müssen keine eigenen Mitgliedschaftstypen wie „Monatsmitglied“, „Jahresmitglied“ oder „SEPA-Mitglied“ angelegt werden.

5.6 Eine Kündigung erfassen

Öffnen Sie den Kontakt des Mitglieds und wechseln Sie zum Bereich Mitgliedschaften. Bearbeiten Sie dort die betreffende Mitgliedschaft.

Tragen Sie in der Feldgruppe Mitgliedschaft Förderverein zunächst ein, wann die Kündigung eingegangen ist:

Kündigung eingegangen am: 15.05.

Wählen Sie gegebenenfalls außerdem den Kündigungsgrund.

Tragen Sie anschließend im regulären CiviMember-Feld Enddatum das Datum ein, zu dem die Mitgliedschaft tatsächlich endet:

Enddatum: 31.07.

Die Mitgliedschaft bleibt bis einschließlich dieses Tages im Status Aktiv.

Nach Ablauf des Enddatums kann CiviMember die Mitgliedschaft anhand der eingerichteten Statusregeln automatisch auf Beendet setzen.

Damit lässt sich beispielsweise eine Satzungsregel abbilden, nach der eine Kündigung im Mai erklärt wird, die Mitgliedschaft aber erst zum Ende des Schuljahres endet.

5.7 Beispiel Schulförderverein: Das Ende des Schulbesuchs erfassen

Bei einem Schulförderverein kann die Mitgliedschaft mit dem Schulbesuch eines Kindes verknüpft sein. In unserem Beispiel sieht die Satzung vor, dass die Mitgliedschaft mit dem Ende des Schulbesuchs endet, sofern nicht die weitere Mitgliedschaft beantragt wird.

Öffnen Sie den Kontakt des Mitglieds und wechseln Sie zum Bereich Mitgliedschaften. Bearbeiten Sie dort die betreffende Mitgliedschaft.

Tragen Sie in der Feldgruppe Mitgliedschaft Förderverein das Datum unter Schulbesuch des Kindes endet am ein.

Prüfen Sie anschließend das Feld Mitgliedschaft nach Schulende fortführen.

Soll die Mitgliedschaft fortbestehen, bleibt das reguläre Enddatum der Mitgliedschaft leer.

Soll die Mitgliedschaft dagegen mit dem Ende des Schulbesuchs enden, tragen Sie das entsprechende Datum zusätzlich als Enddatum der Mitgliedschaft ein.

Damit bleiben zwei Dinge voneinander unterscheidbar:

organisatorischer Anlass: Ende des Schulbesuchs
tatsächliches Ende der Membership: Enddatum der Mitgliedschaft

Diese Felder gehören nicht allgemein zu CiviMember. Sie sind ein Beispiel dafür, wie die generische Mitgliederverwaltung an die Satzung und die tatsächlichen Abläufe eines bestimmten Vereinstyps angepasst werden kann.

5.8 Eine Mitgliedschaft beenden

Eine Mitgliedschaft muss normalerweise nicht am letzten Tag manuell auf Beendet gesetzt werden.

Ist ein Enddatum eingetragen, wertet CiviMember dieses Datum anhand der eingerichteten Mitgliedsstatusregeln aus. Nach Ablauf des Enddatums erhält die Mitgliedschaft den Status:

Beendet

Die Person selbst bleibt weiterhin als Kontakt in CiviCRM erhalten.

Das ist wichtig, weil sie beispielsweise weiterhin

ehemalige Funktionsträgerin oder ehemaliger Funktionsträger,
Spenderin oder Spender,
Veranstaltungsteilnehmerin oder Veranstaltungsteilnehmer,
Ansprechpartnerin oder Ansprechpartner

sein kann.

Beendet wird also die Mitgliedschaft, nicht der Kontakt.