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 Customer Orders.