MRP Live Replacing Classic MRP in S/4HANA

Classic ECC behaviour

S/4HANA behaviour

Project impact

• Custom reports and interfaces that read the classic MRP list expecting a frozen snapshot per run break, because MRP Live does not generate that same persisted list; anything downstream comparing 'last MRP list' to 'current situation' needs redesign.
• User exits and BAdIs written against the classic ABAP-level MRP logic (custom exception messages, custom date logic, custom lot-size adjustments) are silently not invoked when the calculation runs as a database stored procedure, and this is often discovered only when a familiar exception message stops appearing.
• Job scheduling built around several parallel classic MRP variants per plant has to be redesigned around a single MRP Live job, changing how job monitoring, restart, and failure alerting work.
• Materials with sales order stock, engineer-to-order configurations, or unsupported special procurement types have to be segmented out and still planned through classic total planning or its batch wrapper, so the project ends up running two planning mechanisms side by side rather than one.
• Planners lose the habit of comparing a frozen MRP list against the live situation and need retraining on what evaluation now represents 'what changed since the last run'.
• Security roles built around MD01/MD02/MD03 need MD01N added, and audit trails that referenced job variant names by MRP controller need rework since the job structure is different.

Migration actions

• Inventory every custom BAdI or user exit attached to classic MRP and determine, one by one, whether the equivalent hook exists under MRP Live; this is a gate item, since silently losing exception logic at month end is a production incident, not a defect ticket.
• Identify every material, plant, or procurement combination that is not supported by MRP Live (sales order stock, engineer-to-order, unsupported special procurement) and formally route it to classic total planning or its batch tool; this segmentation has to be agreed before cutover, not discovered afterward.
• Rebuild the job scheduling chain around MRP Live's single-job model, replacing the old variant-per-controller split, and rework monitoring and restart logic accordingly.
• Retire or rebuild custom reports depending on the persisted classic MRP list, replacing them with logic based on the current stock/requirements list.
• Update security roles to include MD01N and plan the eventual phase-out of reliance on MD01/MD02/MD03 as the default entry point.
• Run a parallel comparison of MRP Live output against classic MRP output on production-scale data before cutover, checking planned order dates and exception messages, not just runtime.
• Train MRP controllers explicitly on the loss of the frozen MRP list and on the new evaluation path for identifying what changed since the last run.

Whose problem this is

Common pitfalls

• Sandbox testing with a small material master sample shows MRP Live 'just working', but in production with millions of materials the custom BAdI logic that silently stopped firing is only noticed at month end when a shortage that used to generate an exception message goes unflagged.
• Teams assume MD01/MD02/MD03 are fully retired and stop maintaining them, then discover late that a scenario segment (sales order stock, engineer-to-order) still depends on them permanently, not just during transition.
• Storage location MRP or specific special procurement combinations behave differently and this only surfaces for a small subset of plants that were not in the test scope.
• The custom development inventory is done at blueprint level from documentation rather than by walking the actual attached exits, so the count of affected BAdIs is understated and real gaps appear only in integration testing.
• The planning file entry consistency check and rebuild before go-live is treated as optional cleanup rather than a mandatory technical gate, and materials silently do not get planned after cutover because their planning file entries were never regenerated correctly.