Scenario 13 — Release Strategy (PO Approval Workflow)

TIER 5 · PROCESS CONTROL ★★★★☆ ⏱️ ~3 hours CT04 → CL02 → OME4 → SM30 (V_T16FG/FC/FS) → ME21N → ME29N

✅ The ENTIRE release-strategy configuration is built + committed LIVE and verified correct — only the block/release demo waits on a one-time Basis table repair (not a config error)

On the real system (PakSteel IDES, S/4HANA, client 250), on 2026-07-23, we built and saved every piece of a working PO release strategy, live: the two characteristics (the questions SAP asks each PO), the class that holds them, the dedicated purchasing group R13 that scopes the strategy so it never freezes anyone else's POs, the release group Z1, the two release codes (Z1/01 Purchasing Mgr + Z1/02 Finance Head), and the two-step release strategy Z1/ZS with its prerequisites, status lights, and classification rule. Every code below is the real one on the system. We verified the strategy is active in CL24N (status 1) and consistent in OMGSCK (no errors).

The one thing still ahead is the live block/release demo (ME21N raise a qualifying PO → ME29N release it). It waits on a one-time Basis job — this is not a config change and not a config error. While clearing a pre-existing broken release group (message ME492), we had to delete and re-create the characteristics and class several times, and that churn left some dead internal-ID links in SAP's hidden classification tables, so the runtime finds no match yet. A Basis run of the standard correction reports rebuilds those links and the strategy then determines with no config change. Both stories are told plainly in the Errors section.

Part of the build	What we did	Status
Value characteristic	CT04 — reference `CEKKO-GNETW` (PO total net value), type CURR, currency `PKR`, multiple + interval values	`Z_PSPK_PO_VAL` — created + saved live ✅
Scope characteristic	CT04 — reference `CEKKO-EKGRP` (purchasing group), type CHAR 3, single value	`Z_PSPK_PO_PGRP` — created + saved live ✅
Release class	CL02 — class type 032 (Release Strategy), both characteristics assigned	`Z_PSPK_PO_REL` — created + saved live ✅
Purchasing group (the scope key)	OME4 → New Entries — a group used only by this scenario's test POs	`R13` "Release Test Sc13" — saved live ✅ (request `DEVK904800`)
Release group	SM30 `V_T16FG` / SPRO — points at class `Z_PSPK_PO_REL`; release object auto-derives to `2`	`Z1` — saved live ✅
Release codes	SM30 `V_T16FC` — the two approver stamps	`Z1/01` "Purchasing Mgr" + `Z1/02` "Finance Head" — saved live ✅
Release strategy + classification	SM30 `V_T16FS` — codes 01+02, prerequisite 02-after-01, statuses `B`→`G`, class values `R13` + ≥ 500,000 PKR	`Z1/ZS` "Sc13 2-step release" — saved + active live ✅ (CL24N status 1, OMGSCK clean)
Block + release demo	ME21N raise a qualifying PO → ME29N release with `01` then `02`	pending a one-time Basis table repair (see Errors) — no config change needed

Honesty note (one calm line): we do not show a demo PO number, because the strategy does not yet attach at runtime — the fix is the standard Basis correction reports RCCLINOB / RCLINOB2 / RCCLUKA2 / RCCLZUOB, which repair the internal links in the hidden classification tables KSSK / AUSP / INOB. We never invent SAP document numbers, so the demo tail carries none until it is posted for real.

Lesson baked into this build: once characteristics and classes are in use, deleting and re-creating them repeatedly corrupts SAP's internal ID links — so the config can be perfect on every screen yet the runtime still finds no match. Avoid the churn; if it happens, the Basis reports above are the clean, one-time fix.

📊 Business Case — When & Why You Use This

A release strategy is SAP's built-in approval workflow for purchasing documents. It blocks a PO (a purchase order = a written promise to buy from a vendor) from being printed, sent to the vendor, or used for goods receipt until the right people have signed off. Sign-off is decided by things like total value, plant, material group, or purchasing group. This is pure internal financial control: the system — not trust or email — enforces who may commit the company's money.

🎯 The one big design lesson — scope it, or you freeze the whole company

A release strategy fires for every PO whose values match its rule. So a naive rule like "block every PO over 500,000" would freeze every high-value PO in the entire system — everyone's work stops. To stay safe, we scope the strategy to a dedicated purchasing group, R13. The strategy only triggers when Purchasing Group = R13 AND net value ≥ 500,000 PKR. Only this scenario's own test POs get caught; nobody else's POs are disturbed. Always scope a learning/test strategy this way.

🕐 When to use it

Whenever spend needs sign-off before it becomes a commitment: a buyer raises a PO at or above the value limit, and a manager (and above) must approve before it can go to the vendor.

❓ Why it matters

It prevents unauthorized spend and builds segregation of duties into the document. The person who raises a PO is not the person who frees it — approval is baked into the flow, not left to trust.

👤 Who triggers it

Buyers create the PO; the release codes (Z1/01 = Purchasing Mgr, Z1/02 = Finance Head) identify the approvers who release it in ME29N.

