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
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 TAB-STRIPS..................................31
3.7
SMART FORMS..................................................................................................................................... 31

279114320.doc
Page

Version: 3
04 March 2003
i

4.

ABAP INTERNAL NAMES..............................................................................................................................33

4.1
4.2
4.3
4.4

5.

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

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
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

279114320.doc
Page

Version: 3
04 March 2003
ii

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
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.
2.

INTRODUCTION........................................................................................................................................... V
STANDARD OUTLINE.................................................................................................................................. V

4/ SAP STANDARD CONVERSION PROGRAMS................................................................................................VI

279114320.doc
Page

Version: 3
04 March 2003
iii

1. Document Revision History

Date
29 January 2003
05 February 2003
04 March 2003

Version
#
1
2
3

Requester
Vineet Bhatia
Vineet Bhatia
Vineet Bhatia

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

279114320.doc
Page

Change Description

Version: 3
04 March 2003
1

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
SELECTION-SCREEN 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 CTS (Correction and Transport System), this is
contained within the Appendix of this document.

279114320.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:Z
(1)

Type
(1)

Proc1
(2)

Req Num
(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.
Req Num (character 5, 6):
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):

279114320.doc
Page

Version: 3
04 March 2003
3

The _ symbol will be defined as separator.

Brief Desc (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 worklist 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 worklist.
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
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

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

279114320.doc
Page

Version: 3
04 March 2003
4

Development Class
ZNCT
ZNCV
ZNCX
ZNCZ

3.1.3

Description
Novartis Consumer Health - Temp. Dev. (Conversion
programs)
Novartis Consumer Health - Sales & Distribution
Novartis Consumer Health - Material Master Data
Management
Novartis Consumer Health - Cross application

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 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

279114320.doc
Page

Version: 3
04 March 2003
5

3.1.6

Layout Sets
SAPscript 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, SAPscript 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 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.

279114320.doc
Page

Version: 3
04 March 2003
6

3.1.10

Lock 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).

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.

279114320.doc
Page

Version: 3
04 March 2003
7

279114320.doc
Page

Version: 3
04 March 2003
8

2. Choose Logical file name definition, cross-client

279114320.doc
Page

Version: 3
04 March 2003
9

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

279114320.doc
Page

Version: 3
04 March 2003
10

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
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

279114320.doc
Page

Version: 3
04 March 2003
11

3.2.3

3.2.4

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

Status

SAP standard production program.

Customer production program.

System Program.

Test Program.

In SAP implementation, all programs are developed as Customer Production Programs.

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.

279114320.doc
Page

Version: 3
04 March 2003
12

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.

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

279114320.doc
Page

Version: 3
04 March 2003
13

of the main program. An overall description 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
29/05/01
Shivapriya
DEV190001
*---------------------------------------------------------------

Description
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.

DevK9000045
DevK9000045 ENDIF.

Exit.

DevK9000045
Or
Begin of DevK9000045
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:
******************************************
function module formats and posts
MB01 - Post Goods Receipt
******************************************
FUNCTION POST_GOODS_RECEIPT

279114320.doc
Page

* This
* transaction
* via CALL transaction
CALL
EXPORTING
TCODE = W_TCODE

Version: 3
04 March 2003
14

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.

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:
*----------------------------------------*
F_xxxxxxxxxxxxxx
*-----------------------------------------*
descriptive text here

279114320.doc
Page

FORM

Insert a

Version: 3
04 March 2003
15

*----------------------------------------*
F_xxxxxxxxxxxxxx

FORM

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
xxxxxxxx.

* INCLUDE

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 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
10
15

xxxxxxx1,
xxxxxxx2,
xxxxxxx3.

Incorrect
279114320.doc
Page

Version: 3
04 March 2003
16

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
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

279114320.doc
Page

Version: 3
04 March 2003
17

SELECT-OPTIONS
CONSTANTS
DATA
RANGES
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:
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.
279114320.doc
Page

Version: 3
04 March 2003
18

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 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.

279114320.doc
Page

Version: 3
04 March 2003
19

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 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.1Menu 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> <object>
Other
<object>
Create
Change
Display
Copy
-------------Save
-------------Print

Edit
Select all

Goto
See
below

Deselect
all
Select
block
Choose

----------Back

Extras
See
below

Environment
See below

View
See
below

Settings
See
below

Utilities
See
below

System
Create
sessions
End
session
User
profile
Services

