SAP’s ABAP Objects, fully introduced with R/3 Release 4.6C, promise faster development times and reduced maintenance costs, yet they have failed to catch on for custom HR software development. For various reasons, HR support teams are depriving their companies of the full potential of their SAP HR implementations — a potential the companies have paid for but are not using. It’s hard to say why HR support groups may shy away from using ABAP object technology. Excuses heard recently on projects I’ve been on are, “No one has asked for it yet,” “Too many existing programs to support, and if it ain’t broke, don’t fix it,” “We’re just upgrading the SAP release, not our programs,” or, “No one here knows how to use that stuff.”

Using the ABAP Objects enhanced programming technology, you can upgrade custom programs developed in an R/3 3.x environment or implement new ones to:

• Consolidate business application procedures into reusable objects
• Enable standardized data structures and calculation processes
• Increase reliability and consistency while reducing size and complexity
• Store all required infotype data or payroll results in a single internal table
• Realize the substantial cost savings of single-point code development, maintenance, and enhancement

I’ll explain the practical use of three 4.6C technologies that do just that. I’ll also demonstrate how these technologies provide new report and analysis capabilities that will benefit both you and your company’s HR professionals. The vehicle for this demonstration is an on-screen employee payroll program that allows you to display and analyze multiple payroll results. Along the way, I’ll show how ABAP object technology provides HR analysts with expanded report flexibility and data analysis options, and gives technical support personnel reusable program components that are simple, consistent, and easy to maintain.

As my example, I’ll create a payroll cluster comparative viewer (PCCV) that is based on custom HR data objects. The PCCV enables you to compare different payroll cluster tables simultaneously on the same screen. These cluster tables can be from the same or different employees.

The programming of the PCCV brings together these three 4.6C SAP software enhancements:

Deep structures — Table types and row types are ABAP Data Dictionary tools that enable creation of complex or deep data types such as a table of tables. When used within programs, these so-called deep structures greatly simplify reporting data management by providing the means to group many program data elements into a single data object.

ABAP Objects — The ABAP programming language enhancement that provides for the “encapsulation” of program code and data resulting in significant standardization of programming techniques and simplified program maintenance.

ALV grids — The ABAP List Viewer (ALV) is part of the SAPGUI Controls Technologies that present report data on the workstation and provide users with greatly expanded data analysis and manipulation tools.

The Payroll Deep Structure

To create a PCCV, you first need a program structure to hold data. SAP delivers a deep structure called PAYUS_RESULTS that’s perfect for the job. Also provided are two function modules — CU_READ_RGDIR and PYXX_READ_PAYROLL_RESULT — that return the payroll directory and pay results from the payroll clusters and deliver them in the ready-to-use PAYUS_ RESULTS deep structure package.

The two function modules and the deep structure together virtually eliminate the need for payroll IMPORT macros, extensive data declarations, buffer management, cluster keys, and complex ABAP programming.

Function module PYXX_READ_ PAYROLL_RESULT uses different data packages depending on the country in which the payroll was created. The U.S. data package is described by the ABAP Data Dictionary structure PAYUS_RESULT.

PAYUS_RESULT has three components that are built up using the basic payroll cluster structures from the ABAP Data Dictionary. The first component is EVP, which has the same PC261 layout as the payroll directory, RGDIR. Notice the structure icons shown as the data types (Dtyp) in Figure 1.

The next component is INTER. INTER itself is a deep structure, PAY99_ INTERNATIONAL. Its building blocks are all the internationally used SAP payroll cluster structures, namely RT (results table), CRT (cumulative results table), WPBP (work area basic pay table), and so on, that are now the row types of the HRPAY99 series of table types. Notice in Figure 2 the data type icons that denote these table types and structures.

The third and final component of PAYUS_RESULT is NAT (Figure 3). NAT is mapped to a country-specific deep structure that contains those tables unique to a particular country. In the U.S., this structure is PAYUS_NATIONAL, which contains all of the U.S.-specific payroll cluster tables and structures such as TAX (table of tax authorities), and TCRTA and TCRTB, which combine into TCRT (tax cumulative results table), etc.

Figure 1

ABAP Data Dictionary screen for PAYUS_RESULT

Figure 2

Internationally used SAP payroll cluster tables

Figure 3

U.S.-specific payroll cluster tables and structures

The Infotype Deep Structure

You also need a container for any HR master data that you want to show on the screen of your PCCV. For that, you again use SAP-delivered structures and table types. SAP constructs the infotype deep structure in a particularly interesting way using nested table types.

