You are on page 1of 75

Developing an Infotype in Personnel Administration

PDF download from SAP Help Portal:


http://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d52552575e11d189270000e8322f96/content.htm
Created on August 25, 2014

The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.

Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.

2014 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

Table of content

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

Page 1 of 75

Table of content
1 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 Version
1.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 Fields
1.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

1.4.3.7.2 Disabling Foreign Key Checks


1.4.3.7.3 Disabling Value Range Checks
1.4.3.7.4 Checking Radio Buttons and Checkboxes
1.4.3.7.5 Changing the Keys for HR Master Data (PSKEY) Field During Checks
1.4.3.7.6 Implementing Mutually Dependent Fields
1.4.3.7.7 Performing Subtype Checks
1.4.3.7.8 Calling Function Modules
1.4.3.7.9 Reading the Country Grouping (MOLGA) Field
1.4.3.7.10 Reading Infotypes
1.4.3.7.11 Reading Customizing Tables with Existing Specialized Classes
1.4.3.7.12 Creating New Specialized Classes to Read Customizing Tables
1.4.3.7.13 Reading Features
1.4.3.7.14 Replacing Fields PSYST-NSELC and PSYST-IOPER (Migration Only)
1.4.4 Writing Infotype Records
1.4.4.1 Background Information
1.4.4.2 Using Containers to Write Data
1.4.4.3 Reading Before Writing
1.4.4.4 Creating New Containers Before Writing
1.4.4.5 Modifying Contents of Containers
1.4.4.6 Deleting Existing Records
1.4.4.7 Inserting New Records
1.4.4.8 Modifying Existing Records
1.4.4.9 Using Pushbuttons
1.4.4.9.1 Declaring the Operations
1.4.5 Assigning Check Classes to Containers and Infotype Versions
1.5 UI Programming Guidelines for Infotypes
1.5.1 Programming User Interfaces in the De-Coupled Framework
1.5.2 Screen Structures
1.5.2.1 Infotype Screen Structures (Type MAIN)
1.5.2.2 Repeat Field Screen Structures (Type LINE)
1.5.3 Conversion Classes
1.5.3.1 Initialization (Method INITIALIZE)
1.5.3.2 Output Conversion (Method OUTPUT_CONVERSION)
1.5.3.3 Input Conversion (Method INPUT_CONVERSION)
1.5.3.4 Input Help Values (Method FILL_HELP_VALUES)
1.5.3.5 Repeat Fields: Output Conversion (Method OUTPUT_TABLE_CONVERSION
1.5.3.6 Repeat Fields: Input Conversion (Method INPUT_TABLE_CONVERSION)
1.5.3.7 Automatically Retrieving Descriptive Texts
1.5.3.8 Reusing International Conversion Classes
1.5.4 Assigning Conversion Classes to Screen Structures

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

Page 3 of 75

Developing an Infotype in Personnel Administration


Use
Infotypes are used in Personnel Administration and Recruitment.
Transaction PM01 Create Infotype is a tool that both customers and SAP can use to develop new infotypes and to enhance standard infotypes.
This transaction allows you to enhance and modify standard SAP infotypes, and create your own infotypes.

Prerequisites
To be able to enhance a standard infotype or create a customer-defined infotype, you must have knowledge in ABAP programming, as well as experience using
the Screen Painter and ABAP Dictionary .

Features
Transaction PM01 Create Infotype comprises the following functions that you can select using tab pages:
Create new infotype
There is an old method and a new method for creating infotypes. With infotypes created using the new method, there is a strict separation between business
logic and user interface-relevant elements. These infotypes are known as "decoupled" infotypes. For more information, see Decoupling Infotypes.
New infotypes that you create using transaction PM01 should be decoupled.
The system automatically creates the necessary subobjects in the background. Some subobjects must be edited.
Create infotype version
An infotype version can be a country-specific infotype, an industry-specific infotype, or an infotype for the public sector of a country.
Enhance a screen structure of an infotype and delete enhancement.
You can create fields you want to be displayed in the infotype but are not saved in the database.
Enhance the single screen of a standard infotype and delete enhancement.
Enhance the list screen of a standard infotype and delete enhancement.
Delete customer-defined infotype

1.1 Infotype Concept


An infotype is a group of object-based pieces of information on a particular area. Infotypes are units of information in the SAP system that are grouped together as
a set of data fields.
From the user's perspective, an infotype is an input screen for creating employee-related data and business data belonging together. The user can create,
change, copy, delimit, and delete this data using infotypes.
Technically speaking, an infotype is a data structure. The data stored in an infotype is always based on the personnel number of an employee or the applicant
number of an applicant. In other words, an infotype data record is always assigned to exactly one employee or applicant.
There are infotypes that are only used in Personnel Administration and infotypes that are only used in Recruitment. There are also some infotypes that are used in
both application areas, such as:
Personal Data (Infotype 0002)
Addresses (Infotype 0006)
Internal Communication (Infotype 0105)
Each infotype is indicated by a four-digit number nnnn . This number uniquely identifies an infotype. The number range 9000 to 9999 is reserved for customer
infotypes.

1.1.1 Decoupling Infotypes


There is an old method and a new method for creating and defining infotypes. The new method does away with the previous close link between the business logic
and the user interface, that is, the visual display of the data (ABAP screens). Infotypes that are created using the new method are also known as "decoupled"
infotypes.
The infotype-specific business logic for decoupled infotypes is programmed in ABAP Objects classes instead of in the module pool. A check class is created for
each infotype; the check class is addressed by the infotype framework. For the interface-relevant elements of the infotype, a conversion class is created that
formats the business logic data for display in the user interface.
The following objects and structure are required to create an infotype in the decoupled infotype framework:
Screen structure
An ABAP dictionary structure containing all elements that should be displayed on the user interface of the infotype.
For more information, see Structure and Task of the Screen Structure.
Conversion class
An ABAP Objects class that defines the conversion of the data display in the back end to the display on the user interface.
For more information, see Conversion Class.
Assignment of screen structure to conversion class
An entry in view V_T588UICONVCLAS that controls the access of the decoupled infotype framework to the correct conversion class for the processing of a
screen structure.
For more information, see Assigning Conversion Classes to Screen Structures.

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

Page 4 of 75

Check class CL_HRPA_INFOTYPE_nnnn for a standard infotype or ZCL_HRPA_INFOTYPE_9nnn for a customer-specific infotype.
For more information, see Check Classes.
An entry in view V_T582ITVCLAS for the classes to determine version IDs and infotype containers
Check class for a version indicator
An entry in view V_T582ITVCHCK that defines the assignment of the infotype version and associated check class
The basic principles of the new method are described in the following sections. For more information and detailed notes for experts, see:
Business Logic Guidelines for Creating and Migrating Infotypes
UI Programming Guidelines for Infotypes
Transaction PM01, Create Infotype , supports the creation and enhancement of decoupled infotypes. Infotypes created using the old method can still be used. It
is not mandatory to convert infotypes to the new method, but it is advisable.
Whether or not the infotype is decoupled is irrelevant for the transaction for maintaining HR master data (PA30). Both versions are supported.

However, newer applications such as some ESS scenarios or the HR Administrative Services are based on the decoupled infotype framework,
and can only process decoupled infotypes.
This means that if you want to use a customer-specific infotype within this framework, the infotype must be decoupled.
When you create a new infotype, you should therefore always create a decoupled infotype.

Advantages
Decoupling infotypes has the following advantages:
It enhances the interchangeability of the user interface to keep up with the constant influx of new developments in visual display (new controls, visual
patterns, new graphic elements, changed user guidance, and so on)
Several infotypes can be grouped in a visual display (on a screen)
It provides high-performance processing of electronic input data without time-intensive screen processing logic (batch input)

New infotypes are decoupled right from the start if they are created using the Create Infotype transaction (PM01). To benefit from the advantages
of decoupling for existing, non-decoupled, customer-specific infotypes and non-decoupled enhancements of standard infotypes, you must
decouple them retroactively. For more information, see Migrating an Infotype.

Definition of an Infotype within the ABAP Dictionary


Each infotype nnnn requires at least three structures and one table:
Structure PSnnnn
Structure PSnnnn contains all of the infotype data fields.
Transparent table PAnnnn and/or transparent table PBnnnn
Transparent table PAnnnn is required if you want to use the infotype in Personnel Administration.
Transparent table PBnnnn is required if you want to use the infotype in Recruitment.
Structure Pnnnn
Structure Pnnnn contains infotype key fields and all of the data fields from structure PSnnnn .
Structure HCMT_BSP_PA_yy_Rnnnn (for country-specific infotypes) or HCMT_BSP_PA_XX_Rnnnn ( for international infotypes)
Generally, screen structure HCMT_BSP_PA_yy_Rnnnn contains all the fields of data field structure PSnnnn , as well as additional fields that are
displayed on the user interface of the infotype.
For more information, see Structure and Task of the Screen Structure.
When you create a new infotype, screen structure HCMT_BSP_PA_yy_Rnnnn is automatically created as a copy of structure PSnnnn . Both structures
are initially identical. To enhance a screen structure, you must edit it manually. To do this, choose the Enhance Screen Structure tab page in the Create
Infotype transaction (PM01).
In accordance with the distribution of infotype name ranges, objects P9nnn, PS9nnn, PA9nnn, PB9nnn, and ZHCMT_BSP_PA_yy_R9nnn are assigned to the
customer name range.

You want to develop an international infotype with the number 9900to be used in Personnel Administration only. The names of the structures and
tables for this infotype are as follows:
PS9900(structure)
PA9900 (transparent table)
P9900(structure)
ZHCMT_BSP_PA_XX_R9900 (structure)

For information about using name range enhancements when you create infotypes, see Developing an Infotype.

Structure and Task of Data Field Structure PSnnnn


Definition
Structure containing infotype data fields that are to be saved in the infotype.

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

Page 5 of 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 tables that 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

MANDT

CLNT

T000

Client

.INCLUDE

PAKEY

.INCLUDE

PSHD1

.INCLUDE

PSnnnn

Table PBnnnn
Field Name

Key

Data Element

Type

Length

Check Table

Short Text

MANDT

MANDT

CLNT

T000

Client

.INCLUDE

PBKEY

.INCLUDE

PSHD1

.INCLUDE

PSnnnn

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

Page 6 of 75

The definition of the primary key is the only difference between the structure of the two tables. The primary key is determined on the basis of the Client field and
substructures PAKEY and PBKEY .

Technical Settings of Database Tables


Database tables are read using the primary index. It is rarely necessary to create secondary indices.
When determining the logical memory parameters, enter the value APPL0 in the Data class field. The value of the size category can vary, depending on how
the infotype is used. For this reason, you must estimate the number of expected data records and then specify a suitable size category.
Tables PAnnnn and PBnnnn may not be buffered using the SAP database interface because the application programs must always work with current data.
For this reason, you must select the Buffering not allowed checkbox in the Buffering frame.
Infotype data records are buffered in the Personnel Management applications, irrespective of the ABAP Dictionary settings.
You can enter changes to infotype records in the form of change documents using the infotype log creation function in Personnel Management . Report
RPUAUD00 enables you to display these documents. It is rarely necessary to log data changes within the ABAP Dictionary.

Structure and Task of Structure Pnnnn


Definition
Structure containing the data fields of structure PSnnnn, and also data fields that feature in all infotypes.

Structure
Structure Pnnnn comprises the following substructures:

PSnnnn
PSHDR
Structure PSHDR contains the following substructures:
PSKEY
PSHD1

Structure Pnnnn contains almost the same fields as tables PAnnnn and PBnnnn . There are differences in the included key fields ( PSKEY instead of
PAKEY and PBKEY ). Furthermore, the Client field is not required in this structure.

Use
Structure Pnnnn is used in reporting and in the infotype module pools. It serves as an interface between the program and the database.
For information about using infotypes in reports, see the

Logical Database section under Programming Reports in HR .

For information about infotype module pools, see Infotype Module Pool.
Customer infotypes are automatically included in the logical databases PNP and PNPCE.

Structure and Task of the Screen Structure


Definition
Structure that contains the fields of the data structure PSnnnn and all fields displayed on the user interface of the infotype.

Use
The screen structure is used to display data on the user interface that is derived from the relevant database, but not saved on the database. The data can be input
fields, output fields, or descriptive texts.
When you create a new standard infotype or a customer infotype, the system creates the relevant screen structure in the background. All fields from structure
PSnnnn are automatically copied to the screen structure. You can enhance this structure. You must define a component in the screen structure for each element
you want to appear on the user interface for the infotype.
There are two types of screen structure:
MAIN
Structures with single fields
LINE
Structures with a repetitive nature (repeat structures)
Since there can be several repeat structures for an infotype, as groups of fields should be grouped in different structures, they are distinguished by the suffix
_z (see "Naming Convention" ).

Naming Convention

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

Page 7 of 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 structures contain all interface-relevant fields of an infotype that can be displayed 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 conversion class for an infotype is called at runtime by the various applications 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 versions 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_STANDARD
This 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

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

Page 8 of 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

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

Page 9 of 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
MPnnnn10

Content
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
FP50PPSB

Use
Declaration of common data objects
This data area is used as a buffer for imported infotype records and maintenance
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 not change 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 Screens


Each infotype has at least three screens:
An initial screen
A single screen

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

Page 10 of 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 infotype from 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 infotype and the user.
This screen provides the user with the following functions:
Create Data Records
Display 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 screen. 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 2900 to
2999.

Entry checks
The values of the Organizational Assignment infotype (0001) that are valid at the beginning of the records validity period, as well as the entries in the tables
listed below that are valid in structure PSYST, enable you to carry out infotype-specific 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 checked against a table.
If you assign a check table that can be checked automatically to a field within the ABAP Dictionary, the system displays possible entries automatically.

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

Page 11 of 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

Empty line

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

Empty line

Infotype-specific 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 control on 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_subscreen on chain-request.
endchain.
* ... Subscreen 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 using 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-specific initialization procedures within PBO module Pnnnn . They enable you, for example, 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

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

Page 12 of 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 example, 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 3000 of module pool
MPMMMM00 is used as a template.
You can create your own list screens for infotypes included in the SAP standard system. Customer-specific list screens are assigned to the namespace 3900 to
3999.

Structure
The list screen is divided into three areas:
Lines 1 to 3 display the header lines in an include screen.
Lines 5 to 19 contain the list with the infotype data records.
Fields assigned 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.

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

Page 13 of 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 RP50MABGRD 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 assigned to structure Pnnnn
are also included in the list screen.
If you do not use subtypes 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 using 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 screens and list screens using 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.

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

Page 14 of 75

The same single screens are used for the Display 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 (0032) 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, depending 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 using 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 screen 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 screen 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 able 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 displaying records. For this reason, the attribute Modification
Group 1 is assigned the value 00E for these fields.

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

Page 15 of 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 00F because 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 Display and Delimit functions are used. Field RP50M-SELEC , which is contained in a
loop, is assigned the value 009 for Modification Group 1 .

1.1.5.4.2 Screen Control Based on Control Data


If 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 and 050 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 SPACE in 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 Administration 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 required 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

LIS0

List screen/display

LIS1

List screen/maintain

LSI9

List screen/delimit

List screen

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 assigned to the dialog module in the Infotypes Dialog/Database Assignment table (T777D).

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

Page 16 of 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 T777D and T77ID 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 alternative 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.

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

Page 17 of 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_DATA . 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-specific 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 displayed.
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 be 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 subobjects 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 customerspecific developments to be retained after a release upgrade.

Features
The following steps are involved in creating an infotype:
Creating the data field structure in the ABAP Dictionary
Creating all other required Dictionary objects, 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-specific 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 application for
which you want to use the infotype ( employee infotype or applicant infotype ).
You create the data field structure PSnnnn .

A new infotype is limited 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 Applicant 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 customerspecific infotype.

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

Page 18 of 75

For more information, see Structure and Task of the Screen Structure.
The system also creates the following subobjects 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 list 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 Assignment )
Entry for the data field structure PSnnnn of the infotype (T777ID 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 9000 to 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 (0006) 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 Object Directory Entry dialog box is opened.
12. Enter the object directory entry for the PS structure.
13. Enter the object 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.

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

Page 19 of 75

14. Enter a transport request.


15. The following information is displayed, which you confirm:
The check class must be encoded manually.
You do this once this procedure is complete by choosing Check Class (BAdI) Edit . For more information, see Editing the Check Class.
The table entry T582ITVCLAS still has to be transported.

This table entry is client-dependent and therefore only exists in this client. Make sure that the table entry is transported.
16. Maintain the characteristics of the infotype. For more information, see Defining Infotype Characteristics.

Note on creating infotypes with name range enhancement


If you are creating an infotype with a name range enhancement (such as /Company1/9000), make sure that your entries are overwritten by those of another
imported infotype with name range enhancement (/Partner1/9000, for example), if the infotype number of the imported infotype is the same as your infotype. For
this reason, make sure before you import infotypes with name range enhancements that there are no conflicts between the infotype numbers available and those
that are to be imported.
To define a namespace, choose Infotype Namespace and enter the namespace reserved for your company.
Then proceed as described above.

Result
You have created a new infotype.
The system has automatically created the following objects and structures:

PS structure (if it did not already exist)


The corresponding P structure
Table(s) PAnnnn and PA9nnn and/or PBnnnn and PB9nnn
Object Pnnnn_AF,%_HRnnnn
Entries in tables T777D and T77ID
Screen structure
The system has copied the fields from the PS structure to the screen structure. The PS structure and the screen structure are identical.
The name of the screen structure HCMT_BSP_PA_yy_Rnnnn or ZHCMT_BSP_PA_yy_R9nnn is generated from the infotype.

To enhance the screen structure, choose the tab page Enhance Screen Structure.
Entry in table T588UICONVCLAS
Assignment of screen structure to conversion class
SNAME

INFTY

STYPE

VERSIONID

CLSNAME

HCMT_BSP_PA_yy_Rnnnn

nnnn

MAIN

yy

CL_HRPA_UI_CONVERT_BASI
C

Module pool
Screen and interface
Check class CL_HRPA_INFOTYPE_nnnn for a standard infotype or ZCL_HRPA_INFOTYPE_9nnn for a customer-specific infotype.
The check class was generated in the background from the check class CL_HRPA_INFOTYPE_NNNN and must be encoded manually.
Entry in table T582ITVCLAS
Classes for determining version IDs and infotype containers
INFTY

IDCLASS

nnnn

CL_HRPA_INFOTYPE_nnnn

CONT_GUI

CONT_DB

NITF_ADM

CL_HRPA_INFOTYPE_CONTAI 3
NER

1.2.1.1 Defining Infotype Characteristics


Use
Infotype characteristics contain information about the time constraint (time constraint table), subtype (subtype table), display and selection (such as reaction
indicators for entering dates on the menu selection screen, date proposal for the start date on the selection screen, and so on), information about the retroactive
accounting trigger for payroll infotypes, information about the single screen and list screen, and so on. You must define these infotype characteristics after you
create an infotype.

Procedure
1. If you want to maintain the characteristics of an infotype, proceed as follows:
After you have created a new infotype, you automatically go to the maintenance view for infotype characteristics.
If you want to go back and edit the characteristics of an infotype, choose Infotype Characteristics .
The Display Infotype Characteristics (Customizing): Overview screen appears.

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

Page 20 of 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 characteristics 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.

Result
You 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 Guidelines 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-specific input and processing logic must be decoupled manually. They are decoupled in the same way as the infotype-specific input
and processing logic of a customer infotype.
For more information, see Business Logic Guidelines for Creating and Migrating Infotypes.

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

Page 21 of 75

Features
The system creates the following objects and structures automatically:
Screen structure
The P structure fields are copied to the screen structure.
Table T588UICONVCLAS
The system creates the following entry for customer infotypes:
Assignment of screen structure to conversion class
SNAME

INFTY

STYPE

VERSIONID

CLSNAME

ZHCMT_BSP_PA_yy_R9nnn

9nnn

MAIN

yy

CL_HRPA_UI_CONVERT_BASI
C

The system creates the following entry for standard infotypes:


Assignment of screen structure to conversion class
SNAME

INFTY

STYPE

VERSIONID

CLSNAME

HCMT_BSP_PA_yy_Rnnnn

nnnn

MAIN

yy

CL_HRPA_UI_CONVERT_BASI
C

Check class CL_HRPA_INFOTYPE_nnnn or ZCL_HRPA_INFOTYPE_9nnn for customer infotypes


The check class is generated in the background from the check class CL_HRPA_INFOTYPE_NNNN. If you have already made modifications in the check
class, the check class can not be overwritten by another migration. The criterion for a migration that has already taken place is the entry in table
T582ITVCLAS.
Entry in table T582ITVCLAS
The system creates the following entry for customer infotypes:
Assignment of infotype to check class and container class
INFTY

IDCLASS

CONT_GUI

CONT_DB

9nnn

ZCL_HRPA_INFOTYPE_9nnn

CL_HRPA_INFOTYPE_CONTAI 3

NITF_ADM

NER

The system creates the following entry for standard infotypes:


Assignment of infotype to check class and container class
INFTY

IDCLASS

CONT_GUI

CONT_DB

nnnn

CL_HRPA_INFOTYPE_nnnn

CL_HRPA_INFOTYPE_CONTAI 3
NER

NITF_ADM

The check class must be encoded manually. The system outputs a message to this effect.
The module pool, screen, and interfaces must be processed manually.

Creating an Infotype Version


Use
You create an infotype version if you want to create a country-specific or industry-specific infotype, or an infotype for the public sector of a country.
If you require an international infotype, choose Creating an Infotype.
Creating infotype versions can affect all existing subobjects of an infotype.

For country-specific versions of the Addresses infotype (0006), a specific single screen can be required for certain countries (for example, a
single screen for entering US address data). In addition, you may have to adjust the list screen specifically for the infotype version (for example,
the list screen for US address data).

Procedure
1. Choose Create Infotype Version (tab page).
2. Enter the infotype number.
3. Enter the infotype version.

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

Page 22 of 75

4. Choose Generate Objects.


The Create Object Directory Entry dialog box is opened.
5. Enter the object directory entry for the following object:
CL_HRPA_INFOTYPE_nnnn_yy for an infotype version of a standard infotype, or ZCL_HRPA_INFOTYPE_9nnn_yy for an infotype version of a
customer-specific infotype.
6. The following information is displayed, which you confirm:
Note: Check class CL_HRPA_INFOTYPE_nnnn_y (or ZCL_HRPA_INFOTYPE_9nnn_yy) must be encoded manually.
Transport table T582ITVCHCK.

This table is client-dependent and cannot be transported, depending on how the client is set up. You must therefore transport the object manually
(if necessary from another client).
7. Now process the subobjects of the infotype version.

Result
You have created a new infotype version.
The system has automatically created the following objects and structures:

PS structure (if it did not already exist)


The corresponding P structure
Table(s) PAnnnn and PBnnnn
Screen structure
The system has copied the fields from the PS structure to the screen structure. The PS structure and the screen structure are identical. The name of the
screen structure ( HCMT_BSP_PA_yy_Rnnnn or ZHCMT_BSP_PA_yy_R9nnn ) is generated from the infotype and the infotype version.
Entry in table T588UICONVCLAS
Assignment of screen structure to conversion class
SNAME

INFTY

STYPE

VERSIONID

CLSNAME

HCMT_BSP_PA_yy_Rnnnn

nnnn

MAIN

yy

CL_HRPA_UI_CONVERT_BASI
C

Module pool (if it did not already exist)


Screen and interface (if they did not already exist)
Check class CL_HRPA_INFOTYPE_nnnn_yy or ZCL_HRPA_INFOTYPE_9nnn_yy
This check class is generated from the check class CL_HRPA_INFOTYPE_nnnn or CL_HRPA_INFOTYPE_9nnn, if they exist. If not, it is generated
from check class CL_HRPA_INFOTYPE_NNNN and must be encoded manually .
Entry in table T582ITVCHCK
Check class for a version indicator
MANDT

INFTY

VERSIONID

CHECKCLASS

Sy-mandt

nnnn

yy

CL_HRPA_INFOTYPE_nnnn_yy

Entry in table T582ITVCLAS


This entry is generated if the table does not contain an entry for the infotype nnnn or 9nnn , that is, if there is no relevant international infotype and no other
infotype version.
Assignment of infotype to check class and container class
INFTY

IDCLASS

nnnn

CL_HRPA_INFOTYPE_nnnn_yy

CONT_GUI

CONT_DB

NITF_ADM

CL_HRPA_INFOTYPE_CONTAI 3
NER

Editing of Subobjects of an Infotype Version


Use
If you have created an infotype version, you modify each subobject to suit your specific requirements.
Above all, you must encode the check class CL_HRPA_INFOTYPE_nnnn_yy manually.

Activities
Editing the PS structure
Edit the PS structure. Add the specific fields for your infotype version.

You have created an infotype version Z6 for the Addresses infotype (0006). You include the field for the ZIP code in the PS structure for the
infotype, that is, in structure PS0006 in the customer include CI_P0006.

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

Page 23 of 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 single screen and list 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 (0006) for the US contains a module called ZIP_CODE_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.
4. Choose Generate Objects.
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.

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

Page 24 of 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 0081)
Leave Entitlement Compensation (infotype 0083)
Time Quota Compensation (infotype 0416)
Applicant 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 Assignment infotype (0001), you cannot use them as selection fields.

