56637862-abap-standards.pdf

SAP ABAP

Development

Standards

Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 AM u0092453 /opt/scribd/conversion/tmp/scratch6126/59492316.doc 1 of

65

Document Identification

Summary Information

Title ABAP Development StandardsVersion 4.0Date 3/15/1999Author Kevin Wolfe

How to Find the Latest Version of This DocumentThis document is located in\\Koro\Q-SAP\BIECS SAP Development Team\Standards and Templates\A8 Standards - ABAP Standards.doc

Summary of ChangesVersion Number

Version Date

Revision Comments Added by

1.0 3/15/1999 Initial Creation Kevin Wolfe6/3/1999 Added Application Module LO- Logistics General. Added Application

Submodules: MD under Logistics Data and BD under Production Planning. Josh Duerkop

6/4/1999 Added External Files; directories and file names. Also added useful function modules.

Kevin Wolfe

7/13/1999 Removed Approved by from summary of changes. Added HR submodule under program name. Chged R/L margins from 1.25 to 1.

Kevin Wolfe

7/20/1999 Added PM module and HR submodule to the program name section. Kevin Wolfe9/13/1999 Add SU (subscription) submodule under SD for program naming Kevin Wolfe9/15/1999 Add CA (Cross Applications) module for program naming Kevin Wolfe9/23/1999 Add PC (Product Cost) submodule under CO module Kevin Wolfe11/01/1999 Update Search Help and Lock Objects Kevin Wolfe11/02/1999 Reduced table name to 10 characters since that is all that a change object can handle. Kevin Wolfe12/14/1999 Changed DDIC to refer all work to the Basis team Kevin Wolfe1/26/2000 Update variants to include transport procedure Kevin Wolfe5/6/2002 Changed Prototype in Program Use category to Processing Kevin Wolfe5/7/2002 Changed warning about external forms use because SAP can detect its use from

parent programKevin Wolfe

6/10/2003 1. Program Name naming convention should include descriptive text after the numeric for unique identifier. This greatly simplifies finding related programs without having to go to the extra step of analyzing program descriptions which are often not changed from the default on creation of programs.2. Addition of PR to the application submodule under SD for pricing.3. "Pretty Printer" should be used. The issues with it in the past seem to save been cleared up. Not only do we have a problem with developers using different methods of indentation than other developers, many use different methods between different programs, within the same program and even within the same subroutines.4. Naming convention for structures should be gs_ or ls_ to differentiate structures from individual variable fields.5. Removal of all references to Select...Endselect except to say that it should not be used.6. Field Names in Z tables should have no prefix (currently defined as ZZ). Field names added to standard SAP table should continue to retain the ZZ prefix.7. Function Module naming convention should be Z_MMSS_XXXXX... .

Ryan Kane

12/08/03 Added standards for business object methods and attributes Aaron Pust


65

Table of Contents

OVERVIEW....................................................................................................................................................1

PURPOSE..........................................................................................................................................................1OBJECTIVES......................................................................................................................................................1CONTENT.........................................................................................................................................................1SUPPLEMENTAL DEVELOPMENT MATERIALS..........................................................................................................1TERMINOLOGY..................................................................................................................................................2

Adherence.................................................................................................................................................2Glossary...................................................................................................................................................2

APPLICATION....................................................................................................................................................2

PROGRAM ELEMENTS..............................................................................................................................2

PROGRAM NAME...............................................................................................................................................2ATTRIBUTES.....................................................................................................................................................4

Title...........................................................................................................................................................5Type..........................................................................................................................................................5Status........................................................................................................................................................5Application...............................................................................................................................................5Authorization group.................................................................................................................................5Development class....................................................................................................................................5Fixed point arithmetic..............................................................................................................................6

SOURCE CODE..................................................................................................................................................6Coding Guidelines....................................................................................................................................6

Readability............................................................................................................................................6Functionality.........................................................................................................................................9Performance..........................................................................................................................................9

Declarative Elements.............................................................................................................................10REPORT/PROGRAM........................................................................................................................10TABLES.............................................................................................................................................11TYPES................................................................................................................................................12SELECT-OPTIONS...........................................................................................................................12PARAMETERS..................................................................................................................................13DATA.................................................................................................................................................14CONSTANTS.....................................................................................................................................17RANGES............................................................................................................................................18FIELD-GROUPS................................................................................................................................19FIELD-SYMBOLS.............................................................................................................................20

Event Elements.......................................................................................................................................21AT SELECTION-SCREEN................................................................................................................21START-OF-SELECTION..................................................................................................................21END-OF-SELECTION.......................................................................................................................22AT USER-COMMAND.....................................................................................................................22AT PFn................................................................................................................................................22TOP-OF-PAGE...................................................................................................................................22

Control Elements....................................................................................................................................22IF.........................................................................................................................................................22CASE..................................................................................................................................................23DO.......................................................................................................................................................24WHILE...............................................................................................................................................24LOOP..................................................................................................................................................24FORM (SUBROUTINES)..................................................................................................................25CALL (FUNCTION MODULES)......................................................................................................26

Operational Elements.............................................................................................................................27Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 AM u0092453 /opt/scribd/conversion/tmp/scratch6126/59492316.doc 3 of

65

CHECK...............................................................................................................................................27CLEAR...............................................................................................................................................28COMMIT WORK...............................................................................................................................28CONCATENATE...............................................................................................................................29DELETE.............................................................................................................................................29EXPORT TO MEMORY / IMPORTFROM MEMORY...........................................................29FORMAT............................................................................................................................................30MODIFY.............................................................................................................................................30MOVE/MOVE-CORRESPONDING.................................................................................................30READ TABLE (itab)..........................................................................................................................30SELECT..............................................................................................................................................31WRITE................................................................................................................................................31

Other Source Code Elements.................................................................................................................32COMMENTS......................................................................................................................................32

TEXT ELEMENTS.............................................................................................................................................32Titles and headers..................................................................................................................................32Selection texts.........................................................................................................................................32 Text symbols..........................................................................................................................................33

MESSAGES.....................................................................................................................................................34Long text.................................................................................................................................................35

VARIANTS......................................................................................................................................................35PROGRAM DOCUMENTATION.............................................................................................................................35

REPORT/PROGRAM OUTPUT................................................................................................................36

SELECTION SCREENS........................................................................................................................................36Field Descriptions..................................................................................................................................36Possible Values......................................................................................................................................36Field Help...............................................................................................................................................37

LISTS............................................................................................................................................................37Header....................................................................................................................................................37End of Report Line.............................................................................................................................37Logos......................................................................................................................................................37Field Formats.........................................................................................................................................37

Retail price..........................................................................................................................................38UPC.....................................................................................................................................................38

Audit Reports..........................................................................................................................................38FONTS...........................................................................................................................................................39

DATA DICTIONARY ELEMENTS...........................................................................................................39

TABLES..........................................................................................................................................................39Table Elements Maintenance Approval Procedure...............................................................................39Table Technical Settings Maintenance Approval Procedure.................................................................40

STRUCTURES...................................................................................................................................................40IDOC segments......................................................................................................................................40

