ABAP CODING STANDARDS

SATYAM COMPUTER SERVICES LIMITED

 SCSL REF. ABAPSTD /2.0
Quality Procedures ABAP CODING STANDARDS W.E.F
Manual PAGE 2 of 17

Table of Contents

Topic Page No.

PURPOSE......................................................................................................................................................................3
SCOPE..........................................................................................................................................................................3
REFERENCES (OPTIONAL)............................................................................................................................................3
ACRONYMS..................................................................................................................................................................3
1.1 NAMING CONVENTIONS..................................................................................................................................3
The 8-character ABAP names will conform to the formats given below:..............................................................3
Position 1:..............................................................................................................................................................3
Position 2:..............................................................................................................................................................4
Position 3-4............................................................................................................................................................6
1.1.1 Exceptions to the rule.............................................................................................................................6
1.1.2 Warning..................................................................................................................................................6
1.2 ABAP4 - ATTRIBUTES.....................................................................................................................................7
Title:........................................................................................................................................................................7
Type:.......................................................................................................................................................................7
Status:.....................................................................................................................................................................7
Application:............................................................................................................................................................7
Authorization Group:..............................................................................................................................................7
Logical Databases:.................................................................................................................................................7
Fixed point arithmetic:...........................................................................................................................................7
1.3 CODING FEATURES..........................................................................................................................................7
1.3.1 Sequence.................................................................................................................................................8
1.3.2 Indenting...............................................................................................................................................10
1.3.3 Spacing..................................................................................................................................................11
1.3.4 Paragraphing........................................................................................................................................11
1.3.5 Variable naming....................................................................................................................................11
1.3.6 Commenting..........................................................................................................................................12
NOTE:...................................................................................................................................................................12
1.4 LAYOUTS.......................................................................................................................................................14
1.4.1 Selection Screens..................................................................................................................................14
1.4.2 Reports..................................................................................................................................................14
1.5 MODIFICATIONS.............................................................................................................................................14
1.5.1 Standard SAP repairs (OSS Repairs)...................................................................................................14
1.5.2 Approved Repairs (Changes/Repairs)..................................................................................................14
1.5.3 Modifications to Copies of Standard SAP ABAPs................................................................................14
IN ORDER TO PICK UP THE EXACT PURPOSE OF THE CHANGE QUICKLY, THE CORRECTION OR TASK DESCRIPTION
SHOULD BE VERY CONCISE AND ACCURATE..............................................................................................................15
1.6 DIRECT UPDATES...........................................................................................................................................16
1.6.1 Locking a database table for: Update, Modify, and Delete.................................................................16
Single Record Lock:..............................................................................................................................................16
1.6.2 Multiple Record Lock:..........................................................................................................................16
1.7 DOCUMENTATION..........................................................................................................................................17
NOTE:........................................................................................................................................................................17
1.8 QUALITY CONTROL GUIDELINES..................................................................................................................17
Purpose This document is a compendium of conventions and practices that can be gainfully used
while coding in ABAP

Scope The team members will use this standard during the construction phase. It covers

References Nil
(Optional)

Acronyms ABAP Advanced Business Application Programming

BDC Batch Data Communication
OSS Online SAP service

1.1 Naming Conventions

There are several reasons for defining development standards. If a common style
is used, obviously reviews and maintenance will be more efficient. It also shows a
professional approach to development. Another reason is that it indicates Quality
awareness.
This document is a standard for the development and maintenance of ABAPs that
deal with Reporting, Batch Data Capture sessions, Uploads and Downloads in the
R3 environment.
The following naming conventions apply for all ABAPs.
We follow the 8 character ABAP names.

The 8-character ABAP names will conform to the formats given below:
Position 1:
All characters except ‘Y’ and ‘Z’ are reserved for SAP.
Y - Denotes a SAP ABAP, which has been copied and modified. All
original SAP code must remain in place commented out if appropriate.
Positions 3 - 8 of the ABAP name remain as the SAP original. These will
be referred to as Y-ABAPs.
Copies of original SAP ABAPs must remain Y-ABAP’s in the following
situations.
 If the changes to the standard SAP code will have to be applied again
