Many R/3 users need to store data that does not appear on a standard infotype. Using methods provided by SAP, a functional team member can create user-specific infotypes or extend existing ones to meet their needs. We’ll discuss some considerations in making the decision about which option to use, and give you time-saving hints from our personal experience. First, though, we’ll explain what happens behind the scenes by giving you an overview of the building blocks involved in creating a Personnel Administration (PA) infotype. You can create a simple infotype without any ABAP coding. For the PA submodule, which includes employee-, time-, and applicant-related infotypes, use transaction code PM01 - Enhance Infotypes. It guides you through the steps and takes you to the transactions used to create a new infotype or enhance an infotype by adding new fields. There are six tabs on transaction PM01’s screen. (See the sidebar, “The Six Functions Provided by PM01,” below.) An infotype is a grouping of related information that is typically presented to the user on a single screen. In addition to the interface screen, an infotype has a program with logic to process the screen, and a table, or tables, on the database to store the data. Customizing tables control the processing of the infotype. An infotype is identified by its number and name, such as “Infotype 0006 - Addresses.” The number ranges for infotypes are defined by SAP (Table 1).

Infotype Number Range	Corresponds to
0000-0999	General personnel administration
1000-1999	Organizational Management and Personnel Development
2000-2999	Time-related
4000-4999	Applicant administration
9000-9999	Customer defined — can be a PA/OM/PD, time, or applicant infotype

Table 1

Ranges for infotype numbers

The foundation of the infotype is its definition in the ABAP dictionary, SAP’s data dictionary. The definition consists of nested structures that describe the infotype’s components. The key fields, which make a record unique, and the header fields are the same on all PA infotypes. (OM and PD have different standard portions than PA infotypes.) Because they are used so often, both groupings are made into structures that are included in the definition of each infotype. The fields specific to the infotype are also grouped into a structure, which is called the PSnnnn structure. The “nnnn” stands for the infotype number. The pieces are put together in the Pnnnn structure, which is the HR Master Record layout for the infotype. Figure 1 (below) depicts the nesting of the structures used to define a PA infotype. The PSnnnn structure is also used to define the column layout for the database table PAnnnn. Most of the Pnnnn structures delivered by SAP incorporate a customer include called CI_Pnnnn. An include is a subcomponent of a structure. The customer include is delivered empty, so that you can use it to add fields to an infotype. The program that processes the infotype is called a “module pool.” It contains both the screens and the logic used to create, list, change, display, delimit, and delete the infotype. It is important to understand the basic flow of processing to know what user-specific enhancements you are able to make. First, infotype data is retrieved from the database if it already exists. Then, any formatting of the data or defaulting of screen values occurs. Next, the screen is presented to the user and the user enters the input. Finally, the input is validated and either the screen is presented back to the user or the appropriate change is made to the database. User-specific processing can be added both before the screen is displayed (process before output - PBO) and after the user interacts with the screen (process after input - PAI). SAP-created user exits allow the ABAP developer to alter some of the module pool standard processes. For example, in the PAI user exit, the developer could make a field entry required based on data input into another field. As of Release 4.6C, SAP provides Business Add-ins (BAdIs) as an alternative to user exits. The BAdI HRPAD00INFTY (update infotype maintenance), for example, allows a developer to process information pertaining to an infotype later in the module pool program than the PAI customer enhancement allows. A user exit in the module pool is different than using a customer include to enhance an infotype. A customer include in an infotype structure adds fields to the infotype. However, a user exit in the module pool only allows additional processing of data.

Creating an Infotype

When you create a new PA infotype, transaction PM01 serves as a one-stop interface workbench. It allows you to create the data dictionary entries, create the screen, generate the program, and maintain the customizing entries on the infotype attributes table. PS structure: You can use the PM01 transaction instead of going directly to the data dictionary to create the PSnnnn structure. You need to indicate the data elements that will be stored in the PSnnnn structure. The PSnnnn structure is comprised of the fields that make the infotype unique. An example of this is an infotype that stores information pertaining to a person’s address. The PSnnnn data elements would be street, city, state, zip code, etc. The system builds the top-level structure Pnnnn, including both PSHDR (which contains PSKEY and PSHD1) and PSnnnn. The database table PAnnnn is automatically built using the definition of PSnnnn, header fields, and key fields. Module pool: PM01 uses Pnnnn to automatically generate MPnnnn00, the module pool program for the infotype. You may need to change the module pool program to add edits or special processing such as changing screen attributes dynamically (fields display or input allowed) or validating user input. You may need to involve a member of your ABAP team. Screen Painter: PM01 builds a screen based on the fields in the infotype. You can refine the screen manually by selecting the screen radio button on PM01, which branches you to transaction code SE53 - Screen Painter. A graphical layout editor for Screen Painter makes adjusting the screen layout easy. Navigating and working with Screen Painter can drastically differ depending on the SAP GUI release and whether or not the graphical layout editor is enabled. (To install the graphical editor interface for Release 4.6, you need the SAP GUI for Windows installation CD. When you get to the SAP Installation Options screen, select Development Tools.) Customizing entries: PM01 also allows you to maintain the customizing entries on T582A Infotype Attributes (Figure 2). These attributes tell the system how to process the infotype, including whether the infotype has subtypes, how many infotype records can be valid at a time (see, “Time Constraints,” below), if the record is relevant to retroactive payroll processing, and what dates to default to when the infotype record is created.

Extend or Create?

So, how do you decide whether to extend an existing infotype or to create a new one? Either option allows you to store data within the R/3 system. You have to judge if the new data is similar enough to data on an existing infotype for it to make sense from a user’s perspective to include it there. If an infotype has similar data, it may be appropriate to extend it using a customer include. If not, a totally new infotype may be the best approach. For example, say that a company has a new dress code policy, and it needs to ensure that everyone has read the new guidelines. Printing the new policy and mailing it out to employees in order to receive a signed signature back is far too costly and cumbersome. The company would like to use an infotype that employees could update, indicating they have read and agreed to the dress code policy that has been posted on an internal Web site. However, because there is no infotype related to dress code information, the company would probably want to create its own. An example of when it’s appropriate to enhance an infotype is with the addition of a Relationship to employee field to infotype 0006 – Addresses, subtype 4 – Emergency contact. The standard infotype does not indicate what the relationship of the emergency contact is to the employee (Figure 3.) It makes sense to add this information to the existing infotype, as it is associated with the information already being collected about the emergency contact. You would not want the user to have to go to an additional screen to enter the relationship to the employee.   Another consideration is your authorization strategy. If different users will access the new fields, creating a new infotype may be better than controlling access with field-level authorizations. Also, consider if there is an Easy Web Transaction (EWT) for the infotype, as customer include fields are not automatically included in an EWT. The screen used to maintain an infotype through an EWT is in the EWT function group and is not the same screen as in the module pool program. PM01 makes changes only to the module pool program. You may have to make a repair or write your own EWT. Another factor is whether existing reports are able to access the custom data. For the most part, extending an existing infotype allows you to continue to use existing standard SAP reports. However, your new fields may not appear on those reports. Also, check that any InfoSets you use in Ad Hoc query have the new fields. Depending on how the InfoSet was defined, the new fields may be automatically included for an infotype enhancement. If a new infotype is created, you may need to modify SAP reports, InfoSets, or customer queries.