1.2.5.1 Enhancing the Single Screen


Procedure
1. Choose Enhance Single Screen.
2. In the Infotype Number field, enter the four-digit number of the infotype you want to enhance.
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.
4. Choose Generate Objects.
You see the message CI_Pnnnn 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 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 Single
Screen screen of the Create Infotype transaction (PM01) .
The screen structure include CI_XX_Rnnnn is created 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 HRPAD00INFTYUI BAdI must be implemented.
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.

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

Page 25 of 75

1.2.5.2 Enhancing the List Screen


Procedure
1. Choose Enhance List Screen.
2. In the Infotype Number field, enter the four-digit number of the infotype you want to enhance.
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).
4. Choose Generate Objects.
You see the message ZPLISnnnn 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 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-specific, 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


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

Page 26 of 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 example)

If you add new sub-objects to an infotype, you must always use customer-specific development classes. It is important that you use customerspecific 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

2900 to 2999

Customer-specific list screens

3900 to 3999

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 x can 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,
the revised framework.

HR Administrative Services introduced in the standard system after or in tandem with

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

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

Page 27 of 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 implicit 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 visible 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 applicable) 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 analysis of 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 SCREEN in 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 invisible, 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 Screen 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 implicit value restrictions, as described 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,

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

Page 28 of 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-specific version of any infotype tends to store and process data in other words, behave in a manner that is similar 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 class CL_HRPA_INFOTYPE_0011is assigned to the External Transfers infotype (0011). Check class CL_HRPA_INFOTYPE_NNNN is
defined as the superclass for this check class. Because of this definition, check class CL_HRPA_INFOTYPE_0011 inherits its properties from
check class CL_HRPA_INFOTYPE_NNNN.
Check class CL_HRPA_INFOTYPE_0011, in turn, is defined as the superclass for five country-specific 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-specific infotypes to be able to inherit the check class of the international version, then you must not the select 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 View 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-specific 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 method ascertains whether it is permitted to modify a certain record.

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

Page 29 of 75

SPECIFIC_INSERT_COMPUTATIONS

This method ascertains whether it is permitted to insert a particular record.

SPECIFIC_DELETE_COMPUTATIONS

This method ascertains whether it is permitted to delete a particular record.

As the naming convention implies, methods are referred to as computations, rather than checks, because any method can be applied to perform additional
functions for example, filling in derived values. Methods can even be used to write additional records into the buffer, or to prepare additional updates for tables
that lie outside the PAnnnn name range. Therefore, if you wish to use methods to write data, you must take precautions to ensure that such methods are
smoothly integrated.

Procedure
These methods should always be written as if an actual update will be requested and as if the database will not be updated. This requirement exists as the result
of a mechanism in this release that allows the buffer to roll back at any time. We therefore recommend that you never update any table directly from within a check
class; additional updates for tables that lie outside the PAnnnn name range must instead be processed via the so-called additional update mechanism, which
serves to forestall errors that may arise from the absent buffer rollbacks.

1.4.3.1 Redefining Check Methods


In rare cases, the re-definition of check methods may result in errors. The three topics in this section, listed below, discuss the errors that may arise.
Inserting New Check Methods
Removing Existing Check Methods
Extending Existing Check Methods

The information presented in the topics in this section 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
the three topics in this section for reference.

1.4.3.1.1 Inserting New Check Methods


The international version of the Personal Data infotype (0002) contains the method SPECIFIC_COMPUTATIONS, which in turn calls several other subordinate
check methods that are smaller than SPECIFIC_COMPUTATIONS.
Suppose that a country-specific version of the Personal Data infotype (0002) requires more check methods than are offered in the international version. In
creating the country-specific version, one could falsely assume that it is correct to re-define the method SPECIFIC_COMPUTATIONSto call all of the smaller
subordinate check methods, along with the new check method(s) that the country version requires. Although this approach is incorrect, you could easily achieve
such an action by copying the properties of the international version of the Personal Data infotype (0002) into the country-specific name range. The drawback of
this approach, however, lies in the fact that any subsequent changes to the method SPECIFIC_COMPUTATIONSwould not be inherited in the country-specific
version of the infotype.
Therefore, to ensure that the properties of the international version are considered (and inherited) in the country-specific version, we recommend that you re-define
method SPECIFIC_COMPUTATIONSin your country-specific version to call the superordinate method SUPER->SPECIFIC_COMPUTATIONS. After this call is
complete, simply add the additional country-specific method(s) that you require.

1.4.3.1.2 Removing Existing Check Methods


It is slightly more difficult to remove check methods from country-specific infotype versions than it is to insert them. In creating the country-specific version, one
could falsely assume that it is correct to copy the properties of the international version of the Personal Data infotype (0002) into the country-specific name range,
then remove the check method(s) that the country version does not require. The drawback of this approach, however, lies in the fact that any subsequent changes
to the method SPECIFIC_COMPUTATIONS would not be inherited in the country-specific version of the infotype.
Suppose that a country-specific infotype version requires all of the check methods that are found in the international version, except one: the method
CHECK_POSITION. In this situation, the best approach is not to re-define the (superordinate) method SPECIFIC_COMPUTATIONS, but rather the (subordinate)
method call itself: CHECK_POSITION. To this end, define CHECK_POSITION as IS_OK = TRUE, because if you do not wish to check the position, then you can
just as easily write your source code, via this definition, to disregard it.

1.4.3.1.3 Extending Existing Check Methods


Suppose you want to extend a check method that is already present, but whose existing signature method is not wide enough. For example, suppose you wish to
call method CHECK_BIRTH_DATE, but that you additionally require the country grouping in the signature. This requirement obviously cannot be fulfilled by redefining the method. However, two alternative approaches do serve to fulfill this requirement.
The first approach would be to change the signature of the method in the international class. This approach presents one drawback: all of the classes that directly
call the method would be invalidated, as it is assumed that method SPECIFIC_COMPUTATIONShas been re-defined and copied. Therefore, only pursue the first
approach in the event that this signature is actually flawed in other words, if the parameter is truly absent.
The second approach is to understand that if the signature is not suitable, and if the method has a correct signature, then the semantics of the method itself are in
effect unsuitable. In other words, if you wish to call method CHECK_BIRTH_DATEwith the country grouping in the signature, then you actually require an entirely
new method for example, CHECK_COUNTRY_SPECIFIC_BIRTH_DATE. To this end, you would redefine CHECK_BIRTH_DATE to be empty, thereby disabling
the international check. Then, you would redefine SPECIFIC_COMPUTATIONSby implementing the superordinate check method SUPER>SPECIFIC_COMPUTATIONS, which would serve to process all of the international checks. Finally, you would create a new method
CHECK_COUNTRY_SPECIFIC_BIRTH_DATE, which would be called after the method SUPER->SPECIFIC_COMPUTATIONS.
In summary, it is worth noting that the examples provided above are not exhaustive; other situations may arise that require existing check methods to be modified.
However, all of the examples provided do serve to illustrate an important point: in most cases, re-defining a method with a slightly modified copy usually does not

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

Page 30 of 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 Checks provide you with dynamically correctly typed Pnnnn structures. 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 <p0014> TYPE p0014.
ASSIGN pnnnn to <p0014> 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 simplicitys 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.

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

Page 31 of 75

In the SPECIFIC_INITIAL_COMPUTATIONS method, all appropriate default values are filled. In the SPECIFIC_INSERT_COMPUTATIONS method, 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 system modifies records in essentially the same manner as it copies them.
Diagram D, shown below, describes how a record is deleted.

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

Page 32 of 75

As Diagram D demonstrates, the system deletes records in essentially the same manner as it modifies them.
In summary, within the system, no one-to-one mapping relationship exists between PBO or PAI and the respective methods. Rather, as the above diagrams
suggest, PBO flows into the methods SPECIFIC_INITIAL_COMPUTATIONS and SPECIFIC_READ_COMPUTATIONS, while PAI flows into the methods
SPECIFIC_INSERT_COMPUTATIONS, SPECIFIC_MODIFY_COMPUTATIONS and SPECIFIC_DELETE_COMPUTATIONS.

1.4.3.4 Performing Message Handling


Procedure
As you are implementing checks, it is important to consider the means you will use to indicate error conditions. Unlike prior releases, where message statements
are issued to draw attention to errors, you may no longer use message statements in this release, as such statements now lead to errors in their own right.
In this release, you must therefore employ interface IF_HRPA_MESSAGE_HANDLER to handle messages. To add a message to this interface, employ method
ADD_MESSAGE.
Unlike prior releases, messages in this release are always created dynamically. For this reason, the Where-Used List in this release can no longer determine
where messages are used. It is therefore useful to employ the statement IF 1 = 0 to hard-code a dummy message. Alternatively, one could falsely assume
that it is correct to employ the MESSAGE INTO statement, so that breakpoints, where needed, could be set at this statement. However, this approach is
unnecessary, because interface IF_HRPA_MESSAGE_HANDLER already fulfills the requirement of setting breakpoints wherever needed; any breakpoints at
MESSAGE will always stop in method ADD_MESSAGE.

Example
The following example demonstrates a case where the method CHECK_REQUIRED_FIELD of check class CL_HRPA_INFTY_NNNNis called; for background
information on the use of this check class, refer to a subsequent background topic.
METHOD check_required_field.
DATA msg

TYPE symsg.

DATA field_list TYPE hrpad_field_tab.


IF field_name IS INITIAL.
RAISE EXCEPTION TYPE cx_hrpa_invalid_parameter
EXPORTING
parameter = 'FIELD_NAME'.
ENDIF.
IF required_field IS NOT INITIAL.
is_ok = true.
ELSE.
IF 1 = 0.
*

055 Make an entry in all required fields


MESSAGE ID '00' TYPE 'E' NUMBER '55'.
ENDIF.
msg-msgid = '00'.
msg-msgty = 'E'.
msg-msgno = '55'.
APPEND field_name TO field_list.
CALL METHOD message_handler->add_message
EXPORTING
message

= msg

field_list = field_list
cause

= if_hrpa_message_handler=>infotype_specific.

is_ok = false.

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

Page 33 of 75

ENDIF.
ENDMETHOD.
The parameters shown in this example convey the corresponding meanings:
MESSAGE contains the actual text of the message.
FIELD_LIST contains the list of fields that the message affects. In dynpro terms, FIELD_LIST in 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.
CAUSE informs 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 MOVE command, unlike prior 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 INTO command, 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, you can
easily avoid each of these pitfalls.
The first pitfall occurs when an error is added to the message handler and a method is exited, but no information is provided to instruct the caller that the
corresponding checks have failed. You can easily avoid this pitfall by creating an additional message handler object although the contents of the imported
message handler should not be evaluated under any circumstances, and cannot be evaluated by a typecast anyway, because the handler may already contain
other messages. Under these circumstances, the most expedient solution is to insert an additional IS_OK flag (of TYPE BOOLE_D) to indicate that processing
was completed successfully. With this solution in place, the system eventually will ascertain whether the message handler and the IS_OK statement are
synchronized. If this is not the case, then the system will issue an exception.
The second pitfall arises when warnings inadvertently change the control flow. Warnings, unlike errors, always enable processing to continue. Although warnings
advise the user that a particular action may cause subsequent problems, warnings do not prevent the user from performing that action. Therefore, if you add a
warning, you should always return with IS_OK = TRUE to ensure that your warning does not change the control flow.
The third pitfall relates to the fact that the buffer can be rolled back at any time, even if no errors are issued, and even if additional updates (for example,
retrocalculation checks) are performed. Therefore, even if none of your checks fail, you must still expect that the buffer can be rolled back at any time. Thus, your
check classes should refrain, for example, from using database operations, or attributes that hold an internal state that depends upon the checks, to say nothing of
import/export statements, SET/GET parameters and the like.

Streamlining Message and Exception Handling


This topic discusses approaches for streamlining message handling within your infotype.

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.
To encode message handling in the most expedient manner possible, we recommend that you refrain from using macros, as other methods exist to achieve
shorter calls.

The following example demonstrates one option to streamline message handling.


DATA dummy(1) TYPE c.
(...)
*

055 Make an entry in all require fields


MESSAGE ID '00' TYPE 'E' NUMBER '55' INTO dummy.
MOVE-CORRESPONDING sy TO msg.
APPEND field_name TO field_list.
CALL METHOD message_handler->add_message
EXPORTING
message

= msg

field_list = field_list
cause

= if_hrpa_message_handler=>infotype_specific.

If you elect to use this option, then you need not concern yourself with output conversion, because the system will populate the SY variables
correctly.
A second option to streamline message handling concerns the field list; rather than specifying the following source code
APPEND P4711-FIELD1 TO field_list.
APPEND P4711-FIELD2 TO field_list.
APPEND P4711-FIELD3 TO field_list.
APPEND P4711-FIELD4 TO field_list.
you may instead specify either of the following two alternatives:

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

Page 34 of 75

SPLIT P4711-FIELD1 P4711-FIELD2 P4711-FIELD3 P4711-FIELD4


AT space INTO TABLE field_list.
or
SPLIT
P4711-FIELD1 &
P4711-FIELD2 &
P4711-FIELD3 &
P4711-FIELD4 AT space INTO TABLE field_list.
As you consider the most expedient manner for your infotype to handle messages, keep in mind that the system assumes that all exceptions will be handled by
the class-based exception mechanism, and that all exceptions truly are, in fact, exceptional, rather than mechanisms, for example, to set return values with a
global variable. Because of these underlying assumptions, you should never misuse exceptions to indicate expected results, but rather only to indicate that an
exceptional situation has occurred, in response to which the system may issue a short dump.
Review the following criteria to determine whether your infotype, depending upon the corresponding situation, should issue an error message or an exception.
Under the following circumstances, an error message should be issued.

A deviation from standard processing is required.


Processing of data should not be interrupted.
The problem is likely to be caused by user input.
The problem can be corrected by the user.
The problem is expected to happen on a regular basis.

In contrast, under the following circumstances, an exception should be used.


The problem is caused either by erroneous source code or by erroneous database entries.
The problem is not expected to happen on a regular basis. Once the problem does occur, the application must determine whether or not it can recover. In
severe cases, where recovery is impossible, the system may issue an exception to interrupt any subsequent processing (that is, dump). Determination of
whether recovery is possible therefore should not be performed in low-level routines.
To summarize, it is important that you avoid confusing exceptions with messages or status indicators, and vice versa. Only occurrences that would merit an entry
in the system log should be considered as exceptions.

The following examples are intended to help you distinguish situations that require genuine exceptions from situations that merely require error
messages.
Exception CX_HRPA_INVALID_DATABASE is used to indicate the presence of corrupt database entries, which merits a genuine exception, rather
than an error message.
Exception CX_HRPA_INVALID_INFOTYPE indicates that entries are missing from the Infotypes - Dialog/Database Assignment or Infotypes:
Customer-Specific Settings tables (T777D or T582A, respectively). However, because situations exist in which this exception should not be used
as when a user, for example, enters an invalid number while attempting to display an infotype an error message is generally more appropriate
than a genuine exception. The exception CX_HRPA_INVALID_INFOTYPE, in fact, should only be applied when an infotype for example, the
Organizational Assignment infotype (0001) is expected to be present, but its table entries are absent.

1.4.3.4.3 Remapping Generic Messages


In some cases, users may need to remap messages. For example, a caller may on the one hand use the Currency Key field (CURKY), but a called method, on
the other hand, may instead use the field CURRENCY_KEY.

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.
In situations like these, it may be necessary to ignore all fields and enforce a specific field list, and therefore substitute a technical message with an error
message that is more informative and user-friendly. The following procedure summarizes the actions to be taken when generic message remapping is required.
1. In order to remap certain fields, you must first create a local remapping class, by means of which the corresponding source code is inserted into your local
type declarations.

To remap messages that pertain to currency keys, insert the following source code, which presupposes that you have defined lcl_msg_curky_remap as
a local remapping class.
CLASS lcl_msg_curky_remap DEFINITION FINAL
INHERITING FROM cl_hrpa_message_generic_remap.
PROTECTED SECTION.
METHODS remap REDEFINITION.
ENDCLASS.
2. Once the local remapping class is defined, you must actually implement the corresponding source code in all local instances of your class, as demonstrated
below.

To continue with the previous example, implement the source code as follows.
CLASS lcl_ msg_curky_remap IMPLEMENTATION.
METHOD remap.
CLASS lcl_msg_curky_remap DEFINITION FINAL
INHERITING FROM cl_hrpa_message_generic_remap.
PROTECTED SECTION.
METHODS remap REDEFINITION.
ENDCLASS.

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

Page 35 of 75

ENDMETHOD.
ENDCLASS.
3. Finally, once your implementation is in place, you may invoke it with the following command.

To continue with the previous example, implement the source code as follows.
DATA remapper TYPE REF TO if_hrpa_message_handler.
CREATE OBJECT remapper TYPE lcl_msg_curky_remap
EXPORTING
message_handler = message_handler.

Processing Required Fields, Read-Only Fields and Unused Fields


Purpose
Two tables are delivered in the standard system to determine the properties of infotype fields. For all standard infotypes (0000-8999), which are delivered by
SAP, table T588MFPROPS governs the behavior of the corresponding fields. In contrast, customer table T588MFPROPC governs this behavior for customerspecific infotypes (9000-9999), but may also (where permitted) overwrite the standard entries in table T588MFPROPS and therefore also influence the behavior
of standard infotypes.

Process Flow
To view (or, if applicable, maintain) the entries in either table for a particular infotype, execute the Create Infotype transaction (transaction code PM01). On the
subsequent screen, either on the default IT tabstrip, or on the adjacent IT Version tabstrip, enter the corresponding infotype number. Then choose Infotype
Edit Field Characteristics (Customer IT) to view or maintain entries in table T588MFPROPC. For T588MFPROPS table entries, choose Infotype Edit
Field Characteristics (Standard IT) .
Each table describes the P structures of the corresponding set of primary records. Where applicable, each table also describes the P structures of the
corresponding secondary records and cost PREF structures. As summarized in the following chart, various attributes can be assigned to the respective fields
within each table.
Use of Attributes Within Tables T588MFPROPS and T588MFPROPC
Table T588MFPROPS

Table T588MFPROPC

Attribute MANDATORY

available

available

Attribute READONLY

available

available

Attribute UNUSED

available

available

Attribute FIXED

available

unavailable

If the MANDATORY attribute is specified, indicating that input is required, then the system will issue an error from this field in response to non-initial input.
If the READONLY attribute is specified, then the system will not permit the user to modify the field, and will in fact issue warnings if the user attempts to do so.
If the attributes MANDATORY and READONLY are both specified, then the system will consider the field to be required, during insertion, or read-only, during
modification. (Specification of both attributes is appropriate for fields in which an entry is to be made once, but never changed again.)
If the UNUSED attribute is specified, then the system will subsequently ignore the MANDATORY and READONLY attributes. (Where this attribute is specified, the
system will always initialize the corresponding field; no data can ever be stored in it.)
Finally, if the FIXED attribute is specified in table T588MFPROPS, then the system will not evaluate any attribute that is set for this field in table
T588MFPROPC. In other words, for all fields except those to which the FIXED attribute is assigned, customers may overwrite the (standard) T588MFPROPS
entry with a (customer-specific) T588MFPROPC entry.

As summarized in the chart above, the FIXED attribute is not available in table T588MFPROPC.

Inheritance Mechanism for Infotype and Related Fields


In addition to the attributes described in the prior topic, tables T588MFPROPS and T588MFPROPC both feature the key fields Infotype (INFTY), ID for Infotype
Versions (ITVERS) and Subtype (SUBTY), which enable the system to differentiate among the infotype, infotype version and subtype, respectively.

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.
To avoid the necessity of maintaining entries for all country versions and all subtypes, the standard system features an inheritance mechanism, described in the
following diagram, which instructs it to evaluate the most specific of the key fields INFTY, ITVERS and SUBTY. In the context of this mechanism, generic entries
are created by setting the key field ITVERS or the key field SUBTY (or both key fields) to space ( ), as shown below in Diagram E.

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

