Custom Tcode Management

[shivakumarbalaiah_balaiah]

As an SAP Authorization Administrator would have come across with Functional/IT team creating Custom tcodes for a specific Business purpose and requesting Auth team to include into a suitable role.

There are many projects/organizations still not managing custom tcodes methodically, leading to audit deficiency and in some cases misuse of critical access assigned via custom tcode.

Also, if custom tcodes technical name not based on functionality i.e Create/Change/Display, then it will be a tedious effort to categorize and also mapping into GRC ruleset for the first time, when there are hundreds of custom tcodes to be looked into.

Purpose

This document provides information on managing Custom Tcodes in any organization from an SAP Authorization team perspective.

Introduction

In SAP we have many modules and each module has specific tcodes in place to process Business data. There are few instances where Business team needs to be restricted with few fields or added more fields in a standard tcode provided by SAP. This type of requirement differs from Business to Business.

There also few scenarios when Custom data managed in a custom table, needs to be given access to Business/IT teams for data processing.

Business Case

Let’s take an example a Business team intend to restrict Company Code data field in the SAP standard tcode XK02 i.e changing Vendor. Hence based on Business requirement a Custom tcode copy of XK02 need to build with restricted Company Code Data field.

Based on my experience and per SAP best practice, i would suggest the below steps as a SAP Authorization Administrator.

Step 1: Whenever there is a need for Custom development, make sure it is relevant, unless the business requirement cannot be fulfilled/managed by SAP standard tcode. If there is an alternative tcode, suggest Business team to leverage with the same and avoid custom development.

SAP Functional/ABAP team should involve Authorization team from the initial discussions since Business team mostly contact Functional team. This will help Auth team to understand the requirement in terms of auth checks, objects, table access requirement etc.

Step 2: Upon the requirement is finalized, let there be a Functional/Technical Spec document for Custom tcode which includes Custom program names, objects, tables, Custom tcode and most important functionality i.e Create/Change/Display type of the tcode. As per SAP best practice it is suggested to use SAP standard objects within custom program and it is fine to create custom tables if needed.

Also, insist ABAP team to name custom tcode based on the nature of tcode i.e ending with 01 for create/ending with 02 for change etc. and update suitable Tcode description as per the type, since this will help to identify type of tcode if there is no proper documentation.

Step 3: Upon ABAP/Functional team completes necessary developments in Dev system, Authorization team can build a test role with new Custom tcode added and assign test role to a test user for further testing from Functional team.

Enable Auth trace for the test user to capture the auth check objects within the trace.

Scenario 1: If no objects traced when tcode successfully executed, it means there is no Authority check enabled in the Custom Program and hence inform ABAP team to include suitable objects under Authority-Check section of the custom program. Relevant Auth objects can also be identified if custom tcode is a copy of standard tcode in SU24 and same can be enabled for Custom tcode program.

Scenario 2: If objects are populated in the Auth trace as missing auth, then relevant object can be added into test role to make sure it executes successfully. Later inform ABAP team to include in the Authority-Check section with relevant objects, if not enabled in the custom program. Please make note of these objects which required to be added into SU24.

Step 4:  Other option to get objects relevant by executing program RS_ABAP_SOURCE_SCAN with below mentioned search strings and based on the results ,we could classify Change/Display tcode ,based on objects with Activity i.e Change/Display.

AUTHORITY-CHECK
BDC_INSERT
CALL FUNCTION
Call Transaction
Call Method
Submit Report
Submit
Update table/Database
Delete from

Step 5: Maintain relevant Auth objects identified from previous steps into SU24 with required Values as well.  After saving the changes, it will request for a Workbench transport request and capture in the same.

Step 6: Assign custom tcode into desired Business Role and make sure Auth objects are populated into the role, which were included in SU24.

Step 7: Get the necessary Unit testing performed to make sure Custom tcode functionality works as expected and proceed further with Quality for UAT.

Also update into GRC Ruleset if tcode is a Business sensitive Access (BSA) with relevant Risk id & objects and its values mapped and check for SOD conflict with existing tcodes in the role.

Please follow the sequence of ABAP/Functional changes to be moved first and followed by Security i.e SU24 and Role changes into Production system.

 

Key Take Aways

- Auth team involvement from early stage of requirement gathering.

- Avoid custom development if standard functionality is not available/possible.

- Suitable Naming Conventions, Authority-check enablement in Custom program by ABAP team.

- Update into SU24 with relevant objects/values and GRC Ruleset if tcode is BSA.

- Follow Sequencing of ABAP/Functional changes followed by Auth changes into Production system.