Part 2 — Master Recipes, Resources & Process Execution (PP-PI)

Process manufacturing — chemicals, edible oil refining, pharmaceuticals, fertilizers, food and beverage — operates under constraints that standard discrete manufacturing cannot satisfy. Materials are bulk, liquid, or semi-solid. Production runs are continuous or semi-continuous. Finished goods cannot be disassembled into their inputs. A batch, once made, is non-reproducible.

SAP S/4HANA addresses this through PP-PI (Production Planning for Process Industries), a discipline built on three master data objects — the master recipe, the resource, and the production version — and an execution engine centered on control recipes, PI-sheets, and process messages. Together, these objects extend the discrete manufacturing model with shop-floor parameter delivery, digital signature enforcement, and closed-loop actual value return, enabling end-to-end traceability from raw material batch to finished goods batch.

This paper — Part 2 of a four-part series on Production Planning in SAP S/4HANA — covers the full PP-PI landscape: master recipe structure and creation, resource master data, production version discipline, batch management, the process order lifecycle from planned order conversion through settlement, the control recipe and PI-sheet execution layer, and the information systems that close the loop on traceability and cost.

SAP S/4HANA Production Planning spans two fundamentally different execution models. Part 1 of this series covered discrete manufacturing: countable units, routing-based execution, work center confirmations. This part covers process manufacturing: bulk and continuous production, recipe-based execution, phase confirmations and PI-sheet-driven shop-floor control.

The distinction is not cosmetic. Discrete manufacturing produces things that can be picked up, counted, and — if necessary — disassembled. Process manufacturing produces things that flow. A batch of refined edible oil, a pharmaceutical tablet run, a batch of fertilizer concentrate: none of these can be returned to their constituent inputs after production. The production record — what was mixed, at what temperature, for how long, with which raw material lots — must be captured at execution time, not reconstructed afterward.

Standard discrete routing (task list type N) provides none of this. It defines work sequence and duration but has no mechanism for embedding shop-floor execution parameters, dispatching those parameters to an operator or process control system, or receiving actual parameter values back. PP-PI fills that gap with the master recipe (task list type 2), a structurally richer object that carries process instructions within phases, supports control recipe generation on order release, and closes the loop via process messages returned from the shop floor.

The PP-PI module is purpose-built for industries where these constraints apply: chemicals, edible oil refining, pharmaceuticals, fertilizers, beverages, food and food processing. What these industries share is the batch paradigm — a standardized production run produces a homogeneous lot with uniform characteristics, that lot is non-reproducible, and regulatory or quality requirements demand full traceability of that lot through the supply chain.

A master recipe is the process industry’s counterpart to a routing, but it carries constructs that routings do not. Where a routing operation defines what work is done and how long it takes, a master recipe phase additionally defines what parameters must be achieved and recorded during execution — temperatures, pressures, mixing durations, yield checkpoints — and delivers those parameters to the operator via a PI-sheet or to an external process control system via a control recipe.

The fundamental structural difference is the process instruction layer embedded within phases. Process instructions are the mechanism by which the master recipe’s execution knowledge is packaged and dispatched at order release. A routing has no equivalent.

The master recipe header anchors the identity and validity of the recipe:

The recipe group / group counter combination is the key by which the production version links a specific recipe to a BOM alternative.

There are two creation paths for a master recipe. The first creates the recipe with direct reference to a material/plant combination. The second creates a standalone recipe group — independent of any material — which can be assigned to materials later. In both cases, the production version is the bridge that connects the master recipe to the Bill of Materials.

The recommended creation sequence in process manufacturing is:

1. Create the production version (Transaction C223) with BOM details entered — the master recipe does not yet exist
2. Create the master recipe (Transaction C201) referencing the production version
3. Return to the production version and update it with the recipe group and group counter generated when the recipe was saved

Creating a production version directly from Transaction MM02 should be treated as an exception. Using C223 ensures complete data entry and the full production version structure is maintained.

Phases are the operational units of a master recipe — the PP-PI equivalent of operations in a discrete routing. Each phase carries:

