ABAP Development Handbook

Page 1/30

ABAP Development handbook

Table of Contents
1 2 INTRODUCTION........................................................................................5 ABAP REPOSITORY NAMING CONVENTIONS...............................................6 2.1 ABAP REPORTS........................................................................................................ 6 2.2 REPORT PAINTER REPORTS.......................................................................................... 6 2.3 DIALOG PROGRAMS (MODULE POOL PROGRAMS)............................................................7 2.4 INCLUDES (WITHIN MODULE POOL PROGRAMS).................................................................7 2.5 TRANSACTION CODES................................................................................................. 8 2.6 SCREEN PAINTER SCREENS.......................................................................................... 8 2.7 FUNCTION GROUPS.................................................................................................... 8 2.8 FUNCTION MODULES.................................................................................................. 8 2.9 MESSAGE CLASSES.................................................................................................... 9 2.10 DEVELOPMENT CLASSES............................................................................................ 9 2.11 AREA MENUS.......................................................................................................... 9 2.12 BDC SESSION NAMES............................................................................................... 9 2.13 TRANSPARENT TABLES............................................................................................10 2.14 POOLED TABLES.................................................................................................... 10 2.15 CLUSTER TABLES................................................................................................... 10 2.16 STRUCTURES........................................................................................................ 11 2.17 VIEWS................................................................................................................. 11 Database view......................................................................................................... 11 Help view................................................................................................................ 11 Maintenance view................................................................................................... 11 Projection views...................................................................................................... 12 2.18 DOMAINS............................................................................................................. 12 2.19 DATA ELEMENTS.................................................................................................... 12 2.20 LOCK OBJECTS ..................................................................................................... 12 2.21 SEARCH HELPS...................................................................................................... 13 2.22 TYPE GROUPS....................................................................................................... 13 2.23 VARIANTS............................................................................................................ 13 2.24 LAYOUT SETS....................................................................................................... 13 2.25 REPORT PAINTER LIBRARIES.....................................................................................14 2.26 REPORT PAINTER SETS............................................................................................14 3 ABAP PROGRAMMING NAMING CONVENTIONS.........................................15 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4 DATA VARIABLES..................................................................................................... 15 GLOBAL VARIABLES.................................................................................................. 15 LOCAL VARIABLES.................................................................................................... 15 CONSTANTS........................................................................................................... 15 INTERNAL TABLES.................................................................................................... 15 PARAMETERS.......................................................................................................... 16 SELECT OPTIONS..................................................................................................... 16 FORMS.................................................................................................................. 16 TRANSPORTS.......................................................................................................... 16

ABAP PROGRAMMING STANDARDS..........................................................18 4.1 ABAP PROGRAMS.................................................................................................... 18 Program header...................................................................................................... 18 Report header......................................................................................................... 19 Report trailer........................................................................................................... 19 4.2 PROGRAM FLOW...................................................................................................... 19 4.3 INITIALIZATION EVENT............................................................................................... 20 4.4 START OF SELECTION EVENT......................................................................................20

151866248.doc

Page 2/30

Printed 14/6/13

ABAP Development handbook

4.5 4.6 4.7 5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 6 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 7 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10

END OF SELECTION EVENT......................................................................................... 20 TOP OF PAGE EVENT................................................................................................ 20 FORMS.................................................................................................................. 20 CASE STATEMENT................................................................................................... 22 CHECK STATEMENT................................................................................................ 22 COLLECT STATEMENT.............................................................................................22 IF STATEMENT........................................................................................................ 22 LOOP STATEMENT................................................................................................... 23 SELECT STATEMENT...............................................................................................23 SHIFT STATEMENT.................................................................................................. 23 MOVE STATEMENT ................................................................................................. 23 WHILE STATEMENT.................................................................................................24 DATA RETRIEVAL WITH GET STATEMENT......................................................................25 DATA RETRIEVAL WITH SELECT STATEMENT.................................................................25 PROGRAM SIZE....................................................................................................... 26 MESSAGES............................................................................................................. 26 PROGRAM CHECKS................................................................................................... 26 TABLE UPDATES AND MODIFICATIONS...........................................................................26 TEXT ELEMENTS...................................................................................................... 27 SYSTEM FIELDS....................................................................................................... 27 READING TABLES..................................................................................................... 27 BATCH SESSIONS................................................................................................... 27 DEVELOPMENT WORKBENCH....................................................................................27 LIST OF SAP MODULES............................................................................................. 28 LIST OF SAP SUBMODULES.......................................................................................28 LIST OF REPORT TYPES.............................................................................................28 FUNCTIONAL MESSAGE CLASSES.................................................................................28 DEVELOPMENT CLASSES............................................................................................28 FUNCTIONAL AREAS FOR REPORT PAINTER LIBRARY........................................................29 LIST OF REPORT PAINTER SETS..................................................................................29 LIST OF TEAMS........................................................................................................ 29 LIST OF SUB TEAMS.................................................................................................29 CHANGE REQUEST EXAMPLES..................................................................................29

ABAP STATEMENTS FOR PROCESSING.....................................................22

GENERAL GUIDELINES............................................................................25

APPENDIX.............................................................................................. 28

151866248.doc

Page 3/30

Printed 14/6/13

ABAP Development handbook

Intentionally Left Blank

151866248.doc

Page 4/30

Printed 14/6/13

ABAP Development handbook

