
Contents
- What the SAP PP module does
- Discrete, process and repetitive manufacturing
- Discrete manufacturing
- Process manufacturing (PP-PI)
- Repetitive manufacturing
- How the planning cycle runs
- MRP Live and embedded PP/DS in S/4HANA
- MRP Live
- Embedded PP/DS
- When IBP takes over
- Master data: where most implementations break
- Readiness checklist before the first MRP run
- Integration points and failure modes
- Frequently asked questions
- Next step
SAP PP stands for Production Planning. It is the SAP module that turns demand into a production plan, then runs production orders from release through confirmation to cost settlement.
PP takes forecasts and sales orders, checks them against stock, bills of materials, routings and capacity, and proposes what to make, what to buy and when. In SAP S/4HANA it sits in the manufacturing area alongside Materials Management (MM), Quality Management (QM) and Controlling (CO).
This guide is for plant managers, planners and project leads. I have implemented PP in discrete, process (PP-PI) and repetitive manufacturing, so the guide covers all three. The short answer on where PP breaks is master data.
I once worked with a team at a packaging plant that had over 400 production orders a week. Without PP, they were juggling spreadsheets and sticky notes. After implementation, they did not become perfect, but they stopped drowning.
PP sits at the centre of the logistics chain. It takes demand and works backwards through materials, capacity and timing to generate production proposals. The functions, in the order demand flows through them:
- Sales and operations planning (SOP): high-level volumes based on forecasts and market expectations
- Demand management: converts those volumes into planned independent requirements (PIRs) that drive MRP
- Material requirements planning (MRP): works out what to produce or buy, when and in what quantity, using stock, lead times and open orders
- Capacity planning and levelling: shows work centre overloads before they reach the shop floor
- Production execution: creates, releases, schedules and confirms orders through to completion and settlement
In S/4HANA, classic SOP is compatibility scope, and SAP points customers to IBP for that job. More on both below.
PP is not one way of running a plant. It supports three manufacturing styles, and the choice drives which order type, which master data and which costing approach you configure. Many plants run more than one.
The table compares the three as SAP delivers them.
| Style | Typical industries | Execution object | Core master data | Costing |
|---|---|---|---|---|
| Discrete manufacturing | Machinery, electronics, car parts, defence equipment | Production order | BOM, routing, work centre | By order, settled at closure |
| Process manufacturing (PP-PI) | Food, beverages, chemicals, pharmaceuticals | Process order | Master recipe, resources, BOM | By order, with co-products and by-products |
| Repetitive manufacturing | Packaging, consumer goods, high-volume lines | Planned orders on a run schedule | Production version, production line, rate routing or routing | By period |
Discrete manufacturing
Discrete is the default most people mean when they say "SAP PP". MRP creates planned orders, planners convert them into production orders, and each order carries its own components, operations and costs. It suits products built in distinct lots, often to order, where each order needs tracking.
Process manufacturing (PP-PI)
PP-PI (Production Planning for Process Industries) handles batch and recipe-based production. It replaces production orders with process orders and routings with master recipes, and it adds co-products, by-products and batch traceability. In regulated industries such as pharmaceuticals and food, that batch-level trail is a compliance requirement, not a nice-to-have.
Repetitive manufacturing
Repetitive manufacturing suits the same products made on the same lines over long periods. Instead of individual orders, planning runs in time buckets on a run schedule, and operators confirm directly against planned orders. SAP's repetitive manufacturing documentation describes the period-based planning and the backflush that posts component consumption when the finished quantity is confirmed.
The trade-off is detail. Repetitive manufacturing removes order handling overhead, and costs settle by period rather than by order. If you need cost and traceability per lot, discrete or PP-PI is the better fit.
The flow from demand to completion has five stages. In practice it rarely runs without interruption, but this is the structure PP is built to manage.
- SOPVolume targets from forecasts
- Demand managementPIRs that drive the MRP run
- MRPPlanned orders and purchase requisitions
- Production executionOrders released, materials staged
- ConfirmationLabour, quantities and goods movements booked
SAP reflects what actually happened on the floor
Demand management generates PIRs. A PIR is a forecast: we expect to need this quantity of this product at this time. PIRs are the input to MRP, and mistakes here cascade. A client once uploaded duplicate PIRs covering three months. No one noticed until production started overordering everything.
MRP is the planning engine. It nets PIRs and sales orders against stock and open receipts, then creates planned orders for in-house production and purchase requisitions for bought-in parts. A run built on inaccurate master data produces noise that planners spend weeks chasing.
Execution and confirmation close the loop. Orders are released, materials are staged and operations run at the work centres. Labour, quantities and goods movements are then booked, and the system reflects what happened on the floor, provided people confirm on time.