• Primary resource — the main processing unit (reactor, mixer, filling line) where the phase executes
• Standard values — duration and other activity quantities used for scheduling, costing, and confirmation
• Control key — governs whether the phase is relevant for scheduling, capacity planning, costing, and confirmation (exactly as in discrete routing operations)
• Process instructions — the shop-floor execution parameters embedded in the phase

The control key assignment is the phase-level switch that determines which phases generate capacity requirements, which drive cost collection, and which require operator confirmation. This mirrors the control key mechanics in Part 1’s routing operations, with the addition that PP-PI control keys also govern whether a phase generates a control recipe and PI-sheet segment.

Secondary resources are resources assigned to a phase in addition to the primary resource. Where the primary resource is the main processing unit, secondary resources represent parallel resource usage — labor crews, auxiliary equipment, utilities — that operate concurrently. The distinction matters for both scheduling (secondary resources are capacity-loaded in parallel with the primary) and costing (their activity rates are applied separately to the process order).

Process instructions are defined within phases and carry the shop-floor parameter specifications: temperature setpoints, pressure ranges, mixing durations, yield targets. They are the mechanism by which the master recipe’s execution knowledge is packaged into a control recipe and dispatched at order release.

Process instructions can be defined using characteristics-based process instructions — the classical approach, using classification characteristics to define parameter types and value ranges — or XStep-based process instructions (XSteps), the modern and more flexible approach that is also available in discrete manufacturing. XSteps provide richer structural options and are the forward path in S/4HANA.

A resource in PP-PI is functionally equivalent to a work center in discrete manufacturing. It represents the physical or logical processing unit — a reactor, mixing vessel, filling line, drying oven — at which phases execute. Resources carry the same master data constructs as work centers: basic data, default values, capacities, and costing linkages. The objects are parallel in structure but maintained separately, differentiated by their work center category.

The work center category, configured in customization, controls which fields and tabs are active in the master record and what application area the object serves:

This category-based differentiation is why a resource and a work center, while structurally parallel, are maintained as distinct master data objects. The application area assignment in customization is the mechanism that determines whether an object behaves as a routing work center or a recipe resource.

The standard value key for process manufacturing is SAP4, which uses Duration as the primary activity. This is distinct from the standard value keys used in discrete manufacturing, which typically carry setup, machine, and labor times as separate standard values.

Cost collection from process orders flows through the resource’s cost center and activity type assignments. When a process order phase is confirmed, the system applies the actual activity quantities against the activity rate defined for the cost center/activity type combination, generating actual costs on the process order and actual activity confirmations on the cost center. This is the same CO-PC integration mechanism as in discrete manufacturing — the resource is the object that carries the cost center link, exactly as a work center does in discrete.

The production version in process manufacturing carries a specific creation discipline. In PP-PI, BOM details are entered in the production version first, before the master recipe exists. The production version is a staging object that holds the BOM reference while the master recipe is being created. Once both exist, the production version defines the unique combination of alternative BOM and master recipe that the system uses when creating process orders for a given material and plant.

This is the mechanism by which MRP and the process order creation transaction know which BOM and which recipe to apply. When the master recipe references a production version, all BOM components appear in the Materials view of the master recipe, where they are used for Material Quantity Calculations — the PP-PI feature that dynamically adjusts component quantities when the batch size changes or when one component’s actual quantity forces a proportional recalculation of others.

Batch management is not optional in most process industry environments. The regulatory and operational requirements of pharmaceuticals, food and beverage, chemicals, and similar industries demand end-to-end traceability: which raw material lots were consumed, in which production run, to produce which finished goods lot. Recall management depends on answering these questions rapidly and with certainty.

A batch is a quantity of a specific material produced during a standardized production run. It is homogeneous within the lot and non-reproducible across runs. In a food and beverage context, a batch might be characterized by calories, vitamin C content, protein percentage, and sugar concentration. In pharmaceuticals, by active ingredient potency, moisture content, and particle size. The material master data is valid for all batches of that material; the batch master record carries what makes this lot distinct.

