SAP Global Technical Development Programming Standards

SAP Technical Development
Programming Standards & Guidelines

Table Of Contents
PURPOSE OF DOCUMENT.......................................................................................................................................4
ROLES AND RESPONSIBILITIES...................................................................................................................................4
WHAT THIS DOCUMENT DOES NOT COVER.................................................................................................................4
INTRODUCTION.........................................................................................................................................................5
GENERAL RULES......................................................................................................................................................6
NAMING CONVENTIONS FOR PROGRAM OBJECTS......................................................................................7
CHAPTER I. NAMING CONVENTIONS FOR DEVELOPMENT OBJECTS...................................................8

1.1 NAMING STANDARD FOR CUSTOM DEVELOPED PROGRAMS................................................................................8
1.2 NAMING STANDARD FOR CUSTOMER MODIFIED SAP PROGRAMS......................................................................8
1.3 NAMING STANDARD FOR MODULE POOL PROGRAM...........................................................................................9
1.4 NAMING STANDARD FOR GUI STATUS & GUI TITLE..........................................................................................9
1.5 NAMING STANDARD FOR CLASSES (ABAP OBJECTS)..................................................................................10
1.6 NAMING STANDARD FOR VARIANTS..................................................................................................................12
1.7 NAMING STANDARD FOR BDC SESSIONS..........................................................................................................12
1.8 NAMING STANDARD FOR PACKAGES..................................................................................................................12
1.9 PROGRAM VARIABLES NAMES...........................................................................................................................12
1.9.1 Work Variables.......................................................................................................................................14
1.9.2 Work Area................................................................................................................................................14
1.9.3 Internal Tables Naming Conventions..................................................................................................14
1.9.4 Parameters..............................................................................................................................................15
1.9.5 Select-Options........................................................................................................................................15
1.9.6 Macros.....................................................................................................................................................16
1.9.7 Constants.................................................................................................................................................16
1.9.8 Subroutine forms....................................................................................................................................16
CHAPTER II. NAMING CONVENTIONS FOR DATA DICTIONARY OBJECTS.........................................17
2.1 DATA STORAGE TABLES....................................................................................................................................17
2.2 TRANSPARENT TABLES.......................................................................................................................................17
2.3 VIEWS.................................................................................................................................................................17
2.4 STRUCTURES.......................................................................................................................................................17
2.5 FIELD NAME STANDARDS...................................................................................................................................18
2.6 DOMAINS FIELD NAME STANDARD....................................................................................................................18
2.7 DATA ELEMENT NAME STANDARD....................................................................................................................18
2.8 OVERVIEW OF DATA ELEMENTS & DOMAIN RE-USE GUIDELINES....................................................................19
2.9 SEARCH HELP.................................................................................................................................................19
2.9.1 Elementary search help.........................................................................................................................20
2.9.2 Collective search help:..............................................................................................................................20
2.10 LOCK OBJECTS.................................................................................................................................................20
CHAPTER III. NAMING CONVENTIONS FOR OTHER OBJECTS...............................................................22
3.1 NAMING STANDARD FOR AREA MENU..............................................................................................................22
3.2 NAMING STANDARD FOR TRANSACTION CODES................................................................................................22
3.3 NAMING STANDARDS FOR FUNCTION GROUPS & MODULES.............................................................................22
3.4 NAMING STANDARD FOR FUNCTION GROUP......................................................................................................23
3.5 NAMING STANDARD FOR FUNCTION MODULE...................................................................................................23
3.6 NAMING STANDARD FOR LOGICAL DB..............................................................................................................24
3.7 EVENTS NAMING CONVENTIONS........................................................................................................................25
SAP Technical Development Programming Standards
3.8 NAMING STANDARDS FOR PARAMETERS ID......................................................................................................25
3.9 AUTHORIZATION OBJECT....................................................................................................................................25
3.10 MESSAGE CLASS...............................................................................................................................................26
3.11 EXPORT / IMPORT MEMORY ID........................................................................................................................27
CHAPTER IV. ENHANCEMENTS.........................................................................................................................27
CHAPTER V. ERROR HANDLING........................................................................................................................32

5.1 ERROR MESSAGES..............................................................................................................................................32
FOLLOWING ARE THE SUPPORTED SAP ERROR MESSAGE TYPES..............................................................................32
CHAPTER VI. FORMS STANDARDS....................................................................................................................33
6.1 PRINT PROGRAM NAMING CONVENTION........................................................................................................33
6.2 FORMS LAYOUT NAMING STANDARDS............................................................................................................33
6.3 NAMING CONVENTIONS FOR DEFINING PARAGRAPHS:......................................................................................34
6.4 NAMING CONVENTIONS FOR DEFINING CHARACTER STRINGS:.........................................................................34
6.5 NAMING CONVENTIONS FOR PAGES AND WINDOWS:........................................................................................34
6.6 STANDARDS FOR CREATING TEXT IN WINDOWS:..............................................................................................34
6.7 STANDARDS FOR CREATING SPOOL REQUEST:...................................................................................................35
CHAPTER VII. ABAP SOURCE PROGRAM STRUCTURE AND ORGANIZATION...................................36
7.1 HEADER DOCUMENTATION................................................................................................................................36
7.2 CHANGE MARKERS.............................................................................................................................................37
7.2 THE STANDARD STRUCTURE FOR ABAP CODE.................................................................................................38
7.3 PROGRAM COMMENTS........................................................................................................................................39
7.4 TABLE TVARVC...............................................................................................................................................40
7.5 USING ADVANCED FEATURES OF RENEWED ABAP...........................................................................................41
7.6 COMMUNICATION WITH MIDDLEWARE..............................................................................................................42
APPENDIX A-GLOSSARY.......................................................................................................................................43
DOCUMENT REVISION HISTORY......................................................................................................................43
Page 3 of 44
Purpose of Document
 This document explains the standards that BD has adopted for the development of custom code
within the SAP environment. They are to be used by both BD staff and 3 rd party contractors.
 The Goal of these standards is to provide quality, consistency, and maintainability without hampering
the development process.
 These Standards are updated periodically to stay aligned with future SAP release enhancements.
Roles and Responsibilities

It is the responsibility of any person developing custom code for use at BD in the SAP
environment to become familiar with, and to adhere to these development standards. If the
person developing the code is not an IT Development team member, an IT Development team
member must be assigned to perform the technical walkthrough to ensure compliance.
What this document does not cover

