ABAP Development Standards

Program Everest
SAP Development Standards
1 Introduction Use of Standards............................................................7

1.1
1.2
1.3
1.4
1.4.1
1.4.2
Introduction..........................................................................................................7
Scope....................................................................................................................7
Applicability........................................................................................................7
This Document.....................................................................................................8
Hypertext Links...............................................................................................8
Naming Format in this Document....................................................................8
2 How to Change SAP R/3 Development Standard.................................9

2.1
2.2
Purpose.................................................................................................................9
Uncontrolled Copies, Standard Users Responsibility.........................................9
3 Naming/Design Standards....................................................................10
3.1
Purpose...............................................................................................................10
3.2
Application ID...................................................................................................10
3.3
Program Type ID................................................................................................10
3.4
Naming Standard Summary Table.....................................................................11
3.4.1 ABAP Program Structure...............................................................................12
3.4.2 SAP Dictionary Objects.................................................................................12
3.4.3 Form Specific Standards................................................................................13
3.4.4 ALE/EDI Specific Standards.........................................................................14
3.4.5 Project Enhancement Specific Standards.......................................................14
3.4.6 Workflow Specific Naming Conventions:.....................................................14
3.5
ABAP Program..................................................................................................17
3.5.1 ABAP Report Variant.....................................................................................17
3.6
Development Classes (format = ZDEV.)...........................................................17
3.7
Functions............................................................................................................17
3.7.1 Function Groups (26 Characters)...................................................................17
3.7.2 Functions (Maximum of 30 Characters)........................................................18
3.8
JOBS..................................................................................................................18
3.8.1 Batch Job Names............................................................................................18
3.8.2 Batch Input Sessions (BDC)..........................................................................19
3.9
MESSAGES.......................................................................................................19
3.9.1 Message Class................................................................................................19
3.10 ON-LINE PROGRAMMING............................................................................19
3.10.1
ABAP Module Pools..................................................................................20
3.10.2
ABAP Module Pool Components..............................................................20
3.10.3
Dynpros (Screens)......................................................................................21
3.10.4
GUI Status (GUI definition for screen, i.e. function codes, etc.)..............21
3.10.5
GUI Title (screen title)...............................................................................21
3.11 Menus.................................................................................................................21
3.11.1
Function Keys............................................................................................21
3.11.2
Titlebar.......................................................................................................21
3.12 Projects & Enhancements..................................................................................21
3.12.1
Projects.......................................................................................................21
343416319.doc

3.12.2
3.12.3
3.12.4
Enhancements............................................................................................22
Project Area................................................................................................22
Project & Enhancement Process................................................................23
4 Dictionary Standards............................................................................24
4.1
Purpose...............................................................................................................24
4.2
Transparent Tables, Pool Tables (16 Characters)...............................................24
4.2.1 Understanding the Delivery Class.................................................................25
4.2.2 ATAB/Control Tables (5 characters)..............................................................25
4.2.3 Cluster Tables.................................................................................................25
4.2.4 Structure.........................................................................................................26
4.2.5 View...............................................................................................................26
Example: ZMVPRCHASE.........................................................................................26
4.2.6 Table Maintenance (Authorization Group)....................................................27
4.2.7 Table Maintenance (Function Group)............................................................27
4.3
Table Field Name...............................................................................................28
4.4
Data Element (Maximum of 16 Characters)......................................................28
4.4.1 Data Element Medium Field Label................................................................28
4.4.2 Data Element Short Field Label.....................................................................28
4.4.3 Data Element Header.....................................................................................28
4.5
Domain Name (Maximum of 30 Characters)....................................................29
4.6
Search Helps......................................................................................................29
4.6.1 Data Classifiers..............................................................................................30
4.7
Data Elements & Domain Re-use Guidelines....................................................30
4.7.1 Overview........................................................................................................30
4.7.2 Data Elements................................................................................................30
4.7.3 Domains.........................................................................................................31
5 Data File Naming Standards................................................................32

5.1
Purpose...............................................................................................................32
5.2
UNIX Data Files................................................................................................32
5.2.1 UNIX Data Directories Structure, for SAP Development.............................32
5.3
UNIX Application Directories for SAP Development.......................................34
5.3.1 UNIX Applications Directory Structure:.......................................................34
5.3.2 Upper and Lowercase Parameters with UNIX Physical Filenames...............34
6 ABAP Message/Error Handling Standards.........................................36

6.1
6.2
6.3
6.4
6.4.1
6.4.2
6.4.3
6.4.4
Purpose...............................................................................................................36
Message Handling..............................................................................................36
SAP Message Types (format = a).......................................................................37
Return Codes......................................................................................................38
ABAP System Field SY-SUBRC...................................................................38
Exception Codes............................................................................................38
Closing the Spool...........................................................................................38
CATCH Keyword (New in 4.6).....................................................................39
7 ABAP Improve Efficiency Standards..................................................40

7.1
7.2
7.3
Purpose...............................................................................................................40
Use of Internal Tables........................................................................................40
ABAP run-time Analysis...................................................................................41
343416319.doc

7.4
7.5
7.6
Pretty Printer......................................................................................................41
Following Is Not Allowed..................................................................................41
the COLLECT command...................................................................................41
8 Standard Include Programs..................................................................42

8.1
8.2
Purpose...............................................................................................................42
Program to Print Header Information in a Report - TBD..................................42
9 ABAP Program Structure/Organization.............................................43

9.1
9.2
9.3
9.3.1
9.3.2
9.3.3
9.4
10
10.1
10.2
11
Purpose Patterns for header............................................................................43

The Standard Structure for ABAP Report Code................................................43
Header Documentation......................................................................................44
Comment Box................................................................................................44
Goto Program Doc.....................................................................................45
Declarative Elements.....................................................................................45
Currency and Quantity Rules.............................................................................47
Application Development Process for Development Objects........48

Purpose...............................................................................................................48
Overview............................................................................................................48
SAP Conversion and Interface Tool Selection Guidelines.............49
11.1 Purpose...............................................................................................................49
11.2 Overview............................................................................................................49
11.3 Terms used.........................................................................................................49
11.4 Approach............................................................................................................49
11.4.1
Discovery/Validation..................................................................................49
11.4.2
Consolidation.............................................................................................49
11.4.3
Reconciliation............................................................................................49
11.4.4
Design........................................................................................................49
11.4.5
Execution...................................................................................................50
11.5 Legacy Extract...................................................................................................50
11.5.1
DB2............................................................................................................50
11.5.2
Flat Files.....................................................................................................50
11.5.3
Microsoft ACCESS Data Bases.................................................................50
11.5.4
Microsoft EXCEL Spreadsheets................................................................50
11.6 SAP Inbound/Outbound Interface......................................................................50
12
SAP Conversion and Interface Method Selection Guidelines.......51
12.1 Purpose...............................................................................................................51
12.2 Overview............................................................................................................51
12.3 Terms used.........................................................................................................51
12.3.1
ALE (Application Link Enabling.)............................................................51
12.3.2
BAPI (Business Application Programming Interface)...............................51
12.3.3
BDC (Batch Input Session)........................................................................52
12.3.4
Call Transaction (Synchronous or asynchronous execution).....................52
12.3.5
CATT (format = Z_CATT_xxxxxx_yy).....................................................52
12.3.6
Data Transfer Program...............................................................................52
12.3.7
IDoc (Intermediate Document)..................................................................52
12.4 Interface Guidelines...........................................................................................52
343416319.doc

12.5
13
13.1
13.2
13.3
13.4
13.5
13.6
14
Conversion Guidelines.......................................................................................54
Forms Standards...............................................................................55
Purpose...............................................................................................................55
Three Ways to Create SAP Forms......................................................................55
Standard Text-ID (format = Zxxx).....................................................................55
Standard Text Name (format = Z_xxxxxx)....................................................55
Style (format = Z_xxxxxx)................................................................................55
SAPScript Layout Set Naming (Maximum 16 Characters)...............................56
Reports Standards.............................................................................57
14.1 Purpose...............................................................................................................57
14.2 Four Ways to Create SAP Reports.....................................................................57
14.3 SAP-Supplied Standard Default Formats (TRX=SPAD)...................................57
14.3.1
Background................................................................................................57
14.3.2
Listing SAP Standard Default Formats Using TRX=SPAD......................58
14.3.3
Standard LINE-SIZE and LINE-COUNT.................................................58
14.4 Standards for New ABAP Reports.....................................................................58
14.5 ABAP to Print All Standard Report Titles.........................................................59
14.5.1
How This ABAP Works.............................................................................59
14.5.2
Standards for Report Titles........................................................................60
14.5.3
Example of ABAP Using Standard Report Header...................................60
14.6 Open SQL versus Native SQL...........................................................................60
15
IDocs..................................................................................................61
15.1 Purpose...............................................................................................................61
15.2 IDocs (format= Zxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)..................................61
15.3 IDoc Segments (format=Z1xxxxxx)..................................................................61
15.4 Process Codes (format=Zxxx)...........................................................................61
15.5 Partner Profiles Naming.....................................................................................61
15.6 Port Naming (File Port Type).............................................................................62
15.7 Parameters for Outbound Files (used with File Port Type)...............................62
15.7.1
Directory....................................................................................................62
15.7.2
Function Module........................................................................................62
15.8 Parameters for Command Files (used with File Port Type)...............................62
15.8.1
Automatic Start Possible............................................................................62
15.8.2
Logical Destination....................................................................................62
15.8.3
Directory....................................................................................................62
15.8.4
Shell Script.................................................................................................63
15.9 Parameters for Inbound Files (used with File Port Type)..................................63
15.10
Parameters for Status Files (used with File Port Type).................................63
15.11
Port Naming (Transactional RFC Port Type).................................................63
15.11.1 Port.............................................................................................................63
15.11.2 Port Description.........................................................................................63
15.11.3 Destination (RFC Destination)..................................................................63
15.12
Message Type.................................................................................................63
16
16.1
16.2
How to Handle Special Data Types in ABAP..................................64

Purpose...............................................................................................................64
User Defaults.....................................................................................................64
343416319.doc

16.3 Dates Defaults by country...............................................................................64
16.3.1
Inbound......................................................................................................64
16.3.2
Outbound....................................................................................................65
16.4 Amount/Currencies (the number of decimals issue)..........................................65
16.4.1
Inbound......................................................................................................65
16.4.2
Outbound....................................................................................................65
16.5 Amount/Currencies (the decimal place/thousands separator issue)...................65
16.5.1
Inbound......................................................................................................65
16.5.2
Outbound....................................................................................................65
16.6 Quantities (the decimal place/thousands separator issue)..................................66
16.6.1
Outbound....................................................................................................66
17
Authorization Checks Work In Process.......................................67
17.1 Purpose...............................................................................................................67
17.2 Authorization Checks.........................................................................................67
17.2.1
Authorization Checks: Table TSTC..........................................................67
18
18.1
19
19.1
19.2
20
SAP Requests Naming Convention..................................................68

Purpose...............................................................................................................68
Frequently Used Transaction Codes................................................70

Purpose...............................................................................................................70
Frequently Used Transaction Code Table..........................................................70
Index...................................................................................................72
343416319.doc
1 Introduction Use of Standards
1.1 Introduction
Development standards and consistent conventions will contribute significant time and resource savings for both
the initial construction and long term maintenance of the Federal Mogul SAP system. Addressing these
standards prior to construction and adhering to them during construction is especially helpful when addressing
the following:
Migration into a production environment

Facilitating knowledge transfer for future SAP resources
Long-term maintenance/expansion of custom development
Future upgrades
Small amounts of effort now will prove beneficial for the overall project and SAP system. The objective of this
overview is to define guidelines for SAP developers.
This document is based on:
SAPs Naming Conventions for Development Objects
Previous PwC SAP project implementation standards
This document will further evolve as batch scheduling, mapping and middleware tools are more solidly
integrated into the Federal Mogul development environment, and as new requirements/standards arise.
1.2 Scope
This standards document describes the development standards within the SAP R/3 environment plus file
naming convention for files directly imported into or exported from SAP. The level of detail is described so that
an SAP R/3 specialist will understand how to work with SAP at Federal Mogul.
1.3 Applicability
Use of these standards are to be followed by all ERP SAP developers in the R/3 system working on the Federal
Mogul project.

1.4
This Document
1.4.1 Hypertext Links
Throughout the document, references to other parts of the document have been hyperlinked to the section that
they refer to. If you read this manual in an electronic format, then you may point and click the hypertext to see
the referenced section. Hyperlinks appear in a blue colored text. To return from a hyperlink reference use the
Go pull down box (on the Web Toolbar of MS Word) and select Back.
1.4.2 Naming Format in this Document
The naming convention format used within this document includes the use of UPPERCASE and lowercase
characters. UPPERCASE characters are used to describe literal constants. Using lowercase characters is the
convention for variable portions of a naming convention format, and the variable portions are usually explained
further following the (Format = lowercase). Since underscores and periods have no uppercase and lowercase
representation, they are always literal constants (therefore must be used as described by the format or
qualifying statement).
Example:
343416319.doc
(Format = ZUPPER_programmer)
programmer = programmer name up to nn characters

2 How to Change SAP R/3 Development Standard
2.1
Purpose
The purpose of this chapter is define the process for making a change to the Federal Mogul SAP R/3
Development Standard.
2.2
Uncontrolled Copies, Standard Users Responsibility

Printed copies of this standard are considered Uncontrolled Copies. Printed copies of this standard
should be marked with the words UNCONTROLLED COPY Verify Current issue before use. Users
of this standard are responsible to ensure that only the current standard is used. Users are also
responsible to ensure that old revisions of this standard are thrown away in the appropriate recycle bin, or
clearly marked OBSOLETE.
343416319.doc

