MM / P2Pbeginner

MM Release Strategy Part 1: Classic Release Strategy for Purchase Requisitions and Purchase Orders

Key takeaway

Configure classic approvals: characteristics based on communication structures (CEBAN for PRs, CEKKO for POs), release class (class type 032), release groups, release codes, release indicators, strategies with prerequisites and classification values, and the release transactions.

Explanation

📌 KEY POINTS
✅ Characteristics reference fields of CEBAN (PR) or CEKKO (PO), e.g. total value, document type, purchasing group, plant.
✅ A release class (class type 032) holds the characteristics; release groups link the class to strategies.
✅ Release codes represent approvers; strategies define codes, prerequisites and release indicators.
✅ Classification values in the strategy decide which documents it applies to.
⚠️ Overlapping classification values make strategy determination ambiguous — documents may get no or wrong strategy.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS
Part 1: Classic release strategy for PRs and POs
Part 2: Migrating classic release strategy to flexible workflow

━━━━━━━━━━━━━━━━━━━━
▶ 1. CHARACTERISTICS AND CLASS

CT04 characteristics on CEKKO-GNETW (PO net value), CEKKO-BSART, CEKKO-EKGRP…
CL02 class, class type 032.

━━━━━━━━━━━━━━━━━━━━
▶ 2. RELEASE GROUPS AND CODES

Group (e.g. 01) assigned to class; codes per approver level (e.g. C1, C2).

━━━━━━━━━━━━━━━━━━━━
▶ 3. RELEASE INDICATORS

Blocked, released; changeability after release (e.g. new strategy if value increases).

━━━━━━━━━━━━━━━━━━━━
▶ 4. STRATEGIES

Codes, prerequisites (C2 after C1), release statuses, classification values.

━━━━━━━━━━━━━━━━━━━━
▶ 5. EXECUTION

ME28 collective, ME29N individual PO release; ME54N/ME55 for PRs; workflow optional.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Create characteristics and class.
Define group, codes, indicators, strategy.
Maintain classification values.
Create a PO above threshold and release it.

✅ CHECKPOINT: POs above the threshold are blocked until the right code releases them.

Code example

ABAP Code

===== STEP 1: characteristics and class =====CT04: Z_PO_VALUE (CEKKO-GNETW, currency), Z_PO_DOCTYPE (CEKKO-BSART)CL02: class Z_PO_RELEASE, class type 032 ===== STEP 2: configuration (SPRO > MM > Purchasing > Purchase Order > Release Procedure) =====Release group 01 → class Z_PO_RELEASE | codes C1 (manager), C2 (director)Indicators: B blocked, R released | strategy S1: C1 then C2 | classification: value > 10,000; doc type NB ===== STEP 3: execution =====ME29N release by C1 → C2 | ME28 collective release

Real project scenario

A PO expected two approvals but was released after one. The strategy's prerequisites were missing, so C2 could release independently and C1's release set the final indicator. Correcting prerequisites and release statuses restored the two-step approval.

Common mistakes

Overlapping classification values.
Missing prerequisites.
Wrong changeability setting.
Person-based codes without substitutes.
Too many strategies.

Best practices

Keep value bands non-overlapping.
Define prerequisites clearly.
Set changeability to re-trigger on value increase.
Use role-based approvers/workflow.
Test each band.

Interview angle

Questions: "How do you configure a PO release strategy?", "What is CEKKO?", "What is changeability?"
Strong answer: characteristics on CEKKO/CEBAN, class 032, groups, codes, indicators, strategies with prerequisites and values, release transactions.

Practice this lesson

Quick check

1. A services PO uses a confirmation control key requiring both a milestone confirmation and a service entry sheet before invoice, but every time a milestone confirmation is entered, the release strategy re-triggers full approval, delaying SES creation and holding up FI-AP invoice postings during month-end. How would you redesign the confirmation control and release strategy interaction? Choose the response that best aligns with the expected SAP approach.

2. Which communication structure provides the characteristics for classic PO release strategies?

3. After go-live, business complains that PO document type ZSRV (service PO) is bypassing the release strategy entirely for high-value orders, while document type NB works correctly. As the architect, how do you diagnose and resolve this design flaw? Choose the response that best aligns with the expected SAP approach.

Interview questions

1. How would you configure release strategy and workflow integration for external services procurement so that both the service purchase order and its subsequent service entry sheet are subject to appropriate approval before invoice posting?

Answer it in your own words first, then compare.

2. A services PO uses a confirmation control key requiring both a milestone confirmation and a service entry sheet before invoice, but every time a milestone confirmation is entered, the release strategy re-triggers full approval, delaying SES creation and holding up FI-AP invoice postings during month-end. How would you redesign the confirmation control and release strategy interaction?