Add more docs for Feature Layer

not complete, but progress..

docs/features/transactions/importing/index.rst

@@ -0,0 +1,47 @@
+
+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)

docs/features/transactions/index.rst

@@ -0,0 +1,17 @@
+
+POS Transactions
+================
+
+Presumably all retailers have a dedicated point of sale (POS) system
+which is where most if not all transactions occur.
+
+Rattail is not and likely will never be a POS system, so it's not
+concerned with faciliating the transaction, but rather in "harvesting"
+its data for whatever purposes you may have.
+
+
+.. toctree::
+   :maxdepth: 1
+
+   importing/index
+   reporting/index

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.