Page 36 of 75

If corresponding entries also exist in table T588MFPROPC and provided that the FIXED attribute is not specified in table T588MFPROPS for these entries
then the inheritance mechanism will evaluate the key fields in the manner described below, in Diagram F.

If entries exist in table T588MFPROPC for which the FIXED attribute is specified in table T588MFPROPS, then the evaluation of key fields continues as
described in Diagram F, but omits all customer entries that are fixed in table T588MFPROPS.

Programming Your Infotype to Perform Implicit Checks


Procedure
Whenever you consider the business logic of an infotype, or the role that this logic will play in your landscape, you must consider the implicit checks that are
introduced in the Preliminary Analysis topic. The following topics, in contrast, describe the correct approaches for programming these implicit checks.

Performing Foreign Key Checks


Disabling Foreign Key Checks
Disabling Value Range Checks
Checking Radio Buttons and Checkboxes
Changing the Keys for HR Master Data (PSKEY) Field During Checks
Implementing Mutually Dependent Fields
Performing Subtype Checks
Calling Function Modules
Reading the Country Grouping (MOLGA) Field
Reading Infotypes
Reading Customizing Tables with Existing Specialized Classes
Creating New Specialized Classes to Read Customizing Tables

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

Page 37 of 75

Reading Features
Replacing Fields NSELC and IOPER (For Infotype Migration Only)
As you examine the business logic of your infotype to isolate implicit checks, simply refer to the relevant topic(s) for detailed information on programming them
correctly.

1.4.3.7.1 Performing Foreign Key Checks


Use
As delivered, the system can automatically perform foreign key checks, which are especially simple either for personnel areas/subareas (derived from table
T001P), personnel areas (derived from table T500P), and employee groups/subgroups (derived from table T503), or for the fields of your primary and secondary
records, since these fields are hard-coded.

The following three foreign key checks are delivered with the standard system.
t001p = cl_hr_t001p=>read( werks = p0001-werks btrtl = p0001-btrtl ).
CALL METHOD a_foreign_key_check->add_foreign_keys
EXPORTING
foreign_key_structure = t001p.
t500p = cl_hr_t500p=>read( persa = p0001-werks ).
CALL METHOD a_foreign_key_check->add_foreign_keys
EXPORTING
foreign_key_structure = t500p.
t503

= cl_hr_t503=>read( persg = p0001-persg

persk = p0001-persk ).

CALL METHOD a_foreign_key_check->add_foreign_keys


EXPORTING
foreign_key_structure = t503.

Procedure
However, if you need to perform checks in relation to other tables, then you must instruct the system accordingly; to this end, you re-define the
FOREIGN_KEY_ADDITIONAL_DATA methods and implement these methods within the method CHECK_FOREIGN_KEYS.

In the Capital Formation infotype (0010) in prior releases, a foreign key check is automatically performed for the Currency Key field (WAERS)
in relation to the Valid Country Currencies table (T500W), using the following source code:
T500W-MANDT = SYST-MANDT,
T500W-LAND1 = PSYST-LAND,
T500W-WAERS = P0010-WAERS.
If you wish to perform exactly the same checks in this release, then the following source code is required in method
FOREIGN_KEY_ADDITIONAL_DATA:
DATA p0010 TYPE p0010.
DATA psyst TYPE psyst.
DATA p0001 TYPE p0001.
DATA t500p TYPE t500p.
p0010 = pnnnn.
p0001 = p0001( tclas = tclas
pernr = p0010-pernr
begda = p0010-begda ).
t500p = cl_hr_t500p=>read( persa = p0001-werks ).
psyst-land = t500p-land1.
CALL METHOD a_foreign_key_check->add_foreign_keys
EXPORTING
foreign_key_structure = psyst.
This source code instructs the system to check the Country Key field (LAND1) in structure PSYST rather than, as in prior releases, structure PSYST itself. No
explicit instructions are required in this release to check the HR Master Record for the Capital Formation infotype (structure P0010) or the Valid Country
Currencies table (T500W), since the system now does so automatically. Structure SYST also requires no explicit check, since the system can evaluate this
structure without external input. In essence, you need only provide the structure(s) that are required for the check, not the contents of the corresponding table(s).

1.4.3.7.2 Disabling Foreign Key Checks


Use
This topic discusses approaches for disabling foreign key checks in your infotype.

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

Page 38 of 75

Procedure
If you wished to remove all foreign key checks simultaneously, you could theoretically redefine method CHECK_FOREIGN_KEYS with an empty implementation. In
practice, however, only some foreign checks require exclusion. Redefining method FOREIGN_KEY_EXCLUDED_FIELDS, which is designed to return the names
of the fields that are to be excluded from foreign key checks, is thus the most efficient manner of disabling, when needed, a subset of foreign checks.

Suppose you wish to exclude fields P0002-BEGDA and P0106-ENDDA from foreign key checks for the Family Member/Dependents infotype
(0021). Also, suppose PERNR is to be excluded from both records. Under these circumstances, you could insert the following source code in
method FOREIGN_KEY_EXCLUDED_FIELDS.
IF PRIMARY_FIELDS = TRUE.
APPEND 'BEGDA' TO EXCLUDED_FIELDS.
ELSE.
APPEND 'ENDDA' TO EXCLUDED_FIELDS.
ENDIF.
APPEND 'PERNR' TO EXCLUDED_FIELDS.

Disabling Value Range Checks


Use
By default, value range checks are active, and the system compares value ranges with Data Dictionary domain values in exactly the same manner that it
performs foreign key checks.

Procedure
Consequently, redefining method FOREIGN_KEY_EXCLUDED_FIELDS is also the most efficient manner of disabling value range checks, when required.

Checking Radio Buttons and Checkboxes


Use
Radio buttons and checkboxes constitute implicit checks that are performed by the screen. Because the business logic cannot derive these implicit checks from
the Data Dictionary, customers are responsible for implementing them, when required, on their own.

Procedure
The simplest approach for implementing radio buttons and checkboxes is to employ a domain with suitable values. Alternatively, a corresponding foreign key
relationship can be established.

Changing the Keys for HR Master Data (PSKEY) Field During


Checks
Use
Under certain circumstances, you may want your infotype to change the Keys for HR Master Data (PSKEY) field upon performing its checks. Although it is
technically possible to do so, two constraints apply to this function.

Prerequisites
Under the first constraint, it is not permissible to change either the Infotype (INFTY) or the Standard Selections for HR Master Data Reporting (PERNR) fields.
Under the second constraint, any changes thus performed must adhere to the revised framework that exists in this release for creating infotypes; specifically, any
changes must comply with the following implicit checks, all of which are enforced in the standard system within method ASSERT_CLEAN_DATA.

Technical field contents must be fulfilled; for example, numeric fields may only contain numbers.
The subtype at hand must be permissible for the country grouping assigned to the personnel number.
The start date must precede the end date.
The entry in the Name of subtype (NAMST) field must be valid.
Depending upon the entry in the Maintenance permitted after leaving (NAUST) field in the Infotypes: Customer-Specific Settings table (T582A), the system
may not permit the record to be maintained in inactive periods.
For time constraints 1, 2, and 3, it is not permitted to create records that precede the date of birth.

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

Page 39 of 75

Procedure
Because they are implicit, all of the checks summarized above are processed before all infotype-specific checks. Therefore, if any condition established by these
checks is violated, the system considers the corresponding discrepancies to arise from the business logic, rather than the user. For this reason, when any of
these checks is violated, the system issues an exception, rather than an error message.

Example
Suppose your infotype features a new, specific date field of its own, with the technical name MYINFTYDATE, which is mapped to the Start Date and End Date
fields (BEGDA and ENDDA, respectively). Because the latter fields do not appear on the infotype screen, and because the MYINFTYDATE field does, the only
date that any user can enter is in that field. Now suppose that the user enters a date that precedes the date of birth. Because the Start Date and End Date fields
are hidden, these fields will not be processed, and the error initially will not be detected, because the infotypes business logic populates BEGDA and ENDDA
with MYINFTYDATE. However, upon processing the business logic, the system would determine that the start date is too low, then issue a corresponding
exception, which would result in a short dump. (The system cannot issue an error message in this case, because it can only refer to BEGDA, rather than
MYINFTYDATE.)
To prevent the system from issuing the exception in this example, the business logic of your infotype should first check the MYINFTYDATE field entry in relation
to the date of birth, and only then populate the Start Date field with the user entry. This approach is easily implemented by calling method COMPUTE_GBDAT.
With this method in place, your infotype can easily issue an error message for example, The specified entry precedes the date of birth.

Implementing Mutually Dependent Fields


Use
Suppose your infotype features two fields for example, a value field and a percentage field that are mutually dependent, meaning that any change to the
percentage field should result in a corresponding change in the value field, and vice versa. In the event that both fields are changed, one of the two fields in this
example, the value field must predominate, such that the change in value will override the change in percentage, and a new percentage will be calculated in
proportion to the changed value.

Procedure
The most expedient manner to implement mutual field dependency in your business logic is to instruct the system to erase the percentage field entry when a
value is entered, and conversely, to erase the value field entry when a percentage is entered, thereby removing the dependency from the display. Aside from
optional screen elements to suggest that the fields are mutually dependent, this approach abstains from explicit business logic on the user interface.
With this approach, the business logic will evaluate which of the fields is initial. If only one field is initial, then the business logic will derive its entry from the other
field. If neither field is initial, or if both fields are initial, then the screen logic will employ the predominant field (in this example, the value) to calculate the entry for
the other field (in this example, the percentage). Once the corresponding business logic is processed and the mutually dependent fields are again consistent, the
system will update the display accordingly.

The approach described above is equally valid for any number of mutually dependent fields.

1.4.3.7.7 Performing Subtype Checks


Procedure
As delivered, the system supports generic subtype checks, but cannot determine all of the applications that pertain to a particular infotype. For this reason,
subtype checks are performed by means of the Business Add-In (BAdI) HRPAD_SUBTY_CHECK. A number of standard implementations are delivered with this
BAdI, the most useful of these being implementations CHECK_BY_T512Z, CHECK_BY_T531 and CHECK_BY_T591A. If your infotype requires subtype checks
in relation to other tables, you may also create new implementations. To this end, you may refer to and copy standard implementation
CHECK_BY_T591A_CHAR1 which checks the first character of the Subtype (SUBTY) field in relation to the Subtype Characteristics table (T591A) then
modify the copy to suit your requirements.

If foreign key checks and Business Add-In HRPAD_SUBTY_CHECK are simultaneously active, then the system may issue inconsistent error
messages. If you do choose to perform subtype checks by means of this BAdI, it is therefore vital that you disable foreign key checks for your
subtype fields.

1.4.3.7.8 Calling Function Modules


Procedure
The action of calling function modules may simultaneously cause the system to issue corresponding messages. If such messages are issued via the MESSAGE
RAISING command, then no additional action is necessary. However, if such messages are issued via the MESSAGE command, then you must ensure that the
system does not bypass them; to this end you must isolate such messages and re-map them either into genuine exceptions or into interface
IF_HRPA_MESSAGE_HANDLER, which is introduced in the topic Performing Message Handling.

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

Page 40 of 75

Example
If you wish to re-map function module messages into interface IF_HRPA_MESSAGE_HANDLER, then you may employ the following business logic.
CALL FUNCTION
. . .
EXCEPTIONS
exception1

= 1

exception2

= 2

error_message = 3
others

= 4.

IF sy-subrc = 3.
MOVE-CORRESPONDING sy TO message.
CALL METHOD message_handler->add_message
EXPORTING
message

= msg

field_list = field_list
cause

= if_hrpa_message_handler=>infotype_specific.

is_ok = false.
ENDIF.

Reading the Country Grouping (MOLGA) Field


Procedure
The following abbreviated method call provides an example that you can use to read the Country Grouping (MOLGA) field.

pme04-molga = molga( tclas = tclas


pernr = l_pskey-pernr
begda = l_pskey-begda ).
If no country grouping can be determined, then SPACE will return.

1.4.3.7.10 Reading Infotypes


Use
For infotypes that must be read frequently for example, the Organizational Assignment and Payroll Status infotypes (0001 and 0003, respectively) the
standard system provides corresponding read methods for example, P0001 and P0003.

Read method P0001 is called in the following manner.


p0001 = p0001( tclas = tclas
pernr = pernr
begda = begda ).

Procedure
If you plan to create a new infotype, and if your infotype will require data from other infotypes, we recommend that you implement the following business logic.
CALL METHOD a_read_infotype->read_single
EXPORTING
tclas

= tclas

pernr

= pernr

infty

= '0003'

subty

= space

objps

= space

sprps

= if_hrpa_read_infotype=>unlocked

begda

= low_date

endda
mode

= high_date
= if_hrpa_read_infotype=>last_intersecting_record

no_auth_check = true
IMPORTING
pnnnn

= p0003

data_exists

= data_exists.

The above business logic enables your infotype to obtain multiple records from the corresponding infotype to be read. By means of the method READ_SINGLE,
this business logic also allows your infotype to read cost assignment and other secondary data. If you would like to implement the method READ_SINGLE in your
infotype, review interface IF_HRPA_READ_INFOTYPE.

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

Page 41 of 75

Never substitute the method READ_SINGLE with function module HR_READ_INFOTYPE, nor with an external perform into subroutine pool
SAPFP50P.

Reading Customizing Tables with Existing Specialized Classes


Use
For many Customizing tables, standard specialized classes are delivered. These classes enable standard business logic, when required, to read the
corresponding tables; moreover, they facilitate processing by offering a central buffering location, as well as return parameters. Wherever such standard classes
are delivered, they always observe the naming convention CL_HR_<tablename>.

As illustrated below (and in a previous topic, Performing Foreign Key Checks), the standard system automatically performs foreign key checks by
using classes CL_HR_T001P, CL_HR_T500P and CL_HR_T503 to read the Personnel Area/Subarea table (T001P), Personnel Areas table
(T500P) and Employee Group/Subgroup table (T503), respectively.
t001p = cl_hr_t001p=>read( werks = p0001-werks btrtl = p0001-btrtl ).
CALL METHOD a_foreign_key_check->add_foreign_keys
EXPORTING
foreign_key_structure = t001p.
t500p = cl_hr_t500p=>read( persa = p0001-werks ).
CALL METHOD a_foreign_key_check->add_foreign_keys
EXPORTING
foreign_key_structure = t500p.
t503

= cl_hr_t503=>read( persg = p0001-persg

persk = p0001-persk ).

CALL METHOD a_foreign_key_check->add_foreign_keys


EXPORTING
foreign_key_structure = t503.

Procedure
In the event that no standard specialized class exists for a Customizing table that your infotype must read, you may create a new class for this purpose, as
described in the following topic.

Creating New Specialized Classes to Read Customizing Tables


Use
Although standard specialized classes are delivered for many Customizing tables, other Customizing tables exist for which no such classes are delivered. If your
infotype must nonetheless read a Customizing table for which no standard specialized class is delivered, then you may employ a suitable function module for this
purpose, provided that such a function module already exists.

If you do choose to employ an existing function module to read Customizing tables, make certain that any message statements within it are remapped either into genuine exceptions or into interface IF_HRPA_MESSAGE_HANDLER, which is introduced in the topic Performing Message
Handling.
For additional guidelines on calling function modules, consult the corresponding topic.

Procedure
If no suitable function module exists, you may create a new class for this purpose by copying an existing specialized class, then modifying the copy to suit your
requirements. If you choose to pursue this route, we recommend that you use standard class CL_HR_T582A or CL_HR_T582V as a template, for reference.
Furthermore, as you modify your copy of either standard class to suit your requirements, we recommend that you adhere to the following guidelines.
When creating a new specialized class to read Customizing tables, always observe the naming convention CL_HR_<tablename>. For example, if your new
class is to read the Pay Scale Groups table (T510U), then name it CL_HR_T510U.
Always implement the method READ for a full specified key.
If your new specialized class requires other methods to read data, always observe the naming convention READ_BY_<key field>. For example, if your
new class is to read the Plant key field (WERKS), then implement method READ_BY_WERKS.
Only perform buffering for single infotype records. Never buffer tables explicitly, for the application server already will buffer them by default. (Buffering full
tables may appear to increase the performance of your infotype, but in fact reduces overall system performance.)
Always clear return values or tables before subsequently filling them.
Avoid appending results to export parameters.
If the required data cannot be read, always set the output to be initial.
Never include in your new class methods that will issue messages or exceptions.
Always order by primary key any table output to be issued by your infotype.
Before saving your business logic, always choose Pretty Printer from the application toolbar.

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

Page 42 of 75

If you choose to create a new specialized class, carefully consider whether to create it in Core or Extension; tables that originally exist in Core
usually require specialized classes to be created in Core as well. In general, you should create the new class in the original (Core or Extension)
system of the corresponding table.

Reading Features
Use
Standard business logic, when required, uses class CL_HRPA_FEATURE to read features; the method that calls this class, shown in the example below, is much
shorter than the corresponding function modules.

CALL METHOD cl_hrpa_feature=>get_value


EXPORTING
feature

= 'IVWID'

struc_content = pme04
IMPORTING
return_value

= viekn.

Class CL_HRPA_FEATURE conforms with the exception handling principles described previously. However, under certain circumstances, exception handling
may not be appropriate for example, if you wish to explicitly ignore cases in which the feature cannot be read. In such cases, we recommend that you instead
employ the business logic shown in the following example, which does not conform with the exception handling principles cited here, but which does conform with
standard processing.

CALL METHOD cl_hrpa_feature=>get_value


EXPORTING
feature

= feature_name

struc_content = pme01
IMPORTING
return_value

= varky.

CATCH cx_hrpa_invalid_feature.
CLEAR varky.

Replacing Fields PSYST-NSELC and PSYST-IOPER (Migration


Only)
Use
This topic solely applies to the migration of infotypes from prior releases into this release.

The information presented in this topic exceeds the general knowledge that is required to migrate infotypes into 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.

Prerequisites
The replacement of the New selection of an infotype record and Infotype operation fields (NSELC and IOPER, respectively) solely concerns infotypes that must
be migrated into this release. If you do not need to migrate infotypes into this release, then disregard the following information.

Procedure
In prior releases, some infotypes evaluate in structure PSYST the New selection of an infotype record and Infotype operation fields, which are no longer used in
this release. As you migrate a particular infotype into this release, you must first determine why your infotype evaluates these fields in prior releases before you
attempt in this release to replace any business logic within your infotype that contains these fields.
If the system evaluates fields PSYST-NSELC or PSYST-IOPER in prior releases to distinguish among operations for insertion, modification and deletion, then you
can replace these fields in this release in a very simple manner, since this release offers a specific method for each corresponding operation.
In contrast, if the system evaluates these fields in prior releases to determine whether the record is newly created, then you can replace these fields in this
release with the method SPECIFIC_INITIAL_COMPUTATIONS.
In some cases, the system evaluates these fields in prior releases in order to present a one-time warning message. One-time warnings, however, are not
supported within standard business logic; any relevant warning message should be repeated in the business logic as often as necessary. If you nonetheless wish
to repress repeated warnings, then you must design the graphical user interface accordingly, and this processing must be performed centrally, rather than for
individual infotypes.

1.4.4 Writing Infotype Records


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

Page 43 of 75

Use
Some infotypes in your system may need to manipulate more data than the current record contains. Because the manner in which the system manipulates the
buffer in this release differs from that of prior releases, we recommend that you take a moment to examine how infotype records are written. To this end, consider
why your infotype needs to update other records. The goal of this analysis is to determine whether your infotype would truly require the corresponding updates to be
hard-coded.

To obtain an understanding of how infotype records are written in the system, we recommend that you review the Personal Data infotype (0002)
as an example.

Procedure
If sufficient conditions exist to restrict the updates of other records to dialog mode only, then you should by all means hard-code the corresponding updates but
not in the infotype business logic itself. For additional information, you may refer to the subsequent topics in this section, which are summarized below; each topic
addresses an aspect of managing infotypes that modify other infotype records within the system.

Background Information
Using Containers to Write Data
Reading Before Writing
Creating New Containers Before Writing
Modifying Contents of Containers
Deleting Existing Records
Inserting New Records
Modifying Existing Records
Using Pushbuttons
Declaring the Operations

The information presented in each of the subsequent topics 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 these topics for reference.

1.4.4.1 Background Information


The following topic provides additional background information to describe how infotype records are written.
If your class will not write data to the buffer, then no technical limitations exist to prevent it from inheriting the properties of the standard check class (or
superclass) CL_HRPA_INFOTYPE_NNNN, as described in the topic Creating Country-Specific Check Classes. However, if your class will indeed write data to
the buffer, then it must instead inherit the properties of the superclass CL_HRPA_INFTY_NNNN, as noted in the topic Creating Single Check Classes. This
technical limitation exists because classes that inherit their properties from superclass CL_HRPA_INFOTYPE_NNNN are required to run in conjunction with buffer
PS; however, only classes that inherit their properties from superclass CL_HRPA_INFTY_NNNNcan write to the actual buffer.

Check classes that inherit their properties from superclass CL_HRPA_INFOTYPE_NNNN and subsequently write data to the buffer are likely to
cause system short dumps.
Two routes are available for accessing the buffer either direct access, through which the system bypasses processing the business logic (including checks) of
the other infotype(s) to write data to the buffer, or indirect access, through which the system first processes the business logic (and checks) of the other
infotype(s), then writes data to the buffer.
Indirect access, however, may fail for several reasons, including the following:
If indirect access is used to process your own infotype, endless recursion may result. In this case, indirect access must be avoided.
If unacceptable input causes the checks of the other infotype(s) to fail, then indirect access may fail, too. Indirect access nonetheless can be applied in this
case, but the caller must be available to handle the situation.
If retrocalculation or authorization checks fail, then the other infotype(s) may not be written, and indirect access may fail. Indirect access can still be applied in
these cases, but the caller must be available to handle the situation.
Given the potential failures summarized above, if you choose to employ indirect access within your infotype, it is important to consider the appropriate response if
indirect access should fail. Simply issuing the error message(s) from another infotype, for example, is inappropriate, because such messages generally apply to
dialog users, rather than end users. (End users, in any event, cannot take note that updates have been performed without their knowledge.) Simply disabling
retrocalculation and authorization checks or refraining from the use of indirect access and thus bypassing the business logic (including checks) of all other
infotypes is also inappropriate in most cases. On balance, you are therefore advised to evaluate the IS_OK statement, then issue an appropriate message from
within your own infotype.