1 Introduction
The purpose of this document is to establish the ABAP development standards and naming conventions for all SAP R/3 repository items likely to be affected in the project. It serves as a guideline for all the developers to strictly follow such that a unique standard of custom objects can be maintained throughout the project. These standards should be followed in order to achieve consistent and high quality programming code. To enforce the above all custom developments should undergo a final review at the completion of the task to ensure that these standards were applied and adhered to. The author of this document does not claim to have fully documented every single item and aspect, as some of the repository items are self-explanatory and therefore have no validity for further documentation. Missing objects that warrant documentation should be added to this document to make it an up-to-date and complete document. This might also be required in the case of a software upgrade containing enhancements, new features and functionality. This document was written on the basis of a SAP/R3 system release 4.70

151866248.doc

Page 5/30

Printed 14/6/13

ABAP Development handbook

2 ABAP repository naming conventions

SAP has a huge number of R/3 repository objects that are either delivered, can be configured or are intended for customer use. The customer repository objects are within a reserved range to allow for a trouble free upgrade of their software at later times. The resulting naming conventions outlined in this document have been defined to incorporate SAP recommendations and requirements. This will ensure distinction between SAP supplied repositories and customized repositories and will furthermore allow for a consistent approach for all custom development. SAP supplied objects must not be modified or deleted. If a change to a SAP supplied repository object is required the original object must be copied to a new object using the naming conventions outlined in this document. Only this new object can then be modified. Please consult the appendix E of BC Style Guide for objects inadvertently not covered by this document. In case of development done base on SAP standard object, then add prefix Z to customized object naming. For example, standard form for withholding tax certificate is IDWTCERT_TH_DOM. Naming for customized form is ZIDWTCERT_TH_DOM.

2.1 ABAP reports

ABAP reports are developed via the ABAP workbench. In general they are noninteractive and designed to complete a task without continual intervention by the user. The following is the naming convention for ABAP reports that will be promoted to the production environment. ABAP reports that are developed for testing or personal use must start with ZZZZ. The remaining part of the program name should be constructed in a way that does not interfere with the following naming conventions. Positio n 1 2-3 4-5 Sample Z FI GL Type Constant Z List List Description/Purpose This identifies the report as a custom development. Identification of SAP/R3 module the report is developed for. See appendix for a list of valid SAP/R3 modules. Identification of SAP/R3 submodule the report is developed for. See appendix for a list of valid SAP/R3 submodules. Type of report. See appendix for a list of valid report types. Sequential numbering for programs in the same application/module. Always use the next available number. Description of program if required starting with _

6 7-8 9-20

I 17 _Cash_Discou nt

List Range Descriptive character

2.2 Report Painter reports

Reports that are developed with the ABAP Report Painter tool will have the following naming conventions. Positio n Sample Type Description/Purpose
Page 6/30 Printed 14/6/13

151866248.doc

ABAP Development handbook

1 2-3 4-5 6 7-8

Z GS C0 _ 12

Constant Z List

Constant _ Range

This will identify the report as a custom development. Identification of SAP module the report is developed for. See appendix for a list of valid SAP modules. Identification of the report painter library. Always use the last two characters of the library name. Separator Sequential numbering for programs in the same module/report painter library. Always use the next available number.

2.3 DIALOG programs (module pool programs)

Dialog programs must always be developed via the Repository Browser. By using this development tool SAP will prompt the developer with correctly named Include components (described below). This will allow the developer to perform a syntax check and generate the underlining Includes with the correct naming conventions. This program must only contain Includes and program comments. Positio n 1-4 5 6-8 Sample SAPM Z 07E Type Constant SAPM Constant Z Range Description/Purpose This will identify the program as a Dialog program. This will identify the Dialog program as a custom development. Any three numbers/characters. Special characters like underscore are not allowed.

2.4 Includes (within module pool programs)

These types of Includes must always be developed via the Repository Browser after the generation of the program name. By using this development tool SAP will prompt the developer with correctly named Include components. This will allow the developer to perform a syntax check and generate the Includes with the correct naming conventions. Positio n 1-5 6-8 6 6 6 Sample MZ07E TOP O I F Constant Type Description/Purpose Always use position 4 to 8 of the associated Dialog program name. TOP Use TOP to identify the Include as the depository for the data declarations. O Include to store PBO (Process before Output) modules. I Includes to store PAI (Process after Input) modules. F Include to store subroutines called by perform statement in PBO and PAI. Used to number the Include within the
Page 7/30 Printed 14/6/13

7-8

05

Range

151866248.doc

ABAP Development handbook

same Include type. Always use the next available number.

2.5 Transaction codes

Transaction codes can be assigned to programs in order to execute them via the transaction code box or within user menus. The following naming conventions will apply. Positio n 1 9-20 Sample Z PRFORM Type Constant Z Descriptive Description/Purpose This will identify the transaction as a custom development. Description of functionality of Tcode

2.6 Screen painter screens

These objects are only ever associated with Module Pool programs except in the case of SAP generated parameter and list report screen, both of which are generated each time the List report is generated and are therefore not changeable. Subsequently the following naming conventions apply. Positio n 1-8 9-12 Sample SAPMF07E 9010 Type Constant Range Description/Purpose Module pool name the screen is developed in. This will identify the screen number. All custom developed screen should be in the 9000 number range. Always use the next available number. All screens pertaining to correctly named Module Pool programs will be protected from SAP upgrades.

