Runs quality rules on live master data, routes each failing record to its steward with the fix options, and writes the correction back to the ERP.
Today a data quality report arrives monthly as a spreadsheet with thousands of rows, and the fixes are typed into the ERP when someone has time. Many of the same records appear on the next report.
The app runs each active rule on the live tables and lists every record that fails, with the rule, the field, the current value, the severity and the steward responsible for that object and plant. The steward sees the record with the failing field highlighted and a suggested value from similar records, and either sets the value, asks the business owner for it on the same screen, marks an exception with a reason and an end date, or merges a duplicate. A mass fix applies the same correction to every record with the same rule, with a preview and the master data lead's approval above 50 records. Each correction goes through the ERP change interface, the rule runs again within seconds, and the issue closes when the record passes.
| Lane | Does |
|---|---|
| Data steward | reviews the failing records of the object and area, chooses the fix |
| Business owner | planner, buyer or sales operations: supplies the missing value when asked |
| Master data lead | approves mass fixes above 50 records and exceptions on critical rules |
| Data quality analyst | writes and tunes the rules, sets severity and steward groups |
Every screen renders for desktop and mobile; portal screens are the same screens delivered to an outside login.
| Screen | What is on it |
|---|---|
| S01 Issues | grid of rule, record, field, current value, severity, steward, age; filter by object, plant and rule; open, assign and mass-fix buttons |
| S02 Record fix | the record's fields with the failing field highlighted, the rule in plain words, suggested value from similar records, fix options: set value, ask owner, exception with reason and end date, merge duplicate; save |
| S03 Ask the owner | message to the planner or buyer with the record link and the field to supply; reply field that writes the value into the fix |
| S04 Mass fix | records with the same rule and the same correction, preview of each write, count; approve |
| S05 Rules | rule list with object, condition, severity, steward group, active flag; edit; test on live data with the count of failing records |
| S06 Board | records passing every rule by object, open issues by rule and steward, fixed per week, age of the oldest issue |
The first object is the main one; each system page shows the real table or resource behind every handler.
| Object | Why the app reads it | See it on |
|---|---|---|
| Material master | material records: status, plant data, lead time, type | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Supplier master | supplier records: country, terms, block, purchasing organisation | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Customer master | customer records: sales organisation, terms, block | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Purchase order line | open orders on records with an open issue, to show the effect of a fix | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Object | What changes |
|---|---|
| Material master | field corrected through the material interface; exception flag recorded beside the record |
| Supplier master | payment terms, country or purchasing data corrected; duplicate flagged for deletion |
| Customer master | sales organisation data completed or corrected |
Start: A record that fails one of the active quality rules, such as an active material with a lead time of 0, a supplier with empty payment terms, or a customer with an empty sales organisation.
# start criterion, in canonical fields; each system page shows it in that system's fields
({material.status} = 'active' and {material.lead_time} = 0) or {vendor.terms} = '' or {customer.sales_org} = ''| Step | Moves when |
|---|---|
| Issue detected | record fails an active rule; issue created with severity and steward |
| Assigned | steward of the object and plant sees it on S01; the clock for the severity starts |
| Fix chosen | value entered, owner asked and replied, exception recorded with reason and end date, or duplicate merged |
| Approved where needed | mass fix above 50 records, or an exception on a critical rule, approved by the master data lead |
| Written back | record changed through the ERP interface; rule re-run within seconds; issue closed when the record passes |
| Component | Trigger → action → outcome |
|---|---|
| grd_issues | on load → run each active rule on the live tables → list failing records with severity, steward and age |
| btn_fix | on click → validate the new value against the field's rules → call the ERP change interface, re-run the rule, close the issue when the record passes |
| btn_ask_owner | on click → send the question with the record link to the owner → place the reply value into the fix and notify the steward |
| btn_mass_fix | on click → preview the writes for the selected records → send to the master data lead above 50 records, then write each record and report the result per row |
| Step | Time limit and escalation |
|---|---|
| Critical severity | 1 working day, then the master data lead is copied |
| Standard severity | 5 working days, then the steward's lead is reminded |
| Owner reply | 2 working days, then the steward is reminded and may set an exception |
Names, places and figures are illustrative; the pattern is the catalogue's.
On Monday at 08:00 the app listed 312 open issues for the Chennai plant, 41 of them critical: active materials with a lead time of 0, which planning treated as available today. Ravi, the planning data steward, fixed 30 from the suggested values by 09:30 and asked 3 buyers for the rest; 2 replied before lunch. A mass fix of 118 supplier records with empty payment terms went to the master data lead at 10:15 and reached SAP by 11:00. The board showed 97 percent of materials passing every rule on Friday, up from 91 percent the week before.
The objects with their real names, the criteria in that system's fields, the write interface and what to set up first.
Material master read from MARA · MARC · MAKT; also on SAP ECC.
Open the S/4HANA page →Material master read from Product Hub REST: itemsV2; also on Oracle E-Business Suite.
Open the Oracle Fusion page →Material master read from CONFORMED.MATERIAL; lakehouse.
Open the Snowflake page →Material master read from silver.material; lakehouse.
Open the Databricks page →Other systems connect through the same handlers; see how SmartApps connect.
About 30 minutes to a first running screen on your live rows, and 5 working days to the production-grade version described here, most of it spent agreeing screens and criteria with the process owner.
Any of SAP S/4HANA, Oracle Fusion Cloud, Snowflake, Databricks, with the objects read in place; the pages above show the objects and the write path for each. Two systems at once is one handler per object per system.
Every role in this app is inside the company; an outside role can be added as a lane with a portal screen.
Every step, value, decision, notification and write-back acknowledgement of every instance, with the version of the app, append-only.
Bring the process and the systems it touches. In the first session we register the data handlers, draw the levels or the lanes and run the first screen on your live rows.