-------------Cut

Utilities

Copy
-------------Paste

Workflow
Links

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

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

Delete

Insert
line

List

Private
notes
Own
spool
requests
Own jobs

279114320.doc
Page

Help
Applica
tion
Help
SAP
Library
Glossar
y
-------------Release
notes
-------------SAPNet
-------------Feedbac
k
-------------Settings

Version: 3
04 March 2003
20

Exit

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

Short
message
Status
Log off

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
(non-mandatory) information.
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.2Tabstrips 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
Related tables can be incorporated in a lock object instead of having lock objects per
table.
Applying the Lock

279114320.doc
Page

Version: 3
04 March 2003
21

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
Numbering / Key
External
Internal
External / Internal
External / Internal

Process
Create
Create
Change / Delete
Select and delete in a multirecords / multi-purpose
transaction

Lock / Get No:

Start of Unit
End of Unit
Start of Unit
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.

279114320.doc
Page

Version: 3
04 March 2003
22

3.3.5.4

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.

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 organisation.
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.

279114320.doc
Page

Version: 3
04 March 2003
23

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.

279114320.doc
Page

Version: 3
04 March 2003
24

Back

Exit

Cancel

Effect

Exits object component

Exits task (application)

Exits
processing

Jump target

Returns to previous level

Screen calling the task

Screen
calling
task

Save
option(dialogu
e window)

Yes

Yes

No

Checks

Yes

Yes

No

Sequence of
save/check

Checks first, save option

later

Save option 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.

the

--- blank
line --Do you want
to cancel the
editing? (1st
line
is
diagnosis
text)

Pushbuttons
in dialogue
window
(default
answer
underlined)

Yes, No, Cancel

Yes, No, Cancel

Yes, No

Function
module

popup_to_confirm_step

popup_to_confirm_step

popup_to_co
nfirm_loss_
of_ data

Action menu

Goto

<object>

Edit

F-key

F3 (V3)

F15 (V15)

F12 (V12)

279114320.doc
Page

Version: 3
04 March 2003
25

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 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?

279114320.doc
Page

Version: 3
04 March 2003
26

TABLE LOCK
Transaction aborted. Unable to Lock the Database Tables
Object required is locked by another user

(used for Abort message)

(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

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)
279114320.doc
Page

Version: 3
04 March 2003
27

Start time is later than end time

From date is later than to date
From date is in past
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.

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 .

279114320.doc
Page

Version: 3
04 March 2003
28

3.4

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.

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

Output in ALV
Medium text
Report for field
Short text of of Data
Long text of
catalog field
Data Element Element
Data Element Heading colddictxt
Y
Long Text
Y
Y
Y
As set (L, M, S )
Y
Y
Y
Y
Set R - Heading
Y
Y
As set (L, M, S )

Print Preview
of ALV report
Long Text
Short
Heading
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.

279114320.doc
Page

Version: 3
04 March 2003
29

3.5

If Heading doesnt exist then default column heading will be Short text of the field
label .

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.

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 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

279114320.doc
Page

Version: 3
04 March 2003
30

NE 0.

Exit.
DEVK900088
DEVK900088
DEVK900088

ENDIF.

Or
Begin of DEVK900088
SELECT SINGLE * FROM LFA1
WHERE KUNNR EQ I_TAB-KUNNR.
SUBRC NE 0.

IF SYExit.
ENDIF.

End of DEVK900088

3.6

Creation of additional tabs in SAP Standard

Programs with Tab-strips
The steps for creating additional tabs in SAP Standard Programs with tab-strips are as
follows

3.7

Execute Transaction code VFBS

Create function codes

Specify the program name (SE38) and the subroutine name.

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.

Smart Forms
The SAP Smart Forms is used for creating and maintaining forms for mass printing.
They replace the SAPscript forms, however SAPscript 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.

279114320.doc
Page

Version: 3
04 March 2003
31

No hard coding should be done in include text and address window in Smart Forms.

279114320.doc
Page

Version: 3
04 March 2003
32

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 TYPE-GROUPS 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:

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
1-2

Description
Variable
Description

279114320.doc
Page

Values

Meaning

C_

For Constants

P_
S_

For Parameters
For Select-Options
Version: 3
04 March 2003

33

RB_
CB_
PB_
V_
T_
L_
X_
WA_
E_
CL_
CO_
GR_
CI_
R_
Fld_
Cnt_
Flg
3+

