People
======

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
:doc:`../custorders/index`.

.. toctree::
   :maxdepth: 2

   entry/index
   users/index
   employees/index
   customers/index
   members/index
   household/index