Abap Development Standards And Guidelines-secured-3 584l1n

or TYPE where field name =

‘SAKNR’, ‘BUKRS’, ‘MATNR’, etc.

Use the LIKE option to refer to an SAP field where possible.

Page 12 of 51

Development System Manual & Operating Procedure

3.7.2 Select Options Format:

S_ + field name FOR

or TYPE where field name =

‘SAKNR’, ‘BUKRS’, ‘MATNR’

Use the LIKE option to refer to an SAP field where possible.

3.7.4 Local Data Items to form or function Format:

L_ + field name LIKE or TYPE where field name = ‘SAKNR’, ‘BUKRS’, ‘MATNR’ Use the LIKE option to refer to an SAP field where possible

3.7.5 Constants Format:

C_ + field name LIKE or TYPE where field name =

‘SAKNR’, ‘BUKRS’, ‘MATNR’

Use the LIKE option to refer to an SAP field where possible

3.7.6 Field-Symbols Format:

3.7.7 Types Used to declare custom data definitions in an ABAP program Format:

TY_+ descriptive name

3.7.8 Internal Tables To differentiate between the 3 types of internal table, use the following formats Standard

IST_ + descriptive name

Page 13 of 51


Sorted/Index ISO_ + descriptive name Hashed

IHA_ + descriptive name

Each table must be declared with an associated work area for processing table entries. The work area must have the same name as the internal table but have the prefix WA_. Internal table work area

WA_ + associated internal table descriptive name

Alternatively you may declare a structure and use that as a work area. ™ If you are unsure as to the type of internal table to use – please use TYPE STANDARD TABLE … however DO NOT USE pre-4.0 internal table logic i.e. tables with header lines as this is out dated and inefficient programming!

3.7.9 Internal Data Structures Format:

ST_ + descriptive name

3.7.10 Ranges Format:

R_ + descriptive name

3.7.11 Field Groups Format:

FG_ + descriptive name

3.8 Data Dictionary Declarations Dictionary items to be created via SE11 transaction

3.8.1 External Tables Declarations Use nomenclature ZXX_DESC XX

= SAP module name

DESC = Short description The maximum suggested length for a field in the Data Dictionary is 15 characters. The following section describes the requirements for the different tables and fields. Transparent, Pool, INTTAB, and Cluster Tables: The SAP data dictionary contains four types of data tables. The following naming conventions will define the requirements for each of the different types.

Page 14 of 51


3.8.2 Transparent Tables: Table type TRANS are reproduced 1:1 in the database that is each field is known to the database. These types of tables are typically master data and transaction tables. The name can be up to 16 characters (Z+15) in length.

3.8.3 Pool Table: These are logical tables that must be assigned to a table pool when they are defined. Pooled tables can be used to store control data (such as screen sequences or program parameters). Several pooled tables can be combined in a table pool. The data of these pooled tables are then stored in a common table in the database. Pooled tables can also contain master and transaction data. The grouping of tables containing a limited number of records in a table pool. Several pooled tables are described logically in a pool definition in the data dictionary. The name can be up to 16characters (Z+15) in length.

3.8.4 Cluster Tables: These are logical tables that must be assigned to a table cluster when they are defined. Cluster tables can be used to store control data (such as screen sequences or program parameters). They can also be used to store temporary data or texts, such as documentation. Cluster tables are also used to store large amounts of related data, like IMG Chapters, change documents, processed items payments, conditions (procedure data) etc. Several cluster tables can be combined to form a table cluster. The data of the cluster tables is then stored in a single common table cluster in the database. Cluster tables contain no key field for the table name. Tables are typically System related tables (relational table). The name can be up to 16 characters (Z+15) in length.

3.8.5 INTTAB Tables (Structures): In the ABAP Dictionary the construction of the data produced when calculations are carried out within programs or when data is transferred between programs can also be defined globally. This is achieved by defining a structure. A structure is defined in the ABAP Dictionary like a table and can then be addressed from ABAP programs. Any change to the definition of the structure in the ABAP Dictionary is automatically implemented in all programs. While data in tables is stored permanently in the database, structures contain data only during the runtime of a program.

Page 15 of 51


Structures are defined in (almost) the same way as tables. The only difference is that no database table is generated. The same data elements and domains can be used in structures as are used in tables and it is even possible to Include tables. As a result, it is possible to achieve a high level of consistency of data definitions even in complex programs which link data taken from several places. Structures are used in particular for defining data at the interface between module pools and screens and for standardising parameters for function modules. Since structures that are used more than once are defined centrally, they can also be changed centrally. These changes are then effected at all relevant points by the active ABAP Dictionary. Table types INTTAB have no records in the database. These types of tables are structures shared across multiple ABAP programs. The maximum length of INTTAB tables is 30 characters.

3.8.6 Dictionary (SE11 object) Naming Standards For new Transparent, Pool, and Cluster tables defined (non-standard SAP tables), the following format is preferred:

DB Tables & Structures Use nomenclature ZXX_DESC XX

= SAP module name

DESC = Short description Example

ZSD_PRICING, ZMM_PURCHASINGKEYS etc.

General Information New control tables/DB tables must adhere to the above naming convention standards. Control tables can be created by all of the development and process teams but should be contained in the specification package. Some SAP objects violate the naming conventions. You can view these object names in table TDKZ. These object names cannot be used for Customer Objects. Note that all database tables should begin with client number defined in the MANDT element. ™ The Project Manager, on the recommendations of the SAP Development Lead, must approve any changes to the standard SAP tables.

Page 16 of 51


3.8.7 Data elements & Domains Where possible you should use the standard SAP data elements and domains. If you require a new data element then it should be given a name, which is as meaningful as possible. Try to limit the name to 11 characters maximum to ease maintenance; it is possible to use 30. Format:

Z + (Max 29 chars)

3.8.8 Views When defining a view use the following format:

Z+descriptive name(max 12 chars) _V

e.g. ZEKETEKPO_V to name a database view that s tables EKET & EKPO.

3.9

Table Types

These are used to define the set up of an internal table within an interface – for example from function modules or for ing data between routines. Format:

ZT_+descriptive name

3.10 Append Structures These are useful if you want to add new fields to a database table – for example a SAP standard table, without having to actually request an OSS change ID ! Format:

Z _ descriptive name e.g. ZMM_POEXTRAS

If there is more than 1 append with a similar/same name then you may wish to add a 2 digit _version number after the descriptive name.

3.11 Search Helps The maximum size of a Search Helps object name is 30 Characters. Format: ZXXXXXXX Example: ZADD, Z123