3 Naming/Design Standards
3.1
Purpose
This chapter highlights the naming standards that should be followed when writing ABAP programs.
Following these standards will improve readability and maintainability of the code.
3.2
Application ID
For Federal Mogul purposes, the Application ID will be a 1-character field, which acts as a general
functional identifier for each object developed. This application ID corresponds to SAPs predefined
application ID set. The application ID will be used in definitions of other objects, which will be defined
below.
ID
A
B
C
D
E
G
H
I
L
M
N
P
Q
R
S
T
U
V
W
Z
Description
Asset Management
Project Systems
Controlling/Labor Overhead
CRM
EDI
General Ledger/Reporting/Tax
Human Resources
Plant Maintenance
Inventory Management
Materials Management
Accounts Receivable
Production Planning
Accounts Payable
Requisition To Check
Basis
Treasury
Procurement
Sales
Warehouse Management
Cross Application Use
The list of Application IDs may be further refined for specific project requirements. If it appears that a
specific development object cannot be appropriately classified by the current list of Application IDs, a new
Application ID should be requested from the applications development team lead.
3.3
Program Type ID
Program Type ID
A
B
C
D
E
G
343416319.doc
Description
CRM Class/Interface
Business Server Pages
Data Conversion
Data Dictionary Maintenance
EDI
General Development
10

I
O
M
N
R
S
U
X
3.4
Inbound Interfaces
Outbound Interfaces
System Maintenance
Include program
Report
SAPscript
User Exit/Enhancement
Temporary, Demo or Test programs
Naming Standard Summary Table

Note: The naming conventions below utilize the x as free text for each type of object. The number of
x in each object, does not represent the actual length of the field within SAP. Each object may utilize
the full length of the name with in the system. For instance, ABAP program can be up to 36 characters
in length, and only the first 3 characters use specific naming conventions, positions 4 36 can be free
text.
Section
3.5
SAP Object Type
Length
ABAP Programs
30
ABAP Report
Variants
Development Class
14
3.7.1
Function Groups
3.7.2
Function Modules
30
3.8.1
Batch Job Requests
32
3.8.2
Batch Input
Sessions (BDC
Sessions)
Messages classes
12
ABAP Module Pool

Components
3.5.1
3.6
3.9.1
3.10.2
343416319.doc
20
Naming Convention
Zabxxxxxx
a
=
Application ID (section 3.2)
b
=
Program Type ID (section 3.3)
x
=
Open (Description)
xxxxxxxxxxxxxxxxxxxxxx
x
=
Open
Mulitple Development Classes will be utilized. See
section 3.6 for naming convention
Zaxxxxxxxx
a
=
Application ID
x
=
Open
Z_a_xxxxxxxxxxxxxxxxxxxxxxxxxx
a
=
Application ID
x
=
Open (separate words with
underscores)
Z_b_a_xxxxxxxxxxxxxxxxxxxxxxxxxx
b
=
Frequency (O,Y,Q,M,W,D,N,H,E)
a
=
Application ID
x
=
Open
NOTE: Batch job requests will be further defined when the
batch scheduling architecture is designed.
xxxxxxxxxxx
x = open text
Zaxxxxxxxxxxxxxxxxxx
a
=
Application ID
x
=
Description (18 Characters)
MZannTOP
= Top Include data declarations
MzannOxx
= PBO modules
MzannIxx
= PAI modules
MzannFxx
= Subroutines
11

Section
SAP Object Type
Length
Naming Convention
MzannHxx
MzannVxx
3.10.3
Dynpros (Screens)
= Process on Help Routines

= Process on Value Routines
Zann
=
Main Module Pool name above
x
=
Open
SAP Attached (Attached to SAP-supplied programs
in increments of 1
Custom Developed Attached
(Attached to custom-developed programs in increments of
10
3.11.2
Function Key Codes
3.11.3
Titlebars
9.3.3
Program Variables,
Select-Options and
Parameters
CATT Scripts
12.3.5
30/8
16
Pop-up screens
(e.g. 0101)
xxxx
x
=
xxx
x
=
See section 9.3.3
Parent screen # plus 1

Open
Open
Z_CATT_xxxxxx_yy
xxxxxx
=
yy
the development object identifier

(required)
the sequence number of the script
(use only if there are multiple
scripts per object)
3.4.1 ABAP Program Structure

Section
9.3.3
SAP Object Type

Program Variables,
Select-Options and
Parameters
Lengt
h
30/8
Naming Convention
See section 9.3.3
3.4.2 SAP Dictionary Objects

Section
4.2
4.2.2
SAP Object Type
Naming Convention
Length
Tables
16
ATAB / Control
Tables
Zatxxxxxxxxxxxxxx
a
=
Application ID
T
= Table
x
=
Open
T9axx
a
=
Application ID
x
4.2.4
343416319.doc
Structures
16
ZaSxxxxxxxxxxxxx
a
=
S
=
x
=
Open (limit to two for Control

tables)
Application ID
structure
Open
12

4.2.5
4.3
Views
16
Table Fields
12
10
4.4
Data Elements
16
4.5
Domain
16
4.6
Search Help
ZaVxxxxxxxxxxxxx
a
=
Application ID
V
=
view
x
=
Open
(Attached to SAP-delivered tables)
ZZxxxxxxxxxx
x
=
Open
(Attached to custom tables)
Zxxxxxxxxxx
x
=
Open
Zxxxxxxxxxxxxxxx
X
=
Open
Zxxxxxxxxxxxxxxx
x
=
Open
ZaH_xxxxx
a
=
Application ID
H
=
H for Help
xxxxx
=
Table name search is based on or
description of search help
3.4.3 Form Specific Standards

SAP Object Type
Standard Text ID
Length
13.4
Standard Text Name
32
13.5
Style
13.6
SAPScript Layoutset
Naming
16
Section
13.3
343416319.doc
Naming Convention
Zxxx
x
=
Open
Zxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x
=
Open
Z_xxxxxx
x
=
Open
Zaxxxxxxxxxxxxxx
a
=
Application ID
x
=
Open
13
3.4.4 ALE/EDI Specific Standards

SAP Object Type
IDOCs
Length
15.3
IDOC Segments
15.4
Process Codes
15.5
Partner Profiles
Naming
Port Names
Message Type
Section
15.2
15.6
15.12
30
30
Naming Convention
Zxxxxxxx
x
=
Z1xxxxxx
x
=
Zxxx
x
=
See Section 15.5
Open
Open
Open
See Section 15.6

Zxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x
=
Open
3.4.5 Project Enhancement Specific Standards

Section
3.12.1
3.12.2
SAP Object Type

Project Names
Enhancement
Names
Length
8
8
Naming Convention
Zppppnnn
pppp
n
Zppppnnn
pppp
n
=
=
Project Area
Numeric Sequence
=
=
Project Area
Numeric Sequence
3.4.6 Workflow Specific Naming Conventions:
Component of
Workflow
Object - Type name
Length
Naming Convention
10
ZWO + ShortDesc (7 chars)

ShortDesc - Short Description of object name (7 chars)
If an object type is defined as a business object (BUSnnn), the same
name as that of the assigned data model should be chosen
If not a business object, the 7 characters should use the following
format:
ZWOaannnnn
A = application module ID
Nnnn = sequential number
Object (Interfaces)
10
ZWIF + ShortDesc (6 chars)

IF indicates Interface
343416319.doc
14

ShortDesc - Short description of interface (6 chars)
Object (Key Fields)
20
ZWK + ShortDesc (17 chars)

K indicates Key Fields +
ShortDesc - Short description of key field (17 chars)
Object (Attributes)
20
ZWAab + ShortDesc (15 chars)

A indicates Attribute
B=
S - Single line
M - Multi-line
I - Instance independent
O - Only modeled
ShortDesc - Short description of attribute (15 chars)
Object (Methods)
30
ZWMabc + ShortDesc (24 chars)

M - Method
A=
S - Dialog synchronous
A - Dialog asynchronous
B - Background
B=
FRTDO-
C=
P - Parameter(s)
N - No parameter(s)
Function module
ABAP report
SAP transaction
Dialog methods
Other
ShortDesc - Short description of method (25 chars)

Object (Method
Function Modules)
30
Object )Method ABAP Reports)
Z_WF + ShortDesc (26 chars)

ShortDesc - Short description of method (25 chars)
ZWR + ShortDesc (5 chars)
R indicates ABAP Report
ShortDesc - Short description of ABAP Report (5 chars)
Object (Method
ABAP Programs
(Other))
ZWP + ShortDesc (5 chars)

P indicates ABAP Program - Other than report
ShortDesc - Short description of ABAP program (5 chars)
Object (Method
Transaction)
Object (Method
Dialog Modules
ABAP)
ZW + 2 chars
30
ZWD + ShortDesc (27 chars)

D Indicates Dialog Module - ABAP
ShortDesc - Short description of dialog module (27 chars)
Object (Events)
20
ZWE + ShortDesc (17 chars)

E indicates Event
ShortDesc - Short description of event (17 chars)
343416319.doc
15

Object
(Implementation
Program)
SINGLE STEP TASKS
Standard Tasks
12
ZW + last 6 chars of business object name
ZWTSa + ShortDesc (7 chars)

T indicates Standard task (single step)
A = D - Dialog
B - Background
ShortDesc - Short description of standard task (7 chars)
Customer Tasks
12
ZWTa + ShortDesc (8 chars)

T indicates Customer task (single step)
A = Dialog
Background
ShortDesc - Short description of workflow template (7 chars)
MULTI-STEP TASKS
Workflow Templates
12
ZWWSa + ShortDesc (7 chars)

WS indicates Workflow template (multi-step)
a = SAP Module
ShortDesc - Short description of workflow template (7 chars)
Workflow Tasks
12
ZWWFa + ShortDesc (7 chars)

WF indicates Workflow task (multi-step)
A = SAP module / application abbreviation
ShortDesc - Short description of workflow task (7 chars)
CONTAINER
ELEMENTS (field
names)
32
Cab + ShortDesc (29 chars)

C indicates Container Element
A indicates Workflow tasks & templates
T - Standard / Customer task
R - Role resolution
B indicates Object type
DDIC field
ShortDesc - Short standard container element (field) description (29
chars)
STANDARD ROLES
12
ZWRa + ShortDesc (8 chars)

R indicates Standard Role
a Function module
Organizational object
ShortDesc - Short standard role description (8 chars)
Standard Roles:
Function module
343416319.doc
30
Z_WF_ROLE + ShortDesc (21 chars)

ShortDesc - Short standard role description (21 chars)
16

ORGANIZATION
UNITS
12
ZWUO + ShortDesc (8 chars)

UO indicates Organization Unit
ShortDesc - Short organization unit description (8 chars)
Org Unit - Jobs
12
ZWUP + ShortDesc (8 chars)

UP indicates Organization Unit / Job
ShortDesc - Short organization unit position description (8 chars)
Org Unit - Positions
12
ZWUS + ShortDesc (8 chars)

US Organizational Unit / Position
ShortDesc - Short organization unit position description (8 chars)
3.5
ABAP Program
(Format = Zabxxxxxxxxxxxxxxxxxxxxxxxxxxx)
Z
a=
b=
x=
= the alpha character Z for ABAP program name. All SAP user defined program
objects must start with a Z. These objects can be local /private or transportable
objects.
Application ID (section 3.2)
Program Type ID (section 3.3)
Free form text separated by underscores
3.5.1 ABAP Report Variant

(format = xxxxxxxxxxxxxxxx)
xxxx
= Open
Examples:
3.6
Development Classes (format = ZDEVError! Bookmark not defined..)
Multiple development classes will be utilized on the project. The classes will be determined at a
later time and updated.
The development class, which will be used for all development at Federal Mogul, will be ZDEV.
Programs, which are type x (temporary, demo or test programs), should be declared as local objects.
3.7
Functions
3.7.1 Function Groups (26 Characters)
Function groups allow for grouping related function modules and their components into a common area.
Also, all function modules within a function group may share common variables.
Function groups should adhere to the following naming convention:
Zaxx
343416319.doc
17

a = Application ID
xx = Open text
Remarks: The creation of a Function Group results in the creation of a main program for the Function
Group called SAPLZaxx where Zaxx is the name of the Function Group.
Example: ZF01 - Function group for financial management this creates the main program SAPLZF01.
3.7.2 Functions (Maximum of 30 Characters)
The SAP function modules are programs written in ABAP that form logical units in function groups.
They can be shared by multiple ABAP programs and by other function modules. They are managed
centrally in the function library.
Function modules are grouped together using the function groups. Function modules may be defined to
one and only one function group. SAP-supplied function groups should never be used to define new
function modules.
Function modules are similar to programs, the primary difference is they can be called using remote
function calls from the operating system, can be called variably within and across programs, and are not
typically built for reporting using selection criteria.
Function module names can be a maximum of 30 characters. The following naming convention should
be used:
Z_a_xxxxxxxxxxxxxxxxxxxxxxxxxx
a = Application ID
xx = Open (Meaningful, separate words with underscores)
Remarks: All function modules should follow programming standards outlined in this document. There
is no difference between programs and function modules when considering logic flows, syntax, unit
testing, and variable naming.
Example: Z_Z_OPEN_DATASET
3.8
JOBS
3.8.1 Batch Job Names
(format = Z_b_a_xxxxxxxxxxxxxxxxxxxxxxxxxx)
Length: Up to a maximum of 32 characters
Z
= the alpha character Z.
Application ID
Frequency ID (from table below):

Frequency ID
O
Y
Q
343416319.doc
Description
On request
Yearly
Quarterly
18

