SlideShare a Scribd company logo
1 of 66
Coding Standard – ABAP
Abap coding standards
Coding Standard – ABAP
Coding Standard – ABAP
                                                TABLE OF CONTENTS


EXECUTIVE SUMMARY ....................................................................................................6

DOCUMENT OBJECTIVE......................................................................................................................6
DOCUMENT SCOPE...........................................................................................................................6
TARGET AUDIENCE............................................................................................................................6
ACTION & ADHERENCE....................................................................................................................6
GENERAL COMMUNICATION .............................................................................................................6

THE DEVELOPMENT LIFE-CYCLE.................................................................................7

PREPARATION OF A FUNCTIONAL SPECIFICATION .......................................................................................7
FUNCTIONAL SPECIFICATION SIGN-OFF...................................................................................................7
THE TECHNICAL SPECIFICATION ...........................................................................................................7
     DEVELOPMENT OF PROGRAM CODE...............................................................................................7
UNIT TESTING & DOCUMENTATION ......................................................................................................8
SYSTEM TESTING...............................................................................................................................8
USER ACCEPTANCE TESTING................................................................................................................8
PROGRAM SIGN-OFF.......................................................................................................................8


TYPES OF ABAP PROGRAM.............................................................................................8

DATA CONVERSION PROGRAMS...........................................................................................................9
BATCH INTERFACES...........................................................................................................................9
INBOUND INTERFACES......................................................................................................................9
OUTBOUND INTERFACES.................................................................................................................10
ALE INTERFACES...........................................................................................................................10
REPORTS......................................................................................................................................10
BASIC LIST..................................................................................................................................11
INTERACTIVE REPORT.....................................................................................................................12
    ALV....................................................................................................................................12
TRANSACTIONS (DIALOGUE PROGRAMMING)..........................................................................................12
USER EXITS..................................................................................................................................13
    BADI’S...............................................................................................................................13
    SAPSCRIPTS............................................................................................................................13
    SMART FORMS........................................................................................................................13


FUNCTIONAL SPECIFICATIONS...................................................................................13

WHAT IS A FUNCTIONAL SPECIFICATION................................................................................................14
WHY WRITE FUNCTIONAL SPECIFICATIONS..............................................................................................14
WHAT SHOULD BE IN A FUNCTIONAL SPECIFICATION?................................................................................14


THE TECHNICAL SPECIFICATION...............................................................................14

WHAT IS A TECHNICAL SPECIFICATION?................................................................................................15

CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 2 of 66
Coding Standard – ABAP
WHY WRITE TECHNICAL SPECIFICATIONS?.............................................................................................15
WHAT SHOULD BE IN A TECHNICAL SPECIFICATION?..................................................................................15


ABAP CODING STANDARDS...........................................................................................15

GENERAL PRINCIPLES......................................................................................................................16
ERROR HANDLING..........................................................................................................................18
GENERAL.....................................................................................................................................18
CONVERSIONS & INTERFACES ERROR HANDLING...............................................................................18
DIALOG PROGRAMMING..................................................................................................................19
GENERAL.....................................................................................................................................19
NAMING.......................................................................................................................................19
REPORT PROGRAMS........................................................................................................................19
PROGRAM STRUCTURE......................................................................................................................20
READABILITY.................................................................................................................................20
AUTHORIZATIONS & SECURITY............................................................................................................21
PERFORMANCE CONSIDERATIONS........................................................................................................21
DATABASE SELECTIONS..................................................................................................................21
ABAP STATEMENTS.......................................................................................................................24
COMPUTE AND MOVE STATEMENT...................................................................................................24
COMPARE OPERATORS ..................................................................................................................24
AVOID ‘HARD CODING’               ...................................................................................................24
CASE VS. IF/ELSE: WHICH TO USE WHEN BOTH WOULD WORK?....................................................25
BREAK LEVELS IN LOOP STATEMENTS..............................................................................................26
INTERNAL TABLES............................................................................................................................27
ABAP LIST VIEWER.......................................................................................................................29
ABAP QUERIES...........................................................................................................................30
SAPSCRIPT CODING STANDARDS......................................................................................................30
STANDARDS FOR ALL ENHANCEMENT USER EXITS......................................................................................31
CUSTOM BAPI DEVELOPMENT..........................................................................................................32
LOGICAL DATABASES......................................................................................................................33
 SELECTION SCREEN PARAMETERS........................................................................................................33


PROGRAM DOCUMENTATION......................................................................................33

PROGRAM FOLDER OVERVIEW...........................................................................................................33
SOURCE CODE DOCUMENTATION.......................................................................................................34
ON-LINE HELP..............................................................................................................................35
PROGRAM ATTRIBUTES...................................................................................................................35
PROGRAM MODIFICATIONS..............................................................................................................35
PROGRAM TESTING.........................................................................................................................36
TEST CONDITIONS........................................................................................................................36
 TEST PLAN................................................................................................................................37
TEST DATA..................................................................................................................................37
EXPECTED RESULTS.......................................................................................................................37
ACTUAL RESULTS.........................................................................................................................37
NAMING CONVENTIONS..................................................................................................................37
PROGRAM DOCUMENTATION TEMPLATES................................................................................................37
PROGRAM HEADER........................................................................................................................38
PROGRAM CHANGE........................................................................................................................38
INCLUDE PROGRAM HEADER...........................................................................................................39

CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 3 of 66
Coding Standard – ABAP
SUB-ROUTINE/FORM......................................................................................................................39
FUNCTION MODULE.......................................................................................................................40
FUNCTION MODULE – EXCEPTION HANDLING....................................................................................40
APPLICATION OSS NOTES..............................................................................................................41
ABAP PROGRAM TEMPLATES............................................................................................................44
BASIC REPORT LIST......................................................................................................................44
INTERACTIVE ABAP REPORT LIST..................................................................................................46
BATCH INPUT PROGRAM.................................................................................................................48

PROGRAM PERFORMANCE TUNING TECHNIQUES...............................................50

TECHNIQUE 1: USING SELECT STATEMENTS......................................................................................50
TECHNIQUE 2: SELECTING ORDERED RECORDS FROM A TABLE...............................................................50
   TECHNIQUE 3: READING LARGE INTERNAL TABLES WITHOUT USING BINARY SEARCH............................51
TECHNIQUE 4: MOVING DATA FROM INTERNAL TABLE 1 TO INTERNAL TABLE 2....................................51
TECHNIQUE 5: APPENDING DATA FROM INTERNAL TABLE 1 TO INTERNAL TABLE 2................................51
TECHNIQUE 6: DELETING DATA FROM INTERNAL TABLES....................................................................52

ABAP CODE REVIEW CHECKLIST..............................................................................53

ABAP OBJECTS..................................................................................................................53

INTRODUCTION .............................................................................................................................53
NAMING CONVENTIONS .................................................................................................................54
GENERAL CONVENTIONS..................................................................................................................54
CLASS CONVENTIONS ....................................................................................................................55
FIXED METHOD NAMES ..................................................................................................................55
METHOD CONVENTIONS .................................................................................................................56


WORK FLOW......................................................................................................................58

INTRODUCTION..............................................................................................................................58
NAMING CONVENTION...................................................................................................................58
1.1WORKFLOW TEMPLATES / TASK.................................................................................................58
1.2BUSINESS OBJECT....................................................................................................................59
1.3BUSINESS OBJECT – PROGRAM...................................................................................................59
PREFERRED APPROACHES / PRACTICES:.................................................................................................60
A. WORKFLOW IMPLEMENTING APPROACH:........................................................................................60
B. WORKFLOW SCENARIO DEVELOPMENT:.........................................................................................60
PERFORMANCE TIPS:........................................................................................................................62
ERROR HANDLING:.........................................................................................................................62
      CHECKLIST FOR WORKFLOW DEVELOPMENT:..................................................................................63


QA SUMMARY ...................................................................................................................63

OBJECTIVE...................................................................................................................................63
SCOPE........................................................................................................................................63
TARGET AUDIENCE..........................................................................................................................63
ACTION & ADHERENCE...................................................................................................................63
CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 4 of 66
Coding Standard – ABAP
QA PROCESS OVERVIEW................................................................................................................64




CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 5 of 66
Coding Standard – ABAP
Executive Summary
           Document Objective
This document has been prepared to outline the development approach followed by the
Wipro Technologies ABAP development group.

           Document Scope
This is a definition of the base standards relating to applications development work and
recommendations for efficient programming techniques for all custom development work
carried out by the Wipro Technologies ABAP development group. It describes progression
from functional specification, through technical specification to code development, with
associated Quality Assurance and documentation. Details of performance improvement
measures and technical information are also included.


           Target Audience
The target audience for this document according to the purpose is as follows:
                 Action & Adherence
         Project Managers
         Technical Team leads
         Technical Team members
                 General Communication
         All Core & Country Team Leaders & Members (Process & Technical)




CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 6 of 66
Coding Standard – ABAP
The Development Life-cycle
 During the life cycle a number of deliverables are expected and checkpoints reached (see
diagram below).



        The ABAP Development Life Cycle
                                                                      ABAP Development Team


          Formal                    Functional
          Sign-off                 Specification                   Technical
                                                                  Specification



                                                      Code and
                 User
                                                      Unit Test
              Acceptance
                                                      Program
               Testing




                                              System Test




           Preparation of a Functional Specification
The Project Implementation team members, located on-site, are responsible for preparing
Functional Specifications. These will describe the development requirement and contain a
description of the functionality of the proposed custom ABAP program. During production of
these specifications it may be necessary for the business teams to gain input in the form of
Functional Specification assistance from ABAP team members.



           Functional Specification Sign-off
Each functional specification, once complete, will be subject to review and approval by the
ABAP team leader. In addition, the ABAP team leader assesses the complexity and cost of
the proposed development - any changes to the original assessment are subject to written
approval of both parties.



           The Technical Specification
The functional requirements will be translated to a technical specification. This will subject to
internal ABAP team quality assurance. Once complete, it will be signed off internally by the
ABAP development team leader. Any changes between the technical and functional
specification will be made in writing and subject to the written approval of both parties.

     Development of Program Code
Program coding then occurs from the technical specification.
CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 7 of 66
Coding Standard – ABAP
           Unit Testing & Documentation
Once complete, the program will be tested by the programmer, who will also produce the
following testing documentation:
• Unit Test Conditions
• Unit Test Plan
• Test Data
• Actual Results


           System Testing
At regular intervals (e.g. 2 months) a number of developments are subject to system testing.
This will be to verify inter-dependencies between reports.



           User Acceptance Testing
The ABAP reports will be tested and accepted by reference to whether they conform in all
material respects to the Functional Specifications (as signed off by both parties) and in
accordance with the following procedure:
            • Functional Designer prepares Test Plan.
            • Client Project Manager nominates suitable User for acceptance testing
            • User conducts testing as detailed in plan.
            • Client Project Manager reviews UAT test plan and results to verify validity of
              results and completeness of testing.


           Program Sign-Off
Following a successful User Acceptance Test, the program will then be signed-off by both
parties.

After development technical specifications are updated to reflect any program
modifications requested during the life cycle. Approval to implement any modifications not
covered in the original functional specification will be obtained in writing & a copy
contained within the program folder.



Types of ABAP Program

There are a number of different types of ABAP program, as listed below. The type of
program to be developed affects which details are required in the functional specification.
It is important that the different types of program are understood before detailing the
relevant requirements.


•   Data Conversion
•   Batch Interface
•   ALE Interface
•   Report
•   Transaction
•   User Exit
•   SAPScript (output)
•   Smart Forms
•   BADI’s
CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 8 of 66
Coding Standard – ABAP

           Data Conversion Programs
Data conversion programs can be written to upload data from external legacy systems into
SAP. There are a number of standard SAP programs specifically designed to meet this
requirement. These use one of two methods to upload the data:
• Direct Input
• Batch Input

Direct input programs tend to be around ten times faster than batch input programs.
However custom ABAP developments are only supported if they use the batch input
method. Batch input programs read a file from either the presentation or application server
and upload it into SAP by simulating the actions of a user stepping through the screens of the
relevant transaction. This means that the SAP transaction validates that the data being input
is valid so the custom ABAP program does not have to do this.

The Batch input program creates a ‘session’, which can be thought of as a collection of
information relating the transaction fields to the data to be uploaded. The database is not
updated until the ‘session’ is processed. This can be done either manually or automatically.
If the session should be processed automatically this should be specified. Any invalid records
encountered by SAP are not uploaded into the database and they result in the session being
‘in error’. All valid records will be loaded, the remaining erroneous records will be retained
and this session can be re-processed manually. This allows a user to correct the records on-
line.




           Batch Interfaces
Interfaces are used to transfer data between SAP and an external system. There are two
types of interface:
• Inbound       - transfers data from the external system to SAP
• Outbound - transfers data from SAP to the external system

The transfer of data is usually facilitated by either reading from or writing to a file on the
application server that has been created or is subsequently read by the external application.


                 Inbound Interfaces
For an inbound interface (data being put into SAP), the program first reads the data from the
source file, performs any conversions, calculations and formatting that is required for the SAP
transaction. The program can then write the data out either as a set of table entries or to a
flat file if the data needs to be stored for audit reasons although if this approach is adopted
archiving strategies must also be considered. Obviously a flat file carries fewer overheads in
terms of maintenance, but there are also benefits of interface controls and audit through
intermediate tables that in some instances outweighs this. The program then uses the
converted data and creates a SAP batch input session to load it into SAP via the relevant
transactions (If writing to a table this may be a second program).




CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 9 of 66
Coding Standard – ABAP


                  First Stage

                    Extract             Calculate              Convert               Format


                  Second Stage
                                            Map                  Load




                 Outbound Interfaces
An outbound interface will typically consist of only one program. This will retrieve the relevant
data from SAP tables and write it to an output file. Conversion and formatting will be carried
out by the destination interface. Again, some use of tables may be adopted to provide a
record of interface operation.


           ALE Interfaces
Application Link Enabling (ALE) interface will also comprise inbound and outbound types of
interfaces. ALE is a standard SAP Application component that provides standard settings or
the ability to customize elements to take advantage of the ALE application layer.

ALE interfaces fall into the following categories:
• Standard Scenarios – where SAP provides standard components i.e. Message Types,
   IDOCs, Function Modules that can be set-up immediately to enable data transfer
• Modified Scenarios – where the standard SAP components are enhanced to either
   reduce data or extend the data being sent i.e. reduce or extend IDOCs, additional
   function module changes
• Customized Scenarios – new components are added to address interface requirements
   that cannot be met by modified or standard scenarios i.e. new message types, new
   IDOCs

ALE interfaces require a slightly different development approach as the ALE interface require
a combination of:
• Client Independent Customization e.g. Message Types
• Client Dependent Customization e.g. Output Types
• Repository changes e.g. Function Modules


           Reports
SAP Reports provide a user with a list of data; this can be either displayed on the screen or
printed. Using the following SAP supplied tools can also produce these Reports:
• Report Writer
• Report Painter
• ABAP Query.
• ALV



CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 10 of 66
Coding Standard – ABAP
These are useful tools suitable for relatively simple reports and can be used as end-user tools.
It should be remembered that since these tools are effectively code-generators the code
developed might lack clarity and be relatively inefficient.

Reports produced using ABAP code can be one of two types:
• Basic List
• Interactive Report


                 Basic List
This is a report that produces a basic list of data. The user can enter selection criteria on the
selection screen to restrict what data is available on the output report. In addition, a number
of calculations may be performed by the report together with some data grouping and
sorting but this is controlled by the program code.



 Basic List Report




                                                          Simple list of Data,
                                                          double-clicking has no
                                                          effect




CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 11 of 66
Coding Standard – ABAP
                 Interactive Report
An interactive report allows the user more flexibility in what data they wish to retrieve but are
more complex to code and test. The user is given the option to double-click or select lines
and see more information. What further information is displayed should be detailed in the
Functional Specification. For instance, a report on Purchases could list a number of purchase
orders. By double clicking on the Purchase order number the user can be taken to the
‘Display Purchase Order’ transaction to browse the purchase order. This will allow them to
view more information than in the report.


 Interactive Report




 User Double-clicks
 on PO Number, the
 Purchase Order
 Overview is displayed.




       ALV

  ABAP List Viewer (ALV) is one of the fascinating tools provided by SAP for displaying reports.
This tool has the merit of reducing the development time of reports by providing standard
interfaces (Function Modules). These standard interfaces provide GUI and formatting options
for the on screen display.

           Transactions (Dialogue Programming)
A transaction is a dialogue program with one or more screens. It changes objects in the
database in a consistent manner. Examples of standard SAP transactions include ‘Change a
Purchase Order, Create a Material, Enter a G/L Posting’. Custom transactions can be
developed to meet functionality not covered by the standard SAP system.
CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 12 of 66
Coding Standard – ABAP

           User Exits
Changes to SAP supplied code are called a repair to the system and are not supported by
SAP. There are however number of places in the standard SAP code where additional
functionality can be implemented called ‘User Exits’. These exist in pre-defined places in the
standard SAP code. Specific data is passed into and out of these exits allowing some data
manipulation flexibility. These areas of SAP code are reserved for customer enhancements
and are protected from changes during upgrades.


     BADI’s

Business Add-Ins are a new SAP enhancement technique based on ABAP Objects. They can
be inserted into the SAP System to accommodate user requirements too specific to be
included in the standard delivery. Since specific industries often require special functions, SAP
allows you to predefine these points in your software.

     SapScripts
SAP supplies a number of outputs as standard, e.g. Purchase Order, Invoice, etc. In many
cases these meet client business requirements but additional changes are often requested.
This can vary from adding company logos to retrieving additional data and changing the
layout. The outputs are produced using the SAP tool SAPScript.

     Smart Forms
The Smart Forms replace the SAPScript forms.

SAP Smart Forms allows you to execute simple modifications to the form and in the form logic
by using simple graphical tools; in 90% of all cases, this won't include any programming effort.
Thus, a user who is familiar with the tool but has only rudimentary programming knowledge
can configure forms with data from an SAP System for the relevant business processes. The
result of the form development is a Smart Form. After it is activated, the Smart Form is similar
to a callable function module in the SAP System.

The logic of the form is mapped entirely in the Smart Form. To print a form, you call it from
within an application program, in which you retrieve the application data to be merged into
the form. As data retrieval and form logic are separated, you must only adapt the Smart
Form if changes to the form logic are necessary. The application program passes the data
via a function module interface to the Smart Form.




