Skip to main content
Quanta Meridian logo
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.

Executed Python validationOpen 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?

From source record to report decision

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

The Python build loads the retained order model into DuckDB and applies 19 checks from a schema-validated YAML catalogue. 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 rerunPASSMONTHLY SERVICE REPORT120,000 orders releasedRELEASEFAIL / 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.

Executed December 2025 run

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

Initial failed rows250

Retained against 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 release decision changes to RELEASE.

Native rule results

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.

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
    Source order

    ORD-0001041 has customer receipt on 2024-11-16 and warehouse despatch on 2024-11-17.

  2. 02
    DQ-04 fails

    Customer receipt is dated one day before warehouse despatch. The order is held from delivery measures.

  3. 03
    Warehouse systems analyst corrects the event dates

    Correct the two retained event dates and preserve the amended timeline.

  4. 04
    Independent data-quality reviewer reruns the check

    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.

Configuration, execution and retained evidence

The project can be run and challenged without reading the 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.

Rebuild and validation

The release result is tied back to retained source and test outputs.

  • 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 type remains traceable

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.

Data and limits

A reproducible non-client example, 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 documentationOpen the retained data, rebuild command and detailed limitations

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.

Data Quality SolutionAnalytics Engineering SolutionKPI definitions and data quality projects

More work in KPIs and Data Quality

Promotional artwork for Reporting Data Issue and Retest Register; inspect the project page for native evidence.

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.

Decision: 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
Maturity
Native Python, DuckDB, SQL and Excel build verified with 28 of 28 controls passing; no live Microsoft 365 tenant claimed.
Inspect this example

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-release check