Académique Documents
Professionnel Documents
Culture Documents
Introduction..........................................................................................................7
Scope....................................................................................................................7
Applicability........................................................................................................7
This Document.....................................................................................................8
Hypertext Links...............................................................................................8
Naming Format in this Document....................................................................8
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
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
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
Purpose...............................................................................................................40
Use of Internal Tables........................................................................................40
ABAP run-time Analysis...................................................................................41
343416319.doc
Pretty Printer......................................................................................................41
Following Is Not Allowed..................................................................................41
the COLLECT command...................................................................................41
Purpose...............................................................................................................42
Program to Print Header Information in a Report - TBD..................................42
10
10.1
10.2
11
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
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
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
343416319.doc
17
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
Index...................................................................................................72
343416319.doc
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:
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.
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.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
343416319.doc
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
3.4
Inbound Interfaces
Outbound Interfaces
System Maintenance
Include program
Report
SAPscript
User Exit/Enhancement
Temporary, Demo or Test programs
Length
ABAP Programs
30
ABAP Report
Variants
Development Class
14
3.7.1
Function Groups
3.7.2
Function Modules
30
3.8.1
32
3.8.2
Batch Input
Sessions (BDC
Sessions)
Messages classes
12
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
Length
Naming Convention
MzannHxx
MzannVxx
3.10.3
Dynpros (Screens)
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
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
Z_CATT_xxxxxx_yy
xxxxxx
=
yy
Lengt
h
30/8
Naming Convention
See section 9.3.3
4.2.2
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
=
12
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
Length
13.4
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
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
Length
8
8
Naming Convention
Zppppnnn
pppp
n
Zppppnnn
pppp
n
=
=
Project Area
Numeric Sequence
=
=
Project Area
Numeric Sequence
Component of
Workflow
Object - Type name
Length
Naming Convention
10
Object (Interfaces)
10
343416319.doc
14
20
Object (Attributes)
20
Object (Methods)
30
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
30
Object (Method
ABAP Programs
(Other))
Object (Method
Transaction)
Object (Method
Dialog Modules
ABAP)
ZW + 2 chars
30
Object (Events)
20
343416319.doc
15
Standard Tasks
12
Customer Tasks
12
MULTI-STEP TASKS
Workflow Templates
12
Workflow Tasks
12
CONTAINER
ELEMENTS (field
names)
32
STANDARD ROLES
12
Standard Roles:
Function module
343416319.doc
30
16
12
12
12
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
= Open
Examples:
3.6
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
JOBS
3.8.1 Batch Job Names
(format = Z_b_a_xxxxxxxxxxxxxxxxxxxxxxxxxx)
Length: Up to a maximum of 32 characters
Z
Application ID
343416319.doc
Description
On request
Yearly
Quarterly
18
Monthly
Weekly
Daily
Nightly
Hourly
Event-Driven
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
=
=
=
Application ID
description of the class
Menu painters
DDIC references and objects
343416319.doc
19
PAI modules
PBO modules
Perform modules
-------->
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
For logical database module pools, use the last three characters for the logical database name.
343416319.doc
Naming convention
MZannTOP
MZannOxx,
- Open
ZannIxx,
- Open
MZannFxx,
- Open
MZannHxx,
- Open
MZannVxx,
- Open
20
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
21
3.12.2 Enhancements
(Format = Zppppnnn)
Z
pppp
n
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
Enhancement
ZSALS001 AD010001
SAP Include
EXIT_SAPLAD13_001
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
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
Data Transported
No, data updated manually
or an ABAP
Yes, from Development
System/Gold client, client
dependent
Application ID
Open
343416319.doc
25
Application ID
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
Application ID
xxxxxxx
A meaningful description
Example: ZMVPRCHASE
343416319.doc
26
343416319.doc
27
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.
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.
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
343416319.doc
30
343416319.doc
31
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
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
<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
<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
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
343416319.doc
35
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
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
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
38
343416319.doc
39
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
75.769
42.138
12.597
50%
100%
130.504
=
=
=
58,1%
32,3%
9,7%
= 100,0%
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
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.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
343416319.doc
42
9.1
343416319.doc
43
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
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
=
global/local identifier (g=global;l=local)
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
=
global/local identifier (g=global;l=local)
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
Select-options
s_xxxxxx
s_
=
For Select-options
x
=
Descriptive Select-option name up to 6 characters.
9.3.3.7
Data Type
Character
Integer
Numeric
Floating-point
Packed Decimal
String
Raw String
Time
Hexadecimal
Date
Types
iTY_xxxxxxxxxxxxxxxxxxxxxxxxxxx
i
=
global/local identifier (g=global;l=local)
T
=
the constant TY
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.
Types: gt_vbeln type vbak-vbeln.
343416319.doc
46
Field Symbols
<iF_xxxxxxxxxxxxxxxxxxxxxxxxxx>
i
=
global/local identifier (g=global;l=local)
F
=
the constant F
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.
Field-symbols: <gf_vbeln> type vbak-vbeln.
9.3.3.9
Classes
iCL_xxxxxxxxxxxxxxxxxxxxxxxxxx
i
=
global/local identifier (g=global;l=local)
CL
=
the constant CL
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.
Field-symbols: <gf_vbeln> type vbak-vbeln.
9.3.3.10 Forms
F_xxxxxxxxxxxxxxxxxxxxxxxxxx
F
=
the constant F
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.
Perform f_getorder.
9.3.3.11Method Parameters
Import Parameter:
I_xxxxxxxxxxxxxxxxxxxxxxxxxx
I
=
Import Parameter Constant
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.
.
Export Parameter:
E_xxxxxxxxxxxxxxxxxxxxxxxxxx
E
=
Export Parameter Constant
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.
Changing Parameter:
C_xxxxxxxxxxxxxxxxxxxxxxxxxx
C
=
Changing Parameter Constant
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.
343416319.doc
47
9.3.3.12
Form Parameters
P_xxxxxxxxxxxxxxxxxxxxxxxxxx
P
=
Always P Constant
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.
.
9.4
343416319.doc
48
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.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
343416319.doc
51
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
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
No
Develop a custom
solution
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
Yes
Yes
Yes
No
Is a
Standard Data Transfer
Program available?
(SXDA)
No
Is a
useable BAPI
available?
(BAPI)
No
Is a
useable IDoc
available
(WEDI)
No
Are the
data mappings simple
(i.e. do not require
data lookups within
SAP)?
Yes
No
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
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
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)
Length: 32 characters.
x
Open
Example: Z_TOT_MATL_COST
SAP Transaction: SO10
343416319.doc
56
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.
58
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.
343416319.doc
LINE-SIZE
1 < 130 *
80
LINE-COUNT
65
65
59
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.
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
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
Open
LS (Logical System)
B (Bank)
LI (Vendor)
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
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
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)
Length: 30 characters
x
=
Open
343416319.doc
65
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:
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.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.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.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
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
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