after each upgrade.
 If the ABAP is called automatically by another standard SAP ABAP
or transaction.
Z – Denotes programs, either written from scratch or based on a SAP
original without the original code being retained. (This may be done if
the changes become significantly large. As a guide, if more than a quarter
of the original code lines is changed, a new Z-ABAP is desirable).
Position 2:
For Y-ABAPs
Position 2 is only changed from the original SAP ABAPs name, in a SAP
system, which contains multiple Development Groups. This position
indicates the ABAPs ‘owner’. A single character or number will
represent the Development Group.

For Z-ABAPs
Following represents the SAP Application (as per SAP ABAPs).
A Assets Accounting
C PPC (Production Planning and Control)
F Financial Accounting
H Human Resources Planning
I Maintenance
K Cost Accounting
L Warehouse Management
M Materials Management
N Hospital
P Human Resources
S System
V Sales
X This has been allocated to SAP enhancements – e.g. user exits
etc.
In cases where some ambiguity may be present, such as in ABAPs
dealing with one of the Cycles where strict Application boundaries are
crossed, the application letter used should represent the primary use of
the ABAP.

Position 3: (Position 3 - 8 affect Z-ABAPs only)

This position can be used in 2 different ways.
In the case of a SAP system, which contains only a single company, this
position indicates the ABAPs main purpose (Read/Update).
R Read Only (Report Programs)
I Include ABAP
M Module Pool ABAP
S Generating a BDC session
E External Data transfer
T User Defined Table Update
U Other Update
P PC Upload/Download
In the case of a SAP system, which contains multiple companies and
clients, this position indicates the ABAPs ‘owner’. A single character or
number will represent the company.
If the ABAP is not Development Group specific, the 3rd character must
contain a ‘0’ to indicate it is a Central Development Group program.
Positions 4 - 6:
Classification: This should contain characters 2 - 4 from the program
classification on the attribute screen. For a list of ABAP classes, refer
tables TRCL (available as part of the product for all releases of SAP
above 3.0) and TRCLT (available as part of the product for all releases of
SAP above 3.0).
The program class must start with a ‘Z’. If the description for the
program class starts with a ‘*’, then the program class must no longer be
used.
If no suitable program class exists, please speak to your system
administrator.

Positions 7 - 8: Sequence Number

For ABAPs with a reasonably close similarity, the sequence number
should be incremented by 1. For ABAPs with a more significant
variation increments of 10 should be used.
It is recognized that it will not always be possible to conform strictly to
this method. But there are advantages to be gained from grouping
ABAPs in this way, within the broader classification given by positions 4
- 6.Workbench Organizer / Correction and Transport
Naming for development classes is as follows:
Position 1: ALWAYS a ‘Z’
Position 2: Represents the SAP application (as per SAP ABAPs).
A Assets Accounting
C PPC (Production Planning and Control)
F Financial Accounting
H Human Resources Planning
 I Maintenance
K Cost Accounting
L Warehouse Management
M Materials Management
N Hospital
P Human Resources
S System
V Sales
X where a large development is required
Y where a large development is required
Z where a large development is required
Position 3-4
Development Group numbers or the characters to represent the sub
module relevant to the development
1.1.1 Exceptions to If position 2-3 is ‘SU’, this is a development class to be used for upgrades.
the rule
1.1.2 Warning No ABAP should be created under development class $TMP i.e. as Local Private
Objects.
Development Classes can be found in table TDEVC (available as part of the product and
referred during coding). If the development class description starts with a ‘*’, then the
development class must not be used. If your required development class does not exist on
your system, please speak to your system administrator.
1.2 ABAP4 -Title:
Attributes The title of the report should make it easily identifiable. It should be concise. The
title must also reflect the main purpose of the ABAP.
Type:
1 On-line program
J Job report
I Include Program
M Module Pool for screen painter screens
V Update program
F Function module

