ABAP Standards PDF

SAP ABAP
Development
Standards
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
/opt/scribd/conversion/tmp/scratch6126/59492316.doc
Page:
1 of
65
Document Identification
Summary Information
Title
Version
Date
Author
ABAP Development Standards

4.0
3/15/1999
Kevin Wolfe
How to Find the Latest Version of This Document

This document is located in
\\Koro\Q-SAP\BIECS SAP Development Team\Standards and Templates\A8 Standards - ABAP Standards.doc
Summary of Changes
Version
Version
Number
Date
1.0
3/15/1999
6/3/1999
6/4/1999
7/13/1999
7/20/1999
9/13/1999
9/15/1999
9/23/1999
11/01/1999
11/02/1999
12/14/1999
1/26/2000
5/6/2002
5/7/2002
6/10/2003
12/08/03
Last changed on:

2/3/2006 11:58:00 AM
Revision Comments
Added by
Initial Creation
Kevin Wolfe
Added Application Module LO- Logistics General. Added Application

Submodules: MD under Logistics Data and BD under Production Planning.
Added External Files; directories and file names. Also added useful function
modules.
Removed Approved by from summary of changes. Added HR submodule under
program name. Chged R/L margins from 1.25 to 1.
Added PM module and HR submodule to the program name section.
Add SU (subscription) submodule under SD for program naming
Add CA (Cross Applications) module for program naming
Add PC (Product Cost) submodule under CO module
Update Search Help and Lock Objects
Reduced table name to 10 characters since that is all that a change object can handle.
Changed DDIC to refer all work to the Basis team
Update variants to include transport procedure
Changed Prototype in Program Use category to Processing
Changed warning about external forms use because SAP can detect its use from
parent program
1. Program Name naming convention should include descriptive text after the
numeric for unique identifier. This greatly simplifies finding related programs
without having to go to the extra step of analyzing program descriptions which are
often not changed from the default on creation of programs.
2. Addition of PR to the application submodule under SD for pricing.
3. "Pretty Printer" should be used. The issues with it in the past seem to save been
cleared up. Not only do we have a problem with developers using different methods
of indentation than other developers, many use different methods between different
programs, within the same program and even within the same subroutines.
4. Naming convention for structures should be gs_ or ls_ to differentiate structures
from individual variable fields.
5. Removal of all references to Select...Endselect except to say that it should not be
used.
6. Field Names in Z tables should have no prefix (currently defined as ZZ). Field
names added to standard SAP table should continue to retain the ZZ prefix.
7. Function Module naming convention should be Z_MMSS_XXXXX... .
Josh Duerkop
Added standards for business object methods and attributes
Aaron Pust
Last changed by:

u0092453
File name:
Kevin Wolfe
Kevin Wolfe
Kevin Wolfe
Kevin Wolfe
Kevin Wolfe
Kevin Wolfe
Kevin Wolfe
Kevin Wolfe
Kevin Wolfe
Kevin Wolfe
Kevin Wolfe
Kevin Wolfe
Ryan Kane
Page:
2 of
65
Table of Contents
OVERVIEW....................................................................................................................................................1
PURPOSE..........................................................................................................................................................1
OBJECTIVES......................................................................................................................................................1
CONTENT.........................................................................................................................................................1
SUPPLEMENTAL DEVELOPMENT MATERIALS..........................................................................................................1
TERMINOLOGY..................................................................................................................................................2
Adherence.................................................................................................................................................2
Glossary...................................................................................................................................................2
APPLICATION....................................................................................................................................................2
PROGRAM ELEMENTS..............................................................................................................................2
PROGRAM NAME...............................................................................................................................................2
ATTRIBUTES.....................................................................................................................................................4
Title...........................................................................................................................................................5
Type..........................................................................................................................................................5
Status........................................................................................................................................................5
Application...............................................................................................................................................5
Authorization group.................................................................................................................................5
Development class....................................................................................................................................5
Fixed point arithmetic..............................................................................................................................6
SOURCE CODE..................................................................................................................................................6
Coding Guidelines....................................................................................................................................6
Readability............................................................................................................................................6
Functionality.........................................................................................................................................9
Performance..........................................................................................................................................9
Declarative Elements.............................................................................................................................10
REPORT/PROGRAM........................................................................................................................10
TABLES.............................................................................................................................................11
TYPES................................................................................................................................................12
SELECT-OPTIONS...........................................................................................................................12
PARAMETERS..................................................................................................................................13
DATA.................................................................................................................................................14
CONSTANTS.....................................................................................................................................17
RANGES............................................................................................................................................18
FIELD-GROUPS................................................................................................................................19
FIELD-SYMBOLS.............................................................................................................................20
Event Elements.......................................................................................................................................21
AT SELECTION-SCREEN................................................................................................................21
START-OF-SELECTION..................................................................................................................21
END-OF-SELECTION.......................................................................................................................22
AT USER-COMMAND.....................................................................................................................22
AT PFn................................................................................................................................................22
TOP-OF-PAGE...................................................................................................................................22
Control Elements....................................................................................................................................22
IF.........................................................................................................................................................22
CASE..................................................................................................................................................23
DO.......................................................................................................................................................24
WHILE...............................................................................................................................................24
LOOP..................................................................................................................................................24
FORM (SUBROUTINES)..................................................................................................................25
CALL (FUNCTION MODULES)......................................................................................................26
Operational Elements.............................................................................................................................27
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
3 of
65
CHECK...............................................................................................................................................27
CLEAR...............................................................................................................................................28
COMMIT WORK...............................................................................................................................28
CONCATENATE...............................................................................................................................29
DELETE.............................................................................................................................................29
EXPORT TO MEMORY / IMPORTFROM MEMORY...........................................................29
FORMAT............................................................................................................................................30
MODIFY.............................................................................................................................................30
MOVE/MOVE-CORRESPONDING.................................................................................................30
READ TABLE (itab)..........................................................................................................................30
SELECT..............................................................................................................................................31
WRITE................................................................................................................................................31
Other Source Code Elements.................................................................................................................32
COMMENTS......................................................................................................................................32
TEXT ELEMENTS.............................................................................................................................................32
Titles and headers..................................................................................................................................32
Selection texts.........................................................................................................................................32
Text symbols..........................................................................................................................................33
MESSAGES.....................................................................................................................................................34
Long text.................................................................................................................................................35
VARIANTS......................................................................................................................................................35
PROGRAM DOCUMENTATION.............................................................................................................................35
REPORT/PROGRAM OUTPUT................................................................................................................36
SELECTION SCREENS........................................................................................................................................36
Field Descriptions..................................................................................................................................36
Possible Values......................................................................................................................................36
Field Help...............................................................................................................................................37
LISTS............................................................................................................................................................37
Header....................................................................................................................................................37
End of Report Line.............................................................................................................................37
Logos......................................................................................................................................................37
Field Formats.........................................................................................................................................37
Retail price..........................................................................................................................................38
UPC.....................................................................................................................................................38
Audit Reports..........................................................................................................................................38
FONTS...........................................................................................................................................................39
DATA DICTIONARY ELEMENTS...........................................................................................................39
TABLES..........................................................................................................................................................39
Table Elements Maintenance Approval Procedure...............................................................................39
Table Technical Settings Maintenance Approval Procedure.................................................................40
STRUCTURES...................................................................................................................................................40
IDOC segments......................................................................................................................................40
VIEWS...........................................................................................................................................................41
Database.................................................................................................................................................42
Projection...............................................................................................................................................42
Help........................................................................................................................................................42
FIELD NAMES..................................................................................................................................................42
DATA ELEMENTS.............................................................................................................................................42
Documentation.......................................................................................................................................42
DOMAINS.......................................................................................................................................................42
TABLE INDEXES..............................................................................................................................................43
Table Index Maintenance Approval Procedure.....................................................................................43
LOCK OBJECTS................................................................................................................................................43
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
4 of
65
Lock Objects :.....................................................................................................................................43

SEARCH HELP.................................................................................................................................................44
Search Help Objects : ........................................................................................................................44
TYPE GROUPS.................................................................................................................................................44
FUNCTION GROUP ELEMENTS............................................................................................................44
FUNCTION GROUPS...........................................................................................................................................44
FUNCTION MODULES........................................................................................................................................45
DOCUMENTATION............................................................................................................................................45
MISCELLANEOUS DEVELOPMENT ELEMENTS..............................................................................45
TRANSACTIONS...............................................................................................................................................46
LOGICAL DATABASES.......................................................................................................................................46
Logical Database...................................................................................................................................46
SET/GET PARAMETERS (PARAMETER IDS)......................................................................................................47
AREA MENUS..................................................................................................................................................47
PF keys...................................................................................................................................................47
MESSAGE CLASSES..........................................................................................................................................47
JOBS..............................................................................................................................................................48
Job names...............................................................................................................................................48
Event IDs...............................................................................................................................................48
PBO MODULES...............................................................................................................................................48
PAI MODULES................................................................................................................................................48
DIALOG MODULES...........................................................................................................................................48
SCREENS........................................................................................................................................................49
MODULE POOLS..............................................................................................................................................49
INCLUDE PROGRAMS.........................................................................................................................................49
SCREEN PAINTER.....................................................................................................................................49
BUSINESS OJBECTS..................................................................................................................................51
Methods..................................................................................................................................................52
Events.....................................................................................................................................................52
Attributes................................................................................................................................................52
BDC SESSIONS / CALL TRANSACTIONS.............................................................................................52
BDC Sessions.........................................................................................................................................52
Call Transaction.....................................................................................................................................52
SECURITY....................................................................................................................................................52
SECURING A PROGRAM.....................................................................................................................................53
SECURING A TRANSACTION................................................................................................................................53
EXTERNAL FILES......................................................................................................................................53
DIRECTORIES..................................................................................................................................................54
FILENAMES.....................................................................................................................................................54
IDOCS....................................................................................................................................................55
IDOC Type.........................................................................................................................................55
FTP.............................................................................................................................................................56
APPENDIX ...................................................................................................................................................56
USEFUL FUNCTION MODULES...........................................................................................................................56
USEFUL ABAP PROGRAMS.............................................................................................................................57
END OF DOCUMENT.................................................................................................................................59
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
5 of
65
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
6 of
65
OVERVIEW
Purpose
The ABAP (Advanced Business Application Programming) Development Standards document has been
created to describe the standards and guidelines to be followed by application programmers when
developing applications in SAPs ABAP programming language. The standards described in this document
are based on the ABAP Workbench and programming language for SAP version 4.0.
The intended purpose of this document is to describe West Groups development standards for the most
common ABAP development elements and topics. It is not intended to describe the functionality or explain
how to use the ABAP language. For ABAP language support, you should refer to the SAP ABAP language
manuals and on-line help, especially the ABAP Users Guide (from initial SAP screen: Help > Application
help > BC Basis Components > BC ABAP Users Guide).
This document will describe the standards defined per ABAP development element, followed by standards
for other miscellaneous development topics. Standards for a given development element or topic will
include any applicable coding standards and/or naming conventions.
Objectives
The objectives of the development standards contained in this document are to help you, the developer:
Establish naming conventions, which will assist in identifying SAP objects.

Develop commonly structured programs.
Develop programs that are easily read and understood.
Develop software that can be easily maintained.
Develop software that is consistent with SAP ABAP software development guidelines.
Produce application output that is consistent with SAP application output guidelines.
Content
This document lists standard development procedures for the most commonly used ABAP development
elements, and will undergo continual improvement to evolve the documentation. If you need to create a
development element for which no standard is listed, you should contact your Team Lead so they can
determine if a new standard should be created. During the time that no standard exists, you should refer to
the SAP Style Guide (from initial SAP screen: Help > Application help > BC-Basis Components > BCSAP Style Guide) to the standards for closely related elements listed in this document as guidelines for
development of this element.
Supplemental Development Materials

Supplemental development materials such as Development Request templates and documentation,
information on prototyping, and approvals and walkthru templates can be found in (Carolyns master
directory document?? )
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
1 of
65
Terminology
Adherence
The following terms will be used throughout this document to define the degree to which your adherence to
a listed standard is required:
Shall/Will/Must
Should/May
Assume
Recommend
A Standard. You must adhere to the standard in every case. No exceptions.

A Guideline. You should adhere to the standard whenever possible.
Your adherence to the standard is inferred or implicit.
Your adherence to the standard is preferred.
Glossary
Descriptions for ABAP-related terms found throughout this document can be found within the SAP
Glossary, which can be accessed via the ABAP Workbench (Help > Glossary).
Application
You shall apply the standards described in this document to all custom-developed applications written in
the ABAP programming language.
As a rule, whenever you are in the process of updating a custom application, you should also check the
application to ensure that it conforms to the standards set forth in this document. If it does not conform,
you should also update the application to bring it up to standard, but only if these updates can be made
relatively easily and in a timely fashion.
PROGRAM ELEMENTS
This section defines the development standards for the following ABAP Program Elements:
Program Name
Attributes
Source Code
Text Elements
Messages
Variants
Program Documentation
Program Name
The program name shall be determined based upon the naming convention below. The program name must
be approved by the Team Lead before you create the program object.
Naming convention:
tmmssuf999n
where:
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
2 of
65
t.................Type.
Y = Data conversions which are one-time loads, and example programs used for
demonstration.
Z = Applications and permanent interfaces.
mm...............Application Module.
AM = Asset Management.
BC = Basis.
BW = Business Information Warehouse.
CA = Cross Applications.
CO = Controlling.
FI = Financial.
LO = Logistics General.
MM = Material Management.
PA = Personnel Management.
PM = Plant Maintenance.
PP = Production Planning.
PS = Project System.
SD = Sales and Distribution.
TP = Temporary (local object).
XX = Not specific to any one application module.
ss...............Application Submodule.
XX = Not specific to any one submodule.
Asset Management Submodules.
IC = Investment Control (sale of assets).
IM = Investment Management.
TA = Technical Asset Accounting (replacement, depreciation).
TM = Technical Asset Management & Plant Maintenance.
Basis Submodules.
CT = Change Transport System.
SC = Security.
SM = System Monitoring.
Business Information Warehouse Submodules.
None defined at this time.
Controlling Submodules.
AC = Activity Based Costing.
CC = Cost Center Accounting.
EC = Enterprise Controlling.
IM = Investment Management.
OM = Internal Orders.
PA = Profitability Analysis.
PC = Product Cost
Financial Submodules.
AA = Asset Accounting.
AP = Accounts Payable.
AR = Accounts Receivable.
GL = General Ledger.
HR = Human Resources.
SP = Special Ledger.
Logistics General Submodules.
MD = Basic Data.
Material Management Submodules.
PO = Procurement.
WM = Warehouse Management.
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
3 of
65
Personnel Management Submodules.

