Skip to main content
Quanta Meridian logo
Skip example collections

All examplesExample 5 of 15

KPI Definitions and Data QualityExample 2 of 4 in this collection

View all 15 examplesReturn to KPI Definitions and Data Quality
KPI Definitions and Data Quality

Order and Delivery Data Quality Checks

A repeatable set of checks that stops incomplete or contradictory order records from entering the monthly service report and gives each failed row a specific correction reason.

Project previewOpen full image

A customer receipt dated before warehouse despatch holds one order outside delivery measures until the warehouse systems analyst corrects the source events and an independent retest passes.

The monthly service report is on hold

Incomplete or contradictory orders must be corrected before release.

A reporting analyst combines customer orders, product lines and warehouse delivery events for the monthly Operations review. The data owner, Operations manager and an independent reviewer need to know which rows are fit to use and which report sections would be wrong if a failed row were included.

The release question is specific: can the service report be issued this month, or must orders with missing references, repeated keys, impossible dates and incomplete delivery events remain outside it?

Publish or holdHold unresolved orders; release only after the independent retest passes.

Run DQ-2025-12-INITIAL retained 250 failed rows and held 241 orders. Run DQ-2025-12-RETEST releases the corrected population only after all 19 configured rules pass.

From order record to report decision

Every failed row keeps its reason, consequence and next action.

The Python build loads the saved order model into DuckDB and applies 19 checks from a YAML catalogue that is checked against its schema. A record rejoins the report only when the same rule passes in the independent retest.

Order and delivery records passing through checks, correction and independent retestOrder headers, product lines and delivery events enter 19 named checks. Passing rows continue to the monthly service report. Failed rows are held with a specific correction reason, amended by the responsible data owner and admitted only after an independent retest.MONTHLY RECORDSORDER HEADERS120,000 stable order keysPRODUCT LINES250,000 line recordsDELIVERY EVENTS180,000 dated events19 NAMED CHECKS19 / 19pass after retestsame configuration rerunDQ-01 customer codeDQ-02 product codeDQ-04 receipt before despatchPASSMONTHLY SERVICE REPORT120,000 orders releasedCustomer, supplier and delivery sectionsRELEASEFAIL / WARN / ERRORHOLD RECORDreason + report impactresponsible roleRETESTsecond reviewerPASS
  1. 01
    Read the monthly records

    Order headers, product lines and warehouse delivery events retain their stable keys.

  2. 02
    Run 19 named checks

    Each rule states the field tested, the report consequence, the threshold and the role that can correct it.

  3. 03
    Hold affected rows

    A failed or broken check keeps the record out of the report section it could misstate.

  4. 04
    Correct the source record

    The responsible data owner records the change without overwriting the first-run evidence.

  5. 05
    Rerun independently

    A second reviewer executes the same rules before the reporting analyst releases the monthly service report.

December 2025 test run

The first run holds the report. The corrected run releases it.

Initial failed rows250

Found in 241 distinct orders, with the first decision recorded as HOLD.

Rule outcomes15 fail · 3 warn · 1 error

Pass, warning, failure and execution error remain separate so a broken check is never mistaken for clean data.

Independent retest19 / 19 pass

The corrected view contains 120,000 orders and the report status changes to RELEASE.

What the passing retest proves

The configured rules found no unresolved failure in the corrected customer, product, order line, delivery event, file and reference conditions they evaluate.

What it does not prove

A 19 / 19 pass is not a general completeness score. It does not test every source value, every business rule or the operation of a live warehouse system.

Results from the first run

The check register says what each failure would do to the report.

A missing product code does not become an unexplained quality score. It means the affected delivery cannot be assigned to a product category and must stay outside the supplier score until the product data owner corrects it.

Initial run · DQ-2025-12-INITIAL

The retained CSV contains the evaluated population, threshold, state, failed count, affected report and responsible role for all19 rules.

Rows, report sections and correction history

See the exact orders that stopped the monthly report.

The evidence below is read from the failed-row, report-impact, correction and command output retained by the Python build. It shows which row failed, which report section was affected and who approved the correction for retest.

Failed-row sample250 retained rows
RecordRuleFailed valueReport affected
ORD-0001041delivery_eventsDQ-04Customer receipt does not precede warehouse despatch2024-11-16 before 2024-11-17On-time delivery and order cycle time
OL-0001001order_linesDQ-02Product code exists in the product referencePRD-UNKNOWNProduct service level and supplier score
ORD-0000001ordersDQ-01Customer code exists in the customer referenceCUS-MISSING-01Customer delivery and on-time delivery by customer group
Affected report sections241 orders held
  1. Product service level and supplier scoreProduct data owner
    96 failed rows · 96 orders
  2. Delivered order count and on-time deliveryCustomer service analyst
    36 failed rows · 36 orders
  3. Order volume, sales value and line-level service measuresOrder management data owner
    24 failed rows · 24 orders
  4. Promise-date population and on-time deliveryOrder management data owner
    21 failed rows · 21 orders
  5. Open orders and backlogCustomer service analyst
    20 failed rows · 20 orders
