Standard Operating
Procedure:
NCH Development Guidance
Naming Conventions and
Programming Standards
Version:
1.01
Effective Date: 12/09/2003
Standard Operating Procedure
SOP Title:
NCH Development Guidance Naming Conventions
and Programming Standards
Ref. Number:
MN_G_003_MOD0_TCD0_1.00
AUTHOR:
FUNCTION:
Steve Vasina
Technical Consultant
APPROVED BY:
TITLE and Context of Approval:
DATE:
Miguel Patino
I&B LatAm,Info Technology Team Lead 12/03/2003
Signed Copy On File
Linda Kirk
OTC NA, Functional Team Lead
(Development)
12/03/2003
Signed Copy On File
Mohsen Ghorbati
Medical Nutrition NA, Functional Team 12/03/2003
Lead (Operations)
Signed Copy On File
Matteo Henking
Medical Nutrition Team
Signed Copy On File
12/03/2003
SIGNATURE:
Modifications History
____________________________________________________________________________
VERSION
EFFECTIVE DATE DESCRIPTION OF CHANGES
1.00
1.01
10/15/03
12/09/2003
New document
Add Section on User Exits – Section 4.2
Deleted reference to Ascendant tool in Section 6
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
1.
INTRODUCTION ...............................................................................................................................................5
2.
PREREQUISITES ...............................................................................................................................................5
3.
Object Naming Conventions ...............................................................................................................................6
3.1 General Development Naming logic....................................................................................................................6
3.2 Business Unit Codes ............................................................................................................................................6
3.3 Country Codes .....................................................................................................................................................6
3.4 Application ID .....................................................................................................................................................7
3.5 Summary ..............................................................................................................................................................7
3.6 Development Class ............................................................................................................................................ 12
3.7 ABAP Programs ................................................................................................................................................ 12
3.8 ABAP Report Variants ....................................................................................................................................... 13
Zxxxxxxxxxxxxx ................................................................................................................................................. 13
3.9 On-Line Programming....................................................................................................................................... 13
3.9.1 Transaction Codes ...................................................................................................................................... 13
3.9.2 ABAP Module Pools .................................................................................................................................. 13
3.9.3 ABAP Module Pool Components ............................................................................................................... 14
3.9.4 Dynpros (Screens) ...................................................................................................................................... 14
3.10 Batch Job Requests .......................................................................................................................................... 15
3.11 Batch Input (BDC) Sessions ............................................................................................................................ 15
3.12 Logical Database ............................................................................................................................................. 15
3.13 Menus .............................................................................................................................................................. 16
3.14 ABAP Dictionary ............................................................................................................................................. 16
3.14.1 Transparent Tables, Pool Tables, Structures ............................................................................................. 17
3.14.2 ATAB/Control Tables .............................................................................................................................. 17
3.14.3 Cluster Tables ........................................................................................................................................... 17
3.14.4 Domains .................................................................................................................................................... 18
3.14.5 Data Elements ........................................................................................................................................... 18
3.14.6 Table Fields .............................................................................................................................................. 18
3.14.7 Search Help............................................................................................................................................... 18
3.14.8 View ......................................................................................................................................................... 19
3.14.9 Lock objects .............................................................................................................................................. 19
3.15 Function Library .............................................................................................................................................. 19
3.15.1 Function Groups ....................................................................................................................................... 20
3.15.2 Function Modules ..................................................................................................................................... 20
3.16 SAPscript Layout Sets ...................................................................................................................................... 20
3.17 Message Classes .............................................................................................................................................. 21
3.18 EDI / ALE Objects ........................................................................................................................................... 21
3.18.1 IDOC Segment Type ................................................................................................................................ 21
3.18.2 IDOC Segment Name ............................................................................................................................... 21
3.18.3 Basic IDOC Type ..................................................................................................................................... 21
3.18.4 Enhancement IDOC Type ......................................................................................................................... 21
 Novartis Consumer Health
Page: 2 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
3.18.5 Logical Message ....................................................................................................................................... 21
4.
Programming Standards ................................................................................................................................... 23
4.1 Overview ............................................................................................................................................................ 23
4.1.1 General........................................................................................................................................................ 23
4.2 User Exits .......................................................................................................................................................... 23
4.3 Hardcoding ........................................................................................................................................................ 24
4.4 Checking Return Codes ..................................................................................................................................... 25
4.5 Documentation and Comments .......................................................................................................................... 25
4.6 Program Structure/Style .................................................................................................................................... 28
4.7 Data Definition .................................................................................................................................................. 28
4.8 Text Elements ..................................................................................................................................................... 30
4.9 Report Standards ............................................................................................................................................... 31
4.10 Batch Program / Interface Standards .............................................................................................................. 31
4.11 Online Standards ............................................................................................................................................. 32
4.12 Messages.......................................................................................................................................................... 33
4.13 Subroutines ...................................................................................................................................................... 33
5.
Efficiency Standards .......................................................................................................................................... 35
5.1 General .............................................................................................................................................................. 35
5.1.1 General: Dead Code .................................................................................................................................... 35
5.2 Reports ............................................................................................................................................................... 35
5.2.1 Reports: Control Breaks ............................................................................................................................. 35
5.3 Database Access ................................................................................................................................................ 35
5.3.1 Database Access: General ........................................................................................................................... 35
5.3.2 Database Access: Buffered Tables.............................................................................................................. 35
5.3.3 Database Access: Select * vs. Select Single * ............................................................................................ 35
5.3.4 Database Access: Cluster Tables ................................................................................................................ 36
5.3.5 Database Access: Selecting one row without the full key .......................................................................... 36
5.3.6 Database Access: Select * with Check ....................................................................................................... 36
5.3.7 Database Access: Selecting certain fields ................................................................................................... 36
5.3.8 Database Access: Range Tables ................................................................................................................. 37
5.3.9 Database Access: Views and Inner Joins vs. Nested Selects for Joins ....................................................... 37
5.3.10 Database Access: Index Design ................................................................................................................ 38
5.3.11 Database Access: Logical Databases ........................................................................................................ 39
5.3.12 Database Access: Matchcodes .................................................................................................................. 39
5.4 Internal Tables ................................................................................................................................................... 40
5.4.1 Internal Tables: Reading a Single Record................................................................................................... 40
5.4.2 Internal Tables: Sorting .............................................................................................................................. 40
5.4.3 Internal Tables: Select Into vs. Append ..................................................................................................... 40
5.4.4 Internal Tables: Calculating Totals ............................................................................................................. 40
5.4.5 Internal Tables: APPEND vs. COLLECT .................................................................................................. 41
5.4.6 Internal Tables: Key Fields on Read ........................................................................................................... 41
5.4.7 Internal Tables: Secondary Indexes ............................................................................................................ 41
 Novartis Consumer Health
Page: 3 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
5.4.8 Internal Tables: Sorting .............................................................................................................................. 41
5.4.9 Internal Tables: Deleting Records .............................................................................................................. 41
5.4.10 Internal Tables: Sequential Reads ............................................................................................................. 42
5.4.11 Internal Tables: Direct Reads ................................................................................................................... 42
5.4.12 Internal Tables: Adding entries while sorting ........................................................................................... 42
5.4.13 Internal Tables: Counting Entries ............................................................................................................. 43
5.4.14 Internal Tables: Loop/Shere vs. Loop/Check ........................................................................................... 43
5.5 Logic Paths ........................................................................................................................................................ 43
5.5.1 Logic: PERFORM decisions ...................................................................................................................... 43
5.5.2 Logic: Nested ifs ......................................................................................................................................... 44
5.5.3 Logic: Case vs. If ........................................................................................................................................ 44
5.5.4 Logic: Optimizing IF AND CASE Structures ............................................................................................ 44
5.5.5 Logic: Move-Corresponding....................................................................................................................... 44
5.5.6 Logic: While vs. Do Loops ......................................................................................................................... 44
5.5.7 Logic: Testing for Initial Value .................................................................................................................. 44
5.5.8 Logic: Performing Calculations .................................................................................................................. 45
5.5.9 Logic: Field Length .................................................................................................................................... 45
6.
Tracking SAP Modifications & Enhancements .............................................................................................. 46
7.
Workflow ............................................................................................................................................................ 46
7.1 Customizing of the Workflow. ............................................................................................................................ 46
7.2 Development ...................................................................................................................................................... 46
7.3 Roles and Responsibility .................................................................................................................................... 46
7.4 Organization structure....................................................................................................................................... 46
7.5 Workflow, Task Group, Task, and Role ............................................................................................................. 47
7.5.1 Task ............................................................................................................................................................ 47
7.5.2 Task Group ................................................................................................................................................. 47
7.6 Monitoring ......................................................................................................................................................... 47
7.6.1 Deadline monitoring ................................................................................................................................... 47
8.
EDI Modifications.............................................................................................................................................. 48
9.
Appendix A. - Return Codes ............................................................................................................................. 49
10.
Appendix B. - Skeleton Programs ................................................................................................................ 54
Basic ABAP List Report ........................................................................................................................................... 54
Interactive ABAP List Report .................................................................................................................................. 56
Create a Sequential Dataset .................................................................................................................................... 58
Read Sequential Dataset and Create a BDC Session ............................................................................................. 59
CALL TRANSACTION USING Technique............................................................................................................... 62
 Novartis Consumer Health
Page: 4 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
1. INTRODUCTION
Development programming standards and consistent naming conventions will contribute significant time and
resource savings for both the initial construction and long term maintenance of the SAP system. Addressing these
standards prior to construction and adhering to them during construction is especially helpful when addressing the
following:




Migration into a production environment
Facilitating knowledge transfer for future SAP resources
Long-term maintenance/expansion of custom development
Future upgrades
Small amounts of effort now will prove beneficial for the overall project and SAP system. The objective of this
overview is to define guidelines for SAP developers.
2. PREREQUISITES
This document is based on:
 SAP’s Naming Conventions for Development Objects
 Previous IBM SAP project implementation standards
 Novartis PEP Pharma ERP Program standards and naming conventions
This document will further evolve as batch scheduling and mapping tools are more solidly integrated into the
Novartis development environment, and as new requirements/standards arise.
This document assumes that the reader is comfortable with the following topics:
 ABAP programming language.
 Systems development cycle of SAP R/3.
 Development of DDIC objects like tables, match codes, data elements, domains, menus, screens, functional
modules, and program maintenance.
Notes:
No standard baseline SAP objects should ever be deleted or changed, without the approval of the Novartis Cross-BU
FAST team and Project Management.
All user-defined development objects fall into the category of Customer Object Development.
In SAP terminology, Customer is defined as any development resource that uses the SAP development environment
to meet functional requirements. The objects thus created are called Customer Objects. By convention, Customer
Objects start with the letter ‘Y’ or ‘Z’. Be aware, however, that some reports and objects starting with ‘Z’ were
created by SAP and are not part of the customer development environment.
 Novartis Consumer Health
Page: 5 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
3. OBJECT NAMING CONVENTIONS
3.1 General Development Naming logic
In general, these naming conventions are based on the SAP naming conventions, and are derived from it by adding a
1-character business unit code, the 1-character country code and the 1-character application area code. For newer
object types, the naming can be derived easily with the same logic (in case of doubt, it is best to contact the
Application Development Team Lead). After the business unit code, the country code and the application code, the
naming usually can be defined freely (indicated by a ‘x’). Please note that even in 4.x versions, there are object
types for which the maximum length is 4 (or less) bytes and we have to compromise our policy of including
business unit code, country code and application area code. When creating objects that do not include the country
code in their object name, please contact the Application Development Team lead in order to avoid conflicts.
When creating object types as a copy of SAP standard object types, the original object name should be included in
the custom object name as much as possible. E.g. when you copy the include ‘BDCRECXX’ in the customer name
range it should for example be named ‘ZOUS_BDCRECXX’.
3.2 Business Unit Codes
BU Code
0
I
M
O
Description
NCH-NA
Infant & Baby
Medical Nutrition
OTC
3.3 Country Codes
Country Code
U
A
M
B
L
V
H
P
G
C
Description
USA
Canada
Mexico
Brazil
Venezuela
Puerto Rico
Chile
Peru
Argentina
Global Core Template
The listing of SAP country codes is not complete in above list. Additional country codes have to be requested from
the Application Development Team Leader.
 Novartis Consumer Health
Page: 6 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
3.4 Application ID
For Novartis purposes, the Application ID will be a 1 character field which acts as a general functional identifier for
each object developed. This application ID corresponds to SAP’s predefined application ID set.
Application area
code
A
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
S
T
U
V
W
X
Z
Description
AM - Assets Accounting
PPC - Production Planning & Controlling
DASS
RIVA
FI - Financial Accounting
General Ledger
Human Resources Planning
PM - Plant Maintenance
Publishing
Cost Accounting
Inventory Management
MM - Materials Management
Hospital
Workflow
Human Resources
QSS - Quality Assurance
Basis
Temporary Development (Conversion programs)
EDM - Enterprise Data Model
Sales & Distribution
MMS - Material Merchandising System
Material Master Data Management (MMDM)
Cross application development
The list of Application IDs may be further refined for specific project requirements. If it appears that a specific
development object cannot be appropriately classified by the current list of Application IDs, a new Application ID
should be requested from the Application Development Team Leader.
3.5 Summary
The following table summarizes the naming conventions described in this document. Each SAP Object Type is
described in further detail in following sections. If an SAP Object Type is not listed below, it should follow the
standard naming convention of ZDCaxxxxxxxx…. where ‘D’ is the Business Unit Code, ‘C’ is the Country Code,
‘a’ is the Application ID, and ‘xxxxxxx…’ is freely definable.
 Novartis Consumer Health
