SAP R/3 Implementation

ABAP Programming Standards

Version: 3

TABLE OF CONTENTS
1. DOCUMENT REVISION HISTORY..............................................................1
2. INTRODUCTION................................................................................................2
3. GENERAL PROGRAMMING STANDARDS...............................................3
3.1 NAMING CONVENTIONS OF ABAP DEVELOPMENTS....................................3
3.1.1 Internal data declaration:-........................................................................4
3.1.2 Development Classes.................................................................................4
3.1.3 Function Groups........................................................................................5
3.1.4 Functions Modules.....................................................................................5
3.1.5 Functions Modules Tables Declaration.....................................................6
3.1.6 Layout Sets..............................................................................................6
3.1.7 Standard Text.............................................................................................6
3.1.8 Messages....................................................................................................6
3.1.10 Lock Object.............................................................................................7
3.1.11 Transaction Codes..................................................................................7
3.1.12 Using Logical File Names......................................................................7
3.2 PROGRAM ATTRIBUTES..............................................................................11
3.2.1 Title...........................................................................................................11
3.2.2 Type..........................................................................................................11
3.2.3 Status........................................................................................................12
3.2.4 Application...............................................................................................12
3.2.5 Authorization Group................................................................................12
3.2.6 Logical Database.....................................................................................12
3.2.7 From Application.....................................................................................12
3.2.8 Screen.......................................................................................................13
3.2.9 Editor Lock...............................................................................................13
3.2.10 Fixed Point Arithmetic..........................................................................13
3.2.11 Start via Variant....................................................................................13
3.3 UPDATE PROGRAMS, COMMENTS, FORMATTING,......................................13
STRUCTURE........................................................................................................ 13
3.3.1 Update programs.....................................................................................13
3.3.2 Comments.................................................................................................13
3.3.3 Formatting...............................................................................................15
3.3.3.1 Forms..................................................................................................15
3.3.3.2 Text Elements.....................................................................................16
3.3.4 ABAP Coding Structure............................................................................17
3.3.5 Module Program Structure......................................................................18
261454112.doc
Page

Version: 3
04 March 2003
i

3.3.5.1 Screen Flow Logic..............................................................................18

3.3.5.2 Screens and Screen Style Standards...................................................19
3.3.5.2.1.................................................................................Menu Standards
20
3.3.5.2.2............................................................Tabstrips in SAP Release 4.X
21
3.3.5.3 Locking and Unlocking in Dialog/Interface Programs........................22
3.3.5.4 Database Update Techniques..............................................................23
3.3.5.5 GUI Status..........................................................................................24
3.3.5.6 Back, Exit and Cancel Navigation......................................................24
3.3.5.7 Messages............................................................................................26
3.3.5.8 Validations and Data Volumes in Dialog Programs............................28
3.3.5.9 Program call through a Function Module...........................................28
3.4 ALV REPORTS........................................................................................... 29
3.5 CORE MODIFICATIONS...............................................................................30
3.6 CREATION OF ADDITIONAL TABS IN SAP STANDARD PROGRAMS WITH TABSTRIPS................................................................................................................. 31
3.7 SMART FORMS.......................................................................................... 31
4. ABAP INTERNAL NAMES...........................................................................33
4.1
4.2
4.3
4.4

DATA TYPES.............................................................................................. 33
DATA FIELDS............................................................................................. 33
ABBREVIATIONS......................................................................................... 34
STANDARD HEADER AND FOOTER.............................................................34

5. ABAP DICTIONARY......................................................................................36
5.1 TABLES..................................................................................................... 36
5.1.1 Transparent Tables...................................................................................36
5.1.2 Views........................................................................................................36
5.1.3 Index.........................................................................................................36
5.2 STRUCTURES............................................................................................. 37
5.3 DATA ELEMENTS....................................................................................... 38
5.4 DOMAINS................................................................................................... 38
5.5 SEARCH HELPS SAP RELEASE 4.X (REPLACES MATCHCODES)................38
5.6 TABLE BUFFERING.................................................................................... 39
5.7 DATA TYPE CONVERSION..........................................................................39
6. ABAP CODING TECHNIQUES....................................................................42
6.1 INTERNAL TABLES................................................................................42
6.1.1 Filling an Internal Table..........................................................................42
6.1.1.1 Select Into...........................................................................................42
6.1.1.2 Append...............................................................................................43
261454112.doc
Page

Version: 3
04 March 2003
ii

6.1.1.3 Insert...................................................................................................44
6.1.2 Retrieving from an Internal Table............................................................44
6.1.2.1 Read Table..........................................................................................44
6.1.2.2 LOOP.................................................................................................44
6.1.2.3 Nested Loops......................................................................................45
6.1.2.4 Events inside the LOOP.....................................................................46
6.1.3 Modifying an Internal Table.....................................................................46
6.1.3.1 Collect................................................................................................46
6.1.3.2 Modify................................................................................................47
6.1.3.3 Delete.................................................................................................47
6.1.4 Sorting Internal Tables.............................................................................48
6.1.5 General Internal Table Techniques..........................................................49
6.1.5.1 DESCRIBE........................................................................................49
6.1.5.2 RANGES............................................................................................49
6.1.5.3 Miscellaneous.....................................................................................50
6.1.6 FIELD GROUPS.....................................................................................51
6.1.7 Generation of Error Log from a Dialog Program...................................51
6.1.8 Display of Traffic Lights..........................................................................52
6.1.9 Generation of Sequence Numbers............................................................53
6.1.10 Use of Packed Numbers........................................................................54
6.1.11 Adding Leading Zeros...........................................................................54
6.1.12 Handling Dates in BDC Session...........................................................55
6.1.13 IF Comparison......................................................................................55
6.2 INTERNAL TABLES - SAP RELEASE 4.X.....................................................55
6.2.1 Memory Allocation for Internal Tables in SAP 4.x.................................56
6.3 CODE TO ADD FUNCTION KEY TO REPORTS...............................................57
6.4 LOGICAL DATABASE.................................................................................. 57
6.4 SUBROUTINES........................................................................................... 59
6.4.1 Forms.......................................................................................................59
6.4.2 Includes....................................................................................................60
6.4.3 Function Modules....................................................................................60
6.4.4 Submit, Call, Leave To.............................................................................61
6.5 SQL.......................................................................................................... 62
6.5.1 ABAP Open SQL......................................................................................62
6.5.1.1 Data Selection from Transparent and Pool Tables..............................63
6.5.1.2 Data Selection from Cluster Tables....................................................63
6.5.1.3 SELECT Aggregates...........................................................................64
6.5.1.4 SELECT with BUFFER support.........................................................65
6.5.1.5 Group Level Data Access..................................................................65
6.5.1.6 Column Update..................................................................................66
6.5.1.7 Filling Internal Tables.........................................................................66
261454112.doc
Page

Version: 3
04 March 2003
iii

6.5.1.8 UP TO nn ROWS...............................................................................67
6.5.1.9 ABAP Open SQL Enhancements SAP Release 4.x.........................67
6.5.1.9.1...........................................................................................Inner Join
67
6.5.1.9.2...................................................................................Left Outer Join
68
6.5.1.10 Catch / Endcatch.............................................................................68
6.5.2 Native SQL...............................................................................................69
6.6 STRING MANIPULATION.............................................................................69
6.6.1 CONCATENATE......................................................................................69
6.6.2 Removing Leading Spaces.......................................................................70
6.6.3 SPLIT.......................................................................................................71
6.6.4 STRLEN....................................................................................................71
6.7 FIELD-SYMBOLS................................................................................... 72
6.8 GENERAL STATEMENTS............................................................................73
6.9 SAP RELEASE 4.0X OBJECT ORIENTED PROGRAMMING...........................74
7. HINTS AND TIPS............................................................................................76
APPENDIX...............................................................................................................I
1/ CONVERSION PROCESS.................................................................................I
1.
1.1
1.2
1.3
2.
3.
4.

BUILDING CONVERSION PROGRAMS................................................................ I

FILE UPLOAD............................................................................................... I
FILE TRANSFER............................................................................................ I
TEXT FILE FOR .CSV FILE........................................................................... II
CONVERSION REPORTING............................................................................... II
BDC SESSIONS VS. CALL TRANSACTIONS..................................................... III
CONVERSION TESTING................................................................................... III

2/ EDI MODIFICATIONS...................................................................................IV
3/ CORRECTION AND TRANSPORT SYSTEM (CTS) NAMING
STANDARDS...........................................................................................................V
1. INTRODUCTION............................................................................................... V
2. STANDARD OUTLINE..................................................................................... V
4/ SAP STANDARD CONVERSION PROGRAMS..........................................VI

261454112.doc
Page

Version: 3
04 March 2003
iv

1.

Document Revision History

Date

Versio
Requester
n#
1
Vineet Bhatia

29 January
2003
05 February
2
2003
04 March 2003 3

Vineet Bhatia
Vineet Bhatia

Change Description
Initial Version
Change to CTS Naming
Standards Prefix
Addition of Standards for
Report Header and Footer

2. Introduction
This document is a compilation of possible ABAP programming
and efficiency standards and will provide guidance in creating
readable, maintainable code. It is intended for all developers in
the SAP R/3 Implementation Project Diamond at Novartis, USA.
The ABAP language is an event driven, top-down
programming language. The ABAP processor controls the
execution of an event. For example, the event AT SELECTIONSCREEN is executed when the user presses enter on the
selection screen and the event START-OF-SELECTION is
executed when the user executes the program. As the ABAP
language incorporates many event keywords, it is necessary to
implement in-house ABAP coding standards to create consistent
and efficient maintainable code.
As a standard, The Object Browser should be used for all
development in the SAP system.
A Source Code Change Process should be in place and adhered
to prior to making changes to production ABAP programs and
SAP source code.
The reader is also referred to the section dealing with the
Naming standards required by this project when dealing with the

261454112.doc
Page

Version: 3
04 March 2003
1

CTS (Correction and Transport System), this is contained within

the Appendix of this document.

261454112.doc
Page

Version: 3
04 March 2003
2

3.

General Programming Standards

3.1

Naming Conventions of ABAP Developments

All custom ABAP program names should follow the naming
standards stated below.
Each ABAP program should adhere to the ABAP internal
naming conventions set forth in this document.
Standard naming conventions are in place and should be used at
all times as detailed below for both tables, structures and ABAP
etc:-

261454112.doc
Page

Version: 3
04 March 2003
3

Z (1) Type
(1)

Proc1 Req Num

(2)
(2)

Underscore
(1)

Brief Desc
(23)

Z (character number 1):

Custom ABAP programs need to begin with Z.
Types (character number 2):
This will be used to mention the type of ABAP program. Possible
values are as follows:
N : Include
T : Table
S : Structure
R : Report
C : Conversions for legacy data upload
I : Interface
M : Module Pool for Dialogs
L : Layout Set/Form
Proc1 (characters 3 and 4):
This will be used to mention the main SAP module.
FI : Financial Accounting
CO: Controlling
MM : Materials Management
SD : Sales and Distribution
PP: Production Planning
PM: Plant Maintenance
PS: Project Systems
CS: Customer Service
GN : General
This will be derived from character 3 and 4 of the Functional
specification.
Requirement Num (character 5, 6):

261454112.doc
Page

Version: 3
04 March 2003
4

The Requirement Number will be the running serial number

within a SAP Module. The SAP Module and the requirement
number together will help as an index in collation all
development objects such as Functional specification, Technical
specification, Unit test Plan, ABAP development objects
program/tables/etc.
Underscore (character 7):
The _ symbol will be defined as separator.
Brief Description (characters 8 - 30):
Characters 8 30 can be used to briefly describe the
functionality. This can also be used to distinguish several objects
of the same type for a common work list item, such as multiple
structures used for the same dialog module.
Examples:
ZCMM19_material upload Conversion program for uploading
material masters in materials management module.
ZSMM23_01_Pur_history, ZSMM23_02_Pur_history 2
number structures developed for definition of field catalogs for
ALV report program to show purchasing history. These
structures are created for requirement number 23 within the main
SAP Module in the main ABAP development work list.
Project Policy on Standard SAP changes
To be determined, and included in this document later in the next
version.
3.1.1

Internal data declaration:(see section 4)

3.1.2

Development Classes

261454112.doc
Page

Version: 3
04 March 2003
5

Development classes group together development objects (e.g.

programs, tables, function modules) which can be corrected and
migrated together across instances. A development class can, for
example, consist of a transaction or a group of related transactions
along with programs, DDIC objects, menu painters, screen painters,
lock objects, message classes, match codes, etc.
All custom development should be assigned to a custom development
class. Temporary objects may be assigned to class $TMP. Objects
defined under the $TMP development class will not be migrated.
Development classes follow the naming convention:
Development
Class
ZDMC
ZNCA
ZNCC
ZNCD
ZNCE
ZNCF
ZNCK
ZNCL
ZNCM
ZNCO
ZNCP
ZNCQ
ZNCS
ZNCT
ZNCV
ZNCX
ZNCZ

Description
Extension of Authorization Fields
Novartis Consumer Health - AM - Assets
Accounting
Novartis Consumer Health - PPC - Production
Planning & Contr
Novartis Consumer Health - DASS
Novartis Consumer Health - RIVA
Novartis Consumer Health - FI - Financial
Accounting
Novartis Consumer Health - Cost Accounting
Novartis Consumer Health - Inventory
Management
Novartis Consumer Health - MM - Materials
Management
Novartis Consumer Health - Workflow
Novartis Consumer Health - Human Resources
Novartis Consumer Health - QSS - Quality
Assurance
Novartis Consumer Health - Basis
Novartis Consumer Health - Temp. Dev.
(Conversion programs)
Novartis Consumer Health - Sales &
Distribution
Novartis Consumer Health - Material Master
Data Management
Novartis Consumer Health - Cross application

261454112.doc
Page

Version: 3
04 March 2003
6

3.1.3

Function Groups
Function groups allow for grouping related function modules and their
components into a common area. Also, common variables may be
shared by all function modules within a function group.
Function groups should adhere to the following naming convention:
Z_CCaxxxxxxxxxxxxxxxxxxxxx
CC Country Code
a - Application ID
x - Open

3.1.4

Functions Modules
The SAP function modules are programs written in ABAP that form
logical units in function groups. They can be shared by multiple ABAP
programs and by other function modules. They are managed centrally
in the function library.
Function modules are grouped together using the function groups.
Function modules may be defined to one and only one function group.
SAP-supplied function groups should never be used to define new
function modules.
Function modules are similar to programs, the primary difference is
they can be called using remote function calls from the operating
system, can be called variably within and across programs, and are not
typically built for reporting using selection criteria.
Function module names can be a maximum of 30 characters. The
following naming convention should be used:
Z_CCa_xxxxxxxxxxxxxxxxxxxxxxxx
CC Country Code
a - Application ID
x - Open (separate words with underscores)
Remarks: All function modules should follow programming standards
outlined in this document. There is no difference between programs

261454112.doc
Page

Version: 3
04 March 2003
7

and function modules when considering logic flows, syntax, unit

testing, and variable naming.
3.1.5

Functions Modules Tables Declaration

Tables must be declared in GLOBAL DATA

3.1.6

Layout Sets
SAP script is a tool in R/3 for formatting text documents. The
formatting rules are stored in R/3 objects called a Layout set. Layout
sets can be used to format R/3 standards text or to format the output of
ABAP reports. In particular, SAP script can be used to format R/3
forms (Purchase Order/ GRN / Invoice / etc) when they are displayed
on the screen or printed on a printer.
A maximum of 16 characters can be used to name Layout Sets. The
following naming convention should be used:
ZCCaxxxxxxxxxxxx
CC Country Code
a - Application ID
x - Open (use underscores to separate words and make as meaningful
as possible).

3.1.7

Standard Text
These are standard pieces of text that can be slotted into a layout set
and can contain pieces of standard text that can be called by any layout
set. An example where standard text would be used would be to hold
an address for an invoice approval slip. The address is contained
within the standard text and can be called in the layout set to display
the address when required. If the address changes, only the standard
text needs to be modified for the changes to be effective immediately
where it is called. The menu path for standard text is Tools/Word
Processing/Standard Text or transaction SO10. The transport
procedure is slightly different again in that you have to create a blank

261454112.doc
Page

Version: 3
04 March 2003
8

correction or repair, and attach the standard text to it. The

correction/repair can then be released in the normal way.
3.1.8