Functional Specifications

Functional specifications should be prepared and owned by the Project Implementation
team (business process team). Essentially they document why the development is required,


CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 13 of 66
Coding Standard – ABAP
how the ABAP development will meet the requirement, what user acceptance testing
criteria will be used to verify that the final development meets the business requirements.




           What is a Functional Specification
A functional specification should clearly define the functionality of the proposed ABAP
program. The document should use clear language and not contain ambiguous statements
that could lead to confusion. The document is a design deliverable and is used internally
within the ABAP team as a basis to write a technical specification. The technical
specification should contain no functionality not detailed in the functional specification.
Once complete, the functional specification is used as a baseline to estimate the complexity
of the proposed ABAP program and the associated development time for planning
purposes.

This document forms the link between the functional and ABAP teams but it is important to
remember that this document is owned by the functional designer/Business Process Team.
The success of the development, however, depends on close co-operation with the ABAP
team.




           Why write Functional Specifications
Functional specifications are written to ensure that all parties (ABAP team/Functional Team)
know what is required in the development. This document allows requirements to be
reviewed across regional teams before the development is complete. It is also part of the
process to enable relevant clients to meet validation requirements. In addition, functional
specifications enable dependencies and inter-relationships between the developments and
functional areas to be identified and enable evaluation of the risk of development.

           What should be in a Functional Specification?

•    A description of the business process. A series of bullet points summarizing the process
     flow for this requirement.
•    Assumptions made for this process if any.
•    Key process steps and descriptions.
•    What type of program is required?(Example Conversion/SAP Script etc)
•    Tables from where the data can be fetched
•    A description of the Selection Screen if applicable.
•    Validations required at various steps if applicable.

The Technical Specification
The ABAP team writes technical specifications internally. These document the business
requirements covered by the functional specification in a more technical detail that can be
translated by a programmer into code. The technical specification also aims to document
the implemented solution so it can be used for future code maintenance.




CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 14 of 66
Coding Standard – ABAP
           What is a Technical Specification?
A Technical specification should clearly define the functionality of the proposed ABAP
program in much more detail than the Functional Specification. This document should use
clear language and is devoid of ambiguity. The document is a design deliverable and is
used internally within the ABAP team as a basis to write ABAP code. The technical
specification should contain no functionality not detailed in the functional specification.
Once complete, the technical specification is used to generate the code easily and
seamlessly.

This document forms the link between the functional specification and ABAP code itself. It is
owned by the ABAP developer and is QA’ed by the ABAP team leader before coding
commences. The technical specifications use logic charts to illustrate the main logical steps
in the code and how data and other ABAP specific constructs need to be manipulated to
produce the required functionality.


           Why Write Technical Specifications?
Technical specifications are written to illustrate and help design the main logical steps
involved in meeting the requirements as specified in the functional specifications. This
document allows the developer to visualize and create methods and techniques to manage
processing efficiently.



           What should be in a Technical Specification?
A technical specification needs to contain:


•    A description of the Technical Solution highlighting the key design issues. A series of bullet
     points summarizes the logic chosen for the program and the main technical difficulties.
•    What assumptions are made in the technical specification and what they entail in
     technical terms.
•    Key process steps.
•    Why a particular function module was chosen.
•    Why use multiple selects than just one.
•    Why use a particular kind of logic for the main processing.
•    What were the major technical problems with the design of the program?
•    A description of the Selection Screen with a Selection Screen Prototype
•    All the error messages (ID and Classes) prompted by the validations executed at the
     selection screen will be detailed.
•    Detail Logic Diagrams along with notes associated to them. They should include critical
     decision logic, database selects, complex conversions, calculations, and formatting and
     output.
•    Main Processing steps descriptions
•    Final Processing steps descriptions



ABAP Coding Standards

The standards in this document define a base for applications development and quality
control. They have been defined as a result of past experience on a number of projects.
Standards are used to ensure that the same set of rules are applied in program design,

CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 15 of 66
Coding Standard – ABAP
development and reviews and they are applicable to all programs developed in support of
the conversion, implementation and maintenance of the SAP R/3 System.

           General Principles
When coding a program, the following points should be observed to ensure that
programming is consistent in format across the project. This ensures that work can be easily
transferable between programmers

•    The standard SAP project program template should be used for all programs.

•    ABAP programs that update master and transactional data MUST ALWAYS use SAP
     transaction codes (where transaction codes are available) by utilizing standard SAP
     Function Modules, BDC or ‘call transaction’ utilities. This ensures that logical units of work,
     rollback, locking operations and edits are performed. SAP tables MUST NEVER be
     updated directly.

•    ABAP programs MUST NEVER be used to update configuration 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 are an example of this approach. R/3 provides a large amount of function
     modules that perform various tasks such as convert currencies, calculate dates, explode
     BOM’s etc. In most cases, these modules are efficient and can reduce coding time;
     therefore they should be employed where possible. It is worth taking the time to search
     the function module library for a function that meets your requirements.
         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)

•    Keep program lengths to a minimum. Each program should handle a discrete problem.

•    If there are a large number of data declarations necessary as part of a program,
     consider separating your declarations into an INCLUDE. The include name should be the
     same as the program name with the suffix ‘_DATA’

•    Use subroutines (FORMS) whenever possible to improve readability and logic flow.
     Consider creating a subroutine whenever a block of code is called from multiple places
     in a program.

•    Avoid the COMPUTE function if clearer ADDs, SUBTRACTs, MULTIPLYs, or DIVIDEs can be
     used.

•    When assigning internal fields that are to hold values from databases, use the LIKE option
     to ensure that the variable has identical characteristics. Example:

                                   DATA:         WS_LIFNR LIKE LFA1-LIFNR.
•    Use the INCLUDE statement for Data Declarations, PBO Dynpro modules, PAI Dynpro
     modules, Subroutines, and Individual Event Processing.

CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 16 of 66
Coding Standard – ABAP
•    Use an underscore (_) to connect multi-word variable names and/or MODULE names.

•    Use the WRITE command with Currency or Units option when writing prices/values to
     ensure the data is output with the correct number of decimal places. For example
     weights should always be output with the UNITS options and prices should always be
     output with the CURRENCY option. This ensures the program can be used over multiple
     units of measure and in multiple countries.

•    All programs should be made as generic as possible and reliance on factors specific to
     clients business should be avoided since the business processes can change easily.

•    Programs that set their own GUI status should have menus and screens that are as
     intuitive as possible.

•    Push buttons should reflect the menu options. All push button options should be
     available by menu as well.
        Push button
             Print    Sort    Refresh    Display/Change

•    Explicitly qualify all field specifications. For example, use KA-KTRNA, not KTRNA only.

•    When using the FILL statement, specify FILL FROM. For example, use FILL workarea FROM
     KA, instead of just FILL workarea.

•    When a local variable is declared, it should be initialized in the declaration statement
     whenever possible.

•    Numbered text-elements must be used wherever possible to make use of SAP’s multi-
     language capabilities, to make maintenance easier and reduce the impact of future
     changes on re-work. Text elements should be created with the actual text string in the
     text element itself e.g. text-001 should read ‘Testing String’ (001) so that text elements for
     an ABAP program can be recreated if the program is moved to a different client.

•    Within the main program code literals (i.e. hard-coded values) should be avoided. If
     reference needs to be made to a specific value (for example Company Code ‘0001’ or
     Sales Organisation ‘ABCD’) then this should be defined as a parameter to make the
     program fully flexible. SD/MM/FI document types in particular should not be hard coded
     since they are subject to change.

•    No undocumented features of the ABAP language should be used.

•    External PERFORMs should NOT be used.

•    Comments should be simple but clear - adequate for a different programmer to
     understand the processing quickly. Comments can occupy a whole line in the code
     when it is prefixed with an “*” character, or part of a line when prefixed with an open
     quote character (“).

•    Declare program-specific internal variables to be LIKE data dictionary fields to ensure
     that physical data attributes are consistent.

•    Each program elements should adopt the appropriate naming prefix.

CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 17 of 66
Coding Standard – ABAP

                       Internal Tables                     Transfer          record/Work        REC_*
                                                           Area
                                                           Internal tables:                     IT_*
                                                           Copy         of     database         X_* or Y_* or Z_*
                                                           table
                       Structures                          Not data dictionary                  STRUCT_*
                       Types                               General                              TY_*
                       Constants                           General                              C_*
                       Parameters                          General                              P_*
                       Ranges                              General                              R_*
                       Checkbox                            General                              CB_*
                       Select Options                      General                              S_*
                       Variable                            Local                                LV_*
                                                           Global                               GV_*
                                                           Counters                             CNT_*
                                                           Flags                                FLG_*
                                                           Sums                                 SUM_*
                       Work Areas                          General                              WA_*




           Error Handling
                 General
•    All programs must include proper error handling to avoid undesirable terminations. This
     means that the system status (SY-SUBRC) must be checked where appropriate after
     every event in the program that changes it.
•    If there are more than two possible values for the SY-SUBRC field after a performed event,
     all expected values should be tested and handled in the program.
•    Use the CATCH/ENDCATCH statement to trap runtime errors.

Error checking requirements depend on the type of program under development. Where
possible standard SAP errors messages are utilized in developments. Custom error messages
are created where relevant SAP error messages cannot be found. It is the responsibility of
the functional requestor to define detailed error handling. Error messages used should aim
to be as meaningful as possible.
Conversions & Interfaces Error Handling
Each of the conversion and interface programs should generate an exception/error report
containing detailed record information, corresponding error message(s) and report statistics.
In addition to the error report, inbound interface and conversion programs should generate
BDC sessions for those transactions, which could not be posted to SAP successfully. These

CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 18 of 66
Coding Standard – ABAP
sessions can then be accessed by an authorized user and be processed manually in the
foreground (via transaction SM35) until those error records are posted successfully. It will be
the interface user’s responsibility to check the report to ensure that no errors have occurred.
A sequential file containing the error records can also be generated if an error occurs. The
program can be rerun using this file after fixing the errors. This file can also be used for
creating formatted reporting as well as for audit purposes.

Dialog Programming
                 General
•    If the layout of screens is the same for multiple functions (such as ADD, MOVE, and
     DELETE), use the same screen for all functions. Use online status and security features to
     control which function is executed.

•    Define all global data in the main program module instead of the PBO/PAI.

•    To handle a lock entry failure, raise an error message (type E) preventing any further
     progress but leaving the user on the current screen. The user can take an alternative
     action or continue to try to lock the object. To minimize the impact on users, limit retries.

•    When activating buttons or boxes, activate the associated text as well. This enables the
     user to click on the either button/box or the text.

•    For additional standards, see the SAP online documentation, “SAP Styleguide”.


                 Naming
•    For online programs, the initial screen should always be 9000. Screen numbering should
     follow functionality. For example:
               9000 - Initial
               9100 – Block 1
               9110 - Sub-functionality of Block 1
               9120 - Sub-functionality of Block 1
               Etc....


•    Use Data Dictionary names (short, medium, long) for field text on screens where
     applicable.

•    Use SAVE_OK_CODE as the field name when saving the OK Code field. It is
     recommended that you use a backup version of the OK Code field to avoid sending a
     screen that already has a function code.

•    Always define the field with a Format = OK as OK_CODE. This field is used to validate the
     OK Event.

•    Prefix radio buttons with RB_, push buttons with PB_, and check boxes with CB_.




           Report Programs

CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 19 of 66
Coding Standard – ABAP
•      The only report screen is 1000, which is automatically assigned by SAP.

•      When using the WRITE command, constants should be defined as Text Elements.
       Hardcoded character strings should NOT be used alone. Text elements should be
       defined and used in the WRITE command in addition to a corresponding string value. This
       technique ensures accuracy of output by using text elements, while improving readability
       of the program.

•      For list reports, include the following information to give users a clear indication as to what
       the report consists of. For example:
           - End-User Reports: selection criteria, entries found, requester, report name, date/time,
           exceptions, parameters, etc.
           - Conversion/Interface Reports: number of records read, number of records
           processed, number of records written, date/time, transactions posted, etc.


           Program Structure

ABAP is an event driven programming language. However, proper program structure and
modular coding is still important to maintain readability and efficiency of an ABAP program.
A program should be divided into distinct sections that are properly documented in the
code. Whenever possible, it is sensible to use function modules already available instead of
creating new ones. Refer to the program template in the Appendices section for the proper
order and structure of your program.
Forms should not be too long to help ensure modularity and for ease of following the
program logic.
All forms should be in the order they are first called. Using the letter F and a number code to
identify related forms can help facilitate this.
E.g.
       perform f1000_intialisation.
       perform f2000_main_processing.


       form f2000_main_processing.
       perform f2100_modify_data.
       perform f2200_calculation.
       endform.

Note: If a form contains very general functionality that could be used in other programs, it
may be useful to create it as a function module.

           Readability

•      Start each new command or clause on a new line. Do not put multiple commands on
       the same line.
•      If a statement continues past one line, indent all subsequent lines.
•      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


CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 20 of 66
Coding Standard – ABAP
•         Project Standard Form headings. Add appropriate form description to these headings.
          Note: “Pretty Printer” creates SAP Form headings if no comment lines exist after previous
          ABAP statement.


                  Authorizations & Security

As a rule, authorization checks should be used whenever appropriate to verify the access
level of the user executing the program. Please see the Portal Integration team document
on security & authorizations for ABAP development.



                  Performance Considerations
                              Database Selections
The 3-tier architecture of SAP distributes workload across the servers (presentation,
application, and database). The majority of the work takes place on the application and
database servers. There is an obvious limit on capacity; this means that if not managed
correctly the database server can become a major bottleneck. Applications developers
should aim, for performance reasons, to migrate the majority of processes to the application
servers and to be as efficient as possible when accessing the database server.

This can be achieved in a number of ways. In order to improve performance times wherever
possible the number of database accesses made by a program should be kept to a
minimum. The contents of tables can be selected into internal tables (tables local to the
program) and used for reference during the program execution rather than using the
SELECT...ENDSELECT logic (see diagram below).


                                           Application Server
 Select               VBELN                                              Select                   VBELN
                      POSNN                                                                       POSNN
 From                 VBFA                                               into table               I_VBFA
 Where                VBELV        = S_DOC_NUMBER                        From                     VBFA
 And                  POSNV        = S_ITEM_NO                           Where                    VBELV       = S_DOC_NUMBER
                                                                         And                      POSNV       = S_ITEM_NO
 Move:                VBFA-VBELN           to I_VBFA-VBELN,
                      VBFA-POSNN           to I_VBFA-POSNN.
 Append I_VBFA.

 Endselect.


           Multiple                                                                      Single
          Database                                                                    Database
          Accesses                                                                    Accesses




                               VBFA                           Database                                     VBFA

The typical procedure would be to select relevant fields from the table into an internal table
at the event START-OF-SELECTION. In this example only those records of the sales document
flow table (VBFA), which fall within the selection criteria are selected into an internal table.
CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 21 of 66
Coding Standard – ABAP
Internal tables are generally quicker than using field-groups for small volumes of data
(although they are less flexible for sorting, especially for a large volume of data records).
Field groups should be used if there is a high number of data records that would need to be
processed (e.g. 100+ records). Field groups use memory space on the application server
that does not impede processing space for other applications. Field groups are also more
efficient in their storage handling because the data is compressed before being stored.



In addition, a number of additional principles should be adhered to for efficient coding:


• Where possible fields should be specified rather than SELECT *.

• When accessing pool and cluster tables, these should be accessed using the full primary
  key.

• Avoid placing a ‘SELECT’ or ‘SELECT SINGLE’ in a loop to minimize the number of database
  requests.

• Avoid using ‘SELECT...INTO CORRESPONDING FIELD’, as the associated overhead with
  corresponding field could be significant.

• The number of records retrieved should be limited using the ‘WHERE’ clause rather than
  selecting and using the ‘CHECK’ statement.

•    Fields should be listed in the WHERE clause in the same order as they appear in the table.
• Where possible the ‘AGGREGATE’ function should be used rather than ‘SELECT…’ and
  then do the manipulation.

• When defining internal tables the use of include-structures should be avoided.

• Minimize database accesses. Keep the number of communication processes between
  the database and application servers, as well as the transferred dataset as small as
  possible.

• Do the most restrictive calls first. For example, to process all materials with a quantity-at-
  hand above 50, the tables containing stock quantities should be read before the material
  master tables.

• Always check for the DELETION FLAG on key master data tables (i.e., KNA1, KNVV,
    MARA…). Deletion flags are usually named LOEVM, LOEKZ, LVORM, etc.

• Do not use Order By clause on non-key or non-indexed fields. Bring the data into an
  internal table with a single call and then sort the internal table. This relieves the database
  of the additional sort requirement and utilizes the processing and memory of the
  application server.

• In all cases look to decrease the number of database calls. Whenever possible issue calls
  to retrieve all records into an internal table. Do the processing using the internal table.




CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 22 of 66
Coding Standard – ABAP
    • Nested selects should be avoided as they result in a large volume of database accesses
         (dependent on size of tables). Where further database accesses depend on data stored
         in an internal table the following syntax can be used:
              IF NOT ITAB1 [] IS INITIAL
              Select               FIELD1
                                   FIELD2
              From                 TABLE
              Into table           ITAB2
              For all Entries inITAB1
              Where                FIELD3               = ITAB1-FIELD3
              And                  FIELD4               = S_FIELD.
              ENDIF.
    •     In a SELECT statement, the HAVING clause allows you to specify a logical condition for
          the groups in a GROUP-BY clause. Effective use of the having clause can reduce the set
          of data transferred from the database to the application server. When the having clause
          is used, the aggregates and groups are constructed in the database instead of the
          application server, thereby reducing the resulting set.
    •     When creating a program that writes new or update existing records you MUST secure
          that your program handles COMMIT at a reasonable frequency. As a general rule, you
          should do a commit every 1000 or 10 000 records. If your program is running for a long
          period of time without doing a commit, the data base and finally the whole system will
          be deadlocked and eventually shutting down the system is the only option left to
          terminate the execution as all resources are consumed by your program.
         If multiple inserts must be made to a table, inserting an array from a table, rather than
         performing multiple inserts of single records will improve performance. For example:
              INSERT CUST FROM TABLE TAB.
    Will be more efficient than:
              LOOP AT TAB.
                    MOVE-CORRESPONDING TAB TO CUST.
                    INSERT CUST.
              ENDLOOP.


