Developing an Infotype in Personnel Administration

8/9/2019 Developing an Infotype in Personnel Administration

1/75


2/75

Table of content1 Developing an Infotype in Personnel Administration

1.1 Infotype Concept

1.1.1 Decoupling Infotypes

1.1.2 Definition of an Infotype within the ABAP Dictionary

1.1.2.1 Structure and Task of Data Field Structure PSnnnn

1.1.2.2 Structure and Task of Tables PAnnnn and PBnnnn

1.1.2.3 Structure and Task of Structure Pnnnn

1.1.2.4 Structure and Task of the Screen Structure

1.1.3 Conversion Class

1.1.4 Infotype Module Pool

1.1.5 Infotype Screens

1.1.5.1 Initial Screen

1.1.5.2 Single Screen

1.1.5.2.1 Flow Logic of Single Screen

1.1.5.3 List Screen

1.1.5.3.1 Flow Logic of List Screen

1.1.5.4 Infotype Screen Control

1.1.5.4.1 Screen Control Based on Function to be Performed

1.1.5.4.2 Screen Control Based on Control Data

1.1.5.5 Infotype Interface Status

1.1.6 Infotype Dialog Module

1.1.7 Infotype Characteristics

1.1.8 Infotype Text Modules

1.1.8.1 Single Screen Set-Up for Displaying and Maintaining Text Modules

1.2 Developing an Infotype

1.2.1 Creating an Infotype

1.2.1.1 Defining Infotype Characteristics

1.2.1.2 Editing Subobjects of an Infotype

1.2.1.2.1 Editing the Check Class

1.2.2 Migrating an Infotype

1.2.3 Creating an Infotype Version

1.2.3.1 Editing of Subobjects of an Infotype Version1.2.4 Enhancing the Screen Structure

1.2.5 Enhancing an Infotype Included in the SAP Standard System

1.2.5.1 Enhancing the Single Screen

1.2.5.2 Enhancing the List Screen

1.2.6 Deleting an Infotype

1.3 Modifying an Infotype Included in the SAP Standard System

1.4 Business Logic Guidelines for Creating and Migrating Infotypes

1.4.1 Preliminary Analysis

1.4.1.1 Identifying Implicit Value Restrictions

1.4.1.2 Performing Infotype Screen Control

1.4.2 Check Classes

1.4.2.1 Creating Single Check Classes

1.4.2.2 Creating Country-Specific Check Classes

1.4.3 Implementing Checks

1.4.3.1 Redefining Check Methods

1.4.3.1.1 Inserting New Check Methods

1.4.3.1.2 Removing Existing Check Methods

1.4.3.1.3 Extending Existing Check Methods

1.4.3.2 Using Generic Interfaces

1.4.3.3 Processing Methods: The Standard Sequence

1.4.3.4 Performing Message Handling

1.4.3.4.1 Avoiding Pitfalls in Message Handling

1.4.3.4.2 Streamlining Message and Exception Handling

1.4.3.4.3 Remapping Generic Messages

1.4.3.5 Processing Required Fields, Read-Only Fields and Unused Fields1.4.3.6 Inheritance Mechanism for Infotype and Related Fields

1.4.3.7 Programming Your Infotype to Perform Implicit Checks

1.4.3.7.1 Performing Foreign Key Checks

PUBLIC 2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 2 of 75


3/75


4/75


5/75


6/75

Use

The fields are required when the infotypes data structures and database tables are defined. The data fields are grouped together in structure PSnnnn to keep the

definition as free of redundancy as possible. Structure PSnnnn can then be used as a substructure when other structures and tables are defined in the ABAP

Dictionary.

Do not use integer data types (INT1, INT2, INT4) or floating point number data types (FLTP) for the fields of the data field structure PSnnnn.

Otherwise the infotype cannot be used. Instead, use the data types NUMC and DEC.

Structure

Customer include

The Personnel Administration and Recruitment infotypes contain a customer include CI_Pnnnn in the data field structure PSnnnn. You can include your

customer fields in this include. This is then an enhancement of a standard SAP infotype.

Duplicate fields for subtypes

If you want to divide an infotype into subtypes, you must assign structure PSnnnn a duplicate of key field Pnnnn-SUBTY in which the subtype is then

stored. This field requires its own name and data element.

You must include the duplicate subtype field in the appropriate infotype screens. The user can then make entries in this field.

You must also specify the name of the duplicate subtype field in the Subtype Field field when you maintain the infotype characteristics in the Infotypes :

Dialog/Database Assignment table (T777D). Central infotype modules automatically write data to key field Pnnnn-SUBTY from the entries in this field. Key

field Pnnnn-SUBTY does not appear on infotype screens.

A duplicate subtype field has the following advantages:

Special check tables are used for the infotype subtype

Field-specific documentation can be created for the subtype and then displayed using the field help.

Field PS0006-ANSSA for the address type (check table Infotype Subtype Characteristics (T591A))

Field PS0014-LGART for the wage type (check table Permitted Wage Types (T512Z))

1.1.2.2 Structure and Task of Tables PAnnnn and PBnnnn

Definition

Transparent database tablesthat store the data records for the infotype nnnn .

Use

Which of the tables you require depends on which area you want to use the infotype in:

If you want to use your infotype in Personnel Administration , create table PAnnnn .

If you want to use your infotype in Recruitment , create table PBnnnn .

If you want to use your infotype in Personnel Administration and Recruitment , create both tables PAnnnn and PBnnnn .

You must also specify which of the database tables you want to use in the Infotypes: Dialog/Database Assignment table (T777D).

For more information, see Infotype Characteristics.

Structure

Table PAnnnn

Field Name Key Data Element Type Length Check Table Short Text

MANDT X MANDT CLNT 3 T000 Client

.INCLUDE X PAKEY

.INCLUDE PSHD1

.INCLUDE PSnnnn

Table PBnnnn

Field Name Key Data Element Type Length Check Table Short Text

MANDT X MANDT CLNT 3 T000 Client

.INCLUDE X PBKEY

.INCLUDE PSHD1

.INCLUDE PSnnnn


Page 6 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d52649575e11d189270000e8322f96/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/35/28eb01e8a0556fe10000009b38f983/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/35/26b261afab52b9e10000009b38f974/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d526be575e11d189270000e8322f96/content.htm


7/75


8/75

The naming convention for screen structures of standard infotypes is as follows:

The naming convention for screen structures of customer infotypes is as follows:

Structure

For detailed information about the structure and task of screen structures, see:

Screen Structures

Infotype Screen Structures (Type MAIN)

Repeat Field Screen Structures (Type LINE)

1.1.3 Conversion Class

Definition

Class that converts screen structures to structures that can be interpreted by the business logic

(processing logic).

Use

Screen s tructures contain all interface-relevant fields of an infotype that can be disp layed or edited on the user interface. Therefore, the fields of an infotype

structure must be converted to a relevant format. This function is taken on by the conversion class (see example).

Conversion classes serve two purposes:

Input and output conversion

The conversion classes contain infotype-specific implementations for converting input and output values or filling input helps.

Screen control functions such as determining the field attributes of screen fields.

The convers ion class for an infotype is called at runtime by the various app lications such as the XSS adapter for the self-service scenarios or the adapter for HR

Administrative Services . Each infotype uses at least one conversion class. Different country vers ions use different conversion classes.

There are two types of conversion class that have interfaces with different conversion method parameters:

Standard conversion classes that use the interface IF_HRPA_ UI_CONVERT_STANDARDThis interface contains standard conversion methods that transfer the individual infotype structures Pnnnn (primary infotype), Pnnnn2 (secondary infotype),

and PREF (cost center assignment).

Enhanced conversion classes that use the interface IF_HRPA_UI_CONVERT_ADVANCED

This interface contains enhanced conversion methods that transfer the entire infotype container. These methods also have the same function as the standard


Page 8 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/43/304b0c29990b19e10000000a1553f6/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/3207d8d5b90d24e10000000a1553f7/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/304ad229990b19e10000000a1553f6/content.htm


9/75

conversion methods.

For detailed information about using conversion classes, see the sections on Conversion Classes.

You must specify which conversion class should be used for each screen structure.

You make the assignment in view V_T588UICONVCLAS (Assignment of Screen Structure to Conversion Class). For more information, see Assigning Conversion

Classes to Screen Structures.

Naming Convention