Page 17 of 51


3.12 Message Classes Application area or team message classes should be maintained. Format Z x (+19 characters) Z

SAP Standard for Client Modifications

x

Unique Meaningful Identifier

An alternative to using a custom message class is to use message 010 from message class AD with text elements. e.g.

message E010(AD) with text-e01.

3.13 Package The purpose of a package is to define the development and production SAP R/3 systems for a set of programs. All development work for a particular stream will be assigned to the same package. Only objects that are non-specific should be assigned to the interface, basis or security classes. ZXXn where Z=

fixed first character

XX =

SAP R/3 Component as defined earlier

N=

sequential next number 01,02,03 etc

The following classes have been created in development client 230: Package

Description

ZSD01

Sales and Distribution Development

ZMM01

Materials Management Development

ZPM01

Plant Maintenance Development

ZPP01

Production Planning Development

ZQM01

Quality Management Development

ZHCM01

Human Capital Management development

ZFI01

Financials Development

ZCO01

Controlling Development

Notes: ƒ

For any temporary test objects which are not supposed to be transported over to the production environment, please use ‘Local Private Object - $TMP’.

ƒ

The following development classes are to be used. If any below is not applicable, then create one using the above convention.

Page 18 of 51


4 ABAP Design Standards This section describes guidelines for the best practice approach to design and implementation of ABAP Code.

4.1

Code Reuse / Subroutines

Taking into the reuse of code during the design stage can save a considerable amount of work effort. This section describes the different options available for the reuse of code. When deg and coding programs these options should be fully utilised.

4.2

Subroutines

Subroutines should be used to ease the creation, readability and maintainability of ABAP programs. (Note: A report can call a subroutine from another report – e.g. PERFORM new_routine (zmyprog)). It is recommended that a subroutine library be developed for use in later development.

4.3

Function modules

As noted earlier SAP provides a standard function library, which should be utilised. The functions provided exception handling. New function modules can also be added to the library. A list of function modules can be found by selecting Development > Function modules from the ABAP Program Development: Initial screen. While considering creating a new function module always consults your Team Leader, there may well be a function group you should put your new module into. DO NOT insert your new function module into a standard SAP function group or an existing bespoke function group that you know nothing about. If you create a syntax error in a function group this will render the entire function group inactive, and could have serious consequences. All programs should include a case statement on the return code of a function module (SY-SUBRC) to handle errors encountered.

4.4

Include Programs

An INCLUDE program is a program that does not run on its own, it contains sections of program code used by different reports such as data declarations shared by several reports. INCLUDE programs serve to modularise program source code and thus help to enhance the readability and maintainability of the code. Where possible the use of INCLUDES should be considered within the design especially when there is a high degree of technical complexity and provision for re-use of code. For example a report may have a main executable program and 2 includes:

Page 19 of 51


Main executable program

e.g.

ZEMM_R001_01_E01

TOP include for data definitions

e.g.

ZEMM_R001_01_T01_01

Include for form routines

e.g.

ZEMM_R001_01_F01_01

For example:

ZEMM_R001_01_E01

ZEMM_R001_01_T01_01

4.5

ZEMM_R001_01_F01_01

ABAP Program Layout

The goal of structuring an ABAP program is to facilitate post build maintenance. Invariably this will be undertaken by someone other than the original author , it is therefore imperative that a clear consistent approach be taken. This section details the guidelines that should be taken with all ABAP programs and should be used in tandem with the standard ABAP template supplied with these standards. The template is held locally in program TO BE INSERTED! Always utilise the events START-OF-SELECTION & END-OF-SELECTION even if logical databases are not being used. These events serve to highlight the MAIN part of the program, these should contain the major SELECT groups and display to any programmer the key processes of the program. The Pretty printer formatting command can be used to automatically format code for neatness and readability. The following structure should be followed as a guide to event and section sequencing:

Header Declarations PROGRAM STATEMENT COMMENT BLOCK TABLES TYPES CONSTANTS STRUCTURE DEFINITIONS INTERNAL TABLE DEFINITIONS FIELD-GROUPS and FIELD-SYMBOLS DATA PARAMETERS and SELECT-OPTIONS

Page 20 of 51


Processing Block INITIALIZATION AT SELECTION-SCREEN START-OF-SELECTION GET (if using logical databases) END-OF-SELECTION

Interactive Events AT LINE-SELECTION AT PFnn AT -COMMAND

Page Controls TOP-OF-PAGE END-OF-PAGE

Subroutines FORMS

4.6

Program Header

All ABAP programs, copies of SAP standard programs, function modules, reports and includes must use a standard program header. The format of this header should be in the format shown in the header section of the ABAP template in the appendix. The purpose of the program must be documented within the header. The program header is also used to document changes within the program and to serve as a reference point to navigate around the changes. Each additional change should be logged with a transport request number and a unique identifier. In this case of application of OSS notes it is imperative that the OSS Note Number be used to document the changes. This will aid in determining the program changes need to be re-implemented during a version upgrade.

4.7

Program Documentation - On-line Program Documentation for End s

Program documentation applies only to on-line reports/programs. The aim is to provide a comprehensive description of the function of the ABAP program and details on execution.

Page 21 of 51


Documentation is developed using the SE38 ‘Documentation’ option and will generally be based on the details from the functional specification(M30) document. A program should not be signed off as complete until the documentation is completed. A description of the program should be maintained on-line using the Goto -> Program Doc. pull down menu in the ABAP/4 editor. (The difference between this form of documentation verses comments in the program is that the target audience for this is the end- whilst the latter is for the developer/maintainer). This On-line End documentation must be done. common end language but add enough technical details to allow s to use the program. Use the following template for end documentation: ƒ

Purpose: Describe the purpose of the program in detail.

ƒ

parameters: Describe the parameters the program expect and process.

ƒ

Timing: Describe how often or when the program should be run.

4.8

Commenting

Always provide extensive commenting to future maintenance of your ABAP code. Commenting should explain complicated areas of logic and should give guidance to the logical ‘flow’ within a program. When deciding ‘how much is enough’ imagine what degree of commenting you would like to quickly understand a program that you have not written. Where the program code can be clearly and concisely explained in line comments they should be used above separate line comments, as they will not be as easily separated from the code to which they relate. Line comments should be spaced out from the right hand side of the statement to a consistent point where they do not interweave with the programming code. Where this is not possible the comment should be on a separate line preceding the statement using a ‘comment block’ for lengthy comments (more than 3 lines). ********************************************************** * 001+ * Modification to check the currency values etc etc ********************************************************** Code Change………… ********************************************************** * end of 001+ FORM statements should always include a comment block to describe the function ed and the parameters ed to and from the routine.