2.7 Function groups

Function groups are used to group together functionally related common routines known as Function Modules. As such the following naming conventions will apply. Positio n 1 2-3 4 Sample Z FI A Type Constant Z List Description/Purpose This will identify the Function Group as a custom development. Identifies the SAP module. See appendix for a list of SAP modules. Any character allowed.

2.8 Function modules

Function Modules are grouped together in a Function Group. All function modules belonging to the same function group are stored in an ABAP program where the name of this program is made up out of the prefix SAPL and the function group name (e.g. SAPLZFSA). These programs must never be edited directly. Function modules will be named according to the following naming conventions. Positio n Sample Type Description/Purpose

151866248.doc

Page 8/30

Printed 14/6/13

ABAP Development handbook

1 2 3-30

Z _ SET_DATE

Constant Z Constant _

This will identify the function module as a custom development. Separator Any meaningful description about the functionality of the function module. Multiple underscore characters to separate words are allowed. A total length of thirty characters is permitted.

2.9 Message classes

This is another grouping object. Message classes are used to group message texts together. Up to one thousand messages can be stored in one message class. Internally, all messages are stored in SAP table T100. The following naming conventions apply. Positio n 1 2 Sample Z F Type Constant Z List Description/Purpose This will identify the message class as a custom development. Functional message class identification. See appendix for a list of valid functional message classes.

2.10 Development classes

A Development Class is used to categorize Development Objects. Only the System Administrator can create Development Classes. The naming conventions are as follows. Positio n 1 2-3 Sample Z BC1 Type Constant Z List Description/Purpose This identifies the development class as a custom development. SAP module. See appendix for a list of valid SAP modules.

2.11 Area menus

Area Menus are used to group transactions together for a user- friendly way of executing programs. The naming conventions follow. Positio n 1 2-4 Sample Z FIS Type Constant Z Description/Purpose This identifies the Area Menu as a custom development. Any three characters or numbers. Special characters are not permitted.

2.12 BDC session names

BDC sessions are used to mimic SAP/R3 transaction functionality without user intervention. To ensure SAP/R3 authority checks can be carried out, BDC session names will follow the following naming conventions. Positio n 1 Sample Z Type Constant Z Description/Purpose This identifies the BDC session as a
Page 9/30 Printed 14/6/13

151866248.doc

ABAP Development handbook

2 3-12

_ JRNLS

Constant _

customer generated BDC session. Separator Any abbreviated word describing the functionality of the BDC session. No special characters are permitted.

2.13 Transparent tables

Transparent Tables are used for physical data storage and are precisely mapped in the underlying database system. The SAP R/3 repository table information resides in the DB2 Common Server Database and could therefore potentially be accessed form outside the SAP R/3 system. The following naming conventions apply. Positio n 1-2 Sample ZZ Type Constant ZZ Description/Purpose This identifies the table as a custom development. SAP/R3 has used the prefix Z for some tables. To clearly identify custom developed tables the prefix ZZ is to be used. Use any abbreviated word describing the purpose of the table. If the table will not be maintained via the table maintenance functionality this part of the table name can have up to sixteen characters. For tables where table maintenance functionality will be used the table name must not exceed five characters in total. This is a SAP/R3 restriction.

3-18

VENDTL

2.14 Pooled tables

Pooled Tables is a very old concept within SAP/R3 but still in use. An example of this is the ATAB pool. Pooled Tables are multiple tables can co-exist in the same physical database. This type of table will not be used during the . They are only mentioned here for completeness.

2.15 Cluster tables

Cluster Tables are used to store records of varying length (clustered) together. Data is stored and retrieved via the Import/Export ABAP statements. It is not envisaged that this type of table will be used in the but the following naming conventions would apply. Positio n 1-2 Sample ZZ Type Constant ZZ Description/Purpose This identifies the table as a custom development. SAP/R3 has used the prefix Z for some tables. To clearly identify custom developed tables the prefix ZZ is to be used. Use any abbreviated word describing the purpose of the table. If the table will not be maintained via the table maintenance functionality this part of the table name can have up to sixteen characters. For tables where table maintenance
Page 10/30 Printed 14/6/13

3-8

FINPERIODS

151866248.doc

ABAP Development handbook

functionality will be used the table name must not exceed five characters in total. This is a SAP/R3 restriction.

2.16 Structures
Structures are typically created as a reference to external data storage. Structures represent working storage definitions or copybooks. The following naming conventions apply. Positio n 1-2 Sample ZZ Type Constant ZZ Description/Purpose This identifies the structure as a custom development. SAP/R3 has used the prefix Z for some structures. To clearly identify custom developed structures the prefix ZZ is to be used. Any abbreviated word describing the data addressed in this structure. Underscores are not permitted in the third and fourth position. This is a SAP restriction.

3-8

VENDORDT

2.17 Views
Four types of views are available to the developer. The naming conventions shown below will apply to all of them. A brief description of the purpose of each view type follows the naming conventions. Positio n 1 2-18 Sample Z VENDORVW Type Constant Z Description/Purpose This identifies the View as a custom development. Any abbreviated word describing the data defined in the view.

Database view
Database Views are typically used to join secondary tables to primary tables via a foreign key. This type of view disallows updates. Database views should be generated when accessing two or more related tables to reduce network traffic.