🔁 The key distinction

Scoped, value-based, two-step approval. A PO in group R13 for ≥ 500,000 PKR is frozen and needs Z1/01 then Z1/02, in that order. POs outside R13 are never touched.

💰 Financial Impact — The Easy-Money Example

Release strategy is a control scenario — its value is the unauthorized spend it prevents. Suppose a buyer in purchasing group R13 raises a PO whose net value is ≥ PKR 500,000 (the threshold). Here is what the scoped strategy does to that money:

📝 Buyer raises PO (group R13)

Net ≥ PKR 500,000

At or above the threshold, in the scoped group — so it needs Purchasing Mgr + Finance Head approval.

→

🔒 Release block

Spend frozen ↓

PO is "Blocked for release." It can't be printed, sent to the vendor, or received against. Zero commitment leaves the company.

→

✅ Controlled outcome

Spent only if released

Z1/01 then Z1/02 must release, in order. Unapproved? The money is never committed — risk avoided.

The big idea: the release strategy doesn't generate revenue — it avoids loss. A matching PO is structurally incapable of becoming a commitment until the named approvers sign, in the right order. That converts "trust the buyer" into "the system enforces the policy," which is exactly what auditors and the CFO want to see. And because it is scoped to group R13, it enforces that policy without freezing anyone else's day-to-day POs.

💡 Lesson: Approval limits + segregation of duties, enforced by the document itself — and scoped so the control lands only where you intend. 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 wants a safe test of PO approval control. The policy for this test:

A PO raised in purchasing group R13 with net value ≥ PKR 500,000 → must be approved by the Purchasing Manager (code Z1/01) and then the Finance Head (code Z1/02), in that order.
Any PO not in group R13, or below the threshold → no block, business as usual.

Until both approvers release it, the PO can't be sent to the vendor or used for GR. Because the rule is tied to group R13, the rest of PakSteel keeps working normally — that is the whole point of scoping.

🎯 What you'll learn

A release strategy is built from a small stack of pieces. Learn what each one does and its exact real code:

Characteristic (CT04): the QUESTION SAP asks each PO. We built two — value (CEKKO-GNETW) and purchasing group (CEKKO-EKGRP, the scope).
Class (CL02), type 032: the folder that holds those questions for PO release. Ours: Z_PSPK_PO_REL.
Dedicated purchasing group (OME4): R13 — the scope key that keeps the strategy off everyone else's POs.
Release group + codes (SM30 V_T16FG / V_T16FC): the folder Z1 and the approver stamps Z1/01 (Purchasing Mgr) + Z1/02 (Finance Head). Built + saved live.
Release strategy (SM30 V_T16FS): the rule row Z1/ZS — "POs in group R13 for ≥ 500,000 need these two stamps, in this order" — plus the classification values that make it fire and the status lights (B = blocked → G = released). Built + saved live, active in CL24N.
Demo (ME21N → ME29N): raise a PO that gets blocked, then release it stamp-by-stamp. This part fires once a one-time Basis table repair runs (see Errors).

📋 Prerequisites — what must be in the system (and why)

These are the compulsory pieces the release strategy stands on. Every object below we created and saved live on PakSteel IDES — the four classification/scope foundation objects here, plus the whole release procedure (group Z1, codes Z1/01+Z1/02, strategy Z1/ZS) in the Steps. They are the real codes on the system, verified active in CL24N and consistent in OMGSCK. Miss any piece and you'll meet the messages in the Errors box. The single most important design choice is Prerequisite ⑤ — the scope.

① The live foundation — the classification objects (created + saved on the real system)

Object	Live value	What it is · why the scenario needs it
Value characteristic	`Z_PSPK_PO_VAL` (CT04, ref `CEKKO-GNETW`, type CURR 15/2, currency `PKR`, multiple + interval)	The question "what is this PO's total net value?" Needed because the strategy approves on value — this is where SAP reads the amount from the PO itself.
Scope characteristic	`Z_PSPK_PO_PGRP` (CT04, ref `CEKKO-EKGRP`, type CHAR 3, single value)	The question "which purchasing group is on this PO?" Needed because matching it to `R13` is what keeps the strategy off every other team's POs.
Release class	`Z_PSPK_PO_REL` (CL02, class type 032, both characteristics assigned)	The folder that holds both questions for PO release. Needed because a strategy reads its questions from a class, never from characteristics directly.
Dedicated purchasing group	`R13` "Release Test Sc13" (OME4, saved to request `DEVK904800`)	The scope key. Needed because tying the strategy to this group is what makes it fire only for this scenario's own test POs.

💰 Prerequisite ② — the value characteristic Z_PSPK_PO_VAL (CT04, on CEKKO-GNETW)

🎯 In plain words: a characteristic is the question SAP asks about a PO. This one asks "what is your total value?" — and SAP reads the answer straight from the PO, so nobody types it.

