As of SAP ERP Central Component (ECC) 6.0, SAP has introduced the concept of the decoupled infotype framework. “Decoupling” means removing the previously closed link between the HR infotype business logic programming and the user interface screen programming. In previous versions of SAP ERP HCM, the data conversion and validation logic were embedded in screen dialog module pools. ECC 6.0 uses new ABAP Object classes instead of module pools to accomplish the same processes for certain applications, such as Employee Self-Service (ESS) and HR Administrative Services. In addition, transaction PA30 (HR master data maintenance) has been enhanced to use both the old and new technologies. Some of the advantages of separating the business logic from the user interface are:

• The ability to interchange the user interface to keep up with new developments in visual display, including new graphic elements and portal or Internet-based screens such as ABAP or Java Web Dynpros
• The grouping of several infotypes on a single screen

Dual Environment The new decoupled infotype framework is a different way of accessing, creating, and maintaining infotype data — but it does not replace the previous infotype processing environment. Instead, it sits alongside that environment as an alternative avenue for infotype processing. However, newer applications such as most ESS scenarios and HR Administrative Services are based exclusively on the decoupled infotype framework and only process HR infotypes using this new functionality. If your system uses Concurrent Employment (to allow only one infotype 0002 for all personnel numbers of an individual, for instance), the settings for the decoupled infotype framework are very important to ensure data consistency. For more on Concurrent Employment, see Greg Newman’s HR Expert article “Manage Multiple Employment Scenarios with Concurrent Employment.” If an infotype can be processed by both ESS applications and the standard transaction PA30 SAPGUI screens, and the new decoupled infotype configuration switches are not set so both systems use the same software components, ESS applications and transaction PA30 will use different data conversion and validation logic. This can lead to error messages and locked up screens. This situation can also lead to serious database inconsistencies, because SAP has introduced a new set of Business Add-Ins (BAdIs) for customer enhancements of infotype processing specifically for the decoupled infotype framework. If you have custom infotype validations in your systems already, you must also implement those BAdIs to ensure that identical custom processes occur for both the ESS and transaction PA30 processing environments. You may want to consider moving your custom validations from the old user exit ZXPADU02 and the old BAdIs to the new BAdIs to simplify programming maintenance.

Configuration

If you are not familiar with ABAP class concepts, refer to the sidebar. A new configuration sub-tree has been provided for the configuration of the decoupled infotype framework (Figure 1). Configuration would usually be done by a functional HR expert; however, this is a business decision. After entering transaction SPRO to access the IMG, follow menu path Personnel Management>Personnel Administration>Customizing Procedures>Infotypes>Infotypes in Detached Infotype Framework to reach the sub-tree.    

Enable the Decoupled Infotype Framework

To activate the new browser and portal-based user interface for HR and enable the new decoupled infotype framework, select IMG item Use Decoupled and Not Decoupled IT Framework. The system switch PC_UI in Group CCURE (the Concurrent Employment group) should be set to X, meaning on, in table T77S0 (Figure 2).  

Infotype-Specific Permissibility

IMG item Assign Check Classes and Define Permissibility is used to set field NITF_ADM (permissibility of infotype for new framework) in table T582ITVCLAS (view V_T582ITVCLAS) to one of the following values, as shown in Figure 3: 0 = Not permitted: Infotype does not run using the decoupled framework in transaction PA30. It runs using the old module pool technology, user exit ZXPADU02, and the old BAdIs for custom validations. It only runs in the decoupled infotype framework if the infotype is accessed via ESS. 1 = Central Services: Not permitted for custom infotypes 2 = Permitted in some circumstances: Some individual versions of the infotype may run on the decoupled framework. The rest run on the old framework. This would be for infotypes that have country versions, for example. 3 = Permitted in all circumstances: This infotype and all its country versions run on the decoupled framework in transaction PA30. All validations are carried out in the validation class. If the infotype is processed using the old framework (transaction PA30), the new validation class is still used to perform the infotype-specific validations. Besides assigning permissibility for the decoupled infotype framework, table T582ITVCLAS also assigns the infotype container and the generic check class for the infotype. The specific check classes for infotype country versions are assigned in the next step.

