Add more docs for Feature Layer

not complete, but progress..

docs/features/transactions/reporting/index.rst

@@ -0,0 +1,57 @@
+
+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.