Help view
Help Views are used by SAP/R3 whenever a pull-down on a data dictionary field is done. In most cases this field will be a field generated by Screen Painter or by an ABAP Report. This only applies if no matchcode is defined for the field. Help views are useful as they allow linking to secondary tables via foreign keys.

Maintenance view
Maintenance Views are commonly generated for non-transactional data tables. Multiple tables can be used that are linked via foreign keys. Maintenance views allow the speedy generation of maintenance screens. Due to system restrictions in the locking area, the typical candidates for this type of view are One user at a time update tables. Tables containing fairly static data are also prime examples.
151866248.doc Page 11/30 Printed 14/6/13

ABAP Development handbook

Projection views
These types of views are only permissible on one table and selection restrictions are not permitted. They are used to filter data from views. Recommendation is to use Database Views instead.

2.18 Domains
Domains are used to describe data fields. Developers are encouraged to use a SAP equivalent Domain if it is available. Naming conventions for Domains are as follows. Positio n 1-2 Sample ZZ Type Constant ZZ Description/Purpose This identifies the domain as a custom generated domain. SAP has used the Z prefix for some domains. To clearly identify custom developed domains a prefix of ZZ is used. Any meaningful abbreviation describing the inherence of the domain.

3-8

INT_ID

2.19 Data elements

Data Elements are used to describe the business definition of a domain. The domain name (if newly created) should be used as the Data Element name. If the data element is to be used on an existing domain, a new data element could be used. Naming conventions are: Positio n 1-2 Sample ZZ Type Constant ZZ Description/Purpose This identifies the Data Element as a custom developed Domain. SAP has used the Z prefix for some Data Elements. Therefore the custom identification will be ZZ. Any meaningful abbreviation describing the data element.

3-8

NAME

2.20 Lock objects

Lock Objects are used to manage the SAP/R3 ENQUEUE and DEQUEUE locking process. The lock object is defined at the table level and upon generation, two function modules are generated. These function modules are then used by the developer to lock and unlock the objects. The argument list should be well thought out, as this will limit the locking level. The same applies for the Lock Mode. All custom development doing database updates must use the locking concept. No specific naming conventions apply as SAP does automatically name the objects. Positio n 1-7 8 9-17 Sample ENQUEUE _ ZZVENDORS Type Constant ENQUEUE Constant _ Description/Purpose This identifies the Lock Object as a locking object. The name is automatically generated by SAP. Separator Name of the table the locking process takes place. This is automatically added
Page 12/30 Printed 14/6/13

151866248.doc

ABAP Development handbook

to the Lock Object name by SAP.

2.21 Search helps

A search help is an object with which input filed helps can be defined. They are used to define the search paths. The following naming conventions will apply. Positio n 1 2 3-30 Sample Z _ BU_NAME Type Constant Z Constants _ Description/Purpose This identifies the search help as a custom development. Separator Any meaningful abbreviation describing the search help.

2.22 Type groups

These objects are global definitions of user defined data types that can be used in ABAP programs. This can give the effect of having field group definitions within other definitions. Effectively it is a powerful way to cut down coding and using complex data definitions in common programs. Positio n 1 2-5 Sample Z TBTY Type Constant Z Description/Purpose This identifies the Type Group as a custom developed Type Group. Any four characters are permitted.

2.23 Variants
Variants are used to store default ABAP report parameters. The naming conventions are as follows. Positio n 1-14 Sample GL_UPLOAD Type Description/Purpose Any meaningful abbreviation to describe the purpose of the variant. Multiple underscore characters are allowed.

2.24 Layout Sets

Layout Sets are used to store SAPScript forms. The following naming conventions apply. Positio n 1 2 2-4 5 6-13 Sample Z _ FI _ INVOICE Type Constant Z Constant _ List Constant _ Description/Purpose This identifies the layout set as a custom development. Separator This identifies the SAP module. See appendix for a valid list of SAP modules. Separator Any meaningful word or description to indicate what the layout set contains.

151866248.doc

Page 13/30

Printed 14/6/13

ABAP Development handbook

2.25 Report Painter libraries

Report Painter libraries are use within the Report Painter module. The following naming conventions apply. Positio n 1 2-3 Sample Z 12 Type Constant Z Description/Purpose Customer library identification. Any sequential number or character. Always use the next available number or character.

2.26 Report painter sets

Report Painter libraries are use within the Report Painter module. The following naming conventions apply. Positio n 1 2 3-4 5 6-10 11-12 Sample Z B CO _ RU_CC 01 Type Constant Z List Constant _ Description/Purpose Denotes customer Set. Set type. See appendix for a list of valid set types. SAP module. See appendix for a list of SAP modules. Separator Any meaningful description. Underscore characters are allowed. Any sequential number. Always use the next available number.

151866248.doc

Page 14/30

Printed 14/6/13

PROJECT

ABAP Development handbook

3 ABAP programming naming conventions

This section outlines the adopted programming naming conventions for the . Their usage will not be enforced but developers are encouraged to make use of them as they provide a good guideline to standardized programming code throughout the project. When naming variables, internal tables, parameters etc. the only special character allowed is the underscore character. This is one restriction that which will be enforced.

3.1 Data variables