What to set: CT04 → characteristic Z_PSPK_PO_VAL, description "Total net order value". On the Addnl data tab set Reference to Table Field = table CEKKO, field GNETW (the PO header total net value). Press Enter — SAP copies the format from the ABAP Dictionary (a data type CURR = currency, 15 digits / 2 decimals). Because it is a currency characteristic, SAP asks for a currency — set PKR on the Basic data tab. Also switch on Multiple Values + Interval values allowed (so a strategy can use a range like "≥ 500,000").
Why SAP needs it: the strategy decides sign-off on money. Without a value question wired to the real PO field, there is nothing to measure.
🔍 Everyday analogy: it is like the "amount" box on a cheque — the number the bank looks at to decide whether one signature is enough or two are needed.
What breaks without it: point at the wrong table/field and the strategy approves on the wrong thing (or never fires); leave off "interval values" and you can't set a "≥ 500,000" band.
✅ How you'll know it worked: CT04 shows Z_PSPK_PO_VAL with reference CEKKO-GNETW, type CURR, currency PKR — and the save message "Characteristic Z_PSPK_PO_VAL saved".

🏷️ Prerequisite ③ — the scope characteristic Z_PSPK_PO_PGRP (CT04, on CEKKO-EKGRP)

🎯 In plain words: this is the second question — "which buying team (purchasing group) is on this PO?" It is what lets the strategy target one group only.

What to set: CT04 → characteristic Z_PSPK_PO_PGRP, description "Purchasing Group (Release)". On the Addnl data tab reference table CEKKO, field EKGRP (purchasing group). SAP copies the format from the dictionary — a CHAR 3 (a 3-character code). Leave it as a single value (one group, not a range).
Why SAP needs it: value alone is not enough to stay safe. This question is the "only for this team" filter.
🔍 Everyday analogy: like writing "Toys department only" on a store rule, so the rule doesn't accidentally apply to the whole shop.
What breaks without it: with no purchasing-group question in the class, you can only key the strategy on value — so it would block every high-value PO company-wide.
✅ How you'll know it worked: CT04 shows Z_PSPK_PO_PGRP with reference CEKKO-EKGRP, CHAR 3, single value.

📋 Prerequisite ④ — the release class Z_PSPK_PO_REL (CL02, class type 032)

🎯 In plain words: a class is the folder that holds your questions together so a strategy can use them as one set. Class type 032 means "for PO release."

What to set: CL02 → class Z_PSPK_PO_REL, class type 032 (Release Strategy), description "PakSteel PO Release Strategy". On the Char. tab assign both characteristics: Z_PSPK_PO_VAL and Z_PSPK_PO_PGRP.
Why SAP needs it: a release strategy reads its questions from a class of type 032, not from loose characteristics. The class is the required container.
🔍 Everyday analogy: a clipboard holding two forms — "how much?" and "which team?" — that the approver checks together before deciding.
What breaks without it: choose the wrong class type (e.g. 009 = purchase requisitions) and it never matches a PO; forget to add a characteristic and the class asks nothing, so no strategy can match.
✅ How you'll know it worked: CL02 shows the class with both characteristics on the Char. tab — and the save message "Class type 032: Class Z_PSPK_PO_REL created".

🎯 Prerequisite ⑤ — the dedicated purchasing group R13 (OME4) — THE SCOPE KEY

🎯 In plain words: a purchasing group is just the buying-team code on a PO. We create a brand-new one, R13, used only by this scenario — so the strategy can safely say "only touch POs from this team."

What to set: OME4 → New Entries → purchasing group R13, short name "Release Test Sc13" (keep it short — the name field holds only 18 characters). Save; you'll get the "Prompt for customizing request" dialog (ours saved to request DEVK904800, message "Data was saved").
Why SAP needs it: this is what makes the whole strategy safe. The strategy's rule will be "Purchasing Group = R13 AND value ≥ 500,000" — so only POs raised under R13 are ever caught.
🔍 Everyday analogy: a fresh, empty test lane at a toll booth — you can put a strict barrier on it without stopping traffic in every other lane.
What breaks without it: scope the strategy on value only (no group), and every buyer's high-value PO across the company freezes — a self-inflicted outage. Reusing an existing busy group would do the same to that team.
✅ How you'll know it worked: OME4 lists R13 "Release Test Sc13"; you can pick it as the purchasing group in ME21N.

⚠️ Prerequisite ⑥ — first clear the pre-existing BROKEN release group (the ME492 lesson)

🎯 In plain words: before our new group Z1 would save, we had to fix something already broken on the system. This is a real, important lesson — one broken release group blocks the whole client, and it is the single biggest thing that surprised us live.

