ABAP Development Standards and Guidelines-Secured-3

Development System Manual & Operating Procedure
mySAP Implementation
ABAP/4 Development
Standards and Guidelines
mySAP Solution
5th November 2007
Sample Document
Page 1 of 51
TABLE OF CONTENTS
1 OBJECTIVE .......................................................................................................5
2 PURPOSE ..........................................................................................................6
2.1 Intended audience .................................................................................................... 6
2.2 Objectives of standards/guidelines ......................................................................... 6
3 NAMING CONVENTIONS .................................................................................7
3.1 Program Names........................................................................................................ 7
3.2 Module Pools ............................................................................................................ 9
3.3 Modifications in Standard SAP Objects .............................................................. 10
3.4 Transaction Codes ................................................................................................. 10
3.5 Function Groups .................................................................................................... 11
3.6 Function Module Names ....................................................................................... 12
3.7 Data Declarations................................................................................................... 12
3.8 Data Dictionary Declarations................................................................................ 14
3.9 Table Types............................................................................................................. 17
3.10 Append Structures ................................................................................................. 17
3.11 Search Helps ........................................................................................................... 17
3.12 Message Classes...................................................................................................... 18
3.13 Package ................................................................................................................... 18
4 ABAP DESIGN STANDARDS........................................................................ 19
4.1 Code Reuse / Subroutines...................................................................................... 19
4.2 Subroutines............................................................................................................. 19
4.3 Function modules ................................................................................................... 19
4.4 Include Programs................................................................................................... 19
4.5 ABAP Program Layout ......................................................................................... 20
Page 3 of 51
4.6 Program Header..................................................................................................... 21
4.7 Program User Documentation - On-line Program Documentation for End

Users 21
4.8 Commenting ........................................................................................................... 22
4.9 Program Attributes................................................................................................ 24
4.10 ABAP/4 Security Programming ........................................................................... 25
4.11 Control Reports...................................................................................................... 26
5 ABAP PROGRAMMING TECHNIQUES ........................................................ 29
5.1 SQL.......................................................................................................................... 29
5.2 General Programming Techniques ...................................................................... 32
5.3 Logical Databases................................................................................................... 32
5.4 Debugging ............................................................................................................... 33
6 SAPSCRIPT TECHNIQUES ........................................................................... 34
6.1 Good Practice ......................................................................................................... 34
6.2 Standards ................................................................................................................ 34
6.3 Standard Texts ....................................................................................................... 34
6.4 Tips .......................................................................................................................... 35
7 CHANGING THE SAP STANDARD............................................................... 36
7.1 Originals and copies............................................................................................... 37
7.2 Corrections and repairs......................................................................................... 37
7.3 Modifications and upgrades.................................................................................. 37
7.4 Modifications Procedures...................................................................................... 38
7.5 Modifications Assistant ......................................................................................... 38
7.6 Restoring the original ............................................................................................ 39
8 APPENDIX 1 - ABAP REPORT CODE TEMPLATE ..................................... 41
9 APPENDIX 2 - CODE REVIEW CHECKLIST ................................................ 44
Page 4 of 51
1 Objective
The intent of this document is to provide a norm, structured approach to manage and
accomplish the development in SAP project implementation. This document provides a
standard technique and guidelines to ensure that development methodology and
developments are completed in time and within the permissible budget. The document
provides the framework from which a comprehensive plan for software development can
be accomplished. It also serves as a roadmap for a project management team and
developer to conceive, plan, act and deliver the best solution to a customer.
The goal of this document is to provide the development team with nomenclature to be
followed, adopted and practiced so as to deliver the quality development solution. This
will help the development team in planning, scheduling, monitoring and executing the
project in a most efficient manner.
Page 5 of 51
2 Purpose
This document provides the definitive list of development standards for use with SAP
R/3 system objects (ABAP code, table definitions, and data dictionary components). Aside
from defining the general programming standards the document also serves to detail
naming and programming style conventions.
Adherence to the standards defined within this document will promote a consistent,
robust and high quality development deliverable.
Objects not meeting these standards will not be migrated from the development instance.
This document should be read in conjunction with the development methodology
document.
2.1 Intended audience

It is aimed at analysts / programmers who are developing applications within the SAP
R/3. This includes new ABAP/4 programs and other environment objects, as well as
modifications to standard SAP R/3 objects when it is absolutely necessary to satisfy
business requirements and PROJECT management team has approved it.
2.2 Objectives of standards/guidelines

Programming and Naming standards within a project ensure that the output produced is:
Maintainable
Robust
Easy to enhance
Understandable
Efficient
Consistent
Page 6 of 51
3 Naming Conventions
This section describes the naming conventions that will be used for ABAP developments.
Further naming conventions and structuring standards can be found in SAP on-line
documentation.
During upgrade to a new release of a SAP system a new suite of standard ABAP objects is
supplied. This will certainly overwrite any modifications to SAP standard code but since
all client-specific code is prefixed with a Z or a Y these will remain intact.
3.1 Program Names

There are seven types of ABAP/4 programs, and current Project will use at least five types
namely:
Online Report programs
Module Pool programs
Function modules
Include Program
SAP scripts
NOTE: For Layout set naming convention – see section 6 later in the document
The standard naming convention for all executable reports will be:
ZXX_ DESC where
Z First character of the program
XX SAP R/3 module/component
DESC Short Description viz. INVANLYS or CRDOUTSTND
For example:
ZMM_INVANLY (Inventory Analysis report)
3.1.1 SAP R/3 Module components

XX Sub-component Not Applicable
Financials
AP Accounts Payable
AR Accounts Receivable
AA Asset Accounting
CO Controlling
CC Cost Centre Accounting
Page 7 of 51
CE Cost Element Accounting

EC Enterprise Controlling
GL General Ledger Accounting
PA Profit Centre Accounting
PC Product Cost Controlling
Logistics
IM Inventory Management
IV Invoice Verification
MM Materials Management
QM Quality management
PM Plant Maintenance
PP Production Planning
PO Purchasing
SD Sales and distribution
Human Resources
PA Personnel Administration
PD Personnel Planning and Development
PE Training and Event Management
PT Time Management
PY Payroll
3.1.2 Program Types

For ‘main’ programs, for example reports:
E Executable program
L Layout set
For program includes:
F Indicates a form routine containing sub-routines
T Indicates a TOP include containing data dictionary definitions
I Indicates standalone/other unclassified includes
3.1.3 Test Programs

In order to separate test programs from transportable modifications it will be necessary to
distinguish them via naming convention.
Page 8 of 51
ZTEST_DESC where
Z Client Specific Modifications
TEST Indicates a test program
DESC Short description depicting purpose of test program
In addition it should be noted that these objects will have the $TMP
development class being local objects only.
3.1.4 Utility Programs

From time to time it will be required to have utility programs in the test and production
environments. These need to be identified as utility programs and assigned to an
appropriate development class allowing them to be transported.
ZUTIL_DESC where
UTIL Denotes Utility Program
DESC Shortened Program Title
3.1.5 Interface Programs

From time to time it will be required to have interface programs, like BDC, data input etc.
in the test and production environments. This needs to be identified as interface programs.
ZXX_I_DESC, where
XX Module name ( e.g. FI)
I Interface
3.2 Module Pools

All Custom module pool ABAPs will be named using the following structure:
SAPMZXXDESC where
SAPMZ SAP Standard imposed start of module pool program
XX SAP R/3 module/component
DESC Short Description viz. Inventory report or MATMAST
E.g.
SAPMZMMIMPTDUTY.
Page 9 of 51
3.2.1 Dynpro Names

Dynpro screen number should be numeric, starting with 0100 with increments of at least
10.
3.2.2 Dynpro Titles

These should follow the name of the Dynpro except where the title is used for more than 1
screen.
3.3 Modifications in Standard SAP Objects

If a modification (instead of an Add-On or change to Business Practice) is necessary, then
as far as possible, the modifications should be done directly to the original source codes.
The exception would be if the changes were massive. In this case, the existing SAP
program should be copied out and the modifications made on the copied programs. For
modifications made directly to the original source codes, it should be done via the use of
INCLUDEs.
NOTE: The SAP modification assistant should be used in all cases without exception
3.3.1 Copy and Modify – include naming convention

Follow standard program naming convention identified in section 3.1 for program type I.
3.3.2 Customer Enhancements & projects