Messages
The ability to display messages should also follow the principles of
maintainability and be stored as individual messages. Message classes
exist with messages already in them. There are already an extensive
number of messages in each of the classes therefore, more than likely,
you will find the message you require. You can also create a new
message and store it in an appropriate class.
Message Classes:
Message Classes should adhere to the following naming convention:
ZCCaxxxxxxxxxxxxxxxx
CC Country Code
a - Application ID
x - Open
INDIVIDUAL MESSAGES:
Each message is given a sequential number and called by that number
from the program, with the severity of the warning being decided each
time the message is called.

3.1.10Lock Object
When creating a Lock Object, the file name must begin with EZ and
can be a maximum of 16 characters long.
EZCCa_tttttttttttt
CC Country Code
A Application ID
t - primary table name (where multiple Lock Objects are required
for the same primary table, assign a unique digit to the final
position).
261454112.doc
Page

Version: 3
04 March 2003
9

3.1.11

Transaction Codes
Each SAP transaction is identified by a unique transaction code which
is listed in two SAP tables. Table TSTC contains the attributes of the
transaction, while table TSTCT contains the short text associated with
the transaction. Transaction codes should adhere to the following
naming convention:
ZCCaxx
CC Country Code
a Application ID
x Open
All reports should be executed from an area menu or from the reporting
tree.

3.1.12

Using Logical File Names

1. Use Tcode FILE to create logical file names. For conversions the
Logical File path is ZIDT.

261454112.doc
Page

Version: 3
04 March 2003
10

261454112.doc
Page

Version: 3
04 March 2003
11

2. Choose Logical file name definition, cross-client

261454112.doc
Page

Version: 3
04 March 2003
12

3. Create new entry for your program as following

Logical file :
<program name>_FILE1
Name :
<short description>
Physical file
<file name><DATE>
Data format
ASC
Application area FI
Logical path
ZIDT

261454112.doc
Page

Version: 3
04 March 2003
13

4. Use the following Func.Module in your program to get the physical file
name.
CALL FUNCTION 'FILE_GET_NAME'
EXPORTING
*
CLIENT
= SY-MANDT
LOGICAL_FILENAME
= <program_name>_FILE1
*
OPERATING_SYSTEM
= SY-OPSYS
*
PARAMETER_1
=''
*
PARAMETER_2
=''
*
PARAMETER_3
=''
*
USE_PRESENTATION_SERVER = ' '
*
WITH_FILE_EXTENSION = ' '
*
USE_BUFFER
=''
IMPORTING
*
EMERGENCY_FLAG
=
*
FILE_FORMAT
=
FILE_NAME
= loadfile
EXCEPTIONS
FILE_NOT_FOUND
=1
OTHERS
= 2.
IF SY-SUBRC <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
*
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
:
:
:
:
:
START-OF-SELECTION.
open dataset loadfile for output in text mode message ws_message.

3.2

Program Attributes

3.2.1

Title

261454112.doc
Page

Version: 3
04 March 2003
14

Program attributes are set from the Attributes option on the initial
ABAP editor screen. All program attributes for an ABAP are to be set
as follows: Title
The title should be a short concise description. This is the title which
appears in the header section of a report when it is executed.
Example:
Create BDC Session for Transaction MM01 - Create Material
Master
3.2.2

Type
The following types are available:
Executable program for reports/interfaces
Include programs. These are not directly executable and are
included in other executable or non-executable programs.
Module pool processing the flow logic of a dynpro.
Function group.
Subroutine Pools.
Interface pools
Class pools
Blank

3.2.3

Status
SAP standard production program.
Customer production program.
System Program.
Test Program.

261454112.doc
Page

Version: 3
04 March 2003
15

 In SAP implementation, all programs are developed as Customer

Production Programs.
3.2.4

Application
The ABAP Application should be set as mentioned in the functional
specification name.

3.2.5

Authorization Group
Used to restrict access to users without a matching authorization group
in their profile. Checks are performed before report execution, and
before access to utility functions, report attributes, and the ABAP
editor.

3.2.6

Logical Database
Assigns the logical database to be evaluated by the program. The
workbench provides access to all logical database programs delivered
by SAP.

3.2.7

From Application
Used in conjunction with the logical database field. The tables
retrieved to access the particular logical database depend upon this
entry.

3.2.8

Screen
This is for report programs only. If a Screen is not specified the system
will create a selection screen based on the logical database (if
specified), the program parameters and select-options. To use an
existing selection screen, enter the version in this field. Versions are
connected to the programming of logical databases. Use the workbench
to analyze logical database screen versions.

3.2.9

Editor Lock
To be set while a program is being created or modified. It allows only
the user ID to set the flag to modify the program. This is to prevent
alteration of a program while a programmer makes modifications to it.
The Editor Lock should not be flagged on.

261454112.doc
Page

Version: 3
04 March 2003
16

3.2.10

Fixed Point Arithmetic

If flagged, all calculations in the program are done using fixed point
arithmetic. If the field is not checked, decimal places are only taken
into consideration for output, not for calculations. All programs should
have this flag checked.

3.2.11

Start via Variant

If checked, the program can only be executed via a variant.

3.3

Update programs, Comments, Formatting,

Structure

3.3.1

Update programs
All transaction update programs are to offer the user the option of
running the ABAP either in BDC Session or Call Transaction mode,
unless a specific mode or a combination of them like Call Transaction
for all records and BDC Session for failed records is specified in the
Technical Requirement Specification. Ensure that a duplicate record
existence check must be made in every data upload program

3.3.2

Comments
Internal commenting of an ABAP Program is essential for
program maintenance and must be done for all programs.
Informative comments should precede each part of source code
and supplement what can be read from the code itself. This
ABAP documentation must contain references to the initial
specification and changes made subsequently.
ABAP code is fairly self-documenting. However, it is prudent
to provide future programmers with documentation of
purpose, changes, enhancements, additions, and deletions.
Explain the purpose, design, structure and any testing hints at
the top of the program. Include any key decisions and
assumptions made. Maintain a chronological history of
modification notes; with the latest change being the last entry
in the modification log. The documentation block should be
placed at the top of the main program. An overall description

261454112.doc
Page

Version: 3
04 March 2003
17

of the program should be given at the top of the program and

should have the following format:
Example:
*--------------------------------------------------------------*****************************************************
***********
*
Confidential and
Proprietary
*
Copyright ALSTOM, Australia
*
All Rights Reserved
*****************************************************
************
* Program Name:

Zxxxxxxx

* Created by:
________
* Created on:
mm/dd/yyyy.
Version:
n.n
*--------------------------------------------------------------* Modification Log:
* Date
Author
Correction
Description
*29/05/01
Shivapriya
DEV190001
Added
*---------------------------------------------------------------

If a modification is made to a tested ABAP program, an entry

should be made in the modification log with the date,
programmers initials, correction number, and brief
description. Also, in the program code, a comment should be
added to the effected lines indicating the correction number.
Example:
IF SY-SUBRC NE 0.
Exit.
ENDIF.

DevK9000045
DevK9000045
DevK9000045

Or
Begin of DevK9000045

261454112.doc
Page

Version: 3
04 March 2003
18

IF SY-SUBRC NE 0.
EXIT.
ENDIF.
End of DevK9000045
ABAP code should be written modular rather than in line
paragraph or form style.
Complex and large coding structures should be commented
by using a blocked off comment section preceding the
structure.
Example:
******************************************
* This function module formats and posts
* transaction MB01 - Post Goods Receipt
* via CALL transaction
******************************************
CALL FUNCTION POST_GOODS_RECEIPT
EXPORTING
TCODE = W_TCODE
IMPORTING
DYNPROTAB = I_BDC.
3.3.3

Formatting

3.3.3.1

Forms
A large and complex string of coding statements should be broken up
and placed in FORMs to provide easy readability and maintainability.
FORMs are subroutines, which allow a programmer to define a
process once in a program and call that routine from different places
within the program. If a block of code is executed more than once, it
should be placed in a subroutine. This makes the code more
readable, requires less indentation, and is easier to debug since the
debugger can jump through an entire subroutine via a PF key.

261454112.doc
Page

Version: 3
04 March 2003
19

 Each FORM should serve only one function.

FORMs should be placed at the end of the ABAP. All FORM
paragraphs should generally be positioned in the order they are
called.
The function of the form should be described in the comment
section. In the case of FORMs that use parameters, the parameters
should also be described.

FORM names should begin with F_. This will display all the
program objects together when using Workbench. The rest of the
FORM name should describe what the FORM is doing.

Use the SAP default FORM comment box. To use this feature, code
the PERFORM statement and then double click on the new form
name. The FORM and ENDFORM statements and a default
comment box will be generated at the end of the ABAP. If any
parameters are passed in the PERFORM, comment lines allowing
individual description of these parameters will be generated as well.
With 3.0, the format parameters must be typed using TYPE or LIKE
keywords. This is a new performance feature in 3.0 and also allows
correcting typing errors before runtime.
Pass input parameters as using parameters and output parameters as
CHANGING parameters. The formal parameter does not occupy a
memory of its own. If in doubt, pass the parameters by value.
To avoid shadowing problems, always name your formal parameters
different than the actual parameters.
If Subroutines defined by FORM use/require global variables then
define local fields for use locally within a subroutine and not use
global fields
Example:
*----------------------------------------*
* FORM F_xxxxxxxxxxxxxx
*-----------------------------------------*
* Insert a descriptive text here
261454112.doc
Page

Version: 3
04 March 2003
20

*----------------------------------------*
FORM F_xxxxxxxxxxxxxx
Includes should be used to break down large programs into sections
that can be maintained more easily and to create program sections
that can be shared by several programs. INCLUDE statements
should be commented individually by using the comment indication
*. Code contained within the INCLUDE statement should adhere
to programming standards and naming conventions.
Example:
* Insert a descriptive text to describe the INCLUDE
* INCLUDE xxxxxxxx.
For overall legibility, an ABAP Program should be neatly indented.
The PRETTY PRINTER command (PP typed in the command line)
can be used to indent each nested command structure by 2 positions
with the settings indent and convert to Uppercase.
Statements with multiple objects should be indented and aligned for
clarity.
3.3.3.2

Text Elements
Each ABAP program should have associated text elements and
constants from the source code placed within the Text Elements
section of the ABAP Editor:

Titles and Headings - The heading should always be

completed in as much detail as possible. Use No Standard
Page Heading phrase and code a custom header.

Selection Texts - All system SELECT-OPTIONS and

PARAMETERS are limited to 8 characters and as a
consequence should always have selection texts set to
improve user understanding. All Selection Texts should be in
lower-case with the first word starting with a capital letter.

Text-Symbols - All text symbols used for headers should

have numbers H01, H02, H03.etc. As far as possible, use

261454112.doc
Page

Version: 3
04 March 2003
21

one text for one report header line. All Text Symbols used for
messages should have numbers M01, M02, M03etc.
Example:
WRITE: / TEXT-001.
The advantage of this method is ease of maintainability if
TEXT-001 is coded several times in the program and needs to
be changed.
Formatting Commands
Example:
Correct
WRITE: / 01
xxxxxxx1,
10 xxxxxxx2,
15 xxxxxxx3.
Incorrect
WRITE: / 01
xxxxxxx1, 10 xxxxxxx2, 15
xxxxxxx3.
Use one line per object when defining multiple objects of the
same entity. Describe those objects on that same line.
Example:
Correct
TABLES: T1, description
T2, description
T3. description
Incorrect
TABLES: T1, T2, T3.
Each ABAP command consists of a sentence ending with a
period. SAP allows multiple commands to be on one line;
however, as a standard start each new command on a new
line. This will allow for easier deleting, commenting, and
debugging.
Example:
Correct
261454112.doc
Page

Version: 3
04 March 2003
22

IF W_X = 3
AND W_Y = 2
AND W_Z = 1.
PERFORM.
ENDIF.
Incorrect
IF W_X = 3 AND W_Y =2 AND W_Z = 1
PERFORM.
ENDIF.
3.3.4

ABAP Coding Structure

Data Definition
Data elements must be grouped in logical groups. For example,
constants declared together, variables grouped together, counters
grouped together. For large groupings, put items in alphabetical
order for supportability. Where clarification is needed, variable
names must have in-line comments. Each variable must be
declared on a separate line.
For readability, different components of the names must be
separated by underscores.
Use Like when defining data elements whenever possible.
This will ensure field width and other domain attributes are
correct following upgrades.
Coding Structure
The standard structure for ABAP Report coding is:
REPORT
Header documentation
TYPES OR TYPE-POOLS
TABLES
PARAMETERS
SELECT-OPTIONS
CONSTANTS
DATA
RANGES

261454112.doc
Page

Version: 3
04 March 2003
23

FIELD-GROUPS
FIELDS
FIELD-SYMBOLS
* Event elements
INITIALIZATION
AT SELECTION-SCREEN ON PARAMETERS
AT SELECTION-SCREEN ON BLOCK
AT SELECTION-SCREEN
START-OF-SELECTION
GET
END-OF-SELECTION
TOP-OF-PAGE
END-OF-PAGE
Control elements
TOP-OF-PAGE DURING LINE-SELECTION
AT LINE-SELECTION
AT PFnn
AT USER-COMMAND
Subroutines
FORM / ENDFORM
3.3.5

Module Program Structure

Module programs should only contain Include statements and
any necessary comments. The module pool is also a means of
linking all the associated screens, menus and function keys of the
interface as a transaction.

3.3.5.1

Screen Flow Logic

Place the AT EXIT-COMMAND at the beginning of the flow
logic in the PAI.
Example:

261454112.doc
Page

Version: 3
04 March 2003
24

PROCESS AFTER INPUT.

MODULE EXIT_1170 AT EXIT-COMMAND.
MODULE PAI_1170.
Use FIELD and CHAIN statements to keep fields in error
open for correction.
Example:
PROCESS AFTER INPUT.
MODULE EXIT_1170 AT EXIT-COMMAND.
CHAIN.
FIELD BTCH1170-JOBNAME.
FIELD BTCH1170-USERNAME.
FIELD BTCH1170-FROM_DATE.
FIELD BTCH1170-FROM_TIME.
MODULE PAI_1170.
ENDCHAIN.
When using the AT CURSOR SELECTION, code it after the AT
EXIT-COMMAND.
3.3.5.2

Screens and Screen Style Standards

When designing SCREENS, place fields on the screen in the
sequence in which they are most frequently used.
Align all labels and fields with neighboring lines and BOX
any related screen fields together.
Position the cursor to the most frequently used field on the
initial screen display.
For screen fields that require text input, place literal labels on
the left and the data entry fields on the right of the label.
For screen fields that use graphical elements, place the literal
label to the right of the graphic element.
Apart for the general guidelines given above, the following list
describes the common style and functionality that must be
incorporated into each online transaction screen. This

261454112.doc
Page

Version: 3
04 March 2003
25

information supplements the SAP R/3 Mini Style Guide in SAP

On-line documentation, which should also be adhered to.
Screen literals
Whilst all screens are being constructed in English, it is vital that
the screens be produced using the field text associated with the
data elements to ease translation to other languages.
Parameters
Maximum fields that have parameters defined should use the
GET ID and SET ID flags in screen painter to allow the storage
and retrieval of the parameter values.
Keyboard shortcuts
All functions must be accessible using a keyboard shortcut, by
using the tab key to skip between fields, assigning a function key
(or ctrl and a key) to common tasks, or by allowing access
through the menus, which can be accessed using alt-<key lettter
> (normal menu navigation ). See also the following section on
menu definition)
Tab strips
Tab strips can be used effectively to show the user the different
facets of an object. However, they should not be used to
maintain different objects within the same screen, and
specifically must not be used to switch between objects at
different levels within a logical hierarchy.
Toolbar buttons
Where screens have a selection of filter fields, the Execute
Button (F8) should be used to produce the list.
Push buttons
Except in exceptional circumstances, Buttons should be
positioned on the application toolbar and identified by a suitable
icon. Floating Tool tip text should be defined for all buttons to
ease identification.
Hyperlinks
Where fields shown on a screen have a sensible link to another
transaction (for example the maintenance transaction for the
Service code field), then allow the user to double click on the
field to invoke the associated transaction, passing the contents of
261454112.doc
Page

Version: 3
04 March 2003
26

the field to the new transaction. Back will return to the original
transaction with all fields populated as they were before leaving
it.
Variants
All screens containing lists should be capable of saving display
variants that may be retrieved by the user in the normal way and
be capable of allowing the user to define a default variant.
All report selection must be capable of creating and retrieving
report selection variants.
Layout
Transactions that will be used extensively must be quick and
easy to use with a minimum of screen changes, button clicks or
keystrokes. Screens should be laid out to present a clear,
uncluttered view with data presented in logical groups within
separate frames.

3.3.5.2.1

Menu Standards
A menu must be defined for each screen that follows the standard
SAP style of menus including all of the appropriate menu
elements.

