Alter nach Datum anstatt nach Jahrgang berechnen für die Mitgliederstatistik

[patrickuhlmann]

Problem
Aktuell werden Mitglieder bei uns erst ab dem Jahr beitragspflichtig, in dem sie 8 Jahre alt werden. Dadurch entsteht eine Ungleichbehandlung: Kinder, die vor dem 31. Juli Geburtstag haben, profitieren faktisch von einem zusätzlichen «Gratisjahr» in der Jungschar. Grund dafür ist, dass in der Mitgliederstatistik derzeit der Jahrgang und nicht das tatsächliche Alter am Stichtag berücksichtigt wird.

Wunsch
Wir wünschen uns deshalb, dass in der Mitgliederstatistik der cevi.db künftig das Alter am jeweiligen Stichtag berücksichtigt wird, anstelle des reinen Jahrgangs. Auf diese Weise können alle Kinder korrekt erfasst werden, die bis zum Stichtag das entsprechende Alter erreicht haben. Dadurch würde auch die Berechnung des darauf aufbauenden Kopfbatzen nachvollziehbarer und sachlich korrekter.

Wie oft benötigt
Diese Anpassung wird jeweils bei der Erstellung der Mitgliederstatistik sowie bei der Berechnung des Kopfbatzen benötigt.

Ist dies auch ein Problem in anderen Regionen, oder trifft dies nur auf uns zu?
Ist die Umsetzung generell Möglich, oder eher nicht?

(gemeldet durch Curador)

[patrickuhlmann]

Technische Analyse

Die Zähllogik befindet sich in hitobito_cevi/app/domain/member_counter.rb. Die relevante Stelle ist:

  # Zeile 98 – heute: Gruppierung nach Geburtsjahr                                                                                                                                                                                 
  def members_by_year                                                                                                                                                                                                              
    members.includes(:roles).group_by { |p| p.birthday.try(:year) }
  end

Änderungsbedarf:

• members_by_year so anpassen, dass nach Alter am Stichtag gruppiert wird
• Stichtag definieren (Kandidat: Census#finish_at, bereits vorhanden)
• Anzeige anpassen: statt «Jahrgang 2018» z.B. «Alter 8»
• Entscheid zu historischen Daten: Bestehende member_counts-Einträge speichern born_in als Jahrgang (z.B. 2018). Neue Einträge würden Alter speichern (z.B. 8). Optionen:
  • Alte Daten mit dem jeweiligen Census-Stichtag migrieren
  • Alte und neue Daten koexistieren lassen (alte Zensuse bleiben historisch)

Aufwand

Überschaubar. Die Kernänderung betrifft primär eine Methode in member_counter.rb. Zusätzlicher Aufwand entsteht je nach Entscheid zur Datenmigration und Anpassung der Anzeige/Exporte.

Betroffene Komponenten

• app/domain/member_counter.rb
• app/models/member_count.rb (ggf. Spalte born_in semantisch anpassen)
• Views/Exporte der Mitgliederstatistik

[patrickuhlmann]

tldr

• Gibt es aktuell eine Doppelerfassung bei CCH (einmal über Cevi.db und einmal per Formular?
• Wie umgehen mit fehlenden Jahrgängen (Geburtsdatum)?

Aus einer Diskussion AG-SO-LU-ZG (muss dem vielleicht noch bisschen besser nachgehen):

• Aktuell muss es zweimal gemeldet werden. Einmal via Cevi.db und einem mit einem zusätzlichen Formular. Auf dem Formular muss dann bspw. auch unter/über 25 Jahre angegeben werden. Weshalb kann das nicht alles über Cevi.db abgewickelt werden (bspw. die Unterteilung < 25 Jahre direkt ausgewiesen werden)
• Ein Problem machen teilweise die fehlenden Jahrgänge. Es ist dann schwierig Mitgliederbeiträge nach Alter zu machen. Auch ist es mühsam die Abteilungen immer wieder daran zu erinnern diese auszufüllen und es ist auch nicht so einfach das laufend auszuwerten. Wäre es möglich eine Anpassung vorzunehmen um bei bestimmten Rollen den Jahrgang (respektive wohl das Geburtsdatum) setzen zu müssen?

[nchiapol]

Das Problem von Curador kann ich nicht wirklich nachvollziehen. Es gibt immer irgend ein Stichdatum für die Berechnung des Mitgliederbeitrags. Wenn wir das alte am Stichtag wählen sind es einfach andere Kinder, die dann schon bzw. noch nicht bezahlen müssen.

Das Grundproblem hier ist aber, dass jede Region eigene Regeln für die Mitgliederbeiträge hat und die die Bestandesmeldung für verschieden Zwecke hat.

Persönlich halte ich es deshalb für korrekt, dass wir in der DB eine möglichst allgemeingültige Bestandesstatistik implementieren. Das bedeutet insbesondere einfach Personen nach Jahrgang auszugeben.

Falls jemand komplexere Analysen braucht, müssten diese via API und ausserhalb der DB implementiert werden. (Allenfalls sind dafür Anpassungen an der API nötig, das fände ich dann wieder sinnvoll.)