A project is a logical grouping for a number of customer enhancements, or areas for
customisation within the SAP standard code. The project controls whether an
enhancement is active or de-active and therefore has consequences for how standard
functionality operates.
Projects can be set up by developers or consultants and can be up to 10 characters long.
The convention should be:
ZXX_DESC where
Z initial bespoke identifier
XX logical name/identifier e.g. module/area name
DESC Meaningful description
3.4 Transaction Codes

All SAP transactions are listed in the table TSTC (Standard Transaction Codes).
All programs that can be run using transactions SA38/SE38 should be set up with a
transaction code. The main reasons are:
Page 10 of 51
Security Implications
Addition to Area Menus
Conformity with SAP standard
Z+19 Chars (descriptive name)

e.g. ZPROFIT_ANALYSIS Profitability Analysis Report transaction
However for ease of use it is recommended to keep them as short as possible, using the
R/3 standard method -
ZPRO Profitability Analysis Report
This, however, could depend on the number of custom programs and customer
requirements.
3.5 Function Groups

Each function module must belong to a function group. A function group should be used
to combine function modules that logically belong together. The naming convention for
function group is as follows:
ZXXyy where
XX is the SAP components (refer to above)
yy is the next alphanumeric number (in sequence)
The main program is generated as: SAPLZxxxx
It will contain 'include files' such as:
global data for all functions: LZxxxxTOP
first function created: LZxxxxU01
second function created: LZxxxxU02 etc.
Note:
1. The following function group naming conventions are to be used. If any below is
not applicable, then create one using the convention specified above.
Function Group Purpose
Z000 Function groups generic across

all application modules
ZFI00 General FI function groups
ZFC01 General FI Corporate function

groups
Page 11 of 51
3.6 Function Module Names

Function modules contain commonly used code. Functions are used frequently in ABAP
development. Because the calling syntax differs between Function modules and internal
program modules (CALL and PERFORM respectively), there is no need to provide a
function name qualifier to differentiate the module type.
The function name should always start with a 'Z_' to identify it as user defined. The rest
of the function name should consist of a few words that describe what it will do. When a
function is created, SAP automatically creates a main program to harbour this function
and all other functions in a common group. The main program name associated with the
function is assigned by SAP
Function names take the form:
Z_ DESC where
DESC Short Description viz. File Read, cost centre,
customer read external etc
For example
Z_ READFILE_EXTSYSTEM
Function modules should be used wherever possible to avoid

rewriting the same code.
Exceptions should always be defined in a function module.
Detail documentation about function module is a mandatory
requirement, wherein the purpose has to be documented in detail. It
needs to be checked with ABAP project lead and Project Manger.
3.7 Data Declarations

As a general guideline, the variable name should be as meaningful as possible. All
meaning should be in English. All Variable names defined in the program should be
commented to explain their use and preferably relate to dictionary field names.
Use Underscore ‘_’ and not hyphen ‘-’ character between other characters.
Where possible try to use locally declared variables rather than rely on global
variables
3.7.1 Parameter Names

Format: P_ + field name LIKE <data dictionary field> or TYPE <ABAP type>
where field name = ‘SAKNR’, ‘BUKRS’, ‘MATNR’, etc.
Use the LIKE option to refer to an SAP field where possible.
Page 12 of 51
3.7.2 Select Options

Format: S_ + field name FOR <table field>
where field name = ‘SAKNR’, ‘BUKRS’, ‘MATNR’, etc.
Use the FOR option to refer to an SAP field where possible
3.7.3 Non Structure Related Global Data Items

Format: G_ + field name LIKE <data dictionary field> or TYPE <ABAP type>
where field name = ‘SAKNR’, ‘BUKRS’, ‘MATNR’
Use the LIKE option to refer to an SAP field where possible.
3.7.4 Local Data Items to form or function

Format: L_ + field name LIKE <data dictionary field> or TYPE <ABAP
type>
Use the LIKE option to refer to an SAP field where possible
3.7.5 Constants
Format: C_ + field name LIKE <data dictionary field> or TYPE <ABAP
type>
Use the LIKE option to refer to an SAP field where possible
3.7.6 Field-Symbols
Format: <FS_ + descriptive name>
3.7.7 Types
Used to declare custom data definitions in an ABAP program
Format: TY_+ descriptive name
3.7.8 Internal Tables

To differentiate between the 3 types of internal table, use the following formats -
Standard IST_ + descriptive name
Page 13 of 51
Sorted/Index ISO_ + descriptive name

Hashed IHA_ + descriptive name
Each table must be declared with an associated work area for processing table entries. The
work area must have the same name as the internal table but have the prefix WA_.
Internal table work area WA_ + associated internal table descriptive name
Alternatively you may declare a structure and use that as a work area.
If you are unsure as to the type of internal table to use – please use
TYPE STANDARD TABLE … however DO NOT USE pre-4.0
internal table logic i.e. tables with header lines as this is out dated
and inefficient programming!
3.7.9 Internal Data Structures

Format: ST_ + descriptive name
3.7.10 Ranges
Format: R_ + descriptive name
3.7.11 Field Groups

Format: FG_ + descriptive name
3.8 Data Dictionary Declarations

Dictionary items to be created via SE11 transaction
3.8.1 External Tables Declarations

Use nomenclature ZXX_DESC
XX = SAP module name
DESC = Short description
The maximum suggested length for a field in the Data Dictionary is 15 characters. The
following section describes the requirements for the different tables and fields.
Transparent, Pool, INTTAB, and Cluster Tables:
The SAP data dictionary contains four types of data tables. The following naming
conventions will define the requirements for each of the different types.
Page 14 of 51
3.8.2 Transparent Tables:

Table type TRANS are reproduced 1:1 in the database that is each field is known to the
database. These types of tables are typically master data and transaction tables. The name
can be up to 16 characters (Z+15) in length.
3.8.3 Pool Table:

These are logical tables that must be assigned to a table pool when they are defined.
Pooled tables can be used to store control data (such as screen sequences or program
parameters). Several pooled tables can be combined in a table pool. The data of these
pooled tables are then stored in a common table in the database. Pooled tables can also
contain master and transaction data.
The grouping of tables containing a limited number of records in a table pool. Several
pooled tables are described logically in a pool definition in the data dictionary. The name
can be up to 16characters (Z+15) in length.
3.8.4 Cluster Tables:

These are logical tables that must be assigned to a table cluster when they are defined.
Cluster tables can be used to store control data (such as screen sequences or program
parameters). They can also be used to store temporary data or texts, such as
documentation. Cluster tables are also used to store large amounts of related data, like
IMG Chapters, change documents, processed items payments, conditions (procedure data)
etc.
Several cluster tables can be combined to form a table cluster. The data of the cluster tables
is then stored in a single common table cluster in the database.
Cluster tables contain no key field for the table name. Tables are typically System related
tables (relational table). The name can be up to 16 characters (Z+15) in length.
3.8.5 INTTAB Tables (Structures):

In the ABAP Dictionary the construction of the data produced when calculations are
carried out within programs or when data is transferred between programs can also be
defined globally. This is achieved by defining a structure. A structure is defined in the
ABAP Dictionary like a table and can then be addressed from ABAP programs. Any
change to the definition of the structure in the ABAP Dictionary is automatically
implemented in all programs.
While data in tables is stored permanently in the database, structures contain data only
during the runtime of a program.
Page 15 of 51
Structures are defined in (almost) the same way as tables. The only difference is that no
database table is generated. The same data elements and domains can be used in
structures as are used in tables and it is even possible to Include tables. As a result, it is
possible to achieve a high level of consistency of data definitions even in complex
programs which link data taken from several places.
Structures are used in particular for defining data at the interface between module pools
and screens and for standardising parameters for function modules.
Since structures that are used more than once are defined centrally, they can also be
changed centrally. These changes are then effected at all relevant points by the active
ABAP Dictionary.
Table types INTTAB have no records in the database. These types of tables are structures
shared across multiple ABAP programs. The maximum length of INTTAB tables is 30
characters.
3.8.6 Dictionary (SE11 object) Naming Standards

For new Transparent, Pool, and Cluster tables defined (non-standard SAP tables), the
following format is preferred:
DB Tables & Structures

Use nomenclature ZXX_DESC
XX = SAP module name
DESC = Short description
Example ZSD_PRICING, ZMM_PURCHASINGKEYS etc.
General Information
New control tables/DB tables must adhere to the above naming convention
standards. Control tables can be created by all members of the development and
process teams but should be contained in the specification package. Some SAP
objects violate the naming conventions. You can view these object names in table
TDKZ. These object names cannot be used for Customer Objects.
Note that all database tables should begin with client number defined in the MANDT
element.
The Project Manager, on the recommendations of the SAP