<object>

Edit

Environment

<object
>
Other
Select
<object all
>
Create Desele
ct all

Got
o
See
belo
w
-----------

Change Select
block
Display Choos
e

Bac
k

View

Extr Environm
as
ent
See See below See
belo
belo
w
w

261454112.doc
Page

System Help
Settin
gs
See
below

Utiliti
es
See
below

Create
session
s
End
session

Appli
cation
Help
SAP
Librar
y
User
Gloss
profile ary
Service ------s
------Version: 3
04 March 2003

27

Copy

Utilitie Relea
s
se
notes
List
------------Workfl SAP
ow
Net
Links
------------Private Feedb
notes
ack
Own
------spool
------request s
Own
Settin
jobs
gs
Short
messag
e
Status
Log off

--------------

--------- Cut
-----Save

Copy

--------- ------------------Print

Paste

--------- ------------------Delete
Exit

Insert
line
Delete
line
Sort...
-------------Cancel

Goto is a mandatory element and should be used to invoke

features within the current transaction that are mandatory (or are
almost certainly used) to enter all the required data for the object
being processed
The Extras menu is not always required, but where appropriate
is used for other features or actions related to the object being
processed that are used less frequently for additional (nonmandatory) information.

261454112.doc
Page

Version: 3
04 March 2003
28

The Environment menu is not always required, but where

appropriate is used for linking to other appropriate functions
within the current application area.
The View menu is not always required, but where appropriate is
used to allow the user to switch between different views that are
available for the current object (e.g single or multiline displays,
or graphical or text)
The Settings menu is not always required, but where appropriate
is used to allow the user to set user-defined transaction
parameters (e.g. the number of seconds between automatic
screen refreshes)
The Utilities menu is not always required, but where appropriate
contains functions that allow not only the processing of the
current object, but also cross-object processing such as copying
information from one object to another.
3.3.5.2.2

Tabstrips in SAP Release 4.X

Tabstrips are new objects in SAP 4.X that provide an easy way
to define different application components on the same screen
and switch between them. Their intuitive design also makes
them easier for end users. TabStrips enable the programmer to
make it easier for users to navigate between components of
complicated applications. Moreover, not only are TabStrips
batch input compatible, but they can also be used whenever
components or logical views of a single object occur on different
screens. However, Tabstrips should not be used to represent
different objects.

3.3.5.3

Locking and Unlocking in Dialog/Interface Programs

Lock Object Creation

261454112.doc
Page

Version: 3
04 March 2003
29

Related tables can be incorporated in a lock object instead of

having lock objects per table.
Applying the Lock
Call the ENQUEUE function before the SELECT Statement for
the transactional data to be changed/deleted.
Example
Call Function ENQUEUE_E<lock_object_name>
EXPORTING
_SCOPE
=2
MODE
= E
<key_field1>
= <value1>
.
.
.
EXCEPTIONS
FOREIGN_LOCK = 1
SYSTEM_FAILURE
=2
.
If SY-SUBRC = 1.
Lock Error Handling procedure.
Note- System Field SY-MSGV1 will have the user name by
whom the table record is locked.
ENDIF.
SELECT statement
System Variable SY-SUBRC is being checked for trapping
exceptions.
Only (E) Exclusive locks to be used until otherwise stated
specifically.
Use the standard setting _SCOPE = 2 for ENQUEUE function
module

Locking Stages

261454112.doc
Page

Version: 3
04 March 2003
30

Numbering /
Key
External
Internal
External /
Internal
External /
Internal

Process

Lock / Get No:

Create
Create
Change / Delete

Start of Unit
End of Unit
Start of Unit

Select and delete in a

multi-records / multipurpose transaction

After record is
selected and delete
button is pressed

Use the Function Module DEQUEUE_E<lock_object_name> to

unlock the records locked as above before leaving the program.
Note: Call Function DEQUEUE_ALL is not required as
COMMIT WORK releases all the locks in the LUW (reference
reading recommended on LUW).
The following points should be considered while locking and
unlocking.
Locking should preferably be done at the record level for the
required set of fields only.
Locking should ideally be done outside a loop statement at a
higher level for cases where there is a possibility of the no. of
records being high, as it may lead to the problem of overflow
in the lock table.
The Dequeue processing should take place only after the
Commit Work Statement. Records enqueued should also be
dequeued when the program is terminated through
Exit/Cancel etc. However this should not happen when you
call another program because the call will come back to the
calling program.
There is no need to output a message when a lock is released.
ENQUEUE_READ function can be used to check whether a
lock has been obtained, however it should be avoided.

261454112.doc
Page

Version: 3
04 March 2003
31

3.3.5.4

Database Update Techniques

The main update technique for bundling database

changes in a single database LUW is to use CALL FUNCTION... IN UPDATE
TASK. When the program encounters the COMMIT WORK statement, work
process that is processing the current dialog step starts an asynchronous update
work process. Inside the update task, no message handling required as SAP
automatically does ROLLBACK in case of errors and sends an Express Document
in the user SAP office mailbox. Where more than one update is carried out during
Save the updates should all be carried out in a single UPDATE function call within
save processing for better code organization.
A success message must be given just after all the validations
before applying the records to the database are successfully
completed.
The program flow will be as follows :
Code for Validations
.
Message type S Document successfully posted.
Call Function <Function module> in UPDATE TASK

COMMIT WORK
3.3.5.5

GUI Status
For each GUI, use SAP defaults proposed by Menu Painter
within Workbench for Menu.
Create a title bar for each screen within a transaction that
identifies what function and area the screen is to be used for.
The standard set of PF Keys should use the SAP defaults
proposed by Menu Painter from Workbench.

261454112.doc
Page

Version: 3
04 March 2003
32

 On all initial entry screens, be sure the BACK, CANCEL,

and EXIT functions are activated.
The following functions should have a standard function code
associated to them:
Function

3.3.5.6

Function Code

Function Type

ADD

ADD

CHANGE

CHNG

DELETE

DELT

DISPLAY

DISP

SAVE

SAVE

BACK

BACK

CANCEL

CANC

EXIT

EXIT

CHOOSE

CHSE

FIRST PAGE

P--

PREVIOUS
PAGE

P-

NEXT PAGE

P+

LAST PAGE

P++

PRINT

PRNT

Back, Exit and Cancel Navigation

For understanding of the above, allocate logical numbering of
the screen before hand.

261454112.doc
Page

Version: 3
04 March 2003
33

Back

Exit

Cancel

Effect

Exits object
component

Exits
task Exits
(application)
processin
g

Jump
target

Returns
previous level

to Screen calling the Screen

task
calling
the task

Yes
Save
option(dia
logue
window)

Yes

No

Checks

Yes

Yes

No

Sequence
of
save/chec
k

Checks first, save Save

option --option later
first,checks later

Example
title of
dialogue
window

Back

Exit G/L document Cancel

editing

Diagnosis
text in
dialogue
window

No diagnosis text

No diagnosis text

Unsaved
data will
be lost
(e.g.)

Example
text in
dialogue
window

Do you want to
post
the
held
document?
Or
Do you want to
post
the
held
document 4712?

Do you want to
post
the
held
document?
Or
Do you want to
post
the
held
document 4712?

Unsaved
data will
be lost.

261454112.doc
Page

--- blank
line --Do you
want to
cancel
the
editing?

Version: 3
04 March 2003
34

Back

Exit

Cancel
(1st line
is
diagnosis
text)

Pushbutto Yes, No, Cancel

ns in
dialogue
window
(default
answer
underline
d)

Yes, No, Cancel

Yes, No

Function
module

popup_to_confirm
_step

popup_to_confirm
_step

popup_to
_confirm
_loss_of
_ data

Action
menu

Goto

<object>

Edit

F-key

F3 (V3)

F15 (V15)

F12
(V12)

261454112.doc
Page

Version: 3
04 March 2003
35

3.3.5.7

Messages
Messages can be used to communicate with users. They are
mostly used for error handling during processing of other user
dialogs
You send messages using the ABAP statement MESSAGE. The
statement specifies the message class, number, and type of the
message. All Message statements supplemented in code with
comment that describes the text of the message.
The message class and number are used to identify the message
in table T100. The message type is one of A, E, I, S, W, or X, .
Message processing depends on the message type specified in
the MESSAGE statement, and the program context in which the
statement occurs.
Message Types
A

Termination

Error

Information

Status

Warning

Exit

The message appears in a dialog box, and

the program terminates. When the user has
confirmed the message, control returns to
the next-highest area menu.
Depending on the program context, an
error dialog appears or the program
terminates.
The message appears in a dialog box.
Once the user has confirmed the message,
the program continues immediately after
the MESSAGE statement.
The program continues normally after the
MESSAGE statement, and the message is
displayed in the status bar of the next
screen.
Depending on the program context, an
error dialog appears or the program
terminates.
No message is displayed, and the program
terminates with a short dump. Program

261454112.doc
Page

Version: 3
04 March 2003
36

terminations with a short dump normally

only occur when a runtime error occurs.
Message type X allows you to force a
program termination. The short dump
contains the message ID.
Guidelines for Message handling
BACK / EXIT
Title - Exit Processing
Message text - Do you wish to save your data first?

DELETE
Title Delete Processing
Message text - Do you want to delete the records?
TABLE LOCK
Transaction aborted. Unable to Lock the Database Tables (used
for Abort message)
Object required is locked by another user
(used
for Error message)
DATABASE UPDATION
& Record(s) successfully &
(Eg. 1 Record successfully
created)
& Record(s) successfully created
& Record(s) successfully updated
& Record(s) successfully deleted
& Record has already been deleted
& Record(s) not deleted (Eg. Reason code is used in other
tables. Record(s) not deleted)
No changes made

261454112.doc
Page

Version: 3
04 March 2003
37

DATABASE SELECTION
No record(s) found matching the selection criteria
TABLE CONTROL LINE SELECTION
Position the cursor on a valid entry
Select a record from the list
Select a & record from the list & (Eg. Select a Journey record
from the list to allocate)
Multiple selections not allowed
MANDATORY FIELDS
SAP message should come if a field is defined Mandatory (Eg.
Make an entry in all required fields)
Program specific
Please enter & (eg. Please enter Service Group)
Validation Checks
SAP message should come wherever foreign key is defined
through check table.

Program specific
If SAP foreign key is disabled/does not exist then handle
programmatically
eg. Reason code does not exist
Reason Code does not exist for Reason code type
Program Checks
& exists for the & & & (eg. Service Group exists for the Plant,
Reason Code exists for the Reason code type)
Start time is later than end time
From date is later than to date
From date is in past
261454112.doc
Page

Version: 3
04 March 2003
38

From date is in future

Program specific
Example
Effective from date is overlapping for plant and daily schedule
Effective from date for Daily schedule and Rota set to Date from

3.3.5.8

Validations and Data Volumes in Dialog Programs

Avoid redundant code for validation of screen inputs when the
data dictionary is already handling it through check tables.
Attention should be paid in terms of which all user-commands
and transactions (Display etc.) do not require validations. In a
dialog job it is necessary to distribute the validations across
screens instead of cumulating at one place like SAVE etc.
The programmer should be aware of the volume of data to be
handled in the dialog program and its growth rate during the
Technical specification stage. The algorithm in the Technical
spec should be reviewed with the functional consultant and a
peer.

3.3.5.9

Program call through a Function Module

Normally Set/Get parameters are used to pass data between
calling & called program. But if a program is called by a number
of programs, it becomes easier if the called program is coded as
a function module. Parameter passing can then be done through
the export/import interface of function module.
The following are the steps to achieve the above :
Create a Function group for the function module.

261454112.doc
Page

Version: 3
04 March 2003
39

 Go to the Object Editor (SE80) and within the created

function group create the screens, includes, GUI status & title
as required by the called program.
The top include will be automatically created for the function
group.
Go the main program of the function group and add the
include statements for includes like I01, O01, F01, etc.
Write the processing logic for the screens just like any other
dialog program.
Finally within the Function group create the function module.
Call to the initial screen of the transaction will be made by the
function module. The PBO logic of the initial screen will be
written in the function module before the call.
The parameters which need to be passed to or returned by the
calling program will be defined in the import/export
parameters of the function call.

3.4

ALV Reports
Caution : ALV reports can not be run in background.
In ALV reports use GUI TITLE for setting the title of the
report and GUI STATUS for the menu bar.
Always use data elements for ALV Column headings and
Selection Screen block heading to avoid hard coding.
For ALV Reports, always follow the following instruction for
field catalog:
Y indicates presence of text in respective field label

261454112.doc
Page

Version: 3
04 March 2003
40

Output in
Medium
ALV Report Print
Short text text of
Long text
for field
Preview
of Data Data
of Data
Headin catalog field of ALV
Element Element Element g
colddictxt report
Y
Long Text Long Text
As set (L, M,
Y
Y
Y
S)
Short
Set R Y
Y
Y
Y
Heading
Heading
As set (L, M,
Y
Y
S)
Medium
Always use dictionary structure(s) as per output requirement
of ALV report. This will provide a clean code. Structure
description should say to be used only for the specified
program.
Only a maximum of 9 columns can be sorted in an ALV
Report.
Column heading of ALV report comes from the field label of
data element. The following are four types of field labels
associated with a data element
Short, Medium, Long and Heading
The following rules apply for determining which text will be
selected as field label.
If Heading exists then default column heading will be
Heading text of the field label.
If Heading doesnt exist then default column heading will be
Short text of the field label .

261454112.doc
Page

Version: 3
04 March 2003
41

 If Heading and short both do not exist then default

column heading will be Medium text of field label .
If nothing else exists Long will be used.
3.5

Core Modifications
Prior to making SAP source code modifications, a Source Code
Change Process must be in place and requirements should be
approved. As a standard, only SAP authorized repairs should be
allowed to the SAP code.
When making modifications to SAP core programs, it is very
important to document the changes made within the program.
Within the comments section at the beginning of the program,
include the following as part of a modification log:
Repair number of the modification (system assigned)
Name/initials of person making the modification
Date
Description of the modification
Example:
*************************************************
***
Program xxxxxxxx
*Description:
*--------------------------------------------------*
*Repair No.
Date
Author Description
*
../../..

*************************************************
**
Within the body of the program, comment every addition of
code or change in code. Include in the comments the repair

261454112.doc
Page

Version: 3
04 March 2003
42

number, initials, date, and description of add/change. No code

should be deleted from any SAP core program. Lines of code
that are no longer used should be commented out.
Example:
*************************************************
***
*Repair number: MS1K900088
* Description: Add code to
*************************************************
**
SELECT SINGLE * FROM LFA1
WHERE KUNNR EQ I_TAB-KUNNR.
DEVK900088 IF SY-SUBRC NE 0.
Exit.
DEVK900088
DEVK900088
ENDIF.
DEVK900088
Or
Begin of DEVK900088
SELECT SINGLE * FROM LFA1
WHERE KUNNR EQ I_TAB-KUNNR.
IF SY-SUBRC NE 0.
Exit.

ENDIF.

End of DEVK900088
3.6

Creation of additional tabs in SAP Standard Programs with Tabstrips

The steps for creating additional tabs in SAP Standard Programs
with tab-strips are as follows
Execute Transaction code VFBS
Create function codes
Specify the program name (SE38) and the subroutine name.

261454112.doc
Page

Version: 3
04 March 2003
43

 Call a function module in the subroutine. Call a screen in the

function module.
Create the screen and code in the function group of this
function module.

3.7

Smart Forms
The SAP Smart Forms is used for creating and maintaining forms
for mass printing. They replace the SAP script forms, however
SAP script forms will also be supported by SAP in future. SAP
Smart Forms allow you to execute simple modifications to the
form and in the form logic by using simple graphical tools. The
following points should be considered when creating or
maintaining Smart Forms :
A backup of the layout prepared through Smart Form should
be kept in the system with the name y<formname>_bk<nn>
(nn being the sequence no. of the backup). This is important
as version management is not supported for these forms.
The currency field to be printed using Smart Forms should be
defined as a field of the same type in the global definitions.
No hard coding should be done in include text and address
window in Smart Forms.

261454112.doc
Page

Version: 3
04 March 2003
44

4.

ABAP Internal Names

4.1

Data Types
All data types used by a program should be first defined to the
ABAP Dictionary as a TYPE-GROUP. One or more TYPEGROUPS can be used by the TYPE-POOLS statement.
With release 3.0 there is a clear distinction between the data type
and the data object:
Data types are declared using the keyword TYPE. Data types
are pure type descriptions. They do not require any storage
space. A data type characterizes the technical properties of all
data objects, which have this type.
Data objects are concrete instances of data types. Each data
object has a particular type and requires all appropriate
storage space. User defined data types can be created using
TYPES statement. They can be either elementary or
structured.
User defined data types allow you to create all application
specific type universally. This structure can be defined
centrally and thus made known to the ABAP programming
environment.