Page 22 of 51


4.8.1 Comments for a change to a program This is one of the most important places for comments. Care should be taken to ensure that your comments highlight the changes that you have made against the original program. For example: ************************************************************************************** * CHANGE HISTORY * Mod Date

Changed By

* 29/03/2000 DONOVAR

Description

Chng ID

Addition of select options

001

* Change control **************************************************************************************

70

*-----------------------------------------------------------------* SELECT-OPTIONS and PARAMETERS *-----------------------------------------------------------------select-options: s_kunnr for knvp-kunnr

"001+ Sold-to Party

obligatory,

"001+

s_vkorg for knvp-vkorg

"001+ Sales Org

obligatory,

"001+

s_vtweg for knvp-vtweg

"001+ Distribution Chan

obligatory,

"001+

When: ƒ

Adding a new line of code, use the Change ID with a '+' symbol - e.g. '001+';

ƒ

Removing a line of code, comment out the line of code & use the Change ID with a '-' symbol - e.g. '001-';

ƒ

Amending a line of code, remove the line and add the new code below following the guidelines for adding and removing code (see above)

ƒ

Adding or removing a large amount of code, it may be necessary to insert a header area with a comment of what has changed.

to always ensure that comments are included along with the Change ID and symbol. The Change ID is a number starting at 001 and incrementing by one for each change. Lines should rarely be physically deleted from the program (this is un-auditable and you might want it back). Note however in order to maintain the readability of code it may be necessary to remove extraneous commented out code. Only seek to remove the redundant code when development unit test is complete.

Page 23 of 51


4.9

Program Attributes

The following is a checklist of the fields which must be set FIELD

COMMENTS

Type

I - Include modules F - Function modules M - Module pool/screen painted transactions 1 – Executable S – Subroutine Pool

Status

K - Customer Production Report T - Test Report

Application

V - SD, F- FI, M-MM, C – PPC

Class

All Reports must be assigned to a report class defined in table RCL.

Authorisation

All Reports must have an authorisation group specified.

Logical Database

Since this controls the access path to the data. You must ensure that you are using the correct logical database for optimal performance

Selection Screen

If you do not specify a screen number here, the system automatically creates a selection screen derived from the data base selection criteria and the report-specific parameters and selection options.

Locked for Editor

DO NOT FILL THIS FIELD IN.

Fixed Point Arithmetic

Complete this if you are doing fixed-point arithmetic. Should be set in almost circumstances.

Start via variant

If you set this attribute, the can only start your report via a variant. You must therefore have created at least one variant.

Page 24 of 51


4.10 ABAP/4 Security Programming In order to develop a feasible security strategy it is necessary to consider the implications of the three approaches to implementing security within ABAP/4. The approaches taken are dependant upon the requirement; certainly a security strategy involving preclusion of certain data from a report such as sensitive HR data would almost certainly necessitate embedding authorisation objects within the code. Alternatively prevention of access to data can be gained through prevention of access to the reporting function itself. This can be achieved through converting the ABAP program to a transaction code and utilising the authorisation facilities to determine access rights. Transaction Codes Transaction codes can be assign authorisation objects directly and as such are the most convenient method of securing software. In order to further secure the program ensure that the is denied access to SE38 and SA38. Transaction codes should be used to prevent access to the program entirely. Authority Check Embedding authority checks within programs enables direct control of data access, in this way it is possible for a whole department to utilise a report but have data excluded for certain individuals. Note this method can be used to prevent access to the program code entirely, such as in an exit program. In addition it’s important that the authority group is defined and that the field to be checked is also determined. AUTHORITY-CHECK OBJECT 'object_id ' ID ’ ’ FIELD ‘ ’ Authorisation Group Attribute

The third type of authority check is to utilise the authority group on the program attributes. This group setting can be tied in with an authority group and prevent access to the ABAP program from SE38/SA38. 4.10.1 Authorization Profile Naming Z:sxxxxxxxtt where Z

=

fixed first character of the program

s

=

SAP R/3 components

xxxxxx =

tt

=

any meaningful 6 characters that defines the profile

numbers for different profiles with the same objects but with different field values

NB: You need not use all 12 characters, ytt are the last 3 characters of your profile name

Page 25 of 51


4.10.2 Authorization Object and Field Naming ZXXxxxxxxxx where Z

=


XX

=

SAP R/3 components

xxxxxxxx

=

any meaningful 8 characters that defines the object / field

4.10.3 Authorization Name Naming Z:sxxxxxxxxy where Z

=


s

=

SAP R/3 components

xxxxxxxx

=

any meaningful 8 characters that defines the object / field

y

=

A (all), D (display only), C (create only), E (Change only), T

(delete only), L (list display), B (block)

4.11 Control Reports Control Reports must be generated for all batch programs. Each control figure should be derived and NOT computed e.g. for computing total number of records processed, total number of good records and total number of bad records, maintain 3 counters rather than maintaining only 2 and deriving the 3rd from the other 2. Control figures can also be for amount fields i.e. not only for record count. Wherever possible, for interface files, include a control total record in the output file itself. This is to enable the interfacing system to read the control total record and perform its own reconciliation. An example of when this might not be feasible is when there are constraints imposed by the interfacing system. Examples of Control Reports: Total Selected = A PR

= A1

WR

= A2

SR

= A3

Others

= A4

Total No. of Records Created = B PR

= B1

WR

= B2

Page 26 of 51


SR

= B3

Errors

= B4 where A = A1 + A2 + A3 + A4 B = B1 + B2 + B3 + B4 A1 + A2 + A3 = B1 + B2 + B3 + B4

ƒ

Total Records Read

=A

Total Error Records

=B

Total Good Records

=C

where A = B + C ƒ

ƒ

ƒ

Total No. of Records Processed for 1Q 1995 No. processed for January

= A1

No. processed for February

= A2

No. processed for March

= A3

Total No. of Error Records

=A

=B

Error records for January

= B1

Error records for February

= B2

Error records for March

= B3

Total No. of Records Selected

=C

Selected for January = C1 Selected for February = C2 Selected for March

= C3 where A = A1 + A2 + A3 B = B1 + B2 + B3 C = C1 + C2 + C3 A=B+C

ƒ

Total No. of Records Processed for dd.mm.yyyy = A

ƒ

Total No. of Records Processed = A BEDOK = A1 HAWK = A2 : :

= An where A = A1 + A2 + .... An

Page 27 of 51


No. of Records

Amount