S External Routine
Status:
This should contain a ‘T’ (Test program) while the program is being developed,
and a ‘K’ (Customer production program) once testing of the program is
complete.
Application:
Application must be entered. (For a list of applications please refer to possible
entries on-line). Must match the second character of the program name.
Authorization Group:
A list of valid authorizations groups can be found in program ZSAUTH (for all
SAP releases before 3.0) and in table TPGP (for all SAP releases after 3.0).
This field is mandatory in the following cases: -
 If a logical database is not being used for the primary source of data.
 If specific authorization checks on the primary source of data are not done in
the ABAP.
Logical Databases:
Logical databases are optional.
It is not mandatory for the application of the logical database to match the
application of the ABAP.
Fixed point arithmetic:
When fixed-point arithmetic is switched on, all calculations are performed using fixed-
point arithmetic. The default is set to ‘on’ (This is especially useful when dealing with
floating point numbers).

1.3 Coding Features

1.3.1 Sequence In order to make all ABAPs easy to read and understand by other programmers in
a support environment, a specific coding sequence should be followed. This is a
guideline only and must be followed as long as it is logical to do so.
Please use program ZSABAP for a more accurate and detailed example.

Generally the sequence is as follows:

REPORT XXXXXXXX
LINE-COUNT
PAGE-COUNT
MESSAGE-ID
NO STANDARD PAGE HEADING.
*-------- DATA DECLARATION
-----------------------------------------------------*
INCLUDE xxxxxxx. “ Briefly write what is contained in the
include
TABLES: xxxx, “ Briefly write what the table is.
xxxx.
DATA: xxxxxxxx,
xxxxxxxx.
FIELD-GROUPS: HEADER,
xxxxxxxx.
INSERT xxxxxxxx
xxxxxxxx INTO HEADER.
FIELD-SYMBOLS: xxxxxxxx.
RANGES: xxxxxxxx.
SELECT-OPTIONS: xxxxx,
xxxx.
PARAMETERS: xxxxxxxx,
xxxxxx.
*-------- INITIALIZATION
-----------------------------------------------------------*
Setup parameters and selection defaults etc.
*-------- START OF SELECTION
--------------------------------------------------*
START-OF-SELECTION.
Check input.
GET xx.
GET yy.
GET xx LATE.
SELECT * FROM xyz.
.......
ENDSELECT.
EXTRACT HEADER.
END-OF-SELECTION.
*-------- END OF SELECTION
------------------------------------------------------------*
*-------- SORT AND LOOP PHASE
-----------------------------------------------------*
Sort Field-Groups and/or Tables.
LOOP.
AT NEW xxxxxx.
......
ENDAT.
AT END OF xxxxxx.
......
ENDAT.
ENDLOOP.
AT PFxx.
......
AT USER-COMMAND.
......
*-------- FOOTER
------------------------------------------------------------------------*
 *-------- SUBROUTINES
------------------------------------------------------------------*
FORM abc using xyz
pqr.
......
ENDFORM.
*-------- TOP-OF-PAGE
-------------------------------------------------------------------*
TOP-OF-PAGE.

1.3.2 Indenting All ABAPs must be neatly indented. The standard indent applied by Pretty Print is 2
positions. Statements should be indented and aligned, as it makes reading the ABAP
much easier. For example:
TABLES: VBAK, “ Comment
VBAP.
WRITE: /01(05) xx-xxxx, “ Comment
10(08) xx-yyyy,
xx-zzzz DD/MM/YY.
Not
TABLES: VBAK, VBAP.
WRITE: /1(5) xx-xxxx, 10(8) xx-yyyy, xx-zzzz DD/MM/YY.
1.3.3 Spacing Please leave blank lines between coding structures, or clearly definable coding
blocks.
For example.
IF . . . . . .
MOVE . . . . .
ENDIF.
*------------ Check For ......... -----------------------------------------------------------*
IF . . . . . .
PERFORM . . . . . .
ENDIF.
*EJECT
1.3.4 Paragraphing Ideally no consecutive piece of code should extend to more than 50 lines or so.
Elements of the code should be split into FORMs so that they become
manageable. Putting common pieces of code in FORM routines is also
recommended.
1.3.5 Variable When naming the variables, Internal tables, Parameters and Select options do
naming follow the following naming:
Variables V_XXXXXXXX…..
Internal tables I_XXXX.._XXXX
Parameters P_XXXXXX
Select options SO_XXXXX or S_XXXXXX
The Internal table if similar to a Database table shall preferably contain the name
of the DB table.
Always use variable names that correspond to SAP Data Dictionary naming. This
carries the advantages of often being self-defining, and of being consistent and
recognizable.
For example:
DATA: BUKRS,
xxxx_BUKRS,
BUKRS_xxxx.
For record or internal table definition:
DATA: BEGIN OF rrrrrr,
BUKRS LIKE xx-BUKRS,
 WERKS LIKE xx-WERKS,
