Missing authorization check on the IM Reports

Hi,
We use RAIMINFO reports (S_ALR_87012805, S_ALR_87012806 u2026 ) to display
structure and values in Ferrero Spa investment program
On the initial screen, the value types which have to be output, are
determined by the authorization checks to be carried out .
For example in case that an user decides to display the plan or budget
references to program position, the user has to have the authorizations
on the Persons responsible (A_IMPR_VER). For us this is OK because we
define responsibilities through A_IMPR_VER. But if user decides to
display the appropriation request or measures and he doesnu2019t indicates
the program position it seems that anything on the A_IMPR_VER will be
performed. We need that the check on A_IMPR_VER will be performed always(for all objects: measures, appropriation request ).
We think this is a function missing in RAIMINFO and in all the IM
reports.
Could you help us to solve this problem?
Thanks and best regards,

Hi,
If you want use check box in crystal., then you can do this by writing piece of code.
please try for
If {Table.Field} = True Then
'Display the checkbox of your choice here
Formula = Chr(254).
thanks.
Bala

Similar Messages

Missing authorization check to display master data error..

Hi,
We are in SRM7.0.
After adding content in my shopping cart, I am trying to change the Account Assignment in the Item Details from Network to Cost Center or GL Account.
Under Item Overview, after changing the Account Assignment to Cost Center, I go to "Assign Number" to add a Cost center..On clicking the matchcode search box, I get selection entries like Cost Center, Controlling area etc..If I click on the Search box without keying anything, I get a "Missing authorization check to display master data error".
I get the same error, when I try to select Assets under Account Assignment area and use search under Assign number. I dont get any errors on searching networks.
Am we missing any authorization check in the backend ?
Regards,
Rajan.K

Hello Rajan,
You could use transaction ST01 in SRM to perform some 'authorisation' trace.
It might give you some pointers to the issue.
Regards,
Franz

HR strutural Authorization check in the Lean order Interface (LORD)

Hi ,
We place Quotations , Orders in CRM 7.0 , via the Lean order Interface Screen (LORD) . So users in ECC have HR structural authorization and they seems to the checked ( for the HR# part of the Sales Team , and comming accross as partner function in the Quotations , Orders documents )
Can we avoid the HR structural Authorization check in the Lean order Interface ?

Dear Christophe,
I do not understand the requirement...you create ERP orders via CRM interface, and you have set up authorization in ERP for the users. Why do you want to prevent the authority check when coming from CRM when it is needed ?
However please consider note 1446253 quesiton 9.
You might activate or deactivate the "current user" flag in sm59 for your ERP system.
Hope this information helps...
Regards
Rene

Add authorization checks to the table maintenance

i have created a table maintenance and I have authorization object and the field for it which will take some values this i got from basis people . Then how to add authorization checks to the table maintenance.

U can try to use the event, after generating table maintenance program:
Enviroment->Modification->Events: the events 05/18 could be good for you
Max

Authorization check - Lvel: Program/Tcode - report/SM30/odr

How do we identify if an authority check should be given
1) at the Program(Report) level or
2) at the T-code level itself?
Is there any other level we can do it?
For SM30s / tablemaintenances, how do we do it?
Suppose we have a T-code with SM30 for a table having fields including 'PLANT'. Now if we want to restrict the users to have access to specific plants, where should we put the check - in the Tcode?
say - usergrp1 - plant1
usergrp2- plant 2
etc.
How do we design this scenario?
How is authorization for report and others different?
Do we need to include S_TABU_CLI authorization object? what is its use?

> For SM30s / tablemaintenances, how do we do it?
>
> Suppose we have a T-code with SM30 for a table having fields including 'PLANT'. Now if we want to restrict the users to have access to specific plants, where should we put the check - in the Tcode?
> say - usergrp1 - plant1
> usergrp2- plant 2
> .
> .
> etc.
> How do we design this scenario?
This can only be achieved with a bespoke program in which authority-check statements are programmed at the right point. SM30 will not allow such granularity.
> Do we need to include S_TABU_CLI authorization object? what is its use?
This object is used to shield cross-client tables. Not needed here.

Where to Authorization check for the plant while creating outbound delivery

Hi Experts,
For outbound delivery , the standard program is not doing the authorization check .
Can i use BADI *LE_SHP_DELIVERY_PROC * and the method : DELIVERY_FINAL_CHECK
To write Authority-check statement ,
If the particular is not authorized for any of the plants of the items in the outbound delivery i will throw a error message
Can i use as above?
And if i use it has to apply only for outbound delivery?Because for inbound delivery also the same BADI is getting triggered?
Please suggest.
Regards
Ramakrishna L