4.2

Data Fields
SAP R/3 Requirements:

261454112.doc
Page

Version: 3
04 March 2003
45

 ABAP variable names can be a maximum of 30 characters

long for DATA fields

SELECT-OPTIONS and PARAMETERS can be a maximum

of 8 characters long.

Standards:
All variables should be defined using the type declared in the
TYPE pool.
When custom variables have a corresponding SAP variable, use
the name that reflects that particular SAP data element or field
name. Do not use variable names containing -. as they can be
confused with table fields. Underscores should be used to
separate words contained in variable/constant names. In addition,
make the names descriptive.
For program readability and maintainability, remove defined
fields, which are never referenced, and code, which can never be
logically executed. Whenever possible, the LIKE parameter
should be used to define work fields.
Position Description Values
1-2
Variable
C_
Description
P_
S_
RB_
CB_
PB_
V_
T_
L_
X_
WA_
E_
CL_
CO_
261454112.doc
Page

Meaning
For Constants
For Parameters
For Select-Options
For Radio buttons
For Checkbox
For pushbuttons
For Global Variables
For Internal Tables
For Local Variable
For Types/ Structures
For Work Areas for
Internal Tables (Also for
Layouts in ALV)
For Events
For Classes
For Container
Version: 3
04 March 2003

46

GR_
CI_
R_
Fld_
Cnt_
Flg
3+

4.3

Freely
Definable

For Grid
For Class Instance
For Range
For Field
For Counters
For Flags
use abbreviations for
clear and
concise names.

Abbreviations
When defining Data Fields, use clear and understandable names.
In cases where abbreviations are used, utilize an agreed upon set
of standard abbreviations. It is important that abbreviations are
used consistently in all names.
To determine an abbreviation for words not listed below, strip
out all vowels and insignificant characters. Names, which begin
with a vowel, retain the vowel in the abbreviation. Add vowels
back in when abbreviations for two different names are alike.
Abbreviations will be based on English names.
Name
Customer
Cost
Name
Vendor
Last
First
Middle
Employee
Identification
Quantity
Counter

4.4

Abbreviation
Cus
Cst
Nm
Vnd
Lst
Frst
mdl
Emp
Id
Qty
Cnt

Standard Header and Footer

261454112.doc
Page

Version: 3
04 March 2003
47

All programs that produce reports (ie/ Reports, Interfaces,

Conversions) should use a Standard Header and Footer.
The Standard Header should be as follows:
Color: col_heading intensified on
Company Name: Should be in upper case - Centered
Report Description: Each word in Sentence Case - centered
and aligned with Company name.
A line at the end of the Header.
Footer should comprise of a line at the end of the page.

pic00235.pcx

261454112.doc
Page

Version: 3
04 March 2003
48

5.

ABAP DICTIONARY
When creating a custom table, carefully plan its design and
structure. Define the table fields appropriately. Always place the
key fields starting with MANDT (client) field at the front of the
record layout. Use the SAP database administrator to help design
the table and its attributes, index, and buffer settings.

5.1

Tables
When defining custom tables always place the key fields at the
front of the record structure.

5.1.1

Transparent Tables
When creating custom tables, Transparent Tables should be used
in most cases. A Transparent table is a table with system
structure, which gives an identical structure inside SAP as
outside. Therefore the table can be accessed by both internal and
external applications. All updates to SAP Tables should be
performed within SAP.

5.1.2

Views
For reporting purposes, use VIEW tables to effectively join
related tables that are taking large amounts of time for data
retrieval. A database View is not physically stored, but it is a
table derived from multiple tables. Database Views allow fields
from several tables to be accessed in one view. Generally,
accessing a database view is faster then selecting tables
individually.
With Release 4.X views can be buffered in the same manner as
tables.

5.1.3

Index
The purpose of an Index is to quicken the scanning process when
searching for specific records in a table. An Index is a copy of a
table reduced to particular sorted fields to enable faster access to
needed data.

261454112.doc
Page

Version: 3
04 March 2003
49

 Indexes may be developed when the required access to a

database table is based on fields other than the primary key of
the table.
Only include fields in an index if they reduce the selected
data significantly.
As indexes are adjusted each time table contents are changed,
create secondary indexes discerningly to minimize the impact
on the system.
When SELECTing data from a table, look at the structure of
all of the available indexes and tailor the WHERE clause to
take advantage of the most selective index. Use all fields in
the WHERE clause in the same order for an index, as
skipping one field disables the index.
Place the most common columns at the beginning of an
index. The most common columns are those where reports
are selecting columns with no ranges - the WHERE clause for
these columns is an equal to expression. Rearrange
columns of an index to match the selection criteria. For
example, if a SELECT statement is written to include
columns 1 and 2 with equal to expressions in the where
clause and column 3 and 4 are selected with value ranges,
then the index should be created with columns in the
sequence of 1, 2, 3, 4.
Place Columns toward the end of the index if they are either
infrequently used in SELECTS or are part of reporting
SELECTS that involve ranges of values.
Be sure to order the columns in the WHERE clause of a
SELECT in the same order as an index table.
Indexes should be small (few fields). Some optimizers are
able to combine two or more indexes to execute a query. This
is not possible with wide indexes.

261454112.doc
Page

Version: 3
04 March 2003
50

 Multiple indexes of one table should be disjoint (have few

common fields), in order not to confuse the optimizer which
index to use.
Each index slows the inserts into the table down. Updates are
only slowed down if indexed fields are updated. On the other
hand, the indexes increase the efficiency of reads. These
tradeoffs must be weighed against one another. In general,
frequently updated tables should have only few indexes while
frequently selected tables might have more.
Remove unused indexes or ones that change due to report
design changes.
Caution:
The creation of an index can affect performance adversely. The
most suitable index for the select criteria might not be the index
chosen for use by the database optimizer. Creating Indexes
should be done carefully and jointly with the SAP Database
Administrator. Validate the use of table indexes by performing a
SQL Trace.
1.2

Structures
Identify the fields that are used in constructing a screen in
Dialog program
Create Structures in the Data Dictionary.

Add the fields that are required in the structure. You can copy
the fields contained in a dictionary structures, table or views
with Edit / Include / Insert / Copy components

Maintain the foreign Keys of the Structure

The reference field and reference table must be specified for

components of type CURR (currency) and QUAN (quantity).

Attach a Search Help to a structure field that can be used by

all screen fields that refer to the structure field

261454112.doc
Page

Version: 3
04 March 2003
51

In ABAP programs you can access the fields directly with

<Structure name>-<Field name>

All screen and ALV Reports (for meeting the requirement of

Field Catalog) should use Dictionary structures for screen
fields instead of using table definitions or program variables
5.3

Data Elements
A data element defines the description for the field. The
semantic information (description and field labels) is assigned to
the data element along with any on-line documentation. If
possible, use the standard SAP Data Elements such as BUKRS,
BELNR etc.
The data element is the functional name associated with a
domain; e.g., one of the data elements associated with domain
CHAR30 may be ADDRESS. Whenever ADDRESS is entered
as a data element, the characteristics of the domain CHAR30
appear.

5.4

Domains
A domain describes the physical format of the data such as the
type and length of the data. Fields referring to a domain (via the
data elements assigned to them) assumed the data format defined
by the domain.

5.5

Search Helps SAP Release 4.X (replaces matchcodes)

SEARCH HELPS are a new feature in 4.X. They are more
powerful than input help created using matchcodes and help
views.
A SEARCH HELP is an object that describes the procedure for
possible values help. The 4.X upgrade will automatically

261454112.doc
Page

Version: 3
04 March 2003
52

convert matchcodes and help views to search helps. (The

existing matchcodes and help views will NOT be deleted.)
A SEARCH HELP is an improved method of displaying
allowable values for an input field which can return multiple
values to the underlying screen. A search help exit is a function
module with a standard interface called from each step in the
help process. These should only be used in exceptional cases, as
they make input help harder to maintain.
Notes: For more information, there is a search help conversion
program called RUTHVMIG.
5.6

Table Buffering
Database tables can be stored locally on each application server.
Performance time may be improved because reading from the
buffer avoids directly accessing the database. Within SAP, only
POOLED and TRANSPARENT tables allow buffering. The
decision to buffer a table should be made by the SAP Database
Administrator.
Considerations:
Only buffer a table that has read-only accesses made against
it and is referenced frequently.
Only buffer those tables that contain the business and other
transaction processing rules, that are setup during the
implementation of the SAP R/3 system and are changed very
infrequently.
Tables that contain master and transaction data should not be
buffered.
Only buffer tables that are modifiable, if write access occurs
infrequently. Changes to buffered tables get automatically
logged in the database and are transferred to the application
servers at regular intervals. If buffered tables are modified
frequently, the additional processing needed may cancel any
performance gains attained by buffering.

261454112.doc
Page

Version: 3
04 March 2003
53

 Native SQL. These commands always bypass the buffer and

access the database directly. If native SQL was to update a
buffered table directly, the buffer status is not changed; this
could result in inconsistencies between data in the buffer and
the database.
5.7

Data Type Conversion

Understanding and using data type comparisons and conversions
is very important in ABAP. Following is a list from SAP R/3
system that lists how external data types are mapped to the
ABAP data types using standard domains.
External ABAP Data Type
Description
Data
Type
ACCP
N(6)
Posting period YYYYMM
CHAR n

C(n)

Character strings

CLNT

C(3)

Client

CUKY

C(5)

Currency key, referenced by

CURR fields

CURR n, P((n+2)/2)
m, s
DECIMAL m

Currency field, stored as DEC

DEC n,
m, s

P((n+2)/2)
DECIMAL m

Counter or amount field w/

comma & sign

DATS

D(8)

Date field (YYYYMMDD)

stored as char(8)

FLTP

F(8)

Floating point number, accurate

to 8 bytes

INT1

1-byte integer

INT2

2-byte integer

INT4

4-byte integer

LANG

C(2)

Language key

LRAW

X(n)

Uninterpreted sequence of bytes

LCHR

C(n)

Long character string, requires

261454112.doc
Page

Version: 3
04 March 2003
54

External ABAP Data Type

Data
Type

Description

preceding INT2 field

NUMC n N(n)

Character field with only digits

QUAN n, P((n+2)/2)
m, s
DECIMAL m

Quantity field, points to a unit

field with format UNIT

RAW n

X(n)

Long byte string needs

preceding INT2 field

TIMS

T(6)

Time field (hhmmss), stored as

char(6)

UNIT

C(n)

Unit key for QUAN fields

VARC n

C(n)

Long character string, not

supported from Release 3.0

n: no. of
places

m: number of
decimal places.

s: sign flag

Considerations:
When non-standard conversions are needed to display
differently than SAPs internal format or vice-versa, create a
Conversion Exit for the Domain. This should be done by
creating two function modules in the same function group.
one module to convert from display format to internal
format.
the other to convert from internal format to the external
format.
Data types of P and I are treated the same on all SAP
supported platforms.
Note that floating points have an accuracy up to 15 decimal
places on all platforms, and that the rounding behavior may

261454112.doc
Page

Version: 3
04 March 2003
55

change. SAP advises that when two floating-point numbers

need to be tested for equality, that the difference is very small.
Reports have been made that errors occur when a field having
decimal places is compared to 0 because SAP interprets any
number less than 0.5 as equal to 0. As a standard, create a
constant: C_ZERO with the correct number of decimal places
and use it for comparisons instead of hard coding the constant
in the processing logic.
Example:
DATA:
C_ZERO
0.00

TYPE P

DECIMALS 2

VALUE

Creating constants will also help with debugging and testing

conditions. The debugger will allow the C_ZERO value to be
changed to test various conditions easily.
Use program RSANAL00 to execute conversions by an
ABAP.

261454112.doc
Page

Version: 3
04 March 2003
56

6.

ABAP CODING TECHNIQUES

6.1

INTERNAL TABLES
An Internal Table is a group of records created at runtime.
It is recommended to define all internal tables using user-defined
data types and without a header line.
Example:
TYPES: Begin of T_definition
Driver like driverduty-driver,
End of T_definition
DATA: I_table TYPE STANDARD table of T_definition.
Considerations:
The initial size addition is similar to the OCCURS parameter
in version 3.X. When the initial size is not known, it makes
more sense to leave it to SAP to determine by specifying
initial size 0.

6.1.1

Filling an Internal Table

Information regarding using select statements:
select single should only be used if the entire key is known
2) select (fields) should be used if you are extracting less than
1/3 of the database fields or a maximum of 16 fields

6.1.1.1

Select Into
When an Internal Table needs to be created directly from one
database table, use the SELECT INTO to fill the Internal Table.
The contents of I_T001 will be replaced by the selected data so a
REFRESH is not needed.
Example:
SELECT * FROM T001 INTO TABLE I_T001.

261454112.doc
Page

Version: 3
04 March 2003
57

If an Internal Table is to be created directly from database tables

and the contents currently in the Internal Table need to be kept,
add the APPENDING TABLE parameter.
Example:
SELECT SINGLE * FROM T001W APPENDING
TABLE I_MARA WHERE WERKS = W_ WERKS.
Considerations:
This is only relevant for Internal Tables that are as wide or
wider than the database table being SELECTed.
It is always faster to use the INTO TABLE version of a
SELECT statement than to use APPEND statements.
6.1.1.2

Append
Append adds a new entry to an Internal Table. The system does
not check if a record with the same key exists.
Considerations:
As APPEND adds new entries to an Internal Table, duplicate
entries may occur. If the internal table already contains the
number of entries allocated by the system (Initial size 0
addition), the additional entries are rolled to the paging area,
resulting in longer runtimes.
When using Internal Tables with a header line, avoid
unnecessary assignments to the header line. Use statements,
which have an explicit work area.
Example:
More Efficient
APPEND W_TAB TO I_TAB.
Less Efficient
I_TAB = W_TAB.
APPEND I_TAB

261454112.doc
Page

Version: 3
04 March 2003
58

 Use the CLEAR command after the APPEND command to

clear the contents of the internal table's header record.
As of Release 3.0C, the addition LINES OF can be added to
the APPEND statement. The statement is used to add a block
of lines to an Internal Table. When appropriate, use APPEND
with the block command instead of APPENDING single lines
during a LOOP. The block command is faster and easier to
read.
Example:
More Efficient
APPEND LINES OF I_TAB1 TO I_TAB2.
Less Efficient
LOOP AT I_TAB1.
APPEND I_TAB1 TO I_TAB2
ENDLOOP.
6.1.1.3

Insert
Use INSERT to add single rows or blocks of rows to an Internal
Table as a specific position.
Example:
INSERT I_TAB INDEX 6.
Considerations:
When a block of lines is to be inserted at a specific position,
use the LINES OF parameter of the INSERT statement.
INSERTing a block of lines is faster than INSERTing one row
at a time during a LOOP. This example will insert rows 3
through 7 from I_TAB1 into I_TAB2 as rows 4, 5, 6, and line
4 from I_TAB2 will become line 7 after the INSERT.
Example:
INSERT LINES OF I_TAB1 FROM 3 TO 5 INTO
I_TAB2 INDEX 4.

261454112.doc
Page

Version: 3
04 March 2003
59

6.1.2

Retrieving from an Internal Table

6.1.2.1

Read Table
READ TABLE is used to read a single row from an Internal
Table.
READ TABLE I_TAB is used to read a Internal Table using the
Internal Tables header line as the output area.
READ TABLE I_TAB INTO WA is used to read an Internal
Table and use the work area as the output area.
Considerations:

6.1.2.2

When reading a single record in an Internal Table, the READ

TABLE WITH KEY.. is not a direct READ. Therefore,
SORT the table on the key (to be used for equality) in
ACSENDING ORDER beforehand and use READ TABLE
WITH KEY.. BINARY SEARCH. The binary search will fail
in case the table (key) is sorted in a DESCENDING order.
When the BINARY SEARCH is used, the system starts the
search in the middle of the table. It then checks the first half
or second half depending if the key fields are bigger or
smaller than the middle entry.

LOOP
LOOP WHERE is faster than LOOP/CHECK because LOOP
WHERE evaluates the specified condition internally.
Example:
More Efficient
*Key access with LOOP WHERE
LOOP AT TAB WHERE K = KVAL.
" ...
ENDLOOP.
Less Efficient

261454112.doc
Page

Version: 3
04 March 2003
60

