How is TMS_PROFILE / TMS_* used?

[former_member415661]

Anyone have some examples of how the Talent Management PD Profiles are used? I've read the help files that they are used in conjuction with the Security roles, but when look at these template roles, there is no example if it is used as part of P_ORGINCON or PLOG

We have a requirement to implement structural authorization on infotype 7406 - Mobility. Some guidance of usage would be helpful. Thanks,.

[Former Member · Accepted solution]

Hello Kevin!

First things first. You may not remember this, but we actually worked together back when I first learned SAP. You rolled onto my company's project for a time during its early stages. Hope you're doing well.

For the TMS PD profiles provided by SAP, they aren't really helpful from the perspective you're looking for. The profiles SAP provides for the TMS, as Luke mentioned, are all about individual objects but without regard to manager assignment (instead focusing on the Area of Responsibility assignment), and the TMS_MAN_PROF hinges on successor relationships.

Sorry to answer a question with a question, but are you planning on having your managers looking at HRP7406 through a means other than the way SAP delivers (the Talent Profile)? I ask that because SAP's standard structural authorizations on PERNR will generally accomplish what you want, unless you're going to have a unique way for manager's to access mobility data.

Let me know.

Take care,

Chris

[former_member415661 · Accepted solution]

Ah yes, Of course I remember. How's your boss Julie Miller. It's been 5 years, time flies. How are you? Still supporting SAP? What module have you expand to now?

As for the post, I am curious about the profile because of an interesting requirement. It is not so a manager structural auth requirement, but a HR support Line of Business requirement. Today, we have a custom relationship representing a HR person to one or more org structures representing the line of business they support. So we are using P_ORGINCON for structural authorization. However, our structural auth is special in a sense it is only applicable to compensation / pay related infotypes. All other infotypes are global data and could be seen cross area.

Now with Talent Management, since it is PD data (OM infotypes), P_ORGINCON concept would not work in this matter. They belong to 74xx series infotype. They fall under PLOG. I read there is a possibility of using structural auth with PLOGCON, but no one have seems to successfully implemented PLOGCON due to issues SAP were unable to resolve. The requirement is to have infotype 7406 - Mobility be part of structural profile. As the result, via portal, the HR administrator can only see data from infotype 7406 for who they support / falls within their line of business.

I guess after some heavy research, we would have to go the route of custom code / BADI to handle the structural auth requirement since PLOGCON does not work. I've did a simple test and create a role calling PLOGCON and assign it to an ID. In the trace, while accessing a simple object such as "C - JOB", it stills try to reference PLOG. Even with all the flag activated via T77S0 on PLOGI PDCON.

So there is where I am stuck and wasn't sure if anyone else had similar requirement. Not necessary structural auth on 7406, but just any structural auth on any Talent Management infotyoes (74xx). Structural Auth on Performance Appraisal is easy as there is a BADI for it and I had code it as such, so it works fine there.

Keep in touch..

KN

[Former Member · Accepted solution]

Hi Kevin:

Excellent memory on my former manager. Julie is excellent, but I don't have up to the date information, because, to copy a popular phrase; a couple years ago, I took my talents to independent consulting.

So you're going to be building your own front end application for HR to access HRP7406 data, is that correct?

Does it interest you at all to know that SAP has accounted for that HR line of business reporting relationship? S <-> O 741 is that relationship and you can administer it in transaction HRTMC_PPOM. If you had that, and coupled it with the profile for TMS users to only see CP data for people they have access to (TMS_PROF_90 I think, but I don't have SAP available to me at the moment), it should accomplish your task, wouldn't it? This would work for any of the 7402 - 7409 infotypes (the CP infotypes).

Or, if you copied that profile and modified the evaluation path to use your own relationship, that might also accomplish the task.

What do you think? Would that work for you? Would it be correct for me to say you wish to use the Talent Management infotypes, but you plan to use a different mechanism than the delivered TMS functionality for HR to access that data?

[former_member415661 · Accepted solution]

Lol!! Independent huh! The common route a lot of people take after a large implementation such as yours. I assume you still live in the same area?

In terms of front end, nope. They are accessing this all via portal. I believe the portal frame work is activated by using the template roles they provide. Talent Mgmt provide 4 new template role. I am not involve with the project directly. Was asked to help out with some design area, so I believe it was activated due to the template role. We have several tabs activated for TMS. There are education (moved from infotye 0022 to 74xx), prior worked experiences (both internal and external), mobility, etc.,).

As of right now, I believe they are not going with big bang approach, so they only focus on a small element of TMS and not activate all of it yet. So chances, the relationship is not fully setup yet.

Isn't relationship 741 the business partner relationship (I think, can't remember).

So right now, we have HR with backend ECC access. We will have Talent Management Specialist, to maintain these elements via portal. I'll have to explore the CP. We might need to build a function module on top to read the CP and find the correct P to return. In most cases, CP shouldn't be an issue, but on those who have International Assignment or Transfer (MGE), they do have many P's.

[Former Member · Accepted solution]

I don't know, it doesn't seem THAT common if you ask me. But I'll tell you I worked enough consecutive 70 hour weeks where I only got paid for 40 hours to last me a lifetime.

I'm confused though about what you're saying for the TMS. So your client IS using the standard delivered TMS portal front end? Even if they're only using some of it, you'll almost undoubtedly want to start in with the 741 relationship. Business Partner is 208 to Central Person. Then CP is 209 to Person. Just like the new infotypes, there are new relationships too in the 74* range. I say new, but I guess they've been out since late 2008 now.

For instance, when you said: "We have several tabs activated for TMS. There are education (moved from infotye 0022 to 74xx), prior worked experiences (both internal and external), mobility, etc.,)" The TMS accesses this data through the application HRTMC_SEARCH. This application finds employees by figuring out which employees a TMS has access to. It does that by using the 741 relationships you set up in HRTMC_PPOM.

If you don't use the 741 relationship for the TMS and instead use your own, you'll be tweaking a lot of Web Dynpro components, as well as ESH, to look for your custom relationship instead of the SAP delivered.

Thanks,

Chris

[lukemarson · Accepted solution]

Looks like you two got this covered

For my 2 pence worth (British saying) it sounds like the AOR (741) relationship would suit your requirement for HR LoB.

[former_member415661 · Accepted solution]

So are you saying....

By using relationship 741 from the CP -> O (HR person to Org they are responsible for / LOB) and PD Profile TMS_PROFILE, I should be able to meet the structural auth requirement on infotype 7406?

So on the security roles, we would use P_ORGINCON against PD Profile TMS_PROFILE on infotype 7406?

Hmmm I would like to explore that if it does work. I didn't think you could use P_ORGINCON against 74xx infotypes.

One thing to note...the current structural auth we have with P_ORGINCON isn't like most company.

All infotypes (minus 8, 15, 25, 758, 759, 267, and comp related infotypes) are considered as global data. Meaning, no need structural auth. It is able to be seen across LOB.

Only Comp related infotypes are considered through P_ORGINCON for structural auth. We created a PD_PROFILE called HRBP and table T77UA is populated with data element of position, org, and person for that HR person as it relates to comp data

So we able to do the same with 7406? Let say that is the only talent infotypes with structural requirement?

[Former Member · Accepted solution]

>

> So are you saying....
> 
> By using relationship 741 from the CP -> O (HR person to Org they are responsible for / LOB) and PD Profile TMS_PROFILE, I should be able to meet the structural auth requirement on infotype 7406? 
> 
> So on the security roles, we would use P_ORGINCON against PD Profile TMS_PROFILE on infotype 7406?
> 
> Hmmm I would like to explore that if it does work. I didn't think you could use P_ORGINCON against 74xx infotypes. 
> 
> One thing to note...the current structural auth we have with P_ORGINCON isn't like most company. 
> 
> All infotypes (minus 8, 15, 25, 758, 759, 267, and comp related infotypes) are considered as global data. Meaning, no need structural auth. It is able to  be seen across LOB. 
> 
> Only Comp related infotypes are considered through P_ORGINCON for structural auth. We created a PD_PROFILE called HRBP and table T77UA is populated with data element of position, org, and person for that HR person as it relates to comp data
> 
> 
> So we able to do the same with 7406? Let say that is the only talent infotypes with structural requirement?

HI Kevin, SAP authorizations, one of my favorite topics...

so anyways you are right. P_ORGINCON only works against PA infotypes, not OM infotypes (HRP*).

However, in a single role you can build a context that returns object IDs in P_ORGINCON - which is than restricted based on infotypes you list in the PLOG authorization object (hrp tables).

So - to make this work, you need to make sure that whoever gets this role, has a restricted access to only the correct Central Person numbers.

If for example you gave CP * structural access in a ESS profile, it would conflict with this talent management role.

In the talent management role, you can create a P_ORGINCON with the something like the following;

Authorization level R

Infotype 0001

Personnel Area *

Employee Group *

Employee Subgroup *

Authorization Profile TMS_PROFILE

Subtype ' '

Organizational Key *

Then, you define a PLOG object such as the following:

Infotype 7406

Planning Status ', 1

Object Type CP

Plan Version 01