Page: 7 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
SAP Object Type
Length
ABAP Programs
18
Naming Convention
ZDCa_bccc_xxxxxxxx
14
D – Business Unit Code
C – Country Code
a – Application ID
b – Program Type ID according to RICEF list
c – Last three digits from RICEF object ID
x – Open
(Attached to SAP-delivered programs)
ABAP Report Variants
Zxxxxxxxxxxxxx
x – Open
(Attached to custom programs)
Zxxxxxxxxxxxxx
x – Open
Transaction Codes
10
ZDCa_bcccx
D – Business Unit Code
C – Country Code
a – Application ID
b – Program Type ID according to RICEF list
c – Last three digits from RICEF object ID
x – Open (numeric)
ABAP Module Pools
10
SAPxZDCann
x - Type of module pool:
M – Screens
L – Function Modules
F – Subroutines
D – Logical Database
D – Business Unit Code
C – Country Code
a – Application ID
nn - Numeric
ABAP Module Pool
Components
10
XZDCannTOP
XZDCannOxx
XZDCannIxx
XZDCannFxx
- Data declarations
- PBO modules
- PAI modules
- Subroutines
X – Type of Module Pool:
M – Screens
L – Function Modules
F – Subroutines
D – Logical Database
ZDCann - from main Module Pool name
x – Open
 Novartis Consumer Health
Page: 8 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
SAP Object Type
Length
Naming Convention
Dynpros (Screens)
4
Attached to SAP-supplied programs:
9000-9999, increments of 1
Version 1.00
Effective Date:
Attached to custom-developed programs:
0100-9999, increments of 10
Pop-up screens
Parent screen # plus 1 (e.g. 0101)
Batch Job Requests
32
ZDCa_xxxxxxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a - Application ID
b – Frequency
x - Open
NOTE: Batch job requests will be further defined when the batch
scheduling architecture is designed
Batch Input Sessions (BDC
Sessions)
12
Logical Databases
20
ZDCa_bccc_xx
D – Business Unit Code
C – Country Code
a - Application ID
b – Program Type ID according to RICEF list
c – Last three digits from RICEF object ID
x – Open
ZDCaxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
x – Open
Area Menus
6
ZDCaxx
D – Business Unit Code
C – Country Code
a – Application ID
x – Open
CUA status
8
ZDCaxxyy
ZDCaxx - Area Menu
y - Open
Function Key Codes
4
Titlebars
3
Tables, Views, Structures
16
xxxx
x - Open (capital letter)
xxx
x - Open
ZDCa_bccc_xxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
b – Program Type ID according to RICEF list
c – Last three digits from RICEF object ID
x – Open
 Novartis Consumer Health
Page: 9 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
SAP Object Type
Length
ATAB / Control Tables
5
Version 1.00
Effective Date:
Naming Convention
T9axx
a – Application ID
x - Open (limit to three for Control tables)
Domains
30
ZDCaxxxxxxxx...
D – Business Unit Code
C – Country Code
a – Application ID
x – Open
Data Elements
30
ZDCaxxxxxxxx...
D – Business Unit Code
C – Country Code
a – Application ID
x – Open
Table Fields
16
(Attached to SAP-delivered tables)
ZZxxxxxxxxxx...
x – Open
(Attached to custom tables)
xxxxxxxxxxxx...
x – Open
Search Helps
30
ZDCaxxxx…..
D – Business Unit Code
C – Country Code
a – Application ID
xxxx – Table name search is based on or description of search help
Views
16
ZDCaxxxyyyyyyyyy
D – Business Unit Code
C – Country Code
A – Application ID
X - Open, must be unique across all views
y – Open (i.e. Primary Table Name)
Lock objects
16
EZDCa_tttttttttt
D – Business Unit Code
C – Country Code
A – Application ID
t - primary table name (where multiple Lock Objects are required
for the same primary table, assign a unique digit to the final
position).
Function Groups
26
Z_DCaxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
x - Open (freely definable)
 Novartis Consumer Health
Page: 10 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
SAP Object Type
Length
Function Modules
30
Version 1.00
Effective Date:
Naming Convention
Z_DCa_xxxxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a - Application ID
x - Open (separate words with underscores)
Layout Sets (SAPscript)
16
ZDCa_bccc_xxxxxx
D – Business Unit Code
C – Country Code
a - Application ID
b – Program Type ID according to RICEF list
c – Last three digits from RICEF object ID
x – Open (use as much as possible from original SAP object
Messages classes
20
ZDCaxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
x - Open (freely definable)
IDOC Segment Type
27
Z1DCaxxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
x – Open
IDOC Segment Name
30
Z2DCaxxxxxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
x - Open
Basic IDOC Type
30
ZDCaxxxxxxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
x – open
Enhancement IDOC Type
30
ZDCaxxxxxxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
x – open
Logical Message
30
ZDCaxxxxxxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
x – open
 Novartis Consumer Health
Page: 11 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
SAP Object Type
Length
Naming Convention
Workflow Object Type
10
ZDCaxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
x - Open (freely definable)
Version 1.00
Effective Date:
3.6 Development Class
Development classes group together development objects (e.g. programs, tables, function modules) which can be
corrected and migrated together across instances. A development class can, for example, consist of a transaction or
a group of related transactions along with programs, DDIC objects, menu painters, screen painters, lock objects,
message classes, match codes, etc.
All custom development should be assigned to a custom development class. Temporary objects may be assigned to
class ‘$TMP’. Objects defined under the $TMP development class will not be migrated.
Development classes follow the naming convention:
ZDCx
D – Business Unit Code
C – Country Code
x – Open
3.7 ABAP Programs
The maximum length of an ABAP program name is 30. SAP requires that the first character begin with a Z or Y.
The next two characters identify the Business Unit Code and the Country Code, then Application ID and program
type, followed by a three character SAP-subsystem (non-interface development) or Legacy System Application code
(for interfaces only). The remaining three characters are numeric, with related development grouped into a numeric
series. All programs should adhere to the following naming convention:
ZDCa_bccc_xxxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
b – Program Type ID according to RICEF list
c – Last three digits from RICEF object ID
x – Open
Possible values for Program Type ID are listed below.
Program Type ID
C
E
F
I
R
Description
Data Conversion
Enhancements
Forms
Interfaces
Report
For interface development, an abbreviation of the external system should be included in the program name
(cccccccc):
 Novartis Consumer Health
Page: 12 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
3.8 ABAP Report Variants
When an ABAP report is created, ABAP may generate some database-specific selections on the selection screen.
Additional selection-screen criteria can also be programmed into the report. In order to execute a report for a
specific range of data or selection set, the selection ranges must be entered on the screen. However, if there is a
requirement to run the same report with same selection set, especially in batch, a variant can be used to save the
selection set entered on the screen. If a variant is used, there is no need to enter the same selection set again each
time the report is executed.
The maximum length of an ABAP variant is 14 characters. Report Variants should adhere to the following naming
convention:
(Attached to SAP-delivered programs)
Zxxxxxxxxxxxxx
x - Open (cannot contain the characters ‘&’ and ‘%’.)
(Attached to custom programs)
Zxxxxxxxxxxxxx
x - Open (cannot contain the characters ‘&’ and ‘%’.)
3.9 On-Line Programming
SAP online functionality is driven by transaction codes. Any on-line program normally involves the following
components:
 Screen painters
 Menu painters
 DDIC references and objects
 PAI modules
|
 PBO modules
| -------->
Constitute Module Pools
 Perform modules |
 Authorization objects
3.9.1 Transaction Codes
Each SAP transaction is identified by a unique transaction code which is listed in two SAP tables. Table TSTC
contains the attributes of the transaction, while table TSTCT contains the short text associated with the transaction.
Transaction codes should adhere to the following naming convention:
ZDCa_bccc
D – Business Unit Code
C – Country Code
a – Application ID
b – Program Type ID according to RICEF list
c – Last three digits from RICEF object ID
x – Open
All reports should be executed from an area menu or from the reporting tree.
3.9.2 ABAP Module Pools
An ABAP module pool is an ABAP program that checks and processes what the user enters during an on-line
transaction. It is thus part of the on-line processing. An ABAP module pool groups together the modules that
process common data. For each logical database program, module pools handle the access to database data
selections.
 Novartis Consumer Health
Page: 13 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
Due to their unique properties, module pools must partially follow SAP naming conventions.
SAPxZDCann
x - Module Pool Type (see table below)
D – Business Unit Code
C – Country Code
a – Application ID
nn - Sequential number
Module Pool Type
L
D
F
S
M
Functional Module
Logical Database Module
Subroutine Module
Screen Module
Module Pool
For logical database module pools, use the last three characters for the logical database name.
3.9.3 ABAP Module Pool Components
Naming conventions for Module Pool components must also adhere to SAP standards. See table below for detailed
conventions using the above example. (Note: ZDCann in conventions below should match Zannn in main Module
Pool name).
Module Pool Component Type
Data Definition (Global Data
Include) Module
Process Before Output (PBO)
Module
Process After Input (PAI)
Module
Performs (subroutines)
Process On Help-Request (POH)
Module
Process On Value-Request
(POV) Module
Naming convention
MZDCannTOP
MZDCannOxx,
x - Open
MZDCannIxx,
x - Open
MZDCannFxx,
MZDCannHxx,
x - Open
x - Open
MZDCannVxx,
x - Open
Remarks: It is strongly recommended that you use the ‘SAP Workbench’ to construct module pools. The SAP
Workbench is designed to enforce standard naming conventions.
3.9.4 Dynpros (Screens)
SAP screens are referred to as Dynpros. Standard SAP components, such as transactions, menus and tables, contain
Dynpros and the associated processing logic.
The identification of a Screen Painter Dynpro consists of an ABAP program name (8 characters) and a four digit
Dynpro number. For a customer-developed screen attached to an SAP-supplied program, the allowable range for
the Dynpro number is 9000-9999.’ For a customer-developed screen attached to a custom-developed program, the
programs initial number should be 0100. Additional screens should be created with an increment of 10.
Module Pool Component Type
Screen Number (Attached to
 Novartis Consumer Health
Naming convention
0100-9999 in increments of 10.
Page: 14 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
custom-developed program)
Screen Number (Attached to
SAP-supplied program)
Pop-up screen number
Version 1.00
Effective Date:
9000-9999 in increments of 1.
Parent screen number + multiples of 1 ( e.g. 101 for screen
100)
Remarks: Screens supplied by SAP must not be changed. Approval of the Application Development Team Lead and
Project Management will be required prior to the modification of SAP-supplied screens.
3.10 Batch Job Requests
The maximum length of a batch job request is 32 characters. Batch job requests should adhere to the following
naming convention:
ZDCa_xxxxxxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a - Application ID
x - Descriptive
The remaining characters are open.
Remarks: Background jobs supplied by SAP must not be changed without SAP approval. If it becomes necessary to
modify an SAP-supplied background job, it must be approved by both the Basis and Application Development Team
Leads. If accepted, the job must be copied to a new name, using the naming standards described here. The modified
version should be used instead of the original.
3.11 Batch Input (BDC) Sessions
Much of the data integrity of the SAP application is enforced at the application level (i.e. ABAP/Dynpros) rather
than the database level. As a result all batch data entry to the system must pass through the same application logic
as on-line data entry. This is accomplished via BDC sessions.
The BDC session should use a descriptive name to identify the process and thus the batch job.
BDC sessions should adhere to the following naming convention:
ZDCa_bccc_xx
D – Business Unit Code
C – Country Code
a - Application ID
b – Program Type ID according to RICEF list
c – Last three digits from RICEF object ID
x – Open
3.12 Logical Database
A logical database (LDB) creates a logical view of a physical dataset. Specifically, the developer has the ability to
link database tables to simplify report programming through standardized read accesses, authorization checks and
selections.
Logical database names consist of 20 characters, and should adhere to the following naming convention:
ZDCaxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
 Novartis Consumer Health
Page: 15 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
a - Application ID
x – Descriptive
Remarks: Due to the strategic importance of logical databases and the potential impact on system performance,
careful consideration should be made before creating any new logical databases. Approval of the Application
Development Team Leader will be required prior to the creation of any custom Logical Databases.
3.13 Menus
SAP menus are based on a combination of SAP Dynpros and ABAP programs (CUA). You can display these
menus by executing the appropriate SAP transactions.
Menus should adhere to the following naming conventions:
(Area Menu)
ZDCaxx
D – Business Unit Code
C – Country Code
a - Application ID
x - Descriptive
(CUA Status)
ZDCaxxyy
ZDCaxx – Area Menu
y - open
(Function Keys)
xxxx
x - Open
(Titlebar)
xxx
x - Open
3.14 ABAP Dictionary
Creation of custom DDIC objects should be kept to a minimum to avoid unnecessary maintenance efforts and should
cater to specific functional requirements which are not met in the SAP-supplied ABAP Dictionary.
The following are the points to be kept in mind during definition of DDIC objects:
 Foreign keys referencing SAP table primary keys are highly recommended.
 Table maintenance facility (SM31, SM30) should be encouraged only if data security is not highly critical.
 Documentation at the data element level should make use of the long text facility to make on-line help effective.
 For master data or transactional tables, the user names of the persons who created and/or changed data and the
date of creation/change should also be stored.
 Technical settings should be maintained on all custom tables
 Novartis Consumer Health
Page: 16 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
The maximum length for an object in the data dictionary is 30 characters. However, depending on the object type
the maximum length allowed may be less than 30 characters. The following section will describe the requirements
for different data dictionary objects.
3.14.1 Transparent Tables, Pool Tables, Structures
A transparent table has a 1:1 relationship (field for field) with a corresponding physical table on the underlying
database. Transparent tables are typically used to store master and transaction data.
Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary data).
Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table on the
database in which all the records of the allocated pooled tables are stored. Whereas in SAP a pool table can be
broken down into detailed key and non-key fields, at the database level a pool table is simply divided into one key
and one non-key field. Because of this structure, selections on pool tables are not as efficient as selections on
transparent tables.
Note: Custom search helps result in the generation of pool tables and table pools. The naming standards for these
pool tables will be automatically determined based on the naming standard of the search helps. (See Search Help
Objects below).
A structure does not correspond to any physical table in the database. It is simply a “record layout” which can be
manipulated internally in a program, and whose format can be shared across multiple programs.
Both table and structure names can be up to 16 characters.
Transparent tables, pool tables, and structures should adhere to the following naming convention:
ZDCa_bccc_xxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
b – Program Type ID according to RICEF list
c – Last three digits from RICEF object ID
x – Open
3.14.2 ATAB/Control Tables
The most well-known table pool in the SAP system is the ATAB table. When adding new tables to the ATAB table
pool, a maximum of 5 characters may be used. ATAB/Control Tables should adhere to the following naming
convention:
T9axx
a - Application ID
x – Open
3.14.3 Cluster Tables
Cluster tables contain continuous text, for example, documentation. Several cluster tables can be combined to form
a table cluster. Several logical lines of different tables are combined to form a physical record in this table type. This
permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least parts of
the keys must agree. Several cluster tables are stored in one corresponding table on the database.
Cluster tables are a remnant of “database limits” imposed when R/3 was first developed, which prevented certain
databases from handling more than a certain number of tables.
Custom-developed cluster tables should not be created.
 Novartis Consumer Health