What was wrong: the system carried an old release group 02 pointing at a class, ZMM_PO_RELEASE, that had already been deleted — leaving about ~59 orphaned release strategies hanging off a class that no longer existed. That made the whole PO release configuration inconsistent.
The message it threw: every attempt to save our new group stopped with ME492 "Please check release classes". The rule behind it: all PO release groups of the same overall-release type must use ONE release class — you cannot have one group on class A and another on class B. The broken group 02 (dead class) versus our new group Z1 (class Z_PSPK_PO_REL) was exactly that clash.
The fix: delete the ~59 orphaned strategies and then delete the broken group 02, so only our new group Z1 (with class Z_PSPK_PO_REL) remains. After that, the new group and strategy saved cleanly.
🔍 Everyday analogy: you can't add a new lock to a shared door while a jammed, key-less old lock is still bolted on — you must remove the dead one first.
🧠 The deeper lesson: unlike characteristics/classes in earlier scenarios, the "one dedicated class per scenario" idea does not apply to PO release groups — every PO release group on the client shares one release class. So a single broken group is not a local problem; it freezes the ability to configure release for everyone.
✅ How you'll know it's clear: SM30 on V_T16FG shows only group Z1 (class Z_PSPK_PO_REL), the old group 02 is gone, and saving no longer throws ME492.

🔧 Step-by-Step

🧭 The route at a glance — read this first

Step	T-code	What it does	Why this step exists	Status
13.1	CT04	Create the two questions: PO value (`CEKKO-GNETW`) + purchasing group (`CEKKO-EKGRP`)	a rule needs something to measure, and a way to scope it	live ✅
13.2	CL02	Create the class (type 032) holding both questions	strategies read questions from a class, not directly	live ✅
13.3	OME4	Create the dedicated purchasing group `R13`	the scope key — keeps the strategy off everyone else's POs	live ✅
13.4	SM30 / SPRO	Define release group `Z1`, codes `Z1/01`+`Z1/02`, and strategy `Z1/ZS` + classification (statuses `B`→`G`)	the policy becomes system-enforced, not trust	live ✅
13.5	ME21N	Raise a PO in group `R13` ≥ 500,000 — Save freezes it as blocked	big spend must wait for sign-off	demo — after Basis repair
13.6	ME29N	Approvers stamp the PO with `01` then `02` — status flips to released	only approvers, in order, can free frozen spend	demo — after Basis repair

📇 Your live codes — quick reference

Value char Z_PSPK_PO_VAL (net value, CEKKO-GNETW, CURR PKR) · Scope char Z_PSPK_PO_PGRP (purch group, CEKKO-EKGRP) · Class Z_PSPK_PO_REL (type 032) · Purchasing group R13 "Release Test Sc13" (request DEVK904800) · Release group Z1 · Release codes Z1/01 (Purchasing Mgr) + Z1/02 (Finance Head) · Release strategy Z1/ZS "Sc13 2-step release" · Threshold ≥ 500,000 PKR · Status indicators B (Blocked, changeable with value) → G (Released). Tcodes: CT04, CL02, OME4, SM30 (V_T16FG / V_T16FC / V_T16FS) or SPRO "Define Release Procedure for Purchase Orders", CL24N (check strategy active), OMGSCK (consistency check), ME21N, ME29N.

⚙️ Config Steps — the classification foundation (built live)

13.1 — Create the two Characteristics · CT04 (live ✅)

⚡ This step will: create the two questions the strategy asks every PO — "what is your value?" and "which purchasing group are you?" — wired so SAP reads both answers from the PO itself. Config only: no PO is touched. 📄 paper: — (config objects only) · 📦 stock: no change · 💰 money: no posting

A characteristic = the QUESTION the approval guard asks. Nobody types the answers — SAP reads them from the PO's header card (table CEKKO) at save time.

Do — part A, the value question (Z_PSPK_PO_VAL):

Where on screen · Field	Fill	What the field asks (plain words)	Why we choose this — and the impact if wrong
Initial · Characteristic	`Z_PSPK_PO_VAL`	What is this question's name?	A `Z`-name marks it as your own object, safe from SAP upgrades. Impact: reusing a standard name risks it being overwritten by a support pack.
Basic data · Description	Total net order value	What does a colleague read?	Plain label. Impact: none technical; only clarity.
Addnl data · Reference to Table Field — Table	`CEKKO`	WHICH card does the guard read from?	`CEKKO` is the PO header summary card SAP fills from the PO. Impact: the wrong table has no PO value on it.
Addnl data · Reference to Table Field — Field	`GNETW`	WHICH line on that card holds the answer?	`GNETW` = total net value. Wiring here is what makes the check automatic. Impact: the wrong field reads the wrong number — the block fires on the wrong amount or never.
(after Enter) format	type CURR, 15 / 2 (auto)	What SHAPE is the answer?	SAP copies the format from the ABAP Dictionary — a currency amount, 15 digits, 2 decimals. Just confirm (see Errors: "Format data used from ABAP Dictionary").
Basic data · Currency	`PKR`	A money amount in WHICH currency?	A currency characteristic must carry a currency unit — SAP asks "Enter a currency". Impact: without it you can't save.
Basic data · Multiple Values + Interval values allowed	tick both	Can the strategy use a RANGE, like "≥ 500,000"?	Yes — the value band needs an interval. Impact: leave these off and you can only match a single exact amount, never "500,000 and above".

Result on our system: "Characteristic Z_PSPK_PO_VAL saved". (SAP may also show an information note that the multiple-values setting refers to a reference characteristic — press Continue; it is fine. See Errors.)

Do — part B, the scope question (Z_PSPK_PO_PGRP):

