Lesson 5 of 5
Planning P2P regression after conversion
9 min
A system conversion keeps your configuration and data, which tempts people to say "it's the same process, just a quick smoke test". It is the same process running on a changed platform with changed master data objects, changed tables, changed transactions and adapted custom code. Regression testing proves that what worked in ECC still works, and it focuses hardest where simplification items touched the process.
Prioritize by simplification impact
| P2P area | Simplification items touching it | Regression focus | Priority |
|---|---|---|---|
| Supplier maintenance | Business partner, CVI | Create and change Lakeside as BP with FLVN00/FLVN01; vendor number rule; authorizations | High |
| Purchase orders | Classic transactions, approvals, output, material number | ME21N and Fiori apps; approval behavior; PO output to suppliers | High |
| Goods movements | MATDOC, retired MB transactions | Every movement type in use through MIGO; stock before/after | High |
| Invoice verification | Indirect (vendor data, GR/IR on converted open items) | Invoices for converted open POs; blocks and releases | High |
| Payments | Business partner bank data | Payment run for converted suppliers; bank file format | High |
| Rebates | Subsequent settlement replaced | Condition contracts, accruals and settlement | High if used |
| Reports and interfaces | MATDOC, BP, material number | Output comparison; interface runs end to end | Medium to high |
Contoso's P2P regression priorities after conversion.
Use converted data, especially open items
Regression after a conversion should run on converted data, because that is what users will work with on Monday morning. Open purchase orders, partially received POs, GR/IR open items, blocked invoices and supplier open items all come across from ECC. Test that they continue: receive the rest of a partially delivered PO, invoice a PO that was received in ECC, release an invoice blocked in ECC, and pay supplier items that were open at conversion. These "in-flight" cases catch problems that new transactions created in SAP S/4HANA never touch.
- Sandbox conversionLearnFind simplification item issues, custom code impact and data problems
- Mock conversion 1Regression cycle 1Full P2P regression on converted data; reconciliations
- Mock conversion 2Regression cycle 2Retest fixes; timed conversion; user acceptance on converted data
- Dress rehearsalFinal checkConversion and a smoke regression run exactly as planned for production
- ProductionBusiness validationPost-conversion checks and reconciliations before users start
Reconciliation is part of regression
Compare key figures before and after each conversion: number of open POs and open quantities per plant, stock quantity and value per plant and storage location, GR/IR open items and balance, supplier open items and balances in company code 1710. Differences must be zero or explained. These comparisons are the fastest way to find a data problem, and they are evidence the auditors will ask for.
Building a reusable regression set
The conversion is not the last time P2P needs regression. SAP S/4HANA receives feature packs and upgrades, and each one raises the same question: does procure-to-pay still work? Build the conversion regression set so that it can be reused: give every test a clear expected result, keep test data recipes (which supplier, material, plant and quantity to use), and record which simplification item or risk each test covers. Tests that run often and change rarely are good candidates for automation with the tools your program has approved. After go-live, the same set becomes the baseline for every release, so investing in it once pays off many times.
What would you do?
Two weeks before the production conversion, Grace asks whether P2P regression can be reduced to five smoke tests, because the last cycle passed. What is the best answer?
- Regression after conversion focuses on P2P areas touched by simplification items.
- Run it on converted data and include in-flight open items.
- Reconcile open POs, stock, GR/IR and supplier balances across each conversion.
- Define sign-off criteria for the converted process up front and check them before each go/no-go.
Check your understanding · not graded
Lesson check
1. Which P2P scenarios should get the highest regression priority after conversion?
2. What is an in-flight test case?
3. Which figures should be reconciled across a conversion?
4. Why run regression on converted data rather than only on new test data?