diff --git a/docs/features/people/index.rst b/docs/features/people/index.rst index d3e5432..0df6748 100644 --- a/docs/features/people/index.rst +++ b/docs/features/people/index.rst @@ -6,6 +6,40 @@ Rattail considers the Person to be a central concept, which underpins various other concepts such as User, Customer etc. and ideally ties them together (e.g. one Person may be both a Customer and Employee). +It can be tricky to keep straight all the various relationships +between e.g. a Customer and Person. Here is a quick overview of the +*intended* structure: + +* **Person** - represents exactly one (real) human + +* **User** - represents a user account within the Rattail system. + typically a user associates with one person, but "system" users do + not + +* **Employee** - represents an employee in the org; this is always + associated with one person + +* **Customer** - represents a customer account for the org. this may + have an "account holder" set, which is a person. it also may have + shoppers (next) + +* **CustomerShopper** - represents a "shopper" for a customer account. + these always relate not only to a customer, but also (separately) to + a person who "is" the shopper. the first shopper is usually the + account holder, and is treated as such if no account holder is set + +* **CustomerPerson** - DEPRECATED but documented here for clarity. + there is a table just for connecting person and customer accounts. + it is no longer needed since the customer now has "account holder" + and "shoppers" which are more explicit + +* **Member** - represents a member account for the org. in a retail + context this usually associates with a customer account. it + probably also has an "account holder" which is a person + +* **VendorContact** - represents a contact for a vendor. always + associates with one vendor and one person + Rattail can import this data from other (e.g. POS) systems, but it also can *export* data to other systems. And once this data is in Rattail it can be used for other features as needed; for instance