M
W
D
N
H
E
Monthly
Weekly
Daily
Nightly
Hourly
Event-Driven
= the literal underscore character
xxxx
= A meaningful description
Example: ZSD1_OPEN_ORDER_LOAD
Remarks: Background jobs supplied by SAP must not be changed without SAP approval. If it becomes
necessary to modify an SAP-supplied background job, the Basis, Applications, and QA Leads must
approve it. If accepted, the job must be copied to a new name, using the naming standards described
here. The modified version should be used instead of the original.
Note: The frequency ID can be added to as the batch schedule process becomes further defined. In its
current state t is not intended to be used as a complete list. It is only an initial set of possible values.
New values should be added to the list through the Development Standard Change Process.
3.8.2 Batch Input Sessions (BDC)
Much of the data integrity of the SAP application is enforced at the application level (i.e. ABAP/Dynpros)
rather than the database level. As a result all batch data entry to the system must pass through the same
application logic as on-line data entry. This is accomplished via BDC sessions.
Since BDC sessions are generated from ABAP programs, the BDC session should reference the name of
the ABAP program, which generated it.
BDC sessions should adhere to the following naming convention:
Format:
xxxxxxxxxxxxx
x = open
3.9
MESSAGES
3.9.1 Message Class
(format = Zabbbbbbbbbb)
Z
a
b
=
=
=
the alpha character ZZ
Application ID
description of the class
3.10 ON-LINE PROGRAMMING

SAP online functionality is driven by transaction codes. Any on-line program normally involves the following
components:
Screen painters
Menu painters
DDIC references and objects
343416319.doc
19
PAI modules
PBO modules
Perform modules
-------->
Constitute Module Pools
Authorization objects
Transaction Code
Each SAP transaction is identified by a unique transaction code, which is listed in two SAP tables. Table TSTC
contains the attributes of the transaction, while table TSTCT contains the short text associated with the
transaction. Transaction codes should adhere to the following naming convention:
Zaxxxxxxxxxxxxxxxxxx
a = Application ID
x = Open (Description of Transaction 18 Characters)
3.10.1 ABAP Module Pools
An ABAP module pool is an ABAP program that checks and processes what the user enters during an on-line
transaction. It is thus part of the on-line processing. An ABAP module pool groups together the modules that
process common data. For each logical database program, module pools handle the access to database data
selections. Due to their unique properties, module pools must follow SAP naming conventions. Module pool
names must be 8 characters long and adhere to the following convention:
SAPxZann
- Module Pool Type (see table below)
a = Application ID
n = Sequential number
L
D
F
S
Module Pool Type

Functional Module
Logical Database Module
Subroutine Module
Screen Module
For logical database module pools, use the last three characters for the logical database name.
3.10.2 ABAP Module Pool Components

Naming conventions for Module Pool components must also adhere to SAP standards. See table below for
detailed conventions using the above example. (Note: Zannn in conventions below should match Zannn in main
Module Pool name).
Module Pool Component Type
Data Definition (Global Data Include) Module
Process Before Output (PBO) Module
Process After Input (PAI) Module
Performs (subroutines)
Process On Help-Request (POH) Module
Process On Value-Request (POV) Module
343416319.doc
Naming convention
MZannTOP
MZannOxx,
- Open
ZannIxx,
- Open
MZannFxx,
- Open
MZannHxx,
- Open
MZannVxx,
- Open
20

Remarks: It is required that you use the SAP Workbench (SE80) to construct module pools. The SAP
Workbench is designed to enforce standard naming conventions.
3.10.3 Dynpros (Screens)
SAP screens are referred to as Dynpros. Standard SAP components, such as transactions, menus and tables,
contain Dynpros and the associated processing logic.
The identification of a Screen Painter Dynpro consists of an ABAP program name and a four-digit Dynpro
number. For a customer-developed screen attached to a SAP-supplied program, the allowable range for the
Dynpro number is 9000-9999. For a customer-developed screen attached to a custom-developed program, the
programs initial number should be 0100. Additional screens should be created with an increment of 10.
Module Pool Component Type
Screen Number (Attached to custom-developed program)
Screen Number (Attached to SAP-supplied program)
Pop-up screen number
Naming convention
0100-9999 in increments of 10.
9000-9999 in increments of 1.
Parent screen number + multiples
of 1 ( e.g. 101 for screen 100)
Remarks: Screens supplied by SAP must not be changed. Approval of Project Management will be required
prior to the modification of SAP-supplied screens.
3.10.4 GUI Status (GUI definition for screen, i.e. function codes, etc.)
Correspond to screen name where possible, or use sequential numbering starting with 0100 (i.e., 0100
Ded Mgmt General, 0200 Ded Mgmt Detail, etc.)
3.10.5 GUI Title (screen title)
Correspond to screen name where possible (i.e., 0100 Ded Mgmt General, 0200 Ded Mgmt Detail, etc.)
3.11 Menus
3.11.1 Function Keys
xxxx
x = Open
3.11.2 Titlebar
xxx
x = Open
3.12 Projects & Enhancements

3.12.1 Projects
(Format = Zpppnnn)
343416319.doc
21

Z
pppp
n

= Project Area (section 3.13.3)
= Numerical Sequence
3.12.2 Enhancements
(Format = Zppppnnn)
Z
pppp
n

= Project Area (section 3.13.3)
= Numerical Sequence
3.12.3 Project Area

For Federal Mogul purposes, the Project Area will be a 4-character field, which acts as a general
functional identifier for each project developed. This project area generally coincides with major
programs within SAPs various functional modules.
ID
SALS
DVRY
INVC
PURD
Description
Sales Document Processing
Deliveries
Invoicing
Purchasing Document Processing
The list of Project Areas may be further refined for specific project requirements. If it appears that a
specific development object cannot be appropriately classified by the current list of Project Areas, a new
Project Area should be requested from the Development Standards Document owner.
343416319.doc
22

3.12.4 Project & Enhancement Process
If you need to use an enhancement you must first check to see if a project has already been set up for the
Project Area you will be using. If one has not been created you must create it with the naming convention
listed in Section 3.12.1 above.
The next step is to check to see if the enhancement component needs to be added to the project. If the
component already is assigned to the project then a new include program should be added to the
enhancement which includes code that satisfies the new requirements. The new include program should
also adhere to the documented naming standard for programs listed in Section 3.5 above.
For example. Lets pretend Enhancement AD010001 is assigned to project ZSALS001. Enhancement
AD010001 contains the function exit EXIT_SAPLAD13_001 which contains SAPs include program
ZXAD1U09. If include program ZXAD1U09 already contains code someone developed for another task it
should be included in an include program itself, let say ZVNORDER_CHANGES. If we have additional
changes that need to be added to this function exit then we should include it in a new include that we
would assign to include ZXAD1U09, maybe called ZVNBILLING_CHANGES. The structure would look
like the following
Project
Enhancement
ZSALS001 AD010001
Function Exit Module
SAP Include
EXIT_SAPLAD13_001
ZXAD1U09 -----|---> ZVNORDER_CHANGES
User Include
|---> ZVNBILLING_CHANGES
If the enhancement is not already assigned to the project then the next step would be to assign the
enhancement to the project and add the new include to the function exits standard SAP include program.
343416319.doc
23

4 Dictionary Standards
Creation of custom DDIC objects should be kept to a minimum to avoid unnecessary maintenance efforts and
should cater to specific functional requirements, which are not met in the SAP-supplied ABAP Dictionary.
The following are the points to be kept in mind during definition of DDIC objects:
Foreign keys referencing SAP table primary keys are highly recommended.
Table maintenance facility (SM31, SM30) should be encouraged only if data security is not highly critical.
Documentation at the data element level should make use of the long text facility to make on-line help
effective.
For master data or transactional tables, the user names of the persons who created and/or changed data
and the date of creation/change should also be stored.
Technical settings should be maintained on all custom tables
The maximum length for an object in the data dictionary will be 16 characters. However, depending on the
object type the maximum length allowed might be less than 16 characters. The following section will describe
the requirements for different data dictionary objects.
4.1 Purpose
The naming standards for tables, field names, domains, and data elements define a consistent method to
develop tables within SAP data dictionary.
4.2 Transparent Tables, Pool Tables (16 Characters)
A Transparent table has a 1:1 relationship (field for field) with a corresponding physical table on the underlying
database. Transparent tables are typically used to store master and transaction data.
Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary
data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical
table on the database in which all the records of the allocated-pooled tables are stored. Whereas in SAP a pool
table can be broken down into detailed key and non-key fields, at the database level a pool table is simply
divided into one key and one non-key field. Because of this structure, selections on pool tables are not as
efficient as selections on transparent tables.
Transparent tables and pool tables should adhere to the following naming convention:
Zaxxxxxxxxxxxxxx
a = Application ID
x = Open
Note:
In custom tables created in SAP, the first key field is recommended to be MANDT.
Use the underscore to separate words used in the text string for readability.
343416319.doc
24

4.2.1 Understanding the Delivery Class
Delivery Class
A delivery class is used to categorize a SAP Table to describe whether it is a table used for customizing
or manual ABAP updates.
To add an index to an existing SAP Table:
Get the index approved at Quality Review
Send a request note to the ERP DBA distribution list
Send CC to the Federal Mogul SAP ERP Application Manager and Basis
Be sure to include the Development Object ID
When (C)
Customizing
Customizing tables are normally client-dependent, and should be updated via SM30. This is
generally done manually, but in some cases where a large volume of data is provided in a file,
we have written ABAP BDC programs. Data is entered into the Development system, gold
client and transported to the other Development clients, and then on to Quality and Production.
ABAP programs should not directly update customizing tables.
When (A)
Application
Application tables are usually client-dependent, and usually updated directly in ABAP. Data is
usually loaded into the tables in each client manually, or by executing the same ABAP program
in each client. Application data is not transported, and it is not necessary to keep the clients
'insync'.
Summary:
Delivery Class Table
A
C
Data Transported
No, data updated manually
or an ABAP
Yes, from Development
System/Gold client, client
dependent
Table Definition Transported

Yes, client independent
Yes, client independent
4.2.2 ATAB/Control Tables (5 characters)

The most well known table pool in the SAP system is the ATAB table. When adding new tables to the ATAB
table pool, a maximum of 5 characters may be used. ATAB/Control Tables should adhere to the following
naming convention:
T9axx
a
=
x
=
Application ID
Open
4.2.3 Cluster Tables

Cluster tables contain continuous text, for example, documentation. Several cluster tables can be combined to
form a table cluster. Several logical lines of different tables are combined to form a physical record in this table
type. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at
least parts of the keys must agree. Several cluster tables are stored in one corresponding table on the database.
343416319.doc
25

Cluster tables are a remnant of database limits imposed when R/3 was first developed, which prevented
certain databases from handling more than a certain number of tables.
Custom-developed cluster tables should not be created.
4.2.4 Structure
(format = ZaSxxxxxxxxxxxxx)
A structure does not correspond to any physical table in the database. It is simply a record layout which can
be manipulated internally in a program, and whose format can be shared across multiple programs.
Z
the alpha character Z
Application ID
the alpha character S for Structure
xxxxxxx
a meaningful description
Example: ZMSPRCHASE
4.2.5 View
(format = ZaVxxxxxxxxxxxxx)
Views can be used to create virtual tables that are not physically stored in the database, but present selected
columns from one or more tables, which are stored in the database.
In the simplest case, a view can involve simply suppressing the display of one or more fields from a table
(projection) or transferring only certain records from a table to the view (selection). More complicated views can
be assembled from several tables, with individual tables being linked using the relational join operation. The
maximum length for the name of a View is 10 characters. However, the first 7 characters must be unique across
all views - the Data Dictionary will validate this.
The following naming convention should be used:
Z
the alpha character Z
Application ID
the alpha character V for View
xxxxxxx
A meaningful description
Example: ZMVPRCHASE
343416319.doc
26

4.2.6 Table Maintenance (Authorization Group)
Table Maintenance authorization groups are used to help manage security access during table display
(SE16/SE17) and maintenance (ZSE16). In the QA and Production environments access to the
SM30/SM31 transaction codes will be locked down. However a new transaction ZSE16 has been
developed that will act as a front-end to SM31. This new transaction will provide a drop-down list of the
Z tables the user has access to display/modify. The user can select the desired table and then click
the Display or Maintain button.
Every Z table having maintenance screens must have an Authorization group that adheres to the
following naming convention:
Zax
a = Application ID
x = Open
4.2.7 Table Maintenance (Function Group)
Care must be taken when assigning the function group name during table maintenance screen
generation (SE11). This will avoid problems during transport. These function group names will be
assigned by the technical team leaders and will follow the existing naming standards (see section 3.7.1).
Function groups should adhere to the following naming convention:
Zax
a = Application D
x = Open
Remarks: The creation of a Function Group results in the creation of a main program for the Function
Group called SAPLZaxx where Zaxx is the name of the Function Group.
Example: ZF01 - Function group for financial management this creates the main program SAPLZF01.
343416319.doc
27

4.3 Table Field Name
Fields do not exist as independent objects in SAP. They only exist as part of a table or structure. The
maximum length of a table field is 10 characters (12 if appending to a SAP delivered table with the inclusion
of the ZZ prefix). They are freely definable, but field names should be meaningful, and abbreviations (see
section 4.6.1 Data Classifiers for example abbreviations) should be consistent across a related set of
tables whenever possible. Consistency with SAP-delivered abbreviations is strongly recommended. For
example, for a SAP client number, use MANDT; for a customer number field, use KUNNR. Table fields
should adhere to the following naming convention:
(Attached to SAP-delivered tables as append structures)
ZZxxxxxxxxx
x = Open
(Attached to custom tables)
xxxxxxxxx
x = Open
4.4 Data Element (Maximum of 16 Characters)
A data element is a semantic domain. It provides a precise description of the function of a domain in a specific
commercial context for the benefit of the fields that depend on it. Try to avoid defining new data elements for
existing SAP domains. The maximum length for a data element will be 16 characters. The first character must
be Z. The remaining characters can be arbitrarily assigned.
Data elements should adhere to the following naming convention:
(If using a SAP delivered field)
Data element should be the same as the data element for the existing SAP field name.
(If using a custom data element)
Zxxxxxxxxxxxxxxx
x
Open
Note: See 4.7 Data Elements & Domain Re-use guidelines to determine if you can re-use a data
element.
4.4.1 Data Element Medium Field Label
Length: Maximum of 15 characters.
Medium Field Label = Abbreviated name when the long field label is entered as the full name.
4.4.2 Data Element Short Field Label

