Add more docs for Feature Layer

not complete, but progress..

docs/features/custorders/reporting/index.rst

@@ -0,0 +1,52 @@
+
+Reporting
+=========
+
+Reporting on Customer Orders data is possible but as of writing is
+still being worked out.
+
+The asumption here is that you want to track "sales" which are
+attributable to Customer Orders.
+
+The "easiest" way, though potentially inaccurate, is simply to query
+the Customer Orders data and assume that if a given Order's "status"
+reflects that e.g. it has been paid for, then include it in the
+report.
+
+On the other hand the precise amount paid by the customer may or may
+not even be in the Customer Order data.  Even if it is there, is it
+correct, or was it just an "estimate" and really a related POS
+Transaction must be consulted for the true price.
+
+However the Order status likely *is* important on some level, to
+detect cancellations etc.  Presumably if a refund is given, the POS
+Transaction would have that amount, but there likely is nothing to tie
+that back to the particular Order which was canceled.
+
+So at the moment the focus is on recording "links" between a given
+Customer Order and POS Transaction.  This is done by way of a
+Trainwreck DB (see also :doc:`../../transactions/importing/index`):
+
+A transaction is imported to Trainwreck as per usual, but in addition
+to the normal stuff, the transaction is inspected for any "indicators"
+of Customer Orders.  (Often the cashier scans or enters some ID for
+the Order when ringing it up.)  Such indicators are then stored in a
+dedicated place within Trainwreck.  This takes care of the "high
+level" meaning we now have links between a POS Transaction and
+Customer Order.
+
+But really, a POS Transaction has "line items" and so does a Customer
+Order.  So we actually need a link between the relevant line items.
+
+The line item links are established in a second phase.  So the first
+phase is focused on importing POS Transaction data, and we've done
+that.  But now Trainwreck has all those line items and so the
+item-level reconciliation can be done "natively".  Again we already
+have the high-level links, so we fetch a linked pair (Transaction and
+Order) and then crawl each to identify item-level links, and record
+any which are found.
+
+Once that is complete, a Customer Orders report can more easily obtain
+accurate payment amounts from the POS Transaction data (although it
+reads from Trainwreck instead for convenience).  And of course it can
+still leverage the Customer Order status etc. as needed.