Development Lead, must approve any changes to the standard SAP
tables.
Page 16 of 51
3.8.7 Data elements & Domains

Where possible you should use the standard SAP data elements and domains. If you
require a new data element then it should be given a name, which is as meaningful as
possible. Try to limit the name to 11 characters maximum to ease maintenance; it is
possible to use 30.
Format: Z + (Max 29 chars)
3.8.8 Views
When defining a view use the following format: Z+descriptive name(max 12 chars) _V
e.g. ZEKETEKPO_V to name a database view that joins tables EKET & EKPO.
3.9 Table Types

These are used to define the set up of an internal table within an interface – for example
from function modules or for passing data between routines.
Format: ZT_+descriptive name
3.10 Append Structures

These are useful if you want to add new fields to a database table – for example a SAP
standard table, without having to actually request an OSS change ID !
Format: Z
<functional area>
_ descriptive name
e.g. ZMM_POEXTRAS
If there is more than 1 append with a similar/same name then you may wish to add a 2
digit _version number after the descriptive name.
3.11 Search Helps

The maximum size of a Search Helps object name is 30 Characters.
Format:
ZXXXXXXX
Example:
ZADD, Z123
Page 17 of 51
3.12 Message Classes

Application area or team message classes should be maintained.
Format Z x (+19 characters)
Z SAP Standard for Client Modifications
x Unique Meaningful Identifier
An alternative to using a custom message class is to use message 010 from message class
AD with text elements.
e.g. message E010(AD) with text-e01.
3.13 Package
The purpose of a package is to define the development and production SAP R/3 systems
for a set of programs.
All development work for a particular stream will be assigned to the same package. Only
objects that are non-specific should be assigned to the interface, basis or security classes.
ZXXn where
Z= fixed first character
XX = SAP R/3 Component as defined earlier
N= sequential next number 01,02,03 etc
The following classes have been created in development client 230:
Package Description
ZSD01 Sales and Distribution Development
ZMM01 Materials Management Development
ZPM01 Plant Maintenance Development
ZPP01 Production Planning Development
ZQM01 Quality Management Development
ZHCM01 Human Capital Management development
ZFI01 Financials Development
ZCO01 Controlling Development
Notes:
For any temporary test objects which are not supposed to be transported over to
the production environment, please use ‘Local Private Object - $TMP’.
The following development classes are to be used. If any below is not applicable,
then create one using the above convention.
Page 18 of 51
4 ABAP Design Standards

This section describes guidelines for the best practice approach to design and
implementation of ABAP Code.
4.1 Code Reuse / Subroutines

Taking into account the reuse of code during the design stage can save a considerable
amount of work effort. This section describes the different options available for the reuse
of code. When designing and coding programs these options should be fully utilised.
4.2 Subroutines
Subroutines should be used to ease the creation, readability and maintainability of ABAP
programs. (Note: A report can call a subroutine from another report – e.g. PERFORM
new_routine (zmyprog)). It is recommended that a subroutine library be developed for
use in later development.
4.3 Function modules

As noted earlier SAP provides a standard function library, which should be utilised. The
functions provided support exception handling. New function modules can also be added
to the library. A list of function modules can be found by selecting Development >
Function modules from the ABAP Program Development: Initial screen.
While considering creating a new function module always consults your Team Leader,
there may well be a function group you should put your new module into. DO NOT
insert your new function module into a standard SAP function group or an existing
bespoke function group that you know nothing about. If you create a syntax error in a
function group this will render the entire function group inactive, and could have serious
consequences.
All programs should include a case statement on the return code of a function module
(SY-SUBRC) to handle errors encountered.
4.4 Include Programs

An INCLUDE program is a program that does not run on its own, it contains sections of
program code used by different reports such as data declarations shared by several
reports. INCLUDE programs serve to modularise program source code and thus help to
enhance the readability and maintainability of the code.
Where possible the use of INCLUDES should be considered within the design especially
when there is a high degree of technical complexity and provision for re-use of code. For
example a report may have a main executable program and 2 includes:
Page 19 of 51
Main executable program e.g. ZEMM_R001_01_E01

TOP include for data definitions e.g. ZEMM_R001_01_T01_01
Include for form routines e.g. ZEMM_R001_01_F01_01
For example:
ZEMM_R001_01_E01
ZEMM_R001_01_T01_01 ZEMM_R001_01_F01_01
4.5 ABAP Program Layout

The goal of structuring an ABAP program is to facilitate post build maintenance.
Invariably this will be undertaken by someone other than the original author , it is
therefore imperative that a clear consistent approach be taken. This section details the
guidelines that should be taken with all ABAP programs and should be used in tandem
with the standard ABAP template supplied with these standards. The template is held
locally in program TO BE INSERTED!
Always utilise the events START-OF-SELECTION & END-OF-SELECTION even if logical
databases are not being used. These events serve to highlight the MAIN part of the
program, these should contain the major SELECT groups and display to any programmer
the key processes of the program.
The Pretty printer formatting command can be used to automatically format code for
neatness and readability. The following structure should be followed as a guide to event
and section sequencing:
Header Declarations
PROGRAM STATEMENT
COMMENT BLOCK
TABLES
TYPES
CONSTANTS
STRUCTURE DEFINITIONS
INTERNAL TABLE DEFINITIONS
FIELD-GROUPS and FIELD-SYMBOLS
DATA
PARAMETERS and SELECT-OPTIONS
Page 20 of 51
Processing Block
INITIALIZATION
AT SELECTION-SCREEN
START-OF-SELECTION
GET (if using logical databases)
END-OF-SELECTION
Interactive Events
AT LINE-SELECTION
AT PFnn
AT USER-COMMAND
Page Controls
TOP-OF-PAGE
END-OF-PAGE
Subroutines
FORMS
4.6 Program Header

All ABAP programs, copies of SAP standard programs, function modules, reports and
includes must use a standard program header. The format of this header should be in the
format shown in the header section of the ABAP template in the appendix. The purpose
of the program must be documented within the header.
The program header is also used to document changes within the program and to serve as
a reference point to navigate around the changes. Each additional change should be
logged with a transport request number and a unique identifier. In this case of application
of OSS notes it is imperative that the OSS Note Number be used to document the changes.
This will aid in determining the program changes need to be re-implemented during a
version upgrade.
4.7 Program User Documentation - On-line Program

Documentation for End Users
Program user documentation applies only to on-line reports/programs. The aim is to
provide a comprehensive description of the function of the ABAP program and details on
execution.
Page 21 of 51
Documentation is developed using the SE38 ‘Documentation’ option and will generally be
based on the details from the functional specification(M30) document. A program should
not be signed off as complete until the documentation is completed.
A description of the program should be maintained on-line using the Goto -> Program
Doc. pull down menu in the ABAP/4 editor. (The difference between this form of
documentation verses comments in the program is that the target audience for this is the
end-user whilst the latter is for the developer/maintainer).
This On-line End User documentation must be done. User common end user language
but add enough technical details to allow users to use the program.
Use the following template for end user documentation:
Purpose: Describe the purpose of the program in detail.
User parameters: Describe the user parameters the program expect and process.
Timing: Describe how often or when the program should be run.
4.8 Commenting
Always provide extensive commenting to support future maintenance of your ABAP
code. Commenting should explain complicated areas of logic and should give guidance to
the logical ‘flow’ within a program. When deciding ‘how much is enough’ imagine what
degree of commenting you would like to quickly understand a program that you have not
written.
Where the program code can be clearly and concisely explained in line comments they
should be used above separate line comments, as they will not be as easily separated from
the code to which they relate. Line comments should be spaced out from the right hand
side of the statement to a consistent point where they do not interweave with the
programming code.
Where this is not possible the comment should be on a separate line preceding the
statement using a ‘comment block’ for lengthy comments (more than 3 lines).
**********************************************************
* 001+
* Modification to check the currency values etc etc
**********************************************************
Code Change…………
**********************************************************
* end of 001+
FORM statements should always include a comment block to describe the function
supported and the parameters passed to and from the routine.
Page 22 of 51
4.8.1 Comments for a change to a program