Where on screen · Field	Fill	What the field asks (plain words)	Why we choose this — and the impact if wrong
Initial · Characteristic	`Z_PSPK_PO_PGRP`	Name of the scope question?	Your own `Z`-object. Impact: as above.
Basic data · Description	Purchasing Group (Release)	Colleague label?	Plain label.
Addnl data · Reference — Table / Field	`CEKKO` / `EKGRP`	WHICH card + line holds the purchasing group?	`EKGRP` = the PO's purchasing group. This is the field the scope depends on. Impact: the wrong field can't isolate group R13.
(after Enter) format	CHAR 3 (auto)	What shape is the answer?	A 3-character code, copied from the dictionary. Just confirm.
Basic data · single value	leave single (not multiple)	One group, or a range?	We match exactly one group (`R13`). Impact: multiple isn't needed here.

Result on our system: Z_PSPK_PO_PGRP saved, referencing CEKKO-EKGRP, CHAR 3.

13.2 — Create the Class · CL02 (class type 032) (live ✅)

⚡ This step will: create the folder (class, type 032) that holds both questions from 13.1 — the container a PO release strategy reads from. Config only. 📄 paper: — (config object only) · 📦 stock: no change · 💰 money: no posting

Where on screen · Field	Fill	What the field asks (plain words)	Why we choose this — and the impact if wrong
Initial · Class	`Z_PSPK_PO_REL`	What is this folder's name?	Your own `Z`-object. Impact: reusing a standard class risks it being changed by an upgrade.
Initial · Class Type	`032` (Release strategy)	A folder for WHICH kind of document? `032` = purchase orders · `009` = purchase requisitions	PO and PR read different cards (PO = `CEKKO`). Impact: choose 009 and the class reads the PR card — it never matches a purchase order, so the block never fires.
Basic data · Description	PakSteel PO Release Strategy	What do colleagues read?	Plain label. Impact: none technical; only clarity.
Char. tab · add characteristics	`Z_PSPK_PO_VAL` and `Z_PSPK_PO_PGRP`	WHICH questions are on this folder?	Both — value and scope. Impact: forget the scope characteristic and you can't limit the strategy to R13; forget value and it can't judge amount.

Result on our system: "Class type 032: Class Z_PSPK_PO_REL created", with both characteristics on the Char. tab.

13.3 — Create the dedicated Purchasing Group · OME4 (the scope key) (live ✅)

⚡ This step will: create a fresh purchasing group, R13, used only by this scenario — so the strategy can be tied to it and never disturb anyone else's POs. Config only. 📄 paper: — (config object only) · 📦 stock: no change · 💰 money: no posting

A purchasing group = the buying-team code on a PO. Making a brand-new one is the trick that keeps this test safe.

Where on screen · Field	Fill	What the field asks (plain words)	Why we choose this — and the impact if wrong
OME4 → New Entries · Purchasing Group	`R13`	What is the new team code?	A dedicated code just for this scenario. Impact: reuse a busy group and you'd freeze that team's real POs.
New Entries · Description (name)	Release Test Sc13	What is this group called?	Short and clear. The name field holds only 18 characters, so keep it short. Impact: too long is rejected (see Errors).
Save → customizing request	answer the "Prompt for customizing request" dialog	Where should this config change be recorded?	SAP saves customizing to a transport request. Impact: none if you accept the prompt; ours saved to request `DEVK904800`.

Result on our system: "Data was saved" — purchasing group R13 "Release Test Sc13" saved to request DEVK904800.

⚙️ Config Steps — the release procedure (built + saved live)

📝 How to read 13.4–13.6

13.4 is done live: the release group Z1, both codes, and the strategy Z1/ZS (with prerequisites, status lights, and classification) were entered and committed on PakSteel IDES, and the strategy is active in CL24N (status 1) with a clean OMGSCK consistency check. 13.5–13.6 are the demonstration: raising a qualifying PO and releasing it. They will run once a one-time Basis table repair (the classification-correction reports in the Errors box) rebuilds SAP's internal ID links — no config change is needed. We show no demo PO number, because we never invent SAP document numbers.

13.4 — Define the Release Procedure · SM30 V_T16FG / V_T16FC / V_T16FS (or SPRO "Define Release Procedure for Purchase Orders") (live ✅)

⚡ This step will: build the folder, the approver stamps, the status lights, and the actual rule — after this, every PO in group R13 for ≥ 500,000 is checked at Save. Config only. 📄 paper: — (config objects only) · 📦 stock: no change · 💰 money: no posting

The path is SPRO → Materials Management → Purchasing → Purchase Order → Release Procedure for Purchase Orders → Define Release Procedure for Purchase Orders, a guided dialog with sub-parts (the SM30 views below). Do them in this order — each later part needs the earlier one saved first, and the status lights are filled by SAP inside the strategy step.

