DEVELOPMENT STANDARDS (v2 2011)

Rich Products Corporation
SAP Development Standards
Document Information
Purpose:
Provide standards for development in SAP R/3 and related systems at Rich Products Corporation
Last Saved: 25 June 2018, 11:12 AM

Version History:
Version Number Date Released Updated by Description of Change
1.00 1 July 2002 Development Standards Project Team Initial release
2.00 23 June 2011 Rebecca Wells (Nelson) Update/overhaul to coincide with
upgrade to ECC 6.0
2.01 09 Aug 2011 Rebecca Wells Fix job naming standard to start new
number range with “0100” not “1000”
SAP Development Standards Rich Products Corporation Page iii
Table of Contents
Document Information........................................i
Table of Contents...............................................iii
Introduction.........................................................1
Implementation policy.................................................1
Communication plan...................................................1
Process for updating standards....................................1
Enforcement process...................................................1
ABAP....................................................................3
Naming Standards.......................................................3
Programs 3
Function Modules 3
Variables 3
Subroutines (Forms) 4
Variants 4
Documentation Standards............................................4
Internal 4
External 5
Best Practices..............................................................6
Source Code Content 6
Source Code Layout 6
Optimization 7
Security 8
Copying SAP programs 8
Variants 8
Program Attributes 9
Text Elements 9
Tips & Tricks..............................................................9
Templates..................................................................10
Data Dictionary.................................................11
Transparent Tables....................................................11
Naming 11
Documentation 11
Best Practices 11
Fields.........................................................................12
Naming 12
Documentation 12
Best Practices 12
Views........................................................................12
Naming 12
Documentation 13
Best Practices 13
Structures..................................................................13
Naming 13
Documentation 13
Best Practices 13
Data Elements...........................................................13
Naming 13
Documentation 13
Best Practices 14
S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

SAP Development Standards Rich Products Corporation Page iv
Domains....................................................................14
Naming 14
Documentation 14
Best Practices 14
Search Helps..............................................................14
Naming 14
Matchcodes...............................................................15
Lock Objects.............................................................15
Naming 15
Best Practices 15
SAPScript...........................................................17
Naming Standards.....................................................17
New development 17
Copies of SAP Standard SAPScripts and ABAP 17
Windows 17
Paragraph and Character Formats 17
Documentation Standards..........................................17
Internal 17
External 17
Best Practices............................................................18
Multi-lingual development 18
Identifying TEST output 18
Loading graphics with RSTXLDMC 18
Windows 19
Header information 19
Using Text Elements 19
Choosing and using text editors 19
Templates..................................................................20
CATT.................................................................21
Test Modules 21
Parameters 21
Internal 21
External 21
Best Practices............................................................22
When to use CATT 22
Types 22
Language-independence 22
Parameters 22
Tips & Tricks 23
Templates..................................................................24
Recording a CATT 24
Creating a CATT manually 24
Modifying a CATT manually 25
Interfaces...........................................................27
Non-Mercator............................................................27
Data Files 27
Log Files 30
Mercator....................................................................31
Data Files 31
Log Files 36
Trace Files 36
Map Files 37

Page v of lxi Rich Products Corporation SAP Development Standards
Transaction Codes............................................39
Internal 40
External 40
Communication 40
Best Practices............................................................40
Security 40
Tips & Tricks 41
Templates..................................................................41
Transport Requests...........................................43
Naming......................................................................43
Documentation..........................................................43
Documenting Tasks and Requests 43
IS Change Management 43
Best Practices............................................................43
Cleaning Up Obsolete Transports 43
Monitoring Transports 44
Security 45
Creating Change Requests 45
Documenting Contents of Customizing Transports 45
Tips and Tricks 45
Templates..................................................................46
Transport Policy and Procedure 46
Transport Request Form 46
Batch Jobs..........................................................47
SAP Jobs...................................................................47
Naming Standards 47
Best Practices 47
UNIX Jobs (Scripts)..................................................48
Naming Standards 48
Job Schedules....................................................51
UC4 Applications......................................................51
Naming Standards 51
Documentation Standards 51
Templates..................................................................51
Batch Job Documentation 51
Appendix............................................................53
Reference Materials...................................................53
Business Application Components 53
Development Classes 55
SAP Development Standards Rich Products Corporation Page 1 of 6155
Introduction
This document contains the standards for development that is within or related to SAP R/3 at Rich Products. These standards
are to be followed by all developers in this environment, whether permanent associates, long-term contractors, or temporary
consultants.
This document is organized first by development object (ABAP, Batch Job, etc.), and then by development components. The
main four components are:
 Documentation Standards
 Naming Standards
 Best Practices
 Templates
These apply to nearly every object type. Other components are covered for objects where they are deemed applicable by the
Standards Committee.
Implementation policy
This document pertains to all future development. That is to say that existing development is not required to meet the
standards at this time. However, when a developer modifies an existing development object, they should consider updating
the entire object to meet the standards. Whether or not to update the entire object is at the discretion of the developer or
analyst, and should be determined based on the time, effort and value of bringing the object into compliance.
This document must be distributed to all developers in R/3 or related systems at Rich Products Corporation. New
developers/consultants should be given this document when (or before) they receive their SAP access.
This document will only be distributed in English. If a developer has difficulty understanding this document, pertinent
areas should be explained to them, and the peer reviewer should more closely evaluate compliance with the standards.
Communication plan
This document will be submitted for review by the entire ERP Competency Center team prior to major updates (including
the initial release). An update will be considered “major” if any sections are vastly different from the previous release, or
if dissent to some of the changes can be expected. The review time will not be less than 1 week (5 business days), during
which time the team is requested to thoroughly read the document and submit requests or recommendations for changes.
New releases of the document will be communicated via email to the entire team, including any consultants and interns. A
read-only copy will be available on the ABAP Team’s SharePoint page (www.OneRichs.com > IS > NACC > SAP ABAP >
SAP General Documents )Changes to the standards document are effective immediately upon [post-review] distribution to
the team.
Process for updating standards

Changes to this document will be issued at most once per quarter.
Requests/recommendations for changes may be submitted to the Standards Committee or the SAP AD Manager at any
time. These will be reviewed at least once per quarter by the Standards Committee, which reserves the final say as to
inclusion of changes in the Standards Document.
Enforcement process
These standards will enforced via the Peer Review process. Failure to comply may mean that developments are not cleared
for release or import to the Production R/3 system.

ABAP
Naming Standards
Programs
SAP allows ABAP names up to 40 characters in length. Program names can contain letters, numbers, underscores (_),
etc. Program names may not contain spaces ( ), plus signs (+) or asterisks (*)
Programs beginning with a “Z” or “Y” are considered to be in the customer namespace. This prevents SAP from
overwriting or altering the program during upgrades or hotpack installations. At this time, Rich Products does not use
the “Y” namespace. All RPC development should start with “Z”.
New development
The first 8 characters of the program name must be a unique identifier of the program. This facilitates program
identification in, for example, report headers. The remaining 32 characters may be used to describe the program’s
purpose.
The name should follow this format: ZTAAUUUU_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, where:
 Z – literal “Z” which starts all RPC programs
 T – the program type, as follows:
 C Conversion – is used for one-time data imports from a legacy system (NOT an
interface)
 E Enhancement – enhances or expands SAP functionality, such as a User Exit
 I Inbound interface – is run repeatedly, to import data from an external system.
 N Include member – cannot be executed directly, but is called by other programs
 O Outbound interface – is run repeatedly, to export data to an external system
 P Update/Process – performs a database update or a process
 R Report – reads and examines data, but does not update (**this code is
frequently used)
 U Utility – performs system maintenance functions (informational or update)
 AA – a two-letter code for the Business Application Component. See the Appendix for
available codes.
 UUUU – a 4-digit unique numeric identifier. The next available number should be used for new
development.
 XXX… – a meaningful description of the program’s purpose.
Should include the Business Application Sub-component (see Appendix), where applicable.
EXAMPLE:
ZCCO0001_PA_LOAD_PREP follows both the SAP & RPC standards. The sub-component (PA –
Profitability Analysis) is also referenced in the name.
Copies of SAP programs
When copying a standard SAP program, the same name should be used for the copy, but insert a “Z” at front of the
program name to identify it as a customer program. For example, standard check printing program RFFOUS_C is
copied to ZRFFOUS_C, RPC changes are then made in ZRFFOUS_C.
Function Modules
A function module can have any name, up to 30 characters. It must be unique within the Function Builder and can
consist only of alphanumeric characters and the underscore “_”.
All RPC created function modules should begin with “Z_”. The remaining 28 characters should be used to describe the
functionality as much as possible.
Example: Z_DETERMINE_BOL – Function Module to determine the Bill of Lading.
Variables
A field name can be up to 30 characters long, and may contain any alpha numeric character or symbol apart from the
special characters “'( ) + . , :”. However, a name may not consist only of digits. SPACE is a reserved name, and may not

Page 4 of 6155 Rich Products Corporation SAP Development Standards
be used. For Unicode compliance, field names must not contain hyphens “-”. Hyphens are used only in sub-field
references.
Data field names are freely definable but they must be prefixed appropriately. Use the following prefixes:
 z Data fields
 s_ Select-options
 p_ Parameter
 c_ Constants
 t_ Internal tables
After the prefix, it is preferred to use the same names as SAP standard fields (e.g. p_matnr, zkunnr, c_vkorg).
When changing an SAP standard program (or a copy of one), all new variables must start with “z”. (The exception to
this when implementing an OSS note. Then use the variables as written in the note.)
Subroutines (Forms)
Subroutine names should be descriptive of the main purpose of the subroutine. The format of the names should be
consistent throughout the program.
It is preferred to prefix the subroutine name with "F###", where ### is a four-digit number (e.g. "F1000"). This provides
unique identification, and helps with keeping subroutines in a standard order. (See ABAPTemplates for examples of
the standard subroutine order.)
Subroutine names cannot contain hyphens “-”, per Unicode requirements. Words in the name should always be
separated by underscores “_”.
Variants
Variant names may be up to 14 characters in length. They may contain all letters, numbers, and symbols, including
spaces. However, do not use the ampersand (&) in a variant name. This symbol causes technical problems during
saving, which sometimes appear to be authorization failures (or otherwise unclear errors), so should be avoided.
Variants should be assigned a name that briefly describes the purpose or contents.
There is no naming standard for normal (online) variants, however, variants used for background processing should be
prefixed with “B_”, to identify them as background variants.
The variant description may be up to 30 characters in length, and should more fully describe the purpose of the variant.
EXAMPLES:
NAME DESCRIPTION
ALL OF SYSCO SYSCO FROM 01/01
ALLENTOWN Allentown Service
B_NON-DAIRY Background Weekly - NON-DAIRY
B_LP WEST BDM LP WEST SL Fri - Sun
Documentation Standards
Programs must be thoroughly documented both internally and externally. This is necessary to facilitate maintenance of
programs and expansion of the R/3 footprint.
Documentation should be thorough and understandable by non-programmers..
If the programmer cannot write detailed documentation in English, they may use their primary language, but a brief
explanation must be included in English, regarding the main purpose and major functions of the development. It is
preferred for the developer to work with a translator to write comments in English.
Internal
Program Attributes
The Program Title (on the Attributes screen) must be maintained to describe the purpose of the program.
Program Header
All ABAP program code must begin with the standard header comments. This must be kept up-to-date as
modifications are made to the program.
Dates should be written as YYYYMMMDD, using the three-character abbreviation for the month. This avoids
confusion with MM/DD vs. DD/MM standards in different countries.
Version 1.00 Released 1 July 2002