Batch characteristics are defined using the SAP classification system. Characteristics — “Vitamin C Content”, “Moisture %”, “Potency” — are created in the classification system and assigned to the material master. When the system creates a batch master record, those characteristics are inherited by the batch, and the actual measured values are recorded against them after production. This classification-based approach enables batch search and selection at goods issue: the system can filter available batches by characteristic values when allocating raw material lots to a process order.

The system tracks inventory separately for each batch. Raw material batches are managed in stock and issued to process orders at the batch level. The finished goods batch produced by the process order is also managed discretely. Goods issue (movement type 261) and goods receipt (movement type 101) both carry batch references, enabling the system to record exactly which input batches were consumed and which output batch was produced.

The Batch Information Cockpit (Transaction BMBC) provides complete forward and backward traceability:

• Top-down (forward): Starting from a finished goods batch, trace all raw material and semi-finished batches consumed — including the process order and all input batches
• Bottom-up (backward): Starting from a raw material batch, identify all finished goods batches that incorporated it

The cockpit also provides direct access to the batch master record, stock information by batch, and batch expiry date monitoring. In highly regulated industries, the Electronic Batch Record extends this further: it captures not just batch-level goods movements but the complete record of quality inspections, process parameter recordings from the PI-sheet, and any deviations that occurred during manufacturing.

flowchart TD
    classDef planning fill:#fff3e0,stroke:#e65100
    classDef execution fill:#e8f5e9,stroke:#2e7d32
    classDef control fill:#e3f2fd,stroke:#1565c0
    classDef closing fill:#f3e5f5,stroke:#6a1b9a

    A["Planned Order<br>(from MRP Run)"]
    B["Convert to Process Order<br>(COR1)"]
    C["Process Order Created<br>Header + Phases + BOM<br>Components loaded"]
    D["Order Release"]
    E["Generate Control Recipe"]
    F["Send Control Recipe<br>to Destination"]
    G["PI-Sheet Available<br>at Workstation"]
    H["Operator Executes<br>Phase Instructions<br>Records Actuals + Signature"]
    I["Process Messages<br>Sent to S/4HANA<br>(CO54XT)"]
    J["Process Order Updated<br>Actual Quantities + Times"]
    K["Goods Issue<br>(Movement Type 261)"]
    L["Goods Receipt<br>(Movement Type 101)"]
    M["Phase Confirmations<br>Actual Activity Times"]
    N["Technical Completion"]
    O["Order Settlement<br>Variances to CO"]

    A --> B --> C --> D
    D --> E --> F --> G
    G --> H --> I --> J
    C --> K
    J --> L
    J --> M
    L --> N
    M --> N
    N --> O

    class A,B,C planning
    class D,E,F,G,H execution
    class I,J,K,L,M control
    class N,O closing

MRP generates planned orders for process manufacturing just as it does for discrete. The planned order is converted to a process order using Transaction COR1 (create process order with material). The conversion reads the material master, production version, BOM, and master recipe to populate the process order. All master data is copied into the order at creation time — material master, BOM components, master recipe phases, and material quantity calculation data.

The process order header carries the production quantity, scheduled start and end dates, order type, and settlement rule. Below the header: phases with primary and secondary resource assignments and standard values, components from the BOM, and process instructions. SAP pre-configures process order types for standard scenarios:

When the process order is released, the system generates control recipes — one per control recipe destination defined in the master recipe. Control recipe generation can be automated on order release or triggered manually. The control recipe packages all process instruction data from the order’s phases into a structured dispatch object.

Both movements carry batch references. Movement type 261 issues raw material component batches from stock to the process order. Movement type 101 receives the finished goods batch into stock. These two movements, with their batch references, form the foundational layer of the batch traceability chain.

Technical completion closes the process order to further goods movements and confirmations. Order settlement then distributes the variance between planned and actual costs to the settlement receiver — typically a CO-PA profitability segment or a cost center — depending on the settlement rule defined in the order header.

The control recipe packages all production-relevant data from the process order’s process instructions into a structured dispatch object. It contains the process instruction characteristics and their target values (temperatures, pressures, durations, yield targets), the phases to which those instructions are assigned, and the destination type that governs how it is dispatched.