VIEWS...........................................................................................................................................................41Database.................................................................................................................................................42Projection...............................................................................................................................................42Help........................................................................................................................................................42

FIELD NAMES..................................................................................................................................................42DATA ELEMENTS.............................................................................................................................................42

Documentation.......................................................................................................................................42DOMAINS.......................................................................................................................................................42TABLE INDEXES..............................................................................................................................................43

Table Index Maintenance Approval Procedure.....................................................................................43LOCK OBJECTS................................................................................................................................................43


65

Lock Objects :.....................................................................................................................................43SEARCH HELP.................................................................................................................................................44

Search Help Objects : ........................................................................................................................44TYPE GROUPS.................................................................................................................................................44

FUNCTION GROUP ELEMENTS............................................................................................................44

FUNCTION GROUPS...........................................................................................................................................44FUNCTION MODULES........................................................................................................................................45DOCUMENTATION............................................................................................................................................45

MISCELLANEOUS DEVELOPMENT ELEMENTS..............................................................................45

TRANSACTIONS...............................................................................................................................................46LOGICAL DATABASES.......................................................................................................................................46

Logical Database...................................................................................................................................46SET/GET PARAMETERS (PARAMETER IDS)......................................................................................................47AREA MENUS..................................................................................................................................................47

PF keys...................................................................................................................................................47MESSAGE CLASSES..........................................................................................................................................47JOBS..............................................................................................................................................................48

Job names...............................................................................................................................................48Event IDs...............................................................................................................................................48

PBO MODULES...............................................................................................................................................48PAI MODULES................................................................................................................................................48DIALOG MODULES...........................................................................................................................................48SCREENS........................................................................................................................................................49MODULE POOLS..............................................................................................................................................49INCLUDE PROGRAMS.........................................................................................................................................49

SCREEN PAINTER.....................................................................................................................................49

BUSINESS OJBECTS..................................................................................................................................51

Methods..................................................................................................................................................52Events.....................................................................................................................................................52Attributes................................................................................................................................................52

BDC SESSIONS / CALL TRANSACTIONS.............................................................................................52

BDC Sessions.........................................................................................................................................52Call Transaction.....................................................................................................................................52

SECURITY....................................................................................................................................................52

SECURING A PROGRAM.....................................................................................................................................53SECURING A TRANSACTION................................................................................................................................53

EXTERNAL FILES......................................................................................................................................53

DIRECTORIES..................................................................................................................................................54FILENAMES.....................................................................................................................................................54

IDOCS....................................................................................................................................................55IDOC Type.........................................................................................................................................55

FTP.............................................................................................................................................................56

APPENDIX ...................................................................................................................................................56

USEFUL FUNCTION MODULES...........................................................................................................................56USEFUL ABAP PROGRAMS.............................................................................................................................57

END OF DOCUMENT.................................................................................................................................59


65


65

OVERVIEW

Purpose

The ABAP (Advanced Business Application Programming) Development Standards document has been created to describe the standards and guidelines to be followed by application programmers when developing applications in SAPs ABAP programming language. The standards described in this document are based on the ABAP Workbench and programming language for SAP version 4.0.

The intended purpose of this document is to describe West Groups development standards for the most common ABAP development elements and topics. It is not intended to describe the functionality or explain how to use the ABAP language. For ABAP language support, you should refer to the SAP ABAP language manuals and on-line help, especially the ABAP Users Guide (from initial SAP screen: Help > Application help > BC Basis Components > BC ABAP Users Guide).

This document will describe the standards defined per ABAP development element, followed by standards for other miscellaneous development topics. Standards for a given development element or topic will include any applicable coding standards and/or naming conventions.

Objectives

The objectives of the development standards contained in this document are to help you, the developer:

Establish naming conventions, which will assist in identifying SAP objects. Develop commonly structured programs. Develop programs that are easily read and understood. Develop software that can be easily maintained. Develop software that is consistent with SAP ABAP software development guidelines. Produce application output that is consistent with SAP application output guidelines.

Content

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

Supplemental Development Materials

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


65

Terminology

Adherence

The following terms will be used throughout this document to define the degree to which your adherence to a listed standard is required:

Shall/Will/Must A Standard. You must adhere to the standard in every case. No exceptions. Should/May A Guideline. You should adhere to the standard whenever possible. Assume Your adherence to the standard is inferred or implicit. Recommend Your adherence to the standard is preferred.

Glossary

Descriptions for ABAP-related terms found throughout this document can be found within the SAP Glossary, which can be accessed via the ABAP Workbench (Help > Glossary).

Application

You shall apply the standards described in this document to all custom-developed applications written in the ABAP programming language.

As a rule, whenever you are in the process of updating a custom application, you should also check the application to ensure that it conforms to the standards set forth in this document. If it does not conform, you should also update the application to bring it up to standard, but only if these updates can be made relatively easily and in a timely fashion.

PROGRAM ELEMENTSThis section defines the development standards for the following ABAP Program Elements:

Program Name

Attributes

Source Code

Text Elements

Messages

Variants

Program Documentation

Program NameThe program name shall be determined based upon the naming convention below. The program name must be approved by the Team Lead before you create the program object.

Naming convention:tmmssuf999nwhere:


65

t.................Type.Y = Data conversions which are one-time loads, and example programs used for demonstration.Z = Applications and permanent interfaces.

mm...............Application Module.AM = Asset Management.BC = Basis.BW = Business Information Warehouse.CA = Cross Applications.CO = Controlling.FI = Financial.LO = Logistics General.MM = Material Management.PA = Personnel Management.PM = Plant Maintenance.PP = Production Planning.PS = Project System.SD = Sales and Distribution.TP = Temporary (local object).XX = Not specific to any one application module.

ss...............Application Submodule.XX = Not specific to any one submodule.

Asset Management Submodules.IC = Investment Control (sale of assets).IM = Investment Management.TA = Technical Asset Accounting (replacement, depreciation).TM = Technical Asset Management & Plant Maintenance.

Basis Submodules.CT = Change Transport System.SC = Security.SM = System Monitoring.

Business Information Warehouse Submodules.None defined at this time.

Controlling Submodules.AC = Activity Based Costing.CC = Cost Center Accounting.EC = Enterprise Controlling.IM = Investment Management.OM = Internal Orders.PA = Profitability Analysis.PC = Product Cost

Financial Submodules.AA = Asset Accounting.AP = Accounts Payable.AR = Accounts Receivable.GL = General Ledger.HR = Human Resources.SP = Special Ledger.

Logistics General Submodules.MD = Basic Data.

Material Management Submodules.PO = Procurement.WM = Warehouse Management.


65

Personnel Management Submodules.HR = Human Resources.

Plant Maintenance Submodules.SM = Service Management.

Production Planning Submodules. BD = Basic Data.

PC = Product Costing.PE = Production Execution.PS = Production Scheduling.

Project System Submodules.QC = Quality Control.PM = Project Management Information System.

Sales and Distribution Submodules.BI = Billing.CU = Customer.DP = Delivery Processing.OP = Order Processing.PR = PricingSI = Sales Information System.SP = Sales Pricing.SU = Subscriptions.