EXAMPLE:
1 ************************************************************************
2 * Program Name : ZTAAUUUU_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX *
3 * Author : Author’s Name, company *
4 * Create Date : original program creation date *
5 * *
6 * Description : Name of program, and explanation of major functions *
7 *======================================================================*
8 * External Calls : List all INCLUDE programs called *
9 * Function Modules : List all function modules called in program *
10 * Transactions : List all transactions called in program *
11 *======================================================================*
12 * Execution Methods : Transaction Code, Menu Path, calling programs... *
13 * Scheduling Issues : List any concerns important for scheduling *
14 * Run Frequency : Explain intended run (On demand, nightly batch..)*
15 ************************************************************************
16 * Modifications : *
17 * *
18 * TRANSPORT DATE PROGRAMMER IDENTIFIER/DESCRIPTION *
19 * ========== ========= ================= ========================== *
20 * SDVK###### create date Creator Name Initial release *
21 * - Use first line for Initial Release *
22 * SDVK###### change date Programmer Name Version # / Description *
23 * - Use multiple lines as necessary to explain all changes *
24 * - Identify changes with a Version Number (V####) which *
25 * will also be referenced where the changes are made. *
26 * - The Transport number should be the transport request *
27 * number, not the development/correction number *
28 * - The Change Date should be the date changes were begun *
29 * SDVK987654 2011JUN23 Rebecca Wells V0003 UPG6.0 *
30 * - Set Unicode flag in Attributes *
31 * - Change subroutine names to use “_” instead of “–” *
32 ************************************************************************
33 *eject
In the above example, items in italics should be replaced with information relevant to the development.
When changes are made to a program, they must be added to the Modifications section of the program header. This
will include the Transport Number, Date, Programmer, Version Number & Description, as shown above. The version
number must be in the format “V####”, which will be included at the end of all changed code lines.
Inline documentation
Programs must contain explanatory comments throughout the code. Comments should be thorough enough that a non-
programmer could understand the program’s parts & functions.
For code modifications, the Version Number must be added at the end of each added/changed line ( e.g. "V0001 ).
This number can then be referenced to the Modifications section for details/explanation of the change.
External
Specifications Document
External documentation for new developments must include the Development Specifications document. This
document contains both the functional and technical specifications, as well as documentation of changes throughout
the lifecycle of the program.
The Development Specification template is available on SharePoint at www.OneRichs.com > IS > NACC > SAP
ABAP.
When making modifications to an existing ABAP, the original Specifications Document should be appended noting
the changes. If that document does not exist, a new one should be started, documenting the main purpose of the
program, and the changes that were made. The document should be stored in the Documentation Library (currently at
www.OneRichs.com > NACC > SAP ABAP > Development Specs and Documentation ). The name of the document is
required to contain the ABAP program name. If a project requires documentation to be stored in a different location, a
shortcut to it must be placed in the Documentation Library.

Training Documentation
Training documentation should be developed as needed. This should be stored with the Development Specifications,
and updated according to SLC standards.
Training documentation may also be created using Oracle UPK, in which case that should be described in the
Specification Document.
Best Practices
Source Code Content
 Do not hardcode text or values, if at all possible. Use Text elements, Parameters or Constants
instead. However this should be done within reason; if a value will never change (for example “x” for a
flag) it may make sense to just use the value and not define a Constant to hold it.
 All reports should use the standard page heading Include program, ZUBAHEAD.
Source Code Layout
 Format should be clean & easy to read.
 Comments should be clear & frequent.
 Use consistent indenting within ABAP statements (LOOP, IF, CASE, SELECT, etc.). This is
intended to make the program easy to read and understood by people other than the original programmer.
Program  Pretty Printer can be used to set appropriate formatting.
 Use inline comments to explain the name or purpose of all DATA, TABLE and INCLUDE items.
 Use a consistent order for program sections (see ABAPTemplates, below) and clearly identify all
sections with comment blocks.
EXAMPLE:
114
115 *=====================================================================*
116 * DATA DECLARATIONS: Internal tables *
117 *---------------------------------------------------------------------*
118 DATA: ...
 In each grouping of similar keywords, line up the similar arguments. This helps make the
program more easily readable. In the following example, the Type attributes are aligned, although the
variable names have varying lengths.
EXAMPLE:
160 data: z_sap_shipto(10) type n,
161 z_itemkey(18) type n,
162 z_valuetext(18) type c,
163 z_slsvalue(10) type p decimals 2.
 Use colons ( : ) to use a keyword multiple times. Everything before the colon is repeated at each
comma. Don’t get carried away, this can also make things harder to read.
EXAMPLES:
107 tables: tvstt, "Shipping Point Texts
108 makt, "Material Descriptions
209 move sy-subrc to: z_subrc1,

210 z_subrc2.
Modularization
Programs should make use of Form subroutines, includes, and function modules wherever possible to reuse code, and
for improved readability. Don’t go overboard, it’s not necessary to create an include if the code can reasonably be
included in the main program.
Use START-OF-SELECTION and END-OF-SELECTION to define the main processing area of a program. Form
routines should be used as much as reasonably possible so that the program is organized into functional sections (e.g.
GET DATA, PROCESS DATA, UPDATE DATABASE, WRITE RESULTS).

Optimization
Optimization Tools
 Use SQL Trace (ST05) to analyze overall efficiency of Select Statements.
 Use the Runtime Analysis (SE30) to find the least efficient areas of a program.
 Use the Tips & Tricks section of Runtime Analysis (SE30) to compare performance of code
snippets.
Selects and Joins
 Try to avoid a SELECT within a loop.
 Structure the WHERE clause of a SELECT statement so that it uses as many relative key fields as
possible and (if feasible) test it several different ways. The number and organization of the fields may
effect whether it uses an Index and if it uses the right one. Results can be viewed and compared via the
SQL Trace.
Note: Selecting a large number of records via the wrong Index can decrease efficiencies.
 Always try to limit the number of records retrieved by a SELECT statement, especially against the
larger tables. Using reference tables can be an efficient way to do this:
 SELECT…WHERE IN is usually the most efficient way of retrieving a large amount of
information.
 If WHERE IN cannot be used, try SELECT…FOR ALL ENTRIES IN…, but be certain to check
that the reference table is not empty. If it's empty, that translates as “no restrictions”, so you’ll get
everything from the SELECT table.
 Reduce the size of a reference table (wherever possible) used in WHERE IN or FOR ALL
ENTRIES IN clauses. Sort the reference table by the primary key of the SELECT table and then use
DELETE ADJACENT DUPLICATES against the reference table, prior to performing the SELECT.
 Create a pseudo selection-screen table (described in Tips & Tricks) with a set of reduced selection
criteria if possible. When using this, use I/EQ, rather than any other range definition method.
 If a pseudo selection-screen table is used in a SELECT…WHERE IN, be sure to:
(1) ensure that the pseudo selection-screen table is not empty at the time of the SELECT;
(2) ensure that the number of entries in the table is less than or equal to 2550; otherwise perform a
SELECT…FOR ALL ENTRIES IN.
 Avoid “SELECT * ” statements against tables with many fields. Use specific field names and
INTO TABLE or INTO CORRESPONDING FIELDS OF wherever possible.
 Do not attempt to join more than three or four related tables at a time.
 When doing an INNER JOIN on tables, attempt to structure the statement so that it is a Many-to-
One. For example: get the order item data using “FROM VBAP” and then join the order header with
“INNER JOIN VBAK”.
 When doing an INNER JOIN on tables make sure that the fields that you are attempting to do the
join on have the same format.
The example shown below will not generate any errors during Program Check or Program Generation.
However, EKPO-EBELP is length 5, and VBFA-POSNN is length 6. Therefore their values will never be
equal, and no data will be returned.
EXAMPLE of INCORRECT usage:
SELECT ... FROM VBFA
INNER JOIN EKPO ON EKPO-EBELN = VBFA-VBELN
EKPO-EBELP = VBFA-POSNN
...
 Use CLEAR & REFRESH on internal tables as soon as information is no longer required from
them (prior to program completion) to release the storage back to the system.
Nested Loops
 Avoid Nested Loops (loop-within-a-loop) if at all possible!
 If a Nested Loop is unavoidable, use an Index with the inner loop to avoid re-reading all of the
records.
 An alternative to Nested Loops is to sort both tables by the comparison field(s), LOOP against the
first table, and READ…WITH KEY…BINARY SEARCH against the 2nd table.
This works as a place-holder in the 2nd table, rather than re-reading the 2nd table every time. For this to

work it is critical that the two tables are sorted in the same order before initiating the LOOP/READ TABLE
processing.
 When using several LOOP/READ combinations, with the same READ table, insert the statement
READ TABLE…INDEX 1 between LOOP statements. This resets the READ placeholder to top of the
table.
 When re-READing a table, insert a CLEAR statement prior to the subsequent READ. This
removes leftover data from the previous READ.
EXAMPLE:
SORT: itab1 BY field1, field2,
itab2 BY field1, field2.
LOOP AT itab1.
CLEAR itab2.
READ TABLE itab2 WITH KEY field1 = itab1-field1
field2 = itab1-field2
BINARY SEARCH.
ENDLOOP.
SORT itab3 BY field1, field2.

READ TABLE itab2 INDEX 1.
LOOP AT itab3.
CLEAR itab2.
READ TABLE itab2 WITH KEY field1 = itab3-field1
field2 = itab3-field2
BINARY SEARCH.
ENDLOOP.
Security
Security requirements must be defined for all ABAP developments.
A thorough discussion of security requirements should be conducted between the Programmer/Analyst and the Business
Process Owner during the definition phase of the development. Include the SAP Security Analyst or Administrator in
these discussions for sensitive areas of the business.
The requirements must be included in the Specifications Document (see ABAPDocumentationExternal), and signed by
the Business Process Owner (BPO). The BPO must also approve the program's security during integration testing.
ABAP Security is of two main types: Transaction Codes and Authorization Checks.
Transaction Codes
The strongest and most common security method is to create a Transaction Code assigned to the ABAP program, then
attach the TCode to a security profile. This enables the users assigned to that profile to execute the program. For
more information, see Transaction Codes.
It is not required to attach a Transaction Code to an ABAP, for example conversion programs may only be executed
by a developer, using SE38 (ABAP Editor). Only create Transaction Codes where necessary.
Authorization Checks
Authorization checks may be included in the source code. They should be used in conjunction with Transaction Codes
to restrict access to secure information. For example, a report may be capable of showing data for all company codes,
but users can only request data from company codes for which they are authorized.
Use the AUTHORITY-CHECK statement, followed by a check of SY-SUBRC, to evaluate the executing user's
authorizations and to control program behavior based on those authorizations. The Pattern feature should be used to
create an AUTHORITY-CHECK statement for a business object with the correct syntax and fields.
The Business Object on which the AUTHORITY-CHECK is based should be determined with the input of the
Business Process Owner and the Security Analyst/Administrator.
Copying SAP programs
When enhancing standard SAP programs, copy them if at all possible. Direct changes to non-Z programs may be lost
during hotpack installations or upgrades. However, if the standard program is modified by SAP during a patch or
upgrade, those changes may need to be merged into the custom copy as well.
When copying a standard SAP program, the same name should be used for the copy, but insert a “Z” at front of the
program name to identify it as a customer program.

New variables added to a copied program must start with “z”.

Variants
Variants allow consistent execution of programs. They may be created by any user executing a program. Obsolete
variants should be deleted.
Variant attributes
 Only For Background Processing – disallows use of a variant in foreground processing. This
should not be used except to protect a background variant from changes.
 Protect Variant – allows anyone to use the variant, but only the user that created a variant can
change it. This can be used as needed, but is not recommended as the default. Terminated users have to be
re-activated to change a variant with this setting.
 Only Display In Catalog – variants don’t appear in the drop-down list, but in Variant Catalog
(accessible through SE38). This is not normally used, but can help t protect variants used in background
processing.
 Selection Variable (Dynamic date formatting) – Variants used for background jobs commonly
need the dates to stay current with the program run date. Use this function to make the dates dynamic.
On the Variant Attributes screen, click the check box next to the date field in the Sel. Variable column, then
click the Selection Variables button. Next click the blue down-arrow to the right of the Variable Name
field to get the list of options.
This function is only available for date fields.
Selection Variable can also be used to populate a field from values stored in table TVARVC. This is
helpful when the program needs to store a placeholder so the next execution begins with a particular
timestamp or document number.
Program Attributes
Development Class
Assign a Development Class based on the instructions given in the Appendix of this document.
Unicode Checks Active
As of version ECC6.0, all objects should have Unicode checks active selected (“X”).
Text Elements
ABAP Text Elements can be used wherever a constant value is needed. They are one method of avoiding hard-coding,
but have the added advantage of being language-specific. Any program that may be executed in multiple languages
should use them.
Text elements are a separate transport object from the program source code (LIMU REPT). Be sure they are included in
any transports. They can be missed if multiple transports are released from SDV but not all of them are imported to
PRD. You should always move ALL transports into PRD in the order released from SDV. Barring that, the LIMU
REPT entry can be manually added to an unreleased transport.
Headings
For reports, prepare the headings by running the report (after saving the ABAP), and then use SystemListHeader
to enter the headings in the appropriate place. This will then be saved to the HEADINGS texts. Be sure to create a
translated version as well.
These texts can then be Cut & Pasted into the variables passed to include ZUBAHEAD, to ensure proper alignment in
the standard report header.
Tips & Tricks

 Check sy-subrc after every SELECT, LOOP or READ statement. Don't assume records were
found.
 Whenever programming a function that seems commonly useful, look for a Function Module to do
it for you.
 Use CLEAR…WITH… to fill a variable with a single character.
 Use TRANSLATE…USING… to replace one character with another in a field.
 Always check for division by zero.

 Use functions “UPLOAD” and “DOWNLOAD” to get & put files on your local PC/network
drives.
 Inserting a line containing only “*eject” will force a page break when the program code is printed.
Use as appropriate for readability.
 Whenever using SELECT ... FOR ALL ENTRIES, always check that the ENTRIES table is not
blank, otherwise all records will be pulled from the SELECT table.
Templates
Standard template for a new ABAP program:
 Z_ABAP_TEMPLATE
Recommended structure for a program is as follows:
 Header comment section
 REPORT statement
 TABLES statements
 INCLUDES
 DATA definitions (internal tables, variables)
 FIELD-SYMBOLS
 SELECTION SCREEN definition (SELECT-OPTIONS, PARAMETERS)
 INITIALIZATION section
 AT SELECTION-SCREEN statement
 START-OF-SELECTION
 END-OF-SELECTION
 SUBROUTINES divider:
*======================================================================*
* SUBROUTINES *
*======================================================================*
 TOP-OF-PAGE statement
 TOP-OF-PAGE DURING LINE-SELECTION statement
 AT LINE-SELECTION statement
 FORM statements, in numerical order
FORM f1000_get_data..
FORM f2000_process_data.
FORM f8000_process_errors.
FORM f9000_write_output.
 This header format should be used above all the major sections of the program, including FORM
routines, top-of-page statements, etc.
*=====================================================================*
* DATA DECLARATIONS: Internal tables *
*---------------------------------------------------------------------*
Sample programs for table maintenance (also consider using a transaction that calls SM30 or SM34 rather than writing a
custom ABAP):
 ZRSD0082 – load a table from a spreadsheet
 ZRMM0031 – table display program
 ZRMM0032 – table update program

Data Dictionary
Transparent Tables
Naming
Table names for Rich Product’s-developed tables should be eight characters in length. The standard naming convention
is, “ZZAA9999”, where the format is defined as follows: The first and second characters of the table name are always
“ZZ”. The third and fourth characters of the table name represent the relevant business application component code for
the table. The remaining four characters represent the next available sequential number within the business application
component code. The naming convention is summarized below.
Position Definitions for Tables: ZZAA9999
 ZZ – Customer-developed data dictionary tables
 “ZZ” literal prefix
 AA – Business Application Component code
 See Appendix
 9999 – Next available sequential number within the Business Application Component code
Ex. ZZSD0001
SAP allows for up to 60 characters for the table description. Use as many characters as necessary to provide a
meaningful description of the table.
Documentation
Internal
Internal documentation is required when creating a custom-developed table.
To maintain the documentation, proceed as follows:
 Choose TableChange from the Data Dictionary initial screen
 Choose GotoDocumentation from the “Data Dictionary Table/Structure: Change Fields” screen
 The documentation sections: &USE& and &MAINTENANCE& must be completed.
External
External documentation should be stored with the Development Specification.
Best Practices
Table Maintenance in SAP R/3
Only authorized Application Developers can create new tables in SAP R/3. All new tables should be reviewed and
approved by the Database Administrator (DBA) before being created. The DBA must always review data storage
parameters, complex database operations such as table conversions, and any data dictionary changes impacting
performance enhancements.
Development Class
Delivery Class
Select the appropriate Delivery Class according to who is responsible for maintaining the table contents and how the
table behaves in a client copy or upgrade.
Table Maintenance Allowed
The “Table Maintenance Allowed” checkbox should be left unchecked. Refer to the Templates section in this
document if the user requires direct table maintenance functionality.
Technical Settings
The Data class should be USER.
The size category should reflect the expected number of records in the table. The data class and size category
determines the storage area to be selected in the database and the expected table size. Correctly assigning a size
category prevents over- and under-allocation of database extents.

Choose the status “Buffering not allowed”.

Leave the “Log data changes” checkbox unchecked.
Primary Key/Index Assignment
Primary key accessed fields should be defined as the first fields of the table. Indexes should not be defined unless the
table is very large and can not be accessed via key fields.
Archiving/Data Retention
Identify the data retention requirements as well as any technical, business, or legal requirements for the new table and
forward this information to the Data Archiving Coordinator.
IMG Tables (Condition Tables, Reporting Information System Tables, etc.)
Follow the SAP Online Help instructions when creating tables within the IMG. Consult the Database Administrator
before activating tables or structures in any of the Reporting Information Systems, (e.g., LIS, SIS, PIS, etc.).
Business Warehouse development will require reevaluation of this standard.
Templates
The following template programs should be used to load, display, and update data in custom-developed tables:
 Sample program for a table load from a spreadsheet – ZRSD0082
 Sample program for a table display program – ZRMM0031
 Sample program for a table update program – ZRMM0032
Fields
Naming
Field names can be up to eight characters in length, and contain only letters or numbers.
The standard SAP field names should be used if possible, such as MATNR, WERKS, etc. If non-standard fields are
required the names should be as descriptive as possible.
Fields (unlike data elements) are specific to the structure in which they exist, and so naming is determined based on
where the field is being created:
 Fields in Customer-developed tables (Z-tables) may have any name, but it is preferred to use the
same names as SAP standard fields.
 MATNR for material numbers
 MNAME for a person’s middle name
 Fields added to SAP Standard tables or structures must contain a “Z” in the first position, to
differentiate them from the original fields. It is preferred to use the same names as SAP standard fields.
 ZMATNR for material numbers
 ZMNAME for a person’s middle name
Documentation
Not applicable.
Best Practices
Not applicable.
Views
Naming
View names can be up to sixteen characters in length. The first three characters must be “ZV_”. The remaining thirteen
characters should be the table name. If more than one table is incorporated in the view, use a meaningful combination of
the table names.
Position definitions for data dictionary views: ZV_UUUUUUUUUUUUU
 ZV_ – system constant
 UUUUUUUUUUUUU – Table Name or a meaningful description

Documentation
Not applicable.
Best Practices
Not applicable.
Structures
Naming
The structure name can be up to thirty characters in length. The standard naming convention is
“ZZAA9999_UUUUUUUUUUUUUUUUUUUUU”. The first and second characters of the structure name are always
“ZZ” for customer-specific elements. The third and fourth characters represent the relevant Business Application
Component code for the structure. The next four characters represent the next available sequential number within the
Business Application Component code. Any remaining characters may be used for a meaningful description. The
naming convention is summarized below.
Position Definitions for Structures: ZZAA9999
 ZZ – Customer-developed structures
“ZZ” literal prefix
 AA – Business Application Component code
 See Appendix
 9999 – Next available sequential number within the Business Application Component code
 UUUUUUUUUUUUUUUUUUUUU – Meaningful description (optional)
Example. ZZSD0006_IND_COMM_DIST_CODES
Documentation
Internal documentation is required when creating a custom-developed structure.
 Choose StructureChange from the Data Dictionary initial screen
 Choose GotoDocumentation from the “Data Dictionary Table/Structure: Change Fields” screen
 The documentation sections: &USE& and &MAINTENANCE& must be completed.
Best Practices
Development Class
Data Elements
Naming
The data element name can be up to eight characters in length. The first character must contain a “Z” for customer-
specific elements. The remaining characters should be as descriptive as possible. If the field has the same meaning as an
existing field, use the same data element name.
Position definitions for Data Elements: ZUUUUUUU
The Short Text should more fully describe the meaning of the data element, which will be copied to associated Fields.
Documentation
Internal documentation is required when creating a custom-developed data element.
To maintain the online field documentation, proceed as follows:
 Choose TableDisplay/Change from the Data Dictionary initial screen
 Double click on the data element name for which documentation is to be added. The “Dictionary:
Display Data Element” screen appears.
 Choose GotoDocumentationChange
 Complete the &DEFINITION& section

Best Practices
Development Class
Field Labels
Create appropriate abbreviations for the short, medium, and long field labels.
The heading length should correspond to the display length of the field and contain an appropriate abbreviation.
Domains
Naming
The domain name can be up to eight characters in length. The first character must be “Z” for customer-specific domains.
The remaining characters should be as descriptive as possible. If the technical attributes of the field are the same as an
existing field, use the existing domain name.
Documentation
Internal
Internal documentation is required when creating a custom-developed domain.
To maintain the online field documentation, proceed as follows:
 Choose TableDisplay/Change from the Data Dictionary initial screen
 Double click on the data element name for which documentation is to be added.
The “Dictionary: Display Data Element” screen appears.
 Double click on the domain name for which documentation is to be added.
The “Dictionary: Display Domain XXXX” screen appears.
 Choose DomainChange
 Choose GotoDocumentation
 Complete the &DEFINITION& section
Best Practices
Development Class
Use of Value Tables
The value set of a domain can be determined by specifying a value table.
All table fields, which refer to this domain, can then be checked against the corresponding field in the value table. In
order that the check can be executed on the input template, a foreign key must be defined for the value table.
The value set defined by specifying a value table can be further limited by allowing only a subset of the values in the
value table. This subset can be determined by specifying a check table, which is itself connected to the value table via
foreign keys.
A table can only be the value table of (at most) one domain. All fields that refer to the value set of this table must use
the same domain.
Maintenance and Dependent Objects
When you change a domain, all tables having a field that refers to this domain must be activated again. Re-activation
is automatically triggered when the domain is activated, thus ensuring that all these tables are adjusted to the changed
technical field information.
Search Helps
Naming
The search help name can be up to eight characters in length. The first character must be “Z” for customer-specific
Search Helps. The remaining characters may be used to describe the purpose of the Search Help.

Matchcodes
Matchcodes are obsolete in version ECC6.0.
Lock Objects
Naming
The lock object name should be seven characters in length. The first two characters must be “E_”. The remaining
characters should be as descriptive as possible.
Position Definitions for a Lock Object name: E_UUUUU
E – Constant “E_”
U – Unique Alphanumeric Suffix – As descriptive as possible.
Best Practices
Development Class

SAPScript
Naming Standards
The name of a layout set has a maximum length of 16 characters and can include upper case letters, numeric characters,
hyphens “-” and underscores “_”. It must begin with a letter.
All RPC layout sets must start with the letter “Z”. After the first character, the name is freely definable.
New development
For new development, the name (after the “Z”) is at the discretion of the developer. It should describe the purpose of the
SAPScript.
EXAMPLES:
ZPRICELIST Price List Form
ZPROMO_ANNOUNCE Promotional Announcement Form
Copies of SAP Standard SAPScripts and ABAP
Most often, SAPScript development starts as a copy of a standard SAP layout set (the original SAP layout set should not
be changed). In this case, the same name should be used, but with a “Z” inserted in the first position.
Multiple versions of a SAPScript (e.g. Invoices that use different layouts) should have similar names, differentiated
using numbers or letters.
EXAMPLES:
RVINVOICE01 SAP Std Rechnung
ZRVINVOICE01 RPC development Invoice - Data only
ZRVINVOICE02 RPC development Invoice - Data and Graphic
ZRVINVOICE03 RPC development Invoice - Productos Rich
ZRVINVOICE_ALIGN RPC development Invoice - Alignment Test Form
F110_PRENUM_CHCK SAP Std Scheck (mit Scheckmanagement)
ZF110_PRENUM_CHC RPC development Check (with check management)
ZF110_MEXICO_CHC RPC development Check (with check management)
Windows
Layout set windows should have a name which reflects the purpose of the data to be displayed in the window. For
example: ADDRESS for an address window, HEADER for a letter header, etc.
The description should further identify the usage of the window.
Paragraph and Character Formats
Paragraph and Character Formats are identified by a two-character name. The name may be comprised of letters,
numbers, underscore and hyphen, but must begin with a letter.
The description should identify the usage of the format.
Internal
Use GotoForm Documentation to maintain information about all the elements of a form. The minimum
documentation is the description for each element. SAP standard layout sets (and copies of them) contain standard
documentation.
Maintain this area to reflect contents of and changes made to a SAPScript.
External
SAPScript development must have an associated Specifications Document. This document should include information
about the entire output process; the SAPScript, associated ABAP, Output Condition Type, etc.
If changes are being made to an existing layout set, and an original Document cannot be found, a new one may be started
stating the current changes, with a brief description of the existing development. The developer may also document the
entire SAPScript at their discretion.

SAPScripts must be recorded in the appropriate Documentation Library spreadsheet.

Use UtilitiesForm Info to get a detailed listing of the SAPScript’s contents. This can be exported to MS Word.
Best Practices
Multi-lingual development
SAPScripts are intended to support multi-language implementations. Pages, windows, and formats are defined in the
original language of a SAPScript, but Text elements (the contents of a Window) are definable for each language version.
This functionality should be used wherever possible. A separate SAPScript is required to change Window placement or
Page Layout.
A SAPScript normally executes in the language of the recipient (vendor, plant, customer), but this can be controlled
using the SET LANGUAGE statement in the associated ABAP.
Identifying TEST output
It is easily possible that non-production output (tests) can be printed to Production printers. In order to avoid confusion,
all SAPScripts must contain the following Window. It must be placed on all pages of the output, in a clearly legible
position.
This window prints a large graphic “TEST” and a text comment (&TEXT-001&) whenever the system is not Production
Client 410. Note that text-only printers (dot matrix) will not print the graphic “TEST”, so placement of the text comment
becomes vitally important.
The ABAP text element (TEXT-001 in this example, though that may be changed) MUST be maintained in any language
the SAPScript may be output. It should say something like “Do not send – Test output – Do not pay”, depending on the
purpose of the output.
Window name: CLIENT
Window text element:
/: IF &SYST-MANDT& NE '410' OR &SYST-SYSID& NE 'PRD'

/: INCLUDE ZTEST_PRINT_IDENTIFIER OBJECT TEXT ID ST
*
*
*
*
*
*
*
*
*
*
*
* &TEXT-001& (&SYST-MANDT& &SYST-SYSID&)
/: ENDIF
Loading graphics with RSTXLDMC

Use program RSTXLDMC to load graphics (black & white or grayscale). They are saved as a Standard Text, and then
INCLUDED into a Text Element. The source must be a grayscale or B&W TIFF 6.0 file.
All graphics are actually black/white. The maximum resolution is 600 dpi, to force compliance with the greatest range of
output devices. In order to simulate grayscale, SAP increases the size of the image to effectively increase the detail
while staying within the allowed resolution.
To adjust the appearance of gray levels in a graphic, use these fields: Type, Resolution for TIFF file, and No. of TIFF
gray levels:
 TYPE – use BMON or PCL. BMON is straight black/white, PCL allows shades of gray
 No. levels – This field is ignored unless TYPE is PCL. It may contain the values 2, 4 or 9.
 2 – the same as Black and White. (Multiplies resolution by 1)
 4 – adds 2 levels of gray, and doubles the image size. (Multiplies resolution by 2)
 9 – adds 7 levels of gray, and triples the image size. (Multiplies resolution by 3)

 Resolution – The number entered in this field is multiplied by a factor related to the number of
gray levels (as shown above). Since the allowed resolutions are 75, 100, 150, 200, 300, 600, and no
decimals are allowed, only certain combinations are possible.
Windows
Separating graphics from text
For SAPScripts with boxes, shading, and standard labels, create separate windows for these items vs. the data. For
example, an Address box may have an outline and be labeled “SHIP TO:”. These should be in a window separate
from the address itself, although they are in the same position on the page. This allows much easier maintenance &
control of the data and graphics.
Header information
The Description of a SAPScript must be updated to describe its purpose. This is easy to forget when copying an existing
SAPScript, which makes it difficult to find/maintain them later.
The Status field reflects the current status of the SAPScript. It must be “Active – Saved” for the Script to work.
Activate a SAPScript from change mode using FormActivate.
See the Appendix for information on assigning a Development Class.
Using Text Elements
Window text elements may be controlled using a Write statement in the associated ABAP program. This controls when
the ABAP orders the window to print. Text elements may be identified with “/E” in the tag column. These elements
must be called explicitly in a Write statement, or they will not print at all. Elements without “/E”, or before the first “/E”
in the window will print at the Close Form statement.
Key words
SET DATE MASK – Use with an ABAP Text Element (&TEXT-001&) to format dates according to the output
language. This command can be placed at the top of every SAPScript element where a date is printed, to be sure they
all have the same format.
SET COUNTRY – This command can be placed at the top of every SAPScript element where an address is printed, to
be sure they all have the same format.
ADDRESS – Use this command wherever possible for address printing. SAP formats addresses according to the legal
requirements of each country.
CASE / WHEN / ENDCASE – Use in place of IF / ELSEIF / ELSE / ENDIF, where possible.
PERFORM / ENDPERFORM – May be used to perform calculations within the SAPScript.
DEFINE – Use to define constants as needed.
Default paragraph formats
A default Paragraph Format may be set for each window. Then any line in the Text Element with “*” in the tag
column will use this format.
Note that INCLUDED texts are usually created using “*”, but it is possible for them to use something else. This could
cause problems with printing the output.
ABAP Text Elements
SAPScript can use the language-dependent ABAP texts, by inserting them as variables in the Text Element (e.g.
&TEXT-001&). They will appear in the language with which the SAPScript is being output.
A useful example of this is date formatting. In the ABAP Editor, create text element TEXT-001. In English, give it
the value “MM/DD/YYYY”. Using the Translation feature, enter the Spanish translation “DD-MM-YYYY”. Then
use it in the SAPScript: SET DATE MASK = &TEXT-001&. Now the printed dates in the SAPScript will be
formatted appropriately for the language. Note that the Month-first format uses slashes (/) for separators, but the Day-
first format uses hyphens (-). This is the standard for all RPC development.
Choosing and using text editors
Two text editors are provided in R/3 version 4.5B: the Line editor and the Graphical editor. Change between the two
from the SAPScript Text Element screen, using GotoChange Editor. Switch your default editor using
GotoConfigure Editor.

The Line editor gives visibility to all formatting commands, and should be used for making changes to Text Elements.
The Graphical editor displays text in the way it will be output. This can be useful for verifying formatting, but is not
suggested for editing.
Templates
Use existing SAPScripts as examples for creating new ones.
In the SAPScript editor, go to Application Help for SAP’s online documentation. This contains thorough instructions for
keywords, etc.
The online help can also be reached via this web address: http://www.richsfamily.com/business
%20tools/focus/saphelp/helpdata/EN/d1/802fd3454211d189710000e8322d00/frameset.htm

CATT
CATT (SCAT) is obsolete in version ECC6.0 and in APO & BW; use ECATT for new recordings (transaction
SECATT).
Naming Standards
Test Modules
The name can be a maximum of 30 characters long. The name may contain letters, numbers, or the symbols “/” and “_”.
It must not contain spaces, or any other keyboard symbols, including accented or other non-English letters.
CATTs beginning with a “Z” or “Y” are within the customer namespace, and will not be overwritten by SAP updates.
The remaining 29 characters must create a unique name.
The CATT name must follow this format: Z_AAUUUU_XXXXXXXXXXXXXXXXXXXXX, where:
 Z – literal “Z” which starts all customer programs
 _ – literal “_”
 AA – a two-letter code for the Business Application Component. See the Appendix for available
codes.
development.
 XXX… – may be used to describe the purpose of the CATT.
For example: Z_SD0001_CREATE_CUSTOMERS
Parameters
Parameter names can be any twelve-character names, preceded with an &.
The following names are already used by CATT and cannot be used as parameter or variable names: &Xnn, where nn is
a two-digit number and X is "T" or "M"
New CATT parameters should be named to match the name of the screen field, where possible. For example, the
parameter to fill screen field RMMG1-MATNR would be named &MATNR.
See the CATT Tips & Tricks section for more information on parameters.
Internal
Describe the test case (use of variables, data passing) in the function screen, using the TXT function.
You can create a long text for more detailed documentation:
1. Go to the CATT maintenance transaction in change mode.
2. Choose GotoLong text in the attribute, function or parameter maintenance screens.
3. The documentation editor shows variables for the standard headers. These are replaced by logon language
texts for user display.
4. Enter descriptive texts. Use Insert (F5) to add lines, leave insert mode with End insert or F5.
5. Save your entries.
External
External documentation must include the Development Specifications document. This document contains both the
functional and technical specifications, as well as documentation of changes throughout the lifecycle of the CATT. This
should be stored in the SAP AD Documentation Library.
Training documentation should be developed as needed. This should be stored with the Development Specifications,
and updated according to SLC standards.
All developments must be added to the relevant spreadsheet, (currently located at \\
$NDS\.GENAPP_VOL6.CORP\ISDATA\PROJECTS\OPEN\Archiving\SLC\2. Analysis\ztables.doc ).

Best Practices
When to use CATT
CATTs are not intended for regular, frequent usage. They should be created for execution by Competency Center
associates, not end-users.
They can be used to:
 test transactions
 test system messages
 check authorizations (user profiles)
 test calculations and database changes
 setup customizing tables
 test the effect of customizing setting changes
They cannot be used for:
 lists and display results
 menu paths
 online help (F1, F4)
 editor functions
 transactions that contain the statement LEAVE TO TRANSACTION
Types
The type is automatically assigned when a CATT is recorded. Otherwise, choose the correct type in the Attribute
screen..
 Type Meaning
 C Use for testing Transactions. (default type)
 F Use for testing Function Modules
The following Types are not used at RPC:
 R Use for testing Remote R/2 Transactions
 X Use for loading files to presentation system
 M Manual test instructions
Test case with long documentation
 S System installation training test case.
The additional maintainable attributes specify the installation environment, and are specially
designed for the SAP training course.
 L Test case which refers to generic test cases.
The test case refers to another test case, which is generally not in the same system.
Language-independence
To minimize the number of test cases required, they must be created without language-dependent elements. Text
variables must then be used for language-dependent fields. The text variable table is connected to the translation tool.
To ensure the language-independence of measurement units, use constants, variables or a parameter as input values. Do
not use text variables &Txx for measurement units.
The value must always be specified in the test case original language. If a test case does not run in its original language,
the conversion exit CUNIT translates language-dependent measurement units input in screens into a language-
independent internal format and then back into the execution language. CUNIT uses standard SAP conversion function
modules.
Parameters
To make test cases flexible, it is better to parameterize input fields rather than to use constants, and to perform
calculations with these parameters or variables where appropriate.
Exporting file layout
1. Export the file:
a. Go to the maintenance transaction for the test case.
b. Choose GotoExternal variantsExport defaults.

c. You can enter a path and a name for the external variant in the to local file dialog box.
1) The default filename is the name of the test procedure with the extension .TXT.
2) The default file path is provided by the SET/GET user parameter CTP.
The file type is tab-delimited text.
3) The file contents will be as follows:
a) Row 1: Parameter Names
b) Row 2: Parameter Descriptions
c) Row 3: Parameter Defaults
d) Row 4…: blank, for entering data.
d. After entering the file name, choose Copy. The system downloads the data to the specified file.
6. Open the file and prepare the data:
a. Start MS Excel and open the default file.
1) The columns are separated by tabs.
b. Create/import the data into the appropriate columns, starting in the 4th row.
1) The parameter names must not be changed.
2) Any changes to rows 2 & 3 will be ignored.
3) The column order may be changed, it is unimportant.
c. Save these data records in a tab-delimited text file. (type .TXT)
1) The data format for importing data must be Text, otherwise leading zeros and date formats may be
lost.
7. Use the data file as an External Variant:
a. You can run external variants by specifying the path and file name in the CATT initial screen.
Tips & Tricks
Creating test cases
 Only create test modules for transactions which you know well.
 Only put one transaction in a test module.
 Only call transactions by reference to a test module. Create each test module using a single