This is one of the most important places for comments. Care should be taken to ensure
that your comments highlight the changes that you have made against the original
program.
For example:
**************************************************************************************
* CHANGE HISTORY
* Mod Date Changed By Description Chng ID
* 29/03/2000 DONOVAR Addition of select options 001
* Change control 70
**************************************************************************************
*------------------------------------------------------------------
* SELECT-OPTIONS and PARAMETERS
*------------------------------------------------------------------
select-options: s_kunnr for knvp-kunnr "001+ Sold-to Party
obligatory, "001+
s_vkorg for knvp-vkorg "001+ Sales Org
obligatory, "001+
s_vtweg for knvp-vtweg "001+ Distribution Chan
obligatory, "001+
When:
Adding a new line of code, use the Change ID with a '+' symbol - e.g. '001+';
Removing a line of code, comment out the line of code & use the Change ID with a
'-' symbol - e.g. '001-';
Amending a line of code, remove the line and add the new code below following
the guidelines for adding and removing code (see above)
Adding or removing a large amount of code, it may be necessary to insert a header
area with a comment of what has changed.
Remember to always ensure that comments are included along with the Change ID and
symbol. The Change ID is a number starting at 001 and incrementing by one for each
change. Lines should rarely be physically deleted from the program (this is un-auditable
and you might want it back).
Note however in order to maintain the readability of code it may be necessary to remove
extraneous commented out code. Only seek to remove the redundant code when
development unit test is complete.
Page 23 of 51
4.9 Program Attributes
The following is a checklist of the fields which must be set
FIELD COMMENTS
Type I - Include modules

F - Function modules
M - Module pool/screen painted transactions
1 – Executable
S – Subroutine Pool
Status K - Customer Production Report

T - Test Report
Application V - SD, F- FI, M-MM, C – PPC
Class All Reports must be assigned to a report class

defined in table RCL.
Authorisation All Reports must have an authorisation group

specified.
Logical Database Since this controls the access path to the data. You
must ensure that you are using the correct logical
database for optimal performance
Selection Screen If you do not specify a screen number here, the

system automatically creates a selection screen
derived from the data base selection criteria and
the report-specific parameters and selection
options.
Locked for Editor DO NOT FILL THIS FIELD IN.
Fixed Point Arithmetic Complete this if you are doing fixed-point

arithmetic. Should be set in almost circumstances.
Start via variant If you set this attribute, the user can only start your
report via a variant. You must therefore have
created at least one variant.
Page 24 of 51
4.10 ABAP/4 Security Programming

In order to develop a feasible security strategy it is necessary to consider the implications
of the three approaches to implementing security within ABAP/4. The approaches taken
are dependant upon the requirement; certainly a security strategy involving preclusion of
certain data from a report such as sensitive HR data would almost certainly necessitate
embedding authorisation objects within the code. Alternatively prevention of access to
data can be gained through prevention of access to the reporting function itself. This can
be achieved through converting the ABAP program to a transaction code and utilising the
authorisation facilities to determine access rights.
Transaction Codes
Transaction codes can be assign authorisation objects directly and as such are the most
convenient method of securing software. In order to further secure the program ensure
that the user is denied access to SE38 and SA38. Transaction codes should be used to
prevent access to the program entirely.
Authority Check
Embedding authority checks within programs enables direct control of data access, in this
way it is possible for a whole department to utilise a report but have data excluded for
certain individuals. Note this method can be used to prevent access to the program code
entirely, such as in an exit program.
In addition it’s important that the authority group is defined and that the field to be
checked is also determined.
AUTHORITY-CHECK OBJECT 'object_id '
ID ’ ’ FIELD ‘ ’
Authorisation Group Attribute

The third type of authority check is to utilise the authority group on the program attributes.
This group setting can be tied in with an authority group and prevent access to the ABAP
program from SE38/SA38.
4.10.1 Authorization Profile Naming

Z:sxxxxxxxtt where
Z = fixed first character of the program
s = SAP R/3 components
xxxxxx = any meaningful 6 characters that defines the profile
tt = numbers for different profiles with the same objects but with different
field values
NB: You need not use all 12 characters, ytt are the last 3 characters of your profile name
Page 25 of 51
4.10.2 Authorization Object and Field Naming
ZXXxxxxxxxx where

XX = SAP R/3 components
xxxxxxxx = any meaningful 8 characters that defines the object / field
4.10.3 Authorization Name Naming
Z:sxxxxxxxxy where
s = SAP R/3 components
xxxxxxxx = any meaningful 8 characters that defines the object / field
y = A (all), D (display only), C (create only), E (Change
only), T (delete only), L (list display), B (block)
4.11 Control Reports

Control Reports must be generated for all batch programs. Each control figure should be
derived and NOT computed e.g. for computing total number of records processed, total
number of good records and total number of bad records, maintain 3 counters rather than
maintaining only 2 and deriving the 3rd from the other 2. Control figures can also be for
amount fields i.e. not only for record count.
Wherever possible, for interface files, include a control total record in the output file itself.
This is to enable the interfacing system to read the control total record and perform its own
reconciliation. An example of when this might not be feasible is when there are constraints
imposed by the interfacing system.
Examples of Control Reports:
Total Selected = A
PR = A1
WR = A2
SR = A3
Others = A4
Total No. of Records Created = B
PR = B1
WR = B2
Page 26 of 51
SR = B3
Errors = B4
where A = A1 + A2 + A3 + A4
B = B1 + B2 + B3 + B4
A1 + A2 + A3 = B1 + B2 + B3 + B4
Total Records Read =A
Total Error Records =B
Total Good Records =C
where A = B + C
Total No. of Records Processed for 1Q 1995 =A
No. processed for January = A1
No. processed for February = A2
No. processed for March = A3
Total No. of Error Records =B
Error records for January = B1
Error records for February = B2
Error records for March = B3
Total No. of Records Selected =C
Selected for January = C1
Selected for February = C2
Selected for March = C3
where A = A1 + A2 + A3
B = B1 + B2 + B3
C = C1 + C2 + C3
A=B+C
Total No. of Records Processed for dd.mm.yyyy = A
Total No. of Records Processed = A
BEDOK = A1
HAWK = A2
:
: = An
where A = A1 + A2 + .... An
Page 27 of 51
No. of Records Amount

Active Payroll a $x
NSMen Payroll b $y
Total a+b $(x+y)
4.11.1 BDC Names
Format Z_XX_I_meaningful name where,

XX Application identifier
4.11.2 Batch Job Name
Format Z_meaningful name_sequence
Page 28 of 51
5 ABAP Programming Techniques
This section contains guidelines on programming techniques, it is by no means exhaustive

