Yes, I know, you are skeptical. But Purchasing Release Strategies can be made easy if you understand the fundamental concepts of how to configure them and to follow the KISS principle (keep it simple, stupid). In this article, I will point out some tips and tricks I have learned through implementing Purchase Requisition Release strategies at seven different client locations with very different purchasing approval methodologies. This article will also explore some tricks to managing the constantly changing security roles and assignments due to company reorganizations or attrition.
This post was originally written using SAP R/3 Enterprise (4.7). It is applicable for all SAP R/3, mySAP ERP, and current release of ECC 6.0.
I will present a four-step process to lead you through the setup and implementation. Each step offers tips to help you tiptoe through the potential minefield of gotachas.
This can actually represent the most difficult step in any organization.
The reason here is not to make the implementer’s job easier, but to make it easier for people responsible for entering purchasing requisitions to know who must approve the requisition. I cannot tell you how many times I have agreed to implement a complex release strategy, only to go back later and simplify. Why? Because the user community complained that it was too difficult to figure out who was responsible for holding up their requisition from becoming a Purchase Order.
In my experience, most companies base purchasing approvals on Cost Centers. I have implemented purchasing groups to be synonymous with Cost Centers. This allows you to not require the Cost Center on purchase requisition.
Figure 1 illustrates the example I will follow for this article. I will use two values from which to determine the release strategy:
Figure 1: Department Position Approval Limits
|Object||Transaction||Check (Target)||Message Type (BD64)||Notes|
|BD91||CT04||CHRMAS||Don’t worry about IDOC error message “Object S2L3 (T16FS) not found”.|
Class Type: 032
Class Type: 032
The Example presented in this article is for an Overall Release procedure. This means that when someone approves the requisition, they are approving the entire requisition, and not each line. This simplifies the action required on the approver, because they only have to approve once, but it does restrict you from allowing your users to combine purchase requisitions across departments.
SAP has published a decent note that includes a .pdf document (Note 207490) with steps on how to complete the configuration. Below, we’ll discuss the three components of configuration: (A) Create Characteristics, (B) Create Class, and (C) Define Release Strategy.
To start, navigate the IMG (Implementation Guide) using transaction SPRO. Follow the menu path: Materials Management > Purchasing > Purchase Requisition > Release Procedure > Procedure with Classification, then
A) Create Characteristics:
In Step 1, you probably developed an approval matrix in Excel or on a napkin. Now you need to translate that Release Strategy. What you need to ask is, “what are the parameters that determine the approval person?”
In the scenario illustrated in Figure 1, the parameters that determine the approval person are:
These two parameters equate to characteristics. The characteristics must be represented by values entered in the purchasing document. In this scenario, the characteristics will be:
To determine what parameters are available as characteristics, run transaction SE11 and view table CEBAN. This table stores what fields are available in the release strategy determination. Figure 2 shows where to correlate the characteristic to the field used for determination from CEBAN.
Once you complete the Reference to Table/Field, SAP will import the characteristic formats from the data dictionary (the SAP table/field definition). If you click on the Basic Data tab, you will see the data format and value assignment pulled in from the data dictionary field definitions.
B) Create Class
Once you have created your characteristics, you must assign the characteristics to a class. On the first screen, make sure you use the Class Type 032, which is the class type for Release Strategy.
C) Define Release Strategy
Here we’ll discuss 5 steps for your Release Strategy definition: Release Group, Release Codes, Release Indicators, Release Strategies, and finally we’ll discuss the tie in to Workflow.
1 Create Release Group
In this step, you create release groups (Figure 5). A release group will have the same release levels and strategy. In the scenario illustrated back in Figure 1, there will be two release groups needed because the approval interval values are different between the two departments. If there were a third department that had the same approval interval values, it could share a release group and the release strategy would be for more than one department (or in this example, purchasing group).
2 Create Release Codes
A release code is an identifier that is associated with the person responsible for approving the purchase requisition (Figure 6).
3 Create Release Indicators
A release indicator shows the release status of a purchase requisition. In the standard system, a purchase requisition release status is either “Blocked” or “RFQ/Purchase Order”. The “RFQ/Purchase Order” status indicates that the Purchase Requisition has been fully released and can now be converted into an RFQ or Purchase Order.
In the standard system, SAP will not allow changes to the quantity, unit of measure, or price when an approver is executing the release transaction. If you require that other fields, such as delivery date, plant, etc, not be modified via the release transaction, follow TIP #8.
It is also possible to configure the release to not be restarted if the amounts have only changed a specified percentage. To do this, enter “4 – Changeable, new release in case of new strategy or value” and a percentage in the “Value chgs” field, as shown in Figure 7.
4 Create Release Strategies
A Release Strategy is a combination of the Release Group and Release Code. The Release Group combines the release codes (think of them as release levels) and each combination gets assigned a release strategy. For each release level (or code) you will define the prerequisites required to get to that release level, release status, and the characteristic values that place the release into that release level.
I have never experienced a business rule that allowed a higher-level approver to approve a purchase requisition prior to or simultaneously with a lower level approver. In other words, I have not had a client that wanted the purchase requisition release to go to the approval queue of a director at the same time as the same approval request went to the manager. A director usually wants his/her manager to approve the expense before they approve it. So, it makes completing the Release Prerequisites screen easy to complete (even though, when you view the screen, it is very confusing). I just check the boxes in the lower left corner, like in Figure 8.
In the classification screen shown in Figure 9, you assign the values or ranges of values to the Release Strategy.
5 Workflow: Assign Release Codes to Release Point
Note: You only have to perform this step if you wish to link this release procedure to Workflow, and are not using customer exit M06B0001.
Here’s a brief description of how Purchase Requisition Release Strategies work in SAP.
Security can be the most time consuming activity in developing release strategies – particularly if you have used multiple characteristics to define your release strategies and you have multiple release levels. Again lies that recurring theme of “Keep it Simple”. Also, not that you don’t want the job security for your Basis Security Administrators, but you want the change process to not be overly complex, so you can react quickly when there is a major company reorganization.
You should set up a role for each Release Group/Release Strategy combination. For further security, include either in this role or another role, the restriction for other values that you have assigned as characteristics, such as Purchasing Group.
This is the most overlooked step in the process. The transport you created in Step 3 in your “Gold” SAP Configuration client, does not include the values you associated to the characteristics. They are stored in characteristic value tables that must be moved through your SAP environments via the ALE (Application Link Enabling) function.
Figure 11 is a sample spreadsheet of transaction codes, which you can provide to your Basis team.
Object Transaction Check (Target) Message Type (BD64) Notes
|101||Manager||Up to $10K|
|101||Director||Up to $50K|
|101||VP||Up to $100K|
|101||CFO||Everything Over $100K|
|102||Manager||Up to $5K|
|102||Director||Up to $50K|
|102||VP||Up to $200K|
|102||CFO||Everything Over $200K|
In this article I attempted to lay the groundwork and provide some good tips to help beginner SAP Configurators journey down the path to developing a Purchasing Approval solution. Purchase Requisition release strategies have always ranked high on my list of the ‘tricky’ configuration challenges (others include Condition Techniques and Account Assignments for Inventory Management). But, with a little time and commitment, you too can master this skill!
Additional information on SAP’s purchasing module is available in our SAP purchasing training course offering.