This document does not cover objects related to portal development, CRM BSP
development, and CRM WEB UI development. These technologies are covered in their own
respective standard documents.
Page 4 of 44
INTRODUCTION
These programming standards are intended to aid in the programming and related maintenance
work in the current SAP software development systems. The target audience of this document is anyone
with the necessary appreciation of best practices in software engineering in the SAP environment, and
those required to perform programming tasks.
This is not a programming manual and does not attempt to cover SAP functionality. However,
reference will be made to those features, which if not standardized or controlled could lead to problems in
performance. Programming standards do not exist for their own sake but as an attempt to achieve the
highest quality of work. When high quality of work is achieved, development times are shorter,
particularly in the testing and debugging stage, stakeholder and user expectations are met and system
maintainability is enhanced.
As a result, each program should be self-explanatory to another developer. Sufficient comments

should be included in the code to make the program ‘self-documenting’, without the need to maintain /
refer to hard-copy files or perform on-line data searches.
Page 5 of 44
General Rules
 Any modification to a standard SAP object requires supporting documentation and appropriate
signoff.
 All custom developed SAP objects require an approved System Requirement Specification (SRS).
 All custom developed SAP objects should be named according to the naming standards found in this
document.
 Before creating a new object, an analysis should be performed to determine whether an existing
object can be used to perform the required processing.
 Never perform direct updates to standard SAP tables using the ABAP commands UPDATE,
INSERT, MODIFY, and DELETE. Use standard function modules or SAP BAPIs to ensure data
integrity.
 All custom programs and modifications need to be documented with the BD standard heading block
as outline in section 7.1, Header documentation.
 Avoid inserting large blocks of code in mainstream logic; instead use subroutines to modularize your
code.
 In order keep code clean, please remove all dead code from program, and log detail changes in the
header block. Old code can be reviewed using standard SAP version management.
 From AS 7.40 on, ABAP is further developed in support packages that are bundled with kernel
releases. Further bundled SPs are to come, each with an own kernel and therefore with new ABAP
features can be leveraged on Everest systems.
 Renewed ABAP features are not applicable on Tahiti, Monaco, Fiji, BD India and 4.0B SAP
system’s as basis component is lower than AS 7.40.
Page 6 of 44
Naming Conventions for Program Objects
To simplify the identification of custom-written programs and to prevent SAP from

overwriting any development objects in a new release, the naming conventions herein described
will be used with several qualifications that are outlined in this section. It is critical that all
developers follow these procedures when writing software in the SAP system. If you do not
follow these procedures you may adversely affect the portability and upgrade of the SAP system
you are working with.
The naming convention for new development and custom modifications will distinguish SAP
standard reports from those that are custom developed or modified.
The naming standards for SAP development objects are divided into two categories:
 Custom Developed
 Custom Modified
Process Team Abbreviations
When naming standards specify the need for a process team, use the following table to determine
appropriate values.
Team Description
MTC Market to Customer
OTS Opportunity to Sale
CTC Contract to Cash
UTR Use to Replenish
ITR Idea to Retire
STP Source to Pay
DTS Demand to Supply
FTM Finance to Manage
STS Source to Separate
EDM Enterprise Data Management
ATR Acquire to Retire
CGC Corporate Governance and Controls
UTL Utility
SAP SAP
Page 7 of 44
CHAPTER I. Naming Conventions for Development Objects
1.1 Naming Standard for Custom Developed Programs
Custom developed programs are ABAP programs that we (BDX) develop from scratch. It is new
development and not a modification of an existing SAP program. The name of the ABAP
program will be built by the following naming standards:
Z XXX ‘_’ T ‘_’ ’MMM ( ‘_’ NNN) **

| | | | |
| | | Meaningful ** Use consecutive number suffix (NNN)
| | | Name if more than one version of the object
| | | exists.
| | Dev Type R =Report
| | N =Includes
| | D =Data conversion
| | I =Interface
| | E =Enhancement
| | O =Other
| 3 character Process Team code (refer to table on page 7)
SAP Rule
Examples: ZCTC_R_INVENTORY_REPORT = Inventory Report for CTC
1.2 Naming Standard for Customer Modified SAP Programs
Customer modified SAP programs are SAP supplied ABAP programs that we modify for our
use. We can make modifications to a SAP supplied program by taking a copy of the current SAP
program and renaming it using the following naming standard:
Z ‘SAP’ ‘_’ [Name of SAP Program]

| | | |
| | |
| | Original Name of the SAP Program
| Constant
SAP Rule
Examples: Original SAP Program RSSLGS00

Modified Version ZSAP_RSSLGS00_001
Page 8 of 44
1.3 Naming Standard for Module Pool Program
An ABAP module pool is a group of ABAP programs that access common processing modules,
checks and process user inputs during a transaction. The module pool is also a means of linking
all the associated screens, menus and function keys of the interface as a transaction. The module
pool has a program attribute type of ‘M’ and the following naming standards:
SAPM Z XXX ‘_’ MMMM

| | | |
| | | |
| | | |
| | | Meaningful Name
| | |
| | 3 Character Process Team code (refer to table on page 7)
| SAP Rule
|
Module Pool Program
Example: SAPMZDTS_BOMS
1.4 Naming Standard for GUI Status & GUI Title
An instance of the user interface, consisting of a menu bar, a standard toolbar, an application
toolbar, and a function key setting, is called a GUI status.
The naming convention for GUI Status is as follows:
NNN where NNN = screen number Example: 1000
The naming convention for GUI Title is as follows:
NNN where NNN = screen number Example: 1000
Page 9 of 44
1.5 Naming Standard for CLASSES (ABAP OBJECTS)

Custom developed Classes are ABAP object modules that we (BDX) develop from scratch.
There are two types of Classes that can be developed: local Class(local to program), and global
Class(available for public use).
Global Class Definition
ZCL ‘_’ ‘XXX’ ‘_’ MMM

| | |
| | Meaningful Name
| |
| 3 Character Process Team code (refer to table on page 7)
Example: ZCL_FTM_GETDATA
Global Exception Class
ZCX ‘_’ ‘XXX’ ‘_’ MMM

| | |
| | Meaningful Name
| |
Example: GCX_CTC_ERROR
Local Class Definition
LCL ‘_’ MMM