Infotype Version-Specific Check Class Assignment

IMG item Assign Check Classes for Infotype Versions assigns the check class for specific versions of each infotype in table T582ITVCHCK (view V_T582ITVCHCK). Only those infotypes that use a different check class from the standard international version need to have an entry in this table. All other versions use the check class assigned in table T582ITVCLAS. Compare the single entry in table T582ITVCLAS for infotype 0002 in Figure 3 with the multiple country-specific versions in table T582ITVCHCK for the same infotype. The Version field, VERSIONID, is a combination of the standard MOLGA country codes and other values such as UP for the US Public Sector. Table T582ITVERS is the check table for field VERSIONID (Figure 5).   Note that if the infotype permissibility is set to 2 (permitted in certain circumstances), some versions of the infotype run the custom validations of the new BAdI for the decoupled infotype framework, while others run the custom validations in the old user exit ZXPADU02 and the old BAdIs. Thus, two separate paths of validations exist. Two separate sets of custom ABAP code need to be carefully managed and maintained to produce identical validation results, instead of maintaining the same validation in both places (the old and new). For those infotypes that both ESS and transaction PA30 access, you may wish to force the system to use the new decoupled infotype framework by setting the infotype to 3 (permitted in all circumstances). Then all custom validations are performed by the new framework and can be removed from the user exit. This has the advantage of no longer requiring you to maintain the same ABAP code in two separate locations. The settings in table T582ITVCLAS are set by SAP and users are generally discouraged from changing them. That being said, the old user exit and old BAdIs are processed whether or not the decoupled infotype framework is used. The new BAdI is more flexible and enhancable than the old exits and BAdIs and it can be separated by infotype. The decision to change the permissibility to 3 would depend on whether one would like to move all or some of the validations from the user exits/BAdIs to the new BAdI or not. At the moment, most users, due to time constraints, testing, or other issues, have made the decision to change only those infotypes used in ESS, but have plans to convert the others over time. This strategy has the advantage of providing only one place for processing validations and keeping each infotype separate — thus making testing easier.

Dialog Module Assignment for Transaction PA30

IMG item Assign Dialog Modules for HR Master Data Maintenance assigns the dialog module used by standard infotype maintenance transaction PA30 for infotypes that are set to 2 in previous IMG step Assign Check Classes and Define Permissibility. For infotype versions that are not decoupled, the dialog module is set in table T777D as before. For the decoupled versions of an infotype, the dialog module to be used by transaction PA30 should be entered in table T582ITD (Figure 6).

Defining Screen Field Characteristics

There are two IMG steps and two tables used to set screen field characteristics for the decoupled infotype framework. One table, T588MFPROPS, is for SAP and the second, table T588MFPROPC, is for users. The first of the two IMG steps, SAP: Define Field Characteristics, is used to display the SAP settings for screen fields that should not be changed. The system is designed to use the user’s settings in table T558MFPROPC in preference to those in table T588MFPROPS, which is reserved for SAP. Similar in concept to the old screen field attribute value set in table T588M, table T588MFPROPS allows specific screen field attributes to be set at the infotype version, subtype, and infotype number level. These settings control the appearance and behavior of the files on the Web-based screens. T588MFPROPS is used in lieu of the old table T588M when using the decoupled framework. T588M does not necessarily have to match table T588MFPROPS. T588M is used for transaction PA30, and table T588MFPROPS is used for ESS. The first classification setting in T588MFPROPS (Figure 7) determines if the field is Mandatory [Musseingabe] (checkmark = yes). The second setting determines if the field is Output only [Ausgabe] (checkmark = output only). If both the Mandatory and Output only settings are checked, the field is treated as mandatory when the infotype is first created and then as display only on subsequent updates to the infotype.   The third setting (unbe…) determines if the field is used or not used. This setting does not correspond to the hidden setting in T588M, but means that any value in such a field is ignored during screen processing. A checkmark here means the value will not be used. If this setting is checked the first two settings are ignored as well. The final setting (Fixed) determines if the settings for a specific field in the customer screen field characteristics table T588MFPROPC are effective or not. If this setting is checked, it means that any settings for this field in the designated customer table T588MFPROPC are ignored and the settings made in T588MFPROPS are fixed. The check mark indicates no customer override. The next step in the IMG, Customer: Define Field Characteristics, allows table T588MFPROPC (Figure 8) to be configured with user overrides that take precedence over the field characteristics set by the SAP-controlled table T588MFPROPS (if permitted). The two tables are almost identical except the user-controlled table T588MFPROPC does not have the Fixed column available. Besides overriding the characteristics settings for fields in the SAP-controlled table T588MFPROPS, you may also set the attributes for any additional fields that you may have added to an infotype via the infotype enhancment transaction PM01.  

