Community
Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Read only

reg documents

Vijay
Active Contributor

‎2008 Jan 25 5:36 AM

0 Likes
602

hi all,

i have to prepare 2 documents as per my project requirement.

1. System Build SAP SOP (Standard Operating Procedure).

2. System Build Guidlines - ABAP Coding.

If anybody can please provide me sample documents to refer.

my mail id is vj_vats@yahoo.com.

regards

vijay

2 REPLIES 2
Read only

Former Member

‎2008 Jan 25 5:43 AM

0 Likes
483

Hi

Hope it will help you for ABAP coding guidelines.

Reward if help.

Table of Contents

Topic Page No.

PURPOSE 3

SCOPE 3

REFERENCES (OPTIONAL) 3

ACRONYMS 3

1.1 NAMING CONVENTIONS 3

The 8-character ABAP names will conform to the formats given below: 3

Position 1: 3

Position 2: 4

Position 3-4 6

1.1.1 Exceptions to the rule 6

1.1.2 Warning 6

1.2 ABAP4 - ATTRIBUTES 7

Title: 7

Type: 7

Status: 7

Application: 7

Authorization Group: 7

Logical Databases: 7

Fixed point arithmetic: 7

1.3 CODING FEATURES 7

1.3.1 Sequence 8

1.3.2 Indenting 10

1.3.3 Spacing 11

1.3.4 Paragraphing 11

1.3.5 Variable naming 11

1.3.6 Commenting 12

NOTE: 12

1.4 LAYOUTS 14

1.4.1 Selection Screens 14

1.4.2 Reports 14

1.5 MODIFICATIONS 14

1.5.1 Standard SAP repairs (OSS Repairs) 14

1.5.2 Approved Repairs (Changes/Repairs) 14

1.5.3 Modifications to Copies of Standard SAP ABAPs 14

IN ORDER TO PICK UP THE EXACT PURPOSE OF THE CHANGE QUICKLY, THE CORRECTION OR TASK DESCRIPTION SHOULD BE VERY CONCISE AND ACCURATE. 15

1.6 DIRECT UPDATES 16

1.6.1 Locking a database table for: Update, Modify, and Delete. 16

Single Record Lock: 16

1.6.2 Multiple Record Lock: 16

1.7 DOCUMENTATION 17

NOTE: 17

1.8 QUALITY CONTROL GUIDELINES 17

Purpose This document is a compendium of conventions and practices that can be gainfully used while coding in ABAP

Scope The team members will use this standard during the construction phase. It covers

References (Optional) Nil

Acronyms ABAP

BDC

OSS Advanced Business Application Programming

Batch Data Communication

Online SAP service

1.1 Naming Conventions

There are several reasons for defining development standards. If a common style is used, obviously reviews and maintenance will be more efficient. It also shows a professional approach to development. Another reason is that it indicates Quality awareness.

This document is a standard for the development and maintenance of ABAPs that deal with Reporting, Batch Data Capture sessions, Uploads and Downloads in the R3 environment.

The following naming conventions apply for all ABAPs.

We follow the 8 character ABAP names.

The 8-character ABAP names will conform to the formats given below:

Position 1:

All characters except ‘Y’ and ‘Z’ are reserved for SAP.

Y - Denotes a SAP ABAP, which has been copied and modified. All original SAP code must remain in place commented out if appropriate. Positions 3 - 8 of the ABAP name remain as the SAP original. These will be referred to as Y-ABAPs.

Copies of original SAP ABAPs must remain Y-ABAP’s in the following situations.

 If the changes to the standard SAP code will have to be applied again after each upgrade.

 If the ABAP is called automatically by another standard SAP ABAP or transaction.

Z – Denotes programs, either written from scratch or based on a SAP original without the original code being retained. (This may be done if the changes become significantly large. As a guide, if more than a quarter of the original code lines is changed, a new Z-ABAP is desirable).

Position 2:

For Y-ABAPs

Position 2 is only changed from the original SAP ABAPs name, in a SAP system, which contains multiple Development Groups. This position indicates the ABAPs ‘owner’. A single character or number will represent the Development Group.

For Z-ABAPs

Following represents the SAP Application (as per SAP ABAPs).

A Assets Accounting

C PPC (Production Planning and Control)

F Financial Accounting

H Human Resources Planning

I Maintenance

K Cost Accounting

L Warehouse Management

M Materials Management

N Hospital

P Human Resources

S System

V Sales

X This has been allocated to SAP enhancements – e.g. user exits etc.

In cases where some ambiguity may be present, such as in ABAPs dealing with one of the Cycles where strict Application boundaries are crossed, the application letter used should represent the primary use of the ABAP.

Position 3: (Position 3 - 8 affect Z-ABAPs only)

This position can be used in 2 different ways.

