Purchase requisition workflow, available in SAP ERP, is a useful tool for performing electronic and digital approvals. This commonly used tool offers several advantages to help your company use less paper by facilitating approvals, automatically notifying approvers of pending requisitions, and sending reminders. In most companies, both cost center approving managers and department managers must approve expense requisitions, such as for the purchase of office supplies. Several challenges further complicate this process, including:

• Setting up an approval hierarchy or organizational chart
• Needing approvals by multiple departments (e.g., by a procuring department followed by the controlling department)
• Approving managers going on vacation
• Sending approval reminders
• Meeting compliance regulations

I will explain how to configure requisition approvals using workflow and how to set up some common business scenarios, such as vacant positions. I will also explain how you can ensure Sarbanes-Oxley compliance by setting up the correct authorizations for approving requisitions.

Overview of Purchase Requisition Workflow

Implementing purchase requisition workflow requires understanding the following key areas:

• SAP Business Workflow: You need to understand the business object types used for requisitions (BUS2015), how to trigger the workflow, what methods are, how to code workflow, and how deadline monitoring works

• Requisitions: Requisitions can be broadly categorized as direct or indirect requisitions. Direct material requisitions are driven by Material Requirements Planning (MRP) and are automatically created during the MRP run. Indirect requisitions are created manually, usually with text descriptions of the requested materials and no material numbers. Indirect requisitions also contain the cost centers to which the requisitions are expensed.

• SAP ERP Human Capital Management (SAP ERP HCM) organizational structure: If you are using an HR organizational structure, you need to understand how to set up organizational hierarchies in SAP HR using transaction PP01 (Figure 1). “O” indicates organization, “S” is for position, “K” is for cost center, “C” is for job description, and “P” indicates person.

Figure 1

Organizational chart

With these prerequisites in mind, I will take you through the 10 steps to streamline your requisition approvals process.

Implement Purchase Requisition Workflow

Step 1. Identify the organizational structure to model in your SAP system. To understand the structure better, I recommend you model the organization in a chart using either a mini-HR chart or a z-table.

The mini-HR chart sets up the organizational hierarchy, but has limited functionality, including organizational structure and infotypes. Infotypes are logical groupings of employee data. There are more than 300 infotypes in SAP HR that you can use to capture employee data. For example, you use table HRP1001 (infotype table) to store users, positions, jobs (i.e., organizational chart), and their relationships, such as “belongs to”, “described by”, or “supervisor of”. You populate this table using transaction PP01. Similarly, infotype PA015 (personnel information) captures employee addresses. Once you've maintained this table, you can use it in the workflow steps through a special technique called methods. Methods are tasks that you can perform using workflow. I explain how to use methods in detail in step 9.

The z-table also sets up the organizational hierarchy with a z-table. Tables 1 and 2 show how you can create the organizational hierarchy using the z-table. Table 1 is used to maintain the cost centers (departments), the person associated with the department, and the release codes. Release codes identify the level or position of a person in an organization, such as Director, Senior Manager, or Manager. Table 2 is the z-table's substitute approver table for the table in case the main approver goes on vacation.

You can reference the mini-HR chart or the z-table in the workflow steps using methods. The system can call these tables through the workflow and obtain the correct approving authority. Steps 8 and 9 describe how the z-table and the mini-HR chart are referenced in workflow. To help you decide which table to use, I have outlined the pros and cons of both of these tables in Table 3.

Step 2. Identify the key parameters that trigger the requisition approvals. Most organizations use the following parameters:

• Dollar limits
• Purchase organization
• Material groups
• Cost centers (departments)
• Requestor
• Plants
• Purchasing groups
• Purchase requisition document type

Step 3. Set up release groups in the SAP system. The release group is a way of differentiating release strategies. For example, you can define a release group to approve expense requisitions or another group for direct MRP requisitions. You can even define multiple strategies for each release group. For example, a release group for expense requisitions can have multiple strategies, such as approvals up to $5,000 or approvals up to $10,000. Similarly, a release group for direct MRP requisitions can have its own set of approval strategies.

You can use classification, a tool that SAP provides as standard functionality, if you want to access more parameters for release strategies. The purchase requisition data is passed on to the classification system and the value on the requisition is compared to the values defined in the release strategy. The approval is activated if there is a match. Setting up release procedures with classifications requires you to define the class and characteristics which are linked to the release group (Figure 2).

Figure 2

Release group linked to class

In my example, the release group links to class Z_CLASS. If workflow is required, you must define classification (class and characteristics). Z_CLASS has the characteristics to use with the release procedure. For example, if you decide to use Dollar Amount and Cost Center as parameters in the approval procedure, you define them as characteristics in Z_CLASS.

SAP also provides communication structures, which you can use to identify the parameters in the requisition approval process. These structures pass the value from the purchase requisition when the approval is triggered. The communication structure CEBAN identifies the various parameters that are available. CEBAN fields must be associated with the characteristics you are using. Figures 3 and 4 show how the class Z_CLASS links to the characteristics and how these characteristics associate with the CEBAN structure to pass the values from purchase requisition.

Figure 3

