There is an old method and a new method for creating and defining infotypes. The new method does away with the previous close link between the business logic and the user interface, that is, the visual display of the data (ABAP screens). Infotypes that are created using the new method are also known as "decoupled" infotypes.
The infotype-specific business logic for decoupled infotypes is programmed in ABAP Objects classes instead of in the module pool. A check class is created for each infotype; the check class is addressed by the infotype framework. For the interface-relevant elements of the infotype, a conversion class is created that formats the business logic data for display in the user interface.
The following objects and structure are required to create an infotype in the decoupled infotype framework:
● Screen structure
An ABAP dictionary structure containing all elements that should be displayed on the user interface of the infotype.
For more information, see Structure and Task of the Screen Structure.
● Conversion class
An ABAP Objects class that defines the conversion of the data display in the back end to the display on the user interface.
For more information, see Conversion Class.
● Assignment of screen structure to conversion class
An entry in view V_T588UICONVCLAS that controls the access of the decoupled infotype framework to the correct conversion class for the processing of a screen structure.
For more information, see Assigning Conversion Classes to Screen Structures.
● Check class CL_HRPA_INFOTYPE_nnnn for a standard infotype or ZCL_HRPA_INFOTYPE_9nnn for a customer-specific infotype.
For more information, see Check Classes.
● An entry in view V_T582ITVCLAS for the classes to determine version IDs and infotype containers
● Check class for a version indicator
An entry in view V_T582ITVCHCK that defines the assignment of the infotype version and associated check class
The basic principles of the new method are described in the following sections. For more information and detailed notes for experts, see:
Transaction PM01, Create Infotype, supports the creation and enhancement of decoupled infotypes. Infotypes created using the old method can still be used. It is not mandatory to convert infotypes to the new method, but it is advisable.
Whether or not the infotype is decoupled is irrelevant for the transaction for maintaining HR master data (PA30). Both versions are supported.
However, newer applications such as some ESS scenarios or the HR Administrative Services are based on the decoupled infotype framework, and can only process decoupled infotypes.
This means that if you want to use a customer-specific infotype within this framework, the infotype must be decoupled.
When you create a new infotype, you should therefore always create a decoupled infotype.
Decoupling infotypes has the following advantages:
● It enhances the interchangeability of the user interface to keep up with the constant influx of new developments in visual display (new controls, visual patterns, new graphic elements, changed user guidance, and so on)
● Several infotypes can be grouped in a visual display (on a screen)
● It provides high-performance processing of electronic input data without time-intensive screen processing logic (batch input)
New infotypes are decoupled right from the start if they are created using the Create Infotype transaction (PM01). To benefit from the advantages of decoupling for existing, non-decoupled, customer-specific infotypes and non-decoupled enhancements of standard infotypes, you must decouple them retroactively. For more information, see Migrating an Infotype.