Hierarchy
BBPCRM (Software Component) BBPCRM⤷
CRM-MD-BP (Application Component) Business Partners⤷
FB0C (Package) Financial Accounting customers
IMG Activity
| ID | SIMG_CFMENUORFBOBZ9 | Authorization Objects |
| Transaction Code | S_ALR_87003400 | IMG Activity: SIMG_CFMENUORFBOBZ9 |
| Created on | 19981222 | |
| Customizing Attributes | SIMG_CFMENUORFBOBZ9 | Maintain Authorizations |
| Customizing Activity | SIMG_CFMENUORFBOBZ9 | Maintain Authorizations |
Document
| Document Class | SIMG | Hypertext: Object Class - Class to which a document belongs. |
| Document Name | SIMG_CFMENUORFBOBZ9 |
You define an authorization by listing the operational objects allowed (for example, company code or business area) and the editing functions allowed (for example, create, change, delete) for a standard authorization object. You can always define several authorizations for each authorization object.
For each authorization object, you can assign authorizations on one or more independent levels. This restricts access to documents depending on, for example, the company code, business area, document type, account type and account. There is an authorization object for each level which determines how you enter the corresponding authorizations.
An example of an authorization object is "Accounting document: Company code authorization". With this standard authorization object, two specifications are required to assign authorization:
- A list of the company codes where documents can be processed
- A list of the activities permitted for document processing in the above-mentioned company codes.
The possible activities are defined in the system. You can find the activities and their keys for each authorization object in the TACTZ table.
Most authorization objects have a similar structure, that is, two specifications are necessary for each object. The first specification lists values for a field in the object to be protected (company code for example) and the second lists a series of activities. Via this combination, you can differentiate the permitted activities distinctly. For example, you can restrict the creation and changing of documents to one company code, but permit the display of documents in other company codes.
Defining authorizations
The assignment of authorizations is divided into three groups:
- General authorizations, with which you specify the functions that an employee may carry out. In this authorization, you can specify that an employee cannot change the system configuration, for example.
- Organizational authorizations, on the level of the organizational units with which you specify the activities that are permitted in the organization units. These authorizations can be seen as a restriction of the general authorizations. If an employee can post documents, for example, you can specify the company codes or business areas where this is possible via these authorizations.
- Functional authorizations, with which you can restrict activities to certain account types, accounts or master records. These authorizations can be seen as a restriction of the general authorizations. If an employee can post documents, for example, you can specify the document types or accounts where this is permitted via these authorizations.
You can assign general authorizations for the individual functions defined in the standard system.
You can assign organizational authorizations for:
- Company codes
- Business areas
You can assign functional authorizations, for example, for the account type, the document type or the customer, vendor or G/L account.
Checking the general authorization
If you want to prevent an employee from carrying out certain functions, you can do this by assigning a general authorization. The system checks this authorization when the employee selects a function and prevents him or her from carrying out the function if no corresponding authorization exists.
Example: The authorization object "Accounting document: Company code authorization" has been assigned to the function for posting documents. When you select this function, the system checks whether you have authorization to post documents (activity 01) in at least one company code. Posting is only permitted to employees who are allowed to post in at least one company code.
With the organizational and functional authorizations, you further limit this general authorization.
Checking the organizational and functional authorizations
When an employee attempts to carry out an activity, the system checks whether he or she
- Is permitted to carry out the activity for the specified organizational units (company code and business area)
- Has the required functional authorizations.
These authorization checks are always carried out after a user makes an entry. If all authorization checks were passed successfully, the next activity can be carried out. Otherwise, the system rejects further processing.
Note
You can protect customer and vendor master record fields from being changed using the "Customer: Change authorization for certain fields" and "Vendor: Change authorization for certain fields" authorization objects. You can read about which requirements have to be fulfilled for this in the chapters on the topic Prepare to change customer master records and Prepare to change vendor master records.
When assigning authorizations for one-time accounts, you should note that master data is entered during document entry with the one-time account method. If you want to limit the processing of master data using the assignment of authorizations, you must take this into consideration.
Authorization objects in Financial Accounting
The Financial Accounting component contains predefined authorization objects. These are described in the following. You define authorizations for these objects by entering the required values in the fields for the objects. If you do not want any restrictions, you can enter * in the corresponding field.
Caution: Authorization groups are contained in certain authorization objects. These objects have been defined to protect individual master records, accounts or document types. If you do not require this special protection, you need not define any authorizations for these objects. By omitting these authorizations, the processing options of your employees are not restricted. For all other authorization objects, you must assign authorizations to enable processing with the objects.
Authorization objects
For customer master data:
F_KNA1_APP application authorization
F_KNA1_BED account authorization
F_KNA1_AEN change authorization for certain fields
For vendor master data:
F_LFA1_APP application authorization
F_LFA1_BEK account authorization
F_LFA1_AEN change authorization for certain fields
For G/L account master data:
F_SKA1_BES account authorization
For banks:
F_BNKA_MAN general maintenance authorization
Note You can create, display and change bank master records with a specific function or from the maintenance screen for customer or vendor master records. Therefore, you should also give authorization for bank master records to the employees who maintain customer and vendor master records.
For credit management:
F_KNKA_KKB credit control area
F_KNKA_MAN general maintenance authorization
F_KNKA_AEN change authorization for certain fields
For account analysis for customers:
Using the account analysis, you can gain an overview of: the total open items, the statements and interest, the credit limit and the payment history.
For accounting document:
F_BKPF_VW default values for changing document type and posting keys
You can protect the user activities that affect accounting documents from different viewpoints. On the one hand, you can specify the organizational units (such as company code, business area) in which an employee may post or display a document. On the other hand, you can define authorization for posting and processing documents from the point of view of the accounts.
You should note the following special features of authorization objects for accounting documents:
- With automatic postings, the system does not carry out an authorization check for business areas and accounts. Therefore, these authorizatons only take effect with manually-entered line items.
- Authorizations for document types and business areas are not taken into consideration for display functions and for reporting. That is, line items are always displayed in lists for all document types and for all business areas.
- Line items for which an employee has no authorization are suppressed when displaying and changing documents. The system indicates the missing authorization with a mes
Business Attributes
| ASAP Roadmap ID | 209 | Establish Authorization Management |
| Mandatory / Optional | 2 | Optional activity |
| Critical / Non-Critical | 2 | Non-critical |
| Country-Dependency | A | Valid for all countries |
Assigned Application Components
| Documentation Object Class | Documentation Object Name | Current line number | Application Component | Application Component Name |
|---|---|---|---|---|
| SIMG | SIMG_CFMENUORFBOBZ9 | 0 | HLA0006520 O HLA0006511 O HLA0006500 |
Maintenance Objects
| Maintenance object type | C | Customizing Object |
| Assigned objects | ||||||
|---|---|---|---|---|---|---|
| Customizing Object | Object Type | Transaction Code | Sub-object | Do not Summarize | Skip Subset Dialog Box | Description for multiple selections |
| SU03 | T - Individual transaction object | PFCG | 0000000024 |
History
| Last changed by/on | SAP | 19981222 |
| SAP Release Created in |