•       Open SQL is SAP’s version of SQL and is designed to work with most RDBMS Systems
        (Relational Database Management Systems). Avoid using any native SQL features that are
        not documented or used in Open SQL.
•       You can specify as many WHERE conditions as you like in all types of database tables –
        i.e. transparent tables, pool tables and cluster tables. However, you should be aware for
        performance reasons that complex WHERE conditions involving pool and cluster tables
        usually cannot be passed to the database system. They must be processed by the SAP
        database interface through post-selection.
•       Use secondary index / Create secondary index if accessing a database table with
        non-key fields depending on the frequency of usage and volume of data accessed.



    CS_ABAPCDS – Version 2.0

    Select the document classification as per the defined classification in the master list of documents’ for your project
    <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 23 of 66
Coding Standard – ABAP
•          Use of total key is preferred in search criteria. If you can not give total key and you can
        give former part of key, still the select is effective. If you are specifying later part of key then
        it is equivalent to non-key field which is not effective.

•       When a full key is unknown and only one record is needed, the UP TO 1 ROWS append is
        added to the SELECT statement.

•       When using the AND OR operator the most likely elimination criteria is specified first.
        (Expressions are evaluated left to right and the evaluation ends when the final result has
        been established)




    ABAP Statements
    Compute and Move Statement
    Use operators (+, -, *, /) in the form of “pctocc = seatsocc / seatsmax” instead of the COBOL
    form of “Divide seatsocc by seatsmax giving pctocc”.
    Use the = sign in the form of “J_4KRCAT_I = VBAP_I-J_4KRCAT” instead of the COBOL MOVE
    statement “MOVE VBAP_I-J_4KRCAT TO J_4KRCAT_I”.

    Compare Operators
    Use compare operators (=, <, >, <>) instead of EQ, NE, LT, GT

    Avoid ‘Hard Coding’

    RULE OF THUMB: Use constants rather than ‘hard coding’ when:

    •     It adds value to the code and is named informatively.
    •     It is defined in the standard include.

    Incorrect:
      CONSTANTS: C_SA                  LIKE BKPF-BLART VALUE 'SA',
                 C_DR                  LIKE BKPF-BLART VALUE 'DR',
                 C_DG                  LIKE BKPF-BLART VALUE 'DG',
                 C_KR                  LIKE BKPF-BLART VALUE 'KR',
                 C_KG                  LIKE BKPF-BLART VALUE 'KG',
                 C_AC                  LIKE BKPF-BLART VALUE 'AC',
                 C_O                   LIKE T001B-RRCTY VALUE '0'.

    IF rs_header-document_type = C_SA OR
        rs_header-document_type = C_DR OR
        rs_header-document_type = C_DG OR
        rs_header-document_type = C_KR OR
        rs_header-document_type = C_KG OR
        rs_header-document_type = C_AC OR
        rs_header-document_type = C_O.
    ...

    Correct:
       CONSTANTS: C_GL_ACCOUNT_DOC       LIKE BKPF-BLART VALUE 'SA',
                  C_CUSTOMER_INVOICE     LIKE BKPF-BLART VALUE 'DR',
                  C_CUSTOMER_CREDIT_MEMO LIKE BKPF-BLART VALUE 'DG',
                  C_VENDOR_INVOICE      LIKE BKPF-BLART VALUE 'KR',
    CS_ABAPCDS – Version 2.0

    Select the document classification as per the defined classification in the master list of documents’ for your project
    <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 24 of 66
Coding Standard – ABAP
                       C_VENDOR_CREDIT_MEMO                      LIKE BKPF-BLART VALUE 'KG',
                       C_ACCRUALS                                LIKE BKPF-BLART VALUE 'AC'.

 IF RS_HEADER-DOCUMENT_TYPE = C_GL_ACCOUNT_DOC      OR
    RS_HEADER_DOCUMENT_TYPE = C_CUSTOMER_INVOICE     OR
    RS_HEADER_DOCUMENT_TYPE = C_CUSTOMER_CREDIT_MEMO OR
    RS_HEADER_DOCUMENT_TYPE = C_VENDOR_INVOICE       OR
    RS_HEADER_DOCUMENT_TYPE = C_VENDOR_CREDIT_MEMO OR
    RS_HEADER_DOCUMENT_TYPE = C_ACCRUALS.
...

OR this is also correct:

IF RS_HEADER-DOCUMENT_TYPE                     = ‘SA’ OR      “GL_ACCOUNT_DOC
  RS_HEADER_DOCUMENT_TYPE                      = ‘DR’ OR      “CUSTOMER_INVOICE
  RS_HEADER_DOCUMENT_TYPE                      = ‘DG’ OR      “CUSTOMER_CREDIT_MEMO
  RS_HEADER_DOCUMENT_TYPE                      = ‘KR’ OR      “VENDOR_INVOICE
  RS_HEADER_DOCUMENT_TYPE                      = ‘KG’ OR       “VENDOR_CREDIT_MEMO
  RS_HEADER_DOCUMENT_TYPE                      = ‘AC’.         “ACCRUALS




CASE VS. IF/ELSE: Which to use when both would work?

IF/ELSE RULE OF THUMB

Use the IF/ELSE rather than the CASE statement when there is only one condition.
Example:
IF T_DETAIL-BSCHL = C_POSTING_KEY_70.
   <action 1>.
ELSE.
   <action 2>.
ENDIF.



CASE RULE OF THUMB

Use the CASE statement rather than IF/ELSEIF statement when there are multiple conditions.
Example:
CASE T_DETAIL-BSCHL.
  WHEN C_POSTING_KEY_70.
      <action 1>.
  WHEN C_POSTING_KEY_75.
      <action 2>.
  WHEN OTHERS.

CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 25 of 66
Coding Standard – ABAP
      <action 3>.
ENDCASE.


Note: ‘WHEN OTHERS’ always requires generic error processing.
Incorrect:
CASE sy-subrc.
  WHEN 1.
      MESSAGE ID ‘ZSD’ TYPE ‘E’ NUMBER ‘100’.
  WHEN 2.
      MESSAGE ID ‘ZSD’ TYPE ‘E’ NUMBER ‘101’.
  WHEN OTHERS.
* No action required
ENDCASE.


Correct:
CASE sy-subrc.
  WHEN 1.
      MESSAGE ID ‘ZSD’ TYPE ‘E’ NUMBER ‘100’.
  WHEN 2.
      MESSAGE ID ‘ZSD’ TYPE ‘E’ NUMBER ‘101’.
  WHEN OTHERS.
      MESSAGE ID ‘ZSD’ TYPE ‘E’ NUMBER ‘102’.
ENDCASE.
If you are using CHECK or EXIT statements, be careful while considering any required follow-
on processing, e.g. a failed CHECK statement in the START-OF-SELECTION event of a program
causes the program to move directly to END-OF-SELECTION processing.


Break Levels in Loop Statements

Inside Loops the preferred way of recognizing changes is AT....ENDAT.                                      Avoid using On
Change Of statement. There's a difference between these statements.

AT ..... ENDAT

This statement is triggered based on any change in the field specified and any change in a
previous field inside the structure. Note: All character fields on the right are filled with * after
the current control level key. See SAP Help for more information.

ON CHANGE OF



CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 26 of 66
Coding Standard – ABAP
This statement is specific to a single field. Using this statement can cause unpredictable
results.

Internal Tables
Defining internal tables
When defining a table using occurs the ‘occurs’ statement allocates an area in memory of
the specified size. It is generally accepted as preferable, to declare a type (for custom
structures) or use the database structure and use syntax ’standard table of’ to define an
internal table.
Internal tables should be defined, whenever possible, without header lines. It improves
readability to use work areas instead when processing internal tables.
Incorrect:
   DATA: BEGIN OF T_MAT OCCURS 0,
            MATNR LIKE MARA-MATNR,
            WERKS LIKE MARC-WERKS,
            DISPO LIKE MARC-DISPO,
           END OF TYPE_MAT.

Correct:
   TYPES: BEGIN OF TYPE_MAT,
           MATNR LIKE MARA-MATNR,
           WERKS LIKE MARC-WERKS,
            DISPO LIKE MARC-DISPO,
          END OF TYPE_MAT.

     DATA: IT_MAT TYPE STANDARD TABLE OF TYPE_MAT,
       WA_MAT TYPE TYPE_MAT.

Always use Work Areas while processing internal tables.
   LOOP AT IT_MAT INTO WA_MAT.
   ENDLOOP.
      (OR)
Use Field symbols on LOOP/READ statements as it is easier to modify the internal table entry
and also avoids the usage of MODIFY statements.


Sorting internal tables

When sorting internal tables, specify the fields to SORT on.
SORT ITAB BY FLD1 FLD2. Is more efficient than SORT ITAB.
       (OR)
Instead of using SORT table itab with matnr use, SORTED table with table key matnr
The access type of an internal table defines the way in which ABAP accesses the individual
table entries. There are three access types: Standard, Sorted, and Hashed.
DELETE ADJACENT DUPLICATES statement should always be used with specific sort /
comparison fields.

Incorrect:
DELETE ADJACENT DUPLICATES FROM T_DOCUMENT.
CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 27 of 66
Coding Standard – ABAP
Correct:
DELETE ADJACENT DUPLICATES FROM T_DOCUMENT COMPARING VBELN VBELP.

Note: Internal Tables should be always sorted before using DELETE ADJACENT DUPLICATES.


Standard Internal Tables
Standard tables have a linear index. You can access them using either the index or the key. If
you use the key, the response time is in linear relationship to the number of table entries. The
key of a standard table is always non-unique, and you may not include any specification for
the uniqueness in the table definition.
This table type is particularly appropriate if you want to address individual table entries using
the index. This is the quickest way to access table entries. To fill a standard table, append
lines using the (APPEND) statement. You should read, modify and delete lines by referring to
the index (INDEX option with the relevant ABAP command). The response time for accessing
a standard table is in linear relation to the number of table entries. If you need to use key
access, standard tables are appropriate if you can fill and process the table in separate
steps. For example, you can fill a standard table by appending records and then sort it. If you
then use key access with the binary search option (BINARY), the response time is in
logarithmic relation to the number of table entries.


Sorted Internal Tables
Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like
standard tables, you can access them using either the table index or the key. When you use
the key, the response time is in logarithmic relationship to the number of table entries, since
the system uses a binary search. The key of a sorted table can be either unique, or non-
unique, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard
tables and sorted tables both belong to the generic group index tables.
This table type is particularly suitable if you want the table to be sorted while you are still
adding entries to it. You fill the table using the (INSERT) statement, according to the sort
sequence defined in the table key. Table entries that do not fit are recognized before they
are inserted. The response time for access using the key is in logarithmic relation to the
number of table entries, since the system automatically uses a binary search. Sorted tables
are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition
contains the beginning of the table key.
DO NOT use APPEND to fill the entries of SORTED internal table.
Do NOT use SORTED tables in database SELECT statements as it would lead to a short dump if
the system tries to append the entries into the sorted internal table.


Hashed Internal Tables
Hashed tables have no internal linear index. You can only access hashed tables by
specifying the key. The response time is constant, regardless of the number of table entries,
since the search uses a hash algorithm. The key of a hashed table must be unique, and you
must specify UNIQUE in the table definition.
This table type is particularly suitable if you want mainly to use key access for table entries.
You cannot access hashed tables using the index. When you use key access, the response
time remains constant, regardless of the number of table entries. As with database tables,
the key of a hashed table is always unique. Hashed tables are therefore a useful way of
constructing and using internal tables that are similar to database tables.

CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 28 of 66
Coding Standard – ABAP
DO NOT use APPEND to fill the entries of HASHED internal table.
Collect
The COLLECT statement is used to create a unique dataset.
To fill a standard internal table without creating duplicate entries and add up the Packed,
Integer, and Floating Point fields at the same time, use:
    COLLECT itab.
This is only recommended for tables for which you expect approximately 50 entries or less.
The COLLECT statement scans the table sequentially for a match on all fields that do not
have a data type of Packed, Integer, or Floating-Point. Hence it is can be resource
expensive for larger tables.
When dealing with larger internal tables, it is more efficient to READ the internal table with
key, and then perform an INSERT or MODIFY statement on the table depending on the return
code.
Other ways to create unique datasets are to fill an internal table with all entries SORT it then
use the statement ‘DELETE ADJACENT DUPLICATES’. (This statement is much more efficient
than deleting using a LOOP structure that would achieve the same effect).

ABAP List Viewer


A call back FORM in List Viewer should not be called the same name as an ABAP event or
keyword.

i.e. rt_events-form = 'TOP_OF_PAGE'.


Incorrect:
*&---------------------------------------------------------------------*
*&      Form DEFINE_EVENTS
*&---------------------------------------------------------------------*
* This form defines the events for display list
*----------------------------------------------------------------------*
*     <--RT_EVENTS Event table
*----------------------------------------------------------------------*
FORM define_events TABLES rt_events LIKE t_events.

 rt_events-name = slis_ev_top_of_page.
 RT_EVENTS-FORM = 'TOP_OF_PAGE'.
 APPEND rt_events.
ENDFORM.                   " DEFINE_EVENTS


Correct:
*&---------------------------------------------------------------------*
*&      Form DEFINE_EVENTS
*&---------------------------------------------------------------------*
* This form defines the events for display list
*----------------------------------------------------------------------*
*     <--RT_EVENTS Event table
*----------------------------------------------------------------------*
FORM define_events TABLES rt_events LIKE t_events.


CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 29 of 66
Coding Standard – ABAP
 rt_events-name = slis_ev_top_of_page.
 rt_events-form = 'PROCESS_TOP_OF_PAGE'.
 APPEND rt_events.
ENDFORM.                   " DEFINE_EVENTS


ABAP Queries

ABAP Queries should not be used in production. A query generates a program which must
be reviewed by ABAP COE. The generated program must have the following disciplines in
place:

     •    Program Header is required
     •    Program Name should end with '_Query'
     •    If a key field statement is being used in a Where statement in SQL, then the field must
          be made mandatory on the selection screen so that Index scan is forced rather than
          a table scan.

SAPScript Coding Standards


Print Program

Print Program - Header
 At the top of each print program include the header text.

Print Program and Form (Layout Set) Combinations
SAP allows multiple print programs to call one form layout. To reduce complexity and
maintenance a newly enhanced form layout should have its own enhanced print program
that calls this form. Here are some examples of the Print Program(s) on the left that calls the
Form on the right:
Example 1:

          Print Program #1 - change                           Form #1 - change
          Print Program #2 - no change

          becomes

          ZPrint Program #1 - changed                         ZForm #1 - changed
          Print Program #2 - no change                        Form #1 - no change


Example 2:

          Print Program #1 - change                           Form #1 - change
                                                              Form #2 - no change
          becomes

          ZPrint Program #1 - changed                         ZForm #1 - changed
          Print Program #1 - no change                        Form #2 - no change




CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 30 of 66
Coding Standard – ABAP
 Form Painter - Adding and Deleting Windows