MATNR LIKE xx-MATNR,
END OF rrrrrr.
BEGIN OF tttttt occurs nn,
xxxxxx LIKE xx-xxxxxx,
END OF tttttt.
As a general rule, keep names as short as possible, it reduces effort and helps to
avoid mistakes. Avoid using names containing a hyphen (‘-’) as the may appear
like table or database fields. The use of ‘like’ when defining a field is to be used
when possible. This will avoid problems at upgrade time.
If a DATA structure is to be used in many ABAPS, then create a structure in the
Data Dictionary.
When creating multiple variables, group fields with similar purposes together, for
example all Total fields could be coded together in one area.
1.3.6 Commenting Internal ABAP commenting is critical for ease of maintenance and for general
comprehension. It is a good practice to explain all working storage defined by
TABLES, SELECT-OPTIONS and PARAMETERS. Particular care should be
taken to explain the purpose of records and internal tables.
Comment blocks in the standard format are expected for the following structures.
REPORT, FORM . . ENDFORM, MODULE . . ENDMODULE
The report standard comment block must include the following information.
 The notifications ‘UPDATE = Y/N’ and ‘BDC = Y/N’ using either ‘Y’ or ‘N’
as appropriate.
 A brief description of the output produced by the ABAP
 A brief description of the purpose of the ABAP.
 Details of any special peculiarities in the coding.
 The name of the author and the month/year it was written.
 See ABAP ZSABAP for an example of a header block.
If a control structure is complex or large, then a comment block should be
included giving an explanation.
NOTE:
Pretty print will try to put all double inverted commas for comments in column 40.
If this is impossible because of the line length, it will increment the column
number in 5s.
1.4 Layouts
1.4.1 Selection These must follow SAP standards. All input fields must be left aligned with
Screens descriptions entered in a combination of lower and uppercase. No lines are to be
skipped between parameters and select-options unless a logical grouping of
parameters can be formed. All parameters and select-options must be assigned a
memory-id if one exists. Selection texts must be taken from the data dictionary
wherever possible (The texts are found on the data element). ‘Possible entries’
must be available wherever possible.
Memory-id’s can be picked up off the data element screen.
1.4.2 Reports Standard page headings and footers must be used. Column headings should follow
the same alignment as the field being represented, example, quantity fields must
have a heading that is right aligned.
All parameters entered on the selection screen should be displayed in the headings
of the report, example if a specific plant is called for, then the headings must
reflect which plant was selected.
The sequence of the fields from top to bottom and left to right should indicate the
sort sequence, as far as logically possible.
1.5 Modifications
1.5.1 Standard SAP Place a modification comment block at the top of the ABAP. If more than one
repairs (OSS Repairs) modification has been made, the latest change should be at the top. In the body of the
ABAP, any line no longer required must be commented out (with an asterisk (‘*’) in
column 1), NOT deleted. A line needing to be changed must also be commented out, the
new, modified line following it immediately.
The comment block must include the OSS number, the name of the person making
the modification and the date. All the altered lines, including lines commented out
must contain the OSS note number on the far right hand side of the line
(OSS99999).
(This is required to assist in upgrades). The description of the repair MUST be "OSS
Note xxxxx - Your Name - Description of Fix", e.g.: "OSS Note 42225 - Nico -
Itemization Display in prod. Order". If this convention is not followed, then the fixes
will be lost after an upgrade.
1.5.2 Approved The comment block must include the Repair number, the name of the person
Repairs making the modification and the date. All the altered lines, including the lines
(Changes/Repairs) commented out must contain the Repair number on the far right hand side of the
line.
The change MUST then be documented in the repair documentation.
1.5.3 Modifications toAs a general principle, if a standard SAP ABAP is to be modified, create a copy
Copies of Standard (using ‘Yxxxxxxx’ for the ABAP name) and modify the copied version only.
SAP ABAPs
Place a modification comment block at the top of the ABAP. If more than one
modification has been made, the latest change should be at the top. The comment
block must include the name of the person making the modification and the date
as well as the modification id (the modification id consists of the author(s) initials
and the date, in the format IIDDMMYY). The original name of the SAP ABAP
must be specified to aid in identification should this be necessary.
In the body of the ABAP, any line no longer required must be commented out
(with an asterisk (‘*’) in column 1), NOT deleted. A line needing to be changed
must also be commented out, the new, modified line following it immediately. All
the altered lines, including lines commented out must contain the modification id
on the far right hand side of the line. This is required to assist in upgrades.
Version management cannot be relied upon for the following reasons: -
 Version management will only keep the changes made from the first time the
