LDB PNP authorization check at record level - rp_provide_from_last

hi,
i am using LDB PNP,
I am using macro 'rp-provide-from-last' .
I neeed to place a authorization check so that the user of the program should only be allowed to view records of the people which comes under the same personnel area as of the user of the program.
Can you please guide me on how to implement this?
thanks in advance,
akash.

Hi,
(1)
Actually, if you're wirting report with PNP LDB, you do NOT need to do this hard-coded auth checking at all. Because the LDB abap code behind PNP has already do this job for you.
So all you need to do is to ask you HR consultant or Basis consultant to modify the authority config of certain ROLE with t-code PFCG, and then assign that ROLE to certain user with t-code SU01.
ABAP code behind PNP will automatically verify the current user according to his ROLE setting.
(2)
In some case you do not work with LDB report, then you need to do the authority check by yourself. General function  AUTHORITY_CHECK is what you need.  AUTHORITY_CHECK do the authority check by means of Authority Object.Belows are authority objects used in HR module(you can also see in PFCG if technial name switched on):
P_ORGIN    HR: Master Data
PLOG       Personnel Planning
P_PCLX     HR: Clusters
P_TCODE    HR: Transaction codes
Sample of checking personal area:
CALL FUNCTION 'AUTHORITY_CHECK'
     EXPORTING
          FIELD1              = ' PERSA'
          OBJECT              = 'P_ORGIN'
          USER                = 'SAPSUPPORT1'
          VALUE1              = 'Z001'  
     EXCEPTIONS
          USER_DONT_EXIST     = 1
          USER_IS_AUTHORIZED  = 2
          USER_NOT_AUTHORIZED = 3
          USER_IS_LOCKED      = 4
          OTHERS              = 5.  
IF SY-SUBRC NE 2.
MESSAGE E001(01) RAISING AUTH_FAILED.
ENDIF.
Reward if helpful pls!