More Efficient
*Key access with LOOP/CHECK
LOOP AT TAB.
CHECK TAB-K = KVAL.
" ...
ENDLOOP.
Make the comparison operators share a common type; as with
any logical expression, the performance is better if the operands
of a comparison share a common type.
Performance can be further enhanced if the LOOP WHERE is
combined with FROM i1 and/or TO i2.
6.1.2.3

Nested Loops
Performance in reading the internal tables can be enhanced by
using the combination of Read table and Loop statements.
Read table will locate the index of the record and loop
statement can be used with the addition From.
Caution: The nested loop table should be sorted on the basis of
where clause fields. It has to be ensured that sorting a table on a
particular field should not affect the program flow at a
subsequent location in the program flow where a different sort is
expected. Therefore, in such cases the internal table must be
resorted as per fields expected.
Example:
More Efficient

261454112.doc
Page

Version: 3
04 March 2003
61

Sort I_tab by f1.

Read table I_tab with key f1 = w_f1.
If sy-subrc = 0.
w_index = sy-tabix.
Endif.
LOOP AT I_tab from w_index.
If w_f1 <> I_tab-f1.
Exit.
Endif.
Processing within loop

ENDLOOP.

6.1.2.4

Events inside the LOOP

While using events like At start of, At end of, At first, At
Last, On change of in side the loop, always transfer the
header record into a work area. Because when control comes to
At end of or At start of , all the character field of header line
becomes star(*).
Example
Correct Method
Loop at itab where .
Wa_itab = itab.
At end of plant.
Endat.
Endloop.

6.1.3

Modifying an Internal Table

6.1.3.1

Collect
The COLLECT statement scans the Internal Table for an entry
where the default key matches that of the entry in the Work area /

261454112.doc
Page

Version: 3
04 March 2003
62

Internal Tables header record. If a match is found, the system

sums any field of type F, P, I, N in that record; if no record exists
the header record is inserted into the Internal Table.
When adding data to SAP tables (as opposed to totaling
numbers), use the APPEND statement instead of the
COLLECT statement. This improves speed and avoids
comparisons to existing data
Considerations:
When working with Internal Tables, recall that the COLLECT
statement is very CPU intensive. When COLLECTing on an
Internal Table with greater than 50 entries, use the following
alternative code:
..
READ TABLE I_TAB WITH KEY .. BINARY
SEARCH.
CASE SY-SUBRC.
WHEN 0.
I_TAB-AMT = I_TAB-AMT + W_NEW_AMT.
MODIFY I_TAB INDEX SY-TABIX.
WHEN 4.
INSERT ITAB INDEX SY-TABIX.
WHEN 8.
APPEND I_TAB.
ENDCASE
..
* For Internal Tables with less than 50 entries the COLLECT is
acceptable.
After the COLLECT statement has been executed, the index
of the modified or new entry is written to the system field SYTABIX.
When you fill an internal table, do not use COLLECT in
combination with any other table-filling statements
(APPEND, INSERT, and/or MODIFY). If you mix
261454112.doc
Page

Version: 3
04 March 2003
63

COLLECT with the other statements, COLLECT cannot use

its hash algorithm. In this case COLLECT resorts to a normal
linear search, which is dramatically slower.
6.1.3.2

Modify
Use the MODIFY command to change a line within an Internal
Table
Example:
LOOP AT I_TAB.
MOVE C_INITIALIZE TO I_TAB-INITIALIZE.
MODIFY I_TAB.
ENDLOOP.

6.1.3.3

Delete
Use the DELETE command to delete a row or group of rows
from an Internal Table. When DELETEing a group of rows from
an Internal Table, delete them using a DELETE WHERE clause
instead of a single row at a time during a LOOP, unless other
activity takes place during the LOOP.
Example:
DELETE I_TAB
WHERE WERKS EQ C_0010.
If possible, WHERE should be used together with
FROM...and/or TO ... to enhance performance even more.
Example:
DELETE I_TAB [FROM] [TO] WHERE.
Considerations:
To delete all rows in an Internal Table, use the REFRESH
statement.
When working with Internal Tables, use the FREE command to
release the memory after the Internal Table has served its
purpose and will not be used again.

261454112.doc
Page

Version: 3
04 March 2003
64

Example: If Table I_TAB is 10MB, use

FREE I_TAB.
If an Internal Table is defined locally in a subroutine, the
allocated memory is released upon completion of the subroutine,
so the REFRESH statement is not needed.
6.1.4

Sorting Internal Tables

Qualify all SORT statements with the BY option and limit the
sorting of data to fields that must be used to satisfy the
requirements. SORTs, in general, are expensive.
Considerations:
Be aware of the effect on character sequence using SORT.
Upper case characters can be sorted before lower case
letters or, lower case can be sorted before upper case.
The sort might place letters before numbers or vice versa.
SORTED Internal Tables
When SORTing Internal Tables, specify the fields to be
SORTed.
Example:
More Efficient
SORT ITAB BY FLD1 FLD2
Less Efficient
SORT ITAB.
Building SORTED Tables
If the amount of data is less than 20 entries, or if read access to
the Internal Table is needed while the ITAB is being filled, use a
one-step approach using READ/INSERT. If the data amount is
larger and read-access is only needed to the completely filled
table, use the two-step process.

261454112.doc
Page

Version: 3
04 March 2003
65

Example:
One-step Approach: READ/INSERT
* I_DEST is filled with 1000 entries
REFRESH I_DEST.
LOOP AT TAB_SRC INTO WA_SRC.
READ TABLE I_DEST WITH KEY K =
TAB_SRC-K BINARY SEARCH.
INSERT WA_SRC INTO I_DEST INDEX SYTABIX.
ENDLOOP.
*Use on small tables (<= 20 rows)
Two-step Approach: APPEND, SORT
* I_DEST is filled with 1000 entries
REFRESH I_DEST.
LOOP AT TAB_SRC INTO WA_SRC.
APPEND WA_SRC TO I_DEST.
ENDLOOP.
SORT TAB_DEST BY K.
*Use on large tables
6.1.5

General Internal Table Techniques

6.1.5.1

DESCRIBE
DESCRIBE determines the number of entries in an Internal
Table.
Example:
More Efficient
DESCRIBE TABLE I_TAB LINES W_LNE_CNTR
Less Efficient
LOOP AT I_TAB.
W_LNE_CNTR = W_LNE_CNT + 1.
ENDLOOP

6.1.5.2

RANGES
The RANGES statement creates Internal Tables that have the
structure of a SELECT-OPTION table, but the RANGES do not

261454112.doc
Page

Version: 3
04 March 2003
66

have the same functionality. The structure created by the

RANGES statement is:
Example:
BEGIN OF R_tab,
SIGN(1),
OPTION(2),
LOW LIKE ..,
HIGH LIKE ..,
END OF R_tab.

As a standard, when using the IN operator in combination with

SUBMIT, SELECT, CHECK, WHILE, or IF, always define the
associated Internal Table using SELECT-OPTIONS or RANGES
Never define the selection criteria in an Internal Table directly.
Using RANGES will make for easier maintainability, readability,
and conforms to SAP recommendations.
As a standard, when an Internal Table is to be used as above, use
the RANGES definition to define the range.
Example:
Standard
RANGES R_tab for lfb1-Bukrs
Non-Standard

261454112.doc
Page

Version: 3
04 March 2003
67

DATA:

BEGIN OF I_TAB, OCCURS nn,

SIGN(1),
OPTION(2),
LOW LIKE ..,
HIGH LIKE ..,

END OF I_TAB,.
Considerations when using RANGES:
RANGES are not selection screen fields.
RANGES are not passed to the logical database programs.
RANGES do not support the short form of logical
expressions,
RANGES are to be used in the WHERE clause of OPEN
SQL statements in expressions with the IN parameter.
6.1.5.3

Miscellaneous
More Efficient
APPEND WA_ TO ITAB.
Less Efficient
MOVE WA_ TO ITAB.
APPEND ITAB.
More Efficient
INSERT WA_ INTO ITAB.
Less Efficient
MOVE WA_ TO ITAB.
INSERT ITAB.

261454112.doc
Page

Version: 3
04 March 2003
68

More Efficient
COLLECT WA_ INTO ITAB.
Less Efficient
MOVE WA_ TO ITAB.
COLLECT ITAB.
Use the FREE statement to release the memory allocated to
Internal Tables. The FREE statement should follow the last
statement used to process the data in the table. Use the FREE
statement where you no longer need the internal table in your
program.
As noted above in APPEND, when using Internal Tables with a
header line, avoid unnecessary assignments to the header line.
Use statements that have an explicit work area:
Examples:
When performing control break logic on Internal Tables and
FIELD-GROUPS, make use of the AT NEW, AT END OF,
ON CHANGE OF, and SUM commands. The use of ABAPs
control break commands will provide easier readability and
maintainability versus coding the break logic without the
benefit of the commands. When using the control break logic
statements, one must necessarily use the work area instead of
internal table header.
6.1.6

FIELD GROUPS
SAP R/3 Requirements:
FIELD-GROUPS combines several existing fields together under
one name. Used in conjunction with INSERT, EXTRACT, and
LOOP. Conceptually, it is similar to processing Internal Tables.
Considerations:
FIELD-GROUP are used to build internal tables that have a
common key structure but different arguments. They are

261454112.doc
Page

Version: 3
04 March 2003
69

supported by 3.0 and more efficient than internal tables

because of compression.
FIELD-GROUP should be used to process large amounts of
data. Smaller amounts of data should be stored in Internal
Tables.
As soon as the first dataset for a FIELD-GROUP has been
extracted with EXTRACT, the FIELD-GROUP can no longer
be extended with INSERT.
FIELD-GROUPS can only have records added to them
before a sort or loop command is performed.
6.1.7

Generation of Error Log from a Dialog Program

If a list is required (e.g an Error or Confirmation Log) from
dialog processing, use the statement LEAVE TO LISTPROCESSING. Its effect is to start the list processor and
display the basic list after the PAI processing of the current
screen. Then its possible to use all the usual list layout
commands like WRITE, SKIP, etc. All list programming options
are possible, e.g line selection, function keys, windows.
List processing can be exited by using the
BACK/EXIT/CANCEL of the GUI status defined for the list
using SET PF_STATUS ... By default, the dialog processor
returns to the PBO of the screen from where the list was called.

Example

261454112.doc
Page

Version: 3
04 March 2003
70

Sample Code
set pf-status '24BM_ERR'.
leave to list-processing.
write text-004.
loop at i_return where type = 'E'.
* Data to be displayed
write at / i_return-message
endloop.

6.1.8

Display of Traffic Lights

Traffic lights (Red, Yellow and Green) might have to be
displayed for different error situations i.e. Red for Error, Yellow
for Warning and Green in case there is no error or warning. The
following piece of code demonstrates the method:
Sample Code
* Type defined for module level validations
types:begin of t_module,
*
The field (statusicon) represents the icon
for traffic lights
statusicon type icons-text, " for status icon
include structure zcramodhd.
types: end of t_module.
Data w_icon_stat type icons-text.
Data I_module type standard table of t_module with
header line.
* Creating the traffic lights in the status field
depending on the corrstat (Error Status field) of the
record in the table zcramodhd
clear: w_stat, w_icon_stat.
w_stat = i_module-corrstat.

261454112.doc
Page

Version: 3
04 March 2003
71

perform f_get_lights using

w_stat
changing w_icon_stat.
i_module-statusicon = w_icon_stat.
form f_get_lights using
p_w_stat
changing p_w_icon_stat.
data: l_stat like zcramodhd-corrstat,
l_icon_stat type icons-text,
l_icon_name(60) type c.
l_stat = p_w_stat.
l_icon_stat = p_w_icon_stat.
if l_stat = c_e.
l_icon_name = c_red.
elseif l_stat = c_w.
l_icon_name = c_yellow.
elseif l_stat = space.
l_icon_name = c_green.
endif.
* This function module will return the icon
(l_icon_stat)
call function 'ICON_CREATE'
exporting
name
= l_icon_name
importing
result
= l_icon_stat
exceptions

if sy-subrc <> 0.
* Status light not created.
Error Message
endif.
p_w_stat = l_stat.
p_w_icon_stat = l_icon_stat.
endform.

" F_GET_LIGHTS

261454112.doc
Page

Version: 3
04 March 2003
72

6.1.9

Generation of Sequence Numbers

Depending on the business requirements the generation of
sequence numbers can take place in the following ways:
If the number to be generated is independent of any other entity,
the number can obtained by using a standard or user-defined
function module which gets the next available number for the
domain.
Example
* For external number range get the next number
available
call function 'GET_NEXT_NUMBER'
exporting
domname
= c_domn_name_id
importing
nxtnum
= w_rcid
exceptions
invalid_number_range = 1
invalid_parameter_type = 2
others
= 3.

When using the standard or user defined function modules to

generate the next sequence number, there can be a number loss
in case of an error. This loss of number is not acceptable in
statutory transactions like GR, IR,etc. where one should try to
confirm the validations in test mode before generating the
number. To keep the loss to a minimum, the number should be
generated after all validations and just before the enqueue
function for logical locking if the number field is part of the lock
key else just before the update statement.
If the number is to be internally generated without a number
range we get the last used number from the database table,
increment it by one to get the next number, and lock it
immediately.

261454112.doc
Page

Version: 3
04 March 2003
73

Example
* Get the last used value of plant recid for
plant and date
select max( plntrecid ) into
w_plantid
from /slssv/cplntrec
where plant = p_plant
and lddate = p_date.
w_plantid = w_plantid + 1.
Immediately enqueue w_plantid.

6.1.10

Use of Packed Numbers

Use caution when performing arithmetic with packed numbers.
Be aware that if the numbers are defined with a different number
of decimal places you may get unexpected results. ABAP
performs the arithmetic ignoring the decimal places and inserts
the decimal on the answer. Careful testing is essential.
All Packed fields are treated as whole numbers. Calculations
involving decimal places require additional programming to
include multiplication or division by 10, 100, 1000, etc.. The
DECIMALS specification with the DATA declaration is effective
only for output with the WRITE statement. If, however, fixed
point arithmetic (program attributes) is active, the DECIMALS
specification is also taken into account. In this case,
intermediate results are calculated with maximum accuracy (31
decimal places). This applies particularly to division. For this
reason, you should always set the program attribute "Fixed point
arithmetic", unless there are technical requirements needing
floating-point.

6.1.11

Adding Leading Zeros

To display a numeric value in a layout or a report with all leading
zeros, instead of using your own code use the function module

261454112.doc
Page

Version: 3
04 March 2003
74

CONVERSION_EXIT_ALPHA_INPUT. This function

converts a padded value to a value with leading zeros.
e.g.
If you give the input as 123 & the field length is 10 then this
module will
give the output as 0000000123.
6.1.12

Handling Dates in BDC Session

Date values in a BDC session should always be converted to a value as
per the user master so as to maintain consistency. To achieve the above,
make use of the function module DATE_STRING_CONVERT. In the
input parameters of this function we specify the format of the existing
date and its value. The output of the function module is the date as per
the User Master.
e.g.
FORM abc.
data: ws_date like sy-datum.
:
:
*--- Fix date.
CALL FUNCTION 'DATE_STRING_CONVERT'
EXPORTING
DATE_FORMAT = '4'
"4 = YYYY.MM.DD
DATE_STRING = date_value
*
START_DATE = SY-DATUM
IMPORTING
RESULT_DATE = ws_date.
write ws_date

to ...

ENDFORM.

" abc

Here ws_date contains date_value as the format in the User Master.

6.1.13

IF Comparison
Before doing IF comparisons on elements of different types (i.e.,
numeric to character), move one element to a variable of the
same type as the other element so that you will not experience
unexpected results. While ABAP will automatically convert

261454112.doc
Page

Version: 3
04 March 2003
75

elements of unlike types for you, the end result may not be what
the programmer expects.
When comparing quantity fields, make sure the quantities are in
the same unit of measure. Note that this is normally done by
looking at which field is used NOT by coding in a unit
conversion or validation.
6.2

Internal Tables - SAP Release 4.x

Table Declaration and Memory Allocation

Types: BEGIN OF <type>,
<fieldnames> ,
END OF <type>.

Data: <itab> TYPE <itabkind> of

<type>
[with [UNIQUE]/NON
UNIQUE] <keydef>
[INITIAL SIZE <n>],
<work area> TYPE <type>.