Page: 17 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
3.14.4 Domains
A domain is a central point for describing the technical attributes of a field such as length and type. A domain
describes the value set for a field. This set of values is defined by specifying the format attributes, such as the
external format, length and type. The maximum length of a domain can be 30 characters long. The first 4
characters must be ‘ZDCa’ and the remaining characters can be assigned arbitrarily.
Domains should adhere to the following naming convention:
ZDCaxxxxxxxx...
D – Business Unit Code
C – Country Code
A – Application ID
x – Open
3.14.5 Data Elements
A data element is a semantic domain. It provides a precise description of the function of a domain in a specific
commercial context for the benefit of the fields that depend on it. Try to avoid defining new data elements for
existing SAP domains. The maximum length for a data element is 30 characters. The first 4 characters must be
‘ZDCa’. The remaining characters can be arbitrarily assigned.
Data elements should adhere to the following naming convention:
ZDCaxxxxxxxx…
D – Business Unit Code
C – Country Code
A – Application ID
x – Open
3.14.6 Table Fields
Fields do not exist as independent objects in SAP. They only exist as part of a table or structure. The
maximum length of a table field is 16 characters. They are freely definable, but field names should be
meaningful, and abbreviations should be consistent across a related set of tables whenever possible.
Consistency with SAP-delivered abbreviations is strongly recommended. For example, for an SAP client
number, use MANDT; for a customer number field, use KUNNR. Table fields should adhere to the following
naming convention:
(Attached to SAP-delivered tables)
ZZxxxxxxxxxxxxxx
x - Open
(Attached to custom tables)
xxxxxxxxxxxxxxxx
x - Open
3.14.7 Search Help
Search Help replaces the Matchcode from previous 3.x versions. Search helps can be used to assign an input help
(F4 help) to fields in input masks. Upon pressing the F4 key, the user is offered a number of possible search paths,
each of which presents a number of restrictions to limit the number of possible input values. After entering the
restrictions (if required), the system returns the values (hits), which satisfy the restrictions. The user then selects the
desired line from the hit list, and this value is copied to the screen mask.
There are two types of search helps: elementary and collective. An elementary search help corresponds to a search
path. It must define the selection method (how data of the hit list is read: table, view, or table with text table), the
interface (parameters) of the search help, and the online behavior of the search help (how displayed). A collective
 Novartis Consumer Health
Page: 18 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
search help comprises several elementary search helps. Its behavior is defined by the parameters of the collective
search help, as well as the search helps assigned to the collective search help.
SAP delivers a standard F4 input process, which is defined by defining a search help. If this standard does not meet
the desired requirements, a search help exit can be used at fixed times. The search help exit must have the same
interface as function module F4IF_SHLP_EXIT_EXAMPLE. (See Data Dictionary and function module on-line
help for more information.)
Search Helps may be up to 30 characters and should begin with ‘ZDCa’ and follow the naming convention:
ZDCaxxxx…..
D – Business Unit Code
C – Country Code
A – Application ID
3.14.8 View
Views can be used to create virtual tables that are not physically stored in the database, but present selected columns
from one or more tables which are stored in the database.
In the simplest case, a view can involve simply suppressing the display of one or more fields from a table
(projection) or transferring only certain records from a table to the view (selection). More complicated views can be
assembled from several tables, with individual tables being linked using the relational join operation. The maximum
length for the name of a View is 16 characters. However, the first 7 characters must be unique across all views - the
Data Dictionary will validate this.
The following naming convention should be used:
ZDCaxxxyyyyyyyyy
D – Business Unit Code
C – Country Code
A – Application ID
x - Open, must be unique across all views
y - Open
3.14.9 Lock objects
Lock objects control simultaneous access to a particular table by two update users via ‘locks’ which are set and
released by calling a function module. The function modules are automatically generated when the lock object is
activated. Lock object names can be up to 16 characters and should start with the character ‘E’. The second
character should be a ‘Z’ to identify the lock object as a customer object. The remaining characters are open but
should generally reference the name of the primary table to which the locks will be applied.
Lock Objects should adhere to the following naming convention:
EZDCa_tttttttttttt
D – Business Unit Code
C – Country Code
A – Application ID
t – Primary table name (where multiple Lock Objects are required for the same primary table, assign a unique
digit to the final position).
3.15 Function Library
The SAP function library is used to group related Function Modules into Function Groups.
 Novartis Consumer Health
Page: 19 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
3.15.1 Function Groups
Function groups allow for grouping related function modules and their components into a common area. Also,
common variables may be shared by all function modules within a function group.
Function groups should adhere to the following naming convention:
Z_DCaxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a - Application ID
x - Open
3.15.2 Function Modules
The SAP function modules are programs written in ABAP that form logical units in function groups. They can be
shared by multiple ABAP programs and by other function modules. They are managed centrally in the function
library.
Function modules are grouped together using the function groups. Function modules may be defined to one and
only one function group. SAP-supplied function groups should never be used to define new function modules.
Function modules are similar to programs, the primary difference is they can be called using remote function calls
from the operating system, can be called variably within and across programs, and are not typically built for
reporting using selection criteria.
Function module names can be a maximum of 30 characters. The following naming convention should be used:
Z_DCa_xxxxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a - Application ID
x - Open (separate words with underscores)
Remarks: All function modules should follow programming standards outlined in this document. There is no
difference between programs and function modules when considering logic flows, syntax, unit testing, and variable
naming.
3.16 SAPscript Layout Sets
SAPscript is a tool in R/3 for formatting text documents. The formatting rules are stored in R/3 objects called a
Layout set. Layout sets can be used to format R/3 standards text or to format the output of ABAP reports. In
particular, SAPscript can be used to format R/3 forms (Purchase Order/ GRN / Invoice / etc) when they are
displayed on the screen or printed on a printer.
A maximum of 16 characters can be used to name Layout Sets. The following naming convention should be used:
ZDCa_bccc_xxxxxx
D – Business Unit Code
C – Country Code
a - Application ID
b – Program Type ID according to RICEF list
c – Last three digits from RICEF object ID
x – Open (use as much as possible from original SAP object)
 Novartis Consumer Health
Page: 20 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
3.17 Message Classes
Message Classes are used to group related error messages together. Message Classes should adhere to the following
naming convention:
ZDCaxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a - Application ID
x - Open
3.18 EDI / ALE Objects
3.18.1 IDOC Segment Type
IDOC Segment types may be up to 27 characters in length, and should adhere to the following naming convention:
Z1DCaxxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
x – Open
3.18.2 IDOC Segment Name
IDOC Segment Names may be up to 30 characters in length, and should adhere to the following naming convention:
Z2DCaxxxxxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
x - Open
3.18.3 Basic IDOC Type
Basic IDOC Types may be up to 30 characters in length, and should adhere to the following naming convention:
ZDCaxxxxxxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
x – open
3.18.4 Enhancement IDOC Type
Enhancement IDOC Types may be up to 30 characters in length, and should adhere to the following naming
convention:
ZDCaxxxxxxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
x – open
3.18.5 Logical Message
Logical Messages may be up to 30 characters in length, and should adhere to the following naming convention:
 Novartis Consumer Health
Page: 21 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
ZDCaxxxxxxxxxxxxxxxxxxxxxxxxxx
D – Business Unit Code
C – Country Code
a – Application ID
x - open
 Novartis Consumer Health
Page: 22 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
4. PROGRAMMING STANDARDS
4.1 Overview
The ABAP language is an "event-driven", "top-down" programming language. The ABAP processor controls the
execution of an event. For example, the event AT SELECTION-SCREEN is executed when the user hits ENTER
on the selection screen and the event START-OF-SELECTION is executed once all selection screen validations are
complete. Because the ABAP language incorporates many "event" keywords and these keywords need not be in
any specific order in the code, it is wise to implement in-house ABAP coding standards, for ease of maintainability
and consistency across programs.
This section contains a list of ABAP coding standards, as well as some efficiency standards. The purpose of these
standards is to:

Encourage consistent practices among programmers: Programs coded by different people should
follow standard coding conventions.

Provide internal documentation: Programs should be documented to the extent that another
programmer could follow the logic of the code.

Improve readability: Programs should follow a format that makes the code easy to read.
4.1.1 General


SAP-delivered ABAP programs, Dynpros, SAP transactions and Batch programs should never be
changed without the approval of the Application Development Team Leader. If it becomes
necessary to modify one of these objects, then, if possible, the object should be copied to a new
name using Novartis SAP naming standards, and modifications should be made to the copied object.
Before writing any code, make sure that no existing modules satisfy the coding requirements.
If custom coding is necessary, attempt to write the module so that it is re -usable and can be stored
in a central library. Function modules are an example of this approach.
4.2 User Exits





Obtain approval from the BU Fast Team.
Contact the central administrator to update table ZNU_BU_ACTIVE.
The central administrator uses transaction code ZNU_BU_ACTIVE to maintain the table
ZNU_BU_ACTIVE. This table is client dependent and maintaining it activates the object for a specific
client.
If necessary activate the SAP enhancement using transaction CMOD. Note that when you activate
an enhancement in CMOD, the enhancement is active across all clients
The first business unit to develop the object must insert the code below. Subsequent business units
will insert code only in their section.
CALL FUNCTION 'ZNU_BU_ACTIVE'
EXPORTING
NAME
= USER-EXIT-NAME
IMPORTING
ZNU_BU_ACTIVE = ZNU_BU_ACTIVE.
if znu_bu_active ne space.
case znu_bu_active-zz_bu_identifier.
when 'OTC'.
 Novartis Consumer Health
Page: 23 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
*insert include for otc here
when 'MN'.
*insert include for medical nutrition here
when 'IB'.
*insert include for infant and baby here
endcase.
endif.

The include created for should follow the appropriate naming conventions as specified in this
document. In addition to the standards found there the following standard can also be used.
ZDCA_Tnnnn_XXXXXXXXXXXXXXXXXXX
Where Z is for customer namespace,
D is for business unit identifier
C is for country code
A is for application area
T is for RICEF type
N is for RICEF number
X is free text and should the user-exit name excluding the word EXIT.
For example if OTC is going to use the user-exit called EXIT_SAPLKEDRCOPA_001 and it has the
RICEF id CO-ENH-006 then the include should be called ZOUK_E006_SAPLKEDRCOPA_001.

Object to support the process
Function Module:
ZNU_BU_ACTIVE
Maintenance Table:
ZNU_BU_ACTIVE
Transaction Code:
ZNU_BU_ACTIVE
4.3 Hardcoding

Programs generally should contain no hard-coding. Hard coding builds in maintenance problems, limits our
flexibility, and makes assumptions that today’s world will continue indefinitely.

Examples of hard coding which are not acceptable:
Select * from MARC where WERKS = ‘5000’ …
If VBFA-VBTYP_N = ‘J’ …
W_COST = MBEW-STRPS * 1.2.
Cases where hard coding might be acceptable:

Programs used only once, e.g. conversion programs

Defining screen names and numbers for BDC processing
Reasons not to hard code include:

Data values may change or be added
 Novartis Consumer Health
Page: 24 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:

May not be easy to change in the future

Requires IS personnel to make change

Requires approval to make change

Client’s business requirements may change, new plants added, different codes or values used, etc.

SAP may change data values in a future release
Possible alternative solutions:

Use parameters or select-options

Use existing tables

If none exist, should a custom table be created?

Use a function module to determine the data value needed
4.4 Checking Return Codes

A program should test the system return code field (SY-SUBRC) after any statements that could potentially
change its value unless the outcome of the statement is not important for subsequent processing.

The return code should always be checked after any database table read/update statements.

Be aware that many ABAP statements will set the value of the system return code. It is advisable, therefore, to
test the return code immediately after the statement whose outcome is important, rather than further along in the
code.

Refer to Appendix A for a list of ABAP statements/keywords that set the system return code and possible
values as a result of these.

