rattail/rattail-manual
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add more docs for Feature Layer

Browse source 
not complete, but progress..
This commit is contained in:
Lance Edgar 2022-03-20 13:57:06 -05:00
parent f2fd88fc63
commit db50895459
40 changed files with 998 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

64
docs/features/people/customers/index.rst Normal file
View file

@ -0,0 +1,64 @@
Customers
=========
In many cases it's best for Customer data to live in Rattail (usually
in addition to POS, which is considered the authority). But possibly
not, so let's first look at *why* you might want/need to have it in
Rattail.
And quickly even before that, let's just say that we're defining a
"Customer" simply as a "patron" (shopper) of the retailer. In some
cases Customer data is held not only in POS but also in a separate CRM
system, etc. Your own definition of "Customer" is free to vary a bit
in terms of how you must represent real-world concerns.
If your POS does not expose a web app, then often there will only be a
few machines which can be used for account lookup etc. Rattail web
app can let you view this data directly (if it can be accessed via
SQL), i.e. *without* importing it to Rattail. However such
"dedicated" views for various tables in other systems are not given a
lot of priority in terms of aesthetic or utility.
Importing the data to Rattail means the web app can show you the data
in (hopefully) the "best" way. That's obviously a loaded term but
what is meant here, is that the views for native Rattail data are
given the most attention and are what various other features are built
on top of.
So if we assume you *are* importing Customer data into Rattail, then
what? You can view it, but can/should you edit it? That again
depends on whether or not you can (or how difficult it is to) export
the changes back to the source (or other) systems. It's *possible*
for instance, to allow edits in Rattail web app, which then are
automatically synced back to the POS in real-time (by a separate
datasync daemon process). But that is a more advanced topic, and in
most cases, at least in the beginning, you should only edit data in
one system, which likely is *not* Rattail.
If you want to track *extra* data for Customer records in Rattail,
then things change again. You *would* (probably) want to import the
data to Rattail, *not* allow edit for that particular data, but then
*do* allow edit for only the "extra" fields. With this approach you
get to start tracking that data while avoiding the need to export
anything back to POS etc. Reports can be created in Rattail which
leverage data from both systems.
And speaking of "extra data" - that is essentially what is happening
with the Customer Orders feature in Rattail. Underlying it is the
Customer record itself, which was likely imported from POS, but then
when an order is created, that is just extra data on top which never
needs to be synced back to the POS. See also
:doc:`../../custorders/index`.
Finally again there is the concept of :doc:`../entry/batches`. In
fact when creating a new Customer Order, really you are creating a
batch and then adding items to it, finally "executing" which submits
the order for further processing. But batch logic can be crafted to
do anything you need with regard to Customer data maintenance. And in
some cases a Customer-related batch may be more "accurate" if it does
*not* use Rattail data but instead reads directly from the source
(e.g. POS) when making the batch. Also a "New Customers" batch by
definition would contain data not yet "in the system" - so importing
the data to Rattail is not a requirement in order to use batch
features generally.