and should be used in conjunction with the SAP help – for example see transaction SE30
and programming tips section.
5.1 SQL
In order to enhance the performance of your ABAP code a number of useful guidelines can
be used.
• Use SELECT SINGLE wherever possible to retrieve up to one row of information. It is
important to specify all the key fields to ensure a unique record.
• Be careful using the FOR ALL ENTRIES addition since this is very bad for very large
datasets (10,000+ records)
• Joins and subqueries are good
• Do not use SELECT * statement unless the program needs ALL columns from the
table. Instead, only specify the fields you require. This will also avoid unnecessary
network transports. The addition INTO CORRESPONDING FIELDS of the INTO
clause of the SELECT statement is worthwhile to use only for large amounts of data
where the external table and destination fields have the same names. Consider the use
of the DISTINCT option in the case of many duplicate entries.
The following example compares selecting all fields to selecting only the document
number, the item number and the material.
Avoid:. select * from vbap
where vbeln in s_docno.
….
endselect.
Use: select vbeln posnr matnr
into (wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr)
from vbap
….
endselect.
Important Points:
Page 29 of 51
The order of the fields retrieved must match the order of the destination fields in the field
list.
• Use the SELECT...WHERE clause to restrict data rather than retrieve all rows and use a
CHECK or IF statements to filter data.
Avoid: select vbeln posnr matnr
from vbap.
check s_docno.
….
endselect.
Use: select vbeln posnr matnr
from vbap
….
endselect.
Important Points:
Order the columns in the where clause of a select in the same order as the key or index
table.
• WHERE Clause Tips
o Exploit the indexes of the database tables for an efficient use of the WHERE
clause. To do so check all index fields with the equality operator (EQ, =) and
concatenate these checks by AND. The primary key of a database table makes up
its primary index automatically. Secondary indexes for a database table can be
created in the ABAP Dictionary.
o If possible, include all columns of the key or an index in the where clause. Use a
default or appropriate value. If the column(s) is not included, the database may not
be able to fully utilise the index.
o Avoid complex WHERE clauses. The system must split up those into single
statements for the database system.
o Do not use the logical NOT in WHERE clauses but inverted operators instead. The
logical NOT is not supported by the database indexes.
• Try to avoid the select … endselect programming construct. Rather select all the
required records from the database directly into an internal table and loop at the table
to process the entries. This is usually faster than the select … endselect code, and also
allows easier debugging of the code.
Avoid: select vbeln posnr matnr
Page 30 of 51
from vbap
write:/ wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr.
endselect.
Use: select vbeln posnr matnr into table ts_vbap
from vbap
loop at ts_vbap into wa_vbap.
write:/ wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr.
Endloop.
• Avoid nested select statements if possible as they generally have poor performance. It
is preferable to select all the entries for each table directly into an internal table and use
nested internal table loops to process all the entries.
• Check runtime analysis tips and tricks for detailed comparisons in select performance
(SM30). SELECT statements.
• Use aggregate expressions in the SELECT clause to perform calculations instead of
transporting great amounts of data and calculating thereafter. This distributes the
processing load and minimises the network data transfer. Valid aggregate functions
include: MAX, MIN, AVG, SUM and COUNT.
• The storage of database tables in local buffers can lead to significant time savings. Use
the buffering of database tables whenever possible. Use the addition BYPASSING
BUFFER only if it is really necessary.
If DISTINCT, SINGLE FOR UPDATE, and aggregate expressions are used in the
SELECT clause, buffering should be turned off.
• Provide the appropriate selection criteria to limit the number of data base reads. Force
users to provide selection criteria by evaluating the selection criteria entered on the
selection screen during the AT SELECTION-SCREEN event.
• Create indices where needed to enhance query performance. This should be used in
large table lookups to increase efficiency. For example, SELECT…WHERE FieldA =
‘001’. In this case FieldA is not a key field, therefore an index should be created to
improve the efficiency of the select statement. Beware that there is always an
additional processing system overhead for indices. Therefore, only create indices if a
major performance benefit will be realised, especially if the program concerned is
executed many times throughout the day and is business critical.
5.1.1 SQL Checklist

• Keep the selected dataset small
• Keep the transferred data small
• Keep the number of database accesses small
• Use database buffers
Page 31 of 51
• Create views for table joins instead of using multiple selects.

• Select data only one time where possible (i.e., don’t have multiple selects against the
same table - get the data one time and store it in an internal table).
• Remove unused indexes from tables.
5.2 General Programming Techniques
Detailed below are a number of additional programming techniques that should be borne in
mind when implementing ABAP code.
• When testing fields "equal to" something, one can use either the nested IF or the CASE
statement. The CASE is better for two reasons. It is easier to read and the
performance of the CASE is more efficient.
• Do not use MOVE CORRESPONDING unless the data is contiguous.
• When records a and b have the exact same structure, it is more efficient to MOVE a TO
b than to MOVE-CORRESPONDING a TO b, if records a and b have the exact same
structure.
MOVE BSEG TO *BSEG. is better than
MOVE-CORRESPONDING BSEG TO *BSEG.
• Do not use the COLLECT statement with large internal tables as this can be very CPU
intensive.
• When reading a single record in an internal table, the READ TABLE WITH KEY is not
a direct READ on a on a sorted table. Therefore, SORT the table and use READ
TABLE WITH KEY BINARY SEARCH.
• Use the SORT...BY when sorting internal tables.
SORT ITAB BY FLD1 FLD2. is more efficient than
SORT ITAB.
• Avoid hard-coding and use of literals in ABAP code. Use reference tables to drive
processing to support business change flexibility and reduce ongoing maintenance
costs. If hard-coding and literals are required, be sure to include these as constants.
• The Tips & Tricks function is very useful in comparing different methods of coding
without going to the trouble of coding both and then performing your own run-time
analysis. System > Utilities > Runtime Analysis > Tips & Tricks.
5.3 Logical Databases
Use logical databases and ‘GET’ events wherever reads on parent/child segments need to
be performed e.g. require data from both MARA then MARD table - use GET MARA then
GET MARD. (Note you do not need to use an LDB if data from only the MARA or MARD
table is required.)
Page 32 of 51
Where an LDB is used provide defaults or checks for the standard selection-
options/parameters wherever possible.
Avoid use of logical data bases as much as possible - use SELECT statements instead.
(Logical databases are good as a reference tool to look up database hierarchies).
Logical database should only be used when there are no other

options.
Use of Logical database in ABAP programs must be approved by a
DEVELOPMENT TEAM LEAD
Due to strategic importance of LDB’s and the potential impact on
system performance, careful consideration should be made before
creating new LDB’s. Consequently no LDB’s should be created
without approval from the Development Team Lead
5.4 Debugging
When testing ABAP, use of the debugging tool plays an essential role in checking the
value of variables during the execution of the program. This tool should be used during
the unit testing to ensure programs are executing as desired.
You can use the debugging tool by selecting Program > Debugging from the ABAP
program Development Initial screen.
In addition to the static programming of breakpoints, ABAP’s on-line debugging tools also allow
you to set breakpoints and interrupt conditions dynamically. This makes the whole process of
debugging reports much more flexible and the consequent advantage is that you do not have to
change your code. Watchpoints can now be set based on the value a field takes (like R/2).
Once you have stopped the report processing, you can view the contents of all the fields
(up to 8), internal tables and database tables referenced in the report. The system fields
SY-TABIX and SY-DBCNT are now displayed at the bottom of the screen along with SY-
SUBRC.
Finally, you can change the contents of fields for debugging purposes and then resume
report processing, with the changed data. To set breakpoints select Breakpoints > Set from
the ABAP: Editor screen. Then execute the program.
Beware that in order to debug SAPscript programs, hard-coded breakpoints are often
required. Be sure to remove these once testing is complete and the program transported.
Use the syntax BREAK username, rather than BREAK-POINT, as this will ensure the code
only stops when running under the specified username.
Page 33 of 51
6 SAPscript Techniques
6.1 Good Practice
• Always copy the SAP standard print programs where available and, in most instances,
the layout set. Never start a complex SAPscript (e.g. Invoice, Purchase Order) from the
beginning, as this will require far more development time to complete.
• When creating a new layout set by copying a SAP standard, always change the
original language from D to E and then activate.
6.2 Standards
• Naming convention for layout sets – this will follow the same as the program name,
except the version number will be prefixed L. For example a purchase order layout set
would be:
ZMM_DESC where
MM SAP R/3 module/component
DESC Meaningful description i.e. PO printing, INVOICE.
• When copying SAP standard print programs ensure they have a standard header
block as defined earlier. Also ensure that any code that is added, removed or changed
is commented in the standard fashion.
6.3 Standard Texts
• These should be of the following format:

ZXX_DESC
Where:
XX Module name
DESC Meaningful description.
Page 34 of 51
6.4 Tips
• Text elements must be maintained individually for each layout set language. Any
other changes to the layout set i.e. window size or paragraphs, will be copied from the
original language to the other languages.
As layout sets are client-dependant they must be ‘transported’

between clients on the same box. To do this use the ‘Copy from
Client’ function from within the ‘target’ client. This is language
specific.
Always ACTIVATE the layout set each change and in each language
before transporting.
The SAPscript debugger can be sent useful, this is turned on at the
front screen on transaction SE71.
Standard text used within a layout set must be assigned to a
transport request using the program RSTXTRAN. Once assigned the
transport request can be released in the usual manner via SE10.
Page 35 of 51
7 Changing the SAP Standard