The general naming convention for conversion classes is as follows:

Standard conversion class

Customer-specific conversion class

Example

Conversion of the date for output on forms, for example, in three separate fields:

Current Date

Name of month

Year


Page 9 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/43/304cf629990b19e10000000a1553f6/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/304c3329990b19e10000000a1553f6/content.htm


10/75

1.1.4 Infotype Module Pool

Definition

Framework program for the user interface of an infotype. The name of the program is MPnnnn00 . P stands for Human Resources (personnel), and nnnn is the

four-digit infotype number.

There is a module pool for each infotype.

Structure

Infotype-specific includes

The main program only contains INCLUDE statements. If you create the main program using transaction Create Infotype (PM01), the system also creates the

following four includes:

Includes and their contents

Name of include Content

MPnnnn10 PROGRAM statement

Declaration of common data objects

MPnnnn20 PBO modules for the screens

MPnnnn30 PAI modules for the screens

MPnnnn40 Subroutines

All of the changes you make to module pool MPnnnn00 or the includes listed here for an infotype within the standard system constitute

modifications.

General includes

The system also inserts INCLUDE statements in the main program for the following includes:

Includes and their contents

Name of include Use

FP50PPSB Declaration of common data objects

This data area is used as a buffer for im ported infotype records and main tenance

information. The variables specified in this area are used as export or import parameters

when the infotype dialog module is accessed.

MPPDAT00 Declaration of common data objects

MPPERS00 Standard infotype modules

MPPIRC00 Definition of infotype return codes

MPPREF00 Definition of two data objects that contain the number of reference personnel numbers in

structure P0031 or P0121

These includes contain standard functionality that must be offered by each infotype.

Do notchange these includes. They are used by the module pools for all infotypes.

Includes for infotypes with country-specific features

Many infotypes require modules that apply to just one country.

You must store these modules separately in their own includes for the data definition, PBO and PAI modules, and subroutines. You then enter the

HR country indicator , which is assigned in table T500L Country Grouping for HR Management to the appropriate country grouping , at the end

of the name of the corresponding include.

1.1.5 Infotype ScreensEach infotype has at least three screens:

An initial screen

A single screen


Page 10 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/35/28eb01e8a0556fe10000009b38f983/content.htm


11/75

A list screen

It is possible to modify the screen control to replace the single or list screen with alternative screens. This enables you to use different single or list screens for an

infotype. Additional single screens or list screens are used in Personnel Administration to adapt an infotype screen to the requirements of a particular country, for

example.

Screen control

Screen control provides options for modifying the interface. For more information, see Infotype Screen Control.

1.1.5.1 Initial Screen

Definition

Interface between the Human Resources transactions and the infotypefrom a technical perspective. It is accessed using the dialog module for the relevant

infotype.

Use

Screen 1000 is used as the initial screen for all infotypes. Screen 1000 of module pool MPMMMM00 is used as a template.

The initial screen is processed in the background, that is, the screen is not displayed while the flow control is executed.The tasks of the initial screen are as follows:

It performs general initialization procedures required by all infotypes

It calls the single screen

It performs general processing steps once the single screen has been processed.

You must always create the initial screen using the Create Infotype transaction (PM01) . The system then creates an initial screen with all of the

functions required. Do not change the initial screen.

1.1.5.2 Single Screen

Definition

The actual interface between the infotypeand the user.

This screen provides the user with the following functions:

Create Data Records

Disp lay Data Records

Edit data records

Use

Screen 2000 is usually used for the single screen. However, you can choose to use a different screen as a single sc reen. Screen 2000 of module pool

MPMMMM00 is used as a model for the single screen.

You can create your own single screens for infotypes included in the standard system. Customer-specific single screens are assigned to the name range 2900to

2999.

Entry checks

The values of the Organizational Ass ignment infotype (000 1) that are valid at the beginning of the records val idity period, as well as the entries in the tables

listed below that are valid in structure PSYST, enable you to carry out infotype-spec ific entry checks.

Personnel area / subarea (T001P)

Currency of the public sector (T500C)

Personnel area (T500P)

Employee Group/Subgroup(T503)

This means that the system does not need to read the tables cited above. It is sufficient to include the tables in the TABLES statement.

Do not use the values in structures P0001 or P0002 . These structures are used internally and are not always initialized.

Possible entries for screen fields

The system displays possible entries for all of the fields whose entry is c hecked against a table.

If you ass ign a check table that can be checked automatically to a field within the ABAP Dictionary, the system disp lays possible entries automatically.


Page 11 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/35/28eb01e8a0556fe10000009b38f983/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/35/28eb01e8a0556fe10000009b38f983/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d52608575e11d189270000e8322f96/content.htm


12/75

Structure

Screen setup

The first six lines of the initial screen are the same for all infotypes:

Lines of Initial Screen and their Use

Line number Use

1 to 3 Include screen for header lines with data such as the personnel number

4 Empty line

5 FROM date, TO date, lock field, text field, the last person to make a change, and the date

on which the last change was made

6 Empty line

Infotype-sp ecific fields are included in lines 7 to 21.

The infotypes in the standard system then contain an include screen for customer enhancements.

All of the screen fields must be included in one frame. The screen field that contains the subtype assigned to the infotype, however, may appear above the first

frame.

Tab Strips on the Single Screen

You can include a tabstrip controlon the single screen.Note the following dependencies:

You must include three modules in the flow logic of the tab strip control subscreen.The modules are in the include MPPERS00.

The modify_subscreen module must be included as the first module of the PBO.

The hidden_data_subscreen module must be the last module included in the PBO.

The input_status_subscreen must be included as the first module of the PAI. The module is called up in the same way as the input_status module on the

single screen: all fields that may be maintained must be included in a CHAIN statement.

process before output.

MODULE modify_subscreen.

* ... Subscreen specific PBO Module ...

MODULE hidden_data_subscreen.

process after input.

chain.

field: ... all maintainable fields ... module input_status_subscr een on chain-request.

endchain.

* ... Subscr een specific PAI Module ...

The function codes for the buttons on the tabstrip control must be the same type as the function codes of a P button (local GUI function, function code is processed

directly from GUI). That way a PAI is not triggered when scrolling. If this is not possible because validations are to take place when scrolling between the different

screens, a new PBO must be triggered on the single screen before the last module, post_input_checks is executed.

Otherwise the fcode function code field is deleted in the post_input_checks module.

1.1.5.2.1 Flow Logic of Single Screen

If you create the single screen for the infotype us ing the Create Infotype transaction (PM01), the system prepares the flow logic.

The flow logic of infotypes in the SAP standard system usually follows this pattern:

Action PBO

PROCESS BEFORE OUTPUT.

MODULE BEFORE_OUTPUT.

MODULE get_header_subscreen.

CALL SUBSCREEN subscreen_header INCLUDING header_prog header_dynnr.

MODULE Pnnnn.

MODULE get_t582c_subscreen.

CALL SUBSCREEN subscreen_t582c INCLUDING subscr_prog subscr_dynnr.

MODULE HIDDEN_DATA.

You can carry out infotype-spec ific initialization procedures within PBO module Pnnnn . They enable you, for examp le, to fill the screen fields stored in structures

Qnnnn and Znnnn .

If wage types are valuated indirectly, the amount field Q0014-BETRG in the process logic of the Recurring Payments and Deductions infotype


Page 12 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/35/26b26cafab52b9e10000009b38f974/content.htm


13/75

(0014) must be filled since the amount is not stored on the database.

You must not change PBO modules BEFORE_OUTPUT and HIDDEN_DATA.

Action PAI

PROCESS AFTER INPUT.

MODULE EXIT AT EXIT-COMMAND.

CHAIN.

FIELD Pnnnn-feld1,...

MODULE INPUT_STATUS ON CHAIN-REQUEST.

ENDCHAIN.

PAI module INPUT_STATUS must be performed if the user makes an entry in a screen field. For this reason, all of the entry fields in the following chain must be

counted. PAI module INPUT_STATUS sets internal system statuses. For example, if a value has been changed, the infotype data record is to be saved later.

MODULE PRE_INPUT_CHECKS.

PAI module PRE_INPUT_CHECKS is used to process the function code before the entry check. If you choose the Exit function, for examp le, the system stops

processing the current single screen.

Once module PRE_INPUT_CHECKS has been processed, you can carry out your own entry checks or call up your own PAI modules.

