Project

General

Profile

Actions

Feature #22

open

How best to track membership status

Added by Lance Edgar over 1 year ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
Start date:
08/21/2023
Due date:
% Done:

0%

Estimated time:

Description

The basic questions are:

  • how should membership status be modeled in schema
  • how/when should it change, and how is that modeled

So far the Member model can track "status" in 3 ways:

  • presence or absence of Member record indicates whether or not a given person/customer has "ever" been a member
  • Member.active flag is basically "true" when member joins, and becomes "false" when they withdraw (or are escheated)
  • nb. the remaining points would only apply if Member.active is "true"
  • Member.membership_type can indicate which "type" of member account; supported types are user-defined in MembershipType model
  • Member.equity_current indicates the account's equity/stock payments are up-to-date

This much has been "good enough" but is showing some weak spots now.

In one notable instance, we need some way to indicate member account status as being "truly active" only IFF member has shopped within the last 12 months. So far one idea to add this would be to:

  • add new Member.active_current flag, which can be (un)set per custom logic (e.g. based on transaction activity)

But also in this instance we need a way to report on how many member accounts had a status change (i.e. went from "not truly active" to "truly active" in a given date range. So far the version history tables are the only way we could know that, so additionally need to add a "status tracking" table to more easily see status changes over time. Probably add a MemberStatus model with columns:

  • member_uuid - FK to Member.uuid
  • as_of_date - date when status changes
  • flags for active, equity_current, active_current
  • possibly others, e.g. employee_current ?

When a corresponding Member value changes, a new MemberStatus record is added with the new set of values. Reports can then target this table to find status changes for a date range.

And so far there is no MemberHistory table either; need to add that similar to EmployeeHistory etc. This is to track join vs. withdrawal dates over time. (Or could this be obviated by MemberStatus ? if so maybe name that MemberStatusHistory instead.)

Actions

Also available in: Atom PDF