Similar Messages

  • LDB PNP authorization check authorization object

    Hi,
    I have used LDB PNP for HR reports.
    We are using the authority check also, but the problem is all the records/data for all the people is being read by the report where some of the people data should not have been read as they belong to some other personal area that the role of the executer (user).
    Hence it appears that authorization check is not working properly.
    Following is how I am using it, Please suggest corrections or alternate way to correct this issue.
        rp-provide-from-last p0002 space gwa_outlist-begda 
                                                        gwa_outlist-begda.
        IF pnp-sw-found NE '1' OR
            pnp-sw-auth-skipped-record EQ '1'.
            EXIT.
        ELSE.
            ls_tab-vorna = p0002-vorna.
            ls_tab-nachn = p0002-nachn.
        ENDIF.
    Please reply with the corrections ore alterations,
    Thanks in advance.
    Akash.

    Hi,
    (1)
    Actually, if you're wirting report with PNP LDB, you do NOT need to do this hard-coded auth checking at all. Because the LDB abap code behind PNP has already do this job for you.
    So all you need to do is to ask you HR consultant or Basis consultant to modify the authority config of certain ROLE with t-code PFCG, and then assign that ROLE to certain user with t-code SU01.
    ABAP code behind PNP will automatically verify the current user according to his ROLE setting.
    (2)
    In some case you do not work with LDB report, then you need to do the authority check by yourself. General function  AUTHORITY_CHECK is what you need.  AUTHORITY_CHECK do the authority check by means of Authority Object.Belows are authority objects used in HR module(you can also see in PFCG if technial name switched on):
    P_ORGIN    HR: Master Data
    PLOG       Personnel Planning
    P_PCLX     HR: Clusters
    P_TCODE    HR: Transaction codes
    Sample of checking personal area:
    CALL FUNCTION 'AUTHORITY_CHECK'
         EXPORTING
              FIELD1              = ' PERSA'
              OBJECT              = 'P_ORGIN'
              USER                = 'SAPSUPPORT1'
              VALUE1              = 'Z001'  
         EXCEPTIONS
              USER_DONT_EXIST     = 1
              USER_IS_AUTHORIZED  = 2
              USER_NOT_AUTHORIZED = 3
              USER_IS_LOCKED      = 4
              OTHERS              = 5.  
    IF SY-SUBRC NE 2.
    MESSAGE E001(01) RAISING AUTH_FAILED.
    ENDIF.
    Reward if helpful pls!

  • Authorization check at diff levels

    I need this functionality:
    several authorization checks should be implemented.
    ·         Selection on Plant level (authorized yes or no is then taken care within the authorization role)
    ·         When this was successful, check further whether User is authorized for Change, or only for Display mode. When User is only authorized for Display mode, the different button’s e.g. ‘Approve’ ‘Cancel’… are not visible at all or great out. (this is as well then on user level maintained via authorization role)
    How should we do this using ABAP?
    Regards

    Check with below link :
    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/a92195a9-0b01-0010-909c-f330ea4a585c
    Thanks
    Seshu

  • Authorization Check on Multiprovider level

    hi,
    We have following requirement.
    1. we have two groups accessing the same reports (A and B).
    2. When user from A view the report, he should only see the data from A. Similar for B, he should only see data from B.
    3. We also provide ad-hoc query creation in production through Query Designer.
    We thought of creating authorization relevant object and include it in query. But the problem is, if they dont include the authorization object in the query, then data will not be filtered and we will get data security issue. We dont have any problem with Canned queries (deliverd by developers). but while creating ad-hoc query, they might remove the authorization relevant field. Hence, this type of authorization may not work for us.
    Option 2:
    1. While loading the data split the data and load into seperate cubes. That is Cube-A and Cube-B.
    2. Apply info provider level security to Cube-A and Cube-B (based on PFCG security roles)
    3. Create a multiprovider on top of Cube-A and Cube-B
    4. Expose this mutliprovider for ad-hoc and other quries.
    But i am not sure about following things.
    1. Lets say A tries to access the report created on this multiprovider.
    2. As the multiprovider splits the query to Cube-A and Cube-B, will he gets authorization failed error on Cube-B? Or whether multiprovider just ignores data from Cube-B and shows only Cube-A data?
    3. Or, will it ignore the authorization at Cube-B and shows all the data?
    4. if this model works from authorization perspective, what are the drawbacks we have with this approach.
    Please let me know your thoughts on this design and also suggest if you have any other solution.
    regards
    Raghavendra

    Hi,
    If the user is restricted to an infoprovider in the role then it works perfectly with out any security leak.If the user tries to acess any other infoprovider then authorisation chk works and throws an error message "No authorisation".
    As we do not have control at the query designer level to restrict the user by an authorisation variable(considering adhoc queries) better to restrict the user with infoprovider restriction at role level.
    1. Lets say A tries to access the report created on this multiprovider.
    User A will be able to view the data from the infoprovider A only.
    2. As the multiprovider splits the query to Cube-A and Cube-B, will he gets authorization failed error on Cube-B? Or whether multiprovider just ignores data from Cube-B and shows only Cube-A data?
    Multiprovider does not know or able to differentiate A and B its just physical stucture formed by the combination of fields from infoprovider A and B. If the user tries to access the fields from Infoprovider B then he will get an authorisation error as he is not authorised to Cube B.
    3. Or, will it ignore the authorization at Cube-B and shows all the data?
    Authorisation check will happen as per the infoprovider restriction assigned to the user in the role so it does not show the other values.
    4. if this model works from authorization perspective, what are the drawbacks we have with this approach.
    The user should be well aware of the fields from A and B, if any of the filed is used for which he is not authorised then it gives an error.If the multiprovider has large number of objects then its slightly difficult for the user to remember the fields from which infoprovider to use and not to use.
    Also if u have logically split the data into two infoproviders then why do you need multiprovider ? Let A work on A and B on B. So no complexity of multiprovider.
    Let me know if i miss anything.
    Regards

  • Authorization check in LDB PNP

    Hi All,
    I am using logical database PNP in my report program and GET PERNR to fill the infotype tables. Infotype level authorization checks are performed but not Org data level (organizational assignments). The role assigned to me has access to data of specific personnel areas but I am able to retrieve data of all personnel areas (this was maintained in the authorization object P_ORGIN).
    I read the level of simplification should have a value 1 in the authorization object P_ABAP for Org Level authorizations to be performed. I have updated my role but still org level authorizations are not performed.
    Can you please let me know if  any special setting are to be done like in Tcode OOAC or set some flags/parameters in the report program to perform org data level authorization.
    Any information provided will be really helpful.
    Thanks,
    Pavan

    Hi,
    A separate ID was created in an environment similar to production and proper authorization were assigned to it (I mean roles with authorization objcts P_ABAP - level of simplfication 1 and P_ORGIN - restricting based on personnel area). Still Org level authorizations were not performed while using the LDB PNP. Is there anything I am missing?
    Thanks,
    Pavan

  • Authorization checks for PNP LDB

    question    : how to validate authorization checks for pnp logical database?
    2 nd question: hr report
    this report is basically for salary survey. in this i had so many fields can any body let me know how
    can i form the internal tables. and i have to display overall 150 fields in csv file for that
    how can i take in to the final internal table.
    what is the logic behind this:
    T71JPR09-JOBCODE
    PA0000-PERNR
    HRP1000-STEXT
    P0006-PSTLZ
    PA0008-ANSAL * 100 / PA0008-BSGRD
    PA0015-BETRG
    PA0761-LTEXT  WHERE PA0761-CPLAN = LTI PLAN PSU YEAR 1
    PA0761-GRADT  WHERE PA0761-CPLAN = LTI PLAN PSU YEAR 1
    PA0761-ZZGRANT WHERE PA0761-CPLAN = LTI PLAN PSU YEAR 1
    PA0761-LTEXT WHERE PA0761-CPLAN = LTI PLAN esu YEAR 1
    like that i had.
    please give me the steps how can i proceed.

    Hi,
    The PNP database will take care of authorization check. It will not execute if used does not have authorizations.
    Hope this helps.

  • SM30 Field level authorization check

    Hi,
    I have a requirement to add the authorization check in SM30 for the company field in the custom table. Please suggest.
    Thanks,
    Gagan Chodhry

    Hi,
    I have this requirement for both type of tables i.e. custom as well as standard. Tables has got field profit center.. I need to show the table based on the loggedin user authorization to the profit center.
    If it is a custom table then as mentioned by Siva, there is a way I heared that we can check the authorization in PAI event, but when I tried to do a small test, I could get the field symbol with the values, but I was not able to skip that record for disply.
    If anyone can send the sample or the way to skip the record based on the check.
    Also is there any other way to add the field level authorization to custom and standard tables...
    Thanks,
    Gagan Chodhry

  • Reading Locked records from HR table using LDB PNP

    Hi,
    I am trying to read the table pa0168 using LDB PNP.
    But the problem is that get pernr staement does not retrieve locked records i.e where PA0168-sprps eq "X'.
    Can anybody help me with this.
    I have to use LDB  so i don't want a solution of writing a select * for the pa0168 table.
    hence i have to use get pernr statement but it should also retrieve locked records.
    how can i achieve that.? please help
    Thanks
    GT
    Message was edited by: GT

    Hi GT,
    In the START-OF-SELECTION event, set the parameter value
    pnp-sw-ignorelockedrecords = 'N'.
    Good Luck,
    Suresh Datti
    ( Pl award points if the answer helps you )

  • Direct database data access without data level authorization check

    Hello,
    My customer raised issue about direct database data access. Due to the customeru2019s strong security policy, it shouldnu2019t be allowed.
    To prevent this kind of illegal data access, customer ask me to list up all the possibilities to display data without data level authorization check.
    The things in my mind are
    SQL Command Editor (for Oracle based system) : ORASPACE, DB02, ST04
    Query Based : SQVI (Quick Viewer), SQ01/SQ02/SQ03 (SAP Query)
    Data Browser : SE11, SE12, SE16, SE16N, SE17
    Table Maintenance : SM30
    Function Module : RFC_READ_TABLE
    Function Module : DB_EXECUTE_SQL (DML)
    Anyone knows anything which is not listed above?
    Thanks

    HI,
        Generally in production user's should not be given all these authorizations.
    Ram.

  • Coding ABAP using LDB PNP and authorizations problems

    This post requires a blend of ABAP and HCM skills.
    When coding my own ABAP using LDB PNP, the LDB will provide me with the employees selected but will skip those for which I do not have access (regarding Authorizations settings) to one or more of the infotypes declared in the program.
    As a programmer I would like to receive from the LDB the information that an employee is skipped so that I can handle the exception.
    Do you know how can I get this information from the LDB?
    Thanks

    I dont know if PNP can do it but PNPCE can:
    at END-OF-SELECTION call macro PNP_GET_AUTH_SKIPPED_PERNRS
    it will provide a list of skiped PERNRs
    for further info see docu PNPCE

  • Cost element group authorization check on controlling area level

    Hi!
    When maintaining cost element groups (KAH1, KAH2, KAH3) is it possible to run an authorization check on controlling area level?
    We have one global chart of account but several controlling areas. When we create a cost element group it is created at chart of account level for all the controlling areas. When someone changes a cost element group it changes in all controlling areas. I cannot restrict user's authorization to be able to change cost element groups only in their own controlling area.
    Is it possible somehow?
    Thanks for your help.

    Hi,
    Like how the global chart of accounts is at the client level, the cost element groups are also independent of the controlling areas.  Infact, the cost element groups are created at the global COA level. 
    In such a case, I don't think it is possible to restrict the authorizations to amend the cost element groups at controlling area level.
    Thanks and Regards,
    Bhuvaneswari.S

  • Record selection in IT0000 (Actions) using LDB PNP

    Hi Guys,
    I am writing a report using LDB PNP, where I need to EXCLUDE the employees, if an action has been done on IT0000 for the reporting start date and end date.
    Can anybody share the logic to do this using HR Macros or FM?
    Thanks,
    mini

    Hi miniSAP!
    I think this tip can help you.
    You can make your job at follow form:
    at "infotypes" declaration, use:
    INFOTYPES: 0000 MODE N.
    Inside "GET PERNR" event, you can get the informations using directly fm: HR_READ_INFOTYPE, because using "MODE N" at infotype declaration the standard system will not return any information about employee. In this form, you can make de filter of informations from fm HR_READ_INFOTYPE.
    Best regards!

  • Any option to restrict SE16 record level access based on company code?

    Hi All,
    I have a requirement to restrict record level access in SE16 based on company code.
    Our SAP system has two company codes. The requirement is that users of one company code should not be able to see records of other company code in SE16.
    Is it possible through some exits/badis/other methods?
    Thanks in advance.
    Regards,
    Arun Mohan

    You could write a small front end that accepts the company code, applies custom authorization code for each value and retains or removes, then calls the transaction and enters the selections the user requested and that your authorization check resulting in "passing"....  Of course, you'd have to block those users from "pure" SE16...   I once worked in situation similar, users in one country couldn't see USA data, etc. I think someone wrote an entire new program, called by ZSE16, for that.

  • Obsolete statements while using LDB PNP

    Hi,
    I am using LDB PNP, while extended program check it is showing  many obsolete statements like-
    tables : PERNR.
    infotypes
    RP_PROVIDE_FROM_LAST.
    What is the alternate to all these above statements.
    I searched the forum, but could not found anything. Please provide example.
    Thanks,

    That will bevary from system settings, In the standard reports, it will never give you the error/warning/informaton messages. But custom programs it will give as a absolete, But i can see many experts will use the these Macro's, We are doing world largest HR implemetation, Still we are using the same, Not a problem, you can avoid those messages.
    Only one way of avoiding is Using Provide statements.
    Regards,
    Mallikarjuna

  • Authorization check by Cost centers

    Hello all,
    I developed a report in Report Painter and the requirement is that the users be able to run it only for their own CCtrs - challenge is that we are trying to not use variants, custom transactions and also modifying / checking authorization at at SU01 level.
    Is there any other way to do this and if yes can you pls provide some details.
    Thanks,
    Richa

    hi richa,
    Authorizations with Variables
    Definition
    Instead of using a single value or interval, you can also use variables in authorizations. The Customer Exit is called up for these variables while the authorization check is running. The call is carried out with I_STEP = 0. The intervals of characteristic values or hierarchies for which the user is authorized can be returned here. By doing this, the maintenance load for authorizations and profiles can be reduced significantly.
    Every cost center manager should only be allowed to evaluate data for his/her cost center. Within the SAP authorization standard, a role or a profile with the authorization for the InfoObject 0COSTCENTER equal to ‘XXXX’ (XXXX stands for the particular cost center) would have to be made for every cost center manager X. This then has to be entered in the user master record for the cost center manager.
    Using variables reduces the authorization maintenance workload with the InfoObject 0COSTCENTER equal to ‘$VARCOST’, as well as with the role or the profile, which is maintained for all cost center managers. The value of the variable ‘VARCOST’ is then set for runtime during the authorization check by the CUSTOMER-EXIT ‘RSR00001’.
    Maintaining the authorizations restricts the entries for the values to the length of the existing InfoObject. It is possible, however, to use both limits of the interval. In the example 0COSTCENTER with 4 spaces, the variable ‘VARCOST’ is, therefore, entered as ‘$VAR’ – ‘COST’.
    There is a buffer for these variables. If this buffer is switched on, the customer exit is only called up once for a variable with the authorization check. In doing so, you avoid calling up the customer exit for variables over and over, as well as decreasing performance. If you want to call up the customer exit each time, you have to deactivate this buffer in the Setting Up Reporting Authorizations. To do this, go to the main menu and choose Extras  ® Compatibility  ® Buffer for Variables (Customer-Exit)  ® Deactivate..
    You can also call up the customer exit for authorizations for hierarchies. There are two ways to do this:
           1.      Enter the variable in the authorization for characteristic 0TCTAUTHH. The customer exit is then called up while the authorization check is running. In the LOW fields of the return table E_T_RANGE, the system anticipates the technical name for the hierarchy authorization that you specified in the authorization maintenance (transaction RSSM).
    As a result, all parameters are available for such an authorization. Nevertheless, you must also create a new definition for each node.                                    
           2.      Where many authorizations differ from an authorization for a hierarchy only in respect to the nodes and not to the other authorizations, we suggest the following solution: Different users can be authorized for a specific hierarchy area (subtree). The highest node is different for each user.                                          
    Do this by creating an authorization for a hierarchy in the transaction RSSM and enter this in the authorization or role. Instead of specifying a particular node, you specify the variable in the authorization maintenance (transaction RSSM). The customer exit is then called up for the node while the authorization check is running. The return table E_T_RANGE must be filled according to the customer exit documentation (nodes in the LOW field, InfoObject of the node in the HIGH field
    Setting Up Reporting Authorizations
    Use
    Before you are able to set up reporting authorizations, you have to create authorization objects.
    As soon as an authorization object is saved, it can be checked when a query is run. The user may not have the appropriate authorizations if he or she has not yet been assigned this authorization object.
    Only when the user has been assigned the appropriate authorizations can he/she define and execute a query or navigate in an existing query.
    If in the query a characteristic value or a node is excluded, a complete authorization check “*” is required.
    Procedure
    Creating an authorization object
           1.      In the SAP Easy Access initial screen of the SAP Business Information Warehouse, choose the path SAP Menu ® Business Explorer ® Authorizations ® Reporting Authorization Objects.
           2.      Choose Authorization Object ® Create. Give the authorization object a technical name and a regular name. Save your entries.
           3.      On the right-hand side of the screen, an overview of all the InfoObjects that are authorization-relevant is displayed.
    Only those characteristics that have been flagged as authorization-relevant previously in the InfoObject maintenance screen can be assigned as fields for an authorization object. See also: Creating InfoObjects: Characteristics
           4.      Assign the InfoObject fields to the authorization object:
    ¡        Select the characteristics for which you want an authorization check of the selection conditions to be carried out.
    ¡        Select the InfoObject key figure (1KYFNM) if you want to restrict the authorization to a single key figure.
    ¡        Select the InfoObject (0TCTAUTHH) if you want to check authorizations for a hierarchy.
    ¡        Include the authorization field activity (ACTVT) in the authorization object if you want to check authorizations for documents.
           5.      Save your entries.
           6.      Go back to the initial screen of the authorization maintenance.
           7.      Choose Check for InfoProviders ® Display to get a list of the InfoProviders that contain the InfoObjects that you selected and are therefore subject to an authorization check (where-used list). In the change mode you can exclude individual InfoProviders from the authorization check for this authorization object by removing the flag.
    Authorization object:           S_RSRSAREA
    Name:                   Sales area
    Fields:                         DIVISION, CUSTGROUP, 1KYFNM
    Creating authorizations
    Authorizations are created and maintained in the role maintenance screens.
           1.      Choose Authorizations ® Roles ® Change.
           2.      Specify the roles that you want to change and choose Change. This takes you to the role maintenance screen.
           3.      On the Authorizations tabstrip, choose the Expert mode for generating profiles option.
           4.      Choose the Enter Authorization Objects Manually option, and specify the objects that you require. Choose Enter. The authorization object is added to the role.
           5.      Choose Generate.
    For more information, see Changing and Assigning Roles.
    Result
    The user is now able to work with queries
    Authorizations to Work with a Query
    Use
    Authorizations to work with a query are first checked in the dialog box to open a query.
    Furthermore, when a query is opened, the authorizations for the individual objects are checked.
    See also: Authorization Check When Executing a Query..
    Structure
    Check in the Open Dialog Box:
    When you open a query, you will see four buttons in the dialog box. The History, Favorites and Roles buttons only display your own queries and those queries intended for you per role definition.
    The InfoAreas button enables you to look at all queries for which the user has display authorization. If this display authorization is not restricted to queries, the user will see all available queries in the system here. It is possible to hide the InfoAreas button if you do not want the user to see all queries in the system. The authorization object S_RS_FOLD with the field SUP_FOLDER can be used here. In order to hide the InfoArea button, set this field to X when authorizing, otherwise leave the field blank “ “ or set it to * (asterisk – all authorizations).. The button will be displayed if the authorization check fails.
    Authorizations by User
    It is also possible to make queries from particular users (= OWNER = query creator) available to other users (= USER) for display or processing. The authorization object S_RS_COMP1 with four fields (COMPID, COMPTYPE, OWNER, ACTVT) is used here.
    You can grant this authorization to a particular team or use the variable $USER to give all users the authorization for queries that they created themselves. $USER is replaced by the corresponding user name during the authorization check.
    See also the Example for Reporting Authorizations.
    Authorizations for the BEx Broadcaster
    Using the authorization object S_RS_BCS, you can determine which user is allowed to register broadcasting settings for execution and in which way.
    Note:
    ·        The only authorization necessary for the online execution of broadcasting settings is the authorization for the execution of the underlying reporting objects (for example, the Web template).
    ·        Every user that has authorization to create background jobs also has authorization for direct scheduling in the background.
    ·        If you need to work under the name of another user to execute broadcast settings (for example with user-specific precalculations), the authorization object S_BTCH_NAM for background scheduling is also required for the other user. For more information, see Authorizations for Background Processing and Definition of Users for Background Processing
    Authorizations for Selection Criteria
    Definition
    The selection criteria of a query determine which data can be displayed after you have entered it in a workbook.
    An authorization check for certain InfoObjects only takes place if an authorization object with this InfoObject was already created in the authorization object class Business Information Warehouse.
    As soon as an authorization object is created, only authorized users can select query data.
    Use
    To decide whether a user should be authorized to work with a query, you should check whether authorization has been given to him/her for all selection criteria.
    Essential to the authorization of selection criteria is the authorization object S_RS_ICUBE.
    Definitions of authorizations for working with certain InfoCubes must be transported separately.
    See: Transporting Additional Information
    In general, it is not sufficient to give authorizations for individual InfoObjects (characteristics and key figures), or to check them separately from one another. It more usual that specific authorizations should be given for combinations of characteristics and key figures.
    It is therefore feasible that a "Sales Manager" is allowed to view the respective total sales figures for all sales areas, but is only authorized to break down "his/her" area (0001) according to the individual sales personnel. In this case, the following authorizations, which are grouped together, would be created and assigned.
    Sales area = *
    Sales personnel = :
    Key figure = Sales figures
    (‘:’ represents the authorization to view the values aggregated with the characteristic.
    Sales area = 0001
    Sales personnel = *
    Key figure = Sales figures
    The user frequently uses these "multidimensional" authorities in companies that are regional as well as product-oriented (matrix organization). In this way, you could arrange for the person responsible for the combination of a certain division and a certain sales area to have the exact authorization for the output of the relevant values, without him/her necessarily also having access to the data for the whole division or the whole sales area.
    Authorizations for the Query Definition
    Authorizations can be granted for the following objects for the query definition in the Business Explorer:
    The entire query
    Structures
    Calculated key figures
    Restricted key figures
    Variables
    The activities for the query definition are specified in the authorization object S_RS_COMP (Business Explorer - components). The authorization object has the following fields: InfoArea, InfoCube, component type, component name and activity.
    The following values are possible for the component type:
    REP: Entire query
    STR: Structure
    CKF: Calculated key figure
    RKF: Restricted key figure
    VAR: Variables
    By specifying an InfoArea or an InfoCube, you can further restrict the component types. By specifying a component name, you can specify the authorization for individual components in more detail. Components that begin with 0 are delivered by SAP and cannot be changed. Components that are within the customer name range must begin with a letter of the alphabet.
    Valid activities are:
    01 (create)
    02 (change)
    03 (display)
    06 (delete)
    At the moment, activities 16 (Execute) and 22 (Save for Reuse) are not checked for the query definition.
    User A is allowed to create, change or delete queries beginning with A1 and A6 within InfoArea 0001 in InfoCube 0002. In addition, the user is allowed to change the calculated key figures and structures (templates) already defined in this InfoProvider.
    Related authorizations for user A:
    InfoArea: ‘0001’
    InfoProvider: ‘0002’
    Component type: ‘REP’
    Component Name: ‘A1’, ‘A6’
    Activity: ‘01’, ‘02’, ‘06’
    InfoArea: ‘*’
    InfoProvider: ‘0002*’
    Component type: ‘STR’, ‘CKF’
    Component name: ‘*’
    Activity: ‘02’
    Authorizations for Display Attributes
    Definition
    Authorization-relevant display attributes are hidden in the query if the user does not have sufficient authorization to view them.
    Use
    For characteristics:
    The user needs to have complete authorization (*) to see the display attribute in the query.
    For the characteristic 0EMPLOYEE, the 0EMPLSTATUS attribute is authorization-relevant. Only users with authorization "*" for 0EMPLSTATUS can display the attribute in the query.
    For key figures:
    Key figures cannot be marked as authorization-relevant. To use this function nonetheless for key figure attributes, the system checks against meta object 1KYFNM. For this, the user requires authorization for the field 1KYFNM in the authorization object.
    The key figure attribute 0ANSALARY is contained in the 0EMPLOYEE characteristic.
    If the user has the 1KYFNM field in his or her authorization object, and authorization "*", he or she can display all key figure attributes.
    If the user has the 1KYFNM field in the authorization object and the 0ANSALARY key figure as a value of the authorization, he or she can only see this key figure attribute. If the user is not supposed to see this attribute, do not give the authorization "*" but only assign the key figures for authorization that are to be displayed.
    Authorizations for Navigation Attributes
    Use
    During authorization checks for navigation attributes, it is always the characteristic that is being used as a navigation attribute that is checked.
    Integration
    If referencing characteristics are used as navigation attributes, authorization for the basic characteristic is checked. You should, however, change this logic so that the referencing characteristic is checked for instead. In the maintenance screen for reporting authorizations, choose the following path from the main menu Extras  ® Compatibility  ® Navigation Attributes ® Switch Off.
    This function exists for reasons of compatibility. The authorization logic of referencing characteristics worked differently with the beginning of Release BW 2.0. From BW 2.0, Support Package 20 and in all of the releases that follow, for referencing characteristics as well, the authorization for exactly this characteristic (and not the basic characteristic, as was the case previously) is checked.
    Example
    In the query, you use characteristic A with the navigation attributes A__B and A__R. Characteristic R references characteristic B. For these navigation attributes, authorization for the basic characteristic B is checked. If you switch off the compatibility for navigation attributes option, B is checked for A__B, and R is check for A__R.
    Maintaining Authorizations for Hierarchies
    Use
    Authorizations for hierarchies determine up to which subarea of a hierarchy a user may drilldown.
    Prerequisites
    Before you can set authorizations for hierarchies, you must first transfer and activate the InfoObject 0TCTAUTHH from the Business Content. Make sure that the indicator Relevant for Authorization is set. You must also create an authorization object for which you want to set the authorization.
    Authorization for a hierarchy on the Profit Center characteristic (0PROFIT_CTR):
    Define an authorization object with 0PROFIT_CTR and 0TCTAUTHH.
    Example: You define a hierarchy for the basic characteristic B. For characteristic B there is a referencing characteristic R. If you use this hierarchy for characteristic R in the query, authorization for the basic characteristic B is checked. However, you can change this logic so that characteristic R is checked for instead. In the maintenance screen for reporting authorizations, choose the following path from the main menu Extras ® Compatibility ® Ref. Characteristics with Hierarchy ® Switch Off.
    You need the characteristic 0TCTAUTHH to specify the hierarchy in the authorization. If you add this characteristic to an authorization object, you can specify authorizations for hierarchies for all InfoObjects in the authorization object.
    Procedure
           1.      In the SAP Easy Access initial screen of the SAP Business Information Warehouse, choose SAP Menu ® Business Explorer ®Reporting Authorization Objects.
           2.      Choose Authorizations ® Authorization Definition for Hierarchies ® Change.
           3.      In the Definition, select the InfoObject, hierarchy and node.
    If there are several users who are authorized to work with just one part of a hierarchy (subtree) but the top node is different for each, you have the option of specifying a variable instead of a node.
    See also: Variable Types
    Instead of selecting a node, you can also set the Top of hierarchy indicator. This enables you to ensure that a user is authorized to use a hierarchy from the top node down to a determined level.
    You can select the top node here. However, if the hierarchy is being used in a query without a filter on this node, the user will not be able to execute the query.
    This is because the top-most visible node does not represent the actual top of the hierarchy. As, for example, there are other Remaining Leaves, there should always be exactly one internal node at the top of the hierarchy. Therefore, there is one internal node above the top-most visible node. If the hierarchy is used in a query without the top-most node being determined, it is compared with this unseen, internal node. So that the user has the correct authorizations, select the internal top of the hierarchy for this option.
           4.      Select the authorization type:
    ¡        0 for the node
    ¡        1 for a subtree below the node
    ¡        2 for a subtree below the node up to and including a level (absolute)
    You must define a level for this type. A typical example of an absolute level is data protection with regard to the degree of detail of the data (works council ruling: no reports at employee level only at more summarized levels).
    ¡        3 for the entire hierarchy
    ¡        4 for a subtree below the node up to and including a level (relative)
    You must specify a level that is defined relative to the node for this type. It makes sense to specify a relative distance if an employee may only expand the hierarchy to a certain depth below his or her initial node, but this node moves to another level when the hierarchy is restructured.
           5.      For types 2 and 4 you can specify, in Hierarchy Level, the level to which the user can expand the hierarchy.
    ¡        With authorization type 2 (up to and including a level, absolute) the level refers to the absolute number of the level in the hierarchy where the top-most node of the hierarchy is level 1.
    ¡        With authorization type 4 (up to and including a level, relative) the level number refers to the number of levels starting from the selected node itself which is level 1.
           6.      In the Validity Area you specify in exactly which ways a hierarchy authorization has to match a selected display hierarchy for it to be included in the authorization check.
    ¡        Type 0 (very high) : The name, version and key date of the hierarchy on which the hierarchy authorization is based have to agree with the selected display hierarchy.
    ¡        Type 1: The name and version of the hierarchy on which the hierarchy authorization is based have to agree with the selected display hierarchy.
    ¡        Type 2: The name of the hierarchy on which the hierarchy authorization is based has to agree with the display hierarchy.
    ¡        Type 3 (lowest) : None of the characteristics have to match.
    Note that in some circumstances, setting a check level that is too low may lead to more nodes being selected using hierarchy node variables that are filled from authorizations, than actually exist in the display hierarchy for the query. This can cause an error message.
    As a general rule, select the highest possible level for the check.
           7.      If you set the Node variable default value indicator, this definition of an authorization for a hierarchy is used as the default value for node variables.
    If more than several authorizations are assigned to a user for different subareas of the same hierarchy, one of these authorizations has to be defined as the default value. Only one node can be selected for a node variable on the variable screen of a query. So that this variable can be filled from the authorizations, the correct variable type has to be selected and an authorization has to be determined as the default value.
           8.      Specify a technical name for this definition. If you do not enter a value, a unique ID is set.
           9.      Now create an authorization for the new authorization object. To do this, enter the technical name of the definition as a characteristic value for the characteristic 0TCTAUTHH. Hierarchy authorizations and authorizations for characteristic values are added:
    ¡        Specify the value ‘ ‘ (a blank character) as a characteristic value if only hierarchy authorizations are to be in effect. If you specify more values these are authorized additionally.
    ¡        Specify the value “:” (a colon) when queries are also allowed without this characteristic.
    The value '’ (all characteristic values) is not supported for the characteristic 0TCTAUTHH. Nevertheless, if you specify the value ‚’ a ‚:’ is automatically generated instead because no other valid value is found.
    If you would like the user to be able to see all values and hierarchies for a characteristic, use the value '*' for this characteristic.
    If you use a drilldown hierarchy in the query, you restrict the highest node by a fixed node or a node variable.
    Definitions of authorizations for hierarchies must be transported separately. See: Transporting Additional Information
    Alternative Procedure:
    Manually Maintaining Reporting Authorizations
    Use
    You usually maintain authorizations in the role maintenance. However, in exceptional cases it could be more practical to create authorizations manually. This is the case if you have to assign every user his/her own role.
    Prerequisites
    Reporting authorization objects have been created.
    Procedure
    Assign Authorization Objects
           1.      In the SAP Easy Access initial screen of the SAP Business Information Warehouse, choose SAP Menu ® Business Explorer ® Authorizations ® Reporting Authorization Objects.
           2.      Choose Authorizations ® Authorizations for Several Users. Enter an interval and choose Change.
           3.      Select a characteristic from the left side of the screen. You can then display master data as a list or as a hierarchy. The right side of the screen shows you a list of all the selected users with the authorization profiles and roles you assigned.
           4.      You can now use Drag&Drop to assign additional authorization objects to the user.
           5.      Choose Generate authorizations. The system creates the authorizations and assigns them to the users.
    Assigning Authorizations for Hierarchies
    You can also make authorizations for hierarchies in the same transaction.
           1.      Select a characteristic.
           2.      You can use the context menu on the authorization object to determine up to which hierarchy level the authorization should apply.
    You can currently select exactly 1 level for each hierarchy and user.
           3.      Choose Generate authorizations. The system creates the authorizations and assigns them to the user.
    Result
    The system has created individual authorization profiles.
    thanks
    karthik
    reward me ipoints if the above is usefull to you

Maybe you are looking for