Security Restriction at Field Level
Scenario: For transaction PA20/PA30 - you wish to restrict the user from viewing the social security field for some users, but you wish this field to be visible for another group of users
Answer: Using screen modifications, table t588m, create an alternate screen for infotype 2. In the alternate screen set the ssn to hide. Change feature p0002 to determine which screen the employee should see. If the fields needed to determine which employees should see which screen are not available in the feature, have the feature call an abap program. The abap program can check security or whatever and return a code to the feature.
If a user is blocked from using a certain transaction, choose transaction code /nSU53 immediately after the failed transaction. This will give the security person the details that are required to let this user access the pertinent transaction/screen.
If you have been denied access to a transaction that you should have access to, enter transaction code SU53 immediately after the failed transaction. This will give you a chance to see the user groups that were initiated.
For structural authorizations, use the menu path in the IMG:
Personal ManagementOrganisation Management
The transaction code for the above is OOSP.
These authorisations can be plan version specific as well as object specific (authorisations for position, organisation unit, etc.)
After maintaining authorisations in this screen, you can assign authorisations to user names in: Assign structural authorisation to authorisation profiles. The transaction code for the above is OOSB.
When an infotype is introduced, you have to use the Standard authorizations to control when you want to limit the records to the arbitrary HR structure, you use the Structural Profiles ( PD Profiles). You should be able to accomplish what you want, but you may have to turn on the HR authorization checks P_ORGIN or P_ORXXX. SAP delivers these turned OFF. Depending on the version of SAP they are turned on in different ways. The 4.6 code is something like OOSW, but regardless of the version if you go to transaction code SU03, select Human Resources and put the cursor on the P_ORGIN authorisation object and click on the documentation button. It will tell you how to turn on the authorisation check.
Note: The way HR is structured means that you cannot always rely on SU53 to work out which values you need. In fact, in many cases SU53 will be wrong. You will have to go into Debug or just use good old trial and error to find the solution.
PD Profiles and Standard profiles are two independent items but work together if assigned to the user. The only "link" is the ability to assign the PD profile and Standard profile ( Activity Group) to a position in the HR structure ( Job, Position, Org level) or to the user ID directly.
You can authorise certain payroll users to run specific payrolls by using the administrator fields on IT 0001. You can incorporate the particular code for the different administrator fields into the authorisation profiles.
Customer-Specific HR Master Data Authorisation Object
You can create a customer-specific authorisation object for HR: Master Data. It must be defined and then the program code generated. Program RPUACG00 can do this.
To do so, go to program RPUACG00 - Code Generation for HR Master Data Authorisation Validation. Read the documentation that will take you through the different steps and allows you to execute them.
For example, to create a new authorisation object which allows you to restrict on Personnel Sub-area:
- Go to transaction SU21 - list of authorisation classes and objects. Go into the HR class and create a new object that has the same fields as P_ORGIN but also has the field BTRTL (personnel sub-area). Make sure it has a Z or Y at the beginning of the name, e.g. Z_ORGIN.
- Execute the program RPUACG00 with the name of your new authorisation object and the test status removed. Use your user name as the password. You will need a developer and access key for this.
- Optional: In transaction SU24 (Maintain assignment of Authorisation Objects to Transactions) add your new authorisation object to the transactions which will require it e.g. the same as those using P_ORGIN. If you don't do this, the new auth object will not be pulled into the profile generator when the relevant transactions are added to the user menu of a role. You would have to add it manually each time.
Adding the relevant transactions will ensure that they are generated as and when they are required.
- Modify the roles that are accessing HR: Master Data to include the new object. Remember that SAP_ALL will need to include it - make sure that you check that all roles or profiles with P_ORGIN also have the new object or they will have no access to master data at all.
Run a report to list the current roles or profiles that use the P_ORGIN authorisation profile. The title of the report is "List Profiles by Complex Selection Criteria" and can be called by using transaction code S_BCE_68001409.
- Activate the check for the new authorisation object by turning on the switch NNNNN in transaction OOAC (HR: Authorisation main switch). Set the switch to "1" to make it active.
Remember that all roles with P_ORGIN will be affected. They will not be able to access master data when it is turned on unless they also have the new authorisation object, including SAP_ALL.
Restricted Security to SE16 - Data Browser
Wishing to allow everyone to access the data browser (SE16) but not giving authorization to access the basic pay infotype (table PA0008)?
You need to assign an authorization group to the table and then allow table access for the users to access all groups except this one - e.g. assign group ZZZZ to this table (PA0008) then give everyone access to groups 0000 - ZZZY. This will cover all the tables except the one holding basic pay.
You can adjust these authorisation groups on tables by executing SUCU or SE54
No comments:
Post a Comment