If you are moving from ECC, these are the planning changes that affect design and data. The wider migration paths are in my ECC to S/4HANA migration guide.
MRP Live
MRP Live (transaction MD01N) is SAP's recommended planning run in S/4HANA. It runs inside the SAP HANA database, can plan one or several plants in a single run, and does not write the classic MRP lists. SAP's MRP Live learning module is a good primer, and the SAP Help page on working with MRP Live has the configuration detail.
Three other changes come with it:
- Production versions are mandatory for in-house produced materials. MRP Live will not explode a BOM without one, so ECC customers who relied on BOM selection methods need to create them during conversion.
- MRP areas replace storage location MRP. Storage locations planned separately in ECC need an MRP area in S/4HANA.
- SOP, MRP lists and forecast-based planning are compatibility scope. Their usage rights are time-limited and differ by contract type, and SAP has changed the dates more than once. Check SAP Note 2269324 against your own contract before you design around them.
Embedded PP/DS
PP/DS (Production Planning and Detailed Scheduling) is the advanced planning engine that used to live in SAP APO. In S/4HANA it is embedded, so there is no separate APO system to run. It adds finite scheduling, setup sequences and pegging across BOM levels.
MRP Live and PP/DS split the work by material. Materials flagged for advanced planning in the material master go to PP/DS, and the rest stay in MRP Live. SAP's PP/DS learning content suggests planning critical products on bottleneck resources in PP/DS, and less critical, consumption-based materials in MRP Live.
I have used both MRP Live and embedded PP/DS on implementations. Two practical points matter more than the feature list:
- Plan everything that shares a bottleneck resource in PP/DS. If half the products on a constrained line stay in MRP Live, finite capacity planning on that line does not work.
- Exclude PP/DS materials from the MRP Live planning scope. Otherwise a later MRP Live run reschedules them and the detailed scheduling result is lost.
For a side-by-side view of what MRP Live, PP/DS and IBP each plan, see my comparison of MRP Live vs PP/DS vs IBP.
Check what your contract covers before you design around PP/DS.
PP plans the plant: what to make, on which line, in which week. SAP Integrated Business Planning (IBP) plans the business above it. It is a cloud product covering sales and operations planning, demand forecasting, inventory planning and supply planning across the network.
I have sent clients to IBP, but only where the case called for it. Some plants run well on MRP Live alone.
Others need PP/DS for a bottleneck line. A smaller group needs IBP because the planning problem is not on the shop floor at all.
The table shows how I separate the three layers.
| Planning question | Tool | Horizon | Typical trigger to move up |
|---|---|---|---|
| What do I make and buy, and when? | MRP Live in S/4HANA | Days to months | Planners overriding MRP on constrained resources |
| In what sequence do I run the line, at finite capacity? | Embedded PP/DS | Hours to weeks | Volume and mix decisions made across plants or regions |
| How much should the business sell, stock and supply? | SAP IBP | Months to years | Multi-site networks, consensus demand, scenario planning |
Signals that point to IBP:
- You need a monthly sales and operations process with finance in the room.
- Demand comes from statistical forecasting across many customers and channels.
- Supply decisions span several plants and distribution centres.
Classic SOP being compatibility scope adds a deadline to that decision. My guide on why SAP IBP matters covers the IBP side in more depth.
If you are still choosing between SAP and other ERPs for a plant, my comparison of the best ERP for manufacturing sets out the options by company size and type.
If you rush master data in an SAP PP implementation, everything else becomes a workaround. BOM accuracy, routing completeness, work center maintenance. None of it is optional.
Master data is the backbone of SAP PP. Not as a saying. As a fact with consequences.
Material master (MRP views). Every manufactured material needs its MRP views set correctly. MRP type, lot size, strategy group, availability check and scheduling margin key each change what MRP does. One missing field in a material master blocked production for a week on a project I was on. One field.
Strategy group. The strategy group controls whether sales orders consume PIRs. If it is wrong, sales orders and forecasts run in parallel instead of netting off, doubling the demand signal with no error message.
Bills of materials (BOM). The BOM defines what goes into a finished product: components, quantities, scrap percentages, sometimes alternatives. The question "do we really need five BOMs for this one item?" has a real answer. Work it out before implementation, not during MRP runs.
Routings and master recipes. A routing defines how something is made: operations, work centres and times. Process industries use master recipes instead. Without one, SAP cannot calculate production duration or check capacity.
Work centres. Work centres carry scheduling formulas, costing links and shift calendars. Keeping them current after go-live is the task that gets dropped. When it is, capacity planning goes inaccurate and the planners stop trusting the system.
Readiness checklist before the first MRP run
Run this sequence before you let MRP loose on migrated data. The owner in brackets is who signs it off.
- Material master MRP views complete for every planned material, including strategy group and lot size (planning lead)
- BOMs validated against what is actually built, with engineering confirming components and scrap (engineering)
- Routings or master recipes exist for every in-house material, with realistic operation times (production engineering)
- Work centre calendars and capacities reflect current shifts (plant manager)
- One valid production version per in-house material, covering the planning horizon (planning lead)
- PIRs loaded once, reconciled to the approved demand plan before the first run (demand planner)
- Open orders and stock reconciled between legacy and SAP (inventory controller)
- A test MRP run on a single plant or MRP area, with planners reviewing exceptions before the full run (planning lead)
PP does not work alone. MM sources what PP requires, SD sales orders consume forecasts, CO tracks actual against standard cost, and QM inspection lots can hold up orders. Each integration point is also a failure point.
I have seen some real disasters over the years, and these are the patterns to avoid.
- Rushing master data migration. I remember one automotive parts company that rushed its BOM and routing migration. It spent six months after go-live fixing production orders that kept failing on data problems. My piece on why SAP data migration fails goes further.
- Replicating legacy processes. The most consistent configuration mistake I see: setting SAP up to work exactly like the old process instead of adopting standard planning logic. The result is an over-configured system that delivers less than PP was designed to.
- Undertesting integrations. Teams that test each module alone discover integration problems in production. Test the full plan-to-produce chain across PP, MM, SD, CO and QM, as set out in my guide to SAP testing.
- User resistance. Experienced planners often resist PP because it takes over work they used to do by hand and judgement. Bring them into configuration early and show them where PP gives them time back.
- Cutting training. I have seen companies spend millions on implementation and then save money by cutting training. Users who do not understand the system create workarounds, and workarounds break the data accuracy MRP depends on.
The table maps each risk to its impact and the mitigation I would put in the plan.
| Risk | Impact | Mitigation |
|---|---|---|
| Incorrect MRP configuration | Stockouts, overproduction, excess procurement cost | Validate MRP types, strategy groups and lot sizing with business leads |
| Inaccurate BOM, routing or recipe | Wrong material requirements, shop floor delays | Involve engineering in reviews before migration |
| Missing production version | MRP cannot explode the BOM or create valid orders | One valid production version per in-house material |
| PP/DS and MRP Live overlap | Detailed schedules overwritten by the next MRP run | Exclude PP/DS materials from the MRP Live planning scope |
| No real-time shop floor feedback | Inaccurate status, late visibility of deviations | Enforce timely confirmations; integrate SAP Digital Manufacturing or another MES |
| Undertrained users | Wrong confirmations, backflush errors, unresolved rework | Role-specific training on real production cycles |
What is the full form of SAP PP?
SAP PP stands for Production Planning. It is the SAP module for planning and executing manufacturing, from demand and MRP through production orders, confirmation and cost settlement.
What is the SAP PP module used for?
The SAP PP module connects demand from forecasts and sales orders to production capacity through MRP. It manages bills of materials, routings, work centres and production versions, and runs production or process orders from creation to settlement.
What is the difference between SAP PP and SAP PP-PI?
SAP PP in the narrow sense covers discrete and repetitive manufacturing, using production orders or run schedules based on BOMs and routings. PP-PI is for batch and recipe-based production in food, chemicals and pharmaceuticals. It uses process orders and master recipes, and adds co-products, by-products and batch traceability.
What is MRP Live in SAP S/4HANA?
MRP Live (transaction MD01N) is SAP's recommended MRP run in S/4HANA. It runs inside the SAP HANA database, can plan several plants in one run and does not create classic MRP lists. Materials flagged for advanced planning are handed to PP/DS.
What is the difference between SAP PP and PP/DS?
PP with MRP Live plans at infinite capacity: what to make and buy, and when. PP/DS adds finite scheduling, setup sequences and pegging for critical materials on bottleneck resources. In S/4HANA, PP/DS is embedded; check with SAP how your contract licenses it.
Does SAP IBP replace SAP PP?
No. IBP plans sales and operations, demand, inventory and supply across the business, usually in monthly or weekly buckets. PP still plans and executes production in the plant.
IBP is SAP's named successor for classic SOP, which is compatibility scope in S/4HANA.
If you are scoping PP for an S/4HANA programme, settle three things first: which manufacturing styles each plant runs, which materials need PP/DS, and whether your planning problem belongs in IBP at all. If you want a second view on that design, talk to me about your SAP programme.
Next step
Running an ERP programme right now?
If this article touched on a programme you are live in right now, a 30-minute conversation usually gets further than another week of internal analysis.