Notes:
For SELECT ... ENDSELECT processing loops, the return code should be checked after the ENDSELECT
statement to check for the success of the SELECT statement.
For LOOP AT ... ENDLOOP processing loops, the return code should be checked after the ENDLOOP statement
to check for the success of the LOOP statement.
4.5 Documentation and Comments

To enhance maintenance and debugging of source code, program documentation should be quite exhaustive.
Every logical division within the program should have descriptive comments immediately prior to the actual
code. SAP provides ready-made comment heading structures, check the on-line help on the IC command.
Basically, this means comments - lots of comments!

All comments should be blocked in the program – not alone. This makes the program more readable.

Use the SAP online documentation – a functional description should be given to each program in the system.

ABAP code is fairly self-documenting. However, it is wise to provide future programmers with documentation.
Explain the purpose, design, structure and any testing hints at the top of the program. Include any key decisions
and assumptions made.
 Novartis Consumer Health
Page: 25 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards

Version 1.00
Effective Date:
Each program should have a comment box after the “REPORT” statement as shown below (which
includes the modification log):
REPORT ZUSFRGLM001.
******************************************************************************
* Program Name: XXXXXXXXXXX
*
* Author:
XXXXXXXXXXXXXXXXXXXX
*
* Create Date: MM/DD/CCYY
*
* Description:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*
*
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX* *
*
*******************************************************************************
*
MODIFICATIONS
*
*******************************************************************************
* INIT WHO
DATE
TEXT
* XXX XXXXXXXXXXXXXXXXXXX MM/DD/CCYY
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
*
*
******************************************************************************

Once the program is in the production environment, every modification, no matter how insignificant, should
be documented with an additional comment box added to the program. This provides an easy audit trail of the
program’s history, and also allows for comparison of versions in different environments “at a glance” rather than via
remote comparisons.

Be sure to include all updates as part of the “Documentation” screen of the ABAP editor. Remember that others
may be reading your documentation for many years - check the documentation for correct format and
spelling/grammatical errors.

Comment all subroutines with their purpose. Comments should explain the business reasons for the code in a
particular section and what the code in that section is accomplishing. Comments should not explain individual
ABAP commands.

Whether or not to delete old code when modifying a program will be left to the discretion of the programmer.
SAP's version control should provide an audit trail of changes between versions. However, the programmer should
consider if simply commenting out the old code, rather than deleting it, will make comparisons easier for subsequent
programmers.

HINT: The standard header and modification comments boxes can be added in the ABAP editor by selecting
EDIT -> PATTERN -> OTHER PATTERN and selecting Novartis.

The noting of which lines were changed or added for a modification is recommended with PERnnn, where nnn
is the change number (001, 002, 003, etc.) This “search string” should be recorded in the comment box for the
modification at the beginning of the program. An easy way to modify a block of code with the search string is as
follows, utilizing the MOVE and OVERLAY commands:
ABAP Editor
....+....1....+....2....+....3....+....4....+....5....+....
000160 INSERT D030L-TYPE D030L-DDNAME D030T-DDTEXT
 Novartis Consumer Health
Page: 26 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
000170
Version 1.00
Effective Date:
D030L-SEGMENTID D030L-DOCTYPE
000180 INTO HEADER.
M00190
"PER001
000200
000210
OO0220 SELECT * FROM D030L WHERE
000230 DDNAME BETWEEN TABLEFR AND TABLETO.
000240 CHECK D030L-DDMODIFY NE USR.
000250 SELECT * FROM D030T WHERE
000260
DDLANGUAGE EQ SY-LANGU AND
000270
DDNAME EQ D030L-DDNAME.
000280 ENDSELECT.
000290 EXTRACT HEADER.
OO0300 ENDSELECT.
000310
After pressing the enter key your program will look like the following:
....+....1....+....2....+....3....+....4....+....5....
000160 INSERT D030L-TYPE D030L-DDNAME D030T-DDTEXT
000170
D030L-SEGMENTID D030L-DOCTYPE
000180 INTO HEADER.
000190
000200
000210
000220 SELECT * FROM D030L WHERE
"PER001
000230 DDNAME BETWEEN TABLEFR AND TABLETO.
000240 CHECK D030L-DDMODIFY NE USR.
000250 SELECT * FROM D030T WHERE
DDLANGUAGE EQ SY-LANGU AND
000270
DDNAME EQ D030L-DDNAME.
000290 EXTRACT HEADER.
000300 ENDSELECT.
"PER001
"PER001
000260
000280 ENDSELECT.
"PER001
"PER001
"PER001
"PER001
"PER001
"PER001
000310
 Novartis Consumer Health
Page: 27 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
4.6 Program Structure/Style

When events (e.g. END-OF-SELECTION, TOP-OF-PAGE, etc.) are used in the code, they should appear in the
order in which they are generally executed. Any events not used may be deleted.

Each ABAP command consists of a sentence ending with a period. Multiple commands can be on one line;
however, as a standard start each new command on a new line. This will allow for easier deleting, commenting, and
debugging. If a statement continues past one line, subsequent lines should be indented.

Skipped lines and indention should be used to promote clarity between sections of code as well as between file
definitions and declarations.

The ABAP editor has a PP (Pretty Printer) command to indent specific lines of code by 2 positions and add
subroutine comments.

For ease of reading code, concatenate repetitive commands with a colon as provided by SAP. This is
particularly applicable to repetitive MOVE and WRITE statements. For example:
WRITE: LFA1_LIFNR,
LFA1_NAME1,
LFA1_ORTO1.

Keep programs to a reasonable length. Programs should be long enough so that there is not an excessive amount
of data being passed between two related programs, but should be short enough so that the same program does not
perform many discrete functions.

Consider the use of INCLUDE programs for Data Declarations, PBO Dynpro modules, PAI Dynpro modules,
Subroutines, and Individual Event Processing.

Use subroutines and FORM paragraphs whenever possible to improve readability and logic flow. If a block of
code is executed more than once, it should be placed in a subroutine at the bottom of the code. This makes the code
more readable, requires less indentation, and is easier to debug.

FORM paragraphs should be placed after all non-subroutine code, after the END-OF-SELECTION event.
FORM paragraphs should generally be positioned in the order in which they are called within the program.

All TYPEs, TOs, VALUEs, DEFAULTs, table names, and comments should be aligned among themselves
throughout the code.
4.7 Data Definition

Internal Program Data Variables:
Data variable names can be up to 32 characters long, with the exception of selection-screen parameters and
select-options which can only be 8 characters long. Variable names should be descriptive.
Variables should be named as follows:
a_xxx...
a - Variable Type
x - Open
Possible values for VariableType are listed below.
 Novartis Consumer Health
Page: 28 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
When defining internal tables, always use the “occurs 0” option unless you know the exact number of rows.
Variable
Type
P_
S_
C_
R_
T_
X_
L_
V_
Represents
P_ for selection screen parameters
S_ for selection screen SELECT-OPTIONS fields
C_ for constants
R_ for ranges
T_ for internal tables
X_ for structures
L_ for local variables
V_ for global variables

Within a table name or within a field name, use an underscore (e.g. CUST_NO or T_LIKP). This
will avoid confusion when connecting the table name and field name together with the required hyphen
(e.g. T_LIKP-CUST_NO). In general, hyphens should be avoided except in the specific case of
connecting a table name to a field name.

Table definitions should be formatted as follows. Only one table shall be listed on any one line of the program,
and the table description should be added as the end of line comment.
Example:
TABLES:

T001,
T100,
TDCT,
TAPLT.
“Company codes
“Messages
“Dialog Modules
“Program applications
Comment work fields and fields in work records, especially those used for interfacing.
Example:
DATA: BEGIN OF T_REC,
ind,
f1 LIKE MA-IDNRA,
f2 LIKE MA-KTX01,
f3(16),
END OF T_REC.
"interface type ind.
"material number
"material short text
"filler

Always perform an analysis on data volumes before assigning value to the OCCURS parameter for
the definition of an internal table.

For each field, include a comment (after the field) describing the use or purpose of the field.

Data fields should appear in alphabetical order within each grouping (except for internal tables).

Use INCLUDES for:
 Novartis Consumer Health
Page: 29 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards

Data structures that will be used in more than one ABAP program.

Dictionary defined tables.
Version 1.00
Effective Date:

When assigning internal fields that are to hold values from databases, use the LIKE option to ensure that the
variables have identical characteristics. Example:
DATA:
V_LIFNR LIKE LFA1-LIFNR.

Fully declare each field unless LIKE is used. Do not let the data type or the length default. For fields that are
whole numbers, it is not necessary to define them with zero decimal places.

Fields that require initialization should either be initialized as part of the declaration using the VALUE clause or
in an INITIALIZATION "form" that is called immediately after the last data statement (as well as other places in the
code). If initial field values must be reestablished multiple times during the execution of the program it is preferable
to use one or more FORM(s). If fields need only be initialized one time, either method may be used.

If "field symbols" are used, their use must be fully explained in program comments at the place were the symbol
is defined and used.
4.8 Text Elements

Do not use hard-coded literals. Use Text Elements to handle literal text that is printed on a report.
WRITE:/ TEXT-001. “ writes error message
The advantage to using Text Elements is easier maintainability.

Do not use Text Elements for constants. Constants should be defined in the DATA statements.
Example:
CONSTANTS:

C_ONE_THOUSAND
C_TRUE
C_FALSE
TYPE I VALUE 1000,
TYPE C VALUE ‘TRUE’,
TYPE C VALUE ‘FALSE’.
Literal text that is printed on the report can be handled in two ways:
1. By hard-coding the literal in the code:
WRITE:/ 'Grand Total:' (001), ...
2. Through Text Elements. For example:
WRITE:/ TEXT-001.

All numeric fields that may contain a negative value should be displayed or printed with a trailing minus sign
(SAP standard).

Selection Texts: Ensure that all the selection-options and parameters have a corresponding text in the selection
texts. Also ensure that there are no additional selection texts (i.e. selection texts are present for parameters or selectoptions which are not there in the program). All Selection Texts should be in lower-case with the first word starting
with a capital letter.

Text Symbols (Numbered Texts): All text symbols used for headers should have numbers H01, H02, H03….etc.
As far as possible, use one text for one report header line.

All Text Symbols used for messages should have numbers M01, M02, M03…etc
 Novartis Consumer Health
Page: 30 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
4.9 Report Standards

Reports use the SAP database for information access based on selection criteria or variants specified by the
user. Report programs should follow modular logic to ensure code readability and ease in error tracking.

The only report screen is 100, which is automatically assigned by SAP.

Specify blank lines (for output) by using “SKIP TO LINE <nn>” or "SKIP <n>“, rather than multiple “WRITE
/” lines.

For program parameters, use Selection Texts to specify literals that will appear on the screen. This will enable
the literal to be implemented in multiple languages. (See Text Elements below).

See “International Considerations” section for paper size considerations.

Use the standard page header function in the TOP-OF-PAGE event of the program to provide a standard page
header for the report.
4.10 Batch Program / Interface Standards

Message statements executed in batch programs are output to the txn SM37 "Job Log". "Success"
messages (type ‘S’) should be used generously to provide an audit trail of the program's execution.

Include record counters to indicate the number of records read and processed. Write out exceptions
to a report.

Document program variant(s) if a program needs to run wit h special parameters.

External datasets should be referenced and named using SAP logical file names. SAP's FILENAME
table allows for differentiation between the logical and physical dataset names. For example, the logical filename
defined to a program may be "CUSTOMER_FILE" while the physical file may be "/sap/<SID>/cust/in/cust.dat".
The SAP system will automatically replace the <SID> field with the system ID, allowing for transporting of
interface programs between development/test environments.
See the following example:
DATA:
G_PDSNME LIKE FILENAME-FILEEXTERN. "Physical Dataset Name.
DATA: BEGIN OF T_TAB OCCURS ...
END OF T_TAB.
PARAMETERS: P_LDSNME LIKE FILENAME-FILEINTERN "Logical Dataset Name
DEFAULT 'CUSTOMER_FILE'.
AT SELECTION-SCREEN.
CALL FUNCTION 'FILE_GET_NAME'
EXPORTING
LOGICAL_FILENAME = P_LDSNME
IMPORTING
FILE_NAME = G_PDSNAME
EXCEPTIONS
FILE_NOT_FOUND = 01.
IF SY-SUBRC <> 0.
 Novartis Consumer Health
Page: 31 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
*-------No physical filename can be determined for &
MESSAGE E016(MG)WITH P_LDSNME.
ENDIF.
START-OF-SELECTION.
OPEN DATASET G_PDSNME FOR OUTPUT IN TEXT MODE.
IF SY-SUBRC <> 0.
* Insert error processing here.
ENDIF.
TRANSFER T_TAB TO G_PDSNME.
CLOSE DATASET G_PDSNAME.

An ABAP program that reads from or writes to a sequential dataset should always OPEN the dataset before the
read/write operation, and after file processing it should CLOSE the file. Although these statements are not
mandatory, it is good practice to include them. Also, without an OPEN DATASET statement, a file will always be
opened in BINARY mode. This may not be the mode required!
4.11 Online Standards

If the layout of screens is the same for multiple functions (such as Add, Move, Delete), use the same
screen for all functions. Use online status and security features to control which function is executed.

If, on your screen, you are going to use a variable length table, put static data above it.

Define all global data in the main program module instead of the PBO/PAI.

To handle a lock entry failure, invoke an error message (type E) to prevent any further progress but
leaving the user on the current screen. The user can then take an alternative action or continue to try to
lock the object. To minimize the impact on users, limit retr ies.

When activating buttons or boxes, activate the associated text as well. This enables the user to click
on either the button/box or the text.

Use Data Dictionary names (short, medium, long) for field text on screens where applicable.