When adding a window to a page use 'Z' as the first letter of the window name. You can
delete windows from pages that are no longer being used by the print program. Delete
windows when it is necessary to reduce clutter within the form and to make future
maintenance less complex. Do not use the Graphical Form Painter to delete windows since
this editor permanently deletes the window from the form. Use the older non-graphical form
painter to remove the Window from Page Windows (the window will still remain in the form).
You are then required to document the deleted window name in the Documentation
section of the form.
Form Painter - Delete Lines
For program enhancements within a window refer to 3.1.6. You can only delete lines in
blocks as shown below.
/*63-JWILMO-20000204 begin: delete
/*&REGUH-NAME1&
/*63-JWILMO-20000204 end: delete
Form Painter - Elements
Within a window, do not change the element name/number that is being called a print
program. If the element is no longer being used by the print program (or other print
programs), you can comment out the code ‘deleted/comment out elements' clause shown
below. However, do no comment out the element itself. If more than one block of elements
can be commented out you can begin at the top of the first element and end at the bottom
of the last element as shown in elements 512 and 513 below.
/*63-JWILMO-20000204 begin: delete/comment out elements
512

/*The items listed below are managed on the following account:
/*&REGUH-NAME1&

/*&REGUH-STRAS&
513

/*------------------ Heading ---------------------------------------------
/*&ULINE(71)&

/*<K>Document,,Your document,,Date,,,,Deductions,,Gross amount</>
/*<K>Number,,Date,,Text</>

/*63-JWILMO-20000204 end: delete/comment out elements




Standards for all Enhancement User Exits


     •    Always create a new separate include for each Gap in a SAP Enhancement exit
          Separate User Exits allow enable the independent migration of code as part or the
          promote-to-production path

     •    Using the EXIT statement will terminate processing for all subsequent user exits
CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 31 of 66
Coding Standard – ABAP
     •    The use of memory pointers in order to overcome User Exit Interface limitations is not
          permitted

          FIELD-SYMBOLS: <F>                        TYPE STANDARD TABLE.

          ASSIGN ('(SAPMV56A)XVTTP[]') TO <F>.
          T_XVTTP = <F>.

The variable XVTTP accessed in this example is not within the regular data scope of the
current program. In order to overcome this limitation and we are using the 'Assign' statement
against a specific memory location. During the execution of the VOFM we have no control
of the availability of this memory location. The SAP Interpreter basically searches all available
memory areas for the specified name and returns the value found in the first location - that's
a solution that's very difficult to maintained going forward - Any OSS note or external
transport could affect the availability of specific variables in SAP Memory – this is
unacceptable.

DO NOT use CHECK statements in User-exits instead use IF….ENDIF

Custom BAPI Development


BAPI must be part of the Business Object Repository (BOR). Use Business Object Builder (BOB –
Transaction SWO1) to associate a BAPI with a Business Object.

Naming Convention for custom BAPI’s is ZBAPI_objectname_method name i.e.
ZBAPI_COMPANYCODE_GETDETAIL.

Do not use BAPI in a report program if you require a few fields. Instead make use of select
statement. If its an online transaction program or you will be needing most of the fields then
using BAPI is OK.

BAPI Interface consists of Import and Export only. No Tables and no Exceptions should be
used in the BAPI Interface.
All messages need to be returned to the calling program via Return Structures:
        BAPIRET1 or BAPIRETURN
        BAPIRET2

Adding a BAPI to an existing SAP object should be done using Subtypes and should not have
a Z* as part of the naming convention. Z* is only used for BAPI's belonging to custom objects.

All messages that can be issued by a BAPI MUST be listed in the BAPI Documentation

Some Basic Rules:
   • Always perform database changes using the update task
   • No screen output allowed in BAPI
   • Can not cause program termination i.e. message type 'A'
   • Cannot dispatch commit work - Must useBapiService.TransactionCommit
      (Function Module BAPI_TRANSACTION_COMMIT)




CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 32 of 66
Coding Standard – ABAP
Please refer to SAP BAPI Programming Guide for more detail on programming with BAPI's. In
4.6, use transaction BAPI to get to relevant documentation. Other sources are
http://service.sap.com/bapi


Logical Databases
Logical databases can be inefficient because they can generally be thought of as nested
selects where large volumes of data as retrieved which may not exactly match report
requirements. There are, however, instances when the use of a logical database can be
justified. For instance, in Asset Management a large number of calculations are performed
which would take a large amount of time to replicate in custom code. Where a logical
database maps closely to the data required by a program it maybe justified incorporating it
into the code however checks should be made to ensure that the authority checks
performed by the logical database are sufficient.

Selection Screen Parameters
Include organizational entities (e.g. sales organization, plant) fields in the selection screen
wherever it makes sense as this can also help reduce execution time (this should be
mandatory for multiple company implementations). Use can often be made of the user
parameter IDs to bring values into a selection screen. The following is an example of how this
can be coded:


Parameters: SALES_ORG LIKE TVKOV-VKORG MEMORY ID VKO.
Frequently used parameter ID codes are:
Company Code         BUK
Sales Organization   VKO
Distribution Channel VTW
Division             SPA
Plant                WRK
Storage location     LAG
    USE SELECT-OPTIONS with NO-EXTENSION NO INTERVALS instead of PARAMETER

                   SELECT matnr into wl_matnr
                          From mara
                          Where matnr IN s_matnr.



Program Documentation

Documentation of all new ABAP developments is completed in three ways.


           Program Folder Overview
The initial development results in a program folder that is stored electronically (where
relevant).

Subsequent modifications are monitored via the project Change Control system and each
change will result in additional testing documentation clearly documenting the change.
Again, these will be stored electronically. Header details and on-line help are recorded in
the program itself.

CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 33 of 66
Coding Standard – ABAP
For all new programs, the following components make up the program folder:
1. Program Functional Specification (provided by User/Configurer/Implementation Team
    member on-site),
2. Program Technical Specification (written internally to ABAP team),
3. Commented program source code (all messages and text elements must be fully
    commented),
4. Test conditions,
5. Test plan using all test conditions,
6. Test Data used in the Test Plan,
7. Expected Results for each Test Condition in the Test Plan,
8. Actual Results generated when the Test Plan is executed,
9. ALE related interface will also require a configuration script review to validate entries
    have been added for that particular interface.
10. Program on-line help documentation.

Once a program change has been requested. The program folder also contains:
1. Copy of change request
2. Amended source code (commented where appropriate changes have been made)
3. Additional test data and results, along with test plan and test conditions.


           Source Code Documentation
All ABAP developments start with the program name followed by header documentation
relating to the purpose of the report. The program author and creation date, together with
information relating to the report user is also included. This type of header is also used for
custom-built include modules, and custom-built function modules.



Example:

************************************************************************
* 1/ Report name: Cost Centre report
************************************************************************
* 2/ Description/program functions
************************************************************************
*
* This program is a Cost Centre report, which can be sorted
* And summarized in different formats.
*
************************************************************************
* 3/ Responsibility
************************************************************************
 * Author:               A Programmer
* Creation Date:         14th February 02
* Requested by:          E User
* Reference document: (design document)
* Owner:                 Controlling
* Project:               A Project
************************************************************************
* 4/ External References
************************************************************************
*

CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 34 of 66
Coding Standard – ABAP
* Include modules, input files etc.
*
************************************************************************
REPORT ZKEVR034 NO STANDARD PAGE HEADING
            LINE-SIZE 132
            LINE-COUNT 65
            MESSAGE-ID ZE.

Within the code comments are added as necessary to ensure that the code is clear,
readable and maintainable.


                 On-line Help
On-line help will accompany all on-line programs. This is held in the Documentation element
of the ABAP program. Four sections are usually populated by default and details for each
are:

Description: an overview of what the program does (and who the program is intended for).
Parameters: an explanation of the select options where appropriate.
Output:an explanation of the different output options where appropriate

This documentation can then be accessed by the user via the Help / Extended Help menu
path when running the program.


                 Program Attributes
In addition to the title an ABAP report should be given the following attributes:
Type:           e.g.     1 (Reporting)         (as appropriate)
Status:                  K (Customer program)
Application:             S (Basis)             (as appropriate)

It is not normally necessary to assign the program to a class but it can be important that an
Authorization Group is assigned. This is to ensure that the program can be properly secured
but is the responsibility of client authorization specialists to review.


                 Program Modifications
Any changes that are made to a program (because a problem has been identified or
because further enhancements are required) are carefully documented in the code (as well
as in the program folder).   A summary of the change is included in the header
documentation of the code, immediately below the author details.

*************************************************************************
* Revised by:            A Programmer
* Change Date:           14/2/02
* Change Request:        00001
* Description:           Addition of the document type Invoice
*                        Cancellation (N) to the program selection
* OSS Note:              00001 (If required)
* Changes identified by: XD1 S00K900001
************************************************************************

The CR (Change Request) number from the Change Request system should be entered so
the change details can be referenced, as should the SAP System and Correction number
relating to the change.
CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 35 of 66
Coding Standard – ABAP
Code which needs to be changed is not removed but preceded by '*' to remain as
comment. Any section changed is surrounded with some form of documentation and
commented as normal. The SAP correction and transport number is used to identify each line
which change the code applies to, as illustrated in the following example:


* Code commented out by A. Programmer 14/02/02 to implement change to add
* Doc type invoice cancellation (N) to Credit memo (O) and Debit memo (P)
* IF VBRK-VBTYP = 'O' OR VBRK-VBTYP = 'P'.        “XD1 S00K900001
 CLEAR MAKE_NEGATIVE.                             “XD1 S00K900001
 IF VBRK-VBTYP = 'O'.                      “XD1 S00K900001
   MAKE_NEGATIVE = 'Y'.                           “XD1 S00K900001
 ENDIF.                                           “XD1 S00K900001
* End of code commented out by A. Programmer 12/09/98.




           Program Testing
All code is thoroughly Unit Tested before it is submitted for User Testing. The testing strategy is
documented by two documents:
• Test Conditions      - details what conditions will be tested.
• Test Plan            - details how the conditions will be tested
Test Conditions
Before coding, all conditions that will require testing are defined from the Functional
Specification. Obviously, as each program differs in its output, it therefore has a set of test
conditions unique to itself. However, there are common features to most programs and test
conditions that are of general application. The following test conditions (which cannot
necessarily be tested on the same test run) are typical:
Selection screen
        Selection screen contains a range of sales organization/plant/division boxes.
        Selection screen contains a single parameter box for currency, defaulting to the
user’s parameter ID setting for currency.
        Currency parameter box cannot be left blank.

Selection
        Report selects within range of sales organizations/plants/divisions specified.
        Report selects a single value of sales organization.
        Report doesn’t select outside the specified ranges.
        Report verifies that the currency entered in the parameter box is a valid value.
        Report terminates if the user attempts to view documents for which there is no
        authorization.

Report header
       Report header displayed correctly once at the top of each page of the report.
       Report selections displayed correctly on first page beneath report header.
       Column headers displayed correctly once at the top of each page of the report.

Report layout
        Detail lines formatted correctly.
        Report is sorted correctly by sales organization, customer...
        A new page is started for each new plant/sales org/customer/material...
        Full fields are displayed correctly

CS_ABAPCDS – Version 2.0

Select the document classification as per the defined classification in the master list of documents’ for your project
<VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC>                                             Page 36 of 66
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards
Abap coding standards

More Related Content

What's hot

Sap mrp-configuration-pp
Sap mrp-configuration-ppSap mrp-configuration-pp
Sap mrp-configuration-ppLokesh Modem
 
Functional specification doc Gst purcahse register
Functional specification doc Gst purcahse registerFunctional specification doc Gst purcahse register
Functional specification doc Gst purcahse registerLokesh Modem
 
Abap object-oriented-programming-tutorials
Abap object-oriented-programming-tutorialsAbap object-oriented-programming-tutorials
Abap object-oriented-programming-tutorialscesarmendez78
 
Sap pp shop floor control configuration
Sap pp   shop floor control configurationSap pp   shop floor control configuration
Sap pp shop floor control configurationVikranth Ikkalaki
 
Enhancement technique how to use validations
Enhancement technique how to use validationsEnhancement technique how to use validations
Enhancement technique how to use validationsUgeshkumarnetha Dasari
 
Sap MM-configuration-step-by-step-guide
Sap MM-configuration-step-by-step-guideSap MM-configuration-step-by-step-guide
Sap MM-configuration-step-by-step-guideVenet Dheer
 
Mts and mto and account based copa and costing based copa
Mts and mto and account based copa and costing based copa Mts and mto and account based copa and costing based copa
Mts and mto and account based copa and costing based copa Intelligroup, Inc.
 
Funds management configuration sap ag
Funds management configuration sap agFunds management configuration sap ag
Funds management configuration sap agLluckyy
 
SAP Validation and substitution
SAP Validation and  substitution SAP Validation and  substitution
SAP Validation and substitution Hari Krishna
 
6714600 sap-production-planning-table
6714600 sap-production-planning-table6714600 sap-production-planning-table
6714600 sap-production-planning-tableSanjeev Malik
 
94757421 list-of-bapis
94757421 list-of-bapis94757421 list-of-bapis
94757421 list-of-bapisjvcss
 
Sap mm configuration document ramesh kamishetty
Sap mm  configuration document ramesh kamishettySap mm  configuration document ramesh kamishetty
Sap mm configuration document ramesh kamishettyRamesh Kamishetty
 
Sap FICO complete end user manual
Sap FICO complete end user manual Sap FICO complete end user manual
Sap FICO complete end user manual learnstraightsap
 

What's hot (20)

Sap mrp-configuration-pp
Sap mrp-configuration-ppSap mrp-configuration-pp
Sap mrp-configuration-pp
 
Functional specification doc Gst purcahse register
Functional specification doc Gst purcahse registerFunctional specification doc Gst purcahse register
Functional specification doc Gst purcahse register
 
Abap object-oriented-programming-tutorials
Abap object-oriented-programming-tutorialsAbap object-oriented-programming-tutorials
Abap object-oriented-programming-tutorials
 
Sap pp shop floor control configuration
Sap pp   shop floor control configurationSap pp   shop floor control configuration
Sap pp shop floor control configuration
 
BPD Design Template
BPD Design TemplateBPD Design Template
BPD Design Template
 
Enhancement technique how to use validations
Enhancement technique how to use validationsEnhancement technique how to use validations
Enhancement technique how to use validations
 
Sap MM-configuration-step-by-step-guide
Sap MM-configuration-step-by-step-guideSap MM-configuration-step-by-step-guide
Sap MM-configuration-step-by-step-guide
 
Dip profiles-documentation
Dip profiles-documentationDip profiles-documentation
Dip profiles-documentation
 
Sapscript
SapscriptSapscript
Sapscript
 
Mts and mto and account based copa and costing based copa
Mts and mto and account based copa and costing based copa Mts and mto and account based copa and costing based copa
Mts and mto and account based copa and costing based copa
 
Field symbols
Field symbolsField symbols
Field symbols
 
Funds management configuration sap ag
Funds management configuration sap agFunds management configuration sap ag
Funds management configuration sap ag
 
Work clearance management config and steps
Work clearance management   config and stepsWork clearance management   config and steps
Work clearance management config and steps
 
ABAP in 21 days
ABAP in 21 daysABAP in 21 days
ABAP in 21 days
 
SAP Validation and substitution
SAP Validation and  substitution SAP Validation and  substitution
SAP Validation and substitution
 
6714600 sap-production-planning-table
6714600 sap-production-planning-table6714600 sap-production-planning-table
6714600 sap-production-planning-table
 
94757421 list-of-bapis
94757421 list-of-bapis94757421 list-of-bapis
94757421 list-of-bapis
 
Sap mm configuration document ramesh kamishetty
Sap mm  configuration document ramesh kamishettySap mm  configuration document ramesh kamishetty
Sap mm configuration document ramesh kamishetty
 
SAP Smart forms
SAP Smart formsSAP Smart forms
SAP Smart forms
 
Sap FICO complete end user manual
Sap FICO complete end user manual Sap FICO complete end user manual
Sap FICO complete end user manual
 

Viewers also liked

Case Study: Automating Code Reviews for Custom SAP ABAP Applications with Vir...
Case Study: Automating Code Reviews for Custom SAP ABAP Applications with Vir...Case Study: Automating Code Reviews for Custom SAP ABAP Applications with Vir...
Case Study: Automating Code Reviews for Custom SAP ABAP Applications with Vir...Virtual Forge
 
How to extend an outbound i doc
How to extend an outbound i docHow to extend an outbound i doc
How to extend an outbound i docrupesh chouhan
 
Best Practices for Ensuring SAP ABAP Code Quality and Security
Best Practices for Ensuring SAP ABAP Code Quality and SecurityBest Practices for Ensuring SAP ABAP Code Quality and Security
Best Practices for Ensuring SAP ABAP Code Quality and SecurityVirtual Forge
 
10 GOLDEN RULES FOR CODING AUTHORIZATION CHECKS IN ABAP
10 GOLDEN RULES FOR CODING AUTHORIZATION CHECKS IN ABAP10 GOLDEN RULES FOR CODING AUTHORIZATION CHECKS IN ABAP
10 GOLDEN RULES FOR CODING AUTHORIZATION CHECKS IN ABAPVirtual Forge
 
ABAP Test & Troubleshooting @SITMuc 2013
ABAP Test & Troubleshooting @SITMuc 2013ABAP Test & Troubleshooting @SITMuc 2013
ABAP Test & Troubleshooting @SITMuc 2013SbgMartin
 
ITSS Trainning | Curso de SAP ABAP Foundations
ITSS Trainning | Curso de SAP ABAP FoundationsITSS Trainning | Curso de SAP ABAP Foundations
ITSS Trainning | Curso de SAP ABAP FoundationsCharles Aragão
 
Abap query
Abap queryAbap query
Abap querybrtkow
 
Abap 7 02 new features - new string functions
Abap 7 02   new features - new string functionsAbap 7 02   new features - new string functions
Abap 7 02 new features - new string functionsCadaxo GmbH
 
Comandos e funções em abap
Comandos e funções em abapComandos e funções em abap
Comandos e funções em abapalienscorporation
 
Funções - Tutorial ABAP
Funções - Tutorial ABAPFunções - Tutorial ABAP
Funções - Tutorial ABAPRicardo Ishida
 
Manikanta Sai Kumar Karri SAP ABAP and OO ABAP 3 Years.doc
Manikanta Sai Kumar Karri SAP ABAP and OO ABAP 3 Years.docManikanta Sai Kumar Karri SAP ABAP and OO ABAP 3 Years.doc
Manikanta Sai Kumar Karri SAP ABAP and OO ABAP 3 Years.docmanikanta sai kumar karri
 
SAP ABAP Proxy Objects: Configuración del entorno
SAP ABAP Proxy Objects: Configuración del entornoSAP ABAP Proxy Objects: Configuración del entorno
SAP ABAP Proxy Objects: Configuración del entornoOreka IT
 

Viewers also liked (20)

Case Study: Automating Code Reviews for Custom SAP ABAP Applications with Vir...
Case Study: Automating Code Reviews for Custom SAP ABAP Applications with Vir...Case Study: Automating Code Reviews for Custom SAP ABAP Applications with Vir...
Case Study: Automating Code Reviews for Custom SAP ABAP Applications with Vir...
 
How to extend an outbound i doc
How to extend an outbound i docHow to extend an outbound i doc
How to extend an outbound i doc
 
Naming Conventions
Naming ConventionsNaming Conventions
Naming Conventions
 
Best Practices for Ensuring SAP ABAP Code Quality and Security
Best Practices for Ensuring SAP ABAP Code Quality and SecurityBest Practices for Ensuring SAP ABAP Code Quality and Security
Best Practices for Ensuring SAP ABAP Code Quality and Security
 
10 GOLDEN RULES FOR CODING AUTHORIZATION CHECKS IN ABAP
10 GOLDEN RULES FOR CODING AUTHORIZATION CHECKS IN ABAP10 GOLDEN RULES FOR CODING AUTHORIZATION CHECKS IN ABAP
10 GOLDEN RULES FOR CODING AUTHORIZATION CHECKS IN ABAP
 
Web dynpro for abap
Web dynpro for abapWeb dynpro for abap
Web dynpro for abap
 
ABAP Test & Troubleshooting @SITMuc 2013
ABAP Test & Troubleshooting @SITMuc 2013ABAP Test & Troubleshooting @SITMuc 2013
ABAP Test & Troubleshooting @SITMuc 2013
 
ITSS Trainning | Curso de SAP ABAP Foundations
ITSS Trainning | Curso de SAP ABAP FoundationsITSS Trainning | Curso de SAP ABAP Foundations
ITSS Trainning | Curso de SAP ABAP Foundations
 
Abap query
Abap queryAbap query
Abap query
 
Analista programador SAP ABAP IV
Analista programador SAP ABAP IVAnalista programador SAP ABAP IV
Analista programador SAP ABAP IV
 
Qué es abap
Qué es abapQué es abap
Qué es abap
 
Icones - ABAP
Icones - ABAPIcones - ABAP
Icones - ABAP
 
View - Tutorial ABAP
View - Tutorial ABAPView - Tutorial ABAP
View - Tutorial ABAP
 
Abap 7 02 new features - new string functions
Abap 7 02   new features - new string functionsAbap 7 02   new features - new string functions
Abap 7 02 new features - new string functions
 
Comandos e funções em abap
Comandos e funções em abapComandos e funções em abap
Comandos e funções em abap
 
Sap abap Q&A
Sap abap Q&A Sap abap Q&A
Sap abap Q&A
 
Funções - Tutorial ABAP
Funções - Tutorial ABAPFunções - Tutorial ABAP
Funções - Tutorial ABAP
 
Basic abap oo
Basic abap ooBasic abap oo
Basic abap oo
 
Manikanta Sai Kumar Karri SAP ABAP and OO ABAP 3 Years.doc
Manikanta Sai Kumar Karri SAP ABAP and OO ABAP 3 Years.docManikanta Sai Kumar Karri SAP ABAP and OO ABAP 3 Years.doc
Manikanta Sai Kumar Karri SAP ABAP and OO ABAP 3 Years.doc
 
SAP ABAP Proxy Objects: Configuración del entorno
SAP ABAP Proxy Objects: Configuración del entornoSAP ABAP Proxy Objects: Configuración del entorno
SAP ABAP Proxy Objects: Configuración del entorno
 

Similar to Abap coding standards

Sap mm configuration_step_by_step_guide
Sap mm configuration_step_by_step_guideSap mm configuration_step_by_step_guide
Sap mm configuration_step_by_step_guideigosnell
 
Saptableref[1]
Saptableref[1]Saptableref[1]
Saptableref[1]mpeepms
 
1 purpose of the document6
1 purpose of the document61 purpose of the document6
1 purpose of the document6Ngọc Trần
 
Mastering Oracle PL/SQL: Practical Solutions
Mastering Oracle PL/SQL: Practical SolutionsMastering Oracle PL/SQL: Practical Solutions
Mastering Oracle PL/SQL: Practical SolutionsMURTHYVENKAT2
 
Relazione forno orizzontale
Relazione forno orizzontaleRelazione forno orizzontale
Relazione forno orizzontaleALESSANDRO LOTTI
 
An c xml_punchout_implementation
An c xml_punchout_implementationAn c xml_punchout_implementation
An c xml_punchout_implementationNand Singh
 
Span derivés gb_200802 _2__tcm6-44568
Span derivés gb_200802 _2__tcm6-44568Span derivés gb_200802 _2__tcm6-44568
Span derivés gb_200802 _2__tcm6-44568stratforcms
 
IPO process in Bangladesh and performance analysis
IPO process in Bangladesh and performance analysisIPO process in Bangladesh and performance analysis
IPO process in Bangladesh and performance analysisSumaiya Akter
 
Ascp training manual_v1.2
Ascp training manual_v1.2Ascp training manual_v1.2
Ascp training manual_v1.2Charan Reddy
 
Global Available to Promise with SAP: Functionality and Configuration
Global Available to Promise with SAP: Functionality and ConfigurationGlobal Available to Promise with SAP: Functionality and Configuration
Global Available to Promise with SAP: Functionality and ConfigurationSandeep Pradhan
 
Oracle forms and resports
Oracle forms and resportsOracle forms and resports
Oracle forms and resportspawansharma1986
 
Canadian tax configuration in sap
Canadian tax configuration in sapCanadian tax configuration in sap
Canadian tax configuration in sapAmit Sawant
 
R3 tax interface configuration guide
R3 tax interface configuration guideR3 tax interface configuration guide
R3 tax interface configuration guideracingboat
 
R3 tax interface configuration guide
R3 tax interface configuration guideR3 tax interface configuration guide
R3 tax interface configuration guideracingboat
 
Sappress sap governance risk and compliance
Sappress sap governance risk and complianceSappress sap governance risk and compliance
Sappress sap governance risk and complianceSiva Pradeep Bolisetti
 
Product description vital qip next generation v7 2_en_feb09(1)
Product description vital qip next generation v7 2_en_feb09(1)Product description vital qip next generation v7 2_en_feb09(1)
Product description vital qip next generation v7 2_en_feb09(1)Roy Muy Golfo
 

Similar to Abap coding standards (20)

Abap
AbapAbap
Abap
 
Sap mm configuration_step_by_step_guide
Sap mm configuration_step_by_step_guideSap mm configuration_step_by_step_guide
Sap mm configuration_step_by_step_guide
 
Saptableref[1]
Saptableref[1]Saptableref[1]
Saptableref[1]
 
1 purpose of the document6
1 purpose of the document61 purpose of the document6
1 purpose of the document6
 
Mastering Oracle PL/SQL: Practical Solutions
Mastering Oracle PL/SQL: Practical SolutionsMastering Oracle PL/SQL: Practical Solutions
Mastering Oracle PL/SQL: Practical Solutions
 
plsqladvanced.pdf
plsqladvanced.pdfplsqladvanced.pdf
plsqladvanced.pdf
 
Relazione forno orizzontale
Relazione forno orizzontaleRelazione forno orizzontale
Relazione forno orizzontale
 
An c xml_punchout_implementation
An c xml_punchout_implementationAn c xml_punchout_implementation
An c xml_punchout_implementation
 
Span derivés gb_200802 _2__tcm6-44568
Span derivés gb_200802 _2__tcm6-44568Span derivés gb_200802 _2__tcm6-44568
Span derivés gb_200802 _2__tcm6-44568
 
IPO process in Bangladesh and performance analysis
IPO process in Bangladesh and performance analysisIPO process in Bangladesh and performance analysis
IPO process in Bangladesh and performance analysis
 
Ascp training manual_v1.2
Ascp training manual_v1.2Ascp training manual_v1.2
Ascp training manual_v1.2
 
Global Available to Promise with SAP: Functionality and Configuration
Global Available to Promise with SAP: Functionality and ConfigurationGlobal Available to Promise with SAP: Functionality and Configuration
Global Available to Promise with SAP: Functionality and Configuration
 
Oracle forms and resports
Oracle forms and resportsOracle forms and resports
Oracle forms and resports
 
Oracle sap
Oracle sapOracle sap
Oracle sap
 
Canadian tax configuration in sap
Canadian tax configuration in sapCanadian tax configuration in sap
Canadian tax configuration in sap
 
R3 tax interface configuration guide
R3 tax interface configuration guideR3 tax interface configuration guide
R3 tax interface configuration guide
 
R3 tax interface configuration guide
R3 tax interface configuration guideR3 tax interface configuration guide
R3 tax interface configuration guide
 
SOC/ASIC Bus Standards
SOC/ASIC Bus StandardsSOC/ASIC Bus Standards
SOC/ASIC Bus Standards
 
Sappress sap governance risk and compliance
Sappress sap governance risk and complianceSappress sap governance risk and compliance
Sappress sap governance risk and compliance
 
Product description vital qip next generation v7 2_en_feb09(1)
Product description vital qip next generation v7 2_en_feb09(1)Product description vital qip next generation v7 2_en_feb09(1)
Product description vital qip next generation v7 2_en_feb09(1)
 

Recently uploaded

kids gpaddfghtggvgghhhuuuuuhhhgggggy.pptx
kids gpaddfghtggvgghhhuuuuuhhhgggggy.pptxkids gpaddfghtggvgghhhuuuuuhhhgggggy.pptx
kids gpaddfghtggvgghhhuuuuuhhhgggggy.pptxJagrutiSononee
 
STORY OF SUSAN & JUDY - CEREBRAL PALSY.pptx
STORY OF SUSAN & JUDY - CEREBRAL PALSY.pptxSTORY OF SUSAN & JUDY - CEREBRAL PALSY.pptx
STORY OF SUSAN & JUDY - CEREBRAL PALSY.pptxsheenam bansal
 
127. Reviewer Certificate in BP International
127. Reviewer Certificate in BP International127. Reviewer Certificate in BP International
127. Reviewer Certificate in BP InternationalManu Mitra
 
Audhina Nur Afifah Resume & Portofolio_2024.pdf
Audhina Nur Afifah Resume & Portofolio_2024.pdfAudhina Nur Afifah Resume & Portofolio_2024.pdf
Audhina Nur Afifah Resume & Portofolio_2024.pdfaudhinafh1
 
How to Host a Successful Webinar for Success?
How to Host a Successful Webinar for Success?How to Host a Successful Webinar for Success?
How to Host a Successful Webinar for Success?StrengthsTheatre
 
asdfasdiofujasloidfoia nslkflsdkaf jljffs
asdfasdiofujasloidfoia nslkflsdkaf jljffsasdfasdiofujasloidfoia nslkflsdkaf jljffs
asdfasdiofujasloidfoia nslkflsdkaf jljffsJulia Kaye
 
10 Things That Will Shape the Future of Education.pdf
10 Things That Will Shape the Future of Education.pdf10 Things That Will Shape the Future of Education.pdf
10 Things That Will Shape the Future of Education.pdfEducationView
 
Moaaz Hassan El-Shayeb - Projects Portfolio
Moaaz Hassan El-Shayeb - Projects PortfolioMoaaz Hassan El-Shayeb - Projects Portfolio
Moaaz Hassan El-Shayeb - Projects Portfoliomoaaz el-shayeb
 
Nashon Holloway - Media/Press Kit - Priv
Nashon Holloway - Media/Press Kit - PrivNashon Holloway - Media/Press Kit - Priv
Nashon Holloway - Media/Press Kit - PrivNashonHolloway
 
Chapter-1 IATA, UFTAA, ICAO, FAA, CAA, ATAB, Conventions
Chapter-1 IATA, UFTAA, ICAO, FAA, CAA, ATAB, ConventionsChapter-1 IATA, UFTAA, ICAO, FAA, CAA, ATAB, Conventions
Chapter-1 IATA, UFTAA, ICAO, FAA, CAA, ATAB, ConventionsMd Shaifullar Rabbi
 
reStartEvents March 28th TS/SCI & Above Employer Directory.pdf
reStartEvents March 28th TS/SCI & Above Employer Directory.pdfreStartEvents March 28th TS/SCI & Above Employer Directory.pdf
reStartEvents March 28th TS/SCI & Above Employer Directory.pdfKen Fuller
 
Fireman Resume Strikuingly Text............................
Fireman Resume Strikuingly Text............................Fireman Resume Strikuingly Text............................
Fireman Resume Strikuingly Text............................calvinjamesmappala
 
FAHAD HASSAN NOOR || UCP Business School Data Analytics Head Recommended | MB...
FAHAD HASSAN NOOR || UCP Business School Data Analytics Head Recommended | MB...FAHAD HASSAN NOOR || UCP Business School Data Analytics Head Recommended | MB...
FAHAD HASSAN NOOR || UCP Business School Data Analytics Head Recommended | MB...FaHaD .H. NooR
 
ASDFSDFASDFASDFASDFOUIASHDFOIASUD FOIJSADO;IFJOISADJF
ASDFSDFASDFASDFASDFOUIASHDFOIASUD FOIJSADO;IFJOISADJFASDFSDFASDFASDFASDFOUIASHDFOIASUD FOIJSADO;IFJOISADJF
ASDFSDFASDFASDFASDFOUIASHDFOIASUD FOIJSADO;IFJOISADJFJulia Kaye
 
wealth_spend_bharatpeVerse_Analysis .pptx
wealth_spend_bharatpeVerse_Analysis .pptxwealth_spend_bharatpeVerse_Analysis .pptx
wealth_spend_bharatpeVerse_Analysis .pptxAnuragBhakuni4
 
Chapter-4 Introduction to Global Distributions System and Computerized Reserv...
Chapter-4 Introduction to Global Distributions System and Computerized Reserv...Chapter-4 Introduction to Global Distributions System and Computerized Reserv...
Chapter-4 Introduction to Global Distributions System and Computerized Reserv...Md Shaifullar Rabbi
 
Blockchain_TezosDeveloperCommunitySNSCE.pdf
Blockchain_TezosDeveloperCommunitySNSCE.pdfBlockchain_TezosDeveloperCommunitySNSCE.pdf
Blockchain_TezosDeveloperCommunitySNSCE.pdfVISHNURAJSSNSCEAD
 

Recently uploaded (17)

kids gpaddfghtggvgghhhuuuuuhhhgggggy.pptx
kids gpaddfghtggvgghhhuuuuuhhhgggggy.pptxkids gpaddfghtggvgghhhuuuuuhhhgggggy.pptx
kids gpaddfghtggvgghhhuuuuuhhhgggggy.pptx
 
STORY OF SUSAN & JUDY - CEREBRAL PALSY.pptx
STORY OF SUSAN & JUDY - CEREBRAL PALSY.pptxSTORY OF SUSAN & JUDY - CEREBRAL PALSY.pptx
STORY OF SUSAN & JUDY - CEREBRAL PALSY.pptx
 
127. Reviewer Certificate in BP International
127. Reviewer Certificate in BP International127. Reviewer Certificate in BP International
127. Reviewer Certificate in BP International
 
Audhina Nur Afifah Resume & Portofolio_2024.pdf
Audhina Nur Afifah Resume & Portofolio_2024.pdfAudhina Nur Afifah Resume & Portofolio_2024.pdf
Audhina Nur Afifah Resume & Portofolio_2024.pdf
 
How to Host a Successful Webinar for Success?
How to Host a Successful Webinar for Success?How to Host a Successful Webinar for Success?
How to Host a Successful Webinar for Success?
 
asdfasdiofujasloidfoia nslkflsdkaf jljffs
asdfasdiofujasloidfoia nslkflsdkaf jljffsasdfasdiofujasloidfoia nslkflsdkaf jljffs
asdfasdiofujasloidfoia nslkflsdkaf jljffs
 
10 Things That Will Shape the Future of Education.pdf
10 Things That Will Shape the Future of Education.pdf10 Things That Will Shape the Future of Education.pdf
10 Things That Will Shape the Future of Education.pdf
 
Moaaz Hassan El-Shayeb - Projects Portfolio
Moaaz Hassan El-Shayeb - Projects PortfolioMoaaz Hassan El-Shayeb - Projects Portfolio
Moaaz Hassan El-Shayeb - Projects Portfolio
 
Nashon Holloway - Media/Press Kit - Priv
Nashon Holloway - Media/Press Kit - PrivNashon Holloway - Media/Press Kit - Priv
Nashon Holloway - Media/Press Kit - Priv
 
Chapter-1 IATA, UFTAA, ICAO, FAA, CAA, ATAB, Conventions
Chapter-1 IATA, UFTAA, ICAO, FAA, CAA, ATAB, ConventionsChapter-1 IATA, UFTAA, ICAO, FAA, CAA, ATAB, Conventions
Chapter-1 IATA, UFTAA, ICAO, FAA, CAA, ATAB, Conventions
 
reStartEvents March 28th TS/SCI & Above Employer Directory.pdf
reStartEvents March 28th TS/SCI & Above Employer Directory.pdfreStartEvents March 28th TS/SCI & Above Employer Directory.pdf
reStartEvents March 28th TS/SCI & Above Employer Directory.pdf
 
Fireman Resume Strikuingly Text............................
Fireman Resume Strikuingly Text............................Fireman Resume Strikuingly Text............................
Fireman Resume Strikuingly Text............................
 
FAHAD HASSAN NOOR || UCP Business School Data Analytics Head Recommended | MB...
FAHAD HASSAN NOOR || UCP Business School Data Analytics Head Recommended | MB...FAHAD HASSAN NOOR || UCP Business School Data Analytics Head Recommended | MB...
FAHAD HASSAN NOOR || UCP Business School Data Analytics Head Recommended | MB...
 
ASDFSDFASDFASDFASDFOUIASHDFOIASUD FOIJSADO;IFJOISADJF
ASDFSDFASDFASDFASDFOUIASHDFOIASUD FOIJSADO;IFJOISADJFASDFSDFASDFASDFASDFOUIASHDFOIASUD FOIJSADO;IFJOISADJF
ASDFSDFASDFASDFASDFOUIASHDFOIASUD FOIJSADO;IFJOISADJF
 
wealth_spend_bharatpeVerse_Analysis .pptx
wealth_spend_bharatpeVerse_Analysis .pptxwealth_spend_bharatpeVerse_Analysis .pptx
wealth_spend_bharatpeVerse_Analysis .pptx
 
Chapter-4 Introduction to Global Distributions System and Computerized Reserv...
Chapter-4 Introduction to Global Distributions System and Computerized Reserv...Chapter-4 Introduction to Global Distributions System and Computerized Reserv...
Chapter-4 Introduction to Global Distributions System and Computerized Reserv...
 
Blockchain_TezosDeveloperCommunitySNSCE.pdf
Blockchain_TezosDeveloperCommunitySNSCE.pdfBlockchain_TezosDeveloperCommunitySNSCE.pdf
Blockchain_TezosDeveloperCommunitySNSCE.pdf
 

Abap coding standards

  • 4. Coding Standard – ABAP TABLE OF CONTENTS EXECUTIVE SUMMARY ....................................................................................................6 DOCUMENT OBJECTIVE......................................................................................................................6 DOCUMENT SCOPE...........................................................................................................................6 TARGET AUDIENCE............................................................................................................................6 ACTION & ADHERENCE....................................................................................................................6 GENERAL COMMUNICATION .............................................................................................................6 THE DEVELOPMENT LIFE-CYCLE.................................................................................7 PREPARATION OF A FUNCTIONAL SPECIFICATION .......................................................................................7 FUNCTIONAL SPECIFICATION SIGN-OFF...................................................................................................7 THE TECHNICAL SPECIFICATION ...........................................................................................................7 DEVELOPMENT OF PROGRAM CODE...............................................................................................7 UNIT TESTING & DOCUMENTATION ......................................................................................................8 SYSTEM TESTING...............................................................................................................................8 USER ACCEPTANCE TESTING................................................................................................................8 PROGRAM SIGN-OFF.......................................................................................................................8 TYPES OF ABAP PROGRAM.............................................................................................8 DATA CONVERSION PROGRAMS...........................................................................................................9 BATCH INTERFACES...........................................................................................................................9 INBOUND INTERFACES......................................................................................................................9 OUTBOUND INTERFACES.................................................................................................................10 ALE INTERFACES...........................................................................................................................10 REPORTS......................................................................................................................................10 BASIC LIST..................................................................................................................................11 INTERACTIVE REPORT.....................................................................................................................12 ALV....................................................................................................................................12 TRANSACTIONS (DIALOGUE PROGRAMMING)..........................................................................................12 USER EXITS..................................................................................................................................13 BADI’S...............................................................................................................................13 SAPSCRIPTS............................................................................................................................13 SMART FORMS........................................................................................................................13 FUNCTIONAL SPECIFICATIONS...................................................................................13 WHAT IS A FUNCTIONAL SPECIFICATION................................................................................................14 WHY WRITE FUNCTIONAL SPECIFICATIONS..............................................................................................14 WHAT SHOULD BE IN A FUNCTIONAL SPECIFICATION?................................................................................14 THE TECHNICAL SPECIFICATION...............................................................................14 WHAT IS A TECHNICAL SPECIFICATION?................................................................................................15 CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 2 of 66
  • 5. Coding Standard – ABAP WHY WRITE TECHNICAL SPECIFICATIONS?.............................................................................................15 WHAT SHOULD BE IN A TECHNICAL SPECIFICATION?..................................................................................15 ABAP CODING STANDARDS...........................................................................................15 GENERAL PRINCIPLES......................................................................................................................16 ERROR HANDLING..........................................................................................................................18 GENERAL.....................................................................................................................................18 CONVERSIONS & INTERFACES ERROR HANDLING...............................................................................18 DIALOG PROGRAMMING..................................................................................................................19 GENERAL.....................................................................................................................................19 NAMING.......................................................................................................................................19 REPORT PROGRAMS........................................................................................................................19 PROGRAM STRUCTURE......................................................................................................................20 READABILITY.................................................................................................................................20 AUTHORIZATIONS & SECURITY............................................................................................................21 PERFORMANCE CONSIDERATIONS........................................................................................................21 DATABASE SELECTIONS..................................................................................................................21 ABAP STATEMENTS.......................................................................................................................24 COMPUTE AND MOVE STATEMENT...................................................................................................24 COMPARE OPERATORS ..................................................................................................................24 AVOID ‘HARD CODING’ ...................................................................................................24 CASE VS. IF/ELSE: WHICH TO USE WHEN BOTH WOULD WORK?....................................................25 BREAK LEVELS IN LOOP STATEMENTS..............................................................................................26 INTERNAL TABLES............................................................................................................................27 ABAP LIST VIEWER.......................................................................................................................29 ABAP QUERIES...........................................................................................................................30 SAPSCRIPT CODING STANDARDS......................................................................................................30 STANDARDS FOR ALL ENHANCEMENT USER EXITS......................................................................................31 CUSTOM BAPI DEVELOPMENT..........................................................................................................32 LOGICAL DATABASES......................................................................................................................33 SELECTION SCREEN PARAMETERS........................................................................................................33 PROGRAM DOCUMENTATION......................................................................................33 PROGRAM FOLDER OVERVIEW...........................................................................................................33 SOURCE CODE DOCUMENTATION.......................................................................................................34 ON-LINE HELP..............................................................................................................................35 PROGRAM ATTRIBUTES...................................................................................................................35 PROGRAM MODIFICATIONS..............................................................................................................35 PROGRAM TESTING.........................................................................................................................36 TEST CONDITIONS........................................................................................................................36 TEST PLAN................................................................................................................................37 TEST DATA..................................................................................................................................37 EXPECTED RESULTS.......................................................................................................................37 ACTUAL RESULTS.........................................................................................................................37 NAMING CONVENTIONS..................................................................................................................37 PROGRAM DOCUMENTATION TEMPLATES................................................................................................37 PROGRAM HEADER........................................................................................................................38 PROGRAM CHANGE........................................................................................................................38 INCLUDE PROGRAM HEADER...........................................................................................................39 CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 3 of 66
  • 6. Coding Standard – ABAP SUB-ROUTINE/FORM......................................................................................................................39 FUNCTION MODULE.......................................................................................................................40 FUNCTION MODULE – EXCEPTION HANDLING....................................................................................40 APPLICATION OSS NOTES..............................................................................................................41 ABAP PROGRAM TEMPLATES............................................................................................................44 BASIC REPORT LIST......................................................................................................................44 INTERACTIVE ABAP REPORT LIST..................................................................................................46 BATCH INPUT PROGRAM.................................................................................................................48 PROGRAM PERFORMANCE TUNING TECHNIQUES...............................................50 TECHNIQUE 1: USING SELECT STATEMENTS......................................................................................50 TECHNIQUE 2: SELECTING ORDERED RECORDS FROM A TABLE...............................................................50 TECHNIQUE 3: READING LARGE INTERNAL TABLES WITHOUT USING BINARY SEARCH............................51 TECHNIQUE 4: MOVING DATA FROM INTERNAL TABLE 1 TO INTERNAL TABLE 2....................................51 TECHNIQUE 5: APPENDING DATA FROM INTERNAL TABLE 1 TO INTERNAL TABLE 2................................51 TECHNIQUE 6: DELETING DATA FROM INTERNAL TABLES....................................................................52 ABAP CODE REVIEW CHECKLIST..............................................................................53 ABAP OBJECTS..................................................................................................................53 INTRODUCTION .............................................................................................................................53 NAMING CONVENTIONS .................................................................................................................54 GENERAL CONVENTIONS..................................................................................................................54 CLASS CONVENTIONS ....................................................................................................................55 FIXED METHOD NAMES ..................................................................................................................55 METHOD CONVENTIONS .................................................................................................................56 WORK FLOW......................................................................................................................58 INTRODUCTION..............................................................................................................................58 NAMING CONVENTION...................................................................................................................58 1.1WORKFLOW TEMPLATES / TASK.................................................................................................58 1.2BUSINESS OBJECT....................................................................................................................59 1.3BUSINESS OBJECT – PROGRAM...................................................................................................59 PREFERRED APPROACHES / PRACTICES:.................................................................................................60 A. WORKFLOW IMPLEMENTING APPROACH:........................................................................................60 B. WORKFLOW SCENARIO DEVELOPMENT:.........................................................................................60 PERFORMANCE TIPS:........................................................................................................................62 ERROR HANDLING:.........................................................................................................................62 CHECKLIST FOR WORKFLOW DEVELOPMENT:..................................................................................63 QA SUMMARY ...................................................................................................................63 OBJECTIVE...................................................................................................................................63 SCOPE........................................................................................................................................63 TARGET AUDIENCE..........................................................................................................................63 ACTION & ADHERENCE...................................................................................................................63 CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 4 of 66
  • 7. Coding Standard – ABAP QA PROCESS OVERVIEW................................................................................................................64 CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 5 of 66
  • 8. Coding Standard – ABAP Executive Summary Document Objective This document has been prepared to outline the development approach followed by the Wipro Technologies ABAP development group. Document Scope This is a definition of the base standards relating to applications development work and recommendations for efficient programming techniques for all custom development work carried out by the Wipro Technologies ABAP development group. It describes progression from functional specification, through technical specification to code development, with associated Quality Assurance and documentation. Details of performance improvement measures and technical information are also included. Target Audience The target audience for this document according to the purpose is as follows: Action & Adherence Project Managers Technical Team leads Technical Team members General Communication All Core & Country Team Leaders & Members (Process & Technical) CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 6 of 66
  • 9. Coding Standard – ABAP The Development Life-cycle During the life cycle a number of deliverables are expected and checkpoints reached (see diagram below). The ABAP Development Life Cycle ABAP Development Team Formal Functional Sign-off Specification Technical Specification Code and User Unit Test Acceptance Program Testing System Test Preparation of a Functional Specification The Project Implementation team members, located on-site, are responsible for preparing Functional Specifications. These will describe the development requirement and contain a description of the functionality of the proposed custom ABAP program. During production of these specifications it may be necessary for the business teams to gain input in the form of Functional Specification assistance from ABAP team members. Functional Specification Sign-off Each functional specification, once complete, will be subject to review and approval by the ABAP team leader. In addition, the ABAP team leader assesses the complexity and cost of the proposed development - any changes to the original assessment are subject to written approval of both parties. The Technical Specification The functional requirements will be translated to a technical specification. This will subject to internal ABAP team quality assurance. Once complete, it will be signed off internally by the ABAP development team leader. Any changes between the technical and functional specification will be made in writing and subject to the written approval of both parties. Development of Program Code Program coding then occurs from the technical specification. CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 7 of 66
  • 10. Coding Standard – ABAP Unit Testing & Documentation Once complete, the program will be tested by the programmer, who will also produce the following testing documentation: • Unit Test Conditions • Unit Test Plan • Test Data • Actual Results System Testing At regular intervals (e.g. 2 months) a number of developments are subject to system testing. This will be to verify inter-dependencies between reports. User Acceptance Testing The ABAP reports will be tested and accepted by reference to whether they conform in all material respects to the Functional Specifications (as signed off by both parties) and in accordance with the following procedure: • Functional Designer prepares Test Plan. • Client Project Manager nominates suitable User for acceptance testing • User conducts testing as detailed in plan. • Client Project Manager reviews UAT test plan and results to verify validity of results and completeness of testing. Program Sign-Off Following a successful User Acceptance Test, the program will then be signed-off by both parties. After development technical specifications are updated to reflect any program modifications requested during the life cycle. Approval to implement any modifications not covered in the original functional specification will be obtained in writing & a copy contained within the program folder. Types of ABAP Program There are a number of different types of ABAP program, as listed below. The type of program to be developed affects which details are required in the functional specification. It is important that the different types of program are understood before detailing the relevant requirements. • Data Conversion • Batch Interface • ALE Interface • Report • Transaction • User Exit • SAPScript (output) • Smart Forms • BADI’s CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 8 of 66
  • 11. Coding Standard – ABAP Data Conversion Programs Data conversion programs can be written to upload data from external legacy systems into SAP. There are a number of standard SAP programs specifically designed to meet this requirement. These use one of two methods to upload the data: • Direct Input • Batch Input Direct input programs tend to be around ten times faster than batch input programs. However custom ABAP developments are only supported if they use the batch input method. Batch input programs read a file from either the presentation or application server and upload it into SAP by simulating the actions of a user stepping through the screens of the relevant transaction. This means that the SAP transaction validates that the data being input is valid so the custom ABAP program does not have to do this. The Batch input program creates a ‘session’, which can be thought of as a collection of information relating the transaction fields to the data to be uploaded. The database is not updated until the ‘session’ is processed. This can be done either manually or automatically. If the session should be processed automatically this should be specified. Any invalid records encountered by SAP are not uploaded into the database and they result in the session being ‘in error’. All valid records will be loaded, the remaining erroneous records will be retained and this session can be re-processed manually. This allows a user to correct the records on- line. Batch Interfaces Interfaces are used to transfer data between SAP and an external system. There are two types of interface: • Inbound - transfers data from the external system to SAP • Outbound - transfers data from SAP to the external system The transfer of data is usually facilitated by either reading from or writing to a file on the application server that has been created or is subsequently read by the external application. Inbound Interfaces For an inbound interface (data being put into SAP), the program first reads the data from the source file, performs any conversions, calculations and formatting that is required for the SAP transaction. The program can then write the data out either as a set of table entries or to a flat file if the data needs to be stored for audit reasons although if this approach is adopted archiving strategies must also be considered. Obviously a flat file carries fewer overheads in terms of maintenance, but there are also benefits of interface controls and audit through intermediate tables that in some instances outweighs this. The program then uses the converted data and creates a SAP batch input session to load it into SAP via the relevant transactions (If writing to a table this may be a second program). CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 9 of 66
  • 12. Coding Standard – ABAP First Stage Extract Calculate Convert Format Second Stage Map Load Outbound Interfaces An outbound interface will typically consist of only one program. This will retrieve the relevant data from SAP tables and write it to an output file. Conversion and formatting will be carried out by the destination interface. Again, some use of tables may be adopted to provide a record of interface operation. ALE Interfaces Application Link Enabling (ALE) interface will also comprise inbound and outbound types of interfaces. ALE is a standard SAP Application component that provides standard settings or the ability to customize elements to take advantage of the ALE application layer. ALE interfaces fall into the following categories: • Standard Scenarios – where SAP provides standard components i.e. Message Types, IDOCs, Function Modules that can be set-up immediately to enable data transfer • Modified Scenarios – where the standard SAP components are enhanced to either reduce data or extend the data being sent i.e. reduce or extend IDOCs, additional function module changes • Customized Scenarios – new components are added to address interface requirements that cannot be met by modified or standard scenarios i.e. new message types, new IDOCs ALE interfaces require a slightly different development approach as the ALE interface require a combination of: • Client Independent Customization e.g. Message Types • Client Dependent Customization e.g. Output Types • Repository changes e.g. Function Modules Reports SAP Reports provide a user with a list of data; this can be either displayed on the screen or printed. Using the following SAP supplied tools can also produce these Reports: • Report Writer • Report Painter • ABAP Query. • ALV CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 10 of 66
  • 13. Coding Standard – ABAP These are useful tools suitable for relatively simple reports and can be used as end-user tools. It should be remembered that since these tools are effectively code-generators the code developed might lack clarity and be relatively inefficient. Reports produced using ABAP code can be one of two types: • Basic List • Interactive Report Basic List This is a report that produces a basic list of data. The user can enter selection criteria on the selection screen to restrict what data is available on the output report. In addition, a number of calculations may be performed by the report together with some data grouping and sorting but this is controlled by the program code. Basic List Report Simple list of Data, double-clicking has no effect CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 11 of 66
  • 14. Coding Standard – ABAP Interactive Report An interactive report allows the user more flexibility in what data they wish to retrieve but are more complex to code and test. The user is given the option to double-click or select lines and see more information. What further information is displayed should be detailed in the Functional Specification. For instance, a report on Purchases could list a number of purchase orders. By double clicking on the Purchase order number the user can be taken to the ‘Display Purchase Order’ transaction to browse the purchase order. This will allow them to view more information than in the report. Interactive Report User Double-clicks on PO Number, the Purchase Order Overview is displayed. ALV ABAP List Viewer (ALV) is one of the fascinating tools provided by SAP for displaying reports. This tool has the merit of reducing the development time of reports by providing standard interfaces (Function Modules). These standard interfaces provide GUI and formatting options for the on screen display. Transactions (Dialogue Programming) A transaction is a dialogue program with one or more screens. It changes objects in the database in a consistent manner. Examples of standard SAP transactions include ‘Change a Purchase Order, Create a Material, Enter a G/L Posting’. Custom transactions can be developed to meet functionality not covered by the standard SAP system. CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 12 of 66
  • 15. Coding Standard – ABAP User Exits Changes to SAP supplied code are called a repair to the system and are not supported by SAP. There are however number of places in the standard SAP code where additional functionality can be implemented called ‘User Exits’. These exist in pre-defined places in the standard SAP code. Specific data is passed into and out of these exits allowing some data manipulation flexibility. These areas of SAP code are reserved for customer enhancements and are protected from changes during upgrades. BADI’s Business Add-Ins are a new SAP enhancement technique based on ABAP Objects. They can be inserted into the SAP System to accommodate user requirements too specific to be included in the standard delivery. Since specific industries often require special functions, SAP allows you to predefine these points in your software. SapScripts SAP supplies a number of outputs as standard, e.g. Purchase Order, Invoice, etc. In many cases these meet client business requirements but additional changes are often requested. This can vary from adding company logos to retrieving additional data and changing the layout. The outputs are produced using the SAP tool SAPScript. Smart Forms The Smart Forms replace the SAPScript forms. SAP Smart Forms allows you to execute simple modifications to the form and in the form logic by using simple graphical tools; in 90% of all cases, this won't include any programming effort. Thus, a user who is familiar with the tool but has only rudimentary programming knowledge can configure forms with data from an SAP System for the relevant business processes. The result of the form development is a Smart Form. After it is activated, the Smart Form is similar to a callable function module in the SAP System. The logic of the form is mapped entirely in the Smart Form. To print a form, you call it from within an application program, in which you retrieve the application data to be merged into the form. As data retrieval and form logic are separated, you must only adapt the Smart Form if changes to the form logic are necessary. The application program passes the data via a function module interface to the Smart Form. Functional Specifications Functional specifications should be prepared and owned by the Project Implementation team (business process team). Essentially they document why the development is required, CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 13 of 66
  • 16. Coding Standard – ABAP how the ABAP development will meet the requirement, what user acceptance testing criteria will be used to verify that the final development meets the business requirements. What is a Functional Specification A functional specification should clearly define the functionality of the proposed ABAP program. The document should use clear language and not contain ambiguous statements that could lead to confusion. The document is a design deliverable and is used internally within the ABAP team as a basis to write a technical specification. The technical specification should contain no functionality not detailed in the functional specification. Once complete, the functional specification is used as a baseline to estimate the complexity of the proposed ABAP program and the associated development time for planning purposes. This document forms the link between the functional and ABAP teams but it is important to remember that this document is owned by the functional designer/Business Process Team. The success of the development, however, depends on close co-operation with the ABAP team. Why write Functional Specifications Functional specifications are written to ensure that all parties (ABAP team/Functional Team) know what is required in the development. This document allows requirements to be reviewed across regional teams before the development is complete. It is also part of the process to enable relevant clients to meet validation requirements. In addition, functional specifications enable dependencies and inter-relationships between the developments and functional areas to be identified and enable evaluation of the risk of development. What should be in a Functional Specification? • A description of the business process. A series of bullet points summarizing the process flow for this requirement. • Assumptions made for this process if any. • Key process steps and descriptions. • What type of program is required?(Example Conversion/SAP Script etc) • Tables from where the data can be fetched • A description of the Selection Screen if applicable. • Validations required at various steps if applicable. The Technical Specification The ABAP team writes technical specifications internally. These document the business requirements covered by the functional specification in a more technical detail that can be translated by a programmer into code. The technical specification also aims to document the implemented solution so it can be used for future code maintenance. CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 14 of 66
  • 17. Coding Standard – ABAP What is a Technical Specification? A Technical specification should clearly define the functionality of the proposed ABAP program in much more detail than the Functional Specification. This document should use clear language and is devoid of ambiguity. The document is a design deliverable and is used internally within the ABAP team as a basis to write ABAP code. The technical specification should contain no functionality not detailed in the functional specification. Once complete, the technical specification is used to generate the code easily and seamlessly. This document forms the link between the functional specification and ABAP code itself. It is owned by the ABAP developer and is QA’ed by the ABAP team leader before coding commences. The technical specifications use logic charts to illustrate the main logical steps in the code and how data and other ABAP specific constructs need to be manipulated to produce the required functionality. Why Write Technical Specifications? Technical specifications are written to illustrate and help design the main logical steps involved in meeting the requirements as specified in the functional specifications. This document allows the developer to visualize and create methods and techniques to manage processing efficiently. What should be in a Technical Specification? A technical specification needs to contain: • A description of the Technical Solution highlighting the key design issues. A series of bullet points summarizes the logic chosen for the program and the main technical difficulties. • What assumptions are made in the technical specification and what they entail in technical terms. • Key process steps. • Why a particular function module was chosen. • Why use multiple selects than just one. • Why use a particular kind of logic for the main processing. • What were the major technical problems with the design of the program? • A description of the Selection Screen with a Selection Screen Prototype • All the error messages (ID and Classes) prompted by the validations executed at the selection screen will be detailed. • Detail Logic Diagrams along with notes associated to them. They should include critical decision logic, database selects, complex conversions, calculations, and formatting and output. • Main Processing steps descriptions • Final Processing steps descriptions ABAP Coding Standards The standards in this document define a base for applications development and quality control. They have been defined as a result of past experience on a number of projects. Standards are used to ensure that the same set of rules are applied in program design, CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 15 of 66
  • 18. Coding Standard – ABAP development and reviews and they are applicable to all programs developed in support of the conversion, implementation and maintenance of the SAP R/3 System. General Principles When coding a program, the following points should be observed to ensure that programming is consistent in format across the project. This ensures that work can be easily transferable between programmers • The standard SAP project program template should be used for all programs. • ABAP programs that update master and transactional data MUST ALWAYS use SAP transaction codes (where transaction codes are available) by utilizing standard SAP Function Modules, BDC or ‘call transaction’ utilities. This ensures that logical units of work, rollback, locking operations and edits are performed. SAP tables MUST NEVER be updated directly. • ABAP programs MUST NEVER be used to update configuration 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 are an example of this approach. R/3 provides a large amount of function modules that perform various tasks such as convert currencies, calculate dates, explode BOM’s etc. In most cases, these modules are efficient and can reduce coding time; therefore they should be employed where possible. It is worth taking the time to search the function module library for a function that meets your requirements. 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) • Keep program lengths to a minimum. Each program should handle a discrete problem. • If there are a large number of data declarations necessary as part of a program, consider separating your declarations into an INCLUDE. The include name should be the same as the program name with the suffix ‘_DATA’ • Use subroutines (FORMS) whenever possible to improve readability and logic flow. Consider creating a subroutine whenever a block of code is called from multiple places in a program. • Avoid the COMPUTE function if clearer ADDs, SUBTRACTs, MULTIPLYs, or DIVIDEs can be used. • When assigning internal fields that are to hold values from databases, use the LIKE option to ensure that the variable has identical characteristics. Example: DATA: WS_LIFNR LIKE LFA1-LIFNR. • Use the INCLUDE statement for Data Declarations, PBO Dynpro modules, PAI Dynpro modules, Subroutines, and Individual Event Processing. CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 16 of 66
  • 19. Coding Standard – ABAP • Use an underscore (_) to connect multi-word variable names and/or MODULE names. • Use the WRITE command with Currency or Units option when writing prices/values to ensure the data is output with the correct number of decimal places. For example weights should always be output with the UNITS options and prices should always be output with the CURRENCY option. This ensures the program can be used over multiple units of measure and in multiple countries. • All programs should be made as generic as possible and reliance on factors specific to clients business should be avoided since the business processes can change easily. • Programs that set their own GUI status should have menus and screens that are as intuitive as possible. • Push buttons should reflect the menu options. All push button options should be available by menu as well. Push button Print Sort Refresh Display/Change • Explicitly qualify all field specifications. For example, use KA-KTRNA, not KTRNA only. • When using the FILL statement, specify FILL FROM. For example, use FILL workarea FROM KA, instead of just FILL workarea. • When a local variable is declared, it should be initialized in the declaration statement whenever possible. • Numbered text-elements must be used wherever possible to make use of SAP’s multi- language capabilities, to make maintenance easier and reduce the impact of future changes on re-work. Text elements should be created with the actual text string in the text element itself e.g. text-001 should read ‘Testing String’ (001) so that text elements for an ABAP program can be recreated if the program is moved to a different client. • Within the main program code literals (i.e. hard-coded values) should be avoided. If reference needs to be made to a specific value (for example Company Code ‘0001’ or Sales Organisation ‘ABCD’) then this should be defined as a parameter to make the program fully flexible. SD/MM/FI document types in particular should not be hard coded since they are subject to change. • No undocumented features of the ABAP language should be used. • External PERFORMs should NOT be used. • Comments should be simple but clear - adequate for a different programmer to understand the processing quickly. Comments can occupy a whole line in the code when it is prefixed with an “*” character, or part of a line when prefixed with an open quote character (“). • Declare program-specific internal variables to be LIKE data dictionary fields to ensure that physical data attributes are consistent. • Each program elements should adopt the appropriate naming prefix. CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 17 of 66
  • 20. Coding Standard – ABAP Internal Tables Transfer record/Work REC_* Area Internal tables: IT_* Copy of database X_* or Y_* or Z_* table Structures Not data dictionary STRUCT_* Types General TY_* Constants General C_* Parameters General P_* Ranges General R_* Checkbox General CB_* Select Options General S_* Variable Local LV_* Global GV_* Counters CNT_* Flags FLG_* Sums SUM_* Work Areas General WA_* Error Handling General • All programs must include proper error handling to avoid undesirable terminations. This means that the system status (SY-SUBRC) must be checked where appropriate after every event in the program that changes it. • If there are more than two possible values for the SY-SUBRC field after a performed event, all expected values should be tested and handled in the program. • Use the CATCH/ENDCATCH statement to trap runtime errors. Error checking requirements depend on the type of program under development. Where possible standard SAP errors messages are utilized in developments. Custom error messages are created where relevant SAP error messages cannot be found. It is the responsibility of the functional requestor to define detailed error handling. Error messages used should aim to be as meaningful as possible. Conversions & Interfaces Error Handling Each of the conversion and interface programs should generate an exception/error report containing detailed record information, corresponding error message(s) and report statistics. In addition to the error report, inbound interface and conversion programs should generate BDC sessions for those transactions, which could not be posted to SAP successfully. These CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 18 of 66
  • 21. Coding Standard – ABAP sessions can then be accessed by an authorized user and be processed manually in the foreground (via transaction SM35) until those error records are posted successfully. It will be the interface user’s responsibility to check the report to ensure that no errors have occurred. A sequential file containing the error records can also be generated if an error occurs. The program can be rerun using this file after fixing the errors. This file can also be used for creating formatted reporting as well as for audit purposes. Dialog Programming General • If the layout of screens is the same for multiple functions (such as ADD, MOVE, and DELETE), use the same screen for all functions. Use online status and security features to control which function is executed. • Define all global data in the main program module instead of the PBO/PAI. • To handle a lock entry failure, raise an error message (type E) preventing any further progress but leaving the user on the current screen. The user can take an alternative action or continue to try to lock the object. To minimize the impact on users, limit retries. • When activating buttons or boxes, activate the associated text as well. This enables the user to click on the either button/box or the text. • For additional standards, see the SAP online documentation, “SAP Styleguide”. Naming • For online programs, the initial screen should always be 9000. Screen numbering should follow functionality. For example: 9000 - Initial 9100 – Block 1 9110 - Sub-functionality of Block 1 9120 - Sub-functionality of Block 1 Etc.... • Use Data Dictionary names (short, medium, long) for field text on screens where applicable. • Use SAVE_OK_CODE as the field name when saving the OK Code field. It is recommended that you use a backup version of the OK Code field to avoid sending a screen that already has a function code. • Always define the field with a Format = OK as OK_CODE. This field is used to validate the OK Event. • Prefix radio buttons with RB_, push buttons with PB_, and check boxes with CB_. Report Programs CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 19 of 66
  • 22. Coding Standard – ABAP • The only report screen is 1000, which is automatically assigned by SAP. • When using the WRITE command, constants should be defined as Text Elements. Hardcoded character strings should NOT be used alone. Text elements should be defined and used in the WRITE command in addition to a corresponding string value. This technique ensures accuracy of output by using text elements, while improving readability of the program. • For list reports, include the following information to give users a clear indication as to what the report consists of. For example: - End-User Reports: selection criteria, entries found, requester, report name, date/time, exceptions, parameters, etc. - Conversion/Interface Reports: number of records read, number of records processed, number of records written, date/time, transactions posted, etc. Program Structure ABAP is an event driven programming language. However, proper program structure and modular coding is still important to maintain readability and efficiency of an ABAP program. A program should be divided into distinct sections that are properly documented in the code. Whenever possible, it is sensible to use function modules already available instead of creating new ones. Refer to the program template in the Appendices section for the proper order and structure of your program. Forms should not be too long to help ensure modularity and for ease of following the program logic. All forms should be in the order they are first called. Using the letter F and a number code to identify related forms can help facilitate this. E.g. perform f1000_intialisation. perform f2000_main_processing. form f2000_main_processing. perform f2100_modify_data. perform f2200_calculation. endform. Note: If a form contains very general functionality that could be used in other programs, it may be useful to create it as a function module. Readability • Start each new command or clause on a new line. Do not put multiple commands on the same line. • If a statement continues past one line, indent all subsequent lines. • 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 CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 20 of 66
  • 23. Coding Standard – ABAP • Project Standard Form headings. Add appropriate form description to these headings. Note: “Pretty Printer” creates SAP Form headings if no comment lines exist after previous ABAP statement. Authorizations & Security As a rule, authorization checks should be used whenever appropriate to verify the access level of the user executing the program. Please see the Portal Integration team document on security & authorizations for ABAP development. Performance Considerations Database Selections The 3-tier architecture of SAP distributes workload across the servers (presentation, application, and database). The majority of the work takes place on the application and database servers. There is an obvious limit on capacity; this means that if not managed correctly the database server can become a major bottleneck. Applications developers should aim, for performance reasons, to migrate the majority of processes to the application servers and to be as efficient as possible when accessing the database server. This can be achieved in a number of ways. In order to improve performance times wherever possible the number of database accesses made by a program should be kept to a minimum. The contents of tables can be selected into internal tables (tables local to the program) and used for reference during the program execution rather than using the SELECT...ENDSELECT logic (see diagram below). Application Server Select VBELN Select VBELN POSNN POSNN From VBFA into table I_VBFA Where VBELV = S_DOC_NUMBER From VBFA And POSNV = S_ITEM_NO Where VBELV = S_DOC_NUMBER And POSNV = S_ITEM_NO Move: VBFA-VBELN to I_VBFA-VBELN, VBFA-POSNN to I_VBFA-POSNN. Append I_VBFA. Endselect. Multiple Single Database Database Accesses Accesses VBFA Database VBFA The typical procedure would be to select relevant fields from the table into an internal table at the event START-OF-SELECTION. In this example only those records of the sales document flow table (VBFA), which fall within the selection criteria are selected into an internal table. CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 21 of 66
  • 24. Coding Standard – ABAP Internal tables are generally quicker than using field-groups for small volumes of data (although they are less flexible for sorting, especially for a large volume of data records). Field groups should be used if there is a high number of data records that would need to be processed (e.g. 100+ records). Field groups use memory space on the application server that does not impede processing space for other applications. Field groups are also more efficient in their storage handling because the data is compressed before being stored. In addition, a number of additional principles should be adhered to for efficient coding: • Where possible fields should be specified rather than SELECT *. • When accessing pool and cluster tables, these should be accessed using the full primary key. • Avoid placing a ‘SELECT’ or ‘SELECT SINGLE’ in a loop to minimize the number of database requests. • Avoid using ‘SELECT...INTO CORRESPONDING FIELD’, as the associated overhead with corresponding field could be significant. • The number of records retrieved should be limited using the ‘WHERE’ clause rather than selecting and using the ‘CHECK’ statement. • Fields should be listed in the WHERE clause in the same order as they appear in the table. • Where possible the ‘AGGREGATE’ function should be used rather than ‘SELECT…’ and then do the manipulation. • When defining internal tables the use of include-structures should be avoided. • Minimize database accesses. Keep the number of communication processes between the database and application servers, as well as the transferred dataset as small as possible. • Do the most restrictive calls first. For example, to process all materials with a quantity-at- hand above 50, the tables containing stock quantities should be read before the material master tables. • Always check for the DELETION FLAG on key master data tables (i.e., KNA1, KNVV, MARA…). Deletion flags are usually named LOEVM, LOEKZ, LVORM, etc. • Do not use Order By clause on non-key or non-indexed fields. Bring the data into an internal table with a single call and then sort the internal table. This relieves the database of the additional sort requirement and utilizes the processing and memory of the application server. • In all cases look to decrease the number of database calls. Whenever possible issue calls to retrieve all records into an internal table. Do the processing using the internal table. CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 22 of 66
  • 25. Coding Standard – ABAP • Nested selects should be avoided as they result in a large volume of database accesses (dependent on size of tables). Where further database accesses depend on data stored in an internal table the following syntax can be used: IF NOT ITAB1 [] IS INITIAL Select FIELD1 FIELD2 From TABLE Into table ITAB2 For all Entries inITAB1 Where FIELD3 = ITAB1-FIELD3 And FIELD4 = S_FIELD. ENDIF. • In a SELECT statement, the HAVING clause allows you to specify a logical condition for the groups in a GROUP-BY clause. Effective use of the having clause can reduce the set of data transferred from the database to the application server. When the having clause is used, the aggregates and groups are constructed in the database instead of the application server, thereby reducing the resulting set. • When creating a program that writes new or update existing records you MUST secure that your program handles COMMIT at a reasonable frequency. As a general rule, you should do a commit every 1000 or 10 000 records. If your program is running for a long period of time without doing a commit, the data base and finally the whole system will be deadlocked and eventually shutting down the system is the only option left to terminate the execution as all resources are consumed by your program. If multiple inserts must be made to a table, inserting an array from a table, rather than performing multiple inserts of single records will improve performance. For example: INSERT CUST FROM TABLE TAB. Will be more efficient than: LOOP AT TAB. MOVE-CORRESPONDING TAB TO CUST. INSERT CUST. ENDLOOP. • Open SQL is SAP’s version of SQL and is designed to work with most RDBMS Systems (Relational Database Management Systems). Avoid using any native SQL features that are not documented or used in Open SQL. • You can specify as many WHERE conditions as you like in all types of database tables – i.e. transparent tables, pool tables and cluster tables. However, you should be aware for performance reasons that complex WHERE conditions involving pool and cluster tables usually cannot be passed to the database system. They must be processed by the SAP database interface through post-selection. • Use secondary index / Create secondary index if accessing a database table with non-key fields depending on the frequency of usage and volume of data accessed. CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 23 of 66
  • 26. Coding Standard – ABAP • Use of total key is preferred in search criteria. If you can not give total key and you can give former part of key, still the select is effective. If you are specifying later part of key then it is equivalent to non-key field which is not effective. • When a full key is unknown and only one record is needed, the UP TO 1 ROWS append is added to the SELECT statement. • When using the AND OR operator the most likely elimination criteria is specified first. (Expressions are evaluated left to right and the evaluation ends when the final result has been established) ABAP Statements Compute and Move Statement Use operators (+, -, *, /) in the form of “pctocc = seatsocc / seatsmax” instead of the COBOL form of “Divide seatsocc by seatsmax giving pctocc”. Use the = sign in the form of “J_4KRCAT_I = VBAP_I-J_4KRCAT” instead of the COBOL MOVE statement “MOVE VBAP_I-J_4KRCAT TO J_4KRCAT_I”. Compare Operators Use compare operators (=, <, >, <>) instead of EQ, NE, LT, GT Avoid ‘Hard Coding’ RULE OF THUMB: Use constants rather than ‘hard coding’ when: • It adds value to the code and is named informatively. • It is defined in the standard include. Incorrect: CONSTANTS: C_SA LIKE BKPF-BLART VALUE 'SA', C_DR LIKE BKPF-BLART VALUE 'DR', C_DG LIKE BKPF-BLART VALUE 'DG', C_KR LIKE BKPF-BLART VALUE 'KR', C_KG LIKE BKPF-BLART VALUE 'KG', C_AC LIKE BKPF-BLART VALUE 'AC', C_O LIKE T001B-RRCTY VALUE '0'. IF rs_header-document_type = C_SA OR rs_header-document_type = C_DR OR rs_header-document_type = C_DG OR rs_header-document_type = C_KR OR rs_header-document_type = C_KG OR rs_header-document_type = C_AC OR rs_header-document_type = C_O. ... Correct: CONSTANTS: C_GL_ACCOUNT_DOC LIKE BKPF-BLART VALUE 'SA', C_CUSTOMER_INVOICE LIKE BKPF-BLART VALUE 'DR', C_CUSTOMER_CREDIT_MEMO LIKE BKPF-BLART VALUE 'DG', C_VENDOR_INVOICE LIKE BKPF-BLART VALUE 'KR', CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 24 of 66
  • 27. Coding Standard – ABAP C_VENDOR_CREDIT_MEMO LIKE BKPF-BLART VALUE 'KG', C_ACCRUALS LIKE BKPF-BLART VALUE 'AC'. IF RS_HEADER-DOCUMENT_TYPE = C_GL_ACCOUNT_DOC OR RS_HEADER_DOCUMENT_TYPE = C_CUSTOMER_INVOICE OR RS_HEADER_DOCUMENT_TYPE = C_CUSTOMER_CREDIT_MEMO OR RS_HEADER_DOCUMENT_TYPE = C_VENDOR_INVOICE OR RS_HEADER_DOCUMENT_TYPE = C_VENDOR_CREDIT_MEMO OR RS_HEADER_DOCUMENT_TYPE = C_ACCRUALS. ... OR this is also correct: IF RS_HEADER-DOCUMENT_TYPE = ‘SA’ OR “GL_ACCOUNT_DOC RS_HEADER_DOCUMENT_TYPE = ‘DR’ OR “CUSTOMER_INVOICE RS_HEADER_DOCUMENT_TYPE = ‘DG’ OR “CUSTOMER_CREDIT_MEMO RS_HEADER_DOCUMENT_TYPE = ‘KR’ OR “VENDOR_INVOICE RS_HEADER_DOCUMENT_TYPE = ‘KG’ OR “VENDOR_CREDIT_MEMO RS_HEADER_DOCUMENT_TYPE = ‘AC’. “ACCRUALS CASE VS. IF/ELSE: Which to use when both would work? IF/ELSE RULE OF THUMB Use the IF/ELSE rather than the CASE statement when there is only one condition. Example: IF T_DETAIL-BSCHL = C_POSTING_KEY_70. <action 1>. ELSE. <action 2>. ENDIF. CASE RULE OF THUMB Use the CASE statement rather than IF/ELSEIF statement when there are multiple conditions. Example: CASE T_DETAIL-BSCHL. WHEN C_POSTING_KEY_70. <action 1>. WHEN C_POSTING_KEY_75. <action 2>. WHEN OTHERS. CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 25 of 66
  • 28. Coding Standard – ABAP <action 3>. ENDCASE. Note: ‘WHEN OTHERS’ always requires generic error processing. Incorrect: CASE sy-subrc. WHEN 1. MESSAGE ID ‘ZSD’ TYPE ‘E’ NUMBER ‘100’. WHEN 2. MESSAGE ID ‘ZSD’ TYPE ‘E’ NUMBER ‘101’. WHEN OTHERS. * No action required ENDCASE. Correct: CASE sy-subrc. WHEN 1. MESSAGE ID ‘ZSD’ TYPE ‘E’ NUMBER ‘100’. WHEN 2. MESSAGE ID ‘ZSD’ TYPE ‘E’ NUMBER ‘101’. WHEN OTHERS. MESSAGE ID ‘ZSD’ TYPE ‘E’ NUMBER ‘102’. ENDCASE. If you are using CHECK or EXIT statements, be careful while considering any required follow- on processing, e.g. a failed CHECK statement in the START-OF-SELECTION event of a program causes the program to move directly to END-OF-SELECTION processing. Break Levels in Loop Statements Inside Loops the preferred way of recognizing changes is AT....ENDAT. Avoid using On Change Of statement. There's a difference between these statements. AT ..... ENDAT This statement is triggered based on any change in the field specified and any change in a previous field inside the structure. Note: All character fields on the right are filled with * after the current control level key. See SAP Help for more information. ON CHANGE OF CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 26 of 66
  • 29. Coding Standard – ABAP This statement is specific to a single field. Using this statement can cause unpredictable results. Internal Tables Defining internal tables When defining a table using occurs the ‘occurs’ statement allocates an area in memory of the specified size. It is generally accepted as preferable, to declare a type (for custom structures) or use the database structure and use syntax ’standard table of’ to define an internal table. Internal tables should be defined, whenever possible, without header lines. It improves readability to use work areas instead when processing internal tables. Incorrect: DATA: BEGIN OF T_MAT OCCURS 0, MATNR LIKE MARA-MATNR, WERKS LIKE MARC-WERKS, DISPO LIKE MARC-DISPO, END OF TYPE_MAT. Correct: TYPES: BEGIN OF TYPE_MAT, MATNR LIKE MARA-MATNR, WERKS LIKE MARC-WERKS, DISPO LIKE MARC-DISPO, END OF TYPE_MAT. DATA: IT_MAT TYPE STANDARD TABLE OF TYPE_MAT, WA_MAT TYPE TYPE_MAT. Always use Work Areas while processing internal tables. LOOP AT IT_MAT INTO WA_MAT. ENDLOOP. (OR) Use Field symbols on LOOP/READ statements as it is easier to modify the internal table entry and also avoids the usage of MODIFY statements. Sorting internal tables When sorting internal tables, specify the fields to SORT on. SORT ITAB BY FLD1 FLD2. Is more efficient than SORT ITAB. (OR) Instead of using SORT table itab with matnr use, SORTED table with table key matnr The access type of an internal table defines the way in which ABAP accesses the individual table entries. There are three access types: Standard, Sorted, and Hashed. DELETE ADJACENT DUPLICATES statement should always be used with specific sort / comparison fields. Incorrect: DELETE ADJACENT DUPLICATES FROM T_DOCUMENT. CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 27 of 66
  • 30. Coding Standard – ABAP Correct: DELETE ADJACENT DUPLICATES FROM T_DOCUMENT COMPARING VBELN VBELP. Note: Internal Tables should be always sorted before using DELETE ADJACENT DUPLICATES. Standard Internal Tables Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition. This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to the number of table entries. Sorted Internal Tables Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique, or non- unique, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables. This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognized before they are inserted. The response time for access using the key is in logarithmic relation to the number of table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key. DO NOT use APPEND to fill the entries of SORTED internal table. Do NOT use SORTED tables in database SELECT statements as it would lead to a short dump if the system tries to append the entries into the sorted internal table. Hashed Internal Tables Hashed tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition. This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and using internal tables that are similar to database tables. CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 28 of 66
  • 31. Coding Standard – ABAP DO NOT use APPEND to fill the entries of HASHED internal table. Collect The COLLECT statement is used to create a unique dataset. To fill a standard internal table without creating duplicate entries and add up the Packed, Integer, and Floating Point fields at the same time, use: COLLECT itab. This is only recommended for tables for which you expect approximately 50 entries or less. The COLLECT statement scans the table sequentially for a match on all fields that do not have a data type of Packed, Integer, or Floating-Point. Hence it is can be resource expensive for larger tables. When dealing with larger internal tables, it is more efficient to READ the internal table with key, and then perform an INSERT or MODIFY statement on the table depending on the return code. Other ways to create unique datasets are to fill an internal table with all entries SORT it then use the statement ‘DELETE ADJACENT DUPLICATES’. (This statement is much more efficient than deleting using a LOOP structure that would achieve the same effect). ABAP List Viewer A call back FORM in List Viewer should not be called the same name as an ABAP event or keyword. i.e. rt_events-form = 'TOP_OF_PAGE'. Incorrect: *&---------------------------------------------------------------------* *& Form DEFINE_EVENTS *&---------------------------------------------------------------------* * This form defines the events for display list *----------------------------------------------------------------------* * <--RT_EVENTS Event table *----------------------------------------------------------------------* FORM define_events TABLES rt_events LIKE t_events. rt_events-name = slis_ev_top_of_page. RT_EVENTS-FORM = 'TOP_OF_PAGE'. APPEND rt_events. ENDFORM. " DEFINE_EVENTS Correct: *&---------------------------------------------------------------------* *& Form DEFINE_EVENTS *&---------------------------------------------------------------------* * This form defines the events for display list *----------------------------------------------------------------------* * <--RT_EVENTS Event table *----------------------------------------------------------------------* FORM define_events TABLES rt_events LIKE t_events. CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 29 of 66
  • 32. Coding Standard – ABAP rt_events-name = slis_ev_top_of_page. rt_events-form = 'PROCESS_TOP_OF_PAGE'. APPEND rt_events. ENDFORM. " DEFINE_EVENTS ABAP Queries ABAP Queries should not be used in production. A query generates a program which must be reviewed by ABAP COE. The generated program must have the following disciplines in place: • Program Header is required • Program Name should end with '_Query' • If a key field statement is being used in a Where statement in SQL, then the field must be made mandatory on the selection screen so that Index scan is forced rather than a table scan. SAPScript Coding Standards Print Program Print Program - Header At the top of each print program include the header text. Print Program and Form (Layout Set) Combinations SAP allows multiple print programs to call one form layout. To reduce complexity and maintenance a newly enhanced form layout should have its own enhanced print program that calls this form. Here are some examples of the Print Program(s) on the left that calls the Form on the right: Example 1: Print Program #1 - change Form #1 - change Print Program #2 - no change becomes ZPrint Program #1 - changed ZForm #1 - changed Print Program #2 - no change Form #1 - no change Example 2: Print Program #1 - change Form #1 - change Form #2 - no change becomes ZPrint Program #1 - changed ZForm #1 - changed Print Program #1 - no change Form #2 - no change CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 30 of 66
  • 33. Coding Standard – ABAP Form Painter - Adding and Deleting Windows When adding a window to a page use 'Z' as the first letter of the window name. You can delete windows from pages that are no longer being used by the print program. Delete windows when it is necessary to reduce clutter within the form and to make future maintenance less complex. Do not use the Graphical Form Painter to delete windows since this editor permanently deletes the window from the form. Use the older non-graphical form painter to remove the Window from Page Windows (the window will still remain in the form). You are then required to document the deleted window name in the Documentation section of the form. Form Painter - Delete Lines For program enhancements within a window refer to 3.1.6. You can only delete lines in blocks as shown below. /*63-JWILMO-20000204 begin: delete /*&REGUH-NAME1& /*63-JWILMO-20000204 end: delete Form Painter - Elements Within a window, do not change the element name/number that is being called a print program. If the element is no longer being used by the print program (or other print programs), you can comment out the code ‘deleted/comment out elements' clause shown below. However, do no comment out the element itself. If more than one block of elements can be commented out you can begin at the top of the first element and end at the bottom of the last element as shown in elements 512 and 513 below. /*63-JWILMO-20000204 begin: delete/comment out elements 512 /*The items listed below are managed on the following account: /*&REGUH-NAME1& /*&REGUH-STRAS& 513 /*------------------ Heading --------------------------------------------- /*&ULINE(71)& /*<K>Document,,Your document,,Date,,,,Deductions,,Gross amount</> /*<K>Number,,Date,,Text</> /*63-JWILMO-20000204 end: delete/comment out elements Standards for all Enhancement User Exits • Always create a new separate include for each Gap in a SAP Enhancement exit Separate User Exits allow enable the independent migration of code as part or the promote-to-production path • Using the EXIT statement will terminate processing for all subsequent user exits CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 31 of 66
  • 34. Coding Standard – ABAP • The use of memory pointers in order to overcome User Exit Interface limitations is not permitted FIELD-SYMBOLS: <F> TYPE STANDARD TABLE. ASSIGN ('(SAPMV56A)XVTTP[]') TO <F>. T_XVTTP = <F>. The variable XVTTP accessed in this example is not within the regular data scope of the current program. In order to overcome this limitation and we are using the 'Assign' statement against a specific memory location. During the execution of the VOFM we have no control of the availability of this memory location. The SAP Interpreter basically searches all available memory areas for the specified name and returns the value found in the first location - that's a solution that's very difficult to maintained going forward - Any OSS note or external transport could affect the availability of specific variables in SAP Memory – this is unacceptable. DO NOT use CHECK statements in User-exits instead use IF….ENDIF Custom BAPI Development BAPI must be part of the Business Object Repository (BOR). Use Business Object Builder (BOB – Transaction SWO1) to associate a BAPI with a Business Object. Naming Convention for custom BAPI’s is ZBAPI_objectname_method name i.e. ZBAPI_COMPANYCODE_GETDETAIL. Do not use BAPI in a report program if you require a few fields. Instead make use of select statement. If its an online transaction program or you will be needing most of the fields then using BAPI is OK. BAPI Interface consists of Import and Export only. No Tables and no Exceptions should be used in the BAPI Interface. All messages need to be returned to the calling program via Return Structures: BAPIRET1 or BAPIRETURN BAPIRET2 Adding a BAPI to an existing SAP object should be done using Subtypes and should not have a Z* as part of the naming convention. Z* is only used for BAPI's belonging to custom objects. All messages that can be issued by a BAPI MUST be listed in the BAPI Documentation Some Basic Rules: • Always perform database changes using the update task • No screen output allowed in BAPI • Can not cause program termination i.e. message type 'A' • Cannot dispatch commit work - Must useBapiService.TransactionCommit (Function Module BAPI_TRANSACTION_COMMIT) CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 32 of 66
  • 35. Coding Standard – ABAP Please refer to SAP BAPI Programming Guide for more detail on programming with BAPI's. In 4.6, use transaction BAPI to get to relevant documentation. Other sources are http://service.sap.com/bapi Logical Databases Logical databases can be inefficient because they can generally be thought of as nested selects where large volumes of data as retrieved which may not exactly match report requirements. There are, however, instances when the use of a logical database can be justified. For instance, in Asset Management a large number of calculations are performed which would take a large amount of time to replicate in custom code. Where a logical database maps closely to the data required by a program it maybe justified incorporating it into the code however checks should be made to ensure that the authority checks performed by the logical database are sufficient. Selection Screen Parameters Include organizational entities (e.g. sales organization, plant) fields in the selection screen wherever it makes sense as this can also help reduce execution time (this should be mandatory for multiple company implementations). Use can often be made of the user parameter IDs to bring values into a selection screen. The following is an example of how this can be coded: Parameters: SALES_ORG LIKE TVKOV-VKORG MEMORY ID VKO. Frequently used parameter ID codes are: Company Code BUK Sales Organization VKO Distribution Channel VTW Division SPA Plant WRK Storage location LAG USE SELECT-OPTIONS with NO-EXTENSION NO INTERVALS instead of PARAMETER SELECT matnr into wl_matnr From mara Where matnr IN s_matnr. Program Documentation Documentation of all new ABAP developments is completed in three ways. Program Folder Overview The initial development results in a program folder that is stored electronically (where relevant). Subsequent modifications are monitored via the project Change Control system and each change will result in additional testing documentation clearly documenting the change. Again, these will be stored electronically. Header details and on-line help are recorded in the program itself. CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 33 of 66
  • 36. Coding Standard – ABAP For all new programs, the following components make up the program folder: 1. Program Functional Specification (provided by User/Configurer/Implementation Team member on-site), 2. Program Technical Specification (written internally to ABAP team), 3. Commented program source code (all messages and text elements must be fully commented), 4. Test conditions, 5. Test plan using all test conditions, 6. Test Data used in the Test Plan, 7. Expected Results for each Test Condition in the Test Plan, 8. Actual Results generated when the Test Plan is executed, 9. ALE related interface will also require a configuration script review to validate entries have been added for that particular interface. 10. Program on-line help documentation. Once a program change has been requested. The program folder also contains: 1. Copy of change request 2. Amended source code (commented where appropriate changes have been made) 3. Additional test data and results, along with test plan and test conditions. Source Code Documentation All ABAP developments start with the program name followed by header documentation relating to the purpose of the report. The program author and creation date, together with information relating to the report user is also included. This type of header is also used for custom-built include modules, and custom-built function modules. Example: ************************************************************************ * 1/ Report name: Cost Centre report ************************************************************************ * 2/ Description/program functions ************************************************************************ * * This program is a Cost Centre report, which can be sorted * And summarized in different formats. * ************************************************************************ * 3/ Responsibility ************************************************************************ * Author: A Programmer * Creation Date: 14th February 02 * Requested by: E User * Reference document: (design document) * Owner: Controlling * Project: A Project ************************************************************************ * 4/ External References ************************************************************************ * CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 34 of 66
  • 37. Coding Standard – ABAP * Include modules, input files etc. * ************************************************************************ REPORT ZKEVR034 NO STANDARD PAGE HEADING LINE-SIZE 132 LINE-COUNT 65 MESSAGE-ID ZE. Within the code comments are added as necessary to ensure that the code is clear, readable and maintainable. On-line Help On-line help will accompany all on-line programs. This is held in the Documentation element of the ABAP program. Four sections are usually populated by default and details for each are: Description: an overview of what the program does (and who the program is intended for). Parameters: an explanation of the select options where appropriate. Output:an explanation of the different output options where appropriate This documentation can then be accessed by the user via the Help / Extended Help menu path when running the program. Program Attributes In addition to the title an ABAP report should be given the following attributes: Type: e.g. 1 (Reporting) (as appropriate) Status: K (Customer program) Application: S (Basis) (as appropriate) It is not normally necessary to assign the program to a class but it can be important that an Authorization Group is assigned. This is to ensure that the program can be properly secured but is the responsibility of client authorization specialists to review. Program Modifications Any changes that are made to a program (because a problem has been identified or because further enhancements are required) are carefully documented in the code (as well as in the program folder). A summary of the change is included in the header documentation of the code, immediately below the author details. ************************************************************************* * Revised by: A Programmer * Change Date: 14/2/02 * Change Request: 00001 * Description: Addition of the document type Invoice * Cancellation (N) to the program selection * OSS Note: 00001 (If required) * Changes identified by: XD1 S00K900001 ************************************************************************ The CR (Change Request) number from the Change Request system should be entered so the change details can be referenced, as should the SAP System and Correction number relating to the change. CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 35 of 66
  • 38. Coding Standard – ABAP Code which needs to be changed is not removed but preceded by '*' to remain as comment. Any section changed is surrounded with some form of documentation and commented as normal. The SAP correction and transport number is used to identify each line which change the code applies to, as illustrated in the following example: * Code commented out by A. Programmer 14/02/02 to implement change to add * Doc type invoice cancellation (N) to Credit memo (O) and Debit memo (P) * IF VBRK-VBTYP = 'O' OR VBRK-VBTYP = 'P'. “XD1 S00K900001 CLEAR MAKE_NEGATIVE. “XD1 S00K900001 IF VBRK-VBTYP = 'O'. “XD1 S00K900001 MAKE_NEGATIVE = 'Y'. “XD1 S00K900001 ENDIF. “XD1 S00K900001 * End of code commented out by A. Programmer 12/09/98. Program Testing All code is thoroughly Unit Tested before it is submitted for User Testing. The testing strategy is documented by two documents: • Test Conditions - details what conditions will be tested. • Test Plan - details how the conditions will be tested Test Conditions Before coding, all conditions that will require testing are defined from the Functional Specification. Obviously, as each program differs in its output, it therefore has a set of test conditions unique to itself. However, there are common features to most programs and test conditions that are of general application. The following test conditions (which cannot necessarily be tested on the same test run) are typical: Selection screen Selection screen contains a range of sales organization/plant/division boxes. Selection screen contains a single parameter box for currency, defaulting to the user’s parameter ID setting for currency. Currency parameter box cannot be left blank. Selection Report selects within range of sales organizations/plants/divisions specified. Report selects a single value of sales organization. Report doesn’t select outside the specified ranges. Report verifies that the currency entered in the parameter box is a valid value. Report terminates if the user attempts to view documents for which there is no authorization. Report header Report header displayed correctly once at the top of each page of the report. Report selections displayed correctly on first page beneath report header. Column headers displayed correctly once at the top of each page of the report. Report layout Detail lines formatted correctly. Report is sorted correctly by sales organization, customer... A new page is started for each new plant/sales org/customer/material... Full fields are displayed correctly CS_ABAPCDS – Version 2.0 Select the document classification as per the defined classification in the master list of documents’ for your project <VERY CONFIDENTIAL/CONFIDENTIAL/INTERNALLY RESTRICTED/PUBLIC> Page 36 of 66