Active Payroll

a

$x

NSMen Payroll

b

$y

Total

a+b

$(x+y)

4.11.1 BDC Names Format Z_XX_I_meaningful name where, XX

Application identifier

4.11.2 Batch Job Name Format Z_meaningful name_sequence

Page 28 of 51


5 ABAP Programming Techniques This section contains guidelines on programming techniques, it is by no means exhaustive and should be used in conjunction with the SAP help – for example see transaction SE30 and programming tips section.

5.1

SQL

In order to enhance the performance of your ABAP code a number of useful guidelines can be used. •

Use SELECT SINGLE wherever possible to retrieve up to one row of information. It is important to specify all the key fields to ensure a unique record.

•

Be careful using the FOR ALL ENTRIES addition since this is very bad for very large datasets (10,000+ records)

•

s and subqueries are good

•

Do not use SELECT * statement unless the program needs ALL columns from the table. Instead, only specify the fields you require. This will also avoid unnecessary network transports. The addition INTO CORRESPONDING FIELDS of the INTO clause of the SELECT statement is worthwhile to use only for large amounts of data where the external table and destination fields have the same names. Consider the use of the DISTINCT option in the case of many duplicate entries.

The following example compares selecting all fields to selecting only the document number, the item number and the material. Avoid:. select * from vbap where vbeln in s_docno. …. endselect. Use:

select vbeln posnr matnr into (wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr) from vbap where vbeln in s_docno. …. endselect.

Important Points:

Page 29 of 51


The order of the fields retrieved must match the order of the destination fields in the field list. •

Use the SELECT...WHERE clause to restrict data rather than retrieve all rows and use a CHECK or IF statements to filter data. Avoid:

select vbeln posnr matnr into (wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr) from vbap. check s_docno. …. endselect.

Use:

select vbeln posnr matnr into (wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr) from vbap where vbeln in s_docno. …. endselect.

Important Points: Order the columns in the where clause of a select in the same order as the key or index table. •

•

WHERE Clause Tips o

Exploit the indexes of the database tables for an efficient use of the WHERE clause. To do so check all index fields with the equality operator (EQ, =) and concatenate these checks by AND. The primary key of a database table makes up its primary index automatically. Secondary indexes for a database table can be created in the ABAP Dictionary.

o

If possible, include all columns of the key or an index in the where clause. Use a default or appropriate value. If the column(s) is not included, the database may not be able to fully utilise the index.

o

Avoid complex WHERE clauses. The system must split up those into single statements for the database system.

o

Do not use the logical NOT in WHERE clauses but inverted operators instead. The logical NOT is not ed by the database indexes.

Try to avoid the select … endselect programming construct. Rather select all the required records from the database directly into an internal table and loop at the table to process the entries. This is usually faster than the select … endselect code, and also allows easier debugging of the code. Avoid:

select vbeln posnr matnr into (wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr)

Page 30 of 51


from vbap where vbeln in s_docno. write:/ wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr. endselect. Use:

select vbeln posnr matnr into table ts_vbap from vbap where vbeln in s_docno. loop at ts_vbap into wa_vbap. write:/ wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr. Endloop.

•

Avoid nested select statements if possible as they generally have poor performance. It is preferable to select all the entries for each table directly into an internal table and use nested internal table loops to process all the entries.

•

Check runtime analysis tips and tricks for detailed comparisons in select performance (SM30). SELECT statements.

•

Use aggregate expressions in the SELECT clause to perform calculations instead of transporting great amounts of data and calculating thereafter. This distributes the processing load and minimises the network data transfer. Valid aggregate functions include: MAX, MIN, AVG, SUM and COUNT.

•

The storage of database tables in local buffers can lead to significant time savings. Use the buffering of database tables whenever possible. Use the addition BYING BUFFER only if it is really necessary. If DISTINCT, SINGLE FOR UPDATE, and aggregate expressions are used in the SELECT clause, buffering should be turned off.

•

Provide the appropriate selection criteria to limit the number of data base reads. Force s to provide selection criteria by evaluating the selection criteria entered on the selection screen during the AT SELECTION-SCREEN event.

•

Create indices where needed to enhance query performance. This should be used in large table lookups to increase efficiency. For example, SELECT…WHERE FieldA = ‘001’. In this case FieldA is not a key field, therefore an index should be created to improve the efficiency of the select statement. Beware that there is always an additional processing system overhead for indices. Therefore, only create indices if a major performance benefit will be realised, especially if the program concerned is executed many times throughout the day and is business critical.

5.1.1 SQL Checklist •

Keep the selected dataset small

•

Keep the transferred data small

•

Keep the number of database accesses small

•

Use database buffers

Page 31 of 51


•

Create views for table s instead of using multiple selects.

•

Select data only one time where possible (i.e., don’t have multiple selects against the same table - get the data one time and store it in an internal table).

•

Remove unused indexes from tables.

5.2

General Programming Techniques

Detailed below are a number of additional programming techniques that should be borne in mind when implementing ABAP code. •

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 the performance of the CASE is more efficient.

•

Do not use MOVE CORRESPONDING unless the data is contiguous.

•

When records a and b have the exact same structure, it is more efficient to MOVE a TO b than to MOVE-CORRESPONDING a TO b, if records a and b have the exact same structure. MOVE BSEG TO *BSEG. is better than MOVE-CORRESPONDING BSEG TO *BSEG.

•

Do not use the COLLECT statement with large internal tables as this can be very U intensive.

•

When reading a single record in an internal table, the READ TABLE WITH KEY is not a direct READ on a on a sorted table. Therefore, SORT the table and use READ TABLE WITH KEY BINARY SEARCH.

•

Use the SORT...BY when sorting internal tables. SORT ITAB BY FLD1 FLD2. is more efficient than SORT ITAB.

•

Avoid hard-coding and use of literals in ABAP code. Use reference tables to drive processing to business change flexibility and reduce ongoing maintenance costs. If hard-coding and literals are required, be sure to include these as constants.

•

The Tips & Tricks function is very useful in comparing different methods of coding without going to the trouble of coding both and then performing your own run-time analysis. System > Utilities > Runtime Analysis > Tips & Tricks.

5.3

Logical Databases

Use logical databases and ‘GET’ events wherever reads on parent/child segments need to be performed e.g. require data from both MARA then MARD table - use GET MARA then GET MARD. (Note you do not need to use an LDB if data from only the MARA or MARD table is required.)

Page 32 of 51