Short Field Label = Abbreviated name.
4.4.3 Data Element Header

Restricted: The length you choose should correspond to the length of the field. This header is used for
column headings in reports and should not be much bigger than the field size.
343416319.doc
28
4.5
Header = As close to field length as possible without losing meaning. Make same as short,
medium, or long field label where possible.
Domain Name (Maximum of 30 Characters)

A domain is a central point for describing the technical attributes of a field such as length and type. A
domain describes the value set for a field. This set of values is defined by specifying the format
attributes, such as the external format, length and type. The maximum length of a domain can be 16
characters long. The first character must be Z and the remaining characters can be assigned arbitrarily.
Domains should adhere to the following naming convention:
Zxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x
Open
Note: See 4.7 Data Elements & Domain Re-use guidelines to determine if you can re-use a
domain.
4.6
Search Helps
Search Help replaces the match code from previous 3.x versions. Search helps can be used to assign an
input help (F4 help) to fields in input masks. Upon pressing the F4 key, the user is offered a number of
possible search paths, each of, which presents a number of restrictions to limit the number of possible
input values. After entering the restrictions (if required), the system returns the values (hits) which satisfy
the restrictions. The user then selects the desired line from the hit list, and this value is copied to the
screen mask.
There are two types of search helps: elementary and collective. An elementary search help corresponds
to a search path. It must define the selection method (how data of the hit list is read: table, view, or table
with text table), the interface (parameters) of the search help, and the online behavior of the search help
(how displayed). A collective search help comprises several elementary search helps. Its behavior is
defined by the parameters of the collective search help, as well as the search helps assigned to the
collective search help.
SAP delivers a standard F4 input process, which is defined by defining a search help. If this standard
does not meet the desired requirements, a search help exit can be used at fixed times. The search help
exit must have the same interface as function module F4IF_SHLP_EXIT_EXAMPLE. (See Data
Dictionary and function module on-line help for more information.)
343416319.doc
29

4.6.1 Data Classifiers
The following are the standard field classifiers, their abbreviations and meanings:
Classifier
Abbr
Meanings
Amount
Amt
Monetary values
Sort Key
Srt
Used to sort records
Code
Cd
A finite set of encoded values, each of which has a defined
meaning. (Example: Postal Code)
Count
Cnt
A tally, or number of occurrences (Example: 142 Units)
Date
Dt
A particular day. Would include Year, Month, and Day (Example:
14 June, 1992)
Description
Dsc
A textual explanation
Flag
Flg
A Flag field
Identifier
Id
Uniquely distinguishes the occurrences of an entity
Index
Idx
Use to indicate an index field
Indicator
Ind
A field with two values (Example: yes/no)
Messages
Msg
Holds messages
Name
Nm
A textual description by which the occurrence of an object is
designated (Example: Customer Name)
Number
Num
An identifier composed of numeric values (Example: Customer
Number 13487)
Object
Obj
A large binary object (Example: Image, Word Processing
Document)
Percent
Pct
The result of a division by 100 (Example: 87%, 14%)
Ratio
Rto
The relative size of two quantities expressed as a quotient of
one divided by the other (Example: .25, 1.5)
Quantity
Qty
A non-monetary quantitative measure (Example: 1,257)
Summary
Sumy
Indicating a summary field
Text
Txt
A free-form textual value
Time
Tm
An interval of or point in time (Example: 1:30PM, 14 Hours)
4.7
Data Elements & Domain Re-use Guidelines

4.7.1 Overview
There are a large number of both data elements and domains, which are part of the standard R/3
system. When developing new data dictionary structures that require these objects it may be preferable
to re-use existing objects rather than create new ones.
In general domains are re-used more often than data elements since the domain provides the linkages
for check tables and lists of values.
If there is any doubt about the applicability of an existing data element or domain, it is better to create
new ones rather than re-use the existing ones. Again, good programming and design practice should
be followed.
4.7.2 Data Elements
Data elements can be re-used if an element is needed that:
provides the identical business picture as the existing element with regards to short text, help text,
screen labels and column headings
is linked to a domain that provides the correct physical attributes, validation rules and key linkage.
343416319.doc
30

4.7.3 Domains
Domains can be re-used if a domain that is needed provides the identical physical definition as existing
domain with regards to short text, physical attributes, validation rules and key linkages of the existing
domain.
343416319.doc
31

5 Data File Naming Standards
5.1
Purpose
This chapter will provide guidelines for naming of all external file formats outside of SAP. There must be
consistency between file names used and SAP Development Objects. Files will primarily be used for
Conversion and Interface components. All target files will be moved to UNIX.
This section may be somewhat volatile as changes are made either from BASIS requirements or when
use of middleware, etc is further defined. Some portions of this section are more recommendations
than rules.
5.2
UNIX Data Files

The format for files to be transferred to/from SAP will be:
<development object name>_<description>.<file type>
Parameter
<development
object name>
<description>
<file type>
Value
e.g., zvi000001
As required may include variable components designated by placeholders
dat
Data File (ASCII only for use in SAP R/3)
tmp
Temporary / Work File
ref
Reference File
[DTS] Date/time stamp file (Transactional, use placeholder)
log
log file
err
error file
ebc
EBCDIC data file
Example:
zmi000001_po_load.dat (this is the filename as stored in the UNIX file system)
A file name may contain placeholders that are substituted at runtime by the function module
FILE_GET_NAME when it generates a complete platform-specific file name. Placeholders fall within the
free-form description part of the file name if there is a need for them (e.g. if an interface must read or write
multiple files).
5.2.1 UNIX Data Directories Structure, for SAP Development
When a new SAP instance is created the corresponding data structures will have to be created, (contact
the Basis or C&I Group).
/Public/<module>
/Public/<module>/up
/Public/<module>/down
343416319.doc
32

Parameter
<instance>
<module>
Subdirectory
up
down
srcdata
log
error
Value
Production =
Development = 100, 110, 120, 130
QA =
Sandbox =
Training =
Integration Test =
bs
=
Basis
ci
=
Labor Overhead/Rates
fi
=
Finance (General Ledger/Reporting/Tax)
fa
=
Fixed Assets
tr
=
Treasury
hr
=
Human Resources
mm =
Materials Mgmt /Inventory Management
ot
=
Others (i.e. Industry Solutions)
pm =
Plant Maintenance
pp
=
Production Planning
ps
=
Project Systems
qm =
Quality Management
sd
=
Sales & Distribution
wf
=
Workflow
cc
=
Contracts to Cash
mp =
Manage Programs
sh
=
Shared
Definition
inbound files; data to be loaded into SAP
outbound files; data extracted from SAP
legacy source files to be consolidated or reformatted for SAP loading
(reformatted data from these files will be stored in the directory)
program execution log files
program execution error files
Notes:
temporary data files (i.e. any intermediate and temporary data storage); files older than a week residing in
this directory will be deleted periodically.
archive data files; all files should be moved to this directory once processed
343416319.doc
33

5.3
UNIX Application Directories for SAP Development

ERP application source and executable files will be stored in a directory based on existing Federal
Mogul application directory standard.
5.3.1 UNIX Applications Directory Structure:
/Public/<module>/<directory type>
where:
<module>
<directory type>
=
the SAP Module name the source code or executable is tied to:
bs
= Basis
ci
= Controlling Inventory
fi
= Finance/ Controlling/ Fixed Assets ManagemEnt.
hr
= Human Resources
mm
= Materials Mgmt /Inventory Management
ot
= Others (i.e. Industry Solutions)
pm
= Plant Maintenance
pp
= Production Planning
ps
= Project Systems
qm
= Quality Management
sd
= Sales & Distribution
wf
= Workflow
wm
= Warehouse Management
IM
= Inventory Management
=
src
bin
common
=
=
=
Source code
Executable files
Shared libraries
5.3.2 Upper and Lowercase Parameters with UNIX Physical Filenames

If a parameter is using a domain that has the lowercase letters flag set on, then that field distinguishes
between uppercase or lowercase letters for that parameter (you can type in upper and lower case). If
the parameter is using a domain that does not have the lowercase letters flag set, then all letters that
are entered will be converted to uppercase.
If the domain for your parameter does not have the lowercase letter flag set on, then you need to
explicitly say lowercase in your parameters statement for it to accept lowercase letters.
Note:
For UNIX filenames we MUST allow mixed case letters.

Example:
The domain allows mixed case. Therefore, you do NOT need to explicitly state lowercase on the
parameter field infiLe.
parameters: infile
like rfpdo-rfbifile. " Physical file name
The domain for field rfpdo-rfbifile is TEXT128, which has the lowercase letters flag set ON.
The domain does not allow mixed case. Therefore, you do need to explicitly state lowercase on the
parameter field p_fiLe.
parameters: p_file like filetextci-fileintern lowercase. " Physical File name
343416319.doc
34

The domain for field filetextci-fileintern is FILEINTERN, which does NOT have the lowercase letters
flag set ON.
343416319.doc
35
ABAP Message/Error Handling Standards
6.1
Purpose
The message handling process varies depending on the type of programming, functional requirements,
run time environment and modularization. ABAP errors occur for the same reasons that errors occur in
other programming languages (e.g., record not found, type mismatch, record locked, etc.)
The following sections detail the proper way to handle certain types of messages in certain situations.
The list is not comprehensive and the programmer is responsible for using good professional judgment
for the cases that are not covered below.
6.2
Message Handling
All messages must be included in the SAP message table under message class Za (where a is the
application id). Where an action is required for a message, the long text option in the message should
be used to define the action.
Transaction = SE91
343416319.doc
36
6.3
SAP Message Types (format = a)

Code
Type
Action
I
Informationa Press ENTER to
l
continue
W
Warning
Correction possible
Error
Correction required
Abend
Exit
Success
343416319.doc
Transaction
terminated
Transaction
terminated with short
dump
Message on next
screen
Description
It contains information about operations
already performed and can be safely
ignored without any consequences.
It provides information about the
consequences of certain actions. These
messages cannot be ignored but the user
can choose whether or not to make a
correction or bypass the message.
It contains information about processing
errors. The system interrupts the current
processing so that the errors can be
corrected. Only then can processing
continue.
It provides information about processing
errors but the processing cannot be
resumed.
It provides no processing information, but
rather, a stack dump for the state of the
system.
37

6.4
Return Codes
6.4.1 ABAP System Field SY-SUBRC
Messages in ABAP are handled, in most cases, by the system field SY-SUBRC which retains the value
of the return code after specific operations such as select, read, translate, etc. Whenever it is possible
for a statement to set a return code value, which must be handled to insure proper continuation of the
program, SY-SUBRC should be explicitly checked and appropriate action taken.
SY-SUBRC = 0 ;indicates a successful completion of the statement
SY-SUBRC <> 0 ;indicates an error condition for the statement
6.4.2 Exception Codes
Exception codes are used to communicate errors from a function module to the calling program. The
calling program must handle all possible errors generated by a function by the use of the EXCEPTIONS
clause of the CALL FUNCTION statement in conjunction with SY-SUBRC. The use of OTHERS is
acceptable to handle errors that do not have specific handling required. Letting error codes fall
through is not acceptable. This makes it unnecessary to use of the MESSAGE RAISING
EXCEPTION construct, which should, therefore, be avoided.
When writing a function module, RAISE EXCEPTION should be used to terminate the processing of the
function and return an error code to the calling program unless one or more of the EXPORT parameters
contains valid information that the caller will require. If RAISE EXCEPTION is invoked in a function
module the EXPORT parameters are not filled when control is returned (immediately) to the calling
program.
Example:
CALL FUNCTION STRING_SPLIT
EXPORTING
DELIMITER = :
STRING = FELD
IMPORTING
HEAD = HEAD
TAIL = TAIL
EXCEPTIONS
NOT_FOUND = 1
OTHERS = 2.
CASE SY-SUBRC.
WHEN 1.
WHEN 2.
ENDCASE.
6.4.3 Closing the Spool
E and A level error messages overwrite the print spool and destroy its contents. All write statements are
erased and overwritten by the ABEND. To maintain spool integrity, if desired, insert the following code
before each A or E message.
NEW-PAGE PRINT OFF.
COMMIT WORK.
MESSAGE A (or E)
343416319.doc
ABEND or error coding.
38

6.4.4 CATCH Keyword (New in 4.6)
The CATCHENDCATCH block allows the programmer to catch ABAP runtime errors and assign these
to a SY-SUBRC. This functionality allows errors to be reported in a controlled manner (rather than a
short dump).
The CATCH statement should not become a crutch to catch errors, which can already be avoided by
good programming practice. An example of this would be using the CATCH statement to trap divide by
zero errors, which would result in a short dump. Good programming practice should prevent the
occurrence of divide by zero errors without the use of the CATCH statement. However there may be
instances where the use of the CATCH statement is required.
343416319.doc
39