Figure 4 is a composite of ABAP Data Dictionary screens showing the components of the infotype deep structure.

Figure 4

ABAP Data Dictionary components of the infotype deep structure

I’ll start from the bottom of Figure 4 and work my way up. First, Table Type HRIFT_TT_DATA is based upon the generic infotype structure PRELP. Delivered by SAP, PRELP is a simple structure comprised of standard infotype key and header structures plus a 1,428-byte generic character type data area. HRIFT_TT_DATA is just a flexible container that can contain data rows from any infotype database table.

Next, table type HRIFT_TT_DATA is used as a component of Structure HRIFT_TS_CONT. This structure also contains a component named INFTY based on structure RSITYPELST, which is a structure that contains fields to identify an infotype such as infotype number.

Finally, at the top, is table type HRIFT_TT_CONT where Structure HRIFT_TS_CONT is used as the row type.

HRIFT_TT_CONT is a table of infotype tables. In other words, when you declare a variable based on HRIFT_TT_CONT, you get an internal table where each row contains fields that identify an infotype plus another field that represents a table containing rows of that infotype. In this manner, a table consisting of rows from an HR infotype becomes an element of a row of a table consisting of data tables from many different infotypes. Making a structure the row type of a table type and then making that table type a component of the row type of still another table type creates a single data object that can hold all your infotype data (Figure 5).

Figure 5

Single data object holding all your infotype data

The bottom line of all these row type and table type technicalities is that by using this structure a program can store all needed infotype data for an employee in a single internal table. The result greatly simplifies and standardizes HR data management and paves the way for the creation of HR Objects.

Creating the Employee Object

Now that you have data structures to hold both an employee’s master data and payroll results data, you are ready to create the HR Objects. First, you determine the attributes for the employee object. You want it to hold a variably specified amount of HR master data from the PAxxxx infotype database tables. This is where the HR master data deep structure comes in.

You are going to create a custom data structure, ZHR_EE_DATA, to be used within the employee object. The first field is the personnel number (PERNR) field. The second component of the structure is the table of infotype tables, the HR master data deep structure HRIFT_TT_CONT. Notice in Figure 6 that the second component of the structure has the icon that represents a table type.

Use the new, 4.6 ABAP Workbench development tool CLASS BUILDER (transaction SE24) to add structure ZHR_EE_DATA as an attribute of your new employee object class, ZCL_HR_EMPLOYEE1. Basically, the EE_DATA attribute is just a PERNR number with a pointer to a table of infotype data tables. The other attribute, RINFO, is a list of the requested infotypes. (See Figure 7.)

When the create object command is issued for the employee object, the constructor method is automatically called by the system. Constructors are a special type of object method that, if implemented, always run automatically when the object is created. The programming logic within this method reads the INFOTYPES: data declaration statement within the calling program to determine which infotypes are needed. It then populates the deep structure with the selected HR PA master data. (See the Download Section at the bottom of the article for the coding of the method.)

Once the object is created, the data or attributes within the employee object can be manipulated by the object’s methods. They are also directly available to a program by using any of several easy programming techniques. Some obvious methods might be GET_NAME, GET_BASIC_PAY, GET_AGE, GET_BENEFIT_AGE, and GET_DATES. The values returned from these methods can be used in logical expressions or assigned to program variables. Some statements can be much simpler than a function module call.

For example:

name = my_ee_obj->get_name( ).

The point is that any program can create an employee object and then call its methods. All data collection and manipulation can be done internally within the object. The program is left with only the tasks of creating the object using the correct parameters and assigning values returned from its methods to program variables. HR report programs can be greatly simplified and made to return consistent results if they all use the same data manipulation routines via the object’s methods.

See Figure 8 for example methods for an employee object.

Figure 6

The 4.6B custom version of HRIFT_TT_CONT

Figure 7

Attributes of new employee object class ZCL_HR_EMPLOYEE1

Figure 8

Example of employee object methods

Creating the Employee Payroll Object

Now you determine the attributes for the payroll object. You want it to hold a variably specified amount of payroll results from the payroll cluster tables. You use the pay results deep structure and a custom table type for this purpose.

Use the ABAP Data Dictionary to create table type ZHR_USPAY_RESULTS. Its row type should be the SAP payroll deep structure PAYUS_RESULTS. Remember that PAYUS_RESULTS is the same structure used by the SAP function module PYXX_READ_ PAYROLL_RESULT described above.

