Using features is one way to incorporate your company’s unique business rules into the R/3 system. A feature is a logical construct used to assign a value to one field by examining the values of other fields. When business rules change, you may need to update your features.

Unfortunately, “effective date” is not one of the fields available for making decisions in most features. I’m going to explain some of the problems that can arise with features when business rules change. Then I’ll cover a quick and easy way to retain a feature’s current settings in a user exit while configuring its new settings in the decision tree.

Example: A Change in Eligibility Rules

Company X has both full-time and part-time employees. Currently, each group of employees is offered a unique set of benefits. However, the company has recently evaluated its benefits plans and determined that offering the same plans to all employees will result in significant savings. The change in company policy takes effect on 1/1/2004.

Benefits plan eligibility is controlled by the fields “benefit grouping 1” and “benefit grouping 2,” as saved on infotype 0171. The value of benefit grouping 2 is assigned by feature BSTAT. Figure 1 shows the current configuration of the BSTAT feature. Employee groups 1 and 2 represent the full-time employees, who are assigned the benefit grouping STD. The STD benefit grouping contains the benefit plans offered to full-time employees. Employee group 5 represents the part-time employees, who are assigned the benefit grouping PART. All employees should be offered the STD group of benefits starting on 1/1/2004.

Figure 1

Decision tree for feature BSTAT

The solution to this problem appears simple — just change the feature to assign the benefits grouping STD for part-time employees. However, the situation becomes more complicated when you consider the timing of this change. The policy takes effect on 1/1/2004, so you might consider moving this change into production late on 12/31/2003. Then you realize that open enrollment for 1/1/2004 takes place in October 2003. You’ll need to move the change into production before open enrollment starts. But what about part-time employees hired after open enrollment? They should be offered the old plans until 12/31/2003. No matter when you move the change to production, the feature cannot satisfy the different business rules simultaneously.

Fortunately, most of the features used in the benefits module have user exits available. For the remainder of this article, I’ll show you an easy way to copy the existing feature logic into the user exit and make it date-driven. Many features in HR do not have user exits defined, but it is still possible to replace the decision tree with a custom program. The sidebar, “Calling a Form Routine from a Feature,” explains the process.

Locating the User Exit for a Feature

The first thing you’ll need to know is the name of the customer enhancement for the feature’s user exit. Use transaction SMOD to locate enhancements. Since you don’t know the name of the enhancement, click on the help drop-down list. The initial list of user exits might be quite long. One trick for narrowing the list is to click on the New selection button at the bottom. Since you are looking for an HR enhancement related to features, enter P* in the Exit name field and *feat* in the Short text field. I know from experience that all HR-related enhancements start with the letter P. The regular expression “*feat*” matches any description containing the string “feat” surrounded by other letters. Figure 2 shows the resulting list. I selected enhancement PBEN0003 for the user exit of feature BSTAT.

On the SMOD screen (Figure 3), choose Components and click on Display. The list of components for enhancement PBEN0003 contains function module EXIT_SAPLHRBEN00FEATURE_003. Double-click on the name of the function module to display the source code. Then double-click on the name of include ZXPBEU03. You are prompted to create the object. Click on Yes and accept the default attributes. Now you are ready to program the current business rules, but you don’t need to start from scratch. The following section explains how you can copy the logic from the current feature into the user exit.

Figure 2

User exits available for features

Figure 3

Transaction SMOD

Copying Code from the Compiled Version of a Feature

At first glance, features appear to be simply configuration because they are maintained and transported in the same manner as other table entries. Closer examination reveals that R/3 translates the decision tree of each feature into a program. The activated version of a feature is actually a client-independent repository object. The naming convention for these programs ensures that each client has its own version to preserve the client-dependent status of the feature. Table T549D is used by R/3 to connect the features to their programs.

The name of the program created from the decision tree can be displayed in transaction PE03. Enter the name of the feature, select the Attributes radio button, and click on Display. Figure 4 shows that in client 300 the feature BSTAT is generated as program /1PAPA/ FEAT300BSTAT. Use transaction SE38 to display the source of that program, as shown in Figure 5. You can see that the decision tree of the feature has been converted into a group of nested case statements.

Figure 4

Attributes of feature BSTAT

Figure 5

Source of /1PAPA/FEAT300BSTAT

Select the code from the first CASE statement down to the last ENDCASE statement and copy it to the user exit. A few changes are required to complete the user exit. The variable names need to be changed. In this example, STRUC-BAREA can be changed to _BAREA because an import parameter exists for the benefit area. The field BACK must be changed to the export parameter _BSTAT, and the field STRUC-PERSG must be read from infotype 0001 using function HR_READ_INFOTYPE. Finally, an “if” statement is added to cause the standard feature to be performed if the effective date falls on or after the conversion date. The completed program is shown in Figure 6.

*      
*   INCLUDE ZXPBEU03 - Feature BSTAT   
*      
*  Author:  Clay Molinari
*  Date:    10/20/2003
*  Purpose: This user exit overrides the standard BSTAT feature for 
*           dates before 1/1/04. The new business rules are in the 
*           standard feature.
*********************************************************************
data: i0001 type table of p0001 with header line.
data: l_subrc   like sy-subrc.
if _BEGDA ge ‘20040101’.
  raise evaluate_feature.
else.
  clear: i0001.
  refresh: i0001.
