Ibm Development Standards and Guidelines - Draft 2

Supply Chain Transformation
Development Standards and Guidelines
for
VERIZON
Supply Chain Transformation Project
Verizon Proprietary/Confidential
Page 1 of 60
TABLE OF CONTENTS
1.0 Overview...............................................................................................................................................................................5
2.0 Programming Standards Definitions..................................................................................................................................5
3.0 Development Methodology..................................................................................................................................................6
4.0 Development Guidelines......................................................................................................................................................7
5.0 Program Structure................................................................................................................................................................9
6.0 External ABAP/4 Program Elements..................................................................................................................................9
6.1 Selecting a Program Name..............................................................................................................................................9
6.2 Text Elements...................................................................................................................................................................9
6.3 Attributes..........................................................................................................................................................................9
7.0 Internal ABAP/4 Program Elements.................................................................................................................................12
7.1 Documentation Box .......................................................................................................................................12
7.2 Declarative Elements.....................................................................................................................................................13
7.3 Event Elements...............................................................................................................................................................17
7.4 Control Events................................................................................................................................................................18
7.5 Operation Events............................................................................................................................................................23
8.0 Program Comments............................................................................................................................................................24
8.1 Internal Programming comments..................................................................................................................................24
8.2 External Programming comments.................................................................................................................................25
9.0 ABAP/4 Coding Techniques..............................................................................................................................................26
9.1 Data Selection..............................................................................................................................................................26
9.2 Program Identifiers, Constants and Variables..............................................................................................................27
9.3 Flags..............................................................................................................................................................................27
9.4 PFKEYS Usage..............................................................................................................................................................27
9.5 Screen Painter Standards...............................................................................................................................................28
10.0 Reviews.............................................................................................................................................................................30
10.1 Requirement and Design Reviews ..............................................................................................................................30
10.2 Code Reviews...............................................................................................................................................................30
11.0 SAP Naming Conventions................................................................................................................................................32
11.1 Program Naming..........................................................................................................................................................32
11.1.1 Local Private Programs.........................................................................................................................................32
11.1.2 Production Programs.............................................................................................................................................33
11.2 Data Element................................................................................................................................................................33
11.3 Domain.........................................................................................................................................................................33
11.4 Enhancement ...............................................................................................................................................................33
11.5 Enhancement project....................................................................................................................................................34
11.6 Function Routines.........................................................................................................................................................34
11.6.1 Function Groups....................................................................................................................................................34
11.6.2 Function Modules..................................................................................................................................................34
11.7 IDocs.............................................................................................................................................................................35
11.7.1 IDoc Type...............................................................................................................................................................35
11.7.2 IDoc Message........................................................................................................................................................35
11.7.3 IDoc Function Module..........................................................................................................................................35
11.8 Lock Object...................................................................................................................................................................35
11.9 Logical Database..........................................................................................................................................................35
11.10 Menu...........................................................................................................................................................................36
11.11 Message......................................................................................................................................................................36
11.11.1 Message ID..........................................................................................................................................................36
11.11.2 Message number..................................................................................................................................................36
11.12 Module Pools..............................................................................................................................................................36
Page 2 of 60
11.13 SAPscript....................................................................................................................................................................37
11.14 Standard Text ID........................................................................................................................................................37
11.15 Standard Text Name ---- ...........................................................................................................................................38
11.16 SmartForms................................................................................................................................................................38
11.17 Screens........................................................................................................................................................................38
11.18 Search Helps...............................................................................................................................................................39
11.19 SPA/GPA Parameter...................................................................................................................................................39
11.20 Tables..........................................................................................................................................................................39
11.20.1 Transparent Tables..............................................................................................................................................39
11.20.2 Pooled tables and Cluster tables..........................................................................................................................39
11.21 Transaction Codes .....................................................................................................................................................40
11.22 Views...........................................................................................................................................................................40
11.22.1 Database view, Projection view, Maintenance view...........................................................................................40
11.22.2 Help view.............................................................................................................................................................40
11.23 Variants ......................................................................................................................................................................40
11.24 BDC Sessions.............................................................................................................................................................41
11.25 File Names..................................................................................................................................................................41
11.26 Classes........................................................................................................................................................................41
11.27 ABAP Objects.............................................................................................................................................................42
11.28 Business Objects.........................................................................................................................................................43
11.29 Workflow Templates...................................................................................................................................................43
11.30 Workflow Tasks..........................................................................................................................................................44
12.0 Business Warehouse (BW)...............................................................................................................................................44
12.1 Infocube........................................................................................................................................................................45
12.2 ODS Object...................................................................................................................................................................45
12.3 InfoSource....................................................................................................................................................................46
12.4 InfoObject.....................................................................................................................................................................46
12.5 Query............................................................................................................................................................................47
12.6 InfoSet Query...............................................................................................................................................................47
12.7 Roles.............................................................................................................................................................................48
12.8 Restricted Key Figures.................................................................................................................................................48
12.9 Calculated Key Figures................................................................................................................................................49
12.10 Variables.....................................................................................................................................................................49
12.11 InfoPackage................................................................................................................................................................50
12.12 InfoPackage Groups...................................................................................................................................................50
12.13 Periodic InfoPackage Jobs..........................................................................................................................................51
12.14 Variants.......................................................................................................................................................................52
12.15 Events.........................................................................................................................................................................52
12.16 BW Query and Workbook Properties.........................................................................................................................53
13.0 Portals...............................................................................................................................................................................54
13.1 iViews...........................................................................................................................................................................54
13.2 Channels.......................................................................................................................................................................55
13.3 Roles.............................................................................................................................................................................55
13.4 Pages.............................................................................................................................................................................56
13.5 Workset.........................................................................................................................................................................56
13.6 External Services..........................................................................................................................................................56
13.7 Folders..........................................................................................................................................................................57
14.0 Logical Paths and Files....................................................................................................................................................57
15.0 Standard Header Routine.................................................................................................................................................59
16.0 Change and Transport System........................................................................................................................................59
16.1 Overview......................................................................................................................................................................59
16.2 Creating a correction in the Development system.......................................................................................................59
16.3 Promotion of ETL jobs to QA or Production...............................................................................................................60
Page 3 of 60
Page 4 of 60
1.0Overview
The purpose of this document is to provide development standards and guidelines for members of the
development team on the VERIZON Supply Chain Transformation (SCT) project. The standards and
guidelines cover all the SAP development application areas including ABAP/4 programming language,
Workflow, Portals, EAI WebLogic Integration and Business Warehouse (BW).
The objectives of the standards and guidelines contained in this document are to:
• Produce a common framework for all developers on the VERIZON SCT development team.
• Produce consistent naming conventions.
• Produce consistent and reliable results.
• Allow for easier maintainability (improved productivity / customer service).
• Provide guidelines where definite standards have not been enforced.
• Provide a source document that will be periodically reviewed and updated.
The naming standards contained within this document are not intended to be complete, but rather continually
enhanced via new suggestions, improvements, standards and technologies.
The Programming standards and guidelines contained in this document are primarily designed for developers
who are either employed at, or under contract to the VERIZON SCT Project.
When ABAP programming is required in context of SAP BW, the standards and guidelines set forth for the
ABAP Development Standards will be utilized.
In the ABAP/4 development environment the terms "Report" and "Program" are used to describe written
developments, created using the ABAP/4 Workbench. For clarification purposes, the terms "Report" and
"Program" are considered to be one and the same.
2.0 Programming Standards Definitions

ABAP Advanced Business Application Programming
Shall/Will An imperative. The statement will apply in every case.

No exceptions.
Should A very strong preference. The statement will be

adhered to wherever possible.
Assumed By default the statement will be adhered to.
Recommended The adherence of the statement is preferred.
Standard Reporting Involves selecting, editing, and sorting data; processing

control levels, calculating totals, producing statistics,
etc
Page 5 of 60
Interactive Reporting Select report data using line selection, PFKEYS,

windows, split screens, etc.
Dialog Transactions Covers the area of calling Dynpros, sending messages,

locking and releasing data records, updating, etc.
3.0Development Methodology
The Development Methodology describes the steps used to fulfill a development request from start to finish.
All team members requiring custom development must follow the methodology to have work requests
approved, prioritized, and scheduled for completion. It is important for those working on development tasks to
realize that excessive change can have an adverse effect on project timelines. A procedure for controlling
change and resolving issues during and after development is included in the methodology. Team members
should also be aware of any roles and responsibilities that they may be assigned during the course of the
development process. For the purposes of the VERIZON SCT project, the overarching development
methodology to be followed is VERIZON SCT ’s Software Development Framework (SDF).
Page 6 of 60
4.0Development Guidelines
ABAP/4 programs should adhere to the following coding guidelines:
• Authorization checks are required at the transaction level for all programs, and coded within the
program itself if applicable. Programs will be executed by users in an assigned transaction code.
• Only custom VERIZON SCT defined tables should be directly updated by a program. SAP tables
should be modified by SAP standard methods (eg. BAPI, IDOCS, etc.)
• All programs should use structured programming techniques and a top down methodology, where
applicable. Use Pretty Printer option of the ABAP editor to help align elements.
• Open SQL call should be avoided, Use Select Single when selecting records using the key fields.
Select only the fields of a table required by the program. This will increase performance and
decrease the amount of data sent between the dB server and the Application server. When
possible, read data into an internal table with one select statement, then loop through the table
rather than nesting Select – Endselect loops.
• Use Explicit work area to hold the data from the select statements
• Use CLEAR < > for variable initialization or reset.
• Global variables are restricted as follows
• If variable data is used by only one routine, a local variable must be defined.
• If variable data is used by multiple routines, a global variable or routine invocation with
parameters may be used (programmer’s discretion)
• Variable names should not contain hyphen ( - ), use underscore ( _ ).
• Messages should be maintained using message class. The first 100 messages from each message
class will be used for messages common to other programs.
• All variables should have meaningful names and should indicate what they are used for.
• There will be no literals used or hard coded values within the code.
• Input and output structures should use field names as identified in Data Dictionary.
• All opens and closes of files should be done in the main routine.
• Sequential files access should have only two reads, one to prime the process and one for
sequential processing to end of file.
• The main routine and all subroutines should be structured to avoid large or overly complicated
code. Break source down into simpler code sections (internal subroutines, macros, includes or
function modules).
• Similarly, common code should be maintained in an include or function module.
• Subroutines should be in either alphabetical order or call sequence order within the program.
• Upon the program's conclusion, a return code should be set identifying successful completion,
error, or abnormal termination.
• When using the key word SORT to sort an internal table, use the BY parameter as often as
possible. This will increase performance. Use Binary Search when reading large internal tables (>
20 rows). Sorting the internal table is much faster than using the ORDER BY in the select
statement.
• Set the OCCURS = 0 for internal tables unless you have a good size estimate (Use “INITIAL SIZE”
for new development.)
• Using the ASSIGN keyword should only be done when there are no other possibilities. This key
word generates a heavy load on the system and adversely affects performance.
• When using a logical database, utilize a database with minimal levels (even if one must be
created).
Page 7 of 60
• Is the program using SELECT * statements? Convert them to SELECT column 1 column 2 or use
projection views.
• Are CHECK statements for table fields embedded in a SELECT … ENDSELECT loop? Incorporate
the CHECK statements into the WHERE clause of the SELECT statement.
• Do SELECTs on non-key fields use an appropriate Database Index or is the table buffered? Create
index for the table in the data dictionary or buffer tables if they are read only or read mostly.
• Is the program using nested SELECTs to retrieve data? Convert nested SELECTs to database
views, database joins or SELECT … FOR ALL ENTRIES IN ITAB.
• Are there SELECTs without WHERE condition against files that grow constantly (BSEG, MKPF,
VBAK)? 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)?
Buffer accesses to master data fields by storing the data in an internal table and filling the table
with the READ TABLE.. BINARY SEARCH method.
• Is the program using SELECT .. APPEND ITAB .. ENDSELECT techniques to fill internal tables?
Change the processing to read the data immediately into an internal table (SELECT VBELN
AUART … INTO TABLE IVBAK…).
• Is the program using SELECT ORDER BY statements? Data should be read into an internal table
first and then sorted, 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 or MAX functions for the SELECT statement? Use calculation capabilities of the
database via SELECT SUM…
• Are internal tables processed using the READ TABLE itab WITH KEY technique? Change table
accesses to use BINARY SEARCH method.
• Use “COMMIT WORK” in long running program to free up DBM locks. Commit frequency should
be an input parameter, and varies with the nature of the application. Beware that COMMIT WORK
may loose your cursor positioning.
• Is the program inserting/updating or deleting data in dialog mode (not via an update function
module)? Make sure that the program issues COMMIT WORK statements when one or more
logical units of work (LUWs) have been processed.
In addition, Workflow should adhere to the following policies and guidelines:
• Workflows will not have attachments linked to the actual workflows. Any necessary attachments
should instead be linked to the SAP document itself (such as FI document) and stored through the
VERIZON SCT - approved document management system as described in the business
requirements. Part of the reason for this is because after archiving workflow with attachments, any
retrieval from archiving might or would lose the links to these attachments.
• Workflow development objects should be built once, and if appropriate, reused by other processes.
Page 8 of 60
5.0Program Structure
An important aspect of any programming standards is the need to define the Standard Layout of the program.
This requirement is critical in producing commonly structured programs.
A skeleton ABAP/4 program exists to illustrate the standard program layout. The skeleton ABAP/4 standard
program ZCMN_TEMPLATE must be used as a source document to use as a pattern when creating a new
program.
Each new ABAP/4 program shall contain both:
• External Key Elements

