rattail-manual/docs/features/people/members/index.rst

Members
=======

As with Employee and Customer data, the first questions regarding
Member data are: What is it, and what does it have to do with Rattail?

Rattail's concept of a "Member" comes primarily from the world of
retail food co-ops, where a Member is more like a Customer than an
Employee.  But there exist also worker co-ops, where a Member is
really more like an Employee.  Rattail's Member features are meant to
acommodate both scenarios.

Members often have some equity account associated with them, with join
and (where applicable) withdrawal dates, and usually also a payment
history for the equity.

So if your organization has a membership component, then you most
likely already have some way to track accounts and equity etc.  Why
bring it into Rattail?

As usual the first answer is simple visibility.  For instance you
might be tracking accounts in a spreadsheet or Microsoft Access, or
any of a number of similar "undesirable" solutions.  Even if you
continue with that tracking approach, you also could periodically
import data to Rattail just so it can be more easily viewed by others
via the web app.

And part of visibility is cross-referencing related data.  Maybe you
already have a good way to view accounts, but you have no way to view
an account alongside its equity, or perhaps POS Transaction history
etc.  Showing the various types of data on one screen (maybe with a
link back to the other system) can be quite helpful in some cases.

Another potential feature is to send email reminders to Members who
have an upcoming payment due, etc. based on their account details.
And it's possible to monitor an IMAP folder for any "bounces" that
result from sending such reminders, in which case can e.g. flag the
account as having a bad email on file.

Similarly a Member account status may dynamically affect which
discounts are available to their Customer account at the POS.  This
idea depends on the ability to effect certain changes in the POS
system, e.g. add/remove electronic coupons for an account.

But..everything just stated is technically possible *without*
importing the data to Rattail.  So still at this point we've not
established a good reason to actually import it.

You can of course create batches for performing account maintenance in
whatever way is needed.  Same general "rules" apply as for other
(e.g. Customer) tables.  Member data need not be imported into Rattail
in order to use the batch features.

But unlike the Customer data, where the POS is frequently the obvious
"authority", many times Member data is *not* tracked (well) by the
POS, and so custom spreadsheet workflows or similar tactics are
employed to keep track of it.

So this finally is why you *might* want to import it into Rattail.
Any tasks being managed via spreadsheet workflows (or whatever) can
instead be managed directly in the web app.

If you choose this route, a couple of implications:

Rattail becomes your primary Member system, and you (presumably /
ideally) no longer need your previous system for that, other than to
keep it as an archive.

Data is maintained directly in the web app, for instance creating a
new Member account, or withdrawing one etc.  Also equity payments
could be entered directly if they happen outside of the POS, e.g. when
someone mails a check.

But equity payments still likely will happen in the POS also.  And for
this to work "seamlessly" it means Rattail must monitor the POS
Transactions which occur, at whatever frequency is acceptable.  Near
real-time is possible and in some cases necessary for sake of dynamic
coupons etc.  But in other cases a nightly processing of the previous
day's transactions may be sufficient.