new modified ABAP is copied to production. I.e. the first lines of code
changed would not be recorded.
 Before release 3.0d, it is not possible to copy a single client from one R3
system to another. Therefore when a copy of a client from production to
development is required, the entire system must be copied. In this process
record of versions may be lost. Whenever this copy process happens the
versions will be lost.
It is not necessary to comment each individual line that is changed in the program
so long as a detailed description of the change is provided in the REPORT
comment block and other comments and documentation for the ABAP are updated
to reflect the change.
 If extensive changes are being made to the program, more detailed comments in
the body of the ABAP will be required.
In order to pick up the exact purpose of the change quickly, the correction or task
description should be very concise and accurate.

1.6 Direct Updates

Most SAP standard databases and tables can be updated by the use of a
transaction, and in this case, a BDC program or ‘CALL TRANSACTION’
program must be written.
1.6.1 Locking a
database table for: Single Record Lock:
Update, Modify, and To lock a single record the following statement can be used.
Delete.
Select single for update * from <table>.
A commit work statement releases the record after the update is complete. It
should be noted that all database locks are released at the next database commit or
rollback.
For example when a program is run in debug mode, an automatic release is
initiated.
Example: Select single for update * from zvpro.
Update zvpro set: datum = last_date
Uzeit = last_time.
Commit work.
1.6.2 Multiple RecordIn the case of a multiple record lock, the SAP generated function modules must be used.
Lock: The module generation is initiated by selecting ’database table lock’ in the data
dictionary. Two function modules are generated, namely ENQUEUE_obj and
DEQUEUE_obj. These function modules are then used to lock and unlock the selected
records of the table
1.7 Documentation
You should document the purpose and use of the ABAP. This is the Primary source
of information for the end user of the ABAP and should contain a good description
of the function of the ABAP. Important points should also be noted.
Parameters and select-options that have been defined by the ABAP must be
described. The user should be able to determine exactly the effect on the ABAP of
all select-options and parameter entries. Be particularly careful to explain which
values may be entered.
Sort Sequence, and the conditions specified if more than one sort sequence is
possible, should be listed and explained.
A list of what output can be expected is also very useful. Typically this might
include a list of all columns and a description of any abbreviations in the output
that may be ambiguous. It is also a good place to put details of any formulae,
calculations, special processing rules etc. which may assist the user.
A short note detailing the source of data should also be provided.
Note:
Please Note (Only applies to SAP rel. 3.0) that ABAP documentation must be
activated before it can be copied to production. To do this, from program
documentation, select Document -> Save -> Active version.

1.8 Quality Control Guidelines

All of the above standards will be checked for any ABAP submitted for copying to
production.
All ABAP developments must be given to a group of the developers assigned to
Quality Control before requesting a copy to production. (This includes new
ABAPs being written, as well as modifications to existing ABAPs).
The original specification, log track form, change request form, and test results are
verified and recorded.