| | |
| Meaningful Name
Example: LCL_GETDATA
Local Exception Class
LCX ‘_’ MMM

| | |
| Meaningful Name
Example: LCX_ERROR
Page 10 of 44
Custom developed Interfaces are used to implement ABAP Classes. This can be both SAP and
customer developed classes. 2 types of interfaces that can be developed are local interface, and
global Interface.
Global Interface Definition
ZIF ‘_’ ‘XXX’ ‘_’ MMM

| | |
| | Meaningful Name
| |
SAP Rule
Example: ZIF_FTM_GETDATA
Local Interface Definition
LIF ‘_’ MMM

| |
| Meaningful Name
|
Indicates Local
When passing values using methods the following naming convention should be used.
Example: IWA_STRUCTURE or RT_TABLE.
Class Attributes
Static Attribute G[T]
Instance Attribute M[T]
Constant C[T]
Example: GT_TABLE; MWA_STRUCTURE or CW_VARIABLE.
Page 11 of 44
1.6 Naming Standard for Variants

Variants are objects that users can create when they want to save a specific set of selection
criteria for executing a program. Once the variant is created, it can be used to re-execute the
program without re-keying the selection criteria.
All Variants must be created with a meaningful name that defines the selection criteria being
saved.
1.7 Naming Standard for BDC Sessions

Batch input sessions enter data non-interactively into an R/3 System. Batch input is typically
used to transfer data from non-R/3 Systems to R/3 Systems or to transfer data between R/3
Systems. Use the following naming standards when naming BDC sessions.
XXX ‘_’ ZZZZ ‘_’ NN

| | |
| | 2 Digit Number
| |
| 4 Letter Transaction Code
|
3 Character Process Team code (refer to table on page 7)
Example: CTC_VA01_01 – BDC session to execute transaction VA01
1.8 Naming Standard for Packages

Packages are used to group related development objects together into one common area for
easier reference. Use the following when naming Packages
Z XXX ‘_’ MMM

| | |
| | Meaningful Name
| |
|
|SAP Rule
Example: ZCTC_CONFIG
1.9 Program Variables Names
 Always refer to SAP fields by their full name, e.g. LFA1-KTNRA, SY-SUBRC
 Use ‘TYPE’ when assigning attributes to variables declared in the data statement.
Page 12 of 44
 Subroutines must have meaningful names and their function and interfaces described.
 All data structures and fields used will be commented with a description of their name &
function
In-line Data Declaration.

 In-line Data declaration will continue to follow below naming conventions for locally
defined data objects.
 Also their existence should be local within below modularized units.
1. Subroutines
2. Methods
3. Function Modules
The standard is a letter(s) corresponding to the declared object, separated from the variable name
by an underscore to distinguish it from SAP supplied data names. The following letters will be
used:
(In all following examples, MMM stands for meaningful name)
No. Data Structure Standard Example

1 Global Variables W_MMM W_TOTALS
2 Local Variables LW_MMM LW_TOTALS
3 Global Work Area WA_MMM WA_HEADER
4 Local Work Area LWA_MMM LWA_HEADER
5 Global Internal Table T_MMM T_TAB
6 Local Internal Table LT_MMM LT_TAB
7 Parameters P_MMM P_OPTION
8 Select-Options S_MMM S_BUKRS
9 Types D_MMM D_ADDRESS
10 Macros M_MMM M_COMPUTE
11 Constant C_MMM C_RATE
12 Field Symbols <MMM> <HEADER>
13 Field Groups FG_MMM FG_MATERIAL
14 Global class data R_MMM R_MYDATA
15 Local class data LR_MMM LR_MYDATA
16 Global class object O_MMM O_AN_OBJECT
17 Local class object LO_MMM LO_AN_OBJECT
18 Global class interface I_MMM I_AN_OBJECT
19 Local class interface LI_MMM LI_AN_OBJECT
20 Global BAdI class B_MMM B_AN_OBJECT
21 Local BAdI class LB_MMM LB_AN_OBECT
22 Global class exception X_MMM B_AN_EXCEPTION
23 Local class exception LX_MMM LX_AN_EXCEPTION
Page 13 of 44
Page 14 of 44
1.9.1 Work Variables

Work variables are for general-purpose use. These variables may contain alphanumeric,
numeric, packed, binary, date, time or hexadecimal values.
When defining a global variable, prefix the structure name with ‘W_’ followed by a meaningful
name.
Example of global variable : W_TOTAL
When defining a local variable, prefix the structure name with ‘LW_’ followed by a meaningful
name.
Example of local variable : LW_TOTAL
Example of inline declared local variable: DATA(LW_TOTAL) = LIPS-KWMENG.
1.9.2 Work Area

Work Areas are used to store the record format of a standard table or an internal table.
When defining a work area, prefix the structure name with ‘WA_<name>’ for global work area,
and LWA_<name> for local work area, where <name> is the name of the table, or if it is not
related to a table, use a meaningful name.
Example of a global work area : WA_VBAK

Example of a local work area : LWA_itab
Example of non-table related work area: WA_ORDER_REC
Examples of inline declared local work area:
DATA(LWA_VBAK) = VBAK
SELECT single matnr,
mtart FROM mara INTO @DATA(lwa_mara)
where matnr EQ lw_material.
1.9.3 Internal Tables Naming Conventions

Internal tables are defined within programs and are used to hold blocks of records.
Internal tables must always be prefixed by:
T_<name> Global Internal Table

LT<name> Local Internal Table
In-Line Declaration:
Page 15 of 44
Example of inline declared local internal table:
SELECT matnr,
mtart FROM mara INTO TABLE @DATA(lt_mara_02)
UP TO 10 ROWS ORDER BY PRIMARY KEY.
More Examples:-
Before 7.40 With 7.40
Variables DATA lw_text TYPE string. DATA(lw_text) = `...`.

lw_text = `...`.
Declaration of table DATA lwa like LINE OF ld_itab. LOOP AT lt_itab INTO DATA(lwa).

work areas LOOP AT lt_itab INTO lwa. ...
... ENDLOOP.
ENDLOOP.
Declaration of a result DATA lref_xml TYPE xstring. CALL TRANSFORMATION ... RESULT XML
CALL TRANSFORMATION ... RESULT XML DATA(lref_xml).
lref_xml.
Declaration of actual DATA lw_a1 TYPE ... oref->meth( IMPORTING p1 = DATA(lw_a1)

parameters DATA lw_a2 TYPE ... IMPORTING p2 = DATA(lw_a2)...).
oref->meth( IMPORTING p1 = lw_a1
IMPORTING p2 = lw_a2... )
Declaration of DATA lref_ixml TYPE REF TO if_ixml. DATA(lref_ixml) = cl_ixml=>create( ).