CEBAN structure

Figure 4

Defining classes and characteristics

Class Z_CLASS uses the fields defined in CEBAN as characteristics. For example, if you use Cost Center as a parameter in approval procedure, that parameter needs to exist in the CEBAN structure. In CEBAN, Structure Cost Center is represented as CEBAN-KOSTL. Create the characteristic COSTCENTER and then link it to CEBAN-KOSTL (Figure 4). The various parameters that are required for triggering the approval (such as Cost Center and Amount) also need to exist in the CEBAN structure.

Figure 4 shows that the characteristics COSTCENTER and Dollar Amount (TOTALDOLLARVALUE) associate with class Z_CLASS. For example, the characteristic COSTCENTER links to the CEBAN communication structure field CEBAN-KOSTL. This association enables the value of COSTCENTER to be available as a parameter when the system needs to determine whether it should activate the requisition approval or not.

Step 4. Associate release groups with release codes. The release code represents the position of the person approving the requisition. This step identifies all the relevant positions that you can use with a release group. Refer to Figure 3 to see how Release Group Z1 allows the Manager, Senior Manager, Director, and VP to approve the requisitions.

Step 5. Set up release strategies. The release strategy differentiates how the approval needs to be triggered based on the parameter combinations you choose. For example, release strategy Z1 can be triggered if the monetary value exceeds $5,000, the material group is 00715, and the requisition has a cost center. The manager, senior manager, director, and vice president must approve the requisition. The release strategy provides the variations for the release group by using the characteristics. For example, one release strategy can use total Dollar value of $5,000 for approval and another release strategy can be for 10K. Figures 5, 6, and 7 show how the release group links to release strategy and, in turn, how they link to characteristics.

Figure 5

Release group linked to release strategy

Figure 6

A linked characteristic

Figure 7

Another linked characteristic

In the previous step, I identified the various positions (such as manager or senior manager) that a release group can contain. Not all of these positions are required for every variation of approval. For example, if the requisition dollar amount is $5,000, it may not require the vice president to approve it. On the other hand, if the value of the requisition is $50,000, it can require a manager, senior manager, director, or even vice president to approve it. Here is where the release strategy comes in handy. You can use it to define a release strategy for the $5,000 requisition that requires just a manager's approval as the release code. Similarly, you can define another release strategy for the $50,000 requisition, which requires approval from the manager, senior manager, director and vice president.

Step 6. Associate workflow with release codes. If you need to trigger workflow, you need to associate the release code with workflow setting 1 or 9. When using setting 1 instead of 9 (indicated by 01 in Figure 5) the system automatically looks for entries in Table T16FW (Figure 6). In this case, the role resolution is based on release group release codes and plant. You determine the role using this combination. You can determine the role using the organizational unit (Agent). This can be a user (U), position (S), or job (C). This links to the mini-HR chart discussed in step 1. Figure 8 shows the agents who are users. If you use C or S as the organizational unit instead, you can set up the mini-HR chart. As in the case of an overall purchase requisition release, the Plnt column is not significant, so you can leave it blank.

Figure 8

Release group and release code link to role using organizational unit (O) = U

If you need additional parameters to resolve roles and table T16FW does not suffice, use setting 9 (role resolution) to determine the role. Setting 9 calls user exit M06B0001 and uses user exit ZXM06U12. Use setting 9 and maintain the approvers in the organizational chart in an HR or a z-table.

Imagine the situation in which multiple cost centers, such as the buying department or another overseeing department (e.g., controlling department), have approved the requisitions. In this case, you associate the release codes with setting 9, do the necessary coding in the user exit, and maintain a z-table or mini-HR chart to contain the entries for various departments. Obtain the buying department requisition code by reading the requisition. Be sure to indicate the finance department in the user exit and then retrieve the approvers for the finance department. Figure 9 shows how setting 9 can be set in the table under Workflow.

Figure 9

Role resolution using a custom exit

Once you have associated setting 9 with the release code, as shown in Figure 9, the system automatically calls user exit M06B0001. In this user exit, you can customize the role by ABAP coding.

Step 7. Set up release indicators. Determine the release indicator at the time of creation via the release strategy that applies to the purchase requisition. Setting this indicator blocks the requisition until all the approvers have approved the requisition. Upon final approval, the requisition is ready for release and can be converted to a purchase order (Figure 10). The system determines the release indicator depending on the number of approvers required to approve the requisition. For example, if there are two required approvers, the release indicator on the purchase requisition remains blocked until both the approvers have approved it.

Figure 10

Setup of release codes

You usually do not need to configure release indicators. You can use the field selection key to control which fields users can change after approval (e.g., they cannot change quantity and price after approval). To set up release indicators, follow menu path IMG > Purchase Requisition > Release Procedure > Setup Procedure with Classification > Release Indictor. Although the release indicators usually do not change, the description can occasionally change. For example, release indictor 2 is for purchase orders or requests for quotations. As an exception, if you only need to release purchase orders, you can change the description to purchase order release.