• You can adjust the R/3 System to meet your needs in the following ways:
o Customizing: This means setting up specific business processes and functions for
your system according to an implementation guide. The need for these changes
has already been foreseen by SAP and an implementation procedure has been
developed.
o Personalization: This means making changes to certain fields' global display
attributes (setting default values or fading fields out altogether), as well as creating
user-specific menu sequences.
o Modifications: These are changes to SAP Repository objects made at the customer
site. If SAP delivers a changed version of the object, the customer's system must be
adjusted to reflect these changes. Prior to Release 4.0B these adjustments had to be
made manually using upgrade utilities. From Release 4.5A, this procedure has
been automated with the Modification Assistant.
o Enhancements: This means creating Repository objects for individual customers
that refer to objects that already exist in the SAP Repository.
o Customer Developments: This means creating Repository objects unique to
individual customers in a specific namespace reserved for new customer objects.
• If your requirements cannot be met by Customizing or personalization, you may either
start a development project or try using a CSP solution (= Complementary Software
Product).
• A development project falls into the customer development category if the SAP
standard does not already contain functions similar to the one you are trying to
develop. If, however, a similar SAP function exists, try to assimilate it into your
development project by either enhancing or modifying it, by using a user exit, or
simply by making a copy the appropriate SAP program.
• Modifications can create problems, as new versions of SAP objects must be adjusted
after an upgrade to coincide with modified versions of SAP objects you have created.
Prior to Release 4.0B these adjustments had to be made manually using upgrade
utilities. From Release 4.5A, this procedure has been automated with the Modification
Assistant.
• Thus, you should only make modifications if:
• Customizing or personalizing cannot satisfy your requirements
• Enhancements or user exits are not planned
• It would not make sense to copy the SAP object to the customer namespace.
Page 36 of 51
7.1 Originals and copies
• An object is original in only one system. In the case of objects delivered by SAP, the
original system is at SAP itself. These objects are only copies in customer systems.
This applies to your development system and all other systems that come after it.
• If you write your own applications, the objects that you create are original in your
development system. You assign your developments to a change request, which has
the type Development/Correction.
This request ensures that the objects are transported from the development system into
the subsequent systems
7.2 Corrections and repairs
• Changes to an original are called corrections. They are recorded in a change request
whose tasks have the type "Development/correction".
• If, on the other hand, you change a copy (an object outside its own original system),
the change is recorded in a task with the type "Repair". Repairs to SAP objects are
called modifications.
• When you repair your own objects (for example, if something goes wrong in your
production system), you can correct the original in your development system straight
away. When you change copies, you must correct the original immediately!
• However, you cannot do this with SAP objects, because they are not original in any of
your systems.
• You should only modify the SAP standard if the modifications you want to make are
absolutely necessary for optimizing workflow in your company. Be aware that good
background knowledge of application structure and flow are important prerequisites
for deciding what kind of modifications to make and how these modifications should
be designed.
7.3 Modifications and upgrades
During an upgrade or an import of R/3 Support Packages, new objects delivered overwrite
existing objects of the SAP standard. In order to help customers keep those objects that have
been modified in a previous release, SAP now offers upgrade adjustment for all objects being
upgraded in the form of transactions SPAU and SPDD. These transactions allow customers to
enter their modifications into the corresponding new objects being delivered at upgrade. The
Modification Assistant supports this process of adopting customer modifications. In general,
objects altered using the Modification Assistant can now be automatically accepted into the
upgraded system if the modifications undertaken in the original version do not directly overlap
those made in the customer version. If collisions occur between the two versions at upgrade
Page 37 of 51
(naming collisions, or if SAP has deleted an object modified by a customer), the system offers
semi-automatic adjustment support. In some cases, however, you may still have to manually
adjust objects using ABAP Workbench tools.
• Whenever you upgrade your system, apply a support package, or import a transport
request, conflicts can occur with modified objects.
• Conflicts occur when you have changed an SAP object and SAP has also delivered a
new version of it. The new object delivered by SAP becomes an active object in the
Repository of your system.
• If you want to save your changes, you must perform a modification adjustment for
the objects. If you have a lot of modified SAP objects, your upgrade can be slowed
down considerably.
• To ensure consistency between your development system and subsequent systems,
you should only perform modification adjustments in your development system. The
objects from the adjustment can then be transported into other systems.
7.4 Modifications Procedures
• A registered developer must register changes to SAP objects. Exceptions to this

registration are matchcodes, database indexes, buffer settings, customer objects,
patches, and objects whose changes are based on automatic generation (for example, in
Customizing). If the object is changed again at a later time, no new query is made for
the registration key. Once an object is registered, the related key is stored locally and
automatically copied for later changes, regardless of which registered developer is
making the change. For the time being, these keys remain valid even after a release
upgrade.
• How do you benefit from SSCR (SAP Software Change Registration)?
o Quick error resolution and high availability of modified systems
All objects that have been changed are logged by SAP. Based on this
information, SAP's First Level Customer Service can quickly locate and fix
problems. This increases the availability of your R/3 system.
o Dependable operation
Having to register your modifications helps prevent unintended modification.
This in turn ensures that your R/3 software runs more reliably.
o Simplification of upgrades
Upgrades and release upgrades become considerably easier due to the smaller
number of modifications.
7.5 Modifications Assistant
The aim of the Modification Assistant is to make modification adjustments easier. This is
because (among other reasons) the modifications are registered in a different layer
Page 38 of 51
• If you want to change an SAP object, you must provide the following information:
o SSCR key
o Change request
• The system informs you that the object is under the control of the Modification
Assistant. Only restricted functions are available in the editor.
• You can switch the Modification Assistant on or off for the entire system by changing
the R/3 profile parameter eu/controlled_modification. SAP recommends that you
always work with the Modification Assistant.
• You can switch off the Modification Assistant for single Repository Objects. Once you
have done so, the system no longer uses the fine granularity of the Modification
Assistant.
• In modification mode, you have access to a subset of the normal editor tools. You can
access these using the appropriate pushbuttons. For example, in the ABAP Editor, you
can:
o Insert
The system generates a framework of comment lines between which you can enter
your source code.
o Replace
Position the cursor on a line and choose Replace. The corresponding line is
commented out, and another line appears in which you can enter coding. If you
want to replace several lines, mark them as a block first.
o Delete
Select a line or a block and choose Delete. The lines are commented out.
o Undo modifications
This undoes all of the modifications you have made to this object.
o Display modification overview
Choose this function to display an overview of all modifications belonging to this
object.
7.6 Restoring the original

You can reset all of the modifications that you have made to the current object using the
Modification Assistant by choosing this function. The record of the modifications is also
deleted.
Remember that you cannot selectively undo modifications to an object. You can only undo
modifications based on the "all or nothing" principle.
Any modifications in standard SAP object will require proper

justification and needs to be documented. The rights of
modification the standard SAP object is limited to PROJECT
MANGER only.
Page 39 of 51
APPENDICES
Page 40 of 51
8 APPENDIX 1 - ABAP Report Code Template
REPORT ZTEMPLAT.
* NO STANDARD PAGE HEADING. "Switches off standard heading
* LINE-SIZE nnn. "Line is nnn characters
* LINE-COUNT pp. "Page has pp lines
*****************************************************************************************
* PROGRAM: xxxxxxxx *
* *
* Copyright (C) and all other rights in this program *
* are reserved by xxxxxxxxxxxxxxxxxxxxxxxxxxxx *
* *
* TITLE: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx *
* *
* AUTHOR: I.Surname DATE: xx/xx/xxxx *
* *
* DESCRIPTION: *
PROGRAM
* xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx * HEADER
* xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx *
* xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx *
* *
*****************************************************************************************
* CHANGE HISTORY *
* *
* Mod Date Changed By Description Chng ID *
* xx/xx/xxxx xxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxx *
* *
****************************************************************************************
*-----------------------------------------------------------------------------------------------------*
* EXTERNAL TABLE DECLARATIONS *
*-----------------------------------------------------------------------------------------------------*
*-----------------------------------------------------------------------------------------------------*
* TYPES *
*-----------------------------------------------------------------------------------------------------*
Page 41 of 51
*-----------------------------------------------------------------------------------------------------*
* CONSTANTS *
*-----------------------------------------------------------------------------------------------------*
*-----------------------------------------------------------------------------------------------------*
* STRUCTURE DECLARATIONS *
*-----------------------------------------------------------------------------------------------------*
*-----------------------------------------------------------------------------------------------------*
* INTERNAL TABLE DECLARATIONS *
*-----------------------------------------------------------------------------------------------------*
*-----------------------------------------------------------------------------------------------------*
* FIELD GROUPS & FIELD SYMBOLS *
*-----------------------------------------------------------------------------------------------------*
*-----------------------------------------------------------------------------------------------------*
* VARIABLE DECLARATIONS *
*-----------------------------------------------------------------------------------------------------*
*-----------------------------------------------------------------------------------------------------*
* SELECT-OPTIONS AND PARAMETERS *
*-----------------------------------------------------------------------------------------------------*
*-----------------------------------------------------------------------------------------------------*
* INITIALIZATION EVENT - processing prior to selection screen *
*-----------------------------------------------------------------------------------------------------*
INITIALIZATION.
*-----------------------------------------------------------------------------------------------------*
* AT SELECTION-SCREEN EVENTS - validate user input *
*-----------------------------------------------------------------------------------------------------*
AT SELECTION-SCREEN.
* -------- S T A R T O F M A I N P R O C E S S I N G -------- *
*-----------------------------------------------------------------------------------------------------*
* START-OF-SELECTION - start of database access *
Page 42 of 51
*-----------------------------------------------------------------------------------------------------*
START-OF-SELECTION.
*-----------------------------------------------------------------------------------------------------*
* END-OF-SELECTION - end of logical database selections *
*-----------------------------------------------------------------------------------------------------*
END-OF-SELECTION.
* ----------- E N D O F M A I N P R O C E S S I N G ----------- *
*-----------------------------------------------------------------------------------------------------*
* DIFFERENT PROGRAM EVENTS *
*-----------------------------------------------------------------------------------------------------*
AT USER-COMMAND. "When user presses function key or enters a
"command in the command field
AT LINE-SELECTION. "Point at the user selects a line
TOP-OF-PAGE DURING LINE-SELECTION. "top-of-page for 2ndary lists
AT PFNN. "Point at which the user presses the function