Each data variable declaration should be placed onto a separate line. This will make the program easier to read and more maintenance friendly. Program Data Variables should start with the character V followed by an underscore _ character. If possible, the program variable should refer to an existing SAP data object with the help of the like declaration. Variable names should not exceed 30 characters. For variables referring to existing SAP/R3 data dictionary fields, the prefix 'V_' should be followed by the SAP/R3 data dictionary field name. Example DATA: V_PAGENO LIKE SY-PAGENO, V_LOOPNO(3) TYPE N.

3.2 Global variables

Global Variables will be prefixed with G_. A length restriction of no more than 30 characters applies as well. Example DATA: G_CNT(6) TYPE P NO DECIMALS.

3.3 Local variables

Local variables are defined as local to a subroutine. They will be prefixed with L_. Example DATA: L_SWITCH TYPE I.

3.4 Constants
Constants will be prefixed with C_. A length restriction of 30 characters applies. Constants must be declared with the CONSTANTS statement. Example CONSTANTS: C_ONE(1) TYPE C VALUE 1.

3.5 Internal tables

Internal tables must be prefix with T_. Their full name should not exceed thirty characters. If the internal table uses the same structure as an existing SAP/R3 table or structure the same name should be used. Example DATA: BEGIN OF T_MONTHLY_SUMS OCCURS 0. MONTHS(2) TYPE N, SUM(8) TYPE P DECIMALS 2, DATA: END OF T_MONTHLY_SUMS.
Page 15/30 Printed 14/6/13

151866248.doc

PROJECT

ABAP Development handbook

DATA: BEGIN OF T_T001. INCLUDE STRUCTURE T001. DATA: END OF T_001.

3.6 Parameters
Parameters are restricted to a length of eight characters. They are prefixed with P_ followed by the data dictionary field it resembles or represents. For parameters with no data dictionary field reference, the name can be freely chosen. Example PARAMETERS: P_BUKRS LIKE T001-BUKRS.

3.7 Select options

Select options are restricted to a length of eight characters. They are prefixed with S_ followed by the data dictionary field it resembles or represents. For Select Options with no data dictionary field reference the name can be freely chosen. Example SELECT-OPTIONS: S_LIFNR FOR LFA1-LIFNR.

3.8 Forms
Forms should be named in such a way that it provides a meaningful description of the functionality of the form. Words should be separated with the underscore character. A maximum length of thirty characters is permissible. Example FORM CALCULATE_WEEKLY_AVERAGE. ENDFORM. FORM FIND_FILES_TO_PROCESS. ENDFORM.

Example

3.9 Transports
Transports are the SAP/R3 way to promote developments to other systems. This will mainly be transports of objects from the development environment to the test and production environment. The short description of the underlying change request should be entered according to the following naming conventions. (See appendix for examples of change request descriptions). Positio n 1-2 3 Sample FI GL CCA Type List Constant - List List Description/Purpose This will identify the team. See appendix for a list of valid teams. Separator This will identify the sub team. No positions are provided as the length of
Page 16/30 Printed 14/6/13

151866248.doc

PROJECT

ABAP Development handbook

-60

: Interface Pgm. GL Upload

Constant :

this part of the transport description is variable. See appendix for a list of valid teams. Separator This will identify the contents of the transport. A meaningful short text must be provided.

151866248.doc

Page 17/30

Printed 14/6/13

PROJECT

ABAP Development handbook

4 ABAP programming standards

4.1 ABAP programs Program header
All Report, Dialog type programs and function modules must have a standard section at the top of the program file describing the program in brief and providing an area to function as a modification log for quick reference. A more detailed description of the program should be created in the documentation part of the program provided by SAP. The following is description of the required elements followed by a sample of a program header in an ABAP report program specifying all required elements. Element Program Title Author Date Release Module Description Authority Author Date Change Request Modifications Sample
*----------------------------------------------------------------------* Program : ZBC00000 * Title : Interface Initiator * Author : Tarm Techasarin * Date : January 23, 2004 * Release : 4.7 * Module : FI-GL * * Description : This program will search the specified directories * for the presence of interface data files. * For each file found it will then submit the * appropriate interface program to process the file. * * Authority : No explicit Authority Check is performed in this * program. *----------------------------------------------------------------------*----------------------------------------------------------------------* Modification History *----------------------------------------------------------------------* Author : * Date : * Change Request : 151866248.doc Page 18/30 Printed 14/6/13

Description Object name of program Title of program. This is the technical name of the program Name of developer (First and surname) Date of development commencement SAP/R3 system release the program was originally developed for Name of module and submodule the program was developed for Short but meaningful functional description of the program Provide details about explicit authority checks performed in this program First and surname of the developer who applied the modification Date when the modification was applied The SAP/R3 change request the modification was activated under Brief but meaningful description why the modification was required and how it was achieved.

PROJECT

ABAP Development handbook

* Modifications : *-----------------------------------------------------------------------

Report header
ABAP programs producing report output must have the defined standard header lines. Construction of these lines should be programmed in a function module for easy inclusion. The following is a list of elements and a sample of a header line report output produced by an ABAP program utilizing a function module call. Element Program Corporation Date System Client Report Description Time User Page Sample
PROGRAM: ZBC00000 SYSTEM : DP1/110 USER : THGXS Automobile (Thailand) Interface Initiator DATE: 23/01/2001 TIME: 17:36:25 PAGE: 1