Sub-part (view) · Field	Fill	What it asks (plain words)	Why — and the impact if wrong
Release Groups (`V_T16FG`) · Group	`Z1`	Which FAMILY (folder) of strategies is this?	A folder that will hold your strategy. Impact: use a group tied to another class and your strategy reads the wrong questions.
Release Groups (`V_T16FG`) · Class	`Z_PSPK_PO_REL`	Which folder-of-questions (class) does this group read?	Ties group `Z1` to the class from 13.2. The release object auto-derives to `2` from the CEKKO class — it is not an input you type on the New-Entries screen. Impact: the wrong class judges POs on the wrong data.
Release Codes (`V_T16FC`) · Codes	`Z1`/`01` = "Purchasing Mgr" · `Z1`/`02` = "Finance Head"	WHO are the approvers? A release code = a role/person who must sign, not a name typed on the PO	One stamp per approver role. Impact: miss a code and that approver has no stamp to press, so a strategy needing it can never be fully released. (If you try to add codes before the group is saved, SAP says "Entry Z1 does not exist in T16FG" — save the group first; see Errors.)
Release Strategy (`V_T16FS`) · Strategy	`Z1`/`ZS` "Sc13 2-step release", using release codes 01 + 02	Which approvers, and in which sequence, for this rule?	Two stamps: Purchasing Mgr then Finance Head. Impact: drop code 02 and big POs skip the Finance sign-off — a governance hole.
Release Strategy · Release statuses (auto-filled)	nothing signed → `B` "Blocked, changeable with value" · after `01` → still `B` · after `01`+`02` → `G` "Released"	What STATES can the PO be in, and when? The traffic lights	These are standard indicators SAP fills for you from the code sequence — you do not invent them. `B` = frozen but still editable (no print/send/GR); `G` = free to go. Impact: the PO moves from `B` to `G` only when the last needed stamp lands.
Release Strategy · Classification	`Z_PSPK_PO_VAL` ≥ `500,000` PKR AND `Z_PSPK_PO_PGRP` = `R13`	Which ANSWERS make THIS strategy fire?	This is the heart of it: the strategy triggers only when both are true. The `R13` value is what scopes it — no other group is ever caught. Impact: leave out `R13` and the rule fires on every high-value PO company-wide.
Release Strategy · Release Prerequisites	code `02` requires `01` first	In what ORDER do the stamps land?	Makes the chain sequential — like a cheque that must be countersigned: Finance Head's button stays dead until Purchasing Mgr has signed. Impact: leave prerequisites blank and both may sign in any order.

Note: the release object is a PO (auto-derives to 2) because the class is of type 032 on CEKKO — you do not (and cannot) type it as an input here; SAP derives it from the class.

Result on our system: release group Z1, codes Z1/01+Z1/02, and strategy Z1/ZS "Sc13 2-step release" all saved live; the strategy shows active in CL24N (status 1) and the OMGSCK consistency check reported no errors. (Getting the new group to save first meant clearing the pre-existing broken group 02 — see Prerequisite ⑥ and the Errors box.)

🔄 Test Flow — see the block, then release it

⏳ Why this demo is pending — an honest note (it is NOT a config error)

After the config was complete and verified, we raised a real test PO to watch it get blocked: ME21 — vendor MUGHAL21, purch org PKLO, purch group R13, plant PK01, material RM-IRON-01, qty 100, value ≈ 25,000,000 PKR (well over the 500,000 threshold), tax code I0. Instead of freezing, the PO header showed "Purchasing document not subject to release strategy" — the strategy did not attach.

It is NOT the config. Every configuration screen is correct and consistent: CL24N shows the strategy active (status 1), and OMGSCK (the release-procedure consistency check) reports no errors.
The real root cause: while clearing the pre-existing broken group 02 (the ME492 problem in Prerequisite ⑥), we had to delete and re-create the characteristics and the class several times. That churn left dead internal-ID links (the internal keys ATINN for characteristics and CLINT for the class) in SAP's hidden classification tables — KSSK, AUSP and INOB. The runtime release engine reads those tables directly, follows the stale links, and finds no match — even though the front-end config is perfect.
The fix is a one-time Basis / developer job (no config change): run the standard classification-correction reports RCCLINOB, RCLINOB2, RCCLUKA2, and RCCLZUOB (via SE38 / SA38). They repair and rebuild the internal links so the class and characteristics point at their live objects again. After that, the strategy determines on the next matching PO with nothing else changed.
🧠 The lesson to carry forward: once characteristics and classes are in use, do not delete and re-create them repeatedly — it corrupts these internal ID links. Build them once, carefully; if churn is unavoidable, the correction reports above are the clean repair.

Steps 13.5 and 13.6 below are written as the exact demonstration to run once that repair is done. We show no PO number, because we never invent SAP document numbers.

13.5 — Raise a PO and see the release block · ME21N (demo — fires after the Basis repair)

⚡ This step will: create a test PO in group R13 above the threshold — and on Save the strategy grabs it and freezes it as "Blocked for release", so no promise can leave the company yet. 📄 paper: purchase order (blocked) · 📦 stock: no change · 💰 money: no posting

ME21N · create a PO with Purchasing Group R13 and a net value ≥ PKR 500,000.
Save → the PO is created but shows status "Blocked for release", and the Release strategy tab shows group/strategy Z1/ZS with codes 01 and 02 still open.
You can't print or send the PO to the vendor yet.