HR = Human Resources.
Plant Maintenance Submodules.
SM = Service Management.
Production Planning Submodules.
BD = Basic Data.
PC = Product Costing.
PE = Production Execution.
PS = Production Scheduling.
Project System Submodules.
QC = Quality Control.
PM = Project Management Information System.
Sales and Distribution Submodules.
BI = Billing.
CU = Customer.
DP = Delivery Processing.
OP = Order Processing.
PR = Pricing
SI = Sales Information System.
SP = Sales Pricing.
SU = Subscriptions.
u.................Program Use.
B = Bolt-on.
C = Conversion.
E = Enhancement.
I = Interface.
N = Include.
P = Processing.
R = Report.
U = Utility.
f.................Intended Program Run Frequency.
A = Annually.
B = Bi-weekly
C = Conversion Only.
D = Daily.
M = Monthly.
N = Include (not a stand alone program with its own frequency).
O = On Demand.
P = Accounting Period.
Q = Quarterly.
W = Weekly.
999............Numeric for unique identifier (lowest sequential # available).
n
Open. May be used to add descriptive text to program name.
Attributes
Following are the individual attributes that you should set for a given program:
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
4 of
65
Title
The title you assign to a program shall reflect the functionality of the program. For reporting programs,
this title will also be displayed as the title of the report when used in conjunction with the West Group
standard header function Z_HEADER_ROUTINE. The title shall not contain all CAPS and shall not
contain a period.
Type
As required by SAP.
Status
Although not required by SAP, it is recommended that you enter an appropriate non-blank value into this
field.
Application
As required by SAP.
Authorization group
You should use this field only if the Functional Team requires authorization at the program level. Work
with Basis / SAP Security Administrator to identify the required authorization group, create the
authorization group, and test the program level security.
Development class
You must assign a development class to any program that is to be transported. If the program is not to be
transported, you must create it as a local object (same as assigning development class $TMP to the
program). Development classes help organize our development environment. Below are the development
classes to which every development object should be associated. As the need for new development classes
arises they will be added to this list. The team leads will request the new development class from Basis and
Basis will add the class along with security to the new class. The development class will be required on all
technical specs.
Naming convention:
Standard and EDI
ZOTC Order to Cash
ZOTC_SUBS
ZOTC_PSWD
ZOTC_FEDGOV
ZOTC_BILLING
ZOTC_WLPRICING
ZOTC_PRICING
ZOTC_SC
ZFIN
Subscription Maintenance (Add, lapse, transfer, etc.)

Passwords
Federal Government
Billing both Westlaw and Print/CD
WL Pricing Front-end
Pricing processes and formulas
Ship and Charge
Finance
No breakdown currently needed
ZPUB
Pub/Man
ZPUB_WM
ZARCH
Warehouse management, deliveries, RF, etc.
Archiving
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
5 of
65
ZBAS
Basis
ZBWDEV
Business Warehouse extractors

ZREPORT
Reporting
ZREPORT_FIN
ZREPORT_OTC
ZREPORT_PUB
Finance reports
OTC reports
Pub/Man reports
ZECOMM
E-Commerce
ZECOMM_CSS
Customer Self Service
ZCRSAPP
Cross Application
ZCRSAPP_SAPI
SAPI application
ZTEST
Example Code
Fixed point arithmetic

This attribute is turned on by default when the program is created. You should always leave it on.
Source Code
Coding Guidelines
When developing ABAP source code, you should adhere to the following guidelines whenever possible:
Readability
Within all programs, you should use structured coding techniques.
Within all non-interactive programs, you should use a top-down design (i.e. never branch backward
within your procedural source code).
All of your source code should be developed in a maintainable form. Whenever possible, you should
avoid using rarely used coding techniques that will be difficult to understand by another developer.
Less code is not necessarily better.
When coding a complex statement such as a call to a function module or a statement with multiple
additions, you should import the associated ABAP Editor Pattern for the statement into the source
code.
Whenever possible, you should avoid using large blocks of code in one module or form. You should
break them down into smaller modules or forms. Each form or module should support one basic
program function.
You should code each new ABAP statement on a separate line. You should never combine multiple
statements on the same line.
Example:
Standard:
move g_vkorg to gt_sites-vkorg.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
6 of
65
append gt_sites.
Non-standard (DO NOT USE!):
move g_vkorg to gt_sites-vkorg.
append gt_sites.
You should group together all common declarative elements (e.g. TABLES, DATA, CONSTANTS) that
are declared globally and declare them at the beginning of the program - before any procedural code.
(e.g. You should code all global DATA statements consecutively within the program.). PARAMETERS
and SELECT-OPTIONS are considered one in the same, so you may code them together.
Example:
Standard:
tables:
bdcp,
cdpos,
knvh.
" Change pointer

" Change document
" Customer hierarchies
data:
g_datab_limit
g_event_param
g_item_cnt
type d,
like tbtco-eventparm,
type i.
constants:
gc_false
gc_article_price_ref
gc_article_ref_to_new_var
value ' ',

value 'p',
value 'o'.

data:
g_datab_limit
g_event_param
type d,
like tbtco-eventparm.
constants:
gc_false
value ' '.
data:
g_item_cnt
type i.
constants:
gc_article_price_ref
gc_article_ref_to_new_var
value 'p',
value 'o'.
You should avoid chaining identical ABAP procedural statements together using the statement
keyword with a colon (the exception being the WRITE statement). Chaining is acceptable for
declarative elements, such as DATA. For example, when five consecutive moves need to be
executed, you should code five separate MOVE statements, each on a separate line, aligning their
associated additions (start them in the same column).
Example:
Standard:
move p_vkorg
Last changed on:

2/3/2006 11:58:00 AM
to g_vkorg.
Last changed by:

u0092453
File name:
Page:
7 of
65
move gt_sites-vtweg to g_vtweg.

move s_werks-low
to g_werks.
move:
p_vkorg
to g_vkorg.
gt_sites-vtweg to g_vtweg.
s_werks-low
to g_werks.
You should use blank lines whenever necessary to enhance readability.
You should place comments within the program wherever necessary to enhance the understanding of
the code.
Indentation:
You must indent each ABAP statement addition from the statement keyword(s) when coding the
additions on subsequent lines. Two or four characters per indentation is a good guideline.
When coding multiple additions for one statement on subsequent lines, you must align each
addition (start in same column)..
Example:
select wkfil
from zrzn1
into wl-werks
where vkorg
and vtweg
and matnr
and zz_zone
=
=
=
=
gt_worklist-vkorg
gt_worklist-vtweg
gt_wl_mat-matnr
gt_acclevel-zz_zone.
When coding a looping structure (LOOPENDLOOP, DOENDDO, etc.) or any other logic block
that is defined by a main keyword and its associated ENDxxx keyword, you must align the main
keyword with its associated ENDxxx keyword and indent all statements between these two
keywords. When coding the statements between the two keywords, you should not start them in
the same column as the additions to the main keyword if coding each addition on a separate line.
Example:
loop at gt_kvgr
where kvgr1 = l_kvgr1
and kvgr2 = l_kvgr2.
gt_worklist-werks = gt_kvgr-werks.
append gt_worklist.
endloop.
It is recommended that you use SAPs Pretty Printer function to indent and align your source
code. Pretty Printer can be found in the ABAP editor under Menu path ProgramPretty
Printer.
When updating source code, you must code the new logic to conform to the modularity, structure, and
style of the original source code (providing this code adheres to the coding standards set forth in this
document).
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
8 of
65
When naming declarative elements (except for CONSTANTS), you should use an associated Data
Dictionary table field name after the standard naming convention prefix whenever possible. For
example, you would use g_vkorg to name a global variable for storing the sales organization field.
When naming other declarative elements and/or other types of development elements, you should use
meaningful, yet concise object names.
Functionality
If an object to be updated is already being edited by another developer, you should confer with your
Team Lead before making any changes to that object. Changing that object will cause another task to
be created under the CTS (Change and Transport System) request for that object, and this is not
always the desired result.
When accessing the database, you should use ABAP Open SQL whenever possible. You may only
use Native SQL under extraordinary circumstances and only with approval from your Team Lead.
When necessary to access database table data repetitively or continuously, you should select the
appropriate data from the database and load it into an internal table, then access it from the internal
table. This will increase your programs efficiency by eliminating multiple database reads and
reducing network traffic.
You should always check the return code (SY-SUBRC) after executing a function module call, a
database table access statement, or an internal table access statement.
You should never code literals (text between quotes) within any procedural code. You should declare
all literals as either text symbols within the text elements of your program or as constants (using the
CONSTANT statement) within the data declaration area of your program.
When coding commonly used functionality, you should use a FORM if the functionality is to be used
only by that program. Otherwise, use a function module or include program if multiple programs
could use the functionality. As always, be sure to check if one already exists.
Frequently used data elements occurring within multiple related programs should be defined within an
INCLUDE module or program, and each program should access this INCLUDE module.
Performance
Is the program using SELECT * statements?

You should convert them to SELECT column 1 column 2 or use projection views.
Are CHECK statements for table fields embedded in a SELECTENDSELECT loop?

You should incorporate the CHECK statements into the WHERE clause of the SELECT statement and
re-write the statement to no longer use ENDSELECT.
Do SELECTs on non-key fields use an appropriate DB index or is the table buffered?

You should create an index for the table in the data dictionary or buffer the tables if they are read only
or read mostly. (You must go through the proper approval procedures before creating or updating
any table indexes or table buffering. See the Tables chapter of the Data Dictionary Elements
section of this document.)
Is the program using nested SELECTs to retrieve data?

You should convert nested SELECTs to database views (see Views in the Data Dictionary section of
this document), DB joins or SELECT FOR ALL ENTRIES IN ITAB.
Are there SELECTs without WHERE condition against files that grow constantly (BSEG, MKPF,
VBAK)?
Your program design is wrong - back to the drawing board.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
9 of
65
Are SELECT accesses to master data files buffered (i.e. no duplicate accesses with the same key)?
You should buffer accesses to master data fields within your program by storing the data in an internal
table and accessing the table with the READ TABLE BINARY SEARCH method.
Is the program using SELECT APPEND ITAB ENDSELECT techniques to fill internal tables?
You should change the processing to read the data immediately into an internal table (SELECT
VBLEN AUART INTO TABLE IVBAK)
Is the program using SELECT ORDER BY statements?

You should read the data into an internal table first and then sort it, unless there is an appropriate
index for the order by fields.
Is the programming doing calculations/summations that can be done on the database via SUM, AVG,
MIN, MAX functions for the SELECT statement?
You should use the calculation capabilities of the database via SELECT SUM
Are internal tables processed using the READ TABLE itab WITH KEY BINARY SEARCH
technique?
If not, you should sort the tables and change the table accesses to use BINARY SEARCH method.
Is the program inserting/updating or deleting data in dialog mode (not via an update function
module)?
You should make sure that the program issues COMMIT WORK statements when one or more logical
units of work (LUWs) have been processed.
Declarative Elements
The term "Declarative Elements" is used to describe the programming elements available to you for
defining the internal environment the program will run under. Basically, this is everything that is not logic
or procedural code. This section defines the development standards for the following Declarative
Elements:
REPORT/PROGRAM
TABLES
TYPES
SELECT-OPTIONS
PARAMETERS
DATA
CONSTANTS
RANGES
FIELD-SYMBOLS
REPORT/PROGRAM
In the ABAP development environment, the terms report and program along with their associated
keywords "REPORT" and "PROGRAM" are used interchangeably. You may use either of these keywords
when creating an ABAP program.
Note: It is recommended that you create all new programs via the Repository Browser instead of using the
ABAP Editor directly. When a program is created via the Repository Browser, a source code template is
created for the entire program. This template consists of comment lines for entering a program description,
the standard format for the REPORT statement, and standard formats for other program elements and
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
10 of
65
keywords (only comment lines for now, need to create the rest). You can then make the necessary changes
to this template using the ABAP Editor. This template is not provided when you create a program directly
from within the ABAP Editor.
When coding the REPORT statement, you must:
Declare it as the first executable statement in your program, starting the REPORT keyword in column
1.
Always include the MESSAGE-ID, LINE-COUNT, LINE-SIZE, and NO STANDARD PAGE
HEADING additions to this statement (they are already included in the REPORT statement
template(Need to create it)).
Declare each statement addition on a separate line, indenting each consistently to the right of the
REPORT keyword.
Update the MESSAGE-ID addition with the West Group message class associated with the SAP
functional group for which the program is written. For example, all programs written for the SAP
Financial functional group in the Accounts Payable area (program name ZFIAPxxxxx) shall use
message ID (message class) ZFIAPxxxxx.
The NO STANDARD PAGE HEADING addition inactivates the standard SAP report header and allows for
the use of the West Group standard report header instead. The West Group standard header function
Z_HEADER_ROUTINE will control the formatting of all report headings, plus the end of report line. See
the REPORT/PROGRAM OUTPUT section of this document for more information about function
Z_HEADER_ROUTINE.
Naming convention:
When declaring the REPORT/PROGRAM name, you should use the Program Name you assigned to the
program when you created it.
Example:
*----------------------------------------------------------------------*
* ZFIGLRA001_SITE_MID_YEAR_BUDGET - Site mid-year budget report by
*
*
quarter, wholesale *
*
*
* This program creates the Site Mid-Year Budget Report by Quarter
*
* for a wholesale site.
*
*----------------------------------------------------------------------*
report zfiglra001_site_mid_year_budget
no standard page heading
line-size 132
line-count 65
message-id zfiap.
TABLES
When coding the TABLES statement, you must:
Start the TABLES keyword in column 1.

Declare each database table on a separate line immediately after the TABLES keyword.
Consistently indent each declared table name to the right of the TABLES keyword.
Declare all global tables together under one TABLES statement, immediately following the REPORT
statement in your program. A global table is defined as a table declared outside of a FORM
subroutine or function module, enabling you to reference it from anywhere within your program.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
11 of
65
You may order the tables any way you like, although alphabetizing is recommended. Including the table
description as an in-line comment is optional.
Example:
tables:
cosp,
cosr,
csks,
cskt.
"Cost Totals
"Statistical
"Cost Center
"Cost Center
- External Postings
Ratio Totals
Master
Texts
TYPES
When coding the TYPES statement, you must:
Start the TYPES keyword in column 1.

Declare each user-defined type on a separate line immediately after the TYPES keyword.
Consistently indent each declared type to the right of the TYPES keyword.
Declare all global types together under one TYPES statement, immediately following the TABLES
statement in your program. A global type is defined as a type declared outside of a FORM subroutine
or function module, enabling you to reference it from anywhere within your program.
Naming convention:
You must code each TYPES name with a standard prefix of z.
Example:
types:
zamt
zdept(3)
type p decimals 2,
type c.
SELECT-OPTIONS
When coding SELECT-OPTIONS statements, you must:
Start the SELECT-OPTIONS keyword in column 1 unless it is subordinate to a SELECTIONSCREEN statement, in which case you must code it on the following line and indent it to the right of
the SELECTION-SCREEN keyword.
Declare only one individual selection option on a given line. You may declare the selection option
either on the same line as the SELECT-OPTIONS keyword or on the next line following the
SELECT-OPTIONS keyword. It is recommended that you include the SELECT-OPTIONS keyword
for each declared selection option.
Consistently indent each declared selection option to the right of the SELECT-OPTIONS keyword
(when declaring on the following line).
Consistently indent each associated addition for a given selection option to the right of the SELECTOPTIONS keyword.
If you are declaring a select option field that has a set number of possible values, you must display a
possible values box when the user places the cursor on either the low or high range field. To accomplish
this, you must code the associated FOR field of the SELECT-OPTIONS statement as either a Data
Dictionary field that points to Check Table, a Data Dictionary field that points to a domain that has an
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
12 of
65
associated values list, or an internal table field in which the table contains all possible values for the field.
See the Selection Screens chapter of the REPORT/PROGRAM OUTPUT section of this document for
more information on possible values boxes.
Naming convention:
You must code each SELECT-OPTIONS name with a standard prefix of s_.
Examples:
select-options: s_vkorg
select-options: s_vtweg
select-options: s_werks
for wkbp-vkorg
default 3276
obligatory.
for wkbp-vtweg.
for wkbp-werks.
-- or -select-options:
s_vkorg
s_vtweg
s_werks
for wkbp-vkorg
default 3276
obligatory,
for wkbp-vtweg,
for wkbp-werks.
PARAMETERS
When coding PARAMETERS statements, you must:
Start the PARAMETERS keyword in column 1 unless it is subordinate to a SELECTION-SCREEN

statement, in which case you must code it on the following line and indent it to the right of the
SELECTION-SCREEN keyword.
Declare only one individual parameter on a given line. You may declare the parameter either on the
same line as the PARAMETERS keyword or on the next line following the PARAMETERS keyword. It
is recommended that you include the PARAMETERS keyword for each declared parameter.
Consistently indent each declared parameter to the right of the PARAMETERS keyword (when
declaring on the following line).
Consistently indent each associated addition for a given parameter to the right of the PARAMETERS
keyword.
If you are declaring a parameter field that has a set number of possible values, you must display a possible
values box when the user places the cursor on that field. To accomplish this, you must code the associated
LIKE field of the PARAMETERS statement as either a Data Dictionary field that points to Check Table, a
Data Dictionary field that points to a domain that has an associated values list, or an internal table field in
which the table contains all possible values for the field. See the Selection Screens chapter of the
REPORT/PROGRAM OUTPUT section of this document for more information on possible values
boxes.
Naming convention:
You must code each PARAMETERS name with a standard prefix of p_.
Examples:
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
13 of
65
parameters: p_vkorg
parameters: p_vtweg
parameters: p_count
like wkbp-vkorg.
like wkbp-vtweg.
type I
default 50
obligatory.
-- or -parameters:
p_vkorg
p_vtweg
p_count
like wkbp-vkorg.
like wkbp-vtweg.
type I
default 50
obligatory.
DATA
When coding DATA statements, you must:
Start the DATA keyword in column 1 if it is a global variable, or column 3 if it is a local variable.
Global variable. This is defined as a data work field or structure declared outside of a
FORM subroutine or function module. You are able to reference it from anywhere within the
program.
Local variable. This is defined as a data work field or structure declared within a FORM
subroutine or function module. You are only able to reference it from within that form or
function.
When declaring individual work fields, you must:
Declare each field on a separate line immediately after the DATA keyword. You may declare the DATA
keyword multiple times to create logical groupings of work fields for clarity and readability purposes.
You may list the declared fields within a given DATA statement in any order.
Consistently indent each declared field to the right of the DATA keyword.
Align all similar additions for each individual work field together within a given DATA keyword
grouping (e.g. TYPE, VALUE). You may consider the TYPE and LIKE additions as one in the same
for alignment purposes.
Use the LIKE addition whenever possible to reference a Data Dictionary field.
When declaring an internal table or data structure, you must:
Code the BEGIN OF variant either on the same line as the DATA keyword or on the following line. If
you code it on the following line, you must indent it to the right of the DATA keyword.
Declare each individual work field or include structure belonging to this data structure/internal table on
a separate line following the statement containing the BEGIN OF variant.
Indent each individual work field consistently to the right of the BEGIN OF variant.
Code the END OF variant on a separate line after the last declared individual work field or include
structure of the data structure/internal table.
Align the END OF variant with the BEGIN OF variant.
Code one DATA statement using the LIKE (structure name) addition when declaring a data structure
that is identical to a Data Dictionary structure. Do not use the INCLUDE STRUCTURE keywords.
Code one DATA statement using the LIKE (structure name) addition when declaring an internal table
to be loaded with database table data (for repetitive processing) and all of the database table fields are
to be accessed.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
14 of
65
Code a group of individual data fields, each using the LIKE (table field) addition when declaring an
internal table to be loaded with database table data (for repetitive processing) and only a subset of the
database tables fields are to be accessed.
Set the OCCURS value for internal tables (used to define their size) to 0 if the table will contain more
than 8K-bytes of data. Otherwise, estimate the actual table size and set the OCCURS value
accordingly.
Naming convention:
When declaring DATA names, you must:
Include a standard prefix of g_ for each global individual work field. Do not include this prefix for
individual work fields declared within a structure or internal table.
Include a standard prefix of l_ for each local individual work field. Do not include this prefix for
individual work fields declared within a structure or internal table.
Include a standard prefix of gs_ for each global structure.
Include a standard prefix of ls_ for each local structure.
Include a standard prefix of gt_ for each global internal table.
Include a standard prefix of lt_ for each local internal table.
Use the standard prefix plus the associated Data Dictionary field name or system variable, whenever
possible, when naming an individual work field.
Never include a hyphen ( - ) within an individual work field name. You may include underscores ( _ ).
Examples:
Individual work fields (global variables):
data:
g_vkorg
g_vtweg
g_count
like wkbp-vkorg,
like wkbp-vtweg.
type i
value 20.
Individual work fields (local variables):

form newform.
data:
l_vkorg
like wkbp-vkorg,
l_vtweg
like wkbp-vtweg,
l_count
type i
.
.
.
endform.
value 20.
Data structures (global):

data: begin of gs_orglevel,
vkorg
like wkbp-vkorg,
vtweg
like wkbp-vtweg,
werks
like wkbp-werks,
end of gs_orglevel.
-- or -data:
begin of gs_orglevel,
vkorg
like wkbp-vkorg,
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
15 of
65
vtweg
like wkbp-vtweg,
werks
like wkbp-werks,
end of gs_orglevel.
data: g_cust
like kna1.
Data structures (local):

form newform.
data: begin of ls_orglevel,
vkorg
like wkbp-vkorg,
vtweg
like wkbp-vtweg,
werks
like wkbp-werks,
end of ls_orglevel.
.
.
.
endform.
-- or -form newform.
data:
begin of ls_orglevel,
vkorg
like wkbp-vkorg,
vtweg
like wkbp-vtweg,
werks
like wkbp-werks,
end of ls_orglevel.
.
.
.
endform.
form newform.
data: l_cust
.
.
.
endform.
like kna1.
Internal table (global):

data: begin of gt_cust occurs 0,
vkorg
like wkbp-vkorg,
vtweg
like wkbp-vtweg,
werks
like wkbp-werks,
end of gt_cust.
-- or -data:
begin of gt_cust occurs 0,
vkorg
like wkbp-vkorg,
vtweg
like wkbp-vtweg,
werks
like wkbp-werks,
end of gt_cust.
Internal table (local):
form newform.
data: begin of lt_cust occurs 0,
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
16 of
65
vkorg
like wkbp-vkorg,
vtweg
like wkbp-vtweg,
werks
like wkbp-werks,
end of lt_cust.
.
.
.
endform.
-- or -form newform.
data:
begin of lt_cust occurs 0,
vkorg
like wkbp-vkorg,
vtweg
like wkbp-vtweg,
werks
like wkbp-werks,
end of lt_cust.
.
.
.
endform.
CONSTANTS
When coding CONSTANTS statements, you must:
Start the CONSTANTS keyword in column 1 if it is a global constant, or column 3 if it is a local

constant.
Global constant. This is defined as an individual field or structure declared outside of a

FORM subroutine or function module. You are able to reference it from anywhere within the
program.
Local constant. This is defined as an individual field or structure declared within a FORM
subroutine or function module. You are only able to reference it from within that form or
function.
When declaring individual constant fields, you must:
Declare each field on a separate line immediately after the CONSTANTS keyword. You may declare
the CONSTANTS keyword multiple times to create logical groupings of constant fields for clarity and
readability purposes. You may list the declared fields within a CONSTANTS statement in any order.
Consistently indent each declared field to the right of the CONSTANTS keyword.
Align all similar additions for each individual constant field together within a given CONSTANTS
keyword grouping (e.g. TYPE, VALUE). You may consider the TYPE and LIKE additions as one in
the same for alignment purposes.
When declaring a constant structure, you must:
Code the BEGIN OF variant either on the same line as the CONSTANTS keyword or on the following
line. If you code it on the following line, you must indent it to the right of the CONSTANTS keyword.
Declare each individual constant field belonging to this structure on a separate line following the
statement containing the BEGIN OF variant.
Consistently indent each individual constant field consistently to the right of the BEGIN OF variant.
Code the END OF variant on a separate line after the last declared individual constant field of the
structure.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
17 of
65
Align the END OF variant with the BEGIN OF variant.

Naming convention:
When declaring CONSTANTS names, you must:
Include a standard prefix of gc_ for each global individual work field or structure. Do not include this
prefix for individual work fields declared within a structure or internal table.
Include a standard prefix of lc_ for each local individual work field or structure. Do not include this
prefix for individual work fields declared within a structure or internal table.
Use the standard prefix plus a descriptive, concise field name.
Never include a hyphen ( - ). You may include underscores ( _ ).
Examples:
Individual fields (global):
constants:
gc_sales_org_wg
gc_dist_chan_01
gc_max_entries
like wkbp-vkorg
like wkbp-vtweg
type i
value 4844
value 01,
value 100.
Individual fields (local):

form newform.
constants:
lc_sales_org_wg
lc_dist_chan_01
lc_max_entries
.
.
.
endform.
like wkbp-vkorg
like wkbp-vtweg
type i
value 4844,
value 01,
value 100.
Structures (global):
constants: begin of gc_orglevel,
sales_org_wg
like wkbp-vkorg
dist_chan_01
like wkbp-vtweg
site_4422
like wkbp-werks
end of gc_orglevel.
value 4844,
value 01,
value 4422,
-- or -constants:
begin of gc_orglevel,
sales_org_wg
like wkbp-vkorg
dist_chan_01
like wkbp-vtweg
site_4422
like wkbp-werks
end of gc_orglevel.
value 4844,
value 01,
value 4422,
RANGES
When coding RANGES statements, you must:
Start the RANGES keyword in column 1 if it is a global range, or column 3 if it is a local range.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
18 of
65
Global range. This is defined as a range declared outside of a FORM subroutine or

function module. You are able to reference it from anywhere within the program.
Local range. This is defined as a range declared within a FORM subroutine or function
module. You are only able to reference it from within that form or function.
Declare each range on a separate line immediately after the RANGES keyword. You may declare the
RANGES keyword multiple times to create logical groupings of ranges for clarity and readability
purposes. You may list the declared ranges within a given RANGES statement in any order.
Consistently indent each declared range to the right of the RANGES keyword.
Align all FOR clauses underneath each other for each declared individual range within a given
RANGES keyword grouping.
Naming convention:
When declaring RANGES names, you must:
Include a standard prefix of gr_ for each global range.

Include a standard prefix of lr_ for each local range.
Use the standard prefix plus the associated Data Dictionary field name or system variable whenever
possible.
Examples:
Global:
ranges:
gr_vkorg
gr_vtweg
for wkbp-vkorg,
for wkbp-vtweg.
Local:
form newform.
ranges:
lr_vkorg
lr_vtweg
.
.
.
endform.
for wkbp-vkorg,
for wkbp-vtweg.
FIELD-GROUPS
When coding FIELD-GROUPS statements, you must:
Start the FIELD-GROUPS keyword in column 1.

Declare each individual group on a separate line immediately after the FIELD-GROUPS keyword.
Consistently indent each declared group to the right of the FIELD-GROUPS keyword.
Always name the first group fg_header (available sort fields) and follow it with the remaining
groups, giving each group a meaningful name.
Follow the FIELD-GROUPS declaration with the appropriate INSERT statement required to insert
field names into each field group.
Start each new INSERT statement in column 1.
Declare each individual insert field on a separate line immediately after the INSERT keyword.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
19 of
65
Consistently indent each declared insert field to the right of the INSERT keyword.
Use a corresponding Data Dictionary field, whenever possible, when declaring an insert field.
Naming convention:
When declaring FIELD-GROUPS names, you must:
Include a standard prefix of fg_.

Use the standard prefix plus a descriptive, concise name.
Examples:
field-groups:
fg_header.
fg_detail.
insert
wkbp-vkorg
wkbp-vtweg
into fg_header.
insert
wkbp-werks
wkbp-matnr
into fg_detail.
FIELD-SYMBOLS
When coding FIELD-SYMBOLS statements, you must:
Start the FIELD-SYMBOLS keyword in column 1 if it is a global field symbol, or column 3 if it is a

local field symbol.
Global field symbol. This is defined as a field symbol declared outside of a FORM
subroutine or function module. You are able to reference it from anywhere within the program.
Local field symbol. This is defined as a field symbol declared within a FORM subroutine
or function module. You are only able to reference it from within that form or function.
Declare each field symbol on a separate line immediately after the FIELD-SYMBOLS keyword. You
may declare the FIELD-SYMBOLS keyword multiple times to create logical groupings of field
symbols for clarity and readability purposes. You may list the declared field symbol within a given
FIELD-SYMBOLS statement in any order.
Consistently indent each declared field symbol to the right of the FIELD-SYMBOLS keyword.
Naming convention:
When declaring FIELD-SYMBOLS names, you must:
Include a standard prefix of gfs_ for each global field symbol.

Include a standard prefix of lfs_ for each local field symbol.
Use the standard prefix plus a descriptive, concise name.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
20 of
65
Examples:
Global:
field_symbols:
<gfs_fieldname>,
<gfs_save_fieldname>.
Local:
form newform.
field_symbols:
<lfs_fieldname>,
<lfs_save_fieldname>.
.
.
.
endform.
Event Elements
The term "Event Elements" is used to describe the programming elements available to you for designating a
set of statements to be executed at a certain point in time or upon the occurrence of a specific event during
execution of your program.
When coding event element keywords, you must start them in column 1. When applicable, you should
code the events in the order that they will be executed.
This section defines the development standards for the following Event Elements:
AT SELECTION SCREEN
START-OF-SELECTION
END-OF-SELECTION
AT USER-COMMAND
AT PFn
TOP-OF-PAGE
AT SELECTION-SCREEN
ON psel
You should use the AT SELECTION-SCREEN event with the ON psel addition, where psel is a
parameter or select-options field, when editing selection screen input for an individual field. If the validity
of a parameter or select-options field is dependent upon the value of another parameter or select-options
field, you should edit the parameter or select-options field within a stand-alone AT SELECTION-SCREEN
event (without any additions).
ON HELP-REQUEST
You shall not use the ON HELP-REQUEST addition. You will generate field help using other methods
(see the Selection Screens chapter of the REPORT/PROGRAM OUTPUT section of this document).
START-OF-SELECTION
You must code the START-OF-SELECTION event in all your ABAP reporting programs.
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
21 of
65
END-OF-SELECTION
You must code the END-OF-SELECTION event in all your ABAP reporting programs. Within this event,
you shall print the end of report line (imported via function module Z_HEADER_ROUTINE). See the
REPORT/PROGRAM OUTPUT section of this document for more information on function module
Z_HEADER_ROUTINE.
AT USER-COMMAND
You shall use the AT USER-COMMAND event within interactive programs to interrogate user selections
via function key or the command field. Do not use the AT PFn event for this purpose.
AT PFn
You shall not use the AT PFn event, except for testing purposes. Use the AT USER-COMMAND event
instead.
TOP-OF-PAGE
You must include the TOP-OF-PAGE event in all your ABAP programs that produce list report(s). Within
this event, you shall print the standard report header lines (imported via function module
Z_HEADER_ROUTINE). See the REPORT/PROGRAM OUTPUT section of this document for more
information on function module Z_HEADER_ROUTINE.
DURING LINE-SELECTION
You must include the TOP-OF-PAGE event with the DURING LINE-SELECTION addition in all your
ABAP programs that will contain drill-down online reporting capability.
All standards that apply to TOP-OP-PAGE will also apply to TOP OF PAGE DURING LINESELECTION.
Control Elements
The term "Control Elements" is used to describe the programming elements available to you for controlling
the flow of your program within some type of processing block of logic. This section defines the
development standards for the following Control Elements:
IF
CASE
ON CHANGE OF
DO
WHILE
LOOP
FORM (SUBROUTINES)
CALL (FUNCTION MODULES)
IF
When coding an IF statement, you must:
Align the ELSE (when used), ELSEIF (when used), and ENDIF keywords with the IF keyword.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
22 of
65
Consistently indent to the right of the IF keyword all other statements between the IF and ENDIF
statements that do not contain one of these keywords.
Code the ELSE keyword as the only word on that line (when used). You should start all statements
associated with a particular ELSE clause on the line following the ELSE keyword and consistently
indent them to the right of the ELSE keyword.
Keep nested IF statements to a minimum for readability. Alternatively, you should use PERFORM and
CASE statements. When you need to check the same data field repeatedly for particular values, you
should use a CASE statement instead of an IF statement. The CASE statement is more efficient than
the IF statement in this situation.
Examples:
if bkpf-belnr = g_invoice_nbr.
perform process_invoice.
else
perform check_document_nbr.
endif.
if g_rec_type = gc_header_rec.
perform process_header_rec.
elseif g_vtweg = gc_vtweg_military.
perform process_military.
elseif g_vkorg = gc_vkorg_rc.
perform process_vkorg_rc.
endif.
CASE
When coding an CASE statement, you must:
Code each WHEN clause on a separate line and indent each WHEN keyword consistently to the right of
the CASE keyword.
Code all WHEN clauses in the order that they are most likely to occur (most likely will go first).
Code each logical expression for a given WHEN clause on a separate line after the WHEN keyword and
consistently indent it to the right of the WHEN keyword.
Align the ENDCASE keyword with the CASE keyword.
Keep nested CASE statements to a minimum for readability. Alternatively, you may use PERFORM
statements.
Always use the WHEN OTHERS clause. If no action is to be taken when branching to the WHEN
OTHERS clause, you would not code any procedural statements underneath it.
Example:
case g_rec_type.
when gc_rec_type_a.
perform process_report_1.
when gc_rec_type_b
or gc_rec_type_c.
when gc_rec_type_d.
when others.
perform invalid_rec_type.
endcase.
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
23 of
65
DO
When coding the DO control element, you must follow the coding indentation rules as stated in the Coding
Guidelines previously mentioned in this section of the document.
You must always code the DO control element with a controlled exit point (such as a TIMES variant or an
EXIT statement) to avoid a continuous loop.
Whenever possible, you should use a WHILE loop instead of a DOENDDO construct because it is slightly
more efficient.
Examples:
do.
read dataset pinfile into g_rzone_h.
if sy-subrc <> 0.
exit.
endif.
enddo.
do 5 times
varying g_letter1 from g_word1 then g_word3
varying g_letter2 from g_word2 then g_word4.
write: g_letter1, g_letter2.
enddo.
WHILE
When coding the WHILE control element, you must follow the coding indentation rules as stated in the
Coding Guidelines area of this chapter of the document.
Whenever possible, you should use a WHILE loop instead of a DOENDDO construct because it is slightly
more efficient.
Examples:
while g_cnt < 10.
perform main_process.
add 1 to g_cnt.
endwhile.
while g_cnt < 10
vary g_letter1 from g_word1 next g_word3
vary g_letter2 from g_word2 next g_word4.
write: g_letter1, g_letter2.
add 1 to g_cnt.
endwhile.
LOOP
When coding the LOOP control element, you must follow the coding indentation rules as stated in the
Coding Guidelines area of this chapter of the document with the following exception: the FROM and TO
additions may be on the same line.
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
24 of
65
Warning: You should use the AT additions at your own risk. Unless you loop through the entire internal
table (i.e. not using the WHERE addition) and first sort the internal table in the order that the internal table
fields are declared, you may get unpredictable results.
Examples:
loop at lt_mara.
lt_zrbpw-matnr = lt_mara-matnr.
append lt_zrbpw.
endloop.
loop at lt_mara
where mchl3 = g_mchl3.
append lt_zrbpw.
endloop.
loop at lt_mara
from 1 to 10.
append lt_zrbpw.
endloop.
FORM (SUBROUTINES)
When coding the FORM control element, you must follow the coding indentation rules as stated in the
Coding Guidelines area of this chapter of the document.
You should use the ABAP Editor Pattern when coding the FORM statement. This will ensure that a
standard comment box for the form will be imported into the source code. There are two ways to import a
FORM pattern into the source code: by double-clicking on the associated PERFORM statement, which will
place the form at the end of the program, or by importing the FORM pattern using Other Patterns at the
bottom of the Pattern dialog box, which will place the form at the cursor position.
The use of internal subroutines are imperative in developing well-structured programs. Wherever possible,
you should place logically associated command statements into subroutines within your program.
You must code all FORM subroutines after the END-OF-SELECTION event and order them according to
their execution sequence. You should always code a FORM subroutine after its associated PERFORM
statement to give the program a top-down design.
It is recommended that you do not call a FORM subroutine from within your program that has been declared
in another program (external subroutine). This is because the entire parent program of the external form
will get pulled into runtime memory. As an alternative, you should consider either putting the subroutine
logic into a function module or an include program. Whenever possible, you should not duplicate the
same code in multiple programs.
Naming convention:
When declaring FORM names, you must:
Use meaningful, descriptive, concise names.

When declaring FORM parameter names (in the USING addition without the VALUE clause), you must:
Include a standard prefix of f_ for each individual work field.

Include a standard prefix of ft_ for each internal table.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
25 of
65
Excluding the standard prefix, use a name that is identical to the respective parameter name listed in
the USING addition of the corresponding PERFORM statement.
Tip: To quickly find a particular FORM subroutine within your program, especially a hard copy, you may
consider adding a prefix to each FORM name in the format X999, where X is any alphanumeric character
and 999 is any number, then place the FORM subroutines within the program in alphanumeric sequence
(i.e. A000, A100, A110, A200, B000, B100, C000, etc.).
Examples:
NOTE: Use the Pattern for the FORM statement via the ABAP Editor.
*----------------------------------------------------------------------*
* Form ADD_WL_MAT_MC
*----------------------------------------------------------------------*
* Select all articles for a given merchandise category.
*----------------------------------------------------------------------*
form add_wl_mat_mc.
loop at lt_mara
where matkl = g-matkl.
append lt_zrbpw.
endloop.
endform.
ADD_WL_MAT_MC
Example of USING addition (without the VALUE clause):
perform lock_table_w using svkorg-low pvtweg.
form lock_table_w using f_vkorg f_vtweg.
zrbpl-vkorg = f_vkorg.
zrbpl-vtweg = f_vtweg.
modify zrbpl.
commit work.
endform.
LOCK_TABLE_W
CALL (FUNCTION MODULES)

It is strongly recommended that you use the appropriate ABAP Editor Pattern when coding the CALL
statement to ensure that you include all associated parameters for the given function module. You may
delete any unused parameters from the CALL statement to enhance readability.
You must always check the return code (SY-SUBRC) after executing a CALL to a function module.
Example:
call function 'job_close'
exporting
event_id
event_param
jobcount
jobname
importing
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
=
=
=
=
'R_BGP_VKPB_JOBSTART'
g_event_param
g_jobnr
f_jobname
File name:
Page:
26 of
65
job_was_released
exceptions
cant_start_immediate
invalid_startdate
jobname_missing
job_close_failed
job_nosteps
job_notex
lock_failed
others
case sy-subrc.
when 0.
write: text-001.
when others.
message e999 with sy-subrc.
endcase.
= g_job_subrc
=
=
=
=
=
=
=
=
1
2
3
4
5
6
7
8.
Operational Elements
The term "Operational Elements" is used to describe the programming elements available to you for
performing some type of operational action on any of the data elements of your program. This section
defines the development standards for the following Operational Elements:
CHECK
CLEAR
COMMIT WORK
CONCATENATE
DELETE
EXPORTTO MEMORY / IMPORTFROM MEMORY
FORMAT
MODIFY
MOVE/MOVE-CORRESPONDING
READ TABLE (itab)
SELECT
WRITE
CHECK
It is recommended that you use the CHECK statement instead of the IFEXITENDIF structure when
determining if a looping structure or routine shall be terminated.
You should not use the CHECK statement within a SELECTENDSELECT construct to determine which
rows should be processed. Use the WHERE addition of the SELECT statement instead and change the
statement to no longer use ENDSELECT.
Examples:
Standard method of terminating a looping structure
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
27 of
65
form read_itab.
read table itab
where werks = p_werks
binary search.
check sy-subrc = 0.
.
.
.
endform.
Non-standard method of terminating a looping structure (DO NOT USE!)
form read_itab.
read table itab
where werks = p_werks
binary search.
if sy-subrc <> 0.
exit.
endif.
.
.
.
endform.
CLEAR
It is recommended that you use the CLEAR statement for setting a field to its initial value.
Examples:
data:
g_integer
. g_char
.
.
.
value i,
value c,
Standard method of initializing field

clear g_integer.
clear g_char.
Non-standard methods of initializing field (DO NOT USE!)
g_integer = 0.
move 0 to g_integer.
g_char = space.
g_char = .
move space to g_char.
COMMIT WORK
You should always issue a COMMIT WORK after performing a large number of updates
(changes/inserts/deletes) to the database. You should issue it in the context of a logical unit of work
(LUW), such that if the next COMMIT WORK fails, the database is not out of sync. For example, if update
A and update B both need to be in the database for it to be logically correct, then you need to issue the
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
28 of
65
COMMIT WORK after update B. This is necessary so that if update B fails you can ROLLBACK update A so
that the database stays consistent. If update A and update B are not related and update A could affect a
large number of records (say 1000 records) then you should issue a COMMIT WORK following both update
A and update B.
CONCATENATE
It is recommended that you use the CONCATENATE statement for joining character strings together outside
of a looping structure or within a looping structure that will have a minimum amount of loops. It is
generally more clear and efficient than using a data structure. You should use a data structure when joining
character strings within a looping structure that will loop a significant amount of times, or if the
concatenation involves many fields and incorporating them all into one CONCATENATE statement would
become difficult to read.
DELETE
If you need to delete multiple database or internal table entries - all containing the same characteristics you should use the WHERE addition of the DELETE statement, as opposed to the DELETE statement within
a looping structure.
Examples:
Standard method of deleting database table entries with similar characteristics
delete table zrbpc
where posted = gc_yes
or sleeping = gc_yes.
Non-standard method of deleting database table entries with similar characteristics (DO NOT USE!)
select * from zrbpc
where posted = gc_yes
and sleeping = gc_yes.
delete zrbpc.
endselect.
EXPORT TO MEMORY / IMPORTFROM MEMORY

You should always use the ID addition with the EXPORT or IMPORT statement.
You may code the entire EXPORTTO MEMORY / IMPORTFROM MEMORY statement, including the ID
addition, on the same line. It is recommended that you align all TO MEMORY keywords together, all FROM
MEMORY keywords together, and the ID keywords together for each consecutive statement.
Naming convention:
When declaring ID names, you must:
Include a standard prefix of m_progname_ for each ID identifying an individual work field, where
progname is the name of the exporting program.
Include a standard prefix of mt_progname_ for each ID identifying internal table, where
progname is the name of the exporting program.
Excluding the standard prefix, use a name that is identical to the respective individual work field or
internal table containing the data to be exported. Likewise, you should give the individual work field
or internal table to receive imported data a name that is identical to the respective memory ID being
imported.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
29 of
65

Examples:
export
export
export
export
g_year
l_versn
gt_csku
lt_werks
to
to
to
to
memory
memory
memory
memory
import
import
import
import
g_year
l_versn
gt_csku
lt_werks
from
from
from
from
id
id
id
id
memory
memory
memory
memory
m_zfiglra001_year.
m_zfiglra001_versn.
mt_zfiglra001_csku.
mt_zfiglra001_werks.
id
id
id
id
m_zfiglra001_year.
m_zfiglra001_versn.
mt_zfiglra001_csku.
mt_zfiglra001_werks.
FORMAT
You should apply the same standards to the FORMAT statement that you apply to the WRITE statement.
You may code the first addition to this statement on the same line as the keyword FORMAT. You should
code any further additions on subsequent lines, one addition per line, aligning all additions.
When using the COLOR addition, you should use the COL_xxx option instead of the number of the color
(e.g. COLOR COL_TOTAL instead of COLOR 3).
Example:
format color col_total
intensified off
hotspot.
MODIFY
When using the MODIFY dbtab statement to insert or update a database table entry, by definition, a new
entry will be inserted (just like the INSERT statement) if the key does not already exist, or the new entry
will update the existing entry of the same key (just like the UPDATE statement) if the key already exists.
For performance reasons, you should use the MODIFY statement only if it is not possible for you to
distinguish between using the INSERT or UPDATE option.
MOVE/MOVE-CORRESPONDING
When moving data from individual fields of a database or internal table to their corresponding fields in
another database or internal table, it is generally recommended that you use individual MOVE statements
instead of the MOVE-CORRESPONDING statement because they are more efficient. The MOVECORRESPONDING statement is acceptable only if you do not execute it a significant number of times
throughout the course of one execution of the program, thereby not noticeably increasing processing time.
READ TABLE (itab)

It is highly recommended that the READ TABLE (itab) statement is used with the BINARY SEARCH
addition whenever possible to enhance performance. When executing the READ TABLE (itab)
statement using the WITH KEY K1 = F1 and BINARY SEARCH additions, you must:
Sort the internal table by the desired sequence before executing this statement.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
30 of
65
List all key fields in the WITH KEY addition in the order that the table is sorted.
If you do not, you may get a return code of 4 or 8 (entry not found) after executing this statement, even if
the entry does indeed exist on the internal table.
SELECT
Note: The Performance area of the Coding Guidelines chapter of this section contains many guidelines
for efficient use of the SELECT statement.
You should use the UP TO n ROWS addition when checking to see whether a particular value for a key
field exists on the table and it is possible that this value could exist on more than one table entry (partial
key).
When using a non-key field in the WHERE clause, you may need to incorporate the field into a new index
for the table to speed up the table search process. See the Table Indexes chapter of the DATA
DICTIONARY ELEMENTS section of this document for more information about creating table indexes.
You should always check the system return code (SY-SUBRC) after execution of a SELECT statement.
WRITE
The WRITE statement is the only procedural statement in which it is acceptable, by our standards, for you
to chain statements together on one line using the statement keyword with a colon. When you are writing
to a report, it is recommended that you code one WRITE statement per output line.
You should apply the same standards to the WRITE statement that you apply to the FORMAT statement.
You can find standards for the formatting of report output in the REPORT/PROGRAM OUTPUT section
of this document.
Example:
write:
/01 sy-vline,
02 l_prtdd_cc
09 sy-vline,
10 l_prtdd_year
14 sy-vline,
15 l_prtdd_period
18 sy-vline,
19 l_prtdd_acct
25 sy-vline,
26 l_prtdd_amt
47 sy-vline,
48 l_prtdd_docno
using edit mask '_______'

color col_normal
intensified off,
color col_normal
intensified off,
color col_normal
intensified off,
using edit mask '_______'
color col_normal
intensified off,
color col_normal
intensified off,
using edit mask '__________'
color col_normal
intensified off,
58 sy-vline.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
31 of
65
Other Source Code Elements

This section defines the development standards for the following miscellaneous source code elements:
COMMENTS
COMMENTS
The amount of internal program documentation to include in your program via comments is mainly up to
you. At a minimum, you should provide the necessary level of documentation required to fully clarify the
purpose and functionality of the specific logic, and you should properly document all complex logic.
You may use both full line (* in column 1) and in-line (followed by double quote ) comments as long as
you do not detract from the readability of the program.
For IFELSEENDIF structures that contain many lines, you may add an in-line comment to the end of
the ENDIF statement to indicate its associated IF statement. This will help identify where the IF
construct begins if it is not obvious.
Example:
if not gt_aclvl-matnr is initial.
perform e510_add_wl_mat_matnr.
elseif not gt_aclvl-matkl is initial.
perform e520_add_wl_mat_matkl.
elseif not gt_aclvl-mchl3 is initial.
perform e530_add_wl_mat_mchl3.
.
.
.
endif.
not gt_aclvl-matnr is initial
Text Elements
Titles and headers
Title. The Title text element should be the same as the title defined in the Attributes of the program. For
this reason it is unnecessary to enter a Title text element, as SAP will default to the title defined in the
attributes.
List header. Not used. Because we do not use the standard ABAP header for our reports, the LIST
HEADER text element will not appear on our reports. You must code all list headers manually as text
symbols.
Column header. Not used. Because we do not use the standard ABAP header for our reports, the
COLUMN HEADER text element will not appear on our reports. You must code all column headers
manually as text symbols.
Selection texts
You must include an appropriate text description for each selection text field (selection options and
parameters). When formatting the text description you must:
Capitalize only the first letter of the first word.

Never end it with a period ( . ) or colon ( : ).
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
32 of
65
For more guidelines on selection text formatting, you should refer to Chapter 11 of the SAP Style Guide,
and the Selection Screens chapter of the REPORT/PROGRAM OUTPUT section of this document.
Text symbols
You must code any language text to be used as output from a program (excluding Titles and headers and
Selection texts) as a text symbol. This includes such things as report headers, miscellaneous report texts,
audit report line item descriptions, etc.
Naming convention:
When declaring a Text Symbol ID, you may use any combination of alphanumeric and/or special
characters.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
33 of
65
Messages
When your program must display a message, it is recommended that you use an existing message, if
appropriate. You should make sure the existing message AND its associated long text are both
appropriate for the given situation. You should check the following areas in the order listed to determine if
a suitable message exists:
1.
2.
3.
4.
Similar SAP programs for an SAP-supplied message. This will provide consistency between SAP
and custom applications.
Custom message class ZXXXX (Need to create it). This message class is used for custom
messages that are function module-independent.
Programs default message class (assigned in REPORT statement).
Other custom message classes.
If a suitable message (with long text) could not be found in any of the above areas, you should create a
new message. When creating a new message, you must:
Define the message within either the programs default message class (if applicable only to that
application module), or message class ZX if the message is generic-enough to be used by multiple
application modules.
Create associated long text.
Capitalize only the first letter of the first word.
Never end it with a period ( . ) or colon ( : ).
There are six types of messages:
I - Information, enter to continue
W - Warning, correction possible
E - Error, correction required
A - Abend, transaction terminated
X - Exit, transaction terminated with short dump message
S - Success, message on next screen
For more guidelines on the format and structure of message texts, you should refer to Texts of the SAP
Style Guide (Help > Application help > BC Basis Components > BC SAP Style Guide > Texts).
For message class standards, you should refer to the Message classes area of the OTHER
DEVELOPMENT ELEMENTS section of this document.
All MESSAGE statements should use the following format:
MESSAGE xnnn(mc)
where: x
nnn
mc
= message type
= message number
= message class.
If the messages message class (mc) is identical to the message class designated in the MESSAGE-ID
addition of the REPORT statement, you can omit the message class (mc) in the MESSAGE statement.
You shall not use the MESSAGE statement in the format MESSAGE ID mid TYPE mtyp NUMBER
mnr.
Examples:
message e014 with g_vkorg g_vtweg.
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
34 of
65
Message i025(zfiap).
Long text
You are required to include long text with each message.
During editing, you can organize the long text documentation within certain standard sections. A complete
list of these section names can be found in table TTDTG. Each section consists of a VARNAME (symbol
name) field which is the name of the symbol that you would code in the documentation input screen
(delimited by &), and a VARVALUE (symbol value) field which is the text for the section that appears
when you display the program documentation on-line. When you enter the long text maintenance screen
for an individual message the very first time, the following sections will appear:
VARNAME
CAUSE
VARVALUE
Diagnosis
SYSTEM_RESPONSE
System response
WHAT_TO_DO
What to do
Notes
What has occurred within the program to cause this
message to appear. This is basically a more detailed
description of the original message.
How the system or program has reacted to the event
that has caused this message to appear.
The next steps the user should follow in response to
this message.
If any of the above sections will not be used to document the message, you may delete them from the
documentation. In addition to the above sections, you may add any other sections from the TTDTG table
as needed to further document the message.
Variants
The functional and business users are responsible for the support of program variants in the production
environment. It will be up to them to develop their own standards for the use of variants, although the use
of Z as a first character is will be mandatory.
Variants are client dependent. Work with the Basis group prior to transporting variants, as the target client
on WRQ is client 399, and Basis will need to know what other clients you would like it to be copied to.
Program Documentation
You are required to create on-line program documentation for each of your ABAP programs (main
programs and includes) using the ABAP Editors program documentation facility. You should create
your documentation to be developer-oriented (as opposed to user-oriented), meaning that it should consist
of any technical information to support the understanding of the program.
During editing, you can organize your program documentation within certain standard sections. A
complete list of these section names can be found in table TTDTG. Each section consists of a VARNAME
(symbol name) field which is the name of the symbol that you would code in the documentation input
screen (delimited by &), and a VARVALUE (symbol value) field which is the text for the section that
appears when you display the program documentation on-line. When you enter the program maintenance
screen for your program the very first time, the following sections will appear:
VARNAME
DESCRIPTION
PRECONDITION
Last changed on:
2/3/2006 11:58:00 AM
VARVALUE
Description
Requirements
Last changed by:
u0092453
Notes
Description of the programs function. This should
consist of the program description entered as
comments in the source code immediately before the
REPORT statement.
Any prerequisites that must be met before this
File name:
Page:
35 of
65
OUTPUT
Output
EXAMPLE
Example
program can be executed.

Any output produced from this program - table
updates, reports, screens, etc.
Any examples of how this program might be used.
If any of the above sections will not be used to document the message, you may delete them from the
documentation. In addition to the above sections, you may add any other sections from the TTDTG table
as needed to further document the program.
REPORT/PROGRAM OUTPUT
This section defines the development standards for the following REPORT/PROGRAM output elements:
Selection Screens
Lists
Fonts
Selection Screens
This section describes all the development standards you are to follow when creating selection screens.
Within this documentation, the term screen field refers to each parameter or selection options field.
Within each of your custom-developed programs, you must format each selection screen to be
ergonomically consistent with other similar SAP screens. Ergonomic examples of SAP screens can be
displayed within the ABAP Workbench by going to the Repository Browser, menu selection
Environment/Ergonomic examples/Screens.
This section will cover the following selection screen elements:
Field Descriptions
Possible Values
Field Help
Field Descriptions
You must include an appropriate text description for each screen field. This description will be displayed
next to the input field. (See the Selection texts area of the Program Elements chapter of this section for
more information on screen field descriptions.)
Possible Values
If you are declaring a screen field that has a set number of possible values, you must display a possible
values box when the user places the cursor on the field. To accomplish this, you must code the screen
field association - LIKE for parameters, FOR for selection options - as one of the following:
A Data Dictionary field that points to Check Table.

A Data Dictionary field that points to a domain that has an associated values list. If an existing
domain does not provide these values, you may define a new Data Dictionary field and domain for this
screen field within the West Group Utility Structure in the Data Dictionary (need to create this).
An internal table field in which the table contains all possible values for the field (used in conjunction
with the ON VALUE REQUEST addition of the AT SELECTION SCREEN event). You would most
likely use this method if you only need a subset of table values for the possible values box.
See the Selection Screens chapter of the REPORT/PROGRAM OUTPUT section of this document for
more information on possible values boxes.
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
36 of
65
Field Help
You are required to make field help available for each screen field. To create help for a given field, you
must add appropriate text to the screen fields associated data element documentation in the Data
Dictionary. If the screen field does not have an associated data element in the Data Dictionary, you must
define a new Data Dictionary field and data element for this screen field within the West Group Utility
Structure in the Data Dictionary. See the Structures chapter of the DATA DICTIONARY
ELEMENTS section of this document for more information on the West Group Utility Structure.
Lists
You must format each custom list to be ergonomically consistent with other similar SAP lists. Ergonomic
examples of SAP lists can be displayed within the ABAP Workbench (Repository Browser > Environment
> Ergonomic examples > Lists).
This section will cover the following list elements:
Header
End of Report Line
Logos
Field Formats
Audit Reports
*** Place screen print of basic list here when time permits ***
Header
You must use the custom standard report header as opposed to the standard SAP report header within all
custom lists. Function Z_HEADER_ROUTINE prepares the necessary header fields for use within the list.
Refer to documentation for the function Z_HEADER_ROUTINE provided within the ABAP Workbench for
instructions on how to incorporate the custom standard report header into an ABAP program.
End of Report Line

You must print the standard End of Report line print as the last line of the report within all custom lists.
Function Z_HEADER_ROUTINE prepares this line for use within the list. Refer to documentation for the
function Z_HEADER_ROUTINE provided within the ABAP Workbench for instructions on how to
incorporate the End of Report line into an ABAP program.
Logos
You should not print any logos on any ABAP lists or SAPScript reports without first researching its affect
on performance.
Field Formats
The following sections describe the standard format to be used for certain standard data fields whenever
you display them on your custom lists.
Do we need field formats like the following examples??
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
37 of
65
Retail price
Two decimal places. Leading zeroes truncated up to the single dollar digit. Less than $1.00 shall contain a
zero as the single dollar digit.
Examples:
14.95
2.50
0.75
Retail price w/multiple units (e.g. 3 units for $1.00): Format 99/99.99. Leading zeroes in the units position
suppressed. Dollar amount shall follow the same standards as stated above.
Examples:
12/11.95
3/ 1.00
5/ 0.80
UPC
Always 11 digits. No dashes. Suppressed UPC's (7 digits) shall always be displayed in their full 11-digit
format.
Examples:
01234567890
31234567890
04100000105
Audit Reports
You are required to produce an audit report for each ABAP non-interactive program that does not generate
a user report. The audit report shall contain any vital information to indicate what transpired during a given
execution of the program. This information should include:
Record or table entry counts for all of the primary input and output files and tables.
Texts indicating exception records or table entries and why they were handled differently or bypassed
altogether.
Return code for the program (if applicable).
Any other vital statistics relevant to the programs execution.
The format of the audit report shall be ergonomically consistent with other similar SAP lists.
*** Place screen print of sample audit report here ***
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
38 of
65
Fonts
All SAP users (developers, configurors, end users) should set the Fonts user option (color palette in
upper right-hand corner of SAP screen) for both the fixed font and the variable font to a fixed font
(fixedsys). This font setting controls the font for all screens and displayed lists. Failure to set this to a
fixed font will cause your screen and report columns to be displayed out of alignment. This font does not
control the font for the printed lists. You should use the default font for the given printer when printing
lists. You should not change this printer font within the programs source code.
DATA DICTIONARY ELEMENTS

NOTE: AS OF 12/14/1999, the Basis group has assumed the development responsibility of all Data
Dictionary Objects. Basis needs to be involved in the functional design meetings, if possible, but must be
involved prior to functional signoff of any development request that requires DDIC work.
This section defines the development standards for the following ABAP Data Dictionary Elements:
Tables
Structures
Views
Field Names
Data Elements
Domains
Table Indexes
Lock Objects
Search Help
Type Groups
IDOC Segments
Tables
Table Elements Maintenance Approval Procedure
The following procedure must be followed before a table or elements of a table field (field, data element,
domain) may be added or updated:
If a developer feels there is a need to create a new table, or create or update a table field (fields, data
elements, domains, etc.) on an existing table, they must document their request and forward this
documentation to the DBA Representative for approval.
Once development is completed, the developer will walk through the applicable test cases with the
DBA Representative.
If approved by the DBA Representative, the table maintenance may now be transported to QA.
Naming convention:
Ztmmxxxxxx
where:
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
39 of
65
Constant required for user developed objects.
Type.
T = Table.
Application Module.
mm
(See Program Name naming convention for possible values.)

Any alphanumeric characters (max. 6).
xxs
Table Technical Settings Maintenance Approval Procedure

The following procedure must be followed before the technical settings of a table (logical storage
parameters, buffering, etc.) may be added or updated:
If a developer feels there is a need to create or update the technical settings of a table (logical storage
parameters, buffering, etc.), they must discuss their request with the Basis Representative, explaining
what they would like to change and why they feel it should be changed.
If approved by the Basis Representative, the Basis Representative will perform the requested
maintenance on the table. If denied, the Basis Representative will explain to the developers
satisfaction why the request was denied.
Note: Basis Representatives email group is S&AS BASIS.
Structures
Naming convention:
Ztmmxxxxxxxx
where:
Z
Type.
S = Structure.
mm
Application Module.
xxs
Any alphanumeric characters.
IDOC segments
***Need input from EDI team
Naming convention:
Z1Edsnn
where:
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
40 of
65
s.....................Segment Type.
K = Header.
D or P = Item.
S or T = Summary.
nn..................Sequential number.
West Group Utility Structure - ZUTILITY

The West Group Utility Structure ZUTILITY is a custom structure which stores custom table fields and
data elements created for the purpose of providing field help (F1) and field values for a possible values
boxes for Selection Screen fields that do not associate with any existing Data Dictionary data elements.
Each Selection Screen field is required to have field help and, if applicable, a possible values box
available which are defined at the data element level. If no current data element exists which can be
associated with the screen field, a new table field with this new data element must be created within the
West Group Utility Structure for use by this screen field.
Views
Do not put selection conditions directly in the database view. Selection conditions
should be in the where clause in the source code that selects from the view. (In this
way it is much clearer to a person looking at the program because there are no
'hidden' selection conditions. Verify that the view is bringing back exactly what you
expect it to.
A view allows an alternative way to retrieve data from a table or groups of tables. You can reduce the number of reads
in a program by defining a view that contains related data from several tables. A view is a logical table and is not
physically stored.
Naming convention:
Ztmmxxxxxxxx
where:
Z
Type.
V = View.
mm
Application Module.
xxs
Exception 1: Help Views are needed when F4 Possible Entries requires more than just the key values stored in a
table. Usually both the key values (e.g. codes) and the associated text is required. The view will contain both the
key and text fields. The naming standard for Help views is :
Format :
Where :
ZVTTTTTHFNN
ZV
Constant required for user developed objects
TTTT
Table name the view is help for
HF
Fixed Value
NN
Sequential number
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
41 of
65
Database
Projection
Help
Field names
XXX
Naming convention:
Each field name appended to a standard SAP table shall contain a standard prefix of zz. Each field
included in a custom table should contain no prefix. Where possible, name fields so the names are
understandable, except where using SAP pre-defined fields, use the SAP field names (ex. Do not change
sales document number to DOCNUM, use VBELN)
Data elements
XXX
Documentation
Documentation is required for every custom data element. This documentation is what will be displayed
when a user requests help (F1) for any Selection Screen field that is associated with this data element.
Note: Table THLPF is where the association is made between the documentation and the field/screen.
Naming convention:
Standard
Each data element name shall contain a standard prefix of z.
IDOC Need input from EDI team
ZEnnnnA
where:
nnnn..........4-digit field number per standard ANSI X12 (include leading zeroes).
Domains
Naming convention:
Zxxxlll_nnn
where:
Z..................Constant required for user developed objects.
xxx............Data element type.

CHR = Character.
DAT = Date.
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
42 of
65
DEC = Decimal.
INT = Integer.
lll............Length.
nnn............Sequential number.
Table Indexes
Table Index Maintenance Approval Procedure
The following procedure must be followed before a table index may be added or updated:
If a developer feels there is a need to create or update a table index, they must document this request,
including how they are planning to access the table, why they feel none of the existing table indexes
will work for this access, and the components of the new or updated index, and forward this request to
their Basis Representative for approval.
The Basis Representative will check the request and determine if testing of this index maintenance
should proceed in the Development environment. If approved, the Basis Representative will notify the
developer that testing on this index may proceed.
The developer will perform thorough tests for this particular access both before and after the index is
created or updated, document each of the test cases, and walk through this documentation with the
Basis Representative.
Once the Basis Representative OK's the test case documentation the index maintenance can then be
transported to QA.
Note: Basis Representatives email group is S&AS BASIS.
Lock objects
Lock objects control simultaneous access to a particular table by two update users by means of
locks which are set and released by calling a function module. The function module is
automatically generated when the lock object is activated. These function modules are known as
ENQUEUE and DEQUEUE.
Lock Objects :
Naming convention:
EZ aa ttttt LKnn
Where:
EZ...............Constant required for user developed objects.
aa.................Application type
ttttt..............Table name
LK...............Fixed value
nn................Sequential number
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
43 of
65
Search Help
Search help provides additional functionality to input help. The search help objects are part of the ABAP
Dictionary.
Search Help Objects :

Naming convention:
Z_SH_nnnnnn
Where:
Z_SH_.........Constant required for user developed objects.
nnnnnn.......Search help name (max. 25).
Type groups
XXX
FUNCTION GROUP ELEMENTS

Frequently used routines can be created as function modules. These are accessed by ABAP programs
through the CALL FUNCTION statement and may be shared across programs. Function modules are
contained within function groups. Technically speaking, a function group is a program with one Include file
for each function. When a function is called at runtime, its' function group is loaded into main memory and
the called function is executed. Following execution, the function group remains in memory and is
available to the main program of the current process. All functions in a function group share the same
forms. All functions in a function group share the same global data.
This section defines the development standards for the following ABAP Function Group Elements:
Function Groups
Function Modules
Documentation
Function groups
Naming convention:
zmmxxxxxx
where:
Z..................Constant required for user developed objects.
xxxxxx.....Any alphanumeric characters.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
44 of
65
Function modules
Unless indicated otherwise, the program elements permissible in the function module environment shall
conform to the same standards for program elements defined within this document.
Naming convention:
Standard
Each function module name shall contain a standard prefix of Z_MMSS_XXXX
Where:
Z
Constant required for user developed objects
Mm
Application Module (see program name naming convention for possible values)
Ss
Application SubModule (see program name naming convention for possible values)
xxx
Descriptive Text
IDOC Need input from EDI

Z_xmmyyypppp
where:
Z
Input/Output indicator.
Z = User-defined.
I = Input
O = Output
mm
Application Module
yyy
Logical Message Type

or
Descriptive text (for example: ORDER, INVOICE, etc.).
1-22 characters.
pppp
Process indicator.
MAKE = Create
EDIT = Change
VIEW = Display
PROC = Process
Documentation
Not yet defined.
MISCELLANEOUS DEVELOPMENT ELEMENTS

This section defines the development standards for the following miscellaneous ABAP development
elements:
Transactions
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
45 of
65
Logical Databases
SET/GET Parameters (Parameter IDs)
Area Menus
Message Classes
Jobs
PBO Modules
PAI Modules
Dialog Modules
Screens
Module Pools
Include Programs
Transactions
SAP Transaction Codes are defined in Table TSTC, user defined Transaction Codes are defined in
accordance with the following conventions.
Naming convention:
tmmxxxx
where:
t
Type.
Y = Transactions with security requirements applied at the transaction and/or field
level.
Z = Transactions without security requirements.
mm
Application Module.
xxxx
Logical databases
Logical Database
Naming convention:
zmmxxxx
where:
Z
mm
Application Module.
xxxx
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
46 of
65
SET/GET parameters (parameter IDs)

Naming convention:
Zxx
where:
xx
Unique identifier.
Example: ZCO (parameter ID for company code)
Area menus
XXX
PF keys
The lines 23 and 24 should be reserved for the SAP system when coding interactive reports. Line 24
will be used for PFKEYS display and line 23 for issuing dialog messages.
The standard SAP PFKEYS assignment shall be used when programming interactive reports. The
SAP system has default settings for these particular PFKEYS.
The SAP standard PFKEYS are listed below:

PFl
Help
PF2
Pickup, select
PF3
Back
PF4
Return
PF21
First Page
PF22
Previous Page
PF23
Next Page
PF24
Last Page
PFKEYS assigned to an ABAP report shall be done so with a PFKEYS status. The command
statement SET PF-STATUS 'wxyz' shall be used in the program to reference the correct PFKEY
assignments.
Text used in conjunction with the PFKEY definition, should conform where possible to the SAP
standards. (i.e. PF: n=description)
The most commonly used PFKEY selection shall be displayed as part of the screen Text.
To indicate the availability of more PFKEYS, the standard SAP text of '.....' will be used at the end of
the PFKEYS text line.
All PFKEYS will be documented in the PFKEY window, when defining the PF-status. This text will
be made available when the PFl key is pressed.
Message Classes
Check existing Message Classes before creating new messages to determine if a suitable message already exists.
If no suitable message exists, create a new message following these naming conventions:
Naming convention:
zmmss_nnnnnnnnnnnnnn
where:
Z
mm
Application Module.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
47 of
65
ss
Sub Module.
nnnnnnnn
Other.
Jobs
Job names
Naming convention:
Z_MM_SS_XXXXXXXXXXXXXXXXXXXXXXXX
where:
Z
MM
Constant for user defined job names.

Application Module.
SS
Sub-Module.
XXXX
Job name identifier/description.
Example: Z_SD_PO_PRICING_1
Event IDs
Naming convention:
t_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
where:
t
Type.
Y = Data conversions which are one-time loads, and example programs used for
demonstration.
Z = Applications and permanent interfaces.
xxxx
Event ID description.
Example: Z_START_DISPATCHER
PBO modules
Not yet defined.
PAI modules
Not yet defined.
Dialog modules
Not yet defined.
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
48 of
65
Screens
Not yet defined.
Module pools
Naming convention:
ZTTMZNNN
where:
Z
Constant for locally developed Module Pool.
TT
Application Module.

M
Constant indicating a Module Pool.
Constant indicating a custom object.
NNN
Sequential Number
Include programs
A Module Pool consists entirely of INCLUDE programs. Please name your INCLUDE programs according to
the following examples.
NOTE: The first 4 characters of the INCLUDE program name correspond to the last four characters of the
Module Pool name.
An I in the 5th position indicates that this is an INCLUDE program, the last 2 characters are incrementing
sequential numbers.
Data module
INCLUDE Z 0 0 1 A T O P
Data Definitions, Table Definitions,

and Global Data
PBO modules
INCLUDE Z 0 0 1 I O 0 1
O = Process Before Output module
INCLUDE Z 0 0 1 I O 0 2 etc., etc.
PAI modules
INCLUDE Z 0 0 1 I I 0 1
INCLUDE Z 0 0 1 I I 0 2 etc., etc.
I = Process After Input modules
Perform modules
INCLUDE Z 0 0 1 I F 0 1
F = Forms
INCLUDE Z 0 0 1 I F 0 2 etc., etc.
SCREEN PAINTER
The Screen Painter standards apply to those custom developments involving the creation of tables and
transactions.
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
49 of
65
Dynpro names will always be defined to the data dictionary.
Dynpro sequencing shall be controlled dynamically from within the module pool.
The SET SCREEN statement shall be coded for each possible logical path that can be taken in a
Dynpros PAI processing logic. This will make the transaction easier to read.
When developing Dynpros the PFKEYS and space bar should be used to make alterations to Dynpro
lines. A Dynpro can become corrupted if the normal keyboard delete and insert keys are used.
The commands 'INPUT and 'OUTPUT' will be defined with all respective PAI and PBO modules.
This will eliminate modules being incorrectly processed, as the SAP system assumes each module is a
PAI unless specified otherwise.
Example:
MODULE SET_SCRN_ATTR
OUTPUT.
MODULE PROCESS_PFKEYS_9000
INPUT.
The CHAIN command shall be used to group logical fields together before calling a module. This will
aid the end user in error corrections.
The processing logic command ON CHAIN INPUT and ON CHAIN REQUEST shall be used to
reduce redundant processing.
Example:
CHAIN.
FIELD LFAI-LIFNR.
MODULE CHECK_VENDOR_9000 ON CHAIN REQUEST.
ENDCHAIN.
When dialog messages are issued on a Screen Painter Dynpro that relate to an individual field, the
cursor shall by dynamically positioned on the field.
Example:
SET CURSOR FIELD 'LFAl-LIFNR'.
SET CURSOR 6 10.
(Standard)
(Non Standard)
The EXIT FROM STEP LOOP statement shall be used where premature termination of Dynpro loop
processing is required.
The naming standards regarding Dynpros and module pool shall be found in the document titled
'Naming Standards for SAP'.
Transactions that change the SAP databases shall check whether the desired record is free to be
changed. This check will ensure data integrity is maintained. The ENQUEUE / DEQUEUE statements
shall be used to individually lock data records.
For the purposes of this standard, a database update shall be any modification, deletion or insertion of
a database record or external table.
An update program, of type 'V', shall be written for any database or ATAB table updates. Within this
update program, there will be a FORM subroutine that, when executed, will perform the desired
database update.
It is recommended to not update any SAP database tables with a written program. Use the SAP
transactions to process transactions.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
50 of
65
BUSINESS OJBECTS
Objects created in the business object builder
Naming convention:
Object Type
Zmmxxxx max 10 characters
where:
Z
Constant required for user-developed objects.
mm
Application Module.
xx
Number or Name of the business object super type

(If no supertype exists then use the name of the main table for the object)
Example: ZSD2032 for the sub type of BUS2032

ZSDKNA1 for the sub type of KNA1
Object Name
Zxxxxx
where:
Z
Constant required for user-developed objects.
xx
Name of super business object

(If no supertype exists then use the business name of the object)
Example: ZsalesOrder for the sub type of SalesOrder

ZCustomer for the sub type of Customer
Name and Description
Xxxxx sub type
where:
Xx
Name of super type business object

(If no supertype exists then use the business name of the object)
sub type
Constant required for sub types of standard business objects
Example: Sales Order sub type for the sub type of Sales Order
Program Name
ZBO_xxxxx
where:
ZBO_
Constant required for custom business object programs.
xx
Name of the business object type.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
51 of
65
Example: ZBO_ZSD2032 for the object type ZSD2032
Methods
Methods created under a customer business object do not need to begin with Z, but instead should begin
with the present tense of a verb and then additional information. For example: Create, ListErrors, Edit,
DetermineMaterial, etc. Capitalize the beginning of each word and do not use spaces or underbars.
Events
Events created under a customer business object do not need to begin with Z, but instead should begin with
the past tense of a verb and then additional information. For example: Created, ChangedCredit,
DeletedBlock, DeterminedMaterial, etc. Capitalize the beginning of each word and do not use spaces or
underbars.
Attributes
Attributes created under a customer business object do not need to begin with Z. They should be named
the same as the field label for the referenced data element. Capitalize the beginning of each word and do
not use spaces or underbars.
BDC SESSIONS / CALL TRANSACTIONS

BDC Sessions
Batch Data Communication (BDC) sessions are used to execute batch input of SAP transactions.
Naming convention:
zttdddddddd9
where:
z
Constant for locally developed BDC Session.
tt
Application Module.

dddddddd Date created (YYYYMMDD).
Numeric for unique identifier (lowest sequential # available).
Call Transaction
Call Transaction provides superior performance over a BDC Session. Error logging is not as robust in Call
Transaction, and for this reason you must create a BDC Session if the Call Transaction fails.
SECURITY
This section defines the development standards for applying security to various ABAP development
elements. It will cover the following types of security:
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
52 of
65
Securing a program
Securing a transaction
Securing a program
1) This is how to secure a program that maintains a table:
authority-check object 'Z:ZXXMAINT'
id 'ACTVT' field '01'
id 'TABLE' field 'ZSCXR'.
if sy-subrc ne 0.
message e208 with 'You are not authorized to maintain this table'.
endif.
2) This how to secure all other sensitive programs
authority-check object 'Z:WEST_RPT'
id 'ACTVT' field '02'
id 'PROGRAM' field 'ZBASPRN1'.
if sy-subrc ne 0.
message i000(38) with 'No authority to change'
' the printer status'.
West Group Authorization objects:
Work with Basis Representative to create authorization objects.
Activities:
TACTT contains available activities. Most programs use the first three (1 = create, 2 = display, 3 =
display)
Securing a transaction
To secure a transaction you must fill in the field Authorization object with the value S_TCODE. The
transaction code must also be entered as the value for the object S_TCODE..
Enter tcode screen shot
EXTERNAL FILES
This section defines the development standards for the following external file elements used within ABAP:
Directories
Filenames
FTP
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
53 of
65
Directories
All files will reside in one of the following directories. Directory paths should always be lowercase.
The following directory structures will be used:
/sap/development/conversion
/sap/development/interfacein
/sap/development/interfaceout
/sap/development/temp
for input files transferred to UNIX for conversion purposes.

for input files currently on UNIX & output files that will stay on UNIX.
for output files to be eventually transferred out of UNIX.
for temporary input and output files not previously defined
The same directory paths above will be used, regardless of the SAP platform where the job is running
(Development, Quality Assurance, Production). UNIX will internally manage the separation of
Development, Quality Assurance, and Production data into unique subdirectories (i.e. If you access a
UNIX file within an SAP job that is run on the Development platform, UNIX will read from or write to an
internal Development subdirectory).
Filenames
Filenames must always be UPPERCASE. This naming convention applies to all inbound files. It applies
to only the outbound files in which there is no restriction for naming the file by the target application that
will use the file as input.
Naming convention:
mmbbufxxdd.zzz
where:
bb...............Application Submodule.
u.................Use.
f.................Intended Frequency.
xx...............Program name.
Name of the program that this file is related to (< 41 characters).
dd...............Duplicate (file dependant).
BU = Back up (when appropriate).
.zzz.............File extension.
TXT = Flat file.
Application Filenames
Not yet defined.
FTP Filenames
Not yet defined.
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
54 of
65
IDOCS
IDOC Type
Should be as close to the Basic IDOC Type as possible. In most cases it will be identical.
Basic IDOC Type

Not yet defined.
Extension Type
Not yet defined.
Non-EDI
Not yet defined.
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
55 of
65
FTP
XXX
APPENDIX
Useful Function Modules
BP_EVENT_RAISE - Trigger an event from ABAP/4 program.
BP_JOBLOG_READ - Fetch job log executions.
CLOSE_FORM - Closes layout set.
COMMIT_TEXT - To load long text into SAP.
DOWNLOAD - download a file to the presentation server (PC).
EDIT_TEXT_INLINE Edit SAPScript.
EPS_GET_DIRECTORY_LISTING - return a list of filenames from a local or network drive.
FILENAME_GET - popup to get a filename from a user, returns blank filename if user selects cancel.
G_SET_GET_ALL_VALUES - Fetch values from a set.
HOLIDAY_GET - Provides a table of all the holidays based upon a Factory Calendar &/ Holiday
Calendar.
INIT_TEXT - To load long text into SAP.
LIST_TO_ASCII - convert an ABAP report (displayed on screen) from OTF to ASCII format.
MONTH_NAMES_GET - It returns all the month and names in repective language.
MS_EXCEL_OLE_STANDARD_OLE - will build a file, and automatically start Excel.
OPEN_FORM - Opens layout set from an ABAP program.
POPUP_TO_CONFIRM_LOSS_OF_DATA - Create a dialog box in which you make a question
whether the user wishes to perform a processing step with loss of data.
POPUP_TO_CONFIRM_STEP - Create a dialog box in which you make a question whether the user
wishes to perform the step.
POPUP_TO_CONFIRM_WITH_MESSAGE - Create a dialog box in which you inform the user
about a specific decision point during an action.
POPUP_TO_CONFIRM_WITH_VALUE - Create a dialog box in which you make a question
whether the user wishes to perform a processing step with a particular object.
POPUP_TO_DECIDE - Provide user with several choices as radio buttons.
POPUP_TO_DECIDE_WITH_MESSAGE - Create a dialog box in which you inform the user about
a specific decision point via a diagnosis text.
POPUP_TO_DISPLAY_TEXT - Create a dialog box in which you display a two-line message.
POPUP_WITH_TABLE_DISPLAY - Provide a display of a table for user to select one, with the
value of the table line returned when selected.
READ_TEXT_INLINE Read SAPScript.
READ_TEXT - To load long text into SAP
RH_START_EXCEL_WITH_DATA -starts Excel with the contents of an internal table.
RP_CALC_DATE_IN_INTERVAL - Calculate date +/- year/month/day.
RS_SEND_MAIL_FOR_SPOOLLIST - Send message from ABAP/4 program to SAPoffice.
RS_REFRESH_FROM_SELECTOPTIONS - Get the current contents of selection screen.
RZL_SLEEP - Hang the current application from 1 to 5 seconds.
RZL_SUBMIT - Submit a remote report.
RZL_READ_DIR_LOCAL - Read a directory on the Application Server.
SAVE_TEXT - To load long text into SAP.
SCROLLING_IN_TABLE -If you are coding a module pool and using a table-control, you can use
this function SCROLLING_IN_TABLE to handle any scrolling.
Last changed on:
2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
56 of
65
SD_DATETIME_DIFFERENCE - Give the difference in Days and Time for 2 dates.

SO_SPOOL_READ - Fetch printer spool according to the spool number informed.
SO_SPOOL_READ - SAPoffice: Read a Spool Entry.
SO_WIND_SPOOL_LIST - Browse printer spool numbers according to user informed.
TH_POPUP - Display a popup system message on a specific users screen.
UNIT_CONVERSION_SIMPLE - convert weights from one UOM to another.
UPLOAD - upload a file to the presentation server (PC).
WRITE_FORM - Writes data to layout set by specifying a certain window.
WS_DOWNLOAD - Save Internal Table as File on the Presentation Server.
WS_EXCEL - Start EXCEL on the PC.
WS_EXECUTE - execute a program on a windows PC.
WS_FILE_DELETE - Delete File at the Frontend.
WS_FILENAME_GET - Call File Selector.
WS_MSG - Create a dialog box in which you display an one-line message.
WS_UPLOAD - Load Files from the Presentation Server to Internal ABAP Tables.
WS_VOLUME_GET - Get the label from a frontend device.
WWW_LIST_TO_HTML - After running a report, call this function to convert the list output to
HTML.
Useful ABAP Programs

RSPARAM
RSPROFIL
RSGENLDS
SAPMSOS0
RSDBST00
RSDBCATL
RSREGEN
TOUCHALL
SAPRSEUG
RSSCD100
RSSDOCTB
RSTBPROT
RSUBS042
RSBTCDEL
RSAVGL00
RSAQLGDB
RSDBTREE
RSBPSTDE
RSSNAPDL
RSDBCREO
RSPO0041
List default and active parameters in R/3.

List /sapmnt/<SID>/profile directory and allow editing of the profiles.
Regenerate ABAP loads.
Execute system level (e.g. UNIX) commands that use STDOUT.
Show logical databases.
List catalog of logical databases.
Regenerate all ABAP programs.
Reset all timestamps.
Regenerate all screen painter entries.
Change document log listing all documentation changes.
Table documents.
Table Protocol (SCU0).
Menu Fixes.
Remove batch job logs.
Table Compares.
Logical databases by application area.
Show logical databases.
Reorg job statistics (Monthly)
Reorg ABAP dumps. (Daily)
Reorg batch input jobs. (Daily)
Reorg the spool. (Daily)
Programs are contained in /sapmnt/<SID>/exe

Program
Function
Timing
sapevt
Kick off an event within SAP
On demand
rscoll00
SAP_COLLECTOR_FOR_PERFMONITOR
Hourly
rsbpcoll
SAP_COLLECTOR_FOR_JOBSTATISTIC
Daily
rsm13002
SAP_REORG_UPDATERECORDS
Daily
sappfpar
Display profile params and check consistency of shared
memory pool configurations
as<SID>adm, sappfpar check pf=/sapmnt/<SID>/profile/DVEBMGS00
sappfpar all pf=..... to list all parameters
Program
Class
Short description
_RCCLB101
_RCCLB102
_RCCTB101
_RCOPCA04
KLAS
KLAS
ATTR
Batch Input: Create classes

Batch Input: Create classification data
Batch Input: Create characteristics
CO-PCA: Generating standard reports in batch
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
57 of
65
_RCOPCA05
_RCPBI005
_RCPBI010
_RCPTRA00
_RCSBI010
_RDDUMF01
_RFBIBL00
_RFBIBL01
_RFBIBLG0
_RFBIDE00
_RFBIDEG0
_RFBIKR00
_RFBIKRG0
_RFBIPPG0
_RFBISA00
_RFBISAI0
_RFBITBTC
_RFBITF02
_RFEBBU01
_RFSTAX00
_RGCBDC10
_RGCREC10
_RGUDOCTY
_RGUREC00
_RHINTE30
_RIIBIP00
_RISTRA20
_RKABG000
_RKBIKA00
_RKCBINPT
_RKDBCOMM
_RKEIBDC1
_RKGAL000
_RKGALCO1
_RKIBI001
_RKIBI002
_RKIBI003
_RKKBBG00
_RKKBBR00
_RKKBBR01
_RKKKS000
_RKKP2B02
_RKKPZB02
_RKPBBG00
_RKSBBG00
_RKSBBGO0
_RKSJEX00
_RKSJIM00
_RKZUTG00
_RLBEST00
_RLBEST10
_RLBEST20
_RLMG0000
_RLMG0010
_RLMG0050
_RLMG0051
_RLMG0060
_RLPLAT00
_RLPLAT10
_RM06BBI0
_RM06BBIE
_RM06IBI0
_RM06IBI1
_RM06IBIA
_RM06IBIE
_RM06W005
_RM07IBDC
_RM07ICN1
_RM07IE31
Last changed on:
2/3/2006 11:58:00 AM
TEST
REOR
STUE
FBIP
FBIP
FBIP
FBIP
FBIP
FBIP
FBIP
FBIP
FBIP
FBTC
KORR
RFKB
RFKD
GBAS
PP0D
IBIP
IPMO
RKAG
RKCU
RKCE
KGAL
KGAL
RKEV
RKEV
RKEV
KKB1
KKB1
KKB1
RKKS
KKP
KKP
PRCO
RKRK
RKRK
RKRK
RKRK
RKZT
LTEC
LTEC
LTEC
LTEC
LTEC
LTEC
LTEC
LTEC
LTEC
LTEC
MEIN
MEIN
MBBC
MBBC
MBBC
Last changed by:
u0092453
CO-PCA: Generating standard reports in batch

Generate file for testing batch input of routings
Create routing via batch input
Test report for creating input file for batch input
Create BOMs via batch input
Control program for BATCH-SE02
Batch input documents
Batch input documents
FBIP Generating report: Batch input for documents
Batch input interface for customers
Generating report: Batch input for customer master
Batch input interface for vendors
Generating report: Batch input for vendor master d
Generating report: Batch input for preliminary pos
Batch input interface for G/L account master data
Subroutine pool for initializations of batch input s
Batch input routines for RFBITBXX
Batch input for RFBITB01
Test report: Submit batch job to post buffer data
Creating tax codes using batch input
Batch input
Batch update
RGUREC00 - Example for batch update
RGUREC00 - Example for batch update
Create batch input session for infotype P0001
PM: IBIP - Batch input utility
Maintenance plan date monitoring (batch input IPI0)
CO-CCA: Batch input processing for calc. of imputed cost
Create batch input session to create cost elements
Batch-input data transfer from file
Common_part RKDBATCH_RKXBATCH
Create line items: Create batch-input session from
Allocations: Report for batch start (General)
Allocations: Report for batch start (CO-CCA)
Batch input for cost/revenue transfers
Batch input for cost allocation
Batch input for statistical ratio input
Standard reports: Generate in batch
Costing: Batch request report for reporting
Generator for batch report
Batch processing: Variances/WIP orders
Batch processing: Calculating variances on cost ob
Batch processing: Overheads on cost objects
CO reports: Export reports (In batch)
CO reports: Export reports (In batch)
Batch generation archiving reports
Batch input for transferring stock data
Test data for batch input for data transfer with m
Test data for batch input for data transfer using
Batch input for taking over storage bin data
Test data for batch input for init. entry of stck. b
Batch input for transferring storage bins
Batch input test data for transferring storage bin
Batch input for purchase requistions from another
Create sequential dataset for batch input: Purchasing
Batch input for purchasing info record
Framework for batch input generation: Purchasing I
Listing of sequential dataset for batch input: Inf
Create sequential dataset for batch input: Info re
Generate source list (Batch)
Batch input: Create physical inventory docs. for c
Batch input: Create phys. inv. docs. for cycle cou
Batch input: Create phys. invetory docs for sales
File name:
Page:
58 of
65
_RM07II31
_RM07II32
_RM07II34
_RM07II37
_RM07II38
_RM07II39
_RM07II40
_RM07IK31
_RM07IO31
_RM07IV31
_RM07IVW1
_RM07IW31
_RM07MCHV
_RM07MCHW
_RM07MMBL
_RM07RRES
_RM07SVOR
_RMCVNENL
_RMM60TOP
_RMMM60BI
_RMMMBIM0
_RMMMBIMG
_RMMMBIMI
_RMMMBIMJ
_RMMMBPBI
_RMMPS000
_RMMR2100
_RMMRP000
_RMNIWEBI
_RMSTRA20
_RPBEBA00
_RPCIPO15
_RPIBRT00
_RPICMP01
_RPICMP02
_RPICMP03
_RPICMP05
_RPIJSTD0
_RPIKUGD0
_RPILSKA0
_RPISVRD0
_RPTLEA30
_RPTUPD00
_RPWI0000
_RQEAAS10
MBBC
MBBC
MBBC
MBBC
MBBC
MBBC
MBBC
MBBC
MBBC
MBBC
MBBC
MBBC
MBMB
MBMB
MBBC
MBBC
MBBC
MCV
MDPB
MMBC
MMBC
MMBC
MMBC
MDPB
MD03
BPLA
NIWE
IPM0
PB00
PC00
PINP
PM0I
PM0I
PM0I
PM0I
PCD2
PCD3
PCA0
PBAS
PT0I
PT00
PW00
QRLP
Batch input: Create phys. inv. docs. for normal st

Batch input: Block material for physical inventory
Batch input: Enter count results with reference to
Batch input: Post differences
Batch input: Enter count w. ref. to doc. post dif
Batch input: Enter count w/o reference to document
Batch input: Enter count w/o ref. to doc. post di
Batch input: Create phys. inventory docs. for vend
Batch input: Create phys. inventory docs. for mat
Batch input: Create phys. inv. docs for ret. packa
Batch input: Create phys. inventory docs. for vend
Batch input: Create phys. inv. docs. for consignme
Display batch where-used list
Build up batch where-used list
Batch input: Post material document
Batch input: Create reservation
Batch input: Inventory sampling
Read number of next delivery that will be batch-up
Include for general data structures for batch inpu
Independent requirements batch input
Create batch input session: Create/Change material
Generation program: Batch input for Create/Change
Initialize batch input structures
Initialize batch input structure with predefined c
Create a seq. file for the batch input independen
Batch main program for MPS
Create batch input for price change to future pric
BATCH structure for MRP run
Batch input routines for lowest value determination
Maintenance plan date monitoring (Batch input IP10)
Batch processor statements
INCLUDE for RPCIPO00/RPCIPI00 - Store batch input
Batch input to evaluate personnel reviews
Data definitions for batch input to compensation s
Main program for batch input to compensation syste
Forms for batch input to compensation system
Batch input P0008
Batch input for creating new tax records at beginn
Batch input for KUG/SWG
Creating wage tax papers at end of year with batch
Batch input for changing maximum HI gross amount
Batch input: Annual leave
New valuation of absence records using batch input
Batch input to incentive wages
List of all batches for a material
END OF DOCUMENT
Last changed on:

2/3/2006 11:58:00 AM
Last changed by:

u0092453
File name:
Page:
59 of
65

ABAP Standards PDF

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ABAP Standards PDF

Caricato da

Copyright:

Formati disponibili

SAP ABAP

Last changed on:

Last changed by:

ABAP Development Standards

How to Find the Latest Version of This Document

Last changed on:

Added Application Module LO- Logistics General. Added Application

Added standards for business object methods and attributes

Last changed by:

Last changed by:

Last changed by:

Lock Objects :.....................................................................................................................................43

Last changed by:

Last changed on:

Last changed by:

Establish naming conventions, which will assist in identifying SAP objects.

Supplemental Development Materials

Last changed on:

Last changed by:

A Standard. You must adhere to the standard in every case. No exceptions.

Last changed by:

Last changed by:

Personnel Management Submodules.

Open. May be used to add descriptive text to program name.

Last changed on:

Last changed by:

Subscription Maintenance (Add, lapse, transfer, etc.)

Warehouse management, deliveries, RF, etc.

Last changed on:

Last changed by:

Business Warehouse extractors

Customer Self Service

Fixed point arithmetic

Within all programs, you should use structured coding techniques.

Last changed on:

Last changed by:

" Change pointer

value ' ',

Non-standard (DO NOT USE!):

value ' '.

Last changed on:

Last changed by:

move gt_sites-vtweg to g_vtweg.

You should use blank lines whenever necessary to enhance readability.

Last changed on:

Last changed by:

Is the program using SELECT * statements?

Are CHECK statements for table fields embedded in a SELECTENDSELECT loop?

Do SELECTs on non-key fields use an appropriate DB index or is the table buffered?

Is the program using nested SELECTs to retrieve data?

Last changed on:

Last changed by:

Is the program using SELECT ORDER BY statements?

Last changed by:

Start the TABLES keyword in column 1.

Last changed on:

Last changed by:

Start the TYPES keyword in column 1.

Last changed by:

Start the PARAMETERS keyword in column 1 unless it is subordinate to a SELECTION-SCREEN

Last changed by:

When declaring individual work fields, you must: