Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

SAP HR segregation of data

former_member577095
Participant
0 Kudos

Hi all,

We have a customer with a SAP HR system with many thousands of employees.

Part of the business has been split into two different companies.

Their goal is that each user can manage (create, modify, display) data (mainly PA) of his own company.

Supposing that the company concept is related to personal area field of infotype 001, we can manage it through P_ORGIN authorizations for standard transactions (PA30, PA20, ...).

This it not true for SE16, SM30 transactions since they go directly to the database tables.

A partial solution could be using the S_TABU_LIN for table P0001 (for infotype 0001) but it will not works fr other infotypes tables.

Any suggestions for SE16 and SM30 limitaions?

Thanks in advance.

Andrea

1 ACCEPTED SOLUTION

former_member74904
Contributor
0 Kudos

Hi Andrea,

It is a bit of a truism, but this is exactly the reason why SE16 and SM30/31 should not be given to endusers on productive environments.

There really isn't any reason to do that. You can authorize ranges of tables through authorization groups with S_TABU_DIS or specific tables with S_TABU_NAM. But I don't think this is what you're after.

Good luck!

Dimitri.

2 REPLIES 2

former_member74904
Contributor
0 Kudos

Hi Andrea,

It is a bit of a truism, but this is exactly the reason why SE16 and SM30/31 should not be given to endusers on productive environments.

There really isn't any reason to do that. You can authorize ranges of tables through authorization groups with S_TABU_DIS or specific tables with S_TABU_NAM. But I don't think this is what you're after.

Good luck!

Dimitri.

pmuschick
Participant
0 Kudos

It is not recommended to work with S_TABU_LIN and direct table access, although it is common in HR departments. I had to once and they worked out a logic based on the ranges for personnel numbers. That is the only approach you could to do line based authorization on HR tables. However this is not really straight forward.

I would recommend you to work with a logical database and sap ad-hoc queries. You would have to rethink all tables access and get rid of it.

You can assign query authorizations without the critical S_QUERY auth. via binding it to a role. (have to search for a link, but this works). Authorizations will then be checked via P_ORGIN and the other auth. objects. This should be ok for an auditor...