As you consider the appropriate message(s) to issue, remember to provide business logic with sufficient processing instructions for your own
infotype as well. In other words, if you cannot update the other infotype(s), you may wish to update your infotype just the same; in this case, you
would write the statement IS_OK = true and not issue error messages. Conversely, if you cannot update the other infotype(s) and do not wish to
update yours either, then you would write the statement IS_OK = false and create a suitable error message.

1.4.4.2 Using Containers to Write Data


Purpose
The system does not handle actual records to access the buffer and write data to it. For this purpose, the system instead always uses containers, which represent

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

Page 44 of 75

the abstraction of a record. In general, containers are seen within the system as instances of class CL_HRPA_INFOTYPE_CONTAINER. A container can hold any
or all of the following data:

Infotype records
Secondary infotype records, where infotype views are present
Cost assignment data
Infotype text data

In this release, infotypes generally must be processed by container IF_HRPA_INFOTYPE_CONTAINER. Some infotypes, however whether specialized
infotypes created in this release, or infotypes to be migrated from prior releases are processed by a different container, which will be appropriate under certain
limited circumstances. To determine the container that will process your infotype, you may review, if desired, the Classes for Determining Version IDs and
Infotype Containers table (T582ITVCLAS), which is introduced in a subsequent topic.

From this point forward, all examples of infotypes are assumed to be processed by container IF_HRPA_INFOTYPE_CONTAINER.

Process Flow
Containers are read on demand. Thus, in order to obtain access to data in another infotype (as a prerequisite for writing your data to the buffer), you must first
determine the corresponding container. It is not expedient, however, to read data from another infotype via interface IF_HRPA_READ_INFOTYPE and then to
create the container, as this approach is likely to result in data loss and is certain to impair performance.

Reading Before Writing


Process Flow
Containers are read via interface IF_HRPA_MASTERDATA_BUFFER; within class CL_HRPA_INFTY_NNNN, you can review attribute A_MASTERDATA_BUFFERto
this end. In most cases, it is appropriate to read data from the write buffer (with buffer_mode

= 'W').

The following business logic provides an example of direct buffer access.


DATA infotype_container_tab TYPE hrpad_infotype_container_tab.
CALL METHOD a_masterdata_buffer->read
EXPORTING
tclas

= tclas

pernr

= pernr

infty

= infty

subty

= subty

sprps

= sprps

begda

= begda

endda

= endda

buffer_mode

= 'W'

IMPORTING
container_tab = infotype_container_tab.
As this example demonstrates data that is read from the buffer directly, it would be fully compatible with data that is directly written to the buffer.
Consider, however, that the target infotype may already perform specific computations as data is read. Moreover, in the event that you wish to
subject the data to the checks of other infotypes, you may choose to write data to the buffer through the business logic of those infotypes. On
balance, in this example, you may prefer to access the buffer indirectly, rather than directly. If you do choose to access the buffer indirectly, you
may wish to disable authorization checks, and thereby ensure that data can be read through the business logic of the other infotypes.

The following business logic provides an example of indirect buffer access.


DATA infty_container_tab TYPE hrpad_infty_container_tab.
DATA message_list

TYPE REF TO cl_hrpa_message_list.

CREATE OBJECT message_list.


CALL METHOD business_logic->read
EXPORTING
tclas

= tclas

pernr

= pernr

infty

= infty

subty

= '*'

sprps

= '*'

begda

= begda

endda

= endda

no_auth_check

= true

message_handler = message_list
IMPORTING
container_tab

= infty_container_tab.

Note that this example does not issue messages through interface IF_HRPA_MESSAGE_HANDLER, but rather through a message list of its own.
Also note that this example requires an instance of the business logic; such instances are usually written as an attribute within method
GET_INSTANCE, which would be created within the constructor of your class, as illustrated below.
CALL METHOD cl_hrpa_masterdata_bl=>get_instance

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

Page 45 of 75

IMPORTING
masterdata_bl = a_masterdata_bl.
Ultimately, whether you choose to read data from the buffer directly or indirectly, you must typecast the required containers to class
CL_HRPA_INFOTYPE_CONTAINER.

Creating New Containers Before Writing


Procedure
If you wish to insert new records, then you must create completely new containers, which is done with one approach for direct access, and a different approach for
indirect access. For direct access, call the GET_INSTANCE method of the container class, which is maintained in the Classes for Determining Version IDs and
Infotype Containers table (T582ITVCLAS), which is introduced in a subsequent topic. For indirect access, call the GET_INSTANCE method of the business logic,
then typecast the container to class CL_HRPA_INFOTYPE_CONTAINER.
This latter approach features one disadvantage, namely that it already surrenders control the other infotype(s), in order to process data in advance, and you must
anticipate how the system will respond in the event that this advance processing fails. This disadvantage is offset by the advantage of increased flexibility, for if
the other infotype(s) were to use a container class that is more specific than CL_HRPA_INFOTYPE_CONTAINER, you would not have to adapt your infotype
accordingly.

1.4.4.5 Modifying Contents of Containers


Use
Upon creating or reading a container, your infotype generally will need to modify its contents. To this end, you must first ensure, via the MODIFY_KEY method, that
the container features the correct key unless you have recently created the container and you know that it already has that key.

Procedure
Once you are certain that the container features the correct key, use the following method(s) to populate the container with the corresponding data.

MODIFY_PRIMARY_RECORD

MODIFY_SECONDARY_RECORD

MODIFY_PREF

MODIFY_DATA

MODIFY_TEXT_TAB

The container will only process methods MODIFY_PRIMARY_RECORD, MODIFY_SECONDARY_RECORD and MODIFY_DATA if the key of the data
records agrees with the key reflected in the Keys for HR Master Data (PSKEY) field. If these entries do not match, then a short dump will occur.
However, a container will not lose text data (when present) if the key, primary record, or secondary record are changed.
Upon modifying the contents of the container, your infotype will encounter a new container; the system never alters the contents of the previous container. For this
reason, you do not need to avoid other references to the container, nor do you need to create copies of the container in an effort to protect the buffer.
Once modification is complete, a reference to interface IF_HRPA_INFOTYPE_CONTAINER is returned. In the unlikely event that you wish to perform additional
processing with the container, then you may wish to typecast it again to class CL_HRPA_INFOTYPE_CONTAINER.

In the event that your infotype is to process infotype views, remember to consider how it will process secondary data.

1.4.4.6 Deleting Existing Records


Procedure
Before your infotype may delete a record, it must first read the corresponding container, as described in the topic Reading Before Writing. Once the corresponding
container has been read, you may pursue one of three approaches to perform the deletion.
1. CALL METHOD a_masterdata_buffer->read
(Interface IF_HRPA_MASTERDATA_BUFFER->DELETE)
This approach will directly delete data from the buffer, but it will not process generic business logic for example, retrocalculation, time constraints, and so
on. Due to the nature of this approach, it is seldom applied to delete existing records.
With this approach, your infotype will not need to handle messages.
2. CALL METHOD a_generic_update->delete
(Interface IF_HRPA_GENERIC_UPDATE->DELETE)
This approach will delete the record. It will also process generic business logic for example, retrocalculation, time constraints, and so on. To avoid endless
recursion, this is the recommended approach for updating records of your own infotypes.
With this approach, your infotype will need to handle messages.
3. Interface IF_HRPA_MASTERDATA_BL->DELETE
This approach will delete the record and process the complete business logic both the generic checks and all infotype-specific checks for the container.
This is the recommended approach for deleting records of other infotypes.
With this approach, your infotype will need to handle messages.

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

Page 46 of 75

If you pursue the second or third approach named above, refrain from using interface IF_HRPA_MESSAGE_HANDLER, which is introduced in the topic Performing
Message Handling; it is more expedient to create your own instance (for example, of class CL_HRPA_MESSAGE_LIST), which will allow your infotype to evaluate
any messages that arose during the deletion of records.
Regardless of the approach you choose to pursue, you must always consider the appropriate response if the deletion should fail (for example, in response to
retrocalculation or authorization checks). But regardless of the response you choose to implement, a failed operation will never alter the buffer. In other words, no
matter what prevented the deletion from occurring, the buffer will remain in the same state as before the attempted deletion, since the system automatically rolls it
back if errors occur.

Exceptions of type CX_HRPA_VIOLATED_ASSERTION can arise with any of the three deletion approaches summarized here. Unless you have a
specific reason to do so, we recommend that you disregard such exceptions.

1.4.4.7 Inserting New Records


Procedure
New records are inserted in a manner similar to the one in which existing records are deleted, with two important differences: your infotype does not need to read
the container to be inserted, and the system employs methods A_MASTERDATA_BUFFER->INSERT and A_GENERIC_UPDATE->INSERT.

1.4.4.8 Modifying Existing Records


Procedure
Existing records are modified first by reading the corresponding container (as described in the topic Reading Before Writing) and then by modifying the contents of
the containers in the desired manner.
If you wish to update the buffer directly, as illustrated in the first approach for deletion in the topic Deleting Existing Records, then you may not change the key; the
buffer essentially reflects the current state of the database, rendering key changes impossible.
Otherwise, you may change the key of the containers, if desired. However, in this case, you must issue both the old and the new container, since the system has
no other means to ascertain that a change has occurred.

The following example demonstrates business logic that could be applied to modify the records of another infotype. This example assumes that
attribute A_MASTERDATA_BL was already populated (from class CL_HRPA_MASTERDATA_FACTORY) while the system processed the
constructor method. This example further assumes that the corresponding business logic is run in method SPECIFIC_MODIFY_COMPUTATIONS
of infotype 9999, and that infotype 8888 is to be updated.
The infotypes named in this example 8888 and 9999 do not exist in the standard system; if you choose to apply this example, then modify
the infotype numbers and delete the comments.
METHOD specific_modify_computations.
FIELD-SYMBOLS <p8888> TYPE p8888.
DATA p9999

TYPE p9999.

DATA container_tab
DATA container

TYPE hrpad_infty_container_tab.

TYPE REF TO if_hrpa_infty_container.

DATA it8888_container TYPE REF TO cl_hrpa_infotype_container.


DATA p8888_ref

TYPE REF TO data.

DATA message_list
DATA l_is_ok

TYPE REF TO cl_hrpa_message_list.

TYPE boole_d.

is_ok = true.
p9999 = pnnnn.
* Checks or special calculations for p9999 would follow below
* When these are complete, p9999 is to be filled with new values
* Infotype 9999 will be modified even if Infotype 8888 cannot be
pnnnn = p9999.
* The following check is to optimize performance
CHECK is_ok = true.
CREATE OBJECT message_list.
* At this point, containers are read
CALL METHOD a_masterdata_bl->read
EXPORTING
tclas

= tclas

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

Page 47 of 75

pernr

= p9999-pernr

infty

= '8888'

subty

= p9999-subty

sprps

= p9999-sprps

begda
endda

= p9999-begda
= p9999-endda

no_auth_check

= no_auth_check

message_handler = message_list
IMPORTING
container_tab
is_ok

= container_tab

= l_is_ok.

* This example assumes only some records will be modified


LOOP AT container_tab INTO container
WHERE
table_line->a_pskey-begda = p9999-begda AND
table_line->a_pskey-endda = p9999-endda AND
table_line->a_pskey-objps = p9999-objps AND
table_line->a_pskey-seqnr = p9999-seqnr.
* At this point, data is extracted from the container
it8888_container ?= container.
CALL METHOD it8888_container->primary_record_ref
IMPORTING
pnnnn_ref = p8888_ref.
ASSIGN p8888_ref->* TO <p8888>.
* A sample field is modified
<p8888>-foo = p9999-bar.
* The container itself is modified
container ?= it8888_container->modify_primary_record( <p8888> ).
* Clearing the message list, in this example, is not required
* However, if you wish to evaluate it later, it is indispensable
CREATE OBJECT message_list.
* Process complete business logic of target infotype
CALL METHOD a_masterdata_bl->modify
EXPORTING
old_container
massn
massg

= it8888_container

= massn
= massg

update_mode

= update_mode

no_auth_check

= no_auth_check

message_handler = message_list
IMPORTING
is_ok

= l_is_ok

CHANGING
container

= container.

For this example, messages and l_is_ok are ignored

Actual infotypes, however, may require error handling here

Also, note that the container may be changed

The container now reflects what the business logic of

the other infotype has instructed it to send to the UI


ENDLOOP.

ENDMETHOD.

No methods are available in the standard system to perform delimitations or partial deletions, because method
SPECIFIC_MODIFY_COMPUTATIONS permits key changes to occur. Consequently, instances of this method are only to be applied when key
changes will not result in errors.

1.4.4.9 Using Pushbuttons


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

Page 48 of 75

Use
Certain infotypes feature pushbuttons, which enable them to perform additional functionality for example, to populate fields with values, or to execute external
reports. Broadly speaking, any pushbutton enables an infotype to perform one of two functions, namely:
1. Either to perform an action that depends on the user interface for example, to navigate elsewhere.
2. Or to call business logic that does not depend on the user interface for example, to compute values.

Procedure
If you wish to perform the first type of function, then you must apply a corresponding user interface and provide the source code there yourself for example, by
extending a model access class. To this end, you may wish to review the user interface programming guidelines that apply to Personnel Administration infotypes
created in this (or any subsequent) release.
Generic support is available for the second type of function; to avail yourself of this support and to introduce such functions in your infotype, perform the following
procedure.
1. Modify the Infotype Operations view (V_T582ITOPER) to create a suitable infotype operation.
2. Modify the Infotype Operations view to declare the infotypes, subtypes and country-specific versions for which the infotype operation may be implemented.
In other words, if your infotype is able to process a certain operation, then you must modify this separate view (V_T582ITVOPER) to declare that the operation
is indeed valid for that infotype.
3. Modify method SPECIFIC_ACTION_COMPUTATIONS in the applicable infotype-specific check class(es) to provide source code with suitable handling
instructions. To implement the operation, we recommend that you apply a CASE operation statement to distribute processing among the various
operations. We also recommend that you use a separate method for each value of the case operation.

1.4.4.9.1 Declaring the Operations


Prerequisites
The contents of the Infotype Operations view (V_T582ITOPER) are required to conform with a global naming convention
[nnnn]_[vv]_[ssss]_operation_name which ensures that separate operations will not accidentally overlap within the same infotype(s). Therefore,
whenever you declare an operation in this view, you must follow this convention, where:
[nnnn]
signifies the infotype number,
[vv]
signifies the infotype version, as defined in the Entity Table for Infotype Versions (T582ITVERS)
[ssss]
signifies the subtype (where required), and
operation_name
provides a meaningful description of the operation at hand.

Procedure
In order to declare your operation, you must also declare an input and output structure for which valid Data Dictionary entries exist. If you fail to declare these
structures, then the operation will only process one infotype container, and it may alter the contents of this container in an unforeseeable manner.

Assigning Check Classes to Containers and Infotype Versions


Process Flow
As new infotypes are created by means of the Create Infotype transaction (transaction code PM01), the system automatically generates entries, which are
required for subsequent processing, in a multitude of views. No additional action is required for users to generate the requisite entries in any view. Nonetheless,
users may wish to consider this topic for additional background information. This topic discusses the entries of the views Classes for Determining Version IDs and
Infotype Containers (V_T582ITVCLAS) and Verification Class for a Version Flag (V_T582ITVCHCK), in which the check classes of infotypes are assigned to
containers and infotype versions, respectively. Both views were introduced to the standard system with the revised framework for creating infotypes.
In the first view, V_T582ITVCLAS, a single entry is created for each infotype to assign the corresponding check class to a container. For the majority of infotype
entries stored in view V_T582ITVCLAS, the appropriate container is CL_HRPA_INFOTYPE_CONTAINER, although certain infotypes are not assigned to this
container. Without exception, the system stores one single entry in view V_T582ITVCLAS for every valid infotype within the system. In other words, if the number
of valid standard and customer-specific infotypes in your system is 501, then the system will store exactly 501 entries in view V_T582ITVCLAS.
In the second view, V_T582ITVCHCK, one entry is created for each valid version of an infotype whose check class differs from the check class that is specified
for the corresponding infotype in view V_T582ITVCLAS. Each entry thus created is used to assign the corresponding check class to an infotype version.

View V_T582ITVCHCK does not use the Country Grouping (MOLGA) field to determine the version, but rather the ID for Infotype Versions
(ITVERS) field. Although the corresponding valid entries for each field are often similar, they are not identical. For example, in either field, the
entries 06 and 10 denote France and the United States, respectively. However, in the ID for Infotype Versions (ITVERS) field, the entries FP and
UP which do not exist in the Country Grouping (MOLGA) field respectively denote the Public Sector versions of France and the United
States.
Should you need to review the entries for a particular infotype that have automatically been generated in the appropriate view(s), remember the following rules of
thumb:

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

Page 49 of 75

1. If only an international version of an infotype exists, then view V_T582ITVCLAS will contain a single entry for that infotype, while no entry will exist for that
infotype in view V_T582ITVCHCK.
2. If multiple versions of an infotype exist, but if one of these versions uses the same check class as the international version, then no entry will exist for that
version in view V_T582ITVCHCK.
For any new entries that you cause to be generated in view V_T582ITVCLAS, we strongly recommend that you do not subsequently change the default value
(Permitted in All Circumstances) within the Permissibility of Infotype for New Framework (NITF_ADM) field. By accepting this value, the corresponding
infotype will be identified to comply with the revised framework that exists in this release for creating infotypes. In contrast, if customer-specific infotypes exist in
your system from prior releases, and if you for example neither wish to migrate these infotypes to comply with, nor permit them to be processed by, the revised
framework, then you may instead specify the value Not Permitted here.

Any entries that you cause to be generated in a Customizing client in views V_T582ITVCLAS or V_T582ITVCHCK must be transported manually.

Example
The following examples serve to illustrate the presence (or absence) of entries in each view for the corresponding infotype.
In the first view, V_T582ITVCLAS, a single entry exists for the Personal Data infotype (0002), while one entry exists for each of various versions of that infotype
altogether dozens of entries in view V_T582ITVCHCK.
For the External Transfers infotype (0011), which (as introduced in the topic Creating Country-Specific Check Classes) has five country versions, a single entry
also exists in view V_T582ITVCLAS. In contrast, in view V_T582ITVCHCK, four entries exist for that infotype one each for the country versions of Switzerland,
Norway, New Zealand and South Africa, respectively. (No entry exists in view V_T582ITVCHCK for the Belgian version, because this version uses the same
check class as the international version.)
In contrast, for the Communication infotype (0105), for which only an international version exists, view V_T582ITVCLAS contains a single entry, while view
V_T582ITVCHCK contains no entry.

UI Programming Guidelines for Infotypes


This section discusses important guidelines for programming user interfaces 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 program the corresponding user interfaces.

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 user interface was not
de-coupled from the corresponding business logic. 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 user interface of any infotype is completely de-coupled from the corresponding business logic.
To enhance master data consistency and improve performance, you may therefore wish to migrate into this release existing infotypes from
Release 4.6C and below that is, adjust the user interfaces of the infotypes that were created in the previous framework to make them compatible
with the revised framework for the de-coupled environment.

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,
the revised framework.

HR Administrative Services introduced in the standard system after or in tandem with

In summary, this section discusses the user interface programming guidelines that apply to the creation of new Personnel Administration infotypes, whether
standard or customer-specific, in this (or any subsequent) release.
To this end, the remainder of this section is divided into the following topics:
Programming User Interfaces in the De-Coupled Framework
Screen Structures
Infotype Screen Structures (Type MAIN)
Repeat Field Screen Structures (Type LINE)
Conversion Classes
Initialization (Method INITIALIZE)
Output Conversion (Method OUTPUT_CONVERSION)
Input Conversion (Method INPUT_CONVERSION)
Input Help Values (Method FILL_HELP_VALUES)
Repeat Fields: Output Conversion (Method OUTPUT_TABLE_CONVERSION)
Repeat Fields: Input Conversion (Method INPUT_TABLE_CONVERSION)
Automatically Retrieving Descriptive Texts
Reusing International Conversion Classes
Assigning Conversion Classes to Screen Structures
If you wish to follow the revised framework and create new Personnel Administration infotypes in this release, then we recommend that you observe the user
interface programming guidelines set forth below, along with the corresponding Business Logic Guidelines for Creating and Migrating Infotypes.

Programming User Interfaces in the De-Coupled Framework


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

Page 50 of 75

The de-coupled framework primarily consists of two areas one area that relates to the back-end business logic of an infotype, and a second area that enables
the infotype to be displayed, and if necessary edited, in the user interface.
The business logic area of the de-coupled framework covers a number of requirements, including:

checking the consistency of infotype data,


handling time constraints,
triggering retrocalculations (where necessary), and
storing infotype data on the database.

However, if the infotype is to be displayed on the screen, and if the user should be able to maintain it, then additional requirements arise. The user interface area
of the de-coupled framework covers these requirements, including:
the display of specific values via input help.
the display of additional, read-only information. (For example, you may wish to display the age of an employee derived from his or her date of birth.)
the display of descriptive texts for key values stored in the infotype. {For example, when the employee gender is displayed as Male or Female instead of (or
in addition to) the technical values of 1 and 2 that are ultimately stored in the database.}
dividing the value of one infotype field into several fields shown on the user interface, or vice versa.
performing any kind of calculation that converts values entered on the user interface to values that are to be stored in the infotype, or vice versa.
setting metadata based on values entered for example, mandatory, read-only, and so on.
In short, the de-coupled framework requires programmers to consider the business logic of an infotype separately from its user interface. The division of (backend) business logic from (front-end) user interfaces makes each area independent and therefore ultimately simplifies the manner in which the user interface is
presented by various applications.

Prerequisites
In the de-coupled framework for creating infotypes, the existence of de-coupled business logic is a prerequisite for the creation of de-coupled user interfaces.
Thus, if you wish to create a new Personnel Administration infotype in the de-coupled framework and program its user interface accordingly, you are required to
have created the corresponding business logic already.

To this end, we recommend that you consult the Business Logic Guidelines for Creating and Migrating Infotypes, which describe aspects of this
process in detail.

Process Flow
In the de-coupled framework, for any infotype that is to be displayed (or edited) in the user interface, the following entities must exist:
A Data Dictionary structure (known as a screen structure), which contains all of the infotype fields that should be part of the user interface.
An ABAP-OO class (known as a conversion class), which defines the conversion of the infotype fields from their representation in the back end to their
representation on the user interface.
An entry in the Assignment UI Structures and UI Conversion Classes view (V_T588UICONVCLAS), which defines the conversion class that the system will
apply to the corresponding screen structure, and which thereby governs the assignment of conversion classes to screen structures.
As stated above, the screen structure contains all of the infotype fields that should be part of the user interface. The fields defined therein include editable fields,
read-only fields, and descriptive texts. Everything that is related to the infotype and that should be presented on its user interface requires the explicit definition of a
corresponding component within the screen structure.
To support the country-specific requirements of Personnel Administration infotypes, screen structures themselves are defined to be either international or
country-specific. If a screen structure is defined to be international, then that screen structure will only contain fields that are country-independent. In contrast, if
a screen structure is defined to be country-specific, then it will contain fields that are valid for the country version in question. For additional information, consult the
Screen Structures topic.
The conversion class converts infotype data from the back end for representation on the user interface. Conversion classes therefore convert data that is stored
for the corresponding Pnnnn structure into data for the screen structure, and vice versa. Output conversion denotes the conversion of Pnnnn structure data
into screen structure data, while the conversion of screen structure data into Pnnnn structure data is called input conversion.
In addition to converting data, conversion classes also provide field attribute information, as well as input help, for the user interface fields. To this end,
conversion classes not only specify whether a particular field is mandatory, read-only or hidden, but also furnish the supported field values to populate drop-down
list boxes or input help on the user interface. For additional information, refer to the Conversion Classes topic.
As stated above, an entry in the Assignment UI Structures and UI Conversion Classes view (V_T588UICONVCLAS) is required to establish the link between a
screen structure and the corresponding conversion class. The entries in this view enable the de-coupled framework to call the correct conversion class when
processing a particular screen structure. For additional information, review the Assigning Conversion Classes to Screen Structures topic.

In the event that the infotype in question lacks specific user interface requirements, then it is not necessary to assign a dedicated conversion
class to it. In such cases, the default conversion class CL_HRPA_UI_CONVERT_BASIC can be assigned instead, as described in the topic
referenced immediately above. For a description of this default conversion class, consult the topic Conversion Classes.
To simplify the programming of user interfaces in the de-coupled framework, the standard system features many types of generic functionality, which users can
activate by performing the corresponding Customizing. This functionality includes a generic approach to provide input help values, the automatic retrieval of
descriptive texts for fields that hold key values and the automatic handling of repeat fields. For additional information on any aspect of this functionality, choose the
corresponding link.
Finally, when you have finished creating a new Personnel Administration infotype in the de-coupled framework, you can execute the Test Interface for ITF
Conversion Classes transaction (transaction code PUIT_UI) to ensure that the user interface of your infotype functions properly. For additional information on this
test tool, review the documentation provided with it.
In summary, the process of displaying and editing an infotype in the user interface consists of the following phases.
Output Conversion
During output conversion, back-end data is converted into screen structure data, which in turn is displayed and, if necessary, edited on the user interface.
If the default conversion class CL_HRPA_UI_CONVERT_BASIC is used, all user interface fields that bear the same technical names in the back end
are automatically filled.
Assuming that the corresponding Customizing has been performed, generic functionality to provide input help values is applied; input help automatically

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

Page 51 of 75

becomes available for all fields.


Assuming that the corresponding Customizing has been performed, the automatic retrieval of descriptive texts is applied; descriptive texts for fields that
hold key values are automatically displayed.
Based on the metadata defined for the back-end fields, field attribute information (for example, mandatory, read-only, and so on) is automatically provided.
If additional processing is required for the infotype in question, then the default conversion class cannot be applied. Rather, a dedicated conversion class
must be created and assigned to the infotype screen structure in view V_T588UICONVCLAS. In practice, the OUTPUT_CONVERSION method of the
corresponding conversion class therefore must be implemented.
Input Conversion
Screen structure data which has been displayed (and, if necessary, edited) on the user interface is converted into back-end data for subsequent
database storage.
If the default conversion class CL_HRPA_UI_CONVERT_BASIC is used, all back-end fields that bear the same technical names on the user interface
are automatically filled.
No action is required for input help values; these values are only relevant when the infotype is maintained in the user interface.
No action is required for descriptive texts; these texts are read-only by default, and therefore require no conversion for storage in the database.
No action is required for field attribute information, as this information is already defined in the database.
If additional processing is required for the infotype in question, then the default conversion class cannot be applied. Rather, a dedicated conversion class
must be created and assigned to the infotype screen structure in view V_T588UICONVCLAS. In practice, the INPUT_CONVERSION method of the
corresponding conversion class therefore must be implemented.
For infotypes that contain repeat fields, a generic approach is also provided; for additional information, see Repeat Field Screen Structures (Type LINE). If the
generic approach for repeat fields is insufficient, then a dedicated conversion class must be created and assigned to the infotype screen structure in view
V_T588UICONVCLAS, and the OUTPUT_TABLE_CONVERSION and INPUT_TABLE_CONVERSION methods of that conversion class must be implemented.

Example
Suppose that you wish to create the user interface for infotype 9001, an international customer-specific infotype that is to be processed in the de-coupled
framework and whose structure (P9001) consists of the fields shown below.

Subsequent examples in the present guidelines may refer to the customer-specific infotype (9001) introduced below.
P9001 Structure Fields
Field Name

Short Description

NACHN

Last Name

VORNA

First Name

GBDAT

Date of Birth

GBPAS

Date of Birth According to Passport

NCHMC

Last Name (Field for Search Help)

ANRED

Form-of-Address Key

Because Infotype 9001 is to be processed in the de-coupled framework, a corresponding screen structure must be created. It therefore is incumbent on the
programmer to decide which fields are to become part of the user interface and will consequently require representation within the screen structure.
Field NCHMC is considered to be strictly technical; therefore, it is not needed in the user interface, and will not require corresponding representation within the
screen structure.
Field GBPAS is considered to be relevant for certain countries, but not for others. Because the screen structure to be created corresponds to an international
(rather than country-specific) infotype, this field also is not needed in the user interface, and also will not require screen structure representation.
All other fields NACHN, VORNA, GBDAT and ANRED are considered to be relevant for the user interface. Therefore, these fields require corresponding
representation in the screen structure, where they are defined, to facilitate processing, with the same technical names.
Using the same technical names provides a distinct advantage, because it enables the programmer to use the default conversion class
CL_HRPA_UI_CONVERT_BASIC if desired. This class simply uses a MOVE-CORRESPONDING statement to pass the field values to the screen structure.
(Even if a dedicated conversion class is required, the same statement can be used to simplify programming.) Moreover, using the same technical names
ensures that the relationship between infotype fields and screen structure fields remain transparent.
In addition to the fields from structure P9001, suppose that the following fields are required on the user interface:

FULL_NAME

This field should provide a concatenation of the first and last name of the employee. With this field, users should be able to enter the full employee name in a
single user interface field.
AGE

This field should display the current age of the employee.


FORM_OF_ADDRESS_TEXT
This field should display the descriptive text for field ANRED ( Form-of-Address Key ). In other words, in addition to the key (numerical) values that are stored
in field ANRED, the corresponding descriptive text (Mr., Ms., Dr., and so on) should be displayed on the user interface.

In summary, the screen structure should contain the following fields:


Screen Structure Fields for Infotype 9001
Field Name

Short Description

NACHN

Last Name

VORNA

First Name

FULL_NAME

First and Last Name in One Line

GBDAT

Date of Birth

AGE

Employee Age

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

Page 52 of 75

ANRED

Form-of-Address Key

FORM_OF_ADDRESS_TEXT

Form-of-Address Description

Because of the screen structure fields FULL_NAME and AGE, specific requirements exist for this infotype, and the default conversion class
CL_HRPA_UI_CONVERT_BASIC cannot be used. Therefore, a dedicated conversion class for this screen structure is required, and the programmer must
implement methods OUTPUT_CONVERSION and INPUT_CONVERSION therein. However, for field FORM_OF_ADDRESS_TEXT, the automatic retrieval of
descriptive texts can be applied, meaning that only the appropriate Customizing is required, rather than dedicated source code.

1.5.2 Screen Structures


Definition
As discussed in the topic Programming User Interfaces in the De-Coupled Framework, screen structures are Data Dictionary structures that contain all of the
infotype fields that should be part of the user interface. Therefore, the sole purpose of a screen structure is to display on the user interface data that is derived
from, but not stored in, the corresponding database.
Perhaps the most important attribute of any screen structure is determined in its technical name, which reflects whether the screen structure is either international
(with entry XX) or country-specific (with any entry other than XX). The majority of screen structures are country-specific, and country-specific screen structures
only contain the fields that are valid for the country version in question for example, FR for France, UP for the United States Public Sector and US for the United
States. International screen structures in turn contain fields that are suitable for display in any country version.
A second fundamental attribute of any screen structure is whether it is an infotype screen structure (belonging to type MAIN) or a repeat field screen structure
(belonging to type LINE). All screen structures must belong either to one type or the other. Type MAIN screen structures (introduced in the next topic) and type
LINE screen structures (introduced in the topic thereafter) each observe their own corresponding naming convention. The naming convention of each screen
structure type is explained in the corresponding subsequent topic.
A third and final important consideration of any screen structure is the conversion class that is assigned to it, which in turn determines the manner in which data
from the infotype structure will be converted into a format suitable for display in the screen structure. For additional information on the relationship between
conversion classes and screen structures, consult the topic Assigning Conversion Classes to Screen Structures.

Use
The specific use of type MAIN and type LINE screen structures is described in detail in the corresponding subsequent topic. However, without regard to a screen
structures type, it is important to remember the enhancement concept of standard infotypes when using any screen structure. In accordance with this concept,
the screen structure of any standard infotype delivered by SAP contains the component .INCLUDE, which enables the inclusion of customer-specific user
interface elements on any standard infotype, much as the component .INCLUDE enables the processing of customer-specific business logic in tandem with any
standard infotype.

Examples of component .INCLUDE in the standard Basic Pay infotype (0008) are visible in its infotype structure (P0008) where the system
uses this component to account for data in component type CI_P0008 as well as its international type MAIN screen structure
(HCMT_BSP_PA_XX_R0008) where the system applies this component to consider data in component type CI_XX_R0008. By the same
token, in the international type LINE screen structure (HCMT_BSP_PA_XX_R0008_LIN_A) of the standard Basic Pay infotype (0008), the
system applies this component to consider data in component type CI_XX_R0008_LIN_A.
Thus, if a customer for example wishes to enhance the standard Basic Pay infotype (0008) by creating new fields in component type CI_P0008 of infotype
structure P0008, then he or she must also remember to create corresponding new fields in the corresponding component type of the affected screen structure
for example, in component type CI_XX_R0008 of screen structure HCMT_BSP_PA_XX_R0008 to ensure that these fields are represented on the user
interface.
Aside from this important consideration, no additional action is necessary for such customer-specific fields when they are identically named in the infotype
structure and screen structure; the de-coupled framework will ensure that identically named fields are automatically filled, that input help values and descriptive
texts are automatically retrieved (if Customizing has been performed), and that field attribute information is automatically provided.
Where customer-specific field names bear different field names in the infotype structure and screen structure, corresponding manual coding is required. However,
in contrast to customer-specific infotypes which require the implementation of methods OUTPUT_CONVERSION and INPUT_CONVERSION in the
corresponding conversion class neither method requires implementation when standard infotypes delivered by SAP are enhanced. To this end, Business Add-In
(BAdI) HRPAD00INFTYUI must be implemented instead.

Infotype Screen Structures (Type MAIN)


Definition
Type MAIN screen structures contain all fields that require representation on the user interface, with the exception of repeat fields, which are to be displayed on
the user interface in table format. Therefore, if no repeat fields are to be contained within the screen structure, then a type MAIN screen structure should be
applied. If repeat fields are to be contained in the screen structure, then a type LINE screen structure should be applied instead.
No more than one type MAIN screen structure can exist per combination of infotype and infotype version.
Type MAIN screen structures observe the naming convention HCMT_BSP_PA_yy_Rnnnn, where:
yy
denotes the Version ID for example, FR for France, UP for the United States Public Sector, US for the United States, and XX for the international version,
and
nnnn
denotes the four-digit number that is assigned to the infotype.

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

Page 53 of 75

As with other customer-specific objects that observe a naming convention with the initial letter Z, type MAINscreen structures for customer-specific infotypes
observe the naming convention ZHCMT_BSP_PA_yy_Rnnnn.

If a name range prefix is desired, then the name of the screen structure must be shortened accordingly. Therefore, customers should observe the
naming convention /custcust/ZHCMT_yy_Rnnnn if they wish to apply a name range prefix to customer-specific type MAIN screen structures.

Structure
Type MAIN screen structures are composed of the following elements:

Component OBJECT_KEY
In the de-coupled framework, component OBJECT_KEY is strictly reserved for internal use, and is not relevant for user interfaces. Never change or clear the

value of this component!


Include HRPAD00SCREEN_HEADER

This include contains header columns similar to those found in the infotype structure and is composed of the following fields:
Personnel Number (PERNR),
Changed On (AEDTM),
which indicates the date on which the infotype record was changed,
Name of Person Who Changed Object (UNAME),
which reflects the user name of the party who changed the infotype record,
Lock Indicator for HR Master Record (Text) (SPRTX),
which indicates whether or not the infotype record is locked, and
Start Date (BEGDA) and End Date (ENDDA),
which indicates the validity period of the infotype record.
Fields to be represented on the user interface, including editable fields (for data entry) and read-only fields.
Include CI_yy_Rnnnn (for standard infotypes only)
where yy and nnnn adhere to the naming convention explained above.
As discussed in the topic Screen Structures, this include enables customer-specific fields to be represented on standard infotypes that customers wish to
enhance.
To reiterate, the fields contained within type MAIN screen structures are essentially intended for representation on the user interface. In some cases, these fields
and the corresponding PSnnnn fields may be identical. In other cases, additional fields may exist, or fewer fields, or different fields altogether, as discussed in the
topic Programming User Interfaces in the De-Coupled Framework. As also discussed in that topic, many screen structure fields are filled or otherwise processed
automatically. Fields that cannot automatically be processed require handling in the corresponding conversion class by implementing methods
OUTPUT_CONVERSION and INPUT_CONVERSION. Once these methods are implemented, the conversion class must be assigned to the screen structure, as
explained in the topic Assigning Conversion Classes to Screen Structures.

Repeat Field Screen Structures (Type LINE)


Definition
Type LINE screen structures contain all repeat fields that require representation on the user interface in table format. Therefore, if repeat fields are to be contained
in the screen structure, then a type LINE screen structure should be applied. However, if no repeat fields are to be contained within the screen structure, then a
type MAIN screen structure should be applied instead.

To ensure the complete definition of type LINE screen structures in this topic, a brief description of repeat fields is warranted and provided below.
Repeat fields are fields that are represented on the user interface of an infotype and that can contain several values. Because repeat fields can
contain several values, a given repeat field may be represented several times on the user interface of the corresponding infotype. To illustrate, the
Basic Pay infotype (0008) features the repeat field Wage Type Amount (with technical names BET01 through BET40) on its user interface. As
the repeat field Wage Type Amount demonstrates, the technical names of any repeat field consists of a three-character stem in this case, BET
and a series of consecutive two-digit numbers in this case, 01 through 40. Because the Wage Type Amount field has forty repetitions, forty is
also the maximum number of values that this repeat field is permitted to store.
Multiple type LINE screen structures can exist per combination of infotype and infotype version.
Type LINE screen structures observe the naming convention HCMT_BSP_PA_yy_Rnnnn_LIN_z, where:
yy
denotes the Version ID for example, FR for France, UP for the United States Public Sector, US for the United States, and XX for the international version,
nnnn
denotes the four-digit number that is assigned to the infotype, and
LIN_z
indicates (via suffix LIN) that the screen structure is of type LINE, and therefore contains repeat fields. In addition to suffix LIN, an arbitrary and unique onecharacter suffix _z for example, _A, _B, _C, and so on must be applied to each type LINE screen structure. (Under some circumstances, a twocharacter suffix for example, _A1 or _A2 may instead be applied.) This second suffix serves to distinguish among the multiple type LINE structures that
can exist per combination of infotype and infotype version.
As with other customer-specific objects that observe a naming convention with the initial letter Z, type LINEscreen structures for customer-specific infotypes
observe the naming convention ZHCMT_BSP_PA_yy_Rnnnn_LIN_z.

If a name range prefix is desired, then the name of the screen structure must be shortened accordingly. Therefore, customers should observe the
naming convention /custcust/ZHCMT_yy_Rnnnn_LIN_z if they wish to apply a name range prefix to customer-specific type LINE screen
structures.

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

Page 54 of 75

Use
In the de-coupled framework, type LINEscreen structures are used to represent, in table format, the values of a repeat field on the user interface of an individual
infotype record. Where multiple repeat fields exist on a single infotype, a single type LINE screen structure in principle can contain all of the repeat fields that the
infotype requires. However, each repeat field is stored in the type LINE screen structure only once.

In the user interface of certain infotypes, groups of repeat fields may exist that do not logically belong together. In such cases, a separate type
LINE screen structure is required for each divergent group of repeat fields.
To illustrate, the international and country-specific type LINE screen structures that represent the Basic Pay infotype (0008) do not in fact contain the forty
Wage Type Amount repeat fields that are represented on the user interface; these screen structures instead merely contain the Amount field (BETRG), which is
subsequently used to represent all forty repetitions.
At runtime, the de-coupled framework applies a table to process all of the repeat field values. Within the de-coupled framework, the type LINE structure defines
the technical structure of that table. Each line of the table contains the value of the corresponding repeat field. To illustrate, if three values are to be represented in
the Wage Type Amount field of the Basic Pay infotype (0008), then the corresponding type LINE screen structure will define the technical structure of the table
that is used to represent the repeat fields (in this case, BET01, BET02 and BET03). However, the type LINE screen structure itself will contain the Amount field
(BETRG), rather than the Wage Type Amount repeat fields.
As with type MAIN screen structures, standard functionality is available in the de-coupled framework to process type LINE screen structures, provided that
Customizing has been performed in Mapping for Conversion of Repeat Structure/Tables (tables T588AUTO_MAP and T588AUTO_TABLE) in the manner
indicated below. By extension, if no unusual user requirements exist, then the default conversion class can be used and assigned to the type LINE screen
structure, as described in the topic Assigning Conversion Classes to Screen Structures.
In contrast, if standard functionality is neither suitable nor possible for the type LINE screen structure in question, then methods
OUTPUT_TABLE_CONVERSION and INPUT_TABLE_CONVERSION of the corresponding conversion class must be implemented.

Structure
Type LINE screen structures are composed of the following elements:
Component OBJECT_KEY
In the de-coupled framework, component OBJECT_KEY is strictly reserved for internal use, and is not relevant for user interfaces. Never change or clear the
value of this component!
Fields to be represented on the user interface, including editable fields (for data entry) and read-only fields.
Include CI_yy_Rnnnn_LIN_z (for standard infotypes only)
where yy, nnnn and LIN_z adhere to the naming convention explained above.
As discussed in the topic Screen Structures, this include enables customer-specific fields to be represented on standard infotypes that customers wish to
enhance.
The remainder of this topic discusses the structure of tables T588AUTO_MAP and T588AUTO_TABLE, as well as the manner in which these tables are
customized to enable standard functionality for type LINE screen structures.

Table T588AUTO_MAP
In Mapping for Conversion of Repeat Structure/Tables (table T588AUTO_MAP), the link is established between the repeat fields of the infotype structure and
their representation in the corresponding type LINE screen structure. The following chart summarizes the three fields that, taken together, comprise the structure of
table T588AUTO_MAP.
T588AUTO_MAP Fields
Field

Short Description

SCREENSTRUCTURE

Name of UI Structure

TABLE_FIELD

Name of UI Table Field

REPEAT_FIELD01

Name of First Repeat Field

Among these three fields, only the Name of UI Structure field (SCREENSTRUCTURE) is a key field. This field contains the technical name of the corresponding
type LINEscreen structure.
In contrast, Name of UI Table Field (TABLE_FIELD) contains the name of the repeat field in the type LINE screen structure, while Name of First Repeat Field
(REPEAT_FIELD01) reflects the name of the first enumeration of the repeat field in the infotype structure.
The following example demonstrates the five standard entries that are delivered in table T588AUTO_MAP for the international type LINE screen structure
(HCMT_BSP_PA_XX_R0008_LIN_A) of the standard Basic Pay infotype (0008).
Standard T588AUTO_MAP Entries for Screen Structure HCMT_BSP_PA_XX_R0008_LIN_A
SCREENSTRUCTURE

TABLE_FIELD

REPEAT_FIELD01

HCMT_BSP_PA_XX_R0008_LIN_A

ANZHL

ANZ01

HCMT_BSP_PA_XX_R0008_LIN_A

BETRG

BET01

HCMT_BSP_PA_XX_R0008_LIN_A

INDBW

IND01

HCMT_BSP_PA_XX_R0008_LIN_A

LGART

LGA01

HCMT_BSP_PA_XX_R0008_LIN_A

OPKEN

OPK01

Table T588AUTO_TABLE
Once the link between the repeat fields of the infotype structure and their representation in the corresponding type LINE screen structure fields has been

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

Page 55 of 75

established in table T588AUTO_MAP, additional properties must be defined for the type LINE screen structure. Therefore, for each type LINE screen structure
to be used, a corresponding entry must be defined in Mapping for Conversion of Repeat Structure/Tables (table T588AUTO_TABLE). The following chart
summarizes the four fields that, taken together, comprise the structure of that table.
T588AUTO_TABLE Fields
Field

Short Description

SCREENSTRUCTURE

Name of UI Structure

REPEAT_RECORDS

Repeat Records in Infotype

INITIAL_LINES

Blank Rows

REPEAT_PLACES

Size of Repeat Number

As with table T588AUTO_MAP, among the four fields in this table, only the Name of UI Structure field (SCREENSTRUCTURE) is a key field. This field contains
the technical name of the corresponding type LINE screen structure.
The Repeat Records in Infotype field (REPEAT_RECORDS) defines the maximum number of repetitions supported for that type LINE screen structure that is,
the maximum number of field values in the infotype.
The Blank Rows field (INITIAL_LINES) defines the number of additional initial lines that will be displayed on the user interface, at the end of the table, to permit
new values to be entered. Depending upon the application used, the value defined in this field may have great impact or no impact at all, if the application
defines its own means of processing the insertion of new values.
The Size of Repeat Number field (REPEAT_PLACES) defines the number of suffix characters that denotes the repeat number within the repeat field names.
The following example demonstrates the standard entry that is delivered in table T588AUTO_TABLE for the international type LINE screen structure
(HCMT_BSP_PA_XX_R0008_LIN_A) of the standard Basic Pay infotype (0008).
Standard T588AUTO_TABLE Entry for Screen Structure HCMT_BSP_PA_XX_R0008_LIN_A
SCREENSTRUCTURE