Where an LDB is used provide defaults or checks for the standard selectionoptions/parameters wherever possible. Avoid use of logical data bases as much as possible - use SELECT statements instead. (Logical databases are good as a reference tool to look up database hierarchies). ™ Logical database should only be used when there are no other options. ™ Use of Logical database in ABAP programs must be approved by a DEVELOPMENT TEAM LEAD ™ Due to strategic importance of LDB’s and the potential impact on system performance, careful consideration should be made before creating new LDB’s. Consequently no LDB’s should be created without approval from the Development Team Lead

5.4

Debugging

When testing ABAP, use of the debugging tool plays an essential role in checking the value of variables during the execution of the program. This tool should be used during the unit testing to ensure programs are executing as desired. You can use the debugging tool by selecting Program > Debugging from the ABAP program Development Initial screen. In addition to the static programming of breakpoints, ABAP’s on-line debugging tools also allow you to set breakpoints and interrupt conditions dynamically. This makes the whole process of debugging reports much more flexible and the consequent advantage is that you do not have to change your code. Watchpoints can now be set based on the value a field takes (like R/2). Once you have stopped the report processing, you can view the contents of all the fields (up to 8), internal tables and database tables referenced in the report. The system fields SY-TABIX and SY-DBCNT are now displayed at the bottom of the screen along with SYSUBRC. Finally, you can change the contents of fields for debugging purposes and then resume report processing, with the changed data. To set breakpoints select Breakpoints > Set from the ABAP: Editor screen. Then execute the program. Beware that in order to debug SAPscript programs, hard-coded breakpoints are often required. Be sure to remove these once testing is complete and the program transported. Use the syntax BREAK name, rather than BREAK-POINT, as this will ensure the code only stops when running under the specified name.

Page 33 of 51


6 SAPscript Techniques 6.1

Good Practice

•

Always copy the SAP standard print programs where available and, in most instances, the layout set. Never start a complex SAPscript (e.g. Invoice, Purchase Order) from the beginning, as this will require far more development time to complete.

•

When creating a new layout set by copying a SAP standard, always change the original language from D to E and then activate.

6.2 •

Standards

Naming convention for layout sets – this will follow the same as the program name, except the version number will be prefixed L. For example a purchase order layout set would be: ZMM_DESC where

•

First character of the program

MM

SAP R/3 module/component

DESC

Meaningful description i.e. PO printing, INVOICE.

When copying SAP standard print programs ensure they have a standard header block as defined earlier. Also ensure that any code that is added, removed or changed is commented in the standard fashion.

6.3 •

Z

Standard Texts

These should be of the following format: ZXX_DESC Where: Z

First character of the program

XX

Module name

DESC

Meaningful description.

Page 34 of 51


6.4 •

Tips

Text elements must be maintained individually for each layout set language. Any other changes to the layout set i.e. window size or paragraphs, will be copied from the original language to the other languages.

™ As layout sets are client-dependant they must be ‘transported’ between clients on the same box. To do this use the ‘Copy from Client’ function from within the ‘target’ client. This is language specific. ™ Always ACTIVATE the layout set each change and in each language before transporting. ™ The SAPscript debugger can be sent useful, this is turned on at the front screen on transaction SE71. ™ Standard text used within a layout set must be assigned to a transport request using the program RSTXTRAN. Once assigned the transport request can be released in the usual manner via SE10.

Page 35 of 51


7 Changing the SAP Standard •

•

•

•

• • • •

You can adjust the R/3 System to meet your needs in the following ways: o

Customizing: This means setting up specific business processes and functions for your system according to an implementation guide. The need for these changes has already been foreseen by SAP and an implementation procedure has been developed.

o

Personalization: This means making changes to certain fields' global display attributes (setting default values or fading fields out altogether), as well as creating -specific menu sequences.

o

Modifications: These are changes to SAP Repository objects made at the customer site. If SAP delivers a changed version of the object, the customer's system must be adjusted to reflect these changes. Prior to Release 4.0B these adjustments had to be made manually ugrade utilities. From Release 4.5A, this procedure has been automated with the Modification Assistant.

o

Enhancements: This means creating Repository objects for individual customers that refer to objects that already exist in the SAP Repository.

o

Customer Developments: This means creating Repository objects unique to individual customers in a specific namespace reserved for new customer objects.

If your requirements cannot be met by Customizing or personalization, you may either start a development project or try using a CSP solution (= Complementary Software Product). A development project falls into the customer development category if the SAP standard does not already contain functions similar to the one you are trying to develop. If, however, a similar SAP function exists, try to assimilate it into your development project by either enhancing or modifying it, by using a exit, or simply by making a copy the appropriate SAP program. Modifications can create problems, as new versions of SAP objects must be adjusted after an coincide with modified versions of SAP objects you have created. Prior to Release 4.0B these adjustments had to be made manually ugrade utilities. From Release 4.5A, this procedure has been automated with the Modification Assistant. Thus, you should only make modifications if: Customizing or personalizing cannot satisfy your requirements Enhancements or exits are not planned It would not make sense to copy the SAP object to the customer namespace.

Page 36 of 51


7.1

Originals and copies

•

An object is original in only one system. In the case of objects delivered by SAP, the original system is at SAP itself. These objects are only copies in customer systems. This applies to your development system and all other systems that come after it.

•

If you write your own applications, the objects that you create are original in your development system. You assign your developments to a change request, which has the type Development/Correction.

This request ensures that the objects are transported from the development system into the subsequent systems

7.2

Corrections and repairs

•

Changes to an original are called corrections. They are recorded in a change request whose tasks have the type "Development/correction".

•

If, on the other hand, you change a copy (an object outside its own original system), the change is recorded in a task with the type "Repair". Repairs to SAP objects are called modifications.

•

When you repair your own objects (for example, if something goes wrong in your production system), you can correct the original in your development system straight away. When you change copies, you must correct the original immediately!

•

However, you cannot do this with SAP objects, because they are not original in any of your systems.

•

You should only modify the SAP standard if the modifications you want to make are absolutely necessary for optimizing workflow in your company. Be aware that good background knowledge of application structure and flow are important prerequisites for deciding what kind of modifications to make and how these modifications should be designed.

7.3

Modifications and upgrades

During an upgrade or an import of R/3 Packages, new objects delivered overwrite existing objects of the SAP standard. In order to help customers keep those objects that have been modified in a previous release, SAP now offers upgrade adjustment for all objects being upgraded in the form of transactions SPAU and SPDD. These transactions allow customers to enter their modifications into the corresponding new objects being delivered at upgrade. The Modification Assistant s this process of adopting customer modifications. In general, objects altered using the Modification Assistant can now be automatically accepted into the upgraded system if the modifications undertaken in the original version do not directly overlap those made in the customer version. If collisions occur between the two versions at upgrade

