Scenario 13 — Release Strategy (PO Approval Workflow)

TIER 5 · PROCESS CONTROL ★★★★☆ ⏱️ ~3 hours CT04 → CL02 → OMGS → OMGSCK → ME21N → ME29N
← Previous
Scenario 12: Third-Party Drop-Ship
Next →
Scenario 14: Source Management
⚠️ Not yet live-tested
This page is built from researched standard-SAP content and has not yet been executed end-to-end in our IDES. The T-codes, fields, and accounts follow SAP standard but may need small adjustments on your S/4HANA 2023 system — we'll confirm and correct them when you run this scenario live. Hit a snag? See the Troubleshooting Center.

📊 Business Case

A release strategy is SAP's built-in approval workflow for purchasing documents. It blocks a PO (or PR) from being printed, transmitted, or used for goods receipt until the right people have signed off — typically based on total value, document type, plant, material group, or purchasing group. This is pure internal financial control: it enforces who can authorize spend, and it builds segregation of duties directly into the system so a single buyer can't commit the company to a large order alone.

🕐 When to use it

Whenever spend needs sign-off before it becomes a commitment: a buyer raises a PO above their authority limit, and a Department Head or CFO must approve before it can go to the vendor.

❓ Why it matters

It prevents unauthorized spend and enforces segregation of duties. Approval limits scale by value and org level, so financial control is baked into the document flow — not left to email or trust.

👤 Who triggers it

Buyers create the PO; the release codes (e.g., D1 = Dept Head, F1 = CFO) identify the approvers who release it via ME29N. SAP Workflow notifies them when a release is pending.

🔁 The key distinction

Multi-level approval by value and org. A small PO auto-releases; a mid PO needs one approver; a large PO needs two in sequence. The strategy is what maps value bands to the right chain of approvers.

💰 Financial Impact — The Easy-Money Example

Release strategy is a control scenario — its value is the unauthorized spend it prevents. Suppose a junior buyer at PakSteel tries to commit PKR 8,000,000 to a vendor without sign-off. Here is what the strategy does to that money:

📝 Buyer raises PO
PKR 8,000,000
An 8M order — above the 5M threshold, so it needs Dept Head + CFO approval.
→
🔒 Release block
Spend frozen ↓
PO is "Blocked for release." It can't be printed, transmitted, or received against. Zero commitment leaves the company.
→
✅ Controlled outcome
8M only spent if approved
D1 then F1 must release in sequence. Unapproved? The 8M is never committed — risk avoided.

The big idea: the release strategy doesn't generate revenue — it avoids loss. Every PO above a band is structurally incapable of becoming a commitment until the named approvers sign. That converts "trust the buyer" into "the system enforces the policy," which is exactly what auditors and the CFO want to see.

💡 Lesson: Approval limits + segregation of duties, enforced by the document itself. A blocked PO is a frozen liability — value only flows out once the right people, in the right order, have released it.

🇵🇰 The Business Story

PakSteel implements a PO approval policy: Until approved, the PO can't be sent to the vendor or used for GR.

🎯 What you'll learn

Release strategy is built from 5 building blocks — learn what each one does and the exact T-code:

  1. Characteristic (CT04): WHAT triggers the strategy — total value, doc type, plant, material group, purch group
  2. Class (CL02): Groups characteristics under class type 032 (PO release) or 009 (PR release)
  3. Release Group (OMGS): A code (e.g., 02) grouping strategies for similar docs
  4. Release Codes (OMGS): The approvers (e.g., D1 = Dept Head, F1 = CFO)
  5. Release Strategy (OMGS): Combines class + codes + dependencies (precondition, simultaneous)

🔧 Step-by-Step

⚙️ Config Steps (PO Release for value-based approval)

