MM / P2Padvanced

MM Purchase Requisition Part 4: PR Approval — Classic Release Procedure vs Flexible Workflow

Key takeaway

Approve requisitions: classic release strategies with classes, characteristics, release groups/codes and item vs overall release, compared with S/4HANA flexible workflow for purchase requisitions — conditions, steps, agents, and how to choose and migrate.

Explanation

📌 KEY POINTS
✅ Classic release: classification (class for CEBAN), characteristics (value, cost center, material group), release groups, codes, strategies; overall or item-wise release.
✅ Flexible workflow (S/4HANA): condition-based steps and agents maintained in Fiori (Manage Workflows).
✅ Only one approach should be active per document type.
✅ Released PRs can be converted; unreleased cannot.
⚠️ Dozens of legacy release strategies are hard to maintain — migration is the moment to simplify.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 3 covered PR origins. Now approval.

━━━━━━━━━━━━━━━━━━━━
▶ 1. CLASSIC RELEASE

Class and characteristics (e.g. CEBAN-GSWRT value, KOSTL).
Release group, release codes, strategies, prerequisites.

━━━━━━━━━━━━━━━━━━━━
▶ 2. OVERALL VS ITEM RELEASE

Per document type setting.

━━━━━━━━━━━━━━━━━━━━
▶ 3. FLEXIBLE WORKFLOW

Scenario for purchase requisition, conditions (amount, material group, cost center), steps, agents (roles, managers, rules).

━━━━━━━━━━━━━━━━━━━━
▶ 4. CHOICE AND MIGRATION

Flexible workflow preferred for S/4HANA Fiori; migrate strategies into fewer conditions.

━━━━━━━━━━━━━━━━━━━━
▶ 5. OPERATIONS

Approver inbox, substitution, escalation, audit.

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

Review existing release strategies.
Design flexible workflow conditions.
Activate for one document type and test.

✅ CHECKPOINT: every PR above threshold needs the right approver, and below threshold is auto-released.

Code example

ABAP Code

===== STEP 1: classic =====CT04 characteristics (CEBAN-GSWRT, CEBAN-KNTTP) | CL02 class (032) | OMGQ release groups/codes/strategies ===== STEP 2: flexible workflow =====Activate flexible workflow for PR (per release config) → Fiori "Manage Workflows for Purchase Requisitions"Workflow: condition total value > 10,000 → step 1 cost center manager | > 100,000 → step 2 director ===== STEP 3: operations =====My Inbox approvals | substitutes | reminders/escalation

Real project scenario

A company had 80 classic release strategies created over 15 years, many for departed managers. PRs got stuck and IT changed strategies monthly. Moving to flexible workflow with 6 conditions and role-based agents cut maintenance and approval times sharply.

Common mistakes

Too many strategies.
Person-based approvers.
Mixing classic and flexible for one type.
No substitutes.
Not testing thresholds.

Best practices

Use role-based agents.
Keep conditions few.
Plan substitutions.
Test thresholds and edge cases.
Monitor approval times.

Interview angle

Questions: "How is a PR release strategy configured?", "Classic vs flexible workflow?", "Overall vs item release?"
Strong answer: characteristics/class/groups/codes/strategies; overall vs item; flexible workflow conditions/steps/agents; choosing and migrating; operations.

Practice this lesson

Quick check

1. In classic PR release, what links characteristics like total value to release strategies?

2. A company maintains 80 legacy PR release strategies with person-based approvers. What is the better S/4HANA approach?

3. A team wants to keep classic release strategies and also activate flexible workflow for the same PR document type. What is the issue?

Interview questions

1. A company with dozens of classic PR release strategies moves to S/4HANA. How do you redesign PR approval?

Answer it in your own words first, then compare.

2. As solution architect, how would you design purchase requisition document types to support both self-service (employee) requisitions and centralized strategic sourcing requisitions across a multi-country S/4HANA rollout, considering downstream FI-AP posting consistency?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.