Freely Definable

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
For Grid
For Class Instance
For Range
For Field
For Counters
For Flags
use abbreviations for clear and
concise names.

4.3 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

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

4.4 Standard Header and Footer

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
279114320.doc
Page

Version: 3
04 March 2003
34

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

279114320.doc
Page

Version: 3
04 March 2003
35

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.

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 -

279114320.doc
Page

Version: 3
04 March 2003
36

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.

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

In ABAP programs you can access the fields directly with <Structure name>-<Field
name>

279114320.doc
Page

Version: 3
04 March 2003
37

5.3

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

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 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.

279114320.doc
Page

Version: 3
04 March 2003
38

Considerations:

5.7

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.

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.

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
Data Type

ABAP Data Type

Description

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, m, s P((n+2)/2) 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 preceding

279114320.doc
Page

Version: 3
04 March 2003
39

External
Data Type

ABAP Data Type

Description
INT2 field

NUMC n

N(n)

Character field with only digits

QUAN n, m,
s

P((n+2)/2) 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 change. SAP advises that when two floatingpoint 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

TYPE PDECIMALS 2

VALUE 0.00

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.

279114320.doc
Page

Version: 3
04 March 2003
40

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:

6.1.1

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.

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.
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:

279114320.doc
Page

Version: 3
04 March 2003
41

6.1.1.2

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.

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

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.

279114320.doc
Page

Version: 3
04 March 2003
42

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.

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
279114320.doc
Page

Version: 3
04 March 2003
43

More Efficient
*Key access with LOOP/CHECK
LOOP AT TAB.
CHECK TAB-K = KVAL.
" ...
ENDLOOP.

6.1.2.3

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.

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:

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.

279114320.doc
Page

Version: 3
04 March 2003
44

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 / 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.

8.

WHEN 4.
INSERT ITAB INDEX SY-TABIX.
APPEND I_TAB.

WHEN
..

ENDCASE

* For Internal Tables with less than 50 entries the COLLECT is acceptable.

6.1.3.2

After the COLLECT statement has been executed, the index of the modified or new
entry is written to the system field SY-TABIX.

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
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.

Modify
Use the MODIFY command to change a line within an Internal Table
Example:

279114320.doc
Page

Version: 3
04 March 2003
45

LOOP AT I_TAB.
C_INITIALIZE TO I_TAB-INITIALIZE.
ENDLOOP.

6.1.3.3

MOVE
MODIFY I_TAB.

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.
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

279114320.doc
Page

Version: 3
04 March 2003
46

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.
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 SY-TABIX.
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

279114320.doc
Page

Version: 3
04 March 2003
47

6.1.5.2

RANGES
The RANGES statement creates Internal Tables that have the structure of a SELECTOPTION table, but the RANGES do not 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 SELECTOPTIONS 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
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.

279114320.doc
Page

Version: 3
04 March 2003
48

6.1.5.3

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.

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.

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:

6.1.6

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.

FIELD GROUPS
SAP R/3 Requirements:

279114320.doc
Page

Version: 3
04 March 2003
49

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:

6.1.7

FIELD-GROUP are used to build internal tables that have a common key structure
but different arguments. They are 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.

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 LIST-PROCESSING. 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

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:

279114320.doc
Page

Version: 3
04 March 2003
50

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.
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

279114320.doc
Page

Version: 3
04 March 2003
51

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.
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

279114320.doc
Page

Version: 3
04 March 2003
52

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 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
ENDFORM.

to ...
" 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

279114320.doc
Page

Version: 3
04 March 2003
53

experience unexpected results. While ABAP will automatically convert 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,
WERKS LIKE MSEG-WERKS,
MATNR LIKE MSEG-MATNR,
END OF T_MAT.

DATA: I_MAT TYPE STANDARD TABLE OF T_MAT

WITH KEY NON-UNIQUE MATNR
INITIAL SIZE 0,
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,
WERKS LIKE MSEG-WERKS,
MATNR LIKE MSEG-MATNR,
END OF T_MAT.

DATA: I_MAT TYPE SORTED TABLE OF T_MAT

WITH UNIQUE KEY WERKS
INITIAL SIZE 10000,
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.
TYPES: BEGIN OF T_MAT,
WERKS LIKE MSEG-WERKS,
MATNR LIKE MSEG-MATNR,
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 NONUNIQUE. 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.

279114320.doc
Page