You want an entry for the field Pnnnn-feld1 to be validated against table Tnnn:

FIELD Pnnnn-feld1

SELECT * FROM TABLE Tnnn WHERE feld1 = Pnnnn-feld1

ON INPUT.

You want to perform module Modul_feld2 if the user makes an entry in field Pnnnn-feld2 :

FIELD Pnnnn-feld2 ON INPUT MODULE Modul_feld2.

At this point, the entry checks must be complete up to PAI module POST_INPUT_CHECKS . Once the following process has been carried out, it is no longer

possible to change field contents.

PAI module POST_INPUT_CHECKS processes the function code after the entry checks . It also carries out general entry checks. The system checks, for

example, whether the start date of the infotype record is before the end date of the record.

You must list all the fields that appear on the single screen in the following chain. You must also list fields that are only displayed, such as long texts.

CALL SUBSCREEN subscreen_t582c. CHAIN.

FIELD Pnnnn-feld1,RP50M-SPRPS,Tnnn-felda,... .

MODULE POST_INPUT_CHECKS.

ENDCHAIN.

You must not change PAI modules EXIT , INPUT_STATUS , PRE_INPUT_CHECKS, and POST_INPUT_CHECKS .

1.1.5.3 List Screen

Definition

Infotype screen that displays all data records for a personnel number in a list.

Use

Screen 3000 is usually used for the list screen. You can, however, choose to use a different screen as the list screen. Screen 300 0 of module pool

MPMMMM00 is used as a template.

You can create your own list sc reens for infotypes included in the SAP s tandard sys tem. Customer-specific list sc reens are assigned to the namespace 3900to

3999.

Structure

The list screen is divided into three areas:

Lines 1 to 3 disp lay the header lines in an include screen.

Lines 5 to 19 contain the list with the infotype data records.

Fields ass igned to structure Pnnnn are usually displayed here. If you want to display further information, such as long texts, in the list screen, you can add

other fields for this purpose.


Page 13 of 75


14/75

Infotype data records are displayed in one line in the list screen.

Line 20 contains the Selection fields ( RP50M-BEGDA , RP50M-ENDDA , RP50M-SUBTY , RP50M-ABGRD, and RP50M-PAGEA ).

These fields allow the user to select infotype records in the list by validity period, subtype, delimitation date, or item in the list.

With the exception of the Delimitation Date field ( RP50M-ABGRD ), these fields should always be ready for input. The delimitation date in field RP50M-

ABGRD should only be displayed on the list screen if the current function really is Delimit .

If you create the list screen using the Create Infotype transaction (PM01), the system sets up the list screen automatically. Fields ass igned to structure Pnnnn

are also included in the list sc reen.

If you do not use sub types in the infotype, delete field RP50M-SUBTY.

1.1.5.3.1 Flow Logic of List Screen

If you create the single screen for the infotype us ing transaction Create Infotype (PM01), the system prepares the flow logic.

The flow logic of infotypes within the standard system usually follows this pattern:

Action PBO

PROCESS BEFORE OUTPUT.

MODULE BEFORE_OUTPUT.

MODULE ASSIGN_TC3000.

MODULE VARIATION_TC.

LOOP. MODULE PSLIST.

MODULE Pnnnn.

ENDLOOP.

MODULE GET_HEADER_SUBSCREEN.

...CALL SUBSCREEN SUBSCREEN_HEADER INCLUDING HEADER_PROG HEADER_DYNNR.

You can carry out infotype-specific initialization procedures within PBO module Pnnnn . This is the same module that is used for the single screen. If you require

different infotype-specific initialization procedures for the list screen, you can determine that a different PBO module is accessed. This module must be called

PnnnnL.

You must not change PBO modules PSLIST_TC , BEFORE_OUTPUT , ASSIGN_TC3000 , VARIATION_TC , and

GET_HEADER_SUBSCREEN.

Action PAI

PROCESS AFTER INPUT.

MODULE EXIT AT EXIT-COMMAND.

LOOP.

FIELD RP50M-SELEC MODULE MARK ON REQUEST.

ENDLOOP.

CHAIN.

FIELD RP50M-BEGDA.

FIELD RP50M-ENDDA.

FIELD RP50M-SUBTY.

MODULE SELECT_FOR_LIST ON CHAIN-REQUEST.

ENDCHAIN. FIELD RP50M-PAGEA ON REQUEST MODULE TOP_OF_LIST.

MODULE ADJUST_LIST_TC.

MODULE POST_INPUT_CHECKS.

You must not change PAI modules EXIT , MARK , SELECT_FOR_LIST , and POST_INPUT_CHECKS.

1.1.5.4 Infotype Screen Control

When you create single sc reens and list screens us ing the Screen Painter , you determine the attributes of individual screens fields. However, the same screen

is always used for different functions such as creating, displaying, maintaining, and deleting infotype records. For this reason, you cannot specify whether a

screen field should be ready for input when you maintain the screen. It is also possible that particular screen fields must be hidden, depending on the employees

organizational data.

In other words, some attributes are not specified to be generally applicable; instead, they are specified during runtime. The appearance of the screens changes

depending on the function chosen by the user or the data being processed.


Page 14 of 75


15/75

The same single screens are used for the Disp lay HR Master Data and Maintain HR Master Data functions. The screen fields must only be

ready for input for the Maintain HR Master Data function. For this reason, you should determine the ready-for-input status of the screen fields

according to the function to be carried out.

The screens used to enter company car data in the Internal Control infotype (003 2) must be hidden for employees assigned to the employee

group for pensioners.

Screen control functions have already been implemented in the main infotype program. These functions read the values from the modification groups for individual

screen fields and set their attributes in accordance with the values. The meaning of the values for modification groups is determined in tables.

When you develop infotypes, you can effect screen control as follows:

You can determine whether entries can be made in fields, or you can choose to hide screen fields, dep ending on the function to be carried out.

The value in Modification group 1 controls whether the screen fields are ready for input. You can also hide individual screen fields.

The value for modification group 1 must be maintained for all input fields.

If the entry has not been made for a screen field, the field is not ready for input.

You can use alternative screens , determine whether entries can be made in fields, or hide screen fields us ing control data and the Infotype Screen Control

table (T588M).

Together with the Infotype Screen Control table (T588M), the value of Modification group 3 determines the activity and whether entries can be made in

fields.

If you use both of the above to effect screen control for a screen field, screen control using the Infotype Screen Control table (T588M) has higher priority.

Modification group 2 is used internally.

Modification group 4 is not used in the SAP standard system since it is reserved for customers. If you use this field, this counts as a modification of the SAP

standard system.

Screen Control Based on Function to be Performed

If screen control is effected depending on the function to be performed, you have the following options:

Control the ready for input status of individual screen fields

Hide individual screen fields

The Screen Painter enables you to maintain the value of Modification Group 1 for the relevant screen fields. The value of Modification Group 1 must be

maintained for all of the screen fields in which entries can be made.

The meaning of the values in Modification Group 1 is determined in table Status and Ready for Input Status in Screen Painter Screens (T589A). The following

constants are defined in the SAP standard system for determining the ready for input status of screen fields:

Constants for ready for input status of scr een fields

Screen field is ready for input

for the function

Hexadecimal constant for

modification group 1

Display 001

Change 002

Add and Copy 004

Delete 008

Lock/unlock 010

The following constants are defined in the standard system for hiding screen fields:

Constants for hiding scr een fields

Screen field is hidden

for the function

Hexadecimal constant for

modification group 1

Delimit in list screen 200

Display in list screen and

Change in list screen

400

Add and Copy 800

The value of Modification group 1 is interpreted on a bit-by-bit basis. Several constants can be combined. This is done by adding the values. Note that you must

maintain the value of Modification group 1 in hexadecimal form.

You want to be able to make entries in a screen field when the Add and Change functions are used. In this case, you must maintain value

006in Modification Group 1 .

You want to be ab le to make entries in a screen field for all functions. In this case, you must maintain value 01F in Modification Group 1 .

Default Settings

In the case of certain screen fields for single or list screens, the setting that determines whether entries can be made or not is pre-specified for all infotypes. If you

create the single or list screen using the Create Infotype transaction (PM01), the system enters the correct value in Modification Group 1 for these screen fields.

