54 lines
2.5 KiB
ReStructuredText
54 lines
2.5 KiB
ReStructuredText
|
|
||
|
|
Household / Shared Accounts
|
||
|
|
===========================
|
||
|
|
|
||
|
|
A common scenario is where a Customer (or Employee, or Member) is able
|
||
|
|
to "share" benefits of their account, with their immediate household.
|
||
|
|
There may be other variations but we'll stick with that example here.
|
||
|
|
|
||
|
|
Although to clarify, while many e.g. retail food co-ops may consider
|
||
|
|
the "Household" concept to be an extension of a "Member" account
|
||
|
|
specifically, Rattail instead considers it a logical extension of the
|
||
|
|
"Customer" account. This is because the benefits which are extended
|
||
|
|
to the household normally apply to "shopping" specifically, and
|
||
|
|
Rattail uses the "Customer" concept to represent that. (Same holds
|
||
|
|
true for a more traditional retailer which might extend benefits to
|
||
|
|
the Household of an Employee - the Household will still fall under a
|
||
|
|
Customer account logically.)
|
||
|
|
|
||
|
|
So it might be possible for Rattail to add a broader / more generic
|
||
|
|
"Household" concept later, but for now it's all about Customers. (And
|
||
|
|
a Member account is normally tied to a Customer account, so it's not
|
||
|
|
much more than a difference of semantics.)
|
||
|
|
|
||
|
|
Okay! With that out of the way...
|
||
|
|
|
||
|
|
Household accounts can be tricky. For instance are these people
|
||
|
|
actually tracked in your system? (Do they need to be?) If so are
|
||
|
|
they tracked as separate accounts or just minimal (e.g. name) info
|
||
|
|
somehow tacked onto the main account? In particular how are the
|
||
|
|
accounts represented in your POS system?
|
||
|
|
|
||
|
|
Rattail can be used to help track e.g. Household-related links between
|
||
|
|
various Person and/or Customer records. What you do with such links
|
||
|
|
is up to you of course, but some ideas:
|
||
|
|
|
||
|
|
If your POS allows for it, you might have Rattail keep the POS in sync
|
||
|
|
for (at least certain types of) changes to Household-related accounts.
|
||
|
|
For instance in the dynamic coupon scenario, let's say you do maintain
|
||
|
|
separate POS accounts for the "parent" Customer as well as the
|
||
|
|
Household "shopper". When a coupon is given it may be enabled for
|
||
|
|
both of the accounts, but then when it is redeemed by either it
|
||
|
|
becomes disabled for both.
|
||
|
|
|
||
|
|
Now, maybe your POS already has a way to link Household accounts, and
|
||
|
|
even a way to handle the dynamic coupon example. But then that sounds
|
||
|
|
like you already have a good enough system and don't need Rattail to
|
||
|
|
be the Household "system" at all. Although it could still be used for
|
||
|
|
reporting and similar needs, etc.
|
||
|
|
|
||
|
|
So if your current situation is "not ideal" then Rattail is here to
|
||
|
|
help in whatever way it can; however it's difficult to describe the
|
||
|
|
scenarios it might best be suited for, until more real-world scenarios
|
||
|
|
are dealt with.
|