Description Import parameter Value of text element Value of SAP/R3 system Value of SAP/R3 system Value of SAP/R3 system Value of SAP/R3 system Value of SAP/R3 system Value of SAP/R3 system Value of SAP/R3 system

field field field field field field field

SY-DATUM SY-SYSID SY-MANDT SY-TITLE SY-UZEIT SY-UNAME SY-PAGNO

Report trailer
ABAP programs producing report output must have the defined standard trailer line. Construction of this line should be programmed in a function module for easy inclusion. The following is a list of elements and a sample of a trailer line report output produced by an ABAP program utilizing a function module call. Element Text Description The first sample is for a report that outputted detail lines. The second sample is for a report that did not produce detailed output.

Sample
***** END OF REPORT ***** *** NO DATA TO REPORT ***

4.2 Program flow

The will adopt a modular (Top-Down) design methodology when developing ABAP programs. This methodology will breakdown the program in manageable and easy to maintain parts. This will mean to place logical parts of a program into forms. Subroutines should not be generated for code that is performed once only. The use of the SAP/R3 event methodology will help create structured programs as required.
151866248.doc Page 19/30 Printed 14/6/13

PROJECT

ABAP Development handbook

4.3 Initialization event

This SAP event is performed before any other event. It will be used to perform once-off program tasks. It should also be used for authorization and program status checks.

4.4 Start of selection event

The Start of Selection event represents the main flow coding part of the program. This event block should only contain performs to subroutines in a logical sequence.

4.5 End of selection event

Every program should end in the End of Selection event. Typically, this event should produce the report trailer line.

4.6 Top of page event

This SAP/R3 defined event is performed whenever the system encounters a page break during report output processing. Typically, this event should be programmed to execute the function module that generates the standard report header lines.

4.7 Forms
These subroutines must always use the LIKE statement to declare the forms parameter characteristics. This allows the SAP ABAP generate process to reserve precise dimensions in the generated object. The effect of not having the LIKE statement is that only at run time can ABAP evaluate the size of passed parameters. This has the effect of increasing the programs buffer size. Constant calls to a FORM with varying parameter sizes can mean constant extensions by the ABAP processor. This can simply be avoided by using the LIKE statement. Use the TYPE ASSIGNMENT facility in SE38 (Utilities Menu). There will be cases where the FORMAL parameter size declared on the FORM routine with the LIKE statement doesnt match the ACTUAL parameter size due to the fact that more than one parameter type is passed to the same formal parameter field. A program check will determine this. In this case it is permissible to use the TYPE statement. Forms should be headed by a brief description of the functionality embedded in the form. The input and output parameters should also be described. It is important to distinguish between the input and output parameters in the documentation, as there is no inherent distinction made by SAP ABAP. Any parameters whose values do not change are considered input and any parameters whose value gets set, reset, or changed should be documented as output. The use of directional arrows is a good way to indicate which parameters are input or output. Another way of distinguishing between input and output parameters is to declare those variables, which are changed by the subroutine with the extension CHANGING. In actuality this extension does not affect the data in any way (in this particular case), but it used strictly as a distinguishing feature. Also when declaring your FORM you should always put all input parameters first and then all output parameters. Sample
----------------------------------------------------------------------------* This routine simply concatenates 2 strings separated by a space and places * them in an output string. ----------------------------------------------------------------------------* Parameters: * --> STR1 - string 1 * STR2 - string 2 * <-- O_STRING - output string
151866248.doc Page 20/30 Printed 14/6/13

PROJECT

ABAP Development handbook

*---------------------------------------------------------------------------FORM CONCAT_STRINGS USING STR1 LIKE G_CHAR10 STR2 LIKE G_CHAR10 CHANGING O_STRING LIKE G_CHAR10. DATA: L_LEN1 TYPE I. L_LEN1 = STRLEN( STR1 ). L_LEN1 = L_LEN1 + 1. O_STRING = STR1. WRITE STR2 TO O_STRING+f_LEN1. ENDFORM.

151866248.doc

Page 21/30

Printed 14/6/13

PROJECT

ABAP Development handbook

5 ABAP statements for processing

This section offers a wide range of programming statements used in the ABAP language of SAP/R3. The information found in this section will be in the form of standards, guidelines, descriptions, examples and programming tips. They are in alphabetical order for quick reference.

5.1 CASE statement

Each nested CASE...WHEN...ENDCASE statement will be consistently aligned and indented. The pretty printer feature of SAP/R3 will do indenting automatically when executed. For program runtime efficiency purposes, the most likely event should be coded first. Example CASE LFB1-EIKTO. WHEN C_ACCOUNT_1. PERFORM . MOVE WHEN C_ACCOUNT_2. CONCATENATE . WHEN C_ACCOUNT_3. READ .. ENDCASE.

5.2 CHECK statement

This statement should be used whenever possible in preference of the IF statement. The IFELSEIFELSEENDIF statement can get very deeply nested making it hard to read and modify. Check statement can be of useful for exiting forms. Example LOOP AT T_ACCOUNTS. .. CHECK T_ACCOUNTS-TYPE = C_BS_TYPE.. .. ENDLOOP.

5.3 COLLECT statement

Even thus time consuming the COLLECT statement can be used efficiently as long as that is the type of operation that is really required. In most cases this will be the summing up of totals. The COLLECT statement should not be used in conjunction with other table manipulating statements like APPEND, MODIFY etc. If the number of records is low (< 1000) the read/insert approach should be used.