Hi,
Yes you can use the said BAdi and the method if it is triggerd before the SAVE of the Outbound Delivery Order to do the Authorisation Check. In case the code is triggered for all the orders and you want only to restrict for the Outbound Delivery, then check for the Delivery Type (LFART) from the Delivery Header table for only the Outbound Delivery Order.
Thanks,
Susanth Swain

Authorization check to users in Report

Hi frds,
FI- Posting document created smart form
My customer is asking Document values greater than RS : 250000/- restrict to view some users ..........
How to acheive this requirement...........

Hi Kabil,
a third option to the suggestions Nabheet Madan mentioned is to look for a property to recognize the special users.
This might be a common role or authority, that no other users will own.
For checking roles you can access table AGR_USERS, for check checking special authorities you need a matching AUTHORITY-CHECK in your report.
Regards,
Klaus

Sap note doubt (105621 - Authorization check for the condition )

Hi experts,
I am wondering if this note takes effect also in Mm transactions.
Does anyone have experience with this?
Thanks!!
Artur.

Hi Artur,
I guess you should post in service market place instead SDN....
Arpan

Re: Setting Authorization Check in Report Writer

Hi,
In ABAP Query or ABAP customized program, it is possible to set authorization object checking.
In Report Writer, how can I do it?
<REMOVED BY MODERATOR - REQUEST OR OFFER POINTS ARE FORBIDDEN>
Thanks
Edited by: Alvaro Tejada Galindo on Dec 26, 2008 10:59 AM