Page 37 of 51


(naming collisions, or if SAP has deleted an object modified by a customer), the system offers semi-automatic adjustment . In some cases, however, you may still have to manually adjust objects using ABAP Workbench tools. •

Whenever you upgrade your system, apply a package, or import a transport request, conflicts can occur with modified objects.

•

Conflicts occur when you have changed an SAP object and SAP has also delivered a new version of it. The new object delivered by SAP becomes an active object in the Repository of your system.

•

If you want to save your changes, you must perform a modification adjustment for the objects. If you have a lot of modified SAP objects, your upgrade can be slowed down considerably.

•

To ensure consistency between your development system and subsequent systems, you should only perform modification adjustments in your development system. The objects from the adjustment can then be transported into other systems.

7.4

Modifications Procedures

•

A ed developer must changes to SAP objects. Exceptions to this registration are matchcodes, database indexes, buffer settings, customer objects, patches, and objects whose changes are based on automatic generation (for example, in Customizing). If the object is changed again at a later time, no new query is made for the registration key. Once an object is ed, the related key is stored locally and automatically copied for later changes, regardless of which ed developer is making the change. For the time being, these keys remain valid even after a release upgrade.

•

How do you benefit from SSCR (SAP Software Change Registration)?

7.5

o

Quick error resolution and high availability of modified systems All objects that have been changed are logged by SAP. Based on this information, SAP's First Level Customer Service can quickly locate and fix problems. This increases the availability of your R/3 system.

o

Dependable operation Having to your modifications helps prevent unintended modification. This in turn ensures that your R/3 software runs more reliably.

o

Simplification of upgrades Upgrades and release upgrades become considerably easier due to the smaller number of modifications.

Modifications Assistant

The aim of the Modification Assistant is to make modification adjustments easier. This is because (among other reasons) the modifications are ed in a different layer

Page 38 of 51


•

If you want to change an SAP object, you must provide the following information: o o

SSCR key Change request

•

The system informs you that the object is under the control of the Modification Assistant. Only restricted functions are available in the editor.

•

You can switch the Modification Assistant on or off for the entire system by changing the R/3 profile parameter eu/controlled_modification. SAP recommends that you always work with the Modification Assistant.

•

You can switch off the Modification Assistant for single Repository Objects. Once you have done so, the system no longer uses the fine granularity of the Modification Assistant.

•

In modification mode, you have access to a subset of the normal editor tools. You can access these using the appropriate pushbuttons. For example, in the ABAP Editor, you can: o

Insert The system generates a framework of comment lines between which you can enter your source code.

o

Replace Position the cursor on a line and choose Replace. The corresponding line is commented out, and another line appears in which you can enter coding. If you want to replace several lines, mark them as a block first. Delete Select a line or a block and choose Delete. The lines are commented out. Undo modifications This undoes all of the modifications you have made to this object. Display modification overview Choose this function to display an overview of all modifications belonging to this object.

o o o

7.6

Restoring the original

You can reset all of the modifications that you have made to the current object using the Modification Assistant by choosing this function. The record of the modifications is also deleted. that you cannot selectively undo modifications to an object. You can only undo modifications based on the "all or nothing" principle. ™ Any modifications in standard SAP object will require proper justification and needs to be documented. The rights of modification the standard SAP object is limited to PROJECT MANGER only.

Page 39 of 51


APPENDICES

Page 40 of 51


8 APPENDIX 1 - ABAP Report Code Template REPORT ZTEMPLAT. * NO STANDARD PAGE HEADING. * LINE-SIZE nnn. * LINE-COUNT pp.

"Switches off standard heading

"Line is nnn characters "Page has pp lines

***************************************************************************************** * PROGRAM: xxxxxxxx

*

*

*

*

Copyright (C) and all other rights in this program

*

are reserved by xxxxxxxxxxxxxxxxxxxxxxxxxxxx

* *

*

*

* TITLE: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

*

*

*

* AUTHOR: I.Surname

DATE: xx/xx/xxxx

*

*

*

* DESCRIPTION: PROGRAM

*

*

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx *

HEADER

*


*


*

*

***************************************************************************************** * CHANGE HISTORY

*

* * Mod Date

* Changed By

Description

Chng ID

* xx/xx/xxxx xxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxx

* xxxxxxxx *

*

*

**************************************************************************************** *-----------------------------------------------------------------------------------------------------* * EXTERNAL TABLE DECLARATIONS

*

*-----------------------------------------------------------------------------------------------------*

*-----------------------------------------------------------------------------------------------------* * TYPES

*

*-----------------------------------------------------------------------------------------------------*

Page 41 of 51


*-----------------------------------------------------------------------------------------------------* * CONSTANTS

*

*-----------------------------------------------------------------------------------------------------*

*-----------------------------------------------------------------------------------------------------* * STRUCTURE DECLARATIONS

*

*-----------------------------------------------------------------------------------------------------*

*-----------------------------------------------------------------------------------------------------* * INTERNAL TABLE DECLARATIONS

*

*-----------------------------------------------------------------------------------------------------*

*-----------------------------------------------------------------------------------------------------* * FIELD GROUPS & FIELD SYMBOLS

*

*-----------------------------------------------------------------------------------------------------*

*-----------------------------------------------------------------------------------------------------* * VARIABLE DECLARATIONS

*

*-----------------------------------------------------------------------------------------------------*

*-----------------------------------------------------------------------------------------------------* * SELECT-OPTIONS AND PARAMETERS

*

*-----------------------------------------------------------------------------------------------------*

*-----------------------------------------------------------------------------------------------------* * INITIALIZATION EVENT

- processing prior to selection screen

*

*-----------------------------------------------------------------------------------------------------* INITIALIZATION.

*-----------------------------------------------------------------------------------------------------* * AT SELECTION-SCREEN EVENTS - validate input

*

*-----------------------------------------------------------------------------------------------------* AT SELECTION-SCREEN.

* -------- S T A R T O F M A I N P R O C E S S I N G -------- *

*-----------------------------------------------------------------------------------------------------* * START-OF-SELECTION

- start of database access

Page 42 of 51

*


*-----------------------------------------------------------------------------------------------------* START-OF-SELECTION.

*-----------------------------------------------------------------------------------------------------* * END-OF-SELECTION

- end of logical database selections

*

*-----------------------------------------------------------------------------------------------------* END-OF-SELECTION.

* ----------- E N D O F M A I N P R O C E S S I N G ----------- *