In SAP S/4HANA, the browser-based and ABAP list-based PI-sheets are within the compatibility scope, with limited usage rights governed by the S/4HANA Compatibility Scope Matrix (item ID 444). The PI-PCS interface (destination types 2 and 3) is supported only through Manufacturing Execution Connect (Classic) and sits outside the compatibility scope. New integration capabilities for dispatching process orders to a Manufacturing Execution System — including SAP Digital Manufacturing Cloud — are available via SOAP and OData APIs, which represent the forward path for external system integration in S/4HANA.

flowchart TD
    classDef header fill:#fff3e0,stroke:#e65100
    classDef body fill:#e8f5e9,stroke:#2e7d32
    classDef signature fill:#e3f2fd,stroke:#1565c0

    H["PI-Sheet Header<br>Order No · Material · Batch · Date"]
    P1["Phase 1 Instructions<br>Process Instruction Characteristics<br>Target Values · Tolerances"]
    P2["Phase 2 Instructions<br>Process Instruction Characteristics<br>Target Values · Tolerances"]
    PN["Phase N Instructions<br>..."]
    A1["Actual Value Entry Fields<br>Operator Records Measured Values"]
    A2["Actual Value Entry Fields<br>Operator Records Measured Values"]
    S1["Signature Field<br>Single / Dual / Electronic"]
    S2["Signature Field<br>Single / Dual / Electronic"]
    MSG["Process Message Generated<br>Actuals Packaged for Return to S/4HANA"]

    H --> P1 --> A1 --> S1
    H --> P2 --> A2 --> S2
    H --> PN
    S1 & S2 --> MSG

    class H header
    class P1,P2,PN,A1,A2 body
    class S1,S2,MSG signature

The PI-sheet presents each phase’s process instructions in sequence, with target values and tolerances visible to the operator. Actual value entry fields are embedded directly in the sheet — the operator records the measured value in the same view where the target was defined. Signature fields appear at defined checkpoints.

In GMP-regulated industries, every execution step may require a digital signature confirming the operator reviewed and executed each instruction. SAP supports three signature categories:

Signature fields are defined as part of the process instruction characteristics in the master recipe and are rendered on the PI-sheet at the point where the operator records actual values. The signature records are captured as part of the process message returned to S/4HANA, creating an auditable execution record.

When process messages are received by S/4HANA via Transaction CO54XT, the process order is updated with:

The system verifies process messages before applying updates. Invalid or out-of-tolerance values can be flagged and held for review rather than applied immediately, preserving data integrity on the process order.

The Batch Information Cockpit (Transaction BMBC) is the primary reporting tool for batch traceability. It supports both top-down analysis — starting from a finished goods batch and tracing all input batches and the process order that consumed them — and bottom-up analysis — starting from a raw material batch and identifying every finished goods batch that incorporated it. It also provides direct access to the batch master record, current stock by batch, and batch expiry monitoring.

In highly regulated industries, the Electronic Batch Record extends the cockpit’s scope: it captures quality inspection records, process parameter recordings from the PI-sheet, and deviations, assembling the complete execution record for the batch into a single reviewable document for regulatory submission or internal audit.

Every goods movement against the process order — component issues (261) and finished goods receipts (101) — is documented with a material document accessible from the process order. These material documents carry batch references for both input and output materials, forming the foundational layer of the traceability chain that the Batch Information Cockpit reads.

The process order carries a cost overview showing planned versus actual costs broken down by cost element. Planned costs are calculated at order creation from the master recipe’s standard values and the resource cost center/activity type rates. Actual costs accumulate from three sources as execution proceeds:

• Phase confirmations post actual activity quantities → actual activity costs debited to the order
• Process messages (from PI-sheet actuals) update actual times → additional cost postings where applicable
• Goods issues post actual material consumption at standard or moving average price → material cost component updated

At period-end settlement, the variance between total debits (actual costs on the order) and total credits (standard cost of goods receipt) is settled to the settlement receiver per the order’s settlement rule.