"key with the function code PFnn.
*-----------------------------------------------------------------------------------------------------*
* EVENTS RELATING TO REPORT PROCESSING *
*-----------------------------------------------------------------------------------------------------*
TOP-OF-PAGE. "Point during list processing when a new page is
"started
END-OF-PAGE. "Point during list processing when a page is ended
*-----------------------------------------------------------------------------------------------------*
* FORMS *
*-----------------------------------------------------------------------------------------------------*
Page 43 of 51
9 APPENDIX 2 - Code Review Checklist
Program Review Checklist
Program ID: Program Name:

Programmer: Reviewer:
Date:
Code Review Checklist
Yes No N/A
Naming Convention
1 Program Name is consistent with ABAP Naming

Convention Standard.
2 Lock Object Name is consistent with ABAP Naming
3 Message Name is consistent with ABAP Naming
4 Logical Database Name is consistent with ABAP
Naming Convention Standard.
5 Table Name is consistent with ABAP Naming
6 Data Element Name is consistent with ABAP Naming
7 Domain Name is consistent with ABAP Naming
8 Search Help Name is consistent with ABAP Naming
9 View Name is consistent with ABAP Naming
10 Structure Name is consistent with ABAP Naming
11 Layout Set Name is consistent with ABAP Naming
12 Report Variant Name is consistent with ABAP
13 Subroutine Name is consistent with ABAP Naming
14 GUI Status & GUI Title Name are consistent with
ABAP Naming Convention Standard.
15 Function Module Name is consistent with ABAP
Page 44 of 51
16 Transaction Code Name is consistent with ABAP