In the case of a SAP system, which contains only a single company, this position indicates the ABAPs main purpose (Read/Update).

R Read Only (Report Programs)

I Include ABAP

M Module Pool ABAP

S Generating a BDC session

E External Data transfer

T User Defined Table Update

U Other Update

P PC Upload/Download

In the case of a SAP system, which contains multiple companies and clients, this position indicates the ABAPs ‘owner’. A single character or number will represent the company.

If the ABAP is not Development Group specific, the 3rd character must contain a ‘0’ to indicate it is a Central Development Group program.

Positions 4 - 6:

Classification: This should contain characters 2 - 4 from the program classification on the attribute screen. For a list of ABAP classes, refer tables TRCL (available as part of the product for all releases of SAP above 3.0) and TRCLT (available as part of the product for all releases of SAP above 3.0).

The program class must start with a ‘Z’. If the description for the program class starts with a ‘*’, then the program class must no longer be used.

If no suitable program class exists, please speak to your system administrator.

Positions 7 - 8: Sequence Number

For ABAPs with a reasonably close similarity, the sequence number should be incremented by 1. For ABAPs with a more significant variation increments of 10 should be used.

It is recognized that it will not always be possible to conform strictly to this method. But there are advantages to be gained from grouping ABAPs in this way, within the broader classification given by positions 4 - 6.Workbench Organizer / Correction and Transport

Naming for development classes is as follows:

Position 1: ALWAYS a ‘Z’

Position 2: Represents the SAP application (as per SAP ABAPs).

A Assets Accounting

C PPC (Production Planning and Control)

F Financial Accounting

H Human Resources Planning

I Maintenance

K Cost Accounting

L Warehouse Management

M Materials Management

N Hospital

P Human Resources

S System

V Sales

X where a large development is required

Y where a large development is required

Z where a large development is required

Position 3-4

Development Group numbers or the characters to represent the sub module relevant to the development

1.1.1 Exceptions to the rule If position 2-3 is ‘SU’, this is a development class to be used for upgrades.

1.1.2 Warning No ABAP should be created under development class $TMP i.e. as Local Private Objects.

Development Classes can be found in table TDEVC (available as part of the product and referred during coding). If the development class description starts with a ‘*’, then the development class must not be used. If your required development class does not exist on your system, please speak to your system administrator.

1.2 ABAP4 - Attributes Title:

The title of the report should make it easily identifiable. It should be concise. The title must also reflect the main purpose of the ABAP.

Type:

1 On-line program

J Job report

I Include Program

M Module Pool for screen painter screens

V Update program

F Function module

S External Routine

Status:

This should contain a ‘T’ (Test program) while the program is being developed, and a ‘K’ (Customer production program) once testing of the program is complete.

Application:

Application must be entered. (For a list of applications please refer to possible entries on-line). Must match the second character of the program name.

Authorization Group:

A list of valid authorizations groups can be found in program ZSAUTH (for all SAP releases before 3.0) and in table TPGP (for all SAP releases after 3.0).

This field is mandatory in the following cases: -

 If a logical database is not being used for the primary source of data.

 If specific authorization checks on the primary source of data are not done in the ABAP.

Logical Databases:

Logical databases are optional.

It is not mandatory for the application of the logical database to match the application of the ABAP.

Fixed point arithmetic:

When fixed-point arithmetic is switched on, all calculations are performed using fixed-point arithmetic. The default is set to ‘on’ (This is especially useful when dealing with floating point numbers).

1.3 Coding Features

1.3.1 Sequence In order to make all ABAPs easy to read and understand by other programmers in a support environment, a specific coding sequence should be followed. This is a guideline only and must be followed as long as it is logical to do so.

Please use program ZSABAP for a more accurate and detailed example.

Generally the sequence is as follows:

REPORT XXXXXXXX

LINE-COUNT

PAGE-COUNT

MESSAGE-ID

NO STANDARD PAGE HEADING.

----

DATA DECLARATION -

INCLUDE xxxxxxx. “ Briefly write what is contained in the include

TABLES: xxxx, “ Briefly write what the table is.

xxxx.

DATA: xxxxxxxx,

xxxxxxxx.

FIELD-GROUPS: HEADER,

xxxxxxxx.

INSERT xxxxxxxx

xxxxxxxx INTO HEADER.

FIELD-SYMBOLS: xxxxxxxx.

RANGES: xxxxxxxx.

SELECT-OPTIONS: xxxxx,

xxxx.

PARAMETERS: xxxxxxxx,

xxxxxx.

----

INITIALIZATION -

Setup parameters and selection defaults etc.

----

START OF SELECTION -

START-OF-SELECTION.

Check input.

GET xx.

GET yy.

GET xx LATE.

SELECT * FROM xyz.

. . . . . . .

ENDSELECT.

EXTRACT HEADER.

END-OF-SELECTION.

