Process Flow

As new infotypes are created by means of the Create Infotypetransaction (transaction code PM01), the system automatically generates entries, which are required for subsequent processing, in a multitude of views. No additional action is required for users to generate the requisite entries in any view. Nonetheless, users may wish to consider this topic for additional background information. This topic discusses the entries of the views Classes for Determining Version IDs and Infotype Containers (V_T582ITVCLAS) and Verification Class for a Version Flag (V_T582ITVCHCK), in which the check classes of infotypes are assigned to containers and infotype versions, respectively. Both views were introduced to the standard system with the revised framework for creating infotypes.

In the first view, V_T582ITVCLAS, a single entry is created for each infotype to assign the corresponding check class to a container. For the majority of infotype entries stored in view V_T582ITVCLAS, the appropriate container is CL_HRPA_INFOTYPE_CONTAINER , although certain infotypes are not assigned to this container. Without exception, the system stores one single entry in view V_T582ITVCLAS for every valid infotype within the system. In other words, if the number of valid standard and customer-specific infotypes in your system is 501, then the system will store exactly 501 entries in view V_T582ITVCLAS.

In the second view, V_T582ITVCHCK, one entry is created for each valid version of an infotype whose check class differs from the check class that is specified for the corresponding infotype in view V_T582ITVCLAS. Each entry thus created is used to assign the corresponding check class to an infotype version.

Should you need to review the entries for a particular infotype that have automatically been generated in the appropriate view(s), remember the following rules of thumb:

For any new entries that you cause to be generated in view V_T582ITVCLAS, we strongly recommend that you do not subsequently change the default value ( Permitted in All Circumstances ) within the Permissibility of Infotype for New Framework (NITF_ADM) field. By accepting this value, the corresponding infotype will be identified to comply with the revised framework that exists in this release for creating infotypes. In contrast, if customer-specific infotypes exist in your system from prior releases, and if you for example neither wish to migrate these infotypes to comply with, nor permit them to be processed by, the revised framework, then you may instead specify the value Not Permitted here.

Example

The following examples serve to illustrate the presence (or absence) of entries in each view for the corresponding infotype.

In the first view, V_T582ITVCLAS, a single entry exists for the Personal Data infotype (0002), while one entry exists for each of various versions of that infotype – altogether dozens of entries – in view V_T582ITVCHCK.

For the External Transfers infotype (0011), which (as introduced in the topic Creating Country-Specific Check Classes ) has five country versions, a single entry also exists in view V_T582ITVCLAS. In contrast, in view V_T582ITVCHCK, four entries exist for that infotype – one each for the country versions of Switzerland , Norway , New Zealand and South Africa , respectively. (No entry exists in view V_T582ITVCHCK for the Belgian version, because this version uses the same check class as the international version.)

In contrast, for the Communication infotype (0105), for which only an international version exists, view V_T582ITVCLAS contains a single entry, while view V_T582ITVCHCK contains no entry.