transaction code, then build a test procedure (another CATT) which references (REF) the test modules.
This increases flexibility, and reusability of the CATTs.
 Avoid creating new test cases when existing ones can be modified.
 Always modify test cases so that they remain compatible.
 Document all test cases.
 Use existing test cases in other applications to use their transactions, requesting modifications if
necessary.
 Use variants to broaden the range of tests.
 Define allowed error messages, to avoid logging unnecessary messages.
 Use the Field list (function TCD) for changed transactions:
 If dialog transaction changes have removed fields from screens, the field list helps you find the
fields used in CATT again.
 Fields which were previously used by CATT are at the end of the list (after the BDC fields), with
their previous value, and can so be easily identified.
Using parameters
 Use variables and parameters instead of constants in screens to make test modules flexible
 Use text variables (&T01,...,&T99) for language-dependent fields.
 Do not specify constant dates.
 Use variables: &JHR (year), &DAT (date) for date variables
 Choose the parameters and screen sequence so as to make the test case as generally usable as
possible.
 When creating a new parameter in FunctionDetailsField List, double-click the constant value
to replace it with a parameter name. The parameter name will be the Data Element name, with the Line
Number concatenated to it. Double-click the new parameter name to adjust the settings, including the
Default value which was copied from the Constant value.

Using cursor coordinates

