Flexible Workflow
MM / P2Padvanced

MM Flexible Workflow Part 4: PR Item-Level vs Overall Approval and Purchase Order Workflow

Key takeaway

Choose approval granularity: purchase requisitions approved per item or as a whole, how this interacts with document type settings and conversion to POs, PO header-level approval, re-approval after changes, and designing a consistent PR-to-PO approval chain without double approvals.

Explanation

📌 KEY POINTS
✅ PRs can be approved item-wise (each item to its own approver) or overall (whole document).

✅ POs are approved at document level.

✅ Changes after approval (e.g. value increase) can restart approval per configuration.

✅ Design PR and PO approvals together to avoid approving the same spend twice.

⚠️ Approving both PR and PO for the same catalog purchase adds delay without control benefit.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE

Part 3 covered definitions. Now granularity and chains.

━━━━━━━━━━━━━━━━━━━━
▶ 1. PR ITEM-LEVEL

  • Items routed to different cost center managers.
  • Items converted when approved.

━━━━━━━━━━━━━━━━━━━━
▶ 2. PR OVERALL

  • One decision for all items; simpler for single-requester documents.

━━━━━━━━━━━━━━━━━━━━
▶ 3. PO WORKFLOW

  • Header-level; conditions on totals and header data.

━━━━━━━━━━━━━━━━━━━━
▶ 4. RE-APPROVAL

  • Restart on relevant changes; tolerance rules.

━━━━━━━━━━━━━━━━━━━━
▶ 5. CHAIN DESIGN

  • PR approval for budget; PO approval only for exceptions (price deviation, manual supplier).

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

  1. Decide item vs overall per PR type.
  2. Define PO approval conditions for exceptions.
  3. Test a PR→PO flow.

✅ CHECKPOINT: each euro of spend is approved once, with exceptions escalated.

Code example

ABAP Code
===== STEP 1: design =====PR type NB: item-level (cost center manager per item)PO: workflow only if PO value exceeds approved PR value by > 5% or supplier differs from PR proposal ===== STEP 2: re-approval =====PO change increasing value > tolerance → workflow restarts ===== STEP 3: test =====PR 3 items → approvals per item → PO → no second approval unless exception

Real project scenario

A company required approval of every PR item and every PO. Catalog orders waited days for double approvals. Redesigning to approve budget at PR level and only exceptions at PO level cut cycle time by 60% without reducing control.

Common mistakes

  • Double approvals.
  • Overall approval with mixed cost centers.
  • No re-approval rules.
  • Ignoring catalog flows.
  • No cycle time monitoring.

Best practices

  • Approve spend once.
  • Use item-level for mixed cost centers.
  • Restart on relevant changes.
  • Exception-based PO approval.
  • Measure cycle times.

Interview angle

Questions: "Item-level vs overall PR approval?", "How do you avoid double approvals?", "When does a PO need re-approval?"
Strong answer: granularity options, PO header approval, re-approval on changes, chain design with exceptions.

Practice this lesson

Quick check

1. When is item-level PR approval most useful?

2. A purchasing document requires approval by two department heads, and the process should proceed only after BOTH have approved. Which completion rule setting should be selected for that workflow step?

3. A company approves every PR item and every PO for the same spend. What is the better design?

Interview questions

1. In S/4HANA Public Cloud, a Flexible Workflow approval for a purchase requisition using the standard app fails to route to the correct approver after an org-structure change synced from MDG. What is your systematic diagnosis approach?

Answer it in your own words first, then compare.

2. Requisitions contain items for different cost centers, and POs are approved again after PR approval. How do you design PR and PO approvals?

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.

More lessons in this topic

Interview questions on this topic

Related SAP topics