Examples
Standard - Non-Unique Key, accessed by key or indexing (predominantly by
indexing, also known as Index Tables). When the key is used, the time
increases linearly with the number of table entries.
TYPES: BEGIN OF T_MAT,
DATA: I_MAT TYPE STANDARD
WERKS LIKE MSEGTABLE OF T_MAT
WERKS,
WITH KEY NON-UNIQUE
MATNR LIKE MSEGMATNR
MATNR,
INITIAL SIZE 0,
END OF T_MAT.
WA_MAT TYPE T_MAT.
Sorted - Key is either Unique or Non-Unique, accessed primary by key or
indexing (predominantly by Key). When the key is used, the time is
logarithmic in relation to the number of table entries.
TYPES: BEGIN OF T_MAT,
DATA: I_MAT TYPE SORTED TABLE
WERKS LIKE MSEGOF T_MAT
WERKS,
WITH UNIQUE KEY
MATNR LIKE MSEGWERKS
MATNR,
INITIAL SIZE 10000,
END OF T_MAT.
WA_MAT TYPE T_MAT.
Hashed - Unique Key, accessed only by Key. Response time is constant and
does not depend on the number of entries.
261454112.doc
Page

Version: 3
04 March 2003
76

TYPES: BEGIN OF T_MAT,

WERKS LIKE MSEGWERKS,
MATNR LIKE MSEGMATNR,
END OF T_MAT.

DATA: I_MAT TYPE HASHED TABLE

OF T_MAT
WITH KEY WERKS
INITIAL SIZE 10000,
WA_MAT TYPE T_MAT.

The table type defines how ABAP accesses individual table

entries. There are now three different types of internal tables in
SAP Release 4.x: standard, sorted and hashed.
In a standard table, records can be accessed using either the
table index or the key. If a key is used, the response time is in
linear relation to the number of table entries. The key of a
standard table is always NON-UNIQUE. Standard tables are
generically known as index tables.
In a sorted table, the entries are always saved sorted according
to the key. It is possible to access the table using either the table
index or the key. When the key is used, the response time is in
logarithmic relation to the number of table entries, since the
system uses a binary search. The key or a sorted table can be
either UNIQUE or NON-UNIQUE. Sorted tables are
generically known as index tables.
Hashed tables can only be accessed using their key. The
response time is constant, and does not depend on the number of
table entries, since the system uses a hash algorithm to access
entries. The key of a hashed table must always be unique.
Sorted or hashed tables using index operations (INSERT ,
INDEX, APPEND) cannot be filled. Also it is not possible to
SORT a sorted table.
There are two types of keys for internal tables. Standard key
consists of all of the non-numeric fields from the internal table
that are not internal tables. User-defined key can consist of any
fields from the internal table that are not internal tables. The
additions UNIQUE and NON-UNIQUE determine whether the
table with type <itabtype> may contain entries with duplicate
keys.
261454112.doc
Page

Version: 3
04 March 2003
77

6.2.1

Memory Allocation for Internal Tables in SAP 4.x

Due to all of the internal table nesting that occurs, SAP has
needed to take better control of the memory allocation process
for internal tables. In Release 3.X, the memory for internal
tables was allocated in 8KB blocks. In Release 4.X there will be
a new algorithm to allocate memory.
Essentially, internal tables will now be expected to declare their
table type with an:
< initial size> * <row length> = initial allocation.
If that initial allocation is exceeded, the above equation will be
repeated up to 3 times. After that initial allocation has been
exceeded 3 times, memory is simply allocated in 12KB blocks.
Likewise, if no initial size is specified, SAP guesses (i.e. uses
an undisclosed algorithm).

6.3

Code to add Function Key to Reports

Use the following code to add Function keys to Reports. The
code helps in creating function buttons in a report without the
use of PF-STATUS.
*-------------------------------------------------------------------------------------*table for function button
tables: sscrfields, d0100.
:
:
*******************************************************
*****************
* SELECTION SCREEN
*******************************************************
*****************
*button to check sm35
selection-screen function key 1.
*button to check sm35
*for more buttons use key 2 and key 3 and key 4.

261454112.doc
Page

Version: 3
04 March 2003
78

:
:
INITIALIZATION.
* prepare SM35 button
sscrfields-functxt_01 = 'View SM35'. "for key 1
:
:
at selection-screen.
if sscrfields-ucomm = 'FC01'.
D0100-MAPN = PA_GROUP.
SET PARAMETER ID 'MPN' FIELD D0100-MAPN.
CALL TRANSACTION 'SM35'
AND SKIP FIRST SCREEN.
endif.
-------------------------------------------------------------------------------------The limitation to the above code is that max 4(four) function
keys can be added to the selection screen.

6.4

Logical Database
In most cases, it is likely that coding database retrievals with
SELECT statements will prove more efficient than using a
Logical Database (LDB) program. A LDB program reads tables
with nested SELECT loops. The depth of the SELECT into the
LDB hierarchy depends on the GET statement in the ABAP
corresponding to the tables located at the lowest level of the
LDB hierarchy. If a program does not need information from a
superior table in the hierarchy, unnecessary reads will occur.
Before using a LDB, be sure the logic cannot be coded more
efficiently using SELECT.
The Logical Database allows reading of hierarchically related
tables using GET statements. The advantages of the logical
databases are:
Ease of programming

261454112.doc
Page

Version: 3
04 March 2003
79

 Selection screen and filtering of the data

Authorization checking
If a LDB is chosen, the most efficient logical database possible
should be used. Study the selection criteria and which secondary
indexes are used for that view. Provide the appropriate selection
criteria to limit the number of database reads. Force users to
provide selection criteria by evaluating the selection criteria
entered on the selection screen during AT SELECTIONSCREEN event. Use Matchcodes for selection and report
sorting.
Considerations:
Access to database information via GET provides automatic
security checking and checking on key fields from the
selection screen. The SELECT statement will require both of
these operations to be coded.
When getting information from a hierarchy database via a
logical database view, the order in which you check
statements is important. Attempt to eliminate any data which
is not required at the earliest stage possible.
An ABAP report can work with only one logical database, but
every logical database can be shared by several reports.
When using a logical database, the selection screen of the
report is called automatically by the logical database
program. When using the SELECT statements the selection
screen must be programmed.
Even if a logical database will not be attached to your ABAP
Report, transaction SE36 is useful to learn. - especially the
secondary index tables and relationships between tables.
Logical Database Programs cannot be attached to Function
Modules.
When using Logical Databases, you must take into
consideration the following:
261454112.doc
Page

Version: 3
04 March 2003
80

 Determine if some of the selection screen fields can be

required fields. This would force the users to put in a value
into these fields limiting the number of rows retrieved within
the logical database program. The selection screen can be
dynamically modified by the program using the logical
database and using AT SELECTION-SCREEN output event.
Use the GET dbtab <fields> option to retrieve only the
fields needed by your program. This option requires the
initialization event to populate all internal tables with the
table name and the field name. Use help on GET for
additional information.
6.4

Subroutines
The three subroutine alternatives are:
FORM routines
Include programs
Call functions
Calling ABAP subroutines can create conflicts between the goals
of transparency, maintainability and performance. In each
individual case, consider the following:
How often is the form called?
How much time is required by the respective module call?
The guideline values for resource consumption:
Subroutine Type
Internal PERFORM
External PERFORM
CALL FUNCTION
CALL DIALOG

261454112.doc
Page

Microseconds
3
20-50
20-100
10,000-150,000

Version: 3
04 March 2003
81

6.4.1

Forms
FORMS are subroutines that allow a programmer to define a
process once in a program and call that routine from different
places within the program or from other programs. A FORM
should be used for large coding blocks. Common sections of
code accessed from several points in an ABAP should also be
put into FORMS.
If a block of code is executed more than once, it should be
placed in a subroutine at the bottom of the code. This makes the
code more readable, requires less indentation, and is easier to
debug since the debugger can jump through an entire subroutine
via a PF key.
For good modularization, the decision of whether or not to
PERFORM a subroutine should be made before the subroutine is
called.
Example:
More Efficient
IF f1 NE 0.
PERFORM sub1.
ENDIF.
FORM sub1.
.
ENDFORM.
Less Efficient
PERFORM sub1.
FORM sub1.
IF f1 NE 0.
EXIT.
ENDIF.
ENDFORM..
Considerations:
Dont use PERFORM<form name>(<program name>)
unnecessarily. Overall runtime will be increased because the

261454112.doc
Page

Version: 3
04 March 2003
82

entire program containing the actual perform must be loaded

into memory.
For manageability, subroutines should be created with the
concept of a black box in mind. The routine will have
certain input and output parameters, and knowledge of the
parameters should be sufficient to use the routine.
Subroutines should not, as a rule, reference global data.
Alterations made to global data within the black box produce
less manageable code.
Calling a subroutine without parameters requires minimal
extra CPU time. The more parameters passed, the more CPU
time a subroutine call requires. Passing by reference requires
less CPU time than passing by value. The amount of CPU
time required to pass a single parameter by value is
dependent on the size (field length) of the parameter.
Formal parameters must be fully typed.
6.4.2

Includes
An INCLUDE is a section of code which has been separated due
to program size or it is in common use by several programs.
Effective use of includes can reduce development and
maintenance time.
Consideration:
A program that uses include incorporates it at generation time, so
if the include is altered all the programs that use it must be regenerated. SAP has to regenerate if the last update date and the
regeneration date of the program are not the same.

6.4.3

Function Modules
For speed, internal routines are the fastest. Functions should be
used for general routines so maintenance can be performed
collectively. The routines are loaded into a buffer so their first
access is very slow. The most frequently accessed functions are
held sequentially in memory, and as new routines are used the
least frequent routines are dropped.

261454112.doc
Page

Version: 3
04 March 2003
83

For speed internal routines are quicker than Functions. Create

function calls discerningly. Perform does not require the load of
includes, etc. that call functions do. Therefore, create function
calls when code is used by multiple programs, otherwise use
perform.
Consideration:
A Function module and the calling program have separate
work areas. The separated work area means there is no data
interface between the function module and the calling
program. They are limited to the passing of import and export
parameters. This improves abstraction and manageability at
the cost of efficiency.
A CALL to a Function Module causes the loading of the
entire Function Group. Therefore, always limit the number of
function modules within a group to less than five.
Error handling in Function Modules
If the Exceptions are commented then the Function module will
display the error if the message command is written in it
otherwise the display of the message will be the responsibility of
the calling program.
It is recommended that the Exceptions should not be commented
and rather they should be handled in the calling program by
checking the value of sy-subrc.
Example
Call function .
Exporting

Importing

Tables

Exceptions

if sy-subrc <> 0.
message id sy-msgid type sy-msgty number sy-msgno
261454112.doc
Page

Version: 3
04 March 2003
84

with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.

endif.
The system variables in the message in the example above are
populated in the function module. It can however with
substituted with a program specific message.
6.4.4

Submit, Call, Leave To

The commands SUBMIT and SUBMIT AND RETURN can be
used to start another report and CALL and LEAVE TO can be
used to start another transaction. These commands can be very
useful to build integrated functions.
Considerations:
Commands which go back after execution use additional
ROLL area, therefore, to protect system performance;
complete one SUBMIT. AND RETURN prior to initiating
another.
LEAVE TO cannot be used in a transaction using BDC
processing.

6.5

SQL

6.5.1

ABAP Open SQL

The SAP programming language ABAP has its own dialect of
SQL. This is a rudimentary SQL language designed for database
compatibility and independence. The design philosophy was to
reduce SQL functionality to such a level that code written using
ABAP OPEN SQL was suitable for execution against all of the
major databases used by SAP, thus improving portability.
When using the SELECT statement, study the key and always
provide as much of the left-most part of the key as possible. If
the entire key can be qualified, code a SELECT SINGLE not just
a SELECT

261454112.doc
Page

Version: 3
04 March 2003
85

 Order the columns in the WHERE clause in the same order as

the key.
Avoid the use of LIKE with a pattern in an ABAP OPEN SQL
statement when accessing a large table .It is less efficient and can
cause scanning of the table.
Fields that are compared in SELECT statements should have
similar attributes. If they dont the system will have to convert
the data every time a comparison is made. When the data fields
cant be matched via table definitions, move the data to a
temporary field in the program before doing the compare (if you
will be using the same field for several comparisons)
Familiarize yourself with the data being processed before using
the SELECT statement. Table types greatly influence how the
ABAP program should process the data.
When using ABAP OPEN SQL, the user is restricted to data
pertaining to the client they are currently logged into unless the
table is client independent or client-specified is used.
When SELECTing data from a table, look at the structure of all
of the available indexes and tailor the WHERE clause to take
advantage of the most selective index.
As of Release 3.0, specific fields can be selected instead of using
the SELECT * statement. Specifying fields in the SELECT
statement reduces the amount of data to be retrieved from the
database. Therefore to improve performance select only the
fields that are required.
6.5.1.1

Data Selection from Transparent and Pool Tables

When selecting from a Transparent or Pool Table, always qualify
the SELECT statement as fully as possible with the WHERE
option. This includes data fields that may not be part of the key.
This allows the database to evaluate the records and return only
the records matching the selection criteria.
Example:

261454112.doc
Page

Version: 3
04 March 2003
86

* More efficient for Transparent & Pool tables

SELECT * FROM ZZLT2
WHERE RLDNR = W_LDGR
AND RRCTY = 0
AND RVERS = 001
AND RYEAR = W_YR
AND BUKRS = W_CMPNY
AND RACCT = W_ACCT
AND RCNTR = W_CNTR.
.
ENDSELECT
Will work, but requires more memory & buffers
SELECT * FROM ZZLT2
WHERE RLDNR = W_LDGR
AND RRCTY = 0
AND RVERS = 001
AND RYEAR = W_YR.
CHECK W_CMPNY.
CHECK W_ACCT.
CHECK W_CNTR.

ENDSELECT.

6.5.1.2

Data Selection from Cluster Tables

When working with Cluster tables, only qualify the SELECT
statements with fields that are part of the key. If the table is a
cluster table, use the CHECK command to eliminate records
after the selection has been narrowed via the WHERE clause for
key fields.
Cluster tables cannot be processed by the database directly,
compared to transparent tables. In most cases forcing the
database to unpack and check fields (as with SELECT
statements containing non-key fields in WHERE clauses) is less
efficient then qualifying only with key fields and letting ABAP
check non-key fields after the data is returned.

261454112.doc
Page

Version: 3
04 March 2003
87

Example: For cluster table BSEG with keys MANDT, BUKRS,

BELNR, GJAHR, and BUZEI:

6.5.1.3
SELECT
Aggregates

* Use the Check statement to evaluate non key fields

when selecting from Cluster tables
SELECT * FROM BSEG
WHERE
BUKRS = BSIK-BUKRS
AND REBZG = BSIK-BELNR.
CHECK BSIK-LIFNR = BSEG-LIFNR.
CHECK BSEG-SHKZG = S.
CHECK BSEG-KOART = K.
..
ENDSELECT.
*Works more efficiently for cluster tables, especially in
multiple application server environments.
* With Cluster tables dont specify non-key fields in
the WHERE clause
SELECT * FROM BSEG
WHERE
BELNR = BSIK-BELNR
AND BUKRS = BSIK-BUKRS
AND LIFNR = BSIK-LIFNR
AND SHKZG = S
AND KOART = K.
..
ENDSELECT.
*Will work, but requires a lot of available memory,
buffer space and database time to unpack non-keyed
data for verification/inclusion. This work takes place at
the database level and can be costly. Can overload single
DB servers and slow performance for all user.
When you need to find the maximum, minimum, sum, and
average value or the count of a database column, use a select list
with aggregate functions instead of computing the aggregates
yourself. The network load is considerably less.
Example:
Select using an aggregate function

261454112.doc
Page

Version: 3
04 March 2003
88

SELECT MAX(MSGNR) FROM T100 INTO C4A

WHERE SPRSL = D
AND ARBGB = 00.
*More Efficient
Select. Where + Check
C4A = 000.
SELECT * FROM T100
WHERE SPRSL = D.
CHECK T100-MSGNR > C4A.
C4A = T100-MSGNR.
ENDSELECT.
*Will work, but not Optimally

6.5.1.4

SELECT with BUFFER support.

If buffering is allowed for a table in the ABAP Dictionary, the
SELECT statement always reads the data from the buffer in the
database interface of the current application server. However, as
a rule, only data that does not change frequently should be
buffered, and using the buffer where appropriate improves
performance. This option should be used where really necessary.
Selecting from buffered tables is intended for tables that are
frequently used and read-only. Adding the BYPASSING
BUFFER parameter to the SELECT statement is less efficient.
Example:
Select without buffer support
SELECT * FROM T100 BYPASSING BUFFER
WHERE SPRSL = D
AND ARBGB = 00
AND MSGNR = 999.
*4,395 microsec
Select with buffer support

261454112.doc
Page

Version: 3
04 March 2003
89

SELECT * FROM T100