Function Code AEND, DISP, INSE

Subtype *

The TMS_PROFILE first works by calling the FM: HRTMC_GET_ALL_RESP_ORGUNITS - This finds the respective root org unit for 741 relationshiop. Each of these org units are then through the evaluation path: O_S_SUCC. This is what creates the linkage to only the specified CPs of A741 responsibility.

You can see the tms_profile in OOSP and the eval path in OOAW. although from your post it looks like you already got there, just leaving just in case.

hope this helps.

Michael.

[former_member415661 · Accepted solution]

>

> >

> > So are you saying....
> > 
> > By using relationship 741 from the CP -> O (HR person to Org they are responsible for / LOB) and PD Profile TMS_PROFILE, I should be able to meet the structural auth requirement on infotype 7406? 
> > 
> > So on the security roles, we would use P_ORGINCON against PD Profile TMS_PROFILE on infotype 7406?
> > 
> > Hmmm I would like to explore that if it does work. I didn't think you could use P_ORGINCON against 74xx infotypes. 
> > 
> > One thing to note...the current structural auth we have with P_ORGINCON isn't like most company. 
> > 
> > All infotypes (minus 8, 15, 25, 758, 759, 267, and comp related infotypes) are considered as global data. Meaning, no need structural auth. It is able to  be seen across LOB. 
> > 
> > Only Comp related infotypes are considered through P_ORGINCON for structural auth. We created a PD_PROFILE called HRBP and table T77UA is populated with data element of position, org, and person for that HR person as it relates to comp data
> > 
> > 
> > So we able to do the same with 7406? Let say that is the only talent infotypes with structural requirement?

>

>

> HI Kevin, SAP authorizations, one of my favorite topics...

>

> so anyways you are right. P_ORGINCON only works against PA infotypes, not OM infotypes (HRP*).

>

> However, in a single role you can build a context that returns object IDs in P_ORGINCON - which is than restricted based on infotypes you list in the PLOG authorization object (hrp tables).

>

> So - to make this work, you need to make sure that whoever gets this role, has a restricted access to only the correct Central Person numbers.

>

> If for example you gave CP * structural access in a ESS profile, it would conflict with this talent management role.

>

> In the talent management role, you can create a P_ORGINCON with the something like the following;

>

> Authorization level R

> Infotype 0001

> Personnel Area *

> Employee Group *

> Employee Subgroup *

> Authorization Profile TMS_PROFILE

> Subtype ' '

> Organizational Key *

>

> Then, you define a PLOG object such as the following:

> Infotype 7406

> Planning Status ', 1

> Object Type CP

> Plan Version 01

> Function Code AEND, DISP, INSE

> Subtype *

>

>

> The TMS_PROFILE first works by calling the FM: HRTMC_GET_ALL_RESP_ORGUNITS - This finds the respective root org unit for 741 relationshiop. Each of these org units are then through the evaluation path: O_S_SUCC. This is what creates the linkage to only the specified CPs of A741 responsibility.

>

> You can see the tms_profile in OOSP and the eval path in OOAW. although from your post it looks like you already got there, just leaving just in case.

>

> hope this helps.

> Michael.

Thanks Michael for the ino. I have to explore that a bit. What you've provide might conflict with what we are already doing.

For example:

Infotype 0001, we are using ALL profile right now since we consider it as non-comp sensitive. This information can be seen across LOB with and without structural auth.

Authorization level R

Infotype 0001

Personnel Area *

Employee Group *

Employee Subgroup *

Authorization Profile ALL

Subtype ' '

Organizational Key *

For something sensitive, like infotype 0008, we use structural auth profile.

Authorization level R

Infotype 0008

Personnel Area *

Employee Group *

Employee Subgroup *

Authorization Profile HRBP, MANAGER

Subtype ' '

Organizational Key *

Using PD Profile HRBP, we have use relationship A299 from the position of the HR person to the Org Unit they support (LOB). With that, in OOSP we have the function module and eval path to pull based upon A299 relationship to populate T77UA.

So in T77UA for the person against HRBP PD Profile, it will say who they have access to as it relates to infotype 0008.

If we are doing such already, that might conflict to what you are suggesting. I agree that most company structural auth is a lot clearer defined, unfortunately here I inherit a rather mix requirement. hehehe.

Edited by: Kevin Nguyen-Tu on Jan 24, 2011 5:44 PM

[former_member415661 · Accepted solution]

Thanks Michael for the ino. I have to explore that a bit. What you've provide might conflict with what we are already doing.

For example:

Infotype 0001, we are using ALL profile right now since we consider it as non-comp sensitive. This information can be seen across LOB with and without structural auth.

