58 lines
2.4 KiB
ReStructuredText
58 lines
2.4 KiB
ReStructuredText
|
|
||
|
|
Reporting
|
||
|
|
=========
|
||
|
|
|
||
|
|
Reporting on POS Transaction data is obviously standard practice.
|
||
|
|
Almost certainly your POS system already provides a way to do that.
|
||
|
|
|
||
|
|
Rattail considers its job here to be, "make more things more easily
|
||
|
|
possible" - which is only needed if your existing reports are lacking
|
||
|
|
in some way. Some specific goals here include:
|
||
|
|
|
||
|
|
If your POS Transaction data is already held in a SQL database, which
|
||
|
|
you can query, then the "hardest" part of a report really should just
|
||
|
|
be crafting the SQL query. For the common use case of generating an
|
||
|
|
Excel file with report data, Rattail can provide basically everything
|
||
|
|
but the SQL statement.
|
||
|
|
|
||
|
|
Reports available to Rattail may be generated via the web app. A
|
||
|
|
report may accept/require certain parameters, which the user provides
|
||
|
|
when generating.
|
||
|
|
|
||
|
|
When a report is generated the output file is "saved" for later
|
||
|
|
viewing in the web app, along with details of who generated it etc.
|
||
|
|
|
||
|
|
It's possible to automate report generation, although at this time it
|
||
|
|
can't be done via web app.
|
||
|
|
|
||
|
|
So that's why you might want to use Rattail for reporting on POS
|
||
|
|
Transaction data generally. But it's often the case that the "raw"
|
||
|
|
(native) schema for POS Transaction data is a bit complex, and this
|
||
|
|
can make crafting the SQL queries difficult.
|
||
|
|
|
||
|
|
Additionally, the POS Transaction data may not even be in a SQL DB to
|
||
|
|
begin with; some store it in a file, e.g. XML.
|
||
|
|
|
||
|
|
And not to mention, this data may not even have everything you need
|
||
|
|
for your report. You may need to query additional systems etc. to
|
||
|
|
supplement the transaction data in order to "complete" the report.
|
||
|
|
|
||
|
|
So first of all that is of course possible. Any report can read data
|
||
|
|
from any "normal" place - SQL DB, file, web API, etc. and combine such
|
||
|
|
data as needed.
|
||
|
|
|
||
|
|
But in the case of POS Transactions specifically, the process of
|
||
|
|
reading data from disparate sources and combining, can be "expensive"
|
||
|
|
in terms of compute power/time. Also you *may* need to do essentially
|
||
|
|
the same thing for multiple reports.
|
||
|
|
|
||
|
|
And this is where Trainwreck comes in - the idea being that you
|
||
|
|
*import* the POS Transactions data from the source, into the
|
||
|
|
Trainwreck DB. It's a *little* like running a one-time report to
|
||
|
|
"translate" the transaction data into a simpler format, with all
|
||
|
|
supplemental data merged in as needed.
|
||
|
|
|
||
|
|
Once the data is in Trainwreck you can write reports against that to
|
||
|
|
your heart's content. They will get to query a simpler schema and all
|
||
|
|
that extra data is right there with it.
|