17 BDC Session Name is consistent with ABAP Naming
18 Index
Coding Style
1 PRETTY PRINTER is used for formatting the code.
2 Events appear in the program in the order that they
are generally executed.
3 Blank Lines are used to separate different sections of
code.
4 Subroutine or Function Modules should be created
instead of replicating the same code in many places.
5 FORMS should be placed after all non-subroutine
blocks and in the order in which they are executed.
6 Each logical section of the program has descriptive
comments prior to the actual code.
7 Program should contain standard header for
modification log and documentation.
8 Every modification should be documented with
modification log (see #7 above).
9 Comments are used to indicate the business reason or
purpose of subroutines, events, section
of code, etc.
10 “Dead Code” should be removed from the program,
i.e., the fields that are never referenced and code
that can never be logically executed.
11 Code changes should be marked with the PPR# at block
of code with begin and end notations or at individual
line with PPR# on the right hand side, e.g., “PPR-
12345”. If an entire form is inserted, sufficient to just
note the PPR# in the form header text area e.g.,
“*Form WRITE_REPORT
PPR-12345*”
Report Standard
1 Documentation of Short Text, Description,
Requirements and Report Output is included and
is in “User Friendly” terminology.
2 Report is coded with “NO STANDARD PAGE-
HEADING” and function module is used in “TOP-
OF-PAGE” event to maintain project standard header.
3 Selection Texts are used to specify literal for program
parameters that will appear on the screen.
4 Text Elements are used instead of hard coding of
Page 45 of 51
literal text.
(i.e., WRITE:/TEXT-001. “WRITE CUSTOMER
INFORMATION; or WRITE/ ‘CUSTOMER’(001).)
5 User default date format ( see SU50 ) is used instead of
hard coding of date format in the program.
6 No hard coding of currency output formats in the
program.
7 When output is designed to print on a laser printer,
consider the output of the report so that it will fit for
both A4 and Letter papers.
8 RESERVE statement is used to determine whether a
group of lines can fit on a page.
Data Definition
1 Variable names are descriptive, meaningful and
understandable.
2 Variables that are not changed in the program are
defined with CONSTANT
Statement. ( CONSTANT PI TYPE F VALUE
‘3.14159265359’.)
3 Comments are included after each field ( tables, fields
of internal tables, constants, variables, etc.) to
describe the meaning or purpose of the field.
4 LIKE verb is used while declaring the fields whenever
feasible.
5 When declaring data, type and length are not left as
default.
6 INCLUDES are created for data declarations and any
data structure that will be used in more than one ABAP
program.
7 Global variables are minimized by declaring local
variables or by passing through parameters and
arguments while creating Internal Subroutine.
Online Standard
1 The field with an “OK” format should be defined as
OK_CODE.
2 Screen and program field names should generally be
identical.
3 When handling a lock entry failure, invoke an error
message (type E) to prevent user from progressing to
the next transaction.
4 AT PF-key is used instead of AT Pfnn in program.
Batch Program / Interface Standard
1 “Success” messages (type ‘S’, which will be output to
“Job Log” when the batch programming is
Page 46 of 51
being processed) should be used generously to provide

an audit trail of the program’s execution.
2 Program variants are used if a program needs to run
with different parameters.
3 OPEN the dataset before the read/write operation, and
always CLOSE the file when file processing is finished.
Message
1 Messages are included at appropriate places to indicate
illegal operation, no authorization, no data
found, etc.
2 Customer specified message ID should be created and
maintained instead of using the default message IDs
supplied by ABAP as they may change in future
release.
Program Logic
1 SY-SUBRC is checked after perform data access
statements such as select, read, get, etc.
2 Authorization-Check has been performed to handle the
security of the program.
3 CHECK is used instead of IF / ENDIF whenever
possible.
4 CHECK, EXIT, REJECT, STOP are used to suspend
processing or skip unnecessary processing.
5 When coding IF, testing conditions are nested so that
the most frequently true conditions are processed
first.
6 CASE is used instead of IF when testing fields “equal
to” something, because it is easier to read and more
efficient after four nested IFs.
7 WHILE is used instead of DO + EXIT statement.
8 Perform I Of…. statement is used instead of using
CASE….. WHEN / PERFORM when calling a
certain routine based on a given index.
9 Zcond table is used for all potential hard-coded values.
Data Access
1 In SELECT statement, only the fields which are needed
are selected in the order that they reside on the
database.
2 SELECT SINGLE is used instead of SELECT
ENDSELECT or SELECT up to 1 rows when the
entire key is available.
3 Always specify the conditions in WHERE clause
instead of checking them with check statement.
4 Extensive code is not embedded within a SELECT /
Page 47 of 51
ENDSELECT statement.
5 WHERE clause is organized with simple logic. WHERE
clauses with very complex logic should be avoided.
6 For all frequently used SELECT statements, try to use
an index by specifying the index fields
concatenated with logical ANDs in the WHERE clause.
7 Conditional execution of performs should always be
checked before calling the form.
8 Use SELECT SINGLE only with primary keys - often
fields will not be taken into account with SELECT
SINGLE.
9 Aggregate functions should be used when calculating
the MAX, MIN, SUM, AVG, COUNT of a
database table.
10 VIEW or JOIN is used to replace nested SELECT
statement.
11 Whenever possible, use array operations instead of
single-row operations to modify your database
tables.
12 Whenever possible, use column updates instead of
single-row updates to update your database
tables.
13 When selecting a certain number of rows use SELECT
Up to n rows, or if you just want one row without
a full primary key, use SELECT UP to 1 rows,
instead of using EXIT in SELECT/ENDSELECT.
14 Since views do not have a primary key, ORDER BY
PRIMARY KEY should only be used in database
tables.
15 Since “ORDER BY fi…fn” is not automatically
supported by a (sorted) index, you should sort the
result set with SORT on the application server instead
of with….ORDER BY fi…fn on the database server.
16 No direct updates to ABAP supplied tables.
17 When loading data into internal table, use SELECT…
from <tab> INTO (APPENDING) TABLE <itab>
instead of a SELECT/APPEND combination.
18 Use a VIEW or JOIN instead of “SELECT…for all entries
in TABLE <itab>”.
Internal Table
1 Header line of Internal Table is cleared before moving
data into it.
2 Internal Table is defined with ‘OCCURS 0’ if the
maximum size of the table is potentially >= 8KB. If the
data to be read is estimated to be under 8K, then
Page 48 of 51
specify the number of lines in the OCCURS statement

(e.g., itabl occurs 10) is effective.
3 MOVE-CORRESPONDING is used only when two
internal tables have identical fields and you want to
move a few records from one to the other.
Otherwise, MOVE should be used.
4 When filling an internal table, use READ…BINARY
SEARCH / INSERT if the amount of data is small (<20
entries), or if the user needs read access to the internal
table while it is being filled. Otherwise two step
approach APPEND / SORT is preferable.
5 When filling an internal table, COLLECT is used
instead of READ / INSERT when number of entries
greater than 1000, because COLLECT uses a hash
algorithm which is independent of the number of
entries and does not need to maintain a table index.
6 When filling an internal table, COLLECT is not used
with the combination of APPEND, INSERT and/or
MODIFY, because it cannot use its own hash algorithm
in those circumstances. “READ TABLE TAB WITH
KEY K = ‘XXX’ BINARY SEARCH” is used instead of
linear search when internal table has more than 20
entries (table must have been sorted by the key
specified in READ statement).
7 Key fields should be specified on the READ TABLE
statement, not left as default (e.g., READ TABLE ITAB
WITH KEY K =’XXX’ instead of READ TABLE ITAB).
8 LOOP AT ITAB WHERE K=’XXX’ should be used
instead of LOOP AT ITAB / CHECK ITAB-K
=’XXX’.
9 Sort fields on the SORT statement should not be left as
default (e.g., SORT ITAB BY FLD1 instead of SORT
ITAB).
10 All variants and fields should be explicitly specified
when you use MODIFY statement to modify the
internal table (e.g., you should use MODIFY itab….
TRANSPORTING fl f2…WHERE…instead of
MODIFY itab) .
11 When appending itabl to itab2, use APPEND LINES
OF itabl TO itab2 instead of APPEND itabl TO itab2.
12 When inserting itabl to itab2, use INSERT LINES OF
itabl INTO itab2 INDEX IDX, instead of INSERT
itabl INTO itab2 INDEX IDX.
13 When deleting a record from an internal table, use
DELETE ITAB WHERE condition instead of using
LOOP AT <itab> / CHECK / DELETE ITAB.
14 When the data is processed only once, use a SELECT-
ENDSELECT loop instead of collecting data in an
Page 49 of 51
internal table with SELECT….INTO TABLE because

the internal table handling takes up much more space.
String Operation
1 When searching for a fragment in a long string, use the
special operators CO, CA, CS instead of
programming the operations yourself.
2 Use ABAP-defined string processing statements (e.g.,
concatenate, split, replace, condense, shift, etc.) instead
of programming them yourself.
3 When deleting the leading spaces in a string, use SHIFT
c LEFT DELETING LEADING SPACE.
4 Function STRLEN0 is used to determine the byte length
of a field.
5 CLEAR <field> WITH <value> is used when you want
to initialize a field with a value different from the
field’s type-specific initial value.
ABAP Script
1 Avoid using text elements in any windows other then
the main window.
2 Delete any windows that are not being used in any
pages of the layout set.
3 Try using SET COUNTRY in the print program instead
of individual windows of the layout set.
4 Upload logo or signature to a standard text instead of
using it directly in the layout set.
5 Use program RSTXTRAN to transport standard text
from IGX to PDX.
6 For appearance purposes, use &’Fax Number ‘T024-
TELFX& instead of Fax Number &T024-TELFX& so
that the text ‘Fax number’ will not print if no fax
number exists.
7 When creating new layout sets, give ¼ inch margin
around each corner of the page for faxing purposes.
8 To transport layout sets across different systems, use
report RSTXSCRP.
9 Use table TNAPR to find a layout set and print
program based on the output type.
10 Every .TIF file (logos, signatures, etc.) should be stored
in the ABAP database
(NS_APPS/PHILA/ABAP/US/CIT/ABAP
Programming Team - Logos).
11 Use RSTXFCPY (transaction SE71) to move layout sets
between clients.
Page 50 of 51
12 Use RSTXTCPY (transaction SO10) to move texts

between clients.
Comply to specs
1 Comply to Processing Logic in program specification.
2 Comply to Data Definition in program specification.
3 Comply to Screen Definition in program specification.
4 Comply to Report Format in program specification.
5 Comply to Message Definition in program
specification.
6 Comply to Function & Subroutine usage in program
specification.
7 Comply to Data Mapping Matrix in program
specification.
Comments:
Page 51 of 51

ABAP Development Standards and Guidelines-Secured-3

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ABAP Development Standards and Guidelines-Secured-3

Enviado por

Direitos autorais:

Formatos disponíveis

Development System Manual & Operating Procedure

2.1 Intended audience .................................................................................................... 6

2.2 Objectives of standards/guidelines ......................................................................... 6

3 NAMING CONVENTIONS .................................................................................7

3.1 Program Names........................................................................................................ 7

3.2 Module Pools ............................................................................................................ 9

3.3 Modifications in Standard SAP Objects .............................................................. 10

3.4 Transaction Codes ................................................................................................. 10

3.5 Function Groups .................................................................................................... 11

3.6 Function Module Names ....................................................................................... 12

3.7 Data Declarations................................................................................................... 12

3.8 Data Dictionary Declarations................................................................................ 14

3.9 Table Types............................................................................................................. 17

3.10 Append Structures ................................................................................................. 17

3.11 Search Helps ........................................................................................................... 17

3.12 Message Classes...................................................................................................... 18

3.13 Package ................................................................................................................... 18

4 ABAP DESIGN STANDARDS........................................................................ 19

4.1 Code Reuse / Subroutines...................................................................................... 19

4.3 Function modules ................................................................................................... 19

4.4 Include Programs................................................................................................... 19

4.5 ABAP Program Layout ......................................................................................... 20

4.6 Program Header..................................................................................................... 21

4.7 Program User Documentation - On-line Program Documentation for End

4.8 Commenting ........................................................................................................... 22

4.9 Program Attributes................................................................................................ 24

4.10 ABAP/4 Security Programming ........................................................................... 25

4.11 Control Reports...................................................................................................... 26

5 ABAP PROGRAMMING TECHNIQUES ........................................................ 29

5.2 General Programming Techniques ...................................................................... 32

5.3 Logical Databases................................................................................................... 32

5.4 Debugging ............................................................................................................... 33

6 SAPSCRIPT TECHNIQUES ........................................................................... 34

6.1 Good Practice ......................................................................................................... 34

6.2 Standards ................................................................................................................ 34

6.3 Standard Texts ....................................................................................................... 34

6.4 Tips .......................................................................................................................... 35

7 CHANGING THE SAP STANDARD............................................................... 36

7.1 Originals and copies............................................................................................... 37

7.2 Corrections and repairs......................................................................................... 37

7.3 Modifications and upgrades.................................................................................. 37

7.4 Modifications Procedures...................................................................................... 38

7.5 Modifications Assistant ......................................................................................... 38

7.6 Restoring the original ............................................................................................ 39

8 APPENDIX 1 - ABAP REPORT CODE TEMPLATE ..................................... 41

9 APPENDIX 2 - CODE REVIEW CHECKLIST ................................................ 44

2.1 Intended audience

2.2 Objectives of standards/guidelines

3.1 Program Names

3.1.1 SAP R/3 Module components

CE Cost Element Accounting

3.1.2 Program Types

3.1.3 Test Programs

3.1.4 Utility Programs

3.1.5 Interface Programs

3.2 Module Pools

3.2.1 Dynpro Names

3.2.2 Dynpro Titles

3.3 Modifications in Standard SAP Objects

3.3.1 Copy and Modify – include naming convention

3.3.2 Customer Enhancements & projects

3.4 Transaction Codes

Z+19 Chars (descriptive name)

Function modules should be used wherever possible to avoid

The Project Manager, on the recommendations of the SAP

Logical database should only be used when there are no other