----

END OF SELECTION -

----

SORT AND LOOP PHASE -

Sort Field-Groups and/or Tables.

LOOP.

AT NEW xxxxxx.

. . . . . .

ENDAT.

AT END OF xxxxxx.

. . . . . .

ENDAT.

ENDLOOP.

AT PFxx.

. . . . . .

AT USER-COMMAND.

. . . . . .

----

FOOTER -

----

SUBROUTINES -

FORM abc using xyz

pqr.

. . . . . .

ENDFORM.

----

TOP-OF-PAGE -

TOP-OF-PAGE.

1.3.2 Indenting All ABAPs must be neatly indented. The standard indent applied by Pretty Print is 2 positions. Statements should be indented and aligned, as it makes reading the ABAP much easier. For example:

TABLES: VBAK, “ Comment

VBAP.

WRITE: /01(05) xx-xxxx, “ Comment

10(08) xx-yyyy,

xx-zzzz DD/MM/YY.

Not

TABLES: VBAK, VBAP.

WRITE: /1(5) xx-xxxx, 10(8) xx-yyyy, xx-zzzz DD/MM/YY.

1.3.3 Spacing

Please leave blank lines between coding structures, or clearly definable coding blocks.

For example.

IF . . . . . .

MOVE . . . . .

ENDIF.

----

Check For ......... -

IF . . . . . .

PERFORM . . . . . .

ENDIF.

*EJECT

1.3.4 Paragraphing Ideally no consecutive piece of code should extend to more than 50 lines or so. Elements of the code should be split into FORMs so that they become manageable. Putting common pieces of code in FORM routines is also recommended.

1.3.5 Variable naming

When naming the variables, Internal tables, Parameters and Select options do follow the following naming:

Variables V_XXXXXXXX…..

Internal tables I_XXXX.._XXXX

Parameters P_XXXXXX

Select options SO_XXXXX or S_XXXXXX

The Internal table if similar to a Database table shall preferably contain the name of the DB table.

Always use variable names that correspond to SAP Data Dictionary naming. This carries the advantages of often being self-defining, and of being consistent and recognizable.

For example:

DATA: BUKRS,

xxxx_BUKRS,

BUKRS_xxxx.

For record or internal table definition:

DATA: BEGIN OF rrrrrr,

BUKRS LIKE xx-BUKRS,

WERKS LIKE xx-WERKS,

MATNR LIKE xx-MATNR,

END OF rrrrrr.

BEGIN OF tttttt occurs nn,

xxxxxx LIKE xx-xxxxxx,

END OF tttttt.

As a general rule, keep names as short as possible, it reduces effort and helps to avoid mistakes. Avoid using names containing a hyphen (‘-’) as the may appear like table or database fields. The use of ‘like’ when defining a field is to be used when possible. This will avoid problems at upgrade time.

If a DATA structure is to be used in many ABAPS, then create a structure in the Data Dictionary.

When creating multiple variables, group fields with similar purposes together, for example all Total fields could be coded together in one area.

1.3.6 Commenting Internal ABAP commenting is critical for ease of maintenance and for general comprehension. It is a good practice to explain all working storage defined by TABLES, SELECT-OPTIONS and PARAMETERS. Particular care should be taken to explain the purpose of records and internal tables.

Comment blocks in the standard format are expected for the following structures.

REPORT, FORM . . ENDFORM, MODULE . . ENDMODULE

The report standard comment block must include the following information.

 The notifications ‘UPDATE = Y/N’ and ‘BDC = Y/N’ using either ‘Y’ or ‘N’ as appropriate.

 A brief description of the output produced by the ABAP

 A brief description of the purpose of the ABAP.

 Details of any special peculiarities in the coding.

 The name of the author and the month/year it was written.

 See ABAP ZSABAP for an example of a header block.

If a control structure is complex or large, then a comment block should be included giving an explanation.

NOTE:

Pretty print will try to put all double inverted commas for comments in column 40. If this is impossible because of the line length, it will increment the column number in 5s.

1.4 Layouts

1.4.1 Selection Screens These must follow SAP standards. All input fields must be left aligned with descriptions entered in a combination of lower and uppercase. No lines are to be skipped between parameters and select-options unless a logical grouping of parameters can be formed. All parameters and select-options must be assigned a memory-id if one exists. Selection texts must be taken from the data dictionary wherever possible (The texts are found on the data element). ‘Possible entries’ must be available wherever possible.

Memory-id’s can be picked up off the data element screen.

1.4.2 Reports Standard page headings and footers must be used. Column headings should follow the same alignment as the field being represented, example, quantity fields must have a heading that is right aligned.

All parameters entered on the selection screen should be displayed in the headings of the report, example if a specific plant is called for, then the headings must reflect which plant was selected.