Use SAVE_OK_CODE as the field name when saving the OK Code field. It is recommended that
you use a backup version of the OK Code field to avoid sending a screen that already has a function
code.

Always define the field with a Format = OK as OK_CODE. This field is used to v alidate the OK
Event.

Screen and program field names should generally be identical.

The following are suggested PF-Key assignments:
PF1
PF2
PF3
PF4
Help
Select or Choose
Back (1 level)
Show possible entries
PF11
PF12
Save
Cancel
 Novartis Consumer Health
Page: 32 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
PF13
PF14
PF15
Print
Delete
Exit (to top menu)
PF21
PF22
PF23
PF24
First Page
Page Forward
Page Backward
Last Page
Version 1.00
Effective Date:

Do not use AT PFnn in programs. Instead use the function name so that any method of invoking the function
will have the same effect as the use of the PF-Key.
AT USER-COMMAND.
CASE SYST-UCOMM.
WHEN “funct-name-1”.
WHEN “funct-name 2”.
etc.
ENDCASE.
4.12 Messages
Error messages used in any program code may be created as SAP system messages. These messages are able to
hold up to 4 custom variables within the error text and are defined by both a message class and message ID.
Message ID is simply a two character alphanumeric string to be selected at the developer’s choice. Every program
should be associated with a default message class. Use of multiple message classes within one ABAP program
should be avoided.
Sample Message ID:
REPORT ZMESSAGE MESSAGE ID ZI. "Sets up ZI as the default message class.
...
MESSAGE E001. "Specifies message 001.
"Looks up message ZI-001 in message table.
"The first positon indicates the type of message:
" E - Error
" W - Warning
" I - Information
" A - Abend
" S - Success

Every program should use MESSAGE statements for errors, warnings, and information.

The severity of the message is indicated by the MESSAGE statement in the program.

Although consistency with SAP-supplied messages is highly encouraged, do not use SAP default
message IDs, as these IDs can change from release to release. Instead, copy these messages to customer
(X) message IDs.
4.13 Subroutines

Use local variables inside internal subroutines for all variables that do not need to be global.

Pass variables to internal subroutines through parameters and arguments rather than relying on the use of global
variables.
 Novartis Consumer Health
Page: 33 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
Exceptions are allowed for cases where the value of the subroutine would be compromised by using parameters.
One such example would be a subroutine whose purpose is to initialize variables in the calling program to their
"initial value" state. In the case where global variables are used in a subroutine, comments in the subroutine
header must be used to describe the use of global variables. Tables from the main program may be globally
referenced in subroutines.

Use of the CHANGE OF clause on parameters is permitted when desired.

Place any subroutine that may be needed by more than one ABAP program in a function module.
 Novartis Consumer Health
Page: 34 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
5. EFFICIENCY STANDARDS
5.1 General
5.1.1 General: Dead Code
Avoid leaving "dead code" in the program. Remove defined fields that are never referenced and code that can never
be logically executed. To analyze the program, use the utility function in Tools -> Case -> Development ->
Program Maintenance -> ABAP Development -> Utilities -> Development/Test -> Analysis.
5.2 Reports
5.2.1 Reports: Control Breaks

It is more efficient to use the AT statements ( AT NEW, AT END OF, AT LAST ...) or summing and control
breaks purpose. AT statements are generally better for internal table processing than ON CHANGE OF statements
because they take in to account the hierarchical structure of the internal tables and allow automatic summing.
However remember that inside an AT NEW or AT END OF statement you cannot reference individual fields that
are physically to the right of the control field in the internal table. This makes sense in most cases and should serve
as an aid in designing internal table structure.
5.3 Database Access
5.3.1 Database Access: General

When using the SELECT statement, study the key and always provide as much of the primary key as possible.
If the entire primary key can be qualified, code a SELECT SINGLE. SELECT SINGLE requires one
communication with the database, while SELECT requires two.

When using the SELECT statement, if the order of the records returned is important, use the “ORDER BY”
parameter.

Limit database SELECT statements to the shortest processing time possible, by minimizing the logic within the
select loop. The only logic within the select loop should relate to decisions as to whether a record should be selected
or not. Generally, programs should be broken into three distinct functions:
1. Select data from database into an internal table.
2. Process data stored in the internal table.
3. Output the data to some medium (e.g. screen, flat file, report).

Do not use DBMS specific SQL. Under no circumstances will native database updates directly to the
underlying DBMS engine be permitted in an ABAP program.
5.3.2 Database Access: Buffered Tables

There are some tables that are buffered in R/3 for better performance. But then the program that accesses the
buffered table must take in to account that the buffer may not have the latest data. If a program does require the
latest data from a table it is better to qualify the SELECT statement with ‘BYPASSING BUFFER’ specification.

For all frequently used, read-only tables, attempt to use SAP-buffering. Network, Application-server and
Database load is considerably less.
5.3.3 Database Access: Select * vs. Select Single *
 Novartis Consumer Health
Page: 35 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:

When using the SELECT statement, study the key and always provide as much of the left-most part of the key
as possible. If the entire key can be qualified, code a SELECT SINGLE rather than a SELECT. If the fields on
which the selection must be made do not comprise the primary key, consider the creation of a matchcode, view, or
index to provide more efficient access to the data.

If you are interested in exactly one row of a database table or view, use the SELECT SINGLE statement instead
of a SELECT * statement. SELECT SINGLE requires one communication with the database system whereas
SELECT * requires two.
5.3.4 Database Access: Cluster Tables

Accesses to cluster type tables via non-key selection criteria should be avoided if possible. Also, note that
complex “where” clauses for pool and cluster tables may not be able to be passed to the database, and may require
processing by the SAP database interface post-selection. Consider creation of matchcodes for these tables, or
consider conversion of these tables to transparent and creation of indexes.
5.3.5 Database Access: Selecting one row without the full key

When only one record is sought from a given SELECT statement, and if you don't have the full primary key,
use the following construct to prevent unnecessary database hits:
SELECT * FROM itab UP TO 1 ROWS
WHERE …..
ENSELECT.
5.3.6 Database Access: Select * with Check
SELECT * FROM <TABLE>
CHECK: <CONDITION>
ENDSELECT
vs.
SELECT * FROM <TABLE>
WHERE <CONDITION>
ENDSELECT

Always specify your conditions in the Where-clause instead of checking them yourself with check-statements.
The database system can then use an index (if possible) and the overall systems resource load is considerably less.

The upper version should not be used. In that case, the contents of the whole table must be read from database
files into DBMS cache and transferred over the network. Only after this, is the unselected data filtered out!

As a general rule, always specify all known conditions in the WHERE clause (if possible). If there is no
WHERE clause the DBMS has no chance to make optimizations.
5.3.7 Database Access: Selecting certain fields

If only certain fields (i.e. columns) from records are needed, then only those fields should be read from the
database. The number of fields can be restricted in two ways
using a view defined in ABAP Dictionary
using a field list in the SELECT clause of the statement.

The gain in performance is linear to the amount of data transferred. If only half the fields are selected, the
statement is executed twice as fast.
 Novartis Consumer Health
Page: 36 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:

On the other hand, extensive use of field lists (not views) might lead to a large variety of statements. This might
influence the performance of the statement cache managed by the database interface.
5.3.8 Database Access: Range Tables

The range tables (internal tables with fields INCLUDING, OPERATOR, LOW, HIGH) created by parameters
and select options can be used in the WHERE condition and are well suited for the redirection of users input
(selection screen) to the database.

However, the database interface reformats the range table into a Standard SQL statement. Thus, the size of the
resulting statement depends on the size of the range table. Unfortunately, the maximum size of an SQL statement is
limited by the specific DBMS.
For example, the statement:
SELECT * FROM LIKP
WHERE VSTEL IN S_VSTEL.
ENDSELECT. "LIKP
is reformulated into the following statement, assuming S_VSTEL contains the entries (0100, 0200, 0300, 0400,
etc.):
SELECT * FROM LIKP
WHERE VSTEL = '0100' OR
VSTEL = '0200' OR
VSTEL = '0300'
…
…
ENDSELECT. "LIKP

Thus, when using a range table, there is the danger that the table from which the range table is filled is too large.
The result is a runtime error depending on the size of the table!
5.3.9 Database Access: Views and Inner Joins vs. Nested Selects for Joins
Nested SELECT statements
SELECT * FROM <TABLE-A>
SELECT * FROM <TABLE-B>
ENDSELECT.
ENDSELECT.
vs.
Select with view
SELECT * FROM <VIEW>
ENDSELECT.

To process a logical "join", use a view or inner join wherever possible instead of nested SELECT statements.
Network load is considerably less.

Advantages of database views:
The view can be easily reused in other programs
 Novartis Consumer Health
Page: 37 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
Fields common to both tables (join fields) are not transferred from the database to the application.
Records not contained in the join (entries from table 'PERS' with no corresponding entries in 'PERSPROJ') are not
transferred.
The way the two tables are joined is determined by the DBMS and thus can be optimized.

A join statement may also be coded directly in the program. In a relational data structure, it is quite normal for
data that belongs together to be split up across several tables to help standardization. To regroup this information in
a database query, you can link tables using a join command. This formulates conditions for the columns of the
tables involved. An inner join contains all combinations of lines from database table 1(MSEG in the example below)
with lines from database table 2(MAKT in the example below) that meet the condition specified in the logical
condition ON. Additionally, a WHERE clause may also be included in the same way used in normal selects.
WARNING!! The driving table in an inner join in critically important. A driving table is the first table to be
accessed in a join statement. This is where the database first restricts the data set being transferred. Only after
meeting all of the selection criteria for the driving table does the DBMS check for a corresponding entry in the other
table(s). Generally, this is the rightmost table in the FROM line, but not always. The database optimizer will look
for the best index to select on based on the WHERE condition specified. If this is in the leftmost table, that will be
the driving table, otherwise, all indices equal or if no WHERE condition is specified, it will be the rightmost.
An example joining tables MSEG with MAKT:
SELECT MSEG~MATNR MSEG~MENGE MAKT~MAKTX
INTO ( MSEG-MATNR, MSEG-MENGE, MAKT-MAKTX )
FROM MAKT INNER JOIN MSEG
ON (MAKT~MATNR = MSEG~MATNR)
WHERE MKPF~BUDAT < SY-DATUM
ENDSELECT.
5.3.10 Database Access: Index Design

Indexes may be developed when the required access to a database table is based on fields other than the primary
key of the table. The following are rules for the design of indexes:

First it must be stated that table design is a more logical work while index design is rather technical. In table
design it might make sense to place certain fields (client, company code, …) in the beginning. In index design, this
is not advisable.

Very important for an index is that it contains very selective fields in the beginning. Those are fields like object
numbers. Not selective are client, company code, …

Indexes should be small (few fields). Some optimizers are able to combine two or more indexes to execute a
query. This is not possible with wide indexes.

Multiple indexes of one table should be disjoint (have few common fields), in order not to confuse the optimizer
which index to use.

Each index slows the inserts into the table down. Updates are only slowed down if indexed fields are updated.
On the other hand, the indexes increase the efficiency of reads. These tradeoffs must be weighed against one
another. In general, frequently updated tables should have only few indexes while frequently selected tables might
have more.

Creation of new Index must be approved by member of TI team.
 Novartis Consumer Health
Page: 38 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
5.3.11 Database Access: Logical Databases

Use logical databases when practical to simplify reading of data, to minimize redundancy in programs, to
minimize maintenance, etc. Consider selection and efficiency when programs are designed. Data access may be
more efficient via selects. As a general rule, use logical databases when the logical database hierarchy is at least an
80% match of the database access you would request anyway down to the lowest level you need for your program.
(Ignore portions of the hierarchy below the lowest level you need).

Choose the most efficient logical database possible. Study the selection criteria and which secondary indexes
are used for that view. Provide the appropriate selection criteria to limit the number of database reads. Force users
to provide selection criteria by evaluating the selection criteria entered on the selection screen during the AT
SELECTION-SCREEN event.

When using the GET event keyword to retrieve records via a logical database, selection can be restricted by
using the CHECK statement (using either CHECK select-option(s) or CHECK condition).
In this case, a CHECK statement that returns a negative result terminates the processing of GET events for
subordinate database tables and the associated data is not read. For efficiency reasons, you should therefore
always perform the CHECK at the highest possible level of the database hierarchy.
For example, instead of:
SELECT-OPTIONS: S_CNTRY FOR KNA1-LAND1,
S_COY FOR KNB1-BUKRS.
...
GET KNB1.
CHECK SELECT-OPTIONS. (or CHECK: S_CNTRY,
...
S_COY.)
code it as:
SELECT-OPTIONS: S_CNTRY FOR KNA1-LAND1,
S_COY FOR KNB1-BUKRS.
...
GET KNA1.
CHECK S_CNTRY.
GET KNB1.
CHECK S_COY.
...
5.3.12 Database Access: Matchcodes

Remember the power of matchcodes for selection and report sorting. Any matchcode which can be used to
view data in an on-line transaction can also be accessed from an ABAP program. For example, to build an internal
table of all Deliveries which have not been Goods Issued with their corresponding weights, instead of:
SELECT * FROM LIKP.
SELECT SINGLE * FROM VBUK
WHERE VBELN = LIKP-VBELN AND
WBSTK = ‘C’.
“Goods Movement Status = Goods Issued
IF SY-SUBRC = 0.
MOVE LIKP-VBELN TO T_DELIV-VBELN.
MOVE LIKP-BTGEW TO T_DELIV-BTGEW.
APPEND T_DELIV.
ENDIF.
ENDSELECT. “ LIKP
 Novartis Consumer Health
