48 lines
1.7 KiB
ReStructuredText
48 lines
1.7 KiB
ReStructuredText
|
|
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)
|