• Internal Key Elements
6.0External ABAP/4 Program Elements
External program elements refer to a program characteristic that is external to the actual program source code.
6.1 Selecting a Program Name
Program identification - in compliance with the document "Naming Standards for SAP" (please see section
Naming Conventions for referral to naming standards).
6.2 Text Elements
The use of hard coded text literals will not be permitted in ABAP4 programs. All Text literals shall be declared
as "Text Elements" within an ABAP/4 program.
Example:
WRITE: TEXT-001 (Standard)
WRITE: "Material number..."(Non Standard)
6.3 Attributes
Type
• 1 - Executable program
• I - Include program
• M - Module pool
• F - Function group
• S - Subroutine pool
• J - Interface pool
• K - Class pool
Application
Application types are:
• A - Asset Accounting
Page 9 of 60
• B - Business Information Warehouse

• C - PPC (Production Planning)
• D - DASS (control station)
• E - RIVA
• F - Financial accounting
• G - General ledger
• H - Personnel Planning
• I - Plant maintenance
• J - Publishing
• K - Cost accounting
• L - Inventory management
• M - Material management
• N - Hospital
• P - Human Resources
• Q - QSS (Quality assurance)
• R - Unknown application
• S - Basis
• U - Enterprise Data Model
• V - Sales
• W - MMS (Merchandise mgt. System)
• Y - Customer head office
• Z - Customer branch
• * - Cross-Application
Title
The title of the program shall correspond to the title of the report being created by the ABAP/4 program.
Development Packages
In the VERIZON SCT development environment, related objects in the ABAP Workbench are grouped together
in a package. The assignment of an object to a package is entered in the object directory (TADIR). The
package determines the transport layer that defines the transport attributes of an object. Packages have been
identified for use when assigning Correction numbers to changes you make to Development Objects. When
you are presented with the screen that asks for information on the attributes of the Object you are changing,
you will see a field titled "Package". This is where you will enter the new Packages. Use the Package that
pertains to the area for which you are doing the work. The number “1” in the development packages has been
added to separate Phase 1 development objects. Additional Packages will be created when necessary.
• Z1MM - SAP Materials Management

• Z1PP - SAP Production Planning
• Z1MDM - SAP Master Data Management
• Z1BC - SAP Basis Components
• Z1CA - SAP Cross-Application Components
• Z1FI - SAP Financial Accounting (includes CO)
• Z1SRM - SAP Supplier Relationship Management
• Z1SD - SAP Sales & Distribution
• Z1APO - SAP APO
• Z1COMN - SAP Common ABAP Development
Page 10 of 60
• Z1BW - SAP BW Components

• Z1WF - SAP Workflow specific Components
• Z1PR - SAP Portals
Page 11 of 60
7.0Internal ABAP/4 Program Elements
Internal program elements refer to those program characteristics that directly relate to the ABAP/4 program
source code.
The following Internal Program elements will be documented:

• Documentation box
• Declarative elements
• Event elements
• Control events
• Operational events
7.1 Documentation Box
The documentation box will be the first element to be declared within an ABAP/4 program. The documentation
box is used to describe the characteristics of a program at a summary level. See skeleton program
ZCMN_TEMPLATE for an example.
Each item contained within the standard documentation box is detailed below:
• PROGRAM NAME - Short Description of program

• SAPNAME - Name of the ABAP/4 program
• CREATION DATE - Date the program was written.
e.g. 01/01/2005
• APPLICATION - Identify the SAP application to which this ABAP/4 program applies.
e.g. MM - Materials Management
SD - Sales & Distribution, etc
• AUTHOR - The name of the person who has written the ABAP/4 program.
• DESCRIPTION - Description regarding the purpose for this program being written.
• TYPE - The type of program written.
e.g. "1" – Executable Program
"M"- Module Pool
"J" - Interface Pool
"I" - Include Program
"S" - Subroutine Group
"F" - Function Module
"K" – Class Pool
• INPUTS - Identify all inputs to this program, including Files, etc.
• OUTPUTS - Identify all outputs of this program, including Reports, Files, Batch
inputs, etc.
• EXTERNAL - List all external routines called by this program (ie. Function Modules,
ROUTINES Transactions, Programs)
• RETURN CODES - List the meaning of all return codes that this program generates.
• AMENDMENTS - The last date that the specifications to this program were revised.
Page 12 of 60
- All subsequent program amendments must be documented to provide

an accurate maintenance history. Each amendment must detail the:
• Amendment no. (Maintenance request number or the next
sequential number allocated)
• Programmer making the change.
• Date of the change.
• Description of the change.
- Each amendment should be appended on the end of the last program
amendment.
7.2 Declarative Elements
The term "Declarative Elements" is used to describe those available ABAP/4 elements that are necessary to
define the internal environment that an ABAP/4 program will run under. As part of this standard, each new
ABAP/4 program shall only include those declarative elements required of the program in accordance with the
program specifications.
Throughout all the declarative elements defined for an ABAP/4 program, the exact level of indentation will not
be enforced, but the level of consistency will. (i.e. declarative elements can be indented 3 or 5 characters, etc.,
but the indentation will be kept consistent.)
Also at least one single blank line shall separate each new declarative element.
The following declarative elements are described below:
• REPORT
• TABLES
• SELECT-OPTIONS
• PARAMETERS
• DATA
• FIELD-GROUPS
• FIELD-SYMBOLS
Page 13 of 60
REPORT element
The REPORT element shall start in column one on the next line after the documentation box, with any
associated parameters consistently indented to the right of the REPORT element.
The "NO STANDARD PAGE HEADING" parameter must be included for those ABAP/4 programs that produce
report(s) as output. The common heading routine in the skeleton ABAP/4 program (ZCMN_TEMPLATE) will
control the formatting of all report headings and therefore the standard ABAP/4 page heading must be made
inactive.
Example:
REPORT ZFIOOOlA NO STANDARD PAGE HEADING
LINE-SIZE 132
LINE-COUNT 65
MESSAGE-ID ZZ.
When using the MESSAGE option in your ABAP to send messages back to the user you must first define any
new messages in the message class being used. No hard coded messages will be allowed.
TABLES element
The TABLES element shall start in column one with all tables declared on the subsequent lines. Each table will
commence on a new line and be consistently indented. The ordering of declared tables will not be enforced as
part of this standard. For documentation purposes, include a line comment to the right of the table name to
indicate the short description of the table as it appears in the data dictionary.
Example:
TABLES: BKPF, "Accounting Document Header
LFlA, "Vendor Master (General Section)
T001, "Company Codes
T001W. "Plants/Branches
SELECT-OPTIONS element
The SELECT-OPTIONS element shall start in column one with all select-options declared on the subsequent
lines. Each select-option will commence on a new line and should be prefixed with an “S_” and be consistently
indented. Add selection texts for each select-option to make the selection screen more users friendly.
Example:
SELECT-OPTIONS:
S_USERID FOR SY-UNAME,
S_DOC_DATE FOR SY-DATUM.
PARAMETERS element
The PARAMETERS element shall start in column one with all parameters declared on the subsequent lines.
Each parameter will commence on a new line and should be prefixed with a “P_” and be consistently indented.
Add selection texts for each parameter to make the selection screen more user friendly.
Example:
PARAMETERS:
USERID LIKE SY-UNAME,
Page 14 of 60
DOCDAT LIKE SY-DATUM,

DTL TYPE C DEFAULT "Y".
DATA element
The Data element shall start in column one with all data work fields declared on the subsequent lines. Each
data work field will commence on a new line and be consistently indented. The data work field type and value
definitions must also be aligned. The only exception is for structure definition utilizing the “INCLUDE
STRUCTURE” format (see below).
As part of these programming standards it is highly recommended that wherever possible the reference to data
dictionary fields and structures be used by programmers when developing ABAP/4 programs. The ABAP/4
programming language offers many benefits with regards to available commands and statements when data
dictionary fields are referenced.
It is for this reason that the LIKE attribute be used to define work fields where possible under the data element
area of the program.
Data work field naming conventions will not be enforced as part of these programming standards, although
meaningful assignment of names will be required.
Individual Work Fields

Individual work fields should be prefixed with “g_” for global and “l_” for local variables.
Example:
DATA:
G_USERID LIKE SY-UNAME,
G_DOC_DATE LIKE SY-DATUM,
L_DTL_RPT TYPE C DEFAULT 'Y',
L_ACCT_NUM TYPE N VALUE 0.
Internal Table Work Fields (include structure; multi-line exception)