** read IT0001 for employee group
  call function ‘HR_READ_INFOTYPE’
       exporting
*         TCLAS           = ‘A’
            pernr           = _pernr
            infty           = ‘0001’
            begda           = _begda
            endda           = _begda
*         BYPASS_BUFFER   = ‘ ‘
       importing
            subrc           = l_subrc
       tables
            infty_tab       = i0001
       exceptions
            infty_not_found = 1
            others          = 2.
  if sy-subrc ne 0 or l_subrc ne 0.
    raise customer_error.
  endif.
  read table i0001 index 1.
  if sy-subrc ne 0.
    raise customer_error.
  endif.
** the following copied from 
** /1PAPA/FEAT300BSTAT
  CASE _BAREA .
  WHEN ‘US’ .
    CASE i0001-persg.
    WHEN ‘1’ .
      _BSTAT = ‘STD’ .
    WHEN ‘2’ .
      _BSTAT = ‘STD’ .
    WHEN ‘4’ .
      _BSTAT = ‘RETI’ .
    WHEN ‘5’ .
      _BSTAT = ‘PART’ .
    WHEN OTHERS .
      _BSTAT = ‘NON’ .
    ENDCASE.
  WHEN OTHERS .
    _BSTAT = ‘NON’ .
  ENDCASE.
endif.

In this example, I used a feature with a fairly simple decision tree. The copy-and-paste trick saves even more time on more complex features. After the code of the existing feature has been copied, you can use transaction PE03 to update the feature to contain the new business rules. Transport the new feature and the user exit together.

Sidebar: Calling a Form Routine from a Feature

The process described in this article requires a user exit and has the advantage of allowing the current business rules to be configured in the feature’s decision tree. This makes the standard logic more visible and restricts the exception processing to the old rules only.

Even features that do not have a user exit defined can be configured to call a custom program from their decision tree. You should consider two things when you use this approach. First, the program must assign all possible values for the feature, because it cannot return control to the decision tree. Second, the called program will have access only to the fields of the feature’s structure. In most cases, the effective date will not be available, making it impossible to code date-driven logic or to read other master data. Despite these limitations, you may find it handy to add complicated logic to a feature by calling a custom program.

Calling a Custom Program from the BSTAT Feature
This brief example illustrates the steps required to build and call a custom program for the BSTAT feature. Start by using transaction SE38 to create the custom program. I entered the name ZHR_FEAT_BSTAT and clicked on Create. Figure 1 shows the program attributes.

Figure 1

Program attributes for ZHR_FEAT_BSTAT

Next, I used the process described in the article to copy and paste the existing feature logic into the program. In this case, you copy all of the code from the FORM statement to the ENDFORM statement. Then, add a PROGRAM statement at the top and change the name of the form from CALL_549B to EXT_CALL_F. Next, add a new parameter called FEAT just after the USING statement. Then modify the decision logic as needed to support your business rules. Figure 2 shows a skeleton of the code.

*———————————————————————————————————* *   REPORT ZHR_FEAT_BSTAT - Feature BSTAT                    * *———————————————————————————————————* *  Author:  Clay Molinari *  Date:    10/20/2003 *  Purpose: This process overrides the standard BSTAT feature. *************************************************************** PROGRAM ZHR_FEAT_BSTAT. FORM EXT_CALL_F USING FEAT BACK STATUS STRUC STRUCTURE PME30. SET EXTENDED CHECK OFF.   CASE STRUC-BAREA .   WHEN ‘US’ .     CASE struc-persg.     WHEN ‘1’.       BACK = ‘STD’. * remainder of new logic   ENDCASE. SET EXTENDED CHECK ON. ENDFORM.

Figure 2

Source of ZHR_FEAT_BSTAT

Now use the change button in transaction PE03 to update the decision tree of the BSTAT feature. Select the first node, BSTAT, and click on the blank page icon to create a subordinate node. Next, choose the Program radio button and enter the name of your custom program, as shown in Figure 3. Delete any other nodes that may have been in the feature, and activate the feature. The feature will now be evaluated using the logic of your custom program in place of the decision tree.

Figure 3

Adding a node to feature BSTAT

How the Old and New Rules Are Supported Simultaneously

The feature BSTAT is called upon to assign the value for benefit grouping 2 whenever infotype 0171 is created. Enhancement PBEN0003 is performed in place of the feature. When the begin date of the IT0171 record falls on or after the conversion date, the user exit defers to the standard feature, which contains the new business rules. For earlier dates, the user exit assigns the feature value using logic copied directly from the old feature. Activating this enhancement enables IT0171 to always obtain the correct value for BSTAT, even when creating records before or after the conversion.

This same technique can be used on any of the features for which a user exit has been defined. The cost group feature is an especially strong candidate for this approach, because cost is always driven by effective date. If you enhance the cost group feature this way, you won’t need to worry about incorrect costs being calculated in retroactive pay periods. The ultimate advantage of this method is that it frees the system support team from the catch-22 of trying to schedule the introduction of new business rules into production.

Clay Molinari

Clay Molinari has 20 years of experience in the IT industry and has been working as an SAP HR consultant since 1997. He is currently president of C&C Savant, Inc., an SAP consulting firm that specializes in combining standard SAP configuration and custom ABAP programming to help its clients solve unique or complicated requirements.

You may contact the author at claymolinari@comcast.ne.

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