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)