Lesson 3 of 6
Data cleansing and conversion
9 min
Listen to this lesson
A system conversion moves everything, including what is wrong. In an IS-U system that has billed for fifteen years, a lot is wrong in small ways: installations that cannot be billed, open billing orders from years ago, meter reading results stuck in implausible status, devices installed in two places on paper. Each of these may be harmless today and break a mock conversion, a billing run or a comparison tomorrow. Cleansing starts a year before the first mock, not a month.
What to cleanse
| Area | Typical issue | Why it matters for the move | Owner |
|---|---|---|---|
| Billing orders | Old open billing orders never billed | Unbilled consumption and outsorts appear after conversion | Billing team |
| Meter reading results | Results in implausible or unchecked status | Estimated bills and complaints in the first cycle | Meter reading team |
| Device installations | Devices installed but not billing-relevant, overlapping time slices | Missing charges, billing errors | Device management |
| Installation facts and rates | Expired rate data, operands without values for current periods | Billing errors or wrong amounts | Rates team |
| FI-CA open items | Very old items, unclear clearing, suspense items | Reconciliation noise, dunning errors | FI-CA team |
| Business partners | Duplicates, missing addresses, inconsistent roles | Front office and bill delivery problems | Customer data team |
IS-U data areas to cleanse before conversion.
Northwind's first data health check (illustrative) found 3,900 open billing orders older than six months, 11,200 meter reading results in implausible status, 640 installations with overlapping device installation periods and 27,000 contract accounts with open items older than seven years. None of these block the conversion technically. All of them distort the billing comparison, because a parallel run cannot tell a conversion defect from a legacy defect unless the legacy noise is gone or labeled.
The conversion itself
Technically, an IS-U conversion is a system conversion like any other (sap-s4t-102): Readiness Check, simplification item checks, custom code analysis, SUM with the database migration if the system is not on SAP HANA, then finance and follow-up activities. What is specific is the industry content: Utilities-specific simplification items, custom billing logic in customer-specific operands, variants and enhancements, and the many batch chains (mass billing, invoicing, bill print, dunning) that must be re-scheduled and re-tested.
| Step | Utilities-specific attention |
|---|---|
| Readiness Check and simplification items | Check the Utilities and FI-CA items and their notes for your target release |
| Custom code | Customer-specific billing variants, invoicing enhancements and bill print forms |
| Business partner | Customer/vendor integration where BPs are linked to customers or suppliers outside FI-CA |
| Mass activities and batch chains | Job chains for billing, invoicing, print and dunning re-created and timed |
| Interfaces | Meter data, bill print service, payment providers, regulator reporting |
Conversion steps with Utilities-specific attention. Check the simplification list for your release.
What would you do?
Six weeks before Mock 1, Northwind still has 11,200 implausible meter reading results. The meter reading team says half are from customers who moved out years ago. What do you recommend?
What goes wrong in testing
- Cleansing is measured once and never again, so new bad data accumulates between mocks.
- Known exceptions are not passed to the comparison team, who then investigate them as conversion defects.
- Custom billing logic is tested only by compiling the code, not by billing the contracts that use it.
- Batch chain timing is not measured, so the first production billing cycle overruns its night window.
- MeasureHealth check per area: counts of open billing orders, implausible reads, overlapping installations, old open items
- Set targetsPer area and mock, agreed with each data owner
- Cleanse in ECCBusiness teams fix what they can, through normal transactions
- Label the restKnown exception list with keys, handed to the comparison team
- Re-measureBefore and after each mock; counts must match across the conversion
Northwind's targets (illustrative) for Mock 1 were: open billing orders older than six months below 500, implausible reads below 2,000, zero overlapping device installations, and every FI-CA item older than seven years either cleared, written off under policy, or labeled. Mock 2 tightened each target. The progress chart went to the steering committee every two weeks, because cleansing competes with daily operations for the same people.
Cleansing is also the moment to retire what the new system should not carry. Rate categories no longer used by any active installation, obsolete dunning procedures and custom reports nobody runs can be closed in ECC so they do not need testing after conversion. Every object removed before Mock 1 is one less object in the regression scope, which is the cheapest test reduction available.
- Cleanse a year ahead: billing orders, meter readings, device installations, rates, FI-CA items, partners.
- Label what cannot be fixed so the comparison can separate legacy noise from new defects.
- Utilities conversions need extra care for custom billing logic, batch chains and interfaces.
- Run the same health check before and after each mock; counts must match.
Check your understanding · not graded
Lesson check
1. Why cleanse IS-U data before the first mock?
2. What should happen to data issues that cannot be fixed in ECC?
3. Which Utilities-specific conversion item needs functional testing, not just compiling?
4. What does running the same health check after a mock prove?