Transaction VASK authorization check on warehouse

Hello all,
Does anyone know why there is no authorization check on the warehouse in transaction code VASK? I have an issue where users from different warehouses are deleting groups created in other warehouses. I wanted to know if anoyone else has run into this issue as well. My solution is to create a custom transaction for VASK and add the warehouse check as well as a selection value. Does anyone else have a better soultion?
Thank you,
Steve

I am going to create a new t-code and add the authorization check.

Similar Messages

Transaction code to check warehouse stock with storage section combination

Hello Gentalemen,
Is there any transaction code to check the warehouse stock with combination of storage section in Warehouse Management?
Please let me know.
Thanks

You can use LX02 or LX03. In the tool bar click the third button which will give you the dynamic inputs from LDB(click the storage bin drop down and click on storage section). You can provide the storage section there.
Kesav

CRM - Process Flow of Authorization Check in Business Transactions

Hello Folks:
I have implemented CRM security using Process Flow of Authorization Check in Business Transactions.
What I have in place:
CRM_ORD_OP (inactive, don't want access to own documents)
CRM_ORD_LP (inactive, not using standard org level values Distribution Channel, Sales Group, Sales Office, Sales Organization, and Service Organization.)
CRM_ACT (active)
CRM_CMP (active)
CRM_ORD_OE (active, restricted to display with dummy value ' ' for Distribution Channel
Sales Group, Sales Office, Sales Organization and Service Organization, as we are not restricting on them)
CRM_ORD_PR (active and restricted to display)
Issue:
Restrictions to display for documents works fine when using CRM backend system and the system throws out a message that you are not authorized to change. But, when i come in through Portals (PCUI), i dont get the display at all and it throws out a message insufficient access authorizations.
Traces on backend CRM reveal failing on change access for CRM_ORD_LP and CRM_ORD_PR, which we dont want to give out b/c we dont want to provide change for documents.
OSS notes to SAP have resulted in no results....please advise what is wrong here.
Thanks
KT

Thanks for the Priyanka for the reply, but what you mention is not correct.
BSP errors are different from what I am refering to.
The issue is still open...and looks like a SAP bug, which even they havent been able to fix so far.
Regards,
KT

Authorization Check in Business Transactions

Hi All,
i need to create Authorization Check for Business Transactions ( create/display/change ).
The standart sap Authorization object CRM_ORD_OP or CRM_ORD_LP is no good for me .
does anyone know a BADI or something else i can use ?
Thanks
Lilach.

I would suggest to give the authorization with CRM_ORD_OE if he isn' t in the document may be he is the organization which is selected on the activity..
For details, please have a look at this link :
http://help.sap.com/saphelp_crm70/helpdata/EN/48/a44236ceb873e8e10000000a42189b/content.htm
BR,
Cenk Sezgin

Authorization Check in Business Transactions in CRM 2007

Hi everybody, I have a problem whit the authorization check in CRM 2007.
This link help me to follow the steps
http://help.sap.com/saphelp_crm60/helpdata/en/e9/b29a39e7aee372e10000000a11
I follow this steps:
1.- Created a new single role on the PFCG
2.- On the Menu tab add the transaction BSP_CRMD_BUS2000108 (Trax for LEADS)
3.- On the authorization tab create a new profile and in the authorization data set the values for CRM_ORD_OP: PARTN_FCT 00000012, PARTN_FCTT *, ACTVT '02,03
4.- Generate the authorization.
5.- Set my user "TESTUSER" on the user tab
6.- Save the profile
Then, I login to CRM whit TESTUSER and I see all the leads. I miss something, what could be the problem ?
Thanks for your help

Hi Shaji, Pankaj and Jushan, thanks four your answers.
I still have the same problem, I want to see only my leads that I´am the responsible, after I generated the authorization and assign the role to my user from tcode PFCG and SU01, I logout and login again and no changes, I still see all the leads.
Another test I made, I changed the authorization data and set the values for CRM_ORD_OP: PARTN_FCT , PARTN_FCTT 0008, ACTVT ' (person responsible) and the results was the same, see all the leads.
How works the User Comparisons and how can I check for errors in my pfcg role ?
Thanks for your help.

Disabling authorizations checks for transactions SU53 and/or SU56.

Greetings.
I seem to remember reading that there was either a system profile parameter or a table entry that can be used to disable all authorizations checks for transactions SU53 and/or SU56.
Any truth in this or is my mind playing tricks on me?

Hi,
I guess theres is profile param auth/tcodes_not_checked(I guess thats right), this will exclude SU53/SU56 from checks on transaction code.
This can be done using RZ10 and need to restart the system.
Rakesh

Forcing Authorization for a transaction code without authorization check in

Transaction code 'PP02' has an authorization object P_TCODE. So when a user who does not have authorization to transaction 'PP02' tries to execute it from command prompt, the SAP system appropriately restricts user saying "You have no authorization".
However, If Ia program has "Call transaction" verb calling this transaction and if the restricted user runs this report or module program, it does not restrict the user to access the transaction.
Is there any way to restrict user to access the transaction from program without explicitly doing authorization check from within the program?
Jitendra Mehta

Hi Florin:
S_TCODE restricts the user only at command prompt level, not if you run the transaction for program using "CALL TRANSACTION" verb.
If we assign auth.object P_TCODE with some other transaction values (not one for which we want to restrict), then the authority check works for the above.
But say, if I have no other transaction code values to be assigned to auth. object P_TCODE for the restricted user ( therefore, obviously I don't assign auth. object P_TCODE to any auth. profile for the restricted user) then again, I am out of luck.
The only way, I have seen this working is to assign value space ( ' ' ) to auth. object P_TCODE and then assign this auth.object to one of the auth. profiles of the restricted user, BINGO!, then it works.
But our Authorization team has an objection saying "We assign the transactions ( to auth. object ) which the user should have access. It is not proper to assign a no value to auth. object ( assigning space value ) "
I do not know how much merit their argument has, however, I was wondering if there is another way I could achieve it without relying on tens of hundred of programs doing auth. checks whenever they call the restricted transaction.
Please let me know your thoughts.
Thanks.
Jitendra Mehta

Invoking HR Master Data (P_ORGIN) authorization check for transaction PCP0

Hello,
We have to limit access to executives (managers) sensitive posting data in transaction PCP0 (display posting runs).
Since executives belong to a personnel area other than all other employees, I thought we can achieve this by personnel area distinction.
In order to have this done, P_ORGIN authorization check should be performed.
It looks that by standard, such check is not performed.
Does anyone have any experience of dealing with this issue?
Thanks,
Isaac

Hi,
I have a vague idea.
I remember while creating an ESS user, we did something in P_ORGIN so as to to restrict access to personnel master data.
Check the composite role : SAP_EMPLOYEE_ERP.
A Z role was created for SAP_EMPLOYEE_ERP=>the corresponding roles in it had to be copied to a z role.
Check the z-role created ; zSAP_ESSUSER_ERP.
In Authorizations tab=>Display authorization data option => ;
Expand Human Resources;
In HR : Master data, you can find the various authorization assignments to P_ORIGIN; where
Authorization level (AUTHC)
Infotype (INFTY)
Personnel Area (PERSA)
Employee Group (PERSG)
Employee Subgroup (PERSK)
Subtype (SUBTY)
Organizational Key (VDSK1)
Authorization level (AUTHC) takes the values :
R (Read) for read access
M (Matchcode) for read access to input helps (F4)
W (Write) for write access
E and D (Enqueue and Dequeue) for write access using the Asymmetrical Double Verification Principle. E allows the user to create and change locked data records and D allows the user to change lock indicators.
S (Symmetric) for write access using the Symmetric Double Verification Principle
* always includes all other authorization levels simultaneously
In your case if some has to make changes through PPCO.. it's equivalent to making changes to infotype 0001 (Organizational Assignment)
So, probably, you need the Authorization level to R for Infotype 0001.
I have no personal hands-on experience on this...since we are not allowed to anything Basis
I have seen this being done and have noted what was done... !! May or may not be correct....!!
I hope this is what you want.
Cheers and Good Luck!!
Remi

Authorization check when searching for transactions

Hi all,
We have a requirement to show only those activities for which a user is authorized. A custom authorization object has been maintained and the check in CRMD_ORDER has been extended accordingly. When opening an activity, the check is executed correctly, but when searching for activities, ALL activities are still shown, so the check is not performed at that particular moment. I have tested with standard authorization objects as well, but none of them are taken into account. Does anyone of you know how we can have the authorization check executed before or during the search, so that only those activities are shown, that the user may maintain as well.
Thanks in advance!
Regards,
Joost

Hello Joost,
Check if BADI CRM_ORDER_INDEX_BADI could not map your requirement.
Regards,
Frédéric

Kanban authorization checks (SU24, PK13N, PK*)

Hi,
Does anyone know why the Kanban transactions (PK*) have mostly disabled authorization check indicators in SU24?
In PK13N, for example, there is functionality to do a goods receipt (MIGO GR) and also functionality to create POs (and maybe more that I have not looked into yet).
However, the related auth objects in SU24 are not enabled (check indicator = do not check). This seems strange for these authorization objects.
Especially in light of SoD. Users could create POs or do Goods Receipt via PK13 without proper auth check and these 2 functions conflict already (using default GRC ruleset).
But that's beside the point. The question is: Is there a good reason why these are disabled and how is this NOT a secuty risk?
Now, there is one object that is enabled: C_KANBAN
But, I feel that this is insufficient to really secure the goods receipt action and the PO creation action.
For reference, a list of disabled auth objects:
C_STUE_WRK CS BOM Plant (Plant Assignments)
C_TCLS_MNT Authorization for Characteristics of Org. Area
F_BKPF_KOA Accounting Document: Authorization for Account Types
F_FICA_CTR Funds Management Funds Center
F_FICA_FTR Funds Management FM Account Assignment
F_FICB_FKR Cash Budget Management/Funds Management FM Area
F_FICB_FPS Cash Budget Management/Funds Management Commitment Item
F_LFA1_APP Vendor: Application Authorization
F_SKA1_BUK G/L Account: Authorization for Company Codes
L_BWLVS Movement Type in the Warehouse Management System
L_LGNUM Warehouse Number / Storage Type
M_BANF_BSA Document Type in Purchase Requisition
M_BANF_EKG Purchasing Group in Purchase Requisition
M_BANF_EKO Purchasing Organization in Purchase Requisition
M_BANF_WRK Plant in Purchase Requisition
M_BEST_BSA Document Type in Purchase Order
M_BEST_EKG Purchasing Group in Purchase Order
M_BEST_EKO Purchasing Organization in Purchase Order
M_BEST_WRK Plant in Purchase Order
M_LPET_EKO Purchasing Org. in Scheduling Agreement Delivery Schedule
M_MRES_BWA Reservations: Movement Type
M_MRES_WWA Reservations: Plant
M_MSEG_BWA Goods Movements: Movement Type
M_MSEG_BWE Goods Receipt for Purchase Order: Movement Type
M_MSEG_BWF Goods Receipt for Production Order: Movement Type
M_MSEG_LGO Goods Movements: Storage Location
M_MSEG_WMB Material Documents: Plant
M_MSEG_WWA Goods Movements: Plant
M_MSEG_WWE Goods Receipt for Purchase Order: Plant
M_MSEG_WWF Goods Receipt for Production Order: Plant
M_RAHM_BSA Document Type in Outline Agreement
M_RAHM_EKG Purchasing Group in Outline Agreement
M_RAHM_EKO Purchasing Organization in Outline Agreement

Hi Steven
Normally, when I submit OSS messages about security gaps the response is "working as designed", so I thought I'd try SCN first... perhaps it REALLY IS working as designed and there is a good reason why no auth checks should happen in this case.
Unfortunately this is all too common. However, I have found a lot of the times it is a Level 1 Support person in SMP advising you of this. With perseverance and escalation to a the next level the chance of a fix is greater (still not a guarantee)
It's a pity if working as per design they could explain why.
MIGO can be used in display mode only. If PK13 and PK13N are meant to be display transaction and the SU24 allows you to perform change (i.e. none of the underlying auths are checked for change) then I would refuse to close the customer incident until SAP responds further. At the end of the day, if a display transaction allows modification then it isn't a display transaction
I get the impression SU24 and some other security (e.g. authority check on '' instead of dummy) has been allowed to exist as customers give up and change the values themselves instead of getting SAP to fix their solution.
You could also look at SE97 if call transaction can be switched to yes so users cannot jump from PK13N to MIGO (assuming the code was a CALL TRANSACTION)
Regards
Colleen
P.s. - understand the comment with stale thread but take note of timezone and if you raise it on a Friday people may not see it until the following week. Although you did consider this, a lot of people on SCN put urgent in their question and then within the same day respond to their thread to "bump it" on the list

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

Authorization related with warehouses

Hi experts,
I want to make authorization related with warehouses. Only particular users can do material transfer (by MIGO - movement type 311) in a paticular warehouse. How can I do?

You'd have to use the authorization object M_MSEG_LGO.
You'd have to make the following ACTVT=XX;WERKS=PLNT; LGORT=SLOC; BWART=311;
PLNT is your plant
SLOC is the storage location.
XX = 03 (display only) or
Use SU21 to view the object (use find button) and double click to display documenation (or) ask your BASIS administrator.
Before you can implement the authorization object you need to activate authorization check at storage location level in transaction S_ALR_87000261 else M_MSEG_LGO won't work. You also need to understand the consequence of this is that it will hog the system performance which is why authorization check is inactive by default.
Edited by: Jeevan Sagar on Jan 18, 2012 12:53 PM

Authorization check based on item category on sales order (VA01 or VA02)

I want to be able to restrict authorization of users based on item category. We only want certain users to be able to select a certain item category. I know I'm going to have to check one of the userexits in MV45AFZZ. The issue I'm having is the authorization object .
The item category is field VBAP-PSTYV.
What we are going is having a item category for emergency orders. But this requires more manual steps to associate with the original order. We already have the emergency item categories defined and working (no credit check etc) so there's no reason not to have them added to the original order. The issue is its use has to be restricted so when the user selects an alternative item category it checks whether they have the authority.
Any help would be appreciated

Hi,
You can achieve this through authorization objects.
Transaction
SU20 - Authorization Fields
SU21 - Authorization Objects
Create the field PSTYV in the Authorization Fields.
Then Create the authorization object and include this field along with the standard field ACTVT (which determines what activities can be performed by a certain user i.e. Create, Change or Display) & user-name
In your your-exit, you can either use the ABAP command AUTHORITY-CHECK or the function-module AUTHORITY_CHECK and pass the values for these fields. The system can perform the test based on this values & based on the sy-subrc value you can restrict the users that are not having the authorization to select item-categories for emergency orders.
Following link should help you:
[SAP Authorization Concept|http://help.sap.com/saphelp_wp/helpdata/en/52/671285439b11d1896f0000e8322d00/content.htm]
Hope that helps you.
Regards,
Saurabh

HR ABAP Custom Authorization Check

Hi all,
We know that Implicit authorization check is carried out. The system determines whether the user has the authorizations required for the organizational features of the employees selected with
GET PERNR.
I have a question, if we create a custom authorization then, whether this custom authorization is checked or not.
Thanks in Advance.

There is no difference in the coding of the check, which as RJ has stated needs to be somewhere at the correct coding location... otherwise it is going no where.
Some special differences are:
- The object class of the custom object in SU21 => Authorization objects in HR cannot be deactived context specifically in SU24. You can create custom objects within SAP classes.
- Depending on the transport type of your system, you will have to maintain transaction SU24 with a check indicator for the object - so make in known that the transaction has the capability to check the object. This does not affect "customer" systems, but is still a very good practice for the same reason that SAP forces it in their own development systems.
- Additional object checks in SE93 (which are typically "plausibility" checks) are not subject to this restraint. The check is always there, and your ability to bypass it is limited if you check the tcode authority of the caller at initialization of the (called) coding context. CALL TRANSACTION will skip this check, unless the called transaction is sy-tcode already (as it is in variant transactions... which urban legends claim to be secured to use for CALL TRANSACTION).
This concept is to a large extent influenced by SAP's own development guidelines and "settings" - but it is advisable to understand them and the intended authorization concept - to be able to create consistent customer implementations of SAP products.
Of course there are exceptions to the rules... but they generally cause problems and sooner or later need to be corrected as well when the auditors get hold of them....
Cheers,
Julius
Edited by: Julius Bussche on Apr 27, 2009 9:03 PM

Authorization check

Hi ,
i new to authorization so i need help ,
i go to transaction SU21 and i choose some object for example:
Object R_CPM_BSC
Text Authorization Object SEM: BSC Elements
Class SEM Strategic Enterprise Management*
Author STASTNY
Field name Heading
SEMSCARD Scorecard
SEMOBJTYPE Scorecard Elements: Object Type
SEMOBJKEY Scorecard Elements: Object Key
ACTVT Activity
And when i push on permitted activities i get:
R_CPM_BSC Authorization Object SE
ACTVT Activity
activists
01 Create or generate
02 Change
03 Display
04 Print, edit messages
1. i have always just permitted activities for ACTVT ?
if i wont that user just have display Authorization how i have to write it like below?
AUTHORITY-CHECK OBJECT R_CPM_BSC
ID ACTVT FIELD '03'
thats it i don't use the other fields?
Regards

Hi,
In general different users will be given different authorizations based on their role in the orgn.
We create ROLES and assign the Authorization and TCODES for that role, so only that user can have access to those T Codes.
USe SUIM and SU21 T codes for this.
Much of the data in an R/3 system has to be protected so that unauthorized users cannot access it. Therefore the appropriate authorization is required before a user can carry out certain actions in the system. When you log on to the R/3 system, the system checks in the user master record to see which transactions you are authorized to use. An authorization check is implemented for every sensitive transaction.
If you wish to protect a transaction that you have programmed yourself, then you must implement an authorization check.
This means you have to allocate an authorization object in the definition of the transaction.
For example:
program an AUTHORITY-CHECK.
AUTHORITY-CHECK OBJECT <authorization object>
ID <authority field 1> FIELD <field value 1>.
ID <authority field 2> FIELD <field value 2>.
ID <authority-field n> FIELD <field value n>.
The OBJECT parameter specifies the authorization object.
The ID parameter specifies an authorization field (in the authorization object).
The FIELD parameter specifies a value for the authorization field.
The authorization object and its fields have to be suitable for the transaction. In most cases you will be able to use the existing authorization objects to protect your data. But new developments may require that you define new authorization objects and fields.
http://help.sap.com/saphelp_nw04s/helpdata/en/52/67167f439b11d1896f0000e8322d00/content.htm
To ensure that a user has the appropriate authorizations when he or she performs an action, users are subject to authorization checks.
Authorization : An authorization enables you to perform a particular activity in the SAP System, based on a set of authorization object field values.
You program the authorization check using the ABAP statement AUTHORITY-CHECK.
AUTHORITY-CHECK OBJECT 'S_TRVL_BKS'
ID 'ACTVT' FIELD '02'
ID 'CUSTTYPE' FIELD 'B'.
IF SY-SUBRC 0.
MESSAGE E...
ENDIF.
'S_TRVL_BKS' is a auth. object
ID 'ACTVT' FIELD '02' in place 2 you can put 1,2, 3 for change create or display.
The AUTHORITY-CHECK checks whether a user has the appropriate authorization to execute a particular activity.
This Authorization concept is somewhat linked with BASIS people.
As a developer you may not have access to access to SU21 Transaction where you have to define, authorizations, Objects and for nthat object you assign fields and values. Another Tcode is PFCG where you can assign these authrization objects and TCodes for a profile and that profile in turn attached to a particular user.
Take the help of the basis Guy and create and use.
Thanks
Vikranth

Transaction VASK authorization check on warehouse

Similar Messages

Maybe you are looking for