PP-PI is not a bolt-on to discrete manufacturing — it is a parallel execution model purpose-built for the constraints of process industry operations. The master recipe, resource, and production version form a master data triad that mirrors the routing/work center/production version triad of discrete manufacturing but extends it in every dimension that matters for continuous and batch production: process instructions embedded in phases, material quantity calculations for dynamic component adjustment, and the control recipe / PI-sheet dispatch mechanism for closed-loop shop-floor execution.

For any organization operating in pharmaceuticals, food and beverage, or specialty chemicals, batch management is not a configuration option — it is the operating foundation. The system’s ability to track raw material batches through goods issue (261), link them to a process order and a finished goods batch through goods receipt (101), and surface that chain in the Batch Information Cockpit is the mechanism that makes recall management, regulatory compliance, and quality root-cause analysis operationally viable. Organizations that implement PP-PI without activating batch management for regulated materials are building an execution system without its most critical output.

The PI-PCS interface — destination types 2 and 3 for external process control systems — sits outside the S/4HANA compatibility scope and is supported only through Manufacturing Execution Connect (Classic). Organizations currently relying on the PI-PCS interface for MES integration should treat the migration to SOAP/OData API-based integration as a mandatory workstream in any S/4HANA transformation, not a post-go-live optimization. The browser-based PI-sheet (CO54XT) remains in scope and is the recommended path for operator-facing execution where a full MES integration is not warranted.

flowchart TD
    classDef master fill:#fff3e0,stroke:#e65100
    classDef order fill:#e8f5e9,stroke:#2e7d32
    classDef shopfloor fill:#e3f2fd,stroke:#1565c0
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a

    MR["Master Recipe<br>(Task List Type 2 · C201)"]
    RES["Resource<br>(CRC1 · Work Center Category 0008)"]
    BOM["Bill of Materials<br>(CS01)"]
    PV["Production Version<br>(C223 · BOM + Recipe Link)"]
    PI["Process Instructions<br>(Phases · Characteristics / XSteps)"]

    PO["Process Order<br>(COR1 · Header + Phases + Components)"]
    CR["Control Recipe<br>(Generated on Release)"]
    PISH["PI-Sheet<br>(CO54XT · Operator Execution)"]
    PCS["Process Control System<br>(PI-PCS Interface · Mfg Exec Connect)"]
    PM["Process Messages<br>(Actual Values returned)"]

    GI["Goods Issue 261<br>(Component Batches)"]
    GR["Goods Receipt 101<br>(Finished Goods Batch)"]
    CONF["Phase Confirmations<br>(Actual Activity Times)"]

    BMBC["Batch Information Cockpit<br>(BMBC · Traceability)"]
    COST["Process Order Cost Overview<br>(Planned vs. Actual)"]
    SETT["Order Settlement<br>(Variance to CO-PA / Cost Center)"]

    MR --> PV
    BOM --> PV
    PV --> PO
    RES --> PO
    PI --> CR
    PO --> CR
    CR --> PISH
    CR --> PCS
    PISH --> PM
    PCS --> PM
    PM --> PO
    PO --> GI
    PO --> GR
    PO --> CONF
    GI & GR & CONF --> COST
    COST --> SETT
    GI & GR --> BMBC

    class MR,RES,BOM,PV,PI master
    class PO,CR order
    class PISH,PCS,PM,GI,GR,CONF shopfloor
    class BMBC,COST,SETT reporting

The architecture is clean and deterministic. Master data — recipe, resource, BOM, production version — feeds the process order. The process order generates the control recipe. The control recipe drives shop-floor execution via PI-sheet or PCS. Execution generates process messages that return actuals to the order. Goods movements build the batch traceability chain. Phase confirmations and process messages build the cost record. Settlement closes the financial loop. Every part of this chain has a defined transaction, a defined movement type, and a defined reporting surface.

Part 3 of this series places PP-PI and discrete PP side by side in a direct structural comparison, then maps the full PP architecture — MRP Live, PP/DS, DDMRP, Kanban, and Long-Term Planning — as the demand and supply planning layer that drives both execution models.