abap standards

SAP ABAP

Development

Standards

Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 PM Aaron Pust /tt/file_convert/54770a3d5806b55a068b45a7/document.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. Chg’ed 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 it’s 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......................................................................................................................21AT USER-COMMAND........................................................................................................................22AT PFn..............................................................................................................................................22TOP-OF-PAGE..................................................................................................................................22

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


65

CALL (FUNCTION MODULES).....................................................................................................26Operational Elements.............................................................................................................................27CHECK................................................................................................................................................27CLEAR................................................................................................................................................28COMMIT WORK..................................................................................................................................28CONCATENATE..................................................................................................................................29DELETE..............................................................................................................................................29EXPORT …TO MEMORY / IMPORT…FROM 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.........................................................................................................................................32Text 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....................................................................................................................................................37“End 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.....................................................................................................................................................42


65

TABLE INDEXES...........................................................................................................................................43Table Index Maintenance Approval Procedure......................................................................................43

LOCK OBJECTS.............................................................................................................................................43Lock Objects :.....................................................................................................................................43

SEARCH HELP..............................................................................................................................................44Search Help Objects :.........................................................................................................................44

TYPE 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 ID’S)...............................................................................................47AREA MENUS...............................................................................................................................................47

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

Job names...............................................................................................................................................48Event ID’s...............................................................................................................................................48

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

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

BDC SESSIONS / CALL TRANSACTIONS.............................................................................................51

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

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

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

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

DIRECTORIES...............................................................................................................................................53FILENAMES..................................................................................................................................................53

IDOCS.....................................................................................................................................................54IDOC Type.........................................................................................................................................54

FTP.............................................................................................................................................................55

APPENDIX....................................................................................................................................................55

USEFUL FUNCTION MODULES.....................................................................................................................55USEFUL ABAP PROGRAMS.........................................................................................................................56

