Authorization Objects (SAP Library - Account Management (FS-AM))

Authorization Objects

Definition

An authorization is an empowerment to perform a certain activity in the SAP System.

Every authorization is related to an authorization object and defines a value or values for each authorization field contained in the authorization object.

Authorizations are grouped into profiles that are entered in the user master record.

This graphic is explained in the accompanying text

The profile generator supports the creation of profiles/roles. You can find the documentation in the SAP Library. Choose Basis ® mySAP-Technology Components ® SAP Web Application Server ® Security ® Users and Roles ( Structure link Users and Roles(BC-SEC-USR).

You execute the activities required for the Account Management system in the Account Management Customizing settings by choosing Basic Settings ® Authorizations.

Use

In the Account Management system you use authorization objects for the following areas:

· Account holder change

· Card pool cancellation

· Notice on amount

· Product change (card pool)

· Product change (cards)

· Forward order

· Reconciliation

· Card cancellation

· Product change

· Account closure

· Master contract termination

· Contract maintenance

· General ledger transfer: Individual value adjustment and periodic tasks

· Payment forms

· Payment item (including prenote and information item)

· Payment order

· Standing order

· Product

· Posting Lock Management

· Postprocessing order

In addition to the application authorizations, the system also checks the following authorizations in the Account Management system:

· Central checks

· Conditions

· Market data

· Posting Control Office

· Business partner

· Basis authorizations

· HR authorizations

Structure

For the definition of authorizations and roles, both an overview of the authorization objects supplied by SAP is important as well as an overview showing which authorization objects the system checks in which transactions.

The profile generator you use to define your authorizations selects the checked authorization objects in the transactions you have selected. However, it is still important to know the details of the check made for each individual authorization object. The fields checked for the authorization objects and their values are the most important factors.

Below is an overview of all the authorization objects checked in the Account Management system. These do not only include the ‘own’ authorization objects, but also the cross-application authorization objects checked in the Account Management transactions, such as basis objects.

You can find the “own” authorization objects in the system in the following object classes:

FICO Financial Services - Financial Conditions

FPCO Financial Services - Posting Control Office

FSAM Financial Services - Account Management

FSDH Financial Services - Posting Lock Management

FSMD Financial Services – Market Data

FSPR Financial Services – Product Configurator

PP01 Postprocessing Office

Account Holder Change

Objects	Object	Field names
	F_BOCA_FCT FS-AM Account Holder Change: Operation	Activity Operation of the account holder change
	F_BOCA_ORG FS-AM Account Holder Change: Contract-Managing Organizational Unit	Activity Contract-managing organizational unit (encrypted)
	F_BOCA_RSN Account Holder Change: Account Holder Change Reason	Activity Change reason
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	When an order for account holder change is processed, user authorization can be assigned per function (delete or execute) for the ‘create’ and ‘change’ activities. We do not make any distinctions according to function for the ‘display’ activity. When an order for an account holder change is processed, user authorization can be assigned per contract-managing organizational unit for the ‘create’, ‘change’ and ‘display’ activities. When an order for an account holder change is processed, user authorization can be assigned per change reason for the ‘create’ and ‘change’ activities. We do not distinguish between authorizations according to notice reasons in the case of the ‘display’ activity.

Account Holder Change (BAPI)

Objects	Object	Field names
	F_BOCA_ACT FS-AM Account Holder Change: Activity (BAPI)	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions	The system checks the authorization object when account holder changes are created, displayed or changed via BAPIs.
Notes	You have the option of making a Customizing setting so that the same authorization checks run as in online processing, instead of this authorization object: F_BOCA_FCT, F_BOCA_RSN, F_BOCA_ORG. Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for each authorization check set up by SAP.

Card Pool Cancellation

Objects	Object	Field names
	F_BOCG_FCT FS_AM Card Pool Cancellation: Functions	Activity Operation
	F_BOCG_ORG FS-AM Card Pool Cancellation: Contract-Managing Organizational Unit	Activity Contract-managing organizational unit (encrypted)
	F_BOCG_RSN FS-AM Card Pool Cancellation: Notice Reason	Activity Notice reason for card pool
Activities	01 Add or create 02: Change 03: Display
Check in transactions	BCA_OR_CGC01 Card pool cancellation
Notes	For the processing of an order for card pool cancellation, you can assign a user’s authorization per operation (activate notice, execute notice, deactivate notice and so on) or per notice reason for activities “create” and “change”. We do not make any distinctions according to operations or notice reasons for the “display” activity. When an order for canceling a card pool is processed, user authorization can be assigned per contract-managing organizational unit for the ‘create’, ‘change’ and ‘display’ activities. Authorization objects F_BOCG_FCT and F_BOCG_ORG are not checked in BAdIs. Authorization object Card Pool Cancellation: Activity (technical name F_BOCG_ACT) is checked in BAdIs. Authorization object F_BOCG_RSN is also checked in BAdIs.

Card Pool Cancellation (BAPI)

Objects	Object	Field names
	F_BOCG_ACT FS-AM Card Pool Cancellation: Activity	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions	The system checks this authorization object when an order for card pool cancellation is accessed via BAPIs.
Notes	Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for each authorization check set up by SAP.

Notice on Amount

Objects	Object	Field names
	F_BONW_FCT FS-AM Notice on Amount: Operation	Activity Operation
	F_BONW_ORG FS-AM Notice on Amount: Contract-Managing Organizational Unit	Activity Contract-managing organizational unit (encrypted)
	F_BONW_RSN FS-AM Notice on Amount: Notice Reason	Activity Notice reason
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	When an order for account closure is processed, user authorization can be assigned per notice reason or per function (activate, delete, execute deactivate, reverse) for the ‘create’ and ‘change’ activities. We do not make any distinctions according to functions or notice reasons for the ‘display’ activity. When an order for canceling a card pool is processed, user authorization can be assigned per contract-managing organizational unit for the ‘create’, ‘change’ and ‘display’ activities.

Notice on Amount (BAPI)

Objects	Object	Field names
	F_BONW_ACT FS-AM Notice on Amount: Activity (BAPI)	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions	The system checks the authorization object when notices on amount are created, displayed or changed via BAPIs.
Notes	You have the option of making a Customizing setting so that the same authorization checks run as in dialog processing, instead of this authorization object: F_BONW_FCT, F_BONW_RSN, F_BONW_ORG.. Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for each authorization check set up by SAP.

Product Change (Card Pool)

Objects	Object	Field names
	F_BOPP_FCT FS-AM Product Change (Card Pool): Activities	Activity Operation
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	When an product change is processed, user authorization can be assigned per operation (activate, delete, execute, deactivate) for the ‘create’ and ‘change’ activities. We do not make any distinctions according to operations for the ‘display’ activity.

Product Change (Card Pool) (BAPI)

Objects	Object	Field names
	F_BOPP_ACT FS-AM Product Change (Card Pool): Activity	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions	The system checks this authorization object when a product change is accessed via BAPIs.
Notes	You have the option of making a Customizing setting so that the same authorization checks run as in dialog processing, instead of this authorization object: F_BOPP_FCT. Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for each authorization check set up by SAP.

Product Change (Cards)

Objects	Object	Field names
	F_BOSP_FCT FS-AM Product Change (Cards): Activities	Activity Operation
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	When an product change is processed, user authorization can be assigned per operation (activate, delete, execute, deactivate) for the ‘create’ and ‘change’ activities. We do not make any distinctions according to operations for the ‘display’ activity.

Product Change (Cards) (BAPI)

Objects	Object	Field names
	F_BOSP_ACT FS-AM Product Change (Cards): Activity	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions	The system checks this authorization object when a product change (cards) is accessed via BAPIs.
Notes	You have the option of making a Customizing setting so that the same authorization checks run as in dialog processing, instead of this authorization object: F_BOSP_FCT. Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for each authorization check set up by SAP.

Forward Order

Objects	Object	Field names
	F_FOR_TRT FS-AM Forward Order: Transaction Type	Activity Transaction type
Activities	01 Add or create 02: Change 03: Display 06 Delete
Check in transactions	The system checks this authorization object in all dialog transactions of forward orders.
Notes	Transaction Post Forward Order Before Execution Date is checked with authorization object F_POR_TRT.

Forward Order (BAPI)

Objects	Object	Field names
	F_FOR_ACT FS-AM Forward Order: Activity	Activity
Activities	01 Add or create 02: Change 03: Display 06 Delete
Check in transactions	The system checks this authorization object when a forward order is accessed via BAPIs.
Notes	You have the option of making a Customizing setting so that the same authorization checks run as in online processing, instead of this authorization object: F_FOR_TRT. Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for each authorization check set up by SAP.

Reconciliation

Report

Objects	Object	Field names
	F_GLRC_ACT FS-AM Reconciliation	Activity Company code (general ledger) Bank posting area
Activities	16 Execute
Check in transactions	The system checks this object for all reconciliation reports.
Notes

Card Cancellation

Card Cancellation: Activity

Objects	Object	Field names
	F_BOCC_ACT FS-AM Card Cancellation: Activity	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions	BCA_OR_CARC Card Cancellation (only if the transaction is called up via BAPI)
Notes	This authorization object is only checked in the case of access to notice on card via BAPIs. You have the option of making a Customizing setting so that the same authorization checks run as in dialog processing, instead of this authorization object: F_BOCC_FCT, F_BOCC_RSN, F_BOCC_ORG.

Card Cancellation: Functions

Objects	Object	Field names
	F_BOCC_FCT FS-AM Card Cancellation: Functions	Activity Operation
Activities	01 Add or create 02: Change 03: Display
Check in transactions	BCA_OR_CARC Card cancellation
Notes	When an order for card cancellation is processed, user authorization can be assigned per function (activate, execute or deactivate card cancellation) for the ‘create’ and ‘change’ activities. We do not make any distinctions according to function for the ‘display’ activity. Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for each authorization check set up by SAP.

Card Cancellation: Notice Reason

Objects	Object	Field names
	F_BOCC_RSN FS-AM Card Cancellation: Notice Reason	Activity Notice reason
Activities	01 Add or create 02: Change
Check in transactions	BCA_OR_CARC Card cancellation
Notes	When an order for card cancellation is processed, user authorization can be assigned per notice reason for the ‘create’ and ‘change’ activities. We do not distinguish between authorizations according to notice reasons in the case of the ‘display’ activity.

Card Cancellation: Contract-Managing Organizational Unit

Objects	Object	Field names
	F_BOCC_ORG FS-AM Card Cancellation: Contract-Managing Organizational Unit	Activity Contract-managing organizational unit
Activities	01 Add or create 02: Change 03: Display
Check in transactions	BCA_OR_CARC Card cancellation
Notes	When an order for card cancellation is processed, user authorization can be assigned per contract-managing organizational unit for the ‘create’, ‘change’ and ‘display’ activities.

Product Change

Product Change (BAPI)

Objects	Object	Field names
	F_BOCP_ACT FS-AM Product Change: Activity	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions	The system checks the authorization object when product changes are created, displayed or changed via BAPIs.
Notes	You have the option of making a Customizing setting so that the same authorization checks run as in dialog processing, instead of this authorization object: F_BOCP_FCT. Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for each authorization check set up by SAP.

Product Change

Objects	Object	Field names
	F_BOCP_FCT FS-AM Product Change: Operations	Activity Product change operations
Activities	01 Add or create 02: Change 03: Display
Check in reports
Notes	Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for each authorization check set up by SAP.

Account Closure

Account Closure via BAPI

Objects	Object / object class	Field names
	F_BOTC_ACT FS-AM Account Closure: Activity	Activity
Activities	01 Add or create 02: Change 03: Display
Check	The system checks the authorization object when creating, displaying and changing account closures.
Notes	The system only checks this authorization object in the case of access to account closure via BAPIs. You have the option of making a Customizing setting so that the same authorization checks run as in dialog processing, instead of this authorization object: F_POR_TRT. Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for all authorization checks set up by SAP (see function group BCA_BUSISB002_BTE or BCA_BTE_OR_TOC_SAMPLE: SAMPLE_INTERFACE_0BCA2016).

Edit Account Closure

Objects	Object / object class	Field names
	F_BOTC_FCT FS-AM Account Closure: Functions	Activity Operation
Activities	01 Add or create 02: Change 03: Display
Operations	0110 Delete 0120 Activate 0130 Deactivate 0140 Partial execution 0150 Execute 0160 Reverse
Check in transactions	The system checks the authorization object when account closures are created, displayed or changed (transaction BCA_OR_TOC). The ‘create’ and ‘change’ transactions can change the status of the account closure and the account in question. Authorization can only be restricted in the case of these two activities.
Check in reports	When calling up account closure reports, a check is made to see whether the user has general authorization for end-of-day processing F_EODP_ACT: RBCA_OR_TOC_PP_START (mass account closure).
Notes	Business objects queried by account closure (such as account or business partner) are also subject to authorization checks. Central authorization checks (such as editing accounts belonging to bank employees) are made before the process described above. Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for all authorization checks set up by SAP (see function group BCA_BTE_OR_TOC_SAMPLE: SAMPLE_INTERFACE_0BCA2005).

Check Organizational Unit for Account Closures

Objects	Object / object class	Field names
	F_BOTC_ORG FS-AM Account Closure: Contract-Managing Organizational Unit	Activity Organizational unit
Activities	01 Add or create 02: Change 03: Display
Check in transactions	The system checks the authorization object when account closures are created, displayed or changed (transaction BCA_OR_TOC). During this check, the activities can be restricted in such a way that they are only permitted for certain (contract-managing) organizational units set in Customizing and stored in the account.
Notes	Business objects queried by account closure (such as account or business partner) are also subject to authorization checks. Central authorization checks (such as editing accounts belonging to bank employees) are made before the process described above. Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for all authorization checks set up by SAP (see function group BCA_BTE_OR_TOC_SAMPLE: SAMPLE_INTERFACE_0BCA2006).

Check Notice Reasons for Account Closure

Objects	Object / object class	Field names
	F_BOTC_RSN FS-AM Account Closure: Notice Reason	Activity Notice reason
Activities	01 Add or create 02: Change
Check in transactions	The system checks the authorization object when account closure orders are created or changed (transaction BCA_OR_TOC). During the check, user activities can be restricted in such a way that only certain notice reasons stored in the account product may be processed.
Notes	Business objects queried by account closure (such as account or business partner) are also subject to authorization checks. Central authorization checks (such as editing accounts belonging to bank employees) are made before the process described above. Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for all authorization checks set up by SAP (see function group BCA_BTE_OR_TOC_SAMPLE: SAMPLE_INTERFACE_0BCA2007).

Account Closure: Phase of a Time Deposit

Objects	Object / object class	Field names
	F_BOTC_FPH FS-AM Account closure: time deposit phase	Activity Time deposit phase
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	When an order for account closure is processed, user authorization can be assigned depending on the phase of a time deposit for the ‘create’, ‘change’ and ‘display’ activities. The authorization check is only run for contracts with the time deposit feature.

Master Contract Termination

Objects	Object	Field names
	F_BOTP_ORG FS-AM Master Contract Termination: Contract-Managing Organizational Unit	Activity Contract-managing organizational unit
	F_BOTP_FCT FS-AM Master Contract Termination: Operations	Activity Function
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	When an order for master contract termination is processed, user authorization can be assigned per contract-managing organizational unit for the ‘create’, ‘change’ and ‘display’ activities. When an order for account closure is processed, user authorization can be assigned per function (activate, delete and execute) for the ‘create’ and ‘change’ activities. We do not make any distinctions according to function for the ‘display’ activity.

Master Contract Termination - BAPI

Objects	Object	Field names
	F_BOTP_ACT FS-AM Master Contract Termination: Activity	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions	The system only checks this authorization object in the case of access to master contract termination via BAPIs.
Notes	You have the option of making a Customizing setting so that the same authorization checks run as in online processing, instead of this authorization object: F_BOTP_ORG, F_BOTP_FCT.

Contract Maintenance (Account, Card, Master Contract, Card Pool)

Contract

Objects	Object	Field names
	F_CN_ATT FS-AM Contract: Authorization Types	Activity Authorization type Authorization value (field 1) Authorization value (field 2)
	F_CN_FDG FS-AM Contract: Field Groups	Field group Activity
	F_CN_MOD FS-AM Contract: Contract Element	Activity Object type (limits or conditions)
	F_CN_ORG FS-AM Contract: Managing Organizational Unit and Product Category	Activity Product category Contract-managing organizational unit
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	You can use authorization object F_CN_ATT, which is checked in the BDT, to define authorizations to any number of entry fields in contract maintenance. Depending on the field values, you define which contracts may be maintained. To do this, define an authorization type in Customizing and store the names of the fields you want checked. This authorization is optional. You do not have to assign this if you do not want any particular master data records to be protected and you have therefore not stored any authorization types in the Customizing settings. Authorization object F_CN_FDG is checked in the BDT. Authorizations for changes at field level, such as general ledger group, can be assigned with this. (No check is made during creation). You can use authorization object F_CN_MOD to authorize users to edit certain contract elements. This authorization object is initially only checked for limits and conditions on the contract. This is generally restricted to the ‘create’ and ‘change’ activities, but ‘display’ is always possible. You can use authorization object F_CN_ORG to define which Account Management contracts can be processed, on the basis of the product category and the organizational unit that is valid for the contract.

Simplified Contract Authorization Check

Objects	Object	Field names
	F_CN_ACT Simplified Contract Authorization Check	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions	In the standard set-up, the system checks this authorization object in methods of the following business objects: · CMAccountAM · CMAccountPoolAM · CMBankCard · CMBankCardPool Function module BCA_MAP_CN_CHECK_AUTHORITIES ( check contract authorizations) checks these business objects centrally.
Notes	Object for simplified authorization check for functions of contracts.

Simplified Authorization Check in BAPIs

Objects	Object	Field names
	F_CN_BAPI FS-AM Simplified Authorization Check in BAPIs	Simplified authorization check in contract BAPIs
Check in transactions	You use this authorization object to specify which users only have the simplified authorization check made in the BAPIs for the contract. In the simplified BAPI authorization check, only the authorization object F_CN_ACT is checked. Otherwise, all authorization checks are made.
Notes	Note that when you assign this authorization, the number of authorization checks is reduced. This improves performance of the BAPI call, but also makes your system easier to access for users with this authorization. You can use the IMG activity “Define Authorization Check in BAPIs” to restrict access to certain BAPI modules in a controlled way.

Edit Migration Group

Objects	Object	Field names
	F_CN_MIG Edit Migration Group	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	With this authorization object you define which user is allowed to edit the data of the migration group.

GL Transfer

General Ledger Transfer: Individual Value Adjustment

Objects	Object	Field names
	F_GLVA_ACT FS-AM Individual Value Adjustment	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions	The system checks the authorization object when value adjustments are created, displayed or changed.
Notes	In the case of transaction ‘Post Loss on Receivables’, only the authorization objects of the payment item are checked (see that section).

General Ledger Transfer: Periodic Tasks

Objects	Object	Field names
	F_EODP_ACT FS-AM End-of-Day Processing	Activity Bank posting area
Activities	16 Execute 48 Simulate
Authorization group	FA_01 FS-AM: General Ledger
Check in reports	The authorization group is checked for all reports of the general ledger transfer (except for accrual/deferral). The system also checks the authorization object per bank posting area when executing or simulating. · RFBKGL_VA_CALC_POST (execute individual value adjustment) · RBCA_GL_BSPREP (balance sheet preparation) · RFBKGL01 (transfer postings to the general ledger) · RBCA_GL_BSPREP_RESTART (restart balance sheet preparation)

Payment Form

Objects	Object	Field names
	F_PFM_TYP FS-AM Payment Form: Position Type	Activity Payment form type
Activities	01 Add or create 02: Change 03: Display 05 Lock 06 Delete
Check in transactions	The system checks this authorization object in the following dialog transactions for payment forms: Add, generate, change, display and lock.
Notes	The authorization checks relate to the respective payment form type that is assigned to the form.

Payment Item

Payment Item (Including Prenote and Information Item)

Objects	Object	Field names
	F_PIT_TRT FS-AM Payment Item: Transaction Type	Activity Transaction type
Activities	01 Add or create 02: Change 03: Display 85 Reverse 86 Transfer post 87: Return 89 Force post
Check in transactions	The system checks this authorization object in all dialog transactions for payment items (see ‘Comments’)
Notes	When processing a payment item, user authorization can be assigned per transaction type for the following activities: · Create: This enables you both to park and to post a payment item. To force a posting, authorization for activity ‘post’ is also required. · Change: This enables you to reject a payment item. For reversal and transfer posting of payment items in dialog processing, you also need authorization for the ‘change’ activity as well as that for the ‘reverse’ or ‘transfer Post’ activities. · Display · Transfer post: This enables you to transfer post a payment item if you also have the authorization for the ‘change’ activity. · Reverse: This enables you to reverse a payment item if you also have the authorization for the ‘change’ activity. · Return Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for each authorization check set up by SAP. For this authorization object it is 0BCA3080.

Payment Item (Including Prenote and Information Item) (BAPI)

Objects	Object	Field names
	F_PIT_ACT FS-AM Payment Item: Activity	Activity
Activities	01 Add or create 02: Change 03: Display 85 Reverse 86 Transfer post 87: Return
Check in transactions	The system only checks this authorization object in the case of access to payment items(or prenote and information item) via BAPIs.
Notes	You have the option of making a Customizing setting so that the same authorization checks run as in dialog processing, instead of this authorization object: F_PIT_TRT. Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for each authorization check set up by SAP. For this authorization object it is 0BCA3081.

Payment Order

Objects	Object	Field names
	F_POR_TRT FS-AM Payment Order: Transaction Type	Activity Transaction type
Activities	01 Add or create 02: Change 03: Display 06 Delete 77: Park 85 Reverse 89 Force post
Check in transactions	The system checks the authorization object in all dialog transactions of the payment order.
Notes	You can also make the check by calling up function module BCA_PO_API_AUTHORITY_CHECK if you wish to develop your own GUI to process the payment order, for example.

Payment Order (BAPI)

Objects	Object	Field names
	F_POR_ACT FS-AM Payment Order: Activity	Activity
Activities	01 Add or create 03: Display 85 Reverse
Check in transactions	The system only checks this authorization object in the case of access to payment orders via BAPIs.
Notes	You have the option of making a Customizing setting so that the same authorization checks run as in dialog processing, instead of this authorization object: F_POR_TRT.

Standing Order

Objects	Object	Field names
	F_SOR_FDG FS AM Standing Order: Field Groups	BDT field groups Activity
	F_SOR_ATT FS-AM Standing Order: Authorization Types	Activity Authorization type Authorization value (field 1) Authorization value (field 2)
	F_SOR_TRT FS-AM Standing Order: Transaction Type and Organizational Unit	Activity Transaction type Organizational unit
Activities	01 Add or create 02: Change 03: Display 06 Delete 43 Release
Check in transactions	The system checks the authorization objects when editing (create, change, delete, display, release) standing orders in all dialogs transactions. In the case of authorization object F_SOR_FDG we only distinguish between activities 02 and 03.
Notes	Authorization F_SOR_TRT can be set for the transaction type and organizational unit.

Standing Order (BAPI)

Objects	Object	Field names
	F_SOR_ACT FS-AM Standing Order: Activity	Activity
Activities	01 Add or create 02: Change 03: Display 06 Delete
Check in transactions	The system checks the authorization object when standing orders are created, displayed or changed.
Notes	You have the option of making a Customizing setting so that the same authorization checks run as in dialog processing, instead of this authorization object: F_SOR_FDG, F_SOR_ATT, F_SOR_TRT.

Product

Objects	Object	Field names
	F_PROD_PGR FS-AM/FIPR Product: Authorization Group	Activity Authorization group
Activities	01 Add or create 02: Change 03: Display 06 Delete
Check in transactions	The system only checks authorization object F_PROD_PGR during maintenance of products in the Product Configurator.
Notes	The authorization object field refers to the authorization group in the product. If the authorization group of the product has not been maintained, no authorization check is made.

Posting Lock Management

Customizing for Document Status

Objects	Object	Field names
	F_DEH_STA FS-AM-PLM: Customizing for Document Status	Activity
Activities	01 Add or create 02: Change 03: Display 06 Delete
Check in transactions	Define document status (BCA_CUS_DEH_STATE)
Notes	This authorization object is for checking the authorization for setting the PLM document status.

Customizing for Event Types

Objects	Object	Field names
	F_DEH_STA FS-AM-PLM: Customizing for Event Types	Activity
Activities	01 Add or create 02: Change 03: Display 06 Delete
Check in transactions	Define event type (BCA_CUS_DEH_ET)
Notes	This authorization object is for checking the authorization for setting PLM event type.

Entry Origin

Objects	Object	Field names
	F_DEH_BGRP FS-AM-PLM: Entry Origin	Activity Authorization group for event type Entry origin
Activities	01 Add or create 02: Change 03: Display
Check in transactions	The authorization object is checked in the following transactions: · Create PLM document for an account · Create PLM document for a business partner · Create PLM document for a master contract · Create PLM document for a card · Display PLM document · Change PLM document · Search for PLM document via list · Activate PLM documents · Close PLM documents · Start workflow
Notes	This authorization object is checked when PLM documents are processed.

PLM Document Category 0001 (Account)

Objects	Object	Field names
	F_DEHDOCAC FS-AM-PLM: PLM Document Category 0001(Account)	Activity Bank number Country key Account number Authorization group for event type
Activities	01 Add or create 02: Change 03: Display
Check in transactions	The authorization object is checked in the following transactions and reports: · Create PLM document for an account (BCA_DEH_EVENT_CRE_AC) · Display PLM document (BCA_DEH_EVENT_DISPLA) · Change PLM document (BCA_DEH_EVENT_CHANGE) · Search for PLM document via list (BCA_DEH_EVENT_LIST) · Activate PLM documents (BCA_DEH_STATE_ACT) · Close PLM documents (BCA_DEH_STATE_END) · Start workflow (BCA_DEH_WF_START)
Notes	The system checks the authorization object when PLM documents of document category account are created, displayed or changed.

PLM document Category 0002 (Card) 0003 (Business Partner)

Objects	Object	Field names
	F_DEHDOCBP FS-AM-PLM: PLM Document Category 0002 (Card) 0003 (Business Partner)	Activity Business partner number Authorization group for event type
Activities	01 Add or create 02: Change 03: Display
Check in transactions	The authorization object is checked in the following transactions and reports: · Create PLM document for a card(s) (BCA_DEH_EVENT_CRE_CA) · Create PLM document for a business partner (BCA_DEH_EVENT_CRE_BU) · Display PLM document (BCA_DEH_EVENT_DISPLAY) · Change PLM document (BCA_DEH_EVENT_CHANGE) · Search for PLM document via list (BCA_DEH_EVENT_LIST) · Activate PLM documents (BCA_DEH_STATE_ACT) · Close PLM documents (BCA_DEH_STATE_END) · Start workflow (BCA_DEH_WF_START)
Notes	The system checks the authorization object when PLM documents of document category card and business partner are created, displayed or changed.

PLM Document Category 0004 (Master Contract)

Objects	Object	Field names
	F_DEHDOCAP FS-AM-PLM: PLM Document Category 0004 (Master Contract)	Activity Master contract number Authorization group for event type
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	The system checks the authorization object when PLM documents of document category master contract are created, displayed or changed.

Postprocessing Order

Objects	Object	Field names
	/SAPPO/ORD Postprocessing order	Software component Business process Activity
Activities	02: Change 03: Display 06 Delete A8: Process mass data
Check in transactions	The system checks this authorization in the following transactions: Edit, display, complete, and delete postprocessing order.
Notes	With this authorization object you can give employees display and/or change access to postprocessing orders.

Postprocessing Order Filter

Objects	Object	Field names
	/SAPPO/FLT Postprocessing order filter	Software component Filter authorization object Activity
Activities	02: Change
Check in transactions	The system checks this authorization in the context of filter management in the following transactions: Edit/display postprocessing order.
Notes	With this authorization object you can give employees authorization to manage filters.

Worklist Assignment

Objects	Object	Field names
	/SAPPO/WLA Worklist assignment	Software component Activity
Activities	02: Change 03: Display
Check in transactions	The system checks this authorization object in the following transactions: Display/change worklist assignment.
Notes	With this authorization object you can give employees authorization to display and/or change the worklist assignment.

Central Checks

Employee Authorization for Own Objects

Objects	Object	Field names
	F_EMP_SELF FS-AM Employee Authorization for Own Objects	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	This authorization object enables employees to access Account Management objects relating to a contract in which they are contract holders. The user identification must also be stored on the contract holder in the ‘User’ field. If employees access objects in their contracts, no other Account Management authorization objects are checked. Authorization can be assigned for displaying/changing as well as creating.

Authorization for Employee Contracts and Objects (BAPI)

Objects	Object	Field names
	F_EMP_ACT FS-AM Authorization for Employee Contracts and Objects	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions	You can use this authorization object to authorize users to edit contracts or related objects that have the ‘Employee’ indicator set for their contract holders. This authorization object is checked in addition to the other Account Management authorization objects.
Notes

Authorization Groups

Objects	Object	Field names
	F_BANK_BPG FS-AM Business Partner Authorization Group	Activity BEGRU authorization group
	F_BANK_CNG FS-AM Contract Authorization Group	Activity CN_BEGRU authorization group
Activities	01 Add or create 02: Change 03: Display
Check in transactions	You use authorization object F_BANK_BPG to define which Account Management objects can be processed, on the basis of the authorization group maintained on the business partner. You use authorization object F_BANK_CNG to define which Account Management objects can be processed, on the basis of the authorization group maintained on the contract. The system checks the authorization objects when editing (create, change, display) in all online transactions.
Notes	These authorizations are optional. You do not have to assign these if you do not want to protect any particular master data records. Customers can refine all check procedures using Business Transaction Events (BTEs). There is a BTE for all authorization checks set up by SAP (see OPEN_FI_PERFORM_0BANK003P: SAMPLE_PROCESS_0BANK003).

Conditions

Individual Conditions

Objects	Object	Field names
	F_FICO_IND FICO – Individual Conditions	Activity Condition group type Condition type
Activities	01 Add or create 02: Change 03: Display 06 Delete
Check in transactions	The authorization object is checked in function module FICO_API_AUTH_CHECK. The function module is used in the following programs and function modules: · -Control of screen display (FICO_CONTROL_NEW_COND_NAVIGATE) · Transfer conditions from a list in the global memory (FICO_LIST_GET_COND_OF_LIST) · Create a condition list (FICO_API_CONDITION_CREATE) · Create a new condition (program SAPLFICOO0, method HANDLE_MENU_BUTTON) · Change a condition list (FICO_API_CONDITION_CREATE) · Copy a condition component (= validity period) (FICO_LIST_COPY_COMPONENT) · Copy a condition (= all validity periods) (FICO_LIST_COPY_COND) · Copy a condition group (FICO_LIST_COPY_LIST)
Notes	With this authorization object you define which individual conditions a user is allowed to edit, depending on the defined fields. The authorization object is checked when you are maintaining individual conditions for a contract and in the corresponding BAPIs.

Individual Conditions – BAPIs

Objects	Object	Field names
	F_FICO_AIN FICO – Individual Conditions BAPIs	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	The system only checks this authorization object in the case of access to individual conditions via BAPIs.

Standard Conditions

Objects	Object	Field names
	F_FICO_STD FICO – Standard Conditions	Activity Condition group type Condition type
Activities	01 Add or create 02: Change 03: Display 06 Delete
Check in transactions	The authorization object is checked in function module FICO_API_AUTH_CHECK. The function module is used in the following programs and function modules: · -Control of screen display (FICO_CONTROL_NEW_COND_NAVIGATE) · Transfer conditions from a list in the global memory (FICO_LIST_GET_COND_OF_LIST) · Create a condition list (FICO_API_CONDITION_CREATE) · Create a new condition (program SAPLFICOO0, method HANDLE_MENU_BUTTON) · Change a condition list (FICO_API_CONDITION_CREATE) · Copy a condition component (= validity period) (FICO_LIST_COPY_COMPONENT) · Copy a condition (= all validity periods) (FICO_LIST_COPY_COND) · Copy a condition group (FICO_LIST_COPY_LIST)
Notes	With this authorization object you define which standard conditions a user is allowed to edit, depending on the defined fields. The system checks the authorization object when you are maintaining standard conditions and in the corresponding BAPIs.

Individual Conditions – BAPIs

Objects	Object	Field names
	F_FICO_AST FICO – Standard Conditions BAPIs	Activity
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	The system checks this authorization object when the standard conditions are accessed via BAPIs.

Financial Conditions: Authorization Types

Objects	Object	Field names
	F_FICO_ATT FICO Financial Conditions: Authorization Types	Activity Authorization type Authorization value (field 1) Authorization value (field 2)
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	You can use this authorization object to define authorizations for any input fields in the maintenance of standard and individual conditions. Depending on the field values, you define which conditions may be maintained. To do this, define an authorization type in Customizing and store the names of the fields you want checked. This authorization is optional. You do not have to assign this if you do not want any master data records particularly protected and you have therefore not stored any authorization types in the Customizing settings.

Financial Conditions: Field Groups

Objects	Object	Field names
	F_FICO_FDG FICO Financial Conditions: Field Groups	Activity Field group for authorization
Activities	02: Change 03: Display
Check in transactions
Notes	This authorization object is used by the BDT. Authorizations for changes at field level can be assigned with this. This authorization is optional. You do not have to assign this if you do not want any field groups particularly protected and you have therefore not stored any field groups for authorization in the Customizing settings.

Market Data

Authorization for the Spread Type

Objects	Object	Field names
	F_BAF4_SPT FDB: Authorizations fort he Spread Type	Activity Spread type Market data area
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	This authorization object controls the visibility and the authorizations for editing spread type data within a market data area.

Market Data Area

Objects	Object	Field names
	F_BAF4_MDC FDB: Market Data Area	Activity Market data area
Activities	01 Add or create 02: Change 03: Display
Check in transactions
Notes	This authorization object controls the authorizations for editing and for the visibility of market data area data.

Posting Control Office

Worklist Assignment

Objects	Object	Field names
	F_PCO_WL_A Worklist Assignment	Activity
Activities	02: Change 03: Display
Check in transactions
Notes	This object is checked when worklists are assigned. Possible characteristic values of the authorization include displaying or changing the values. The activity is always checked.

Worklist Overview

Objects	Object	Field names
	F_PCO_WL Worklist Overview	Activity Worklist overview
Activities	03: Display
Check in transactions
Notes	This object is checked when worklists are displayed. Possible characteristic values of this authorization include complete view or a partial view of the worklists, each with and without display of the corresponding values. The display activity is always checked.

Posting Control Order

Objects	Object	Field names
	F_PCO_ORD Posting Control Order	Activity Application that generates a posting control order
Activities	02: Change 03: Display
Check in transactions
Notes	This object is used when posting control orders are displayed and edited. The application is checked, and the display and change activities.

Filter

Objects	Object	Field names
	F_PCO_FILT Filter	Activity PCO filter
Activities	02: Change
Check in transactions
Notes	This object is used for checking authorizations when filters are created. The check is to see if general or only your own filters may be defined. The change activity is checked.

Business Partner

Objects	Object	Field names
	B_BUPA_ATT Business Partner: Authorization Types	Activity Authorization type Authorization value (field 1) Authorization value (field 2)
	B_BUPA_GRP Business Partner: Authorization Groups	Activity Authorization group
	B_BUPA_FDG Business Partner: Field Groups	Activity Field group for authorization
	B_BUPA_RLT Business Partner: BP Roles	Activity Business partner role category
Activities	01 Add or create 02: Change 03: Display
Check in transactions	The system checks the authorization objects when editing business partner master data. In authorization object B_BUPA_FDG the system only checks activities 02 and 03. This authorization object is not checked when creating a business partner.

Basis Authorizations

S_PROGRAM ABAP: Program Process Flow Checks

Objects	Object	Field names
	S_PROGRAM Execute Programs	User activity ABAP/4 program Authorization group ABAP/4 program
Check in transactions	You can issue authorizations for reports and evaluations in the periodic tasks with authorization object S_PROGRAM. This authorization object is not checked except in the ‘Periodic Tasks’ menu. The authorization groups assigned to the standard reports are decisive factors in the check. Displaying the application logs is not protected by authorization object S_PROGRAM. You can protect these using authorization object S_APPL_LOG (read application log) (see below). With this authorization object you can issue authorizations to start reports in BCA. Since the system also calls up reports at certain points, it is recommended that you transfer the authorization to the basis authorizations. The object consists of the following fields: Authorization group ABAP program (P group) Here you specify the name of the program group for which a user is authorized. Find the possible values for this field by using the F4 help. The following authorization groups are used by the Account Management system (see table TPGP): · FA_01 General Ledger · FA_02 Settlement · FA_03 Control · FA_04 Product · FA_05 Bank Statement · FA_06 Balance Confirmation · FA_07 Cards - General · FA_08 Cards - Communication · FA_CORR Adjustment Reports User Action ABAP/4 Program Here you enter the permitted operations. A possible value is SUBMIT (run program), for example.
Notes	You can find the object in object class ‘Basis - Development Environment’.

In the SECU field, the TRDIR table shows the authorization groups that are checked in the individual reports.

S_BTCH_ADM: Batch Processing: Batch Administrator

Objects	Object	Field names
	S_BTCH_ADM Batch Processing: Batch administrator	Identification for batch administrator
Check in transactions	The system checks object S:BTCH_ADM during the periodic tasks (account settlement, archiving and so on). There is a check for ‘Identification for Batch Administrator =Y’.
Notes	You can find the authorization object in object class ‘Basis - Administration’.

S_BTCH_JOB: Batch Processing: Operations in Batch Jobs

Objects	Object	Field names
	S_BTCH_JOB Batch Processing: Operations in Batch Jobs	Operations in a batch job Summarizing jobs in a group
Check in transactions	The system checks object S_BTCH_JOB during the periodic tasks (account settlement, archiving and so on). There is a check for the RELE operation. The job group is blank.
Notes	You can find the authorization object in object class ‘Basis - Administration’.

S_APPL_LOG: Read Application Log

Objects	Object	Field names
	S_APPL_LOG Read Application Log	Activity Application log: Object name Application log: Sub-object
Activities	03: Display
Check in transactions	In the Account Management system, this object is checked when the application logs are displayed. The following object names are checked with their sub-object names (you can find the list of sub-objects per object in table BALSUB): · FIBA: FI – Bank Accounting · BCA_CARD: Card Management of Banking Solution · DEH: Posting Lock Management · FS_ARCH: Financial Services - Archiving · FS_EVENT: Error Log for External Data Transfer · FS_EXC: Financial Services – Standard Error Log · FS_EXC_ACCT: FS_AM: Account – Error Log · FS_EXC_ACPOOL: FS_AM_AP: Master Contract – Error Log · FS_EXC_BDT_CTRL: Error Log for BDT in Subscreen Controller · FS_MASS: Financial Services – Standard Log for Quantity Processing · FS_PROT: Financial Services – Standard Log · FS_PROT_DEH: FS DEH – Standard Log
Notes	You can find the authorization object in object class ‘Basis - Central Functions’.

S_TABU_DIS: Table Maintenance (using standard tools such as SM31)

Objects	Object	Field names
	S_TABU_DIS Table Maintenance (using standard tools such as SM31)	Activity Authorization group
Activities	01 Add or create 02: Change 03: Display
Check in transactions	With authorization object S_TABU_DIS you can set up authorizations for Customizing, meaning the maintenance of the configuration tables in the IMG: By assigning them an authorization group, the tables you maintain during configuration of a component are summarized to groups for the issuing of authorizations. You can use this authorization group to target your issuing of authorizations for individual areas of Customizing. The authorization groups relevant for Customizing are arranged similarly to the IMG.
Notes	The following authorization groups are used in the Customizing for the Account Management system: · FA01: Customizing · FA02: Control · FA03: Master Data · FA04: Flow Data · FA05: Archiving Do not give ordinary processing staff, meaning users without Customizing authorization, authorization for S_TABU_DIS. You can find the authorization object in object class ‘Basis - Administration’.

S_RFC: Authorization Check for RFC Access

Objects	Object	Field names
	S_RFC Authorization Check for RFC Access	Activity Name of the RFC object to be protected (name of the function group) Category of the RFC object to be protected (FUGR)
Activities	16 Execute
Check in transactions	The system checks authorization object S_RFC during a general ledger transfer with ALE connection, in other words, only when external transfer per RFC is set. In the case of external general ledger linkage via ALE, the system also makes an authorization check when calling up the FI reconciliation reports (Logs ® Reconciliation ® ...). This authorization object is checked for all RFC calls.
Notes	Authorization object S_RFC is located in object class Cross-Application Authorization Objects.

HR Authorizations

When creating, changing or displaying contracts (account, card, master contract, card pool), the system checks HR authorization object PLOG with the function code (DISP) and the respective data. For more information, see the documentation on this authorization object in the system.