SAP BW HCM Reporting - P_PERNR concept in BI, who's done it

[Former Member]

Just curious if anyone one has achieved P_PERNR type restriction in BI, and how did you do it. Right now I'm thinking when we generate structural authorizations we'll use a routine to remove the pernr of the user that is being assigned the structural auth. Thanks Mike.

[kmoore007]

You could use an Enhancement Implementation at the end of the source code for the function HR_BW_IS_AUTHORITY to "enhance" the structural authorizations to your liking using ABAP. Hopefully, your HR ABAPer is somewhat familar with Enhancements. This is also assuming you are on SAP ECC 5.0 or above.

Alternatively, take a look at SAP Note Number: 1342620 BI-HR Structural Authorization.

[romanweise]

Hello Mike,

could you give a bit more background information on the goal you want to achieve? Which information shall the report contain and which action you want to generate from the information?

From my perspective BI is for reporting aggregated data so why you need restrictions on a single persons data? Either someone can report salary information or he cannot (perhaps restricted to a certain part of a company). Restricting single data records coultd result in wrong aggregation within reports furthermore just hiding certain records to a pernr will not ensure that data cannot be associated to a person. If someone can report on salary structures and restrict e.g. on org.unit and level of employment he could get the exact payment for the department head if he is the only one in level of employment = manager.

Having a better understanding on your functional reporting requirements will surly help people to offer possible solutions.

Kind Regards

Roman

[Former Member]

Hi Roman,

I completely agree with all that you have stated.

I need more information to push back on this type of requirement. The business is not too familiar with BI analystics therefore they are wearing their ECC transactional reporting hats. Could you provide with some bullets as to why trying to restrict individuals records is a flawed approach in BI? I see you have already mentioned a couple issues:

1.) Aggregated data will be skewed if individual records are restricted.

2.) Users could derive values by drilling down on other characteristics.

Thanks,

Mike

[Former Member]

>

> Right now I'm thinking when we generate structural authorizations we'll use a routine to remove the pernr of the user that is being assigned the structural auth.

I don't think that is enough.. What about telephone number? Address? Bank account? Number of employees on the cost center.

Cheers,

Julius

[Former Member]

We're not attempting to restrict all characteristics associated with a user, just those related to compensation for themselves. However, they need to see compensation for their direct reports. This is how we're doing it in ECC today. Trying to replicate in BI reporting.

[Former Member]

Sorry, I missed the part about removing it from the analysis authorizations. I thought you wanted to anonymize the data itself.

This seems a bit strange to me as via ESS they would be able to see this data. P_PERNR enables exactly (only) that aspect.

Perhaps if you explain which org key level you are using and why they should not have access to their own data, then it will be easier for someone to spot who has already done this.

Cheers,

Julius

[Former Member]

Hi Julius, actually from an ESS and MSS perspective in ECC, no one outside of HR can view their own compensation. Our company just doesn't allow visibility to it anywhere outside of a manager giving you a printed letter.

Its a funky requirement, but the reason is that HR doesn't want compensation adjustments to be visible to a user prior to an official communication from their manager, and the infotypes usually are updated weeks before the communication.

It's a case of using security control vs. changing a business process.

[Former Member]

> Its a funky requirement, but the reason is that HR doesn't want compensation adjustments to be visible to a user prior to an official communication from their manager, and the infotypes usually are updated weeks before the communication.

So you don't need to delimit the time, or use a procedure for only loading the current data into your cube.

Have you considered only dequeing the data on a monthly basis? I guess you need it in BW?

Tricky question... I will think about it.

For a BW specific technical solution, I can move the thread to the BW forum for a while. Perhaps a ninja there has done this before.

Let me know,

Julius

[Former Member]

Sure if you think it may get more visibilty out there that would be fine.

I am also considering using time delimiting on the authorization, but that would mean restricting comp for all direct reports too, not just the managers. Also users that are intentionally restricted in ECC could just go to BI when the auth was valid.

Personnally I think comp should be available to associates, and the transfer from compensation planning infotypes(0759) to actually (0008) should occur in unison with notifications.

But for now, trying to come up with an approach the the business is ok with.

Thanks Julius,

Mike

[Former Member]

Lets try the HCM forum for a second opinion.

There are a lot of "linkfarmers" here, so just hit the "Report Abuse" button (yellow triangle) if you get such answers.

Cheers,

Julius