WHERE SPRSL = D
AND ARBGB = 00
AND MSGNR = 999.
*242 microsec
6.5.1.5

Group Level Data Access

In general, external table I/O (table reads, inserts, updates) are
much more efficient when done at a group level. Group-level
table accesses are less expensive in terms of disk I/O and CPU
cycles, and they are usually cleaner and easier to read.
Example 1:
Select into Table
REFRESH I_T006.
SELECT * FROM T006 INTO TABLE I_T006.
*Faster
Select and the append statement
REFRESH I_T006.
SELECT * FROM T006 INTO I_T006.
APPEND I_T006.
ENDSELECT.
*Will work, but if possible, use INTO TABLE
Example 2:
The group update will find all matching rows in the external table
and update them with the rows in the internal table.
Group Update using Table
UPDATE TADIR USING TABLE I_OBJECTS.
* More Efficient
Non-group update

261454112.doc
Page

Version: 3
04 March 2003
90

LOOP AT I_OBJECTS.
SELECT * FROM TADIR
WHERE PGMID = I_OBJECTS-PGMID
AND OBJECT = I_OBJECTS-OBJECT
AND OJB_NAME = I_OBJECTSOBJ_NAME.
TADIR = INT_OBJECTS.
UPDATE TADIR.
ENDSELECT.
ENDLOOP.
* Less Efficient

6.5.1.6

Column Update
When possible, use column updates instead of single-row
updates to update database tables
Example:
Column update
UPDATE VERI_CLNT
SET FUNCTINT = FUNCTINT + 1
* More Efficient
Single line update
SELECT * FROM VERI_CLNT.
VERI_CLNT-FUNCTINT = VERI_CLNTFUNCTINT + 1.
UPDATE VERI_CLNT.
ENDSELECT.
* Will work, but Less Efficient

6.5.1.7

Filling Internal Tables

It is always faster to use the INTO TABLE version of a SELECT
statement than to use APPEND statements

261454112.doc
Page

Version: 3
04 March 2003
91

Example 1:
Select Into Table
SELECT * FROM T006
INTO TABLE I_T006.
* More Efficient
Select + Append Statement
REFRESH X006.
SELECT * FROM T006 INTO I_T006.
APPEND I_T006.
ENDSELECT.
* More Efficient
As a general rule, use database views or the INTO TABLE
version of a SELECT statement with the addition FOR ALL
ENTRIES IN TABLE ITAB rather than using nested SELECT
statements. The latter (for all entries) is less efficient than using
database views but is more efficient than nested selects. When
using For All Entries in Table ITAB, it must be ensured that
ITAB is not initial.
6.5.1.8

UP TO nn ROWS
The ABAP UP TO nn construct causes as many FETCHs to be
executed until sufficient rows have been returned to satisfy the
nn requirement. When coding a construct of this type, use SQL
Trace to examine the output to see how many records can be
retrieved with a single FETCH and adjust your Initial Size and
UP TO values appropriately. When examining the trace screen,
look for the FETCH xx Array: nnn statement. This gives the
optimum value for the size of the UP TO and Initial Size in the
program

6.5.1.9

ABAP Open SQL Enhancements SAP Release 4.x

6.5.1.9.1

Inner Join

261454112.doc
Page

Version: 3
04 March 2003
92

Inner Join Provides the capability to produce a set of results

from multiple tables via one SELECT statement.
SELECT F1~CARRID F1~CONNID F1~FLDATE
F2~CUSTOMID INTO
(SFLIGHT-CARRID, SFLIGHT-CONNID, SFLIGHTFLDATE, SBOOK-CUSTOMID)
FROM SFLIGHT AS F1 INNER JOIN SBOOK AS F2
ON F1~CARRID = F2~CARRID
AND F1~CONNID = F2~CONNID
AND F1~FLDATE = F2~FLDATE.
The INNER JOIN provides the capability to produce a set of
results from multiple tables via one SELECT statement (as
opposed to nested selects). Views created in the data dictionary
can be considered as inner joins. Since views are buffered, there
will be instances when a view will be used over an inner join
depending on the tables. Further investigation per situation
should be done using the Runtime Analysis Tool in SE30.
If field names are used in the field list that occur in both tables of
the inner join, they must be made unique by either prefixing them
with an alias name and a tilde OR the table name and a tilde.
Overall, the result of an inner join is the same, regardless of
whether the condition is expressed in the ON or WHERE clause.
Using a join has the added advantage that only one statement is
executed in the database. However, it has the disadvantage that
redundant data from the outer table appears in the result if there
is a 1:N relationship between the outer and inner tables. For this
reason, when a join is used, only necessary fields should be
specified. Likewise, the performance of a join depends heavily
on the performance of the database optimizer that is used,
especially if there are more than 2 tables in the join.
6.5.1.9.2

Left Outer Join

Outer Join Similar to an Inner Join, except the result of a
LEFT OUTER JOIN depends on whether the condition is
specified in the ON or the WHERE clause.
SELECT F1~CARRID F1~CONNID F1~FLDATE
F2~CUSTOMID INTO

261454112.doc
Page

Version: 3
04 March 2003
93

(SFLIGHT-CARRID, SFLIGHT-CONNID, SFLIGHTFLDATE, SBOOK-CUSTOMID)

FROM SFLIGHT AS F1 LEFT OUTER JOIN SBOOK AS F2
ON F1~CARRID = F2~CARRID
AND F1~CONNID = F2~CONNID
AND F1~FLDATE = F2~FLDATE
ORDER BY F1~CARRID F1~CONNID F1~FLDATE.
Unlike an INNER JOIN, the result of a LEFT OUTER JOIN
depends on whether the condition is specified in the ON or the
WHERE clause. Without a WHERE clause the resulting table
will always contain all the lines of the left table, whereas with a
WHERE clause, records from the left table can be taken out.
Table entries appear in the join result even if there is no
corresponding record in the right-hand table. This is the
equivalent of the nested SELECT statement in the result set.
There are restrictions on the LEFT OUTER JOIN. For example,
the only logical expressions allowed with the ON clause are =
& AND. Also, the ON clause must contain fields from the righthand table and the ON clause must contain at least one field
comparison of the form tab1~field1 = tab2~field1. In addition,
the WHERE clause can only contain fields from the left-hand
table.
6.5.1.10

Catch / Endcatch
Catch/Endcatch - The CATCH and ENDCATCH statements
allow for the implementation of global exception handling.
CATCH SYSTEM-EXCEPTIONS CONVT_NO_NUMBER = 1
BCD_ZERODIVIDE = 2
OTHERS
= 3.
ENDCATCH.
CASE SY-SUBRC.
WHEN 1.
WRITE: / 'Numeric conversion error.'.
WHEN 2.
WRITE: / 'Divide by zero error.'.
WHEN 3.
WRITE: / 'Unknown run time error has
occurred.'.
ENDCASE.

261454112.doc
Page

Version: 3
04 March 2003
94

The CATCH and ENDCATCH statements allow for the

implementation of global exception handling. They form a
processing block to allow the trapping of ABAP runtime errors
(and errors from function modules and methods with 4.0C). The
CATCHENDCATCH statements can be nested to any depth.
If the relevant runtime error occurs in the CATCH processing
block, the system jumps from the ABAP statement where the
error occurred directly to the ENDCATCH statement regardless
how many control structure levels exist (e.g., IF, DO, SELECT,
CATCH). In addition, the return value <rcn> assigned to the
system exception <excptn> is placed in the system field SYSUBRC. If there is more than one expression <exceptn> =
<rcn>, the <rcn> the first expression is returned. This is
particularly important if two different ERROR classes contain
the same runtime error.
6.5.2

Native SQL
The use of native SQL provides the programmer with greater
flexibility but increases the responsibility to produce efficient
code. In addition, native SQL can improve performance but
increases responsibility. Personnel need to be multiskilled as
maintenance becomes more difficult.
Considerations:
The buffering of tables will not be beneficial if Native SQL is
used.
Unlike ABAP OPEN SQL, the programmer needs to be
concerned with the MANDT field. In ABAP OPEN SQL,
WHERE MANDT = is added to the SELECT statement; with
native SQL, the programmer needs to code WHERE
MANDT = :SY-MANDT.
The use of native SQL for INSERT, UPDATE, and DELETE
operations is not recommended for standard SAP tables.
As native SQL directly accesses the underlying database and
bypasses the buffer for SAP buffered tables, native SQL
should only be used for read-only tables.

261454112.doc
Page

Version: 3
04 March 2003
95

 With the use of SQL, there is a potential loss of portability.

6.6

String Manipulation

6.6.1

CONCATENATE
Use the CONCATENATE statement instead of programming a
string concatenation.
Example:
Use of the CONCATENATE statement
MOVE Jane TO W_MA.
MOVE Miller TO W_MB.
MOVE New York City TO w_MC.
CONCATENATE Mrs.
w_MA w_MB
from
w_MC INTO CHA SEPARATED BY
SPACE.
Mrs. Jane Miller from New York City is the final
value of CHA
* More Efficient
Moving with Offset
MOVE Jane TO w_MA.
MOVE Miller TO w_MC.
I1 = STRLEN( w_MA ).
I2 = STRLEN( w_MB )
MOVE Mrs. TO W_CHA.
MOVE w_MA TO CHA+5. I1 = I1 + 6.
MOVE w_MB TO CHA+11. 1 = I1 + 12 + 1.
MOVE from TO CHA+I1.I1 = I1 + 5.
MOVE w_MC TO CHA+11.
Mrs. Jane Miller from New York City is the final
value of CHA
* Less Efficient

261454112.doc
Page

Version: 3
04 March 2003
96

Some string manipulation functions have become obsolete in

Release 3.0 and can be replaced by an ABAP statement or
functions:
STRING_CONCATENATE
CONCATENATE
STRING_SPLIT
SPLIT
STRING_LENGTH
STRLEN()
STRING_CENTERED
WRITE TO
CENTERED STRING_MOVE_RIGHT
WRITE
TO RIGHT-JUSTIFIED
Example:
Use of the CONCATENATE Statement
CONCATENATE T100-ARBGB
T100-MSGNR
T100-TEXT
INTO w_CLA.
* Standard in Release 3.0
Use of a CONCATENATE function module
CALL FUNCTION STRING_CONCATENATE_3
EXPORTING
STRING1 = T100-ARBGB
STRING2 = T100-MSGNR
STRING3 = T100-TEXT
IMPORTING
STRING = w_CLA
EXCEPTIONS
TOO_SMALL = 01.
* Obsolete in Release 3.0
6.6.2

Removing Leading Spaces

If leading spaces in a string are to be deleted, use the ABAP
statement
SHIFT LEFT

DELETING LEADING

Avoid using SHIFT inside a WHILE loop.

Example:
261454112.doc
Page

Version: 3
04 March 2003
97

Using SHIFT LEFT DELETING LEADING

W_CLA contains the sting

Editor line n.
SHIFT W_CLA LEFT DELETING LEADING
SPACE.
* More Efficient
Shifting by SY-FDPOS places
W_CLA contains the sting

Editor line n.
IF W_CLA CN SPACE. ENDIF.
SHIFT W_CLA BY SY-FDPOS PLACES LEFT.
* Less Efficient

6.6.3

SPLIT
Use the SPLIT statement instead of programming a string split.
Example:
Use of the SPLIT statement
* W_CMA contains '(410)-45174-66354312' and shall
be split into
* W_AREA_CD, W_TEL_NBR1, TEL_NBR2
SPLIT W_CMA AT '-' INTO W_AREA_CODE
W_TEL_NBR1
W_TEL_NBR2.
* More Efficient
Use of SEARCH and MOVE with offset

261454112.doc
Page

Version: 3
04 March 2003
98

*W_CMA contains '(410)-45174-66354312' and shall

be split into *AREA_CD, TEL_NBR1, TEL_NBR2.
SEARCH W_CMA FOR '-'.
MOVE W_CMA(SY-FDPOS) TO W_AREA_CD.
I1 = SY-FDPOS + 2.
SEARCH W_CMA FOR '-' STARTING AT I1.
I1 = I1 - 1.
MOVE W_CMA+I1(SY-FDPOS) TO TEL_NBR1.
I1 = I1 + SY-FDPOS + 1.
MOVE W_CMA+I1 TO TEL_NBR2.
* Less Efficient
6.6.4

STRLEN
The ABAP function STRLEN returns the length of a string up to
the last character that is not a space.
Example
* Display the length of the variables w_word1,
w_word2 and w_word3
DATA: W_INT TYPE I,
W_WORD1(20) VALUE 'ABCDE'.
W_WORD2(20).
W_WORD3(20) VALUE ' 4 '.
W_INT = STRLEN( W_WORD1 ). WRITE W_INT.
W_INT = STRLEN( W_WORD2 ). WRITE / W_INT.
W_INT = STRLEN( W_WORD3 ). WRITE / W_INT.
The results are 5 , 0, and 1 respectively.

6.7

FIELD-SYMBOLS
Use the ASSIGN and FIELD-SYMBOLS statements to provide
the powerful functionality of pointers. FIELD-SYMBOLS are
place holders for fields. A FIELD-SYMBOL does not occupy
memory, but points to a position that has been ASSIGNed to the
FIELD-SYMBOL at runtime. After the FIELD-SYMBOL has

261454112.doc
Page

Version: 3
04 March 2003
99

been ASSIGNed to an object, it can be worked with the same

way as the object itself.
Example:
A data string contains two types of fields. Field 1 contains the
length of Field 2; Field 3 contains the length of Field 4. This
occurs until the length field contains 0 or the total length is over
3000.
PARAMETERS:
P_FL_IN(70).
DATA:
INPT_RCRD(3000),
POSITION TYPE I,
LENGTH TYPE N.
SYMBOLS <ENTRY>.

FIELD-

DO.
READ DATASET P_FL_IN INTO INPT_RCRD.
IF SY-SUBRC NE 0.
EXIT.
ENDIF.
LENGTH =
INPT_RCRD+POSITION(3).
IF
LENGTH = 0.
EXIT.
ENDIF.
ADD 3
TO POSITION.
ASSIGN INPT_RCRD+POSITION(LENGTH) TO
<ENTRY>.
WRITE <ENTRY>.
IF POSITION >= 3000.
EXIT.
ENDIF.
ENDDO.
Considerations:
As FIELD-SYMBOL references are only established at
runtime, the syntax does not always detect errors such as type
conflicts. This could cause runtime errors or incorrect data
assignments. As of Release 3.0, to avoid the possibility of a
261454112.doc
Page

Version: 3
04 March 2003
100

type conflict, you can declare FIELD-SYMBOLS with a

TYPE.

6.8

General Statements
Logical expressions are evaluated from left to right. The
evaluation is ended when the final result has been established
(elimination or complete inclusion). Therefore, when using
AND or OR operator (in IF, WHERE, etc.), the most likely
elimination criterion should be specified first. The opposite
will be true for negative comparisons and some OR
conditions.
Example:
The following table is to be read with printing of employees from
ABC company in Georgia:
EMPLOYE
E
001
002
003
004
005
006
007
008
009
010

NAME
Doe, J
Doe, M
Jones, A.
Jones, B.
Jones, C.
Jones, D.
Jones, E.
Smith, A.
Smith, B.
Smith, C.

COMPAN
Y
ABC
ABC
XYZ
ABC
ABC
XYZ
ABC
ABC
ABC
ABC

STATE
TX
OK
TX
GA
TX
GA
TX
GA
TX
OK

Less Efficient
IF COMPANY = ABC
AND STATE = GA.
WRITE
ENDIF.
Will work, but will need to evaluate both the company
and state fields for eight of ten records.
261454112.doc
Page

Version: 3
04 March 2003
101

More Efficient
IF STATE = GA
AND COMPANY = ABC.
WRITE
ENDIF.
Will need more time to process, since it can eliminate all
records without STATE = GA and therefore will need
to evaluate both company and state for only 3 records.
Use special operators CO (Contains Only), CA (Contains
Any), CS (Contains String) instead of programming the
operations yourself. If ABAP statements are executed per
character on long strings, CPU consumption can rise
substantially.
Example:
Do-Loop with Field-Symbols
ASSIGN CHA(1) TO <C>.
DO 200 TIMES.
IF <C> = ( OR <C> = ).
.. any actions
EXIT.
ENDIF.
ASSIGN <C>+1 TO <C>.
ENDDO.
1263 microsec
Using the CA Operator
IF CHA(200) CA ().
any actions.
ENDIF.
443 microsec
When testing fields equal to something, use either the
nested IF or the CASE statement. CASE is better for two
reasons. It is easier to read and after about five nested IFs the
performance of the CASE is more efficient.
261454112.doc
Page

