Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 4 of 5

Impacted reports and extensions

10 min

Listen to this lesson

0:00 / 5:40

Configuration converts. Custom code converts too, but it may no longer work, because the data it reads or the logic it extends has changed. Manufacturing is full of such code: exception reports built on MRP lists, enhancements to MRP, planning interfaces, and extracts for plant reporting. This lesson helps the manufacturing team and Kenji find what breaks and decide what to do.

Where manufacturing custom code breaks

ChangeTypical custom code affectedWhat to check
MRP lists not written by MRP LiveReports and interfaces reading MRP list dataWhether the report still gets data; successor apps or a redesign
Classic MRP reads data via AMDPMRP BAdI implementationsRe-implementation as AMDP BAdIs, even if classic MRP stays in use
New planning fileCode reading or writing the old planning fileUse of the new table and the new setup report
Total dependent requirements droppedReports reading totalsSwitch to individual dependent requirements
Storage location MRP removedCode using storage-location MRP fieldsMRP area records and their fields
SOP not future technologyCustom planning hierarchies, SOP extractsCompatibility scope status and the successor
Logistics Information System in PPReports on LIS info structuresThe LIS in PP simplification item and the analytics successor

Manufacturing changes and the custom code they typically affect. Confirm each against the business impact note.

The MRP in HANA item is specific about extensions: before using MRP Live, re-implement BAdI implementations and extensions of classic MRP as AMDP BAdIs. It adds that some BAdI implementations may need adjustment even if you keep classic MRP, because classic MRP transactions also read receipts and requirements through an ABAP Managed Database Procedure in SAP S/4HANA, and that optimization cannot be switched off. Kenji's team therefore treats every MRP BAdI as affected.

MRP Live runs inside a database procedure, so only AMDP BAdI implementations take part; a classic ABAP implementation is simply not called.
The Sign-Off Table · thesignofftable.com/academy/sap-pp-304
  1. InventoryAll custom objects touching planning, production orders and plant reporting
  2. UsageWhich objects ran in EP1 in the last 12 months; unused code is a deletion candidate
  3. AnalysisABAP test cockpit with SAP S/4HANA checks and the simplification database
  4. DecisionDelete, adapt, replace with standard app, or redesign
  5. TestEach adapted object gets a regression test with expected output
How Kenji's team processes manufacturing custom code.
The Sign-Off Table · thesignofftable.com/academy/sap-pp-304

Do not forget the code at the edges. Interfaces that send planned or production orders to shop floor systems, extracts that feed plant dashboards, and output for order papers all read manufacturing data. SAP Readiness Check includes an integration analysis that inventories IDocs, RFCs and BAPIs, web services, OData services, SAP BW extractors and flat file interfaces, and highlights the ones most likely to be affected by the transition. Use that list alongside the custom code results so no manufacturing interface is left untested.

Use the custom code tools, but do not stop there

The SAP S/4HANA 2025 Conversion Guide explains that custom code is checked against the simplification database with the Custom Code Migration tool or the ABAP test cockpit, and warns that the checks do not yet identify every instance of non-compliant code. The Simplification Item Catalog remains the reference, and SAP states that you also need to test custom code in SAP S/4HANA. Readiness Check adds a custom code analysis view by simplification item category. For a test lead, this means static checks reduce the list; regression tests prove the result.

Delete or retireRarely used and likely broken, e.g. an old SOP extract
Fix and test firstDaily and likely broken, e.g. the morning MRP exception report
Leave and monitorRarely used and probably fine, e.g. a yearly BOM printout
Regression testDaily and probably fine, e.g. a production order print form
Prioritizing manufacturing custom objects by daily use and breakage risk.
The Sign-Off Table · thesignofftable.com/academy/sap-pp-304
The morning exception report shows why static checks aren't enough: it compiles fine and quietly reads MRP lists that MRP Live never writes.
The Sign-Off Table · thesignofftable.com/academy/sap-pp-304

What would you do?

The ATC run shows no findings for Contoso's custom MRP BAdI implementation. Kenji suggests marking it "no change needed". What should Priya ask for?

Key points
  • Reports on MRP lists, MRP BAdIs and planning file code are the usual casualties.
  • MRP BAdIs need AMDP re-implementation, even when classic MRP is kept.
  • Static checks shorten the list; they do not prove that code works.
  • Prioritize by daily use and breakage risk; every adapted object gets a test.

Check your understanding · not graded

Lesson check

  1. 1. A custom report reads MRP list data. What happens after the switch to MRP Live?

  2. 2. Why can an MRP BAdI need changes even if classic MRP stays in use?

  3. 3. What do custom code checks against the simplification database not guarantee?

  4. 4. A custom report is used daily and likely broken. What is its priority?