Next, create a custom data structure, ZHR_EE_PAY_RESULTS, to be used within the payroll object. The first field is the personnel number (PERNR) field. The second component of the structure is your new table type, ZHR_USPAY_ RESULTS. Figure 9 is a composite of ABAP Data Dictionary screens showing the creation of ZHR_USPAY_ RESULTS and ZHR_EE_PAY_ RESULTS.

Use transaction SE24 again to add an attribute named EE_PAY_RESULTS to your employee payroll object class ZCL_HR_EMP_PAY1. Its data type is your custom structure, ZHR_EE_ PAY_RESULTS (Figure 10).

The employee payroll object can simultaneously hold as many individual payroll results as needed within a single internal table. This single table for all cluster data from multiple payrolls makes managing payroll cluster data much easier than in any release prior to 4.6C. Simple looping program structures can replace the multiple IMPORT macro statements that were needed previously.

The CONSTRUCTOR method for the employee payroll object requires a number of parameters to define which payroll results are wanted (Figure 11). The method’s first step determines which payroll cluster records are needed by analyzing the RGDIR and creates a list of payroll directory sequence numbers. In the second step, the method uses function module PYXX_READ_ PAYROLL_RESULT within a loop of the sequence number list to retrieve and store payroll results data from the data clusters.

Once created, data tables within the employee payroll object can be directly accessed by commands within the program or manipulated by custom methods based on an organization’s business requirements. These methods can include standardized calculation of year-to-date values, current period wage type amounts, retrocalculation amounts, and other calculation procedures, depending on the organization’s reporting needs.

For example, you could use the following ABAP statement to retrieve the year-to-date total for wage type /101:

ytd_101 = ee_pay->get_ytd_lgart( ‘/101’ ).

Figure 12 shows example methods for an employee payroll object.

The employee payroll object now represents a central repository of approved calculations and algorithms (methods) for payroll data and payroll interfaces. These methods can be made available to all programs requiring these types of calculations simply by using the DATA: statement to declare a variable based on the employee payroll object, i.e.:

DATA: my_pay_data type ref to zcl_hr_emp_pay1.

Payroll data retrieval and calculation processing no longer need to be embedded in individual programs or include files but instead can be incorporated into the employee payroll object for all programmers to use. Centralizing payroll data retrieval and processing procedures goes a long way toward ensuring reliable and consistent payroll reports.

Figure 9

ABAP Data Dictionary screen composite for ZHR_USPAY_RESULTS and ZHR_EE_PAY_RESULTS

Figure 10

Attributes of employee payroll object class ZCL_HR_EMP_PAY1

Figure 11

Parameters for the employee payroll object class ZCL_HR_EMP_PAY1 CONSTRUCTOR method

Figure 12

Example employee payroll object methods

Creating the ALV Grid Display

Now that the data retrieval techniques and data containers are encapsulated within the employee and employee payroll objects, you need a way to display this information on the screen. The PCCV requires four separate and independent screen windows. For this purpose, use an SAP controls technology object — the ALV grid.

My example PCCV has buttons representing the RT, CRT, TAX, and TCRT, etc., payroll cluster tables. Of the four ALV grids, two on the left show the payroll directories for either one or two individual employees. Two grids on the right dynamically display payroll cluster tables selected by the user from the pushbuttons on the screen. (See Figure 13 for the screen layout.) The ALV grids on the right side of the screen display different pay cluster tables depending on the buttons pushed by the user. As the user presses different buttons, the grids on the right dynamically switch from one pay cluster table layout to another. New ALV grids need to be created each time a button is pressed.

Figure 13

Screen layout for the PCCV

The layout for the PCCV program’s single screen is simple. It has four container objects to hold the ALV grids, the cluster table pushbuttons, and two PERNR data entry fields. The PCCV is a module pool program type that is started via a custom transaction, ZPAYVIEW, so only one screen is required.

The dynamic creation of ALV grids is facilitated by another set of custom ABAP Objects. CONSTRUCTOR methods of the ZCL_ALV_FIELDCAT_ MANAGER (ALV Grid Catalog Manager) and the ZCL_ALV_SORT_ MANAGER (ALV Grid Sort Manager) objects use SAP function modules to automatically read table structures in the calling program to help create new ALV grids on the fly. For any of the different payroll cluster tables, depending on the user’s selection, the previous grid is destroyed and a new one, based on a different table, is created in its place within the same area on the screen. (For full documentation, go to the Download Section at the bottom of the article.)