7 ABAP Improve Efficiency Standards
7.1 Purpose
The purpose of this chapter is to highlight some techniques that can be helpful to improve the run-time
performance of the code. Following are some of the techniques that can be used. Also, refer to the Tips &
Tricks section on the Runtime analysis screen from the top level Utilities menu of R/3.
7.2 Use of Internal Tables
An internal table is a group of records created at run time. To define an internal table use the OCCURS
parameter followed by the estimated number of lines. It is much quicker to perform a direct read on the Internal
Table. In this case try to adjust the OCCURS parameter with the correct number of table entries. This will
prevent system allocating unneeded memory. If the table size is less than 8K, estimate the number of rows with
the OCCURS parameter. If over 8K, let runtime allocate the optimal size by setting the occurs parameter to 0.
When filling an internal table, use SELECT INTO option. This will eliminate the REFRESH statement.
Example 1: SELECT statement
SELECT * FROM T001 INTO TABLE I_T001.
When filling an internal table from another internal table the following are the most efficient methods available.
In many cases the structure of the internal tables need to be identical.
Example 2: APPEND statement
Most efficient
I_TAB1[] = I_TAB2[].
More efficient
LOOP AT I_TAB1.
APPEND I_TAB1 to I_TAB2.
ENDLOOP.
Less efficient
LOOP AT I_TAB1.
I_TAB1 = I_TAB2.
APPEND.
ENDLOOP.
Example 3: READ statement
This example assumes the table is sorted by the key K.
More efficient
READ TABLE I_TAB
WITH KEY K = X BINARY SEARCH.
Less efficient
Move space to I_TAB.
I_TAB-k = x.
Read table I_TAB binary search.
Example 4: LOOP statement
More efficient
LOOP AT I_TAB where K = KVAL.
343416319.doc
40

-ENDLOOP.
Less efficient
LOOP AT I_TAB.
CHECK I_TAB-k = KVAL.
--ENDLOOP.
7.3 ABAP run-time Analysis
The ABAP runtime analysis can be used to further monitor the performance. This option can be selected from
transaction SE30. The output will be a report indicating the following
Execution time in microseconds:
ABAP
Database
R/3 System
0%
75.769
42.138
12.597
50%
100%
130.504
=
=
=
58,1%
32,3%
9,7%
= 100,0%
7.4 Pretty Printer

Use PP at the command line or use Program Pretty printer from the SE38 menu path in order to maintain
proper indentation. This command will indent the program statements automatically and improve program
readability. If pretty printer is not used then the program should still maintain indentation in order to improve
readability of the code.
7.5
1.
Following Is Not Allowed

Multiple statements in one line.
Example:
A = B . C = D.
Not Allowed
Example:
A = B.
B = C.
Allowed
2.
The use of MESSAGE RAISING to terminate a function will not be used. The calling program
should be responsible for displaying any messages. Use RAISE EXCEPTION instead.
3.
Do not define any data with the BEGIN OF COMMON statement. The scope of data should not exceed
the particular transaction being dealt with.
7.6
the COLLECT command
When used with a standard table, the COLLECT statement creates a temporary hash administration for the
table and uses it to find entries. This makes the runtime independent of the number of table entries. However,
once a command like DELETE, INSERT, or SORT is used on the table the hash administration is invalidated
and any future COLLECTs must use a linear search, causing the runtime to be dependent on the table size.
The runtime for the COLLECT command increases with the width of the table key as well as with the number of
fields that have to be summed.
When filling an internal table, use COLLECT instead of READ/INSERT when the number of table entries is
greater than 1000. Do not use it with a combination of APPEND, INSERT, and/or MODIFY.
343416319.doc
41

8 Standard Include Programs
8.1 Purpose
The purpose of this chapter is to list some of the common include programs that can be used for reports,
interfaces and conversions.
8.2
Program to Print Header Information in a Report - TBD
343416319.doc
42

9 ABAP Program Structure/Organization
9.1
Purpose Patterns for header

This chapter describes the general program structure to be used when coding new source code modules,
as well as details specific to certain statements or module blocks. Use ABAP program template
ZTEMPLAT to get started when writing an ABAP program.
9.2 The Standard Structure for ABAP Report Code

Note:
In this context, a report is any instance of a conversion, interface, report, form, or extension.
REPORT
Header documentation (comment box, Goto Program Doc, Maintenance History Box)
Declarative elements
TABLES
TYPES
INTERNAL TABLES
STRUCTURES
CONSTANTS
DATA
RANGES
FIELD-GROUPS
FIELDS
FIELD-SYMBOLS
PARAMETERS
SELECT-OPTIONS
Event elements
INITIALIZATION
AT SELECTION-SCREEN
START-OF-SELECTION
GET (Logical DB do not use)
END-OF-SELECTION
TOP-OF-PAGE
END-OF-PAGE
Control elements
TOP-OF-PAGE DURING LINE-SELECTION
AT LINE-SELECTION
AT PFnn
AT USER-COMMAND
Required elements
FORM
ENDFORM
343416319.doc
43

9.3
Header Documentation
9.3.1 Comment Box
This will need to be entered into the SAP system and used as the standard, you can find this
within SE38 -> Pattern -> Other Pattern > ZDOCHEADER.
************************************************************************
********************** INCLUDE ZDOCHEADER **************************
************************************************************************
************************* COPYRIGHT NOTICE *****************************
************************************************************************
*
*
*
(C) FEDERAL MOGUL COMPANY 2000
*
*
ALL RIGHTS RESERVED
*
*
*
************************************************************************
* System Name : FEDERAL MOGUL
Date: xx/xx/xxxx *
* Company Name : FEDERAL MOGUL COMPANY
*
* Developer Name :
*
*
*
* Program Name :
*
* Program Type :
*
* Transactions :
*
* Program Title :
*
*
*
*
Frequency :
*
*
*
* Ascendant ID :
*
*
Functional
*
*
Area :
*
*
Functional
*
*
Spec Name :
*
*
Technical
*
*
Spec Name :
*
*
*
* I/O File(s)
*
*
Input File:
*
*
Output File:
*
*
*
************************************************************************
*********************** PROCESS OUTLINE# *******************************
*
*
*
*
*
*
*
*
************************************************************************
********************* REVISION HISTORY OUTLINE *************************
*
*
* DATE
DEVELOPER
TRANSPORT NO.
*
*
*
* ___________
_________________
_____________
*
*
*
*
*
************************************************************************
********************* REVISION HISTORY DETAIL **************************
*
*
* TRANSPORT NO. REVISION NOTES
*
* _____________ ___________________________________________________ *
*
*
343416319.doc
44

************************************************************************
9.3.2 Goto Program Doc

All documentation should be maintained using the documentation feature through the menu toolbar
(Goto Program Doc). Enter the following details in the body of the banner.
Description: Lists and describes processing steps done in the program.
Precondition: Lists any input and processing that is necessary before executing the program.
Postcondition: Lists any output from the program.
9.3.3 Declarative Elements
ABAP variable names can be a maximum of 30 characters long for the DATA field.
SELECT-OPTIONS and PARAMETERS can be up to 8 characters.
When defining Data Fields, use clear and understandable names. When declaring elements, never leave type
and length as default values.
9.3.3.1
Constants
iC_xxxxxxxxxxxxxxxxxxxxxxxxxxx
i
=
global/local identifier (g=global;l=local)
C
=
the constant c
x
=
Descriptive variable name up to 27 characters. If the constant is declare LIKE an
SAP data DDIC element use that DDIC element as the descriptive variable name.
Example: The following would be the definition of a global constant for the SAP field SD document
number.
Constant: gc_vbeln like vbak-vbeln.
9.3.3.2
Internal Tables
iT_xxxxxxxxxxxxxxxxxxxxxxxxxxx
i
=
T
=
the constant t
x
=
Descriptive variable name up to 27 characters. If the table contains data elements
from a single database table then this database table should be referenced in the
descriptive name.
Example: The following would be the definition of a global internal table for the SAP table SD document
header (VBAK).
data: begin of table gt_vbak occurs 0.
Include structure vbak.
data: end of table gt_vbak.
9.3.3.3
Structures
iK_ xxxxxxxxxxxxxxxxxxxxxxxxxxx
i
=
K
=
the constant k (The letter K is used based on the German spelling struktur)
x
=
Descriptive variable name up to 27 characters. If the structure contains data elements
from a single database table then this database table should be referenced in the
descriptive name.
9.3.3.4
Parameters
p_xxxxxx
p_
=
343416319.doc
For Parameters
45

x
9.3.3.5
Descriptive parameter name up to 6 characters.
Select-options
s_xxxxxx
s_
=
For Select-options
x
=
Descriptive Select-option name up to 6 characters.
9.3.3.6 Variable Names

When declaring variable never default the type or length where required.
For global and local variables, which will be declared LIKE a standard SAP DDIC object, use the following
format:
i_<SAP DDIC NAME>
i
=
<SAP DDIC NAME>
=
Standard SAP DDIC name up to 30 characters.
Example: The following would represent a local variable for the SAP SD Document Number (VBELN):
l_vbeln like vbak-vbeln.
For global and local variable, which will be defined by the developer, use the following format:
iVt_xxxxxxxxxxxxxxxxxxxxxxxxxx
i
=
V
=
the constant V.
t
=
data type identifier. The valid variable types are noted below.
x
=
descriptive variable name up to 26 characters.
Example: The following would represent a global character variable with a length 4.
gvc_temp_id(4) type c.
Data Type Identifier
C
I
N
F
P
S
R
T
X
D
9.3.3.7
Data Type
Character
Integer
Numeric
Floating-point
Packed Decimal
String
Raw String
Time
Hexadecimal
Date
Types
iTY_xxxxxxxxxxxxxxxxxxxxxxxxxxx
i
=
T
=
the constant TY
x
=
number.
Types: gt_vbeln type vbak-vbeln.
343416319.doc
46

9.3.3.8
Field Symbols
<iF_xxxxxxxxxxxxxxxxxxxxxxxxxx>
i
=
F
=
the constant F
x
=
number.
Field-symbols: <gf_vbeln> type vbak-vbeln.
9.3.3.9
Classes
iCL_xxxxxxxxxxxxxxxxxxxxxxxxxx
i
=
CL
=
the constant CL
x
=
number.
Field-symbols: <gf_vbeln> type vbak-vbeln.
9.3.3.10 Forms
F_xxxxxxxxxxxxxxxxxxxxxxxxxx
F
=
the constant F
x
=
number.
Perform f_getorder.
9.3.3.11Method Parameters
Import Parameter:
I_xxxxxxxxxxxxxxxxxxxxxxxxxx
I
=
Import Parameter Constant
x
=
.
Export Parameter:
E_xxxxxxxxxxxxxxxxxxxxxxxxxx
E
=
Export Parameter Constant
x
=
Changing Parameter:
C_xxxxxxxxxxxxxxxxxxxxxxxxxx
C
=
Changing Parameter Constant
x
=
343416319.doc
47

Returning Parameter:
R_xxxxxxxxxxxxxxxxxxxxxxxxxx
R
=
Returning Parameter Constant
x
=
9.3.3.12
Form Parameters
P_xxxxxxxxxxxxxxxxxxxxxxxxxx
P
=
Always P Constant
x
=
.
9.4
Currency and Quantity Rules

The following rules should be followed when coding programs containing CURRENCY and QUANTITY
fields:
SAP Currency fields indicate that data type CURR uses 2 decimal positions. The defined decimal point
is not accurate (ignore it). The real decimal position is defined by the currency key field associated with
the currency field.
Example: Spanish currency (ESP) has no decimal positions. 125 ESP is stored in the SAP CURR
field as 1.25. $1.25 USD is stored in the SAP CURR field as 1.25. Currently, SAP allows 0 to 5
decimal positions.
All new fields for currency and quantity should be created as type CURR and QUAN, and have an
associated key field with type CUKY and UNIT, respectively.
When writing a report, use the CURRENCY and UNIT options with the WRITE command. Most moves
and mathematical commands are considered normal processing.
343416319.doc
48
10 Application Development Process for Development Objects
10.1 Purpose
The purpose of this chapter is to define the Application Development Process for Development Objects.
10.2 Overview
The following details the process through which objects are built and tested by the application
development team. A development object is defined as either:
Interface
Conversion
Extension
Report
Form
Table or other DDIC object
The process flow assumes that the work has been identified and approved by the appropriate people
(justification form), and begins with the development of the functional specification.
11 SAP Conversion and Interface Tool Selection Guidelines
11.1
Purpose
The purpose of the Tool Selection Guidelines chapter is to provide guidelines, not rules, in selecting the
proper tool(s) to transfer data to and from SAP.
11.2
Overview
There are many ways to construct conversion and interfaces in SAP. It is essential that good
programming and design practice be the primary consideration. The tools and techniques that will be
used in the development of conversions and interfaces will vary throughout the different phases of the
business object life cycle. It should also be noted that the duration of the object life will affect the
approach taken.
11.3
Terms used
The following terms are used in this section and should be defined for clarity of understanding in the
scope of transferring data into and out of the SAP application.
11.4
Approach
The general approach to be taken is to move legacy data to the UNIX platform for performing
Discovery/Validation, Consolidation, Reconciliation, and Coding and Testing. The rationale for utilizing
this approach is to reduce mainframe costs and to better resource management.
11.4.1 Discovery/Validation
The first phase of the life cycle of a business object that identifies and analyzes all data sources
and targets on which the Development Object is dependent. The main deliverables are
data dictionaries.
11.4.2 Consolidation
The second phase of life cycle of a business object that involves mapping the data sources to a logical
structure. This logical structure will act as a staging table when moving data to SAP. The main
deliverables are Technical Mapping Specifications, which will be completed during the Reconciliation
phase.
a)
Functional Specification
b)
Technical Map Specification (Word/Excel)
11.4.3 Reconciliation
The third phase of the life cycle of a business object that involves mapping SAP to the logical structure
and resolving any technical/functional business issues. What data will be passed and where it will go in
SAP will be defined here. The main deliverable here is a complete Technical Mapping Specification.
a)
Technical Map Specification (Word/Excel)
11.4.4 Design
The fourth phase of the life cycle of business object that identifies how the data will be passed to SAP.
The system information flow is defined here. The main deliverable is a complete Technical Design
Specification.
a)
Technical Design Specification (Word/Excel)
b)
See 11.6 SAP Inbound/Outbound Interface.
i)
ii)
iDoc/ALE
343416319.doc
50
iii)
iv)
v)
vi)
vii)
viii)
BAPI
Direct Input
BDC
Call Transaction
CATT
LSMW
11.4.5 Execution
The final phase of the life cycle of a business object where the deliverables of this phase are coded,
tested, documented and approved Development Objects.
a)
Scheduler (Open Issue)
b)
See 11.6 SAP Inbound/Outbound Interface.
i)
ii)
iDoc/ALE
iii)
BAPI
v)
BDC
vi)
CATT
ix)
LSMW
11.5
Legacy Extract
The general approach that is being taken is to extract the legacy data sources.
11.5.1 DB2
Unload DB2 tables using utilities. Keep in mind that packed/binary data will require formatting before
downloading to the UNIX. FTP will be used to transfer data to the UNIX platform.
11.5.2 Flat Files
If data contains any packed/binary data, reformat the data and then FTP will be used to transfer data to
the UNIX platform.
11.5.3 Microsoft ACCESS Data Bases
MS Access is an acceptable tool to use to format and manipulate data prior to conversions. If you are
using MS/Access, use a query to extract into a format that is readable by the conversion program taking
care to format the numeric fields. FTP should be used to transfer data to the UNIX platform.
11.5.4 Microsoft EXCEL Spreadsheets
In order to get data into a format that can be read on UNIX platform, SAVE the data in a Tab Delimited
file. If any additional transformations or reformatting (from packed/binary) is required, the mapping tool
can be used to generate code and FTP can be used to transfer data to the UNIX platform.
11.6
SAP Inbound/Outbound Interface