Correction and retest historyIndependent data-quality reviewer
  1. COR-0123
    ORD-0001041 · DQ-04

    Warehouse systems analyst changed 2024-11-16 before 2024-11-17 and marked it approved for retest on 08 Jan 2026, 10:30.

    Retest: FAIL with 1 row to PASS with 0 rows.
  2. COR-0003
    OL-0001001 · DQ-02

    Product data owner changed PRD-UNKNOWN and marked it approved for retest on 08 Jan 2026, 10:30.

    Retest: FAIL with 96 rows to PASS with 0 rows.
  3. COR-0002
    ORD-0000001 · DQ-01

    Customer data owner changed CUS-MISSING-01 and marked it approved for retest on 08 Jan 2026, 10:30.

    Retest: FAIL with 2 rows to PASS with 0 rows.
CLI outputHOLD to RELEASE
ORDER AND DELIVERY DATA QUALITY CHECKS
Source: 120,000 orders | 250,000 lines | 180,000 delivery events
Period: 2024-01-01 to 2025-12-21

DQ-2025-12-INITIAL
  PASS  0 | WARN  3 | FAIL 15 | ERROR  1
  Failed rows retained: 250
  Orders held: 241
  Decision: HOLD

DQ-2025-12-RETEST
  PASS 19 | WARN  0 | FAIL  0 | ERROR  0
  Orders released: 120,000
  Decision: RELEASE

Featured trace: ORD-0001041 / DQ-04
  receipt 2024-11-16 before despatch 2024-11-17 -> warehouse systems analyst
  corrected chronology -> independent retest PASS -> admitted to delivery measures

One order, from hold to release

ORD-0001041 records customer receipt before warehouse despatch.

The sequence is impossible. Including it would produce a negative warehouse-to-customer duration and could distort cycle-time and on-time delivery measures.

  1. 01
    Order record

    Event EVT-QA-1041-R records customer receipt on 2024-11-16. Event EVT-QA-1041-D records warehouse despatch on 2024-11-17.

  2. 02
    DQ-04 fails

    Customer receipt is dated one day before warehouse despatch. Run DQ-2025-12-INITIAL tests 119,974 orders and retains this row in delivery_events for on-time delivery and order cycle time.

  3. 03
    Warehouse systems analyst corrects the event dates

    COR-0123 records the change on 08 Jan 2026, 10:30. Correct the two retained event dates and preserve the amended timeline.

  4. 04
    Independent data-quality reviewer reruns the check

    Run DQ-2025-12-RETEST retests 120,000 corrected orders. The result is PASS: despatch is now dated 2024-11-16 and receipt 2024-11-17.

  5. 05
    Reporting decision

    The order is admitted to delivery cycle-time and on-time reporting. The reporting analyst includes it in the next monthly service-report run.

How the checks run

Another analyst can rerun the checks without relying on this website.

The installable Python package validates the rule catalogue, records execution errors separately from failed data and uses explicit exit codes for a release, quality hold, broken check or invalid configuration.

83 checks completed before the report is shared

The final decision can be checked against the source records and test results.

  • 01

    The shared source contains 120,000 orders, 250,000 order lines and 180,000 delivery events across 24 months.

  • 02

    The initial run retains 250 failed rows and accounts for the 241 orders held from report release.

  • 03

    Every configured rule has a result, severity, affected report section, correction reason and responsible role.

  • 04

    Duplicate failures do not multiply the count of held orders or disappear from the retained failed-row output.

  • 05

    The corrected run passes all 19 rules and the released service-report view contains all 120,000 orders.

  • 06

    The verifier reproduces the page values from the manifest, rule results, failed rows and the DuckDB release view.

A second failure follows the same process

ORD-0000001 arrives with customer code CUS-MISSING-01, which is absent from the customer reference. The customer data owner restores CUS-00001, and DQ-01 passes before the order enters customer-level reporting.

Run the checks again

The clean verifier reruns the package, compares 11 saved file hashes, confirms all seven unit and integration tests and checks 9 screenshots against their required dimensions.

Data and limits

A repeatable example with no client data, not a claim about live operations.

The build uses deterministic non-client order and delivery records from 2024-01-01 to 2025-12-21.

Technical detailsView the data, rebuild steps and detailed limits

The dataset was generated by Quanta Meridian with seed 240605. It covers 2024-01-01 to 2025-12-21; source checksums, the rule configuration and run outputs are retained with the build.

Passing these checks covers only the configured fields, references, sequences and thresholds. It does not demonstrate live monitoring, production permissions or operational service levels.

  • Passing checks cover only the configured fields, references, sequences and thresholds; they do not prove that every source value is correct.
  • The generated order and delivery records do not measure a real organisation or its service performance.
  • The local build does not demonstrate live monitoring, production permissions or enterprise incident management.

More examples in KPIs and Data Quality

OL-0001001 moving from PRD-UNKNOWN through a held supplier report, correction to PRD-01001, an independent PASS and release of Product category 06 and £5,747.91

Supplier reporting

Reporting Data Issue and Retest Register

A missing product code causes one supplier category to disappear from the monthly report. The product data owner corrects the reference table, a second analyst reruns the failed check and the reporting owner decides whether to release the report.

What it helps answer: Has the missing mapping been corrected and independently retested well enough to release the supplier report?

Platform
Python, DuckDB, SQL and Excel, with Microsoft Lists and Power Automate deployment designs
Data scale
120,000 orders, 250,000 lines and 180,000 delivery events; 60 incidents across 6 reporting cycles, verified
Project status
The Python, DuckDB, SQL and Excel files pass all 28 controls. The Microsoft 365 workflow has not been deployed to a live tenant.
View Reporting Data Issue and Retest Register

Next step

Check the records before the monthly service report.

Start with the measures people dispute or the failed checks that need clearer ownership before reporting.

Discuss a report check