These ALV Grid Manager objects (see composite Figure 14) also provide additional methods to override the settings generated by the CONSTRUCTOR methods for column headings, field display lengths, subtotal, and sorting options of the grid as needed.

Figure 14

ALV Grid Manager object methods

Each of the four ALV grids on the PCCV screen has its own set of ALV Grid Manager objects. This ability to create multiple, completely independent sets of processing entities using the same ABAP program code demonstrates a very real advantage of ABAP Object technology over the classic, pre-4.6 function module technology. The multiple sets of ALV Grid Manager objects are declared using the DATA: statement, i.e.:

DATA:
alv_cat1 type ref to zcl_alv_fieldcat_manager,
alv_sort1 type ref to zcl_alv_sort_manager,
alv_cat1sub type ref to zcl_alv_fieldcat_manager,
alv_sort1sub type ref to zcl_alv_sort_manager,
alv_cat2 type ref to zcl_alv_fieldcat_manager,
alv_sort2 type ref to zcl_alv_sort_manager,
alv_cat2sub type ref to zcl_alv_fieldcat_manager,
alv_sort2sub type ref to zcl_alv_sort_manager.

Additionally, since you are using your new HR objects, the PCCV can simultaneously display cluster tables from two different employees without much programming complexity. In fact, the PCCV needs fewer than 400 lines of program code. ABAP object technology can really provide a boost to your programming productivity.

It’s simple to create the two independent sets of employee and employee payroll objects in your program. Use the following DATA: declaration:

DATA:
ee_dat1 type ref to zcl_hr_employee1,
ee_dat2 type ref to zcl_hr_employee1,
ee_pay1 type ref to zcl_hr_emp_pay1,
ee_pay2 type ref to zcl_hr_emp_pay1.

Figure 15 shows a composite sequence of PCCV screens.

Figure 15

PCCV screen sequence

The first screen (top left) is presented on startup. The second screen (top right) is displayed after entering a personnel number (PERNR) in the top data entry field. Two payroll directory listings are displayed.

The third screen (bottom left) displays an RT on the top and a CRT on the bottom for the same selected payroll period. The fourth screen (bottom right) shows CRTs for two different payroll periods. Payroll periods are selected by highlighting a row in an ALV grid on the left. Screen pushbuttons select the cluster tables to be shown in the ALV grids on the right. ABAP object technology enables the PCCV to use the bottom grid pair to display data for an employee different from the employee shown in the top grids.

DATA: plan_cost type ben_eecost. LOOP AT pa0001. CASE pa0001-persk. WHEN ‘R’. CREATE OBJECT my_employee TYPE zcl_hr_retiree1 EXPORTING pernr = pernr. WHEN ‘T’. CREATE OBJECT my_employee TYPE zcl_hr_trainee1 EXPORTING pernr = pernr. WHEN OTHERS. CREATE OBJECT my_employee TYPE zcl_hr_employee1 EXPORTING pernr = pernr. ENDCASE. CALL METHOD my_employee->get_plan_cost EXPORTING heathplan = ‘0001’ IMPORTING plan_cost = plan_cost. CLEAR my_employee. ENDLOOP.

Consolidation in Two Steps

It’s clear that ABAP Objects for HR make sense from a technical point of view. But do they make sense from a practical or cost point of view? In my experience, you can estimate that the development time per method will average four to eight hours, much less if similar subroutines have already been developed in-house. Generally, method development for the employee object requires less time than methods for the employee payroll object. (Example method implementations are provided in the Download Section at the bottom of the article.)

If you are implementing SAP HR for the first time, ABAP Objects for HR can ensure standardized custom development and consistent data analysis results. If your company is upgrading to an SAP release that supports ABAP Objects, upgrading your current custom HR programs as well could make financial sense. Since all HR existing custom programs will be required to pass through quality assurance testing during the system upgrade process, you have an opportunity to consolidate data processing routines into ABAP Object methods.

This work can proceed in two simultaneous tasks. The first task is to create the objects, determine their methods, and develop or copy existing coding for method implementation. The second task is to review existing custom programs to identify areas where object method calls can replace or simplify complex coding blocks. In other words, don’t discard the existing custom programs, just replace coding that has been replicated in multiple programs with object method calls and preserve the specialized processing. Screen output or list processing can remain the same or be simplified and enhanced with conversion to ABAP List Viewer technology.