Hi Colin,
I would like to suggest,
Creating an Authorization object & then using it in the report program is the preffered way.
I would like to suggest a couple of references, quite similar to your issue,
[SDN - Reference for using authorization checks at the report level|User authorisation check in ABAP-HR program;
[SAP HELP - Standard Reference for Programming Autorization checks|http://help.sap.com/saphelp_nw04/helpdata/en/52/6712ac439b11d1896f0000e8322d00/frameset.htm]
[SAP HELP - Standard Reference for Authorization checks|http://help.sap.com/saphelp_nw04s/helpdata/en/fc/eb3ba5358411d1829f0000e829fbfe/frameset.htm]
Hope that's usefull.
Good Luck & Regards.
Harsh Dave

Can we edit the System Report queries to add some missing fields ?

Hello,
I'm using SAP Business One 2005 A and I was wondering if there was a way to edit the system report queries. Sometime, I'm only missing calculated fields in the existing report. Something as easy as the difference between 2 dates is not working with the formula fields.
Instead of rewriting everything, could we simply see that original query and edit it to add the missing fields ?
I don't like the fact I can't add my own created report from a query in the main menu. Since I couldn't do anything with the Backorder reports by default, I created mine with my own SQL query. Can't I replace the existing one with my own ?
Thank you
Daniel Gagnon

Hi Daniel,
You can edit a system query but then you can only save it as a user query (ie you cannot overwrite the system queries).
User queries can't be placed in the Main Menu using the standard GUI though you could add them to the User Menu tab so your users can get to them easily. I think to add them to the Main Menu would require the development of an add-on that updated the Main Menu and triggered the running of the query when the user clicked on the menu option.
The other thing to look at is using XL Reporter for your reports rather than the Query Generator. With XL Reporter you can automatically add reports to the main menu.
Kind Regards,
Owen

How to check if the user has only the display authority of a message

hi,
How to check if the user has only the display authority of a message but does not have the change authority for a certain message?
Best regards,

hi blake
though i am an application consultant and for authorisation u need to have help of BASIS person if u r not the one but still i can guide u regarding the same,
Basically Authorization Management
Use
You can use the following authorization objects to control the authorizations for maintaining business partner data:
        Authorization objects for the Business Partner:
             B_BUPA_GRP
             B_BUPA_ATT
             B_BUPA_FDG
             B_BUPA_RLT
Authorization objects for relationships:
             B_BUPR_BZT
             B_BUPR_FDG
In addition, you can assign an authorization group to a business partner in the dialog. The authorization group controls which users may maintain data for this business partner.
You can also define authorizations for fields and field groups using the Business Data Toolset (BDT). Depending on the settings you have made, the system carries out the relevant authorization checks.
In the dialog in the SAP GUI, you can display an overview of the authorizations assigned to you by pressing the button Settings.
For more information on authorization management, see the Implementation Guide (IMG) of the Business Partner, as well as in the Developers Handbook for the BDT under Authorizations.
IntegrationAuthorization management for the Business Partner forms part of the SAP authorization concept.
Prerequisites
You have made the necessary settings in Customizing of the Business Partner under Basic Settings--> -Address Management.
Moving over
AS ABAP Authorization Concept
The ABAP authorization concept protects transactions, programs, and services in SAP systems from unauthorized access. On the basis of the authorization concept, the administrator assigns authorizations to the users that determine which actions a user can execute in the SAP system, after he or she has logged on to the system and authenticated himself or herself.
To access business objects or execute SAP transactions, a user requires corresponding authorizations, as business objects or transactions are protected by authorization objects. The authorizations represent instances of generic authorization objects and are defined depending on the activity and responsibilities of the employee. The authorizations are combined in an authorization profile that is associated with a role. The user administrators then assign the corresponding roles using the user master record, so that the user can use the appropriate transactions for his or her tasks.
Authorization Checks
To ensure that a user has the appropriate authorizations when he or she performs an action, users are subject to authorization checks.
The following actions are subject to authorization checks that are performed before the start of a program or table maintenance and which the SAP applications cannot avoid:
        Starting SAP transactions (authorization object S_TCODE)
        Starting reports (authorization object S_PROGRAM)
        Calling RFC function modules (authorization object S_RFC)
        Table maintenance with generic tools (S_TABU_DIS)
Checking at Program Level with AUTHORITY-CHECK
Applications use the ABAP statement AUTHORITY-CHECK, which is inserted in the source code of the program, to check whether users have the appropriate authorization and whether these authorizations are suitably defined; that is, whether the user administrator has assigned the values required for the fields by the programmer. In this way, you can also protect transactions that are called indirectly by other programs.
AUTHORITY-CHECK searches profiles specified in the user master record to see whether the user has authorization for the authorization object specified in the AUTHORITY-CHECK. If one of the authorizations found matches the required values, the check is successful.
Starting SAP Transactions
When a user starts a transaction, the system performs the following checks:
        The system checks in table TSTC whether the transaction code is valid and whether the system administrator has locked the transaction.
        The system then checks whether the user has authorization to start the transaction.
The SAP system performs the authorization checks every time a user starts a transaction from the menu or by entering a command. Indirectly called transactions are not included in this authorization check. For more complex transactions, which call other transactions, there are additional authorization checks.
             The authorization object S_TCODE (transaction start) contains the field TCD (transaction code). The user must have an authorization with a value for the selected transaction code.
             If an additional authorization is entered using transaction SE93 for the transaction to be started, the user also requires the suitable defined authorization object (TSTA, table TSTCA).
If you create a transaction in transaction SE93, you can assign an additional authorization to this transaction. This is useful, if you want to be able to protect a transaction with a separate authorization. If this is not the case, you should consider using other methods to protect the transaction (such as AUTHORITY-CHECK at program level).
        The system checks whether the transaction code is assigned an authorization object. If so, a check is made that the user has authorization for this authorization object.
The check is not performed in the following cases:
You have deactivated the check of the authorization objects for the transaction (with transaction SU24) using check indicators, that is, you have removed an authorization object entered using transaction SE93. You cannot deactivate the check for objects from the SAP NetWeaver and HR areas.
This can be useful, as a large number of authorization objects are often checked when transactions are executed, since the transaction calls other work areas in the background. In order for these checks to be executed successfully, the user in question must have the appropriate authorizations. This results in some users having more authorization than they strictly need. It also leads to an increased maintenance workload. You can therefore deactivate authorization checks of this type in a targeted manner using transaction SU24.
             You have globally deactivated authorization objects for all transactions with transaction SU24 or transaction SU25.
             So that the entries that you have made with transactions SU24 and SU25 become effective, you must set the profile parameter AUTH/NO_CHECK_IN_SOME_CASES to Y (using transaction RZ10).
All of the above checks must be successful so that the user can start the transaction. Otherwise, the transaction is not called and the system displays an appropriate message.
Starting Report Classes
You can perform additional authorization checks by assigning reports to authorization classes (using report RSCSAUTH). You can, for example, assign all PA* reports to an authorization class for PA (such as PAxxx). If a user wants to start a PA report, he or she requires the appropriate authorization to execute reports in this class.
We do not deliver any predefined report classes. You must decide yourself which reports you want to protect in this way. You can also enter the authorization classes for reports with the maintenance functions for report trees. This method provides a hierarchical approach for assigning authorizations for reports. You can, for example, assign an authorization class to a report node, meaning that all reports at this node automatically belong to this class. This means that you have a more transparent overview of the authorization classes to which the various reports are transported.
You must consider the following:
              After you have assigned reports to authorization classes or have changed assignments, you may have to adjust objects in your authorization concept (such as roles (activity groups), profiles, or user master records).
              There are certain system reports that you cannot assign to any authorization class. These include:
              RSRZLLG0
              STARTMEN (as of SAP R/3 4.0)
              Reports that are called using SUBMIT in a customer exit at logon (such as SUSR0001, ZXUSRU01).
              Authorization assignments for reports are overwritten during an upgrade. After an upgrade, you must therefore restore your customer-specific report authorizations.
Calling RFC Function Modules
When RFC function modules are called by an RFC client program or another system, an authorization check is performed for the authorization object S_RFC in the called system. This check uses the name of the function group to which the function module belongs. You can deactivate this check with parameter auth/rfc_authority_check.
Checking Assignment of Authorization Groups to Tables
You can also assign authorization groups to tables to avoid users accessing tables using general access tools (such as transaction SE16). A user requires not only authorization to execute the tool, but must also have authorization to be permitted to access tables with the relevant group assignments. For this case, we deliver tables with predefined assignments to authorization groups. The assignments are defined in table TDDAT; the checked authorization object is S_TABU_DIS.
You can assign a table to authorization group Z000. (Use transaction SM30 for table TDDAT) A user that wants to access this table must have authorization object S_TABU_DIS in his or her profile with the value Z000 in the field DICBERCLS (authorization group for ABAP Dictionary objects).
please See also:
        SAP Notes 7642, 20534, 23342, 33154, and 67766
guess this info will help you,there is one graphic which actually explain the hierarchy of authorisation,i will find some time out to let u know more info about the authorisation
but if u sit with ur BASIS guy then u can learn lot of things in PFCG
i guess u r a basis guy,then its not a problem
best regards
ashish

Authorization Check in BSP

Hi all,
Iam having a requirement that i need to perform the authorization check for the portal users.
ie, my report is based on the input companycode and customer number, So it should allow the user
to view the report only he has been authorized for that company code.
Can anyone help me out in this..
Thanks
Nehru.

There is no difference in how you perform an authorisation check in BSP to any other ABAP application.
Just use the ABAP AUTHORITY-CHECK OBJECT syntax as usual.
Cheers
Graham Robbo

Authorization Checks in Z programs

Dear Experts,
Fist of all, thanks for your time. We're being asked to review each Functional Specification in the company to suggest to the developement team the standard objects that should be included in the code in order to restrict the access within each developement. My understanding was that, as an standard practice, developers only use bapis, standard functions or call transactions in their code, for which we should be covered, as SAP includes standard object checks in them (so when using a bapi associated to VA01, the objects in the code for VA01 are being checked). The exception for this are reports, for which we have a Z object with most of the Organizational Values like Company Code, Plant, etc to allow restrictions to take place (and developers are supposed to include this check in this code).
My first question is: is it true that bapis, standard functions and call transactions use the regular standard objects when being executed?.
If this is the case, is there any point in suggesting the objects to be checked to the developers?. It looks as if this would be redundant, as SAP is making sure they're being checked when bapis, standard functions and call transactions are executed...(exception made for reports, as mentioned)
Thanks a lot for your help!!
Best regards,
CMPT

Hi,
It is always a good idea for the Z transaction review to be performed by the Security consultant. After all it will be his responsibility later on to restrict access to the transaction. You can always ask for the functional consultant's help with understanding the use of the transaction
In case the custom transaction has been created similar to or is an enhancement on a standard SAP transaction, then it is always a good idea to have at least the same authorization checks for the Z txn also.
For new developments you need to ensure that the authorization checks need to be implemented based on the functionality of the txn and the data it manipulates. For eg., if you have a Z-txn to make changes to purchase orders, you need to ensure that the program checks for change activity for Purchasing Org, Purchasing Group and Plant values and any other authorization relevant data.
The auth objects to be used depends entirely on the data and the functional module the custom program belongs to. I generally prefer to use SAP standard objects where possible. Else create new auth objects as per requirement.
Regards,
Sanju

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

Display Subreport Totals in the Main Report

I am using CF10 Report Builder. I have a main report that show counts/amounts by award type for admitted and deposited students. I have a sub report that shows counts/amounts by award type and level for current students who have registered and those who have not yet registered. I need to show the totals of current students by level and weather they have registered or not.
I tried adding a sub report to show the totals but the sub report does not show up on the main report. Is there a way to do this that I am missing?

I created the sub-report because the award information is kept in separate
tables for incoming and returning students. I will work on combining the
the two.
Thanks
Bonni
Bonni Harris
Database Analyst
Eureka College
300 E. College Avenue
Eureka, IL 61530-1500
309-467-6467
On Tue, Apr 28, 2015 at 12:25 PM, EddieLotter <[email protected]>

Missing authorization check on the IM Reports

Similar Messages

Maybe you are looking for