reference variables for
factory methods
1.9.4 Parameters
Parameters are used to allow data entry at the selection screen before program execution.
These variable names have a limited length of 8 characters, and should be prefixed with ‘P_’ for
easy identification.
Example: P_PLANT
1.9.5 Select-Options
The SELECT-OPTIONS statement generates a program variable used for selection
criteria against a table. It allows the user to enter in a range of values before program execution.
The select-options variable name should be the existing table field name which is being checked,
prefixed with ‘S_’, to indicate a Select-Option
Example: S_PLANT
Page 16 of 44
1.9.6 Macros
Defines a program component (macro) under the name macro. It must consist only of
ABAP statements and is expanded at compilation time. A macro should always be concluded
with the END-OF-DEFINITION statement. In the definition, you can use &n to reference
positional parameters (n = 1, 2 .. 9). When the macro is called, &n is replaced by the n-th actual
parameter.
Example: M_Number.
1.9.7 Constants
Constant variables do not change value during the execution of a program. To indicate
these types, the variable name should be prefixed with ‘C_’
Example: CONSTANTS: C_RATE(4) TYPE N VALUE 1000.
1.9.8 Subroutine forms
When passing variables into subroutine forms, use the below naming standard for parameters.
Page 17 of 44
CHAPTER II. Naming Conventions for Data Dictionary Objects
This section describes tables, views, structures, info structures, domains, data elements, fields,
match code objects, lock objects, and type-groups associated with the Data Dictionary.
2.1 Data Storage Tables

This section describes the naming standards for tables that are used to store data on Disk. This
applies to tables of all types other than ‘internal’, including pool, cluster, and transparent tables.
2.2 Transparent Tables

The procedure will be of the type “transparent”. Tables can be defined independently of the
database in the ABAP Dictionary. The fields of the table are defined with their (database-
independent) data types and lengths
Z MMM
| |
| Meaningful Name
|
SAP Rule
Example: ZCUSTXREF – Customer cross reference
2.3 Views
Views are transparent tables consisting of an alternate view or combination of multiple tables,
such as a joined table. The length of the view name will vary based on the primary table name
for that view.
Z XXX ‘_’ MMMM ‘_’ V

| | | for View
| | Meaningful Name (name should contain main table name)
| |
SAP Rule
2.4 Structures
Structures are similar to tables although no records can be stored within them. They are defined
(almost) exactly like tables; the only difference is that no database tables are generated from
them. The same data elements and domains can be used in structures as in tables.
Page 18 of 44
Structures are used especially to define the data at the interface of module pools and screens and
to define the parameter types of function modules.
Z MMM ‘_’ DS
| | |
| | Data Structure
| Meaningful Name
|
Required By SAP
Example: ZCUSTXREF_DS
2.5 Field Name Standards

If you create your own field – you should create your own data element and domain since SAP
domains and data elements may change and also SAP recommend that you SHOULD copy
Domain and Data Element. Use the following naming standard when defining custom fields.
Z MMM
| |
| Meaningful
SAP Rule
Example: ZWERKS
2.6 Domains Field Name Standard

Different fields with identical technical attributes are combined in a domain. A domain defines a
value range, which describes the valid data values for all the fields, which refer to this domain.
This section describes the naming standards for domains. The 8 character names are formatted
according to the following rules:
Z MMM
| |
| Meaningful Name
SAP Rule
Examples: ZCHAR10, ZNUM5
2.7 Data Element Name Standard

A data element (elementary type) describes the technical attributes and meaning of a table field
or structure field.
The format specifications for a data element (fixed data type in the ABAP Dictionary, field
length and possibly the number of decimal places) are copied from the domain of the data
element.
Page 19 of 44
The following naming standard is applicable to table structure, domain and data element:
Z MMM |
| |
| Meaningful field name
|
SAP Rule
Example: ZMATNROLD - Old material

ZWERKS - Work Plant Code
2.8 Overview of Data Elements & Domain Re-use Guidelines
There are a large number of both data elements and domains, which are part of the standard SAP
system. When developing new data dictionary structures that require these objects it may be
preferable to re-use existing objects rather than creates new ones.
In general, domains are re-used more often than data elements since the domain provides the
linkages for check tables and lists of values.
If there is any doubt about the applicability of an existing data element or domain, it is better to
create new ones rather than re-use the existing ones. Again, good programming and design
practice should be followed.
2.8.1 Data Elements:

Data elements can be used if an element is needed that:
 provides the identical business picture as the existing element with regards to short
text, help text, screen labels and column headings
 is linked to a domain that provides the correct physical attributes, validation rules and
key linkage.
2.8.2 Domains:
Domains can be re-used if a domain that is needed :
 provides the identical physical definition as existing domain with regards to short
text, physical attributes,
 validation rules and key linkages of the existing domain.
2.9 SEARCH HELP
Page 20 of 44
Search helps can be used to assign an input help (F4 help) to fields in input masks.
 Elementary search help
 Collective search help
2.9.1 Elementary search help

An elementary search help corresponds to a search path. The elementary search help must define
where the data of the hit list should be read from (selection method), how the exchange of values
between the screen mask and selection method is implemented (interface of the search help) and
how the online input help should be defined (online behavior of the search help).
Z SSS
| |
| Search Help identifier
|
SAP Rule
Example: ZUS1 Search help for table USR01
2.9.2 Collective search help:

A collective search help comprises several elementary search helps. It combines all the search
paths, which make sense for a field. In a collective search help, the exchange of values between
the screen mask and the selection method (interface of the collective search help) must be
defined. The value selection and the settings for online behavior are taken from the elementary
search helps.
Z SSS
| |
| Search Help identifier
|
SAP Rule
Example: ZUS1 Search help for table USR01
2.10 Lock Objects

In the SAP system, when two users simultaneously attempt to access the same data record this is
synchronized by a lock mechanism. Locks are set or released by calling certain function modules
that are automatically generated from the definition of so-called "lock objects" in the ABAP
Dictionary.
Lock object names are formed as follows:

EZ TTTT
Page 21 of 44
| |
| Primary table to be locked
|
SAP Rule It is mandatory for lock objects to start with “EZ”
Example: For SAP Table EZMARA
Page 22 of 44
CHAPTER III. Naming Conventions for Other Objects
3.1 Naming Standard for Area Menu

Creating an area menu is similar to creating a standard menu. However, instead of specifying
functions for menu options you specify transaction codes.
Z MMM
| |
| Meaningful Name
|
SAP Rule
Example: ZBDX User Menu Becton Dickinson company.
3.2 Naming Standard for Transaction Codes

Transaction codes in SAP are used to execute transactions.
Transactions must be created using the following naming standard:
Z MMM
| |
| Meaningful Name
|
SAP Rule
Example: ZIRMADR – Incentive Rebate Module Agreement Detail Report
3.3 Naming Standards for Function Groups & Modules

Function Module is a sub-routine that facilitates the passing of import and export parameters (in
the form of single fields, field strings and internal tables) through a clearly defined interface.
Function modules only allow changing the data through the interface.
The main difference between a function module and a normal ABAP/4 subroutine is a clearly
defined interface for passing data to and from the function modules. Declaring data as common
parts is not possible for function modules. The calling program and the called function module
have separate work areas for ABAP/4 Dictionary tables.
Page 23 of 44
3.4 Naming Standard for Function Group
Function group is used to group function modules into functional units. The function group has
the following naming standard:
Z MMM
| |
| Meaningful Name
|
SAP Rule
Example: ZIRMBB - Incentive Rebate Module Bill Back objects.
For function groups that are copied from existing SAP function groups the following
naming convention should be used.
Z GGG
| |
| SAP function group
|
SAP Rule
3.5 Naming Standard for Function Module

Function modules are ABAP routines that are stored in a central function library. They
are not application specific, and are available system wide. The ABAP Workbench comes with a
large number of standard function modules.
Like form routines, function modules encapsulate program code, and provide an interface for
data exchange.
The function module name consists of 30 characters and has the following naming standards:
Custom Function module name
Z XXX ‘_’ MMM

| | |
| | Meaningful Name
| |
SAP Standard
Example: ZCTC_GETNAME
SAP copied Function Module name
Page 24 of 44
Z YYY
| |
SAP Rule |
SAP Function Module
Example: Z_POPUP_TO_CONFIRM
When passing values to and from function modules, use the following naming conventions for
parameters
3.6 Naming Standard for Logical DB.

A logical database is an access method where ABAP programs read and process SAP data using
the predetermined tree structure of tables. The naming standard for a logical database is as
follows:
Z XXX ‘-‘ MMMM

| | |
| | Meaningful Name
|
SAP Rule
The logical database naming is limited to the alphanumeric identifier within the SAP application
identifier. A complete list of SAP application identifier is available in the ABAP Program
Attributes screen.
Example: ZCTC_ORDERS - Orders for CTC
Page 25 of 44
3.7 Events Naming Conventions
An event is a signal stating that a predefined status in the system has been reached. The
background processing system receives events and then starts the background job that is linked
to an event.
You can specify predefined events of the SAP applications or events you defined yourself.
Which SAP events you can use are explained in the documentation of the SAP application.
Z MMM
| |
| Meaningful Name
SAP Rule
Example: ZPRODUCT_CREATED
3.8 Naming Standards for Parameters ID

A field can be filled with proposed values from SAP memory using a parameter ID.
A field on the screen is only filled automatically with the value stored under the parameter ID of
the data element if this was explicitly permitted in the Screen Painter.
Z {Field Name} ID
| | |
| | Indicating Parameter ID
| Field Name of parameter ID to be used
SAP Rule
Example: ZWERKS_ID Parameter Id for Plant on New Transaction
3.9 Authorization Object

Authorization object is required to control runtime access to ABAP programs and reports. Users
must be setup with the correct authorization object in the user-profile before they can execute
ABAP programs or reports that have an authorization object assigned. Users with access to
‘SA38’ or ‘SE38’ can execute programs if authority check is not carried out to prevent this.
Much of the data in an SAP system has to be protected so that unauthorized users cannot access
it. Therefore the appropriate authorization is required before a user can carry out certain actions
in the system. When you log on to the SAP system, the system checks in the user master record
to see which transactions you are authorized to use. An authorization check is implemented for
every sensitive transaction.
 Allocate an authorization object in the definition of the transaction;

 Program an AUTHORITY-CHECK.
AUTHORITY-CHECK OBJECT <authorization object> .
Page 26 of 44
ID <authority-field1> FIELD <field-value1>.
ID <authority-field2 > FIELD <field-value2>.
ID <authority-fieldn> FIELD <field-valuen>.
The OBJECT parameter specifies the authorization object.
Ex: ‘S_TCODE’
The ID parameter specifies an authorization field (in the authorization object).
Ex: ID ‘TCD’
The FIELD parameter specifies a value for the authorization field.
Ex: FIELD ‘ZDEV’
Authorization Object Class – All custom authorization objects need to be assigned to an object
class.
Z XXX
| |
SAP Rule
Example: ZIRM – Incentive Rebate Module authorization objects
a) All custom executable programs, other than the exceptions noted below, must contain
a transaction code authorization check within the ABAP code. If the user does not
have the required authorization, program execution must be halted, with an
accompanying error message. The authorization check is applicable whether the
program is executed online or as a background job.
b) The authorization check can be accomplished via the AUTHORITY-CHECK
statement for authorization object S_TCODE, or via a call to function module
AUTHORITY_CHECK_TCODE. It is suggested that the check be placed in the
beginning of the INITIALIZATION event block, though it can also be implemented
in the LOAD-OF-PROGRAM, AT SELECTION SCREEN, or START-OF-
SELECTION event blocks.
c) When implemented in the START-OF-SELECTION event block, the check must be
carried out first, before reading from or writing to the database or any files. Under
normal circumstances, the transaction code for the authorization check will be the
same as the transaction code assigned to the program, but there are situations where
they may be different.
3.10 Message Class
The message class header has the following naming standard:
Z XXX “_”MMM
| | |
| | |
Page 27 of 44
| | Meaningful Name
| |
SAP Rule
A total of 999 messages can be created per message class header. Generic messages with a ‘&’
(substituting variable) should be created as much as possible. Note that a maximum of four
parameters may be used in one message - any more will be ignored by the system.
Example: ZATR_MSGCL = Messages for Acquire to Retire
3.11 Export / Import Memory ID
When exporting and importing memory variables, use a meaningful name to describe the
memory ID so that it’s use can easily be determined. Also, document with comments where the
import and export will be set & used.
Export Example:
Import Example:
CHAPTER IV. Enhancements
Overview
Page 28 of 44
The enhancement concept allows you to add your own functionality to SAP’s standard
business applications without having to modify the original application. As part of the
enhancement concept, it is possible for the customer to add their own elements to application
logic, screens, and menus. The current possibilities for enhancement are as follows.
User Exits:
These are implemented in the form of subroutines and are also known as FORM EXITs. USER
EXITS exists in includes, and are usually attached to a standard SAP program(ex: MV45AFZZ).
USER EXITS are empty subroutines that SAP provides for customer to populate with their own
source code.
Since the subroutine names have already been provided by SAP, there is no naming
standard to adhere to, but keep in mind that all other naming standards must be followed for the
code being implemented.(variables, enhancements, etc…).
Customer Enhancements SMOD & CMOD:

SAP provides customers exits for specific programs, screens, and menus within standard SAP.
These exits do not contain functionality, but instead provide the customer hooks, in predefined
areas, to add you own functionality where needed. These exits can be found in Implementation
Guide or IMG.
The name for CMOD Projects for SAP Enhancements should follow the naming standards for
custom developed.
Z XXX MMM
| | |
| | Meaningful Name
SAP Rule
Examples: Project Manager Enhancements ZCTCSAC
The name for SMOD SAP Projects should follow the naming standards for custom developed.
Z XXX NNNN
| | |
| | Numeric number
| 3 Character Process Team code (refer to chart on page 7)
SAP Rule
Examples: Project Manager Enhancements ZCFT0001 – Own Stock Placement
Text enhancements:
Allow the customer to add supplementary documentation for data fields, and to change key
word texts.
The Name for Text enhancements is as follows:
Page 29 of 44
Z MMMM
| | Meaningful Name
SAP Rule
Field exits:
Every screen element with data element reference can branch to PBO or prior to PAI to a
function module if desired. The field contents are available here for doing special checks and
making changes (e.g. user- specific checks, authority checks, writing entered data and producing
statistics).
Function exits:
From the main program you branch into a software level, in which you can store ABAP/4
coding. The applications programmer at SAP determines where in the main program the function
exit is placed, and which data is imported/exported via the interface. The accompanying
documentation describes the functionality of the function exit.
Menu Exits:
SAP Delivered menu items can be activated and named. On the function code set at menu item
selection, there can be a reaction in a relevant function exit.
Screen Exits:
The customer can determine the layout of areas in screens provided by the applications
developer. Here, additional information can be displayed or data entered.
Page 30 of 44
Enhancement Framework:
SAP Enhancement framework enable you to add functionality to standard SAP software without
changing the original SAP objects, and to organize these enhancements as effectively as
possible.
With this technology, you can enhance global classes, function modules, Web Dynpro
components, and all SAP source code using Implicit enhancements, Explicit enhancements, and
BADI implementations.
Explicit Enhancement
Predefined hooks already coded into the program by SAP at various points of the code where the
customer can implement custom functionality.
Implicit Enhancement:
These are the points within SAP code where SAP allows for the insertion of customer code.
Implicit Enhancements are permitted at the beginning and at the end of subroutines(forms) and
function modules
Enhancement Spot
Enhancement spots are used to manage explicit enhancement options
BADI Enhancement
A BADI is an object-oriented enhancement option that provides a mechanism to change the
functionality of a business function without making changes to the code. A BADI enhancement
is implemented using an enhancement Spot & a BADI Implementation.
Z XXX MMMMM
| | |
| | Meaningful name
| 3 Character Process Team code (refer to chart on page 7)
SAP Rule
ZGN_ENHANCEMENTFRAMEWORK
All enhancements must include a call to the ZGN_ENHANCEMENTFRAMEWORK Function
Module to determine if the code should be executed or not. Execution is controlled by SRS id
and enhancement implementation that are maintained in table ZGN_EXIT via Transaction
ZGNEXIT.
Table ZGN_EXIT
Page 31 of 44
Example:
Page 32 of 44
CHAPTER V. Error Handling
5.1 Error Messages

Error messages are used to communicate with users on results of actions, or if a particular
actions needs to be taken. When issuing error messages, ensure the correct message type is
being used as its resulting action is dependent on the type of message being used. Ex: warning vs
hard error.
All error message tables are language dependent, so when creating new messages, make sure the
message is created for all supported languages. Error messages should not be hard coded into
programs. When using positional parameters, text elements should be used.
Following are the supported SAP error message types
1. I – Informational : Press ENTER to continue

2. W – Warning : Correction possible
3. E – Error : Correction required
4. A – Abend : Transaction terminated
5. X - Exit : Transaction terminated with short dump
6. S - Success : Message on next screen
5.2 Exception Handling

An exception is an event or error during the execution of a program that interrupts the normal
flow of control. An exception handling mechanism makes it possible to deal with these run time
errors. Exception classes are used to define handlers for all type of exceptions. Exception class
CX_ROOT is the super class of all exception classes, and all other exception class inherit from
CX_ROOT.
TRY CATCH ENDTRY

When performing operations where there is a possibility for an exception, ex: divide by zero, an
exception handler should be used.
TRY .
result = value1 / value2.

CATCH cx_sy_zerodivide INTO ex_ref.
msg_text = ex_ref->get_text( ).
CATCH cx_root INTO ex_ref.
msg_text = ex_ref->get_text( ).
CLEANUP.
ENDTRY
Page 33 of 44
CHAPTER VI. Forms Standards

Note: Although some SAPscript forms have been inherited from previous versions, the
SAPscript technology is not a recommended technology for future development
DO NOT USE SAPSCRIPT for new development!
6.1 Print Program Naming Convention