Page: 39 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
code it as:
SELECT * FROM M_VMVLA. “Deliveries not Goods Issued Matchcode
SELECT SINGLE * FROM LIKP
WHERE VBELN = M_VMVLA-VBELN.
IF SY-SUBRC = 0.
MOVE LIKP-VBELN TO T_DELIV-VBELN.
MOVE LIKP-BTGEW TO T_DELIV-BTGEW.
APPEND T_DELIV.
ELSE.
“INSERT ABEND LOGIC HERE
ENDIF.
ENDSELECT. “VBUK
ENDSELECT. “M_VMVLA
5.4 Internal Tables
5.4.1 Internal Tables: Reading a Single Record
When reading a single record in an internal table, the READ TABLE WITH KEY is not a direct READ. Therefore,
SORT the table and use READ TABLE WITH KEY BINARY SEARCH.
5.4.2 Internal Tables: Sorting
SORT ITAB BY FLD1 FLD2.
vs.
SORT ITAB.

When SORTing internal tables, specify the fields to be SORTed.
5.4.3 Internal Tables: Select Into vs. Append
SELECT * FROM <TABLE>.
MOVE-CORRESPONDING TABLE TO INT_TAB.
APPEND <INT-TAB>
ENDSELECT.
vs.
SELECT * FROM <TABLE> INTO TABLE <INT-TAB>.

It is always faster to use the INTO TABLE version of a SELECT statement than to use APPEND statements
5.4.4 Internal Tables: Calculating Totals
Calculating totals via READ BINARY
vs.
Calculating totals via COLLECT

If you need the COLLECT semantics, Do use COLLECT. READ BINARY runs in O(log2(n)) time, and the
internal table’s index must be adjusted with each INSERT. COLLECT, however, uses a hash algorithm and is
therefore independent of the number of entries (ie O(1)) and does not need to maintain a table index. If you need the
final data sorted, sort it after all data has been collected

If the amount of data is small, the READ/INSERT approach is not bad, but for large amounts of data (>1000),
COLLECT is much faster.

Caution: When you fill an internal table, do not use COLLECT in combination with any other table-filling
statements (APPEND, INSERT, and/or MODIFY) If you mix COLLECT with the other statements, COLLECT
 Novartis Consumer Health
Page: 40 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
cannot use its hash algorithm. In this case COLLECT resorts to a normal linear search, which is dramatically
slower: O(n).
5.4.5 Internal Tables: APPEND vs. COLLECT

When adding data to SAP tables (as opposed to totaling numbers), use the APPEND statement
instead of the COLLECT statement. This improves speed and avoids comparisons to existing data.

When reading a single record in an internal table, the READ TABLE WITH KEY statement is not a direct
READ. It is better to use READ TABLE WITH KEY BINARY SEARCH, but the table must be SORTed first.

Use the CLEAR command after the APPEND command to clear the contents of the internal table's header
record.
5.4.6 Internal Tables: Key Fields on Read
(Access via implicit default key)
READ TABLE TAB BINARY SEARCH
vs.
(Access via key specified explicitly)
READ TABLE TAB WITH KEY = 'X' BINARY SEARCH

If possible, specify the key fields for read access explicitly. Otherwise, the key fields have to be computed
dynamically by the run-time system
5.4.7 Internal Tables: Secondary Indexes
(No secondary index: linear search)
READ TABLE TAB WITH KEY DATE = SY-DATUM.
IF SY-SUBRC = 0.
" ...
ENDIF.
vs.
(Creating a secondary index to avoid linear search)
READ TABLE TAB_INDEX WITH KEY DATE = SY-DATUM BINARY SEARCH.
IF SY-SUBRC = 0.
READ TABLE TAB INDEX TAB_INDEX-INDX.
ENDIF.

If you need to access an internal table with different keys repeatedly, keep your own secondary indices.
Dynamically with a secondary index, you can replace a linear search with a binary search plus an index access.
5.4.8 Internal Tables: Sorting
SORT INT-TAB with default sort key
vs.
SORT INT-TAB with explicit sort key

The more restrictively you specify the sort-key, the faster the program will run. Therefore, specify the sort key
as restrictively as possible.
5.4.9 Internal Tables: Deleting Records
LOOP AT TAB_DEST WHERE K = KVAL.
DELETE TAB_DEST.
ENDLOOP.
vs.
DELETE TAB_DEST WHERE K = KVAL.
 Novartis Consumer Health
Page: 41 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards

Version 1.00
Effective Date:
With the new delete variant
DELETE ITAB [FROM ...] [TO ...] WHERE ...
the task of deleting a set of lines can be transferred to the kernel.
If possible, WHERE should be used together with FROM...and/or TO ... to enhance performance even more.
5.4.10 Internal Tables: Sequential Reads

If you are reading through an internal table sequentially using the LOOP at itab ... ENDLOOP method, but are
only interested in certain entries, use a WHERE clause and specify a condition for selection. Note that the
performance of a LOOP AT ... WHERE statement is improved greatly if all fields being compared in the WHERE
clause are of the same data type. Therefore, you should try defining the ‘compare’ fields as follows:
DATA: compare_field LIKE itab-field1.
BEGIN OF itab OCCURS 100,
field1(5), field2(5),
END OF itab.
compare_field = <value to compare>.
LOOP AT itab WHERE field1 = compare_field.
....
ENDLOOP.
5.4.11 Internal Tables: Direct Reads
(Binary search)
READ TABLE itab WITH KEY key BINARY SEARCH.
vs.
(Linear search)
READ TABLE itab WITH KEY key

If you are not processing the entire internal table, use Binary Search.

The second method performs a sequential read from the first record until if finds a match. The first method
performs a binary search to find a matching record, but the table must be sorted first.

If internal tables are assumed to have many (>20) entries, a linear search through all entries is very timeconsuming.

Try to keep the table ordered and use binary search.
5.4.12 Internal Tables: Adding entries while sorting

To add new entries to a table and keep them in sorted order, use the following method, rather than using the
APPEND statement followed by the SORT statement. For a new record the READ statement should fail (SYSUBRC <> 0), but by using the WITH KEY ... BINARY SEARCH extension, you will be positioned at the
location where you want to insert the new record.
READ TABLE INT_TABLE WITH KEY INT_TABLE
BINARY SEARCH.
IF SY-SUBRC <> 0.
INSERT INT_TABLE INDEX_SY-TABIX.
ENDIF.
 Novartis Consumer Health
Page: 42 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
5.4.13 Internal Tables: Counting Entries
DESCRIBE TABLE itab LINES cntlns.
vs.
LOOP AT itab.
cntlns = cntlns + 1.
ENDLOOP.

To find out how many entries are in an internal table use the DESCRIBE verb.
5.4.14 Internal Tables: Loop/Shere vs. Loop/Check
Key access with loop/check)
LOOP AT TAB.
CHECK TAB-K = KVAL.
"....
ENDLOOP.
vs.
(Key access with LOOP....WHERE)
LOOP AT TAB WHERE K = KVAL.
"....
ENDLOOP.

LOOP... WHERE is faster than LOOP/CHECK because LOOP... WHERE evaluates the specified condition
internally. As with any logical expressions, the performance is better if the operands of a comparison share a
common type. The performance can be further enhanced if LOOP... WHERE is combined with FROM I1 and/or
TO I2, if possible
5.5 Logic Paths
5.5.1 Logic: PERFORM decisions

For good modularization, the decision of whether or not to PERFORM a subroutine should be made before the
subroutine is called.
IF f1 NE 0.
PERFORM sub1.
ENDIF.
FORM sub1.
...
ENDFORM.
is better than
PERFORM sub1.
FORM sub1.
IF f1 NE 0.
...
ENDIF.
ENDFORM.
 Novartis Consumer Health
Page: 43 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
5.5.2 Logic: Nested ifs
When coding IF tests, nest the testing conditions so that the outer conditions are those which are most frequently
true. For logical expressions with AND, place the mostly likely false first and for the OR, place the mostly likely
true first.
5.5.3 Logic: Case vs. If
CASE Statements are generally clearer for legibility and a little faster than IF-constructions. When testing fields
"equal to" something, one can use either the nested IF or the CASE statement. The CASE is better for two reasons.
It is easier to read and after about five nested IFs the performance of the CASE is more efficient.
5.5.4 Logic: Optimizing IF AND CASE Structures

To optimize IF and CASE structures, always test values in order of the likelihood of each value occurring.

For example, fieldx can have values ‘A’, ‘B’, or ‘C’. A value of ‘B’ is the most likely value to occur,
followed by ‘C’, then ‘A’. To optimize a CASE statement for fieldx, code the CASE statement as follows:
CASE fieldx.
WHEN ‘B’.
....
WHEN ‘C’.
....
WHEN ‘A’.
....
ENDCASE.
“Most likely value
“Next most likely value
“Least likely value
Here, if fieldx has a value of ‘B’, only one test is performed, if it has a value of ‘C’, two tests must be
performed, and so on.
Coding in this manner reduces the average number of tests performed by the program.
5.5.5 Logic: Move-Corresponding

When records a and b have the exact same structure, it is more efficient to MOVE a TO b than to MOVECORRESPONDING a TO b.
MOVE BSEG TO *BSEG.
is better than:
MOVE-CORRESPONDING BSEG TO *BSEG.
5.5.6 Logic: While vs. Do Loops
If you can use WHILE instead of a DO+EXIT construction, then do so. WHILE is easier to understand and faster to
execute.
5.5.7 Logic: Testing for Initial Value

The use of the IF statement for checking whether a field is empty (i.e. equal to the initial value for its data type)
can be made more efficient by comparing the field with another of the same data type.
For example:
IF MARA-IDNRA = SPACE.
....
ENDIF.
 Novartis Consumer Health
Page: 44 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
is more efficient than:
IF MARA-IDNRA IS INITIAL.
....
ENDIF.
But only for the first time the field is tested. This is because for the ‘IS INITIAL’ test, SAP must determine
what data type the field being tested is and then determine what value it is checking for (e.g. space(s) for
character fields, zero for numeric fields, etc.). After a field has been tested once, SAP remembers its data type
and subsequent ‘IS INITIAL’ tests are equivalent in efficiency to testing against a field (or constant) of the
same data type.
5.5.8 Logic: Performing Calculations

When performing calculations in ABAP, the amount of CPU time used depends on the data type.

In very simple terms, Integers (type I) is the fastest, Floating Point (type F) requires more time, and Packed
(type P) is the most expensive.

Normally, Packed number arithmetic is used to evaluate arithmetic expressions. If, however, the expression
contains a floating point function, or there is at least one type F operand, or the result field is type F, floating point
arithmetic is used instead for the entire expression. On the other hand, if only type I fields or date and time fields
occur, the calculation involves integer operations.

Since floating point arithmetic is fast on SAP hardware platforms, you should use it when you need a greater
value range and you are able to tolerate rounding errors. Rounding errors may occur when converting the external
(decimal) format to the corresponding internal format (base 2 or 16) or vice-versa.

A note about Packed number arithmetic:
All Packed fields are treated as whole numbers. Calculations involving decimal places require additional
programming to include multiplication or division by 10, 100, 1000, etc.. The DECIMALS specification with
the DATA declaration is effective only for output with the WRITE statement. If, however, fixed point
arithmetic (program attributes) is active, the DECIMALS specification is also taken into account. In this case,
intermediate results are calculated with maximum accuracy (31 decimal places). This applies particularly to
division. For this reason, you should always set the program attribute "Fixed point arithmetic".
5.5.9 Logic: Field Length

To find out the length of a field use the string length function.
V_FLDLEN = STRLEN( FLD ).
is more efficient than
IF FLD CP ‘*#’.
...
ENDIF.
V_FLDLEN = SY-FDPOS.
 Novartis Consumer Health
Page: 45 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
6. TRACKING SAP MODIFICATIONS & ENHANCEMENTS
Modifications and enhancements (user-exits, fields-exits, screen-exits, menu-exits, DDIC changes, repairs, etc.) to
SAP delivered objects should be kept to a minimum. If it is determined that modifications and enhancements are
required, the following steps should be followed:

Approval for any modifications or enhancements must be obtained from the Application Development Team
Leader and Project Management.
7. WORKFLOW
7.1 Customizing of the Workflow.
The Workflow Administrator executes the general customizing for the workflow client. Thus no special
authorization needs be assigned for the customizing to other users. Areas of special interests are the active plan
version, the workflow administrator, WF-BATCH user, and the Prefix number for standard objects, which must be
clearly specified and maintained.
 The RFC – destination is in all clients WF-BATCH
The user WF-BATCH is maintained and control by the security team. The user ‘WF-BATCH’ must have
‘SAP_ALL’ and ‘SAP_NEW’ authorizations. This user is protected with a password by the security team.
 The active plan version is never to be changed. The active plan version must be ‘01’ in the system.
In any development client, the Prefix Number for the standard objects is entered with the customizing. The Prefix
number range for SAP client starts with 9xx. In accordance with this document‘ the xx should reflect the system ID.
The exception is Basel (901xxxxx), due to WF development in the old system.
 The customizing for the workflow system is client dependent and therefore to be checked after client copy. USE
the ‘Automatic customizing’.
7.2 Development
All development of workflow and workflow related development takes place in the development clients (e.g.
D01/011).
7.3 Roles and Responsibility
Workflow Administrator
The Workflow Administrator is responsible for the administration of sites in client
 Workflow customizing
 Development
 Error handling
7.4 Organization structure
The requester of the workflow is responsible for the maintenance of the organization structure.
 Novartis Consumer Health
