80 lines
3.6 KiB
ReStructuredText
80 lines
3.6 KiB
ReStructuredText
|
|
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.
|