Developing an Infotype in Personnel Administration

Developing an Infotype in Personnel AdministrationPDF 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 and delete this data using infotypes. Some subobjects must be edited. Prerequisites To be able to enhance a standard infotype or create a customer-defined infotype. For more information. 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. the visual display of the data (ABAP screens). ● 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. There are also some infotypes that are used in both application areas. 1. Transaction PM01 Create Infotype is a tool that both customers and SAP can use to develop new infotypes and to enhance standard infotypes. see Decoupling Infotypes. With infotypes created using the new method. The data stored in an infotype is always based on the personnel number of an employee or the applicant number of an applicant. a conversion class is created that formats the business logic data for display in the user interface. as well as experience using the Screen Painter and ABAP Dictionary . For the interface-relevant elements of the infotype. an industry-specific infotype. ● Enhance the list screen of a standard infotype and delete enhancement. an infotype is an input screen for creating employee-related data and business data belonging together.1 Decoupling Infotypes There is an old method and a new method for creating and defining infotypes. You can create fields you want to be displayed in the infotype but are not saved in the database. see Conversion Class. or an infotype for the public sector of a country. The system automatically creates the necessary subobjects in the background. change. This transaction allows you to enhance and modify standard SAP infotypes. ● Create infotype version An infotype version can be a country-specific infotype. Infotypes that are created using the new method are also known as "decoupled" infotypes. ● Enhance a screen structure of an infotype and delete enhancement. an infotype is a data structure.1. New infotypes that you create using transaction PM01 should be decoupled. There are infotypes that are only used in Personnel Administration and infotypes that are only used in Recruitment. delimit. and create your own infotypes. the check class is addressed by the infotype framework. The user can create. PUBLIC © 2014 SAP SE or an SAP affiliate company. see Structure and Task of the Screen Structure. copy. you must have knowledge in ABAP programming. For more information. The new method does away with the previous close link between the business logic and the user interface. 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. In other words. This number uniquely identifies an infotype. All rights reserved. ● Delete customer-defined infotype 1. Technically speaking. From the user's perspective. These infotypes are known as "decoupled" infotypes. The infotype-specific business logic for decoupled infotypes is programmed in ABAP Objects classes instead of in the module pool. an infotype data record is always assigned to exactly one employee or applicant. that is. see Assigning Conversion Classes to Screen Structures.Developing an Infotype in Personnel Administration Use Infotypes are used in Personnel Administration and Recruitment. A check class is created for each infotype.1 Infotype Concept An infotype is a group of object-based pieces of information on a particular area. For more information. The number range 9000 to 9999 is reserved for customer infotypes. ● Enhance the single screen of a standard infotype and delete enhancement. Page 4 of 75 . ● 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. such as: ● Personal Data (Infotype 0002) ● Addresses (Infotype 0006) ● Internal Communication (Infotype 0105) Each infotype is indicated by a four-digit number nnnn . there is a strict separation between business logic and user interface-relevant elements. For more information. Infotypes are units of information in the SAP system that are grouped together as a set of data fields. For more information. For more information. ● Structure HCMT_BSP_PA_yy_Rnnnn (for country-specific infotypes) or HCMT_BSP_PA_XX_Rnnnn ( for international infotypes) Generally. Transparent table PBnnnn is required if you want to use the infotype in Recruitment. see Migrating an Infotype. Both versions are supported.● Check class CL_HRPA_INFOTYPE_nnnn for a standard infotype or ZCL_HRPA_INFOTYPE_9nnn for a customer-specific infotype. non-decoupled. To enhance a screen structure. PA9nnn. visual patterns. as well as additional fields that are displayed on the user interface of the infotype. Create Infotype . PS9nnn. you must decouple them retroactively. Infotypes created using the old method can still be used. When you create a new infotype. PUBLIC © 2014 SAP SE or an SAP affiliate company. PB9nnn. screen structure HCMT_BSP_PA_yy_Rnnnn is automatically created as a copy of structure PSnnnn . new graphic elements. However. the infotype must be decoupled. see Structure and Task of the Screen Structure. ● Transparent table PAnnnn and/or transparent table PBnnnn Transparent table PAnnnn is required if you want to use the infotype in Personnel Administration. 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. ● 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. To do this. see Check Classes. To benefit from the advantages of decoupling for existing. Page 5 of 75 . see: ● Business Logic Guidelines for Creating and Migrating Infotypes ● UI Programming Guidelines for Infotypes Transaction PM01. choose the Enhance Screen Structure tab page in the Create Infotype transaction (PM01). 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. customer-specific infotypes and non-decoupled enhancements of standard infotypes. but it is advisable. In accordance with the distribution of infotype name ranges. newer applications such as some ESS scenarios or the HR Administrative Services are based on the decoupled infotype framework. Structure and Task of Data Field Structure PSnnnn Definition Structure containing infotype data fields that are to be saved in the infotype. It is not mandatory to convert infotypes to the new method. All rights reserved. When you create a new infotype. see Developing an Infotype. supports the creation and enhancement of decoupled infotypes. 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). you must edit it manually. For more information and detailed notes for experts. changed user guidance. You want to develop an international infotype with the number 9900to be used in Personnel Administration only. objects P9nnn. Whether or not the infotype is decoupled is irrelevant for the transaction for maintaining HR master data (PA30). Both structures are initially identical. For more information. ● Structure Pnnnn Structure Pnnnn contains infotype key fields and all of the data fields from structure PSnnnn . This means that if you want to use a customer-specific infotype within this framework. and ZHCMT_BSP_PA_yy_R9nnn are assigned to the customer name range. and can only process decoupled infotypes. 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. you should therefore always create a decoupled infotype. screen structure HCMT_BSP_PA_yy_Rnnnn contains all the fields of data field structure PSnnnn . The data fields are grouped together in structure PSnnnn to keep the definition as free of redundancy as possible. 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).INCLUDE PSnnnn Table PBnnnn Field Name Key Data Element Type Length Check Table Short Text MANDT X MANDT CLNT 3 T000 Client . you must assign structure PSnnnn a duplicate of key field Pnnnn-SUBTY in which the subtype is then stored. ● If you want to use your infotype in Recruitment . use the data types NUMC and DEC. This field requires its own name and data element. ● If you want to use your infotype in Personnel Administration and Recruitment .INCLUDE X PBKEY . You must also specify which of the database tables you want to use in the Infotypes: Dialog/Database Assignment table (T777D). see Infotype Characteristics. INT4) or floating point number data types (FLTP) for the fields of the data field structure PSnnnn. 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 both tables PAnnnn and PBnnnn .INCLUDE PSHD1 . For more information.2.2 Structure and Task of Tables PAnnnn and PBnnnn Definition Transparent database tables that store the data records for the infotype nnnn . All rights reserved. Do not use integer data types (INT1. ● Duplicate fields for subtypes ○ If you want to divide an infotype into subtypes. Structure ● Customer include The Personnel Administration and Recruitment infotypes contain a customer include CI_Pnnnn in the data field structure PSnnnn. The user can then make entries in this field. 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. You must include the duplicate subtype field in the appropriate infotype screens. ■ 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.Use The fields are required when the infotype’s data structures and database tables are defined. Instead. This is then an enhancement of a standard SAP infotype. INT2.1. create table PAnnnn . 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.INCLUDE PSnnnn PUBLIC © 2014 SAP SE or an SAP affiliate company.INCLUDE PSHD1 . Structure PSnnnn can then be used as a substructure when other structures and tables are defined in the ABAP Dictionary. You can include your customer fields in this include.INCLUDE X PAKEY . Page 6 of 75 . Structure Table PAnnnn Field Name Key Data Element Type Length Check Table Short Text MANDT X MANDT CLNT 3 T000 Client . Otherwise the infotype cannot be used. create table PBnnnn . For information about infotype module pools. It is rarely necessary to create secondary indices. Use The screen structure is used to display data on the user interface that is derived from the relevant database. or descriptive texts. 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 . Structure and Task of Structure Pnnnn Definition Structure containing the data fields of structure PSnnnn. All fields from structure PSnnnn are automatically copied to the screen structure. Report RPUAUD00 enables you to display these documents. You can enhance this structure. the system creates the relevant screen structure in the background. Tables PAnnnn and PBnnnn may not be buffered using the SAP database interface because the application programs must always work with current data. It is rarely necessary to log data changes within the ABAP Dictionary. 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. It serves as an interface between the program and the database. For this reason. you must select the Buffering not allowed checkbox in the Buffering frame. you must estimate the number of expected data records and then specify a suitable size category. There are differences in the included key fields ( PSKEY instead of PAKEY and PBKEY ). When you create a new standard infotype or a customer infotype. The value of the size category can vary. When determining the logical memory parameters. For information about using infotypes in reports.The definition of the primary key is the only difference between the structure of the two tables. output fields. the Client field is not required in this structure. All rights reserved. see Infotype Module Pool. For this reason. Customer infotypes are automatically included in the logical databases PNP and PNPCE. Page 7 of 75 . You can enter changes to infotype records in the form of change documents using the infotype log creation function in Personnel Management . You must define a component in the screen structure for each element you want to appear on the user interface for the infotype. but not saved on the database. Furthermore. Use Structure Pnnnn is used in reporting and in the infotype module pools. they are distinguished by the suffix _z (see "Naming Convention" ). 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. irrespective of the ABAP Dictionary settings. Infotype data records are buffered in the Personnel Management applications. The data can be input fields. see the Logical Database section under Programming Reports in HR . enter the value APPL0 in the Data class field. The primary key is determined on the basis of the Client field and substructures PAKEY and PBKEY . Naming Convention PUBLIC © 2014 SAP SE or an SAP affiliate company. Technical Settings of Database Tables Database tables are read using the primary index. depending on how the infotype is used. and also data fields that feature in all infotypes. These methods also have the same function as the standard PUBLIC © 2014 SAP SE or an SAP affiliate company. Use Screen structures contain all interface-relevant fields of an infotype that can be displayed or edited on the user interface.1. All rights reserved. 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). This function is taken on by the conversion class (see example). 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 . Therefore. 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.3 Conversion Class Definition Class that converts screen structures to structures that can be interpreted by the business logic (processing logic). ● Screen control functions such as determining the field attributes of screen fields. see: Screen Structures Infotype Screen Structures (Type MAIN) Repeat Field Screen Structures (Type LINE) 1. Page 8 of 75 . the fields of an infotype structure must be converted to a relevant format. ● Enhanced conversion classes that use the interface IF_HRPA_UI_CONVERT_ADVANCED This interface contains enhanced conversion methods that transfer the entire infotype container. and PREF (cost center assignment).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. Each infotype uses at least one conversion class. Different country versions use different conversion classes. 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. Page 9 of 75 . All rights reserved. see Assigning Conversion Classes to Screen Structures. for example.conversion methods. see the sections on Conversion Classes. For more information. in three separate fields: ● Current Date ● Name of month ● Year PUBLIC © 2014 SAP SE or an SAP affiliate company. You make the assignment in view V_T588UICONVCLAS (Assignment of Screen Structure to Conversion Class). For detailed information about using conversion classes. You must specify which conversion class should be used for each screen structure. and subroutines. Page 10 of 75 . PBO and PAI modules. You must store these modules separately in their own includes for the data definition. There is a module pool for each infotype. which is assigned in table T500L Country Grouping for HR Management to the appropriate country grouping . If you create the main program using transaction Create Infotype (PM01). They are used by the module pools for all infotypes. at the end of the name of the corresponding include.1. You then enter the HR country indicator . 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. P stands for Human Resources (personnel).1.4 Infotype Module Pool Definition Framework program for the user interface of an infotype. Do not change these includes. 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. The variables specified in this area are used as export or import parameters when the infotype dialog module is accessed. 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. Includes for infotypes with country-specific features Many infotypes require modules that apply to just one country.1. Structure Infotype-specific includes The main program only contains INCLUDE statements. All rights reserved.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. and nnnn is the four-digit infotype number. The name of the program is MPnnnn00 . 1. Possible entries for screen fields The system displays possible entries for all of the fields whose entry is checked against a table. Screen control Screen control provides options for modifying the interface.1. All rights reserved. Page 11 of 75 . You must always create the initial screen using the Create Infotype transaction (PM01) . The initial screen is processed in the background. for example. It is sufficient to include the tables in the TABLES statement. Do not change the initial screen. 1. Screen 2000 of module pool MPMMMM00 is used as a model for the single screen.1.5. 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. Customer-specific single screens are assigned to the name range 2900 to 2999. that is. Entry checks The values of the Organizational Assignment infotype (0001) that are valid at the beginning of the record’s validity period. PUBLIC © 2014 SAP SE or an SAP affiliate company. 1. You can create your own single screens for infotypes included in the standard system.2 Single Screen Definition The actual interface between the infotype and the user. Additional single screens or list screens are used in Personnel Administration to adapt an infotype screen to the requirements of a particular country.● A list screen It is possible to modify the screen control to replace the single or list screen with alternative screens. However. you can choose to use a different screen as a single screen. 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. the system displays possible entries automatically. Use Screen 1000 is used as the initial screen for all infotypes. The system then creates an initial screen with all of the functions required. It is accessed using the dialog module for the relevant infotype. enable you to carry out infotype-specific entry checks.5. Screen 1000 of module pool MPMMMM00 is used as a template. as well as the entries in the tables listed below that are valid in structure PSYST. Do not use the values in structures P0001 or P0002 .1 Initial Screen Definition Interface between the Human Resources transactions and the infotype from a technical perspective. These structures are used internally and are not always initialized. If you assign a check table that can be checked automatically to a field within the ABAP Dictionary. This enables you to use different single or list screens for an infotype. ● ● ● ● 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. For more information. the screen is not displayed while the flow control is executed. see Infotype Screen Control. and the date on which the last change was made 6 Empty line Infotype-specific fields are included in lines 7 to 21. ● The hidden_data_subscreen module must be the last module included in the PBO. 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. for example. ● The input_status_subscreen must be included as the first module of the PAI. may appear above the first frame. If wage types are valuated indirectly. a new PBO must be triggered on the single screen before the last module. ● The modify_subscreen module must be included as the first module of the PBO. module input_status_subscreen on chain-request. Page 12 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 4 Empty line 5 FROM date.2. MODULE get_t582c_subscreen. function code is processed directly from GUI). MODULE modify_subscreen..Note the following dependencies: You must include three modules in the flow logic of the tab strip control subscreen. The infotypes in the standard system then contain an include screen for customer enhancements. all maintainable fields . MODULE get_header_subscreen. CALL SUBSCREEN subscreen_header INCLUDING header_prog header_dynnr... endchain.. Subscreen specific PAI Module . process before output. chain. the last person to make a change.. All rights reserved. to fill the screen fields stored in structures Qnnnn and Znnnn .. text field. MODULE hidden_data_subscreen. field: . lock field... TO date. the system prepares the flow logic. They enable you. The screen field that contains the subtype assigned to the infotype.The modules are in the include MPPERS00. 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. MODULE HIDDEN_DATA. however. You can carry out infotype-specific initialization procedures within PBO module Pnnnn . If this is not possible because validations are to take place when scrolling between the different screens. The flow logic of infotypes in the SAP standard system usually follows this pattern: Action PBO PROCESS BEFORE OUTPUT. 1. Otherwise the fcode function code field is deleted in the post_input_checks module. * ..1 Flow Logic of Single Screen If you create the single screen for the infotype using the Create Infotype transaction (PM01). Tab Strips on the Single Screen You can include a tabstrip control on the single screen.. MODULE Pnnnn. process after input. That way a PAI is not triggered when scrolling.1.. 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. CALL SUBSCREEN subscreen_t582c INCLUDING subscr_prog subscr_dynnr. MODULE BEFORE_OUTPUT. All of the screen fields must be included in one frame..5. * . Subscreen specific PBO Module . post_input_checks is executed. You can create your own list screens for infotypes included in the SAP standard system. Use Screen 3000 is usually used for the list screen. You must not change PBO modules BEFORE_OUTPUT and HIDDEN_DATA. 1. whether the start date of the infotype record is before the end date of the record. If you choose the Exit function. It also carries out general entry checks. At this point. For this reason.5. choose to use a different screen as the list screen. MODULE POST_INPUT_CHECKS. You must not change PAI modules EXIT . Once module PRE_INPUT_CHECKS has been processed. the infotype data record is to be saved later. FIELD Pnnnn-feld1. ■ 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.. Fields assigned to structure Pnnnn are usually displayed here. For example. You can. PAI module INPUT_STATUS sets internal system statuses..Tnnn-felda. Screen 3000 of module pool MPMMMM00 is used as a template. The system checks... CALL SUBSCREEN subscreen_t582c. PAI module INPUT_STATUS must be performed if the user makes an entry in a screen field.RP50M-SPRPS. All rights reserved. MODULE EXIT AT EXIT-COMMAND.3 List Screen Definition Infotype screen that displays all data records for a personnel number in a list. MODULE PRE_INPUT_CHECKS. however.. the system stops processing the current single screen. CHAIN. such as long texts. FIELD Pnnnn-feld1. Once the following process has been carried out. for example. you can add other fields for this purpose.1. ■ 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 must also list fields that are only displayed. CHAIN. in the list screen. PAI module PRE_INPUT_CHECKS is used to process the function code before the entry check. Action PAI PROCESS AFTER INPUT. PUBLIC © 2014 SAP SE or an SAP affiliate company. Page 13 of 75 . Customer-specific list screens are assigned to the namespace 3900 to 3999. MODULE INPUT_STATUS ON CHAIN-REQUEST.(0014) must be filled since the amount is not stored on the database. for example.. you can carry out your own entry checks or call up your own PAI modules. ● Lines 5 to 19 contain the list with the infotype data records. such as long texts. PRE_INPUT_CHECKS. PAI module POST_INPUT_CHECKS processes the function code after the entry checks. Structure The list screen is divided into three areas: ● Lines 1 to 3 display the header lines in an include screen. all of the entry fields in the following chain must be counted. ENDCHAIN. the entry checks must be complete up to PAI module POST_INPUT_CHECKS . ENDCHAIN. it is no longer possible to change field contents. . INPUT_STATUS . and POST_INPUT_CHECKS . If you want to display further information. if a value has been changed. You must list all the fields that appear on the single screen in the following chain. they are specified during runtime. subtype. This is the same module that is used for the single screen.4 Infotype Screen Control When you create single screens and list screens using the Screen Painter . MODULE PSLIST. If you do not use subtypes in the infotype. MODULE POST_INPUT_CHECKS. Page 14 of 75 . . or item in the list. FIELD RP50M-SUBTY. You can carry out infotype-specific initialization procedures within PBO module Pnnnn . BEFORE_OUTPUT . Action PAI PROCESS AFTER INPUT. You must not change PBO modules PSLIST_TC .1 Flow Logic of List Screen If you create the single screen for the infotype using transaction Create Infotype (PM01). and POST_INPUT_CHECKS. MODULE ADJUST_LIST_TC. MODULE BEFORE_OUTPUT. you can determine that a different PBO module is accessed. CHAIN.Infotype data records are displayed in one line in the list screen.CALL SUBSCREEN SUBSCREEN_HEADER INCLUDING HEADER_PROG HEADER_DYNNR. It is also possible that particular screen fields must be hidden. and RP50M-PAGEA ). If you create the list screen using the Create Infotype transaction (PM01). VARIATION_TC . RP50M-SUBTY . ASSIGN_TC3000 . 1.. LOOP. MODULE GET_HEADER_SUBSCREEN. depending on the employee’s organizational data. All rights reserved. 1. If you require different infotype-specific initialization procedures for the list screen. the same screen is always used for different functions such as creating. MODULE SELECT_FOR_LIST ON CHAIN-REQUEST. the system prepares the flow logic. PUBLIC © 2014 SAP SE or an SAP affiliate company. delimitation date. instead. MODULE ASSIGN_TC3000. MODULE Pnnnn. With the exception of the Delimitation Date field ( RP50M-ABGRD ). these fields should always be ready for input. ENDLOOP.1. MODULE VARIATION_TC. SELECT_FOR_LIST . The appearance of the screens changes depending on the function chosen by the user or the data being processed.. MARK . These fields allow the user to select infotype records in the list by validity period. RP50M-ENDDA . Fields assigned to structure Pnnnn are also included in the list screen. you cannot specify whether a screen field should be ready for input when you maintain the screen.5.5. FIELD RP50M-SELEC MODULE MARK ON REQUEST. MODULE EXIT AT EXIT-COMMAND. ENDLOOP. The flow logic of infotypes within the standard system usually follows this pattern: Action PBO PROCESS BEFORE OUTPUT. the system sets up the list screen automatically. maintaining.3. This module must be called PnnnnL. ● Line 20 contains the Selection fields ( RP50M-BEGDA . RP50M-ABGRD. delete field RP50M-SUBTY. You must not change PAI modules EXIT . LOOP. some attributes are not specified to be generally applicable. and GET_HEADER_SUBSCREEN. FIELD RP50M-BEGDA. However. FIELD RP50M-PAGEA ON REQUEST MODULE TOP_OF_LIST. FIELD RP50M-ENDDA. ENDCHAIN. For this reason.1. displaying. and deleting infotype records. In other words. The delimitation date in field RP50MABGRD should only be displayed on the list screen if the current function really is Delimit . you determine the attributes of individual screens fields. Modification group 4 is not used in the SAP standard system since it is reserved for customers. § 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. you must maintain value 01F in Modification Group 1 . If you use both of the above to effect screen control for a screen field. the setting that determines whether entries can be made or not is pre-specified for all infotypes. These functions read the values from the modification groups for individual screen fields and set their attributes in accordance with the values. Default Settings In the case of certain screen fields for single or list screens. For this reason. The meaning of the values for modification groups is determined in tables. In this case. screen control using the Infotype Screen Control table (T588M) has higher priority. You can also hide individual screen fields. or you can choose to hide screen fields. If you use this field. you should determine the ready-for-input status of the screen fields according to the function to be carried out. PUBLIC © 2014 SAP SE or an SAP affiliate company.§ The same single screens are used for the Display HR Master Data and Maintain HR Master Data functions. If the entry has not been made for a screen field. determine whether entries can be made in fields. depending on the function to be carried out. In this case. 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. the field is not ready for input. apart from displaying records. Note that you must maintain the value of Modification group 1 in hexadecimal form. Together with the Infotype Screen Control table (T588M). § You want to be able to make entries in a screen field for all functions. the attribute Modification Group 1 is assigned the value 00E for these fields. ● You can use alternative screens. Screen Control Based on Function to be Performed If screen control is effected depending on the function to be performed. the system enters the correct value in Modification Group 1 for these screen fields. If you create the single or list screen using the Create Infotype transaction (PM01). ● Entries can usually be made in the fields BEGDA and ENDDA for all actions. the value of Modification group 3 determines the activity and whether entries can be made in fields. 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 value in Modification group 1 controls whether the screen fields are ready for input. Page 15 of 75 . When you develop infotypes. This is done by adding the values. or hide screen fields using control data and the Infotype Screen Control table (T588M). The value for modification group 1 must be maintained for all input fields. For this reason. The screen fields must only be ready for input for the Maintain HR Master Data function. The value of Modification Group 1 must be maintained for all of the screen fields in which entries can be made. you can effect screen control as follows: ● You can determine whether entries can be made in fields. Modification group 2 is used internally. 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. § You want to be able to make entries in a screen field when the Add and Change functions are used. this counts as a modification of the SAP standard system. you must maintain value 006in Modification Group 1 . All rights reserved. Screen control functions have already been implemented in the main infotype program. Several constants can be combined. For this reason. If screen fields cannot be modified using table Infotype Screen Control (T588M). ● The list screen should allow entries to be made in the fields RP50M-BEGDA . you should also use transaction Create Infotype (PM01) to create the interface for your infotype.5 Infotype Interface Status The interface for single and list screens is standard for all infotypes. ● It is only possible to select multiple records on the list screen if the Display and Delimit functions are used. For this reason.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. Field RP50M-SELEC . For this reason. There are different types of screen control: ● General ● Dependant on the employee’s organizational data ● Dependant on the subtype for the infotype record. is assigned the value 009 for Modification Group 1 .5. assign the value SPACE in Modification group 3 . PUBLIC © 2014 SAP SE or an SAP affiliate company. Modification Group 1 is maintained using value 400. the same value is used as for the pertinent key word and a long text that may have been displayed. ● The delimitation date in field RP50M-ABGRD should only be displayed on the list screen if the current function really is to delimit. 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.1. 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. For this. In Modification group 3 .2 Screen Control Based on Control Data If screen control is effected depending on control data. 1. which is contained in a loop. A specific interface status is used depending on the function to be carried out.4.1. 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. the PBO module is accessed automatically by the flow logic of the infotype screens. It is also possible for particular menu options or function keys defined in the interface status to be deactivated when certain functions are used.● Modification Group 1 has the value 800 for the fields AEDTM and UNAME . you assign a value between 001 and 050 to each screen field. 1. Use the same value for screen fields that are modified in the same way. If you create your infotype using transaction Create Infotype (PM01). The interface status is set in a PBO module included in the standard system.5. Page 16 of 75 . You must specify the name of the module pool and the number of the initial screen for the infotype. These fields are assigned the value 00F because it must be possible to make an entry for each operation. ● You can hide individual screen fields. The dialog module is assigned to an infotype when the dialog module is maintained. The name of the dialog module must be RP_nnnn .1. maintain the value of Modification group 3 for the screen fields in question in the Screen Painter. In the case of an input/output field. 1. where nnnn stands for the number of the infotype. RP50M-ENDDA . All rights reserved. see the IMG documentation for Personnel Administration → Customizing User Interfaces → Change Screen Modifications . The infotype is assigned to the dialog module in the Infotypes Dialog/Database Assignment table (T777D). 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. RP50M-SUBTY and RP50M-PAGEA so that records can be selected. This ensures that these fields are hidden when a record is added. 1. T588M Table T588M enables you to adapt infotype interfaces using screen control. Tables T777D and T77ID are maintained automatically when the Create Infotype transaction (PM01) is used. The table used to store the subtype characteristics must be specified in table T582A as the subtype table. 1. time constraint.7 Infotype Characteristics Infotype characteristics are determined by entries stored in various tables. dialog module. and so on) T77ID Name of data field structure (PSnnnn) You can maintain tables T582A and T582S in view V_T582A. When you display or maintain an infotype record. user-specific screen control is also possible). proceed as follows: 1. These text modules are stored in file PCL1 under cluster ID TX . T588G Table T588G controls field-specific retroactive accounting. Tables that are maintained for all infotypes Name of table Task T582A Basic infotype characteristics (single screen. simply adjust the single screen in question. The first three lines of text on the single screen for infotype 0019 Monitoring of Dates are displayed or can be maintained. You can use transaction PM01 Create Infotype to maintain basic infotype characteristics and set up infotype menus. 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. you can display or maintain the text for the record. RP50M-TEXT2 . All rights reserved. You can use a different table instead of table T591A. the Text allowed field (T582A-INFTX) must be flagged when the infotype characteristics are maintained (table T582A). 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.8 Infotype Text Modules You can create a text module when entering master data for individual infotype data records. (You can specify an alternative or subsequent screen.1. T588B Infotype menus T588Z Dynamic actions The entries stored in these tables must be maintained manually. To ensure that text modules can be created for an infotype.Infotype 0002 Personal Data uses module pool MP000200 and screen 1000 as its initial screen. PUBLIC © 2014 SAP SE or an SAP affiliate company. Therefore. Change the display of the infotype single screen in question. You do this in the single screen for the infotype by choosing Edit → Display Text or Edit → Maintain Text. this infotype requires a dialog module called RP_0002 which accesses screen 1000 for module pool MP000200 . and so on) T582S Infotype short texts T777A Technical characteristics of Infotype (database table. list screen. You do not need to change the infotype structures or tables in the ABAP Dictionary. Page 17 of 75 . If you want to use this functionality. and RP50M-TEXT3 on the single screen. 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.1. Include the fields RP50M-TEXT1 . 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. All rights reserved. and the check class. it is an integral part of the Personnel Administration and Recruitment transactions. ● Maintaining the characteristics of the infotype. ● Note the naming convention. RP50M-TEXT3. Insert the module GET_TEXT behind the module HIDDEN_DATA . Result You can maintain texts for your infotype. ○ If you have selected Both . These subobjects must offer particular standard functionality and have a particular structure. A new infotype is limited to a maximum of 1000 positions. You must also include the fields RP50M-TEXT1 . PUBLIC © 2014 SAP SE or an SAP affiliate company. see the online documentation on the ABAP Dictionary. which contains the various includes. The system creates all subobjects that belong to an infotype in the system. The transaction uses a copy template for this. 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. enter the value 006 in Modification Group 1 for all three fields. accessed as the last module of this action. or ZHCMT_BSP_PA_yy_R9nnn for a customerspecific infotype. ENDCHAIN. ● The system creates structure Pnnnn and the database tables for your infotype. ○ The system also creates the screen structure HCMT_BSP_PA_yy_Rnnnn for a standard infotype. The number range 9000 to 9999 is reserved for customer infotypes. RP50M-TEXT2 . RP50M-TEXT2. You must use this number range if you want your customerspecific developments to be retained after a release upgrade. which is used as a container during infotype processing. 3. screens. see Definition of an Infotype in the ABAP Dictionary. The system creates the subobjects with the required functionality and the correct structure. The module GET_TEXT is. Your infotypes are also automatically included in the logical databases PNP and PNPCE. and RP50M-TEXT3 are hidden. 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. Once you have created your infotype in the system. 1. The first three lines of text are displayed on the single screen or can be maintained. the dialog module that calls the initial screen of the infotype. This ensures that your customer developments are not affected by a release upgrade. the fields RP50M-TEXT1 . Check that the Text allowed indicator has been set in table T582A. Enhance the flow logic for the action PROCESS BEFORE OUTPUT . 4. For information about the ABAP Dictionary. 2.2 Developing an Infotype Use The Create Infotype transaction (PM01) can be used by customers and SAP to develop new infotypes. you should complete the modeling and design of the infotype. This restriction is due of the length of structure PRELP. Insert the following lines after the module PRE_INPUT_CHECKS and before the infotype-specific entry checks: CHAIN. table PBnnnn is created. Page 18 of 75 . table PAnnnn is created.To ensure that entries can be made in these fields when the Add and Change functions are used. ● You must use customer-specific development classes for all subobjects of your infotype. therefore. and the application for which you want to use the infotype ( employee infotype or applicant infotype ). both tables are created. a supporting program containing the standard functionality for the infotype. RP50M-TEXT2 . Enhance the flow logic for the action PROCESS AFTER INPUT . the conversion class. a free number in the customer namespace for customer-specific infotypes. MODULE UPDATE_TEXT ON CHAIN-REQUEST. Once you have finished creating your infotype. Prerequisites ● Before you begin implementing a new infotype. The template consists of a module pool called MPMMMM00. ○ If you have selected Employee Infotype . If this indicator is not set. and the GUI status. FIELD: RP50M-TEXT1. ○ If you have selected Applicant Infotype . For more information about the structure and task of individual objects. ● You create the data field structure PSnnnn . You do this by copying the Addresses infotype (0006) and using the Telephone Number field as a copy template. All rights reserved. b. 3. 2. e. In the Field Selection from Table PSnnnn dialog box. Enter the object directory entry for the PS structure. Check your structure. 6. b. see Infotype Module Pool. Double-click on the field and choose a component type from the dialog box. see Infotype Screens. Enter a short description for the infotype. or an infotype for the public sector of a country. 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). Recruitment ( applicant infotype ). Define the enhancement category : To do this. The Create Object Directory Entry dialog box is opened. or in both components ( both ). Choose Generate Objects. You see the message Infotype PSnnnn does not exist . Choose Create . choose the PS structure that contains similar data components to the infotype you are creating.For more information. Page 19 of 75 . For a list of interface statuses. Choose Insert . and ZHCMT_BSP_PA_yy_R9nnn for a customer-specific infotype. and a free number in the customer namespace for customer-specific infotypes. Choose a free infotype number for standard infotypes. Choose Create . MPnnnn30 and MPnnnn40 Includes for module pool MPnnnn00 For more information. d. The system also creates the following subobjects and table entries for an infotype nnnn : ● Module pools ○ MPnnnn00 Module pool for infotype nnnn ○ MPnnnn10 . Enter all required components for the infotype. 11. Once you have checked it. 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. database table PAnnnn . choose Extras → Enhancement Category. How do you want to continue? 5. You branch to the ABAP dictionary structure maintenance. Note the naming convention (customer namespace 9000 to 9999). Enter the component type for each component. 4. ● 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. The components are written to the clipboard. 13. see Interface Status for Infotypes. save the structure. Once the structure has been activated. ● Dialog module RP_nnnn ● Technical characteristics ○ Entry for dialog control such as dialog structure. There are two ways of doing this: Manually: a. Proceed as follows: a. MPnnnn20 . 12. Enter the structure components (infotype fields). You create an infotype containing a telephone number for emergencies. P structure. choose Creating an Infotype Version. select the required components and choose Copy .1 Creating an Infotype Use You use this procedure if you want to create an international infotype. Save your entries. As the structure name. proceed as follows: 1. 9. You get the following message: Structure PSnnnn has been saved . You can refer to an existing component type or create a new component type. Choose Edit → Copy Field . se lect the enhancement category and copy the entry. If you want to create a country-specific or industry-specific infotype. Choose Create Infotype (tab page). Enter the object directory entry for the screen structure: HCMT_BSP_PA_yy_Rnnnn for a standard infotype. Procedure To create an infotype in the ABAP Dictionary. 10. 8. 7. go back. Decide whether you want the infotype to be used in Personnel Administration ( employee infotype ). ● Interface The system creates an interface that contains all required interface statuses. see Structure and Task of the Screen Structure. c. PUBLIC © 2014 SAP SE or an SAP affiliate company. If you want to maintain the characteristics of an infotype. you automatically go to the maintenance view for infotype characteristics. if the infotype number of the imported infotype is the same as your infotype. Result You have created a new infotype.1. The following information is displayed. You do this once this procedure is complete by choosing Check Class (BAdI) → Edit . make sure that your entries are overwritten by those of another imported infotype with name range enhancement (/Partner1/9000. choose the tab page Enhance Screen Structure. Make sure that the table entry is transported. PUBLIC © 2014 SAP SE or an SAP affiliate company. 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. date proposal for the start date on the selection screen. choose Infotype → Namespace and enter the namespace reserved for your company. see Defining Infotype Characteristics. information about the single screen and list screen. The Display Infotype Characteristics (Customizing): Overview screen appears. for example).2. 15. Page 20 of 75 . proceed as follows: ○ After you have created a new infotype. The PS structure and the screen structure are identical. display and selection (such as reaction indicators for entering dates on the menu selection screen. The name of the screen structure HCMT_BSP_PA_yy_Rnnnn or ZHCMT_BSP_PA_yy_R9nnn is generated from the infotype. 16. For more information. ● 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. Then proceed as described above. This table entry is client-dependent and therefore only exists in this client. see Editing the Check Class. For more information. 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. subtype (subtype table). To enhance the screen structure. Maintain the characteristics of the infotype. ● 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. which you confirm: ○ The check class must be encoded manually. and so on.14. choose Infotype Characteristics .%_HRnnnn Entries in tables T777D and T77ID Screen structure The system has copied the fields from the PS structure to the screen structure. You must define these infotype characteristics after you create an infotype.1 Defining Infotype Characteristics Use Infotype characteristics contain information about the time constraint (time constraint table). Note on creating infotypes with name range enhancement If you are creating an infotype with a name range enhancement (such as /Company1/9000). Procedure 1. information about the retroactive accounting trigger for payroll infotypes. Enter a transport request. and so on). To define a namespace. The check class was generated in the background from the check class CL_HRPA_INFOTYPE_NNNN and must be encoded manually. ○ The table entry T582ITVCLAS still has to be transported. ○ If you want to go back and edit the characteristics of an infotype. All rights reserved. For this reason. It is not usually necessary to edit the interfaces for infotypes. see Business Logic Guidelines for Creating and Migrating Infotypes. you can edit all subobjects of the infotype. All rights reserved.2. PUBLIC © 2014 SAP SE or an SAP affiliate company. see Editing the Check Class. menu entries. add or change attributes. you adjust the CUA interface for the new infotype (menu structure. For more information. You should not enhance the PS structure with additional fields in the customer include CI_Pnnnn as part of subobject editing. The check class CL_HRPA_INFOTYPE_nnnn or ZCL_HRPA_INFOTYPE_9nnn contains five change-relevant methods.1.2. You must also modify the infotype-specific parts of the generated module pool MPnnnn00 (create form routines for screen processing. ○ You can copy an infotype entry with similar characteristics. For more information. and so on). the system automatically generates the relevant check class for the infotype in the background. you must encode the check class CL_HRPA_INFOTYPE_nnnn or ZCL_HRPA-INFOTYPE_9nnn manually. 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 choose Copy as… 4. that is. They are decoupled in the same way as the infotype-specific input and processing logic of a customer infotype. add or change texts. select the infotype whose characteristics you want to copy. The infotype-specific input and processing logic must be decoupled manually. Result You have defined the characteristics of infotype Pnnnn or P9nnn . and the relevant check class has been generated. 1. To do so. Switch to change mode ( Display → Change). but as part of the enhancement functionality for infotypes. Above all. or check the structure. 3. Page 21 of 75 . If required. 1. For information about whether the check classes have to be edited for your infotypes. Activities ● You enter the infotype and choose Check Class (BAdI) . Make your entries in the required fields or check the entries you copied and make any necessary changes. where you can display and edit your check class. ● Use the Edit pushbutton to go to the Class Builder.2 Editing Subobjects of an Infotype Use Once you have created an infotype.2. Editing the Check Class Use When you create a new infotype Pnnnn or P9nnnn. There are two ways to create an entry: ○ You can create an entirely new entry by choosing New entries . 5. which creates a decoupling of a similar scope to when a new infotype is created. for example). Save your entries.2 Migrating an Infotype Use You can use this process to trigger an automatic migration of an infotype. ● 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. the check class can not be overwritten by another migration. you may have to adjust the list screen specifically for the infotype version (for example. screen.Features The system creates the following objects and structures automatically: ● Screen structure The P structure fields are copied to the screen structure. Enter the infotype version. Enter the infotype number. the list screen for US address data). and interfaces must be processed manually. In addition. The criterion for a migration that has already taken place is the entry in table T582ITVCLAS. The module pool. choose Creating an Infotype. a specific single screen can be required for certain countries (for example. ● 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. Page 22 of 75 . or an infotype for the public sector of a country. 3. Choose Create Infotype Version (tab page). If you have already made modifications in the check class. PUBLIC © 2014 SAP SE or an SAP affiliate company. a single screen for entering US address data). For country-specific versions of the Addresses infotype (0006). 2. Creating infotype versions can affect all existing subobjects of an infotype. The system outputs a message to this effect. If you require an international infotype. All rights reserved. Procedure 1. Creating an Infotype Version Use You create an infotype version if you want to create a country-specific or industry-specific infotype. 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 and T777ID Structures PS9nnn . Choose Create . 12. Features The system deletes the following objects. and tables for the infotype: ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● Entries in tables T582A. To do this. structures. You branch to the ABAP dictionary structure maintenance. 4. 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 .5. Result You have added fields to the standard list screen for an infotype. The fields in structure ZPLISnnnn are removed from the standard list screen. Make the required modifications in the form FILL_LISTSTRUCT to fill the components of structure ZPLISnnnn for the additional list fields. T777D. Go back. Choose Enhance List Screen. In the Infotype Number field. 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.2. You must enter leading zeros for the infotype number. 3. Choose Generate Objects. 8. or industry-specific infotype. Define the customer-specific components (infotype fields). Enter the screen number of the list screen you want to enhance (usually screen number 3000 for infotypes without versions). enter the four-digit number of the infotype you want to enhance. How do you want to continue? 5. 6. Choose Module Pool (Form Routine) → Edit .1.2. You see the message ZPLISnnnn does not exist . The additional list fields are displayed in the output of the list screen of infotype nnnn (usually screen number 3000). country-specific. 11. Page 26 of 75 . All rights reserved. 1. Save and check the structure ZPLISnnnn . You do this on the Enhance List Screen screen of the Create Infotype transaction (PM01) by choosing List Screen → Delete Enhancement. 9. 2. Structure ZPLISnnnn is identified when it is generated with a TABLES statement in the program ZPnnnn00. The system also creates an include program ZPnnnn40 in program ZPnnnn00. You go back to the initial screen of the transaction. 7. The fields can be filled from the Pnnnn structure or by reading text tables. The FORM routine FILL-LISTSTRUCT is called for each data record in the list. Deleting the additional fields You can delete the fields that have been added to the standard list screen. choose Extras → Enhancement Category. 10. Enter a short description for the structure ZPLISnnnn.6 Deleting an Infotype Use You can use this function to delete a customer-specific. Enter an enhancement category.2 Enhancing the List Screen Procedure 1. 1 Preliminary Analysis Procedure Before you begin infotype creation (or migration). Page 27 of 75 . HR Administrative Services – introduced in the standard system after or in tandem with In summary. then we recommend that you observe the business logic guidelines set forth below. along with the corresponding UI Programming Guidelines for Infotypes. the revised framework. 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. That framework remains operative in this and every subsequent release. Time Management) are not affected. 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. see Enhancing an Infotype Included in the SAP Standard System. We recommend that you review these guidelines. This section also discusses the migration of existing infotypes from prior releases into this release. To enhance master data consistency and improve performance. you may therefore wish to “migrate” existing infotypes from Release 4. All rights reserved. Business Logic Guidelines for Creating and Migrating Infotypes This section discusses important guidelines that apply to standard business logic in a de-coupled environment.4. whether standard or customer-specific. where the business logic was not de-coupled from the corresponding user interface. and therefore relates to the creation of new Personnel Administration infotypes in this and every subsequent release. as needed. In addition to the enhancement concept. you must perform a preliminary analysis to consider the business logic of the corresponding infotype. To this end.6C and in prior releases. 1. meaning that customer-specific infotypes or individual infotype records that were created at Release 4.6C and below (henceforth described as “prior releases”) into this release – that is. To this end. for example) If you add new sub-objects to an infotype. this section also discusses important information to consider and necessary actions to take whenever you migrate infotypes from prior releases into this release. 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. 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. The last character x can be defined as you wish. or any release thereafter. The programming guidelines set forth below solely apply to standard Personnel Administration infotypes.For more information on the enhancement concept. nnnnrepresents the number of the infotype you want to modify. you must first examine the proposed (or existing) flow logic of the infotype at PUBLIC © 2014 SAP SE or an SAP affiliate company. In the revised framework for creating infotypes. the business logic of any infotype is completely de-coupled from the corresponding user interface. as well as the role that the infotype will play (or plays) in your system landscape. Infotypes in other functional areas (for example. whenever you execute the Create Infotype transaction (transaction code PM01) to create new Personnel Administration infotypes and compose the corresponding business logic. At Release 4. this section discusses the business logic guidelines that apply to the creation of new Personnel Administration infotypes. it is important to note that infotypes that have not been migrated cannot be processed by applications – for example.6C or below will continue to function in this release. To the extent that you wish to adjust the business logic of infotypes from prior releases. 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. Although you are not required to migrate infotypes from the previous framework. in this (or any subsequent) release. Personnel Administration infotypes were created in a previous framework. Thus. we recommend that you consider. even if this action may initially seem to be redundant. once you have examined the (explicit) flow logic. users may wish to consider the following chapter. If a radio button or checkbox is present on a screen. the standard system enables users to render certain infotype fields invisible. From this point forward. Always remember that in direct input situations. it is important to remember that the Infotype Screen Control table imposes restrictions that are not processed during direct input. in the event that you encounter such restrictions. The primary examples of implicit value restrictions are radio buttons and checkboxes. 1. you must also determine the implicit checks to ensure that the check class considers the flow logic and the implicit checks alike. Therefore. you must make certain to encode these checks in the business logic. in Customizing for Personnel Administration (PA-PA). Nonetheless. even when such checks may seem to be redundant. Nonetheless.4. In the flow logic itself. Another example of implicit value restrictions is found in dynpros that LOOP AT SCREEN in order to disable input for certain fields. does not provide all the information you need for your preliminary analysis. the import or export of special data. by choosing Customizing User Interfaces → Change Screen Modifications . inactive) and ‘x’ (that is. but which reside in the P-structure Foreign key checks Disabled foreign key checks Values that can only be filled by special means. Nonetheless. this restriction is enforced by the user interface itself. active).1. you must encode checks for the contents of these fields. you cannot prevent these fields from being filled in a direct input situation. however. The Infotype Screen Control table is considered to be part of the user interface. 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). you are required to consider them in your business logic as well. the following implicit checks: · · · · · · · · Implicit value restrictions Input/Output conversions Required input fields Special controls ¡ Fields that cannot accept input. either through corresponding country-specific Customizing activities. 1. PUBLIC © 2014 SAP SE or an SAP affiliate company. Nonetheless. as with checkboxes and radio buttons. or to make input for other infotype fields mandatory. the present guidelines limit themselves to discussing the creation of new infotypes in th is release. exactly like the implicit restrictions already described. or. Therefore. no additional action is required for users to create the requisite check classes. dynamic measures. for example: ¡ Radio buttons ¡ Drop-down boxes ¡ Checkboxes Mutually dependent fields Furthermore.2 Check Classes Definition As new infotypes are created in the Create Infotype transaction (transaction code PM01). Therefore. no dynpro processor is present to prevent the user from specifying other values in these fields. Examining the flow logic alone. as described above. the Infotype Screen Control table obviously introduces implicit value restrictions. then only two input values are possible – ‘_’ (that is. and so on. as when the fields are assigned to a dynpro and therefore have anticipated values. Moreover. However. Page 28 of 75 . the information presented in the remainder of this document applies equally to the hypothetical migration of existing infotypes from prior releases. as with radio buttons and checkboxes.2 Performing Infotype Screen Control Procedure As delivered. because the screen logic has disabled them ¡ Fields that are not visible on the screen. unless otherwise explicitly stated. All rights reserved. the system automatically creates the corresponding check class(es) in the background. we recommend that you consider the following points. they must be considered accordingly in the business logic. · · · · · · · 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. To this end. radio buttons and checkboxes serve as checks. you should attempt to determine whether other unique conditions exist in the infotype – for example. along with the flow logic. the update of tables that lie outside the PAnnnn name range.4. in conducting your preliminary analysis.hand. users can modify the Infotype Screen Control table (T588M) accordingly. and as such. rather than part of the business logic. To simplify the creation (or migration) of infotypes in(to) this release. lest errors subsequently arise in the country-specific versions of the infotypes. Thus. check class CL_HRPA_INFOTYPE_0011 inherits its properties from check class CL_HRPA_INFOTYPE_NNNN. To summarize. the country-specific version of any infotype tends to store and process data – in other words. or in the event that only an international version of it exists. Check class CL_HRPA_INFOTYPE_0011. if a given infotype has only one screen number in the series from 2000 to 2999. remember the following two rules of thumb: · In general. SPECIFIC_READ_COMPUTATIONS This method adds values into records after they are read from the database and before they are presented to the user. then only one check class will exist for it. · Views are considered to represent particular examples of country-specific check classes. in turn. If the structure of the infotype at hand is relatively simple. although you are not necessarily required to re-define all of them. The methods that are subject to possible re-definition are as follows. “behave” – in a manner that is similar to the international version of that infotype. 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 the new check class for the infotype can inherit the properties of the standard check class (or “superclass”) CL_HRPA_INFOTYPE_NNNN. 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. rather than the properties of superclass CL_HRPA_INFOTYPE_NNNN. In such cases. you may wish to review country-specific versions of other infotypes to familiarize yourself with concrete examples of these technical issues. In order to create your infotype. As the logical result of these rules of thumb. 1. 1. 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). All rights reserved. Because of this definition. Check class CL_HRPA_INFOTYPE_NNNN is defined as the superclass for this check class.3 Implementing Checks Use The following methods are delivered in the standard system with superclass CL_HRPA_INFOTYPE_NNNN. the check class must instead inherit the properties of superclass CL_HRPA_INFTY_NNNN. refer to Implementing Checks and subsequent topics for a detailed overview of the technical issues at hand. PUBLIC © 2014 SAP SE or an SAP affiliate company. Standard Methods for Implementing Checks Method Purpose SPECIFIC_INITIAL_COMPUTATIONS This method fills in default values if a record is created anew.4. whenever you are working with international check classes.4. if you are responsible for the international version of an infotype. Creating Country-Specific Check Classes Procedure As you create country-specific check classes. Finally. then only one check class will exist for that infotype. you should use care when performing the creation (or migration) of check classes for infotypes with several country versions. it may be appropriate for the check class to write data to the buffer. Moreover.1 Creating Single Check Classes Procedure In the event that your infotype is country-specific. SPECIFIC_MODIFY_COMPUTATIONS This method ascertains whether it is permitted to modify a certain record. In other words. country-specific check classes inherit the properties of the international check class. Page 29 of 75 . Under very limited circumstances discussed in a subsequent background topic. then you must not the select the Final checkbox (VSEOCLASS-CLSFINAL) while you define the attributes of the international check class. 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.which provides useful information that pertains to the creation of check classes within standard business logic. is defined as the superclass for five country-specific check classes. you must implement checks in one or more of these methods.2. Finally. you must take precautions to ensure that such methods are smoothly integrated. but whose existing signature method is not wide enough. which in turn calls several other subordinate check methods that are smaller than SPECIFIC_COMPUTATIONS. In other words. we recommend that you re-define method SPECIFIC_COMPUTATIONSin your country-specific version to call the superordinate method SUPER->SPECIFIC_COMPUTATIONS. but rather the (subordinate) method call itself: CHECK_POSITION. if you wish to call method CHECK_BIRTH_DATEwith the country grouping in the signature. · 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. then you actually require an entirely new method – for example. In creating the country-specific version. to ensure that the properties of the international version are considered (and inherited) in the country-specific version.3.3. Methods can even be used to write additional records into the buffer. along with the new check method(s) that the country version requires. The drawback of this approach. 1. which would be called after the method SUPER->SPECIFIC_COMPUTATIONS. This requirement obviously cannot be fulfilled by redefining the method. We therefore recommend that you never update any table directly from within a check class. only pursue the first approach in the event that this signature is actually flawed – in other words. the re-definition of check methods may result in errors. one could falsely assume that it is correct to re-define the method SPECIFIC_COMPUTATIONSto call all of the smaller subordinate check methods.4. you would create a new method CHECK_COUNTRY_SPECIFIC_BIRTH_DATE. filling in derived values. then the semantics of the method itself are in effect unsuitable.1. simply add the additional country-specific method(s) that you require. you would redefine SPECIFIC_COMPUTATIONSby implementing the superordinate check method SUPER>SPECIFIC_COMPUTATIONS. via this definition.1. it is worth noting that the examples provided above are not exhaustive. methods are referred to as “computations. 1. however. two alternative approaches do serve to fulfill this requirement. Therefore. lies in the fact that any subsequent changes to the method SPECIFIC_COMPUTATIONSwould not be inherited in the country-specific version of the infotype. Suppose that a country-specific version of the Personal Data infotype (0002) requires more check methods than are offered in the international version.1 Inserting New Check Methods The international version of the Personal Data infotype (0002) contains the method SPECIFIC_COMPUTATIONS. Therefore.4. This approach presents one drawback: all of the classes that directly call the method would be invalidated. if you wish to use methods to write data. define CHECK_POSITION as IS_OK = TRUE. you would redefine CHECK_BIRTH_DATE to be empty. except one: the method CHECK_POSITION. After this call is complete. Suppose that a country-specific infotype version requires all of the check methods that are found in the international version. other situations may arise that require existing check methods to be modified. Page 30 of 75 . but that you additionally require the country grouping in the signature. all of the examples provided do serve to illustrate an important point: in most cases. Procedure These methods should always be written as if an actual update will be requested and as if the database will not be updated.3 Extending Existing Check Methods Suppose you want to extend a check method that is already present. listed below.3. The three topics in this section. as it is assumed that method SPECIFIC_COMPUTATIONShas been re-defined and copied.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. which would serve to process all of the international checks.4. CHECK_COUNTRY_SPECIFIC_BIRTH_DATE. 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. and if the method has a correct signature. In creating the country-specific version. which serves to forestall errors that may arise from the absent buffer rollbacks. The first approach would be to change the signature of the method in the international class.4.” because any method can be applied to perform additional functions – for example. to disregard it. discuss the errors that may arise. re-defining a method with a slightly modified copy usually does not PUBLIC © 2014 SAP SE or an SAP affiliate company. additional updates for tables that lie outside the PAnnnn name range must instead be processed via the so-called additional update mechanism. However. if the parameter is truly absent. thereby disabling the international check. 1. As the naming convention implies. suppose you wish to call method CHECK_BIRTH_DATE.” rather than “checks. Although this approach is incorrect. Then. Therefore. because if you do not wish to check the position.3. 1. All rights reserved. SPECIFIC_DELETE_COMPUTATIONS This method ascertains whether it is permitted to delete a particular record. In this situation. then you can just as easily write your source code. This requirement exists as the result of a mechanism in this release that allows the buffer to roll back at any time. or to prepare additional updates for tables that lie outside the PAnnnn name range. 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. the best approach is not to re-define the (superordinate) method SPECIFIC_COMPUTATIONS. However.1 Redefining Check Methods In rare cases.SPECIFIC_INSERT_COMPUTATIONS This method ascertains whether it is permitted to insert a particular record. To this end. The second approach is to understand that if the signature is not suitable. 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. In summary. To this end. For example. however.1. 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. and so on – but rather limit themselves to the relationship between the methods and these screen events. p0014 = pnnnn. · DATA p0014 TYPE p0014. in lieu of ( . the methods described in the topic Implementing Checks provide you with dynamically correctly typed Pnnnn structures. However. 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 lieu of ( . All rights reserved. It is also feasible to follow a second approach.2 Using Generic Interfaces Use To simplify implementations.. ( .. is valid. describes how a new record is created. For simplicity’s sake. Do not use any attributes to keep track of subsequent changes to your records. you would insert the source code. The first approach avoids field symbols entirely. and must therefore be typecast before they are used. Page 31 of 75 .serve to fulfill the requirement you seek. although either approach. that is required to implement the check for the Recurring Payments/Deductions infotype (0014). determining time constraints. ( . the second approach forestalls the possibility of forgetting to move the structure back again.3. The information presented in this topic exceeds the general knowledge that is required to create (or migrate) infotypes in(to) this release. that is required to implement the check for the Recurring Payments/Deductions infotype (0014). ASSIGN pnnnn to <p0014> casting. However. Furthermore. each approach offers unique advantages and disadvantages. such attributes are explicitly not supported by the standard system. If you need external functionality. Processing Methods: The Standard Sequence Purpose The processing sequence that occurs among the methods and various screen events is described in the following diagrams. ) pnnnn = p0014. shown below. these cannot be statically typed. as the system will detect these and in response issue a short dump. · FIELD-SYMBOLS <p0014> TYPE p0014..4. and may cause your source code to become corrupt. The following source code demonstrates the first approach. Process Flow Diagram A.. rather than the first. ) As in the first example. PUBLIC © 2014 SAP SE or an SAP affiliate company. 1.. this approach offers a minor performance advantage. you would insert the source code. Under no circumstances should you implement external performs into existing reports. these diagrams do not illustrate every process in the sequence – for example. For these reasons. we recommend that you pursue the second approach. determining the correct check class. and may therefore initially offer greater appeal. then you must encapsulate this within classes or function modules. ). to reiterate. it is important to note that all check classes and check methods should be completely stateless. as demonstrated below. In this example. Procedure While both of the approaches described above are valid. because generic interfaces also exist. Finally.... ). Two possible approaches for implementing checks are illustrated in the following examples for the Recurring Payments/Deductions infotype (0014). As Diagram B demonstrates. 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. this method. Diagram C. the system copies records in essentially the same manner as it inserts them. the system reads an existing record. describes how a record is copied. describes how a record is deleted. PUBLIC © 2014 SAP SE or an SAP affiliate company. shown below. with one difference: instead of creating a new record. Diagram D. the system will continue to process the screen anew until the user either exits the session or the records are sent to the database.In the SPECIFIC_INITIAL_COMPUTATIONS method. Diagram B. In the SPECIFIC_INSERT_COMPUTATIONS method. shown below. Page 32 of 75 . all necessary checks are performed for the insertion of records. the system modifies records in essentially the same manner as it copies them. If the user does nothing more than choose Enter . If errors arise. also fills derived values. All rights reserved. where needed. describes how a record is modified. shown below. all appropriate default values are filled. As Diagram C demonstrates. because interface IF_HRPA_MESSAGE_HANDLER already fulfills the requirement of setting breakpoints wherever needed. IF 1 = 0.4 Performing Message Handling Procedure As you are implementing checks.As Diagram D demonstrates. so that breakpoints. DATA field_list TYPE hrpad_field_tab. IF required_field IS NOT INITIAL. could be set at this statement.4. as the above diagrams suggest. any breakpoints at MESSAGE will always stop in method ADD_MESSAGE. Unlike prior releases. All rights reserved. where needed. msg-msgno = '55'. employ method ADD_MESSAGE. METHOD check_required_field. is_ok = false. refer to a subsequent background topic. within the system. the Where-Used List in this release can no longer determine where messages are used. For this reason. Page 33 of 75 . the system deletes records in essentially the same manner as it modifies them. To add a message to this interface. It is therefore useful to employ the statement “IF 1 = 0” to hard-code a “dummy” message. SPECIFIC_MODIFY_COMPUTATIONS and SPECIFIC_DELETE_COMPUTATIONS. one could falsely assume that it is correct to employ the MESSAGE INTO statement. while PAI flows into the methods SPECIFIC_INSERT_COMPUTATIONS. In this release. APPEND field_name TO field_list. ELSE. DATA msg TYPE symsg. Unlike prior releases. no one-to-one mapping relationship exists between PBO or PAI and the respective methods. where message statements are issued to draw attention to errors. as such statements now lead to errors in their own right. However.3. it is important to consider the means you will use to indicate error conditions. PUBLIC © 2014 SAP SE or an SAP affiliate company. ENDIF. Rather. messages in this release are always created dynamically. IF field_name IS INITIAL. Example The following example demonstrates a case where the method CHECK_REQUIRED_FIELD of check class CL_HRPA_INFTY_NNNNis called. Alternatively. msg-msgty = 'E'. this approach is unnecessary. is_ok = true. In summary. * 055 Make an entry in all required fields MESSAGE ID '00' TYPE 'E' NUMBER '55'. CALL METHOD message_handler->add_message EXPORTING message = msg field_list = field_list cause = if_hrpa_message_handler=>infotype_specific. ENDIF. PBO flows into the methods SPECIFIC_INITIAL_COMPUTATIONS and SPECIFIC_READ_COMPUTATIONS. msg-msgid = '00'. you must therefore employ interface IF_HRPA_MESSAGE_HANDLER to handle messages. you may no longer use message statements in this release. 1. for background information on the use of this check class. RAISE EXCEPTION TYPE cx_hrpa_invalid_parameter EXPORTING parameter = 'FIELD_NAME'. However. FIELD_LIST in this release is used in lieu of statement CHAIN. and cannot be evaluated by a typecast anyway. · FIELD_LIST contains the list of fields that the message affects. the system will always return control to your method. or attributes that hold an internal state that depends upon the checks. even if none of your checks fail. Avoiding Pitfalls in Message Handling This topic discusses three pitfalls that frequently arise during message handling. for example.. This prioritization. it is important to remember that filling the message variables with the MOVE command. because you wish to compare two required fields. Because of this change. APPEND ‘P4711-FIELD2’ TO field_list. However. you should always return with IS_OK = TRUE to ensure that your warning does not change the control flow. All rights reserved. but no information is provided to instruct the caller that the corresponding checks have failed. the system eventually will ascertain whether the message handler and the IS_OK statement are synchronized. unlike prior releases. in turn. APPEND ‘P4711-FIELD3’ TO field_list. always enable processing to continue. ENDMETHOD. The parameters shown in this example convey the corresponding meanings: · MESSAGE contains the actual text of the message. the field list in this release is now contained within the business logic itself. you must still expect that the buffer can be rolled back at any time. because the handler may already contain other messages. APPEND ‘P4711-FIELD4’ TO field_list. rather than MOVE. we recommend that you refrain from using macros.. Therefore. Therefore. As a rule of thumb. and even if additional updates (for example. provided that you are familiar with the information in this topic. which allows the system to prioritize errors by their respective semantics. it therefore is possible (and indeed explicitly supported) for processing to continue. facilitates the debugging process. the most expedient solution is to insert an additional IS_OK flag (of TYPE BOOLE_D) to indicate that processing was completed successfully. rather than on the screen. (. In dynpro terms. CALL METHOD message_handler->add_message EXPORTING message = msg field_list = field_list cause = if_hrpa_message_handler=>infotype_specific. In other words. you should use the WRITE INTO command. from using database operations. if you determine that you cannot continue your checks – for example. The information presented in this topic exceeds the general knowledge that is required to create (or migrate) infotypes in(to) this release. but one of these fields lacks the required input – then you should exit the method. APPEND field_name TO field_list. rather than specifying the following source code … APPEND ‘P4711-FIELD1’ TO field_list. then the system will issue an exception. your check classes should refrain. it is reasonable to check all required input fields. Although warnings advise the user that a particular action may cause subsequent problems. A second option to streamline message handling concerns the field list. Finally. This command allows the system to handle errors caused by authorization checks. no longer serves to perform output conversions. MOVE-CORRESPONDING sy TO msg. even if no errors are issued. SET/GET parameters and the like. If you elect to use this option. Warnings. The second pitfall arises when warnings inadvertently change the control flow. because the system will populate the SY variables correctly. With this solution in place. 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. in a different fashion than errors encountered by the infotype.ENDIF. The following example demonstrates one option to streamline message handling. If this is not the case. · CAUSE informs the message handler why the error occurred. retrocalculation checks) are performed. Individuals who have particular expertise in this subject matter or who desire deeper knowledge of this issue may nonetheless consult this topic for reference. even after an error message has been issued. In the standard system. warnings do not prevent the user from performing that action. for example. to say nothing of import/export statements. these fields are no longer determined by the dynpro. then you need not concern yourself with output conversion. unlike errors. In addition to the above example. Under these circumstances. if you add a warning. Streamlining Message and Exception Handling This topic discusses approaches for streamlining message handling within your infotype. if you wish to move data or time information into any of these variables. it is also important to remember that whenever you add a message to interface IF_HRPA_MESSAGE_HANDLER. The third pitfall relates to the fact that the buffer can be rolled back at any time. Therefore. Page 34 of 75 . Thus. as other methods exist to achieve shorter calls. which was employed in prior releases. you can easily avoid each of these pitfalls. DATA dummy(1) TYPE c. … you may instead specify either of the following two alternatives: PUBLIC © 2014 SAP SE or an SAP affiliate company. even if one of them lacks the appropriate input. but rather by the logic that creates the message. The first pitfall occurs when an error is added to the message handler and a method is exited. The same principle holds for any other variables that require output conversion.) * 055 Make an entry in all require fields MESSAGE ID '00' TYPE 'E' NUMBER '55' INTO dummy. To encode message handling in the most expedient manner possible. In order to remap certain fields. implement the source code as follows. it may be necessary to ignore all fields and enforce a specific field list.3. · The problem is caused either by erroneous source code or by erroneous database entries. which merits a genuine exception. The information presented in this topic exceeds the general knowledge that is required to create (or migrate) infotypes in(to) this release.4. To summarize. by means of which the corresponding source code is inserted into your local type declarations. In contrast. dump). a caller may on the one hand use the Currency Key field (CURKY). 1. In situations like these. rather than mechanisms. you must first create a local remapping class. § Exception CX_HRPA_INVALID_DATABASE is used to indicate the presence of corrupt database entries. CLASS lcl_ msg_curky_remap IMPLEMENTATION. METHODS remap REDEFINITION. and therefore substitute a technical message with an error message that is more informative and user-friendly. § Exception CX_HRPA_INVALID_INFOTYPE indicates that entries are missing from the Infotypes . enters an invalid number while attempting to display an infotype – an error message is generally more appropriate than a genuine exception. Determination of whether recovery is possible therefore should not be performed in low-level routines. CLASS lcl_msg_curky_remap DEFINITION FINAL INHERITING FROM cl_hrpa_message_generic_remap. Because of these underlying assumptions. on the other hand. keep in mind that the system assumes that all exceptions will be handled by the class-based exception mechanism. under the following circumstances. The problem can be corrected by the user. respectively). However. where recovery is impossible. an exception should be used. To remap messages that pertain to currency keys. it is important that you avoid confusing exceptions with messages or status indicators. users may need to remap messages. to set return values with a global variable. and that all exceptions truly are. Once the problem does occur. 1. may instead use the field “CURRENCY_KEY”. The exception CX_HRPA_INVALID_INFOTYPE. In severe cases. and vice versa. should only be applied when an infotype – for example. an error message should be issued.4. for example.3 Remapping Generic Messages In some cases. PROTECTED SECTION. but its table entries are absent. To continue with the previous example. Once the local remapping class is defined. because situations exist in which this exception should not be used – as when a user. as demonstrated below. 2. you should never misuse exceptions to indicate expected results. should issue an error message or an exception. depending upon the corresponding situation. Page 35 of 75 . for example. METHODS remap REDEFINITION. ENDCLASS.SPLIT ‘P4711-FIELD1 P4711-FIELD2 P4711-FIELD3 P4711-FIELD4 ’ AT space INTO TABLE field_list. in fact. in response to which the system may issue a short dump. Review the following criteria to determine whether your infotype. the Organizational Assignment infotype (0001) – is expected to be present. which presupposes that you have defined lcl_msg_curky_remap as a local remapping class. Under the following circumstances. exceptional. rather than an error message. Only occurrences that would merit an entry in the system log should be considered as exceptions. As you consider the most expedient manner for your infotype to handle messages. PROTECTED SECTION. the system may issue an exception to interrupt any subsequent processing (that is. but rather only to indicate that an exceptional situation has occurred. PUBLIC © 2014 SAP SE or an SAP affiliate company. METHOD remap.Dialog/Database Assignment or Infotypes: Customer-Specific Settings tables (T777D or T582A. The problem is expected to happen on a regular basis. · The problem is not expected to happen on a regular basis. · · · · · A deviation from standard processing is required. in fact. The following examples are intended to help you distinguish situations that require genuine exceptions from situations that merely require error messages. The following procedure summarizes the actions to be taken when generic message remapping is required. CLASS lcl_msg_curky_remap DEFINITION FINAL INHERITING FROM cl_hrpa_message_generic_remap. but a called method. you must actually implement the corresponding source code in all local instances of your class. or SPLIT ‘P4711-FIELD1 ’ & ‘P4711-FIELD2 ’ & ‘P4711-FIELD3 ’ & ‘P4711-FIELD4 ’ AT space INTO TABLE field_list. Individuals who have particular expertise in this subject matter or who desire deeper knowledge of this issue may nonetheless consult this topic for reference. All rights reserved. ENDCLASS. Processing of data should not be interrupted. For example. The problem is likely to be caused by user input. insert the following source code. the application must determine whether or not it can recover. Individuals who have particular expertise in this subject matter or who desire deeper knowledge of this issue may nonetheless consult this topic for reference. the FIXED attribute is not available in table T588MFPROPC. On the subsequent screen. As summarized in the chart above. ID for Infotype Versions (ITVERS) and Subtype (SUBTY). All rights reserved. Finally. choose Infotype → Edit Field Characteristics (Standard IT) . (Where this attribute is specified. the system will always initialize the corresponding field. no data can ever be stored in it. (Specification of both attributes is appropriate for fields in which an entry is to be made once.) If the UNUSED attribute is specified. respectively. customers may overwrite the (standard) T588MFPROPS entry with a (customer-specific) T588MFPROPC entry. indicating that input is required. CREATE OBJECT remapper TYPE lcl_msg_curky_remap EXPORTING message_handler = message_handler. infotype version and subtype. 3. but may also (where permitted) overwrite the standard entries in table T588MFPROPS and therefore also influence the behavior of standard infotypes. Processing Required Fields. or on the adjacent IT Version tabstrip. ENDCLASS. during insertion. during modification. if the FIXED attribute is specified in table T588MFPROPS. Each table describes the P structures of the corresponding set of primary records. Where applicable. In other words. either on the default IT tabstrip. then the system will consider the field to be required. tables T588MFPROPS and T588MFPROPC both feature the key fields Infotype (INFTY). then the system will subsequently ignore the MANDATORY and READONLY attributes. Inheritance Mechanism for Infotype and Related Fields In addition to the attributes described in the prior topic. enter the corresponding infotype number. The information presented in this topic exceeds the general knowledge that is required to create (or migrate) infotypes in(to) this release. but never changed again. To avoid the necessity of maintaining entries for all country versions and all subtypes.) Finally. Then choose Infotype → Edit Field Characteristics (Customer IT) to view or maintain entries in table T588MFPROPC. In contrast. PUBLIC © 2014 SAP SE or an SAP affiliate company. as shown below in Diagram E.ENDMETHOD. if applicable. For T588MFPROPS table entries. once your implementation is in place. you may invoke it with the following command. which instructs it to evaluate the most specific of the key fields INFTY. the standard system features an inheritance mechanism. described in the following diagram. Page 36 of 75 . Read-Only Fields and Unused Fields Purpose Two tables are delivered in the standard system to determine the properties of infotype fields. customer table T588MFPROPC governs this behavior for customerspecific infotypes (9000-9999). and will in fact issue warnings if the user attempts to do so. In the context of this mechanism. which are delivered by SAP. various attributes can be assigned to the respective fields within each table. DATA remapper TYPE REF TO if_hrpa_message_handler. If the READONLY attribute is specified. or read-only. for all fields except those to which the FIXED attribute is assigned. generic entries are created by setting the key field ITVERS or the key field SUBTY (or both key fields) to space (‛ ’). execute the Create Infotype transaction (transaction code PM01). 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. table T588MFPROPS governs the behavior of the corresponding fields. To continue with the previous example. Process Flow To view (or. If the attributes MANDATORY and READONLY are both specified. then the system will issue an error from this field in response to non-initial input. As summarized in the following chart. ITVERS and SUBTY. then the system will not permit the user to modify the field. each table also describes the P structures of the corresponding secondary records and cost PREF structures. which enable the system to differentiate among the infotype. then the system will not evaluate any attribute that is set for this field in table T588MFPROPC. maintain) the entries in either table for a particular infotype. For all standard infotypes (0000-8999). implement the source code as follows. in Diagram F. · · · · · · · · · · · · 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. Programming Your Infotype to Perform Implicit Checks Procedure Whenever you consider the business logic of an infotype. but omits all customer entries that are “fixed” in table T588MFPROPS. then the evaluation of key fields continues as described in Diagram F. The following topics. in contrast. All rights reserved. describe the correct approaches for programming these implicit checks. you must consider the implicit checks that are introduced in the Preliminary Analysis topic. If entries exist in table T588MFPROPC for which the FIXED attribute is specified in table T588MFPROPS. Page 37 of 75 . or the role that this logic will play in your landscape.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. CALL METHOD a_foreign_key_check->add_foreign_keys EXPORTING foreign_key_structure = t001p.7. t500p = cl_hr_t500p=>read( persa = p0001-werks ).1 Performing Foreign Key Checks Use As delivered. simply refer to the relevant topic(s) for detailed information on programming them correctly. T500W-LAND1 = PSYST-LAND. Page 38 of 75 . DATA p0001 TYPE p0001. 1. to this end.3. you re-define the FOREIGN_KEY_ADDITIONAL_DATA methods and implement these methods within the method CHECK_FOREIGN_KEYS. using the following source code: T500W-MANDT = SYST-MANDT. Structure SYST also requires no explicit check.3. CALL METHOD a_foreign_key_check->add_foreign_keys EXPORTING foreign_key_structure = psyst. p0010 = pnnnn.7. t001p = cl_hr_t001p=>read( werks = p0001-werks btrtl = p0001-btrtl ).2 Disabling Foreign Key Checks Use This topic discusses approaches for disabling foreign key checks in your infotype. structure PSYST itself. or for the fields of your primary and secondary records. which are especially simple either for personnel areas/subareas (derived from table T001P). If you wish to perform exactly the same checks in this release. All rights reserved. if you need to perform checks in relation to other tables. T500W-WAERS = P0010-WAERS. since the system now does so automatically.4. p0001 = p0001( tclas = tclas pernr = p0010-pernr begda = p0010-begda ).4. PUBLIC © 2014 SAP SE or an SAP affiliate company. In the Capital Formation infotype (0010) in prior releases. t503 = cl_hr_t503=>read( persg = p0001-persg persk = p0001-persk ). personnel areas (derived from table T500P). the system can automatically perform foreign key checks. since these fields are hard-coded. psyst-land = t500p-land1. 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). a foreign key check is automatically performed for the Currency Key field (WAERS) in relation to the Valid Country Currencies table (T500W). Procedure However. since the system can evaluate this structure without external input. CALL METHOD a_foreign_key_check->add_foreign_keys EXPORTING foreign_key_structure = t500p. you need only provide the structure(s) that are required for the check. This source code instructs the system to check the Country Key field (LAND1) in structure PSYST – rather than. DATA t500p TYPE t500p. 1. as in prior releases. In essence. not the contents of the corresponding table(s).· Reading Features · Replacing Fields NSELC and IOPER (For Infotype Migration Only) As you examine the business logic of your infotype to isolate implicit checks. t500p = cl_hr_t500p=>read( persa = p0001-werks ). and employee groups/subgroups (derived from table T503). DATA psyst TYPE psyst. then the following source code is required in method FOREIGN_KEY_ADDITIONAL_DATA: DATA p0010 TYPE p0010. then you must instruct the system accordingly. The following three foreign key checks are delivered with the standard system. CALL METHOD a_foreign_key_check->add_foreign_keys EXPORTING foreign_key_structure = t503. on their own. APPEND 'PERNR' TO EXCLUDED_FIELDS. APPEND 'BEGDA' TO EXCLUDED_FIELDS. · · · · · Technical field contents must be fulfilled. a corresponding foreign key relationship can be established. The entry in the Name of subtype (NAMST) field must be valid. Alternatively. all of which are enforced in the standard system within method ASSERT_CLEAN_DATA. Also. any changes thus performed must adhere to the revised framework that exists in this release for creating infotypes. Checking Radio Buttons and Checkboxes Use Radio buttons and checkboxes constitute implicit checks that are performed by the screen. Under the second constraint. 2. IF PRIMARY_FIELDS = TRUE. · For time constraints 1. numeric fields may only contain numbers.Procedure If you wished to remove all foreign key checks simultaneously. Changing the Keys for HR Master Data (PSKEY) Field During Checks Use Under certain circumstances. you could theoretically redefine method CHECK_FOREIGN_KEYS with an empty implementation. Prerequisites Under the first constraint. The subtype at hand must be permissible for the country grouping assigned to the personnel number. specifically. customers are responsible for implementing them. Under these circumstances. All rights reserved. Although it is technically possible to do so. suppose PERNR is to be excluded from both records. value range checks are active. redefining method FOREIGN_KEY_EXCLUDED_FIELDS is also the most efficient manner of disabling value range checks. only some foreign checks require exclusion. Page 39 of 75 . APPEND 'ENDDA' TO EXCLUDED_FIELDS. The start date must precede the end date. Suppose you wish to exclude fields P0002-BEGDA and P0106-ENDDA from foreign key checks for the Family Member/Dependents infotype (0021). when required. it is not permitted to create records that precede the date of birth. and the system compares value ranges with Data Dictionary domain values in exactly the same manner that it performs foreign key checks. which is designed to return the names of the fields that are to be excluded from foreign key checks. for example. and 3. Depending upon the entry in the Maintenance permitted after leaving (NAUST) field in the Infotypes: Customer-Specific Settings table (T582A). PUBLIC © 2014 SAP SE or an SAP affiliate company. a subset of foreign checks. any changes must comply with the following implicit checks. ENDIF. when required. the system may not permit the record to be maintained in inactive periods. ELSE. two constraints apply to this function. you may want your infotype to change the Keys for HR Master Data (PSKEY) field upon performing its checks. Disabling Value Range Checks Use By default. you could insert the following source code in method FOREIGN_KEY_EXCLUDED_FIELDS. In practice. however. Redefining method FOREIGN_KEY_EXCLUDED_FIELDS. when needed. Procedure Consequently. Because the business logic cannot derive these implicit checks from the Data Dictionary. it is not permissible to change either the Infotype (INFTY) or the Standard Selections for HR Master Data Reporting (PERNR) fields. Procedure The simplest approach for implementing radio buttons and checkboxes is to employ a domain with suitable values. is thus the most efficient manner of disabling. 3. In the event that both fields are changed. meaning that any change to the percentage field should result in a corresponding change in the value field. and because the MYINFTYDATE field does. the business logic will evaluate which of the fields is initial. the most useful of these being implementations CHECK_BY_T512Z. the value) to calculate the entry for the other field (in this example. and only then populate the Start Date field with the user entry.7 Performing Subtype Checks Procedure As delivered. To this end. such that the change in value will override the change in percentage. If only one field is initial. then issue a corresponding exception. these fields will not be processed. thereby removing the dependency from the display. then the screen logic will employ the predominant field (in this example. it is therefore vital that you disable foreign key checks for your subtype fields. then no additional action is necessary. a value field and a percentage field – that are mutually dependent. if such messages are issued via the MESSAGE command. which would result in a short dump. For this reason. the system supports generic subtype checks. if any condition established by these checks is violated. (The system cannot issue an error message in this case. rather than MYINFTYDATE. the only date that any user can enter is in that field. to this end you must isolate such messages and re-map them either into genuine exceptions or into interface IF_HRPA_MESSAGE_HANDLER. when any of these checks is violated. specific date field of its own.3. However.) To prevent the system from issuing the exception in this example. the percentage). Because the latter fields do not appear on the infotype screen.4. If such messages are issued via the MESSAGE RAISING command. PUBLIC © 2014 SAP SE or an SAP affiliate company.4. the value field – must predominate. 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.Procedure Because they are implicit. and the error initially will not be detected. If you do choose to perform subtype checks by means of this BAdI. 1. Implementing Mutually Dependent Fields Use Suppose your infotype features two fields – for example.7. then you must ensure that the system does not bypass them. to erase the value field entry when a percentage is entered. For this reason. A number of standard implementations are delivered with this BAdI. your infotype can easily issue an error message – for example. Aside from optional screen elements to suggest that the fields are mutually dependent. and vice versa. one of the two fields – in this example. If your infotype requires subtype checks in relation to other tables. rather than the user. the system considers the corresponding discrepancies to arise from the business logic. or if both fields are initial. The specified entry precedes the date of birth. this approach abstains from explicit business logic on the user interface. The approach described above is equally valid for any number of mutually dependent fields. which is introduced in the topic Performing Message Handling. because the infotype’s business logic populates BEGDA and ENDDA with MYINFTYDATE. you may also create new implementations. respectively). with the technical name MYINFTYDATE. However. but cannot determine all of the applications that pertain to a particular infotype. because it can only refer to BEGDA. the system would determine that the start date is too low. rather than an error message. Page 40 of 75 . the system will update the display accordingly. This approach is easily implemented by calling method COMPUTE_GBDAT. If neither field is initial.7. the business logic of your infotype should first check the MYINFTYDATE field entry in relation to the date of birth. CHECK_BY_T531 and CHECK_BY_T591A. all of the checks summarized above are processed before all infotype-specific checks.8 Calling Function Modules Procedure The action of calling function modules may simultaneously cause the system to issue corresponding messages. All rights reserved. Now suppose that the user enters a date that precedes the date of birth. Once the corresponding business logic is processed and the mutually dependent fields are again consistent. If foreign key checks and Business Add-In HRPAD_SUBTY_CHECK are simultaneously active. 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. Therefore. the system issues an exception. and conversely. and a new percentage will be calculated in proportion to the changed value. Because the Start Date and End Date fields are hidden. then the system may issue inconsistent error messages. With this approach. Example Suppose your infotype features a new. which is mapped to the Start Date and End Date fields (BEGDA and ENDDA. upon processing the business logic. then the business logic will derive its entry from the other field. With this method in place. 1. subtype checks are performed by means of the Business Add-In (BAdI) HRPAD_SUBTY_CHECK. is_ok = false. we recommend that you implement the following business logic. ENDIF. this business logic also allows your infotype to read cost assignment and other secondary data. 1. pme04-molga = molga( tclas = tclas pernr = l_pskey-pernr begda = l_pskey-begda ). . review interface IF_HRPA_READ_INFOTYPE. EXCEPTIONS exception1 = 1 exception2 = 2 error_message = 3 others = 4. p0001 = p0001( tclas = tclas pernr = pernr begda = begda ). CALL METHOD message_handler->add_message EXPORTING message = msg field_list = field_list cause = if_hrpa_message_handler=>infotype_specific. All rights reserved.3.7. The above business logic enables your infotype to obtain multiple records from the corresponding infotype to be read. 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.Example If you wish to re-map function module messages into interface IF_HRPA_MESSAGE_HANDLER. the Organizational Assignment and Payroll Status infotypes (0001 and 0003. then you may employ the following business logic. Read method P0001 is called in the following manner. If no country grouping can be determined. Page 41 of 75 . MOVE-CORRESPONDING sy TO message. If you would like to implement the method READ_SINGLE in your infotype. P0001 and P0003. Procedure If you plan to create a new infotype. 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. then SPACE will return. CALL FUNCTION . PUBLIC © 2014 SAP SE or an SAP affiliate company. .4.10 Reading Infotypes Use For infotypes that must be read frequently – for example. respectively) – the standard system provides corresponding read methods – for example. IF sy-subrc = 3. By means of the method READ_SINGLE. and if your infotype will require data from other infotypes. then modifying the copy to suit your requirements. For example. Never buffer tables explicitly. nor with an external perform into subroutine pool SAPFP50P. provided that such a function module already exists. · Never include in your new class methods that will issue messages or exceptions. t503 = cl_hr_t503=>read( persg = p0001-persg persk = p0001-persk ). standard specialized classes are delivered. If your infotype must nonetheless read a Customizing table for which no standard specialized class is delivered. as well as return parameters. respectively. you may create a new class for this purpose by copying an existing specialized class. the standard system automatically performs foreign key checks by using classes CL_HR_T001P. · If the required data cannot be read. other Customizing tables exist for which no such classes are delivered. Performing Foreign Key Checks). to read the corresponding tables. Procedure In the event that no standard specialized class exists for a Customizing table that your infotype must read. · Always order by primary key any table output to be issued by your infotype. as you modify your copy of either standard class to suit your requirements. Page 42 of 75 . but in fact reduces overall system performance. they always observe the naming convention CL_HR_<tablename>. always set the output to be initial. Furthermore. always choose Pretty Printer from the application toolbar. CALL METHOD a_foreign_key_check->add_foreign_keys EXPORTING foreign_key_structure = t001p. · Always implement the method READ for a full specified key. moreover. for the application server already will buffer them by default. t001p = cl_hr_t001p=>read( werks = p0001-werks btrtl = p0001-btrtl ). All rights reserved. If you do choose to employ an existing function module to read Customizing tables. we recommend that you use standard class CL_HR_T582A or CL_HR_T582V as a template. PUBLIC © 2014 SAP SE or an SAP affiliate company. For example. as described in the following topic. As illustrated below (and in a previous topic. · Avoid appending results to export parameters. Personnel Areas table (T500P) and Employee Group/Subgroup table (T503). These classes enable standard business logic. if your new class is to read the Plant key field (WERKS). t500p = cl_hr_t500p=>read( persa = p0001-werks ). CALL METHOD a_foreign_key_check->add_foreign_keys EXPORTING foreign_key_structure = t503. Creating New Specialized Classes to Read Customizing Tables Use Although standard specialized classes are delivered for many Customizing tables. when required. then you may employ a suitable function module for this purpose. Reading Customizing Tables with Existing Specialized Classes Use For many Customizing tables. Procedure If no suitable function module exists. CL_HR_T500P and CL_HR_T503 to read the Personnel Area/Subarea table (T001P). then name it CL_HR_T510U.Never substitute the method READ_SINGLE with function module HR_READ_INFOTYPE. make certain that any message statements within it are remapped either into genuine exceptions or into interface IF_HRPA_MESSAGE_HANDLER. · Only perform buffering for single infotype records. For additional guidelines on calling function modules. for reference. which is introduced in the topic Performing Message Handling. you may create a new class for this purpose. CALL METHOD a_foreign_key_check->add_foreign_keys EXPORTING foreign_key_structure = t500p. · Before saving your business logic. then implement method READ_BY_WERKS. we recommend that you adhere to the following guidelines.) · Always clear return values or tables before subsequently filling them. always observe the naming convention READ_BY_<key field>. If you choose to pursue this route. always observe the naming convention CL_HR_<tablename>. Wherever such standard classes are delivered. if your new class is to read the Pay Scale Groups table (T510U). · When creating a new specialized class to read Customizing tables. they facilitate processing by offering a central buffering location. (Buffering full tables may appear to increase the performance of your infotype. consult the corresponding topic. · If your new specialized class requires other methods to read data. Class CL_HRPA_FEATURE conforms with the exception handling principles described previously. tables that originally exist in Core usually require specialized classes to be created in Core as well. we recommend that you instead employ the business logic shown in the following example. however. As you migrate a particular infotype into this release. the method that calls this class.If you choose to create a new specialized class. rather than for individual infotypes. then you can replace these fields in this release in a very simple manner. If you nonetheless wish to repress repeated warnings. In contrast. then you can replace these fields in this release with the method SPECIFIC_INITIAL_COMPUTATIONS. All rights reserved.4 Writing Infotype Records PUBLIC © 2014 SAP SE or an SAP affiliate company. One-time warnings. CLEAR varky. Reading Features Use Standard business logic. If you do not need to migrate infotypes into this release. CALL METHOD cl_hrpa_feature=>get_value EXPORTING feature = feature_name struc_content = pme01 IMPORTING return_value = varky. Page 43 of 75 . then you must design the graphical user interface accordingly. then disregard the following information. if the system evaluates these fields in prior releases to determine whether the record is newly created. carefully consider whether to create it in Core or Extension. which are no longer used in this release. if you wish to explicitly ignore cases in which the feature cannot be read. shown in the example below. since this release offers a specific method for each corresponding operation. is much shorter than the corresponding function modules. respectively) solely concerns infotypes that must be migrated into this release. Procedure In prior releases. Prerequisites The replacement of the New selection of an infotype record and Infotype operation fields (NSELC and IOPER. In some cases. which does not conform with the exception handling principles cited here. CATCH cx_hrpa_invalid_feature. any relevant warning message should be repeated in the business logic as often as necessary. 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. are not supported within standard business logic.4. under certain circumstances. you should create the new class in the original (Core or Extension) system of the corresponding table. The information presented in this topic exceeds the general knowledge that is required to migrate infotypes into this release. If the system evaluates fields PSYST-NSELC or PSYST-IOPER in prior releases to distinguish among operations for insertion. Individuals who have particular expertise in this subject matter or who desire deeper knowledge of this issue may nonetheless consult this topic for reference. modification and deletion. 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. CALL METHOD cl_hrpa_feature=>get_value EXPORTING feature = 'IVWID' struc_content = pme04 IMPORTING return_value = viekn. In such cases. 1. but which does conform with standard processing. uses class CL_HRPA_FEATURE to read features. However. and this processing must be performed centrally. In general. the system evaluates these fields in prior releases in order to present a one-time warning message. when required. some infotypes evaluate in structure PSYST the New selection of an infotype record and Infotype operation fields. exception handling may not be appropriate – for example. To this end. then no technical limitations exist to prevent it from inheriting the properties of the standard check class (or “superclass”) CL_HRPA_INFOTYPE_NNNN. · If retrocalculation or authorization checks fail. remember to provide business logic with sufficient processing instructions for your own infotype as well. 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. which represent PUBLIC © 2014 SAP SE or an SAP affiliate company. For additional information. you may refer to the subsequent topics in this section. cannot take note that updates have been performed without their knowledge. endless recursion may result. On balance. through which the system bypasses processing the business logic (including checks) of the other infotype(s) to write data to the buffer. if you cannot update the other infotype(s) and do not wish to update yours either. however. including the following: · If indirect access is used to process your own infotype. however. Procedure If sufficient conditions exist to restrict the updates of other records to dialog mode only. Indirect access nonetheless can be applied in this case. For this purpose. Conversely. you may wish to update your infotype just the same. 1. then it must instead inherit the properties of the superclass CL_HRPA_INFTY_NNNN. then issue an appropriate message from within your own infotype. and indirect access may fail. indirect access must be avoided. if you cannot update the other infotype(s). In this case.4. we recommend that you take a moment to examine how infotype records are written. but the caller must be available to handle the situation. is inappropriate. Because the manner in which the system manipulates the buffer in this release differs from that of prior releases. too. because such messages generally apply to dialog users.4.1 Background Information The following topic provides additional background information to describe how infotype records are written. 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. each topic addresses an aspect of managing infotypes that modify other infotype records within the system.2 Using Containers to Write Data Purpose The system does not handle actual records to access the buffer and write data to it. as described in the topic Creating Country-Specific Check Classes. then you would write the statement IS_OK = false and create a suitable error message. through which the system first processes the business logic (and checks) of the other infotype(s). Indirect access. consider why your infotype needs to update other records. Page 44 of 75 . then indirect access may fail. As you consider the appropriate message(s) to issue. only classes that inherit their properties from superclass CL_HRPA_INFTY_NNNNcan write to the actual buffer. may fail for several reasons. then the other infotype(s) may not be written. 1. Individuals who have particular expertise in this subject matter or who desire deeper knowledge of this issue may nonetheless consult these topics for reference. in this case. To obtain an understanding of how infotype records are written in the system. the system instead always uses containers. you are therefore advised to evaluate the IS_OK statement.Use Some infotypes in your system may need to manipulate more data than the current record contains. In other words. · · · · · · · · · 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. Given the potential failures summarized above. which are summarized below. then you should by all means hard-code the corresponding updates – but not in the infotype business logic itself. All rights reserved. in any event. Simply issuing the error message(s) from another infotype. Indirect access can still be applied in these cases. for example. (End users.4. we recommend that you review the Personal Data infotype (0002) as an example. as noted in the topic Creating Single Check Classes. if your class will indeed write data to the buffer. you would write the statement IS_OK = true and not issue error messages. The goal of this analysis is to determine whether your infotype would truly require the corresponding updates to be hard-coded. but the caller must be available to handle the situation. or indirect access.4. Two routes are available for accessing the buffer – either direct access.) 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. If your class will not write data to the buffer. However. then writes data to the buffer. if you choose to employ indirect access within your infotype. it is important to consider the appropriate response if indirect access should fail. rather than end users. · If unacceptable input causes the checks of the other infotype(s) to fail. which is introduced in a subsequent topic. you can review attribute A_MASTERDATA_BUFFERto this end. Thus. 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. and thereby ensure that data can be read through the business logic of the other infotypes. All rights reserved. you may review. DATA message_list TYPE REF TO cl_hrpa_message_list. As this example demonstrates data that is read from the buffer directly.the abstraction of a record. you must first determine the corresponding container. Note that this example does not issue messages through interface IF_HRPA_MESSAGE_HANDLER. If you do choose to access the buffer indirectly. On balance. to read data from another infotype via interface IF_HRPA_READ_INFOTYPE and then to create the container. however. Reading Before Writing Process Flow Containers are read via interface IF_HRPA_MASTERDATA_BUFFER. It is not expedient. in the event that you wish to subject the data to the checks of other infotypes. however. in order to obtain access to data in another infotype (as a prerequisite for writing your data to the buffer). such instances are usually written as an attribute within method GET_INSTANCE. all examples of infotypes are assumed to be processed by container IF_HRPA_INFOTYPE_CONTAINER. which will be appropriate under certain limited circumstances. Page 45 of 75 . which would be created within the constructor of your class. The following business logic provides an example of direct buffer access. you may choose to write data to the buffer through the business logic of those infotypes. CALL METHOD cl_hrpa_masterdata_bl=>get_instance PUBLIC © 2014 SAP SE or an SAP affiliate company. the Classes for Determining Version IDs and Infotype Containers table (T582ITVCLAS). as illustrated below. that the target infotype may already perform specific computations as data is read. however – whether specialized infotypes created in this release. it would be fully compatible with data that is directly written to the buffer. as this approach is likely to result in data loss and is certain to impair performance. if desired. Process Flow Containers are read on demand. Consider. where infotype views are present Cost assignment data Infotype text data In this release. but rather through a message list of its own. 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. you may wish to disable authorization checks. To determine the container that will process your infotype. Moreover. From this point forward. CREATE OBJECT message_list. DATA infty_container_tab TYPE hrpad_infty_container_tab. infotypes generally must be processed by container IF_HRPA_INFOTYPE_CONTAINER. you may prefer to access the buffer indirectly. Also note that this example requires an instance of the business logic. in this example. The following business logic provides an example of indirect buffer access. containers are seen within the system as instances of class CL_HRPA_INFOTYPE_CONTAINER. or infotypes to be migrated from prior releases – are processed by a different container. In most cases. DATA infotype_container_tab TYPE hrpad_infotype_container_tab. In general. it is appropriate to read data from the write buffer (with buffer_mode = 'W'). Some infotypes. within class CL_HRPA_INFTY_NNNN. rather than directly. A container can hold any or all of the following data: · · · · Infotype records Secondary infotype records. This disadvantage is offset by the advantage of increased flexibility. This latter approach features one disadvantage. CALL METHOD a_generic_update->delete (Interface IF_HRPA_GENERIC_UPDATE->DELETE) This approach will delete the record. Creating New Containers Before Writing Procedure If you wish to insert new records. However.IMPORTING masterdata_bl = a_masterdata_bl. your infotype generally will need to modify its contents. primary record. If these entries do not match. then you must create completely new containers. Once modification is complete. this is the recommended approach for updating records of your own infotypes. it must first read the corresponding container. then typecast the container to class CL_HRPA_INFOTYPE_CONTAINER. via the MODIFY_KEY method. retrocalculation. time constraints. your infotype will encounter a new container. time constraints.5 Modifying Contents of Containers Use Upon creating or reading a container. you do not need to avoid other references to the container. you must first ensure. which is done with one approach for direct access. Upon modifying the contents of the container. 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. nor do you need to create copies of the container in an effort to protect the buffer. Procedure Once you are certain that the container features the correct key. which is maintained in the Classes for Determining Version IDs and Infotype Containers table (T582ITVCLAS). you may pursue one of three approaches to perform the deletion. 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.6 Deleting Existing Records Procedure Before your infotype may delete a record. call the GET_INSTANCE method of the container class. This is the recommended approach for deleting records of other infotypes. use the following method(s) to populate the container with the corresponding data.4. With this approach. and you must anticipate how the system will respond in the event that this advance processing fails. retrocalculation. call the GET_INSTANCE method of the business logic. a reference to interface IF_HRPA_INFOTYPE_CONTAINER is returned. 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. in order to process data in advance. you must typecast the required containers to class CL_HRPA_INFOTYPE_CONTAINER. remember to consider how it will process secondary data. and a different approach for indirect access. In the unlikely event that you wish to perform additional processing with the container. which is introduced in a subsequent topic. For direct access. To this end. All rights reserved. namely that it already surrenders control the other infotype(s). and so on. With this approach. 2. 1.4. 3. In the event that your infotype is to process infotype views. as described in the topic Reading Before Writing. it is seldom applied to delete existing records. then a short dump will occur. · MODIFY_PRIMARY_RECORD · MODIFY_SECONDARY_RECORD · MODIFY_PREF · MODIFY_DATA · MODIFY_TEXT_TAB The container will only process methods MODIFY_PRIMARY_RECORD. that the container features the correct key … unless you have recently created the container and you know that it already has that key. Page 46 of 75 . whether you choose to read data from the buffer directly or indirectly. but it will not process generic business logic – for example. 1. Once the corresponding container has been read. a container will not lose text data (when present) if the key. or secondary record are changed. your infotype will not need to handle messages. your infotype will need to handle messages. and so on. For this reason. To avoid endless recursion.4. CALL METHOD a_masterdata_buffer->read (Interface IF_HRPA_MASTERDATA_BUFFER->DELETE) This approach will directly delete data from the buffer. the system never alters the contents of the previous container. With this approach. It will also process generic business logic – for example. PUBLIC © 2014 SAP SE or an SAP affiliate company.4. then you may wish to typecast it again to class CL_HRPA_INFOTYPE_CONTAINER. your infotype will need to handle messages. For indirect access. Due to the nature of this approach. Ultimately. then you may not change the key. 1. TYPE REF TO if_hrpa_infty_container. In other words. CREATE OBJECT message_list. This example further assumes that the corresponding business logic is run in method SPECIFIC_MODIFY_COMPUTATIONS of infotype 9999. Unless you have a specific reason to do so. METHOD specific_modify_computations. in this case. you must always consider the appropriate response if the deletion should fail (for example. * The following check is to optimize performance CHECK is_ok = true. rendering key changes impossible. DATA it8888_container TYPE REF TO cl_hrpa_infotype_container. is_ok = true. refrain from using interface IF_HRPA_MESSAGE_HANDLER. in response to retrocalculation or authorization checks).4.7 Inserting New Records Procedure New records are inserted in a manner similar to the one in which existing records are deleted. Exceptions of type CX_HRPA_VIOLATED_ASSERTION can arise with any of the three deletion approaches summarized here. Page 47 of 75 . no matter what prevented the deletion from occurring. which is introduced in the topic Performing Message Handling. The infotypes named in this example – 8888 and 9999 – do not exist in the standard system. All rights reserved. of class CL_HRPA_MESSAGE_LIST). But regardless of the response you choose to implement. If you wish to update the buffer directly. you may change the key of the containers. TYPE boole_d. containers are read CALL METHOD a_masterdata_bl->read EXPORTING tclas = tclas PUBLIC © 2014 SAP SE or an SAP affiliate company. the buffer will remain in the same state as before the attempted deletion. DATA p9999 TYPE p9999. as illustrated in the first approach for deletion in the topic Deleting Existing Records. if desired. DATA p8888_ref TYPE REF TO data.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. The following example demonstrates business logic that could be applied to modify the records of another infotype. which will allow your infotype to evaluate any messages that arose during the deletion of records. This example assumes that attribute A_MASTERDATA_BL was already populated (from class CL_HRPA_MASTERDATA_FACTORY) while the system processed the constructor method. if you choose to apply this example. DATA message_list DATA l_is_ok TYPE REF TO cl_hrpa_message_list. FIELD-SYMBOLS <p8888> TYPE p8888.If you pursue the second or third approach named above. p9999 = pnnnn. it is more expedient to create your own instance (for example. we recommend that you disregard such exceptions. DATA container_tab DATA container TYPE hrpad_infty_container_tab.4. you must issue both the old and the new container. and that infotype 8888 is to be updated. since the system automatically rolls it back if errors occur. the buffer essentially reflects the current state of the database. Regardless of the approach you choose to pursue. Otherwise. then modify the infotype numbers and delete the comments.4.4. * At this point. and the system employs methods A_MASTERDATA_BUFFER->INSERT and A_GENERIC_UPDATE->INSERT. p9999 is to be filled with new values * Infotype 9999 will be modified even if Infotype 8888 cannot be pnnnn = p9999. a failed operation will never alter the buffer. 1. since the system has no other means to ascertain that a change has occurred. However. with two important differences: your infotype does not need to read the container to be inserted. * Checks or special calculations for p9999 would follow below * When these are complete. 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. * Clearing the message list. * For this example. Page 48 of 75 . data is extracted from the container it8888_container ?= container.4. messages and l_is_ok are ignored * Actual infotypes. * The container itself is modified container ?= it8888_container->modify_primary_record( <p8888> ). because method SPECIFIC_MODIFY_COMPUTATIONS permits key changes to occur. All rights reserved. * A sample field is modified <p8888>-foo = p9999-bar. however. 1. it is indispensable CREATE OBJECT message_list. ASSIGN p8888_ref->* TO <p8888>.9 Using Pushbuttons PUBLIC © 2014 SAP SE or an SAP affiliate company. in this example. CALL METHOD it8888_container->primary_record_ref IMPORTING pnnnn_ref = p8888_ref. * 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. * At this point. No methods are available in the standard system to perform delimitations or partial deletions. if you wish to evaluate it later. Consequently.4. * 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. may require error handling here * Also. is not required * However. instances of this method are only to be applied when key changes will not result in errors. ENDMETHOD. 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. · [vv] signifies the infotype version. 2. 3. Either to perform an action that depends on the user interface – for example. 1. in which the check classes of infotypes are assigned to containers and infotype versions. Procedure In order to declare your operation. the entries 06 and 10 denote France and the United States. then you must modify this separate view (V_T582ITVOPER) to declare that the operation is indeed valid for that infotype. we recommend that you apply a “CASE operation” statement to distribute processing among the various operations. subtypes and country-specific versions for which the infotype operation may be implemented. View V_T582ITVCHCK does not use the Country Grouping (MOLGA) field to determine the version. 1. All rights reserved. Modify the Infotype Operations view (V_T582ITOPER) to create a suitable infotype operation. then the system will store exactly 501 entries in view V_T582ITVCLAS. in a multitude of views. Modify the Infotype Operations view to declare the infotypes. Without exception. In the first view. if your infotype is able to process a certain operation. which are required for subsequent processing. although certain infotypes are not assigned to this container. No additional action is required for users to generate the requisite entries in any view. Nonetheless. which enable them to perform additional functionality – for example. However. In other words.Use Certain infotypes feature pushbuttons. the system automatically generates entries. whenever you declare an operation in this view. Both views were introduced to the standard system with the revised framework for creating infotypes. We also recommend that you use a separate method for each value of the case operation. In the second view. perform the following procedure. by extending a model access class. to navigate elsewhere. to compute values. then the operation will only process one infotype container. Procedure If you wish to perform the first type of function.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). the appropriate container is CL_HRPA_INFOTYPE_CONTAINER. 2.4. Page 49 of 75 . you must also declare an input and output structure for which valid Data Dictionary entries exist. Therefore. in either field. to populate fields with values. you may wish to review the user interface programming guidelines that apply to Personnel Administration infotypes created in this (or any subsequent) release. if the number of valid standard and customer-specific infotypes in your system is 501. and it may alter the contents of this container in an unforeseeable manner. remember the following rules of thumb: PUBLIC © 2014 SAP SE or an SAP affiliate company. as defined in the Entity Table for Infotype Versions (T582ITVERS) · [ssss] signifies the subtype (where required). Or to call business logic that does not depend on the user interface – for example. Although the corresponding valid entries for each field are often similar. respectively.9. V_T582ITVCHCK. you must follow this convention. in the ID for Infotype Versions (ITVERS) field. 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).4. then you must apply a corresponding user interface and provide the source code there yourself – for example. they are not identical. Generic support is available for the second type of function. a single entry is created for each infotype to assign the corresponding check class to a container. the system stores one single entry in view V_T582ITVCLAS for every valid infotype within the system. Modify method SPECIFIC_ACTION_COMPUTATIONS in the applicable infotype-specific check class(es) to provide source code with suitable handling instructions. 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). but rather the ID for Infotype Versions (ITVERS) field. respectively. In other words. If you fail to declare these structures. to avail yourself of this support and to introduce such functions in your infotype. where: · [nnnn] signifies the infotype number. 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). any pushbutton enables an infotype to perform one of two functions. namely: 1. Broadly speaking. Each entry thus created is used to assign the corresponding check class to an infotype version. For the majority of infotype entries stored in view V_T582ITVCLAS. 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. V_T582ITVCLAS. To this end. and · operation_name provides a meaningful description of the operation at hand. For example. users may wish to consider this topic for additional background information. or to execute external reports. To implement the operation. To enhance master data consistency and improve performance. UI Programming Guidelines for Infotypes This section discusses important guidelines for programming user interfaces in a de-coupled environment. All rights reserved. In the revised framework for creating infotypes. To this end. (No entry exists in view V_T582ITVCHCK for the Belgian version. the revised framework. At Release 4. 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. and if you for example neither wish to migrate these infotypes to comply with. That framework remains operative in this and every subsequent release. then you may instead specify the value Not Permitted here. nor permit them to be processed by. 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. Infotypes in other functional areas (for example. We recommend that you review these guidelines. this section discusses the user interface programming guidelines that apply to the creation of new Personnel Administration infotypes. Programming User Interfaces in the De-Coupled Framework Purpose PUBLIC © 2014 SAP SE or an SAP affiliate company. 2. meaning that customer-specific infotypes or individual infotype records that were created at Release 4. In contrast. along with the corresponding Business Logic Guidelines for Creating and Migrating Infotypes. HR Administrative Services – introduced in the standard system after or in tandem with In summary. then view V_T582ITVCLAS will contain a single entry for that infotype. Any entries that you cause to be generated in a Customizing client in views V_T582ITVCLAS or V_T582ITVCHCK must be transported manually. New Zealand and South Africa.) In contrast. Page 50 of 75 . a single entry exists for the Personal Data infotype (0002). respectively. Example The following examples serve to illustrate the presence (or absence) of entries in each view for the corresponding infotype. which (as introduced in the topic Creating Country-Specific Check Classes) has five country versions. or any release thereafter. For any new entries that you cause to be generated in view V_T582ITVCLAS. while view V_T582ITVCHCK contains no entry. the corresponding infotype will be identified to comply with the revised framework that exists in this release for creating infotypes. for the Communication infotype (0105). then we recommend that you observe the user interface programming guidelines set forth below. while one entry exists for each of various versions of that infotype – altogether dozens of entries – in view V_T582ITVCHCK. while no entry will exist for that infotype in view V_T582ITVCHCK. By accepting this value. In contrast. If only an international version of an infotype exists. in this (or any subsequent) release. you may therefore wish to “migrate” into this release existing infotypes from Release 4. V_T582ITVCLAS. because this version uses the same check class as the international version.6C or below will continue to function in this release.1. In the first view. but if one of these versions uses the same check class as the international version.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. as needed. whenever you execute the Create Infotype transaction (transaction code PM01) to create new Personnel Administration infotypes and program the corresponding user interfaces. for which only an international version exists. in view V_T582ITVCHCK. then no entry will exist for that version in view V_T582ITVCHCK. if customer-specific infotypes exist in your system from prior releases. a single entry also exists in view V_T582ITVCLAS. For the External Transfers infotype (0011). If multiple versions of an infotype exist. where the user interface was not de-coupled from the corresponding business logic. whether standard or customer-specific. the revised framework. Norway. Time Management) are not affected. The programming guidelines set forth below solely apply to standard Personnel Administration infotypes. Personnel Administration infotypes were created in a previous framework. it is important to note that infotypes that have not been migrated cannot be processed by applications – for example. and therefore relates to the creation of new Personnel Administration infotypes in this and every subsequent release.6C and in prior releases. Although you are not required to migrate infotypes from the previous framework. view V_T582ITVCLAS contains a single entry. the user interface of any infotype is completely de-coupled from the corresponding business logic. four entries exist for that infotype – one each for the country versions of Switzerland. Conversion classes therefore convert data that is stored for the corresponding Pnnnn structure into data for the screen structure. The conversion class converts infotype data from the back end for representation on the user interface. including: ● the display of specific values via input help. 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. the default conversion class – CL_HRPA_UI_CONVERT_BASIC – can be assigned instead. ● An entry in the Assignment UI Structures and UI Conversion Classes view (V_T588UICONVCLAS). For additional information. while the conversion of screen structure data into Pnnnn structure data is called input conversion. For additional information on any aspect of this functionality. The user interface area of the de-coupled framework covers these requirements. input help automatically PUBLIC © 2014 SAP SE or an SAP affiliate company. then additional requirements arise. or vice versa.The de-coupled framework primarily consists of two areas – one area that relates to the back-end business logic of an infotype. we recommend that you consult the Business Logic Guidelines for Creating and Migrating Infotypes. To this end. the standard system features many types of generic functionality. if you wish to create a new Personnel Administration infotype in the de-coupled framework and program its user interface accordingly. Output conversion denotes the conversion of Pnnnn structure data into screen structure data. all user interface fields that bear the same technical names in the back end are automatically filled. the following entities must exist: ● A Data Dictionary structure (known as a screen structure). consult the Screen Structures topic. In addition to converting data. To this end. and if necessary edited. Prerequisites In the de-coupled framework for creating infotypes. which describe aspects of this process in detail. To simplify the programming of user interfaces in the de-coupled framework. or vice versa. which defines the conversion of the infotype fields from their representation in the back end to their representation on the user interface. edited – on the user interface. in the user interface. {For example. if a screen structure is defined to be country-specific. If a screen structure is defined to be international. read-only. The entries in this view enable the de-coupled framework to call the correct conversion class when processing a particular screen structure. All rights reserved. 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. for any infotype that is to be displayed (or edited) in the user interface. you may wish to display the age of an employee derived from his or her date of birth. and which thereby governs the assignment of conversion classes to screen structures. as described in the topic referenced immediately above. refer to the Conversion Classes topic. The fields defined therein include editable fields. read-only fields. 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. choose the corresponding link. ● performing any kind of calculation that converts values entered on the user interface to values that are to be stored in the infotype. ● setting metadata based on values entered – for example. when you have finished creating a new Personnel Administration infotype in the de-coupled framework. the existence of de-coupled business logic is a prerequisite for the creation of de-coupled user interfaces. you are required to have created the corresponding business logic already. read-only or hidden. ● An ABAP-OO class (known as a conversion class). the de-coupled framework requires programmers to consider the business logic of an infotype separately from its user interface. conversion classes also provide field attribute information. which users can activate by performing the corresponding Customizing. This functionality includes a generic approach to provide input help values. Thus. ○ Assuming that the corresponding Customizing has been performed. if necessary. In such cases. review the documentation provided with it. then it will contain fields that are valid for the country version in question. and if the user should be able to maintain it. For a description of this default conversion class.) ● the display of descriptive texts for key values stored in the infotype. screen structures themselves are defined to be either international or country-specific. and storing infotype data on the database. mandatory. For additional information. In short. For additional information. In the event that the infotype in question lacks specific user interface requirements. the screen structure contains all of the infotype fields that should be part of the user interface. However. (For example. the automatic retrieval of descriptive texts for fields that hold key values and the automatic handling of repeat fields. Finally. 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. then it is not necessary to assign a dedicated conversion class to it. if the infotype is to be displayed on the screen. and a second area that enables the infotype to be displayed. the process of displaying and editing an infotype in the user interface consists of the following phases. consult the topic Conversion Classes. To support the country-specific requirements of Personnel Administration infotypes. For additional information on this test tool. conversion classes not only specify whether a particular field is mandatory. As stated above. which contains all of the infotype fields that should be part of the user interface. handling time constraints.} ● dividing the value of one infotype field into several fields shown on the user interface. As stated above. including: ● ● ● ● checking the consistency of infotype data. In contrast. Page 51 of 75 . back-end data is converted into screen structure data. but also furnish the supported field values to populate drop-down list boxes or input help on the user interface. which defines the conversion class that the system will apply to the corresponding screen structure. and so on. ● Output Conversion During output conversion. generic functionality to provide input help values is applied. and descriptive texts. then that screen structure will only contain fields that are country-independent. for the user interface fields. In summary. read-only information. ● the display of additional. and vice versa. as well as input help. Process Flow In the de-coupled framework. review the Assigning Conversion Classes to Screen Structures topic. which in turn is displayed – and. ○ If the default conversion class CL_HRPA_UI_CONVERT_BASIC is used. The business logic area of the de-coupled framework covers a number of requirements. 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. triggering retrocalculations (where necessary). where they are defined. field attribute information (for example. ● Input Conversion Screen structure data – which has been displayed (and. the automatic retrieval of descriptive texts is applied. ● AGE ● This field should display the current age of the employee. these fields require corresponding representation in the screen structure. ○ No action is required for field attribute information. This class simply uses a MOVE-CORRESPONDING statement to pass the field values to the screen structure. read-only. In addition to the fields from structure P9001. Therefore. as this information is already defined in the database. ○ If the default conversion class CL_HRPA_UI_CONVERT_BASIC is used. then the default conversion class cannot be applied. the INPUT_CONVERSION method of the corresponding conversion class therefore must be implemented. and the OUTPUT_TABLE_CONVERSION and INPUT_TABLE_CONVERSION methods of that conversion class must be implemented. the corresponding descriptive text (Mr. a dedicated conversion class must be created and assigned to the infotype screen structure in view V_T588UICONVCLAS. but not for others. therefore. all back-end fields that bear the same technical names on the user interface are automatically filled. GBDAT and ANRED – are considered to be relevant for the user interface. because it enables the programmer to use the default conversion class – CL_HRPA_UI_CONVERT_BASIC – if desired.. see Repeat Field Screen Structures (Type LINE). Rather. the OUTPUT_CONVERSION method of the corresponding conversion class therefore must be implemented. For infotypes that contain repeat fields. Using the same technical names provides a distinct advantage. these values are only relevant when the infotype is maintained in the user interface. a generic approach is also provided. 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. this field also is not needed in the user interface. (Even if a dedicated conversion class is required.. ○ No action is required for descriptive texts. and therefore require no conversion for storage in the database. it is not needed in the user interface. Rather. mandatory. Dr. edited) on the user interface – is converted into back-end data for subsequent database storage.becomes available for all fields. In other words. if necessary. In summary. using the same technical names ensures that the relationship between infotype fields and screen structure fields remain transparent.. and so on) should be displayed on the user interface. Example Suppose that you wish to create the user interface for infotype 9001. to facilitate processing. ● Field GBPAS is considered to be relevant for certain countries. Page 52 of 75 . Ms. 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. users should be able to enter the full employee name in a single user interface field. ● Field NCHMC is considered to be strictly technical. VORNA. then a dedicated conversion class must be created and assigned to the infotype screen structure in view V_T588UICONVCLAS. ○ Based on the metadata defined for the back-end fields. Because the screen structure to be created corresponds to an international (rather than country-specific) infotype. these texts are read-only by default. If additional processing is required for the infotype in question. If the generic approach for repeat fields is insufficient. and will not require corresponding representation within the screen structure.) Moreover. 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. With this field. for additional information. and also will not require screen structure representation. the same statement can be used to simplify programming. a dedicated conversion class must be created and assigned to the infotype screen structure in view V_T588UICONVCLAS. in addition to the key (numerical) values that are stored in field ANRED. Subsequent examples in the present guidelines may refer to the customer-specific infotype (9001) introduced below. In practice. and so on) is automatically provided. then the default conversion class cannot be applied. ○ Assuming that the corresponding Customizing has been performed. with the same technical names. 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. descriptive texts for fields that hold key values are automatically displayed. ○ No action is required for input help values. 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. If additional processing is required for the infotype in question. In practice. a corresponding screen structure must be created. ● All other fields – NACHN. FORM_OF_ADDRESS_TEXT This field should display the descriptive text for field ANRED ( Form-of-Address Key ). and the programmer must implement methods OUTPUT_CONVERSION and INPUT_CONVERSION therein. In accordance with this concept. with the exception of repeat fields. no additional action is necessary for such customer-specific fields when they are identically named in the infotype structure and screen structure. FR for France. Therefore. where: ● yy denotes the Version ID – for example. the automatic retrieval of descriptive texts can be applied. 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).2 Screen Structures Definition As discussed in the topic Programming User Interfaces in the De-Coupled Framework.INCLUDE. meaning that only the appropriate Customizing is required. then he or she must also remember to create corresponding new fields in the corresponding component type of the affected screen structure – for example. By the same token. However. To this end. Type MAIN screen structures observe the naming convention HCMT_BSP_PA_yy_Rnnnn. the de-coupled framework will ensure that identically named fields are automatically filled. 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. a dedicated conversion class for this screen structure is required. 1. Therefore. Where customer-specific field names bear different field names in the infotype structure and screen structure. PUBLIC © 2014 SAP SE or an SAP affiliate company. 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. and the default conversion class CL_HRPA_UI_CONVERT_BASIC cannot be used. it is important to remember the enhancement concept of standard infotypes when using any screen structure. Perhaps the most important attribute of any screen structure is determined in its technical name. without regard to a screen structure’s type.5. in the international type LINE screen structure (HCMT_BSP_PA_XX_R0008_LIN_A) of the standard Basic Pay infotype (0008). Examples of component . which enables the inclusion of customer-specific user interface elements on any standard infotype. that input help values and descriptive texts are automatically retrieved (if Customizing has been performed). 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. rather than dedicated source code. The majority of screen structures are country-specific. then a type LINE screen structure should be applied instead. the sole purpose of a screen structure is to display on the user interface data that is derived from. The naming convention of each screen structure type is explained in the corresponding subsequent topic. 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.ANRED Form-of-Address Key FORM_OF_ADDRESS_TEXT Form-of-Address Description Because of the screen structure fields FULL_NAME and AGE. and ● nnnn denotes the four-digit number that is assigned to the infotype. corresponding manual coding is required. If repeat fields are to be contained in the screen structure. then a type MAIN screen structure should be applied. specific requirements exist for this infotype. A third and final important consideration of any screen structure is the conversion class that is assigned to it. All screen structures must belong either to one type or the other. However. Infotype Screen Structures (Type MAIN) Definition Type MAIN screen structures contain all fields that require representation on the user interface. screen structures are Data Dictionary structures that contain all of the infotype fields that should be part of the user interface. the system applies this component to consider data in component type CI_XX_R0008_LIN_A.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. All rights reserved. However.INCLUDE enables the processing of customer-specific business logic in tandem with any standard infotype. Business Add-In (BAdI) HRPAD00INFTYUI must be implemented instead. which are to be displayed on the user interface in table format. No more than one type MAIN screen structure can exist per combination of infotype and infotype version. Use The specific use of type MAIN and type LINE screen structures is described in detail in the corresponding subsequent topic. the corresponding database. and country-specific screen structures only contain the fields that are valid for the country version in question – for example. UP for the United States Public Sector and US for the United States. For additional information on the relationship between conversion classes and screen structures. Therefore. for field FORM_OF_ADDRESS_TEXT. and XX for the international version. UP for the United States Public Sector. if no repeat fields are to be contained within the screen structure. which reflects whether the screen structure is either international (with entry XX) or country-specific (with any entry other than XX). US for the United States. Page 53 of 75 . consult the topic Assigning Conversion Classes to Screen Structures. International screen structures in turn contain fields that are suitable for display in any country version. the screen structure of any standard infotype delivered by SAP contains the component . but not stored in. 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. and that field attribute information is automatically provided. FR for France. much as the component . or different fields altogether. 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). as discussed in the topic Programming User Interfaces in the De-Coupled Framework. and is not relevant for user interfaces. ○ Name of Person Who Changed Object (UNAME). In some cases. an arbitrary and unique onecharacter suffix _z – for example. many screen structure fields are filled or otherwise processed automatically. To reiterate. ○ Lock Indicator for HR Master Record (Text) (SPRTX). Repeat fields are fields that are represented on the user interface of an infotype and that can contain several values. and XX for the international version. If a name range prefix is desired. Structure Type MAIN screen structures are composed of the following elements: ● Component OBJECT_KEY In the de-coupled framework.As with other customer-specific objects that observe a naming convention with the initial letter Z…. In other cases. PUBLIC © 2014 SAP SE or an SAP affiliate company. and so on – must be applied to each type LINE screen structure. If a name range prefix is desired. component OBJECT_KEY is strictly reserved for internal use. if no repeat fields are to be contained within the screen structure. Page 54 of 75 . _A1 or _A2 – may instead be applied. then the name of the screen structure must be shortened accordingly. _C. ● Include CI_yy_Rnnnn (for standard infotypes only) … where yy and nnnn adhere to the naming convention explained above. the technical names of any repeat field consists of a three-character stem – in this case. the Basic Pay infotype (0008) features the repeat field Wage Type Amount (with technical names BET01 through BET40) on its user interface. BET – and a series of consecutive two-digit numbers – in this case. However. which indicates whether or not the infotype record is locked. a given repeat field may be represented several times on the user interface of the corresponding infotype. As with other customer-specific objects that observe a naming convention with the initial letter Z…. Because repeat fields can contain several values. US for the United States. Once these methods are implemented. a twocharacter suffix – for example. ○ Changed On (AEDTM). a brief description of repeat fields is warranted and provided below. then a type MAIN screen structure should be applied instead. type MAINscreen structures for customer-specific infotypes observe the naming convention ZHCMT_BSP_PA_yy_Rnnnn. 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. where: ● yy denotes the Version ID – for example. ● Fields to be represented on the user interface. To illustrate. UP for the United States Public Sector. additional fields may exist. Type LINE screen structures observe the naming convention HCMT_BSP_PA_yy_Rnnnn_LIN_z. if repeat fields are to be contained in the screen structure. Multiple type LINE screen structures can exist per combination of infotype and infotype version. which reflects the user name of the party who changed the infotype record. this include enables customer-specific fields to be represented on standard infotypes that customers wish to enhance. ● nnnn denotes the four-digit number that is assigned to the infotype. Because the Wage Type Amount field has forty repetitions.) This second suffix serves to distinguish among the multiple type LINE structures that can exist per combination of infotype and infotype version. the fields contained within type MAIN screen structures are essentially intended for representation on the user interface. forty is also the maximum number of values that this repeat field is permitted to store. and therefore contains repeat fields. (Under some circumstances. As the repeat field Wage Type Amount demonstrates. these fields and the corresponding PSnnnn fields may be identical. Therefore. and ● LIN_z indicates (via suffix LIN) that the screen structure is of type LINE. As also discussed in that topic. To ensure the complete definition of type LINE screen structures in this topic. Therefore. Fields that cannot automatically be processed require handling in the corresponding conversion class by implementing methods OUTPUT_CONVERSION and INPUT_CONVERSION. including editable fields (for data entry) and read-only fields. FR for France. which indicates the validity period of the infotype record. In addition to suffix LIN. then the name of the screen structure must be shortened accordingly. _B. then a type LINE screen structure should be applied. All rights reserved. and ○ Start Date (BEGDA) and End Date (ENDDA). type LINEscreen structures for customer-specific infotypes observe the naming convention ZHCMT_BSP_PA_yy_Rnnnn_LIN_z. 01 through 40. or fewer fields. 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. as explained in the topic Assigning Conversion Classes to Screen Structures. 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. which indicates the date on which the infotype record was changed. the conversion class must be assigned to the screen structure. As discussed in the topic Screen Structures. _A. nnnn and LIN_z adhere to the naming convention explained above. BET01. the link is established between the repeat fields of the infotype structure and their representation in the corresponding type LINE screen structure. if no unusual user requirements exist. The remainder of this topic discusses the structure of tables T588AUTO_MAP and T588AUTO_TABLE. In the user interface of certain infotypes. Within the de-coupled framework. 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. the de-coupled framework applies a table to process all of the repeat field values. as well as the manner in which these tables are customized to enable standard functionality for type LINE screen structures. type LINEscreen structures are used to represent. Page 55 of 75 . Structure Type LINE screen structures are composed of the following elements: ● Component OBJECT_KEY In the de-coupled framework. while Name of First Repeat Field (REPEAT_FIELD01) reflects the name of the first enumeration of the repeat field in the infotype structure. standard functionality is available in the de-coupled framework to process type LINE screen structures. Where multiple repeat fields exist on a single infotype.Use In the de-coupled framework. groups of repeat fields may exist that do not logically belong together. BET02 and BET03). which is subsequently used to represent all forty repetitions. 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. if standard functionality is neither suitable nor possible for the type LINE screen structure in question. To illustrate. the type LINE structure defines the technical structure of that table. As discussed in the topic Screen Structures. This field contains the technical name of the corresponding type LINEscreen structure. the values of a repeat field on the user interface of an individual infotype record. these screen structures instead merely contain the Amount field (BETRG). only the Name of UI Structure field (SCREENSTRUCTURE) is a key field. To illustrate. in table format. as described in the topic Assigning Conversion Classes to Screen Structures. Never change or clear the value of this component! ● Fields to be represented on the user interface. In such cases. However. taken together. 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. then the default conversion class can be used and assigned to the type LINE screen structure. the type LINE screen structure itself will contain the Amount field (BETRG). At runtime. In contrast. ● Include CI_yy_Rnnnn_LIN_z (for standard infotypes only) … where yy. a separate type LINE screen structure is required for each divergent group of repeat fields. comprise the structure of table T588AUTO_MAP. rather than the Wage Type Amount repeat fields. Name of UI Table Field (TABLE_FIELD) contains the name of the repeat field in the type LINE screen structure. In contrast. The following chart summarizes the three fields that. By extension. a single type LINE screen structure in principle can contain all of the repeat fields that the infotype requires. then methods OUTPUT_TABLE_CONVERSION and INPUT_TABLE_CONVERSION of the corresponding conversion class must be implemented. each repeat field is stored in the type LINE screen structure only once. Each line of the table contains the value of the corresponding repeat field. All rights reserved. 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. 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). this include enables customer-specific fields to be represented on standard infotypes that customers wish to enhance. Table T588AUTO_MAP In Mapping for Conversion of Repeat Structure/Tables (table T588AUTO_MAP). if three values are to be represented in the Wage Type Amount field of the Basic Pay infotype (0008). 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. and is not relevant for user interfaces. component OBJECT_KEY is strictly reserved for internal use. However. including editable fields (for data entry) and read-only fields. As with type MAIN screen structures. 1. and so on. The following chart summarizes the four fields that. 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 1 2 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. if the application defines its own means of processing the insertion of new values. with an arbitrary amount of leading zeros – for example. a corresponding entry must be defined in Mapping for Conversion of Repeat Structure/Tables (table T588AUTO_TABLE). 01. or 001. comprise the structure of that table. other characters are not permitted. 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... The suffix must have the same length for all repetitions of the repeat field. among the four fields in this table. for each type LINE screen structure to be used. Therefore. and therefore are filled with initial values. within one type LINE screen structure – must have the same number of repetitions. In the following table. Page 56 of 75 . These prerequisites are summarized below. An additional empty line is appended to the table to enable new data to be entered. additional properties must be defined for the type LINE screen structure. Example The following tables refer to the Basic Pay infotype (0008) as an example to illustrate the conversion of repeat fields.. 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. In such cases.established in table T588AUTO_MAP. once can simultaneously employ the automatic retrieval of descriptive texts for key values within the 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. Moreover. at the end of the table. by using this generic functionality. The Blank Rows field (INITIAL_LINES) defines the number of additional initial lines that will be displayed on the user interface. The repeat field number must increase successively and without gaps. only the first two repetitions (01 and 02) in this example are filled with 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. Sample Basic Pay Infotype (0008) Record (Screen Structure) … LGART BETRG MA10 910 MA30 720 … In summary. On the user interface. The repeat field number of the first repetition must be 1. If even one of these prerequisites cannot be fulfilled. taken together. PUBLIC © 2014 SAP SE or an SAP affiliate company. one can perform repeat field conversion without the need to compose dedicated source code. Depending upon the application used. 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 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). along with other generic functionality provided by the de-coupled framework. 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. When repeat field conversion is performed. the values of the repeat fields Wage Type (LGA01 through LGA40) and Wage Type Amount (BET01 through BET40) are summarized. the value defined in this field may have great impact … or no impact at all. As one can see. ● ● ● ● ● ● The repeat field number must be an integer. All rights reserved. The repeat field number must be represented in the field name as a suffix.. Sample Basic Pay Infotype (0008) Record (Infotype Structure) . to permit new values to be entered. the two value pairs of this infotype record are converted into a table with two lines. these entries would be displayed in the following manner. All other repetitions are not used. All repeat fields within one group – that is. which represents an infotype record as it exists within the infotype structure. the maximum number of field values in the infotype. by customizing tables T588AUTO_MAP and T588AUTO_TABLE and using the default conversion class. then the standard functionality to process repeat fields cannot be applied. LGA01 BET01 LGA02 BET02 MA10 910 MA30 720 . the remainder of this topic and all subsequent topics in these guidelines always relate to standard conversion classes. All rights reserved. once an exception has been defined for the text identifier. and XX for the international version. To this end. if desired. In contrast. If – by using the appropriate functionality of the Create Infotype transaction – you elect to change the default fields of the screen structure. Instead.1. mandatory. If a name range prefix is desired. it will suffice to implement a standard conversion class. Data Dictionary information is automatically evaluated. However. regardless of the application that is using it. Conversion classes also play a key role in screen control functionality by providing input help values and attributes for user interface fields. and methods OUTPUT_CONVERSION and INPUT_CONVERSION must be implemented. a dedicated conversion class must instead be created and implemented. or if uses of the MOVE-CORRESPONDING statement are not desired. Conversion classes delivered by SAP observe the naming convention CL_HRPA_UI_CONVERT_nnnn_yy. instead of the standard infotype structures. conversion classes created by customers should observe the naming convention ZCL_HRPA_UI_CONVERT_nnnn_yy. advanced conversion classes pass this container. by means of the corresponding exception concept. PREFfor cost distribution. or if the field attributes are dynamically derived on the basis of the current infotype values. ● Input Help Values When the default conversion class is applied. based on the assumption that no specific user interface requirements exist. Use Conversion classes are assigned to screen structures. and methods OUTPUT_CONVERSION and INPUT_CONVERSION must be implemented. that exception can always be re-used by the text identifier. As delivered. where: ● nnnn ● denotes the four-digit number that is assigned to the infotype. ● Descriptive Texts When the default conversion class is applied and the corresponding Customizing has been performed. as well as the behavior of the methods themselves. standard and advanced conversion classes operate in an identical manner. and so on. If the screen structure contains fields whose field names differ from the field names in the infotype structure. then that class cannot be applied. 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). ● Field Values When the default conversion class is applied. UP for the United States Public Sector. In cases where this generic functionality is not suitable.3 Conversion Classes Definition As described in the topic Programming User Interfaces in the De-Coupled Framework. Two types of conversion classes are supported. assigned to the corresponding screen structure) if the infotype in question lacks specific user interface requirements. FR for France. and method FILL_HELP_VALUES must be implemented. in accordance with the specific user interface requirements. as described in detail at the end of these guidelines. a dedicated conversion class must be created. ● Field Attributes When the default conversion class is applied. Advantageously. If you wish to set different field attributes. unless explicitly noted otherwise. this conversion class must be implemented in accordance with PUBLIC © 2014 SAP SE or an SAP affiliate company. both to perform the necessary conversion of data and to provide screen control functionality. The default conversion class CL_HRPA_UI_CONVERT_BASIC is delivered in the standard system and can be used (that is. or if other user interface requirements exist for the input help values to be provided. To this end. Rather. where nnnn and yy denote the same information as in the conversion classes delivered by SAP.5. the text identifier can be enhanced. field attribute information (for example. Standard conversion classes implement interface IF_HRPA_UI_CONVERT_STANDARD. respectively). all user interface fields that bear identical field names in both the screen structure and the infotype structure are automatically filled. the set of methods to be implemented. If this generic functionality is not suitable for the fields in question. rather than relying upon standard infotype structures alone – for example PNNNN for the primary infotype. or if the screen structure contains fields whose field names differ from the field names in the infotype structure. which by default contains the same fields that are contained in structure Pnnnn. Page 57 of 75 . 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. default conversion class CL_HRPA_UI_CONVERT_BASIC provides the following generic functionality. For this reason. then the default conversion class cannot be applied. The same assumption underlies the foregoing generation of the corresponding screen structure. as described in the topic Automatically Retrieving Descriptive Texts. generic functionality known as the text identifier is applied to evaluate the Data Dictionary and derive the appropriate texts. and input help values are automatically retrieved. Always apply the exception concept of the text identifier. in each interface method. then the default conversion class cannot be applied.) Aside from this single difference. PNNNN2 for the secondary infotype (that is. In the majority of cases. descriptive texts for fields that hold key values are automatically retrieved. namely standard conversion classes and advanced conversion classes. Whenever a screen structure appears in the user interface. then customers should observe the naming convention /custcust/ZCL_UI_CONV_nnnn_yy while creating their conversion classes. the system automatically applies the default conversion class CL_HRPA_UI_CONVERT_BASIC. a dedicated conversion class must be created. When the Create Infotype transaction (transaction code PM01) is executed for a new Personnel Administration infotype. and yy denotes the Version ID – for example. US for the United States. while advanced conversion classes implement interface IF_HRPA_UI_CONVERT_ADVANCED. and so on) is automatically provided for those fields that bear identical field names in both the screen structure and the infotype structure. rather than creating a specific conversion class to derive the text on your own. A dedicated conversion class must be created instead. then the default conversion class cannot be applied. the corresponding conversion class is called. (To this end. infotype view). read-only. 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. if the functionality of the default conversion class is insufficient. then the system will automatically generate a dedicated conversion class in response. conversion classes are of fundamental importance in ensuring that data from back-end infotype structures is converted for proper display in screen structures. equally apply to both types of conversion classes. DATA p0001_tab TYPE STANDARD TABLE OF p0001.. a_paitf_read_molga = paitf_read_molga.the specific user interface requirements. if the dedicated conversion class will need to access the infotype container. ASSIGN screen_structure TO <zhcmt_bsp_pa_xx_r9001>. then we recommend that you implement it as demonstrated in the example below.3.5. implementing interface IF_HRPA_UI_CONVERT_STANDARD. PUBLIC © 2014 SAP SE or an SAP affiliate company. ● 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. RAISE EXCEPTION TYPE cx_hrpa_violated_assertion. This source code requires that the following attributes – that is. then you must manually replace this default (standard) interface with the interface for an advanced conversion class – that is. * assign and type structures ASSIGN pnnnn TO <p9001>. in turn. CLEAR field_attributes. METHOD IF_HRPA_UI_CONVERT_STANDARD~INITIALIZE. PAITF_READ_MOLGA Reference PAITF_READ_MOLGArefers to class CL_HRPA_MOLGA. FIELD-SYMBOLS <p9001> TYPE p9001. If this method is required. 1. a_paitf_read = paitf_read. . All rights reserved. However. No other means are permitted for reading infotype data. Method READ of this class can be called to read any additional infotype ● data that will be necessary. in method OUTPUT_CONVERSION – you can access these classes in the following manner. In any subsequent implementation of methods OUTPUT_CONVERSION and INPUT_CONVERSION. Method READ_MOLGA_BY_PERNR of this class can be called to obtain the country grouping of a specified personnel number. METHOD IF_HRPA_UI_CONVERT_STANDARD~OUTPUT_CONVERSION. Example The following source code excerpt demonstrates a sample implementation of the INITIALIZE method. DATA p0001 TYPE p0001. Instance attributes – be defined. ENDMETHOD. ENDIF. might be used to read additional infotype data during output and input conversion. IF_HRPA_UI_CONVERT_ADVANCED. 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'. DATA molga TYPE molga. the reader classes are simply called via the attributes. the following references are passed: ● PAITF_READ Reference PAITF_READ refers to a class with interface IF_HRPA_PAITF_READ. 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.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). Private. Page 58 of 75 . FIELD-SYMBOLS <zhcmt_bsp_pa_xx_r9001> TYPE zhcmt_bsp_pa_xx_r9001. The sample source code below stores the reader class references within attributes of the conversion class. The conversion class thus generated is a standard conversion class. When this method is applied.. In principle. PUBLIC © 2014 SAP SE or an SAP affiliate company. then it may be appropriate to code on these parameters. and ● C signifying mandatory.. IS_OK = false. . appropriate processing must be defined in the implementation of method INPUT_CONVERSION. where the screen structure contains fields whose field names differ from the field names in the infotype structure.. parameter MESSAGE_HANDLER). Under no circumstances should this parameter be used in customer source code. . as shown in the first example at the end of this topic. if a particular field should not be editable. Importing parameter MODE currently is not used in the standard system. In the nested table FIELD_ATTRIBUTE. To this end. ● B signifying hidden. In that table. in more complex cases. provided that the corresponding Customizing has been performed. Output Conversion (Method OUTPUT_CONVERSION) Definition Implementation of this method is mandatory. all fields must be stored by their technical names defined in the screen structure and with a corresponding property. however. This method is the counterpart of method INPUT_CONVERSION. Field OBJECT_KEY should be set to the same value as the object key in parameter SCREEN_STRUCTURE.). intended for future use. Use The name of the screen structure for which the conversion class is called is passed in parameter SCREEN_STRUCTURE_NAME. then the field property must be set accordingly in exporting table FIELD_ATTRIBUTES. Parameter PNNNN2 provides the current record of the secondary infotype (that is. no source code is required. when called for. 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. the current infotype record is passed in parameter PNNNN. Any field that is not expressly listed in the nested FIELD_ATTRIBUTE will be assigned the properties of standard editable fields. All messages stored in this manner will subsequently be presented. as well as a nested table named FIELD_ATTRIBUTE. In the event that the infotype has specific user interface requirements when run in a certain action. Page 59 of 75 . ENDMETHOD. Importing parameters MASSN and MASSG respectively specify the action and reasons in which the infotype is currently running. it is. IS_OK = true. while parameter PREFprovides the cost assignment of the current infotype record. 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. type W(for warnings). then parameter IS_OK must be set to the value “ ” (that is. 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. introduced in the subsequent topic.. Moreover. 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. The following three properties are supported: ● A signifying read-only. exactly one entry must be created for the corresponding field.. 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. infotype view). is sufficient to perform output conversion. * read molga molga = a_paitf_read_molga->read_molga_by_pernr( tclas = 'A' pernr = <p9001>-pernr ). The entry to be created in turn consists of the appropriate value in field OBJECT_KEY. Three types of messages can be issued – type I (for information). As illustrated in the second example at the end of this topic. from the perspective of conversion classes in the de-coupled framework. For all editable fields. a corresponding message can be issued via the Message Handler (that is.). All rights reserved. or type E (for errors).* 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. If error messages (of type E) are to be called. or if that field should receive any other attribute. With this sole exception (as described in the topic Automatically Retrieving Descriptive Texts). 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. on the user interface. CLEAR field_attributes. Page 60 of 75 . ENDIF. * 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. 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. is_ok = if_hrpa_ui_convert_standard~true. ‘Ms. the field metadata passed in parameter FIELD_METADATA can be taken into account.’. RAISE EXCEPTION TYPE cx_hrpa_violated_assertion. Specification of the appropriate field attributes in the conversion class is a prerequisite for any working user interface. ENDMETHOD. 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. FIELD-SYMBOLS <zhcmt_bsp_pa_xx_r9001> TYPE zhcmt_bsp_pa_xx_r9001. All rights reserved. the de-coupled framework can nonetheless set the value of field OBJECT_KEY before calling method OUTPUT_CONVERSION.” It is therefore imperative to note that in the de-coupled framework.When setting the field attributes.’. This metadata is read from tables T588MFPROPS and T588MFPROPC (the SAP and customer tables. METHOD IF_HRPA_UI_CONVERT_STANDARD~OUTPUT_CONVERSION. … representing ‘Mr. as demonstrated in the first example below. METHOD IF_HRPA_UI_CONVERT_STANDARD~OUTPUT_CONVERSION. * move values of fields with identical names MOVE-CORRESPONDING pnnnn TO screen_structure. DATA field_attribute TYPE hrpad_field_attribute. PUBLIC © 2014 SAP SE or an SAP affiliate company. while the second example demonstrates a more complex case. FIELD-SYMBOLS <field_attribute_wa> TYPE hrpad_obj_field_attribute. * 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. since parameter SCREEN_STRUCTURE is passed as “call-by-reference. Ms. respectively) and relates to the infotype fields of structure Pnnnn. 2. implement method CONVERT_AND_MERGE_FIELD_ATTRBS of service class CL_HRPA_FIELD_ATTRIBS_SERVICES. Although SCREEN_STRUCTURE is an exporting parameter. Nonetheless. * ensure that method is called for the correct screen structure IF screen_structure_name <> 'ZHCMT_BSP_PA_XX_R9001'. If you would like the fields of the screen structure to inherit the same attributes.…) FIELD-SYMBOLS <p9001> TYPE p9001. 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.…) * 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. as defined in the (backend) business logic. Special attention must be paid to field OBJECT_KEY of parameter SCREEN_STRUCTURE. * set field FULL_NAME to mandatory CLEAR field_attribute. field_attribute-field_name = 'VORNA'. field_attribute-field_property = if_hrpa_ui_convert_standard~read_only.<p9001>-gbdat+0(4). GBDAT. field_attribute-field_property = if_hrpa_ui_convert_standard~obligatory. ENDIF. CLEAR field_attributes. ANRED (and header fields) MOVE-CORRESPONDING <p9001> TO <zhcmt_bsp_pa_xx_r9001>. * set field NACHN to readonly CLEAR field_attribute. APPEND field_attribute TO <field_attribute_wa>-field_attribute. VORNA. APPEND field_attribute TO <field_attribute_wa>-field_attribute. field_attribute-field_name = 'NACHN'. SUBTRACT 1 FROM <zhcmt_bsp_pa_xx_r9001>-age. field_attribute-field_name = 'FORM_OF_ADDRESS_TEXT'. PUBLIC © 2014 SAP SE or an SAP affiliate company. All rights reserved. * ensure that method is called for the correct screen structure IF screen_structure_name <> 'ZHCMT_BSP_PA_XX_R9001'. * set field VORNA to readonly CLEAR field_attribute. * set field AGE to readonly CLEAR field_attribute.is_ok = if_hrpa_ui_convert_standard~true. * move values of fields NACHN. * assign and type structures ASSIGN pnnnn TO <p9001>. * 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'. field_attribute-field_name = 'AGE'. field_attribute-field_property = if_hrpa_ui_convert_standard~read_only. * 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. ASSIGN screen_structure TO <zhcmt_bsp_pa_xx_r9001>. APPEND field_attribute TO <field_attribute_wa>-field_attribute. field_attribute-field_property = if_hrpa_ui_convert_standard~read_only. field_attribute-field_name = 'FULL_NAME'. field_attribute-field_property = if_hrpa_ui_convert_standard~read_only. Page 61 of 75 . IF <p9001>-gbdat+4(4) > sy-datum+4(4). * calculate field AGE based on the date of birth in GBDAT <zhcmt_bsp_pa_xx_r9001>-age = sy-datum+0(4) . ENDIF. RAISE EXCEPTION TYPE cx_hrpa_violated_assertion. 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. * set field FORM_OF_ADDRESS_TEXT to readonly CLEAR field_attribute. READ TABLE field_attributes ASSIGNING <field_attribute_wa> INDEX 1. APPEND field_attribute TO <field_attribute_wa>-field_attribute. * no action required for field FORM_OF_ADDRESS_TEXT. APPEND field_attribute TO <field_attribute_wa>-field_attribute. ENDIF. based on the values of the screen structure. * 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. RAISE EXCEPTION TYPE cx_hrpa_violated_assertion. * move values of fields with identical names MOVE-CORRESPONDING screen_structure TO pnnnn. METHOD IF_HRPA_UI_CONVERT_STANDARD~INPUT_CONVERSION. review the previous topic. The values that are imported into it are those that were passed as importing when method OUTPUT_CONVERSION was last called. … representing ‘Mr. Infotype structure Pnnnn is a changing parameter.’. METHOD IF_HRPA_UI_CONVERT_STANDARD~INPUT_CONVERSION.ENDMETHOD. method INPUT_CONVERSION is implemented to fill the infotype structure. For an explanation of the parameters contained in method INPUT_CONVERSION. Input Conversion (Method INPUT_CONVERSION) Definition Implementation of this method is mandatory. All rights reserved. * ensure that method is called for the correct screen structure IF screen_structure_name <> 'ZHCMT_BSP_PA_XX_R9001'. is_ok = if_hrpa_ui_convert_standard~true. Ms. Example The first example provided below illustrates the simplest case where this method could be implemented.…) FIELD-SYMBOLS <p9001> TYPE p9001.…) * 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. ENDMETHOD. Moreover. Use Whereas method OUTPUT_CONVERSION is implemented to fill the screen structure. the second example in this topic provides a counterpart to the second example that was demonstrated in the previous topic. is_ok = if_hrpa_ui_convert_standard~true. 2.’. ‘Ms. This method is the counterpart of method OUTPUT_CONVERSION. PUBLIC © 2014 SAP SE or an SAP affiliate company. ENDIF. Page 62 of 75 . based on the values of the infotype structure. * 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. introduced in the previous topic. while the second example demonstrates a more complex case. FIELD-SYMBOLS <zhcmt_bsp_pa_xx_r9001> TYPE zhcmt_bsp_pa_xx_r9001. this line is required to permit the user to initialize the field within the user interface. * copy values of fields GBDAT. as recommended above. comparable functionality is employed to provide both input help options. Nonetheless. ideally. HELP_VALUES solely contains the field name. If the current value is not included. is passed in parameter FIELD_CATALOGS. ● The nested table F4HELP_COLUMNS. then all of the following information is provided: ● DATA. all other information remains absent. which ultimately rely on the same data structures. at random. ultimately determine which of these user interface representations will truly be supported. provided that column headers are available. which states the name of the column that holds the descriptive texts. ● Customary input help also requires a data table. the corresponding table may contain more than two columns. ASSIGN screen_structure TO <zhcmt_bsp_pa_xx_r9001>. one must provide a data table. unlike drop-down list boxes. with one (or more) additional column(s) being used to store information that is linked to those key values – including. summarized below. which is usually invisible on the user interface. Thus. as one cannot foresee how the input help will be presented on the user interface. at least one column to store descriptive texts for the key values. ● Drop-down list boxes require a data table that contains two columns. which contains the names of all columns within the data table. or issue an error message to report the presence of an invalid field value. the technology of the user interface in question would ultimately determine the unexpected system response that would result. All rights reserved. the list of possible field values within the data table must always include the present value of the field. which reflects the table with the input help data. ● VALUECOLUMNNAME. By extension. the system might either modify the field value. specify the names of the columns that contain key values and descriptive texts in that table. the technology of the user interface in question. to become interchangeable on the user interface. However. Therefore. To this end. To distinguish the columns (and their respective entries) from one another. along with the current field value. Naturally. along with the application itself. then create a new entry in FIELD_CATALOGS to apprise the data table of the technical names and headers for all columns. the current field value – that is. On the user interface. assuming that two of the columns in the input help are designated to contain the key value and descriptive text. one column contains all possible key values for that field. As a rule. For those fields where the generic functionality is neither suitable nor possible. In the first column. Because the de-coupled framework offers generic functionality to provide input help values by evaluating Data Dictionary information. along with corresponding header titles. FORM_OF_ADDRESS_TEXT * extract NACHN and VORNA from field FULL_NAME.* assign and type structures ASSIGN pnnnn TO <p9001>. Where method FILL_HELP_VALUES is implemented. NACHN. Method FILL_HELP_VALUESshould always be implemented in a manner that supports both user interface representations. all possible key values are stored. one must remember always to insert exactly one initial line in the data table. column headers are required. ENDMETHOD. Furthermore. the value of the field as stored in parameter SCREEN_STRUCTURE – also must be specified in the data table. If the required values can be retrieved by the generic functionality. contains the corresponding descriptive text for each key value located in the first column. to an arbitrary value. always be certain to include an initial line in the data table. which indicates the name of the column within that table that holds the key values. the system passes all field names for which input help has been requested through table HELP_VALUES. In technical terms. An overview of drop-down list box functionality is summarized below. For this reason. Additional information. SPLIT <zhcmt_bsp_pa_xx_r9001>-full_name AT space INTO <p9001>-vorna <p9001>-nachn. The second column. VORNA. ANRED <p9001>-gbdat = <zhcmt_bsp_pa_xx_r9001>-gbdat. The link between entries in HELP_VALUES and FIELD_CATALOGS is established by the corresponding field names. As soon as the user selects the appropriate field entry (from the second column) the corresponding key value (from the first column) is stored. input help can be represented as a drop-down list box. HELP_VALUES-FIELDNAME equals FIELD_CATALOGS-F4FIELDNAME. Use The FILL_HELP_VALUESmethod enables input help and drop-down list boxes. * no action required for readonly fields AGE. For this reason. input help is customarily displayed as a list that consists of two or more columns. all of the missing information must be provided within the implementation of method FILL_HELP_VALUES. By extension. 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. whose entries remain visible in the list box. Moreover. and for drop-down list boxes. and provided that no problems arise when information from the remaining columns is omitted from the user interface. PUBLIC © 2014 SAP SE or an SAP affiliate company. to wit. undesirable effects might result on the user interface. Page 63 of 75 . along with a contrasting overview of input help functionality. one should always provide all of the requisite information. input help not only displays the key values and their descriptive texts. ● KEYCOLUMNAME. but all other related columns as well. <p9001>-anred = <zhcmt_bsp_pa_xx_r9001>-anred. Conversely. respectively. a drop-down list box can be represented as input help. method FILL_HELP_VALUESonly requires implementation in fields where the generic functionality is either unsuitable or impossible to apply. Finally. DATA field_catalog_wa TYPE hrpad_help_value_field_cat. * assign and type screen structure ASSIGN screen_structure TO <zhcmt_bsp_pa_xx_r9001>. anred_help_value-anred = 2. FIELD-SYMBOLS <anred_help_values> TYPE t_hrpad00anrex_tab. APPEND anred_help_value TO <anred_help_values>. <help_value_wa>-valuecolumnname = 'ANREX'. anred_help_value-anred = <zhcmt_bsp_pa_xx_r9001>-anred. ENDIF.'. METHOD IF_HRPA_UI_CONVERT_STANDARD~FILL_HELP_VALUES. WHEN 'ANRED'. Also." CLEAR anred_help_value. TYPES: t_hrpad00anrex_tab TYPE STANDARD TABLE OF hrpad00anrex. FIELD-SYMBOLS <zhcmt_bsp_pa_xx_r9001> TYPE zhcmt_bsp_pa_xx_r9001. CLEAR anred_help_value. anred_help_value-anrex = '???'. * create help value for "Ms. where repeat fields are present. respectively. or even to specify a completely different data table. it is worthwhile to note that programmers may modify values that are passed by the generic functionality. RAISE EXCEPTION TYPE cx_hrpa_violated_assertion. * append the current value (if not yet in the list) IF NOT <zhcmt_bsp_pa_xx_r9001>-anred IS INITIAL. * create help value for "Mr. remember that the current infotype structure and the current screen structure are passed in parameters PNNNN and SCREEN_STRUCTURE.Moreover. "use text-symbol instead APPEND anred_help_value TO <anred_help_values>. READ TABLE <anred_help_values> TRANSPORTING NO FIELDS WITH KEY anred = <zhcmt_bsp_pa_xx_r9001>-anred. DATA f4help_column TYPE hrpad_f4help_table_column. PUBLIC © 2014 SAP SE or an SAP affiliate company. anred_help_value-anrex = 'Ms. Page 64 of 75 . ENDIF. method FILL_HELP_VALUES is called separately for each screen structure record. * ensure that method is called for the correct screen structure IF screen_structure_name <> 'ZHCMT_BSP_PA_XX_R9001'. ENDIF. IF sy-subrc <> 0. * specify column names <help_value_wa>-keycolumnname = 'ANRED'. * create table containing F4-help data CREATE DATA <help_value_wa>-data TYPE STANDARD TABLE OF hrpad00anrex.'. anred_help_value-anrex = 'Mr. DATA f4help_columns TYPE hrpad_f4help_table_column_tab. Remember that all information passed is merely a proposal for the input help. Nonetheless. the accuracy and consistency of all input help provided must be guaranteed. You are at liberty to modify the entries in the data table. CASE <help_value_wa>-fieldname. with different columns. All rights reserved. LOOP AT help_values ASSIGNING <help_value_wa>. different input help can be provided for each such record." CLEAR anred_help_value. FIELD-SYMBOLS: <help_value_wa> TYPE hrpad_help_value_data. "use text-symbol instead APPEND anred_help_value TO <anred_help_values>. anred_help_value-anred = 1. because input help can vary in accordance with the current field values. Example The following source code excerpt demonstrates a sample implementation of the FILL_HELP_VALUES method. ASSIGN <help_value_wa>-data->* TO <anred_help_values>. DATA anred_help_value TYPE hrpad00anrex. Therefore. Consequently. ENDMETHOD. 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. "use text-symbol instead APPEND f4help_column TO f4help_columns. f4help_column-fieldname = 'ANRED'. for each record in parameter SCREEN_STRUCTURES. f4help_column-fieldname = 'ANREX'. like method OUTPUT_CONVERSION. * create info about column ANRED containing the key value CLEAR f4help_column. The first example provided at the end of this topic illustrates sample source code that complements and enhances the generic functionality. a synonymous identifier must be defined for each record in field OBJECT_KEY. introduced in the subsequent topic. The second example provided at the end of this topic illustrates sample source code that would fulfill this requirement. Finally. Special attention must be paid to field OBJECT_KEY of parameter SCREEN_STRUCTURES. followed by method OUTPUT_TABLE_CONVERSION. f4help_column-headertitle = 'Key'. this identifier serves to establish the link between parameters SCREEN_STRUCTURESand FIELD_ATTRIBUTES. If the infotype to be processed contains repeat fields. Moreover. which converts one infotype structure into exactly one screen structure. the attributes of parameter SCREEN_STRUCTURES define it to have type Table . if the generic functionality is neither suitable nor possible for the infotype in question. For an overview of the generic functionality for processing repeat fields. Use The use of method OUTPUT_TABLE_CONVERSION closely corresponds to the use of method OUTPUT_CONVERSION. the parameters within these methods are essentially the same. the parameter is defined to have the CHANGING attribute. review the topic Repeat Field Screen Structures (Type LINE).* append the initial value APPEND INITIAL LINE TO <anred_help_values>. field_catalog_wa-f4help_columns = f4help_columns. In the event that the generic functionality is applied. OUTPUT_TABLE_CONVERSION. However. Alternatively. For this reason. Repeat Fields: Output Conversion (Method OUTPUT_TABLE_CONVERSION) Definition This method is the counterpart of method INPUT_TABLE_CONVERSION. then method OUTPUT_CONVERSION is first called to process the non-repeat fields. refer to the topic Output Conversion (Method OUTPUT_CONVERSION) for a summary of its parameters. field_catalog_wa-f4fieldname = <help_value_wa>-fieldname. If the generic functionality is applied. method OUTPUT_TABLE_CONVERSION creates several screen structure records – one for each repeat field value. which essentially correspond to the parameters within the present method. the field attributes for each of these records must be set separately. Moreover. because method OUTPUT_TABLE_CONVERSION returns multiple records in parameter SCREEN_STRUCTURES(rather than a single screen structure record). a corresponding record must be returned in parameter FIELD_ATTRIBUTES. and if no corresponding Customizing is defined. All rights reserved. which is called to process the repeat fields. 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. In contrast. parameter SCREEN_STUCTURES will already contain the records that this functionality correspondingly created. if the generic functionality is sufficient. method OUTPUT_TABLE_CONVERSION also can be implemented to provide field attributes – for example. then the system PUBLIC © 2014 SAP SE or an SAP affiliate company. Page 65 of 75 . Therefore. ENDLOOP. readonly or mandatory – for repeat fields. and is passed without a value. * create info about column ANREX containing the descriptive text CLEAR f4help_column. f4help_column-headertitle = 'Form of address'. Because the respective uses of these methods closely correspond to one another. which enables it to support the generic functionality for processing repeat fields. Unlike method OUTPUT_CONVERSION. "use text-symbol instead APPEND f4help_column TO f4help_columns. ENDCASE. * create field catalog entry CLEAR field_catalog_wa. For this reason. then parameter SCREEN_STRUCTURES remains empty. Therefore. then the implementation of method OUTPUT_TABLE_CONVERSION can be omitted. an implementation of method OUTPUT_TABLE_CONVERSION must subsequently create the necessary entries. APPEND field_catalog_wa TO field_catalogs. because it is not a repeat field. Indicator for Indirect Valuation (INDBW) and Operation Indicator for Wage Types (OPKEN). whether or not the generic functionality is applied. 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. PUBLIC © 2014 SAP SE or an SAP affiliate company. FIELD-SYMBOLS <hcmt_bsp_pa_xx_r0008_lin_a> TYPE hcmt_bsp_pa_xx_r0008_lin_a.will accordingly pass records in parameter SCREEN_STRUCTURES. the generic functionality for processing repeat fields has already created records to be passed in parameter SCREEN_STRUCTURES. has not yet been filled. However. FIELD-SYMBOLS <p0008> TYPE p0008. The following source code excerpt therefore demonstrates how this non-repeat field can be filled for each record in parameter SCREEN_STRUCTURES. field_attribute-field_property = if_hrpa_ui_convert_standard~obligatory. * set field LGART to mandatory CLEAR field_attribute. ENDIF. In this example. All rights reserved. Amount (BETRG). Page 66 of 75 . 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. DATA field_attribute TYPE hrpad_field_attribute. * process all records automatically created by T588AUTO_MAP and T588AUTO_TABLE customizing LOOP AT screen_structures ASSIGNING <hcmt_bsp_pa_xx_r0008_lin_a>. In this example. CLEAR field_attributes. field_attribute_wa-object_key = <hcmt_bsp_pa_xx_r0008_lin_a>-object_key. ENDIF. APPEND field_attribute TO field_attribute_wa-field_attribute. APPEND field_attribute_wa TO field_attributes. The Currency Key field (WAERS). DATA field_attribute_wa TYPE hrpad_obj_field_attribute. 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. 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. <hcmt_bsp_pa_xx_r0008_lin_a>-waers = <p0008>-waers. ENDLOOP. * assign and type structure ASSIGN pnnnn TO <p0008>. field_attribute-field_name = 'WAERS'. This excerpt also illustrates how the field attributes can be set. * set the currency of the wage type amount IF <hcmt_bsp_pa_xx_r0008_lin_a>-betrg IS NOT INITIAL. entries have already been filled in the fields Wage Type (LGART). field_attribute-field_property = if_hrpa_ui_convert_standard~read_only. * set field WAERS to readonly CLEAR field_attribute. field_attribute-field_name = 'LGART'. ■ METHOD IF_HRPA_UI_CONVERT_STANDARD~OUTPUT_TABLE_CONVERSION. is_ok = if_hrpa_ui_convert_standard~true. In either case. APPEND field_attribute TO field_attribute_wa-field_attribute. * for each record we have to create field attributes CLEAR field_attribute_wa. and when no corresponding Customizing has been defined. * 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. Consequently. table T588AUTO_MAP has been customized in the same manner described in the example within the topic Repeat Field Screen Structures (Type LINE). however. Number (ANZHL). and field OBJECT_KEY already will be correctly defined for each record. CHECK <hcmt_bsp_pa_xx_r0008_lin_a> IS NOT INITIAL. Example The first example below illustrates sample source code that complements and enhances the generic functionality. field_attribute-field_property = if_hrpa_ui_convert_standard~read_only. as illustrated in the ■ source code excerpt shown below. DATA field_attribute TYPE hrpad_field_attribute. * reset currency and object key CLEAR hcmt_bsp_pa_xx_r0008_lin_a-waers. * set field LGART to mandatory CLEAR field_attribute. CLEAR screen_structures. * make sure that this is not an empty record CHECK hcmt_bsp_pa_xx_r0008_lin_a IS NOT INITIAL. field_attribute-field_name = 'WAERS'. DATA p0008 TYPE p0008. CLEAR field_attributes. 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. * set field WAERS to readonly CLEAR field_attribute. p0008 = pnnnn. field_attribute_wa-object_key = hcmt_bsp_pa_xx_r0008_lin_a-object_key. is_ok = if_hrpa_ui_convert_standard~true. Assume in the following example that no Customizing has been performed for the repeat fields … unlike the previous example. ENDIF. DATA object_key_index TYPE i. APPEND field_attribute_wa TO field_attributes. PUBLIC © 2014 SAP SE or an SAP affiliate company. CLEAR hcmt_bsp_pa_xx_r0008_lin_a-object_key. DATA field_attribute_wa TYPE hrpad_obj_field_attribute. RAISE EXCEPTION TYPE cx_hrpa_violated_assertion. Page 67 of 75 . hcmt_bsp_pa_xx_r0008_lin_a-waers = p0008-waers. APPEND field_attribute TO field_attribute_wa-field_attribute. In this case. field_attribute-field_name = 'LGART'. APPEND hcmt_bsp_pa_xx_r0008_lin_a TO screen_structures. * set object key ADD 1 TO object_key_index. METHOD IF_HRPA_UI_CONVERT_STANDARD~OUTPUT_TABLE_CONVERSION.ENDMETHOD. * create field attributes for each record CLEAR field_attribute_wa. field_attribute-field_property = if_hrpa_ui_convert_standard~obligatory. All rights reserved. ENDIF. * set the currency of the wage type amount IF hcmt_bsp_pa_xx_r0008_lin_a-betrg IS NOT INITIAL. APPEND field_attribute TO field_attribute_wa-field_attribute. hcmt_bsp_pa_xx_r0008_lin_a-object_key = object_key_index. * ensure that method is called for the correct screen structure IF screen_structure_name <> 'HCMT_BSP_PA_XX_R0008_LIN_A'. the implementation of method OUTPUT_TABLE_CONVERSION must create all screen structure records with unique object keys. DATA hcmt_bsp_pa_xx_r0008_lin_a TYPE hcmt_bsp_pa_xx_r0008_lin_a. * 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. Use When implementing method INPUT_TABLE_CONVERSION. Page 68 of 75 . As a result. DATA indbw TYPE indbw. All rights reserved. ENDMETHOD. DATA hcmt_bsp_pa_xx_r0008_lin_a TYPE hcmt_bsp_pa_xx_r0008_lin_a. method INPUT_TABLE_CONVERSIONis called separately for each screen structure record. while the Number of Table for Master Data parameter (TABNO) indicates the index of the record – that is. to the format of the repeat fields in structure Pnnnn. ENDIF. This example assumes that no Customizing has been performed for the repeat fields. then all repeat fields must be updated manually. DATA lgart TYPE lgart. so that the implementation must manually convert the contents of the screen structure fields. DATA betrg TYPE pad_amt7s. RAISE EXCEPTION TYPE cx_hrpa_violated_assertion. DATA opken TYPE opken. 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. However. Each record is passed in parameter SCREEN_STRUCTURE. Before calling method INPUT_TABLE_CONVERSION. the framework first calls method INPUT_CONVERSION to convert all non-repeat fields. * ensure that method is called for the correct screen structure IF screen_structure_name <> 'HCMT_BSP_PA_XX_R0008_LIN_A'. All other repeat fields must remain unchanged. DATA anzhl TYPE anzhl. If the generic functionality for this purpose is applied. CHECK sy-index = tabno. is_ok = if_hrpa_ui_convert_standard~true. p0008 = pnnnn. hcmt_bsp_pa_xx_r0008_lin_a = screen_structure. parameter PNNNN already contains the updated non-repeat fields. for storage. Thus. * set repeat fields to values of screen structure lgart = hcmt_bsp_pa_xx_r0008_lin_a-lgart. DATA p0008 TYPE p0008. introduced in the previous topic. If the generic functionality is not applied. the position of the record in table SCREEN_STRUCTURES at the time that it was provided in method OUTPUT_TABLE_CONVERSION. when method INPUT_TABLE_CONVERSION is called the first time. one is only allowed to modify the repeat fields in structure Pnnnn that correspond to the index passed in parameter TABNO. within the implementation of INPUT_TABLE_CONVERSION. one must update the repeat field(s) with the number(s) correspondingly indicated in parameter TABNO of structure Pnnnn. Repeat Fields: Input Conversion (Method INPUT_TABLE_CONVERSION) Definition This method is the counterpart of method OUTPUT_TABLE_CONVERSION. whereas method OUTPUT_TABLE_CONVERSION is called only once to provide all screen structure records for the repeat fields in question. Example The following source code excerpt demonstrates a sample implementation of method INPUT_TABLE_CONVERSION. PUBLIC © 2014 SAP SE or an SAP affiliate company.ENDDO. then all repeat fields are updated automatically. one substantive difference exists between this method and its counterpart. front-end) perspective. back-end) perspective. but rather in a language-dependent text table. To satisfy the fundamental requirement of displaying texts. generic functionality is delivered with the de-coupled framework to retrieve descriptive texts automatically. 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. one can specify either the name of the screen structure – in other words. the first field of view V_T588AUTO_TEXT contains the name of the screen structure. To illustrate. In the third field of this view. The present topic introduces this functionality. the Assignment of Text Fields for Generic Text Reader (for Customers) view (V_T588AUTO_TEXTC) determines this process. is converted into screen structure format for representation on the user interface. rather than values. In other words. taken together. As in view V_T588AUTO_TEXTC. From a user interface (that is. ENDMETHOD. the name of the screen structure must be specified. The following chart summarizes the three fields that.betrg = hcmt_bsp_pa_xx_r0008_lin_a-betrg. the descriptive texts are of no importance. the field that contains the key value PUBLIC © 2014 SAP SE or an SAP affiliate company. users expect to view the corresponding descriptive texts. and the key value of 2 to represent female employees. 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. comprise the structure of the Assignment of Text Fields for Generic Text Reader (for Customers) view (V_T588AUTO_TEXTC). Automatically Retrieving Descriptive Texts Use The information that is stored in infotypes is mainly comprised of key values. However. 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. which relies on Customizing. while the fourth field contains the name of the field in the screen structure that contains the key value. opken = hcmt_bsp_pa_xx_r0008_lin_a-opken. which is delivered by SAP. In the second and third fields of this view. the Assignment of Text Fields for Generic Text Reader view (V_T588AUTO_TEXT) determines the automatic retrieval of descriptive texts. Prerequisites Two views are delivered in the standard system to determine Customizing for the automatic retrieval of descriptive texts. For all customer-specific Customizing. along with an explanation of the fields contained therein. rather than the underlying key values. If you choose the first option and specify the name of the screen structure in Structure Holding the Key Field (VALUESTRUC). indbw = hcmt_bsp_pa_xx_r0008_lin_a-indbw. the second field contains the name of the field in the screen structure that is to receive the descriptive text. the identical entry contained in the first field – or the name of the infotype structure whose data. the de-coupled framework can fill them with the corresponding texts. Page 69 of 75 . Customers are therefore required to maintain entries in the latter view if they wish to implement this approach. All rights reserved. For all standard Customizing. while SAP maintains the entries that are delivered in the former view. No other entries are supported. then the de-coupled framework processes entries in views V_T588AUTO_TEXT and V_T588AUTO_TEXTC in an identical manner. the descriptive texts are of great importance. with the exception of an additional field. the structure of view V_T588AUTO_TEXT is almost identical to the structure of view V_T588AUTO_TEXTC. Because this fundamental requirement is shared by all infotypes. taken together. From a business logic (that is. Structure Holding the Key Field (VALUESTRUC). To facilitate the necessary Customizing. pnnnn = p0008. entries in the Gender Key field (GESCH) are stored with the key value of 1 to represent male employees. anzhl = hcmt_bsp_pa_xx_r0008_lin_a-anzhl. when the infotype is represented in the UI. the descriptive texts of Male and Female are not stored in the infotype itself. and therefore greatly reduces the effort of implementing it. ENDDO. EXIT. the structure of each view is summarized below. on the user interface. during output conversion. comprise the structure of the Assignment of Text Fields for Generic Text Reader view (V_T588AUTO_TEXT). The following chart summarizes the four fields that. Once the screen structure fields are defined. 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). As information in the Data Dictionary – for example. A thorough description of the exception concept. 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 following chart summarizes the three fields that. All rights reserved. if data element PAD_PRCNT ( Percentage ) is specified. if PAD_CURRE ( Payroll Currency ) is the data element specified in field FDTEL. the system then applies generic functionality known as the text identifier to retrieve the necessary texts. rather than the screen structure. This field is assumed to be defined. a third view delivered in the standard system features Customizing entries that influence automatic text retrieval. is delivered with the documentation for interface IF_TEXT_IDENTIFIER. and so on. 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. However. comprise the structure of the Assignment of Data Elements to Determine Fixed Texts view (V_T588FIX_TEXT). If desired. the field containing the key value customarily should be part of the screen structure.) To this end. 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. Once the appropriate view is determined. domain fixed values. For this reason. by the data element specified in FDTEL. Page 70 of 75 . A preferable – and recommended – approach is to enhance the text identifier by means of the corresponding exception concept. 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. The third view therefore cannot be modified in customer systems. 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). the exception concept provides a decisive advantage over manual specification of the descriptive text in the conversion class. In accordance with this principle. If such Customizing is present. the entries in the third view are exclusively determined by SAP. the text identifier evaluates all Data Dictionary information that is available for the field that contains the key value and is specified in VALUEFIELD. In cases where the generic text retrieval functionality is not suitable. By applying the exception concept. PUBLIC © 2014 SAP SE or an SAP affiliate company. the data element stored in FDTEL defines the fixed text that will be retrieved for the field entered in TEXTFIELD. in turn stores this text in the screen structure field specified in TEXTFIELD. (Several standard applications. Moreover. In the standard system. If you choose the second option and specify the name of the infotype structure in Structure Holding the Key Field (VALUESTRUC). then the system will retrieve and display %. then the system reverts to the standard Customizing delivered in the Assignment of Text Fields for Generic Text Reader view (V_T588AUTO_TEXT). then the text identifier extracts and returns this 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. For all other data elements specified here. The system. If no such Customizing is present. foreign key relationships. you may execute the Test Report for Text Recognition (report RS_TEST_IDENTIFY_TEXT) to test the generic functionality provided by the text identifier. while the data element PAD_KMETRES { Unit (Kilometer) }. it is theoretically possible – although not recommended – manually to specify the descriptive text in method OUTPUT_CONVERSION of the conversion class.(specified in VALUEFIELD) is understood to be part of the same screen structure. within the screen structure. regardless of the application that is using it. In addition to the two views introduced above. In other words. taken together. check tables and text tables – is evaluated. including the manner in which exceptions are created. The exception theoretically could be re-used within the text identifier itself. yet simultaneously derive texts that cannot otherwise be retrieved from the Data Dictionary. that exception can always be reused by the text identifier. then the field that contains the key value (specified in VALUEFIELD) is understood to be part of the infotype structure. the second option should only be applied in exceptional cases. As additional examples. If a text source is located. 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. To illustrate. the system will derive texts first by retrieving the name of the domain that is used for the specified data element. and if this text source contains a text for the given key value. you may elect to execute transaction code SE11 and review the domain fixed values of the data elements used in V_T588FIX_TEXT. then the system responds accordingly. The fixed text. including SAP Query and Ad-hoc Query. then by retrieving the fixed values that are defined for that domain. use the text identifier themselves to retrieve descriptive texts automatically. because once an exception has been defined for the text identifier. is retrieved via the specified data element or the corresponding fixed domain values. will lead the system to retrieve and display km. the system attempts to determine the location where the text for this field is stored. For reference. in turn. The text of the first fixed value is subsequently retrieved and displayed in the screen structure field. three of the many standard entries delivered in the Assignment of Data Elements to Determine Fixed Texts view (V_T588FIX_TEXT) are summarized below. but is nonetheless introduced below for reference. one can make use of the generic functionality for automatic text retrieval. Instead. as you and that party must jointly agree upon its operation. encode the country-specific functions accordingly. it is important to remain in contact with the party who is responsible for the international class. the Final checkbox (VSEOCLASS-CLSFINAL) may not be selected. whereby the country-specific conversion class declares the international conversion class to be its superclass. Page 71 of 75 . If the international conversion class is not final and if you elect to re-use it. and a consistent presentation of data across all applications is guaranteed. Only via this attribute should the country-specific conversion class access the international screen structure. and therefore relies upon. Only encode the required country-specific functions within the methods of the country-specific conversion class. are exchanged within the international conversion class. First. among the properties of any international conversion class to be re-used. Never encode such functions in the international conversion class! Example PUBLIC © 2014 SAP SE or an SAP affiliate company. All rights reserved. 1. proceed as follows. 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. the functionality provided by the international class. Define the international conversion class as the superclass of the country-specific conversion class. the international conversion class should use a public constant attribute (with type PAD_SNAME) to contain the name of the international screen structure. call the corresponding method of the international class (statement CALL METHOD super->…) to process the international fields of the screen structure. For this reason. manual coding efforts are greatly reduced. proceed as follows. 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). Procedure To reuse any international conversion class that fulfills the above prerequisites. In the country-specific class. and provided that the international version of the infotype fulfills the majority of country-specific requirements. b. at a later date. This end is achieved by means of inheritance. it may be effective to reuse the functionality of the international infotype’s conversion class within the countryspecific conversion class(es) of the country-specific infotype(s). as well as the text identifier and the corresponding exception concept. In other words. redefine methods OUTPUT_CONVERSION and INPUT_CONVERSION. Prerequisites An international conversion class can only be re-used if it has not been declared as final. 2. a. In the implementation of these methods. Finally. Second. you must remember that your country-specific conversion class has inherited. you should refrain from hard-coding the name of the international screen structure within the country-specific conversion class. 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. This recommendation serves to prevent subsequent problems in the event that screen structures.Result By using the automatic retrieval of descriptive texts. ASSIGN screen_structure TO <zhcmt_bsp_pa_us_r9001>. The first example demonstrates an implementation of the output conversion method. * exit in case of error IF is_ok = if_hrpa_ui_convert_standard~false. FIELD-SYMBOLS <super_screen_structure> TYPE ANY. PUBLIC © 2014 SAP SE or an SAP affiliate company. DATA super_screen_structure TYPE REF TO data. ■ METHOD IF_HRPA_UI_CONVERT_STANDARD~OUTPUT_CONVERSION.The following examples are provided to clarify the principles that undergird the output and input conversion methods. CLEAR field_attributes. * ************************************* * the country-specific part starts here * assign and type structures ASSIGN pnnnn TO <p9001>. ENDIF. * ensure that method is called for the correct screen structure IF screen_structure_name <> 'ZHCMT_BSP_PA_US_R9001'. * 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. RAISE EXCEPTION TYPE cx_hrpa_violated_assertion. . ENDIF. FIELD-SYMBOLS <p9001> TYPE p9001. However. ENDMETHOD. FIELD-SYMBOLS <zhcmt_bsp_pa_us_r9001> TYPE zhcmt_bsp_pa_us_r9001. The international conversion class has been specified as the superclass of the country-specific conversion class.. ASSIGN super_screen_structure->* TO <super_screen_structure>. while the second example demonstrates an implementation of the input conversion method. * create international screen structure CREATE DATA super_screen_structure TYPE (a_super_screen_structure_name). 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. is_ok = if_hrpa_ui_convert_standard~true. the procedure that is used to perform both methods is analogous... All rights reserved. A public constant attribute has been defined for the international conversion class. * move values from international to country-specific screen structure MOVE-CORRESPONDING <super_screen_structure> TO screen_structure. RETURN. 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'.. Page 72 of 75 . * place any country-specific coding here . Assigning Conversion Classes to Screen Structures Definition As explained previously. ENDIF. . DATA super_screen_structure TYPE REF TO data.. * move values from country specific to international screen structure MOVE-CORRESPONDING screen_structure TO <super_screen_structure>. ASSIGN super_screen_structure->* TO <super_screen_structure>. * ensure that method is called for the correct screen structure IF screen_structure_name <> 'ZHCMT_BSP_PA_US_R9001'.■ The following example demonstrates the implementation of the corresponding input conversion method. 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). data from infotype structures requires conversion into a format suitable for screen structures. RAISE EXCEPTION TYPE cx_hrpa_violated_assertion. * ************************************* * the country-specific part starts here * assign and type structures ASSIGN pnnnn TO <p9001>. The entries in this view thereby determine which conversion class will be applied to which screen structure(s). ENDIF. All rights reserved. RETURN. is_ok = if_hrpa_ui_convert_standard~true. For this reason. Therefore. * 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.. ASSIGN screen_structure TO <zhcmt_bsp_pa_us_r9001>. Each entry in this view therefore constitutes a link between a screen structure and its corresponding conversion class. This conversion is performed by means of conversion classes. pnnnn2 pref = pnnnn2 = pref * exit in case of error IF is_ok = if_hrpa_ui_convert_standard~false. FIELD-SYMBOLS <p9001> TYPE p9001. Page 73 of 75 . METHOD IF_HRPA_UI_CONVERT_STANDARD~INPUT_CONVERSION. * place any country-specific coding here . screen structures contain all of the fields that are related to and required for displaying and editing the infotype in the user interface.. * create international screen structure CREATE DATA super_screen_structure TYPE (a_super_screen_structure_name). ENDMETHOD. FIELD-SYMBOLS <zhcmt_bsp_pa_us_r9001> TYPE zhcmt_bsp_pa_us_r9001.. an entry in this view is mandatory for every screen PUBLIC © 2014 SAP SE or an SAP affiliate company. and vice versa. FIELD-SYMBOLS <super_screen_structure> TYPE ANY. All rights reserved. then type LINE must be specified. In the majority of cases. only the Name of Screen Structure field (SNAME) is a key field. comprise the structure of the Assignment UI Structures and UI Conversion Classes view (V_T588UICONVCLAS). 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). ■ ■ ■ ■ ■ 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. is called. otherwise. 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. Use To determine which conversion class belongs to a given screen structure. in this field. which enables a variety of generic functionality. However. if the screen structure in question is designed to process repeat fields. then that screen structure cannot be used. the screen structure cannot be used. 10 CL_HRPA_UI_CONVERT_0008_U S Page 74 of 75 . 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 A PUBLIC © 2014 SAP SE or an SAP affiliate company. When maintaining entries here. When maintaining entries in this view. 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. you must specify the type of screen structure at hand. you must specify the conversion class to which the screen structure is assigned. Structure The following chart summarizes the five fields that. this field will contain either CL_HRPA_UI_CONVERT_BASIC – the default conversion class. the system refers to view V_T588UICONVCLAS. In essence.structure. 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. type MAIN will be specified in this field. as described in the topic Conversion Classes – or a dedicated conversion class of your own. CL_HRPA_UI_CONVERT_BASIC. you must specify in this field the infotype version to which the screen structure is assigned. The ID for Infotype Versions field (VERSIONID) represents the version of the infotype at hand. If no special conversions are required. If no entry exists in this view for the corresponding screen structure. When maintaining entries. taken together. then the default conversion class. The Infotype field (INFTY) denotes the four-digit number assigned to the infotype at hand. However. Therefore. All rights reserved. Page 75 of 75 .PUBLIC © 2014 SAP SE or an SAP affiliate company.