REPEAT_RECORDS

INITIAL_LINES

REPEAT_PLACES

HCMT_BSP_PA_XX_R0008_LIN_A

40

Prerequisites
A complete set of prerequisites must be fulfilled in order to use the standard functionality to process repeat fields in type LINE screen structures in tandem with
Customizing for tables T588AUTO_MAP and T588AUTO_TABLE and the default conversion class. These prerequisites are summarized below.

The repeat field number must be an integer; other characters are not permitted.
The repeat field number must be represented in the field name as a suffix.
The suffix must have the same length for all repetitions of the repeat field.
The repeat field number of the first repetition must be 1, with an arbitrary amount of leading zeros for example, 1, 01, or 001, and so on.
The repeat field number must increase successively and without gaps.
All repeat fields within one group that is, within one type LINE screen structure must have the same number of repetitions.

If even one of these prerequisites cannot be fulfilled, then the standard functionality to process repeat fields cannot be applied. In such cases, output table
conversion and input table conversion for the type LINE screen structure must be performed manually, by composing the appropriate source code in methods
OUTPUT_TABLE_CONVERSION and INPUT_TABLE_CONVERSION of the assigned conversion class.

Example
The following tables refer to the Basic Pay infotype (0008) as an example to illustrate the conversion of repeat fields.
In the following table, which represents an infotype record as it exists within the infotype structure, the values of the repeat fields Wage Type (LGA01 through
LGA40) and Wage Type Amount (BET01 through BET40) are summarized. As one can see, only the first two repetitions (01 and 02) in this example are filled
with values. All other repetitions are not used, and therefore are filled with initial values. When repeat field conversion is performed, the two value pairs of this
infotype record are converted into a table with two lines. An additional empty line is appended to the table to enable new data to be entered, as demonstrated
above by value 1 in the INITIAL_LINES field of the standard T588AUTO_TABLE entry for screen structure HCMT_BSP_PA_XX_R0008_LIN_A.
Sample Basic Pay Infotype (0008) Record (Infotype Structure)
...

LGA01

BET01

LGA02

BET02

MA10

910

MA30

720

...

On the user interface, these entries would be displayed in the following manner.
Sample Basic Pay Infotype (0008) Record (Screen Structure)

LGART

BETRG

MA10

910

MA30

720

In summary, by customizing tables T588AUTO_MAP and T588AUTO_TABLE and using the default conversion class, one can perform repeat field conversion
without the need to compose dedicated source code. Moreover, by using this generic functionality, once can simultaneously employ the automatic retrieval of
descriptive texts for key values within the type LINE screen structure, along with other generic functionality provided by the de-coupled framework.

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

Page 56 of 75

1.5.3 Conversion Classes


Definition
As described in the topic Programming User Interfaces in the De-Coupled Framework, conversion classes are of fundamental importance in ensuring that data
from back-end infotype structures is converted for proper display in screen structures. Conversion classes also play a key role in screen control functionality by
providing input help values and attributes for user interface fields.
Conversion classes delivered by SAP observe the naming convention CL_HRPA_UI_CONVERT_nnnn_yy, where:
nnnn

denotes the four-digit number that is assigned to the infotype, and


yy
denotes the Version ID for example, FR for France, UP for the United States Public Sector, US for the United States, and XX for the international version.

In contrast, conversion classes created by customers should observe the naming convention ZCL_HRPA_UI_CONVERT_nnnn_yy, where nnnn and yy denote
the same information as in the conversion classes delivered by SAP.

If a name range prefix is desired, then customers should observe the naming convention /custcust/ZCL_UI_CONV_nnnn_yy while creating
their conversion classes.

Use
Conversion classes are assigned to screen structures, as described in detail at the end of these guidelines. Whenever a screen structure appears in the user
interface, the corresponding conversion class is called, both to perform the necessary conversion of data and to provide screen control functionality.
Two types of conversion classes are supported, namely standard conversion classes and advanced conversion classes. Standard conversion classes
implement interface IF_HRPA_UI_CONVERT_STANDARD, while advanced conversion classes implement interface IF_HRPA_UI_CONVERT_ADVANCED.
In the majority of cases, it will suffice to implement a standard conversion class. Advanced conversion classes only require implementation in cases where the
infotype in question contains additional data (via a specific infotype container) that needs to be accessed, rather than relying upon standard infotype structures
alone for example PNNNN for the primary infotype, PNNNN2 for the secondary infotype (that is, infotype view), PREFfor cost distribution, and so on. (To this end,
advanced conversion classes pass this container, instead of the standard infotype structures, in each interface method.)
Aside from this single difference, standard and advanced conversion classes operate in an identical manner; the set of methods to be implemented, as well as
the behavior of the methods themselves, equally apply to both types of conversion classes. For this reason, unless explicitly noted otherwise, the remainder of
this topic and all subsequent topics in these guidelines always relate to standard conversion classes.
The default conversion class CL_HRPA_UI_CONVERT_BASIC is delivered in the standard system and can be used (that is, assigned to the corresponding
screen structure) if the infotype in question lacks specific user interface requirements. However, if the functionality of the default conversion class is insufficient,
then that class cannot be applied; a dedicated conversion class must instead be created and implemented.
As delivered, default conversion class CL_HRPA_UI_CONVERT_BASIC provides the following generic functionality.
Field Values
When the default conversion class is applied, all user interface fields that bear identical field names in both the screen structure and the infotype structure
are automatically filled. To this end, a MOVE-CORRESPONDING statement is used to transfer all field values from the infotype structure to the screen structure
(for output conversion) and from the screen structure to the infotype structure (for input conversion).
If the screen structure contains fields whose field names differ from the field names in the infotype structure, or if uses of the MOVE-CORRESPONDING
statement are not desired, then the default conversion class cannot be applied. Rather, a dedicated conversion class must be created, and methods
OUTPUT_CONVERSION and INPUT_CONVERSION must be implemented, in accordance with the specific user interface requirements.
Input Help Values
When the default conversion class is applied, Data Dictionary information is automatically evaluated, and input help values are automatically retrieved.
If this generic functionality is not suitable for the fields in question, or if other user interface requirements exist for the input help values to be provided, then the
default conversion class cannot be applied. A dedicated conversion class must be created instead, and method FILL_HELP_VALUES must be
implemented.
Descriptive Texts
When the default conversion class is applied and the corresponding Customizing has been performed, descriptive texts for fields that hold key values are
automatically retrieved, as described in the topic Automatically Retrieving Descriptive Texts. To this end, generic functionality known as the text identifier is
applied to evaluate the Data Dictionary and derive the appropriate texts. In cases where this generic functionality is not suitable, the text identifier can be
enhanced, if desired, by means of the corresponding exception concept. Advantageously, once an exception has been defined for the text identifier, that
exception can always be re-used by the text identifier, regardless of the application that is using it.

Always apply the exception concept of the text identifier, rather than creating a specific conversion class to derive the text on your own.
Field Attributes
When the default conversion class is applied, field attribute information (for example, mandatory, read-only, and so on) is automatically provided for those
fields that bear identical field names in both the screen structure and the infotype structure. The system provides this information by evaluating the metadata
defined for the back-end fields in tables T588MFPROPS and T588MFPROPC (the SAP and customer tables, respectively).
If you wish to set different field attributes, or if the field attributes are dynamically derived on the basis of the current infotype values, or if the screen structure
contains fields whose field names differ from the field names in the infotype structure, then the default conversion class cannot be applied. Instead, a
dedicated conversion class must be created, and methods OUTPUT_CONVERSION and INPUT_CONVERSION must be implemented.

When the Create Infotype transaction (transaction code PM01) is executed for a new Personnel Administration infotype, the system automatically
applies the default conversion class CL_HRPA_UI_CONVERT_BASIC, based on the assumption that no specific user interface requirements
exist. The same assumption underlies the foregoing generation of the corresponding screen structure, which by default contains the same fields
that are contained in structure Pnnnn.
If by using the appropriate functionality of the Create Infotype transaction you elect to change the default fields of the screen structure, then
the system will automatically generate a dedicated conversion class in response; this conversion class must be implemented in accordance with

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

Page 57 of 75

the specific user interface requirements.


The conversion class thus generated is a standard conversion class, implementing interface IF_HRPA_UI_CONVERT_STANDARD. However, if
the dedicated conversion class will need to access the infotype container, then you must manually replace this default (standard) interface with the
interface for an advanced conversion class that is, IF_HRPA_UI_CONVERT_ADVANCED.

1.5.3.1 Initialization (Method INITIALIZE)


Definition
The implementation of this method is only necessary if other infotypes must be read when output conversion and input conversion is performed (for type MAIN
screen structures) or when output table conversion and input table conversion is performed (for type LINE screen structures).

Use
Method INITIALIZE is called directly after the instance of the conversion class is created. The sole purpose of this method is to pass references to reader
classes that, in turn, might be used to read additional infotype data during output and input conversion. When this method is applied, the following references are
passed:

PAITF_READ
Reference PAITF_READ refers to a class with interface IF_HRPA_PAITF_READ. Method READ of this class can be called to read any additional infotype

data that will be necessary.


PAITF_READ_MOLGA
Reference PAITF_READ_MOLGArefers to class CL_HRPA_MOLGA. Method READ_MOLGA_BY_PERNR of this class can be called to obtain the country
grouping of a specified personnel number.

If this method is required, then we recommend that you implement it as demonstrated in the example below. The sample source code below stores the reader
class references within attributes of the conversion class. In any subsequent implementation of methods OUTPUT_CONVERSION and INPUT_CONVERSION,
the reader classes are simply called via the attributes.

No other means are permitted for reading infotype data.

Example
The following source code excerpt demonstrates a sample implementation of the INITIALIZE method.

METHOD IF_HRPA_UI_CONVERT_STANDARD~INITIALIZE.
a_paitf_read = paitf_read.
a_paitf_read_molga = paitf_read_molga.
ENDMETHOD.
This source code requires that the following attributes that is, Private, Instance attributes be defined.

A_PAITF_READ type ref to IF_HRPA_PAITF_READ

A_PAITF_READ_MOLGA type ref to CL_HRPA_MOLGA


In the subsequent implementation of other methods for example, in method OUTPUT_CONVERSION you can access these classes in the following manner.

METHOD IF_HRPA_UI_CONVERT_STANDARD~OUTPUT_CONVERSION.
DATA p0001_tab TYPE STANDARD TABLE OF p0001.
DATA p0001 TYPE p0001.
DATA molga TYPE molga.
FIELD-SYMBOLS <p9001> TYPE p9001.
FIELD-SYMBOLS <zhcmt_bsp_pa_xx_r9001> TYPE zhcmt_bsp_pa_xx_r9001.

is_ok = if_hrpa_ui_convert_standard~true.
CLEAR field_attributes.

* ensure that method is called for the correct screen structure


IF screen_structure_name <> 'ZHCMT_BSP_PA_XX_R9001'.
RAISE EXCEPTION TYPE cx_hrpa_violated_assertion.
ENDIF.

* assign and type structures


ASSIGN pnnnn TO <p9001>.
ASSIGN screen_structure TO <zhcmt_bsp_pa_xx_r9001>.
...

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

Page 58 of 75

* read infotype 0001


CALL METHOD a_paitf_read->read
EXPORTING
tclas

= 'A'

pernr

= <p9001>-pernr

infty

= '0001'

begda
endda

= <p9001>-begda
= <p9001>-begda

no_auth_check

= if_hrpa_ui_convert_standard~true

message_handler = message_handler
IMPORTING
pnnnn_tab
is_ok

= p0001_tab

= is_ok.

...
* read molga
molga = a_paitf_read_molga->read_molga_by_pernr(
tclas = 'A'
pernr = <p9001>-pernr ).
...
ENDMETHOD.

Output Conversion (Method OUTPUT_CONVERSION)


Definition
Implementation of this method is mandatory.
This method is the counterpart of method INPUT_CONVERSION, introduced in the subsequent topic.

Use
The name of the screen structure for which the conversion class is called is passed in parameter SCREEN_STRUCTURE_NAME. Moreover, the current infotype
record is passed in parameter PNNNN. The foremost task of method OUTPUT_CONVERSION is to fill parameter SCREEN_STRUCTUREwith the corresponding
infotype values that should be presented on the user interface.
In the simplest case where all fields have the same technical names in the infotype structure as in the screen structure a MOVE-CORRESPONDING
statement, as shown in the first example at the end of this topic, is sufficient to perform output conversion.
As illustrated in the second example at the end of this topic, in more complex cases, where the screen structure contains fields whose field names differ from the
field names in the infotype structure, appropriate source code must be composed to fill all fields that belong to the screen structure unless descriptive texts for
fields that hold key values are to be retrieved. With this sole exception (as described in the topic Automatically Retrieving Descriptive Texts), no source code is
required; provided that the corresponding Customizing has been performed, the de-coupled framework will automatically retrieve these texts immediately after
method OUTPUT_CONVERSION is called.

In the event that errors are encountered during output conversion, a corresponding message can be issued via the Message Handler (that is,
parameter MESSAGE_HANDLER). All messages stored in this manner will subsequently be presented, when called for, on the user interface.
Three types of messages can be issued type I (for information), type W(for warnings), or type E (for errors). If error messages (of type E) are to
be called, then parameter IS_OK must be set to the value (that is, IS_OK = false.). In all other cases and especially when no
message is to be issued at all then parameter IS_OK must be set to the value X (that is, IS_OK = true.).
Importing parameter MODE currently is not used in the standard system; it is, however, intended for future use. Under no circumstances should this parameter be
used in customer source code.
Importing parameters MASSN and MASSG respectively specify the action and reasons in which the infotype is currently running. In the event that the infotype has
specific user interface requirements when run in a certain action, then it may be appropriate to code on these parameters.
Parameter PNNNN2 provides the current record of the secondary infotype (that is, infotype view), while parameter PREFprovides the cost assignment of the current
infotype record.
In principle, from the perspective of conversion classes in the de-coupled framework, all fields of the screen structure are considered to be editable in the user
interface although the technology of the user interface in question ultimately determines whether or not the contents of a particular field truly can be edited. For all
editable fields, appropriate processing must be defined in the implementation of method INPUT_CONVERSION. To this end, if a particular field should not be
editable, or if that field should receive any other attribute, then the field property must be set accordingly in exporting table FIELD_ATTRIBUTES.
In that table, exactly one entry must be created for the corresponding field. The entry to be created in turn consists of the appropriate value in field OBJECT_KEY,
as well as a nested table named FIELD_ATTRIBUTE. Field OBJECT_KEY should be set to the same value as the object key in parameter
SCREEN_STRUCTURE. In the nested table FIELD_ATTRIBUTE, all fields must be stored by their technical names defined in the screen structure and with a
corresponding property. The following three properties are supported:
A signifying read-only,
B signifying hidden, and
C signifying mandatory.
Any field that is not expressly listed in the nested FIELD_ATTRIBUTE will be assigned the properties of standard editable fields.

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

Page 59 of 75

When setting the field attributes, the field metadata passed in parameter FIELD_METADATA can be taken into account. This metadata is read from tables
T588MFPROPS and T588MFPROPC (the SAP and customer tables, respectively) and relates to the infotype fields of structure Pnnnn, as defined in the (backend) business logic. If you would like the fields of the screen structure to inherit the same attributes, implement method CONVERT_AND_MERGE_FIELD_ATTRBS
of service class CL_HRPA_FIELD_ATTRIBS_SERVICES, as demonstrated in the first example below. It is important to note that this class cannot be used
unless the user interface fields bear identical field names in both the screen structure and the infotype structure.

Specification of the appropriate field attributes in the conversion class is a prerequisite for any working user interface. Nonetheless, the technology
of the user interface in question and by extension the application that is providing the UI ultimately determine whether or not that user interface
truly will reflect the field attributes specified in the conversion class.

Special attention must be paid to field OBJECT_KEY of parameter SCREEN_STRUCTURE. Although SCREEN_STRUCTURE is an exporting
parameter, the de-coupled framework can nonetheless set the value of field OBJECT_KEY before calling method OUTPUT_CONVERSION, since
parameter SCREEN_STRUCTURE is passed as call-by-reference. It is therefore imperative to note that in the de-coupled framework, the field
OBJECT_KEY is strictly reserved for internal use. Never change or clear the value of field OBJECT_KEY!

Example
The first example provided below illustrates the simplest case where this method could be implemented, while the second example demonstrates a more
complex case.

METHOD IF_HRPA_UI_CONVERT_STANDARD~OUTPUT_CONVERSION.

is_ok = if_hrpa_ui_convert_standard~true.
CLEAR field_attributes.

* ensure that method is called for the correct screen structure


IF screen_structure_name <> 'ZHCMT_BSP_PA_XX_R9001'.
RAISE EXCEPTION TYPE cx_hrpa_violated_assertion.
ENDIF.

* move values of fields with identical names


MOVE-CORRESPONDING pnnnn TO screen_structure.

* set field attributes in accordance with field metadata


CALL METHOD cl_hrpa_field_attribs_services=>convert_and_merge_field_attrbs
EXPORTING
field_metadatas

= field_metadatas

CHANGING
field_attributes = field_attributes.
ENDMETHOD.

METHOD IF_HRPA_UI_CONVERT_STANDARD~OUTPUT_CONVERSION.
* infotype structure P9001 contains these fields:
* NACHN Last Name
* VORNA First Name
* GBDAT Date of Birth
* GBPAS Date of Birth According to Passport
* NCHMC Last Name (Field for Search Help) -> not needed on UI
* ANRED Form-of-Address Key (key values 1, 2, representing Mr., Ms.,)
* screen structure ZHCMT_BSP_PA_XX_R9001 contains these fields:
* NACHN Last Name
* VORNA First Name
* FULL_NAME Full Name (Concatenation of First Name and Last Name)
* GBDAT Date of Birth
* AGE Employee age (Derived from Date of Birth)
* ANRED Form-of-Address Key
* FORM_OF_ADDRESS_TEXT Form-of-Address Description (descriptive texts Mr., Ms.,)

FIELD-SYMBOLS <p9001> TYPE p9001.


FIELD-SYMBOLS <zhcmt_bsp_pa_xx_r9001> TYPE zhcmt_bsp_pa_xx_r9001.
FIELD-SYMBOLS <field_attribute_wa> TYPE hrpad_obj_field_attribute.
DATA field_attribute TYPE hrpad_field_attribute.

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

Page 60 of 75

is_ok = if_hrpa_ui_convert_standard~true.
CLEAR field_attributes.

* ensure that method is called for the correct screen structure


IF screen_structure_name <> 'ZHCMT_BSP_PA_XX_R9001'.
RAISE EXCEPTION TYPE cx_hrpa_violated_assertion.
ENDIF.
* assign and type structures
ASSIGN pnnnn TO <p9001>.
ASSIGN screen_structure TO <zhcmt_bsp_pa_xx_r9001>.
* move values of fields NACHN, VORNA, GBDAT, ANRED (and header fields)
MOVE-CORRESPONDING <p9001> TO <zhcmt_bsp_pa_xx_r9001>.
* calculate field AGE based on the date of birth in GBDAT
<zhcmt_bsp_pa_xx_r9001>-age = sy-datum+0(4) - <p9001>-gbdat+0(4).
IF <p9001>-gbdat+4(4) > sy-datum+4(4).
SUBTRACT 1 FROM <zhcmt_bsp_pa_xx_r9001>-age.
ENDIF.
* calculate field FULL_NAME based on names in NACHN and VORNA
CONCATENATE <p9001>-vorna <p9001>-nachn
INTO <zhcmt_bsp_pa_xx_r9001>-full_name SEPARATED BY space.
* no action required for field FORM_OF_ADDRESS_TEXT; this
* descriptive text for field ANRED is derived from Customizing

* set field attributes in accordance with field metadata


CALL METHOD cl_hrpa_field_attribs_services=>convert_and_merge_field_attrbs
EXPORTING
field_metadatas

= field_metadatas

CHANGING
field_attributes = field_attributes.
READ TABLE field_attributes ASSIGNING <field_attribute_wa> INDEX 1.
* delete field attributes for fields not supported in the screen structure
DELETE <field_attribute_wa>-field_attribute
WHERE field_name = 'GBPAS' OR field_name = 'NCHMC'.
* set field AGE to readonly
CLEAR field_attribute.
field_attribute-field_name = 'AGE'.
field_attribute-field_property = if_hrpa_ui_convert_standard~read_only.
APPEND field_attribute TO <field_attribute_wa>-field_attribute.
* set field FORM_OF_ADDRESS_TEXT to readonly
CLEAR field_attribute.
field_attribute-field_name = 'FORM_OF_ADDRESS_TEXT'.
field_attribute-field_property = if_hrpa_ui_convert_standard~read_only.
APPEND field_attribute TO <field_attribute_wa>-field_attribute.
* set field FULL_NAME to mandatory
CLEAR field_attribute.
field_attribute-field_name = 'FULL_NAME'.
field_attribute-field_property = if_hrpa_ui_convert_standard~obligatory.
APPEND field_attribute TO <field_attribute_wa>-field_attribute.
* set field NACHN to readonly
CLEAR field_attribute.
field_attribute-field_name = 'NACHN'.
field_attribute-field_property = if_hrpa_ui_convert_standard~read_only.
APPEND field_attribute TO <field_attribute_wa>-field_attribute.
* set field VORNA to readonly
CLEAR field_attribute.
field_attribute-field_name = 'VORNA'.
field_attribute-field_property = if_hrpa_ui_convert_standard~read_only.
APPEND field_attribute TO <field_attribute_wa>-field_attribute.

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

Page 61 of 75

ENDMETHOD.

Input Conversion (Method INPUT_CONVERSION)


Definition
Implementation of this method is mandatory.
This method is the counterpart of method OUTPUT_CONVERSION, introduced in the previous topic. For an explanation of the parameters contained in method
INPUT_CONVERSION, review the previous topic.

Use
Whereas method OUTPUT_CONVERSION is implemented to fill the screen structure, based on the values of the infotype structure, method INPUT_CONVERSION
is implemented to fill the infotype structure, based on the values of the screen structure. Infotype structure Pnnnn is a changing parameter. The values that are
imported into it are those that were passed as importing when method OUTPUT_CONVERSION was last called.

Example
The first example provided below illustrates the simplest case where this method could be implemented, while the second example demonstrates a more
complex case. Moreover, the second example in this topic provides a counterpart to the second example that was demonstrated in the previous topic.