Version: 3
04 March 2003
102

When records a and b have the exact same structure, it is

more efficient to MOVE a to b than to MOVECORRESPONDING a to b, if records a and b have the exact
same structure.

Example:
More Efficient
MOVE BSEG TO *BSEG
Less Efficient
MOVE-CORRESPONDING BSEG TO *BSEG

6.9

SAP Release 4.0X Object Oriented Programming

Example:
REPORT Flightdemo.
TYPES: tpassenger(20).
CLASS c_flight DEFINITION.
PUBLIC SECTION.
DATA:
carrid like spfli-carrid,
connid like spfli-connid,
fldate like spfli-fldate.
METHODS: book IMPORTING passenger TYPE tpassenger.
PRIVATE SECTION.
DATA:
passengerlist type tpassenger occurs 10.
ENDCLASS.s
CLASS c_flight IMPLEMENTATION.
METHOD book.
APPEND passenger to passengerlist.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
DATA: flight TYPE REF to c_flight.
CREATE OBJECT flight.
Flight->carrid = LH.
Flight->connid = 0567.
Flight->fldate = 19970908.
CALL METHOD flight->book EXPORTING passenger = Peter
Miller.

261454112.doc
Page

Version: 3
04 March 2003
103

Object Orientated Programming (OOP) re-defines

modularization and can produce software more tolerant of
change.
Classes Define Objects
Sections
Public components are visible outside the class
Protected components are visible to subclasses of that class
Private components are only visible within the class itself.
Attributes and Methods Assigned to a section
Attributes define the internal state of an object, defined using
a DATA statement.
Store an objects properties
Reference other objects
Virtual, controlled by set/get methods and Read Only
Methods Operations that are applied to objects.
Interface is similar to function modules.
Import and export parameters
Pass a return value and can raise exceptions.
Objects Instances of Classes
Objects belong to classes and have the same attributes and
respond to the same methods as other objects in that class.
Objects have: State, as described by its attributes, behavior,
described by its methods, and an identity.
Objects may interact: by accessing public attributes, by calling
methods, or by raising and handling events.

261454112.doc
Page

Version: 3
04 March 2003
104

7.

Hints and Tips

You can use the Edit and Pattern Statement to set up

statements, for example WRITE or CASE. You will get the
shell of your statement already set up and you just have to
enter your variables.

If problems occur with data in your internal tables, check that

the fields are declared in the data declaration section in the
same order that they occur in the original table. Also, check
to see that when you are grabbing the values for the internal
table that the fields are in the same order as in the declared
table statement.
Use the Pretty Printer to line up your code so that statements
such as if-endif are easy to read. Select Pretty Printer with
the settings indent and convert to Lowercase.
Copy and paste working code from other reports as much as
possible to save time and avoid errors.
Put all words and names that appear on your reports into text
elements so that they can be maintained easily.

When inputting OSS notes, if you have to input large sections

of code, copy the OSS note to .txt format and then using the
Tools and Upload functionality, upload the code directly into
your program therefore reducing the chance of any spelling
errors or mistakes.

Before a piece of code goes live, it is always a good idea to

ask another programmer to do a code review for you. They
can either look at the program in their own time or you can go
through the program with them. The checker maybe able to
see any problems or possible performance enhancements of
your code and may be able to offer advice.
Do not declare the initial size of an internal table. Leave this
as 0 of which the system will dynamically allocate memory to
however many are required. It is more efficient than
261454112.doc
Page

Version: 3
04 March 2003
105

declaring occurrence of 1000 and the system allocates

memory for 1000 but you only use a few.
When declaring a field, try to use the LIKE statement to give
your variable the same characteristics of an already defined
variable.
Always check ABAP statements return value SY-SUBRC,
whether an operation was successful. Can be used in
READ, INSERT, MODIFY, DELETE, SELECT,
CALL FUNCTION etc.
For more details refer to the ABAP code review checklist
which is given in the Appendix below.
Use Perform instead of a new print program for layout jobs.
Remove redundant code from the program in the final
delivery.
When SELECTing data from text table ensure that the
language is included in the where clause using SY-LANGU.

261454112.doc
Page

Version: 3
04 March 2003
106

Appendix
1/ Conversion Process
The purpose of this Appendix is to provide clear guidelines for
building Conversion Programs and Conversion Reporting.
1.

Building Conversion Programs

SAP provides a number of Standard Upload Conversion
programs. If no Standard Conversion program exists a Custom
ABAP program will be built.
Where a Standard Conversion program does exist, the program
requires the input data in a specified structure/format.
Consequently, a custom ABAP program must be built to
manipulate and map the data. Therefore the standard process
will be the development of a Custom ABAP program to produce
a file that meets the SAP Standard Upload programs
requirements. The new file will be passed into the Standard
ABAP. A list of standard SAP programs for data upload is
provided later.

1.1

File Upload
In interface programs, when you upload the data from file to
internal table then all the fields should be character type only
otherwise it may cause a short dump. Once the data is there in
the character fields it is then validated for containing values as
per its required field type. Incorrect records are rejected as errors
and correct records are passed ahead for further processing. This
prevents any short dumps. Also, translate to upper case all
character fields (exclude descriptive text fields) of inbound files
first, and then use them in validations against SAP tables.

1.2

File Transfer

261454112.doc
Page

Version: 3
04 March 2003
i

When a transfer of the file from workstation to application server

is required then transfer mode should always be ASCII only.
When the file is opened for reading the data from application
server then use in text mode.
Eg. open dataset p_ifile for input in text mode.
Where p_ifile is file name with path.

IN TEXT MODE
Effect: If this addition is used, the contents of the file are
structured in lines. Each time the READ DATASET or
TRANSFER statement are used, the system reads or writes a
single line.
IN BINARY MODE
Effect: The contents of the file are not structured in lines in the
READ DATASET or TRANSFER operations. Instead, they are
input or output as a stream. There is no need to specify the IN
BINARY MODE addition explicitly.
Note
Only one of the additions IN TEXT MODE and IN
BINARY MODE can be used in a single statement.
Mode of upload Mode of opening Result
the data
the file
Binary
Binary mode
# appears as
character in
record
Binary
Text mode
# appears as
character in
record
ASCII
Binary mode
# appears as
character in
record
ASCII
Text mode
Without #.
261454112.doc
Page

a last
each
a last
each
a last
each

Version: 3
04 March 2003
ii

1.3

Text file for .CSV File

While uploading the file (*.CSV, Comma separated file) in
interface job, if contents of any of the text field in the input file
contains comma , it must be separately taken care of
(automatically taken care in MS Excel) and the text should have
identifier to signify the start and end of text field data.
Eg.
: Plant, Schedule Code, Schedule
Description, Date
Data Record no. 1 : P100,DLY100,Daily Schedule,01012001
Data Record no. 2 : P100,DLY200,Monday,
Tuesday,Schedule,01012001
Data Record no. 3
: P100,DLY200,Monday,
Tuesday,Schedule,01012001
Note: Record no. 2 in the field schedule description contains
as an identifier, quotes signify the start and end of the
schedule description and comma inside the quotes is data itself
and not a field separator.
Note: Record no. 3 doesnt contain quotes for schedule
description. As a result system will consider Monday as
Schedule Description and Tuesday as Date.

2.

Conversion Reporting
Each Conversion program should generate the following reports:
1/ Conversion Statistics Report: This is a breakdown of
conversion statistics (ie/ Total number of records in the input file;
total number of records processed; total number of records
containing errors).
2/ Major Error Report: This is a list of all the records, which
contained major errors (ie/ No value for a mandatory field;
incorrect/non SAP Standard value for a mandatory field;
incorrect/non SAP standard value for any field with a check
table). It should also detail records which have failed because

261454112.doc
Page

Version: 3
04 March 2003
iii

Select statements have not been able to return an SAP value (eg/
Purchase Order Conversion will take a legacy system Vendor
number and use it to try to find the SAP Vendor Number).
A page break should exist between these reports. Each of the
conversion programs should use the same Report format.
3.

BDC Sessions vs. Call Transactions

If the requirements deem that BDC sessions are not needed in a
finished state (for user review/comfort), use CALL
TRANSACTION and create a BDC session for error
transactions with errors.

4.

Conversion Testing
All Custom Conversion ABAPs should be unit tested prior to
being signed off as completed. It is assumed that in cases where
the Conversion process comprises a SAP Standard and a Custom
ABAP ABAP, both will be unit tested. The text file will be
passed through the SAP Standard ABAP, all the way to executing
the BDC Session. Test scripts and data should be provided to
the Conversion functional and technical Designers.

261454112.doc
Page

Version: 3
04 March 2003
iv

2/ EDI Modifications
When modifying SAP supplied EDI function modules, the
following steps should be followed:
1. Copy SAP standard function module
An exact copy of SAPs standard EDI function modules will be
made for those transactions that Novartis will be using. These
copies will keep the same name as the original, but will be
prefixed with Z_CCa ( CC = Country Code, a = application
ID). The name of the function module will serve as the link
back to the SAP original version.
2. Modifications and commenting
Modifications are made directly in the code of the customer
function module. The modification should be commented in such
a way as to allow easy readability and tracking of updates.
Modifications should only include adding lines of code and
commenting out of SAP code, if necessary. SAP standard code
should never be deleted or changed. The modifications should
be commented and marked with a search string as described in
Section 4 above.
3. OSS notes should be applied simultaneously to SAP
standard and custom function modules
This will ensure that both function modules are kept in sync. It
also ensures that the only differences in the two function modules
are the commented modifications made as a result of as GAP.
This will make it easier in the future to identify SAP bugs
independently from the modifications made at Novartis.
The advantages and disadvantages to this method are outlined in
the following table:
Advantages
Ease of code maintenance and
modification
261454112.doc
Page

Disadvantages
SAP lack of support for
customer function modules
Version: 3
04 March 2003

Minimal upgrade impact.

Customer function modules will
remain unchanged. - no chance of
overwrite.
Performance can be fine-tuned
more easily by removing
unnecessary generic lookups
(depends on customer-specific
needs).

Migration of upgraded
enhancements in SAP standard
function modules to customer
function modules.

3/ Correction and Transport System (CTS) Naming Standards

1.

Introduction
The purpose of this document is to outline the naming
convention that should be followed for the creation of Transports
for ABAP development jobs in the development environment.
A rigorous naming convention is the cornerstone of effective
version management and change control in an SAP landscape.
The Transport description will allow the technical team to audit /
track / group changes in the system. It will also allow the
technical team to identify and correct errors when they occur.
In short a good naming standard will allow the technical team
and the Basis engineers to better support the project.
It should be noted that the basis team will be instructed not to
move any transports from Development which do not comply
with the naming standard outlined below.

2.

Standard Outline
This section will review some of the main fields of relevance in
the transport, and which are regularly used as a basis for
reporting.
Transport No.
The transport no is automatically assigned by the SAP system to
each CTS.

261454112.doc
Page

Version: 3
04 March 2003
vi

Sample Transport No:

DO3K003428

The first 3 letters refer to the Instance where the transport is

being created, (transport nos are client independent). K
Delimiter. Finally a sequential 6 digit number that identifies the
transport.
For info. SAP supplied transports e.g. for Service Packs/ Hot
Packets follow the SAP naming convention i.e. These are not
prefixed with our system Id
Short Description
This field is the main focus of this document. The short
description is a 60 character free text field which is completed
by the creator of the transport request. This is one of the primary
fields used by the technical team for reporting.
Outlined below is the structure which must be followed when
creating a Transport request.
Position
1-3
4
5.6
name)
7
8-11

Text
Valid 3-character prefix e.g. NCC
Dash -
SAP module name (Pick from Functional spec

Dash -
Type of program (Pick from Functional spec name
e.g. CON, REP, etc.) followed by a space
12
Dash -
13.16
Valid sequence number (Prefix 0 to the 3
digit number
obtained from Functional spec name)
17.24
Valid date in YYYYMMDD format
25+
Valid R/3 user id, followed by space, followed by
free form text.
Example:
NCC-FI-CON 000220030121ROUTRAB1 Chart of
Accounts Conversion

261454112.doc
Page

Version: 3
04 March 2003
vii

The 3-character prefix for the transport description should be

chosen from the following table:
Prefix
CAT
DMC
DNT
DVC
GUE
NCC
OSS
USC
UUE

Description
CATT SCRIPTS
DEDUCTION
MANAGEMENT
DO NOT TRANSPORT!
DEVELOPMENT CLASSES
GLOBAL USER EXIT
NOVARTIS
CONSUMER
CORE
OSS NOTES
US
SECURITY
AND
CONTROLS
US USER EXIT

Note: When creating Transport Requests for any User Exit jobs,
please use the prefix GUE.
The following aspects related to organization of CTS should be
adhered to:
Objects of the same program in one transport request.
Objects for global use in separate request one for each ABAP
object. Create related group of global objects in one request.

261454112.doc
Page

Version: 3
04 March 2003
viii

4/ SAP Standard Conversion Programs

Business Object

Program/Transaction Code

Financial Accounting
Financial Accounting

Accounting documents
Assets

Financial Accounting
Financial Accounting
Financial Accounting

G/L account master

Customer master
Vendor master

RFBIBL00
RAALTD01 (Batch Input)
RAALTD11 (Direct Input)
RFBISA00
RFBIDE00
RFBIKR00

FI-Bank Data

Transfer of Bank Data

(Austrian)
Transfer of Bank Data (Canada)
Transfer of Bank Data
(Germany)
Transfer of Bank Data (Great
Britain)
Transfer of Bank Data (Italian)
Transfer of Bank Data (Spanish)
Transfer of Bank Data (Swiss)

RFBVAT_0

RPUSTD00

Human Resources
Human Resources

Master data (Organizational

Units)
Payroll account
Personnel planning data

Materials Management
Materials Management

Create characteristics
Create classes

RCCTBI01
RCCLBI01

FI-General Ledger
FI-General Ledger
FI-General Ledger
Human Resources

261454112.doc
Page

RFBVCA_0
RFBVD_ _2
RFBVGB_0
RFBVIT_0
RFBVES_0
RFBVCH_0

RPULKT00
RHALTD00

Version: 3
04 March 2003
vi

Business Object
Materials Management
Materials Management
Materials Management
Materials Management
Materials Management

Materials Management
Materials Management
Materials Management
Materials Management
(EH&S)

Plant Maintenance
Plant Maintenance
Plant Maintenance
Plant Maintenance
Plant Maintenance
Plant Maintenance
Plant Maintenance
Plant Maintenance
Plant Maintenance
Plant Maintenance
Plant Maintenance

Program/Transaction Code

Create classification
Change classification
Material master
Purchase information records
Purchase requisitions
Open purchase order

RCCLBI02
RCCLRI03
RMDATIND
RM06IBI0
RM06BBI0
RM06EEI0 Purchase Order
RM06EEI1 Order
Development
RSTXLITF Long Texts
Reservations
RM07RRES
Stocks (Inventory Management) RM07MMBL
Vendor master
RFBIKR00
Phrases
CG31
Sources
Substances

CG32
CG33

Measuring point
Measurement document
Notifications - general
Functional location
Object link
Equipment
Maintenance plan
Scheduling maintenance plan
Order confirmation
Equipment task list
General maintenance task list

RIIBIP00/IBIP
RIIBIP00/IBIP
RIIBIP00/IBIP
RIIBIP00/IBIP
RIIBIP00/IBIP
RIIBIP00/IBIP
RIIBIP00/IBIP
RIIBIP00/IBIP
RIIBIP00/IBIP
RIIBIP00/IBIP
RIIBIP00/IBIP

261454112.doc
Page

Version: 3
04 March 2003
vii

Business Object

Program/Transaction Code

Plant Maintenance

Functional location task list

RIIBIP00/IBIP

Production Master Data

Production Master Data
Production Master Data
Production Master Data

Create bill of material

Change bill of material
Create variant bill of material
Create bill of material with long
texts
Routings/task lists
Documentation info record

RCSBI010
RCSBI020
RCSBI030
RCSBI040

Production Planning

Demand management

RMMM60BI (Batch Input)

RM60IN00 (Direct Input)

SAP-EIS

Several records for SAP-EIS

RKCFILE0

Sales and Distribution

Sales and Distribution
Sales and Distribution
on

Condition records (pricing)

Customer master
Open sales orders

RV14BTCI
RFBIDE00
RVINVB00

Invoicing external transactions

RVAFSS00

Production Master Data

Warehouse Management Storage bins

Stocks on Storage Bins

261454112.doc
Page

RCPTRA01
RCVBI010

RLPLAT00
RLBEST00

Version: 3
04 March 2003
viii