You can use this process to trigger an automatic migration of an infotype, which creates a decoupling of a similar scope to when a new infotype is created.
Note
The infotype-specific input and processing logic must be decoupled manually. They are decoupled in the same way as the infotype-specific input and processing logic of a customer infotype.
For more information, see Business Logic Guidelines for Creating and Migrating Infotypes .
The system creates the following objects and structures automatically:
Screen structure
The P structure fields are copied to the screen structure.
Table
T588UICONVCLAS
The system creates the following entry for customer infotypes:
SNAME |
INFTY |
STYPE |
VERSIONID |
CLSNAME |
---|---|---|---|---|
ZHCMT_BSP_PA_yy_R9nnn |
9nnn |
MAIN |
yy |
CL_HRPA_UI_CONVERT_BASIC |
The system creates the following entry for standard infotypes:
SNAME |
INFTY |
STYPE |
VERSIONID |
CLSNAME |
---|---|---|---|---|
HCMT_BSP_PA_yy_Rnnnn |
nnnn |
MAIN |
yy |
CL_HRPA_UI_CONVERT_BASIC |
Check class
CL_HRPA_INFOTYPE_nnnn
or
ZCL_HRPA_INFOTYPE_9nnn
for customer infotypes
The check class is generated in the background from the check class CL_HRPA_INFOTYPE_NNNN. If you have already made modifications in the check class, the check class can not be overwritten by another migration. The criterion for a migration that has already taken place is the entry in table T582ITVCLAS.
Entry in table T582ITVCLAS
The system creates the following entry for customer infotypes:
INFTY |
IDCLASS |
CONT_GUI |
CONT_DB |
NITF_ADM |
---|---|---|---|---|
9nnn |
ZCL_HRPA_INFOTYPE_9nnn |
’’ |
CL_HRPA_INFOTYPE_CONTAINER |
3 |
The system creates the following entry for standard infotypes:
INFTY |
IDCLASS |
CONT_GUI |
CONT_DB |
NITF_ADM |
---|---|---|---|---|
nnnn |
CL_HRPA_INFOTYPE_nnnn |
’’ |
CL_HRPA_INFOTYPE_CONTAINER |
3 |
Note
The check class must be encoded manually. The system outputs a message to this effect.
The module pool, screen, and interfaces must be processed manually.