To identify the cursor location by coordinates (for picking an item from a screen list), use the field BDC_CURSOR,
and put the row/column in New Field Contents (e.g.: “15/2” would be the 15th row, 2nd column). Then call the
appropriate function code for the next step.
Executing test cases
 Only run parts of a test case in the foreground.
 Enter processing mode A in the REF function detail maintenance for a called test case.
 Enter processing mode A in the TCD function detail maintenance screen for a transaction.
 This part of the test case then runs in the foreground, even if the test started in "background
processing".
 You can deactivate individual lines in the CATT function editor. If you want to exclude a
function temporarily, you do not need to delete it, you can deactivate it to by flagging the I column at the
end of the line in the function editor. This function does not then run in the test.
 You can display all test check data with the SE38 report RSCATPRF.
CATT for Output Condition Records: Create vs. Display
When CATTs are developed to load Output Condition Records for SD, they should begin with a mode other than the
one to be used. That is to say, if you want to Create records, you should start with Display or Change. To Change
records, start with Create or Display. The reason for this is that the mode the CATT starts in is disabled from the
menu (normally “ENTER” would access it, but this doesn’t work for this area via CATT). The solution is to start the
CATT execution in a different mode, so that the mode you want to use is available in the menu.
Templates
Recording a CATT
You can use the recording function to create test cases for transactions:
2. Enter a test case name in the CATT maintenance transaction initial screen and choose Record Module.
3. Enter the transaction for which you want to record the test case, in the next dialog box.
a. Pressing Enter takes you to the initial screen of the transaction you want to record.
b. Specify the transaction recording CATT mode in the transaction entry dialog box. The transaction is
recorded in "without COMMIT WORK end" mode by default. It can be appropriate in particular cases
to record the transaction in "with COMMIT WORK end" mode (e.g. Batch Input data transfer
transaction sequence test). To change the mode, choose "COMMIT WORK end" ( F7 ) with the right-
hand mouse key in the dialog box.
4. Make sure that the window size is set to the default by choosing Default size.
a. This ensures that recorded test cases run correctly in the background. This is necessary, e.g. for step
loop fields whose length depends on the screen size.
5. Run the transaction as you want it to be tested later with the Test Case.
6. After ending the transaction, you automatically go to the CATT Maintenance transaction. A dialog box tells
you that the recording is finished.
7. Press ENTER to go to the CATT Maintenance Transaction Attribute Maintenance Screen. Check the
attributes and change them if necessary.
8. Choose GotoFunctions to go to the Function Editor.
9. Enter additional functions and save them.
10. Parameterize the test case.
Read the Test Case Creation Tips before creating test cases.
You must confirm type "I" system messages with ENTER before you can continue. This also applies to messages that
only appear in the status bar.
If an OK code of type "T" is entered on a screen of the transaction to be recorded, the recording terminates without an
error message.
Creating a CATT manually
Use this procedure if you want to collect individual test modules (transaction test cases) in a test procedure (e.g. to test a
business process).

