Dealing with Authorization Groups: Part 2

As I said in a previous post, "Dealing with Authorization Gaps: Part 1," the authorization groups aren't limited to technical data as there are also many related to Business Master Data. The concept of implementation is the same:

  • Understand the reason for using an authorization group.
  • Identify where to set the groups.
  • Find the related authorization objects.
  • Assign the values to the proper roles taking into account which users need each access.

Normally, there are more SAP business users than technical users, making the assignment to users much more complex. Since there are many business authorization groups, I will focus on the ones I believe are the most critical:

  • For FI Document Types.
  • For Vendors.
  • For Customers.
  • For G/L Accounts.

Authorization Groups For FI Document Types

There are many transactions inside SAP which allow users to post financial documents. The best way to avoid having users posting document types that they shouldn't is to assign authorization groups. The document types can be updated using transaction OBA7. Since it’s a customizing transaction you will probably need to perform the change in Development and then transport it into Production.

Another way to see the list of document types is by displaying table T003 using transaction SE16. The related authorization object is the F_BKPF_BLA. The big challenge here is to group the document types according to the business needs (this is always a challenge but for posting FI documents it’s especially complex). At first glance you might think that you only need to determine which documents are for each dept, e.g.:

  • Payments (KZ) -> Treasury.
  • Vendor Invoices (KR) -> Accounts Payable.
  • Asset Posting (AA) -> Fixed Assets Team.
  • GL account document (SA) -> Accounting.

But then you have other document types such as credit notes, debit notes, vendor documents and others that could be shared among teams, while at the same time have different locations with different departments. Since it's a global table it can’t be segregated by company code which presents a big challenge.

Authorization Groups For Vendor Accounts

There are two main reasons to assign authorization groups to vendors:

  • To limit the access to maintain/display vendor master data.
  • To limit the access to post/display vendor documents.

The difference between the authorization group for vendors and the one for Document Type is that this is a field that can be maintained at Master Data Level, directly with a business transaction and doesn't need to be transported. The authorization group can be assigned to vendors using the following transactions:

  • XK01, FK01 or MK01 when creating a vendor
  • XK02, FK02 or MK02 when updating a vendor

And it can be assigned in two levels:

  • General Vendor Master Data: 
  • Vendor Master Data per Company Code: 

This means that a vendor can have two authorization groups, so users will need both values to operate with that vendor. To list all the existing groups you can display table LFA1 (for General Vendor Master Data) or table LFB1 (for Vendor Master Data per Company Code) using transaction SE16 and check the field BEGRU. Once the AG is assigned, the following authorization objects are required in the user roles:

  • F_LFA1_BEK: For users responsible for vendor maintenance. The object has two fields: ACTVT (activity) which restricts the actions, BRGRU (authorization group) access to vendors with that authorization group.
  • F_BKPF_BEK: For users responsible for posting documents (invoices, payments, credit notes, etc) on vendor accounts. The object has two fields: ACTVT (activity) which restricts the actions, BRGRU (authorization group) access to vendors within that authorization group.

Authorization Groups For Customer Accounts

The concept is the same that for Vendor Accounts, but the transactions and the names of the authorization objects are different. The authorization group can be assigned to customers using following transactions:

  • XD01, FD01 or VD01 when creating a customer.
  • XD02, FD02 or VD02 when updating a customer.

And it can also be assigned in two levels:

  • General Customer Master Data: 

 

  • Customer Master Data per Company Code: 

  To list all the existing groups you can display table KNA1 (for General Customer Master Data) or table KNB1 (for Customer Master Data per Company Code) using transaction SE16 and check the field BEGRU. Once the AG is assigned, the following authorization objects are required in user roles:

  • F_KNA1_BED: For users responsible for customer maintenance.  The object has two fields: ACTVT (activity) which restricts the actions, BRGRU (authorization group) access to customers within that authorization group.
  • F_BKPF_BED: For users responsible for posting documents (invoices, payments, debit notes, etc) on customer accounts. The object has two fields: ACTVT (activity) which restricts the actions, BRGRU (authorization group) access to customers within that authorization group.

 

Authorization Groups For G/L Accounts

Same as for Vendors and Customers, you can limit the access to maintaining and posting on General Ledger accounts. The authorization group can be assigned using transactions FS00 and FSS0

To list all the existing groups you can display table SKB1 using transaction SE16 and check the field BEGRU. In this case the related authorization objects are:

  • F_SKA1_BES: For users responsible for G/L accounts maintenance.  The object has two fields: ACTVT (activity) which restricts the actions, BRGRU (authorization group) access to G/L accounts within that authorization group.
  • F_BKPF_BES: For users responsible for posting documents on G/L accounts. The object has two fields: ACTVT (activity) which restricts the actions, BRGRU (authorization group) access to G/L accounts within that authorization group.

 

Summary

Leave a comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Subscribe to our monthly newsletter, the Defender's Digest!