METHOD IF_HRPA_UI_CONVERT_STANDARD~INPUT_CONVERSION.
is_ok = if_hrpa_ui_convert_standard~true.
* ensure that method is called for the correct screen structure
IF screen_structure_name <> 'ZHCMT_BSP_PA_XX_R9001'.
RAISE EXCEPTION TYPE cx_hrpa_violated_assertion.
ENDIF.
* move values of fields with identical names
MOVE-CORRESPONDING screen_structure TO pnnnn.
ENDMETHOD.

METHOD IF_HRPA_UI_CONVERT_STANDARD~INPUT_CONVERSION.
* infotype structure P9001 contains these fields:
* NACHN Last Name
* VORNA First Name
* GBDAT Date of Birth
* GBPAS Date of Birth According to Passport
* NCHMC Last Name (Field for Search Help) -> not needed on UI
* ANRED Form-of-Address Key (key values 1, 2, representing Mr., Ms.,)
* screen structure ZHCMT_BSP_PA_XX_R9001 contains these fields:
* NACHN

Last Name

* VORNA

First Name

* FULL_NAME Full Name (Concatenation of First Name and Last Name)


* GBDAT Date of Birth
* AGE Employee age (Derived from Date of Birth)
* ANRED Form-of-Address Key
* FORM_OF_ADDRESS_TEXT Form-of-Address Description (descriptive texts Mr., Ms.,)
FIELD-SYMBOLS <p9001> TYPE p9001.
FIELD-SYMBOLS <zhcmt_bsp_pa_xx_r9001> TYPE zhcmt_bsp_pa_xx_r9001.

is_ok = if_hrpa_ui_convert_standard~true.

* ensure that method is called for the correct screen structure


IF screen_structure_name <> 'ZHCMT_BSP_PA_XX_R9001'.
RAISE EXCEPTION TYPE cx_hrpa_violated_assertion.
ENDIF.

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

Page 62 of 75

* assign and type structures


ASSIGN pnnnn TO <p9001>.
ASSIGN screen_structure TO <zhcmt_bsp_pa_xx_r9001>.

* copy values of fields GBDAT, ANRED


<p9001>-gbdat = <zhcmt_bsp_pa_xx_r9001>-gbdat.
<p9001>-anred = <zhcmt_bsp_pa_xx_r9001>-anred.

* no action required for readonly fields AGE, NACHN, VORNA, FORM_OF_ADDRESS_TEXT

* extract NACHN and VORNA from field FULL_NAME.


SPLIT <zhcmt_bsp_pa_xx_r9001>-full_name AT space
INTO <p9001>-vorna <p9001>-nachn.
ENDMETHOD.

Input Help Values (Method FILL_HELP_VALUES)


Definition
Method FILL_HELP_VALUES is delivered to provide input help values for user interface fields both for customary input help, which is displayed by selecting
F4, and for drop-down list boxes. In technical terms, comparable functionality is employed to provide both input help options. An overview of drop-down list box
functionality is summarized below, along with a contrasting overview of input help functionality.
Drop-down list boxes require a data table that contains two columns. In the first column, which is usually invisible on the user interface, all possible key
values are stored. The second column, whose entries remain visible in the list box, contains the corresponding descriptive text for each key value located in
the first column. As soon as the user selects the appropriate field entry (from the second column) the corresponding key value (from the first column) is stored.
Customary input help also requires a data table. However, unlike drop-down list boxes, the corresponding table may contain more than two columns. Thus,
one column contains all possible key values for that field, with one (or more) additional column(s) being used to store information that is linked to those key
values including, ideally, at least one column to store descriptive texts for the key values. On the user interface, input help is customarily displayed as a
list that consists of two or more columns. By extension, input help not only displays the key values and their descriptive texts, but all other related columns
as well. To distinguish the columns (and their respective entries) from one another, column headers are required.

Use
The FILL_HELP_VALUESmethod enables input help and drop-down list boxes, which ultimately rely on the same data structures, to become interchangeable on
the user interface. By extension, a drop-down list box can be represented as input help, provided that column headers are available. Conversely, input help can
be represented as a drop-down list box, assuming that two of the columns in the input help are designated to contain the key value and descriptive text,
respectively, and provided that no problems arise when information from the remaining columns is omitted from the user interface.

Method FILL_HELP_VALUESshould always be implemented in a manner that supports both user interface representations. Nonetheless, the
technology of the user interface in question, along with the application itself, ultimately determine which of these user interface representations will
truly be supported.
Because the de-coupled framework offers generic functionality to provide input help values by evaluating Data Dictionary information, method
FILL_HELP_VALUESonly requires implementation in fields where the generic functionality is either unsuitable or impossible to apply.
Where method FILL_HELP_VALUES is implemented, the system passes all field names for which input help has been requested through table HELP_VALUES.
If the required values can be retrieved by the generic functionality, then all of the following information is provided:
DATA, which reflects the table with the input help data.
KEYCOLUMNAME, which indicates the name of the column within that table that holds the key values.
VALUECOLUMNNAME, which states the name of the column that holds the descriptive texts.
Additional information, summarized below, is passed in parameter FIELD_CATALOGS.
The nested table F4HELP_COLUMNS, which contains the names of all columns within the data table, along with corresponding header titles.
The link between entries in HELP_VALUES and FIELD_CATALOGS is established by the corresponding field names; to wit, HELP_VALUES-FIELDNAME equals
FIELD_CATALOGS-F4FIELDNAME.
For those fields where the generic functionality is neither suitable nor possible, HELP_VALUES solely contains the field name; all other information remains absent.
For this reason, all of the missing information must be provided within the implementation of method FILL_HELP_VALUES. To this end, one must provide a data
table, specify the names of the columns that contain key values and descriptive texts in that table, then create a new entry in FIELD_CATALOGS to apprise the
data table of the technical names and headers for all columns. As a rule, one should always provide all of the requisite information, as one cannot foresee how the
input help will be presented on the user interface.
Furthermore, one must remember always to insert exactly one initial line in the data table; this line is required to permit the user to initialize the field within the user
interface. Moreover, the current field value that is, the value of the field as stored in parameter SCREEN_STRUCTURE also must be specified in the data table.
For this reason, the list of possible field values within the data table must always include the present value of the field.

If the current value is not included, undesirable effects might result on the user interface; the system might either modify the field value, at random,
to an arbitrary value, or issue an error message to report the presence of an invalid field value. Naturally, the technology of the user interface in
question would ultimately determine the unexpected system response that would result. Therefore, as recommended above, always be certain to
include an initial line in the data table, along with the current field value.

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

Page 63 of 75

Moreover, it is worthwhile to note that programmers may modify values that are passed by the generic functionality. Remember that all information passed is
merely a proposal for the input help. You are at liberty to modify the entries in the data table, or even to specify a completely different data table, with different
columns. Nonetheless, the accuracy and consistency of all input help provided must be guaranteed.
Finally, because input help can vary in accordance with the current field values, remember that the current infotype structure and the current screen structure are
passed in parameters PNNNN and SCREEN_STRUCTURE, respectively. Also, where repeat fields are present, method FILL_HELP_VALUES is called separately
for each screen structure record. Therefore, different input help can be provided for each such record.

Example
The following source code excerpt demonstrates a sample implementation of the FILL_HELP_VALUES method.

METHOD IF_HRPA_UI_CONVERT_STANDARD~FILL_HELP_VALUES.
TYPES: t_hrpad00anrex_tab TYPE STANDARD TABLE OF hrpad00anrex.
FIELD-SYMBOLS <anred_help_values> TYPE t_hrpad00anrex_tab.
DATA anred_help_value TYPE hrpad00anrex.
FIELD-SYMBOLS <zhcmt_bsp_pa_xx_r9001> TYPE zhcmt_bsp_pa_xx_r9001.
DATA field_catalog_wa TYPE hrpad_help_value_field_cat.
DATA f4help_columns TYPE hrpad_f4help_table_column_tab.
DATA f4help_column TYPE hrpad_f4help_table_column.
FIELD-SYMBOLS: <help_value_wa> TYPE hrpad_help_value_data.

* ensure that method is called for the correct screen structure


IF screen_structure_name <> 'ZHCMT_BSP_PA_XX_R9001'.
RAISE EXCEPTION TYPE cx_hrpa_violated_assertion.
ENDIF.

* assign and type screen structure


ASSIGN screen_structure TO <zhcmt_bsp_pa_xx_r9001>.

LOOP AT help_values ASSIGNING <help_value_wa>.


CASE <help_value_wa>-fieldname.
WHEN 'ANRED'.
*

specify column names


<help_value_wa>-keycolumnname = 'ANRED'.
<help_value_wa>-valuecolumnname = 'ANREX'.

create table containing F4-help data


CREATE DATA <help_value_wa>-data TYPE STANDARD TABLE OF hrpad00anrex.
ASSIGN <help_value_wa>-data->* TO <anred_help_values>.

create help value for "Mr."


CLEAR anred_help_value.
anred_help_value-anred = 1.
anred_help_value-anrex = 'Mr.'.

"use text-symbol instead

APPEND anred_help_value TO <anred_help_values>.


*

create help value for "Ms."


CLEAR anred_help_value.
anred_help_value-anred = 2.
anred_help_value-anrex = 'Ms.'.

"use text-symbol instead

APPEND anred_help_value TO <anred_help_values>.

append the current value (if not yet in the list)


IF NOT <zhcmt_bsp_pa_xx_r9001>-anred IS INITIAL.
READ TABLE <anred_help_values> TRANSPORTING NO FIELDS
WITH KEY anred = <zhcmt_bsp_pa_xx_r9001>-anred.
IF sy-subrc <> 0.
CLEAR anred_help_value.
anred_help_value-anred = <zhcmt_bsp_pa_xx_r9001>-anred.
anred_help_value-anrex = '???'.
APPEND anred_help_value TO <anred_help_values>.
ENDIF.
ENDIF.

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

Page 64 of 75

append the initial value


APPEND INITIAL LINE TO <anred_help_values>.

create field catalog entry


CLEAR field_catalog_wa.
field_catalog_wa-f4fieldname = <help_value_wa>-fieldname.

create info about column ANRED containing the key value


CLEAR f4help_column.
f4help_column-fieldname = 'ANRED'.
f4help_column-headertitle = 'Key'.

"use text-symbol instead

APPEND f4help_column TO f4help_columns.


*

create info about column ANREX containing the descriptive text


CLEAR f4help_column.
f4help_column-fieldname = 'ANREX'.
f4help_column-headertitle = 'Form of address'.

"use text-symbol instead

APPEND f4help_column TO f4help_columns.


field_catalog_wa-f4help_columns = f4help_columns.
APPEND field_catalog_wa TO field_catalogs.
ENDCASE.
ENDLOOP.
ENDMETHOD.

Repeat Fields: Output Conversion (Method


OUTPUT_TABLE_CONVERSION)
Definition
This method is the counterpart of method INPUT_TABLE_CONVERSION, introduced in the subsequent topic.
Implementation of this method is necessary only in cases where the infotype in question contains repeat fields and the generic functionality to process these
repeat fields (via Customizing) is neither suitable nor possible.

For an overview of the generic functionality for processing repeat fields, review the topic Repeat Field Screen Structures (Type LINE).

Use
The use of method OUTPUT_TABLE_CONVERSION closely corresponds to the use of method OUTPUT_CONVERSION. If the infotype to be processed contains
repeat fields, then method OUTPUT_CONVERSION is first called to process the non-repeat fields, followed by method OUTPUT_TABLE_CONVERSION, which is
called to process the repeat fields. Because the respective uses of these methods closely correspond to one another, the parameters within these methods are
essentially the same. Therefore, refer to the topic Output Conversion (Method OUTPUT_CONVERSION) for a summary of its parameters, which essentially
correspond to the parameters within the present method, OUTPUT_TABLE_CONVERSION.
Unlike method OUTPUT_CONVERSION, which converts one infotype structure into exactly one screen structure, method OUTPUT_TABLE_CONVERSION creates
several screen structure records one for each repeat field value. For this reason, the attributes of parameter SCREEN_STRUCTURES define it to have type
Table . Moreover, the parameter is defined to have the CHANGING attribute, which enables it to support the generic functionality for processing repeat fields. In
the event that the generic functionality is applied, parameter SCREEN_STUCTURES will already contain the records that this functionality correspondingly created.
For this reason, if the generic functionality is sufficient, then the implementation of method OUTPUT_TABLE_CONVERSION can be omitted. Alternatively, if
additional source code is desired to complement and enhance the generic functionality by providing additional data or field values then method
OUTPUT_TABLE_CONVERSION can be implemented to this end. The first example provided at the end of this topic illustrates sample source code that
complements and enhances the generic functionality.
In contrast, if the generic functionality is neither suitable nor possible for the infotype in question, and if no corresponding Customizing is defined, then parameter
SCREEN_STRUCTURES remains empty, and is passed without a value. Consequently, an implementation of method OUTPUT_TABLE_CONVERSION must
subsequently create the necessary entries. The second example provided at the end of this topic illustrates sample source code that would fulfill this requirement.
Finally, like method OUTPUT_CONVERSION, method OUTPUT_TABLE_CONVERSION also can be implemented to provide field attributes for example, readonly or mandatory for repeat fields. However, because method OUTPUT_TABLE_CONVERSION returns multiple records in parameter
SCREEN_STRUCTURES(rather than a single screen structure record), the field attributes for each of these records must be set separately. Therefore, for each
record in parameter SCREEN_STRUCTURES, a corresponding record must be returned in parameter FIELD_ATTRIBUTES. Moreover, a synonymous identifier
must be defined for each record in field OBJECT_KEY; this identifier serves to establish the link between parameters SCREEN_STRUCTURESand
FIELD_ATTRIBUTES.

Special attention must be paid to field OBJECT_KEY of parameter SCREEN_STRUCTURES. If the generic functionality is applied, then the system

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

Page 65 of 75

will accordingly pass records in parameter SCREEN_STRUCTURES, and field OBJECT_KEY already will be correctly defined for each record.
However, if the generic functionality is not applied meaning that output table conversion is implemented manually then a unique OBJECT_KEY
value must exist for each record created in parameter SCREEN_STRUCTURES. In either case, whether or not the generic functionality is applied,
exactly the same OBJECT_KEY value must be used in the corresponding record that is created to specify the field attributes in parameter
FIELD_ATTRIBUTES.

Example
The first example below illustrates sample source code that complements and enhances the generic functionality, while the second example illustrates sample
source code to create the necessary entries in parameter SCREEN_STRUCTURES when the generic functionality is neither suitable nor possible for the infotype in
question, and when no corresponding Customizing has been defined.

The following example demonstrates an implementation of method OUTPUT_TABLE_CONVERSION for the Basic Pay infotype (0008) by means
of screen structure HCMT_BSP_PA_XX_R0008_LIN_A. In this example, table T588AUTO_MAP has been customized in the same manner
described in the example within the topic Repeat Field Screen Structures (Type LINE).
In this example, the generic functionality for processing repeat fields has already created records to be passed in parameter
SCREEN_STRUCTURES. Consequently, entries have already been filled in the fields Wage Type (LGART), Amount (BETRG), Number
(ANZHL), Indicator for Indirect Valuation (INDBW) and Operation Indicator for Wage Types (OPKEN). The Currency Key field (WAERS),
however, has not yet been filled, because it is not a repeat field. The following source code excerpt therefore demonstrates how this non-repeat
field can be filled for each record in parameter SCREEN_STRUCTURES. This excerpt also illustrates how the field attributes can be set.
METHOD IF_HRPA_UI_CONVERT_STANDARD~OUTPUT_TABLE_CONVERSION.
FIELD-SYMBOLS <p0008> TYPE p0008.
FIELD-SYMBOLS <hcmt_bsp_pa_xx_r0008_lin_a> TYPE hcmt_bsp_pa_xx_r0008_lin_a.
DATA field_attribute TYPE hrpad_field_attribute.
DATA field_attribute_wa TYPE hrpad_obj_field_attribute.

is_ok = if_hrpa_ui_convert_standard~true.
CLEAR field_attributes.

* ensure that method is called for the correct screen structure


IF screen_structure_name <> 'HCMT_BSP_PA_XX_R0008_LIN_A'.
RAISE EXCEPTION TYPE cx_hrpa_violated_assertion.
ENDIF.

* assign and type structure


ASSIGN pnnnn TO <p0008>.

* process all records automatically created by T588AUTO_MAP and T588AUTO_TABLE customizing


LOOP AT screen_structures ASSIGNING <hcmt_bsp_pa_xx_r0008_lin_a>.
CHECK <hcmt_bsp_pa_xx_r0008_lin_a> IS NOT INITIAL.
*

set the currency of the wage type amount


IF <hcmt_bsp_pa_xx_r0008_lin_a>-betrg IS NOT INITIAL.
<hcmt_bsp_pa_xx_r0008_lin_a>-waers = <p0008>-waers.
ENDIF.

for each record we have to create field attributes


CLEAR field_attribute_wa.
field_attribute_wa-object_key = <hcmt_bsp_pa_xx_r0008_lin_a>-object_key.

set field WAERS to readonly


CLEAR field_attribute.
field_attribute-field_name = 'WAERS'.
field_attribute-field_property = if_hrpa_ui_convert_standard~read_only.
APPEND field_attribute TO field_attribute_wa-field_attribute.

set field LGART to mandatory


CLEAR field_attribute.
field_attribute-field_name = 'LGART'.
field_attribute-field_property = if_hrpa_ui_convert_standard~obligatory.
APPEND field_attribute TO field_attribute_wa-field_attribute.
APPEND field_attribute_wa TO field_attributes.
ENDLOOP.

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

Page 66 of 75

ENDMETHOD.

Assume in the following example that no Customizing has been performed for the repeat fields unlike the previous example. In this case, the
implementation of method OUTPUT_TABLE_CONVERSION must create all screen structure records with unique object keys, as illustrated in the

source code excerpt shown below.


METHOD IF_HRPA_UI_CONVERT_STANDARD~OUTPUT_TABLE_CONVERSION.
DATA field_attribute TYPE hrpad_field_attribute.
DATA field_attribute_wa TYPE hrpad_obj_field_attribute.
DATA hcmt_bsp_pa_xx_r0008_lin_a TYPE hcmt_bsp_pa_xx_r0008_lin_a.
DATA object_key_index TYPE i.
DATA p0008 TYPE p0008.

is_ok = if_hrpa_ui_convert_standard~true.
CLEAR screen_structures.
CLEAR field_attributes.

* ensure that method is called for the correct screen structure


IF screen_structure_name <> 'HCMT_BSP_PA_XX_R0008_LIN_A'.
RAISE EXCEPTION TYPE cx_hrpa_violated_assertion.
ENDIF.
p0008 = pnnnn.
DO 40 TIMES
VARYING hcmt_bsp_pa_xx_r0008_lin_a-lgart
FROM p0008-lga01 NEXT p0008-lga02
VARYING hcmt_bsp_pa_xx_r0008_lin_a-betrg
FROM p0008-bet01 NEXT p0008-bet02
VARYING hcmt_bsp_pa_xx_r0008_lin_a-anzhl
FROM p0008-anz01 NEXT p0008-anz02
VARYING hcmt_bsp_pa_xx_r0008_lin_a-indbw
FROM p0008-ind01 NEXT p0008-ind02
VARYING hcmt_bsp_pa_xx_r0008_lin_a-opken
FROM p0008-opk01 NEXT p0008-opk02.
*

reset currency and object key


CLEAR hcmt_bsp_pa_xx_r0008_lin_a-waers.
CLEAR hcmt_bsp_pa_xx_r0008_lin_a-object_key.

make sure that this is not an empty record


CHECK hcmt_bsp_pa_xx_r0008_lin_a IS NOT INITIAL.

set object key


ADD 1 TO object_key_index.
hcmt_bsp_pa_xx_r0008_lin_a-object_key = object_key_index.

set the currency of the wage type amount


IF hcmt_bsp_pa_xx_r0008_lin_a-betrg IS NOT INITIAL.
hcmt_bsp_pa_xx_r0008_lin_a-waers = p0008-waers.
ENDIF.
APPEND hcmt_bsp_pa_xx_r0008_lin_a TO screen_structures.

create field attributes for each record


CLEAR field_attribute_wa.
field_attribute_wa-object_key = hcmt_bsp_pa_xx_r0008_lin_a-object_key.

set field WAERS to readonly


CLEAR field_attribute.
field_attribute-field_name = 'WAERS'.
field_attribute-field_property = if_hrpa_ui_convert_standard~read_only.
APPEND field_attribute TO field_attribute_wa-field_attribute.

set field LGART to mandatory


CLEAR field_attribute.
field_attribute-field_name = 'LGART'.
field_attribute-field_property = if_hrpa_ui_convert_standard~obligatory.
APPEND field_attribute TO field_attribute_wa-field_attribute.
APPEND field_attribute_wa TO field_attributes.

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

Page 67 of 75

ENDDO.
ENDMETHOD.

Repeat Fields: Input Conversion (Method


INPUT_TABLE_CONVERSION)
Definition
This method is the counterpart of method OUTPUT_TABLE_CONVERSION, introduced in the previous topic. However, one substantive difference exists between
this method and its counterpart; whereas method OUTPUT_TABLE_CONVERSION is called only once to provide all screen structure records for the repeat fields in
question, method INPUT_TABLE_CONVERSIONis called separately for each screen structure record. Each record is passed in parameter SCREEN_STRUCTURE,
while the Number of Table for Master Data parameter (TABNO) indicates the index of the record that is, the position of the record in table
SCREEN_STRUCTURES at the time that it was provided in method OUTPUT_TABLE_CONVERSION.

Use
When implementing method INPUT_TABLE_CONVERSION, one must update the repeat field(s) with the number(s) correspondingly indicated in parameter
TABNO of structure Pnnnn. If the generic functionality for this purpose is applied, then all repeat fields are updated automatically. If the generic functionality is not
applied, then all repeat fields must be updated manually.
Before calling method INPUT_TABLE_CONVERSION, the framework first calls method INPUT_CONVERSION to convert all non-repeat fields. Thus, when method
INPUT_TABLE_CONVERSION is called the first time, parameter PNNNN already contains the updated non-repeat fields. As a result, within the implementation of
INPUT_TABLE_CONVERSION, one is only allowed to modify the repeat fields in structure Pnnnn that correspond to the index passed in parameter TABNO. All
other repeat fields must remain unchanged.