13.1 — Create Characteristic · CT04
  1. CT04 · Characteristic: CEKKO_GNETW (total PO net value) — use this existing characteristic OR copy to Z_PO_VALUE
  2. If creating new: Data type CURR, length 15.2, Table CEKKO, Field GNETW
  3. Values tab: define value ranges (e.g., 0 – 500,000; 500,001 – 5,000,000; etc.)
  4. Save
13.2 — Create Class · CL02
  1. CL02 · Class: Z_PSPK_PO_REL · Class Type: 032 (Release strategy for PO)
  2. Description: PakSteel PO Release Class
  3. Characteristics tab: Add CEKKO_GNETW (or your Z_ char)
  4. Save
13.3 — Release Group + Codes · OMGS (for PO)
  1. OMGS · Edit Release Groups · New Entry: Group 02, Class Z_PSPK_PO_REL · Description "PakSteel POs"
  2. Edit Release Codes: D1 (Dept Head), F1 (CFO) — link to user role/agent via SAP user authorization
  3. Edit Release Indicators: 1 = blocked, 2 = released
  4. Save
13.4 — Release Strategies · OMGS
  1. OMGS · Release Strategies · New Entries:
    • Strategy S1: Class Z_PSPK_PO_REL · Codes D1 only · Value 500K-5M
    • Strategy S2: Codes D1 + F1 simultaneous · Value 5M+
  2. For each: Click Classification → set the characteristic value ranges
  3. For S2: Release Prerequisites → F1 needs D1 first (sequential)
  4. Save

🔄 Test Flow

13.5 — Create PO and see release block · ME21N
  1. ME21N · create PO totaling PKR 2,000,000 (in S1 range)
  2. Save → PO has status "Blocked for release"
  3. You can't print/transmit the PO yet
13.6 — Release the PO · ME29N (or ME28 bulk)
  1. Login as Dept Head user (assigned to release code D1)
  2. ME29N · PO # → click Release
  3. PO status changes to "Released"
  4. Now visible in vendor's view, GR allowed, etc.
💡 Workflow integration
SAP Workflow (SBWP) notifies the approver by email when their release is pending. Use SBWP Business Workplace to see pending approvals.

✅ Verification

#T-codeCheck
1ME21NCreate a PO ≥ PKR 500,000 → on Save it shows status "Blocked for release" (cannot print/transmit)
2ME29NAs the D1 user, the PO appears in the release worklist; clicking Release flips status to "Released"
3ME2NList POs by release status — confirm the blocked vs released split matches the value bands
4SBWPThe pending approver sees a workflow item in their Business Workplace inbox

🎓 Interview-Ready Answers

Q: What are the building blocks of a release strategy?

Five pieces: (1) Characteristic (CT04) defines what the strategy keys on — e.g. total net value via CEKKO_GNETW; (2) Class (CL02, class type 032 for PO / 009 for PR) groups the characteristics; (3) Release Group ties the class to a document category; (4) Release Codes are the approver slots (D1, F1); (5) the Release Strategy itself combines class + codes + dependencies (prerequisite/sequential or simultaneous) and the characteristic value ranges that select it.

Q: What's the difference between class type 032 and 009?

032 is the release strategy class type for purchase orders (and other external purchasing docs); 009 is for purchase requisitions. They use different communication structures — PO release reads CEKKO, PR release reads CEBAN — so the characteristics you build differ accordingly.

Q: How do you enforce that the CFO can only release after the Department Head?

In the release strategy (OMGS), set Release Prerequisites: mark that code F1 (CFO) requires D1 (Dept Head) first. That makes the chain sequential — F1's release button stays inactive until D1 has released. For parallel sign-off instead, leave prerequisites blank so both can release independently (simultaneous).

Q: Why does a release strategy improve internal control?

It builds segregation of duties into the document itself. A buyer can create a PO but cannot commit it — the system blocks printing, transmission, and goods receipt until the value-appropriate approvers release it. Spend authority is enforced structurally and is fully auditable, rather than relying on email approvals or trust.

← Previous
Scenario 12: Third-Party Drop-Ship
Next →
Scenario 14: Source Management