2009 Feb 06 7:36 AM
Hi Experts,
I am unable to restrict personal subarea wise authorisation which is very important with view to my current scenario, secondly i am not able to restrict on infotype wise like if i am restricting on deletion ,system is restricting on creation also.Please help.
Regards,
Vinny
Edited by: vinny on Feb 6, 2009 8:39 AM
2009 Feb 06 8:11 AM
Hi Vinny
If you want to check authorization on personal Subarea, you need to use the P_NNNNN authorization object, you can find some documentation on it [here|http://help.sap.com/saphelp_47x200/helpdata/en/bc/b8b83b5b831f3be10000000a114084/frameset.htm] - Remember, you need to activate this check as well.
Regarding the deletion check, your right, it not possible to separate create, maintain and delete in object P_ORGIN. If it's a must you need to take a look at the possibilities for implementing a BAdI, or other workarounds, like a transaction variant etc
Regards
Morten Nielsen
2009 Feb 06 8:11 AM
Hi Vinny
If you want to check authorization on personal Subarea, you need to use the P_NNNNN authorization object, you can find some documentation on it [here|http://help.sap.com/saphelp_47x200/helpdata/en/bc/b8b83b5b831f3be10000000a114084/frameset.htm] - Remember, you need to activate this check as well.
Regarding the deletion check, your right, it not possible to separate create, maintain and delete in object P_ORGIN. If it's a must you need to take a look at the possibilities for implementing a BAdI, or other workarounds, like a transaction variant etc
Regards
Morten Nielsen
2009 Feb 06 9:15 AM
HI Morten Nielsen,
Thanks for ur reply, u have mentioned that in p_nnnnn we can maintain authorization for personel subarea but here i am not getting any object for personel sub area , in ur reply u have given some link for documentation but i am not able to open here, please help.
Thanks and regards,
Vinny
Edited by: vinny on Feb 6, 2009 10:15 AM
2009 Feb 06 10:19 AM
hi vinny,
if you want to avoid creating a custom authorization object, you could use the organizational key (VDSK1) from the P_ORGIN object and populate it with the personnel subarea.
for more info on how to do this, look [here|http://help.sap.com/saphelp_47x200/helpdata/en/17/4bba3b3bf00152e10000000a114084/frameset.htm]
good luck!
2009 Feb 06 11:14 AM
Hi, i tried but it is not restricting can u plz tell me , how it will be done.
Regards,
Vinny
2009 Feb 06 11:22 AM
Hi
with the P_NNNNN approach, you need to create your own object, you can see howto [here|http://help.sap.com/saphelp_47x200/helpdata/en/bc/b8b83b5b831f3be10000000a114084/frameset.htm]
Regards
Morten Nielsen
2009 Feb 06 11:53 AM
hi vinny,
just filling in the appropriate personnel subarea values in the org. key fields will not do the trick.
aren't you able to have a look at the saphelp link I posted before?
Controlling the Creation and Validation of the Organizational Key
The VDSK1 feature (Organizational Key) and the T527 (Organizational Key: Control), T527A (Organizational Key: Rules for Creating Organizational Keys), and T527O (Organizational Key: Validation) tables control the creation and validation of the organizational key.
A variable key, VARKY, is determined for this purpose using the VDSK1 feature. This key is used according to the T527 table to determine how the VDSK1 (Organizational Key) should be created or validated. The OFLAG (Default/Validation) and RULID (Rule for Creating Organizational Keys) fields are evaluated for this. The OFLAG (Default/Validation) field can have the following specifications:
The T527A table (Organizational Key: Rule for Creating Organizational Keys) controls the creation of the organizational key.
You can create one or several rows for each rule. The rows are always sorted according to SEQNO (sequence number). SNAME (Field Name) specifies the field of the Organizational Assignment infotype (0001) from which data should be included in the organizational key. Using the LNGTH (Length) and OFFST (Offset) fields, you can also specify that only data from certain places in the specified fields should be transported. OFFST defines the number of places that should be skipped (from the left). LNGTH specifies the number of places that should be included. The fields, or parts of fields, that have been determined for each row are placed after each other in the organizational key.