Example
The following source code excerpt demonstrates a sample implementation of method INPUT_TABLE_CONVERSION. This example assumes that no Customizing
has been performed for the repeat fields, so that the implementation must manually convert the contents of the screen structure fields, for storage, to the format of
the repeat fields in structure Pnnnn. Note that this example is the counterpart to the second example found within the topic Repeat Fields: Output Conversion
(Method OUTPUT_TABLE_CONVERSION

METHOD IF_HRPA_UI_CONVERT_STANDARD~INPUT_TABLE_CONVERSION.
DATA hcmt_bsp_pa_xx_r0008_lin_a TYPE hcmt_bsp_pa_xx_r0008_lin_a.
DATA p0008 TYPE p0008.
DATA lgart TYPE lgart.
DATA betrg TYPE pad_amt7s.
DATA anzhl TYPE anzhl.
DATA indbw TYPE indbw.
DATA opken TYPE opken.

is_ok = if_hrpa_ui_convert_standard~true.

* ensure that method is called for the correct screen structure


IF screen_structure_name <> 'HCMT_BSP_PA_XX_R0008_LIN_A'.
RAISE EXCEPTION TYPE cx_hrpa_violated_assertion.
ENDIF.
p0008 = pnnnn.
hcmt_bsp_pa_xx_r0008_lin_a = screen_structure.
* find the correct repeat field number according to TABNO
DO 40 TIMES
VARYING lgart FROM p0008-lga01 NEXT p0008-lga02
VARYING betrg FROM p0008-bet01 NEXT p0008-bet02
VARYING anzhl FROM p0008-anz01 NEXT p0008-anz02
VARYING indbw FROM p0008-ind01 NEXT p0008-ind02
VARYING opken FROM p0008-opk01 NEXT p0008-opk02.
CHECK sy-index = tabno.
*

set repeat fields to values of screen structure


lgart = hcmt_bsp_pa_xx_r0008_lin_a-lgart.

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

Page 68 of 75

betrg = hcmt_bsp_pa_xx_r0008_lin_a-betrg.
anzhl = hcmt_bsp_pa_xx_r0008_lin_a-anzhl.
indbw = hcmt_bsp_pa_xx_r0008_lin_a-indbw.
opken = hcmt_bsp_pa_xx_r0008_lin_a-opken.
EXIT.
ENDDO.
pnnnn = p0008.
ENDMETHOD.

Automatically Retrieving Descriptive Texts


Use
The information that is stored in infotypes is mainly comprised of key values. To illustrate, entries in the Gender Key field (GESCH) are stored with the key value
of 1 to represent male employees, and the key value of 2 to represent female employees. However, the descriptive texts of Male and Female are not stored in
the infotype itself, but rather in a language-dependent text table. From a business logic (that is, back-end) perspective, the descriptive texts are of no importance.
From a user interface (that is, front-end) perspective, the descriptive texts are of great importance; when the infotype is represented in the UI, users expect to
view the corresponding descriptive texts, rather than the underlying key values.
To satisfy the fundamental requirement of displaying texts, rather than values, on the user interface, a corresponding field must exist in the screen structure for
every field in the infotype structure whose value is to be represented by a descriptive text. Once the screen structure fields are defined, the de-coupled framework
can fill them with the corresponding texts.
Because this fundamental requirement is shared by all infotypes, generic functionality is delivered with the de-coupled framework to retrieve descriptive texts
automatically. The present topic introduces this functionality, which relies on Customizing, and therefore greatly reduces the effort of implementing it.

Prerequisites
Two views are delivered in the standard system to determine Customizing for the automatic retrieval of descriptive texts. For all standard Customizing, which is
delivered by SAP, the Assignment of Text Fields for Generic Text Reader view (V_T588AUTO_TEXT) determines the automatic retrieval of descriptive texts.
For all customer-specific Customizing, the Assignment of Text Fields for Generic Text Reader (for Customers) view (V_T588AUTO_TEXTC) determines this
process. Customers are therefore required to maintain entries in the latter view if they wish to implement this approach, while SAP maintains the entries that are
delivered in the former view. To facilitate the necessary Customizing, the structure of each view is summarized below, along with an explanation of the fields
contained therein.
The following chart summarizes the three fields that, taken together, comprise the structure of the Assignment of Text Fields for Generic Text Reader (for
Customers) view (V_T588AUTO_TEXTC).
V_T588AUTO_TEXTC Fields
Field

Short Description

SCREENSTRUC

Name of Screen Structure

TEXTFIELD

Text Field in the Screen Structure

VALUEFIELD

Kay Field in the Screen Structure

In the Name of Screen Structure field (SCREENSTRUC), the name of the screen structure must be specified.
In the second and third fields of this view, you must respectively specify the name of the field in the screen structure that is to receive the descriptive text and the
name of the field in the screen structure that contains the key value.
The following chart summarizes the four fields that, taken together, comprise the structure of the Assignment of Text Fields for Generic Text Reader view
(V_T588AUTO_TEXT).
V_T588AUTO_TEXT Fields
Field

Short Description

SCREENSTRUC

Name of Screen Structure

TEXTFIELD

Text Field in the Screen Structure

VALUESTRUC

Structure Holding the Key Field

VALUEFIELD

Key Field in the Screen Structure

As a comparison of the two views will demonstrate, the structure of view V_T588AUTO_TEXT is almost identical to the structure of view V_T588AUTO_TEXTC,
with the exception of an additional field, Structure Holding the Key Field (VALUESTRUC). As in view V_T588AUTO_TEXTC, the first field of view
V_T588AUTO_TEXT contains the name of the screen structure, the second field contains the name of the field in the screen structure that is to receive the
descriptive text, while the fourth field contains the name of the field in the screen structure that contains the key value. In the third field of this view, one can
specify either the name of the screen structure in other words, the identical entry contained in the first field or the name of the infotype structure whose data,
during output conversion, is converted into screen structure format for representation on the user interface. No other entries are supported.
If you choose the first option and specify the name of the screen structure in Structure Holding the Key Field (VALUESTRUC), then the de-coupled framework
processes entries in views V_T588AUTO_TEXT and V_T588AUTO_TEXTC in an identical manner. In other words, the field that contains the key value

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

Page 69 of 75

(specified in VALUEFIELD) is understood to be part of the same screen structure.


If you choose the second option and specify the name of the infotype structure in Structure Holding the Key Field (VALUESTRUC), then the field that contains the
key value (specified in VALUEFIELD) is understood to be part of the infotype structure, rather than the screen structure. For this reason, the second option should
only be applied in exceptional cases; the field containing the key value customarily should be part of the screen structure.

In addition to the two views introduced above, a third view delivered in the standard system features Customizing entries that influence automatic
text retrieval. However, the entries in the third view are exclusively determined by SAP. The third view therefore cannot be modified in customer
systems, but is nonetheless introduced below for reference.
In the standard system, the Assignment of Data Elements to Determine Fixed Texts view (V_T588FIX_TEXT) is used to specify any field of a
screen structure that is to be filled with a fixed text. The fixed text, in turn, is retrieved via the specified data element or the corresponding fixed
domain values.
The following chart summarizes the three fields that, taken together, comprise the structure of the Assignment of Data Elements to Determine
Fixed Texts view (V_T588FIX_TEXT).
V_T588FIX_TEXT Fields
Field

Short Description

SCREENSTRUC

Name of Screen Structure

TEXTFIELD

Text Field in the Screen Structure

FDTEL

Data Element (Semantic Domain)

As in the prior two views, you must respectively specify in TEXTFIELD and SCREENSTRUC the name of the field and the corresponding screen
structure to ensure that that field receives a fixed text. This field is assumed to be defined, within the screen structure, by the data element
specified in FDTEL. In other words, the data element stored in FDTEL defines the fixed text that will be retrieved for the field entered in
TEXTFIELD.
In accordance with this principle, if PAD_CURRE ( Payroll Currency ) is the data element specified in field FDTEL, then the system will
automatically retrieve and display the text for example USD or EUR that is associated with the payroll currency assigned to the employee. For
all other data elements specified here, the system will derive texts first by retrieving the name of the domain that is used for the specified data
element, then by retrieving the fixed values that are defined for that domain. The text of the first fixed value is subsequently retrieved and
displayed in the screen structure field.
To illustrate, if data element PAD_PRCNT ( Percentage ) is specified, then the system will retrieve and display %, while the data element
PAD_KMETRES { Unit (Kilometer) }, will lead the system to retrieve and display km, and so on.

For reference, you may elect to execute transaction code SE11 and review the domain fixed values of the data elements used in
V_T588FIX_TEXT.
As additional examples, three of the many standard entries delivered in the Assignment of Data Elements to Determine Fixed Texts view
(V_T588FIX_TEXT) are summarized below.
Standard V_T588FIX_TEXT Entries
SCREENSTRUC

TEXTFIELD

FDTEL

HCMT_BSP_PA_XX_R0006

ENTKM_SIGN

PAD_KMETRES

HCMT_BSP_PA_XX_R0007

PRCNT

PAD_PRCNT

HCMT_BSP_PA_XX_R0165

WAERS

PAD_CURRE

Procedure
During the automatic retrieval of descriptive texts, the system first evaluates whether Customizing has been performed in the Assignment of Text Fields for
Generic Text Reader (for Customers) view (V_T588AUTO_TEXTC). If such Customizing is present, then the system responds accordingly. If no such
Customizing is present, then the system reverts to the standard Customizing delivered in the Assignment of Text Fields for Generic Text Reader view
(V_T588AUTO_TEXT).
Once the appropriate view is determined, the system then applies generic functionality known as the text identifier to retrieve the necessary texts. (Several
standard applications, including SAP Query and Ad-hoc Query, use the text identifier themselves to retrieve descriptive texts automatically.) To this end, the text
identifier evaluates all Data Dictionary information that is available for the field that contains the key value and is specified in VALUEFIELD. As information in the
Data Dictionary for example, domain fixed values, foreign key relationships, check tables and text tables is evaluated, the system attempts to determine the
location where the text for this field is stored. If a text source is located, and if this text source contains a text for the given key value, then the text identifier extracts
and returns this text. The system, in turn stores this text in the screen structure field specified in TEXTFIELD.

If desired, you may execute the Test Report for Text Recognition (report RS_TEST_IDENTIFY_TEXT) to test the generic functionality provided by
the text identifier. The application help delivered with this report provides additional information about the manner in which the Data Dictionary is
evaluated and the descriptive texts are automatically retrieved.
In cases where the generic text retrieval functionality is not suitable, it is theoretically possible although not recommended manually to specify the descriptive
text in method OUTPUT_CONVERSION of the conversion class. A preferable and recommended approach is to enhance the text identifier by means of the
corresponding exception concept. By applying the exception concept, one can make use of the generic functionality for automatic text retrieval, yet simultaneously
derive texts that cannot otherwise be retrieved from the Data Dictionary. Moreover, the exception concept provides a decisive advantage over manual
specification of the descriptive text in the conversion class, because once an exception has been defined for the text identifier, that exception can always be reused by the text identifier, regardless of the application that is using it. The exception theoretically could be re-used within the text identifier itself.

A thorough description of the exception concept, including the manner in which exceptions are created, is delivered with the documentation for
interface IF_TEXT_IDENTIFIER.

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

Page 70 of 75

Result
By using the automatic retrieval of descriptive texts, as well as the text identifier and the corresponding exception concept, manual coding efforts are greatly
reduced, and a consistent presentation of data across all applications is guaranteed.

Example
The following example demonstrates an entry that could theoretically be found in a customer system in the Assignment of Text Fields for Generic Text Reader (for
Customers) view (V_T588AUTO_TEXTC).
Sample V_T588AUTO_TEXTC Entry
SCREENSTRUC

TEXTFIELD

VALUEFIELD

ZHCMT_BSP_PA_XX_R9001

FORM_OF_ADDRESS_TEXT

ANRED

Three of the many standard entries delivered in the Assignment of Text Fields for Generic Text Reader view (V_T588AUTO_TEXT) are summarized below.
Standard V_T588AUTO_TEXT Entries
SCREENSTRUC

TEXTFIELD

VALUESTRUC

VALUEFIELD

HCMT_BSP_PA_XX_R0001

KOSTX

HCMT_BSP_PA_XX_R0001

KOSTL

HCMT_BSP_PA_XX_R0001

COMP_NAME

P0001

BUKRS

HCMT_BSP_PA_XX_R0008_LIN_A

LGTXT

HCMT_BSP_PA_XX_R0008_LIN_A

LGART

Reusing International Conversion Classes


Use
In cases where various country-specific versions of an infotype exist alongside an international version, and provided that the international version of the infotype
fulfills the majority of country-specific requirements, it may be effective to reuse the functionality of the international infotypes conversion class within the countryspecific conversion class(es) of the country-specific infotype(s). This end is achieved by means of inheritance, whereby the country-specific conversion class
declares the international conversion class to be its superclass.

Prerequisites
An international conversion class can only be re-used if it has not been declared as final. In other words, among the properties of any international conversion
class to be re-used, the Final checkbox (VSEOCLASS-CLSFINAL) may not be selected.
If the international conversion class is not final and if you elect to re-use it, you must remember that your country-specific conversion class has inherited, and
therefore relies upon, the functionality provided by the international class. For this reason, it is important to remain in contact with the party who is responsible for
the international class, as you and that party must jointly agree upon its operation.
Finally, you should refrain from hard-coding the name of the international screen structure within the country-specific conversion class. Instead, the international
conversion class should use a public constant attribute (with type PAD_SNAME) to contain the name of the international screen structure. Only via this attribute
should the country-specific conversion class access the international screen structure.

This recommendation serves to prevent subsequent problems in the event that screen structures, at a later date, are exchanged within the
international conversion class.

Procedure
To reuse any international conversion class that fulfills the above prerequisites, proceed as follows.
1. Define the international conversion class as the superclass of the country-specific conversion class.
2. In the country-specific class, redefine methods OUTPUT_CONVERSION and INPUT_CONVERSION.
In the implementation of these methods, proceed as follows.
a. First, call the corresponding method of the international class (statement CALL METHOD super->) to process the international fields of the screen
structure.
b. Second, encode the country-specific functions accordingly.

Only encode the required country-specific functions within the methods of the country-specific conversion class. Never encode such functions in the
international conversion class!

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

Page 71 of 75

The following examples are provided to clarify the principles that undergird the output and input conversion methods. The first example demonstrates an
implementation of the output conversion method, while the second example demonstrates an implementation of the input conversion method. However, the
procedure that is used to perform both methods is analogous.

The following example demonstrates the implementation of the output conversion method of a country-specific conversion class that has inherited
the properties of an international conversion class. The international conversion class has been specified as the superclass of the country-specific
conversion class.
A public constant attribute has been defined for the international conversion class; this attribute contains the name of the (international) screen
structure for which the class was originally designed: A_SUPER_SCREEN_STRUCTURE_NAME with type PAD_SNAME and the constant value
'ZHCMT_BSP_PA_XX_R9001'.

METHOD IF_HRPA_UI_CONVERT_STANDARD~OUTPUT_CONVERSION.
DATA super_screen_structure TYPE REF TO data.
FIELD-SYMBOLS <super_screen_structure> TYPE ANY.
FIELD-SYMBOLS <p9001> TYPE p9001.
FIELD-SYMBOLS <zhcmt_bsp_pa_us_r9001> TYPE zhcmt_bsp_pa_us_r9001.

is_ok = if_hrpa_ui_convert_standard~true.
CLEAR field_attributes.

* ensure that method is called for the correct screen structure


IF screen_structure_name <> 'ZHCMT_BSP_PA_US_R9001'.
RAISE EXCEPTION TYPE cx_hrpa_violated_assertion.
ENDIF.

* create international screen structure


CREATE DATA super_screen_structure TYPE (a_super_screen_structure_name).
ASSIGN super_screen_structure->* TO <super_screen_structure>.

* call output conversion of the international class


CALL METHOD super->if_hrpa_ui_convert_standard~output_conversion
EXPORTING
mode

= mode

screen_structure_name = a_super_screen_structure_name
pnnnn

= pnnnn

pnnnn2
pref

= pnnnn2
= pref

massn

= massn

massg

= massg

field_metadatas

= field_metadatas

message_handler

= message_handler

IMPORTING
screen_structure
is_ok

= <super_screen_structure>

= is_ok

field_attributes

= field_attributes.

* exit in case of error


IF is_ok = if_hrpa_ui_convert_standard~false.
RETURN.
ENDIF.
* move values from international to country-specific screen structure
MOVE-CORRESPONDING <super_screen_structure> TO screen_structure.

* *************************************
* the country-specific part starts here
* assign and type structures
ASSIGN pnnnn TO <p9001>.
ASSIGN screen_structure TO <zhcmt_bsp_pa_us_r9001>.
...
* place any country-specific coding here
...

ENDMETHOD.

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

Page 72 of 75

The following example demonstrates the implementation of the corresponding input conversion method.
METHOD IF_HRPA_UI_CONVERT_STANDARD~INPUT_CONVERSION.
DATA super_screen_structure TYPE REF TO data.
FIELD-SYMBOLS <super_screen_structure> TYPE ANY.
FIELD-SYMBOLS <p9001> TYPE p9001.
FIELD-SYMBOLS <zhcmt_bsp_pa_us_r9001> TYPE zhcmt_bsp_pa_us_r9001.

is_ok = if_hrpa_ui_convert_standard~true.

* ensure that method is called for the correct screen structure


IF screen_structure_name <> 'ZHCMT_BSP_PA_US_R9001'.
RAISE EXCEPTION TYPE cx_hrpa_violated_assertion.
ENDIF.

* create international screen structure


CREATE DATA super_screen_structure TYPE (a_super_screen_structure_name).
ASSIGN super_screen_structure->* TO <super_screen_structure>.
* move values from country specific to international screen structure
MOVE-CORRESPONDING screen_structure TO <super_screen_structure>.

* call input conversion of the international class


CALL METHOD super->if_hrpa_ui_convert_standard~input_conversion
EXPORTING
screen_structure_name = a_super_screen_structure_name
screen_structure
message_handler

= <super_screen_structure>
= message_handler

IMPORTING
is_ok

= is_ok

CHANGING
pnnnn

= pnnnn.

pnnnn2
pref

= pnnnn2
= pref

* exit in case of error


IF is_ok = if_hrpa_ui_convert_standard~false.
RETURN.
ENDIF.

* *************************************
* the country-specific part starts here
* assign and type structures
ASSIGN pnnnn TO <p9001>.
ASSIGN screen_structure TO <zhcmt_bsp_pa_us_r9001>.
...
* place any country-specific coding here
...

ENDMETHOD.

Assigning Conversion Classes to Screen Structures


Definition
As explained previously, screen structures contain all of the fields that are related to and required for displaying and editing the infotype in the user interface. For
this reason, data from infotype structures requires conversion into a format suitable for screen structures, and vice versa. This conversion is performed by means
of conversion classes.
The assignment of an individual conversion class to the corresponding screen structure is stored in the Assignment UI Structures and UI Conversion Classes
view (V_T588UICONVCLAS). The entries in this view thereby determine which conversion class will be applied to which screen structure(s). Each entry in this
view therefore constitutes a link between a screen structure and its corresponding conversion class. Therefore, an entry in this view is mandatory for every screen

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

Page 73 of 75

structure. If no entry exists in this view for the corresponding screen structure, then that screen structure cannot be used.

Use
To determine which conversion class belongs to a given screen structure, the system refers to view V_T588UICONVCLAS. If no special conversions are
required, then the default conversion class, CL_HRPA_UI_CONVERT_BASIC, is called. However, a corresponding entry must exist in this table for every screen
structure, even when the default conversion class CL_HRPA_UI_CONVERT_BASIC is called; otherwise, the screen structure cannot be used.

Structure
The following chart summarizes the five fields that, taken together, comprise the structure of the Assignment UI Structures and UI Conversion Classes view
(V_T588UICONVCLAS).
V_T588UICONVCLAS Fields
Field

Short Description

SNAME

Name of Screen Structure

INFTY

Infotype

STYPE

Type of Screen Structure

VERSIONID

ID for Infotype Versions

CLSNAME

Name of Specific Conversion Class

Among these five fields, only the Name of Screen Structure field (SNAME) is a key field.
The Infotype field (INFTY) denotes the four-digit number assigned to the infotype at hand. When maintaining entries in this view, you must specify in this field the
infotype number to which the corresponding screen structure is assigned.
The Type of Screen Structure field (STYPE) indicates whether the screen structure at hand is of type MAIN or type LINE. When maintaining entries here, you
must specify the type of screen structure at hand. In the majority of cases, type MAIN will be specified in this field. However, if the screen structure in question is
designed to process repeat fields, then type LINE must be specified.
The ID for Infotype Versions field (VERSIONID) represents the version of the infotype at hand. When maintaining entries, you must specify in this field the
infotype version to which the screen structure is assigned.

The following entries demonstrate examples of infotype versions that could be entered in this field:
06 France
10 United States
99 International
FP France Public Sector
UP United States Public Sector

The Name of Specific Conversion Class field (CLSNAME) denotes the name of the conversion class that is assigned to the screen structure at hand. Therefore,
in this field, you must specify the conversion class to which the screen structure is assigned. In essence, this field will contain either
CL_HRPA_UI_CONVERT_BASIC the default conversion class, which enables a variety of generic functionality, as described in the topic Conversion Classes
or a dedicated conversion class of your own.

Example
The following example demonstrates certain entries that could theoretically be found in a customer system in the Assignment UI Structures and UI Conversion
Classes view (V_T588UICONVCLAS).
Sample V_T588UICONVCLAS Entries
SNAME

INFTY

STYPE

VERSIONID

CLSNAME

HCMT_BSP_PA_XX_R0001

0001

MAIN

99

CL_HRPA_UI_CONVERT_0001_X
X

HCMT_BSP_PA_XX_R0002

0002

MAIN

99

CL_HRPA_UI_CONVERT_0002_X

HCMT_BSP_PA_US_R0002

0002

MAIN

10

HCMT_BSP_PA_XX_R0006

0006

MAIN

99

CL_HRPA_UI_CONVERT_BASIC

ZHCMT_BSP_PA_XX_R9001

9001

MAIN

99

ZCL_HRPA_UI_CONVERT_9001_

ZHCMT_BSP_PA_XX_R9002

9002

MAIN

99

CL_HRPA_UI_CONVERT_BASIC

HCMT_BSP_PA_XX_R0008_LIN_ 0008

LINE

99

CL_HRPA_UI_CONVERT_0008_X

X
CL_HRPA_UI_CONVERT_0002_U
S

XX

A
HCMT_BSP_PA_US_R0008_LIN_ 0008

X
LINE

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

10

CL_HRPA_UI_CONVERT_0008_U
S

Page 74 of 75

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

Page 75 of 75