Entries can usually be made in the fields BEGDA and ENDDA for all actions, apart from display ing records. For this reason, the attribute Modification

Group 1 is assigned the value 00Efor these fields.


Page 15 of 75


16/75

Modification Group 1 has the value 800 for the fields AEDTM and UNAME . This ensures that these fields are hidden when a record is added.

The list screen should allow entries to be made in the fields RP50M-BEGDA , RP50M-ENDDA , RP50M-SUBTY and RP50M-PAGEA so that records

can be selected. These fields are assigned the value 00Fbecause it must be possible to make an entry for each operation.

The delimitation date in field RP50M-ABGRD should only be displayed on the list screen if the current function really is to delimit. For this reason,

Modification Group 1 is maintained using value 400 .

It is only possible to select multiple records on the list screen if the Disp lay and Delimit functions are used. Field RP50M-SELEC , which is contained in a

loop, is assigned the value 009for Modification Group 1 .

1.1.5.4.2 Screen Control Based on Control DataIf screen control is effected depending on control data, you have the following options:

Replace the standard screen with an alternative screen

You can control the ready for input status of individual screen fields.

You can hide individual screen fields.

There are different types of screen control:

General

Dependant on the employees organizational data

Dependant on the subtype for the infotype record.

For this, maintain the value of Modification group 3 for the screen fields in question in the Screen Painter.

In Modification group 3 , you assign a value between 001 and050 to each screen field. Use the same value for screen fields that are modified in the same way.

In the case of an input/output field, the same value is used as for the pertinent key word and a long text that may have been displayed. If screen fields cannot be

modified using table Infotype Screen Control (T588M), assign the value SPACEin Modification group 3 .

You then use table T588M to determine the following:

Whether and which alternative screens are used

How the individual screen fields are modified

For more information about screen control depending on control data, see the IMG documentation for Personnel Adminis tration Customizing User Interfaces

Change Screen Modifications .

1.1.5.5 Infotype Interface Status

The interface for single and list screens is standard for all infotypes. A specific interface status is used depending on the function to be carried out. It is also

possible for particular menu options or function keys defined in the interface status to be deactivated when certain functions are used.

The interface status is set in a PBO module included in the standard system. If you create your infotype using transaction Create Infotype (PM01), the PBO

module is accessed automatically by the flow logic of the infotype screens. For this reason, you do not need to program the interface status yourself.

The PBO module that sets the interface status can only function properly if the name and structure of the interface status to be used abide by SAP conventions.For this reason, you should also use transaction Create Infotype (PM01) to create the interface for your infotype.

List of req uired interface statuses

Screen Interface status Use of interface status for the function

Single screen DIS Display

MOD Change

DEL Delete

COP Copy

INS Insert

EDQ Lock

List screen

LIS0 List screen/display

LIS1 List screen/maintain

LSI9 List screen/delimit

The initial screen does not include an interface status.

1.1.6 Infotype Dialog Module

Each infotype requires a dialog module that represents the interface between the transactions used within Human Resource Management and the infotype itself.

The name of the dialog module must be RP_nnnn , where nnnn stands for the number of the infotype.

The dialog module is assigned to an infotype when the dialog module is maintained. You must specify the name of the module pool and the number of the initial

screen for the infotype.

The infotype is ass igned to the dialog module in the Infotypes Dialog/Database Assignment table (T777D).


Page 16 of 75


17/75

Infotype 0002 Personal Data uses module pool MP000200 and screen 1000 as its initial screen. Therefore, this infotype requires a dialog

module called RP_0002 which accesses screen 1000 for module pool MP000200 .

1.1.7 Infotype Characteristics

Infotype characteristics are determined by entries stored in various tables.

Tables that are maintained for all infotypes

Name of table Task

T582A Basic infotype characteristics

(single screen, list screen, time constraint, and so on)

T582S Infotype short texts

T777A Technical characteristics of Infotype (database table, dialog module, and so on)

T77ID Name of data field structure (PSnnnn)

You can maintain tables T582A and T582S in view V_T582A. Tables T777 D and T77 ID are maintained automatically when the Create Infotype transaction

(PM01) is used.

Additional tables that are maintained for some infotypes

Name of table Task

T591A Table T591A is used if the infotype is divided into subtypes. The subtype characteristics

are determined in this table.

You can use a different table instead of table T591A.

The table used to store the subtype characteristics must be specified in table T582A as

the subtype table.

T588G Table T588G controls field-specific retroactive accounting.

T588M Table T588M enables you to adapt infotype interfaces using screen control.

(You can specify an al ternative or subsequent screen; user-specific screen control is also

possible).

T588B Infotype menus

T588Z Dynamic actions

The entries stored in these tables must be maintained manually. You can use transaction PM01 Create Infotype to maintain basic infotype characteristics and

set up infotype menus.

1.1.8 Infotype Text Modules

You can create a text module when entering master data for individual infotype data records. These text modules are stored in file PCL1 under cluster ID TX .

To ensure that text modules can be created for an infotype, the Text allowed field (T582A-INFTX) must be flagged when the infotype characteristics are

maintained (table T582A).

When you display or maintain an infotype record, you can display or maintain the text for the record. You do this in the single screen for the infotype by choosing

Edit Display Text or Edit Maintain Text.

Displaying and maintaining text on the single screen

You can also display or maintain the first three lines of text on the infotype single screen.

If you want to use this functionality, simply adjust the single screen in question. You do not need to change the infotype structures or tables in the ABAP

Dictionary.

The first three lines of text on the single screen for infotype 0019 Monitoring of Dates are displayed or can be maintained.

Single Screen Set-Up for Displaying and Maintaining Text Modules

Procedure

If you want to display or be able to maintain the first three lines on the single screen of your infotype, proceed as follows:

1. Change the display of the infotype single screen in question.

Include the fields RP50M-TEXT1 , RP50M-TEXT2 , and RP50M-TEXT3 on the single screen.


Page 17 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d52622575e11d189270000e8322f96/content.htm


18/75

To ensure that entries can be made in these fields when the Add and Change functions are used, enter the value 006 in Modification Group 1 for all three

fields.

2. Enhance the flow logic for the action PROCESS BEFORE OUTPUT .

Insert the module GET_TEXT behind the module HIDDEN_D ATA . The module GET_TEXT is, therefore, accessed as the last module of this action.

3. Enhance the flow logic for the action PROCESS AFTER INPUT .

Insert the following lines after the module PRE_INPUT_CHECKS and before the infotype-sp ecific entry checks:

CHAIN.

FIELD: RP50M-TEXT1, RP50M-TEXT2, RP50M-TEXT3.

MODULE UPDATE_TEXT ON CHAIN-REQUEST.

ENDCHAIN.

You must also include the fields RP50M-TEXT1 , RP50M-TEXT2 , RP50M-TEXT3 in the chain for module POST_INPUT_CHECKS so that entries can

be made in these fields when the message W200 Please save your entry is disp layed.

4. Check that the Text allowed indicator has been set in table T582A.

If this indicator is not set, the fields RP50M-TEXT1 , RP50M-TEXT2 , and RP50M-TEXT3 are hidden.

Result

You can maintain texts for your infotype. The first three lines of text are displayed on the single screen or can be maintained.

1.2 Developing an Infotype

Use

The Create Infotype transaction (PM01) can b e used by customers and SAP to develop new infotypes.

Prerequisites

Before you begin implementing a new infotype, you should complete the modeling and design of the infotype.

You must use customer-specific development classes for all subobjec ts of your infotype. This ensures that your customer developments are not affected by a

release upgrade.

Note the naming convention. The number range 9000 to 9999 is reserved for customer infotypes . You must use this number range if you want your customer-

specific developments to be retained after a release upgrade.

FeaturesThe following steps are involved in creating an infotype:

Creating the data field structure in the ABAP Dictionary

Creating all other required Dic tionary objec ts, a supporting program containing the standard functionality for the infotype, the dialog module that calls the initial

screen of the infotype, the conversion class , and the check class.

Maintaining the characteristics of the infotype.

The system creates all subobjects that belong to an infotype in the system.

These subobjects must offer particular standard functionality and have a particular structure. The system creates the subobjects with the required functionality and

the correct structure. The transaction uses a copy template for this. The template consists of a module pool called MPMMMM00, which contains the various

includes, screens, and the GUI status.

