Enhancement of Standard Infotype in ESS Personal Profile (EHP 5 and above)

[Bhaskar_Tripath]

This blog describes the steps to enhance standard infotypes for ESS Personal Profile (Details Screen). The purpose of this blog is to consolidate all steps required for enhancement of decoupled infotype and the subsequent changes in UI in ESS. This is just to make life easier for beginners and doesn't include too much of advance concept. It covers the following areas:

1. Enhancing standard infotype 0006 for country US
2. Screen Validation
3. UI to infotype field Conversion
4. Controlling field visibility according to subtype

What it does not include:

1. Enhancing the infotype screen in backend (Transaction PA30). Hence no screen validation and screen field conversion for PA30.

Scenario: Add custom Mobile No. and a related fields in infotype 0006. This will be used for US employees. The field is subjected to format validation and display of field requires conversion. Finally, these fields should be hidden for certain subtypes.

Lets Begin:

Step 1: Enhance infotype 0006 structure

We need to add field in CI include CI_P0006. So as you can see, I have added 2 fields: i) Mobile No. ii) Do not disturb (For not receiving text messages).

Step 2: Enhance UI screen structure for infotype 0006

Since we only want to use these fields for country US, we should only be enhancing only the US specific structure. It is assumed that already a US screen exists (as we are only enhancing) and you can check the same by opening Component Configuration:

You can also create your own country specific screen from scratch and add the configuration here. Note that configuration key here allows us to configure screen based on MOLGA and Subtype for an infotype.

Screen structure of IT0006 for US is HCMT_BSP_PA_US_R0006 which you can check in transaction GENIL_MODEL_EDITOR (or in view V_T588UICONVCLAS). So we add the fields in the customer include inside this structure (note that I have 4 screen fields for the above mentioned 2 database fields and hence require conversion):

Step 3: Enhance the UI screen

As we saw in step 2, there is already an FPM UIBB configuration HRESS_CC_PER_DTL_ADDRESS_US for US. So now we need to add our fields in the same. There are 2 ways to do that: i) Create Enhancement ii) Create Customization. I am going with the later one for no special reason. So we open the component configuration HRESS_CC_PER_DTL_ADDRESS_US and select 'Create Customizing' from additional function.

As we added our fields in the UI structure, the custom field would automatically appear (courtesy feeder class CL_HRESS_PER_DETAIL) in the field list. So now we can add them to the screen. You can also make the necessary field attribute change here, e.g. show/hide label, display type and so on.

That's all we have to do to enhance infotype with custom fields if there are no requirement of validations and conversions. Please note, in case of automatic conversion, you must keep the screen field name same as DB field. However, we want to go further by having UI screen conversion.

Step 4: UI Conversion

For this, you must implement BADI HRPAD00INFTYUI (with filter value for infotype we are implementing for). For our requirement we need to implement only 2 methods: INPUT_CONVERSION (convert screen structure to DB structure) and OUTPUT_CONVERSION (convert DB structure to screen structure). Take caution in using MOVE-CORRESPONDING here since this BADI is called after SAP standard UI conversion. So this statement may disturb the already converted structure. It is advised to touch only the required fields.

Since my logic of conversion is similar to what SAP standard is for telephone number, I reused the standard class-method for INPUT_CONVERSION.

For OUTPUT_CONVERSION, I am implementing only a little piece of standard code.

Step 5: Business Logic check (validation)

Now we want to put some validations around our custom fields e.g. mobile number should be only 10 digit in total. To do this we need to implement BADI HRPAD00INFTYBL. In our scenario, validations are only required for insert and modify operation. So we add the code inside INSERT_COMPUTATIONS and MODIFY_COMPUTATIONS. To throw an error, we can add message to import parameter for message handler.

Remember that checks implemented using this BADI would not be performed in transaction PA30 subjected to condition. And the condition is: if the infotype is not fully decoupled. You can find this information by reading views V_T582ITVCLAS in parallel with V_T582ITD. However, this is good for only standard infotypes since all new custom infotypes that we create through PM01 are automatically built on decoupled framework.

Step 6: Hide custom fields for particular subtype

Now this requirement can be achieved in two ways:

1. Create a different component configuration - As noted in step 2, with the use of configuration key, we can configuration different screen based on MOLGA and subtype. However, I wouldn't use this just for hiding a couple of fields. I would rather use this option when there are some other major screen differences.
2. Enhance the feeder class and set the field property dynamically - I find this more appropriate in the current scenario.

As mentioned earlier, feeder class CL_HRESS_PER_DETAIL provides all data to our UIBBs. So we'll enhance GET_DATA method by using implicit enhancement at the end of standard code.

Points to note:

• We want to ensure that our code should trigger only for infotype 0006 for US. So first we check that and then implement our code.
• You can always get access to data (business data) using MO_ENTITY object.
• Screen field meta data is container in table CT_FIELD_USAGE. You can make changes to field properties by updating values in this table. Also ensure that if you have done changes in this table, parameter EV_FIELD_USAGE_CHANGED should be set.

If you want to hide fields at subtype level per country version, you can make use of views: V_T588MFPROPS and V_T588MFPROPC. However, above logic gives more control in terms of further conditions to base our field visibility.

Thats it. We are done with customization. Now lets test.

So we got our custom field on screen and also the validations are working. Now lets check other subtype for which we have hidden the checkbox:

Yes, the check box is hidden :grin: !

Hope its helpful for all those who are new to this area and find themselves tangled in too much information on infotype decoupled framework (as far as enhancing infotype is concerned) and ESS personal profile page.

I would also recommend reading the excellent blog Summary of configuration options in ESS Personal Information scenario by Sagar (Keep it bookmarked :wink: ).

Cheers!