Authorization level R

Infotype 0001

Personnel Area *

Employee Group *

Employee Subgroup *

Authorization Profile ALL

Subtype ' '

Organizational Key *

For something sensitive, like infotype 0008, we use structural auth profile.

Authorization level R

Infotype 0008

Personnel Area *

Employee Group *

Employee Subgroup *

Authorization Profile HRBP, MANAGER

Subtype ' '

Organizational Key *

Using PD Profile HRBP, we have use relationship A299 from the position of the HR person to the Org Unit they support (LOB). With that, in OOSP we have the function module and eval path to pull based upon A299 relationship to populate T77UA.

So in T77UA for the person against HRBP PD Profile, it will say who they have access to as it relates to infotype 0008.

If we are doing such already, that might conflict to what you are suggesting. I agree that most company structural auth is a lot clearer defined, unfortunately here I inherit a rather mix requirement. hehehe.

[Former Member · Accepted solution]

>

> Thanks Michael for the ino. I have to explore that a bit. What you've provide might conflict with what we are already doing. 
> 
> For example: 
> 
> Infotype 0001, we are using ALL profile right now since we consider it as non-comp sensitive. This information can be seen across LOB with and without structural auth. 
> 
> Authorization level            R                                  
> Infotype                       0001           
> Personnel Area                 *                                  
> Employee Group                 *                                  
> Employee Subgroup              *                                  
> Authorization Profile         ALL
> Subtype                        ' '                                
> Organizational Key             *                                  
> 
> For something sensitive, like infotype 0008, we use structural auth profile. 
> Authorization level            R                                  
> Infotype                       0008           
> Personnel Area                 *                                  
> Employee Group                 *                                  
> Employee Subgroup              *                                  
> Authorization Profile         HRBP, MANAGER
> Subtype                        ' '                                
> Organizational Key             *  
> 
> Using PD Profile HRBP, we have use relationship A299 from the position of the HR person to the Org Unit they support (LOB). With that, in OOSP we have the function module and eval path to pull based upon A299 relationship to populate T77UA. 
> 
> So in T77UA for the person against HRBP PD Profile, it will say who they have access to as it relates to infotype  0008. 
> 
> 
> If we are doing such already, that might conflict to what you are suggesting. I agree that most company structural auth is a lot clearer defined, unfortunately here I inherit a rather mix requirement. hehehe.

Hi Kevin, I reviewed this more thoroughly with our security consultant. I provided some misleading information before.

Basically when you turn on structural authorizations, the OM side check happens automatically and there is no way to give context on the OM side.

sooooo let me try to explain that a bit more. let's assume you have 1 user and that user has two structural profiles defined in T77UA.

PROFL_1_CP - returns all CP based on their manager relationship

PROFL_2_CP - returns all CP *

now completely ignore everything I said about P_ORGINCON - this applies in no way to your problem around HRP7406. This entire solution needed is on the OM side and doesn't touch PA.

Now, in the PFCG role you define PLOG:

Infotype 7406

Planning Status ', 1

Object Type CP

Plan Version 01

Function Code AEND, DISP, INSE

Subtype *

The important point about PLOG is that you cannot specify the structural profile, so what SAP does automatically is applies all structural profiles available to the user in T77UA and then applies it the PLOG specification. So what this means is there is no way to provide context authorization on HRP7406 for the CP object.

Well, wait a second? what about the auth object called PLOG_CON - because this allows within the role to specify the structural profile. Therefore, you could make one PLOG_CON have just read access for HRP7406 using PROFL_2_CP and another PLOG_CON have edit access to HRP7406 using PROF_1_CP and now you successfully created a context authorization on the OM side.

So PLOG_CON is the solution? Nope, in su21 you can go to the object (under HR node) and read the documentation. the first sentence from SAP is: NOTE: Do NOT use this authorization object. It does not work.

It's actually quite comical to see it, so you should check it out. My security colleague said he experimented with it and confirmed SAPs conclusion that it does not work.

Conclusion:

As i thought through this problem in more detail, it appears to me (unless someone can enlighten me on any misstatements i'm making, as I already did that on the previous post) that we have a growing GAP in the SAP authorization model that is needed to support Talent Management.

As Talent Management functionality increases, SAP continues to drive more functionality through the CP object sitting on the HRP (om tables). As Talent Managenent functionality increases, you will have increased need for context based structural authorizations needed on OM.

Maybe you need a role where the :

HR Talent Manager should be able to edit potential (HRP7408) for their A012 employees, but only display potential for the rest of the organization. Well with what I just laid out that's impossible to make work in SAP using standard authorizations.