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