Version: 3
04 March 2003
54

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 nonnumeric 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.

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.
:
:
INITIALIZATION.
* prepare SM35 button
sscrfields-functxt_01 = 'View SM35'. "for key 1
:
:
at selection-screen.
if sscrfields-ucomm = 'FC01'.
D0100-MAPN = PA_GROUP.
279114320.doc
Page

Version: 3
04 March 2003
55

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

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 SELECTION-SCREEN 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.

279114320.doc
Page

Version: 3
04 March 2003
56

6.4

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:

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.

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

Microseconds

Internal PERFORM
External PERFORM
CALL FUNCTION
CALL DIALOG

6.4.1

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

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.

279114320.doc
Page

Version: 3
04 March 2003
57

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:

6.4.2

Dont use PERFORM<form name>(<program name>) unnecessarily. Overall

runtime will be increased because the 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.

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:

279114320.doc
Page

Version: 3
04 March 2003
58

A program that uses include incorporates it at generation time, so if the include is altered
all the programs that use it must be re-generated. 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.
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
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.
279114320.doc
Page

Version: 3
04 March 2003
59

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

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.

279114320.doc
Page

Version: 3
04 March 2003
60

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:

* 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.

279114320.doc
Page

Version: 3
04 March 2003
61

Example: For cluster table BSEG with keys MANDT, BUKRS, BELNR, GJAHR, and
BUZEI:
* 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.

6.5.1.3

SELECT Aggregates
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

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

279114320.doc
Page

Version: 3
04 March 2003
62

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 readonly. 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

SELECT * FROM T100
WHERE SPRSL = D
AND ARBGB = 00
AND MSGNR = 999.

6.5.1.5

*242 microsec

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
279114320.doc
Page

Version: 3
04 March 2003
63

Non-group update
LOOP AT I_OBJECTS.
SELECT * FROM TADIR
WHERE PGMID = I_OBJECTS-PGMID
AND OBJECT = I_OBJECTS-OBJECT
AND OJB_NAME = I_OBJECTS-OBJ_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_CLNT-FUNCTINT + 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
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
279114320.doc
Page

Version: 3
04 March 2003
64

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.1Inner Join
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, SFLIGHT-FLDATE, 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.2Left 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.

279114320.doc
Page

Version: 3
04 March 2003
65

SELECT F1~CARRID F1~CONNID F1~FLDATE F2~CUSTOMID INTO

(SFLIGHT-CARRID, SFLIGHT-CONNID, SFLIGHT-FLDATE, 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 right-hand 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.
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

279114320.doc
Page

Version: 3
04 March 2003
66

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.

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

279114320.doc
Page

Version: 3
04 March 2003
67

Some string manipulation functions have become obsolete in Release 3.0 and can be
replaced by an ABAP statement or functions:
STRING_CONCATENATE
SPLIT
STRING_CENTERED
STRING_MOVE_RIGHT

CONCATENATE
STRING_SPLIT
STRING_LENGTH
STRLEN()
WRITE TO CENTERED
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:

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

279114320.doc
Page

Version: 3
04 March 2003
68

 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

*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.

279114320.doc
Page

Version: 3
04 March 2003
69

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 FIELDSYMBOL does not occupy memory, but points to a position that has been ASSIGNed to
the FIELD-SYMBOL at runtime. After the FIELD-SYMBOL has 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
LENGTH
TYPE N.
FIELD-SYMBOLS <ENTRY>.

TYPE I,

DO.
READ DATASET P_FL_IN INTO INPT_RCRD.
SUBRC NE 0.
EXIT.
LENGTH =
INPT_RCRD+POSITION(3).

IF SYENDIF.
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 type
conflict, you can declare FIELD-SYMBOLS with a TYPE.

279114320.doc
Page

Version: 3
04 March 2003
70

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:

EMPLOYEE

NAME

COMPANY

STATE

001
002
003
004
005
006
007
008
009
010

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

ABC
ABC
XYZ
ABC
ABC
XYZ
ABC
ABC
ABC
ABC

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.

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

279114320.doc
Page

Version: 3
04 March 2003
71

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.

When records a and b have the exact same structure, it is more efficient to MOVE a
to b than to MOVE-CORRESPONDING a to b, if records a and b have the exact
same structure.

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.
279114320.doc
Page

Version: 3
04 March 2003
72

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.
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.

279114320.doc
Page

Version: 3
04 March 2003
73

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 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.

279114320.doc
Page

Version: 3
04 March 2003
74

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

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

279114320.doc
Page

Version: 3
04 March 2003
i

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 the data
Binary

Mode of opening the file

Binary mode

Binary

Text mode

ASCII

Binary mode

ASCII

Text mode

Result
# appears as a last
character in each record
# appears as a last
character in each record
# appears as a last
character in each record
Without #.

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.
Data Record no. 1
Data Record no. 2
Data Record no. 3

: Plant, Schedule Code, Schedule Description, Date

: P100,DLY100,Daily Schedule,01012001
: P100,DLY200,Monday, Tuesday,Schedule,01012001
: 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).