END OF DOCUMENT.................................................................................................................................58


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 SAP’s 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 Group’s 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 User’s Guide (from initial SAP screen: Help > Application help > BC – Basis Components > BC ABAP User’s 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 (Carolyn’s master directory document…?? )

Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 PM Aaron Pust /tt/file_convert/54770a3d5806b55a068b45a7/

document.doc 1 of

65

Terminology

Adherence

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

Shall/Will/Must 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 ELEMENTS

This section defines the development standards for the following ABAP Program Elements:

Program Name

Attributes

Source Code

Text Elements

Messages

Variants

Program Documentation

Program Name

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

Naming convention:

tmmssuf999n

where:

t.................Type.


document.doc 2 of

65

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.

Personnel Management Submodules.HR = Human Resources.


document.doc 3 of

65

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.

Attributes

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

Title

The title you assign to a program shall reflect the functionality of the program. For reporting programs, this title will also be displayed as the title of the report when used in conjunction with the West Group


document.doc 4 of

65

standard header function Z_HEADER_ROUTINE. The title shall not contain all CAPS and shall not contain a period.

Type

As required by SAP.

Status

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

Application

As required by SAP.

Authorization group

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

Development class

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

Naming convention:

Standard and 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

ZBAS Basis No breakdown currently needed


document.doc 5 of

65

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 arithmetic

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

Source Code

Coding Guidelines

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

Readability

Within all programs, you should use structured coding techniques.

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

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

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

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

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

Example:

Standard:

move g_vkorg to gt_sites-vkorg.append gt_sites.

Non-standard (DO NOT USE!):


document.doc 6 of

65

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 hierarchies

data: 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'.


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.move gt_sites-vtweg to g_vtweg.move s_werks-low to g_werks.


document.doc 7 of

65


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 (LOOP…ENDLOOP, DO…ENDDO, 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 SAP’s “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).

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.


document.doc 8 of

65

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 program’s 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 SELECT…ENDSELECT 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.

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.


document.doc 9 of

65

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

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

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

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

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

Declarative Elements

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

REPORT/PROGRAM

TABLES

TYPES

SELECT-OPTIONS

PARAMETERS

DATA

CONSTANTS

RANGES

FIELD-SYMBOLS

REPORT/PROGRAM

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

Note: It is recommended that you create all new programs via the Repository Browser instead of using the ABAP Editor directly. When a program is created via the Repository Browser, a source code template is created for the entire program. This template consists of comment lines for entering a program description, the standard format for the REPORT statement, and standard formats for other program elements and 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:


document.doc 10 of

65

Declare it as the first executable statement in your program, starting the REPORT keyword in column 1.

Always include the MESSAGE-ID, LINE-COUNT, LINE-SIZE, and NO STANDARD PAGE HEADING additions to this statement (they are already included in the REPORT statement template(Need to create it)).

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

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

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

Naming convention:

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

Example:

*----------------------------------------------------------------------** ZFIGLRA001_SITE_MID_YEAR_BUDGET - Site mid-year budget report by ** quarter, wholesale ** ** This program creates the Site Mid-Year Budget Report by Quarter ** for a wholesale site. **----------------------------------------------------------------------*

report zfiglra001_site_mid_year_budget no standard page heading line-size 132 line-count 65 message-id zfiap.

TABLES

When coding the TABLES statement, you must:

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

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

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:


document.doc 11 of

65

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

TYPES

When coding the TYPES statement, you must:

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

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

Naming convention:

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

Example:

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

SELECT-OPTIONS

When coding SELECT-OPTIONS statements, you must:

Start the SELECT-OPTIONS keyword in column 1 unless it is subordinate to a 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 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.


document.doc 12 of

65

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.

PARAMETERS

When coding PARAMETERS statements, you must:

Start the PARAMETERS keyword in column 1 unless it is subordinate to a SELECTION-SCREEN statement, in which case you must code it on the following line and indent it to the right of the SELECTION-SCREEN keyword.

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

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

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

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

Naming convention:

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

Examples:

parameters: p_vkorg like wkbp-vkorg.parameters: p_vtweg like wkbp-vtweg.parameters: p_count type I


document.doc 13 of

65

default 50 obligatory.

-- or --

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

DATA

When coding DATA statements, you must:

Start the DATA keyword in column 1 if it is a “global” variable, or column 3 if it is a “local” variable. Global variable . This is defined as a data work field or structure declared outside of a FORM

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

subroutine or function module. You are only able to reference it from within that form or function.

When declaring individual work fields, you must:

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

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

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

Use the LIKE addition whenever possible to reference a Data Dictionary field.

When declaring an internal table or data structure, you must:

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

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

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

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

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

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

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 table’s 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.


document.doc 14 of

65

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, vtweg like wkbp-vtweg, werks like wkbp-werks, end of gs_orglevel.

data: g_cust like kna1.

Data structures (local):

form newform.


document.doc 15 of

65

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, vkorg like wkbp-vkorg, vtweg like wkbp-vtweg, werks like wkbp-werks, end of lt_cust. . . .endform.Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 PM Aaron Pust /tt/file_convert/54770a3d5806b55a068b45a7/

document.doc 16 of

65

-- or --

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

CONSTANTS

When coding CONSTANTS statements, you must:

Start the CONSTANTS keyword in column 1 if it is a “global” constant, or column 3 if it is a “local” constant. Global constant . This is defined as an individual field or structure declared outside of a FORM

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

subroutine or function module. You are only able to reference it from within that form or function.

When declaring individual constant fields, you must:

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

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

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

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. 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


document.doc 17 of

65

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.

RANGES

When coding RANGES statements, you must:

Start the RANGES keyword in column 1 if it is a “global” range, or column 3 if it is a “local” range. 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.Last changed on: Last changed by: File name: Page:2/3/2006 11:58:00 PM Aaron Pust /tt/file_convert/54770a3d5806b55a068b45a7/

document.doc 18 of

65

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-GROUPS

When coding FIELD-GROUPS statements, you must:

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

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

field names into each field group. Start each new INSERT statement in column 1. Declare each individual insert field on a separate line immediately after the INSERT keyword. 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 ( _ ).


document.doc 19 of

65

Examples:

field-groups: fg_header. fg_detail.

insert wkbp-vkorg wkbp-vtweg into fg_header.

insert wkbp-werks wkbp-matnr into fg_detail.

FIELD-SYMBOLS

When coding FIELD-SYMBOLS statements, you must:

Start the FIELD-SYMBOLS keyword in column 1 if it is a “global” field symbol, or column 3 if it is a “local” field symbol. Global field symbol . This is defined as a field symbol declared outside of a FORM subroutine or

function module. You are able to reference it from anywhere within the program. Local field symbol . This is defined as a field symbol declared within a FORM subroutine or

function module. You are only able to reference it from within that form or function. Declare each field symbol on a separate line immediately after the FIELD-SYMBOLS keyword. You

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

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

Naming convention:

When declaring FIELD-SYMBOLS names, you must:

Include a standard prefix of gfs_ for each global field symbol. Include a standard prefix of lfs_ for each local field symbol. Use the standard prefix plus a descriptive, concise name. Never include a hyphen ( - ). You may include underscores ( _ ).

Examples:

Global:

field_symbols: <gfs_fieldname>, <gfs_save_fieldname>.

Local:

form newform. field_symbols: <lfs_fieldname>, <lfs_save_fieldname>. .


document.doc 20 of

65

. .endform.

Event Elements

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

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

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

AT SELECTION SCREEN

START-OF-SELECTION

END-OF-SELECTION

AT USER-COMMAND

AT PFn

TOP-OF-PAGE

AT SELECTION-SCREEN

ON psel

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

ON HELP-REQUEST

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

START-OF-SELECTION

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

END-OF-SELECTION

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

AT USER-COMMAND

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


document.doc 21 of

65

AT PFn

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

TOP-OF-PAGE

You must include the TOP-OF-PAGE event in all your ABAP programs that produce list report(s). Within this event, you shall print the standard report header lines (imported via function module Z_HEADER_ROUTINE). See the “REPORT/PROGRAM OUTPUT” section of this document for more information on function module Z_HEADER_ROUTINE.

DURING LINE-SELECTION

You must include the TOP-OF-PAGE event with the DURING LINE-SELECTION addition in all your ABAP programs that will contain “drill-down” online reporting capability.

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

Control Elements

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

IF

CASE

ON CHANGE OF

DO

WHILE

LOOP

FORM (SUBROUTINES)

CALL (FUNCTION MODULES)

IF

When coding an IF statement, you must:

Align the ELSE (when used), ELSEIF (when used), and ENDIF keywords with the IF keyword. 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.


document.doc 22 of

65

else perform check_document_nbr.endif.

if g_rec_type = gc_header_rec. perform process_header_rec.elseif g_vtweg = gc_vtweg_military. perform process_military.elseif g_vkorg = gc_vkorg_rc. perform process_vkorg_rc.endif.

CASE

When coding an CASE statement, you must:

Code each WHEN clause on a separate line and indent each WHEN keyword consistently to the right of the CASE keyword.

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

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

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

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

Example:

case g_rec_type. when gc_rec_type_a. perform process_report_1. when gc_rec_type_b or gc_rec_type_c. perform process_report_2. when gc_rec_type_d. perform process_report_3. when others. perform invalid_rec_type.endcase.

DO

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

You must always code the DO control element with a controlled exit point (such as a TIMES variant or an EXIT statement) to avoid a continuous loop.

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

Examples:


document.doc 23 of

65

do. read dataset pinfile into g_rzone_h. if sy-subrc <> 0. exit. endif.enddo.

do 5 times varying g_letter1 from g_word1 then g_word3 varying g_letter2 from g_word2 then g_word4. write: g_letter1, g_letter2.enddo.

WHILE

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

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

Examples:

while g_cnt < 10. perform main_process. add 1 to g_cnt.endwhile.

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

LOOP

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

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.


document.doc 24 of

65

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. 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:


document.doc 25 of

65

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_MC

Example of USING addition (without the VALUE clause):

perform lock_table_w using svkorg-low pvtweg.

form lock_table_w using f_vkorg f_vtweg. zrbpl-vkorg = f_vkorg. zrbpl-vtweg = f_vtweg. modify zrbpl. commit work.endform. “ LOCK_TABLE_W

CALL (FUNCTION MODULES)

It is strongly recommended that you use the appropriate ABAP Editor “Pattern” when coding the CALL statement to ensure that you include all associated parameters for the given function module. You may delete any unused parameters from the CALL statement to enhance readability.

You must always check the return code (SY-SUBRC) after executing a CALL to a function module.

Example:

call function 'job_close' exporting event_id = 'R_BGP_VKPB_JOBSTART' event_param = g_event_param jobcount = g_jobnr jobname = f_jobname importing 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.


document.doc 26 of

65

when others. message e999 with sy-subrc.endcase.

Operational Elements

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

CHECK

CLEAR

COMMIT WORK

CONCATENATE

DELETE

EXPORT…TO MEMORY / IMPORT…FROM MEMORY

FORMAT

MODIFY

MOVE/MOVE-CORRESPONDING

READ TABLE (itab)

SELECT

WRITE

CHECK

It is recommended that you use the CHECK statement instead of the IF…EXIT…ENDIF structure when determining if a looping structure or routine shall be terminated.

You should not use the CHECK statement within a SELECT…ENDSELECT 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

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


document.doc 27 of

65

binary search. if sy-subrc <> 0. exit. endif. . . .endform.

CLEAR

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

Examples:

data: g_integer 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 WORK

You should always issue a COMMIT WORK after performing a large number of updates (changes/inserts/deletes) to the database. You should issue it in the context of a logical unit of work (LUW), such that if the next COMMIT WORK fails, the database is not out of sync. For example, if update A and update B both need to be in the database for it to be logically correct, then you need to issue the COMMIT WORK after update B. This is necessary so that if update B fails you can ROLLBACK update A so that the database stays consistent. If update A and update B are not related and update A could affect a large number of records (say 1000 records) then you should issue a COMMIT WORK following both update A and update B.

CONCATENATE

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


document.doc 28 of

65

DELETE

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

Examples:

Standard method of deleting database table entries with similar characteristics

delete table zrbpc where posted = gc_yes or sleeping = gc_yes.

Non-standard method of deleting database table entries with similar characteristics (DO NOT USE!)

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

EXPORT …TO MEMORY / IMPORT…FROM MEMORY

You should always use the ID addition with the EXPORT or IMPORT statement.

You may code the entire EXPORT…TO MEMORY / IMPORT…FROM MEMORY statement, including the ID addition, on the same line. It is recommended that you align all TO MEMORY keywords together, all FROM MEMORY keywords together, and the ID keywords together for each consecutive statement.

Naming convention:

When declaring ID names, you must:

Include a standard prefix of m_progname_ for each ID identifying an individual work field, where progname is the name of the exporting program.

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

Excluding the standard prefix, use a name that is identical to the respective individual work field or internal table containing the data to be exported. Likewise, you should give the individual work field or internal table to receive imported data a name that is identical to the respective memory ID being imported.

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

Examples:

export g_year to memory id ‘m_zfiglra001_year’.export l_versn to memory id ‘m_zfiglra001_versn’.export gt_csku to memory id ‘mt_zfiglra001_csku’.export lt_werks to memory id ‘mt_zfiglra001_werks’.

import g_year from memory id ‘m_zfiglra001_year’.import l_versn from memory id ‘m_zfiglra001_versn’.import gt_csku from memory id ‘mt_zfiglra001_csku’.import lt_werks from memory id ‘mt_zfiglra001_werks’.


document.doc 29 of

65

FORMAT

You should apply the same standards to the FORMAT statement that you apply to the WRITE statement.

You may code the first addition to this statement on the same line as the keyword FORMAT. You should code any further additions on subsequent lines, one addition per line, aligning all additions.

When using the COLOR addition, you should use the COL_xxx option instead of the number of the color (e.g. COLOR COL_TOTAL instead of COLOR 3).

Example:

format color col_total intensified off hotspot.

MODIFY

When using the MODIFY dbtab statement to insert or update a database table entry, by definition, a new entry will be inserted (just like the INSERT statement) if the key does not already exist, or the new entry will update the existing entry of the same key (just like the UPDATE statement) if the key already exists. For performance reasons, you should use the MODIFY statement only if it is not possible for you to distinguish between using the INSERT or UPDATE option.

MOVE/MOVE-CORRESPONDING

When moving data from individual fields of a database or internal table to their corresponding fields in another database or internal table, it is generally recommended that you use individual MOVE statements instead of the MOVE-CORRESPONDING statement because they are more efficient. The MOVE-CORRESPONDING statement is acceptable only if you do not execute it a significant number of times throughout the course of one execution of the program, thereby not noticeably increasing processing time.

READ TABLE (itab)

It is highly recommended that the READ TABLE (itab) statement is used with the BINARY SEARCH addition whenever possible to enhance performance. When executing the READ TABLE (itab) statement using the WITH KEY K1 = F1 and BINARY SEARCH additions, you must:

Sort the internal table by the desired sequence before executing this statement. List all key fields in the WITH KEY addition in the order that the table is sorted.

If you do not, you may get a return code of 4 or 8 (entry not found) after executing this statement, even if the entry does indeed exist on the internal table.

SELECT

Note: The “Performance” area of the “Coding Guidelines” chapter of this section contains many guidelines for efficient use of the SELECT statement.

You should use the UP TO n ROWS addition when checking to see whether a particular value for a key field exists on the table and it is possible that this value could exist on more than one table entry (partial key).


document.doc 30 of

65

When using a non-key field in the WHERE clause, you may need to incorporate the field into a new index for the table to speed up the table search process. See the “Table Indexes” chapter of the “DATA DICTIONARY ELEMENTS” section of this document for more information about creating table indexes.

You should always check the system return code (SY-SUBRC) after execution of a SELECT statement.

WRITE

The WRITE statement is the only procedural statement in which it is acceptable, by our standards, for you to “chain” statements together on one line using the statement keyword with a colon. When you are writing to a report, it is recommended that you code one WRITE statement per output line.

You should apply the same standards to the WRITE statement that you apply to the FORMAT statement.

You can find standards for the formatting of report output in the “REPORT/PROGRAM OUTPUT” section of this document.

Example:

write: /01 sy-vline, 02 l_prtdd_cc using edit mask '_______' color col_normal intensified off, 09 sy-vline, 10 l_prtdd_year color col_normal intensified off, 14 sy-vline, 15 l_prtdd_period color col_normal intensified off, 18 sy-vline, 19 l_prtdd_acct using edit mask '_______' color col_normal intensified off, 25 sy-vline, 26 l_prtdd_amt color col_normal intensified off, 47 sy-vline, 48 l_prtdd_docno using edit mask '__________' color col_normal intensified off, 58 sy-vline.

Other Source Code Elements

This section defines the development standards for the following miscellaneous source code elements:

COMMENTS

COMMENTS

The amount of internal program documentation to include in your program via comments is mainly up to you. At a minimum, you should provide the necessary level of documentation required to fully clarify the purpose and functionality of the specific logic, and you should properly document all complex logic.

You may use both full line (“*” in column 1) and in-line (followed by double quote “) comments as long as you do not detract from the readability of the program.


document.doc 31 of

65

For IF…ELSE…ENDIF structures that contain many lines, you may add an in-line comment to the end of the ENDIF statement to indicate its associated IF statement. This will help identify where the IF construct begins if it is not obvious.

Example:

if not gt_aclvl-matnr is initial. perform e510_add_wl_mat_matnr.elseif not gt_aclvl-matkl is initial. perform e520_add_wl_mat_matkl.elseif not gt_aclvl-mchl3 is initial. perform e530_add_wl_mat_mchl3. . . .endif. “ not gt_aclvl-matnr is initial

Text Elements

Titles and headers

Title. The “Title” text element should be the same as the title defined in the Attributes of the program. For this reason it is unnecessary to enter a “Title” text element, as SAP will default to the title defined in the attributes.

List header. Not used. Because we do not use the standard ABAP header for our reports, the LIST HEADER text element will not appear on our reports. You must code all list headers manually as text symbols.

Column header. Not used. Because we do not use the standard ABAP header for our reports, the COLUMN HEADER text element will not appear on our reports. You must code all column headers manually as text symbols.

Selection texts

You must include an appropriate text description for each selection text field (selection options and parameters). When formatting the text description you must:

Capitalize only the first letter of the first word. Never end it with a period ( . ) or colon ( : ).

For more guidelines on selection text formatting, you should refer to Chapter 11 of the “SAP Style Guide”, and the “Selection Screens“ chapter of the “REPORT/PROGRAM OUTPUT” section of this document.


document.doc 32 of

65

Text symbols

You must code any language text to be used as output from a program (excluding Titles and headers and Selection texts) as a “text symbol”. This includes such things as report headers, miscellaneous report texts, audit report line item descriptions, etc.

Naming convention:

When declaring a Text Symbol ID, you may use any combination of alphanumeric and/or special characters.


document.doc 33 of

65

Messages

When your program must display a message, it is recommended that you use an existing message, if appropriate. You should make sure the existing message AND its associated “long text” are both appropriate for the given situation. You should check the following areas in the order listed to determine if a suitable message exists:

1. Similar SAP programs for an SAP-supplied message. This will provide consistency between SAP and custom applications.

2. Custom message class ZXXXX (Need to create it). This message class is used for custom messages that are function module-independent.

3. Program’s default message class (assigned in REPORT statement).4. Other custom message classes.

If a suitable message (with “long text”) could not be found in any of the above areas, you should create a new message. When creating a new message, you must:

Define the message within either the program’s default message class (if applicable only to that application module), or message class ZX if the message is generic-enough to be used by multiple application modules.

Create associated “long text”. Capitalize only the first letter of the first word. Never end it with a period ( . ) or colon ( : ). There are six types of messages:

‘I’ - Information, enter to continue

‘W’ - Warning, correction possible

‘E’ - Error, correction required

‘A’ - Abend, transaction terminated

‘X’ - Exit, transaction terminated with short dump message

‘S’ - Success, message on next screen

For more guidelines on the format and structure of message texts, you should refer to “Texts” of the “SAP Style Guide” (Help > Application help > BC – Basis Components > BC – SAP Style Guide > Texts).

For message class standards, you should refer to the “Message classes” area of the “OTHER DEVELOPMENT ELEMENTS” section of this document.

All MESSAGE statements should use the following format:

MESSAGE xnnn(mc)

where: x = message typennn = message numbermc = message class.

If the message’s message class (mc) is identical to the message class designated in the MESSAGE-ID addition of the REPORT statement, you can omit the message class (mc) in the MESSAGE statement.

You shall not use the MESSAGE statement in the format “MESSAGE ID mid TYPE mtyp NUMBER mnr”.

Examples:

message e014 with g_vkorg g_vtweg.


document.doc 34 of

65

Message i025(zfiap).

Long text

You are required to include “long text” with each message.

During editing, you can organize the long text documentation within certain standard sections. A complete list of these section names can be found in table TTDTG. Each section consists of a VARNAME (symbol name) field which is the name of the symbol that you would code in the documentation input screen (delimited by &), and a VARVALUE (symbol value) field which is the text for the section that appears when you display the program documentation on-line. When you enter the long text maintenance screen for an individual message the very first time, the following sections will appear:

VARNAME VARVALUE NotesCAUSE Diagnosis What has occurred within the program to cause this

message to appear. This is basically a more detailed description of the original message.

SYSTEM_RESPONSE System response How the system or program has reacted to the event that has caused this message to appear.

WHAT_TO_DO What to do The next steps the user should follow in response to this message.

If any of the above sections will not be used to document the message, you may delete them from the documentation. In addition to the above sections, you may add any other sections from the TTDTG table as needed to further document the message.

Variants

The functional and business users are responsible for the support of program variants in the production environment. It will be up to them to develop their own standards for the use of variants, although the use of ‘Z’ as a first character is will be mandatory.

Variants are client dependent. Work with the Basis group prior to transporting variants, as the target client on WRQ is client 399, and Basis will need to know what other clients you would like it to be copied to.

Program Documentation

You are required to create on-line program documentation for each of your ABAP programs (main programs and “includes”) using the ABAP Editor’s program documentation facility. You should create your documentation to be developer-oriented (as opposed to user-oriented), meaning that it should consist of any technical information to support the understanding of the program.

During editing, you can organize your program documentation within certain standard sections. A complete list of these section names can be found in table TTDTG. Each section consists of a VARNAME (symbol name) field which is the name of the symbol that you would code in the documentation input screen (delimited by &), and a VARVALUE (symbol value) field which is the text for the section that appears when you display the program documentation on-line. When you enter the program maintenance screen for your program the very first time, the following sections will appear:

VARNAME VARVALUE NotesDESCRIPTION Description Description of the program’s function. This should

consist of the program description entered as comments in the source code immediately before the REPORT statement.


document.doc 35 of

65

PRECONDITION Requirements Any prerequisites that must be met before this program can be executed.

OUTPUT Output Any output produced from this program - table updates, reports, screens, etc.

EXAMPLE Example Any examples of how this program might be used.

If any of the above sections will not be used to document the message, you may delete them from the documentation. In addition to the above sections, you may add any other sections from the TTDTG table as needed to further document the program.

REPORT/PROGRAM OUTPUT

This section defines the development standards for the following REPORT/PROGRAM output elements:

Selection Screens

Lists

Fonts

Selection Screens

This section describes all the development standards you are to follow when creating selection screens. Within this documentation, the term “screen field” refers to each parameter or selection options field.

Within each of your custom-developed programs, you must format each selection screen to be ergonomically consistent with other similar SAP screens. Ergonomic examples of SAP screens can be displayed within the ABAP Workbench by going to the Repository Browser, menu selection “Environment/Ergonomic examples/Screens”.

This section will cover the following selection screen elements:

Field Descriptions

Possible Values

Field Help

Field Descriptions

You must include an appropriate text description for each screen field. This description will be displayed next to the input field. (See the “Selection texts” area of the “Program Elements” chapter of this section for more information on screen field descriptions.)

Possible Values

If you are declaring a screen field that has a set number of possible values, you must display a “possible values” box when the user places the cursor on the field. To accomplish this, you must code the screen field association - LIKE for parameters, FOR for selection options - as one of the following:

A Data Dictionary field that points to Check Table. A Data Dictionary field that points to a domain that has an associated “values” list. If an existing

domain does not provide these values, you may define a new Data Dictionary field and domain for this screen field within the West Group Utility Structure in the Data Dictionary (need to create this).

An internal table field in which the table contains all possible values for the field (used in conjunction with the ON VALUE REQUEST addition of the AT SELECTION SCREEN event). You would most likely use this method if you only need a subset of table values for the “possible values” box.

See the “Selection Screens” chapter of the “REPORT/PROGRAM OUTPUT” section of this document for more information on “possible values” boxes.


document.doc 36 of

65

Field Help

You are required to make field help available for each screen field. To create help for a given field, you must add appropriate text to the screen field’s associated data element documentation in the Data Dictionary. If the screen field does not have an associated data element in the Data Dictionary, you must define a new Data Dictionary field and data element for this screen field within the West Group Utility Structure in the Data Dictionary. See the “Structures” chapter of the “DATA DICTIONARY ELEMENTS” section of this document for more information on the West Group Utility Structure.

Lists

You must format each custom list to be ergonomically consistent with other similar SAP lists. Ergonomic examples of SAP lists can be displayed within the ABAP Workbench (Repository Browser > Environment > Ergonomic examples > Lists).

This section will cover the following list elements:

Header

“End of Report” Line

Logos

Field Formats

Audit Reports

*** Place screen print of basic list here when time permits ***

Header

You must use the custom standard report header as opposed to the standard SAP report header within all custom lists. Function Z_HEADER_ROUTINE prepares the necessary header fields for use within the list. Refer to documentation for the function Z_HEADER_ROUTINE provided within the ABAP Workbench for instructions on how to incorporate the custom standard report header into an ABAP program.

“End of Report” Line

You must print the standard “End of Report” line print as the last line of the report within all custom lists. Function Z_HEADER_ROUTINE prepares this line for use within the list. Refer to documentation for the function Z_HEADER_ROUTINE provided within the ABAP Workbench for instructions on how to incorporate the “End of Report” line into an ABAP program.

Logos

You should not print any logos on any ABAP lists or SAPScript reports without first researching its affect on performance.

Field Formats

The following sections describe the standard format to be used for certain standard data fields whenever you display them on your custom lists.

Do we need field formats like the following examples??


document.doc 37 of

65

Retail price

Two decimal places. Leading zeroes truncated up to the single dollar digit. Less than $1.00 shall contain a zero as the single dollar digit.

Examples:

14.95 2.50 0.75

Retail price w/multiple units (e.g. 3 units for $1.00): Format 99/99.99. Leading zeroes in the units position suppressed. Dollar amount shall follow the same standards as stated above.

Examples:

12/11.95 3/ 1.00 5/ 0.80

UPC

Always 11 digits. No dashes. Suppressed UPC's (7 digits) shall always be displayed in their full 11-digit format.

Examples:

012345678903123456789004100000105

Audit Reports

You are required to produce an audit report for each ABAP non-interactive program that does not generate a user report. The audit report shall contain any vital information to indicate what transpired during a given execution of the program. This information should include:

Record or table entry counts for all of the primary input and output files and tables.

Texts indicating exception records or table entries and why they were handled differently or bypassed altogether.

Return code for the program (if applicable).

Any other vital statistics relevant to the program’s execution.

The format of the audit report shall be ergonomically consistent with other similar SAP lists.

*** Place screen print of sample audit report here ***


document.doc 38 of

65

Fonts

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

DATA DICTIONARY ELEMENTSNOTE: AS OF 12/14/1999, the Basis group has assumed the development responsibility of all Data Dictionary Objects. Basis needs to be involved in the functional design meetings, if possible, but must be involved prior to functional signoff of any development request that requires DDIC work.

This section defines the development standards for the following ABAP Data Dictionary Elements:

Tables

Structures

Views

Field Names

Data Elements

Domains

Table Indexes

Lock Objects

Search Help

Type Groups

IDOC Segments

Tables

Table Elements Maintenance Approval Procedure

The following procedure must be followed before a table or elements of a table field (field, data element, domain) may be added or updated:

If a developer feels there is a need to create a new table, or create or update a table field (fields, data elements, domains, etc.) on an existing table, they must document their request and forward this documentation to the DBA Representative for approval.

Once development is completed, the developer will walk through the applicable test cases with the DBA Representative.

If approved by the DBA Representative, the table maintenance may now be transported to QA.

Naming convention:

Ztmmxxxxxx

where:

Z Constant required for user developed objects.


document.doc 39 of

65

t Type.

T = Table.

mm Application Module.

(See Program Name naming convention for possible values.)

xx’s Any alphanumeric characters (max. 6).

Table Technical Settings Maintenance Approval Procedure

The following procedure must be followed before the technical settings of a table (logical storage parameters, buffering, etc.) may be added or updated:

If a developer feels there is a need to create or update the technical settings of a table (logical storage parameters, buffering, etc.), they must discuss their request with the Basis Representative, explaining what they would like to change and why they feel it should be changed.

If approved by the Basis Representative, the Basis Representative will perform the requested maintenance on the table. If denied, the Basis Representative will explain to the developers satisfaction why the request was denied.

Note: Basis Representative’s email group is S&AS – BASIS.

Structures

Naming convention:

Ztmmxxxxxxxx

where:


t Type.

S = Structure.



xx’s Any alphanumeric characters.

IDOC segments

***Need input from EDI team

Naming convention:

Z1Edsnn

where:


document.doc 40 of

65

s.....................Segment Type.K = Header.D or P = Item.S or T = Summary.

nn..................Sequential number.

West Group Utility Structure - ZUTILITY

The West Group Utility Structure ZUTILITY is a custom structure which stores custom table fields and data elements created for the purpose of providing field help (F1) and field values for a “possible values” boxes for Selection Screen fields that do not associate with any existing Data Dictionary data elements.

Each Selection Screen field is required to have field help and, if applicable, a “possible values” box available which are defined at the data element level. If no current data element exists which can be associated with the screen field, a new table field with this new data element must be created within the West Group Utility Structure for use by this screen field.

ViewsDo not put selection conditions directly in the database view. Selection conditions should be in the where clause in the source code that selects from the view. (In this way it is much clearer to a person looking at the program because there are no 'hidden' selection conditions. Verify that the view is bringing back exactly what you expect it to.A view allows an alternative way to retrieve data from a table or groups of tables. You can reduce the number of reads in a program by defining a view that contains related data from several tables. A view is a logical table and is not physically stored.

Naming convention:

Ztmmxxxxxxxx

where:


t Type.

V = View.



xx’s Any alphanumeric characters.

Exception 1: Help Views are needed when F4 Possible Entries requires more than just the key values stored in a table. Usually both the key values (e.g. codes) and the associated text is required. The view will contain both the key and text fields. The naming standard for Help views is :

Format : ZVTTTTTHFNNWhere : ZV Constant required for user developed objects

TTTT Table name the view is help forHF Fixed ValueNN Sequential number


document.doc 41 of

65

Database

Projection

Help

Field names

XXX

Naming convention:

Each field name appended to a standard SAP table shall contain a standard prefix of zz. Each field included in a custom table should contain no prefix. Where possible, name fields so the names are understandable, except where using SAP pre-defined fields, use the SAP field names (ex. Do not change sales document number to DOCNUM, use VBELN)

Data elements

XXX

Documentation

Documentation is required for every custom data element. This documentation is what will be displayed when a user requests help (F1) for any Selection Screen field that is associated with this data element.

Note: Table THLPF is where the association is made between the documentation and the field/screen.

Naming convention:

Standard

Each data element name shall contain a standard prefix of z.

IDOC Need input from EDI team

ZEnnnnA

where:

nnnn..........4-digit field number per standard ANSI X12 (include leading zeroes).

Domains

Naming convention:

Zxxxlll_nnn

where:

Z..................Constant required for user developed objects.

xxx............Data element type.CHR = Character.DAT = Date.


document.doc 42 of

65

DEC = Decimal.INT = Integer.

lll............Length.

nnn............Sequential number.

Table Indexes

Table Index Maintenance Approval Procedure

The following procedure must be followed before a table index may be added or updated:

If a developer feels there is a need to create or update a table index, they must document this request, including how they are planning to access the table, why they feel none of the existing table indexes will work for this access, and the components of the new or updated index, and forward this request to their Basis Representative for approval.

The Basis Representative will check the request and determine if testing of this index maintenance should proceed in the Development environment. If approved, the Basis Representative will notify the developer that testing on this index may proceed.

The developer will perform thorough tests for this particular access both before and after the index is created or updated, document each of the test cases, and walk through this documentation with the Basis Representative.

Once the Basis Representative OK's the test case documentation the index maintenance can then be transported to QA.

Note: Basis Representative’s email group is S&AS – BASIS.

Lock objects

Lock objects control simultaneous access to a particular table by two update users by means of “locks” which are set and released by calling a function module. The function module is automatically generated when the lock object is activated. These function modules are known as ENQUEUE and DEQUEUE.

Lock Objects :

Naming convention:EZ aa ttttt LKnn

Where:

EZ...............Constant required for user developed objects.

aa.................Application type

ttttt..............Table name

LK...............Fixed value

nn................Sequential number


document.doc 43 of

65

Search Help

Search help provides additional functionality to input help. The search help objects are part of the ABAP Dictionary.

Search Help Objects :

Naming convention:Z_SH_nnnnnn

Where:

Z_SH_.........Constant required for user developed objects.

nnnnnn.......Search help name (max. 25).

Type groups

XXX

FUNCTION GROUP ELEMENTS

Frequently used routines can be created as function modules. These are accessed by ABAP programs through the “CALL FUNCTION” statement and may be shared across programs. Function modules are contained within function groups. Technically speaking, a function group is a program with one Include file for each function. When a function is called at runtime, its' function group is loaded into main memory and the called function is executed. Following execution, the function group remains in memory and is available to the main program of the current process. All functions in a function group share the same forms. All functions in a function group share the same global data.

This section defines the development standards for the following ABAP Function Group Elements:

Function Groups

Function Modules

Documentation

Function groups

Naming convention:

zmmxxxxxx

where:

Z..................Constant required for user developed objects.

mm...............Application Module.(See Program Name naming convention for possible values.)

xxxxxx.....Any alphanumeric characters.


document.doc 44 of

65

Function modules

Unless indicated otherwise, the program elements permissible in the function module environment shall conform to the same standards for program elements defined within this document.

Naming convention:

Standard

Each function module name shall contain a standard prefix of Z_MMSS_XXXX…

Where:

Z Constant required for user developed objects

Mm Application Module (see program name naming convention for possible values)

Ss Application SubModule (see program name naming convention for possible values)

xxx… Descriptive Text

IDOC Need input from EDI

Z_xmmyyy…pppp

where:


x Input/Output indicator.Z = User-defined.I = InputO = Output

mm Application Module(See Program Name naming convention for possible values.)

yyy… Logical Message Typeor

Descriptive text (for example: ORDER, INVOICE, etc.).1-22 characters.

pppp Process indicator.MAKE = CreateEDIT = Change VIEW = DisplayPROC = Process

Documentation

Not yet defined.

MISCELLANEOUS DEVELOPMENT ELEMENTS

This section defines the development standards for the following miscellaneous ABAP development elements:

Transactions


document.doc 45 of

65

Logical Databases

SET/GET Parameters (Parameter ID’s)

Area Menus

Message Classes

Jobs

PBO Modules

PAI Modules

Dialog Modules

Screens

Module Pools

Include Programs

Transactions

SAP Transaction Codes are defined in Table TSTC, user defined Transaction Codes are defined in accordance with the following conventions.

Naming convention:

tmmxxxx

where:

t Type.Y = Transactions with security requirements applied at the transaction and/or field level.Z = Transactions without security requirements.

mm Application Module.(See Program Name naming convention for possible values.)

xxxx Any alphanumeric characters.

Logical databases

Logical Database

Naming convention:

zmmxxxx

where:



xxxx Any alphanumeric characters.


document.doc 46 of

65

SET/GET parameters (parameter ID’s)

Naming convention:

Zxx

where:

xx Unique identifier.

Example: ZCO (parameter ID for company code)

Area menus

XXX

PF keys

The lines 23 and 24 should be reserved for the SAP system when coding interactive reports. Line 24 will be used for PFKEYS display and line 23 for issuing dialog messages.

The standard SAP PFKEYS assignment shall be used when programming interactive reports. The SAP system has default settings for these particular PFKEYS.

The SAP standard PFKEYS are listed below:

PFl Help PF2 Pickup, select PF3 Back

PF4 Return PF21 First Page PF22 Previous Page

PF23 Next Page PF24 Last Page

PFKEYS assigned to an ABAP report shall be done so with a PFKEYS status. The command statement SET PF-STATUS 'wxyz' shall be used in the program to reference the correct PFKEY assignments.

Text used in conjunction with the PFKEY definition, should conform where possible to the SAP standards. (i.e. PF: n=description)

The most commonly used PFKEY selection shall be displayed as part of the screen Text.

To indicate the availability of more PFKEYS, the standard SAP text of '.....' will be used at the end of the PFKEYS text line.

All PFKEYS will be documented in the PFKEY window, when defining the PF-status. This text will be made available when the PFl key is pressed.

Message Classes

Check existing Message Classes before creating new messages to determine if a suitable message already exists. If no suitable message exists, create a new message following these naming conventions:

Naming convention:zmmss_nnnnnnnnnnnnnn

where:



ss Sub Module.


document.doc 47 of

65


nnnnnnnn Other.

Jobs

Job names

Naming convention:

Z_MM_SS_XXXXXXXXXXXXXXXXXXXXXXXX

where:

Z Constant for user defined job names.

MM Application Module.(See Program Name naming convention for possible values.)

SS Sub-Module.


XXXX Job name identifier/description.

Example: Z_SD_PO_PRICING_1

Event ID’s

Naming convention:

t_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

where:

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

xxxx Event ID description.

Example: Z_START_DISPATCHER

PBO modules

Not yet defined.

PAI modules

Not yet defined.

Dialog modules

Not yet defined.


document.doc 48 of

65

Screens

Not yet defined.

Module pools

Naming convention:

ZTTMZNNN

where:

Z Constant for locally developed Module Pool.

TT Application Module.(See Program Name naming convention for possible values.)

M Constant indicating a Module Pool.

Z Constant indicating a custom object.

NNN Sequential Number

Include programs

A Module Pool consists entirely of INCLUDE programs. Please name your INCLUDE programs according to the following examples.

NOTE: The first 4 characters of the INCLUDE program name correspond to the last four characters of the Module Pool name.An ‘I’ in the 5th position indicates that this is an INCLUDE program, the last 2 characters are incrementing sequential numbers.

Data module

INCLUDE Z 0 0 1 A T O P Data Definitions, Table Definitions,

and Global Data

PBO modulesINCLUDE Z 0 0 1 I O 0 1 O = Process Before Output module INCLUDE Z 0 0 1 I O 0 2 etc., etc.

PAI modules

INCLUDE Z 0 0 1 I I 0 1 I = Process After Input modules

INCLUDE Z 0 0 1 I I 0 2 etc., etc.

Perform modules

INCLUDE Z 0 0 1 I F 0 1 F = Forms

INCLUDE Z 0 0 1 I F 0 2 etc., etc.

SCREEN PAINTER

The Screen Painter standards apply to those custom developments involving the creation of tables and transactions.


document.doc 49 of

65

Dynpro names will always be defined to the data dictionary.

Dynpro sequencing shall be controlled dynamically from within the module pool.

The SET SCREEN statement shall be coded for each possible logical path that can be taken in a Dynpros PAI processing logic. This will make the transaction easier to read.

When developing Dynpros the PFKEYS and space bar should be used to make alterations to Dynpro lines. A Dynpro can become corrupted if the normal keyboard delete and insert keys are used.

The commands 'INPUT and 'OUTPUT' will be defined with all respective PAI and PBO modules. This will eliminate modules being incorrectly processed, as the SAP system assumes each module is a PAI unless specified otherwise.

Example:

MODULE SET_SCRN_ATTR OUTPUT.

MODULE PROCESS_PFKEYS_9000 INPUT.

The CHAIN command shall be used to group logical fields together before calling a module. This will aid the end user in error corrections.

The processing logic command ON CHAIN INPUT and ON CHAIN REQUEST shall be used to reduce redundant processing.

Example:

CHAIN.

FIELD LFAI-LIFNR.

MODULE CHECK_VENDOR_9000 ON CHAIN REQUEST. ENDCHAIN.

When dialog messages are issued on a Screen Painter Dynpro that relate to an individual field, the cursor shall by dynamically positioned on the field.

Example:

SET CURSOR FIELD 'LFAl-LIFNR'. (Standard)

SET CURSOR 6 10. (Non Standard)

The EXIT FROM STEP LOOP statement shall be used where premature termination of Dynpro loop processing is required.

The naming standards regarding Dynpros and module pool shall be found in the document titled 'Naming Standards for SAP'.

Transactions that change the SAP databases shall check whether the desired record is free to be changed. This check will ensure data integrity is maintained. The ENQUEUE / DEQUEUE statements shall be used to individually lock data records.

For the purposes of this standard, a database update shall be any modification, deletion or insertion of a database record or external table.

An update program, of type 'V', shall be written for any database or ATAB table updates. Within this update program, there will be a FORM subroutine that, when executed, will perform the desired database update.

It is recommended to not update any SAP database tables with a written program. Use the SAP transactions to process transactions.


document.doc 50 of

65

BUSINESS OJBECTSObjects created in the business object builder

Naming convention:

Object Type

Zmmxxxx – max 10 characters

where:

Z Constant required for user-developed objects.


xx Number or Name of the business object super type (If no supertype exists then use the name of the main table for the object)

Example: ZSD2032 for the sub type of BUS2032

ZSDKNA1 for the sub type of KNA1

Object Name

Zxxxxx

where:

Z Constant required for user-developed objects.

xx Name of super business object(If no supertype exists then use the business name of the object)

Example: ZsalesOrder for the sub type of SalesOrder

ZCustomer for the sub type of Customer

Name and Description

Xxxxx sub type

where:

Xx Name of super type business object(If no supertype exists then use the business name of the object)

sub type Constant required for sub types of standard business objects

Example: “Sales Order sub type” for the sub type of “Sales Order”

Program Name

ZBO_xxxxx

where:

ZBO_ Constant required for custom business object programs.

xx Name of the business object type.


document.doc 51 of

65

Example: ZBO_ZSD2032 for the object type ZSD2032

Methods

Methods created under a customer business object do not need to begin with Z, but instead should begin with the present tense of a verb and then additional information. For example: Create, ListErrors, Edit, DetermineMaterial, etc. Capitalize the beginning of each word and do not use spaces or underbars.

Events

Events created under a customer business object do not need to begin with Z, but instead should begin with the past tense of a verb and then additional information. For example: Created, ChangedCredit, DeletedBlock, DeterminedMaterial, etc. Capitalize the beginning of each word and do not use spaces or underbars.

Attributes

Attributes created under a customer business object do not need to begin with Z. They should be named the same as the field label for the referenced data element. Capitalize the beginning of each word and do not use spaces or underbars.

BDC SESSIONS / CALL TRANSACTIONS

BDC Sessions

Batch Data Communication (BDC) sessions are used to execute batch input of SAP transactions.

Naming convention:

zttdddddddd9

where:

z Constant for locally developed BDC Session.

tt Application Module.(See Program Name naming convention for possible values.)

dddddddd Date created (YYYYMMDD).

9 Numeric for unique identifier (lowest sequential # available).

Call Transaction

Call Transaction provides superior performance over a BDC Session. Error logging is not as robust in Call Transaction, and for this reason you must create a BDC Session if the Call Transaction fails.


document.doc 52 of

65

SECURITY

This section defines the development standards for applying security to various ABAP development elements. It will cover the following types of security:

Securing a program

Securing a transaction

Securing a program

1) This is how to secure a program that maintains a table:

authority-check object 'Z:ZXXMAINT' id 'ACTVT' field '01' id 'TABLE' field 'ZSCXR'. if sy-subrc ne 0. message e208 with 'You are not authorized to maintain this table'. endif.

2) This how to secure all other sensitive programs

authority-check object 'Z:WEST_RPT' id 'ACTVT' field '02' id 'PROGRAM' field 'ZBASPRN1'. if sy-subrc ne 0. message i000(38) with 'No authority to change' ' the printer status'.

West Group Authorization objects:

Work with Basis Representative to create authorization objects.

Activities:

TACTT contains available activities. Most programs use the first three (1 = create, 2 = display, 3 = display)

Securing a transaction

To secure a transaction you must fill in the field “Authorization object” with the value S_TCODE. The transaction code must also be entered as the value for the object S_TCODE..

Enter tcode screen shot

EXTERNAL FILES

This section defines the development standards for the following external file elements used within ABAP:

Directories

Filenames

FTP


document.doc 53 of

65

Directories

All files will reside in one of the following directories. Directory paths should always be lowercase. The following directory structures will be used:

/sap/development/conversion for input files transferred to UNIX for conversion purposes./sap/development/interfacein for input files currently on UNIX & output files that will stay on UNIX./sap/development/interfaceout for output files to be eventually transferred out of UNIX./sap/development/temp for temporary input and output files not previously defined

The same directory paths above will be used, regardless of the SAP platform where the job is running (Development, Quality Assurance, Production). UNIX will internally manage the separation of Development, Quality Assurance, and Production data into unique subdirectories (i.e. If you access a UNIX file within an SAP job that is run on the Development platform, UNIX will read from or write to an internal Development subdirectory).

Filenames

Filenames must always be UPPERCASE. This naming convention applies to all inbound files. It applies to only the outbound files in which there is no restriction for naming the file by the target application that will use the file as input.

Naming convention:

mmbbufxxdd.zzz

where:

mm...............Application Module.(See Program Name naming convention for possible values.)

bb...............Application Submodule.(See Program Name naming convention for possible values.)

u.................Use.(See Program Name naming convention for possible values.)

f.................Intended Frequency.(See Program Name naming convention for possible values.)

xx...............Program name.Name of the program that this file is related to (< 41 characters).

dd...............Duplicate (file dependant).BU = Back up (when appropriate).

.zzz.............File extension.TXT = Flat file.

Application Filenames

Not yet defined.

FTP Filenames

Not yet defined.


document.doc 54 of

65

IDOCS

IDOC Type

Should be as close to the Basic IDOC Type as possible. In most cases it will be identical.

Basic IDOC Type

Not yet defined.

Extension Type

Not yet defined.

Non-EDI

Not yet defined.


document.doc 55 of

65

FTP

XXX

APPENDIX

Useful Function Modules

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


document.doc 56 of

65

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

Useful ABAP ProgramsRSPARAM List default and active parameters in R/3.RSPROFIL List /sapmnt/<SID>/profile directory and allow editing of the profiles.RSGENLDS Regenerate ABAP loads.SAPMSOS0 Execute system level (e.g. UNIX) commands that use STDOUT.RSDBST00 Show logical databases.RSDBCATL List catalog of logical databases.RSREGEN Regenerate all ABAP programs.TOUCHALL Reset all timestamps.SAPRSEUG Regenerate all screen painter entries.RSSCD100 Change document log listing all documentation changes.RSSDOCTB Table documents.RSTBPROT Table Protocol (SCU0).RSUBS042 Menu Fixes.RSBTCDEL Remove batch job logs.RSAVGL00 Table Compares.RSAQLGDB Logical databases by application area.RSDBTREE Show logical databases.RSBPSTDE Reorg job statistics (Monthly)RSSNAPDL Reorg ABAP dumps. (Daily)RSDBCREO Reorg batch input jobs. (Daily)RSPO0041 Reorg the spool. (Daily)

Programs are contained in /sapmnt/<SID>/exeProgram Function Timing sapevt Kick off an event within SAP On demandrscoll00 SAP_COLLECTOR_FOR_PERFMONITOR Hourlyrsbpcoll SAP_COLLECTOR_FOR_JOBSTATISTIC Dailyrsm13002 SAP_REORG_UPDATERECORDS Dailysappfpar Display profile params and check consistency of shared memory pool configurations as<SID>adm, sappfpar check pf=/sapmnt/<SID>/profile/DVEBMGS00 sappfpar all pf=..... to list all parameters

Program Class Short description

_RCCLB101 KLAS Batch Input: Create classes_RCCLB102 KLAS Batch Input: Create classification data_RCCTB101 ATTR Batch Input: Create characteristics_RCOPCA04 CO-PCA: Generating standard reports in batch


document.doc 57 of

65

_RCOPCA05 CO-PCA: Generating standard reports in batch_RCPBI005 TEST Generate file for testing batch input of routings_RCPBI010 Create routing via batch input_RCPTRA00 REOR Test report for creating input file for batch input_RCSBI010 STUE Create BOMs via batch input_RDDUMF01 Control program for BATCH-SE02_RFBIBL00 FBIP Batch input documents_RFBIBL01 FBIP Batch input documents_RFBIBLG0 FBIP Generating report: Batch input for documents_RFBIDE00 FBIP Batch input interface for customers_RFBIDEG0 FBIP Generating report: Batch input for customer master_RFBIKR00 FBIP Batch input interface for vendors_RFBIKRG0 FBIP Generating report: Batch input for vendor master d_RFBIPPG0 FBIP Generating report: Batch input for preliminary pos_RFBISA00 FBIP Batch input interface for G/L account master data_RFBISAI0 FBIP Subroutine pool for initializations of batch input s_RFBITBTC FBTC Batch input routines for RFBITBXX_RFBITF02 Batch input for RFBITB01_RFEBBU01 Test report: Submit batch job to post buffer data_RFSTAX00 KORR Creating tax codes using batch input_RGCBDC10 RFKB Batch input_RGCREC10 RFKD Batch update_RGUDOCTY RGUREC00 - Example for batch update_RGUREC00 GBAS RGUREC00 - Example for batch update_RHINTE30 PP0D Create batch input session for infotype P0001_RIIBIP00 IBIP PM: IBIP - Batch input utility_RISTRA20 IPMO Maintenance plan date monitoring (batch input IPI0)_RKABG000 RKAG CO-CCA: Batch input processing for calc. of imputed cost_RKBIKA00 Create batch input session to create cost elements_RKCBINPT RKCU Batch-input data transfer from file_RKDBCOMM RKCE Common_part RKDBATCH_RKXBATCH_RKEIBDC1 Create line items: Create batch-input session from_RKGAL000 KGAL Allocations: Report for batch start (General)_RKGALCO1 KGAL Allocations: Report for batch start (CO-CCA)_RKIBI001 RKEV Batch input for cost/revenue transfers_RKIBI002 RKEV Batch input for cost allocation_RKIBI003 RKEV Batch input for statistical ratio input_RKKBBG00 KKB1 Standard reports: Generate in batch_RKKBBR00 KKB1 Costing: Batch request report for reporting_RKKBBR01 KKB1 Generator for batch report_RKKKS000 RKKS Batch processing: Variances/WIP orders_RKKP2B02 KKP Batch processing: Calculating variances on cost ob_RKKPZB02 KKP Batch processing: Overheads on cost objects_RKPBBG00 PRCO Standard reports: Generate in batch_RKSBBG00 RKRK Standard reports: Generate in batch_RKSBBGO0 RKRK Standard reports: Generate in batch_RKSJEX00 RKRK CO reports: Export reports (In batch)_RKSJIM00 RKRK CO reports: Export reports (In batch)_RKZUTG00 RKZT Batch generation archiving reports_RLBEST00 LTEC Batch input for transferring stock data_RLBEST10 LTEC Test data for batch input for data transfer with m_RLBEST20 LTEC Test data for batch input for data transfer using_RLMG0000 LTEC Batch input for taking over storage bin data_RLMG0010 LTEC Batch input for transferring stock data_RLMG0050 LTEC Batch input for transferring stock data_RLMG0051 LTEC Test data for batch input for init. entry of stck. b_RLMG0060 LTEC Batch input for transferring stock data_RLPLAT00 LTEC Batch input for transferring storage bins_RLPLAT10 LTEC Batch input test data for transferring storage bin_RM06BBI0 MEIN Batch input for purchase requistions from another_RM06BBIE Create sequential dataset for batch input: Purchasing_RM06IBI0 Batch input for purchasing info record_RM06IBI1 Framework for batch input generation: Purchasing I_RM06IBIA Listing of sequential dataset for batch input: Inf_RM06IBIE Create sequential dataset for batch input: Info re_RM06W005 MEIN Generate source list (Batch)_RM07IBDC MBBC Batch input: Create physical inventory docs. for c_RM07ICN1 MBBC Batch input: Create phys. inv. docs. for cycle cou_RM07IE31 MBBC Batch input: Create phys. invetory docs for sales


document.doc 58 of

65

_RM07II31 MBBC Batch input: Create phys. inv. docs. for normal st_RM07II32 MBBC Batch input: Block material for physical inventory_RM07II34 MBBC Batch input: Enter count results with reference to _RM07II37 MBBC Batch input: Post differences_RM07II38 MBBC Batch input: Enter count w. ref. to doc. post dif_RM07II39 MBBC Batch input: Enter count w/o reference to document_RM07II40 MBBC Batch input: Enter count w/o ref. to doc. post di_RM07IK31 MBBC Batch input: Create phys. inventory docs. for vend_RM07IO31 MBBC Batch input: Create phys. inventory docs. for mat_RM07IV31 MBBC Batch input: Create phys. inv. docs for ret. packa_RM07IVW1 MBBC Batch input: Create phys. inventory docs. for vend_RM07IW31 MBBC Batch input: Create phys. inv. docs. for consignme_RM07MCHV MBMB Display batch where-used list_RM07MCHW MBMB Build up batch where-used list_RM07MMBL MBBC Batch input: Post material document_RM07RRES MBBC Batch input: Create reservation_RM07SVOR MBBC Batch input: Inventory sampling_RMCVNENL MCV Read number of next delivery that will be batch-up_RMM60TOP Include for general data structures for batch inpu_RMMM60BI MDPB Independent requirements batch input_RMMMBIM0 MMBC Create batch input session: Create/Change material_RMMMBIMG MMBC Generation program: Batch input for Create/Change_RMMMBIMI MMBC Initialize batch input structures_RMMMBIMJ MMBC Initialize batch input structure with predefined c_RMMMBPBI MDPB Create a seq. file for the batch input independen_RMMPS000 MD03 Batch main program for MPS_RMMR2100 Create batch input for price change to future pric_RMMRP000 BPLA BATCH structure for MRP run_RMNIWEBI NIWE Batch input routines for lowest value determination_RMSTRA20 IPM0 Maintenance plan date monitoring (Batch input IP10)_RPBEBA00 PB00 Batch processor statements_RPCIPO15 PC00 INCLUDE for RPCIPO00/RPCIPI00 - Store batch input_RPIBRT00 PINP Batch input to evaluate personnel reviews_RPICMP01 PM0I Data definitions for batch input to compensation s_RPICMP02 PM0I Main program for batch input to compensation syste_RPICMP03 PM0I Forms for batch input to compensation system_RPICMP05 PM0I Batch input P0008_RPIJSTD0 PCD2 Batch input for creating new tax records at beginn_RPIKUGD0 PCD3 Batch input for KUG/SWG_RPILSKA0 PCA0 Creating wage tax papers at end of year with batch_RPISVRD0 PBAS Batch input for changing maximum HI gross amount_RPTLEA30 PT0I Batch input: Annual leave_RPTUPD00 PT00 New valuation of absence records using batch input_RPWI0000 PW00 Batch input to incentive wages_RQEAAS10 QRLP List of all batches for a material

END OF DOCUMENT


document.doc 59 of

65

abap standards

Documents