Once you have finished creating your infotype, it is an integral part of the Personnel Administration and Recruitment transactions. Your infotypes are also

automatically included in the logical databases PNP and PNPCE.

Once you have created your infotype in the system, you can implement the infotype-spec ific functionality:

Set up individual single and list screens

Program your own initialization procedures for screen fields Program your own input checks

Activities

You choose a free infotype number for standard infotypes, a free number in the customer namespace for customer-specific infotypes , and the app lication for

which you want to use the infotype ( employee infotype or applicant infotype ).

You create the data field structure PSnnnn .

A new infotype is l imited to a maximum of 1000 positions. This restriction is due of the length of structure PRELP, which is used as a container

during infotype processing.

For more information about the structure and task of individual objects, see Definition of an Infotype in the ABAP Dictionary.

For information about the ABAP Dictionary, see the online documentation on the ABAP Dictionary.

The system creates structure Pnnnn and the database tables for your infotype.

If you have selected Employee Infotype , table PAnnnn is created. If you have selected App licant Infotype , table PBnnnn is created.

If you have selected Both , both tables are created.

The system also creates the screen structure HCMT_BSP_PA_yy_Rnnnn for a standard infotype, or ZHCMT_BSP_PA_yy_R9nnn for a customer-

specific infotype.


Page 18 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d5256c575e11d189270000e8322f96/content.htm


19/75

For more information, see Structure and Task of the Screen Structure.

The system also creates the following subobjec ts and table entries for an infotype nnnn :

Module pools

MPnnnn00

Module pool for infotype nnnn

MPnnnn10 , MPnnnn20 , MPnnnn30 and MPnnnn40

Includes for module pool MPnnnn00

For more information, see Infotype Module Pool.

Screens

MPnnnn00 1000 initial screen for infotype nnnn

MPnnnn00 2000 single screen for infotype nnnn

MPnnnn00 3000 lis t screen for infotype nnnn

For more information, see Infotype Screens.

Interface

The system creates an interface that contains all required interface statuses. For a list of interface statuses, see Interface Status for Infotypes.

Dialog module RP_nnnn

Technical characteristics

Entry for dialog control such as dialog structure, P structure, database table PAnnnn , module pool (T777D Infotypes: Dialog/Database Ass ignment )

Entry for the data field structure PSnnnn of the infotype (T777 ID Infotypes Supplements for T777D )

Check class

Table entry T582ITVCLAS

Conversion class

Table entry T588UICONVCLAS

1.2.1 Creating an Infotype

Use

You use this procedure if you want to create an international infotype. If you want to create a country-specific or industry-specific infotype, or an infotype for the

public sector of a country, choose Creating an Infotype Version.

Procedure

To create an infotype in the ABAP Dictionary, proceed as follows:

1. Choose Create Infotype (tab page).

2. Choose a free infotype number for standard infotypes , and a free number in the customer namespace for customer-specific infotypes.

Note the naming convention (customer namespace 9000to 9999).

3. Decide whether you want the infotype to be used in Personnel Administration ( employee infotype ), Recruitment ( applicant infotype ), or in both

components ( both ).

4. Choose Generate Objects.

You see the message Infotype PSnnnn does not exist . How do you want to continue?

5. Choose Create .

You branch to the ABAP dictionary structure maintenance.

6. Enter a short description for the infotype.

7. Enter the structure components (infotype fields).

There are two ways of doing this:

Manually:

a. Enter all required components for the infotype.

b. Enter the component type for each component. You can refer to an existing component type or create a new component type. Double-click on the field

and choose a component type from the dialog box. Choose Create .

Copy template:

You can also use the PS structure of an existing infotype if the infotype contains similar information (data components with a similar semantic meaning).

You create an infotype containing a telephone number for emergencies.

You do this by copying the Addresses infotype (000 6) and using the Telephone Number field as a copy template.

Proceed as follows:

a. Choose Edit Copy Field .

b. As the structure name, choose the PS structure that contains similar data components to the infotype you are creating.

c. In the Field Selection from Table PSnnnn dialog box, select the required components and choose Copy .

The components are written to the clipboard.

d. Choose Insert .

e. Save your entries.

8. Define the enhancement category :

To do this, choose Extras Enhancement Category, se lect the enhancement category and copy the entry.

You get the following message: Structure PSnnnn has been saved .

9. Check your structure.

10. Once you have checked it, save the structure.

11. Once the structure has been activated, go back.

The Create Objec t Directory Entry dialog box is opened.

12. Enter the objec t directory entry for the PS structure.

13. Enter the objec t directory entry for the screen structure:

HCMT_BSP_PA_yy_Rnnnn for a standard infotype, and ZHCMT_BSP_PA_ yy_R9nnn for a customer-specific infotype.


Page 19 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/43/903cefe2a225dee10000000a1553f7/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d5262f575e11d189270000e8322f96/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d525ba575e11d189270000e8322f96/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d525ad575e11d189270000e8322f96/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/e1/3e09429edcc417e10000000a155106/content.htm


20/75


21/75

2. Switch to change mode ( Display Change).

3. There are two ways to create an entry:

You can create an entirely new entry by choosing New entries .

You can copy an infotype entry with similar characteristics.

To do so, select the infotype whose charac teristics you want to copy, and choose Copy as

4. Make your entries in the required fields or check the entries you copied and make any necessary changes.

5. Save your entries.

ResultYou have defined the characteristics of infotype Pnnnn or P9nnn .

1.2.1.2 Editing Subobjects of an Infotype

Use

Once you have created an infotype, you can edit all subobjects of the infotype, that is, add or

change texts, add or change attributes, or check the structure.If required, you adjust the CUA interface for the new infotype (menu structure, menu entries, and so on). It is not usually necessary to edit the interfaces for

infotypes.

Above all, you must encode the check class CL_HRPA_INFOTYPE_nnnn or ZCL_HRPA-INFOTYPE_9nnn manually.

For more information, see Editing the Check Class.

You must also modify the infotype-specific parts of the generated module pool MPnnnn00 (create form routines for screen processing, for example).

You should not enhance the PS structure with additional fields in the customer include CI_Pnnnn as part of subobject editing, but as part of the

enhancement functionality for infotypes.

Editing the Check Class

Use

When you create a new infotype Pnnnn or P9nnnn, the system automatically generates the relevant check class for the infotype in the background. The check

class CL_HRPA_INFOTYPE_nnnn or ZCL_HRPA_INFOTYPE_9nnn contains five change-relevant methods. For information about whether the check

classes have to be edited for your infotypes, see the Business Logic G uidelines for Creating and Migrating Infotypes under

Creating Single Check Classes

Creating Country-Specific Check Classes

Prerequisites

You have created an infotype, and the relevant check class has been generated.

Activities

You enter the infotype and choose Check Class (BAdI) .

Use the Edit pushbutton to go to the Class Builder, where you can display and edit your check class.

1.2.2 Migrating an Infotype

Use

You can use this process to trigger an automatic migration of an infotype, which creates a decoupling of a similar scope to when a new infotype is created.

The infotype-sp ecific input and processing logic must be decoupled manually. They are decoupled in the same way as the infotype-sp ecific input

and processing logic of a customer infotype.

For more information, see Business Logic Guidelines for Creating and Migrating Infotypes.


Page 21 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/43/02311a08a26db7e10000000a422035/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/02338e08a26db7e10000000a422035/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/02334208a26db7e10000000a422035/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/903c69e2a225dee10000000a1553f7/content.htm


22/75


23/75


24/75

Editing the module pool

If you have created specific fields that require special processing in the PS structure, you must take this into account in the module pool in the output

modules, input modules, and in the form routines.

SAP recommends that you summarize this special processing in your own program includes in the module pool MP000600.

Note the naming convention. Customer includes should begin with Z.

Editing the screen

Create an infotype version-specific s ingle screen and lis t screen if required.

Choose a free screen number.

Do this by copying the single screen 2000 or list screen 3000 to your infotype version-specific screen, and make the relevant modifications in

the layout and flow logic.

The infotype version of the Addresses infotype (000 6) for the US contains a module called ZIP_CO DE_PBO_OUTPUT, which formats the ZIP

code display.

Editing the interface

If required, you modify the CUA interface for the infotype version (menu structure, menu entries, and so on). It is not usually necessary to edit the interfaces for

infotype versions.

Editing the check class (BAdI)