What happened at Save: SAP filled the CEKKO header card (purchasing group = R13, total ≥ 500,000) → the class asked its two questions → both answers matched strategy ZS's classification → ZS grabbed the PO and froze it. A blocked PO is a frozen liability: it exists, but no money can start moving until both stamps arrive. Because we scoped on R13, a PO raised in any other purchasing group would not be blocked at all.

13.6 — Release the PO · ME29N (codes 01 then 02) (demo — fires after the Basis repair)

⚡ This step will: put the two approver stamps on the blocked PO, in order — its status flips from blocked to released, so it can now be printed, sent to the vendor, and received against. Status only: nothing posts. 📄 paper: — (status change on the existing PO) · 📦 stock: no change · 💰 money: no posting

ME29N is a single-screen transaction with 3 parts: ① the header, which carries the release-strategy box, ② the item display (the PO's lines, read-only in release mode), and ③ the Release strategy tab — the sign-off sheet, where each release code (01, 02) shows its own Release button.

Field / Action	Fill	What it asks (plain words)	Why — and the impact if wrong
Opening screen · Purchase Order	the blocked PO number from 13.5	WHICH PO are you approving?	Opens that PO in release mode. Impact: the wrong number would approve the wrong document.
Release strategy tab · read the codes	it lists `01` "Purchasing Mgr" and `02` "Finance Head" with each one's status	WHO must stamp, and who already has?	This tab is the sign-off sheet. Impact: if your code isn't shown, your user was never linked to it — you simply can't release.
Release button for code `01`	click it first (Purchasing Mgr)	Press the FIRST stamp?	Sets `01` = released. Because of the prerequisite from 13.4, code `02`'s button stays dead until this is done. Impact: clicking the "cancel release" icon instead undoes approval.
Release button for code `02`	then click it (Finance Head)	Press the SECOND stamp?	Only active after `01`. Sets `02` = released — the last one needed. Impact: skip it and a ≥ 500,000 PO never gets the Finance sign-off.
Toolbar · Save	Save → status flips to "Released"	Make the approval stick?	The status only changes once you Save. Impact: leave without saving and the PO stays blocked.

What changes at this exact moment: the release indicator flips from Blocked to Released. The PO can now be printed / sent to the vendor, and a goods receipt becomes allowed. No Dr/Cr and no stock move — a release changes only status, not the books.

⚠️ A release moves status, not money — and the two stamps are sequential (the lesson)

Unlike the MIGO / MIRO steps in other scenarios, releasing posts nothing financial — it just frees a frozen document. It also enforces segregation of duties: the buyer who created the PO should not be the user who releases it. And the release is sequential — Finance Head's 02 button stays dead until Purchasing Mgr's 01 has been pressed first (the prerequisite you set in 13.4), so one stamp alone is never enough.

Why a different login? A release code belongs to an approver's user. If the buyer could press Release on his own PO, the control would be theatre. That separation — the one who creates may not be the one who approves — is segregation of duties, and here the document enforces it. ME29N = release one PO; ME28 = release a whole worklist at once.

Verify: ME29N / ME23N → the PO now reads status "Released" and can be output · ME2N → list POs by release status to confirm the blocked-vs-released split, and that only R13 POs were ever caught.

💡 Workflow integration

SAP Workflow (SBWP, the Business Workplace) can notify the approver when a release is pending, so they don't have to watch ME29N. Use SBWP to see pending approvals in the inbox.

🐞 Errors we hit live — and how to fix them

Every row below is a real message we hit on PakSteel IDES while building this scenario — from the chatty CT04 notes, through the big ME492 block that stopped every save, to the runtime message on the test PO — each linked to the Prerequisite or Step that clears it. Some are harmless information notes; two (ME492 and the "not subject to release strategy" message) are the real, important ones this scenario is built around.

Where it appears	The message SAP shows	What it means & why it happens	How to fix it
Characteristic — 13.1 (CT04, Addnl data, after Enter)	"Format data used from ABAP Dictionary"	You pointed the characteristic at table field `CEKKO-GNETW`, so SAP copied that field's technical format (type CURR, 15/2) automatically. It's confirming, not complaining.	Just press Continue — the format is correct — Prerequisite ②.
Characteristic — 13.1 (CT04, Basic data)	"Enter a currency"	Because `GNETW` is a money field, the characteristic is a currency characteristic — and a currency characteristic must carry a currency unit.	Type `PKR` in the Currency field on the Basic-data tab — Prerequisite ②.
Characteristic — 13.1 (CT04)	"Multiple-values indicator refers to a reference characteristic"	An information note: because the characteristic points at a real table field, SAP flags that the "multiple values" setting is tied to that reference. The setting is valid.	Press Continue; keep Multiple + Interval ticked — Prerequisite ②.
Purchasing group — 13.3 (OME4, New Entries)	the group name would not fit / was truncated	The purchasing-group description field (`EKNAM`) holds only 18 characters, so a long name is rejected or cut short.	Keep the name short — we used "Release Test Sc13" — Prerequisite ⑤.
Release groups — 13.4 (SPRO / SM30 `V_T16FG`, on Save)	"Please check release classes" (message ME492)	The big one. Two PO release groups pointed at different classes — a broken pre-existing group `02` (its class `ZMM_PO_RELEASE` had been deleted, leaving ~59 orphaned strategies) versus our new group `Z1` on class `Z_PSPK_PO_REL`. All PO release groups of the same overall-release type must share ONE class, so the whole config was inconsistent and no new group would save.	Make all PO release groups use one class: delete the ~59 orphaned strategies, then delete the broken group `02`, leaving only `Z1` — Prerequisite ⑥.
Release codes — 13.4 (SM30 `V_T16FC`)	"Entry Z1 does not exist in T16FG (check entry)"	You tried to add release codes for group `Z1` before the release group itself was saved. Codes hang off a saved group.	Create and save release group `Z1` (view `V_T16FG`) first, then add its codes — Step 13.4.
Test PO — 13.5 (ME21 / ME21N item, Tax code)	"Tax code V0 in procedure TAXPAK is invalid"	We first tried tax code `V0`, but it is not a valid code for Pakistan's tax procedure `TAXPAK`.	Use `I0` (0% input tax) on the PO item — Step 13.5.
Test PO — 13.5 (ME21N header, Release strategy)	"Purchasing document not subject to release strategy"	Despite fully correct, consistent config (CL24N active, OMGSCK clean), the strategy did not attach. Earlier delete/re-create churn of the characteristics and class left dead internal-ID links (`ATINN`/`CLINT`) in the hidden classification tables `KSSK` / `AUSP` / `INOB`, which the runtime reads directly — so it finds no match. Not a config error.	One-time Basis job (no config change): run `RCCLINOB` / `RCLINOB2` / `RCCLUKA2` / `RCCLZUOB` to rebuild the internal links, then re-test — Step 13.5.

✅ Verification — Confirm Scenario 13 Worked

#	T-code	Check
1	CT04	Both characteristics exist: `Z_PSPK_PO_VAL` (ref `CEKKO-GNETW`, CURR PKR) and `Z_PSPK_PO_PGRP` (ref `CEKKO-EKGRP`, CHAR 3). (live ✅)
2	CL02	Class `Z_PSPK_PO_REL` (class type `032`) shows both characteristics on the Char. tab. (live ✅)
3	OME4	Purchasing group `R13` "Release Test Sc13" exists and can be chosen in a PO. (live ✅)
4	SM30	Views `V_T16FG`/`V_T16FC`/`V_T16FS` show group `Z1` (class `Z_PSPK_PO_REL`), codes `Z1/01`+`Z1/02`, and strategy `ZS` with classification `R13` + ≥ 500,000. (documented)
5	ME21N	A PO in group `R13` for ≥ 500,000 → on Save shows "Blocked for release"; a PO in another group is not blocked (proves the scope). (documented)
6	ME29N	Release code `01` then `02` → status flips to "Released"; code `02` only becomes active after `01`. (documented)

🎓 Interview-Ready Answers

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

Five pieces: (1) Characteristics (CT04) define what the strategy keys on — here total net value via CEKKO-GNETW and purchasing group via CEKKO-EKGRP; (2) a Class of type 032 (CL02) groups those characteristics; (3) the Release Group (V_T16FG) ties the class to a folder; (4) Release Codes (V_T16FC) are the approver stamps (Z1/01, Z1/02); (5) the Release Strategy itself (V_T16FS) combines the codes, the release prerequisites (sequence), and the classification values that select it (here R13 + value ≥ 500,000).

Q: Why did you create a dedicated purchasing group R13 instead of just keying on value?

Because a release strategy fires for every PO whose values match. Keying on value alone (e.g. "≥ 500,000") would freeze every high-value PO in the whole system and stop everyone's work. By adding purchasing group R13 to the classification (R13 AND value ≥ 500,000), the strategy only catches POs raised under that one dedicated group — so the control is real but scoped, and nobody else's POs are disturbed. Scoping a test or new strategy this way is the safe standard.

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 read different header structures — PO release reads CEKKO, PR release reads CEBAN — so the characteristics differ. Our class is 032 on CEKKO, which is also why the release object is a PO automatically, with nothing to type.

Q: How do you enforce that Finance releases only after Purchasing?

In the release strategy (V_T16FS), set Release Prerequisites: mark that code 02 (Finance Head) requires 01 (Purchasing Mgr) first. That makes the chain sequential — 02's Release button in ME29N stays inactive until 01 has released. Leave prerequisites blank and both can release in any order (parallel).

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, sending, and goods receipt until the value-appropriate approvers release it, in order. Spend authority is enforced structurally and is fully auditable, rather than relying on email or trust. And IDES proves the mechanism is production-grade: it already runs release group 02 / class ZMM_PO_RELEASE with 75 live strategies.

✅ Scenario 13 complete — Scoped PO release strategy configured + tested

← Previous

Scenario 12: Third-Party Drop-Ship

Scenario 14: Source Management