u.................Program Use.B = Bolt-on.C = Conversion.E = Enhancement.I = Interface.N = Include.P = Processing.R = Report.U = Utility.

f.................Intended Program Run Frequency.A = Annually.B = Bi-weeklyC = Conversion Only.D = Daily.M = Monthly.N = Include (not a stand alone program with its own frequency).O = On Demand.P = Accounting Period.Q = Quarterly.W = Weekly.

999............Numeric for unique identifier (lowest sequential # available).n Open. May be used to add descriptive text to program name.

AttributesFollowing are the individual attributes that you should set for a given program:


65

TitleThe title you assign to a program shall reflect the functionality of the program. For reporting programs, this title will also be displayed as the title of the report when used in conjunction with the West Group standard header function Z_HEADER_ROUTINE. The title shall not contain all CAPS and shall not contain a period.

TypeAs required by SAP.

StatusAlthough not required by SAP, it is recommended that you enter an appropriate non-blank value into this field.

ApplicationAs required by SAP.

Authorization groupYou should use this field only if the Functional Team requires authorization at the program level. Work with Basis / SAP Security Administrator to identify the required authorization group, create the authorization group, and test the program level security.

Development classYou must assign a development class to any program that is to be transported. If the program is not to be transported, you must create it as a local object (same as assigning development class $TMP to the program). Development classes help organize our development environment. Below are the development classes to which every development object should be associated. As the need for new development classes arises they will be added to this list. The team leads will request the new development class from Basis and Basis will add the class along with security to the new class. The development class will be required on all technical specs.

Naming convention:

Standard and EDIZOTC Order to Cash ZOTC_SUBS Subscription Maintenance (Add, lapse, transfer, etc.) ZOTC_PSWD Passwords ZOTC_FEDGOV Federal Government ZOTC_BILLING Billing both Westlaw and Print/CD ZOTC_WLPRICING WL Pricing Front-end ZOTC_PRICING Pricing processes and formulas ZOTC_SC Ship and Charge

ZFIN Finance No breakdown currently needed

ZPUB Pub/ManZPUB_WM Warehouse management, deliveries, RF, etc.

ZARCH Archiving No breakdown currently needed


65

ZBAS Basis No breakdown currently needed

ZBWDEV Business Warehouse extractors No breakdown currently needed

ZREPORT ReportingZREPORT_FIN Finance reportsZREPORT_OTC OTC reportsZREPORT_PUB Pub/Man reports

ZECOMM E-CommerceZECOMM_CSS Customer Self Service

ZCRSAPP Cross Application ZCRSAPP_SAPI SAPI application

ZTEST Example Code No breakdown currently needed

Fixed point arithmeticThis attribute is turned on by default when the program is created. You should always leave it on.

Source Code

Coding GuidelinesWhen developing ABAP source code, you should adhere to the following guidelines whenever possible:

Readability Within all programs, you should use structured coding techniques.

Within all non-interactive programs, you should use a top-down design (i.e. never branch backward within your procedural source code).

All of your source code should be developed in a maintainable form. Whenever possible, you should avoid using rarely used coding techniques that will be difficult to understand by another developer. Less code is not necessarily better.

When coding a complex statement such as a call to a function module or a statement with multiple additions, you should import the associated ABAP Editor Pattern for the statement into the source code.

Whenever possible, you should avoid using large blocks of code in one module or form. You should break them down into smaller modules or forms. Each form or module should support one basic program function.

You should code each new ABAP statement on a separate line. You should never combine multiple statements on the same line.

Example:

Standard:

move g_vkorg to gt_sites-vkorg.Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 AM u0092453 /opt/scribd/conversion/tmp/scratch6126/59492316.doc 6 of

65

append gt_sites.Non-standard (DO NOT USE!):

move g_vkorg to gt_sites-vkorg. append gt_sites.

You should group together all common declarative elements (e.g. TABLES, DATA, CONSTANTS) that are declared globally and declare them at the beginning of the program - before any procedural code. (e.g. You should code all global DATA statements consecutively within the program.). PARAMETERS and SELECT-OPTIONS are considered one in the same, so you may code them together.

Example:

Standard:

tables: bdcp, " Change pointer cdpos, " Change document knvh. " Customer hierarchiesdata: g_datab_limit type d, g_event_param like tbtco-eventparm, g_item_cnt type i.constants: gc_false value ' ', gc_article_price_ref value 'p', gc_article_ref_to_new_var value 'o'.Non-standard (DO NOT USE!):

data: g_datab_limit type d, g_event_param like tbtco-eventparm.

constants: gc_false value ' '.

data: g_item_cnt type i.

constants: gc_article_price_ref value 'p', gc_article_ref_to_new_var value 'o'.

You should avoid chaining identical ABAP procedural statements together using the statement keyword with a colon (the exception being the WRITE statement). Chaining is acceptable for declarative elements, such as DATA. For example, when five consecutive moves need to be executed, you should code five separate MOVE statements, each on a separate line, aligning their associated additions (start them in the same column).

Example:

Standard:

move p_vkorg to g_vkorg.Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 AM u0092453 /opt/scribd/conversion/tmp/scratch6126/59492316.doc 7 of

65

move gt_sites-vtweg to g_vtweg.move s_werks-low to g_werks.Non-standard (DO NOT USE!):

move: p_vkorg to g_vkorg. gt_sites-vtweg to g_vtweg. s_werks-low to g_werks.

You should use blank lines whenever necessary to enhance readability.

You should place comments within the program wherever necessary to enhance the understanding of the code.

Indentation:

You must indent each ABAP statement addition from the statement keyword(s) when coding the additions on subsequent lines. Two or four characters per indentation is a good guideline. When coding multiple additions for one statement on subsequent lines, you must align each addition (start in same column)..

Example:select wkfil from zrzn1 into wl-werks where vkorg = gt_worklist-vkorg and vtweg = gt_worklist-vtweg and matnr = gt_wl_mat-matnr and zz_zone = gt_acclevel-zz_zone.

When coding a looping structure (LOOPENDLOOP, DOENDDO, etc.) or any other logic block that is defined by a main keyword and its associated ENDxxx keyword, you must align the main keyword with its associated ENDxxx keyword and indent all statements between these two keywords. When coding the statements between the two keywords, you should not start them in the same column as the additions to the main keyword if coding each addition on a separate line.

Example:loop at gt_kvgr where kvgr1 = l_kvgr1 and kvgr2 = l_kvgr2. gt_worklist-werks = gt_kvgr-werks. append gt_worklist.endloop.

It is recommended that you use SAPs Pretty Printer function to indent and align your source code. Pretty Printer can be found in the ABAP editor under Menu path ProgramPretty Printer.

When updating source code, you must code the new logic to conform to the modularity, structure, and style of the original source code (providing this code adheres to the coding standards set forth in this document).


65

When naming declarative elements (except for CONSTANTS), you should use an associated Data Dictionary table field name after the standard naming convention prefix whenever possible. For example, you would use g_vkorg to name a global variable for storing the sales organization field. When naming other declarative elements and/or other types of development elements, you should use meaningful, yet concise object names.

Functionality If an object to be updated is already being edited by another developer, you should confer with your

Team Lead before making any changes to that object. Changing that object will cause another task to be created under the CTS (Change and Transport System) request for that object, and this is not always the desired result.

When accessing the database, you should use ABAP Open SQL whenever possible. You may only use Native SQL under extraordinary circumstances and only with approval from your Team Lead.

When necessary to access database table data repetitively or continuously, you should select the appropriate data from the database and load it into an internal table, then access it from the internal table. This will increase your programs efficiency by eliminating multiple database reads and reducing network traffic.

You should always check the return code (SY-SUBRC) after executing a function module call, a database table access statement, or an internal table access statement.

You should never code literals (text between quotes) within any procedural code. You should declare all literals as either text symbols within the text elements of your program or as constants (using the CONSTANT statement) within the data declaration area of your program.

When coding commonly used functionality, you should use a FORM if the functionality is to be used only by that program. Otherwise, use a function module or include program if multiple programs could use the functionality. As always, be sure to check if one already exists.

Frequently used data elements occurring within multiple related programs should be defined within an INCLUDE module or program, and each program should access this INCLUDE module.

Performance Is the program using SELECT * statements?

You should convert them to SELECT column 1 column 2 or use projection views.

Are CHECK statements for table fields embedded in a SELECTENDSELECT loop?You should incorporate the CHECK statements into the WHERE clause of the SELECT statement and re-write the statement to no longer use ENDSELECT.

Do SELECTs on non-key fields use an appropriate DB index or is the table buffered?You should create an index for the table in the data dictionary or buffer the tables if they are read only or read mostly. (You must go through the proper approval procedures before creating or updating any table indexes or table buffering. See the Tables chapter of the Data Dictionary Elements section of this document.)

Is the program using nested SELECTs to retrieve data?You should convert nested SELECTs to database views (see Views in the Data Dictionary section of this document), DB joins or SELECT FOR ALL ENTRIES IN ITAB.

Are there SELECTs without WHERE condition against files that grow constantly (BSEG, MKPF, VBAK)?Your program design is wrong - back to the drawing board.


65

Are SELECT accesses to master data files buffered (i.e. no duplicate accesses with the same key)?You should buffer accesses to master data fields within your program by storing the data in an internal table and accessing the table with the READ TABLE BINARY SEARCH method.

Is the program using SELECT APPEND ITAB ENDSELECT techniques to fill internal tables?You should change the processing to read the data immediately into an internal table (SELECT VBLEN AUART INTO TABLE IVBAK)

Is the program using SELECT ORDER BY statements?You should read the data into an internal table first and then sort it, unless there is an appropriate index for the order by fields.

Is the programming doing calculations/summations that can be done on the database via SUM, AVG, MIN, MAX functions for the SELECT statement?You should use the calculation capabilities of the database via SELECT SUM

Are internal tables processed using the READ TABLE itab WITH KEY BINARY SEARCH technique?If not, you should sort the tables and change the table accesses to use BINARY SEARCH method.

Is the program inserting/updating or deleting data in dialog mode (not via an update function module)?You should make sure that the program issues COMMIT WORK statements when one or more logical units of work (LUWs) have been processed.

Declarative ElementsThe term "Declarative Elements" is used to describe the programming elements available to you for defining the internal environment the program will run under. Basically, this is everything that is not logic or procedural code. This section defines the development standards for the following Declarative Elements:

REPORT/PROGRAM TABLES TYPES SELECT-OPTIONS PARAMETERS DATA CONSTANTS RANGES FIELD-SYMBOLS

REPORT/PROGRAMIn the ABAP development environment, the terms report and program along with their associated keywords "REPORT" and "PROGRAM" are used interchangeably. You may use either of these keywords when creating an ABAP program.

Note: It is recommended that you create all new programs via the Repository Browser instead of using the ABAP Editor directly. When a program is created via the Repository Browser, a source code template is created for the entire program. This template consists of comment lines for entering a program description, the standard format for the REPORT statement, and standard formats for other program elements and Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 AM u0092453 /opt/scribd/conversion/tmp/scratch6126/59492316.doc 10 of

65

keywords (only comment lines for now, need to create the rest). You can then make the necessary changes to this template using the ABAP Editor. This template is not provided when you create a program directly from within the ABAP Editor.

When coding the REPORT statement, you must: Declare it as the first executable statement in your program, starting the REPORT keyword in column

1. Always include the MESSAGE-ID, LINE-COUNT, LINE-SIZE, and NO STANDARD PAGE

HEADING additions to this statement (they are already included in the REPORT statement template(Need to create it)).

Declare each statement addition on a separate line, indenting each consistently to the right of the REPORT keyword.

Update the MESSAGE-ID addition with the West Group message class associated with the SAP functional group for which the program is written. For example, all programs written for the SAP Financial functional group in the Accounts Payable area (program name ZFIAPxxxxx) shall use message ID (message class) ZFIAPxxxxx.

The NO STANDARD PAGE HEADING addition inactivates the standard SAP report header and allows for the use of the West Group standard report header instead. The West Group standard header function Z_HEADER_ROUTINE will control the formatting of all report headings, plus the end of report line. See the REPORT/PROGRAM OUTPUT section of this document for more information about function Z_HEADER_ROUTINE.

Naming convention:

When declaring the REPORT/PROGRAM name, you should use the Program Name you assigned to the program when you created it.

Example:*----------------------------------------------------------------------** ZFIGLRA001_SITE_MID_YEAR_BUDGET - Site mid-year budget report by ** quarter, wholesale ** ** This program creates the Site Mid-Year Budget Report by Quarter ** for a wholesale site. **----------------------------------------------------------------------*report zfiglra001_site_mid_year_budget no standard page heading line-size 132 line-count 65 message-id zfiap.

TABLESWhen coding the TABLES statement, you must: Start the TABLES keyword in column 1. Declare each database table on a separate line immediately after the TABLES keyword. Consistently indent each declared table name to the right of the TABLES keyword. Declare all global tables together under one TABLES statement, immediately following the REPORT

statement in your program. A global table is defined as a table declared outside of a FORM subroutine or function module, enabling you to reference it from anywhere within your program.


65

You may order the tables any way you like, although alphabetizing is recommended. Including the table description as an in-line comment is optional.

Example:tables: cosp, "Cost Totals - External Postings cosr, "Statistical Ratio Totals csks, "Cost Center Master cskt. "Cost Center Texts

TYPESWhen coding the TYPES statement, you must: Start the TYPES keyword in column 1. Declare each user-defined type on a separate line immediately after the TYPES keyword. Consistently indent each declared type to the right of the TYPES keyword. Declare all global types together under one TYPES statement, immediately following the TABLES

statement in your program. A global type is defined as a type declared outside of a FORM subroutine or function module, enabling you to reference it from anywhere within your program.

Naming convention:

You must code each TYPES name with a standard prefix of z.

Example:types: zamt type p decimals 2, zdept(3) type c.

SELECT-OPTIONSWhen coding SELECT-OPTIONS statements, you must: Start the SELECT-OPTIONS keyword in column 1 unless it is subordinate to a SELECTION-

SCREEN statement, in which case you must code it on the following line and indent it to the right of the SELECTION-SCREEN keyword.

Declare only one individual selection option on a given line. You may declare the selection option either on the same line as the SELECT-OPTIONS keyword or on the next line following the SELECT-OPTIONS keyword. It is recommended that you include the SELECT-OPTIONS keyword for each declared selection option.

Consistently indent each declared selection option to the right of the SELECT-OPTIONS keyword (when declaring on the following line).

Consistently indent each associated addition for a given selection option to the right of the SELECT-OPTIONS keyword.

If you are declaring a select option field that has a set number of possible values, you must display a possible values box when the user places the cursor on either the low or high range field. To accomplish this, you must code the associated FOR field of the SELECT-OPTIONS statement as either a Data Dictionary field that points to Check Table, a Data Dictionary field that points to a domain that has an


65

associated values list, or an internal table field in which the table contains all possible values for the field. See the Selection Screens chapter of the REPORT/PROGRAM OUTPUT section of this document for more information on possible values boxes.

Naming convention:

You must code each SELECT-OPTIONS name with a standard prefix of s_.

Examples:select-options: s_vkorg for wkbp-vkorg default 3276 obligatory.select-options: s_vtweg for wkbp-vtweg.select-options: s_werks for wkbp-werks.-- or --select-options: s_vkorg for wkbp-vkorg default 3276 obligatory, s_vtweg for wkbp-vtweg, s_werks for wkbp-werks.

PARAMETERSWhen coding PARAMETERS statements, you must: Start the PARAMETERS keyword in column 1 unless it is subordinate to a SELECTION-SCREEN

statement, in which case you must code it on the following line and indent it to the right of the SELECTION-SCREEN keyword.

Declare only one individual parameter on a given line. You may declare the parameter either on the same line as the PARAMETERS keyword or on the next line following the PARAMETERS keyword. It is recommended that you include the PARAMETERS keyword for each declared parameter.

Consistently indent each declared parameter to the right of the PARAMETERS keyword (when declaring on the following line).

Consistently indent each associated addition for a given parameter to the right of the PARAMETERS keyword.

If you are declaring a parameter field that has a set number of possible values, you must display a possible values box when the user places the cursor on that field. To accomplish this, you must code the associated LIKE field of the PARAMETERS statement as either a Data Dictionary field that points to Check Table, a Data Dictionary field that points to a domain that has an associated values list, or an internal table field in which the table contains all possible values for the field. See the Selection Screens chapter of the REPORT/PROGRAM OUTPUT section of this document for more information on possible values boxes.

Naming convention:

You must code each PARAMETERS name with a standard prefix of p_.

Examples:Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 AM u0092453 /opt/scribd/conversion/tmp/scratch6126/59492316.doc 13 of

65

parameters: p_vkorg like wkbp-vkorg.parameters: p_vtweg like wkbp-vtweg.parameters: p_count type I default 50 obligatory.-- or --parameters: p_vkorg like wkbp-vkorg. p_vtweg like wkbp-vtweg. p_count type I default 50 obligatory.

DATAWhen coding DATA statements, you must: Start the DATA keyword in column 1 if it is a global variable, or column 3 if it is a local variable.

Global variable . This is defined as a data work field or structure declared outside of a FORM subroutine or function module. You are able to reference it from anywhere within the program. Local variable . This is defined as a data work field or structure declared within a FORM subroutine or function module. You are only able to reference it from within that form or function.

When declaring individual work fields, you must:

Declare each field on a separate line immediately after the DATA keyword. You may declare the DATA keyword multiple times to create logical groupings of work fields for clarity and readability purposes. You may list the declared fields within a given DATA statement in any order.

Consistently indent each declared field to the right of the DATA keyword. Align all similar additions for each individual work field together within a given DATA keyword

grouping (e.g. TYPE, VALUE). You may consider the TYPE and LIKE additions as one in the same for alignment purposes.

Use the LIKE addition whenever possible to reference a Data Dictionary field.When declaring an internal table or data structure, you must:

Code the BEGIN OF variant either on the same line as the DATA keyword or on the following line. If you code it on the following line, you must indent it to the right of the DATA keyword.

Declare each individual work field or include structure belonging to this data structure/internal table on a separate line following the statement containing the BEGIN OF variant.

Indent each individual work field consistently to the right of the BEGIN OF variant. Code the END OF variant on a separate line after the last declared individual work field or include

structure of the data structure/internal table. Align the END OF variant with the BEGIN OF variant. Code one DATA statement using the LIKE (structure name) addition when declaring a data structure

that is identical to a Data Dictionary structure. Do not use the INCLUDE STRUCTURE keywords. Code one DATA statement using the LIKE (structure name) addition when declaring an internal table

to be loaded with database table data (for repetitive processing) and all of the database table fields are to be accessed.


65

Code a group of individual data fields, each using the LIKE (table field) addition when declaring an internal table to be loaded with database table data (for repetitive processing) and only a subset of the database tables fields are to be accessed.

Set the OCCURS value for internal tables (used to define their size) to 0 if the table will contain more than 8K-bytes of data. Otherwise, estimate the actual table size and set the OCCURS value accordingly.

Naming convention:

When declaring DATA names, you must: Include a standard prefix of g_ for each global individual work field. Do not include this prefix for

individual work fields declared within a structure or internal table. Include a standard prefix of l_ for each local individual work field. Do not include this prefix for

individual work fields declared within a structure or internal table. Include a standard prefix of gs_ for each global structure. Include a standard prefix of ls_ for each local structure. Include a standard prefix of gt_ for each global internal table. Include a standard prefix of lt_ for each local internal table. Use the standard prefix plus the associated Data Dictionary field name or system variable, whenever

possible, when naming an individual work field. Never include a hyphen ( - ) within an individual work field name. You may include underscores ( _ ).

Examples:

Individual work fields (global variables):

data: g_vkorg like wkbp-vkorg, g_vtweg like wkbp-vtweg. g_count type i value 20.Individual work fields (local variables):

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

data: begin of gs_orglevel, vkorg like wkbp-vkorg, vtweg like wkbp-vtweg, werks like wkbp-werks, end of gs_orglevel.-- or --data: begin of gs_orglevel, vkorg like wkbp-vkorg,Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 AM u0092453 /opt/scribd/conversion/tmp/scratch6126/59492316.doc 15 of

65

vtweg like wkbp-vtweg, werks like wkbp-werks, end of gs_orglevel.data: g_cust like kna1.Data structures (local):

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

data: begin of gt_cust occurs 0, vkorg like wkbp-vkorg, vtweg like wkbp-vtweg, werks like wkbp-werks, end of gt_cust.-- or --data: begin of gt_cust occurs 0, vkorg like wkbp-vkorg, vtweg like wkbp-vtweg, werks like wkbp-werks, end of gt_cust.Internal table (local):

form newform. data: begin of lt_cust occurs 0,Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 AM u0092453 /opt/scribd/conversion/tmp/scratch6126/59492316.doc 16 of

65

vkorg like wkbp-vkorg, vtweg like wkbp-vtweg, werks like wkbp-werks, end of lt_cust. . . .endform.-- or --form newform. data: begin of lt_cust occurs 0, vkorg like wkbp-vkorg, vtweg like wkbp-vtweg, werks like wkbp-werks, end of lt_cust. . . .endform.

CONSTANTSWhen coding CONSTANTS statements, you must: Start the CONSTANTS keyword in column 1 if it is a global constant, or column 3 if it is a local

constant. Global constant . This is defined as an individual field or structure declared outside of a FORM subroutine or function module. You are able to reference it from anywhere within the program. Local constant . This is defined as an individual field or structure declared within a FORM subroutine or function module. You are only able to reference it from within that form or function.

When declaring individual constant fields, you must:

Declare each field on a separate line immediately after the CONSTANTS keyword. You may declare the CONSTANTS keyword multiple times to create logical groupings of constant fields for clarity and readability purposes. You may list the declared fields within a CONSTANTS statement in any order.

Consistently indent each declared field to the right of the CONSTANTS keyword. Align all similar additions for each individual constant field together within a given CONSTANTS

keyword grouping (e.g. TYPE, VALUE). You may consider the TYPE and LIKE additions as one in the same for alignment purposes.

Use the LIKE addition whenever possible to reference a Data Dictionary field.When declaring a constant structure, you must:

Code the BEGIN OF variant either on the same line as the CONSTANTS keyword or on the following line. If you code it on the following line, you must indent it to the right of the CONSTANTS keyword.

Declare each individual constant field belonging to this structure on a separate line following the statement containing the BEGIN OF variant.

Consistently indent each individual constant field consistently to the right of the BEGIN OF variant. Code the END OF variant on a separate line after the last declared individual constant field of the

structure.Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 AM u0092453 /opt/scribd/conversion/tmp/scratch6126/59492316.doc 17 of

65

Align the END OF variant with the BEGIN OF variant. Use the LIKE addition whenever possible to reference a Data Dictionary field.

Naming convention:

When declaring CONSTANTS names, you must: Include a standard prefix of gc_ for each global individual work field or structure. Do not include this

prefix for individual work fields declared within a structure or internal table. Include a standard prefix of lc_ for each local individual work field or structure. Do not include this

prefix for individual work fields declared within a structure or internal table. Use the standard prefix plus a descriptive, concise field name. Never include a hyphen ( - ). You may include underscores ( _ ).

Examples:

Individual fields (global):

constants: gc_sales_org_wg like wkbp-vkorg value 4844 gc_dist_chan_01 like wkbp-vtweg value 01, gc_max_entries type i value 100.Individual fields (local):

form newform. constants: lc_sales_org_wg like wkbp-vkorg value 4844, lc_dist_chan_01 like wkbp-vtweg value 01, lc_max_entries type i value 100. . . .endform.Structures (global):

constants: begin of gc_orglevel, sales_org_wg like wkbp-vkorg value 4844, dist_chan_01 like wkbp-vtweg value 01, site_4422 like wkbp-werks value 4422, end of gc_orglevel.-- or --constants: begin of gc_orglevel, sales_org_wg like wkbp-vkorg value 4844, dist_chan_01 like wkbp-vtweg value 01, site_4422 like wkbp-werks value 4422, end of gc_orglevel.

RANGESWhen coding RANGES statements, you must: Start the RANGES keyword in column 1 if it is a global range, or column 3 if it is a local range.Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 AM u0092453 /opt/scribd/conversion/tmp/scratch6126/59492316.doc 18 of

65

Global range . This is defined as a range declared outside of a FORM subroutine or function module. You are able to reference it from anywhere within the program. Local range . This is defined as a range declared within a FORM subroutine or function module. You are only able to reference it from within that form or function.

Declare each range on a separate line immediately after the RANGES keyword. You may declare the RANGES keyword multiple times to create logical groupings of ranges for clarity and readability purposes. You may list the declared ranges within a given RANGES statement in any order.

Consistently indent each declared range to the right of the RANGES keyword. Align all FOR clauses underneath each other for each declared individual range within a given

RANGES keyword grouping.

Naming convention:

When declaring RANGES names, you must: Include a standard prefix of gr_ for each global range. Include a standard prefix of lr_ for each local range. Use the standard prefix plus the associated Data Dictionary field name or system variable whenever

possible. Never include a hyphen ( - ). You may include underscores ( _ ).

Examples:

Global:

ranges: gr_vkorg for wkbp-vkorg, gr_vtweg for wkbp-vtweg.Local:

form newform. ranges: lr_vkorg for wkbp-vkorg, lr_vtweg for wkbp-vtweg. . . .endform.

FIELD-GROUPSWhen coding FIELD-GROUPS statements, you must: Start the FIELD-GROUPS keyword in column 1. Declare each individual group on a separate line immediately after the FIELD-GROUPS keyword. Consistently indent each declared group to the right of the FIELD-GROUPS keyword. Always name the first group fg_header (available sort fields) and follow it with the remaining

groups, giving each group a meaningful name. Follow the FIELD-GROUPS declaration with the appropriate INSERT statement required to insert

field names into each field group. Start each new INSERT statement in column 1. Declare each individual insert field on a separate line immediately after the INSERT keyword.Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 AM u0092453 /opt/scribd/conversion/tmp/scratch6126/59492316.doc 19 of

65

Consistently indent each declared insert field to the right of the INSERT keyword. Use a corresponding Data Dictionary field, whenever possible, when declaring an insert field.

Naming convention:

When declaring FIELD-GROUPS names, you must: Include a standard prefix of fg_. Use the standard prefix plus a descriptive, concise name. Never include a hyphen ( - ). You may include underscores ( _ ).

Examples:field-groups: fg_header. fg_detail.insert wkbp-vkorg wkbp-vtweg into fg_header.insert wkbp-werks wkbp-matnr into fg_detail.

FIELD-SYMBOLSWhen coding FIELD-SYMBOLS statements, you must: Start the FIELD-SYMBOLS keyword in column 1 if it is a global field symbol, or column 3 if it is a

local field symbol. Global field symbol . This is defined as a field symbol declared outside of a FORM subroutine or function module. You are able to reference it from anywhere within the program. Local field symbol . This is defined as a field symbol declared within a FORM subroutine or function module. You are only able to reference it from within that form or function.

Declare each field symbol on a separate line immediately after the FIELD-SYMBOLS keyword. You may declare the FIELD-SYMBOLS keyword multiple times to create logical groupings of field symbols for clarity and readability purposes. You may list the declared field symbol within a given FIELD-SYMBOLS statement in any order.

Consistently indent each declared field symbol to the right of the FIELD-SYMBOLS keyword.

Naming convention:

When declaring FIELD-SYMBOLS names, you must: Include a standard prefix of gfs_ for each global field symbol. Include a standard prefix of lfs_ for each local field symbol. Use the standard prefix plus a descriptive, concise name. Never include a hyphen ( - ). You may include underscores ( _ ).


65

Examples:

Global:

field_symbols: , .Local:

form newform. field_symbols: , . . . .endform.

Event ElementsThe term "Event Elements" is used to describe the programming elements available to you for designating a set of statements to be executed at a certain point in time or upon the occurrence of a specific event during execution of your program.

When coding event element keywords, you must start them in column 1. When applicable, you should code the events in the order that they will be executed.

This section defines the development standards for the following Event Elements:

AT SELECTION SCREEN START-OF-SELECTION END-OF-SELECTION AT USER-COMMAND AT PFn TOP-OF-PAGE

AT SELECTION-SCREENON pselYou should use the AT SELECTION-SCREEN event with the ON psel addition, where psel is a parameter or select-options field, when editing selection screen input for an individual field. If the validity of a parameter or select-options field is dependent upon the value of another parameter or select-options field, you should edit the parameter or select-options field within a stand-alone AT SELECTION-SCREEN event (without any additions).

ON HELP-REQUESTYou shall not use the ON HELP-REQUEST addition. You will generate field help using other methods (see the Selection Screens chapter of the REPORT/PROGRAM OUTPUT section of this document).

START-OF-SELECTIONYou must code the START-OF-SELECTION event in all your ABAP reporting programs.


65

END-OF-SELECTIONYou must code the END-OF-SELECTION event in all your ABAP reporting programs. Within this event, you shall print the end of report line (imported via function module Z_HEADER_ROUTINE). See the REPORT/PROGRAM OUTPUT section of this document for more information on function module Z_HEADER_ROUTINE.

AT USER-COMMANDYou shall use the AT USER-COMMAND event within interactive programs to interrogate user selections via function key or the command field. Do not use the AT PFn event for this purpose.

AT PFnYou shall not use the AT PFn event, except for testing purposes. Use the AT USER-COMMAND event instead.

TOP-OF-PAGEYou must include the TOP-OF-PAGE event in all your ABAP programs that produce list report(s). Within this event, you shall print the standard report header lines (imported via function module Z_HEADER_ROUTINE). See the REPORT/PROGRAM OUTPUT section of this document for more information on function module Z_HEADER_ROUTINE.DURING LINE-SELECTIONYou must include the TOP-OF-PAGE event with the DURING LINE-SELECTION addition in all your ABAP programs that will contain drill-down online reporting capability.

All standards that apply to TOP-OP-PAGE will also apply to TOP OF PAGE DURING LINE-SELECTION.

Control ElementsThe term "Control Elements" is used to describe the programming elements available to you for controlling the flow of your program within some type of processing block of logic. This section defines the development standards for the following Control Elements:

IF CASE ON CHANGE OF DO WHILE LOOP FORM (SUBROUTINES) CALL (FUNCTION MODULES)

IFWhen coding an IF statement, you must: Align the ELSE (when used), ELSEIF (when used), and ENDIF keywords with the IF keyword.


65

Consistently indent to the right of the IF keyword all other statements between the IF and ENDIF statements that do not contain one of these keywords.

Code the ELSE keyword as the only word on that line (when used). You should start all statements associated with a particular ELSE clause on the line following the ELSE keyword and consistently indent them to the right of the ELSE keyword.

Keep nested IF statements to a minimum for readability. Alternatively, you should use PERFORM and CASE statements. When you need to check the same data field repeatedly for particular values, you should use a CASE statement instead of an IF statement. The CASE statement is more efficient than the IF statement in this situation.

Examples:if bkpf-belnr = g_invoice_nbr. perform process_invoice.else perform check_document_nbr.endif.if g_rec_type = gc_header_rec. perform process_header_rec.elseif g_vtweg = gc_vtweg_military. perform process_military.elseif g_vkorg = gc_vkorg_rc. perform process_vkorg_rc.endif.

CASEWhen coding an CASE statement, you must: Code each WHEN clause on a separate line and indent each WHEN keyword consistently to the right of

the CASE keyword. Code all WHEN clauses in the order that they are most likely to occur (most likely will go first). Code each logical expression for a given WHEN clause on a separate line after the WHEN keyword and

consistently indent it to the right of the WHEN keyword. Align the ENDCASE keyword with the CASE keyword. Keep nested CASE statements to a minimum for readability. Alternatively, you may use PERFORM

statements. Always use the WHEN OTHERS clause. If no action is to be taken when branching to the WHEN

OTHERS clause, you would not code any procedural statements underneath it.

Example:case g_rec_type. when gc_rec_type_a. perform process_report_1. when gc_rec_type_b or gc_rec_type_c. perform process_report_2. when gc_rec_type_d. perform process_report_3. when others. perform invalid_rec_type.endcase.Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 AM u0092453 /opt/scribd/conversion/tmp/scratch6126/59492316.doc 23 of

65

DOWhen coding the DO control element, you must follow the coding indentation rules as stated in the Coding Guidelines previously mentioned in this section of the document.

You must always code the DO control element with a controlled exit point (such as a TIMES variant or an EXIT statement) to avoid a continuous loop.Whenever possible, you should use a WHILE loop instead of a DOENDDO construct because it is slightly more efficient.

Examples:do. read dataset pinfile into g_rzone_h. if sy-subrc 0. exit. endif.enddo.do 5 times varying g_letter1 from g_word1 then g_word3 varying g_letter2 from g_word2 then g_word4. write: g_letter1, g_letter2.enddo.

WHILEWhen coding the WHILE control element, you must follow the coding indentation rules as stated in the Coding Guidelines area of this chapter of the document.

Whenever possible, you should use a WHILE loop instead of a DOENDDO construct because it is slightly more efficient.

Examples:while g_cnt < 10. perform main_process. add 1 to g_cnt.endwhile.while g_cnt < 10 vary g_letter1 from g_word1 next g_word3 vary g_letter2 from g_word2 next g_word4. write: g_letter1, g_letter2. add 1 to g_cnt.endwhile.

LOOPWhen coding the LOOP control element, you must follow the coding indentation rules as stated in the Coding Guidelines area of this chapter of the document with the following exception: the FROM and TO additions may be on the same line.


65

Warning: You should use the AT additions at your own risk. Unless you loop through the entire internal table (i.e. not using the WHERE addition) and first sort the internal table in the order that the internal table fields are declared, you may get unpredictable results.

Examples:loop at lt_mara. lt_zrbpw-matnr = lt_mara-matnr. append lt_zrbpw.endloop.loop at lt_mara where mchl3 = g_mchl3. lt_zrbpw-matnr = lt_mara-matnr. append lt_zrbpw.endloop.loop at lt_mara from 1 to 10. lt_zrbpw-matnr = lt_mara-matnr. append lt_zrbpw.endloop.

FORM (SUBROUTINES)When coding the FORM control element, you must follow the coding indentation rules as stated in the Coding Guidelines area of this chapter of the document.

You should use the ABAP Editor Pattern when coding the FORM statement. This will ensure that a standard comment box for the form will be imported into the source code. There are two ways to import a FORM pattern into the source code: by double-clicking on the associated PERFORM statement, which will place the form at the end of the program, or by importing the FORM pattern using Other Patterns at the bottom of the Pattern dialog box, which will place the form at the cursor position.

The use of internal subroutines are imperative in developing well-structured programs. Wherever possible, you should place logically associated command statements into subroutines within your program.

You must code all FORM subroutines after the END-OF-SELECTION event and order them according to their execution sequence. You should always code a FORM subroutine after its associated PERFORM statement to give the program a top-down design.

It is recommended that you do not call a FORM subroutine from within your program that has been declared in another program (external subroutine). This is because the entire parent program of the external form will get pulled into runtime memory. As an alternative, you should consider either putting the subroutine logic into a function module or an include program. Whenever possible, you should not duplicate the same code in multiple programs.

Naming convention:

When declaring FORM names, you must: Use meaningful, descriptive, concise names. Never include a hyphen ( - ). You may include underscores ( _ ).

When declaring FORM parameter names (in the USING addition without the VALUE clause), you must: Include a standard prefix of f_ for each individual work field. Include a standard prefix of ft_ for each internal table.Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 AM u0092453 /opt/scribd/conversion/tmp/scratch6126/59492316.doc 25 of

65

Excluding the standard prefix, use a name that is identical to the respective parameter name listed in the USING addition of the corresponding PERFORM statement.

Use meaningful, descriptive, concise names. Never include a hyphen ( - ). You may include underscores ( _ ).

Tip: To quickly find a particular FORM subroutine within your program, especially a hard copy, you may consider adding a prefix to each FORM name in the format X999, where X is any alphanumeric character and 999 is any number, then place the FORM subroutines within the program in alphanumeric sequence (i.e. A000, A100, A110, A200, B000, B100, C000, etc.).

Examples:

NOTE: Use the Pattern for the FORM statement via the ABAP Editor. *----------------------------------------------------------------------** Form ADD_WL_MAT_MC*----------------------------------------------------------------------** Select all articles for a given merchandise category.*----------------------------------------------------------------------*form add_wl_mat_mc. loop at lt_mara where matkl = g-matkl. lt_zrbpw-matnr = lt_mara-matnr. append lt_zrbpw. endloop.endform. ADD_WL_MAT_MCExample of USING addition (without the VALUE clause):

perform lock_table_w using svkorg-low pvtweg.form lock_table_w using f_vkorg f_vtweg. zrbpl-vkorg = f_vkorg. zrbpl-vtweg = f_vtweg. modify zrbpl. commit work.endform. LOCK_TABLE_W

CALL (FUNCTION MODULES)It is strongly recommended that you use the appropriate ABAP Editor Pattern when coding the CALL statement to ensure that you include all associated parameters for the given function module. You may delete any unused parameters from the CALL statement to enhance readability.You must always check the return code (SY-SUBRC) after executing a CALL to a function module.

Example:call function 'job_close' exporting event_id = 'R_BGP_VKPB_JOBSTART' event_param = g_event_param jobcount = g_jobnr jobname = f_jobname importingLast changed on: Last changed by: File name: Page:2/3/2006 11:58:00 AM u0092453 /opt/scribd/conversion/tmp/scratch6126/59492316.doc 26 of

65

job_was_released = g_job_subrc exceptions cant_start_immediate = 1 invalid_startdate = 2 jobname_missing = 3 job_close_failed = 4 job_nosteps = 5 job_notex = 6 lock_failed = 7 others = 8.case sy-subrc. when 0. write: text-001. when others. message e999 with sy-subrc.endcase.

Operational ElementsThe term "Operational Elements" is used to describe the programming elements available to you for performing some type of operational action on any of the data elements of your program. This section defines the development standards for the following Operational Elements:

CHECK CLEAR COMMIT WORK CONCATENATE DELETE EXPORTTO MEMORY / IMPORTFROM MEMORY FORMAT MODIFY MOVE/MOVE-CORRESPONDING READ TABLE (itab) SELECT WRITE

CHECKIt is recommended that you use the CHECK statement instead of the IFEXITENDIF structure when determining if a looping structure or routine shall be terminated.

You should not use the CHECK statement within a SELECTENDSELECT construct to determine which rows should be processed. Use the WHERE addition of the SELECT statement instead and change the statement to no longer use ENDSELECT.

Examples:

Standard method of terminating a looping structure


65

form read_itab. read table itab where werks = p_werks binary search. check sy-subrc = 0. . . .endform.Non-standard method of terminating a looping structure (DO NOT USE!)

form read_itab. read table itab where werks = p_werks binary search. if sy-subrc 0. exit. endif. . . .endform.

CLEARIt is recommended that you use the CLEAR statement for setting a field to its initial value.

Examples:data: g_integer value i,. g_char value c, . . .Standard method of initializing field

clear g_integer. clear g_char.Non-standard methods of initializing field (DO NOT USE!)

g_integer = 0. move 0 to g_integer. g_char = space. g_char = . move space to g_char.

COMMIT WORKYou should always issue a COMMIT WORK after performing a large number of updates (changes/inserts/deletes) to the database. You should issue it in the context of a logical unit of work (LUW), such that if the next COMMIT WORK fails, the database is not out of sync. For example, if update A and update B both need to be in the database for it to be logically correct, then you need to issue the


65

COMMIT WORK after update B. This is necessary so that if update B fails you can ROLLBACK update A so that the database stays consistent. If update A and update B are not related and update A could affect a large number of records (say 1000 records) then you should issue a COMMIT WORK following both update A and update B.

CONCATENATEIt is recommended that you use the CONCATENATE statement for joining character strings together outside of a looping structure or within a looping structure that will have a minimum amount of loops. It is generally more clear and efficient than using a data structure. You should use a data structure when joining character strings within a looping structure that will loop a significant amount of times, or if the concatenation involves many fields and incorporating them all into one CONCATENATE statement would become difficult to read.

DELETEIf you need to delete multiple database or internal table entries - all containing the same characteristics - you should use the WHERE addition of the DELETE statement, as opposed to the DELETE statement within a looping structure.

Examples:

Standard method of deleting database table entries with similar characteristics

delete table zrbpc where posted = gc_yes or sleeping = gc_yes.Non-standard method of deleting database table entries with similar characteristics (DO NOT USE!)

select * from zrbpc where posted = gc_yes and sleeping = gc_yes. delete zrbpc.endselect.

EXPORT TO MEMORY / IMPORTFROM MEMORYYou should always use the ID addition with the EXPORT or IMPORT statement.You may code the entire EXPORTTO MEMORY / IMPORTFROM MEMORY statement, including the ID addition, on the same line. It is recommended that you align all TO MEMORY keywords together, all FROM MEMORY keywords together, and the ID keywords together for each consecutive statement.

Naming convention:

When declaring ID names, you must: Include a standard prefix of m_progname_ for each ID identifying an individual work field, where

progname is the name of the exporting program. Include a standard prefix of mt_progname_ for each ID identifying internal table, where

progname is the name of the exporting program. Excluding the standard prefix, use a name

56637862-abap-standards.pdf

Documents

kevin wolfe572002

kevin wolfe7131999

kevin wolfe9131999

kevin wolfe7201999

kevin wolfe12141999

author kevin wolfehow

program descriptions

program use category