cancel
Showing results for 
Search instead for 
Did you mean: 

Will IT0041 come decoupled in EHP7?

Former Member
0 Kudos

Hello group,

Our users want IT0041 to be shown in ESS.

We are on EHP5.

I checked IT0041, and it is not fully decoupled.

I see that there is a controlling class for Belgium (molga 12), but not international or for other countries.

I realize we can build this ourselves.

However, if it comes fully decoupled in EHP7, we want to wait until we upgrade next spring.

Does anyone know?

/Kirsten

Accepted Solutions (0)

Answers (1)

Answers (1)

stuart_campbell
Active Contributor
0 Kudos

Hi Kirsten

Its not clear what you mean by fully decoupled - can you clarify what is missing ?

Are the following structures not available in client 000 of your current system

HCMT_BSP_PA_XX_R0041

HCMT_BSP_PA_XX_R0041_LIN_A

Best wishes

Stuart

Former Member
0 Kudos

HI Stuart,

The structures are available.

But in V_T582ITVCLAS the infotype is "Not permitted" in Infotype for New Framework.

And in V_T582ITVCHCK the verification class is for molga 12 only.

Best regards

Kirsten

stuart_campbell
Active Contributor
0 Kudos

This is the same in our internal EHP7 system and I can find no documentation delivering changes

What I would say is I am not sure if missing check classes for other countries has any bearing on decoupling - this usually just means theres no country specific delivery - the rest of the countries use XX check class

In what way do you plan to use 0041 in the decoupled framework ?


Former Member
0 Kudos

Thanks, Stuart.

There is no XX check class for 0041, this is why I wondered.

They want to display the date-types for the employee in ESS.

I am torn between creating a "regular" UIBB or just making our own listing the data.

So I am playing with it in my sandbox.

/Kirsten

stuart_campbell
Active Contributor
0 Kudos

I might be wrong but is the XX check class not CL_HRPA_INFOTYPE_0041 ? in V_T582ITVCLAS ? for all countries except Belgium

Also for using in ESS - I would recommend to test standard approach to adding a new infotype to Personal Profile and see how you get on - would be interested in your feedback

Former Member
0 Kudos

Hi again,

Yes, CL_HRPA_INFOTYPE_0041 exsists in V_T582ITVCLAS, but the record is marked "Not permitted" for New Infotype Framework (which seems to be the term these days).

I will go ahead and test it by permitting the class, and with the Belgium class in V_T582ITVCHCK and let you know the result. Right now I am stopped in the config due to a problem in our sandbox setup - so it might be a while before I finish this.

Kirsten

siddharthrajora
Product and Topic Expert
Product and Topic Expert
0 Kudos

Typically you see infotypes for ESS UI are decoupled. You should be able to achieve your requirement without decoupling Note you can create any custom infotype as decoupled.This means, a CHECK class should be provided in view V_T582ITVCLAS.It is not necessary to have huge code inside this class; even empty implementations should be fine, important is to have this class implement some methods in principle. Of course, if the custom infotype has its logic in module pools, that needs to be incorporated into the BL class. Note that Basically there are 2 "HR masterdata frameworks" that (technically) handle the masterdata maintenance: the 'old infotype framework' (OITF) and the 'new infotype framework' (NITF). O ITF comprises the user exits ZXPADUxx and the BAdI HRPAD00INFTY. It is called from standard transactions PA30/PA40 etc. NITF uses enhancement spot HRPAD00INFTYBL. NITF is called in the Concurrent Employement environment for certain infotypes (see T582ITVCLAS, field NITF_ADM) during PA30/PA40 maintenance and by certain applications like HCM Processes&Forms and ESS. This means NITF only uses enhancement spot HRPAD00INFTYBL HCM P&F only uses the new infotype framework hence ZXPADUxx and BAdI HRPAD00INFTY are NOT called via the NITF.

not recommended to change permisssiblity of standard infotypes as it ll cause dump.

Former Member
0 Kudos

Thank you Siddharth,

ESS is exactly the reason we were wondering if IT0041 would be decoupled in EHP7 - do you know?

Also - you mention that we should be able to bring IT0041 to ESS without decoupling? Are you thinking about just building a UIBB that reads infotype 41 (as display is what we want).

Reason for treating it like other infotypes in ESS is to get a unified interface.

We actually did change permissibility of IT0023 to include it in ESS. This has worked (I understand it will be delivered in EHP7 as decoupled).

Bottom line:

1. Will IT0041 be decoupled for international use in EHP7 (it seems to be for Belgium).

2. If not - how do you suggest we fill customer's requirement (showing date types in ESS) - preferably with identical look and feel as the rest of ESS.

3. What kind of dumps will we get if we change permissibility (and of course include it in BOL/GENIL-model).

Thank you again.

Kirsten

siddharthrajora
Product and Topic Expert
Product and Topic Expert
0 Kudos

good question, so if you change the permissibility of other IT and it worked, I would suggest please go ahead and try with 0041 We haven't heard any need for 0041 to be decoupled, EHP7 is out already and yes its not decoupled, I have to check for future releases etc. I would suggest try with decoupling if that doesn't work try with UIBB You said screen look different, Please can you share how does it differ? are you allowing Employees to update 0041? or display only?

stuart_campbell
Active Contributor
0 Kudos

I have looked at various sources and cannot see where V_T582ITVCLAS would influence ESS - this table likely determines the permissibility for back-end ECC to use decoupled framework not ESS - ESS always uses decoupled framework if it is available - which it looks to be in the case of XX and BE (but only these molgas)

What error do you face when using or trying to customize ESS to show 0023 or 0041 - I suspect this is caused by some other issue - perhaps the MOLGA of employee used -  or the structure of the infotype itself (requiring specific UIBB customizing)