sitemap
SAP ABAP DEVELOPMENT STANDARDS - page1
This document is the result of work sessions that were held to review the ABAP/4 programming standards suggested by SAP and available on ASAP.
These standards form a good basis for use however there were areas that were either missing from the documents or that needed to be made more specific
to our organization.
· Areas which we felt were well addressed in the SAP documents are not included in this document since it was not our intent to rewrite the complete
standards. However, this document addresses areas which were lacking or which needed improvement and as such this document should be the first point
of reference
FOR NEW DEVELOPMENT, THESE STANDARDS MUST BE ADHERED TO AT ALL TIMES AND SHOULD BE ENFORCED DURING
WALKTHROUGHS.
For changes to existing code, changes must comply to the new standards and should not rely on the old standards when the program was originally
developed; however should the introduction of new standards negatively impact the comprehension of the code, then the old standards should remain in
effect for that program.
An effort should also be made to bring existing code up to standards; Keep in mind that good judgment must prevail in this area as we should not spend
more time in cleaning the code than the actual enhancement…
ABAP/4 NAMING CONVENTIONS
PROGRAMS, FUNCTIONS, INCLUDES and REPORTS (1.1)
Naming conventions for programs have been upgraded so that the 4th character becomes more self-explanatory as to the function of the program.
NOTE: There are 2 exceptions to the above standard:
· SAP copied programs, functions, includes and reports, where the SAP name should remain with the first position changed to a “z” (e.g. SAP report
RVSAMPLE should be renamed to ZRVSAMPLE). This will allow easy identification of all program customizations when migrating to a new release.
· Module pools and module pool includes, used in online programming, which should follow their own naming conventions as defined in section 1.2
of the SAP naming conventions standards. As for module pool includes, you should let their names automatically generated by SAP.



Report Variant (1.6.2)
When an ABAP report is created, ABAP may generate some database-specific selections on the selection screen. Additional selection-screen criteria can also
be programmed into the report. In order to execute a report for a specific range of data or selection set, the selection ranges must be entered on the screen.
However, if there is a requirement to run the same report with the same selection set, especially in batch, a variant can be used to save that selection set. If a
variant is used, there is no need to enter the same selection set again each time the report is executed.
The maximum length of an ABAP variant is 14 characters. Report Variants should adhere to the following naming convention:
xxxxxxxxxxxxxx
x - Open (cannot contain the characters ‘&’ and ‘%’.)
Module Pool Names (1.6.3)
ABAP module Pools:
An ABAP module pool is an ABAP program that checks and processes what a user enters during a transaction. It is thus part of on-line programming. An
ABAP module pool groups together the modules that process common data. Module pool names can be up to 30 characters long and must begin with
‘SAPxZ’ (where x can be ‘U’ for update modules, ‘M’ for screen modules, ‘D’ for dialog modules, and ‘F’ for subroutine modules). The next character
represents the Module ID and the next two positions contain a numeric value. For ‘M’ type module pools, the last 20 characters of the program name should
be identical to the primary transaction code created for that module pool.

Remarks: It is strongly recommended that you use the ‘SAP Workbench’ to construct module pools. The SAP Workbench is designed to enforce standard naming conventions.
Dynpros (Screen) (1.6.4)
SAP screens are referred to as dynpros. Standard SAP components, such as transactions, menus and tables, contain dynpros and the associated processing logic. RDF
developer may also create customized dynpros.
The identification of a screen painter dynpro consists of an ABAP program name and a 4-digit dynpro number. The number range reserved for RDF dynpros should be between
9000 - 9999. The initial screen number for a given transaction should be 9000 and additional screens numbers increment by 10. This rule may not apply to screen exits where
screen numbers are defined by SAP in the enhancement.
Example
Module Pool: SAPMZF01
Screen #: 9000
GUI Status & GUI Title (1.6.5)
GUI Status
A GUI status is the main element of the Graphical User Interface. A GUI status can consist of the following: menu bar, standard toolbar, application toolbar and functions. A
GUI status is related to an ABAP program.
The GUI status should be limited to 4 characters, even though the system will allow a length of 20. The four characters are open to the developer.
Example
STND
Function Key
Function keys are part of the GUI status and are defined in the menu painter along with pushbuttons and menu items. SAP has certain standard settings for some function keys,
listed below:
F1 Help
F2 Choose
F3 Back (one step)
F4 Possible entries
F9 Select
F10 Jump to menu bar
F11 Save/Generate
F12 Cancel
Shift-F1 Print
Shift-F2 Delete
Shift-F5 Open
SAP also uses the following function keys for scrolling:
Shift-F9 First Page
Shift-F10 Previous Page
Shift-F11 Next Page
Shift-F12 Last Page
GUI Title
The GUI title name is limited to 20 characters, but the actual title bar can be up to sixty characters.
Example
INI
Messages (1.6.7)
Messages are used in ABAP programs to send information to the user. There are six different types of messages: information, warning, error, abend, exit and success.
A message consists of a 20 character message class and a 3 digit message number. The first character of the message class should be a ‘Z’ and the second character will contain
the Application Area code. The remaining 18 characters are open. The message number is open to any number between 000 and 999.
According to the naming conventions, only one message class can exist for each Application Area code. When a developer needs to create new message numbers, they need to
request a number range within a specific class from the DV team lead.
Example
Message Id ‘ZF’ Type ‘E’ Number ‘001’.
TABLES (1.8.1)
Small lookup tables (i.e. less than 1000 rows) can be maintained via SM30. However, one word of caution regarding the use of SM30; tables maintained using this transaction
code are very inefficient and most of all they hardly offer any data validation.
Tables maintained via SM30 require that the table maintenance dialog be generated. This can be done, once the table is created in the data dictionary, via Environment à Tab.
Maint. Generator and the one-step maintenance type is the recommended approach.
Table names should adhere to the following naming conventions:

All of the product names here are trademarks of their respective companies. The site www.allsaplinks.com no way affiliated with
SAP AG. We have made every effort for the content integrity. Information used on this site is at your own risk.
TRANSACTION CODES (1.4)
Transaction codes MUST be assigned to any batch ABAP program that may be run online by an end-user (e.g. function program or report program for a report
not listed in the generic report tree). This will eliminate the need for authorization groups with this type of program while the security will be controlled at the
transaction code level.
Transaction codes are created using transaction code SE93 and should adhere to the following naming conventions: