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

Finally again there is the concept of 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.