Page: 46 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
7.5 Workflow, Task Group, Task, and Role
Before a new workflow or task is defined, the SAP library must be searched for any templates in the system. There
are several templates predefined. The template base should be used as this can greatly reduce development time.
 It is forbidden to change standard SAP workflow, task groups, tasks, and roles. These elements are client
independent in the system.
7.5.1 Task
Task should always be assigned to a specific user group. A general assignment of task should only be done if it is
such a task that should be handled by all SAP users.
 Use the general task assignment appropriate for tasks.
7.5.2 Task Group
The tasks (TS) and workflow templates (WS) that belong to a specific workflow are collected in a Task Group. Thus
it is possible to keep an overview of the tasks, which are assigned to a specific workflow.
 Collect the tasks and workflows that belong together in a task group.
7.6 Monitoring
Any changes on monitoring schedules have to be addressed to PEPSISNet.
7.6.1 Deadline monitoring
Deadline monitoring will be always set to ‘individual’. The schedule for ‘permanent’ deadline monitoring
must be requested.
 Novartis Consumer Health
Page: 47 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
8. EDI MODIFICATIONS
When modifying SAP supplied EDI function modules, the following steps should be followed:
Copy SAP standard function module
An exact copy of SAP’s standard EDI function modules will be made for those transactions that Novartis will
be using. These copies will keep the same name as the original, but will be prefixed with ‘Z_DCa’ ( DC =
Country Code, a = application ID). The name of the function module will serve as the ‘link’ back to the SAP
original version.
Modifications and commenting
Modifications are made directly in the code of the customer function module. The modification should be
commented in such a way as to allow easy readability and tracking of updates. Modifications should only
include adding lines of code and commenting out of SAP code, if necessary. SAP standard code should never
be deleted or changed. The modifications should be commented and marked with a search string as described
in Section 4 above.
OSS notes should be applied simultaneously to SAP standard and custom function modules
This will ensure that both function modules are kept in sync. It also ensures that the only differences in the two
function modules are the commented modifications made as a result of as GAP. This will make it easier in the
future to identify SAP bugs independently from the modifications made at Novartis.
The advantages and disadvantages to this method are outlined in the following table:
Advantages
Ease of code maintenance and modification
Minimal upgrade impact. Customer function modules
will remain unchanged. - no chance of overwrite.
Performance can be fine-tuned more easily by removing
unnecessary generic lookups (depends on customerspecific needs).
 Novartis Consumer Health
Disadvantages
SAP lack of support for customer function modules
Migration of upgraded enhancements in SAP standard
function modules to customer function modules.
Page: 48 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
9. APPENDIX A. - RETURN CODES
ABAP Statement
ASSIGN (field) TO <field symbol>.
ASSIGN TABLE FIELD (f)
TO <field symbol>.
AUTHORITY-CHECK .... .
SY-SUBRC
value
0
4
0
4
0
4
8
12
16
24
28
32
36
CALL DIALOG .... .
CALL FUNCTION .... .
CALL TRANSACTION .... .
COMMUNICATION .... .
COMPONENT-CHECK NUMBER n.
COMPONENT-CHECK
PROGRAM prog.
0
>0
0
>0
0
>0
0
>0
0
4
0
4
8
COMPONENT-CHECK
TRANSACTION tcod.
0
4
8
DELETE dbtab .
0
4
DELETE FROM dbtab
WHERE .... .
0
4
 Novartis Consumer Health
Reason / Comment
Assignment was successful.
field could not be assigned to <field symbol>.
Assignment was successful.
field could not be assigned to <field symbol>.
User has the required authorization.
User does not have authorization for the specified
action/activity.
Too many parameters (fields, values) passed. Maximum
allowed is 10.
Specified authorization object is not maintained in the
user master record.
No profile entered in the user master record.
Fewer field names specified in the AUTHORITYCHECK call than defined in
the user master record for the authorization
object concerned.
Incorrect structure for user master record.
System error.
Incorrect structure for user master record.
System error.
Incorrect structure for user master record.
System error.
Dialog module completed successfully.
Exception raised in Dialog module.
Function module completed successfully.
Exception raised in Function module.
Transaction completed successfully.
A dialog step ended in error.
Function completed successfully.
Function failed.
SAP Price List component is active
SAP Price List component is not active
SAP Price List component is active
SAP Price List component is not active
Program prog does not belong to any SAP price list
component (i.e. no entry in Table DIR).
SAP Price List component is active
SAP Price List component is not active
Transaction tcod does not belong to any SAP price list
component (i.e. no entry in Table DIR).
Record was deleted.
No record was found to match the primary key
specified for dbtab.
At least one record has been deleted.
No records were deleted (none found that satisfy
WHERE condition)
Page: 49 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
ABAP Statement
DELETE dbtab
FROM TABLE itab .... .
.
SY-SUBRC
value
0
4
DELETE itab.
0
DELETE itab INDEX idx.
0
4
DELETE DATASET dsn.
DESCRIBE LIST LINE lin
PAGE pag.
DESCRIBE LIST NUMBER OF
PAGES n.
DESCRIBE LIST PAGE pag.
EDITOR-CALL FOR itab.
GENERATE REPORT report.
GENERATE DYNPRO .... .
GET CURSOR FIELD field.
IMPORT ... FROM DATABASE ....
ID key .
IMPORT DIRECTORY INTO itab
FROM DATABASE .... ID key.
IMPORT .... FROM MEMORY
ID key.
INSERT dbtab.
INSERT INTO dbtab VALUES wa.
INSERT dbtab FROM TABLE itab.
0
4
0
4
8
0
>0
0
4
8
0
4
0
4
8
12
0
8
0
4
0
4
0
4
0
4
0
4
0
4
0
INSERT itab.
0
INSERT itab INDEX idx.
0
 Novartis Consumer Health
Version 1.00
Effective Date:
Reason / Comment
For all records in the internal table, there was a match
against a record in dbtab.
For one or more records in the internal table, no match
was found in dbtab.
This format must be used within a LOOP ... ENDLOOP
structure. The result must be a 0 return code value or a
runtime error.
Record was deleted
The record number idx does not exist in internal table
itab
Dataset dsn deleted
Dataset dsn does not exist or could not be deleted
List line found
Line does not exist
List does not exist
List found
List does not exist
List page found
Page does not exist
List does not exist
Editor left and changes saved
Editor left and changes not saved
Program generated ok
Program contains syntax errors
Other generation errors occurred
Screen(s) did not generate
Screen generated ok
Screen not generated
Cursor positioned on valid field/field name returned.
No field found at cursor position.
Data imported successfully from database.
No data found / ID key does not exist on database.
Data imported successfully from database.
No data found / ID key does not exist on database.
Data imported successfully.
ID key not found.
Record successfully inserted.
Record with duplicate key exists.
Record successfully inserted from work area.
Record with duplicate key exists.
All records from the internal table have been
successfully inserted. If one or more records cannot be
inserted (due to one or more duplicate records existing)
a runtime error occurs.
Header line successfully inserted into the internal table
itab before the current line.
Header line successfully inserted into the internal table
itab before line idx.
Page: 50 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
ABAP Statement
LOOP AT itab.
ENDLOOP.
LOOP AT itab WHERE .... .
ENDLOOP.
SY-SUBRC
value
4
0
4
0
4
MODIFY dbtab.
0
MODIFY dbtab
FROM TABLE itab.
0
MODIFY itab.
0
MODIFY itab INDEX idx.
0
4
MODIFY LINE .... .
OPEN DATASET .... .
OVERLAY f1 WITH f2 .
READ DATASET dsn INTO rec.
READ LINE .... .
(all variations)
READ REPORT prog INTO itab.
REPLACE f WITH g INTO h.
 Novartis Consumer Health
0
>0
0
4
0
4
0
4
8
0
>0
0
>0
0
>0
Version 1.00
Effective Date:
Reason / Comment
Header line not inserted into the internal table itab
because the table contains fewer than idx - 1 entries.
After ENDLOOP statement, this indicates that at least
one record was read from table itab.
Note: Testing SY-SUBRC immediately after the LOOP
AT itab statement will always return a value of 0
(record read) into SY-SUBRC.
Internal table itab is empty.
After ENDLOOP statement, this indicates that at least
one record was read from table itab which satisfied the
condition specified in the WHERE clause.
Note: Testing SY-SUBRC immediately after the LOOP
AT itab statement will always return a value of 0
(record read) into SY-SUBRC.
No entry in the internal table itab satisfied the condition
specified in the WHERE clause.
Record was successfully inserted or updated in database
table dbtab.
If this statement fails for any reason, a runtime error
(abend) will occur.
All records from the internal table itab were
successfully inserted or updated in database table dbtab
or the internal table itab was empty.
If this statement fails for any reason, a runtime error
(abend) will occur.
Insert/Update was successful.
If this statement fails for any reason, a runtime error
(abend) will occur.
Record number idx in the internal table itab was
successfully updated.
Record number idx does not exist in the internal table
itab.
Line to be modified exists.
Line to be modified does not exist.
File successfully opened
File could not be opened
At least one character in f1 was overlaid by one
character from f2.
No characters in f1 were overlaid by characters from f2.
One record from dataset dsn successfully read
End of dataset reached
Cannot open dataset / dataset does not exist
Line exists (and was read)
Line does not exist
Report successfully read into internal table itab.
Report not successfully read into itab.
String replaced successfully
String not replaced
Page: 51 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
ABAP Statement
READ TABLE itab
WITH KEY key.
READ TABLE itab
WITH KEY key BINARY SEARCH.
READ TABLE itab INDEX idx.
READ TABLE itab
COMPARING f1 f2 .... .
SY-SUBRC
value
0
SEARCH f FOR g.
(all variations)
SELECT * FROM dbtab .... .
ENDSELECT.
(all extensions)
SELECT * FROM dbtab INTO /
APPENDING TABLE itab.
(all extensions)
4
8
No record matching key was found.
The key of the desired record in the internal table itab
is greater than the previous entry
in the table.
Record number idx from internal table itab
successfully read.
No record number idx exists in the internal table itab.
Entry from internal table itab was successfully read and
the fields f1 and f2 have identical contents.
Entry from internal table itab was successfully read but
the fields f1 and f2 have different contents.
Entry from internal table itab does not exist.
List output scrolled successfully.
List limit reached - cannot scroll.
When using the optional parameter INDEX - List does
not exist - cannot scroll.
String g found in field f.
String g not found in field f.
At least one record successfully read - statements
between SELECT ... and ENDSELECT executed at
least once.
No record(s) read / statements not executed.
A least one record was read from the database table
dbtab and was placed in the internal table itab.
0
4
0
>2
0
4
8
0
4
0
4
0
0
4
SELECT COUNT(*) FROM dbtab ....
(all extensions)
SET COUNTRY f.
SET COUNTRY SPACE.
SHIFT f UP TO s.
UPDATE dbtab SET .... .
0
4
0
4
0
0
4
0
4
UPDATE dbtab.
 Novartis Consumer Health
Entry from internal table itab was successfully read.
No record matching key was found.
Entry from internal table itab was successfully read.
4
SELECT SINGLE * FROM dbtab
WHERE .... .
Reason / Comment
4
0
2
SCROLL .... .
(all variations)
Version 1.00
Effective Date:
0
No records were read from the database table dbtab.
Internal table itab will be empty.
One matching entry was found on database table dbtab
for the specified key field values.
No matching entry was found on database table dbtab
for the specified key field values.
At least one record was read from the database table
dbtab.
No records were read from database table dbtab.
Successful
Country f not found in table T005X.
No other values possible
String s found in field f.
String not found
At least one record in database table dbtab was
updated.
No records updated (table may be empty or, if a
WHERE clause was used, no matching entries were
found)
Record was successfully updated
Page: 52 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
ABAP Statement
UPDATE dbtab
FROM TABLE itab.
SY-SUBRC
value
4
0
4
WRITE f TO itab+off(len)
INDEX idx.
0
4
 Novartis Consumer Health
Version 1.00
Effective Date:
Reason / Comment
No record exists for the specified primary key.
All records in the internal table itab were used to update
records in database table dbtab.
For at least one record of internal table itab,
the database table dbtab contained no record with the
same primary key.
Contents of field f successfully written to the idxth row
of internal table itab.
Row idx of internal table idx does not exist. If the value
of idx is <= 0, a runtime error occurs.
Page: 53 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
10.
Version 1.00
Effective Date:
APPENDIX B. - SKELETON PROGRAMS
The ABAP “skeleton” programs listed in this section show how various ABAP programs should be structured. As
far as possible and appropriate, their structure should be followed.
ZSKELREP-- Basic ABAP List Report
ZSKELINT -- Interactive ABAP List Report
ZSKELOUT -- Create a Sequential Dataset
ZSKELBDC -- Read a Sequential Dataset and Create a Batch Input Session
ZSKELCLT -- CALL TRANSACTION USING Technique
Basic ABAP List Report
REPORT ZSKELREP.
*******************************************************************************
* Program Name: XXXXXXXXXXX
* Author:
XXXXXXXXXXXXXXXXXXXX
* Create Date: MM/DD/CCYY
* Description:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX *
*
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX *
*******************************************************************************
*
MODIFICATIONS
*
*******************************************************************************
* INIT WHO
DATE
TEXT
*
* XXX XXXXXXXXXXXXXXXXXXX MM/DD/CCYY
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX *
*
******************************************************************************
TABLES: ...
DATA: ...
SELECT-OPTIONS: ...
PARAMETERS: ...
FIELD-GROUPS: HEADER, ...
FIELD-SYMBOLS: ...
* Event which occurs before the selection screen is
* shown to the user. It happens only once and is
* ignored in background processing.
INITIALIZATION.
 Novartis Consumer Health