For information about encoding the check class, see Editing the Check Class.

1.2.4 Enhancing the Screen Structure

Use

If you have created an infotype or infotype version, the screen structure is initially identical to the P structure. You use this procedure to enhance the screen

sctructure.

For more information about the screen structure, see Structure and Task of the Screen Structure.

Procedure

1. Choose Enhance Screen Structure.

2. In the Infotype Number field, enter the four-digit number of the infotype you want to enhance.

When you enter the infotype number, remember to enter any leading zeros.

3. Enter an infotype version for infotypes with versions.


You see the message Structure HCMT_BSP_ PA_xx_Rnnnn (or ZHCMT_BSP_PA_yy_R9nnn) is being edited .

5. Modify the structure in line with the additional components in the customer include CI_Pnnnn.

6. Go back.

7 . Choose Conversion Class/BAdI Edit .

The editor for the conversion class BAdI appears, where you enter the code for the BAdI manually.

8. Choose Module Pool Edit, and enter the same code as in the BAdI .

9. Choose Screen Edit to modify the additional fields manually.

Result

The enhancement of your infotype is now decoupled.

Enhancing an Infotype Included in the SAP Standard System

Use

The enhancement concept for infotypes within Personnel Administration and Recruitment offers you the following functions:

You can perform additional customer validations.

You can include additional fields in an infotype.

The enhancement concept allows you to include additional fields in the data field structure Psnnn. You can then maintain these fields in the standard

single screens.

For more information, see Enhancing the Single Screen.

The enhancement concept also allows you to add fields to the standard list screens.

For more information, see Enhancing the List Screen.

If you add fields to an infotype, they are treated in the same way as SAP standard fields in reporting, when creating infotype logs, and within

dynamic actions.


Page 24 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d526d8575e11d189270000e8322f96/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d526cb575e11d189270000e8322f96/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/e1/3e09429edcc417e10000000a155106/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/903c69e2a225dee10000000a1553f7/content.htm


25/75

Constraints

The following infotypes are not included in the enhancement concept:

Actions (infotype 0000 )

Additional Actions (infotype 0302)

Time Management infotypes (2nnn)

Leave Entitlement (infotype 0005)

Maternity Protection/Parental Leave (infotype 0080)

Military Service (infotype 008 1)

Leave Entitlement Compensation (infotype 0083)

Time Quota Compensation (infotype 0416) App licant Actions (infotype 4000 )

The length of the data field structure PSnnnn together with the CI include must not exceed 1500 bytes.

If you include additional fields in the Organizational Ass ignment infotype (0001), you cannot use them as selection fields.

1.2.5.1 Enhancing the Single Screen

Procedure

1. Choose Enhance Single Screen.


You must enter leading zeros for the infotype number.

It is not possible to enhance the single screen for the Actions infotype (0000) or the Time Management infotypes, as well as some other

infotypes. For a list of these infotypes, see Enhancing an Infotype Included in the SAP Standard System.

3. In the Subobjects group box, select Customer Include.


You see the message CI_Pnnnn does not exist . How do you want to continue?

5. Choose Create .


6. Enter a short description for the structure CI_Pnnnn.

7. Enter an enhancement category. To do this, choose Extras Enhancement Category.

8. Define the customer-specific components (infotype fields).

9. Save and check the structure CI_Pnnnn .

10. Go back.

The initial screen of the transaction appears.

11. You must store the checks for the customer fields manually in the BAdI HRPAS00INFTYBL :

To enter the code for the BAdI, choose BAdI in Check Class Edit . 12. Choose Module Pool Edit, and enter the same code as in the BAdI .

13. You must edit the include screen manually.

Choose Include Screen Edit (default value 0200). On this screen, you can make the enhancement and carry out the relevant processing in the flow

logic of the include screen.

Result

You have added fields to the standard single screen for an infotype nnnn. You can edit the additional fields using the infotype maintenance tools.

Migrating the single screen

To decouple non-decoupled enhancements from standard infotypes, you must migrate them.

You do this once you have enhanced the single screen of a standard infotype by choosing Single Screen Migrate Enhancement in the Enhance SingleScreen screen of the Create Infotype transaction (PM01) .

The screen structure include CI_XX_Rnnnn is c reated as a copy of include CI_Pnnnn , and the fields of the existing customer include are copied to the screen

structure include.

If you want to add fields that are not in the customer include, you must do so manually. To do this, choose Enhance Screen Structure.

It is not necessary to modify the conversion class or the entry in table T588UICONVCLAS . Instead, the HRPAD00 INFTYUI BAdI must be imp lemented.

The checks for the customer fields are stored in the HRPAD00INFTYUI BAdI.

Deleting the additional fields

You can delete the fields that have been added to the standard single screen.

You do this on the Enhance Single Screen screen of the Create Infotype transaction (PM01) by choosing Single Screen Delete Enhancement.

This deletes the customer include.


Page 25 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d526be575e11d189270000e8322f96/content.htm


26/75

1.2.5.2 Enhancing the List Screen

Procedure

1. Choose Enhance List Screen.


You must enter leading zeros for the infotype number.

3. Enter the screen number of the list screen you want to enhance (usually screen number 3000 for infotypes without versions).


You see the message ZPLISnnnn does not exist . How do you want to continue?

5. Choose Create .


6. Enter a short description for the structure ZPLISnnnn.

7. Enter an enhancement category. To do this, choose Extras Enhancement Category.

8. Define the customer-specific components (infotype fields).

9. Save and check the structure ZPLISnnnn .

The system also creates an include program ZPnnnn40 in program ZPnnnn00.

10. Go back.

You go back to the initial screen of the transaction.

11. Choose Module Pool (Form Routine) Edit .

12. Make the required modifications in the form FILL_LISTSTRUCT to fill the components of structure ZPLISnnnn for the additional list fields.

Result

You have added fields to the standard list screen for an infotype. The additional list fields are displayed in the output of the list screen of infotype nnnn (usually

screen number 3000).

The FORM routine FILL-LISTSTRUCT is called for each data record in the list.

Structure ZPLISnnnn is identified when it is generated with a TABLES statement in the program ZPnnnn00.

The fields can be filled from the Pnnnn structure or by reading text tables.

Deleting the additional fields

You can delete the fields that have been added to the standard list screen.

You do this on the Enhance List Screen screen of the Create Infotype transaction (PM01) by choosing List Screen Delete Enhancement.

The fields in structure ZPLISnnnn are removed from the standard list screen.

1.2.6 Deleting an Infotype

Use

You can use this function to delete a customer-specific, country-spec ific, or industry-specific infotype.

Features

The system deletes the following objects, structures, and tables for the infotype: Entries in tables T582A, T777D, and T777ID

Structures PS9nnn , P9nnn

Screen structure ZHCMT_BSP_ PA_yy _R9nnn

Table(s) PA9nnn and PB9nnn

Objects P9nnn_AF and %_HR9nnn

Conversion class ZCL_HRPA_UI_CONVERT_9nnn , if it exists

Entry in table T588UICONVLAS

Module pool

Screen

Dialog module

RP_9nnn

Interface

Check class ZCL_HRPA_INFOTYPE_9nnn

Entry in table T582ITVCLAS

Entry in table T582ITVCHCK

Modifying an Infotype Included in the SAP Standard System


Page 26 of 75


27/75

For more information on the enhancement concept, see Enhancing an Infotype Included in the SAP Standard System.

In addition to the enhancement concept, the following modification options are available:

Exchanging infotype screens

Creating customer-specific single screens

Creating customer-specific list screens

Creating customer-specific includes for data declaration

Creating customer-specific includes for PBO modules

Creating customer-specific includes for PAI modules

Creating customer-specific includes for subroutines

Changing the screen control via table T588M Infotype Screen Control (to hide certain fields, for examp le)

If you add new sub-objects to an infotype, you must always use customer-specific development classes. It is important that you use customer-

specific development classes and observe the naming conventions so that your developments are not lost when the system is upgraded.

Customer-specific sub-objects are assigned to the following name ranges:

Naming conventions

Subobject Name range

Customer-specific single screens 2900to2999

Customer-specific list screens 3900to3999

Customer-specific includes for data declarations MPnnnn5x

Customer-specific includes for PBO modules MPnnnn6x

Customer-specific includes for PAI modules MPnnnn7x

Customer-specific includes for subroutines MPnnnn8x