The sequence of the fields from top to bottom and left to right should indicate the sort sequence, as far as logically possible.

1.5 Modifications

1.5.1 Standard SAP repairs (OSS Repairs) Place a modification comment block at the top of the ABAP. If more than one modification has been made, the latest change should be at the top. In the body of the ABAP, any line no longer required must be commented out (with an asterisk (‘*’) in column 1), NOT deleted. A line needing to be changed must also be commented out, the new, modified line following it immediately.

The comment block must include the OSS number, the name of the person making the modification and the date. All the altered lines, including lines commented out must contain the OSS note number on the far right hand side of the line (OSS99999).

(This is required to assist in upgrades). The description of the repair MUST be "OSS Note xxxxx - Your Name - Description of Fix", e.g.: "OSS Note 42225 - Nico - Itemization Display in prod. Order". If this convention is not followed, then the fixes will be lost after an upgrade.

1.5.2 Approved Repairs (Changes/Repairs) The comment block must include the Repair number, the name of the person making the modification and the date. All the altered lines, including the lines commented out must contain the Repair number on the far right hand side of the line.

The change MUST then be documented in the repair documentation.

1.5.3 Modifications to Copies of Standard SAP ABAPs As a general principle, if a standard SAP ABAP is to be modified, create a copy (using ‘Yxxxxxxx’ for the ABAP name) and modify the copied version only.

Place a modification comment block at the top of the ABAP. If more than one modification has been made, the latest change should be at the top. The comment block must include the name of the person making the modification and the date as well as the modification id (the modification id consists of the author(s) initials and the date, in the format IIDDMMYY). The original name of the SAP ABAP must be specified to aid in identification should this be necessary.

In the body of the ABAP, any line no longer required must be commented out (with an asterisk (‘*’) in column 1), NOT deleted. A line needing to be changed must also be commented out, the new, modified line following it immediately. All the altered lines, including lines commented out must contain the modification id on the far right hand side of the line. This is required to assist in upgrades.

Version management cannot be relied upon for the following reasons: -

 Version management will only keep the changes made from the first time the new modified ABAP is copied to production. I.e. the first lines of code changed would not be recorded.

 Before release 3.0d, it is not possible to copy a single client from one R3 system to another. Therefore when a copy of a client from production to development is required, the entire system must be copied. In this process record of versions may be lost. Whenever this copy process happens the versions will be lost.

It is not necessary to comment each individual line that is changed in the program so long as a detailed description of the change is provided in the REPORT comment block and other comments and documentation for the ABAP are updated to reflect the change.

If extensive changes are being made to the program, more detailed comments in the body of the ABAP will be required.

In order to pick up the exact purpose of the change quickly, the correction or task description should be very concise and accurate.

1.6 Direct Updates

1.6.1 Locking a database table for: Update, Modify, and Delete. Most SAP standard databases and tables can be updated by the use of a transaction, and in this case, a BDC program or ‘CALL TRANSACTION’ program must be written.

Single Record Lock:

To lock a single record the following statement can be used.

Select single for update * from <table>.

A commit work statement releases the record after the update is complete. It should be noted that all database locks are released at the next database commit or rollback.

For example when a program is run in debug mode, an automatic release is initiated.

Example: Select single for update * from zvpro.

Update zvpro set: datum = last_date

Uzeit = last_time.

Commit work.

1.6.2 Multiple Record Lock: In the case of a multiple record lock, the SAP generated function modules must be used. The module generation is initiated by selecting ’database table lock’ in the data dictionary. Two function modules are generated, namely ENQUEUE_obj and DEQUEUE_obj. These function modules are then used to lock and unlock the selected records of the table

1.7 Documentation

You should document the purpose and use of the ABAP. This is the Primary source of information for the end user of the ABAP and should contain a good description of the function of the ABAP. Important points should also be noted.

Parameters and select-options that have been defined by the ABAP must be described. The user should be able to determine exactly the effect on the ABAP of all select-options and parameter entries. Be particularly careful to explain which values may be entered.

Sort Sequence, and the conditions specified if more than one sort sequence is possible, should be listed and explained.

A list of what output can be expected is also very useful. Typically this might include a list of all columns and a description of any abbreviations in the output that may be ambiguous. It is also a good place to put details of any formulae, calculations, special processing rules etc. which may assist the user.

A short note detailing the source of data should also be provided.

Note:

Please Note (Only applies to SAP rel. 3.0) that ABAP documentation must be activated before it can be copied to production. To do this, from program documentation, select Document -> Save -> Active version.

1.8 Quality Control Guidelines

All of the above standards will be checked for any ABAP submitted for copying to production.

All ABAP developments must be given to a group of the developers assigned to Quality Control before requesting a copy to production. (This includes new ABAPs being written, as well as modifications to existing ABAPs).

The original specification, log track form, change request form, and test results are verified and recorded.