5.4 IF statement
When coding nested IF statements, no more than three levels should be constructed. This will restrict lengthy control events congesting a program and making it difficult to read. Each level must be consistently aligned and indented. Deeply nested IF statements are not recommended and should be replaced with CASE statements. When coding IF tests, nest the testing conditions so that the outer conditions are those which are most frequently true. For logical expressions with AND, place the most likely false first and for the OR, place the mostly likely true first. Avoid the use of double nive checks, as this can be difficult to understand and maintain.
151866248.doc Page 22/30 Printed 14/6/13

PROJECT

ABAP Development handbook

Example

IF BKPF-BELNR = V_INVNO. PERFORM INVOICE_PROCESS. ELSE. CHECK_DOC_NUMBER. ENDIF.

5.5 LOOP statement

Loop statements should be restricted whenever possibly. A good technique is to position the loop on the first record and then loop and exit the loop. Another possibility is to sort the table beforehand and terminated the loop with an CHECK statement. Example SORT T_ACCOUNTS BY TYPE. LOOP AT T_ACCOUNTS. CHECK T_ACCOUNTS-TYPE = C_BS_ACCOUNT. PERFORM ENDLOOP. Example READ T_ACCOUNTS WHERE TYPE = C_BS_ACCOUNT. G_TABIX = SY-TABIX. LOOP AT T_ACCOUNTS FROM G-TABIX . CHECK T_ACCOUNTS-TYPE = C_BS_ACCOUNT. PERFORM ... ENDIF.

5.6 SELECT statement

Only fields needed for processing should be retrieved during a select. The fields should be selected in the same sequence as they appear in the accessed table. Key fields must be defined in the same sequence as they appear in the table. Always try to nominate as many key fields as possible. If all parts of the table key is known use SELECT SINGLE instead of a SELECTENDSELECT. Small tables that are frequently accessed should be loaded into internal tables at program beginning. NEVER use the client-specified extension for the select statement. This statement will allow accessing data from a client other that the one you are currently logged into. This is never necessary and use of it will not be tolerated.

5.7 SHIFT statement

Try to avoid using the ABAP SHIFT statement if you are shifting many times (or many characters). Many shifts can quickly become very inefficient and dramatically slow down your program. Use other means such as the MOVE statement with variable offsets. Obviously avoid the use of SHIFT in a WHILE LOOP if the WHILE condition is checking the contents of the SHIFT field. That would be a good way to create a runaway program.

5.8 MOVE statement

When records involved in a move have the exact same structure, it is more efficient to use MOVETO than to use the MOVE-CORRESPONDING statement.

151866248.doc

Page 23/30

Printed 14/6/13

PROJECT

ABAP Development handbook

5.9 WHILE statement

WHILE loop processing makes more sense as the condition is stated on the WHILE condition. It is also quicker to execute. Example WHILE RECORD_FOUND = TRUE. READ DATASET P_FILE INTO V_RECORD IF NOT SY-SUBRC IS INITIAL. RECORD_FOUND = FALSE. ENDIF. ENDWHILE.

151866248.doc

Page 24/30

Printed 14/6/13

PROJECT

ABAP Development handbook

6 General guidelines
The following sections are intended to provide general guidelines for ABAP developers in the . The subjects discussed will be familiar to all developers but are reiterated here because of their importance.

6.1 Data retrieval with GET statement

There are two basic techniques in ABAP/R3 to retrieve data from the database. These are the use of the GET statement with logical databases and the use of the SELECT statement with SAP SQL. Both methods offer some advantages and disadvantages as outlined below which should be considered before deciding which data retrieval method will be selected. Advantages Automatically retrieves related records from all the superior tables in the logical database defined within the program with the TABLES statement. Retrieves records in the logical order of the primary key. Usually can provide a complete hierarchy of related tables in an application area. For example the logical database MSM provides a complete hierarchy for the material master. This can sometimes make programming easier. Validates user inputs (Selection screen) for completeness, correctness, and logic. Automatically creates data selection screen for all primary key fields of declared tables in the logical database. Performs authorization checks for database access. Is ideal for reporting purposes where related data needs to be retrieved. Involves less coding than SELECT. Disadvantages If selection criteria other than primary keys needs to be specified the use of logical databases becomes less efficient than the use of SELECT statements. Logical databases are almost always restricted to one module (application area) within the system. Since only one logical database can be specified per program, GET cannot be used against a table external to this logical database. WHERE conditions can be specified only by using the selection screen at run time. Once entered by the user they cannot be changed during the execution of the program. Statement ORDER BY is not allowed. The automatic retrieval of related records from all superior tables might cause excessive database I/0 if GET is used at a very deep level in the structure. Data must be accessed in the order defined by the logical database.

6.2 Data retrieval with SELECT statement

The developer should have a complete understanding in the use of the SELECT statement. Information about the proper usage can be obtained via the ABAP HELP ON facility. The biggest processing overhead on any computer system is usually read and write access to the database. Efficient and proper coding of the SELECT statement can greatly improve program performance.

151866248.doc

Page 25/30

Printed 14/6/13

PROJECT

ABAP Development handbook