Internal tables should be prefixed with “GI_” for global and “LI_” for local internal tables.
Example:
DATA: BEGIN OF GI_CUSTOMER_STRUCTURE.
INCLUDE STRUCTURE KNA1.
DATA: END OF GI_CUSTOMER_STRUCTURE.
Internal Table Work Fields (Single & Multilevel)

Examples:
DATA:
BEGIN OF DATE,
MONTH (2) TYPE C,
DAY (2) TYPE C,
YEAR (4) TYPE C,
END OF DATE.
Page 15 of 60
DATA:
BEGIN OF USERIDS OCCURS 50,
CODE (5),
NAME LIKE SY-UNAME,
ACCT (1 0),
END OF USERIDS.
Objects
Examples:
DATA:
<instance> TYPE REF TO <classname>.
FIELD-GROUPS element
The FIELD-GROUPS element shall start in column one with groups defined on the subsequent lines. The first
field-group will always be "HEADER" (available sort fields), followed by the remaining groups which must be
meaningfully named.
The INSERT statement required to insert field names into each field-group will immediately follow the FIELD-
GROUP declaration. Each new INSERT statement shall also start in column one and have the first field name
indented. The fields to be inserted shall reference those corresponding data dictionary names where possible.
This will make coding benefits available with several of the ABAP/4 command statements.
Examples:
FIELD-GROUPS:
HEADER
DETAIL.
INSERT:
LFA1-LIFNR
LFAl-LANDl
INTO HEADER.
INSERT:
LFAl-STRAS
LFAl-ORT01
INTO DETAIL.
FIELD-SYMBOLS element
The Field-symbols element shall start in column one with the field-symbols indented on the subsequent line(s).
Each field-symbol shall be assigned a meaningful name. Field symbols should be prefixed with “FS_”.
Examples:
FIELD-SYMBOLS:
<FS_ACCT_CD>, <FS_STORE_LOC>.
Page 16 of 60
7.3 Event Elements
Within the ABAP/4 programming language there exists several programming events. A programming event
signals the execution of a specific set of program statements (block of code), at a specific point, during
program run time.
The following event elements are documented below:
• INITIALIZATION
• START-OF-SELECTION / END-OF-SELECTION
• GET / GET LATE and other DB related statements
• TOP-OF-PAGE
INITIALIZATION
This event shall always be present for those ABAP/4 programs with a selection screen. It is essential that this
event always be the prior event to the Start-of-Selection event. Care should be exercised with regards to the
programming logic contained in this event, as the Initialization event is not executed in batch.
Data declarations shall not be defined after this event, as during a program batch execution the data fields will
not be known to the program.
START-OF-SELECTION / END-OF-SELECTION
The events Start-of-Selection and End-of-Selection shall always be present in all ABAP/4 reporting programs.
The End-of-Selection event will be used to execute among other things the standard subroutine
"REPORT_HEADER", so that titles of reports will be printed. The standard routines will need to be developed at
a later time within the phase 1 of implementation.
GET / GET LATE and other DB access related statements

The event GET LFAl will access the table LFAl. As part of these standards the GET event shall only be used
with a database table. The GET event shall only be used in conjunction with a table that requires specific
processing.
Example:
(Non Standard)
GET LFAl.
GET LFB1.
CHECK LFB1-BUKRS = '0010'.
WRITE: / LFB1-EIKTO.
(Standard)
GET LFB1.
CHECK LFB1-BUKRS = '0010'.
WRITE: / LFB1-EIKTO.
Page 17 of 60
All table fields accessed and subsequently referenced in an ABAP/4 program shall always have the field
prefixed with its table name, etc. to uniquely identify the source of the data field. The one exception to this is
the use of table fields in connection with the AT...ENDAT construct.
The ABAP/4 programming language allows program data fields which are unique to the program, to be
referenced without a prefix.
Examples:
LFB1-BUKRS, (Standard)
BUKRS, (Non Standard)
It is recommended that all access to files be through the use of logical databases. Accesses to individual table
should be kept to a minimum.
TOP-OF-PAGE
All ABAP/4 programs that produce list report(s) must contain the TOP-OF-PAGE event. This event is executed
at each new page when generating the report, and therefore will be used in these programming standards to
control and print the program headings.
A function module has been written to control all header and footer detail lines, of all ABAP/4 report generating
programs.
7.4 Control Events
Controlling events within the ABAP/4 programming environment are used to control the flow of the program
within processing blocks. There are several controlling elements available, with their description and
functionality described below:
• IF.... ELSE...ENDIF
• DO...ENDDO / WHILE....ENDWHILE
• CASE....WHEN....ENDCASE
• ON CHANGE OF......ENDON
• LOOP....ENDLOOP
• LOOP TERMINATION
• TERMINATION OF PROCESSING
• SUBROUTINES
• FUNCTION MODULES
• AUTHORITY-CHECK
IF.... ELSE...ENDIF.
When coding nested IF statements within a program, no more than three nests shall be structured, at such a
point a PERFORM call or CASE statement will be executed. This standard will restrict lengthy control events
congesting a program, and making it difficult to read.
Each matching IF...ELSE...ENDIF will be consistently aligned and indented.
Example:
IF BKPF-BELNR = INVOICE_NUMBER.
PERFORM PROCESS_INVOICE.
Page 18 of 60
ELSE.
PERFORM CHECK_DOCUMENT_NO.
ENDIF.
When a program variable is repeatedly evaluated for discrete values the IF.... ELSE...ENDIF statement shall
be replaced with the CASE.... WHEN.... ENDCASE construct.
Example: 1
(Non Standard)
IF LFB1-EIKTO = '00014000'.
<.....CODE.....>.
ELSE.
IF LFBl-EIKTO = '00014500'.
<...CODE...>.
ELSE.
IF LFBl-EIKTO = '00014800'.
<....CODE....>.
ELSE.
IF LFB1-EIKTO = '00015000'.
<....CODE....>.
ENDIF.
ENDIF.
ENDIF.
ENDIF.
Example: 2
(Standard)
CASE LFB1-EIKTO.
WHEN '00014000'.
<....CODE....>.
WHEN '00014500'.
<....CODE....>.
WHEN '00014800'.
<....CODE....>.
WHEN '00015000'.
<....CODE....>.
WHEN OTHERS.
<....CODE....>
ENDCASE.
The IF.... ELSEIF statement will not be used.
Page 19 of 60
DO...ENDDO. / WHILE...ENDWHILE.
The Do...Enddo. / While...Endwhile control events shall always be coded with a controlled exit point.
Example:
DO 9 TIMES.
SHIFT NAME BY 1 PLACES.
ENDDO.
OR
DO.
READ DATASET 'SAPV01' INTO RECORD.
IF SY-SUBRC NE 0.
EXIT.
ENDIF
ENDDO.
CASE....WHEN....ENDCASE.
When coding nested CASE....WHEN....ENDCASE statements within a program, no more than three nests shall
be structured, at such a point a PERFORM call will be executed. The WHEN OTHERS clause will be used
always. This standard will restrict lengthy control events congesting a program and making it difficult to read.
Each nested CASE....WHEN...ENDCASE statement will be consistently aligned and indented. For program
efficiency purposes the most likely 'WHEN' event should be coded first.
Example:
see the control event example for IF....ELSE....ENDIF.
ON CHANGE OF.......ENDON.
The ON CHANGE OF control event is preferred to the IF statement when field change evaluation is required.
This will eliminate the need to define a work field.
Example:
GET LFAl.
ON CHANGE OF LFAl-LIFNR.
WRITE:/ ’Vendor name:’, LFAl-NAME1.
ENDON.
LOOP....ENDLOOP.
To ensure all requested entries in a transparent table are read, the table shall be initialized to spaces.
Page 20 of 60
ABAP/4 interprets each value (other than space) in a declared transparent table as part of the generic key, and
hence no data will be processed.
Example:
MOVE SPACE TO T005.
LOOP AT T005.
<....CODE... >.
ENDLOOP.
LOOP TERMINATION
It is recommended, that for readability and maintainability purposes, that loop termination be controlled via the
CHECK and EXIT statements.
Example: 1.
GET LFB1
CHECK LFBl-BUKRS = SY-BUKRS.
2.
LOOP AT TAB.
<....CODE....>
IF SY-SUBRC NE 0.
EXIT.
ENDIF.
<....CODE....>
ENDLOOP.
TERMINATION OF PROCESSING
The REJECT statement shall be used to terminate a currently processed Table and all dependent Tables lower
in the logical database hierarchy.
The STOP statement shall be used to terminate an ABAP/4 program's data selection. The END-OF-
SELECTION event will be declared in all programs and will be used in conjunction with the STOP statement.
The inclusion of the END-OF-SELECTION event is consistent with the rule of structured programming, of one
entry and one exit point.
SUBROUTINES
The use of subroutines is imperative in developing well structured programs. Wherever possible a program
should logically organize command statements into subroutines.
The ABAP/4 statements FORM....ENDFORM are used to define the boundaries of a subroutine. Both of these
statements shall start in column one, with subroutine statements indented consistently thereafter. Each
subroutine shall be prefixed with a standard FORM documentation box and preferably start with the name
“SUB_”.
Page 21 of 60
All FORM....ENDFORM constructs shall be placed at the bottom of the program, ordered according to their
execution sequence.
An ABAP/4 Program may not call a FORM routine in another program. In this situation the program code that is
common to two or more programs shall be incorporated into an INCLUDE member or a FUNCTION MODULE.
The programmer, where possible, should refrain from duplicating ABAP/4 code across more than one program.
Example:
* ----------------------------------------------------------------------------*
* FORM Read-purchase-order *
* ----------------------------------------------------------------------------*
* This form reads the purchase order relating to the invoice *
* document stored in the internal table 'INV-DOCS'. *
* ----------------------------------------------------------------------------*
FORM SUB_READ_PURCHASE_ORDER.
IF............
MOVE..............
ENDIF.
ENDFORM.
FUNCTION MODULES
The use of function modules in the ABAP/4 development environment provides the means to execute common
processing logic, available to all programs.
Developed Programs shall call function module logic where applicable, rather than re-invent the wheel. Quite
often function modules can be enhanced to accommodate variations in the required processing logic.
All declarative elements defined in a function module shall be consistent with those standards and comments
documented as part of this document.
Unless indicated otherwise the programming elements permissible in the function module environment, shall
conform to the same programming standards which form this document.
AUTHORITY-CHECK
Authority checks are used to prevent the unauthorized execution or restrict the available processing options of
an ABAP/4 program. When functional requirements specify that security needs to be applied, an authority
check will be included within the program.
If the security provided by using logical databases satisfies the functional requirement then there is no need to
include an authority check within the program. A generic authorization object will need to be developed if there
Page 22 of 60
are many programs that need it. Additional documentation for how to develop this authorization object is
available online in SAP.
Example:
7.5 Operation Events
Operation events are those program events indicated by an operational action.

(i.e. MOVE, SUM, APPEND, WRITE,.....etc.)
MOVE-CORRESPONDING / ADD-CORRESPONDING ETC.