11. To create a test case manually, enter a name and choose Test procedureCreate in the CATT maintenance
transaction initial screen.
12. Maintain and save the attributes.
a. When you save the module or procedure for the first time, a dialog box prompts you to assign it to a
development class. See the Appendix for information on choosing a Development Class.
b. Enter the Header Data Type (see CATT Types).
c. On the CATT-Specific tab, set the Test Module Attribute for test modules, allowing the CATT to be
referenced by another Test Procedure.
13. Choose GotoFunctions to go to the Function Editor.
14. Enter functions.
15. Parameterize the test case.
Read the test case creation tips before creating test cases.
Modifying a CATT manually
CATTs may be modified after recording or manual creation. In Change Mode, Maintain the Details for a function.
Screens may be inserted or removed. Select a screen & use the Field List button to see all available fields with
parameters. Double-click a parameter name to change its settings.

Interfaces
This section is out-of-date and must be revised. New interfaces should focus on efficiency of storage & processing, as well
as ease-of-support. They should use existing interface examples as a pattern to follow, making improvements where feasible.
Detailed recommendations will be added to this section in the future.
SAP recommends and supports three methods of interfacing data:
 IDoc – Intermediate Document
 BAPI – Business Application Programming Interface
 BDC – Batch Input Sessions
The preferred method at Rich Products for a batch interface (inbound and outbound) is to use an IDoc and use the Mercator
tool to build the interface. If an IDoc is not available from SAP, a custom IDoc may be developed in some instances.
If an IDoc interface is not feasible, then BAPI and BDC solutions should be explored. Currently, there are several BDC
interfaces implemented in the production environment. The BAPI interface option has not been implemented for any
interface solution.
Non-Mercator
Data Files
Extract Files – SAP Outbound Interfaces
Naming Standards
Description
Refers to the name of the data file that is interfaced into an application other than SAP (i.e. I2, QAD, FMIS,
Mainframe, etc.)
File Name
Outbound interface file names should be structured as follows:
descriptive filename_date-time stamp.file format
For example: Roads Daily Interface extract file: roadsfile_20020614-130044.txt
 roadsfile – descriptive file name
 20020614-130044 – date-time stamp
 txt – file format
Directory Structure
The directory structure for Extract data files is as follows:
/data/$env/source application/program name_variant name/extract file name
 /data – data directory
 /$env – enviroment that the application is executing in i.e.
prd – production
qa – QAS
dev – development
 source application – indicates the application that provides input to the specific interface program.
sap – SAP
 program name_variant name – indicates the name of the program (APAP, BDC, etc.) that will be
generating the data file.
 extract file name – name of the Extract file
Example
Roads Daily Interface: (SAP program ZOSD0003)
/data/prd/sap/zosd0003_b_sdroadsdly/roadsfile_20020614-130044.txt
 data – data directory
 prd – production environment
 sap – source application

 zosd0003_b_sdroadsdly – SAP program name and variant that is used to generate the extract data
file
 b_roadsfile_20020614-130044.txt – extract file name
Backup/Archive Files – SAP Outbound Interfaces
Naming Standards
Description
Refers to the name of the archive version of the extract file defined above.
File Name
Archive file names should be same as the extract file name defined above. The structure is as follows:
descriptive filename_date-timestamp.file format
Example
Roads Daily Interface archive file name: roadsfile_20020614-130044.txt
 roadsfile – descriptive file name
 20020614-130044 – date-time stamp
 txt – file format
Directory Structure
The directory structure for archive data files is as follows:
/data/$env/source application/program name_variant name/archive/archive file name
prd – production
qa – QAS
dev – development
sap – SAP
 archive – indicates the archive version of the data files
 archive file name – name of the archive file
Examples
Roads Daily Interface: (SAP program ZOSD0003)
/data/prd/sap/zosd0003_b_sdroadsdly/archive/roadsfile.20020614-130044.txt
 zosd0003_b_sdroadsdly – SAP program name and variant that is used to generate the output data
file
 archive – archive directory
 roadsfile_20020614-130044.txt – name of the archive file
Extract Files – SAP Inbound Interfaces
Naming Standards
Description
Refers to the name of the data file that is interfaced into SAP from an application other than SAP (i.e. I2, QAD,
FMIS, Mainframe, etc.)
File Name
Mainframe Interfaces
The program input file name must be the same as the file name on the Mainframe. This can be accomplished
within your FTP job.

Please see job name PSA09EDA on the mainframe as an example. There are four JCL steps required to
accomplish this, they are defined in the steps below . (i.e. PBUA.D4160AC.G0884.V00).
16. Perform a “listcat” on your GDG file to get the full system name
8. build a file with the FTP commands to transport your GDG file. This is accomplished by sorting the FTP
commands together with the file name that you built in the previous step.
9. Dynamically build an OPC job to execute a script that will be using the file as input. This is accomplished
by sorting the Script execution commands together with the file name that you built in step 1.
10. Transport your data with the standard FTP proc (PR0239). Please see the Batch Jobs section of this
document for more information on FTP jobs.
Example
Mainframe Gelco Interface file – PBUA.D1585AM.G1144V00
Other Inbound Interfaces (i.e. QAD, JWA, I2, etc.)
Inbound interface file names should be structured as follows:
descriptive filename_date-time stamp.file format
Directory Structure
The directory structure for Inbound Extract data files is as follows:
/data/$env/source application/program name_variant name/extract file name
 /$env – enviroment that the application is executing in:
prd – production
qa – QAS
dev – development
 source application – indicates the application that provides the input to the SAP inbound interface.
A few examples include:
mf – Mainframe
I2 – I2
qad – QAD
pitbull – FMIS spoilage
odss – FMIS ODSS
xref – cross reference files
jwa – JW Allen
using the extract file as input.
Example
Gelco Monthly Interface: (SAP program ZIFIG001)
/data/prd/mf/zifig001_b_figlgelco/PBUA.D1585M.G1144V00
 mf – source application
 zifig001_b_figlgelco – SAP program name and variant that will use the extract file as input.
 PBUA.D4158AM.G1144AM.V00 – extract file name
Backup/Archive Files – SAP Inbound Interfaces
Naming Standards
Description
Refers to the name of the Archive version of the Extract file defined above.
File Name
Archive file names should be same as the Extract file name defined above. The structure is as follows:
Example
Mainframe Gelco Interface file – PBUA.D1585AM.G1144V00

Directory Structure
The directory structure for Archive data files is as follows:
/data/$env/source application/program name_variant name/archive/archive file name
prd – production
qa – QAS
dev – development
mf – Mainframe
I2 – I2
qad – QAD
odss – FMIS ODSS
jwa – JW Allen
Example
Gelco Monthly Interface: (SAP program ZIFIG001)
/data/prd/mf/zifig001_b_figlgelco/archive/PBUA.D1585M.G1144V00
 zifig001_b_figlgelco – SAP program name and variant that will use the extract file as input.
 archive – indicates the archive directory
 PBUA.D4158AM.G1144AM.V00 – extract file name
Log Files
Naming Standards
There are no naming standards for Log files. It is recommended that you use unique log file names in order to assist in
trouble shooting and problem recovery. The directory structure that the log files are placed in will provide a means to
quickly identify log files related to a specific interface program.
Directory Structure
The directory structure for log files is as follows:
/log/$env/source application/ program name_variant name/log file name
 /log – log file directory
prd – production
qa – QAS
dev – development
 source application – indicates the application that provides input to the interface. A few examples
include:
mf – Mainframe
sap – SAP
i2 – I2
qad – QAD
odss – FMIS ODSS
jwa – JW Allen

 program name_variant name – indicates the name of the program that will be generating the log