The developer should endeavor to retrieve the data in one operation. This can be achieved with the INTO TABLE addition to the SELECT statement. This form of coding will reduce the network traffic between the SAP/R3 work process and the database thread assigned to the work process. Using the SELECT statement in this form can bring other potential processing time savings as well in the areas of reduced input/output due to the fact the database buffers could store all results after the input/output operation without having it flushed due to other thread requests by competing programs. The usage of views instead of nested SELECT statements will also improve program performance for the same reasons as stated above.

6.3 Program size

All data retrieved into a program needs to be stored by SAP/R3 into the work process roll area. A busy application server can have lots of context switching if the SAP/R3 dispatcher has lots of requests. Therefore it is essential to reduce program runtime size. Use of explicit fields required on a SELECT statement helps achieve this. Not declaring internal tables too big can also achieve this. The best practice of OCCURS size specification is to leave it at 0 if the optimal size cannot be established. This is particularly true if the table is filled in one operation by use of the INTO TABLE addition on the SELECT statement. If the OCCURS size is known then it should be specified as the program size for that table will be reserved at generation time. This will reduce program extensions. Extensions will occur if the program stores additional rows. Once the program no longer requires the internal table the space taken up by the table should explicitly be handed back to the processor. This can be achieved through the use of the FREE statement.

6.4 Messages
The will try to use existing SAP/R3 messages whenever possible. This way the messages are not duplicated within the system and the user will not get different messages depending on in which part of the system he or she operates in.

6.5 Program checks

After completion the developed program should be checked via the extended program check functionality provided by the SAP/R3 ABAP Workbench. Runtime analysis should be undertaken with the Runtime Analysis tool.

6.6 Table updates and modifications

No direct updating of SAP/R3 tables via ABAP reports, dialog programs or in any other fashion is allowed. The only way to update tables will be with the use of the Call Transaction technique. Direct updates of SAP/R3 tables by the customer will void SAP warranty for the system. One exception is when SAP provided patches would have direct table updates. Customer defined tables can be updated but this must be done by putting the code that updates the table in a function module and then calling it with the extension IN UPDATE TASK. This enables complete logging of the updates and will allow to rollback or rollforward these changes if necessary. This will also allow the system administrators to monitor any updates and thus will be better able to troubleshoot problems. The other major reason is that it will reduce the Dialog time, so end-users will not have to wait as long. A message indicating that the update will take place must be relayed to the enduser.

151866248.doc

Page 26/30

Printed 14/6/13

PROJECT

ABAP Development handbook

6.7 Text elements

It is essential to store text that is written to a screen into text elements. No ABAP program should have any so called hard coding of texts. This makes it easier for future changes to these texts, as they are all contained in one place. This is also a SAP/R3 prerequisite if these texts have to be translated into other languages.

6.8 System fields

Language and currency codes must not be hard coded. The current system language should be determined from SY-LANGU and the currency code should be passed as a parameter.

6.9 Reading tables

Avoid reading large tables via non-key fields. If an alternative table cannot be found, then the creation of additional indices on transparent tables can overcome the problem of non-key table access.

6.10 Batch sessions

When writing out dates in batch input session they must be written out in the eventual users default format. This will ensure the batch session will not fail due to the fact that the batch session contains a different date format to the users date format. This can be accomplished by moving the date variable to a character variable using the WRITE statement with the DD/MM/YYYY extension.

6.11 Development Workbench

Developers are encouraged to use the development workbench for development work. It is a very good organisational tool that will greatly assist in developing programs.

151866248.doc

Page 27/30

Printed 14/6/13

PROJECT

ABAP Development handbook

7 Appendix
7.1 List of SAP modules
Module FI CO MM BC Description Financials Controlling Material Management BASIS

7.2 List of SAP Submodules

Module GL AR AP SL PA CC IO IM PUR ZZ Description General Ledger Accounts Receivable Accounts Payable Special Ledger Profitability Analysis Cost Center Accounting Internal Order Inventory Management Purchasing Unspecified

7.3 List of report types

Report Type C I R E F X Description Conversion Interface Report Enhancement Form (Layout) Include for report type programs

7.4 Functional message classes

Message Class F K M S Description Financial Accounting Controlling Material Management Basis

7.5 Development classes

Message Class ZBC ZCO
151866248.doc

Description Basis Controlling

Page 28/30 Printed 14/6/13

PROJECT

ABAP Development handbook

ZFI ZMM

Financials Material

7.6 Functional areas for Report Painter library

Message Class A F K O S Description Asset Management Financial Accounting Controlling Special Ledger Basis

7.7 List of Report Painter sets

Set B S M D S Description Basic Single Multiple Dataset Basis

7.8 List of teams

Team FI CO MM BC Description Financial Team Financial Controlling Team Material Management Team Basis Team

7.9 List of sub teams

Sub Team GL AP AR SL CCA PA OPA PUR IM ABAP SEC Description General Ledger Accounts Payable Accounts Receivable Special Ledger Cost Center Accounting Profitability Analysis Internal Orders Purchasing Inventory Management ABAP Developments Security

7.10 Change Request Examples

OSS:160380:FI:Message RW022 Balance in transaction currency FI-AP:Customizing the Accounts Payable Module BC-CUS:Create Logical System for DP1 100/110 CO-CCA:Activate integrate in Planning Version
151866248.doc Page 29/30 Printed 14/6/13

PROJECT

ABAP Development handbook

FI-GL:ABAP Account Master Listing FI-AP:SAPscript Accounts Payable Invoice

151866248.doc

Page 30/30

Printed 14/6/13