Once the SAP method for the conversion or interface has been selected, the mapping tools will be used
to facilitate the data transfer. The mapping transformation tool will be used for importing/extracting of data
into the SAP application when the method is one of the following (IDoc, BAPI, DX, or BDC).
343416319.doc
51
12 SAP Conversion and Interface Method Selection Guidelines
12.1 Purpose
The purpose of the Method Selection Guidelines chapter is to provide guidelines, not rules, for the use of
the various techniques to transfer data to and from SAP.
12.2 Overview
There are eight primary ways to construct conversions and interfaces to R/3 and four primary ways to
construct outbound interfaces. It is essential that good programming and design practice be the primary
consideration.
Conversions will have other considerations that will need to be considered over an on-going interface.
This is due to the volumes of data that will be handled in the conversions and the nature of the frequency
of execution.
The techniques in question for inbound conversions and interface development are:
1.
IDoc / ALE
2.
BAPI
3.
Data Transfer Programs
4.
Customized BDC
5.
CATT scripts
6.
Customized ABAP
7.
Call Transaction
8.
BADI
The four techniques for outbound interfaces are:
1.
IDoc/ALE
2.
ASCII Flat File
3.
BAPI
4.
HTML
12.3 Terms used
The following terms are used in this section and should be defined for clarity of understanding in the
scope of transferring data into and out of the SAP application.
12.3.1 ALE (Application Link Enabling.)
ALE supports the configuration and operation of distributed applications. There is no data retention. ALE
ensures data is distributed and coordinated using asynchronous communication. ALE uses synchronous
connections for reading data. The technology is based on business-event-controlled, time driven
exchange of business information messages. Message formats are either IDoc or BAPI based.
Release independent.
12.3.2 BAPI (Business Application Programming Interface)
Technology-independent business interfaces. Open business standard. The standard interface
facilitates the integration of R/3 with the processes and data of other business application systems.
Implemented as methods (functions) of an object in the Business Object Repository. The BAPIs are,
underneath, simply function modules. Error handling and the size of the logical unit of work are
controlled by the calling application. Release independent.
343416319.doc
52
12.3.3 BDC (Batch Input Session)

Processing of an online transaction in background processing using a formatted file in synchronous
mode (i.e. single dialog) Call Transaction. Error logs are generated and allows for good error control.,
but there is a cost to this because the dialogs are slow to execute. You can execute any SAP
Transaction using this method, but keep in mind that any screen maintenance will require maintenance
to the batch session definition also. The executions of these are slow and should be avoided for large
volumes.
12.3.4 Call Transaction (Synchronous or asynchronous execution)
Processing of an online transaction in foreground or background using a formatted file in synchronous
or asynchronous (multiple dialog / update only) mode. Has limited error control.
12.3.5 CATT (format = Z_CATT_xxxxxx_yy)
xxxxxx
yy
= the development object identifier (required)

= the sequence number of the script (use only if there are multiple scripts per object)
Examples:
Z_CATT_FIC203
Z_CATT_MMC023_1
Z_CATT_MMC023_12
(Computer Aided Test Tool)
An SAP tool that allows you to automate the testing screens in a batch mode. This testing is conducted
by describing the relevant screens in a test module and executing this transaction like batch input. The
tool allows you to execute the screens using data supplied from an external input file. This facility can
be used to import data into the application. Error logs are automatically generated when executing
CATT.
12.3.6 Data Transfer Program
Provides a standard format for data loads, and a single workbench for managing the execution of them.
Is not available for all Business Objects. Execution techniques vary for each object. Most support BDC
and/or Call Transaction approach. A few support Direct Input (high performance SAP-supplied ABAP
which validates data and directly updates required tables).
12.3.7 IDoc (Intermediate Document)
SAP standard that determines the structure and format of the data for electronic transmission, identical
for inbound and outbound processing, dependant only on message types, independent of External
System data requirements. Release independent.
12.4 Interface Guidelines
The guidelines for selecting an SAP interface solution are described in the following decision map:
343416319.doc
53
Data Migration
SAP Interface Options
Selection Guide
Identify an interface
Examine functional /
technical specifications
and requirements
Is a
useable BAPI
available?
(BAPI)
No
Is a
useable IDoc
available
(WEDI)
No
Is a Standard
Data Transfer Program
available?
(SXDA)
Yes
Yes
Yes
Develop using BAPIs
Develop using ALE /

IDocs
Develop using the SDT

Program
No
Develop a custom
solution
Will the interface

be triggered externally
(i.e. from outside SAP)?
343416319.doc
Yes
No
Develop an external
"push" mechanism (i.e
SysAdmiral, SAPEvent,
StartRFC)
Develop an internal
"pull" mechanism (i.e.
ABAP, Scheduled Job
Processing)
54
12.5
Conversion Guidelines
The guidelines for selecting an SAP interface solution are described in the following decision map:
Data Migration
SAP Conversion Options
Selection Guide
Identify a Conversion
Examine functional /
technical specifications
and requirements
Is it simple
(i.e. low volume,
could be done
manually)?
Yes
Develop using CATT
Yes
Develop using the SDT

Program
Yes
Develop using BAPIs
Yes
Develop using ALE /

IDocs
No
Is a
Standard Data Transfer
Program available?
(SXDA)
No
Is a
useable BAPI
available?
(BAPI)
No
Is a
useable IDoc
available
(WEDI)
No
Develop using ABAP

(RFC-enabled) code
Are the
data mappings simple
(i.e. do not require
data lookups within
SAP)?
Yes
No
Develop Mappings using

ABAP (LSMW)
343416319.doc
Develop Mappings
55
13 Forms Standards
13.1 Purpose
The purpose of this chapter is to illustrate the different ways to create new SAP Forms and the naming
standards to be used when the forms are created by SAPscript (Smart Forms).
13.2 Three Ways to Create SAP Forms
1)
SAP supplied ABAP
all information available on a form to meet business need
no changes necessary by anyone

2)
SAP supplied ABAP & layout set requiring minor changes
an existing ABAP or layout set is missing a few data elements to meet business need
the format of the existing SAP supplied form will primarily remain the same, except to
add new data so no major changes are made to the existing form
changes required are:
Copy SAP layout set (SAPscript) and make changes to have the layout set only
produce a data file from the ABAP's output (not the electronic form image with
data embedded in the form fields)
3)
No SAP supplied form exists or an existing SAP form needs major changes to meet business
need, changes required are:
Create new ABAP to gather necessary data elements for the form
13.3 Standard Text-ID (format = Zxxx)
Length: 4 characters.
x
Open
Example: ZMAX
SAP Transaction: SO10
13.4 Standard Text Name (format = Z_xxxxxx)
x
Open
Example: Z_TOT_MATL_COST
SAP Transaction: SO10
343416319.doc
56
13.5 Style (format = Z_xxxxxx)

x
Open
Example: Z_LARGE
SAP Transaction: SE72
13.6 SAPScript Layout Set Naming (Maximum 16 Characters)
Use the following format.
Zaxxxxxxxxxxxxxx
a
=
Application ID
x
=
Open
SAP Transaction: SE71
SAPScript layout sets can be used for organizing data on forms.
Following notations can be used when defining SAPScript layout set names:
SAP-supplied form:
Example: RVINVOICE01
SAPScript only forms: Z_< meaning name >
Example: Z_RVINVOICE01
The standard for SAPScript layout set names should have a meaningful name for program readability and ease
of maintainability. Whenever possible, try to link the user-defined SAPScript form name back to the SAPsupplied form name (like the example above) if you are making minor changes to an SAP-supplied form with
SAPScript. If you are not making minor changes to an SAP-supplied form, you may choose any meaningful
name.
343416319.doc
57
14 Reports Standards
14.1 Purpose
The purpose of this chapter is to illustrate the different ways of creating new SAP Reports and the
naming standards to be used followed by some recommendations.
14.2 Four Ways to Create SAP Reports
Note:
These are in order by preference as recommended by SAP consultants involved with the project. It is
up to the users working with their consultants to determine which reporting tool to select for generating
the new report.
1. SAP-supplied Standard Report
all information available on a form to meet business need
no changes necessary by anyone
2. Report Painter (not Report Writer)
similar to ABAP Query
generates ABAP code automatically (potential performance issue)
should be generated by experienced professionals (consultants, super users)
Useable by those with some experience (not restricted to super users)
user-friendly
little to no training necessary
3. ABAP Query
generates ABAP code automatically (potential performance issue)
development team or super user (preferable; need business knowledge)
user polite as opposed to user friendly
training required
4. Custom ABAP Program
Note:
Report Painter and ABAP Query are generally implemented as end-user tools and are currently being
evaluated by the Federal Mogul ERP Reporting Team. Any standards for Report Painter and ABAP
Query will be developed by the reporting team. The remainder of this chapter will deal with standards
for custom ABAP programs only.
14.3 SAP-Supplied Standard Default Formats (TRX=SPAD)

Note :
Always try to use the SAP supplied standard default formats for creating new SAP custom designed
reports. It is difficult to create new SAP formats for printing custom designed ABAP reports.
14.3.1 Background
SAP supplies standard default formats for printing all reports. These SAP formats are based on
different font sizes and the dimensions of the report (width/rows and length/columns). Depending on
how you define the width/rows (LINE-SIZE) and length/columns (LINE-COUNT) within your ABAP will
determine how SAP will interpret and apply a standard default.
The standard default SAP supplies to your report is done automatically when the report is sent to the
print spool. You can not tell SAP which standard default format to select. SAP will select the standard
default format which best matches an existing standard default format listed in SAP. This means
that if you do not set up the LINE-SIZE and LINE-COUNT variables in your ABAP correctly, your report
will probably not print out in the way you really wanted it to.
343416319.doc
58
14.3.2 Listing SAP Standard Default Formats Using TRX=SPAD

To obtain a list of SAP-supplied standard default formats, use transaction = SPAD (Spool
Administration). On the Devices/Servers tab, click on the Output devices button and double click the
device that you want to get SAP format information on. In the Spool Administration: Device Type
(Display) screen, click on the formats button. The standard default formats for printing reports all begin
with the letter X. For example, X_65_132. The 65 is the reports maximum number of rows/width
(LINE-SIZE) and the 132 is the reports maximum number of columns/length (LINE-COUNT). This
default will be chosen by SAP if your report is less than or equal to the total number of rows and
columns combined as long as another default format is not closer to your reports dimensions specified.
This default will not be chosen if your report requires more than 65 rows or more than 132 columns.
Rule:
Remember to specify your LINE-SIZE and LINE-COUNT variables as shown in the SAP standard
default formats that begin with the letter X or with variables that are less than or equal to those shown
in SAP under TRX=SPAD.
14.3.3 Standard LINE-SIZE and LINE-COUNT

Non-USA countries use the A4 paper type as a standard and the USA uses 8 x 11 paper as a
standard. The A4 paper is narrower and longer than the 8 x 11 paper. To make the same report
printable in both non-USA and the USA, you should use these standards for your ABAP variables in
your report:
ABAP Variables
LINE-SIZE
LINE-COUNT
Landscape
1 < 130 *
65
Portrait
80
65
*
It is possible to use a maximum LINE-SIZE up to 255 if a business need arises.
However, the small font size makes the report very difficult to read and the last page
number value gets truncated.
14.4 Standards for New ABAP Reports
1.
Non-USA countries use the A4 paper type as a standard and the USA uses 8 x 11 paper as a
standard. The A4 paper is narrower and longer than the 8 x 11 paper. To make the same
report printable in both non-USA and the USA, you should use these maximum standards for
your ABAP variables in your report:
ABAP Variables
Landscape
Portrait
343416319.doc
LINE-SIZE
1 < 130 *
80
LINE-COUNT
65
65
59
It is possible to use a maximum LINE-SIZE up to 255 if a business need arises.