Fields participating in these special ABAP/4 statements shall, where possible, use the LIKE statement.
Examples:
START-OF-SELECTION.
GET LFA1.
MOVE-CORRESPONDING LFAl TO RECORD.
GET LFB1
MOVE-CORRESPONDING LFB1 TO RECORD.
-------
-------
END-OF-SELECTION.
Page 23 of 60
8.0Program Comments
The amount of detail with regards to program comments is largely up to the discretion of the individual
programmer. The programmer should access the necessary level of program documentation required to fully
clarify the purpose and functionality of the program. Program documentation includes both internal and external
documentation.
8.1 Internal Programming comments
Program comments shall appear in the documentation box, before complex code and before each FORM
routine.
All program comments shall be clear, concise and accurately expressed, with the emphasis placed on the
WHAT and WHY aspects.
As part of this standard, all comments shall appear before the coded functionality and will be in the form of a
full comment line. Wherever possible it is recommended that full comment lines not be inserted in the middle
of control events. (e.g. IF.....ELSE.....ENDIF), to maintain program readability.
Example:
*--------------------------------------------------------------------*
* This is an example of a full program comment line. *
*--------------------------------------------------------------------*
The ABAP/4 language permits a comment to reside adjacent to a code line. In-line comments will be used for
documenting change request numbers, data element definitions and nested end statements. The change
request number will appear against those lines modified as part of the program enhancement.
Example:
MOVE: LFAl-LIFNR TO LFB1-LIFNR, "example of in-line comment

LFAl-NAMES TO LFBl-NAME1.
When modifying an ABAP/4 program, lines to be deleted or changed shall be copied and commented out. All
lines of code relating to the change should be commented to the right of the line with the change request
number (TMS Request Number). The duplication of program lines provides a program history.
Programs that have had sufficient enhancements made, can become difficult to read when blocks of code are
repeated and subsequently commented out. Therefore consideration has to be given to when a program has
become too difficult to read, and should be cleaned up ready for another change cycle.
In the following example the number '99999' must match with the sequential number given to the corresponding
program amendment. The first amendment number will be '00001', and subsequent amendments will be
incremented by one.
Example:
* WRITE:/TEXT-001, TEXT-002. "99999
Page 24 of 60
WRITE:/TEXT-001, TEXT-003. "99999
8.2 External Programming comments
External report documentation can be created using the SE38 transaction and selecting the Documentation
button.
Page 25 of 60
9.0ABAP/4 Coding Techniques