The value change controls the triggering of purchase requisitions after the requisition has been released. You define it in percentage by field Value Change (Figure 10). For example, if the requisition dollar value is $10,000, the value change is defined as 20% (i.e., if the value of the requisition is changed to over 20%, which is over $12,000). In my example, I have selected 4. After a release, if the user changes the requisition value to $11,000, it is below the specified limit of 20%, so the system doesn't trigger another release by the approver. On the other hand, if it exceeds the limit, the approver has to reapprove it.

Step 8. Trigger the workflow. BUS2015 Business Object triggers the workflow for the overall purchase requisition release. This has to be activated by using transaction SWE2. You can create and activate a custom workflow template from the Standard WS20000077 (Figure 11). A custom workflow is required for some of the functionalities, such as substitute approvers and multiple departments approving the requisitions.

Figure 11

Activation of a custom workflow template

Step 9. Build a custom workflow. To build a custom workflow, use the Workflow Builder, which you can access in transaction PFTC. Various methods perform the operations on the business object. For example, getting the approvers and sending an email are both methods. The method contains the coding to perform the operation.

The method identifies the set of activities that the system needs to perform. Figure 12 indicates that the first step of the method is to get the Release Codes and thereby obtain the approvers. You can maintain the approvers as a mini-HR or as a z- table. The system automatically checks table T16FW for the role resolution. When you use 1, the release code refers to table T16FW for role resolution. On the other hand, if you use 9, the system automatically checks the user exit, and the custom coding in the user exit dictates the role resolution. Neither of these are requirements, so you can use whichever you choose. You apply the user exit when the role resolution requirements cannot be fulfilled using table T16FW.

Figure 12

A custom workflow

If you have set the workflow indicator, the workflow activates for each release code. In the workflow, the method determines what needs to happen (i.e., find approver, send an email, or reject a requisition). Sent mail to first approver and First Approver represent the methods for the BUS2015 object (Figure 12). In this case, it can send mail or reject it.

In the method, you can achieve several workflow variations by coding. If an approver is on vacation, the workflow can automatically notify substitute approvers using either the z-table or mini-HR chart. This functionality needs to be coded in the workflow. You must also maintain the table defined earlier for substitute approvers. The workflow coding ensures that when the main approver is on vacation, the workflow reads the substitute approver table and sends the requisition to the substitute approver, as in Table 4.

If z-tables are used when workflow is triggered, the method Get Approver obtains the approvers from the z-tables. First, it must find a match between the release code on the requisition and Table 5. The method should also search Table 4 to see if there are any substitute approvers.

If you find a match and the date of the requisition falls between start and end dates, the substitute approver can be found from the vacation table and override Table 4.

If you have implemented a mini-HR chart, the workflow method can search this chart by using the release code and the department (Cost Center) and identify the appropriate approving manager. If the approving manager is on vacation, you can indicate it on the personnel record of the identified approving manager. You can use a simple custom table modeled on that of a previous solution to find an alternative approver.

For example, select the Position (Organizational Unit P) from the HRP1001 table. This infotype contains the entries for the organizational chart. Then select the user ID of the person from Personnel table PA0105 matching the position. Check for non-availability from Infotype Absences and if there is a match, check the z-table for a substitute approver.

• You can also send reminders to approvers if they have not approved the requisition after a specified time period. You can set this functionality up in workflow in the Latest End tab of the method (Figure 13). In this case, when the approver has not approved the requisition in 24 minutes, the system sends a reminder.

Figure 13

Deadline monitoring

• When a position is vacant, you can trigger workflow to read the position in the z-table or the mini-HR chart, thereby sending an email to a higher approving authority. This again can be coded in the method. The position can be maintained as vacant or by another entry, such as 9999.

• You can also code the method to control sending emails instead of using the office inbox

Step 10. Set up compliance and security. Proper segregation of duties needs to exist in the system to ensure Sarbanes-Oxley compliance. For example, the requestor creates and the approving manager authorizes the requisitions. A combination of release groups and release codes for transaction ME54N controls this process. Each approver is associated with a release code, thereby providing authorization to release the purchase requisitions. The approver alone has authorization for his release code.

The system automatically performs an authority check on object M_BANF_FRG for transaction ME54N. With authorization object M_EINK_FRG, you can determine which purchasing documents the user can release via the release group FRGGR, and which release codes (such as FRGCO) he can use when releasing the purchasing documents.

Authorization object M_BANF_FRG enables you to restrict the release of purchase requisitions via release code FRGCD. Each role has a combination of release group and release code, which is assigned to each approving manager. The security team assigns values using transaction PFCG (role maintenance) and then assigns them to users using transaction SU01 (Figure 14).

Figure 14

Authorization object

Suresh Veeraraghavan

Suresh Veeraraghavan is a senior manager with Capgemini, a leading management and IT consulting firm. He works in the technology service group. He has 14 years of experience delivering SAP implementations in various capacities. Prior to joining Capgemini, he worked with Hewlett-Packard as a supply chain architect, managing and implementing SAP supply chain projects on a $26 billion platform. His expertise is in implementing best practices in supply chain management, specifically procure-to-pay and order-to-cash. He is a certified project management professional (PMP) and CPIM certified.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.