SAP ERP has an advanced system for managing authorizations of users. This system allows to configure what employees of a company have access to particular transactions and functions of an SAP system. User access is restricted through authorization objects which are assigned to a user account created in SAP. The same authorization system is also used in SAP FI module where SAP FI posting authorization is assigned as per role or responsibilities of a user. For example, invoice booking team will have authorization to post or book invoices, treasury team will have authorization to book payments, sales team will have authorization to create sales orders, etc.
As per SAP best practice, it is advisable to create a role (combination of required transaction codes with required authorization objects) as per the responsibilities of an employee to avoid multiple or duplicate roles in the system. This helps management of the company to maintain restrictions to control usage of the SAP system and to secure important information (reports, details of stakeholders, etc.) of an organization.
SAP has introduced a functionality called park and hold for financial documents to avoid actual postings in financial accounting. Park and hold enables users to save documents without actually posting them and without making an impact to the financial reports. Usually in companies, users will park or hold documents and the manager or the senior user will later check and post the parked or held document which will update figures in financial accounting.
While posting the document a user can choose between immediately posting, parking or holding it to avoid actual postings. After review by the management, the entry can be posted through transaction codes FBV0 (Post/Delete a parked document), FBV2 (Change park document), FBV3 (Display document), FBV4 (Change header), or FBV5 (Display changes).
Tolerance groups in SAP help to set up even more fine-grained restrictions for users at transaction and activities levels. Different tolerance groups can be created and assigned at the company code level, so while posting transactions the SAP system will restrict users to post documents only up to for certain amounts or with cash discounts up to certain limit, etc.
Three types of tolerance groups can be created in SAP:
- G/L account
Tolerance groups are defined in SAP customizing. You can configure them by navigating to the following menus in SPRO transaction:
Path: SPRO – SAP IMG – Financial Accounting – General ledger accounting – Business transactions – Open item clearing – Clearing differences – Define tolerance group for employees/Define tolerance group for General ledger accounts
Path: SPRO – SAP IMG – Financial Accounting – Accounts receivable and payable –Business transactions – Outgoing payments – Manual outgoing payments – Define vendor tolerance
Transaction codes: OBA4/OBA0/OBA3
Tables: T043T (FI tolerance groups for employees), T043S (Tolerances for Groups of G/L Accounts), T043G (Tolerances for Groups of Customers/Vendors)
Employee Tolerance Groups
These tolerance groups are defined for users and control amounts per document, amounts per open item account item and cash discounts that can be posted by a user belonging to a particular tolerance group. If a tolerance group is empty, it means that it is applicable to all the users. If a tolerance group is maintained, then the same to be updated at user profile level.
G/L Account Tolerance Groups
Tolerance groups for G/L accounts control limit in local currency for respective debit or credit postings on G/L accounts for which we maintain a particular tolerance group.
Customer and Vendor Tolerance Groups
These tolerance groups control tolerance or limit at the time of clearing transactions, payment differences and payment advices for automatic write offs.
SAP FI Posting Authorization
The technical SAP BASIS team normally create roles and assign them to the user accounts. SAP FI posting authorizations are usually maintained by SAP FI team with the help of tolerance groups. SAP has provided several transaction codes to get the required authorization objects as explained below.
If you want to find out which authorization objects are required to access a particular transaction, you can use the transaction SU24 to obtain a list of authorization default values for any transaction code. For example, on the screenshots below we checked what authorization objects are required for the transaction OB52.
Another transaction code that is useful when dealing with missing authorizations is SU53. It helps to get the information about missing authorization object(s) as enclosed below. This is how you should use SU53 for troubleshooting missing authorizations:
- First, run the transaction where you have missing authorizations.
- Next, enter /nSU53 in the transaction bar.
- The system will show you diagnostic of authorization checks in the transaction where you have missing authorizations.