Assign the Connection Between the Screen Structure and Conversion Class

In IMG step Assign Screen Structure and Conversion Class, you can view the assignments of conversion classes that SAP has made for the SAP-delivered infotypes. If you have created a custom infotype and wish to use it in an application such as ESS that uses the decoupled infotype framework, you must enter a conversion class for that infotype in table T588UICONVCLAS (Figure 9). The methods of the assigned conversion class control the direction of databases to and from screen conversion processes.   The first column in table T588UICONVCLAS is the name of the screen structure used for decoupled infotype framework applications such as ESS. The second column is the infotype number. The third column indicates the type of structure, which can be MAIN for editing a single infotype instance or LINE for repeating groups of infotype fields on the screen. The fourth column indicates the infotype version, and the last column indicates the conversion class. If you wish to adjust the standard SAP conversion processes, you may use the new BAdI HRPAD00INFTYUI. It has the same methods for handling output and input data conversions as the standard conversion classes and it is open to user modification. This BAdI can also be used to map conversions for any custom fields or custom infotypes.

Associating Screen Text Fields with Screen Value Field

IMG steps SAP: Configure Screen Structure Text Fields and Customer: Configure Screen Structure Text Fields work together in a manner similar to the field characteristics configuration table T588M. Table T588AUTO_TEXT is the SAP-reserved table for linking value fields and text fields on the same screen. For example, the text field ANREX (title) is linked to infotype 0002 database field ANRED (form of address) for screen display in Figure 10.   Table T588AUTO_TEXTC is the user version for assignment of screen text fields to value fields. This table is primarily used to assign text fields to value fields for custom fields that you may have added to an infotype. It is possible to override the assignments made by SAP in table T588AUTO_TEXT, but SAP states that this is not recommended. Table T588AUTO_TEXTC should be the table used to make all overrides or changes necessary for any existing assignments. SAP controls the values in table T588AUTO_TEXT and can change or remove them at any stage. Changing these values yourself can create compatibility issues and would not really be necessary, as any additional entries that may be required by the customer can be added to table T588AUTO_TEXTC. The IMG step for configuring table T588AUTO_TEXTC, Configure screen structure for Repeat Fields, is a two-level configuration screen for defining repeating lines in an infotype display. The first level indicates the screen structure used for the repeating lines and the number of repetitions. The second level is used to map the field names in the structure to the field names in the database table. For example, field LGART in screen structure HCMT_BSP_PA_AU_R0008_LIN_A for the wage type list subscreen is mapped to database field LGA01 in the database table PA0008 (basic pay). We have explained the basic IMG configuration points for setting up and using the new decoupled infotype framework. From this point, if your system has no custom user exits or BAdIs to enhance infotype screen behavior, modify infotype screen behavior, or add custom validation routines, then the system is ready to go with consistent ESS and transaction PA30 behavior. However, this is almost never the case. If your system has custom BAdIs or user exits, the new BAdIs associated with the decoupled infotype framework must be implemented with the same enhancement logic. Otherwise, infotype behavior in applications using the framework exclusively (such as ESS) may be different than in transaction PA30. This problem can lead to data inconsistencies and even error messages that can freeze update operations. The new BAdIs that must be implemented include:

• HR_PADINFTY00BL for enhancing infotype business logic
• HR_PADINFTY00DB for adjusting update operations on database tables
• HR_PADINFTY00UI for screen control (user interface) in applications such as ESS