SAP ME21N: why the release strategy is not determined on a purchase order
SAP ME21N purchase order release strategy not determined, PO saved without release
Also searched as
- SAP release strategy not triggered ME21N
- SAP PO release strategy not found class 032 CEKKO
- why is my purchase order not going for approval in SAP
Short answer
When a purchase order saves without a release strategy, no strategy in the release group matched the PO's characteristic values. Compare the PO header values (value, document type, purchasing group, plant) against the value ranges in the strategy classification (CL24N), and check that the release group and code are active for the PO document type.
Applies to: SAP ECC 6.0 and S/4HANA on-premise, classic release procedure for POs (not the flexible workflow approval in Fiori)
Debug why no strategy is assigned
- 1Open the PO in ME23N and go to Header > Release strategy tab. If it is empty and the PO is not blocked, the strategy was never determined. Note the net value, document type, purchasing group, plant and account assignment category.
- 2In SPRO go to Materials Management > Purchasing > Purchase Order > Release Procedure for Purchase Orders > Set Up Procedure with Classification, and check that the release group (for example 01) is assigned to the PO object, and that the release indicator and strategy exist.
- 3In CL20N, display class type 032 and the release class for your group. Check that the characteristics (for example CEKKO-GNETW, CEKKO-BSART, CEKKO-EKGRP, CEKKO-WERKS) are assigned and that each has a value range covering your PO.
- 4In CL24N, open the release strategy and look at the Classification screen. Every characteristic that has values on the strategy must match the PO. A characteristic with no values on the strategy acts as a wildcard.
- 5Check the currency. GNETW is compared in the characteristic's currency, usually the company code or a fixed one, and a PO in another currency is converted at the rate for the document date.
- 6If the PO already exists, change a value and re-save, or use ME28 or ME29N to see whether a strategy appears. Strategy determination reruns when relevant fields change, not on every save.
- 7Transport the corrected classification, because release strategies are customizing plus classification data, and classification changes need their own transport or manual replication in each client.
How determination actually works
The classic release procedure builds a communication structure, CEKKO for the PO header, and fills it from the document when you save in ME21N. SAP then looks through the release strategies in the release group for the one whose classification values all match the CEKKO fields. If exactly one matches, its release group and strategy are written to EKKO (fields FRGGR and FRGSX). If none match, nothing is written and the PO behaves as released.
Each strategy is stored in table T16FS, the release codes in T16FC, and the prerequisites between codes in T16FV. The characteristic values for the strategy sit in the classification system, not in T16FS, which is why a customizing screen can look perfect while determination still fails.
Because the match is an AND across characteristics, the most common cause is a value range that is slightly off: a PO of exactly 10,000.00 against a strategy that covers 10,000.01 to 50,000.00, or a document type NB against a strategy that lists only FO.
-- Header release data on the PO
SELECT EBELN, BSART, EKGRP, FRGGR, FRGSX, FRGKE, FRGZU, FRGRL
FROM EKKO WHERE EBELN = '4500001234';
Value range gaps and overlaps
Two strategies in the same group that both match produce a determination conflict, and SAP picks neither or the one it finds first depending on release. Gaps are the opposite problem: no strategy covers the PO. Review all strategies in the group side by side and make the ranges contiguous, with the upper bound of one just below the lower bound of the next.
For value characteristics, use the same decimals and currency across strategies. Mixing a range defined in USD with one defined in EUR is a frequent source of confusing behaviour after a company code restructure.
If you want a PO to need no approval under a threshold, create an explicit strategy with no release codes or rely on the gap, but document the choice. A gap by accident and a gap by design look identical in the system.
Fields that trigger a re-determination
Not every change reruns determination. Changing the net value, the document type or the purchasing group typically does. Editing text or delivery dates does not. If a user lowered the value after the PO was released, the existing release state is reset and the PO goes through the strategy again.
For items, SAP also supports the item-level procedure for purchase requisitions through class 032 with the CEBAN structure, which is a different customizing node. Check you are editing the PO node and not the requisition node, because both live under Purchasing and have similar names.
Authorizations and release codes
A strategy that is determined but has nobody who can release it looks like a stuck PO, not a missing strategy. Release codes are protected by authorization object M_EINK_FRG with the group and code. Verify with SU53 or the authorization trace in ST01 that approvers hold the right code, and that the prerequisite codes in the strategy are released first.
Common pitfalls
- !Editing the strategy in customizing but forgetting the classification values in CL24N, which is where the matching happens.
- !Overlapping value ranges across strategies in one release group, producing no determination or the wrong one.
- !Testing with a PO in a different currency than the characteristic and assuming the number you see is the number compared.
- !Transporting customizing but not the classification data, so the strategy works in development and fails in test.
- !Expecting a changed strategy to apply to existing POs automatically. Existing documents keep their strategy until a relevant field changes.
How an ERP-grounded AI assistant handles this
An assistant grounded in your SAP system can take a PO number, read the EKKO header and the CEKKO-relevant values, then walk the strategies in T16FS and their classification ranges to say which characteristic fails to match and by how much. ERPray reads this data read-only and shows the query it used, so the buyer or key user sees the evidence. Fixing the classification stays a human change under your normal transport process.
Frequently asked questions
Why does my PO save as released when I expect an approval?
Because no release strategy matched the PO's values, SAP writes no release group and treats the PO as released. Compare the header net value, document type, purchasing group and plant against the ranges in the strategy classification in CL24N. A single characteristic outside the range is enough to prevent determination.
Where is the release strategy stored?
The strategy master is in table T16FS and the release codes in T16FC, but the characteristic values used for matching live in the classification system under class type 032. On a PO, the assigned group and strategy are stored in EKKO fields FRGGR and FRGSX.
Does the release strategy rerun when I change the PO?
It reruns when a field relevant to the communication structure changes, such as net value, document type or purchasing group. Changing a text or a delivery date does not trigger it. You can force a check by changing a relevant value and saving, or by using ME28 on the document.
Can I use Fiori approval instead of the classic release procedure?
In S/4HANA, flexible workflow approval for purchase orders is available as an alternative to the classic procedure. It is configured differently and the two should not be mixed on the same document type. If you already have a working classic setup, there is rarely a reason to migrate it just for the interface.
Related
SAP MIRO: invoice blocked for price variance, and how to release it in MRBR
MIRO blocks an invoice for payment when its price or quantity differs from the PO or goods receipt by more than the tolerance limits defined in OMR6. The invoice posts, but it carries a payment block reason (R for price) until someone releases it in MRBR or corrects the underlying data. Release only after confirming which side is wrong.
How-toHow to Use BAPI_TRANSACTION_COMMIT Correctly
SAP's BAPI programming model separates business logic from the database commit on purpose, so a caller must explicitly call BAPI_TRANSACTION_COMMIT after a successful BAPI - usually with WAIT = 'X' - or the created object never actually persists. Skipping this step, or forgetting WAIT, is the most common reason a BAPI 'runs fine' but nothing gets saved.
How-toSAP open purchase orders report: ME2N, ME2M, ME2L and the underlying tables
Use ME2N for a flexible open PO list, ME2M by material and ME2L by vendor, with the selection parameter Still to be delivered. The open quantity is the scheduled quantity in EKET minus goods received in EKBE, excluding deleted and delivery-completed items. For custom reports, read EKKO, EKPO, EKET and EKBE.
Error fixSAP M7 021: Deficit of SL Stock Quantity
M7 021 fires during a goods issue, delivery, or confirmation when SAP checks the unrestricted-use (SL) stock for the exact plant, storage location and batch combination and finds less than what you are trying to post out. Fix the entry (batch, storage location, quantity) first; only enable negative stock or downgrade the message to a warning if the business genuinely needs to post ahead of a receipt.
Error fixSAP IDoc Status 51: Application Document Not Posted
Status 51 tells you the IDoc reached the application layer and failed to post, but the status text itself is not the error - the real cause sits in the status record's long text or the linked application log. Fix the underlying data or configuration, then reprocess the IDoc through BD87 rather than editing the status.
Error fixSAP Short Dump TIME_OUT: Maximum Runtime Exceeded
A TIME_OUT runtime error means a dialog (or RFC) work process ran longer than the maximum allowed runtime, controlled by profile parameter rdisp/max_wprun_time (600 seconds by default). The fix is almost always to move the long-running work to background processing or tune the underlying program, not to raise the timeout.
AI for ERPAI for SAP S/4HANA, Running On-Prem or in Your Private Cloud
Run AI on SAP S/4HANA without sending ERP data to a public API. On-prem and private-cloud architecture, CDS views, OData, and honest deployment trade-offs.
AI for ERPAI Agents for SAP Production Planning, MRP, and Exception Triage
AI agents that triage SAP MD04 exceptions, explain predictive MRP shortages, and draft planned-order actions, grounded on your own SAP data, deployed on-prem.
Stuck on SAP ECC / S/4HANA?
Talk to engineers who work inside SAP ECC / S/4HANA every week, and who build private AI that answers these questions from your own ERP data.