Auditing and Understanding PO Release Strategy in SAP

How PO Release Strategy works. Which Tables to Extract. What configurations needs to be tested. How PO release strategy is set up. Auditing PO approval process.

Introduction

For any organization, it is imperative that all purchases (i.e. action which results in an outflow of Money) is controlled. Since Purchase Order is the starting point of the Procure to Pay cycle, it is the best place to implement controls. It’s at the time of PO creation where the negotiation with vendor will take place and organization will decide – Vendor, Quantity, Price of the Materials to be purchased / procured. Thus a purchase order (PO) needs to be approved as per the Authority Matrix designed by the organization. For managing PO approval, we have “Release Strategy” in SAP.

PO release strategy is an important control for any organization. Due to the complexity of the setup of PO release strategy, it is important to audit (aka Test) the PO release strategy control.

How it works

For general users who create PO, PO release strategy is very straightforward. Users will create PO using ME21N and system (i.e. SAP) will automatically trigger the applicable release strategy.

Triggering – The release strategy is triggered based on the defined configurations in SAP. Once the release strategy is triggered for a PO, system mark that PO as “Blocked”. The field “Release Indicator” is used to denote the current status of PO. Until the “Release Indicator” is not set to “Y” i.e. Final Released, the system will not allow creating a GRN with reference to the PO.

Business requirement for PO approval

Let’s take an example for a giant multi-billion $ organization – ABC. The organization will contain many legal entities, say – A Ltd, B Ltd (Defined as Company Code in SAP). Each Company / Legal Entity will have many plants, say – Plant X, Plant Y. There will be some categorization of purchase orders like – Local Purchase, Imports, Purchase of Fixed Assets, etc.

In the above case study, the business requirement could be as follows, for all local purchase orders approval is required if the amount is greater than 10,000 INR. If local PO amount exceeds 10,000 INR it will require the approval of purchase manager. If more than 10 Lac, approval of HOD. If more than 1 Cr approval of Accounts Head. For a certain plant, (say, Plant X) approvals will be – up to 1 Lac approval from a manager and more than 1 lac approval from plant head.

Thus, the business requirement can be pretty complex and diverse. In order to tackle this, SAP provides various options to define / configure release strategy. 

How is PO Release Strategy Configured

When an organization plans to implement a PO release Strategy, it has to first decide on the parameters to be used for defining PO Release Strategy. SAP provides a long list to parameters which can be used to define release strategy. Some of the example – PO Amount, Company Code, Plant, Purchasing Org, PO Document Type, Purchasing Group, Currency Key, Material Group, Vendor Subrange.

The fields to be used for configuring release strategy are defined in “Characteristic” This can be accessed using TCode “SPRO” Material Management > Purchasing > Purchase Order > Release Procedure for Purchase Order > Edit Characteristic.

If we want to configure PO release strategy based on just “Plant” and “Total net order value” then we will create 2 Characteristics. If we want to also use Company Code, we will create another characteristic with “Company Code”.

Next, we create “Class”. This can be accessed using TCode “SPRO” Material Management > Purchasing > Purchase Order > Release Procedure for Purchase Order > Edit Class. In class creation, we specify which Characteristics to be used. Think Class as a group of Characteristics.

Next, we create “Group” also called “Release Group”. We assign the class to a group. Group and Class have many to one relationship. This relationship is saved in Table – “V_T16FG_2” which can be downloaded using SE16N.

Next, we define “Code” also called “Release Code”. Release code is generally defined as per the approval hierarchy. If we have 3 people for approval, we shall create 3 release codes. This is the time we give a name to each Code. Release code as used as a means to restrict access to approve / release a PO, as we will see later.

Next, we defined “Strategy” also called as “Release Strategy”. This is the heart of the entire PO Release Strategy Configuration. Here we define following things

1. Hierarchy of Release Code – which release code is 1st and which release code is last. Example, Assistant Manager will be 1st and then Manager’s release code.
2. Release Status – what happens when a release code is released, basically, what value will be set to “Release Indicator” field of PO. Thus the for our last release code, we shall set “Release Indicator” to be “Y”. We can set anything for intermediate release codes.
3. Classification (i.e. Condition based on which this strategy is triggered) – Based on the “Characteristics” defined we get to specify whether this (the strategy which we are configuring) particular release strategy will trigger or not. For example, we have defined “Characteristics” for – “Company Code” then here we will define particular “Company Code”. If we had defined Plant and PO Amount in “Characteristics” then, we shall specify plant and PO amount.

Take a deep breath 🙂 

Based on the discussion above, we can summarize that PO release strategy is a result of careful planning. If a lot of thought process is not put into the planning phase of release strategy things can easily get out of hand and there can be scenarios which do not trigger any release strategy. Example where release strategy is not triggered – suppose as “Characteristics” we use – Plant and PO amount, then we need to make sure that all the plants are defined in “Condition” while defining “Strategy”. If any plant is missed out, PO created for that pant will not trigger PO Release Startegy. This will lead to P2P process without PO approval.

Let’s Test PO Approval

1. Configuration Testing
2. Substantive Testing

We need not use both the approaches for testing, but knowing both the approaches will definitely help in autiting.

Substantive Testing

First, we need to check if for all PO the release strategy was triggered or not. By using TCode SE16N extract Table EKKO.

The Fields that we are interested are – Release group (FRGGR), Release Strategy (FRGSX), Release Indicator: Purchasing Document (FRGKE), Release status (FRGZU), Release Not Yet Completely Effected (FRGRL). Along with these fields, we also need to extract – Purchasing Document Number (EBELN), Purchasing Document Type (BSART), Purchasing Group (EKGRP), Purchasing organization (EKORG), Currency Key (WAERS), Supplying Vendor (LLIEF) to try analysing the link between the release strategy and these fields.

We shall use following fields to scope EKKO Table. Company Code (BURKS) [Company Code in Audit Scope], Purchasing Document Category (BSTYP) [only “F” i.e. Purchase Order], Date on which the record was created (AEDAT) [Audit Period in Scope].

The list we generate will still contain some Purchase Orders which we don’t’ need for testing like:

• Deleted PO
• PO where all line items were deleted
• Incomplete PO

To exclude such PO, we need to combine another Table – EKBE (History per Purchasing Document) which contains a history of all the transactions with reference to a PO. We can combine the table using TCode SQVI. We just need to link the table. No need to extract any data from this table. Just join these table. Joining these tables will exclude all the PO for which no further processing has taken place. However this will also exclude PO which are complete but no GRN or Invoicing is done. But these casese will be very rare and can be considered as immaterial.

Analysis of the extracted data

We can perform the following analysis

1. Check if there is any PO where release strategy is not triggered. If we find any such cases this forms an audit observation and possible control failure.
2. Using Pivot tables, try to figure out if there is any linkage between Release Group & Release Strategy with Pur Org, Plant, PO Document Type.

Configuration Testing

Configuration Testing of PO Release Strategy is divided into following

1. Identifying Class assigned to Release Groups and Characteristic assigned to Class

The Release indicator can be set as:

1 Cannot be changed
2 Changeable, no new determination of strategy
3 Changeable, new release in case of new strategy
4 Changeable, new release in case of new strat. or val. change
5 Changeable, new release if new strategy/outputted
6 Changeable, new rel. if new strat. or value change/outputted
   Changeable, new release in case of new strategy 

The recommended configuration is either 4 or 6.