65 lines
3.2 KiB
ReStructuredText
65 lines
3.2 KiB
ReStructuredText
|
|
||
|
|
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.
|