Eliminating Duplicate-Line Reporting in the HCM Module
| Upon execution of virtually any report in SAP, an end user sees a selection screen that provides the opportunity to further clarify selections. (See Chapter 5, "Basics of Using Reporting Selection Screens," and Chapter 6, "Using Reporting Selection Screens: Advanced Skills," for more information on selection screens.) The most common date parameter for reporting in the SAP HCM module on the selection screen is the date selection period Today. Selecting Today ensures that the data you have retrieved from the database is valid as of today. One thing to note here is that if you have any future-dated records (for example, for increases or organizational changes), they will not be included in your report output because technically they do not exist yet. Many users wonder why they sometimes retrieve multiple (or duplicate) line items when selecting Today for an HCM report. This happens only with certain infotypes that have multiple values in a single or table-based storage space. This might sound pretty technical, but basically it means that the database pulls all the records that meet the specified criteria. Most users complain of duplicate record results when selecting the Other or Person Selection Period date parameters because multiple records may exist for that employee during the date range specified. An example of an infotype that does not produce multiple lines in an SAP Query is Infotype 0002: Personal Data. This is because Infotype 0002 stores each piece of information in a single identifiable field; for example, it stores an associate's first name in the field labeled First Name onscreen. Behind the scenes, the data entered in this field is stored in the SAP database in the P002-VORNA structure, where P002 identifies the infotype number (in this case Infotype 2). P002-VORNA is referred to as the field's technical details. To view a field's technical details, you need to place your cursor in a field (for example, the Birth Date field on Infotype 0002) and then press F1. The Performance Assistant dialog box appears (see Figure 17.1), providing a definition of the specified field. The Performance Assistant dialog box provides a Technical Information button that you can click to view the field's technical details (see Figure 17.1). Figure 17.2 shows the Technical Information dialog box that appears. Figure 17.1. The Performance Assistant dialog box provides a definition of the selected field and, in some cases, examples of its usage. Figure 17.2. The Technical Information dialog box displays the behind-the-scenes database information about the selected field. The associate's date of birth is the only information that should be stored in the designated Birth Date (P0002-GBDAT) field, because the Birth Date field on Infotype 0002 is designed exclusively for that purpose. In comparison, Figure 17.3 shows Infotype 0041: Date Specifications, which is often known to produce duplicate records when its fields are included in an HCM report. Figure 17.3. Infotype 0041: Date Specifications allows an organization to save multiple date types for an associate in a single place. For Infotype 0041, there is not a single field identified for only a single piece of data; rather, the data that can be stored in each field is variable. Infotype 0041 is designed to permit storage of customer-specific dates. During configuration, you determine the date types that you want to use for your organization. For example, in Figure 17.3, the fictional associate has four different date types, stored as Date Types 30, 36, 66, and 80, listed in numeric order. Unlike with Infotype 0002, with Infotype 0041, the fields on this screen can store variable data. If you were to look at the technical details of the Date Type 30 date field (for example, the first date field listed, labeled Benefit Override Dte), you would see the value P0041 - DAT01. If you were to look at the details of the next date field immediately to its right (for example, the field labeled Date of Hire), you would see the value P0041 - DAT02. In the first example, the value DAT01 is assigned because that date is stored in the first position on that screen. Similarly, in the second example, the value DAT02 is assigned because that date is stored in the second position on that screen. If you added a new date type for the associate (for example, Date Type 23), that would then become assigned to the technical field P0041 - DAT01 because it would then be in the first numeric position (because 23 is numerically before 30). If you created a query-based report, run as of today, to include the First Name and Last Name fields from Infotype 0002, the report output would appear in a single line across the page for each associate. However, if you ran a report and listed the Date Type and Date for Date Type fields in the output, you would display multiple lines in the report for each associate for each date stored on their Infotype 41, which includes the technical fields P0041 - DAT01 through P0041 - DAT12. Using the sample shown in Figure 17.3, you would display four line items for the associate, one for each date type. There are two possible solutions for single-line reporting based on infotypes, including Infotype 41: a basic solution and an advanced solution. The Quick-and-Dirty Solution for Single-Line Reporting Based on InfotypesWith the quick-and-dirty, limited solution for single-line reporting based on infotypes, if you wanted to create a basic list query report that would include an associate's hire date (for example, Date Type 36), you would simply need to include the Date Type field on your report's selection screen. Using that method, you could, upon report execution, specify that you want only that one date type in the report output, thus ensuring that you get only a single line of data per associate in your report output. This same method works on Infotype 0006: Addresses, where multiple subtypes of addresses are available. This is a limited workaround because of the way a selection screen works. It includes in your report only data that meets the criteria entered on the selection screen. So, for example, if you were to produce a report of everyone and their hire date on a single line, as just mentioned, the single-line report output would include only those associates who have the specified date type. If some folks were missing it, for example, they would be excluded from the report output. This quick-and-dirty workaround is helpful when you are sure all associates meet the criteria entered on the selection screen (so you get complete output) or when you want your report output to include only those associates. A downside of this method is that you are limited to reporting based on only one item in a single report. So, for example, if you wanted to include hire date (Date Type 30) and service award date (Date Type 66) from the preceding example, you would still get two lines for each associate. The same would be true if you were to run a list of employee addresses from Infotype 0006: Addresses. You would only have the option to specify a particular subtype of address (01 - Mailing, 02 Permanent Residence, and so on), as specified in the Address Subtype field on the report's selection screen, or you would display both and have multiple lines per associate. The Advanced Solution for Single-Line Reporting Based on InfotypesThe second and more technical solution for single-line reporting based on infotypes is designed for ABAP programmers. The premise is that you can insert into the InfoSet (your report's data source) code that evaluates each of the fields for you and creates fields in the InfoSet that store each specific field. Using the Infotype 41 example, you could add code to your InfoSet that evaluates each of the date types specific to your company's configuration (for example, Date Types 30, 36, 66, and 80) and creates fields in the InfoSet for each specific date type, allowing you to simply select which dates you want to include in your report output (regardless of the number you want to include), and all will appear on one line. This advanced solution enables you to simply select which fields you want to include in your report output. Adding code to an InfoSet is a subject geared toward trained ABAP programmers and is beyond the scope of this book. However, because this is one of the most popular challenges for HCM reporting, this section includes some quick notes on it. Listing 17.1 shows an example of ABAP program code developed by a trained HR ABAP programmer that you can include in a SAP Query tool InfoSet to assist with the challenge of reporting based on an infotype that stores variable data. For example, you can add this code to the InfoSet, to create new fields in your InfoSet that store each Date field from Infotype 0041 in a single designated field. That way, you can include any or all dates in a report from your Infotype 0041 (regardless of whether the associate has values for the date types), all on a single line in the SAP Query tool. Listing 17.1. Sample Code to Add to InfoSet for Infotype 41 Reporting
The data types referenced in this code are specific to the way a sample organization has them configured, so you need to substitute for them the names and numbers that you use at your organization. The code reads through all the different table values and assigns each date to a specific field for use in reporting. You can use this code as a helpful reference to set up your own custom fields for reporting on things like date types and wage types. |
