Skip to Content
Author's profile photo Bhaskar Tripathi

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

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 😀 !

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 😉 ).


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Siddharth Rajora
      Siddharth Rajora

      Bhaskar, Very lucid, detailed steps you have listed. Very helpful Thanks for sharing your knowledge and perhaps more blogs 😉 Best.

      Author's profile photo Bhaskar Tripathi
      Bhaskar Tripathi
      Blog Post Author

      Thanks Siddharth! 🙂

      Author's profile photo Former Member
      Former Member

      nice blog , helpful to us all ,

      Thank you.

      Author's profile photo Shankar Reddy Chamala
      Shankar Reddy Chamala

      Nice blog 🙂

      Just to add one point to below.

      If you want to hide fields across all subtypes, you can make use of views: V_T588MFPROPS and V_T588MFPROPC.

      For subtype level, we can control in above tables itself by doing configurations.

      No need of doing enhancement for subtypes.

      Author's profile photo Bhaskar Tripathi
      Bhaskar Tripathi
      Blog Post Author

      Hi Shankar,

      Yes you are right. I have corrected the same. Thanks for pointing out 🙂


      Author's profile photo Santhosh Manchala
      Santhosh Manchala

      Hi Bhaskar,

      thanks for the blog. I have a question on this. Have you done changes to HRESS_CC_PER_OVR_ADDRESS_XX  for overview page to show these new fields?

      I have made changes to this and created a new configuration for DTL page for US specific. I have used these two in Personal Data Config and it says it cannt convert from XX to Molga 10.

      Also I have created a new ZHRESS_CC_PER_OVR_ADDRESS_US and also custom DTL screen ZHRESS_CC_PER_DTL_ADDRESS_US for edit screen. This also errors out with conversion issue. Could you please guide me.

      Author's profile photo Seema Naharia
      Seema Naharia

      Hi Bhasker,

      I have added extra field in structure for infotype 0077. I can see those fields in personal prodile but whne I try to populate those fields, system autopopulates field non-veteran and throws eror please select a valid veteran state.

      Meaning is system is not able to reconize the population of extra veteran status fields. If i populate exiting fields then those get updated without any problem. But if I populate these new fields, system autopopulate non - veteran and throws error that please select a valid state. when I debug and see, internal table has non veteran selected and one of extra fields selected. I do no know from where non veteran status gets selected automatically.

      Please help me out here. I have tried using 0077_10 also since it has all the fields. I do not need to add extra. But system is throwing another dump.

      Both methods are not working for me to have additional personal information on personal profile in ESS.



      Author's profile photo Seema Naharia
      Seema Naharia

      Hi Bhasker,

      I saw in conversion class, this piece of code is written, due to which system is throwing error please select a veteran status and autopopulating non-veteran.

      *veteran status are mandatory for international screens

      *Error message if vet status is not maintained.

            IF <r0077>-vets2 EQ space AND <r0077>-vets3 EQ space

           AND <r0077>-vets4 EQ space AND <r0077>-vets5 EQ space

           AND <r0077>-vets1 EQ space.

      *        MESSAGE e055(5u).

             CALL METHOD cl_hrpa_ben_services=>fill_message


                    message_handler = message_handler

                    msgty           = 'E'

                    msgid           = '5U'

                    msgno           = '055'


                    is_ok           = is_ok.


      this is standard code. I have added fields vetst6, 7, 8 and 9. But system is checking only 1,2,3,4 and 5.  thats the reason it is throwing error.  How can we regenarte the conversion class to have new fields also in various checks.



      Author's profile photo Bhaskar Tripathi
      Bhaskar Tripathi
      Blog Post Author

      Hi Seema,

      2 options:

      1. Implement enhancement to overwrite current conversion class method.

      2. Define a new conversion class (by copying the existing one) and write your logic accordingly. After that, set this class in view V_T588UICONVCLAS.

      Hope it helps.



      Author's profile photo Former Member
      Former Member

      Hi Bhaskar,

      Pretty good blog. I have one question though.

      How did that Edit melting group page comes up. Not able to find that in my system.



      Author's profile photo Bhaskar Tripathi
      Bhaskar Tripathi
      Blog Post Author

      Thanks Priti and sorry for late reply.

      I hope you would have got the answer already. If not, you just have to select the melting group and click on add element button (to add field).


      Author's profile photo Former Member
      Former Member

      Thanks Bhaskar,

      Thanks!! I got that . But I am facing another issue regarding ZHRESS_CC_PER_CONFIG.

      I am not able to save that. Can you please help with this?

      Please refer to :

      Please help in this regard.



      Author's profile photo Former Member
      Former Member

      Nice Document,

      Thanks a lot 🙂