53 lines
2.3 KiB
ReStructuredText
53 lines
2.3 KiB
ReStructuredText
|
|
||
|
|
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.
|