Importing

So, the POS is ringing transactions but now you want to import those to another system? Why?

The most frequent “use” for transaction data is probably to report on sales trends etc. That is covered more in the next section, Reporting. And commonly, it is done directly from the POS DB.

But there are other uses for the data, and even if reporting is your only use, it still may be helpful to import it first, as will (hopefully) be explained.

Rattail has a separate / dedicated DB for this scenario, meant to contain only POS (and similar) transaction data. This is referred to as the “Trainwreck” DB; see also Trainwreck Database.

If you do import transaction data then here are some implications:

• you ultimately decide the schema, though default is likely sufficient

• schema is ideally simpler than “raw” POS transaction data

  • (in some cases POS transaction data is not even in SQL DB, but a file)

• SQL reporting can then happen on the (simple!) Trainwreck data

But those are just the obvious ones; here are some more advanced:

• additional calculations may be made, e.g. custom “patronage” amount for each transaction

• other data points known at time of transaction, may be recorded within it; e.g.:

  • current account status of customer or member

  • current [sub]department of each product sold

  • “links” between transaction/items and related customer order(s)

    • (this makes reporting on the Customer Orders possible, or at least much easier!)

• transaction may later be “re-assigned” to a [different] customer, with subsequent reports reflecting the change

  • (e.g. for attributing patronage to correct member for annual refund)