Within the names of the includes, nnnnrepresents the number of the infotype you want to modify. The last character xcan be defined as you wish.

Business Logic Guidelines for Creating and Migrating Infotypes

This section discusses important guidelines that apply to standard business logic in a de-coupled environment, and therefore relates to the creation of new

Personnel Administration infotypes in this and every subsequent release. We recommend that you review these guidelines, as needed, whenever you execute the

Create Infotype transaction(transaction code PM01) to create new Personnel Administration infotypes and compose the corresponding business logic.

The programming guidelines set forth below solely apply to standard Personnel Administration infotypes. Infotypes in other functional areas (for

example, Time Management) are not affected.

At Release 4.6C and in prior releases, Personnel Administration infotypes were created in a previous framework, where the business logic was

not de-coupled from the corresponding user interface. That framework remains operative in this and every subsequent release, meaning that

customer-specific infotypes or individual infotype records that were created at Release 4.6C or below will continue to function in this release, or any

release thereafter.

In the revised framework for creating infotypes, the business logic of any infotype is completely de-coupled from the corresponding user interface.

To enhance master data consistency and improve performance, you may therefore wish to migrate existing infotypes from Release 4.6C and

below (henceforth described as prior releases) into this release that is, adjust the business logic of the infotypes that were created in the

previous framework to make them compatible with the revised framework for the de-coupled environment.

To the extent that you wish to adjust the business logic of infotypes from prior releases, this section also discusses important information to consider and

necessary actions to take whenever you migrate infotypes from prior releases into this release.

Although you are not required to migrate infotypes from the previous framework, it is important to note that infotypes that have not been migrated

cannot be processed by applications for example, HR Administrative Services introduced in the standard system after or in tandem with

the revised framework.

In summary, this section discusses the business logic guidelines that apply to the creation of new Personnel Administration infotypes, whether standard or

customer-specific, in this (or any subsequent) release. This section also discusses the migration of existing infotypes from prior releases into this release.

To this end, this section is divided into the following five subsections:

Preliminary Analysis

Check Classes

Implementing Checks

Writing Infotype Records

Assigning Check Classes to Containers and Infotype Versions

If you wish to follow the revised framework and create new Personnel Administration infotypes in this release, then we recommend that you observe the business

logic guidelines set forth below, along with the corresponding UI Programming Guidelines for Infotypes.

1.4.1 Preliminary Analysis

Procedure

Before you begin infotype creation (or migration), you must perform a preliminary analysis to consider the business logic of the corresponding infotype, as well as

the role that the infotype will play (or plays) in your system landscape. To this end, you must first examine the proposed (or existing) flow logic of the infotype at


Page 27 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/43/30423d29990b19e10000000a1553f6/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/21d31c4bba2bebe10000000a1553f7/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/21d1014bba2bebe10000000a1553f7/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/1d4a1b9cdb68c8e10000000a1553f7/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/02330508a26db7e10000000a422035/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/02317608a26db7e10000000a422035/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/1d63953fce3566e10000000a11466f/frameset.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d5268a575e11d189270000e8322f96/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d526be575e11d189270000e8322f96/content.htm


28/75

hand. Examining the flow logic alone, however, does not provide all the information you need for your preliminary analysis; once you have examined the (explicit)

flow logic, you must also determine the implic it checks to ensure that the check class considers the flow logic and the implicit checks alike.

From this point forward, unless otherwise explicitly stated, the present guidelines limit themselves to discussing the creation of new infotypes in

th is release. Nonetheless, the information presented in the remainder of this document applies equally to the hypothetical migration

of existing infotypes from prior releases.

Therefore, in conducting your preliminary analysis, we recommend that you consider, along with the flow logic, the following implicit checks:

Implicit value restrictions

Input/Output conversions Required input fields

Special controls

Fields that cannot accept input, because the screen logic has disabled them

Fields that are not vis ible on the screen, but which reside in the P-structure

Foreign key checks

Disabled foreign key checks

Values that can only be filled by special means, for example:

Radio buttons

Drop-down boxes

Checkboxes

Mutually dependent fields

Furthermore, you should attempt to determine whether other unique conditions exist in the infotype for example, dynamic measures, the update of tables that lie

outside the PAnnnn name range, the import or export of special data, and so on.

In the flow logic itself, we recommend that you consider the following points.

How default values are filled

How additional infotype data is read

How table PS (if applicable) is manipulated

How other infotypes (where appl icab le) are accessed

Dynamic measures that manipulate infotype records without user interaction

Processing behavior that depends on global variables

Export/Import memory issues

Identifying Implicit Value Restrictions

Procedure

Implicit value restrictions are often overlooked during the preliminary analysisof an infotype. The primary examples of implicit value restrictions are radio buttons

and checkboxes. If a radio button or checkbox is present on a screen, then only two input values are possible _(that is, inactive) and x(that is, active);

this restriction is enforced by the user interface itself. Nonetheless, radio buttons and checkboxes serve as checks , and as such, they must be considered

accordingly in the business logic.

Always remember that in direct input situations, no dynpro processor is present to prevent the user from specifying other values in these fields.

Therefore, you must make certain to encode these checks in the business logic, even if this action may initially seem to be redundant.

Another example of implicit value restrictions is found in dynpros that LOOP AT SCREENin order to disable input for certain fields. This command presupposes

that the fields in question are bound to a predefined value typically space or initial that is filled at Process Before Output (PBO). However, as with radio

buttons and checkboxes, you cannot prevent these fields from being filled in a direct input situation. Thus, as with checkboxes and radio buttons, you must

encode checks for the contents of these fields, even when such checks may seem to be redundant, as when the fields are assigned to a dynpro and therefore

have anticipated values.

1.4.1.2 Performing Infotype Screen Control

Procedure

As delivered, the standard system enables users to render certain infotype fields invisib le, or to make input for other infotype fields mandatory. To this end, users

can modify the Infotype Screen Control table (T588M) accordingly, either through corresponding country-specific Customizing activities, or, in Customizing for

Personnel Administration (PA-PA), by choosing Customizing User Interfaces Change Screen Modifications .

The Infotype Sc reen Control table is considered to be part of the user interface, rather than part of the business logic. Nonetheless, the Infotype Screen Control

table obviously introduces impli cit value restrictions, as describ ed above. Moreover, it is important to remember that the Infotype Screen Control table imposes

restrictions that are not processed during direct input, exactly like the implicit restrictions already described. Therefore, in the event that you encounter such

restrictions, you are required to consider them in your business logic as well.

1.4.2 Check Classes

Definition

As new infotypes are created in the Create Infotype transaction (transaction code PM01), the system automatically creates the corresponding check class(es)

in the background; no additional action is required for users to create the requisite check classes. Nonetheless, users may wish to consider the following chapter,


Page 28 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d5268a575e11d189270000e8322f96/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/02317608a26db7e10000000a422035/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d52586575e11d189270000e8322f96/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/21cdfc4bba2bebe10000000a1553f7/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/21cd844bba2bebe10000000a1553f7/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/21cd844bba2bebe10000000a1553f7/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/1fd622ff432e29e10000000a11466f/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/1fd5d0ff432e29e10000000a11466f/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/1fb7e9ff432e29e10000000a11466f/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/1fb7e9ff432e29e10000000a11466f/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/1f79fe033405c5e10000000a1553f6/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/02325f08a26db7e10000000a422035/content.htm


29/75

which provides useful information that pertains to the creation of check classes within standard business logic.

1.4.2.1 Creating Single Check Classes

Procedure

In the event that your infotype is country-specific, or in the event that only an international version of it exists, then only one check class will exist for it. In other

words, if a given infotype has only one screen number in the series from 2000 to 2999, then only one check class will exist for that infotype.

If the structure of the infotype at hand is relatively simple, then the new check class for the infotype can inherit the properties of the standard check class (or

superclass) CL_HRPA_INFOTYPE_NNNN.

Under very limited circumstances discussed in a subsequent background topic, it may be appropriate for the check class to write data to the

buffer. In such cases, the check class must instead inherit the properties of superclass CL_HRPA_INFTY_NNNN, rather than the properties of

superclass CL_HRPA_INFOTYPE_NNNN.

Creating Country-Specific Check Classes

Procedure

As you create country-specific check classes, remember the following two rules of thumb:

In general, the country-spec ific version of any infotype tends to store and process data in other words, behave in a manner that is simi lar to the

international version of that infotype.

Views are considered to represent particular examples of country-specific check classes .

As the logical result of these rules of thumb, country-specific check classes inherit the properties of the international check class, which in turn inherits its

properties from check class CL_HRPA_INFOTYPE_NNNN.

Check c lass CL_HRPA_INFOTYPE_0011is assigned to the External Transfers infotype (0011). Check class CL_HRPA_INFOTYPE_NNNNis

defined as the superclass for this check c lass. Because of this definition, check c lass CL_HRPA_INFOTYPE_0011inherits its properties from

check class CL_HRPA_INFOTYPE_NNNN.

Check c lass CL_HRPA_INFOTYPE_0011, in turn, is defined as the superclass for five country-spec ific check classes, as demonstrated below:

CL_HRPA_INFOTYPE_NNNN

CL_HRPA_INFOTYPE_0011

CL_HRPA_INFOTYPE_0011_BE

CL_HRPA_INFOTYPE_0011_CH

CL_HRPA_INFOTYPE_0011_NO

CL_HRPA_INFOTYPE_0011_NZ

CL_HRPA_INFOTYPE_0011_ZA

If you want country-spec ific infotypes to be able to inherit the check c lass of the international vers ion, then you must not the selec t the Final

checkbox (VSEOCLASS-CLSFINAL) while you define the attributes of the international check class.

To simplify the creation (or migration) of infotypes in(to) this release, we recommend that you design the methods of the new check class such that the specific

classes of country-specific infotypes can be easily derived. Thus, if you are responsible for the international version of an infotype, refer to Implementing Checks

and subsequent topics for a detailed overview of the technical issues at hand. Moreover, you may wish to review country-specific versions of other infotypes to

familiarize yourself with concrete examples of these technical issues. Finally, whenever you are working with international check classes, we recommend that you

thoroughly search all entries in the views Assignment of Infotypes to Views (V_T582V) and Assigns Infotype V iew to Primary Infotype (V_T582W) to ensure

that unknown infotype views do not interfere with your work.

To summarize, you should use care when performing the creation (or migration) of check classes for infotypes with several country versions, lest errors

subsequently arise in the country-spec ific versions of the infotypes.

1.4.3 Implementing Checks

Use

The following methods are delivered in the standard system with superclass CL_HRPA_INFOTYPE_NNNN. In order to create your infotype, you must implement

checks in one or more of these methods, although you are not necessarily required to re-define all of them. The methods that are subject to possible re-definition

are as follows.

Standard Methods for Implementing Checks

Method Purpose

SPECIFIC_INITIAL_COMPUTATIONS This method fills in default values if a record is created anew.

SPECIFIC_READ_COMPUTATIONS This method adds values into records after they are read from the database and before

they are presented to the user.

SPECIFIC_MODIFY_COMPUTATIONS This m ethod ascertains whether it is permitted to modify a certain record.


Page 29 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/43/1d4a1b9cdb68c8e10000000a1553f7/content.htmhttp://help.sap.com/saphelp_erp60_sp/helpdata/en/43/21fa3a4a032be8e10000000a1553f7/content.htm


30/75


31/75

serve to fulfill the requirement you seek.

1.4.3.2 Using Generic Interfaces

Use

To simplify implementations, the methods described in the topic Implementing Checksp rovide you with dynamically correctly typed Pnnnn s tructures. However,

because generic interfaces also exist, these cannot be statically typed, and must therefore be typecast before they are used.

Two possible approaches for implementing checks are illustrated in the following examples for the Recurring Payments/Deductions infotype

(0014).

The following source code demonstrates the first approach.

DATA p0014 TYPE p0014.

p0014 = pnnnn.

( ... )

pnnnn = p0014.

In this example, you would insert the source code, in lieu of ( ... ), that is required to implement the check for the Recurring

Payments/Deductions infotype (0014).

It is also feasible to follow a second approach, as demonstrated below.

FIELD-SYMBOLS TYPE p0014.

ASSIGN pnnnn to casting.

( ... )As in the first example, you would insert the source code, in lieu of( ... ), that is required to implement the check for the Recurring

Payments/Deductions infotype (0014).

Procedure

While both of the approaches described above are valid, each approach offers unique advantages and disadvantages. The first approach avoids field symbols

entirely, and may therefore initially offer greater appeal. However, the second approach forestalls the possibility of forgetting to move the structure back again.

Furthermore, this approach offers a minor performance advantage. For these reasons, we recommend that you pursue the second approach, rather than the first,

although either approach, to reiterate, is valid.

Under no circumstances should you implement external performs into existing reports, as the system will detect these and in response issue a

short dump. If you need external functionality, then you must encapsulate this within classes or function modules.

Finally, it is important to note that all check classes and check methods should be completely stateless. Do not use any attributes to keep track of subsequent

changes to your records; such attributes are explicitly not supported by the standard system, and may cause your source code to become corrupt.

Processing Methods: The Standard Sequence

Purpose

The processing sequence that occurs among the methods and various screen events is described in the following diagrams. For simp licitys sake, these

diagrams do not illustrate every process in the sequence for example, determining the correct check class, determining time constraints, and so on but rather

limit themselves to the relationship between the methods and these screen events.

The information presented in this topic exceeds the general knowledge that is required to create (or migrate) infotypes in(to) this release.

Individuals who have particular expertise in this subject matter or who desire deeper knowledge of this issue may nonetheless consult this topic

for reference.

Process Flow

Diagram A, shown below, describes how a new record is created.


Page 31 of 75
http://help.sap.com/saphelp_erp60_sp/helpdata/en/43/1d4a1b9cdb68c8e10000000a1553f7/content.htm


32/75

In the SPECIFIC_INITIAL_COMPUTATIONSmethod, all appropriate default values are filled. In the SPECIFIC_INSERT_COMPUTATIONSmethod, all

necessary checks are performed for the insertion of records; this method, where needed, also fills derived values. If errors arise, the system will continue to

process the screen anew until the user either exits the session or the records are sent to the database. If the user does nothing more than choose Enter , then the

system will respond in the same manner, with one exception: the system will roll back the buffer once all checks have been processed.

Diagram B, shown below, describes how a record is copied.

As Diagram B demonstrates, the system copies records in essentially the same manner as it inserts them, with one difference: instead of creating a new record,

the system reads an existing record.

Diagram C, shown below, describes how a record is modified.

As Diagram C demonstrates, the sys tem modifies records in essentially the same manner as it copies them.

Diagram D, shown below, desc ribes how a record is deleted.


Page 32 of 75


33/75


34/75

ENDIF.

ENDMETHOD.

The parameters shown in this example convey the corresponding meanings:

MESSAGEcontains the actual text of the message.

FIELD_LISTcontains the list of fields that the message affects. In dynpro terms, FIELD_LISTin this release is used in lieu of statement CHAIN, which was

employed in prior releases. Because of this change, these fields are no longer determined by the dynpro, but rather by the logic that creates the message. In

other words, the field list in this release is now contained within the business logic itself, rather than on the screen.

CAUSEinforms the message handler why the error occurred, which allows the system to prioritize errors by their respective semantics. This command allows

the system to handle errors caused by authorization checks, for example, in a different fashion than errors encountered by the infotype. This prioritization, in turn,facilitates the debugging process.

In addition to the above example, it is important to remember that filling the message variables with the MOVEcommand, unlike p rior releases, no longer serves to

perform output conversions. Therefore, if you wish to move data or time information into any of these variables, you should use the WRITE INTOcommand, rather

than MOVE. The same principle holds for any other variables that require output conversion.

Finally, it is also important to remember that whenever you add a message to interface IF_HRPA_MESSAGE_HANDLER, the system will always return control to

your method. In the standard system, it therefore is possible (and indeed explicitly supported) for processing to continue, even after an error message has been

issued. As a rule of thumb, it is reasonable to check all required input fields, even if one of them lacks the appropriate input. However, if you determine that you

cannot continue your checks for example, because you wish to compare two required fields, but one of these fields lacks the required input then you should

exit the method.

Avoiding Pitfalls in Message Handling

This topic discusses three pitfalls that frequently arise during message handling. However, provided that you are familiar with the information in this topic,

Developing an Infotype in Personnel Administration

Documents

Transcript of Developing an Infotype in Personnel Administration