file.
Best Practices
It is recommended to use unique log file names for trouble shooting/problem recovery purposes (i.e. use a date/time
stamp in the name).
Mercator
Data Files
SAP Outbound Interfaces
There are two methods to process SAP outbound IDoc’s in Mercator
 Individually – using the Mercator “Router Map” interface to SAP. For additional information
please see documentation on the Router map located at Q:/sap/Mercator/TSI OB Documentation.
 Batch file – using a Mercator transaction map
Naming Standards – Individual IDoc’s via the Mercator Router Map
Description
Refers to the name of the output data file that is generated from the Mercator Transaction Map.
File Name
The file name should consist of the IDoc Message Type, followed by the IDoc number and a suffix indicating
whether it is a data file, an IDoc status file, or a reject file. The file name should be structured as follows:
 IDoc Message Type – for example
ZINVOI
SHPMNT
 IDoc Number
 Data type suffix
dat – data file
sts – IDoc Status file
rej – rejected data file
Example
EDI Invoice application. This is an SAP outbound interface that interfaces SAP invoice data to the EDI invoice
application on the Mainframe.
The invoice data files are formatted as follows: ZINVOI0000000018490389.dat
The invoice IDoc status files are formatted as follows: ZINVOI0000000018490389.sts
The invoice rejected data files are formatted as follows: ZINVOI0000000018490389.rej
 ZINVOI– Mercator Map name
 0000000018490389 – individual IDoc number
 dat – data file format
Naming Standards –Batch Files - Mercator Transaction Map
Description
Refers to the name of the output data file that is generated from the Mercator Transaction Map.
File Name
The file name should consist of the IDoc Message type, followed by a data/time stamp a suffix indicating
whether it is a data file, status file or a reject file. The file name should be structured as follows:
 Mercator map name – for example
ZINVOI
SHPMNT
 Date/time stamp
dat – data file

sts – status file

Example
The invoice data file is formatted as follows: ZINVOI_20020614.dat
The invoice IDoc status file is formatted as follows: ZINVO_20020614.sts
The invoice rejected data file is formatted as follows: ZINVO_20020614.rej
 ZINVOI – IDoc Message Type
 20020614-130044 – date/time stamp
 dat – data file format
Directory Structure
The directory structure for Mercator extract data files is as follows:
/data/$env/source application/Mercator map name/extract file name
prd – production
qa – QAS
dev – development
sap – SAP
 Mercator map name – indicates the name of the Mercator map generating the files.
Example
/data/prd/sap/zinvoi/ ZINVOI0000000018490389.dat
 zinvoi – Mercator map name will create the interface files.
 ZINVOI0000000018490389.dat – extract file name
Concatenated IDocs
Naming Standards
This is applicable only to SAP outbound interfaces that use the Router Map but ultimately need to batch up the
individual interface files before transferring them to the interfacing application (i.e. EDI on the mainframe).
Individual output files may be concatenated via a PERL program script.
Description
Refers to the name of the file containing the concatenated data files.
File Name
The file name should consist of the IDoc Message Type, followed by a date/time stamp and a suffix indicating
whether it is a data file, status file or a reject file. The file name should be structured as follows:
 Message Type – for example
ZINVOI
SHPMNT
 Date/time stamp
dat – data file
sts – status file

Example
ZINVOI.dat – file that contains concatenated data.
Directory Structure
The directory structure for concatenated data files is as follows:
/data/$env/source application/Mercator map name/ftpdir/data content/concatenated file name
prd – production
qa – QAS
dev – development
sap – SAP
 Mercator map name – indicates the name of the Mercator map generating the files.
 ftpdir – ftp directory
 data content
dat – data files
sts – IDoc status files
Example
/data/prd/sap/zinvoi/ftpdir/dat/ZINVOI.dat
 zinvoi – Mercator map name will create the interface files
 ftpdir – ftp directory
 dat – data files
 ZINVOI.dat – concatenated invoice data file.
Backup/Archive Files – SAP Outbound Interfaces
Naming Standards
Description
File Name
Archive file names should be formatted as follows:
Message Type-date-time stamp.file suffix
Example
 ZINVOI-06-14-13:04.dat – file that contains concatenated EDI Invoice data files.
Directory Structure
The directory structure for archive data files is as follows:
/data/$env/source application/Mercator map name/archive/archive file name
prd – production
qa – QAS
dev – development

sap – SAP
 Mercator Map name – indicates the name of the Mercator map that will be generating the data
file.
Example
/data/prd/sap/zinvoi/archive/archive file name
 zinvoi – Mercator map name that creates the file.
 ZINVOI-06-14-14:04.dat– archive file name
SAP Inbound Interfaces
Naming Standards
Description
Refers to the name of the data file that is interfaced into SAP from Mercator.
File Name
Mainframe Interfaces
The program input file name must be the same as the file name on the Mainframe. This can be accomplished
within your FTP job.
Please see job name PSA09EDA (EDI Carrier transactions) on the mainframe as an example. There are four JCL
steps required to accomplish this, they are defined in the steps below . (i.e. PBUA.D4160AC.G0884.V00).
17. Perform a “listcat” on your GDG file to get the full system name
11. build a file with the FTP commands to transport your GDG file. This is accomplished by sorting the FTP
commands together with the file name that you built in the previous step.
12. Dynamically build an OPC job to execute the generic Mercator Inbound script (InMercator.sh) with the
respective transaction map name and the GDG file name that you built in step 1. This is accomplished by
sorting the Script execution commands together with the file name that you built in step 1.
13. Transport your data with the standard FTP proc (PR0239). Please see the Batch Jobs section of this
document for more information on FTP jobs.
Example
Mainframe EDI Carrier Information file – PBUA.D4160AC.G0884V00
Other Inbound Interfaces (i.e. QAD, JWA, I2, etc.)
Inbound interface file names should be structured as follows: descriptive filename_date-time stamp.file format
Directory Structure
The directory structure for Inbound Extract data files is as follows:
/data/$env/source application/Mercator map name/extract file name
 /$env – enviroment that the application is executing in:
prd – production
qa – QAS
dev – development
mf – Mainframe
I2 – I2

qad – QAD
odss – FMIS ODSS
jwa – JW Allen
 Mercator map name – indicates the name of the Mercator map that will be using the extract file as
input.
Example
EDI Carrier Information Interface: (Mercator map name edi_214)
/data/prd/mf/edi_214/PBUA.D4160AC.G0884V00
 edi_214 – name of the Mercator map that will use the extract file as input.
 PBUA.D4160AC.G0884AC.V00 – Input file name
Backup/Archive Files – SAP Inbound Interfaces
Naming Standards
Description
File Name
Archive file names should be same as the Extract file name defined above. The structure is as follows:
Example
Mainframe EDI Carrier Information file – PBUA.D4160AC.G0884V00
Directory Structure
The directory structure for Archive data files is as follows:
/data/$env/source application/Mercator map name/archive/archive file name
 /$env – enviroment that the application is executing in
prd – production
qa – QAS
dev – development
mf – Mainframe
I2 – I2
qad – QAD
odss – FMIS ODSS
jwa – JW Allen
 Mercator map name – indicates the name of the Mercator map that will be generating the data file.
Example
EDI Carrier Information Interface: (Mercator map edi_214)
/data/prd/mf/edi_214/archive/PBUA.D4160AC.G0884V00

 edi_214 – Mercator map name that will use the extract file as input.
 PBUA.D4160AC.G0884AC.V00 – extract file name
Log Files
Naming Standards
There are no naming standards for Log files. It is recommended that you use unique log file names in order to assist in
trouble shooting and problem recovery. The directory structure that the log files are placed into will provide a means
to quickly identify log files related to a specific Mercator map.
Directory Structure
The directory structure for log files is as follows:
/log/$env/source application/Mercator map name/log file name
 /log – log file directory
prd – production
qa – QAS
dev – development
 source application – indicates the application that provides input into the Mercator interface. A
few examples include:
mf – Mainframe
sap – SAP
i2 – I2
qad – QAD
odss – FMIS ODSS
jwa – JW Allen
 Mercator map name – indicates the name of the program that will be generating the log file.
Best Practices
It is recommended that you use unique log file names for trouble shooting/problem recovery purposes (i.e. use a
date/time stamp in the name).
Trace Files
Naming Standards
There are no naming standards for Mercator Trace files. The directory structure that the trace file is placed into will
provide a means to quickly identify the trace file related to a specific Mercator Map.
Directory Structure
The directory structure for trace files is as follows:
/data/$env/source application/Mercator map name/trace file name
 /trace – trace file directory
prd – production
qa – QAS
dev – development
 source application – indicates the application that provides input to the Mercator interface.
mf – Mainframe
sap – SAP
i2 – I2
qad – QAD
jwa – JW Allen
 Mercator map name – indicates the name of the map that generated the trace file

Best Practices
Trace files should be not be activated in the Production environment unless necessary for troubleshooting purposes.
They are large files that provide information that is valuable only for trouble shooting.
Map Files
See Q:/sap/Mercator/Documentation/Mercator Development Procedures .

Transaction Codes
Naming Standards
SAP allows transaction codes up to 20 characters in length. They may contain letters, numbers, underscores (_), etc., but
not spaces ( ), plus signs (+) or asterisks (*). Transaction codes beginning with a “Z” or “Y” will not be overwritten by
SAP, as they are within the customer namespace. For customer-specific enhancement of area menus, the name must begin
with “+”.
Transaction code names developed for Rich Products must have a length of four or five characters. The standard naming
convention for all Rich Products-developed transaction codes is “ZA##” or “ZA###”, where "Z" is always the first
character, the second character represents the application area, and the last two or three characters are the next available
sequential number within the application area. When three digits are used, the first digit should NEVER be “0”.
Note that the code for Business Application Component is only a single letter for Transaction Codes. Use only the codes
that are in this “Active” list. The “Reserved” codes are only listed here for future expansion.
 Z – The literal “Z” indicates Rich Products-developed transaction code
 A – Business Application Component
 Active Codes:
 A Accounting – General
 B Basis Components
 C Controlling
 E Enterprise Controlling
 F Financial Accounting
 G Plant Maintenance
 L Logistics Execution
 M Materials Management
 O Logistics – General
 P Production Planning & Control
 Q Quality Management
 S Sales and Distribution
 T Treasury
 X Cross-Application Components
 Reserved codes (not currently in use):
 D Customer Service
 H Project System
 I Investment Management
 J Personnel Management
 K Personnel Time Management
 N Payroll Accounting
 R Real Estate Management
 U Training and Event Management
 V Environment Management
 ## or ### – Next available sequential number within the application area.
 For sequential numbers 01-99 in a particular application the format is ZA00 – ZA99.
 For 100 – 999, the format is ZA100 – ZA999.
 The range ZA000 – ZA099 is NOT allowed.
To determine the next available sequential number, use the dropdown menu (F4) for the Transaction Code field or refer
to the list of RPC-developed transaction codes maintained in RPC-Developed Transaction Codes.
EXAMPLES:
ZS01 – Re-price sales orders that are not billed
“Z” is used to identify that Rich Products developed the transaction code
“S” is used to identify the application area as Sales and Distribution
“01” is the first sequential number available within the Sales and Distribution application area.
ZM101 – List of all Materials

“Z” is used to identify that Rich Products developed the transaction code
“M” is used to identify the application area as Materials Management
“101” is the next available sequential number within the Materials Management application area.
Internal
A transaction code which executes an ABAP program should be added to the header comments of that program, if the
program is also being modified. If the program is not being modified at that time, the transaction code can be added to it
at a later date.
External
A Transaction Code must also be mentioned in the External documentation for the ABAP program it executes.
Communication
Users needing access to a transaction code should be notified during training.
The Security team will need a separate request to add the transaction code to the correct user roles.
Best Practices
When defining a transaction code for a report transaction, choose Report transaction. This ensures that the executable
program is started by the same processors in the ABAP runtime environment as when you start it directly from the ABAP
Editor. If you choose Dialog transaction from the above screen, the program has to be controlled using screen logic, like a
module pool.
The transaction code text should be entered in English. The text is stored in the language under which the Developer is
logged in; to enter additional languages, use the SAP Translation tool (transaction SE63). Within the tool, choose
Translation  ABAP Objects  Short Texts. Then select S3 ABAP Texts  TRAN Transactions. Enter the Transaction
name, and choose the Source Language (EN) and the Target language and click EDIT.
SAP requires certain information when a transaction code is created including the Development Class, Transaction Text,
and Program. Other attributes that can be assigned to the transaction code include Selection Screen, Variants, and
Authorization objects. Below are the RPC standards for these attributes.
 Development Class – Refer to the ABAP Program Attributes section for the ABAP Development