*-----------------------------------------------------------------------------------------------------* * DIFFERENT PROGRAM EVENTS

*

*-----------------------------------------------------------------------------------------------------* AT -COMMAND.

"When presses function key or enters a

"command in the command field

AT LINE-SELECTION.

"Point at the selects a line

TOP-OF-PAGE DURING LINE-SELECTION. "top-of-page for 2ndary lists

AT PFNN.

"Point at which the presses the function "key with the function code PFnn.

*-----------------------------------------------------------------------------------------------------* * EVENTS RELATING TO REPORT PROCESSING

*

*-----------------------------------------------------------------------------------------------------* TOP-OF-PAGE.

"Point during list processing when a new page is

"started END-OF-PAGE.

"Point during list processing when a page is ended

*-----------------------------------------------------------------------------------------------------* * FORMS

*

*-----------------------------------------------------------------------------------------------------*

Page 43 of 51


9 APPENDIX 2 - Code Review Checklist Program Review Checklist Program ID:

Program Name:

Programmer:

Reviewer:

Date: Code Review Checklist Yes Naming Convention 1

Program Name is consistent with ABAP Naming Convention Standard.

2

Lock Object Name is consistent with ABAP Naming Convention Standard.

3

Message Name is consistent with ABAP Naming Convention Standard.

4

Logical Database Name is consistent with ABAP Naming Convention Standard.

5

Table Name is consistent with ABAP Naming Convention Standard.

6

Data Element Name is consistent with ABAP Naming Convention Standard.

7

Domain Name is consistent with ABAP Naming Convention Standard.

8

Search Help Name is consistent with ABAP Naming Convention Standard.

9

View Name is consistent with ABAP Naming Convention Standard.

10

Structure Name is consistent with ABAP Naming Convention Standard.

11

Layout Set Name is consistent with ABAP Naming Convention Standard.

12

Report Variant Name is consistent with ABAP Naming Convention Standard.

13

Subroutine Name is consistent with ABAP Naming Convention Standard.

14

GUI Status & GUI Title Name are consistent with ABAP Naming Convention Standard.

15

Function Module Name is consistent with ABAP Naming Convention Standard.

Page 44 of 51

No

N/A


16

Transaction Code Name is consistent with ABAP Naming Convention Standard.

17

BDC Session Name is consistent with ABAP Naming Convention Standard.

18

Index

Coding Style 1

PRETTY PRINTER is used for formatting the code.

2

Events appear in the program in the order that they are generally executed.

3

Blank Lines are used to separate different sections of code.

4

Subroutine or Function Modules should be created instead of replicating the same code in many places.

5

FORMS should be placed after all non-subroutine blocks and in the order in which they are executed.

6

Each logical section of the program has descriptive comments prior to the actual code.

7

Program should contain standard header for modification log and documentation.

8