Print program is similar to a report program. Please refer to standards for report program
naming convention section for details.
6.2 Forms Layout naming standards
3 types of forms exist, Sapscript, Adobe Forms, and Smart Forms
Layout sets copied from the SAP standard layouts should be named as following.
Z XXX ‘_’ F ‘_’ SSSS
| | | |
| | Form Name of SAP form
| |
SAP Rule
Custom Layout sets should be named as follows:
Z XXX ‘_’ F ‘_’ MMM
| | | |
| | Form Meaningful Name
| |
|
SAP Rule
Custom Interface for Adobe Forms should be named as follows: (recommended to use the same
name as layout)
Z XXX ‘_’ I ‘_’ MMM
| | | |
| | Interface
|
SAP Rule
Custom SMARTFORM Style sets should be name as follows:

Z STYLE ‘_’ MMM
Page 34 of 44
| | |
| | Meaningful Name|
SAP Rule |
The word ‘STYLE’
SMARTFORM Text Module

Z XXX ‘_’ T ‘_’ MMM
| | | |
| | Text Meaningful Name
SAP Rule |
3 Character Process Team code (refer to table on page 7)
6.3 Naming Conventions For Defining Paragraphs:

 Paragraph Names in Forms are only 2 character long. All new Paragraph Names
would begin with letter ‘P’. The second character would be 0-9 and A-Z. Example
P1, P2.. PA..PZ.
 The descriptions of the paragraphs should be as detailed as possible with keywords
like Title, Footer, Body text etc.
6.4 Naming Conventions for Defining Character Strings:

 The Character String names are only 2 characters long in Forms. Follow the
following table to define new character strings.
To represent First Character Second Character Example
Barcode related B 0-9, A-Z B1, BA
Font related F 0-9, A-Z F1, FA
Other S 0-9, A-Z S1, SA
 The descriptions of the character strings should be as detailed as possible with

keywords like Bold, Italic, and Courier 10 etc. to best describe the character string.
6.5 Naming Conventions for Pages And Windows:

 SAP creates the new windows with default names like window1, window2 etc.. They
have to be renamed to best describe the contents of the window. The maximum length
allowed is 8 characters.
6.6 Standards for Creating Text In Windows:

 All symbols/variables should be in upper case.
 Hard coded text would be in both upper and lower case as applicable.
Page 35 of 44
 Local symbols can be up to 30 characters long and have to describe the contents of
the variable.
 Comments should follow the format: “** <author> <date> - <description>.
 An Example: “** S.Pentavalli 7/30/98 – Delivery address picked up from Delivery
Note instead of Shipping Header.”
 All modifications should have developer’s name, date and a brief description of the
modification. Add correction number for the first time or where ever meaningful.
6.7 Standards for Creating Spool Request:

Any non-tool output that is created should be assigned a Spool Request Name
Z XXX C MMMMMMMM
| | | |
| | | |
| | | |
| | |
| | Classification
| | "G" Accessible to all users (low risk)
| | “L" restricted only from the general display profiles.(Medium risk)
| | "M" only to planners or managers in the plants(high Risk)
| | "H" Accessible to higher levels within corporate HQ(Restricted)
| | "R" and "S" selectively assigned only to people at the
| | highest level(Secret)
| |
|
Identifies Custom Spool Request
Page 36 of 44
CHAPTER VII. ABAP Source Program Structure and Organization
7.1 Header Documentation

Adequate documentation for custom developed and modified programs is required to ensure the
analyst and/or programmer can understand the program function prior to performing
maintenance. The following documentation is required:
The main documentation block is used to describe the program contents. The following describes the
contents of the documentation block:
 Date and author of the program;
 Name of the program;
 Purpose of the program. This is freeform text that describes the use of the program. Use business
terminology more than computer terminology whenever possible;
 Include documentation for each change to the program;
 Date of change;
 Developer;
 Description of change.
The following is a sample header that should appear in all programs:
*----------------------------------------------------------------------*
* Author : Daniel Bulka
* Creation Date : August 2014
* Transaction : ZLM52
* IM/CR/Defect : IM457239
* Technical Design : GBL-BDX-ERP.6.0-STP-09.4.02-TD-SDS4318
* Transport Number : ECDK982153
* Description : Non HU Put away
*
*----------------------------------------------------------------------*
* Modification Information
*----------------------------------------------------------------------*
* Author : Daniel Bulka
* Date : 10/16/2014
* IM/CM/CR/Defect : Defect 7449
* Transport number: ECDK983764
* Description : in form new_bin, do not issue message for blank batch
* if material is not batch managed. changes marked DB001
*----------------------------------------------------------------------*
Page 37 of 44
7.2 Change Markers
When making modifications to existing code, it is important to mark your changes so

they can be identified later. All changes should be marked with the initials of the developer
and a sequential number. EX: DB01.
7.2.1 Minor modification change markers

Modifications are considered minor when anywhere from one to a few lines of code are
either being added/changed/ or deleted. In this case, changes should be marked with the
developer’s initials at the end of the lines that are being modified. (see below) In addition, a
corresponding header block also needs to be maintained at the top of the program that
documents the change in detail.
Insertion/modification (Minor)
IF w_matnr IS INITIAL OR w_qty <= 0. "DB01
7.2.2 Major modifications change markers

Modifications are considered major when a block of code is either being added/changed/
or deleted. In this case, changes should be marked with the developer’s initials at the top of the
coding block and at the end of the coding block. (see below). In addition, a corresponding
header block also needs to be maintained at the top of the program that documents the change
in detail.
Insertion/modification (Major)
* Begin DB01 give message based on if material is batch managed or not
IF w_xchpf IS INITIAL.
IF w_matnr IS INITIAL OR w_qty <= 0.
PERFORM z_clear_message_variables.
w_msgid = c_msgid.
w_msgno = c_000.
w_msgv1 = text-020.
w_screen = sy-dynnr.
PERFORM z_message_9099 USING w_msgid w_msgno w_msgv1
w_msgv2 w_msgv3 w_msgv4.
MOVE 'W_DESTB' TO w_current_field.
LEAVE TO SCREEN w_screen.
ENDIF
* End DB01 give message based on if material is batch managed or not