279114320.doc
Page

Version: 3
04 March 2003
ii

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 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.

279114320.doc
Page

Version: 3
04 March 2003
iii

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
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).

279114320.doc
Page

Disadvantages
SAP lack of support for customer function
modules
Migration of upgraded enhancements in
SAP standard function modules to customer
function modules.

Version: 3
04 March 2003
iv

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.
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
7
8-11

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

279114320.doc
Page

Version: 3
04 March 2003
v

12
13.16
17.24
25+

e.g. CON, REP, etc.) followed by a space

Dash -
Valid sequence number (Prefix 0 to the 3 digit number
obtained from Functional spec name)
Valid date in YYYYMMDD format
Valid R/3 user id, followed by space, followed by free form text.

Example:
NCC-FI-CON 000220030121ROUTRAB1 Chart of Accounts Conversion
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.

279114320.doc
Page

Version: 3
04 March 2003
vi

4/ SAP Standard Conversion Programs

Business Object

Program/Transaction Code

Financial Accounting

Accounting documents

RFBIBL00

Financial Accounting

Assets

Financial Accounting
Financial Accounting
Financial Accounting

G/L account master

Customer master
Vendor master

RAALTD01 (Batch Input) RAALTD11

(Direct Input)
RFBISA00
RFBIDE00
RFBIKR00

FI-Bank Data

Transfer of Bank Data (Austrian)

RFBVAT_0

FI-General Ledger
FI-General Ledger
FI-General Ledger

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)

RFBVCA_0
RFBVD_ _2
RFBVGB_0
RFBVIT_0
RFBVES_0
RFBVCH_0

Human Resources

Master data (Organizational Units)

RPUSTD00

Human Resources
Human Resources

Payroll account
Personnel planning data

RPULKT00
RHALTD00

Materials Management

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

RCCTBI01
RCCLBI01
RCCLBI02
RCCLRI03
RMDATIND
RM06IBI0
RM06BBI0
RM06EEI0 Purchase Order
RM06EEI1 Order Development
RSTXLITF Long Texts
RM07RRES
RM07MMBL
RFBIKR00
CG31

Materials Management
Materials Management
Materials Management
Materials Management
Materials Management
Materials Management

Materials Management
Materials Management
Materials Management

Materials Management

Reservations
Stocks (Inventory Management)
Vendor master
Phrases

279114320.doc
Page

Version: 3
04 March 2003
vi

Business Object

Program/Transaction Code

Sources
Substances

CG32
CG33

Plant Maintenance

Measuring point

RIIBIP00/IBIP

Plant
Plant
Plant
Plant
Plant
Plant
Plant
Plant
Plant
Plant
Plant

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

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

Production Master Data

Create bill of material

RCSBI010

Production Master Data

Production Master Data
Production Master Data
Production Master Data

Change bill of material

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

RCSBI020
RCSBI030
RCSBI040
RCPTRA01
RCVBI010

Production Planning

Demand management

RMMM60BI (Batch Input)

RM60IN00 (Direct Input)

SAP-EIS

Several records for SAP-EIS

RKCFILE0

Sales and Distribution

Condition records (pricing)

RV14BTCI

Sales and Distribution

Customer master
Open sales orders
Invoicing external transactions

RFBIDE00
RVINVB00
RVAFSS00

Storage bins
Stocks on Storage Bins

RLPLAT00
RLBEST00

(EH&S)

Maintenance
Maintenance
Maintenance
Maintenance
Maintenance
Maintenance
Maintenance
Maintenance
Maintenance
Maintenance
Maintenance

Sales and Distribution on

Warehouse Management

279114320.doc
Page

Version: 3
04 March 2003
vii

Business Object

Program/Transaction Code

279114320.doc
Page

Version: 3
04 March 2003
viii