Rattail Demo

This page describes some features of the public Rattail Demo, at https://demo.rattailproject.org

Please note that you should login as "chuck" with password "admin" to gain full access to the demo.

You can also see the source code for the demo.

CORE-POS

Actually this demo starts with CORE-POS. There is a demo copy of CORE Office installed at https://demo-fannie.rattailproject.org

So everything you see in the Rattail Demo menu, under the "CORE-POS" section, are direct read-only views to the CORE-POS DB (MySQL).

However there are several "native" Rattail tables in the demo, for which data originally came from CORE and should be kept perpetually in sync via the CORE API:

For each, CORE is considered "authority" so a change occurring in CORE should be immediately propagated to Rattail Demo. There may be some tables for which Rattail Demo is also considered authority, in which case if you make a change in Rattail Demo then CORE should be updated immediately also. If a table supports such a 2-way sync then you may notice that you have access to "edit" (etc.) the records within Rattail Demo.

Purchasing

Rattail tries to assign a broad meaning to the word "purchasing" - this is the parent term under which "ordering" and "receiving" also fall. You should think of it like this:

a "purchase" is just that, a purchase made by you the store, to some vendor, regardless of which "phase" it happens to be in
an "ordering batch" is a temporary workspace where a new "purchase" (aka. PO) is being built
when an "ordering batch" is executed, a true "purchase" is created (until then it didn't exist)
a "receiving batch" is a temporary workspace where incoming product is "received" which may or may not involve an existing "purchase"
i.e. may receive "from scratch", or "from purchase" in which case user receives "against" original PO quantities
when a "receiving batch" is executed, a purchase is created (or updated if it already existed) per the new phase and received quantities
additionally, some "purchase credits" for the vendor may be created for tracking purposes

Purchases

So again, in Rattail terms "purchase" is the broad term and so the only records in the demo's Purchases table will be those which have been "truly" created by way of executing an ordering batch, etc.

Ordering

The demo allows you to create a new Ordering Batch. The data isn't that great so probably easiest is to choose "Acme" as the vendor.

Once the batch itself has been created, then you can "populate" the batch. So far the demo only gives you one way to do that, which is to "Edit as Worksheet" - this gives you basically an order form which shows all items available from that vendor, and you can fill it out. (Note that you must type a quantity and then press ENTER to submit the change.)

And when you execute the batch, a Purchase is officially created.

Receiving

Coming soon, to a demo near you, will be a mobile-first single-page app built with Vue.js, which will show how receiving can be done on a phone (ideally with barcode scanner sled).

But for now alas, we must wait until I add that.

Purchase Credits

The software has some logic for handling so-called "credits" with the vendor. So far it's a bit rudimentary and in fact is not exposed within the demo yet.

But if you're curious, all it does is automatically create them when receiving against a PO and a "gap" is noticed. Once a credit is created, it just sits there until a user changes its status, but that again doesn't really affect the system or other data. The credits are there just so you can see their status, but you must manually keep it updated or else there's no point to them.

Shopfoo

This feature is meant to mimic an integration with an e-commerce platform, but specifically one such as Instacart, Freshop, Mercato etc. So basically if you use Instacart, then whenever you encounter the term "Shopfoo" you can think of "Instacart" instead.

The general pattern for "Shopfoo" is where the local product data periodically must be "exported" to the target (Shopfoo) system, by way of e.g. nightly CSV file upload.

What the Rattail Demo does to solve this problem is as follows:

demo's Product data was initially imported from CORE-POS
demo's Product data continues to be updated in real-time, when CORE-POS data changes
demo's Shopfoo Products is a custom table meant to mirror exactly what is on Shopfoo (target) system
nightly, the Shopfoo Products table is updated per latest Products data (from CORE-POS)
nightly, a new Shopfoo Product Export is generated, which is basically a CSV dump of Shopfoo Products table
(demo does not bother "uploading" the export to a Shopfoo server...b/c there is no such thing (I assume), but normally you would want to do that)

That may seem convoluted at first but it's a well-established pattern in the Rattail world. Advantages to this include:

Shopfoo Products (local cache) table gives full visibility at all times, of what "should be" present in Shopfoo itself
plus this table is versioned, so you get a simple but "complete" audit trail for it
exports are all kept in one place, can easily download individual past ones etc.

WooCommerce

Whereas the "Shopfoo" pattern (above) is perhaps more typical these days, with Instacart etc. being so popular, the more traditional e-commerce platforms can be supported as well.

WooCommerce is such a system. In terms of the Rattail Demo, all its product data was exported to a demo WooCommerce store and now Rattail is keeping it in sync going forward. Note that this means, you can edit a product price in CORE-POS and it will "immediately" (within seconds) be reflected in WooCommerce. This is not a 2-way sync; it assumes product data is maintained in CORE (and/or Rattail) but never directly in WooCommerce (WordPress) Admin.

There is also a local cache table for WooCommerce products. This is an exact mirror of all (relevant) fields available via the WooCommerce API. Rattail is able to populate this table by fetching all data from WooCommerce API. When it exports data changes to the API, it knows to update the local cache table. This table may be viewed in the Rattail Demo web app, and can be leveraged by reports etc. as needed.

The other Rattail Demo feature regarding this, is the "cross-reference" buttons available when viewing a product in the native Rattail table, e.g. this one.

Batches

This section is exposed but hasn't received much attention yet. These tools are in production elsewhere but the demo itself hasn't had much testing.

But the ideas are pretty straightforward, outlined below.

Handheld

The Handheld Batches are sort of generic, in the sense that they are expected to come in the form of a simple data file, "records" of which just contain a UPC and case and/or unit counts. Rattail Demo should let you create a new batch by uploading such a data file and selecting the "parser" according to its format. A handheld batch isn't all that useful though - its primary purpose is to give a single entry point for such handheld data files. Executing a handheld batch should let you "convert" it to either a label or inventory batch. (Others would be possible but that's what the demo allows.)

Inventory

Inventory Batches represent a way to enter new inventory counts "en masse" to the system(s) involved.

TODO: should say more about this, but again, it hasn't received much attention yet...

TempMon

This is a "side project" for Rattail in a sense. There is a way to monitor temperatures in real-time and send alerts if they exceed some threshold etc. (I'm sure there are many ways.) Rattail Demo "fakes" the temperature probe itself, by generating random data, but otherwise it is setup like normal.

Clients

In the tempmon parlance, a "client" is a Raspberry Pi which runs the rattail tempmon-client software. This client device has attached to it, one or more "probes" which are covered next.

The client software is responsible for taking readings from each probe periodically, and writing that data to the server.

Probes

A "probe" is the actual component with a thermometer and which can take temperature readings. A "client" will have one or more "probes" attached to it.

Each probe has a "device path" relative to the client (Linux) OS.

Appliances

The "appliance" is an optional construct, made available for sake of convenience. It defines a physical unit under refrigeration, i.e. a freezer or cooler. Each probe may be assigned to only one appliance, although a tempmon "client" may span multiple appliances.