Class standards. The Development Class should be the same as that assigned to the accompanying
program. Also see the Appendix for more information.
 Transaction Text – Be as descriptive as possible here. SAP allows up to 36 characters for this
text. Include the program name in the text.
 Program – Enter the program name
 Selection Screen – Enter the screen number. The default screen number is 1000 for standard
screen selection.
 Start with Variants – Enter the transaction variant if applicable. To set field display options for
transactions, use transaction variants. Transaction variants can simplify working with transactions to preset
field values, hide fields or change their availability, and hide whole screens. In order to assign transaction
variants to specific users, you must first define a variant transaction. When defining a variant transaction
you must enter the name of the transaction and the name of the variant. The new transaction code then
allows you to call this specific variant of your transaction.
 Authorization Object – Enter the name of the authorization object if applicable. The authorization
object is checked against the authorizations of the calling user when a transaction is started. If the user
does not have the necessary authorizations, the transaction will be cancelled. You should normally specify
an object, which is also checked within the program. This check only takes place when calls are made via
START TRANSACTION and via the entry "/n<Transaction code>".
For further instructions on how to create a transaction code, refer to the how-to instructions found in How to Create a SAP
Transaction Code.
Security
Work with the appropriate Business Process Owner to determine the profile(s) that should include the new transaction
code before moving the transaction to the Production system.

Tips & Tricks

Table Maintenance Transactions
To allow users to directly maintain entries in a custom table, use a Parameter Transaction.
 First, use the Table Maintenance Generator to allow table maintenance via SM30. The table
should include MANDT (Client) as the first field to allow maintenance in the Production system.
 Create the parameter transaction to execute SM30, and set “Skip initial screen” = “X”.
 At the bottom of the Transaction Maintenance screen, enter screenfield VIEWNAME, and put the
name of the custom table (or view) as the value. Then enter screenfield UPDATE = “X”.
Templates
Not applicable.

Transport Requests
Naming
SAP allows up to 60 characters for the short description of the request. Enter a description that uniquely identifies the
change request in your development project. This makes it easier to later find your request in the hierarchical list. A
detailed description can be entered in the documentation, see the Documenting Tasks and Requests section in this document.
Change requests for major projects or initiatives should all be prefaced with a short unique identifier to help categorize
changes. For example, change requests for the Mexico ERP implementation begin with “MEX:”. The Project Manager
should decide this naming standard before any customizing or transport changes are made.
All change requests for OSS Notes (a.k.a. SAP Notes) must begin with the characters, “OSS:”. This naming standard will
help to easily find these types of changes.
If multiple transports are needed for the same change, it can help to use a same (or similar) description and end the
transport with a number to signify the transport order.
Documentation
Documenting Tasks and Requests
All developers working on a change request should to write structured documentation when releasing their tasks.
18. In the request overview, position the cursor on the request for which you want to write documentation.
14. Choose GotoDocumentation.
15. The documentation maintenance screen appears. Underneath the keyword, &T_DESCRIPTION&, you
must enter the purpose of the change request including details of specific changes to objects within the
request. References to other internal documentation or internal instructions should also be placed here.
16. The following documentation is not required but is recommended:
a. Affected Systems – Keyword &T_AFFECTED_SYSTEMS&
b. Dependencies on other transport requests – Keyword &T_DEPENDENCIES&
c. Test Scenarios Used and Related Testing Notes – Keyword &T_TESTNOTES&
d. Next Steps, if any, related to the implementation of the change request – Keyword &T_ACTIONS&
The documentation on the tasks of a request is copied to the documentation of that request when the task is released.
IS Change Management
In order to move through to Production, all transports must go through the IS Change Management process. See
documentation at www.OneRichs.com > IS > Applications > Change Management > View All Site Content > CM Documentation .
Best Practices
Cleaning Up Obsolete Transports
Once development is completed on a work product, it is important to back out any change requests that are not going to
be moved into the Production environment. This practice will ensure the integrity of the Development environment.
Remember, if the change request is deleted the changes that you or other users in the same project have already made are
not reset automatically to the state before the modifications. These steps must be followed to clean up an obsolete
transport:
 Back out any changes that were made to the Customizing and/or Workbench objects
 Rename the change request beginning with the text “DO NOT IMPORT:” in uppercase letters.
This text will alert other developers that the change was backed out and the request is no longer active.
 Release the request task(s) and the parent change request. The Transport Request Form should not
be completed since this transport request should not be imported into any system. This last step will ensure
that Workbench object locks are released for future development.
 Move all transports to PRD. This confirms that there are no differences between the Development
& Production environments, and avoids later questions about which transports are relevant.

Monitoring Transports
ZRB2 – Report of Transport Contents
Rich’s has a custom Transport report (transaction ZRB2) which is very useful to check the status of your transports.
Execute the transaction
 If known, you can enter the Transport or Task number(s) or a range
 Owner is the user ID for the Transport (not the tasks)
 Last Changed – if the transport is released, this is the release date & time. Otherwise it’s just the last time
an object was added to the transport
 CTS Project – use this to filter the report for a particular project
 Import History – you can enter the system ID’s for which you want to read or filter the import history. This
way you can see immediately where a transport has moved and when. Putting selections here does
somewhat slow the report, because it must read much more data to filter by import dates.
In order to find transports that have moved to a system on a certain date, check the [X] box next to that
system ID. Then it will exclude transports which have never moved into that system, and will show only
those within the date selections.
In the final report, the Import Date columns will be highlighted in Orange or Red if there was an Error
Code upon Import to that system.
 Objects&Keys / ALV – the ALV view (Default) allows you to sort the results. Turning off ALV allows
you to display Objects & Keys (the transport’s contents) for several transports in one screen.
 System Copy History – if a system has been overwritten (usually QAS), this overwrites the import date for
transports which haven’t moved to that system since the overwrite. That avoids confusion as to which
transports are actually there.
SE01 - SAP Transport Organizer
Released change requests have transport logs showing the date, time, and system of export and import. You can easily
access an overview of your transports and repairs from the right-hand side of the initial screen of the CTO in the
Global information section.
The stoplight icons indicate transport errors (stoplight is red) or unconfirmed repairs (stoplight is yellow).
To access the overview of your transports, choose Transports. A hierarchical list appears with your released transports
and their transport steps, grouped according to target system.
You can see whether the individual transport steps were successful or not from:
 the color of the entry
 the comment
 the return code
If there are faulty transports, analyze the cause of the error. The transport log contains information that may be useful.
You can access the transport log by double-clicking the transport step.
When you have found out what caused the error and corrected it, you can give the request the attribute “Error
corrected”. This action is recorded in the action log.
Even when transports have been performed successfully, check that they work correctly in the target system. After
you have tested the functions in the target system, assign the request the attribute Tested.
Although SAP allows you to delete transports from the display with the attributes Error corrected or Tested, the
standard at RPC is to not delete the transport.
Below are the meanings of the return codes generated by the programs used for the transport to establish whether a
transport has been successful.
 0000  Transport performed without errors
 0004  Warnings were issued. All objects were transported successfully. There were special
actions for individual objects that may not have been intentional, for example, a warning is issued during
the export if the request contains an object deletion. Read the warnings.

 0008  Individual objects could not be transported successfully. You must analyze and correct
the errors. Examples of errors during the import include: "Original object was not overwritten", "Repaired
object was not overwritten".
 0012 or higher  A critical error has occurred, probably not caused by the contents of the request.
You must inform your system administrator.
Security
If a new repository object is being transported, follow the security and authorization processes so authorization can be
assigned.
Creating Change Requests
 Create an individual task for each of the tables modified during customization.
 Do not combine customizing data and development objects in one change request.
 Do not combine changes to the SAP Data Dictionary and Programs in one change request.
Transport the DDIC objects then the programs to avoid dependency problems.
 As you copy single change requests, be sure that you copy all logically related changes. For
example: if you have made related corrections in two separate customizing requests, then be sure to copy
both to the test client. If you copy only one, the test will not succeed.
Documenting Contents of Customizing Transports
A version history of all customizing changes is recommended for all Client-Dependent Customizing objects that are
recorded in Customizing requests. The version history data describes the configuration menu path, the process for
determining the configuration values including responsible persons, and most importantly the table changes with the date
of the change and the transport request number. The version history document should be stored offline SAP in the
Documentation Library (S:\Application Dev\SAP AD\Documentation Library\Standards\). Whether the Version History is
required for a particular object is at the discretion of the Business Process Owner.
To download the transports’ table contents to a file, proceed as follows (or use ZRB2, described above, to show the
Objects & Keys):
19. Position the cursor on the task within the change request
20. Choose Request/taskObject listDisplay object list. The Display Object List screen is shown
21. Choose GotoObject Key. The Display Key Data screen is shown
22. Choose GotoDisplay table contentsSpecified keys. The table contents of the task are shown.
(Choosing Display table contentsEntire table will give you ALL entries, not just the ones being
changed).
23. If all entries are visible on the screen, continue to the next step to save them to a file. Otherwise, choose
TablePrint to print the entire list to a spool file. Then go to transaction SP01 or SP02, Display the spool
entry to screen, and then save it to a local file using the same process described below.
24. Choose SystemListSaveLocal file. The Save List In File dialog is shown.
25. Choose Spreadsheet and press the Enter or Confirm button. The Transfer data to a local file dialog is
shown.
26. Type the destination folder and file name for the list of contents changed and press the transfer button.
Clean up the output in Excel and copy it into the version history document. This works for 95% of all configuration
tables. There are a few that do not have table views and for those you can cut and paste the entries into a worksheet
using the CTRL-Y, CTRL-C, and CTRL-V functions. Whenever the configuration changes, download the new table
view and save it in the version history document.
Tips and Tricks
Change and Transport Organizer Tools
There are tools available in the Change and Transport Organizer (CTO) for searching, displaying, editing, and
analyzing change requests and transports. In the initial screen of the Workbench Organizer, choose GotoTools to
access a collection of tools that support your work with the Change and Transport System. Some of the helpful tools
are:
 Objects in requestsSearch for objects in requests/tasks – Use this program to search for objects
(tables, programs, et al.) in requests/tasks.

 Objects in requestsAnalyze objects in requests/tasks – Enter a request or task here and you can
display the request header and the objects in the request. The information displayed for each object includes
its object directory entry, development class, original system and person responsible.
 Requests/tasksDisplay transport logs – This program displays all transport steps for a specified
request.
 Requests/tasksSearch for requests/tasks – Use this program to search for requests and tasks
according to different criteria (such as owner, status, request type) and display them in a hierarchical list.
You can edit the requests from this list, as you can in the Workbench Organizer.
Customizing Cross-System Viewer
The Customizing Cross-System Viewer tool (SCU0) compares Customizing objects in two logical systems (where
logical systems are either clients in the same R/3 System, or in different R/3 Systems). The Single Object Comparison
function (SCMP) compares the contents of single Customizing tables and views in two logical systems.
The Customizing Cross-System Viewer can also be invoked within display in the IMG activities (e.g.,
UtilitiesCompare/Adjust).
Templates
Transport Policy and Procedure
For more information on the transport movement schedule refer to Rich Product’s Transport Policy and Procedure
document, located in Q:\sap\Competency Center\Change Management\SLC\4. Construction\Transport Request Policy and
Procedure.doc.
Transport Request Form

The Transport Request process has been incorporated into the IS Change Management Process. Information on that
process can be found on the SharePoint site at www.OneRichs.com > IS > Applications > Change Management > View All Site
Content > CM Documentation.