Every modification should be documented with modification log (see #7 above).

9

Comments are used to indicate the business reason or purpose of subroutines, events, section of code, etc.

10

“Dead Code” should be removed from the program, i.e., the fields that are never referenced and code that can never be logically executed.

11 Code changes should be marked with the PPR# at block of code with begin and end notations or at individual line with PPR# on the right hand side, e.g., “PPR12345”. If an entire form is inserted, sufficient to just note the PPR# in the form header text area e.g., “*Form WRITE_REPORT PPR-12345*” Report Standard 1

Documentation of Short Text, Description, Requirements and Report Output is included and is in “ Friendly” terminology.

2

Report is coded with “NO STANDARD PAGEHEADING” and function module is used in “TOPOF-PAGE” event to maintain project standard header.

3

Selection Texts are used to specify literal for program parameters that will appear on the screen.

4

Text Elements are used instead of hard coding of

Page 45 of 51


literal text. (i.e., WRITE:/TEXT-001. “WRITE CUSTOMER INFORMATION; or WRITE/ ‘CUSTOMER’(001).) 5

default date format ( see SU50 ) is used instead of hard coding of date format in the program.

6

No hard coding of currency output formats in the program.

7

When output is designed to print on a laser printer, consider the output of the report so that it will fit for both A4 and Letter papers.

8

RESERVE statement is used to determine whether a group of lines can fit on a page.

Data Definition 1

Variable names are descriptive, meaningful and understandable.

2

Variables that are not changed in the program are defined with CONSTANT Statement. ( CONSTANT PI TYPE F VALUE ‘3.14159265359’.)

3

Comments are included after each field ( tables, fields of internal tables, constants, variables, etc.) to describe the meaning or purpose of the field.

4

LIKE verb is used while declaring the fields whenever feasible.

5

When declaring data, type and length are not left as default.

6

INCLUDES are created for data declarations and any data structure that will be used in more than one ABAP program.

7

Global variables are minimized by declaring local variables or by ing through parameters and arguments while creating Internal Subroutine.

Online Standard 1

The field with an “OK” format should be defined as OK_CODE.

2

Screen and program field names should generally be identical.

3

When handling a lock entry failure, invoke an error message (type E) to prevent from progressing to the next transaction.

4

AT PF-key is used instead of AT Pfnn in program.

Batch Program / Interface Standard 1

“Success” messages (type ‘S’, which will be output to “Job Log” when the batch programming is

Page 46 of 51


being processed) should be used generously to provide an audit trail of the program’s execution. 2

Program variants are used if a program needs to run with different parameters.

3

OPEN the dataset before the read/write operation, and always CLOSE the file when file processing is finished.

Message 1

Messages are included at appropriate places to indicate illegal operation, no authorization, no data found, etc.

2

Customer specified message ID should be created and maintained instead of using the default message IDs supplied by ABAP as they may change in future release.

Program Logic 1

SY-SUBRC is checked after perform data access statements such as select, read, get, etc.

2

Authorization-Check has been performed to handle the security of the program.

3

CHECK is used instead of IF / ENDIF whenever possible.

4

CHECK, EXIT, REJECT, STOP are used to suspend processing or skip unnecessary processing.

5

When coding IF, testing conditions are nested so that the most frequently true conditions are processed first.

6

CASE is used instead of IF when testing fields “equal to” something, because it is easier to read and more efficient after four nested IFs.

7

WHILE is used instead of DO + EXIT statement.

8

Perform I Of…. statement is used instead of using CASE….. WHEN / PERFORM when calling a certain routine based on a given index.

9

Zcond table is used for all potential hard-coded values.

Data Access 1

In SELECT statement, only the fields which are needed are selected in the order that they reside on the database.

2

SELECT SINGLE is used instead of SELECT ENDSELECT or SELECT up to 1 rows when the entire key is available.

3

Always specify the conditions in WHERE clause instead of checking them with check statement.

4

Extensive code is not embedded within a SELECT /

Page 47 of 51


ENDSELECT statement. 5

WHERE clause is organized with simple logic. WHERE clauses with very complex logic should be avoided.

6

For all frequently used SELECT statements, try to use an index by specifying the index fields concatenated with logical ANDs in the WHERE clause.

7

Conditional execution of performs should always be checked before calling the form.

8

Use SELECT SINGLE only with primary keys - often fields will not be taken into with SELECT SINGLE.

9

Aggregate functions should be used when calculating the MAX, MIN, SUM, AVG, COUNT of a database table.

10

VIEW or is used to replace nested SELECT statement.

11

Whenever possible, use array operations instead of single-row operations to modify your database tables.

12

Whenever possible, use column updates instead of single-row updates to update your database tables.

13

When selecting a certain number of rows use SELECT Up to n rows, or if you just want one row without a full primary key, use SELECT UP to 1 rows, instead of using EXIT in SELECT/ENDSELECT.

14

Since views do not have a primary key, ORDER BY PRIMARY KEY should only be used in database tables.

15

Since “ORDER BY fi…fn” is not automatically ed by a (sorted) index, you should sort the result set with SORT on the application server instead of with….ORDER BY fi…fn on the database server.

16

No direct updates to ABAP supplied tables.

17 When loading data into internal table, use SELECT… from INTO (APPENDING) TABLE instead of a SELECT/APPEND combination. 18 Use a VIEW or instead of “SELECT…for all entries in TABLE ”. Internal Table 1

Header line of Internal Table is cleared before moving data into it.

2

Internal Table is defined with ‘OCCURS 0’ if the maximum size of the table is potentially >= 8KB. If the data to be read is estimated to be under 8K, then

Page 48 of 51


specify the number of lines in the OCCURS statement (e.g., itabl occurs 10) is effective. 3

MOVE-CORRESPONDING is used only when two internal tables have identical fields and you want to move a few records from one to the other. Otherwise, MOVE should be used.

4

When filling an internal table, use READ…BINARY SEARCH / INSERT if the amount of data is small (<20 entries), or if the needs read access to the internal table while it is being filled. Otherwise two step approach APPEND / SORT is preferable.

5

When filling an internal table, COLLECT is used instead of READ / INSERT when number of entries greater than 1000, because COLLECT uses a hash algorithm which is independent of the number of entries and does not need to maintain a table index.

6

When filling an internal table, COLLECT is not used with the combination of APPEND, INSERT and/or MODIFY, because it cannot use its own hash algorithm in those circumstances. “READ TABLE TAB WITH KEY K = ‘XXX’ BINARY SEARCH” is used instead of linear search when internal table has more than 20 entries (table must have been sorted by the key specified in READ statement).

7

Key fields should be specified on the READ TABLE statement, not left as default (e.g., READ TABLE ITAB WITH KEY K =’XXX’ instead of READ TABLE ITAB).

8

LOOP AT ITAB WHERE K=’XXX’ should be used instead of LOOP AT ITAB / CHECK ITAB-K =’XXX’.

9

Sort fields on the SORT statement should not be left as default (e.g., SORT ITAB BY FLD1 instead of SORT ITAB).

10

All variants and fields should be explicitly specified when you use MODIFY statement to modify the internal table (e.g., you should use MODIFY itab…. TRANSPORTING fl f2…WHERE…instead of MODIFY itab) .

11

When appending itabl to itab2, use APPEND LINES OF itabl TO itab2 instead of APPEND itabl TO itab2.

12

When inserting itabl to itab2, use INSERT LINES OF itabl INTO itab2 INDEX IDX, instead of INSERT itabl INTO itab2 INDEX IDX.

13

When deleting a record from an internal table, use DELETE ITAB WHERE condition instead of using LOOP AT / CHECK / DELETE ITAB.

14

When the data is processed only once, use a SELECTENDSELECT loop instead of collecting data in an

Page 49 of 51


internal table with SELECT….INTO TABLE because the internal table handling takes up much more space. String Operation 1

When searching for a fragment in a long string, use the special operators CO, CA, CS instead of programming the operations yourself.

2

Use ABAP-defined string processing statements (e.g., concatenate, split, replace, condense, shift, etc.) instead of programming them yourself.

3

When deleting the leading spaces in a string, use SHIFT c LEFT DELETING LEADING SPACE.

4

Function STRLEN0 is used to determine the byte length of a field.

5

CLEAR WITH is used when you want to initialize a field with a value different from the field’s type-specific initial value.

ABAP Script 1

Avoid using text elements in any windows other then the main window.

2

Delete any windows that are not being used in any pages of the layout set.

3

Try using SET COUNTRY in the print program instead of individual windows of the layout set.

4

logo or signature to a standard text instead of using it directly in the layout set.

5

Use program RSTXTRAN to transport standard text from IGX to PDX.

6

For appearance purposes, use &’Fax Number ‘T024TELFX& instead of Fax Number &T024-TELFX& so that the text ‘Fax number’ will not print if no fax number exists.

7

When creating new layout sets, give ¼ inch margin around each corner of the page for faxing purposes.

8

To transport layout sets across different systems, use report RSTXSCRP.

9

Use table TNAPR to find a layout set and print program based on the output type.

10 Every .TIF file (logos, signatures, etc.) should be stored in the ABAP database (NS_APPS/PHILA/ABAP/US/CIT/ABAP Programming Team - Logos). 11 Use RSTXFY (transaction SE71) to move layout sets between clients.

Page 50 of 51


12 Use RSTXTY (transaction SO10) to move texts between clients. Comply to specs 1

Comply to Processing Logic in program specification.

2

Comply to Data Definition in program specification.

3

Comply to Screen Definition in program specification.

4

Comply to Report Format in program specification.

5

Comply to Message Definition in program specification.

6

Comply to Function & Subroutine usage in program specification.

7

Comply to Data Mapping Matrix in program specification.

Comments:

Page 51 of 51

Abap Development Standards And Guidelines-secured-3 584l1n

Overview 3e4r5l

More details w3441

Related Documents 3m3m1z

Abap Development Standards And Guidelines-secured-3 584l1n

Abap-development Badis Bi.pdf 6h5o1w

100 Abap Questions - Abap Development - Scn Wiki 3u162c

Development And Maintainance Of Standards And Accreditation 3s3z3a

Etl Development Standards 3b67q

Property Development Recognition Standards Malaysia 2x1r6y