=======================================================================================
=
Page 1 of 37
Development Standards
=======================================================================================
=
TABLE OF CONTENT
1.
SECTION SUMMARY......................................................................................................................................4
1.1
1.2
1.3
2.
OBJECTIVES.............................................................................................................................................. 4
SCOPE....................................................................................................................................................... 4
SUMMARY................................................................................................................................................. 4
DOCUMENTATION..........................................................................................................................................5
2.1
2.2
3.
TRANSPORT STRATEGY...............................................................................................................................9
4.
NAMING CONVENTIONS.............................................................................................................................10
4.1 IN GENERAL....................................................................................................................................................10
4.2 DEVELOPMENT OBJECTS.................................................................................................................................10
4.3 VARIABLE USE AND NAMING CONVENTIONS.................................................................................................15
4.3.1
Overall requirements:..........................................................................................................................15
4.3.2
Global Definitions:..............................................................................................................................15
5.
6.
GENERAL STANDARDS............................................................................................................................. 17
ERROR HANDLING..........................................................................................................................................18
USER EXITS/BADIS/ENHANCEMENT POINTS (UBE)...............................................................................18
AUTHORIZATION CHECKS........................................................................................................................ 19
TABLES................................................................................................................................................... 19
REPORT PROGRAMS................................................................................................................................. 19
FILE ACCESS...................................................................................................................................................20
GUI STATUS............................................................................................................................................ 20
READABILITY.......................................................................................................................................... 21
COMMIT WORK AND ROLLBACK WORK............................................................................................... 21
DESCRIBE........................................................................................................................................... 21
FREE.................................................................................................................................................. 21
SINGLE VALUE STORAGE..................................................................................................................... 21
CHECKING FOR MULTIPLE EXECUTIONS OF A PROGRAM.......................................................................22
NUMBER RANGES............................................................................................................................... 22
DATES ON FORMS............................................................................................................................... 22
MESSAGES.......................................................................................................................................... 22
PERFORMANCE.............................................................................................................................................24
6.1 DATABASE PERFORMANCE....................................................................................................................... 24
6.1.1
EXEC SQL statements are not allowed, Ever......................................................................................24
6.1.2
Logical Databases or not to be used...................................................................................................24
6.1.3
Fields in a select vs. select *...............................................................................................................24
6.1.4
Select into table............................................................................................................................24
6.1.5
Joins.....................................................................................................................................................24
6.1.6
Smaller, static tables............................................................................................................................24
6.1.7
..for all entries.....................................................................................................................................24
6.1.8
Keys and Index.....................................................................................................................................24
6.1.9
Defining new alternate indexes...........................................................................................................25
6.1.10
Nested Select statements.................................................................................................................25
6.1.11
Sort By.........................................................................................................................................25
6.2 ABAP PERFORMANCE.....................................................................................................................................25
6.2.1
Internal Tables.....................................................................................................................................25
Page 2 of 37
Development Standards
=======================================================================================
=
6.2.2
BDC Sessions/Call transaction...........................................................................................................25
6.2.3
Conditions............................................................................................................................................25
6.2.4
Field Assignment..................................................................................................................................25
6.2.5
Check Statement...................................................................................................................................26
6.2.6
Dead Code...........................................................................................................................................26
6.2.7
Commented Code.................................................................................................................................26
7.
DOCUMENTATION........................................................................................................................................27
7.1 CODE DOCUMENTATION..................................................................................................................................27
7.1.1
Constants and Variables.......................................................................................................................27
7.1.2
Form Routines......................................................................................................................................27
7.1.3
Revision History...................................................................................................................................27
7.2 APPLICATION DEVELOPMENT PROJECT DOCUMENTATION..........................................................................28
7.2.1
Review Documentation........................................................................................................................28
7.2.2
Unit Testing..........................................................................................................................................28
7.2.2.1
7.2.3
Page 3 of 37
Overview........................................................................................................................................................ 28
Development Standards
=======================================================================================
=
1.
Section Summary
1.1 Objectives
The purpose of this document is to articulate a common set of standards and procedures for the naming,
development, and documentation of custom ABAP solutions in SAP with the goal of maximizing the quality,
value, and maintainability of the custom solution. This document is intended for to be used by everyone that will
be doing development in the SAP ABAP environment.
1.2 Scope
Documentation requirements.
1.3 Summary
These development standards have been created to promote clear, efficient and maintainable ABAP
development objects. These standards are to be followed by all developers and require adherence before an
object can be moved into a productive environment. The standards have very specific requirements that must
be followed as well as general guidance in how something should be developed. Where something is not
explicitly specified, the same general principle of these standards should be used to make a decision on what
path to take.
The standards are intended to form the basic foundation for development in ABAP and is intended to make
development objects consistent, efficient, and well documented. The Naming Standards are used for better
object administration and faster location of objects. The naming conventions used here are only relevant for the
SAP System and do not necessarily apply to any other systems or applications.
Page 4 of 37
Development Standards
=======================================================================================
=
2.
Documentation.
Functional Specification
Technical Specification
This is, however, not a definitive list, and any other documentation which will assist in maintaining the program
should also be included.
The templates for Functional Specifications, Technical Specifications, and Unit Test Plans are not included in this
document.
Page 5 of 37
Development Standards
=======================================================================================
=
*& mm/dd/yyyy Xxxxxxxxxx
XXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXX*
*&---------------------------------------------------------------------*
Program Description:
The program Description should be meaningful and include the Development Object Number in the title
if one exists.
Documentation Option
Program documentation option in ABAP library should be used to provide documentation on the
functionality of the object. For Programs, use the following documentation.
The Purpose section of the text object needs to be entered with a clear description of the program
and what it does
When there is a selection screen; selection screen fields needs to be documented in the program.
Page 6 of 37
Development Standards
=======================================================================================
=
Page 7 of 37
Development Standards
=======================================================================================
=
Use in-line comments when necessary to help the reader understand a particular process if it is
complicated.
Comment all subroutines and logical divisions of the program, indicating their purpose.
For call function module statements always use the Pattern button on the editor to add the
function module. Leave any parameters commented out if they are not used, they are not to be
deleted.
It is recommended, when practical, to use the Pattern functionality within the ABAP editor to
format ABAP statements.
Before the first transport of a program, remove all commented out ABAP statements to clean up
the program and to remove any future confusion about the program.
Page 8 of 37
Development Standards
=======================================================================================
=
3.
Transport Strategy
Transports manage the movement of development and customization objects through out the entire SAP
landscape. In order to help manage transports and to keep all instances in the landscape consistent the following
will be observed:.
o
Each RICEWF object is to have its own transport, and all objects related to it will be included in the
single transport if possible.
Each RICEWF object that requires development configuration will have all configuration on a single
customization transport.
Each transport will include the incident number at the beginning of the description.
Objects on a transport task, are never to be deleted from a task. If an object on a task on a transport is
no longer required, the actual object should be deleted, not the line on the task. If configuration or table
entries are not needed, the configuration should be backed out or the table entries should be removed
from the table to fix the transport, it should then be released.
Undo/back out work no longer needed regularly to reduce a build up of unnecessary objects and to
prevent unwanted objects inadvertently being used by other RICEWF development or being moved to a
productive system.
Page 9 of 37
Development Standards
=======================================================================================
=
4. Naming Conventions
The following objects types define the object use.
R
Reports
Interfaces
Conversion
Enhancement
Workflow
Forms
Security
Utilities
Basis
The object use will be used in the naming of certain object types to help identify the purpose of the object.
When the object type is required in the naming of an object, it will be specifically noted.
4.1 In General.
All objects that are intended for a single use such as conversion programs, fix programs, load audit
programs or any other objects intended for a single use will begin with the letter Y.
All objects that are intended to be used after go-live or on a regular basis will start with the letter Z.
Use
Z.
Descriptive Text
Example:
ZC2C package for C2C project
ZFIAA - package for financial asset accounting objects
ZECC_MM - ECC system, Material management application area
ZCRM_BILL CRM Billing application
You can also use area of developments in <NAME>
Page 10 of 37
Development Standards
=======================================================================================
=
For e.g. ZECC_DM Package for ECC data migration objects
ZCRM_IF Package for CRM interface objects
Note: In case of package interfaces please add _IF as suffix.
Use
Z
Object type
Application area (Ref. Appendix A)
Sub-area (Ref. Appendix A)
Short description of program
2.1 Naming Conventions for Module Pool and Module Pool Includes:
The purpose of this section is to define the naming conventions to be used for module pools and module
pool includes created in the SAP system. Module Pool names will consist of thirty (30) characters
formatted as follows:
Position:
1-4
7-8
9-30
Module Pool Include object names consists of thirty three (30) characters formatted as follows:
Position:
1-27
28-30
Usage:
TOP Data Declarations, Tables, etc.
Onn; PBO modules
Inn; PAI modules
Fnn; Subroutines (Forms)
Where nn is a numeric integer between 00 and 99.
The following is an example customer module pool for the application area C, application subarea PC, and the appropriate includes:
Program name
SAPMZCPCPROGR1
Data include
ZCPCPROGR1TOP
Page 11 of 37
Development Standards
=======================================================================================
=
Form routine include
ZCPCPROGR1F01
PBO include
ZCPCPROGR1O01
PAI include
ZCPCPROGR1I01
3. Function Groups:
Position
1
2
3
4..n
Use
Z
Application Area (Ref. Appendix A)
Underscore _
Descriptive Text
4. Function Modules:
Position
1
2
3
4-5
6
7-30
Use
Z
Underscore _
Application Area (Ref. Appendix A)
Application Sub-Area (Ref. Appendix A)
Underscore _
Use descriptive words, separated by underscores
5. Tables:
Position
1
2
3
45
6 - 16
Use
Z
T for Table
Application Area (Ref. Appendix A)
Application Sub-Area (Ref. Appendix A)
Description of Table
6. Views:
View names can consist of sixteen (16) characters as follows:
Position
Use
1
Z
2
V For View
3.n
Table name of the SAP primary table
7.
Structures:
Position
1
2
3
4-5
6-30
Use
Z
S for Structure
Application Area (Ref. Appendix A)
Application Sub-Area (Ref. Appendix A)
Description of Domain
8. Data Elements:
Position
1
2
3..n
Page 12 of 37
Use
Z
E for Data Elements
Descriptive Text
Development Standards
=======================================================================================
=
9. Domains:
Position
1
2
3..n
Use
Z
D for Domains
Descriptive Text
10. Types:
Position
1
2
3..n
Use
Z
Y for Types
Descriptive Text
Use
Z
H for Help
Descriptive Text
Use
E SAP Requirement
Z
Descriptive Text
Use
Z
P for Type Pool
Descriptive Text
Use
Z
M for Message
Descriptive Text
15. Transactions:
Position
1
2
3
4-5
6 20
Use
Z
Object Type (RICEWFSUB)
Application Area (Ref. Appendix A)
Application Sub-Area (Ref. Appendix A)
Description
Page 13 of 37
Use
Z
Descriptive Text
Development Standards
=======================================================================================
=
Use
Z
IM for IDOC Type
Descriptive Text
Use
Z
E for Segment
Descriptive Text
19. Interfaces:
Position
1
2-3
4..n
Use
Z
IF for Class
Descriptive Text
20. Classes:
Position
1
2-3
4
5..n
Use
Z
CL for Class
Underscore _
Descriptive Text
Use
Z
F for SAPscript Form
Descriptive Text
Use
Z
S for Smart Form
Descriptive Text
Use
Z
A for InterActive
Descriptive Text
Page 14 of 37
Use
Z
I for Interface
Descriptive Text
Development Standards
=======================================================================================
=
Use
This is controlled by the security team.
Use
Z
N for Number Range
Descriptive Text
Constants
Ranges
Page 15 of 37
Definition Type
Prefix
Variables
GV_
Constants
GC_
Types
GTY_
Table Types
GTTY_
Internal tables
GT_
Development Standards
=======================================================================================
=
Selection screen parameter
P_
Select-options
S_
Ranges
GR_
Field Symbols
<FS_>
Objects
GO_
Class
GCL_
Forms
(Meaningful Name)
Modules
Definition Type
Prefix
FP_
Variables
LV_
Tables
LT_
Objects
LO_
The following are the naming requirements for import and export parameters.
Function Module:
Import
IM_
Export
EX_
Changing
CH_
Table
IT_
Method:
Page 16 of 37
Importing
IM_
Exporting
EX_
Changing
CH_
Returning
RE_
Development Standards
=======================================================================================
=
5.
Object Header Description must be included and completed at the start of all objects.
Development objects should be designed and written to allow for restart ability from the beginning of the
program if a failure occurs.
Custom ABAP programs MUST NEVER be used to directly update SAP tables.
Before starting any development work, make sure that no existing functionality satisfies the same
requirements.
If possible, write code that it is re-usable and can be stored in a central library. Function modules and
classes are an example of this approach.
Keep program lengths to a minimum. Each program should handle a discrete problem. The ideal
program would have only one statement in the main section and it would be, Create Object.
One statement per line, and it is advisable that when creating statements that contain multiple options,
that the options be separated by line. Example of this would be the select statement where the SELECT,
FROM, INTO, WHERE, etc should be separated on individual lines to increase clarity when reading the
code. It serves no other purpose but to improve readability.
Skipped lines and indention should be used to promote clarity between sections of code as well as
between file definitions and declarations.
Use the Pretty Printer Automatic formatting function for your programs to ensure uniform indentation of
program code
Use subroutines (FORMS) whenever possible to improve readability and logic flow. Create a subroutine
whenever a block of code is called from multiple places in a program.
SAP Supplies a very large library of function modules and classes that can be used to perform
numerous tasks. Take advantage of these to reduce development and testing time and increase
maintainability.
Common examples include:
CONVERT_TO_LOCAL_CURRENCY for any exchange rate based conversion
UNIT_CONVERSION_SIMPLE, UNIT_SUM when dealing with Units of Measure
RV_DOCUMENT_PRINT_VIEW (Sales Order) to get data from SD documents
RV_DELIVERY_PRINT_VIEW
(Delivery)
RV_BILLING_PRINT_VIEW
(Billing)
Define data structures as types to avoid the use of internal memory and promote readability.
Page 17 of 37
Development Standards
=======================================================================================
=
Always use the type statement when defining variables.
Use the underscore (_) to connect multi-word names for things like variables, Forms, etc, to make
programs easier to read.
Import/Export to Memory
Macros
Use of any statement, Function Modules, Class or any other object deemed as obsolete by SAP.
Table definition.
Type definition.
Data definition.
Selection screen.
Initialization events.
Main processing.
Forms.
All programs must include proper error handling to avoid undesirable terminations. This means that the
system status (SY-SUBRC) needs to be checked after every event in the program that changes it.
System status (SY-SUBRC) must be checked after a function module call or a select single statement.
Use the TRYENTRY bock when working with objects to correctly catch exceptions with objects.
Whenever possible, use existing, relevant, standard SAP message classes to display errors.
When creating a new custom message class, it is required that the last message (Number 999) contain
four ampersands that are separated by spaces. This generic message can then be used to substitute in
specific message text before displaying.
Page 18 of 37
Development Standards
=======================================================================================
=
Error messages must be meaningful and provide information about the error.
Error levels need to be appropriately set, things to consider is the mode the program is being used such
as batch or dialog, roll-back requirements, severity of the error, etc.
Interface development objects need to have some method designed in it for error handling. The method
used should also take into account the possible options for updating SAP. Commit and Roll-back
processes should also be taken into account.
It is required that error handling be decided and defined before commencing development as this effects
the overall design.
User exits, BADIs and Enhancement points are designed to be used to update the process that they are
in and should only be used for that.
Other documents/master data/processes are not to be updated from within a UBE. There are many
issues with commit and roll-back as well as error processing when using UBE to update items outside of
the designed point and are not allowed.
UBEs can be used to start a standard SAP process such as a workflow, message process, or call to a
Proxy as these provide their own commit and error strategies.
Enhancement points permeate throughout SAP standard development objects and can now be used
almost anywhere.
Try to use an enhancement point to modify existing output reports instead of copying the SAP supplied
program and modifying the custom version. This will help reduce development effort and will keep
maintenance to a minimum.
Enhancement Points can not be used on SAP supplied dialog programs, interfaces, function modules or
classes without management approval. The risks to SAP processes is very high when doing these type
of enhancements and therefore require prior approval to make the changes to avoid any issues in the
entire process.
As a rule, authorization checks should be used whenever appropriate to verify the access level of the
user executing the program.
Authorization objects will be created by the security team and used by the development team when
applicable.
5.5 Tables.
Custom tables require approval from the technical architect before they can be created or used.
Page 19 of 37
Development Standards
=======================================================================================
=
The creation of custom tables is controlled and authorization to create a new table must be received
from the technical architect.
All fields in a table must be defined using data elements from the data dictionary. Free form definition
of fields is not allowed.
All custom tables must have the table maintenance generated for it.
All custom tables must have an authorization group in the table maintenance. The authorization group
&NC& is not permitted.
Function Groups for table maintenance are to be named starting with YTM_ for one time objects,
ZTM_ should be used for all other table maintenance.
Data in custom tables that are static and are not dependent on clients, still need to have a field in the
table for client. They also need to be defined with delivery class C for customizing table. All data from
these tables must be transported.
Reports are always to be written using SAPs ALV controls. If the Object version of ALV is not used, it
must be explained why.
The report structure and definition must be defined as a structure in the data dictionary.
All text that is defined in the program should be done using text elements to support multiple
languages.
The main section of a report program should have very few statements. A good, clear program has very
few commands in the main section of the program, all other code should be defined in Forms or objects
which are called from the main section.
Use the standard function key definitions in these standards to define menus. All menus are to use the
standards menu functions and transaction values.
Accessing filed from the application server is to be done using Logical Files. The basis team is to define
the logical file and set the directly path. The development team is to use the standard SAP Function
Module GET_FILENAME to get the physical file name for the logical file being used. There is never a
reason to use a physical file name on the application server.
Page 20 of 37
Development Standards
=======================================================================================
=
Description
ICON
Function
Code
Function Text
Function
Key
Setting
Fast Key
Back
ICON_SYSTEM_BAC
K
BACK
Back
Exit Program
ICON_SYSTEM_END
EXIT
Exit
Cancel
ICON_CANCEL
CANC
Cancel
ICON_PRINT
PRNT
Find
ICON_SEARCH
FIND
Find
Repeat Find
ICON_SEARCH_NEX
T
RFND
Repeat Find
Save
ICON_SYSTEM_SAVE
SAVE
Save
Additional GUI status menu options that are to be used to make all GUI status menus consistent, If the value in
the table is blank, there is no specific standard.
Description
ICON
Function
Code
Function Text
Function
Key
Setting
Execute
ICON_EXECUTE_OBJECT
EXEC
Back
F8
Help
ICON_INFORMATION
IHELP
Online Help
Shift-F1
Delete
ICON_DELETE
DELETE
Delete
Shift-F2
Create
ICON_CREATE
NEW
Create
F5
Change
ICON_CHANGE
CHANGE
Change
F6
Copy
ICON_COPY_OBJECT
COPY
Copy
Ctrl-F5
Rename
ICON_RENAME
RENAME
Rename
Ctrl-F6
Display/Chang
e
ICON_TOGGLE_DISPLAY_CHANG
E
TDISCHG
Display/Chang
e
F7
Details
ICON_SELECT_DETAIL
DETAIL
Details
F2
Other Object
ICON_OTHER_OBJECT
TOBJECT
Fast Key
Shift-F5
The Menu Bar should always include all the functions used in the Application Tool Bar and must include any that
are defined to function keys but are not on the Tool Bar. There are no specific requirements on definition of the
menu bar.
Page 21 of 37
Development Standards
=======================================================================================
=
5.9 Readability
Start each new command or clause on a new line. Do not put multiple commands on the same line.
Skipped lines and indention should be used to promote clarity between sections of code as well as
between file definitions and declarations.
Use the Pretty Printer automatic formatting function for your programs to ensure uniform indentation of
program code
Standard Form headings. Add appropriate form description to these headings. Note: Pretty Printer
only creates Form headings if no comment line exists after previous ABAP statement.
5.10
COMMIT WORK is used when doing database operations. It concludes a logical process and releases
all database locks. SY-SUBRC is set to zero if the COMMIT WORK was successfully performed. Once
a COMMIT WORK statement has been executed, it is not possible to rollback (ROLLBACK WORK) the
previous database operations.
COMMIT WORK is implied when a process concludes, but an explicit commit work should be added at
the end of a logical unit of work.
COMMIT WORK is not allowed in User Exits, Enhancements or BADI as they objects tend to be within a
logical unit of work that already has a commit work elsewhere in the process.
BAPIs are not have any commit work within the BAPI as this is contrary to the concept of using BAPIs
as committing of data should be controlled by the calling process.
5.11
Use the describe statement sparingly. If properly defined, checking for data in a table can be done using
a simple if statement.
5.12
Describe
Free
The Free statement should be used with internal tables if it is necessary to release memory after
processing an internal table. This is needed when dealing with large tables. When a program terminates,
memory is automatically released.
Page 22 of 37
Development Standards
=======================================================================================
=
5.13
Sometimes it is necessary to keep track of a single value between executions of a program where the
current execution is dependent on the previous execution. Examples of this might be last date executed
or last time program executed.
When tracking a single value that is needed between execution of the same program, the TVARVC table
should be used to track this information. This is one of the few tables in SAP that can be modified
directly and it should be used in the following way.
o
The Parameter or Selection Option should have be the calling programs name, if a second or
third value is required by the same program, an extension should be used after the program
name such as _1 or _2, etc.
The program should assume that the value exists. The program must not populate the field with
a default if it is missing. Default values should be manually populated before the first execution
of the program. This can also be done by manually adding the entry in the table onto a transport.
Use the SAP lock entry for the table TRDIR and use the lock argument of the current program
name. As programs should never be edited in production, this lock is never used.
Keep the lock entry active until the program has completed execution.
In the program that needs to check for duplicate execution, if the lock is not successful, then it is
already executing and should not be executed, the program should end with an information
message in the log. Only if specifically needed, should the program end in a manner than using an
information message.
5.15
Number Ranges
SAP supplies a method for creating custom number ranges. When there is a custom requirement to
keep track of sequential number for an object, the number range functionality should be used. These
number ranges work in the same manner as all other document/master data numbers ranges in SAP.
The transaction to access number ranges is SNRO.
Page 23 of 37
Development Standards
=======================================================================================
=
5.16
Dates on Forms
In order to correctly accommodate for different time zones, all dates must first be written to a character
field variable before being displayed. Dates are not to be printed directly using in a form. Use the
WRITE statement to a character field in order to correctly display a date on a form.
5.17
Messages
In every program a default message class should be specified in the report statement.
Every program should use MESSAGE statements for errors, warnings, and information.
It is important to use the appropriate message types to indicate different execution statuses of the program. The
design has to consider the different effects of each message type (refer to ABAP on-line help).
Type
Description
On-line action
Background action
Informational
Warning
Correction possible
Error
Correction required
Abend
Success
No action
When designing messaging for reports executed on-line, it should be considered that the first message
with type E, A or X will cancel the execution of the report and the output will be lost.
When issuing a message from an on-line transaction or report the user should be able to correct the
problem on the current screen to avoid any dead-lock situation.
If a message includes program specific text the following format should be used.
This message will use the contents of text-m05 with with, if it exists for sy-langu, else it will use the text
in quotes. This will provide ease of debugging and position the code to work well in multi-lingual
environments. (See Text Handling, above)
When creating new messages, long text for the message should be completed to give a thorough
explanation of the message being displayed. This should always be used when the error is not an
obvious error.
Page 24 of 37
Development Standards
=======================================================================================
=
6.
Performance
6.1.5 Joins.
Joins are not allowed in an ABAP program. If it is more efficient to do a table join when selecting data,
create the join in the data dictionary as a view. This will enhance performance of the view, help reduce the
number of fields being processed, increase reusability as well as force discipline in correctly defining how
tables are joined. Views, by definition, are much more efficient than a join in a program as the database
generates an index for the view when created it in the data dictionary.
Page 25 of 37
Development Standards
=======================================================================================
=
Smaller static tables that are reused within a program, or are checked frequently are more efficiently
accessed if stored in a global, internal table. For small static tables its is more efficient to read the internal
table than to call the table, even if the key is used.
6.1.11 Sort By
The database manager is more efficient in sorting tables than ABAP is, try to presort data in internal tables
by using the sort by extension in ABAP SQL to increase performance.
Page 26 of 37
Development Standards
=======================================================================================
=
6.2.3 Conditions.
When using conditions such as If or Case statements, conditions are processed sequentially so to reduce
execution time, the most common conditions should be listed first.
Always try to use the CASE statement over multiple IF..ELSEIF conditions. The Case statements will be
more efficient over several conditions, and it is much easier to read and maintain.
6.2.4
Field Assignment.
Use field symbols when looping through an internal table, especially ones that needs to be updated. This is
much more efficient than using the into statement on a table. This also makes updating of a table quicker
and easier, reduces memory usage and improves readability of the program.
Page 27 of 37
Development Standards
=======================================================================================
=
To promote good modularization of programs, the check statement should be avoided. Additionally, rather
than doing a check upon entry to a FORM, use a condition before calling the Form. Dont call a form you
are simply going to leave, determine if the form should be executed before calling the From.
Page 28 of 37
Development Standards
=======================================================================================
=
7.
Documentation
Begin each program with a standard header comment (See program template in the Appendices
section)
Use in-line comments when necessary to help the reader understand a particular process.
Comment all subroutines and logical divisions of the program, indicating their purpose. Using the
Pretty Printer utility provides ready-made heading structures for subroutines.
Include detailed program documentation in the documentation module of the program. Do not
include detailed documentation in the standard program header.
The revision number shall identify every changed program line. (e.g. "R001" for all lines of code
changed during the first revision)
Data declarations should be done in the beginning of the program for each data type, as in the
standard program template.
It is desirable to have a comment line written every 15-20 statements, that describes the subsequent
part of the program
Input/output parameters
Page 29 of 37
Development Standards
=======================================================================================
=
All program revisions (changes) must be well documented according to following rules.
At the beginning of the program revisions should be documented as in the program template
For single line changes; Copy the line and convert the original line to a comment line and note it
with the revision number. Make the changes and then also mark the new line with the revision
number.
For multiple line changes: Add a comment line at the beginning and the end of the block to be
changed, this comment should contain the revision number and Start/End of changes.
The block to be changed should be copied. The original statements should be commented out, then
changes should be made in the copied block of code.
Functional Specification the Functional Specification should be written jointly by the business owner
and a senior developer in the ABAP development team. The Functional Specification Document needs
to be signed off by the business owner/ report requestor before any development can begin on the
program.
Technical Specification this should be written by the ABAP developer prior to commencing coding.
This must be signed off by the programmers team lead before programming is started.
Quality Assurance Checklist before a program can be transported from the development system, it
must be QAd by the team lead/peer for efficiency of coding and adherence to the development
standards this process includes a peer review.
Unit Test Plan before a program can be transported from the development system, a completed Unit
Test Plan must be signed off by the developer. The testing documentation should consist of a unit test
plan which includes:
Expected Results
Test Data
Actual Results.
Page 30 of 37
Development Standards
=======================================================================================
=
The unit test is performed by the program author and should follow a relevant test case that covers all condition
sets that are possible when executing the program in a production environment. The unit test should verify
proper error handling and error exits using erroneous values. Each logical step within a condition should include:
Test data
Expected results
Unit testing should be completed in the development environment before any migration to subsequent systems.
Unit testing and the accompanying documentation (completed Unit Test Plan) should be completed, signed off
by the developer, and included in the program folder prior to submitting the program for subsequent testing
activity including System Testing and Migration Testing.
Page 31 of 37
Development Standards
=======================================================================================
=
Appendix A
Area Code
Sub-Area Code
AM - Assets Management
DP Demand Planning
SN Supply Network
Planning
PP Production Planning /
Detail Scheduling
GA Global Available to
Promise
CO - Controlling
Page 32 of 37
I0 Internal Orders
PC Product Costing
IB IBase
Development Standards
=======================================================================================
=
CM Contract Management
PS Professional Services
FS Field Services
IC Interaction Center
Page 33 of 37
MW Middleware
BP Business Partner
PR Products
OP Opportunity Mgmt
QT Quotes
SO Sales Orders
PC Pricing
Development Standards
=======================================================================================
=
FI-Financial Accounting
LD Leads
CP Campaigns
AA - Asset Accounting
AP - Accounts Payable
AR Accounts Receivable
F
F
PA Profitability Analysis
BW Business Warehouse
CA - fica
MM - Materials Management
Page 34 of 37
MR MMR
Development Standards
=======================================================================================
=
HR Payroll/Benefits/PA
Page 35 of 37
ED EDI
IM Inventory Management
PR Purchasing
EN Engineering
CM Common MM
PI Physical Inventory
LE Logistics Execution
EM Export Management
WM Warehouse Mgmt.
TR Transportation
PY Payroll
BN Benefits
OM Organization Mgmt.
Development Standards
=======================================================================================
=
PP - Production Planning
PA Personnel Admin.
BW Business Warehouse
TM Time Management
PO Production Orders
PM - Plant Maintenance
QM - Quality Management
QP Quality Planning
QI Quality Inspection
QC Quality Control
QN Quality Notifications
PS - Project System
Page 36 of 37
Development Standards
=======================================================================================
=
SD Sales & Distribution
MD Master Data
PR Pricing
TP Transportation
BL Billing
ED EDI
SI Sales Information
CS Customer Service
IC Inter-company Sales
Basis
BC Basis Components
Cross Application
ZZ
Page 37 of 37