Page: 54 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
* Event which occurs each time the user hits enter on * the selection screen. This event is ignored in
* background processing.
AT SELECTION-SCREEN.
TOP-OF-PAGE.
END-OF-PAGE.
START-OF-SELECTION.
* Definition of fields for FIELD-GROUP extract
INSERT: ...
INTO HEADER.
GET ...
END-OF-SELECTION.
SORT ...
LOOP ...
AT FIRST
...
ENDAT.
AT NEW
...
ENDAT.
AT END OF
...
ENDAT.
AT LAST.
...
ENDAT.
ENDLOOP.
Subroutines
*----------------------------------------------------* Z_INSERT_ENTRIES
*----------------------------------------------------FORM Z_INSERT_ENTRIES
...
ENDFORM.
 Novartis Consumer Health
Page: 55 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
Interactive ABAP List Report
REPORT ZSKELINT.
******************************************************************************
* Program Name: XXXXXXXXXXX
* Author:
XXXXXXXXXXXXXXXXXXXX
* Create Date: MM/DD/CCYY
* Description:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX *
*
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX *
*******************************************************************************
*
MODIFICATIONS
*
*******************************************************************************
* INIT WHO
DATE
TEXT
* XXX XXXXXXXXXXXXXXXXXXX MM/DD/CCYY
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
*
******************************************************************************
TABLES: ...
DATA: ...
SELECT-OPTIONS: ...
PARAMETERS: ...
FIELD-SYMBOLS: ...
FIELD-GROUPS: ...
* Event which occurs before the selection screen is
* shown to the user. It happens only once and is
* ignored in background processing.
INITIALIZATION.
* Event which occurs each time the user hits enter on
* the selection screen. This event is ignored in
* background processing.
AT SELECTION-SCREEN.
TOP-OF-PAGE.
* Top of page for sublists
TOP-OF-PAGE DURING LINE-SELECTION.
 Novartis Consumer Health
Page: 56 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
END-OF-PAGE.
START-OF-SELECTION.
GET ...
END-OF-SELECTION.
* Produce main list report SY-LSIND = 0.
SORT ...
LOOP...
WRITE:/ ...
* Hide specific fields which are of importance to the * line.
HIDE: ...
ENDLOOP.
* Event which occurs when user hits a particular PF
* key, e.g. PF6. The hide area and SY-LISEL are
* automatically available. It produces a sublist SY* LSIND = 1-9. PF3 is automatic and will always
* take the user back one list level, (SY-LSIND - 1).
AT PF...
* Event which occurs when a user types =LIST in the OK
* code. The hide area and SY-LISEL are automatically
* available. It produces a sublist SY-LSIND = 1-9.
* PF3 is automatic and will always take the user back
* one list level, (SY-LSIND - 1).
AT USER-COMMAND.
CASE SY-UCOMM.
WHEN 'LIST'. .....
ENDCASE.
* Event which occurs when the user places the cursor
* to a specific line on the report and hits enter.
* The hide area and SY-LISEL are automatically
* available. It produces a sublist SY-LSIND = 1-9.
* PF3 is automatic and will always take the user back
* one list level, (SY-LSIND - 1).
AT LINE-SELECTION.
Subroutines
*----------------------------------------------------* Z_INSERT_ENTRIES
*----------------------------------------------------FORM Z_INSERT_ENTRIES
...
ENDFORM.
 Novartis Consumer Health
Page: 57 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
Create a Sequential Dataset
REPORT ZSKELOUT.
******************************************************************************
* Program Name: XXXXXXXXXXX
* Author:
XXXXXXXXXXXXXXXXXXXX
* Create Date: MM/DD/CCYY
* Description:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
*
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX *
*******************************************************************************
*
MODIFICATIONS
*
*******************************************************************************
* INIT WHO
DATE
TEXT
* XXX XXXXXXXXXXXXXXXXXXX MM/DD/CCYY
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
*
******************************************************************************
TABLES: ...
DATA:
G_PDSNME LIKE FILENAME-FILEEXTERN. "Physical Dataset Name.
DATA: BEGIN OF T_TAB OCCURS ...
END OF T_TAB.
PARAMETERS: P_LDSNME LIKE FILENAME-FILEINTERN "Logical Dataset Name
DEFAULT 'CUSTOMER_FILE'.
FIELD-SYMBOLS: ...
AT SELECTION-SCREEN.
CALL FUNCTION 'FILE_GET_NAME'
EXPORTING
LOGICAL_FILENAME = P_LDSNME
IMPORTING
FILE_NAME = G_PDSNAME
EXCEPTIONS
FILE_NOT_FOUND = 01.
IF SY-SUBRC <> 0.
*-------No physical filename can be determined for &
MESSAGE E016(MG)WITH P_LDSNME.
ENDIF.
START-OF-SELECTION.
OPEN DATASET G_PDSNME FOR OUTPUT IN TEXT MODE.
 Novartis Consumer Health
Page: 58 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
IF SY-SUBRC <> 0.
….
TRANSFER T_REC TO G_PDSNME.
CLOSE DATASET G_PDSNAME.
GET ...
MOVE ... TO ...
WRITE ... TO ...
UNPACK ... TO ...
TRANSFER ... TO ...
END-OF-SELECTION.
Subroutines
*----------------------------------------------------* Z_INSERT_ENTRIES
*----------------------------------------------------FORM Z_INSERT_ENTRIES
...
ENDFORM.
Read Sequential Dataset and Create a BDC Session
REPORT ZSKELBDC.
******************************************************************************
* Program Name: XXXXXXXXXXX
* Author:
XXXXXXXXXXXXXXXXXXXX
* Create Date: MM/DD/CCYY
* Description:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
*
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX *
*******************************************************************************
*
MODIFICATIONS
*
*******************************************************************************
* INIT WHO
DATE
TEXT
* XXX XXXXXXXXXXXXXXXXXXX MM/DD/CCYY
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
*
*
******************************************************************************
TABLES: ...
PARAMETERS: P_LDSNME LIKE FILENAME-FILEINTERN "Logical Dataset Name
DEFAULT 'CUSTOMER_FILE'.
DATA:
G_PDSNME LIKE FILENAME-FILEEXTERN. "Physical Dataset Name.
 Novartis Consumer Health
Page: 59 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
DATA: BEGIN OF T_TAB OCCURS ...
END OF T_TAB.
DATA:
DATA:
BEGIN OF T_BDCDATA OCCURS 10.
INCLUDE STRUCTURE BDCDATA.
END OF T_BDCDATA.
DATA: BEGIN OF T_TAB OCCURS ...
END OF T_TAB.
SELECT-OPTIONS: ...
PARAMETERS: ...
FIELD-SYMBOLS: ...
AT SELECTION-SCREEN.
CALL FUNCTION 'FILE_GET_NAME'
EXPORTING
LOGICAL_FILENAME = P_LDSNME
IMPORTING
FILE_NAME = G_PDSNAME
EXCEPTIONS
FILE_NOT_FOUND = 01.
IF SY-SUBRC <> 0.
*-------No physical filename can be determined for &
MESSAGE E016(MG)WITH P_LDSNME.
ENDIF.
*----------------------------------------------------START-OF-SELECTION.
OPEN DATASET G_PDSNME FOR INPUT IN TEXT MODE.
READ DATASET G_PDSNME INTO T_TAB.
IF SY-SUBRC <> 0.
……….
ENDIF.
CLOSE DATASET G_PDSNME.
*-- Upload a file from a PC into an Internal table --*
CALL FUNCTION 'UPLOAD' TABLES DATA_TAB = T_TAB.
*--------------- Open the BDC Session ---------------*
CALL FUNCTION 'BDC_OPEN_GROUP'
EXPORTING CLIENT = SY-MANDT
 Novartis Consumer Health
Page: 60 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
GROUP = 'SESSION_NAME' "session name
USER = SY-UNAME
KEEP = 'X'.
"keep session
"after processing
LOOP AT T_TAB.
*------------------- DYNPRO nnn ---------------------*
PERFORM BDCDYNPRO USING 'X' 'SAPMxxxx' 'nnn' '' ".
PERFORM BDCDYNPRO USING '' '' '' 'TABL-FIELD'
'LITERAL'
*------------------- DYNPRO nnn ---------------------*
PERFORM BDCDYNPRO USING 'X' 'SAPMxxxx' 'nnn' '' ''.
PERFORM BDCDYNPRO USING '' '' '' 'TABL-FIELD' TABVAR.
*----------------------------------------------------*
PERFORM INSERT_BDC.
ENDLOOP.
END-OF-SELECTION.
*--------------- Close the BDC Session -------------*
CALL FUNCTION 'BDC_CLOSE_GROUP'.
*----------------------------------------------------*
* Subroutines
*----------------------------------------------------*
*--------- Add a line to the DYNPRO Table ----------*
FORM BDCDYNPRO USING BEG PRG DYN FLD VAL.
CLEAR T_BDCDATA.
T_BDCDATA-DYNBEGIN = BEG.
T_BDCDATA-PROGRAM = PRG.
T_BDCDATA-DYNPRO = DYN.
T_BDCDATA-FNAM = FLD.
T_BDCDATA-FVAL = VAL.
APPEND T_BDCDATA.
ENDFORM.
*----------------------------------------------------*
* Add a transaction to the BDC session with the
*
* entries in BDCDATA.
*
*----------------------------------------------------*
FORM INSERT_BDC.
CALL FUNCTION 'BDC_INSERT'
EXPORTING
TCODE = 'TCOD'
TABLES
DYNPROTAB = T_BDCDATA.
REFRESH T_BDCDATA.
ENDFORM.
*----------------------------------------------------*
 Novartis Consumer Health
Page: 61 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
CALL TRANSACTION USING Technique
REPORT ZSKELCLT.
******************************************************************************
* Program Name: XXXXXXXXXXX
* Author:
XXXXXXXXXXXXXXXXXXXX
* Create Date: MM/DD/CCYY
* Description:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
*
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX *
*******************************************************************************
*
MODIFICATIONS
*
*******************************************************************************
* INIT WHO
DATE
TEXT
* XXX XXXXXXXXXXXXXXXXXXX MM/DD/CCYY
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
*
*
******************************************************************************
TABLES: INDX,
...
DATA: V_RETURN_CODE LIKE SY-SUBRC,
V_MESSAGE_TEXT(120).
DATA: BEGIN OF T_TRANTAB OCCURS 10.
INCLUDE STRUCTURE BDCDATA.
DATA: END OF T_TRANTAB.
SELECT-OPTIONS: ...
PARAMETERS: ...
FIELD-SYMBOLS: ...
START-OF-SELECTION.
*--------------------- DYNPRO nnn -------------------*
PERFORM TRANS_FIELD USING '' '' '' 'TABL-FIELD'
'LITERAL'.
*--------------------- DYNPRO nnn -------------------*
PERFORM TRANS_FIELD USING 'X' 'SAPMxxxx' 'nnn' '' ''.
PERFORM TRANS_FIELD USING '' '' '' 'TABL-FIELD' TAB-VAR.
*----------------------------------------------------*
CALL TRANSACTION '
' USING T_TRANTAB MODE 'N' UPDATE 'S'.
* Message handling
V_RETURN_CODE = SY-SUBRC.
 Novartis Consumer Health
Page: 62 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
* The following function module is a custom routine
* and can be obtained from SAP America.
CALL FUNCTION 'ZZ_FORMAT_MESSAGE'
EXPORTING MESSAGE_ID = SY-MSGID
MESSAGE_NUMBER = SY-MSGNO
VAR1
= SY-MSGV1
VAR2
= SY-MSGV2
VAR3
= SY-MSGV3
VAR4
= SY-MSGV4
IMPORTING MESSAGE_TEXT = V_MESSAGE_TEXT
EXCEPTIONS NOT_FOUND = 4.
IF SY-SUBRC = 4.
V_MESSAGE_TEXT = 'No message text found in T100'.
ENDIF.
IF V_RETURN_CODE = 0.
* At this point, various things can be done to make
* the process slicker. Send the confirmation or error
* to the other program via RFC. Store key values and
* confirmation document number or error message in an
* ATAB table for future processing.
MOVE 'Transaction posted' TO ...
MOVE V_MESSAGE_TEXT TO ...
MODIFY ...
ELSE.
MOVE 'Transaction failed' TO ...
MOVE V_MESSAGE_TEXT TO ...
MODIFY ...
* In the event of erred transactions:
* Store the internal table in the INDX database for
* future online processing of the SAP transaction.
EXPORT T_TRANTAB TO INDX(..) ID ...
ENDIF.
* or create a batch input session for future
* processing.
REFRESH T_TRANTAB.
END-OF-SELECTION.
* Subroutines
*----------------------------------------------------* Add an entry to the TRANTAB
*----------------------------------------------------FORM TRANS_FIELD USING BEG PRG DYN FLD VAL.
CLEAR T_TRANTAB.
T_TRANTAB-DYNBEGIN = BEG.
T_TRANTAB-PROGRAM = PRG.
T_TRANTAB-DYNPRO = DYN.
 Novartis Consumer Health
Page: 63 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc
SOP title: NCH
Development Guidance
Naming Conventions and
Programming Standards
Version 1.00
Effective Date:
T_TRANTAB-FNAM = FLD.
T_TRANTAB-FVAL = VAL.
APPEND T_TRANTAB.
ENDFORM.
*----------------------------------------------------*
FORM ...
...
ENDFORM.
*------------------------------------------------------
 Novartis Consumer Health
Page: 64 of 64
File:MN_G_003_MOD0_TCD0_1.00 (NCH Development Guidance Naming Conventions and Programming
Standards.doc