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,
:doc:`../reporting/index`.  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 :doc:`/data/trainwreck`.

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)