Batch Jobs
SAP Jobs
Naming Standards
Description
Refers to the job name set up in SAP via transaction SM36. Positions 1 through 8 should uniquely identify the job.
The naming format should be as follows.
SAP allows a maximum of 32 characters for a job name. The first 10 characters of the name must uniquely identify
the job. This facilitates identification without needing to specify the entire name. The remaining 22 characters may be
used to describe the job’s purpose.
The name should follow this format: SS_AA_UUUU_XXXXXXXXXXX, where:
 SS – system identifier of where the job is run, as follows:
 R3 SAP R/3
 AP SAP APO
 BW SAP BW
 UX Unix
 LX Linux
 etc.
 AA – a two-letter code for the Business Application Component. See the Appendix for
available codes.
development. Do NOT reuse a number which has already been used in the outdated 2-digit format (so jobs
can be identified by the module and number without having to state the entire name). The number in this
format should never be less than ‘0100’, to avoid intermixing the old & new formats.
 XXX… – a meaningful description of the job’s purpose, including the timing and the Business
Application Sub-component (see Appendix), where applicable.
EXAMPLES:
R3_SD_0100_INVOICE_OUTPUT
UX_SD_0101_INVOICE_ONBASE_COLL
Best Practices
Job Creation
27. Execute transaction SM36 in SAP to Define a Background Job.
17. Enter the Job name as derived by following the naming standards.
18. Enter "C" in the Job class
19. Target host should be left blank (this allows it to run on all systems such as after a copy to QAS. If it
should run ONLY in PRD, enter the Target host).
20. Select Steps to enter the programs to include in the job.
a. User – set to BUSER. This is the Authorizations under which the job will run, and the User ID that
will be documented in any Change History for objects updated.
b. Select ABAP program. Enter the program name and variant. Verify the language.
c. Select Print specifications to enter the Background Print Parameters. Enter the parameters specific to
the job. Particular attention should be paid to the Spool control and Cover sheet parameters. Click
“Continue” to return to the Step setup.
1) To email the output for a single job step, use printer EMAIL (mail) and press Enter to see the
input field for a single email address.
d. Click “Save” on the Create Step screen.
e. Add additional steps if needed.
f. Green arrow back and Click “Save” on the Define A Background Job screen. A message will indicate
that the job was saved.
21. The job can be verified by executing transaction SM37 (or custom report ZRB1) to Select a Background
Job. Enter the Job name and User name. Ensure Jobs Without a Start Date is checked.

Job Scheduling
1. All jobs should be scheduled through UC4 job scheduler. Work with Production Control to have jobs
created & tested. This allows centralized monitoring, failure notification, and general management which
is not possible otherwise.
2. All jobs must be added to the OnCall database so that Computer Operations knows whom to contact if they
fail or run longer than usual.
3. All jobs must be turned over to the O&M team after they are fully functional in PRD; that team will present
the required documentation format, such as the Master Schedule Spreadsheet. Such turnover
documentation must be complete before the O&M team will support the job.
UNIX Jobs (Scripts)

Naming Standards
Description
Refers to the job, or script, that executes a UNIX process.
Directory Structure
The format for the directory structure will vary depending on whether the script is a general script, FTP housekeeping
script.
General Scripts
The naming format should be /scripts/$env/$source system/ where:
$env = dev
qa
prd
$source system = sap
FTP Housekeeping Scripts
Where feasible, these should be executed directly as a UC4 FTP, rather than creating a Unix/Linux script. Otherwise,
follow these directions.
FTP files should be moved to a save directory where the date and time stamp may be included in the filename
extension for tracking purposes. Environment parameters are used to pass the source directory, destination directory,
and filename.
The naming format should be /scripts/$env/$source system/sapmvsav.ux env.filename where:
$env = dev
qa
prd
Mercator Scripts
Data Formatting and Transfer Scripts
Where feasible, these should be executed directly as a UC4 FTP, rather than creating a Unix/Linux script.
Otherwise, follow these directions.
Script Directory
 /scripts/$env/$source system/$map name/ where:
$env = dev
qa
prd
$map name = process
Example: /scripts/prd/sap/zcsh/
Script Types
 Concatenation Script – concatenates individual IDocs into one file.
The naming format should be $mapname cat where the name is composed of the map name, followed by
the letters “cat”.

Example: /scripts/prd/sap/zcsh/zcshcat
 FTP Script – transfers the file to another server. The naming format should be as follows:
$mapname ftp using env.$mapname and $mapname.in where
env.$mapname = the data directory of the concatenated file to transfer
$mapname.in = the target system sign-on, with the source and target data directories and file names
Example: /scripts/prd/sap/zcsh/zcshftp using env.zcsh and zcsh.in.

Job Schedules
UC4 Applications
Naming Standards
Description
Refers to the name set up in the UC4 scheduler identifying the SAP processes to run. The UC4 application name may
include one or several related jobs. This name is used by the IS Operations and Production Control teams. Job names
are up to the discretion of the Application Developer and Production Control; often the same Job name is used as in
the target system (e.g. SAP or Unix). UC4 allows much longer job names than SAP, so the name format is not really a
concern.
Job Scheduling Procedures
All schedules should be communicated through Production Control. Schedules related to major system
implementations require a three to four week lead-time. Independent schedules or schedules related to minor system
implementations require a one week lead-time.
Templates
Batch Job Documentation
The Batch Job Documentation form must be completed for all SAP jobs. The form includes sections on general
information, job ownership/contacts, scheduling information including predecessors and dependencies, restart
requirements, and processing steps. An area for additional information on inputs, outputs, BDC sessions, variables, and
reports is also provided. While the form is completed as part of the process for setting up batch jobs, it is referenced in
this section on Job Schedules to ensure that the job scheduling information is updated accordingly.
All Batch jobs must be added to the On Call Database with basic information and whom should be called in case of
failure or longer than normal runtime. The individuals listed in the OCDB must be aware of what the job does and
possible failure points and relevant resolutions.

Appendix
Reference Materials
Business Application Components
Business Application Components are SAP-defined development areas of SAP R/3. All new developments should be
associated with a Component in order to identify the affected areas of R/3, and to determine responsibility. Frequently
these codes are referenced in the name of the development, but also should be used in documentation or discussion of
these components.
These abbreviations are defined by SAP, and a complete list can be found at ToolsABAP Workbench,
OverviewApplication Hierarchy (SE81).
The codes listed below are a subset of the Application Hierarchy list. These codes are the only ones currently to be used
at RPC. If none of these codes is applicable, contact the Standards team before using a code not listed here. In choosing
the correct Component, it may help to review the Sub-Components (below) and then select the associated Application
Component.
Logistics:
 LO Logistics (General) – use where the other active Logistics components do not apply
 MM Materials Management
 SD Sales & Distribution
 LE Logistics Execution
Accounting:
 AC Accounting (General) – use where the other active Accounting components do not apply
 FI Financial Accounting
 CO Controlling
 EC Enterprise Controlling
Other:
 BC Basis Components – use for developments related to Basis, such as the ABAP
Workbench or Runtime Environment, Security, or the Change & Transport System.
 CA Cross-Application Components – use for developments that are not application-specific,
such as Archiving, Workflow, CATT, and IDOC/EDI
Sub-components
The following codes represent Sub-Components for the above Business Application Components. The sub-component
code may be used, for example, in the descriptive area of a program name. It should not be used in place of the
Application Component Code.
Logistics:
 LE (Logistics Execution)
 IDW Decentralized WMS Integration
 WM Warehouse Management
 SHP Shipping
 TRA Transportation
 LO (Logistics – General)
 MD Logistics Basic Data
 PDM Product Data Management
 BM Batches
 PR Forecast
 VC Variant Configuration
 ECH Engineering Change Management
 LIS Logistics Information System
 MDS Merchandise Distribution
 SCI Supply Chain Planning Interfaces (SCPI)
 ADM Additional Management

 RIS Retail Information System (RIS)

 MM (Materials Management)
 CBP Consumption-Based Planning
 PUR Purchasing
 SRV External Services Management
 IM Inventory Management
 IV Invoice Verification
 IS Information System
 SD (Sales and Distribution)
 MD Master Data
 BF Basic Functions
 SLS Sales
 FT Foreign Trade
 BIL Billing
 CAS Sales Support
 IS Information System
 POS POS Interface
Accounting:
 AC (Accounting – General)
 COB Coding Block
 INT Accounting Interface
 CO (Controlling)
 OM Overhead Cost Controlling
 PC Product Cost Controlling
 PA Profitability Analysis
 EC (Enterprise Controlling)
 PCA Profit Center Accounting
 BP Business Planning
 CS Consolidation
 EIS Executive Information System
 FI (Financial Accounting)
 GL General Ledger Accounting
 LC Consolidation
 AP Accounts Payable
 AR Accounts Receivable
 BL Bank Accounting
 AA Asset Accounting
 SL Special Purpose Ledger
 FM Funds Management
 TV Travel Management
Other:
 BC (Basis Components)
 KRN Kernel Components
 ABA ABAP Runtime Environment
 SRV Basis Services / Communication Interfaces
 CCM Computing Center Management System
 INS Installation Tools
 UPG Upgrade - General
 CTS Change & Transport System
 OP Operating System Platforms
 DB Database Interface, Database Platforms
 FES Frontend Services
 DWB ABAP Workbench

 SEC Security
 CI Component Integration / Installation Windows Components
 BE Business Engineer
 BMT Business Management
 RRR Ready-to-Run R/3
 CA (Cross-Application)
 EUR European Monetary Union: Euro
 DMS Document Management System
 CL Classification System
 CAD CAD Integration
 BFA Business Framework Architecture
 BP Central Business Partner
 GTF General Application Functions
 PER Personalization
 DOC Documentation and Translation Tools
 EDI Intermediate Document Interface/EDI
 CAT Computer Aided Test Tool
 BW SAP Business Information Warehouse Extractors
 OIW Open Information Warehouse
 TS Time Sheet
 ARC Archiving
Development Classes
SAP Standards
Related objects in the ABAP Workbench are grouped together in a development class. In practice, the objects within a
development class are strongly related to each other. Each development class is under the administration of one
developer. The class determines the transport layer that defines the transport attributes of an object (such as which
system to load the request to).
The first character of a Development Class name is used to denote its function:
 A-S or U-X: only for SAP standard objects. Changes are transportable.
 Y or Z: only for Customer objects. Changes are transportable.
 T: Private Test class. Changes are recorded in local requests. A transport request must be created
manually.
 $: Local class. Changes cannot be transported.
When an ABAP Workbench object is created, the system requires its assignment to a development class. The
development class should describe the area that the object belongs to. The representation of the object tree in the
ABAP Workbench (SE80) uses the development class as a navigation aid. If there are more than 100 objects of a
certain type (that is, ABAP Programs), the object tree can no longer be clearly represented and it becomes increasingly
difficult to use the ABAP Workbench. In this case, we recommend creating new development classes with the same
transport layer and distributing the objects to the new classes on the basis of the areas they belong to.
RPC Standards
Customer developments should use Classes beginning with Z. The following is the list of active Rich Products
Development classes. If a need arises for new Development Classes, they must first be reviewed by the standards
committee.
 ZDEVELOP Developments, including ABAP, Data Dictionary, CATT, EDI, et al.
 ZIMG Configuration (where a development class assignment is required)
 ZBASIS Basis transports, including security
 $TMP Developments that are not to be transported
 Non-“Z” development classes are reserved for SAP objects.

DEVELOPMENT STANDARDS (v2 2011)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DEVELOPMENT STANDARDS (v2 2011)

Uploaded by

Copyright:

Available Formats

Rich Products Corporation

SAP Development Standards

Last Saved: 25 June 2018, 11:12 AM

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Process for updating standards

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

209 move sy-subrc to: z_subrc1,

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

SORT itab3 BY field1, field2.

Version 1.00 Released 1 July 2002

New variables added to a copied program must start with “z”.

Tips & Tricks

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Choose the status “Buffering not allowed”.

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

SAPScripts must be recorded in the appropriate Documentation Library spreadsheet.

/: IF &SYST-MANDT& NE '410' OR &SYST-SYSID& NE 'PRD'

Loading graphics with RSTXLDMC

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Using cursor coordinates

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

sts – status file

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Version 1.00 Released 1 July 2002

Tips & Tricks

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

Transport Request Form

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc

UNIX Jobs (Scripts)

Version 1.00 Released 1 July 2002

S:\Application Dev\SAP AD\Documentation Library\Standards\SAP Development Standards.doc