However, the small font size makes the report very difficult to read and the last page
number value gets truncated.
2.
Using TRX=SPAD (Spool Administration), keep your LINE-SIZE and LINE-COUNT variables in
your ABAP less than or equal to the rows and columns specified in the SAP supplied standard
defaults that have names beginning with an X. See 14.3 SAP-Supplied Standard Default
Formats (TRX=SPAD) for more information.
3.
If LINE-SIZE > 80 means SAP will always print your report in landscape mode since SAP
thinks anything over 80 rows will require the report to be printed using the landscape format of
the form.
4.
Maintain all three titles and column headings as title text element fields. Do not hard code any
titles or column headings in your ABAP. The first line of every report is called the main title.
The second line of every report is called the report title and the third line of every report is
called the report sub-title.
14.5 ABAP to Print All Standard Report Titles

Note:
The remainder of this Chapter discusses the development of a standard module to print all report
titles, headings, etc. This activity is currently under review and the standard will be updated if/when
this module is developed.
14.5.1 How This ABAP Works
This ABAP uses a standard title algorithm to define the first two lines of the reports title on all reports
which is the main title and report title. The R/3 version has been optimized already to always perform
efficiently since this ABAP is called numerous times daily.
Using the same ABAP to produce report headings will keep all custom designed report titles
standardized and allow the development team to concentrate on the actual report itself. This also
allows easier report distribution since all appropriate information is in the same place. This is
particularly helpful if an automated distribution tool is used.
Variables passed to Zxxxxxxx:
COMP_CD
the company code used as the key to retrieve the company codes name for the main
title.
TITLE
the report title (recommend passing in SY-TITLE, which defaults to the report title
stored in the title text element).
CLASS-ID
the report classification which can be one of the following:
C
=
Confidential
R
=
Restricted
U
=
Unrestricted
Blank =
no security restrictions on report required
OPTIONS - ten (??) character value to use for future functionality.
1
=
reset the report page number to 1 (used today)
1X
=
*** For example only - future option not used today ***
use this option to reset page number to 1 and use X for a future option
like using a different company name in the main title on the first line of
the report or any other option that a business need may require in your
report title.
Since this program will handle the first two title lines of a report, the report sub-title (3 rd line) should be
stored as an ABAP title text element. The ABAPs title text element field is loaded into SY-TITLE when
the ABAP starts.
343416319.doc
60
The SY-TITLE field may be changed without changing the titles text element within the ABAP. One
example is using the FROMDATE and TODATE variables to display the range of dates the report used
to generate output (see 14.5.2 Standards for Report Titles). It is a great advantage to utilize SYTITLE because the SY-TITLE is also displayed as the screen banner on-line so the report looks the
same whenever displayed on-line or printed which is a very nice feature to have for our end users.
The maximum title length is stored in SY-LINSZ. For the first two titles that are automatically centered
on your report, the actual title length is calculated as: SY-LINSZ minus 24 (for date/time).
The maximum LINE-SIZE as specified in the REPORT command may be up to 130 characters for
landscape format and 80 for portrait (see 14.3 SAP-Supplied Standard Default Formats (TRX=SPAD)).
ZBSN0001 formats and writes the report title that includes the date, time, ABAP name, and page
number (see 14.5.3 Example of ABAP Using ).
14.5.2 Standards for Report Titles
Main Title - store as a title text element and Zxxxxxxx will center the title automatically on the first
line, display the date the report was run, and the ABAP name that created the report.
Report Title - store as a title text element and Zxxxxxxx will center the title automatically on the
second line, display the time the report was run, and the page number of the report.
Report Sub-Title - store as a title text element and you position the title on the report. Maximum
title length = 255. Use FROMDATE and TODATE to show a date range on the report sub-title when
applicable.
343416319.doc
61
14.5.3 Example of ABAP Using Standard Report Header