7.2.3 Dead Code
The term Dead Code refers to code that has been commented out due to modifications.
No Dead code should remain in a program, as this causes confusion when reviewing the
program. All commented code should be deleted, and SAP version management should be used
to refer to prior changes.
Page 38 of 44
7.2 The Standard Structure for ABAP Code.
SAP does not enforce a rigid coding structure within the syntax, and as a result we can place
elements in any section of a report. We should all develop using a common style so it will help
us navigate when modifications are being done to other team members code.
Declaration elements
TABLES
TYPES
DATA
CONSTANTS
PARAMETERS
SELECT-OPTIONS
RANGES
FIELD-GROUPS
FIELD-SYMBOLS
EVENTS
Event elements
INITIALIZATION
AT SELECTION-SCREEN
AT SELECTION-SCREEN ON VALUE-REQUEST FOR
START-OF-SELECTION
END-OF-SELECTION
TOP-OF-PAGE
END-OF-PAGE
Control elements
TOP-OF-PAGE DURING LINE-SELECTION
AT LINE-SELECTION
AT PFnn
AT USER-COMMAND
Sub-function elements
FORM
ENDFORM
Page 39 of 44
7.3 Program Comments
All initial declarations should contain definition and description comments to aid in future
maintenance. You should assume that support may need to be performed by someone with
limited understanding of the specification.
Within the data declaration area of your ABAP, you should describe the following:
Tables
INCLUDE code
Data Definition
Constants
Ranges
Select-Options
Parameters
Field-Groups
Dynpros
Field Symbols
Within the logic of your program, the following area needs to be documented with comments.
 Before each major section (ABAP events, forms and large code sections that perform a
definable task)
 Before small sections of code (20 or fewer lines of code that perform a definable task)
 Before any complex or unclear logic.
Renewed ABAP Guidelines

Before writing any Renewed ABAP syntax, it should be supported by inline comments.
Refer Below Examples:
While appending a record into an internal table, we can use below syntax. Before writing below
syntax we have write inline comments as below:
For checking the index of a record in internal table we can use below syntax which should be
supported by inline comments:
Page 40 of 44
7.4 Table TVARVC
When circumstances arise where variables need to be compared against a specific value
in a program,(ex: company code), hard coding must be avoided, and these values need to be
maintained in table TVARVC. TVARVC is an SAP provided table that allows for the storage of
variables that can be changed without having to modify the code. Transaction STVARV is
provided to maintain table TVARVC.
Page 41 of 44
7.5 Using Advanced features of Renewed ABAP
The new features of AS7.40/Renewed ABAP can be referred in ECC system using Tcode
‘ABAPDOCU’.
Page 42 of 44
7.6 Communication with Middleware
When coding interfaces utilizing BAPI’s or RFC’s, the standard BAPI return structure
BAPIRET2 should be used to provide a consistent look and feel when communicating to external
systems.
Valid message types available for use:
E = Error
I = Info
W = Warning
S = Success
Do not use type ‘A’ or abort as this is reserved for SAP only.
Page 43 of 44
Appendix A-Glossary
Document Revision History

Originator Effective Summary of Change
Daniel Bulka 04/13/2016 Rewritten for system alignment
Sumit Naik 05/15/2017 Updated to leverage renewed ABAP features for AS7.40 and
above
Daniel Bulka 8/13/2018 Added Middleware communication standards (section 7.6)
Page 44 of 44

SAP Global Technical Development Programming Standards

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP Global Technical Development Programming Standards

Uploaded by

Copyright:

Available Formats

SAP Technical Development

Programming Standards & Guidelines

NAMING CONVENTIONS FOR PROGRAM OBJECTS......................................................................................7

CHAPTER I. NAMING CONVENTIONS FOR DEVELOPMENT OBJECTS...................................................8

CHAPTER V. ERROR HANDLING........................................................................................................................32

DOCUMENT REVISION HISTORY......................................................................................................................43

Roles and Responsibilities

What this document does not cover

As a result, each program should be self-explanatory to another developer. Sufficient comments

Naming Conventions for Program Objects

To simplify the identification of custom-written programs and to prevent SAP from

Process Team Abbreviations

CHAPTER I. Naming Conventions for Development Objects

1.1 Naming Standard for Custom Developed Programs

Z XXX ‘_’ T ‘_’ ’MMM ( ‘_’ NNN) **

Examples: ZCTC_R_INVENTORY_REPORT = Inventory Report for CTC

1.2 Naming Standard for Customer Modified SAP Programs

Z ‘SAP’ ‘_’ [Name of SAP Program]

Examples: Original SAP Program RSSLGS00

SAPM Z XXX ‘_’ MMMM

1.4 Naming Standard for GUI Status & GUI Title

The naming convention for GUI Status is as follows:

NNN where NNN = screen number Example: 1000

The naming convention for GUI Title is as follows:

NNN where NNN = screen number Example: 1000

1.5 Naming Standard for CLASSES (ABAP OBJECTS)

Global Class Definition

ZCL ‘_’ ‘XXX’ ‘_’ MMM

Global Exception Class

ZCX ‘_’ ‘XXX’ ‘_’ MMM

Local Class Definition

LCL ‘_’ MMM

Local Exception Class

LCX ‘_’ MMM

Global Interface Definition

ZIF ‘_’ ‘XXX’ ‘_’ MMM

Local Interface Definition

LIF ‘_’ MMM

Example: IWA_STRUCTURE or RT_TABLE.

Example: GT_TABLE; MWA_STRUCTURE or CW_VARIABLE.

1.6 Naming Standard for Variants

1.7 Naming Standard for BDC Sessions

XXX ‘_’ ZZZZ ‘_’ NN

Example: CTC_VA01_01 – BDC session to execute transaction VA01

1.8 Naming Standard for Packages

Z XXX ‘_’ MMM

1.9 Program Variables Names

In-line Data Declaration.

No. Data Structure Standard Example

1.9.1 Work Variables

Example of global variable : W_TOTAL

Example of local variable : LW_TOTAL

Example of inline declared local variable: DATA(LW_TOTAL) = LIPS-KWMENG.

1.9.2 Work Area

Example of a global work area : WA_VBAK

Examples of inline declared local work area:

1.9.3 Internal Tables Naming Conventions

T_<name> Global Internal Table

Before 7.40 With 7.40

Variables DATA lw_text TYPE string. DATA(lw_text) = `...`.

Declaration of table DATA lwa like LINE OF ld_itab. LOOP AT lt_itab INTO DATA(lwa).

Declaration of actual DATA lw_a1 TYPE ... oref->meth( IMPORTING p1 = DATA(lw_a1)

Declaration of DATA lref_ixml TYPE REF TO if_ixml. DATA(lref_ixml) = cl_ixml=>create( ).

Example: CONSTANTS: C_RATE(4) TYPE N VALUE 1000.