This section of the document is for miscellaneous programming techniques. Not all of the documented
techniques will be enforced as part of the programming standards, although the use of the recommended
programming techniques is encouraged where appropriate.
9.1 Data Selection
• When an ABAP/4 program is executed it reads the selected data from the relevant databases based on
evaluations according to the report's specifications. Therefore strong consideration should be given to
the controlled restriction of unwanted database accesses. The use of precise specifications within all
programs will significantly enhance program performance.
• The ABAP/4 programming language permits the specification of multiple statements on one physical
line of code. To increase program readability, each ABAP/4 statement shall be coded on an individual
line.
• The practice of chaining identical ABAP/4 statements, can increase program readability and remove
redundant statements.
• Large processing blocks of code shall be broken down into logical units of work and performed as
subroutines. The use of subroutines develops structured programs that are easier to read and maintain.
Subroutines shall be ordered in the sequence the system executes, to aid in reading the program.
• The programming standards support the ready made key work structures available in the ABAP/4
language. In the SAP ABAP/4 editor SE38 templates can be inserted for each function call by first
placing the cursor on the line where the code is to be entered and then by pushing the Insert Statement
button). Next select the function.
• Frequently used constants shall be defined with a VALUE clause in the DATA declaration area.
Frequently used data declaration structures shall be defined as Include programs.
• Programs that contain arithmetic computations shall have 'Fixed Point Arithmetic' set in the program
attributes. Fixed point arithmetic allows an ABAP/4 program's computations to be performed as would a
standard calculator. Program debugging and maintenance will be made easier with this attribute set.
• All numeric fields used in calculations should be setup as packed. Numeric fields are stored as packed
in the database. Calculations should be performed on packed fields. For incrementing numeric field
values use the following syntax: FIELDA = FIELDA + 1.
Use internal tables as work areas for database tables when practical. Reference tables used repeatedly in a
program are candidates for loading internally into ABAP. If all the fields are needed, use the STRUCTURE
syntax. Otherwise, name each field in the internal table the same as the database field and use the LIKE
construct to define the attributes. In that case use the SELECT ...INTO. The structure of the internal table must
be identical to the database so use the STRUCTURE syntax. Another option is to create a projection view in
the data dictionary. Then structure the internal table off the projection view. It is then possible to select * from
the projection view into the internal table. Be as restrictive as possible with the WHERE clause to reduce the
answer set. Data should be read into an internal table first and then sorted, unless there is an appropriate index
for the order by fields.
Page 26 of 60
Internal tables are a dynamic data structure. Their memory requirements are met in blocks. The initial
memory allocation (hereafter called the OCCURS area), can be controlled using the "OCCURS n" or "INITIAL
SIZE n" addition in the table definition (DATA, TYPES). Once the OCCURS area is full, the next block to be
created is twice as big as the OCCURS area (as long as this is not greater than 8 KB). All further blocks are
then created with a constant size of 12 KB.
You can leave it to the system to determine the size of the OCCURS area by specifying n = 0. In this case the
system allocates only a "small" portion of memory at the first INSERT or APPEND statement. "OCCURS 0" or
"INITIAL SIZE 0" means that 16 <= n <= 100 (depending on the line width).
It only makes sense to specify a concrete value of n > 0 when you know exactly how many entries the table will
have, and you want to set up the OCCURS area exactly. This can be particularly important if you want to nest
internal tables (where an "outer" internal table contains one or more other internal tables in each line, and the
"inner" tables only have a few entries (no more than five, for example).
To avoid excessive memory requirements, the system handles large values of n as follows: The largest
possible value of n is n_max = 8 KB divided by the line width. For larger values, n is set such that n multiplied
by the line width is around 12 KB.
9.2 Program Identifiers, Constants and Variables
All program identifiers, constants and variables shall be assigned meaningful names that are clearly
understood.
Constants shall be declared with the VALUE clause in the data declaration part of the program. Table ZTXEDIT
can be used to store constants and reference values for program execution. The interface / conversion /
enhancement ID should be used for storing these values in this table.
Variables with the same name shall not be declared as both global and local. This standard will eliminate
confusion when reading through the program.
9.3 Flags
Programming flags should be replaced with alternative logic wherever possible. A flag shall only be assigned a
'Yes' or 'No' value, represented by 'Y' and 'N' respectively.
9.4 PFKEYS Usage
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 Choose PF3 Back

PF4 Possible EntriesPF8 Execute PF9 Editor, Long Text, Select/Deselect
PF10 Menu bar PF11 Save PF12 Cancel
PF14 Delete PF15 Exit PF16 Hold, Save without Check, Sort
CTRL+F Search
CTRL+G Search Again
Page 27 of 60
CTRL+P Print
CTRL+S Save (PF11)
CTRL+PAGE UP First Page
CTRL+PAGE DOWN Last Page
PAGEUP Previous Page
PAGEDOWN Next 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.
Example:
PF3 = Back
PF8 = Execute
9.5 Screen Painter Standards
The Screen Painter standards apply to those customized developments involving the creation of tables and
transactions.
• 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.
Page 28 of 60
• 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 LFA1-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 be 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 Naming Standards
section of this document.
• 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 table with a written program. Use the SAP
transactions to process transactions.
Page 29 of 60
10.0Reviews
10.1 Requirement and Design Reviews
Reviews are mandatory for application development. The following are the guidelines to be used for the
internal project team reviews. Formal quality peer reviews and inspection point guidelines for compliance with
SDF will be documented and distributed by the Methodology Assurance team.
• Design document Author plans and schedules the appropriate review meeting(s).
• Required attendees should include:
• Developer that will work on the application
• Technical Team Leader to moderate the meeting, cancel meeting if insufficient attendance
or reviewers not prepared, resolve any disputes that occur.
• Technical Consultant who will assist in any questions/concerns pertaining to the
specification
• Optional attendees should include:
• Functional Owner that worked on the requirements
• Application Team Leader (Functional),resolve any disputes that occur.
• Application Consultant (Functional) will also assist in any questions/concerns pertaining to
the specification.
• Design document Author distributes Documentation prior to the review.
• Reviewers examine the documentation prior to the meeting noting any deviations to the guidelines
and any other problems.
• The design document Author designates a recorder to document the meeting into meeting minutes.
• The meeting’s output is a list of issues with assigned owners and due dates
• At a minimum, the following items should be checked during the review:
• Does the design document specification conform to the guidelines set forth?
• Are all mandatory sections filled in with enough information?
• All record layouts, inputs and outputs must be documented. Referring to existing
documentation is fine.
• Abnormal conditions must be addressed.
• The review team must decide if a follow up review is required.
• Review will be limited to 30 minutes to one hour in length.
10.2 Code Reviews
Code reviews are required for all application development. Code reviews should be held to inspect code for
correctness and efficiency. It is an ideal way to help educate programmers to a new application or coding
language. It also helps keep code consistent with the standards provided for program development. The
following is a list of the participants in a code review and their responsibilities:
• Author of program
• Schedules the code review.
• Chooses reviewer from distributed list
• Distributes code prior to review.
• Documents the meeting. (minutes)
• Corrects code as needed.
• Reviewer
Page 30 of 60
• Experienced ABAP developer, senior level

• Reviews code based on a provided checklist prior to meeting.
• Provides input to the author of any deviations from guidelines
• Provides suggestions to the author for improvement on performance
• Team Leader
• Reviews results
• Resolves disputes
Page 31 of 60
11.0SAP Naming Conventions

SAP provides reserved name spaces (i.e. ranges of available object names, usually beginning with the letters Y
or Z). Customer object names use these reserved name spaces to avoid unintentional overlaps when
importing a new maintenance level or release upgrade of SAP.
In the SAP standard naming convention, Z is for the use of the branch office and Y is for head office. Within
this project we will use Z for object names that are developed for use in production. We will use Y object
names for local private objects created during testing and experimentation by individual developers. Objects
using the Y naming convention will never be transported.
The naming convention put forth in this document is established to comply with SAP's defined customer
reserved limits, and also outline rules concerning those freely definable characters within the object name.
The following conventions are used throughout this document for our naming conventions:
• Upper case (capital) letters are to be entered as shown.
• Lower case letters are to be interpreted as follows:
x any alphanumeric character

n any numeric character
t Type of program
C Conversion
I Interface
R Report
E Enhancement
U Utility
N Includes
F Forms
W Workflow
P Portals
MNnnn Functional Specification ID without the prefix FS i.e. module name + object number
Example:
For functional specification FSFI001, use the ID as FI001
11.1 Program Naming
11.1.1 Local Private Programs
Format: Yflx…x
Length: up to 30 characters
Where: Y Constant for local private program

f First initial of owner's first name
l First initial of owner's last name
Page 32 of 60
x…x any alphanumeric characters
Note: If another developer has the same initials, add a letter or number to make it unique.
11.1.2 Production Programs
Format: Z_o_desc
Where: Z Constant for customer developed objects

o Interface / Conversion / Enhancement ID
desc Meaningful description
Example:
Z_FII001_FIN_ACC_POSTING
The skeleton ABAP/4 standard program ZCMN_TEMPLATE as shown below must be used as a source
document to use as a pattern when creating a new program.
11.2 Data Element
Format: Zxxxx
Preferably use SAP standard data elements which have the similar length and description as you need. If you
do not find such a data element then try to limit the name to 10 characters.

x…x Any alphanumeric characters
11.3 Domain
Format: Zx…x
Preferably use SAP standard domain which have the similar length and description as you need. If you do not
find such a domain then try to limit the name to 10 characters.

11.4 Enhancement
Format: Zox…x
Page 33 of 60

o Object type
11.5 Enhancement project
Format: Zox…x

o Object type
11.6 Function Routines
Frequently used routines can be created as function modules. These are accessed by ABAP/4 programs
through the “CALL FUNCTION” statement and may be shared across programs. Function Modules are
grouped within a Function Group. All Function Modules belonging to one SAP business object type should be
created in one Function Group, if possible.
11.6.1 Function Groups
Format: Z_o_desc

desc Meaningful description
11.6.2 Function Modules
Format: Z_o_desc

desc Meaningful description. Spell out the name when possible. For Workflow, the first 5 characters
should be one of the following to describe the function module:
_CHK_ for Check Function
_RCV_ for Receiver Function
_TRG_ for Business Transaction Event
_ROL_ for Role Development
_WFD_ for Workflow Development
Page 34 of 60
11.7 IDocs
IDocs are configured with a message type, IDoc type, and function module in which to process them. The
variable component should be named in a consistent manner. Example: Type ZEXAMPLE01, Message Type
ZEXAMPLE, Function Module ZUK_IDOC_INPUT_ZEXAMPLE.
11.7.1 IDoc Type
Format: Z_x…xnn

nn Numeric designation, ie: ‘01’
11.7.2 IDoc Message
Format: Z_x…x

11.7.3 IDoc Function Module
Format: Z_IDOC_INPUT_Zx…x
Where: Z_ Constants for customer developed objects

b Business unit
a Application area
Zx…x IDoc Message.
11.8 Lock Object
Format: EZx…x
Where: EZ Constants for customer developed objects

11.9 Logical Database
Format: Zx…x
Page 35 of 60

11.10 Menu
Format: Zx…x

11.11 Message
11.11.1 Message ID
The following Standard Message classes will be created in the development environment. The first 100
messages within each development class will be used as standard messages common to all programs and the
rest will be program specific messages.
ZMM - SAP Materials Management

ZPP - SAP Production Planning
ZMDM - SAP Master Data Management
ZBC - SAP Basis Components
ZCA - SAP Cross-Application Components
ZFI - SAP Financial Accounting (includes CO)
ZSRM - SAP Supplier Relationship Management
ZSD - SAP Sales & Distribution
ZAPO - SAP APO
ZCOMN- SAP Common ABAP Development
ZBW - SAP BW Components
ZWF - SAP Workflow specific Components
ZPR - SAP Portals
11.11.2 Message number
Format: nnn
Length: 3
Where: nnn Any numeric characters 001 – 100 Standard messages for project
101 – 999 Program specific messages
11.12 Module Pools
Format: SAPDZox…x Module pool for dialog

SAPMZox…x Module pool for screens
Page 36 of 60
SAPFZo…x Module pool for subroutines

SAPSZo…x Module pool for update programs
Where: SAPMZ Constant for customer developed module pools

o Object ID example ESD001
x…x Alphanumeric name for Module pool
Note: It is highly recommended that the Zox…x defined portion of the program name coincide with the name of
the transaction that is used for module execution. Transactions have a limit of 20 characters.
Programming Module Pools:

A module pool consists entirely of INCLUDE programs. Please use the following examples as your standard:
Data module
INCLUDE MZox…xTOP Header with data declarations including tables
(alphabetically sorted) and DATA statements.
PBO modules
INCLUDE MZbox…xO10 Process Before Output modules
INCLUDE MZbox…xO20
PAI modules INCLUDE MZox…xIl0 Process After Input modules
INCLUDE MZox…xI20
Subroutine modules
INCLUDE MZox…xF10 Subroutines
Where Zox…x corresponds to the characters of the module pool name.
11.13 SAPscript
Form
Format: Zo_x…x
Where: Z Constant for customer defined forms

o Object ID
Note: If a SAP delivered form is copied to a Z version and changed it is recommended that as much of the
original name be used to the right of the underscore.
11.14 Standard Text ID
Format: ZMnxx
Page 37 of 60

Mn Module name
xx Any alphanumeric characters
11.15 Standard Text Name ----

use rstxtran program to transport the standard text.
Format: ZMn_x…x

b Business unit
o Object Id
Style
Format: Zbx…x

b Business unit
11.16 SmartForms
Smartforms shall follow the same naming convention as function modules.
11.17 Screens
The name of a screen (or Dynpro) is made up of the name of the module pool and a screen number. The
naming convention for module pools is described above. When creating a new screen for custom developed
modules the screen number given can be in the range of 0000 to 9999. When creating a new screen for a SAP
delivered module pool the screen number is in the range of 9000 to 9999. This is typically done in the case of
a screen exit where a screen exit refers to an area of a main screen reserved by SAP developers for customers
to design their own screens as customer exits.
Format: nnnn (Custom developed module)

9nnn (SAP developed module)
Length: 4 digits
Where: n freely definable digits

9 customer name range in SAP delivered modules
When developing a series of new screens for a transaction, it is recommended that the sequence and interval
of screen numbers be structured appropriately. The sequence of screen numbers should reflect the normal flow
of screens through transaction processing. Major screens should be numbered in intervals of 100 (one
hundred) and minor screens (including pop-up windows) should be numbered in intervals of 10 (ten).
Page 38 of 60
For example: 0100 Initial selection screen

0110 Subscreen A on 0100
0120 Pop-up Window B for 0100
0200 Second output screen
0210 Pop-up Window C for 0200
Final Screen
11.18 Search Helps
Search helps allow the user to display the list of all possible input values for a screen field. They help the user
to easily locate an entry by providing minimal selection criteria. The help displayed can include key value
entries along with text descriptions.
Format: Zx…x
Where: Z Constant for customer developed object

11.19 SPA/GPA Parameter
SPA/GPA Parameter Ids are used to define default values for entry fields. The defaults are defined in the user
master record and linked to a field through the field’s data element definition.
Format: Zx…x

x..x Uniquely identifies the parameter ID.
11.20 Tables
NOTE: Table names in SAP are unique by the first 7 characters only.
11.20.1 Transparent Tables
Format: Zx…x

11.20.2 Pooled tables and Cluster tables
Format: Zx…x
Page 39 of 60

11.21 Transaction Codes
Format: Zo

o Object Id
11.22 Views
A view allows an alternative way to retrieve data from a table or groups of tables. You can reduce the number
of reads by defining a view that contains related data from several tables. A view is a logical table and is not
physically stored. SAP views differ from standard views because only tables already linked by appropriate
foreign keys in the DD can be joined.
11.22.1 Database view, Projection view, Maintenance view
Format: ZVx…x

V Always "V" for view
11.22.2 Help view
Help Views are needed when F4 Possible Entries requires more than just the key values stored in a table.
Usually the key values (e.g. codes) and the associated texts are required. The view will contain both the key
and text fields. Only one help view can be built per table.
Format: H_Zx…x
Where: H_Z Constants for customer developed objects

11.23 Variants
Page 40 of 60
Variants (selection criteria) contain program parameters and select-options. Several variants can be stored for
a program to control its execution. On-line programs should always use selection criteria to limit its execution
time. Since variants are program specific there is a free form naming standard.
Format: x…x
Where: x…x Any alphanumeric characters
11.24 BDC Sessions
Batch Data Communication (BDC) sessions are used to execute batch input of SAP transactions.
Format: bo_x…x
Where: b Business unit

o Object Id
11.25 File Names
Data files used for conversions or interfaces will be stored on the application server rather than on user
workstations unless functional requirements dictate otherwise. The directory path and location of a file is
chosen by using a logical file path and file name combination. It is recommended for ease of use that file
names be kept short and meaningful. Refer to section 2.2 Interface Implementation Guidelines in Deliverable
2.6: Interface Design Document for further details. File names will use the following convention.
Format: o_yyyymmddhhmmss.typ
Where: o Object Id
yyyymmddhhmmss Any alphanumeric characters
.typ file extension type. E.g. .txt, .csv, .dat
All names should be in lower case.
11.26 Classes
Classes are the main object oriented applications in ABAP Objects. They should have the following naming
convention.
Format: ZCL_bax…x
Where: ZCL_ Constants for customer developed classes

x…x Uniquely identifies the function module. Spell out the name when possible.
Page 41 of 60
11.27 ABAP Objects
The following section provides the recommended naming convention for ABAP objects and Variables.
ABAP classes should be named as ZCL_<class_name>. Unless specified all classes are global, local
classes should be named as ZLCL_<class_name>.
Reference variable should be declared with ‘TYPE REF TO’ ZCL_<class_name>.
In ABAP Objects, instances are created with the command ‘CREATE OBJECT’. Instance should be named
as ZICL_<class_name>.
Components of a class
Methods - Public
Static methods should be named as PU_SM_<method_name>.
Instance method should be named as PU_IM_<method_name>.
Methods - Private
Static methods should be named as PV_SM_<method_name>.
Instance method should be named as PV_IM_<method_name>.
Methods - Protected
Static methods should be named as PR_SM_<method_name>.
Instance method should be named as PR_IM_<method_name>.
Parameters of the method should be named as:

Importing parameters I_<parameter name>
Exporting parameters E_<parameter name>
Changing parameters C_<parameter name>
Result (returning) R_<result>
Exceptions for the method should be named as EXC_<exception_name>
Constant attributes should start with MC

Attributes (member variable)
Static attribute should start with SMV
Instance attributes should start with IMV
Attributes (member table)
Static attribute should start with SMT
Instance attributes should start with IMT
It is recommended to have a ‘CONSTRUCTOR’, ‘DESTRUCTOR’, ‘INIT’ and ‘CLOSE’ methods in the

class.
Abstract methods should be named as ABM_<method_name>.
Final methods should be named as FNM_<method_name>.
Events should be named as EV_<event_name>
Page 42 of 60
Event handler method should be named as ON_<event_name>

Interfaces should be named as ZIF_<interface_name>.
11.28 Business Objects
Business objects are identified in the Business Object Repository (BOR) by Object Type (an internal key,
technical name, for example BUS2032) and by a corresponding Object Name (a descriptive, English-like name,
for example SalesOrder). Both identifiers must be unique across all Object Types.
Business objects are often addressed in applications using the descriptive Object Name, while internally in the
BOR they are mostly identified using the Object Type. Initially, only the internal key was used, but the extensive
use of business objects has given rise to the need for addressing them using Object Names. For compatibility
reasons, both identifiers are now used.
Object Type
Format: ZBUSnnnn
Where: Z Constants for customer developed classes

BUS Constant for business objects
nnnn Uniquely identifies the business object type.
The 9000 – 9999 number range is reserved for Workflow-related objects.
Object Name
Format: Zx…x

x…x Uniquely identifies the object name. Spell out the name when possible.
11.29 Workflow Templates
Prefix the standard SAP workflow template Abbr. with a Z when using it to create a custom workflow template
abbreviation. If a new custom workflow template is created, the Abbr. should be named according to the
following standard.
Format: Zx…x

x…x Uniquely identifies the workflow template abbreviation.
Prefix the standard SAP workflow template Name with a Z. If a new template is created, the template should be
named according to the following standard:
Page 43 of 60
Format: Zx…x

x…x Uniquely identifies the workflow template.
11.30 Workflow Tasks
Prefix the standard SAP workflow task Abbr. with a Z when using it to create a custom workflow template
abbreviation. If a new custom workflow template is created, the workflow task should be named according to
the following standard.
Format: Zx…x

x…x Uniquely identifies the workflow tasks abbreviation.
Prefix the standard SAP workflow task Name with a Z. If a new task is created, the task should be named according
to the following standard:
Format: Zx…x

x…x Uniquely identifies the workflow template.
12.0Business Warehouse (BW)

This section provides naming standards and guidelines for BW objects. The document provides a brief
description of the various objects in SAP BW and the naming conventions that will be used for the VERIZON
SCT project.
When ABAP programming is required in context of SAP BW, the standards and guidelines set forth in the
VERIZON SCT ABAP Development Standards sections will be utilized. The BW objects covered in this
document are:
• InfoCube • Calculated Key Figure

• ODS Object • Variable
• InfoSource • InfoPackage
• InfoObject • InfoPackage Groups
• Query • Periodic InfoPackage Jobs
• InfoSet Query • Variants
• Roles • Events, Event Chains
• Restricted Key
Figure
Page 44 of 60
12.1 Infocube
Definition:
An InfoCube is the central data container that forms the basis for reports and analyses in BW. InfoCubes
contain two types of data: key figures and characteristics. An InfoCube is a set of relational tables that are
arranged in a star schema with a large fact table for recording transaction data at the center and several
dimension tables around the fact table. The fact table contains the key figures of the InfoCube while the
dimension tables contain the characteristics of the cube. InfoSources (see below) supply data to InfoCubes.
InfoCube Naming:
The Infocube naming convention will closely follow SAP standard naming convention in BW. The format of the
name will be as follows:
Format: Zo_enn

o Object ID
e Type of the Infocube
nn Two digit numeric in range 50 to 99
Types of Infocubes in SAP BW
Type Description
C Regular Cube
R Remote Cube
M Multi Cube
T Transaction Cube
Note: If a cube is copied from a standard cube and modified, the name should be the same apart from the first
character of ‘0’ being replaced with a ‘Z’. If the cube is created from scratch, then the two digit number should
be sequentially assigned starting with 50.
12.2 ODS Object
Definition:
An ODS Object serves to store consolidated and detailed transaction data on a document level.
It describes a consolidated data set from one or more InfoSources. This data set can be analyzed with a BEx
(Business Explorer) Query or InfoSet Query.
An ODS Object contains a key (for example, document number/item) as well as data fields that can also
contain character fields (for example, order status, customer) as key figures. The data of an ODS Object can
be updated with a delta update into Infocubes and/or other ODS Objects in the same system or across systems.
In contrast to multi-dimensional data storage with Infocubes, the data in ODS Objects is stored in transparent,
flat database tables.
ODS Object Naming:
Page 45 of 60
The ODS object naming convention will closely follow SAP standard naming convention in BW. The format of
the name will be as follows:
Format: Zo_enn

o Object ID
a Application area
e Type of the Infocube
nn Two digit numeric in range 50 to 99
Note: If an ODS Object is copied from a standard ODS object and modified, the name should be the same
apart from the first character of ‘0’ being replaced with a ‘Z’. If the ODS Object is created from scratch, then the
two digit number should be sequentially assigned starting with 50.
12.3 InfoSource
Definition:
An InfoSource is a set of logically associated information, which can contain transaction data (stored in
InfoCubes) and master data (attributes, texts, and hierarchies stored in separate tables). InfoSources describe
all the information available for a business transaction or type of business transaction (for example, cost center
accounting).
InfoSource Naming:
Custom InfoSource should always start with a Z. When a standard SAP InfoSource is copied the 0 should be
dropped from the name and be replaced by Z. A fully customized InfoSource should also begin with a Z
followed by a logical name to describe the InfoSource. The abbreviations used by SAP for various terms in the
standard InfoSource should be used where possible
Examples:
1. A copy of the 0FI_FM_1 InfoSource would be given the technical name ZFI_FM_1.
2. A custom InfoSource has to be created to report on the sales quotas. The technical name would
therefore be ZFM_BUDGET.
12.4 InfoObject
Definition:
An InfoObject is a generic term for characteristics and key figures in the Business Information Warehouse.
InfoObjects are used in InfoCubes and in the three structures that are relevant for data requests extract,
transfer, and communication structures.
InfoObject Naming:
Custom InfoObjects should always start with a Z. When a standard SAP InfoObject is copied the 0 should be
dropped from the name and be replaced by Z. A fully customized InfoObject should also begin with a Z
followed by a logical name to describe the InfoObject. The abbreviations used by SAP for various terms in the
standard InfoObjects should be used where possible.
Page 46 of 60
Examples:
1. A copy of the 0MATERIAL InfoObject would be given the technical name ZMATERIAL.
2. A custom InfoObject has to be created to report on the sales quotas. The technical name would
therefore be ZSLS_QUOTA.
12.5 Query
Definition:
A query is a data evaluation based on the selection of characteristics and key figures. Queries can be
configured according to the way you want to view and navigate through data. Users define queries to analyze
the data from an InfoCube.
Query Naming:
As queries are created specific to an InfoCube it is advisable to identify the respective cube in the technical
name for easy identification. The standard SAP naming convention is as follows:
Zcube_Qnnnn
• cube = InfoCube Name or the ODS Object Name as applicable
• nnnn = four-digit sequential number
Customized queries should use sequential numbers in the range 5000 to 9999. If the InfoCube and query are
copies of standard SAP content the sequential number should be maintained for the query.
Queries developed by the BW Team will have a technical name starting with “Y…”.
Queries developed by the Business Process Teams will have a technical name starting with “YY…”. BW
reconciliation queries will have the query technical name starting with ‘YR’.
12.6 InfoSet Query
Definition:
InfoSets are sets of data coming from one table or multiple joined tables. InfoSet Queries report on data that is
provided by InfoSets. They are especially designed to report on relational data. InfoSet Queries also support
Web reporting, RRI (Report Interface). Presentation of the results is in SAPGUI via SAP List Viewer and on the
Web.
The InfoSet Query is not designed for reporting on Infocubes (fact tables). When working with InfoSet queries
the following features are not supported: Navigation, hierarchies, delivery of Business Content, currency
conversion, variables, exception reporting and interactive graphics in the Web.
Authorization checking of characteristic values is similar to the BEx Query. However, complex selection
conditions (e.g. excluding some values) would result in time-consuming checks. Hence, simple selection
conditions (values and intervals) are supported only.
InfoSet Query Naming:
The InfoSet Query naming convention will closely follow SAP standard naming convention in BW. The format
of the name will be as follows:
Page 47 of 60
ODS_IQnnnn
Where ODS stands for ODS Object name

nnnn stands for a four digit number (5000 – 9999)
Note:
Customized InfoSets should use sequential numbers in the range 5000 to 9999. If the ODS object and InfoSet
are copies of standard SAP content the sequential number should be maintained for the InfoSet.
12.7 Roles
Definition:
A role in BW identifies a person responsible for a specific business area. Roles often correspond to job titles.
Roles are associated with tasks and include all activities that are carried out by the respective users.
Role Naming:
The format for custom roles will follow closely the SAP naming convention as follows:
ZROLE_nnnn
• nnnn = sequential number
Copies of SAP standard roles will retain the same sequential number but Z will replace the initial 0. Custom
roles will also start with Z and have sequential numbers in the range 5000 to 9999.
Examples:
1. A copy of the customer service manager role 0ROLE_0010 would have the technical name
ZROLE_0010.
2. A custom role for technical consultant would have the technical name ZROLE_5000.
12.8 Restricted Key Figures
Definition:
A restricted key figure is a key figure that is restricted to certain characteristic values. It is defined in the query
definition and limits the selected data to the values or range of values selected.
Restricted Key Figure Naming:
Restricted key figures are specific to an InfoCube and therefore will include the InfoCube technical name. The
format will be as follows:
Zcube_RKnnn
• cube = InfoCube technical name
• nnn = sequential number
Custom key figures will have a sequential number starting at 500
Examples:
Page 48 of 60
1. Custom restricted key figure for InfoCube ZFIFM_C01 would have the technical name
0FIFM_C01_RK500.
2. Restricted key figures for custom InfoCube ZIC_C50 would have the technical name ZIC_C50_RK500.
12.9 Calculated Key Figures
Definition:
A calculated key figure is a key figure that is calculated of one or more other key figures. Standard, custom,
restricted key figures and other calculated key figures can be used for the calculation.
Calculated Key Figure Naming:
Calculated key figures are specific to an InfoCube and therefore will include the InfoCube technical name. The
format will be as follows:
Zcube_CKnnn
• cube = InfoCube technical name
• nnn = sequential number
Custom key figures will have a sequential number starting at 500.
Examples:
1. Custom calculated key figure for InfoCube ZFIFM_C01 would have the technical name
0FIFM_C01_CK500.
2. Calculated key figures for custom InfoCube ZIC_C50 would have the technical name ZIC_C50_CK500.
12.10 Variables
Definition:
Variables are parameters of a query that are set in the query definition and are not filled with values
(processed) until the query is executed and inserted into a workbook. They function as a store for characteristic
values, hierarchies, hierarchy nodes, texts and formula elements and can be processed in different ways.
Variables serve for the flexible setting of queries.
Variable Naming:
Following SAP’s naming standard the format for a variable will be:
Format: Zp_nnnnn

p Type of Variable
nnnnn Meaningful name based on the InfoObject for which the variable is used (max of 5 characters)
Types of Variables:
Type Description
S Selection variable
Page 49 of 60
I Interval variable, i.e. the user enters a range

of entries
P Parameter variable (single value)
T Text variable
F Formula variable
H Hierarchy variable
N Hierarchy node variable
T, F, H and N variables describe the variable type. Whereas S, I and P variables are both of the type
characteristic and the acronym stands for the type of parameter selection. The abbreviations used by SAP for
various terms in the standard variables should be used where possible.
Note:
Variables are InfoCube independent and should therefore not contain the names of any InfoCubes.
Examples:
1. A custom variable that is used in a query to select on a range of customers would have the technical
name ZI_CUSTR.
2. A custom variable that is used to automatically replace the text of a time characteristic based on the
entry made would have the technical name ZT_FYEAR.
12.11 InfoPackage
Definition:
Data is requested for a combination of application components, an InfoSource, a Data Source and a source
system. For the data request, you create a so-called InfoPackage in the InfoSource tree of the Administrator
Workbench. Every InfoPackage and every InfoPackage group is assigned to a variant (see below).
InfoPackage Naming:
The InfoPackage name is entered in the description column.
For Transaction data loads, enter the InfoSource name in the description column and next to it mention whether
the data load full upload, initialization of delta and delta load. For Master data loads, enter additional
information such as attributes, text or hierarchy.
12.12 InfoPackage Groups
Definition:
InfoPackage Groups facilitate management of logically related InfoPackages. The execution of the
InfoPackages within the group can be scheduled through the scheduler or triggered by events in the system.
(See next section.)
InfoPackage Group Naming:
The technical names of InfoPackage Groups are system-generated. To help keep track of things, we use the
InfoPackage Group description field.
Page 50 of 60
InfoPackage Group descriptions are indicative of the logical unit of work that the grouping performs. Many of
BW’s InfoPackage Groups are groups of other InfoPackage groups, organized by functional area (e.g., FI-CO),
data type (master or transaction data) and time (daily, weekly, monthly). The general format of top-level
InfoPackage Groups is:
ff – ff [Master | Transaction] [Daily | Weekly | Monthly | <Other>]
Examples:
1. InfoPackage name for the InfoSource 0FI_AP_3 (transaction data) should be:
• If it is full upload - 0FI_AP_3 Full Update

• If it is delta initialization - 0FI_AP_3 Delta Initialization
• If it is delta upload - 0FI_AP_3 Delta Update
2. InfoPackage name for the InfoSource 0Material (master data) Attributes should be:
• If it is full upload - 0MATERIAL Attributes Full Update

• If it is delta initialization - 0MATERIAL Attributes Delta Initialization
• If it is delta upload - 0MATERIAL Attributes Delta Update
3. InfoPackage name for the InfoSource 0Material (master data) Text should be:
• If it is full upload - 0MATERIAL Text Full Update
• If it is delta initialization - 0MATERIAL Text Delta Initialization
• If it is delta upload - 0MATERIAL Text Delta Update
4. InfoPackage name for the InfoSource 0Material (master data) Hierarchy should be:
• 0MATERIAL Hierarchy Full Update
Please note that all the Hierarchy updates are full Updates.
12.13 Periodic InfoPackage Jobs
Definition:
When you schedule an InfoPackage group, you may supply a job name. This is not a requirement of BW. If
you do not supply a name, the system will generate a string of 25 randomly-generated characters that will be
appended to the end of the literal “BI_BTCH,” for example:
BI_BTCH3N73E11VR3YT6SGOA342XME5D.
Such names make it exceedingly difficult to monitor periodically-scheduled data loads. The problem is
compounded by the fact that, at the pleasure of BW, these job names can change over time. For the sake of
clarity and consistency, the VERIZON SCT BW team will supply job names in accordance with the convention
stated below. Note: This convention applies only to periodic, scheduled data loads. There is little to be gained
by using this convention with ad hoc, “one shot” data loads.
Job Naming:
Page 51 of 60
InfoPackage job names start with BI_BTCH—we have no control over this. The remaining 25 characters are
user-supplied. The format is given below:
Format:
BI_BTCH_ZBWa_[InfoPackage Name] | [Periodicity] | [MD or TX]_999
Where “a” is the application area (e.g., FI, PR, HR, etc.); The InfoPackage name should include as much of the
InfoPackage name as possible. (Note the underscore between the functional area and the start of the
InfoPackage name.) The InfoPackage name is followed by the job periodicity, and an indicator of whether the
load is master data, transaction data, or a hierarchy (unless the nature of the data is clear from the name of the
InfoPackage). The last three characters are a sequence number (which we may or may not retain over time).
If any important feature of the InfoPackage (or InfoPackage Group) is changed before the job is started, add 1
to the sequence number. This will provide an audit trail on the daily job logs.
Examples:
Daily run of InfoPackage group “FI-PU-FM Tranx Data”

BI_BTCH _ZBWFI_FI-PU-FM_TX____001
Weekly run of InfoPackage group “FI-IO Master Data - Weekly”
BI_BTCH _ZBWFI_FI-IO_MD_WEEK__001
Weekly run of InfoPackage group “FI-IO Master Data - Weekly”
BI_BTCH _ZBWFI_0FI-FM_IO_WEEK_001
Note: In this example, we didn’t have room to include “MD,” but we still get the point across.
12.14 Variants
Definition:
When you create an InfoPackage or InfoPackage group, you must supply a variant name. Variants allow for
subsequent processing for background jobs through triggering events. Variants are created through the AWB
by selecting Tools  Apply Attribute/Hierarchy Change Run.
Variant Naming:
Variant names start with ZBW, followed by the application area and then the periodicity of the InfoPackage
group that listens for events using the variant.
Format:
ZBWa_DAY | MONTH | WEEK
Examples:
The variant for the FI daily attribute hierarchy load is:
ZBWFI_IO_DAY.
12.15 Events
Definition:
Page 52 of 60
When you create an InfoPackage or InfoPackage group, you must supply the name of the event for which the
variant associated with the InfoPackage is listening.
An event is a signal to background job controlling subsystem that a particular situation has arisen in the system.
Events have meaning only in the background processing system and can be used only to start background
jobs.
Events are created using transaction SM62. Events can be triggered through the termination (successful or
abnormal) of any job in the system.
Event Naming:
Event names start with ZBW, followed by the application area (a), whether the data is master data or attribute
hierarchy maintenance, followed by the periodicity of the job.
Format:
ZBWa_[MD | ATTR_HIER][DAILY | MONTH | WEEK]
ZBWFI_IO MD_DAILY
ZBWFI_ATTR_HEIR_CO_IO DAILY
An event chain is a series of several events that have been successfully completed independently of each
other. If all the events contained in a chain been successfully executed, then a successful event is triggered.
Otherwise, an unsuccessful event is triggered.
12.16 BW Query and Workbook Properties
Number format
- Sign Display “(X)”
- Suppress zeroes checked
- Result position: Bottom/right
Display options
- Adjust formatting after refreshing
- Suppress repeated key values
BW Query Standard Characteristic Properties

- Result display: Suppress results row Conditional
BW Workbook Standards
All workbooks should be imbedded into the standard workbook template. The template contains header and
footer information to standardize printing format.
The template name is “Blank Template” and is located in the folder ‘Statewide Reporting’ in the BW
Development environment.
BW Workbook Standard Properties
Display
Adjust format after data refresh checked
Suppress repeated key values checked
Display filter cells for structures checked
Interaction
Page 53 of 60
Enable interactive functions checked

Refresh query when opening workbook checked
Column width
Do not adjust column width checked
BW Workbook Formatting Standards
All BW workbooks created should use the standard template located in folder “BW Testing\Blank Template”
(BW Development environment) to present a consistent look to workbook reports.
Additional text elements should be displayed to put the workbook report in context and provide useful
information to others if the report is printed. The additional text elements should be located in column D (with
the template embedding), starting in row 3 (with the template embedding), even with the top of the navigation
block. The additional elements to be included are:
• Relevance of the data (so a user knows when BW data was last updated).
• Last refreshed (so a user knows if they are viewing current data).
• Variables – text element only (so a user knows the selection parameters for the report).
• Filters (so a user knows the “data restrictions” applied to the report).
13.0Portals
This section provides a brief description of the various components in SAP Portal and the naming conventions
that will be used for the VERIZON SCT project.
Delivered/imported objects such as roles and worksets are located in a specific namespace with a prefix
namespace of com.sapportals*, com.sapportals.pct*, com.sap* and com.sap.pct*. These objects may not be
modified. If the delivered objects are modified and a new version of the object is imported all changes or
adjustments made in the customized version will be lost. If changes or adjustments need to be made to these
objects the “Delta Link” principle should be used. To find out how to use this principle, refer to the SAP Portals
Administration Guide.
13.1 iViews
Definition:
Integrated Views (iViews) are applications that enable the portal to access available information resources. The
iViews return current information from such sources as relational databases, ERP systems, CRM systems,
enterprise applications, collaboration tools, intranets, the World Wide Web, and email exchange systems. The
information retrieved by iViews is displayed on the Pages of the Portal Content Area.
iView Naming:
The iView requires an iView Name and an iView ID. The iView ID is a unique name identifying the iView and
may not include special characters. This ID is the technical name for the iView. The same iView ID cannot be
assigned to more than one iView in the Portal content repository. If a variation of the iView is required the iView
must be duplicated under a different iView ID becoming a new and independent entity. Standard SAP iViews
received from iViewStudio will retain their ID’s and Names. If changes are required to a standard SAP iView
Page 54 of 60
create a copy of the iView renaming the name prefix of the iView ID (technical name) from com.sapportals to
com.att. For custom iViews the iView ID’s name prefix should also be com.att with a suffix of the technical
name providing a meaningful description of the iView.
The iView Name of duplicated or customized SAP standard iViews may be the same. The iView Name is the
title of the iView that appears in the title bar of the portal as well as in any form, dialog box or window that
displays a list of iViews. The iView Name contains alphanumeric characters.
Example:
The Days Overdue Analysis iView delivered in the Business Package Customer Credit Management from
iViewStudio requires changes. The standard iView com.sapportals.pct.crm.days_overdue_analysis will
be duplicated and the technical name will be renamed to com.att.pct.crm.days_overdue_analysis. The
changes will be made to com.att.pct.crm.days_overdue_analysis. The iView Name will remain Days
Overdue Analysis
13.2 Channels
Definition:
Channels are the avenues in the SAP Enterprise Portal through which iViews are organized into meaningful
categories of subjects or interests. Channels also are used to assign the content a user role has access to. An
iView must be assigned to a Channel.
Channel Naming:
The Channel Name is the value that will appear in the Channel List of the iView Editor interface and the
Channel Assignment interface. The name provided in this field should be a short description of the subject or
interest category for the iViews.
The Channel Description allows for the entry of a long description of the Channel. When the Channel
information has been saved, the Channel is created and an ID is automatically assigned in the system
database.
Examples:
• A Channel that contains iViews relating to Credit Management would have the Channel Name Credit
Management iViews
• A Channel containing iViews relating to VERIZON SCT news updates would have the Channel Name
VERIZON SCT News
13.3 Roles
Definition:
A role is one of the central concepts of the SAP Enterprise Portal. It is a collection of tasks, services and
information for a group of users. The role defines the contents the portal user may access and the actions he or
she may perform. The role also defines the visualization of the contents and the navigation structure within
SAP’s Enterprise Portal. A role contains varied information and combines everything the user will see on the
Portal.
Role Naming:
Page 55 of 60
The Role object name is a short description describing the role of the user or group of users who have been
assign to the role. Also required to be entered is a Role ID which is the technical name of the role stored in the
Portal Content Directory. The SAP Roles will be exported from the SAP R/3 system and imported to the Portal
Roles.
13.4 Pages
Definition:
Pages within SAP’s Enterprise Portal provide the means to display the iViews and define the layout of the
iViews in the content area of the portal.
Page Naming:
The Page requires a Page Name and a Page ID. The Page ID is a unique name that may include up to 40
characters including alphanumeric characters, underscores(_), dashes (-), dots (.) exclamation points (!),
tildes(~) and parentheses. The Page ID may not include special characters or spaces. This ID is the technical
name for the page. The Page Name is the title of the page and appears in the various user interfaces of the
Portal. The Page Name may contain any character including spaces with the exception of apostrophes and
quotation marks and may include up to 40 characters. The Page ID and Page Name will contain the same
value and will provide a meaningful description describing the content of the iViews on the Page. The Page ID
will also include underscores (_) to separate words.
Example:
The Page Name for a page that contains iViews relating to Credit Management Reports would be Credit
Management Reports and the Page ID would be Credit_Management_Reports
13.5 Workset
Definition:
Worksets allow services and pages to be grouped into folder hierarchies, like for roles. In contrast to roles,
worksets are generic, re-usable structures or modules that can be added to roles. A workset alone cannot define
a portal from the user point of view. A workset that is to be added to a Portal therefore is always part of a role.
By setting up a role or a number of roles from multiple worksets, the appearance of the Enterprise Portal is
defined for the users.
Workset Naming:
The Workset object name is a short description describing the services and pages included in the workset. Also
required to be entered is a Workset ID which is the technical name of the workset stored in the Portal Content
Directory. The value of the ID may not include a period (.). The ID will contain the same value as the object
name and will be prefixed by VERIZON SCT to identify the Workset as a VERIZON SCT workset in the Portal
Content Directory. The Workset ID will also include underscores (_) to separate words.
Example:
The Workset object name of the workset created to group the Accounts Receivable Clerk’s services and
pages would be Acct Recv Clerk and the Workset ID would be VERIZON SCT _Acct_Recv_Clerk
13.6 External Services
Definition:
Page 56 of 60
An External Service is a type of iView that cannot be assigned or directly linked to a Portal page. External
Services are assigned to Portal users through role, directory or workset assignment and are usually displayed in
the Portal as full-page iViews.
External Services Naming:
External Services requires a Name and an ID to be entered. The External Service ID is the technical name of
the External Service. The External Service Name provides a short description of the content of the External
Service. The External Service Name will be a meaningful description of the contents of what is being
displayed in the portal view. The External Service ID will follow the same standards as all iViews and will be the
same value as the Name with underscores separating the words.
Example:
For an External Service displaying an analysis of open items sorted by due date for net payment the
External Service would be Due Date Analysis. The technical id would be Due_Date_Analysis
13.7 Folders
Definition:
Roles and worksets are created by setting up folder hierarchies. Folders are also needed to define entry points
within top-level navigation.
In contrast to a workset, a folder in a role is one that only belongs to this role and is set up within the role. A
workset is a separate Portal Content Directory object in the form of a re-usable role component that can be
added to one or more roles.
Folder Naming:
Folders are created in Roles and Worksets when the Role or Workset is created. The folder name will describe
the content of the folder..
Example:
If the content of the folder is Accounts Receivable Clerk transactions, the name of the folder might be Acct
Recv Clerk
14.0Logical Paths and Files

All programs accessing files directly will be required to use logical filenames as part of their coding standard.
During runtime the system and client used for execution replaces <SYSID> with system id and <MANDT> with
client. As an example a program being run on system D10 client 088 would resolve to ..../D10/088/data.
The following code sample generates a physical filename using the SAP delivered function module
FILE_GET_NAME. The parameter selection screen lists the full path as non-modifiable and the filename as
modifiable. The following is sample code to produce the separate path and filename, with the intended display
only attribute on the path field.
*----------------------------------------------------------------------*
* SELECTION SCREEN LAYOUT *
*----------------------------------------------------------------------*
PARAMETERS: FILEPATH LIKE RLGRAP-FILENAME,
Page 57 of 60
FILENAME LIKE RLGRAP-FILENAME OBLIGATORY DEFAULT

'testfile'.
*----------------------------------------------------------------------*
* VARIABLES *
*----------------------------------------------------------------------*
DATA: PHYSNAME LIKE RLGRAP-FILENAME,
PATHLENG TYPE I,
NAMELENG TYPE I,
PHYSLENG TYPE I,
TEXT1(80) VALUE 'This is text1'.
*---------------------------------------------------------------*
* AT SELECTION SCREEN OUTPUT *
*---------------------------------------------------------------*
AT SELECTION-SCREEN OUTPUT.
PERFORM GET_FILENAME USING FILENAME PHYSNAME.
NAMELENG = STRLEN( FILENAME ).
PHYSLENG = STRLEN( PHYSNAME ).
PATHLENG = PHYSLENG - NAMELENG.
FILEPATH = PHYSNAME(PATHLENG).
LOOP AT SCREEN.
IF SCREEN-NAME EQ 'FILEPATH'.
SCREEN-INPUT = '0'.
MODIFY SCREEN.
ENDIF.
ENDLOOP.
*----------------------------------------------------------------------*
* START-OF-SELECTION *
*----------------------------------------------------------------------*
START-OF-SELECTION.
CONCATENATE FILEPATH FILENAME INTO PHYSNAME.
*&---------------------------------------------------------------------*
*& Form GET_FILENAME
*&---------------------------------------------------------------------*
* Obtains the physical file location using a function call.
*----------------------------------------------------------------------*
* -->P_FILENAME file name
* -->P_PHYSNAME full physical path
*----------------------------------------------------------------------*
form get_filename using p_filename
p_physname.
call function 'FILE_GET_NAME'

exporting
logical_filename = 'ZEX_STANDARD_FILENAME'
parameter_1 = p_filename
importing
file_name = p_physname
exceptions
file_not_found =1
others = 2.
Page 58 of 60
if sy-subrc <> 0.
* e001(z1): Exception & occurred in function &.
message e001(z1) with sy-subrc 'FILE_GET_NAME'.
endif.
endform. " GET_FILENAME
15.0Standard Header Routine

The function module REPORT_HEADER subroutine is to be used to create standard heading lines for all
customized ABAP/4 reports. The following steps indicate the process to follow to make use of this subroutine.
1. In the “attributes” section of your ABAP program, the “Title” should be the title of the report your ABAP/4
program is creating.
2. Code your REPORT statement with the NO STANDARD PAGE HEADING option:
REPORT ZEMR00lA NO STANDARD PAGE HEADING

LINE-SIZE 132
LINE-COUNT 65
MESSAGE-ID ZZ.
3. Additional documentation for using this function module can be found online in SAP.
16.0 Change and Transport System

16.1 Overview
The Transport Management System (TMS) will manage changes or additions to new and existing Data
Dictionary objects, ABAP/4 programs, screens, CUA definitions and documentation.
TMS ensures that formal development work is registered and documented. The change system will help
prevent parallel, uncoordinated changes to an object. For existing objects, the system ensures that only a
single original copy of each object exists. Changes may normally be made only to the original copy. The
change system also saves all corrections to ABAP/4 programs and Data Dictionary objects.
The transport system is used for moving objects from a development system to a production system. The
transport system can perform several kinds of operations: overwrite components and data in a target system,
delete and replace such objects, insert objects without overwriting existing ones, delete objects and also protect
objects from being overwritten or deleted.
Client dependent objects should be in a separate request from client independent objects such as programs
and tables. This will make it possible to distribute the client dependent objects to multiple clients.
Refer to Deliverable Transport Procedures for the details regarding VERIZON SCT transport procedures.
16.2 Creating a correction in the Development system
Page 59 of 60
When creating a correction in the Development system, place the business area, application area, type of
program and object id at the start of the description (e.g. PF_I999_) followed by the unique reference number
assigned to the task being worked. It appears that when the list of correction numbers is generated, it cannot
be easily sorted. This will make it easier to determine which change requests belong to each team and what
they are for.
For example: PF_I999-0116 Price Book Interface for ..........
16.3 Promotion of ETL jobs to QA or Production
The ETL Transport Form is used to request that an ETL job or sequence (or a group of jobs and/or batches) be
exported from one of the ETL environments and imported to the other. A form must be filled out completely
and submitted to an ETL Administrator to complete your request whenever a change affects the ETL QA or
Production environments. ETL developers will not have permissions to promote/demote ETL jobs, batches or
scripts from or to the QA and/or Production ETL environments. When the ETL job (or other ETL object) is
ready to be moved to the QA or Production projects, you must fill out the following “ETL Transport Request”
Page 60 of 60

Ibm Development Standards and Guidelines - Draft 2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ibm Development Standards and Guidelines - Draft 2

Uploaded by

Copyright:

Available Formats

Supply Chain Transformation

Development Standards and Guidelines

2.0 Programming Standards Definitions

Shall/Will An imperative. The statement will apply in every case.

Should A very strong preference. The statement will be

Assumed By default the statement will be adhered to.

Recommended The adherence of the statement is preferred.

Standard Reporting Involves selecting, editing, and sorting data; processing

Interactive Reporting Select report data using line selection, PFKEYS,

Dialog Transactions Covers the area of calling Dynpros, sending messages,

In addition, Workflow should adhere to the following policies and guidelines:

Each new ABAP/4 program shall contain both:

• External Key Elements

6.0External ABAP/4 Program Elements

6.1 Selecting a Program Name

6.2 Text Elements

• B - Business Information Warehouse

• Z1MM - SAP Materials Management

• Z1BW - SAP BW Components

7.0Internal ABAP/4 Program Elements

The following Internal Program elements will be documented:

7.1 Documentation Box

• PROGRAM NAME - Short Description of program

- All subsequent program amendments must be documented to provide

7.2 Declarative Elements

The following declarative elements are described below:

DOCDAT LIKE SY-DATUM,

Individual Work Fields

Internal Table Work Fields (include structure; multi-line exception)

Internal Table Work Fields (Single & Multilevel)

7.3 Event Elements

The following event elements are documented below:

GET / GET LATE and other DB access related statements

7.4 Control Events

The IF.... ELSEIF statement will not be used.

7.5 Operation Events

Operation events are those program events indicated by an operational action.

MOVE-CORRESPONDING / ADD-CORRESPONDING ETC.

8.1 Internal Programming comments

MOVE: LFAl-LIFNR TO LFB1-LIFNR, "example of in-line comment

* WRITE:/TEXT-001, TEXT-002. "99999

WRITE:/TEXT-001, TEXT-003. "99999

8.2 External Programming comments

9.0ABAP/4 Coding Techniques

9.1 Data Selection

9.2 Program Identifiers, Constants and Variables

9.4 PFKEYS Usage

The SAP standard PFKEYS are listed below:

PFl Help PF2 Choose PF3 Back

9.5 Screen Painter Standards

• Dynpro names will always be defined to the data dictionary.

MODULE PROCESS_PFKEYS_9000 INPUT.

10.2 Code Reviews

• Experienced ABAP developer, senior level

11.0SAP Naming Conventions

x any alphanumeric character

11.1 Program Naming

11.1.1 Local Private Programs

Where: Y Constant for local private program

x…x any alphanumeric characters

11.1.2 Production Programs

Where: Z Constant for customer developed objects

11.2 Data Element

Where: Z Constant for customer developed objects