REPORT ZSDR0004
LINE-SIZE 65
LINE-COUNT 80
NO STANDARD PAGE HEADING.
<insert Federal Mogul header block, copyright, etc.>
*-------------------------------------------------------------------------*
*Define processing variables
*
*-------------------------------------------------------------------------*
data: first_page(1)
type c,
" Flag first page of report
comp_cd
like lika-bukrs,
fromdate
like sy-datum,
todate
like sy-datum.
*-------------------------------------------------------------------------*
* Start of processing.
*
*-------------------------------------------------------------------------*
start-of-selection.
write: 'From'
to sy-title+32(4),
fromdate
to sy-title+37(8) mm/dd/yyyy,
'To'
to sy-title+46(2),
todate
to sy-title+49(8) mm/dd/yyyy.
*-------------------------------------------------------------------------*
* At top of page, put out standard Dental header along with column
*
*-------------------------------------------------------------------------*
top-of-page.
perform zbsn0001_standard_header using comp_cd sy-title first_page.
*-------------------------------------------------------------------------*
* Include standard header routine.
*
*-------------------------------------------------------------------------*
INCLUDE ZBSN0001.
14.6 Open SQL versus Native SQL
SAP Open SQL will be used exclusively, except in the case of interfaces to external databases.
343416319.doc
62
15 IDocs
15.1 Purpose
This chapter describes the naming convention for partner profiles and ports.
15.2 IDocs (format= Zxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
Length: 30 characters
x
Open
15.3 IDoc Segments (format=Z1xxxxxx)

Z1
=
The characters Z1
x
=
Open
15.4 Process Codes (format=Zxxx)
x
Open
15.5 Partner Profiles Naming

Partner Type
KU (Customer)
LS (Logical System)
B (Bank)
LI (Vendor)

Partner Number
SAP Customer Number
Such as Sold-To party # (SP), Bill-To party #
(BP), Payer party #(PY), and Ship-To party #
(SH)
1. For SAP system clients:
Ex. D71120 where positions:
1 - 3 = box/machine,
4 - 7 = actual client #
2. For logically modeled systems or data
flows (i.e., systems with no crossapplication affect):
Ex. IO054_1033 or IO054KWI
Positions:
1 - 5 = Interface Specification Name
5 - 10 = Freeform Text (Country, plant, system
name, etc.)
Bank ID or Bank Number
SAP Vendor Number
Partner Profiles: Client Dependent. Note that the Partner Profiles will NOT be across clients. The
systems development resource is responsible for Partner Profile creation within each on the clients.
343416319.doc
63
15.6 Port Naming (File Port Type)

(Used by EDI.)
Major port names include:
Logical EDI subsystem name ( Ex. GENTRAN)
Interface # + abbreviated country name (Ex. IO113ES)
Interface # + 2 digits (Ex. IO11301)
SAP + box/instance (Ex. SAPD10)
Ports: Client Independent. Development team will be transporting.
15.7 Parameters for Outbound Files (used with File Port Type)
15.7.1 Directory
Option 1: Several Ports (file destinations). Could define several ports each having a more meaningful
directory name. The Benefits to this method include being easier to locate IDocs of a specific message
type, and less of a need to create a custom function module to further clarify the IDoc name. The
Drawbacks include more ports to maintain
Option 2: One Port (file destination). Could define just one port with one directory as in example above
(Ex. /xfer/D10/<import><export>/). The Benefits to this method include fewer ports to maintain. The
Drawbacks include may have more of a need to create a custom function module to clarify the IDoc
name for various message types.
15.7.2 Function Module
For outbound messages, the file name can be determined by a function module. The following function
modules are included with the standard version of SAP:
EDI_PATH_CREATE_DATE_TIME (Ex. O_19950809_171509)
EDI_PATH_CREATE_USERNAME_DT_TM (Ex. O_SAPUSER_(12
character)_19950809_171509
EDI_PATH_CREATE_CLIENT_DOCNUM
Note:
You can also implement your own function module to name an outbound file that is similar in structure
to the standard ones mentioned above. Do this by creating a custom function module that will
generate the filename, save and activate. Then via /nWEDI -> Control -> Generate File Names ->
Table View -> Change -> New Entries -> add FM to list and save.
15.8 Parameters for Command Files (used with File Port Type)
15.8.1 Automatic Start Possible
Determines whether the EDI Subsystem can be started from the SAP system. If this field is selected,
the logical destination is checked (select this field for EDI).
15.8.2 Logical Destination
Name of the RFC destination with whose description the Remote Function Call is controlled. This
destination is required and checked if automatic triggering has been selected.
15.8.3 Directory
The shell script that controls communication with the EDI subsystem is located in this directory. Specify
the full path name of the shell script (without the name of the script itself).
343416319.doc
64
15.8.4 Shell Script

Outbound IDocs are generated in the R/3 System and written to a file. The R/3 System triggers the next
step that is performed by the follow-on system: the C program rfcexec (Remote Function Code
EXECute) enables a shell script to be started which, in turn, notifies the follow-on system of the directory
and name of the new file and instructs it to read it.
15.9 Parameters for Inbound Files (used with File Port Type)
You do not need to maintain any values in the port definition for status data and inbound data since
these files are created by the EDI subsystem and their names are passed by it to the SAP System when
the C program STARTRFC is executed. Settings made here are always overwritten by the current
values received via STARTRFC. They therefore have no effect on the processing of status data and
inbound data.
15.10 Parameters for Status Files (used with File Port Type)
You do not need to maintain any values in the port definition for status data and inbound data since
these files are created by the EDI subsystem and their names are passed by it to the SAP System when
the C program STARTRFC is executed. Settings made here are always overwritten by the current
values received via STARTRFC . They therefore have no effect on the processing of status data and
inbound data.
15.11 Port Naming (Transactional RFC Port Type)
(Used by ALE. Not used by EDI.)
15.11.1 Port
Generated by the system. Number Ranges: Client Dependent. The Competency Center will be
maintaining these.
15.11.2 Port Description
Free form text.
15.11.3 Destination (RFC Destination)
Logical Logical System name (for ALE, ports can be created automatically for communication between
R/3 systems if the logical system and the corresponding RFC destination have the same name, via SAP
generator program). For communication with R/2 systems, EDI subsystems, and non-SAP systems you
have to create the ports manually.
15.12 Message Type
(format=Zxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
x
=
Open
343416319.doc
65
16 How to Handle Special Data Types in ABAP
16.1 Purpose
This chapter provides guidelines for handling date and currency fields in ABAP. The methods proposed
should eliminate the problems caused by different currencies having different numbers of decimal
places and by different user defaults.
16.2 User Defaults
The various user defaults allow the following options for date format (use System->User Profile->User
Defaults):
DD.MM.YYYY
MM/DD/YYYY
MM-DD-YYYY
YYYY.MM.DD
YYYY/MM/DD
and either a period as the decimal place indicator and a comma as the thousands separator, or a
comma as the decimal place indicator and a period as the thousands separator.
Incorrectly specifying these manually, or assuming a particular user default in your program, will lead to
program failure or worse, to bad data in the system. Bad data! For example the input 02031999 in a
date field will be converted by SAP to an acceptable date in either format DD.MM.YYYY or
MM/DD/YYYY, depending on the users default, but one of these will have the month and date swapped
around. Similarly, an incorrect decimal place can lead to incorrect data in the system: for example, the
value 123.45 appears on the database in a currency field: depending on the currency key, this can
represent different real values including 123.45 USD or 12,345 ESP.
In general the philosophy is to keep data unformatted until the last possible moment - until you write it to
the screen, or need to convert your data to character format for call transactions/BDC sessions.
Use move statement when creating outbound files because is removes the separators.
Example: move mseg-menge to mseg-menge.
Use write statements for spool, screen, report, or BDC sessions. Write statements will keep the
separators.
Example: write / mseg-menge unit mseg-meins.
16.3 Dates Defaults by country
User defaults need to be set to MM/DD/YYYY setting for the US. User Defaults for other countries will
be set to the specific country requirements. When accessing data on custom developed objects, ensure
that the user defaults are read and the format of the date is set to the users own defaults.
16.3.1 Inbound
Always convert a character date from the format specified in the input file to the SAP internal format
YYYYMMDD. If storing in a Z table the data element should also be of this format. Never store a date
in a transparent table or use as an internal variable in its character format such as 10/26/1997 - always
use the internal format 19971026. Fields to use include syst-datum, vbak-erdat etc. that are stored as
type DATS in the data dictionary.
343416319.doc
66
If the inbound date does not contain the century use the function Z_CENTURY_CONVERT (to be
developed if required).
16.3.2 Outbound
When writing to the screen or to a character variable for input into a call transaction or bdc session, use
the write statement without an edit mask. This will ensure that the date is formatted correctly for the
current user.
Write:
/ Todays date is(001),

syst-datum.
where text element 001 contains the text Todays date is.
16.4 Amount/Currencies (the number of decimals issue)
16.4.1 Inbound
Read the character field containing the amount from the file into a character. When the character field is
formatted correctly according to its currency (see function Z_INBOUND_TO_SAP_CURRENCY below) we will
move it to a variable defined LIKE a standard SAP currency variable which is linked to a currency key variable.
You will have to determine the number of decimal places on the file. Remember that all currencies are stored on
the data base in these fields exactly as they are, ie
USD:
1234.56
stored as 1234.56
ESP
78901
stored as 789.01
even in the case of 0 decimals (such as Spanish Pesetas shown) a decimal place is rudely inserted in the
second place.
16.4.2 Outbound
The write statement will include a thousands separator (either a comma or a period depending on the user
defaults) in the number eg 1,005.23 USD. There may be circumstances when you need only the number with
the decimal place indicator - such as when writing to a file which requires that format, or when storing the
number in SAPs IDoc structures. To remove the thousands separator use the SAP supplied function
CURRENCY_AMOUNT_SAP_TO_IDOC.
16.5 Amount/Currencies (the decimal place/thousands separator issue)
16.5.1 Inbound
Inbound amounts should not have a thousands separator or a decimal place indicator. Any amounts from Z or
SAP tables should be stored as currency and associated with a currency key. So the user default values for the
decimal place indicator/thousands separator should have no impact on your processing.
343416319.doc
67
16.5.2 Outbound
When writing to the screen or to a character variable for input into a call transaction or BDC session, use the
write statement with the currency option, followed by the currency:
* Write the currency field and its currency.
WRITE: / This is the amount:(001),
Z0028-KBETR CURRENCY Z0028-WAERS,
Z0028-WAERS.
where text element 001 contains the text This is the amount:. This will ensure that the amount is formatted
correctly for the current user.
16.6 Quantities (the decimal place/thousands separator issue)
16.6.1 Outbound
When writing to the screen or to a character variable for input into a call transaction or BDC session, use the
write statement with the unit option, followed by the unit:
* Write the unit field and its unit of measure.
WRITE: / This is the unit of measure:(002),
mseg-menge unit mseg-meins.
343416319.doc
68
17 Authorization Checks Work In Process
17.1 Purpose
The purpose of this chapter is to provide guidelines for the use of the Authority Check instruction and
transaction level authorizations in developing new code objects.
17.2 Authorization Checks
If you wish to protect a transaction that you have programmed yourself, then you must implement an
authorization check. Authorization checks can be implemented in two ways:
associate an authorization object with a transaction using Transaction SE93. No programming is necessary
to create this type of authority check. If you set up a Transaction Level authority check, then a users
authorization to a transaction is tested when the transaction is started.
program authorization checks in ABAP programs with the AUTHORITY-CHECK instruction.
17.2.1 Authorization Checks: Table TSTC
SAP recommends that you specify an authorization object that is already tested within the transaction.
However, you can associate any authorization object with a transaction in table TSTC using Transaction SE93.
If there is no suitable authorization object for a transaction that needs protecting (see the Authorization Group),
you can set up an authorization object and fields yourself. If you do so, select class names that begin with Z to
avoid conflicts with SAP names. You also specify the values that a user must have to pass the authorization
check. The system permits a user to select the function or run the transaction only if the user has an
authorization for the values you have specified.
The system performs an authorization check that is recorded in table TSTC only when the transaction is called
directly. A transaction is called directly when a user enters the transaction in the command field or selects a
menu entry that calls the transaction (the ABAP START TRANSACTION statement).
The Transaction Level authorization check is not carried out when the transaction is called indirectly, from
another transaction. Authorization is not checked, for example, if a transaction calls another with the CALL
TRANSACTION instruction. Authorization is also not checked for parameter transactions.
If you are programming a critical transaction, then you should always include an AUTHORITY-CHECK statement
in your code. Do not rely solely upon a Transaction Level authority check (i.e., in table TSTC).
343416319.doc
69
18 SAP Requests Naming Convention
18.1 Purpose
The purpose of this chapter is to describe in detail the naming convention of the Changes Request Text field.
This naming convention should be used to populate the Short Description field on the Create Request screen
within transaction SE09 and SE10, when creating customizing or workbench transports.
Syntax:
<Implementation>-<Functional Area>-<Request-Type>-<DCD/IDD/EDD/RDD/LSD/COE number>-<Free
text>
<Implementation>
GL
Global Release
XXX
3 Digit Country Code
OSS OSS Notes
NT
DO NOT TRANSPORT TO PRODUCTION!!!
<Functional Area>
AR
Accounts Receivable
BI
Billing
SD
Sales Order Processing
COD Contracts, Orders and Deliveries
CCMD Contracts to Cash Master Data
CO
Controlling
MA
Manage Assets
GLT
GL/Reporting/Tax
HRL
HR/Labor
TR
Treasury
MP
Manage Projects
AP
Accounts Payable
PO
Procurement
RC
Receiving
RF
Radio Frequency
MD
Master Data
BC
Common tools (e.g. cross team customizing (e.g. Basis tables for EDI), Sys Dev Utilities)
BW
Business Warehouse
WM
Warehouse Management
IM
Inventory Management
WF
Workflow
<Request-Type>
C
Customizing (Client dependent)
W
Workbench objects
<DCD/IDD/EDD/RDD/LSD/COE number>
Reference the relevant Enhancement, Interface, Report, Layout Set or Conversion Toolset document number for
development requests.
Reference the Configuration Element document number for configuration
<Free text>
343416319.doc
70
Useful and descriptive information about the transport request. If this is a modification to a SAP object, ensure
that you have the phrase SAP Object in the description and the corresponding OSS note number.
Examples:
NE-CCMD-W-DCD0010- Customer master conversion
NE-PRO-C-COE2010- XK01 Create Vendor Master Data config .
343416319.doc
71
19 Frequently Used Transaction Codes
19.1 Purpose
The purpose of this chapter is identify key SAP transaction codes used primarily for systems development.
19.2 Frequently Used Transaction Code Table
Transaction
Name
Purpose and/or Menu Path
AL11
Files
Directories and files
BAPI
BAPI Browser
Business application programming interface browser
BALE
ALE Main Menu
Application link enabling main menu
BD64
Maintain Distribution
The model describes ALE flows between logical
Model
systems
BD87
Reprocessing IDoc
Inbound Reprocessing IDoc
BD88
Reprocessing IDoc
Outbound Reprocessing IDoc
BD64
Maintain Distribution
The model describes ALE flows between logical
Model
systems
FILE
Logical Files
Associate logical files with physical files
S001
ABAP Workbench
SA38
Reporting
Run a Program: System > Services > Reporting
SALE
ALE Configuration
Basic settings, Distribution, Interface, Communication,
etc.
SCAT
CATT
System/Services > CATT > Edit
SD11
Data Modeler
Tools > ABAP Workbench > Development > Data
Modeler
SE01
Tools
Requests/Search for Requests/Tasks
SE09
Workbench Organizer Viewing Change Requests, Also SE10
SE10
Release Transports
Change Requests, Tasks,
SE11
ABAP Dictionary
Creating Maintenance Dialogs, > select Change Table
> Environment/Tab. Maint. Generator > Group
(should be a unique newly created group)
SE16
Data Browser
View Table Contents, Tools/ABAP Workbench,
Overview/Data Browser
SE30
RunTime Analysis
System > Utilities Runtime analysis > Execute
Tools > ABAP Workbench > Test > Runtime
Analysis
SE36
Logical Database
Tools > ABAP Workbench > Development >
Program Environment > Logical Database
SE37
Function
Tools > ABAP Workbench > Function Library
Library/Builder
SE38
ABAP Editor
Changing Development Class (for Programs), SE38 >
Program/Reassign
SE39
Split Screen Editor
SE41
Menu Painter
Tools > ABAP Workbench > Overview > Workbench
Organizer
SE51
Screen Painter
Tools > ABAP Workbench > Screen Painter
343416319.doc
72
Transaction
Name
SE71
SE80
Sapscript Form
Object/Repository
Browser
Repository
Information System
Message Handling
Maintain Transactions
Record Batch Input
Overview of Users
Lock entries
System Log
Data Browser
Table Maintenance
Batch Session Input
Background Jobs
SE84
SE91
SE93
SHDB
SM04
SM12
SM21
SM30
SM31
SM35
SM37
SM50
SM59
Work Process
Overview
RFCs
SO01
SAP Inbox
SO10
SOLO
Sapscript Standard
Text
OLE Object Browser
SPAD
SPRO
Spool Administration
Enterprise IMG
ST05
ST22
SU53
SW01
WE05
WE19
Performance Trace
Dump log
Screen Print
Business Object
Builder
Business Object
Browser
Data Transfer
Workbench
IDoc Monitor - Viewer
Test IDoc tools
WE20
WE21
IDoc Partner Profile

IDoc Port Definition
WE30
WE31
WE60
WE47
WE61
WEDI
IDoc Editor
Segment Editor
IDoc Types
Display Status Codes
IDoc Record Types
IDoc, EDI Main Menu
SW02
SXDA
343416319.doc
Purpose and/or Menu Path

Changing Development Class (Tables, Domains,) >
Dictionary Objects/Edit. Development Object/Reassign
> Programming > Programming Environment >
Transactions > <all transaction codes table TSTC>
message class = ZZ with value of [I | W | E | A | X | S]
associate an authorization object with a transaction
disconnect your sessions through this
View/Maintain/Transport Table Contents
Display/Maintain/Customize
Tools > Administration > Monitor > Batch Input
Creating a Function Group > Function Groups >
Create Function Group
Tools/Administration. Administration/Network>RFC
destinations
Tools/SAP Business Workflow> Development>
[Integrated Inbox | Office/Inbox | IDoc > IDoc button]
ABAP Workbench, Development/Programming environ
> OLE2 > Object Browser > OLE stuff
List SAP Std default formats > paper types > display
Tools > ABAP Workbench > Development >
program > Environment > logical database
For attachment of a TPR to the PwC Toolkit
status of inbound/outbound IDoc activity (also WE02)

IDoc menu > Test > test tool, Partner Profiles >
IDoc menu > Partner
Maintain the partners with whom you communicate
Definition for RFC, File Interface, R/2 System, or
Internet
Documentation for IDoc Types
Documentation for IDoc Record Types
Tools/Administration, Administration/Process
Technology, IDoc/IDoc Basis (Could also get to Inbox
from this screen)
73
20
Index
A
ABAP errors, 36
ABAP Query, 57
ABAP Report Code, 43
ACCESS Data Bases, 50
ALE, 51
Amount/Currencies, 65
APPEND, 40
AUTHORITY-CHECK, 67
Authorization Checks, 67
F
Flat Files, 50
Form, 48
H
Header Documentation, 44
I
B
BAPI, 51
BDC, 52
IDoc, 52
IDoc / ALE, 51
IDoc Segments, 61
IDocs, 61
Interface, 48
C
Call Transaction, 52
CALL TRANSACTION, 67
CATT, 52
CATT scripts, 51
Closing the Spool, 38
Consolidation, 49
Conversion, 48
currencies, 64
Currency and Quantity Rules, 47
Custom ABAP Program, 57
Customized ABAP, 51
Customized BDC, 51
D
Data Classi, 30
Data Ele, 30
Data Element H, 28
Data File N, 32
Data Transfer Program, 52
Data Transfer Programs, 51
date format, 64
Dates, 64
DB2, 50
decimal places, 64
Declarative Elements, 45
Design, 49
Discovery/Validation, 49
Do, 31
E
errors, ABAP, 36
EXCEL Spreadsheets, 50
Execution, 50
Extension, 48
343416319.doc
L
Legacy Extract, 50
Logical Destination, 62
LOOP, 40
M
Medium Field, 28
message class, 36
Message Types, 37
Method Selection, 51
O
OCCURS, 40
P
Partner Profiles, 61
Port Naming, 62
Pretty Printer, 41
Process Codes, 61
R
R, 30
RAISE EXCEPTION, 41
READ, 40
Reconciliation, 49
REFRESH, 40
Report, 48
Report Painter, 57
Run-Time Analysis, 41
74
S
SAP Forms, 55
SAP Inbound/Outbound Interface, 50
SAP Reports, 57
SAPScript, 56
SAP-supplied Standard Report, 57
SELECT, 40
SELECT INTO, 40
Shell Script, 63
Short Field, 28
SM30, 25
SQL, 60
Stru, 26
Table Field, 28
Transaction, 70
U
UNIX Data, 32
UNIX Data Directories Stru, 32
Use of Internal Tables, 40
V
View, 26
Z
ZTEMPLAT, 43
t, 25
343416319.doc
75
CHANGE RECORD (note that section numbers may change with each revision)
Date
01/12/2004
Authors &
Tom Marshall
Reviewers
Version
2.1e
Change Reference See ICMS Amendment Appendix, referred to as
ICMS Development Standards Amendment_2.1e.
Date
Authors &
Reviewers
Version
Change Reference
Date
Authors &
Reviewers
Version
Change Reference
Date
Authors
Version
Change
References
Reviewers
Date
Authors
Version
Change
References
Reviewers

ABAP Development Standards

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ABAP Development Standards

Caricato da

Copyright:

Formati disponibili

Program Everest

SAP Development Standards

SAP Development Standards

1 Introduction Use of Standards............................................................7

2 How to Change SAP R/3 Development Standard.................................9

SAP Development Standards

5 Data File Naming Standards................................................................32

6 ABAP Message/Error Handling Standards.........................................36

7 ABAP Improve Efficiency Standards..................................................40

SAP Development Standards

8 Standard Include Programs..................................................................42

9 ABAP Program Structure/Organization.............................................43

Purpose Patterns for header............................................................................43

Application Development Process for Development Objects........48

SAP Conversion and Interface Tool Selection Guidelines.............49

SAP Conversion and Interface Method Selection Guidelines.......51

SAP Development Standards

How to Handle Special Data Types in ABAP..................................64

SAP Development Standards

Authorization Checks Work In Process.......................................67

SAP Requests Naming Convention..................................................68

Frequently Used Transaction Codes................................................70

1 Introduction Use of Standards

Migration into a production environment

SAP Development Standards

SAP Development Standards

Uncontrolled Copies, Standard Users Responsibility

SAP Development Standards

SAP Development Standards

Naming Standard Summary Table

SAP Object Type

Batch Job Requests

ABAP Module Pool

SAP Development Standards

SAP Object Type

= Process on Help Routines

Function Key Codes

Parent screen # plus 1

the development object identifier

3.4.1 ABAP Program Structure

SAP Object Type

3.4.2 SAP Dictionary Objects

SAP Object Type

Open (limit to two for Control

SAP Development Standards

3.4.3 Form Specific Standards

Standard Text Name

SAP Development Standards

3.4.4 ALE/EDI Specific Standards

See Section 15.6

3.4.5 Project Enhancement Specific Standards

SAP Object Type

3.4.6 Workflow Specific Naming Conventions:

ZWO + ShortDesc (7 chars)

ZWIF + ShortDesc (6 chars)

SAP Development Standards

ZWK + ShortDesc (17 chars)

ZWAab + ShortDesc (15 chars)

ZWMabc + ShortDesc (24 chars)

ShortDesc - Short description of method (25 chars)

Object )Method ABAP Reports)

Z_WF + ShortDesc (26 chars)

ZWP + ShortDesc (5 chars)

ZWD + ShortDesc (27 chars)