Turing Demo Wholesale: shared Power BI and Zoho Analytics report data

This is a fictional UK wholesale business. Every customer, product, deal, invoice,
payment and financial outcome is invented teaching data. No client results are implied.
Data covers January 2025 to September 2026, GBP, with a fixed 30 September 2026 cutoff.
The source arithmetic is checked independently in Python and SQLite. On 25 October
2026, Power BI imported the 63 sales rows and verified sales, cost, gross profit and
invoice count. Zoho Analytics imported those sales rows plus the 18 collections rows,
and verified their totals in a saved native Query Table. Execution checks and genuine
report captures are published at https://turingbi.com/proof/bi-portfolio-demo/execution-checks.txt.
These checks cover prepared CSV imports and native aggregation. Raw joins, live
connectors, scheduled refresh and recipient access have not been tested natively.

Fast import for visual report building
Import these three prepared CSVs separately into either platform:
1. sales-monthly.csv: one row per month and region, with net sales, illustrative
   cost, gross profit and posted invoice count. Monetary columns are GBP decimals.
2. collections-by-customer.csv: one row per customer for all posted invoices through
   the cutoff. Includes gross invoiced, allocated payments, outstanding and overdue.
3. pipeline-latest.csv: one row per customer for the 30 September snapshot.
Do not join and sum the prepared tables together. They answer different questions.

Raw source imports for modelling and reconciliation
customers.csv: one customer, CRM and Books identifiers, region and payment terms.
products.csv: fictional product reference data.
invoices.csv: one invoice, with date, due date, status, net, VAT and gross amounts.
invoice-lines.csv: two lines per invoice, with net, illustrative cost and VAT.
payment-allocations.csv: one allocation; includes payments after the reporting cutoff.
deal-snapshots.csv: deal state per month-end; a deal can recur across snapshots.
calendar.csv: one day through the cutoff.
Raw source money columns ending Pence are integers. Prepared-report money is GBP.
All dates use YYYY-MM-DD. Set identifier fields to Text and dates to Date on import.

Definitions
- Net sales means invoiced net sales for Posted invoices; not recognised revenue.
- Gross profit is a demonstration using illustrative line costs. It excludes all
  overheads, taxes, other income/costs, returns and credit notes.
- Every demo invoice line assumes 20% VAT for arithmetic. This is not tax advice.
- Allocated payments are counted only through 30 September. They are not total cash.
- Outstanding is gross posted invoices minus their allocated payments at cutoff.
- Overdue means a due date before cutoff and a positive outstanding amount.
- Open pipeline is unweighted Open deals at one selected snapshot, not future sales.
- Weighted pipeline uses fictional probabilities; it is not a sales forecast claim.
- Keep pipeline and invoiced amounts separate; no deal-to-invoice attribution is supplied.

Report design for both platforms
Page 1: Sales and margin. Net sales and illustrative gross profit cards; monthly
        trend by region; category drill-down only after modelling raw invoice lines.
        Gross margin must be SUM(GrossProfitGBP) / SUM(NetSalesGBP), never an
        average or sum of row percentages. Show date/region selections clearly.
Page 2: Invoice collections. Invoiced, allocated, outstanding and overdue cards;
        outstanding by customer/region; detailed invoice reconciliation from raw data.
        Label all cards with the fixed reporting cutoff.
Page 3: Sales pipeline. Latest open and weighted pipeline, open deal count and
        breakdown by customer/region. Label snapshot date and fictional probabilities.
Use the Turing white/black/insight-blue palette, short headings and ample space.
Mark every page 'Fictional business and sample data'. Capture screenshots from the
actual report after checking totals; do not present browser mockups as native reports.

Power BI import
For the fast route, Get data > Text/CSV for each prepared file. Give the queries the
names sales_monthly, collections_by_customer and pipeline_latest. Use the measures in
power-bi-measures.dax. They are draft definitions until executed in Power BI.
For the source model, relate customers to invoices and snapshots, invoices to lines
and payment allocations, and products to lines. Avoid direct many-to-many joins.
Use an invoice-date calendar for sales. Keep the pipeline snapshot selection separate.
Check viewer access and refresh in the actual Power BI deployment used.

Zoho Analytics import
Create a private demonstration workspace and import each prepared CSV as its own
table. Name sales-monthly.csv Sales_Monthly and collections-by-customer.csv
Collections_By_Customer to run zoho-native-reconciliation.sql. That SQL was executed
as the saved Portfolio_Reconciliation Query Table; it aggregates each input before
combining totals. The preparation applies the reporting cutoff and excludes void
invoices. Set GBP amounts as decimal numbers, identifiers as Text and dates as Date.
Build charts from their own table, or configure explicit lookups for a source model.
Create an aggregate gross-margin formula from summed gross profit and summed sales;
confirm syntax and results in the workspace. Test permissions and the actual refresh
method used. These normalised CSVs are not native CRM or Books connector exports.

Reconciliation
expected-results.json contains source row counts and unfiltered report totals.
reconciliation-walkthrough.txt follows INV-0001 through its two payment allocations,
shows the doubled invoice amount from a direct join and records the expected totals.
raw-invoice-reconciliation.sql is the accompanying raw-source query, executed in
SQLite by the repository builder. It is separate from the native prepared-table SQL.
Reconcile every screenshot's filters and cutoff to those inputs. For example, an
invoice with two allocations must still be counted once; a future payment must not
reduce outstanding at the cutoff. Record native import, measure, access and refresh
checks separately for each platform before claiming them complete.
