abap development standards

8/12/2019 ABAP Development Standards

http://slidepdf.com/reader/full/abap-development-standards 1/42

NTERNAL

Global Delivery Services

ABAP Development

Standards

January !!"

December !!#

Ramanathan Sarvana

Version 1.0Date: 13 December 2006Status: Released



ABAP Development StandardsConfidential

Revision History

Ver sion

Date Author Derivation/Comments

1.0 13/12/2006 Ramanathan Sarvana nitial Version

Revie! History

Ver sion

Date Reviewer Remarks

"##roval History

Ver sion

Date Approver Remarks

1$0 0%/01/200& "l'red Surendran

This document is effective from the Approval date

QMS@DC ! of "!




#a$le of Contents()ecutive Summary................................................................................................................ 6ntended "udience...................................................................................................................6

S"* +amin, -onventions.............................................................................................................. &1. S"* bect +amin, -onventions.................................................................................&

1.1 +amin, -onventions 'or *ro,rams$ unctions$ ncludes and Re#orts...........................&1.2 +amin, -onventions 'or odule *ools and odule *ool ncludes...............................1.3 +amin, conventions 'or 'unction ,rou#s........................................................................

1.3.1 +amin, convention 'or 'unction modules................................................................1.4 +amin, -onventions 'or 5ransaction -odes..................................................................1.% +amin, -onventions 'or Develo#ment -lasses...................................................... ......1.6 +amin, -onventions 'or o,ical Databases................................................................10

1.& aintainin, S"* Standard bects..............................................................................101. Data Dictionary.............................................................................................................10

1..1 5ables.................................................................................................................... 101..2 Vie!s......................................................................................................................111..3 Structures...............................................................................................................111..4 Domains................................................................................................................. 111..% Data (lements.......................................................................................................121..6 ields.....................................................................................................................12

"##end Structures..........................................................................................................121. "uthori7ations...............................................................................................................12

1..1 bect -lass.......................................................................................................... 121..2 -hec8 obects 9 "uthori7ation bects .................................................................131..3 "uthori7ations........................................................................................................ 131..4 *ro'iles.............................................................................................................. .... 13

";"*/4 Standard -onventions.....................................................................................................1%2. ";"*/4 Standard -onventions.......................................................................................... 1%

2.1 *ro,ram "ttributes....................................................................................................... 1%2.2 *ro,ram nternal Structures.........................................................................................16

2.2.1 nternal 5able +amin, -onvention................................................................ ........162.2.2 System 5able "ddressin, -onvention................................................................. ..16

2.3 *ro,ram Variable +ames.............................................................................................162.3.1 la,s...................................................................................................................... 1&2.3.2 nde)es.................................................................................................................. 1&2.3.3 -onstant ields...................................................................................................... 1&2.3.4 <or8 Variables.......................................................................................................1&2.3.% *arameter 'ields.................................................................................................... 12.3.6 S((-5=*5+S 'ields......................................................................................1

2.3.& R"+>( 'ields........................................................................................................ 12.4 (rror essa,es............................................................................................................ 1

2.4.1 essa,e D?s................................................................................................... ...... 12.4.2 essa,e Severity..................................................................................................12.4.3 essa,e +umber................................................................................................. .1

2.% emory Stora,e D?s....................................................................................................12.6 *=Status..................................................................................................................... 12.& ()ternal iles............................................................................................................... 202. Variants........................................................................................................................ 20

";"*/4 *ro,rammin, Standards "nd *ractices......................................................................... .21

QMS@DC % of "!




3. ";"*/4 *ro,rammin, Standards and *ractices...............................................................213.1 *ro,ram Structure........................................................................................................213.2 ain Documentation ;loc8..........................................................................................213.3 Statement ormattin,................................................................................................. .223.4 nclude -ode................................................................................................................ 22

3.% essa,es..................................................................................................................... 223.6 Re#ort ormattin,........................................................................................................ 223.& ;atch Data n#ut.......................................................................................................... 223. Data "ccess................................................................................................................. 223. Data @#date................................................................................................................. 233.10 ()ternal ile @sa,e....................................................................................................233.11 Variants.......................................................................................................................233.12 -om#utations............................................................................................................. 233.13 Subroutines................................................................................................................ 233.14 "uthori7ation -hec8in,........................................................................................ ......243.1% oc8 obects............................................................................................................... 243.16 Debu,,in,..................................................................................................................243.1& Standards 'or S#eci'ic Statements.............................................................................24

3.1&.1 "**(+D 5";...................................................................................................... 243.1&.2 "SS>+............................................................................................................... 243.1&.3 "5 *nn............................................................................................................... 243.1&.4 -H(-A................................................................................................................ 243.1&.% -*@5(........................................................................................................... 2%3.1&.6 D"5".................................................................................................................... 2%3.1&.& (D5R=-"..................................................................................................... 2%3.1&. -H(-A$ (B5$ R(C(-5$ S5*........................................................................... 2%3.1&. /-"S(...............................................................................................................2%3.1&.10 V(=-RR(S*+D+>...............................................................................2%3.1&.11 R("D 5";(..................................................................................................... 2%3.1&.12 SR5.................................................................................................................263.1&.13 -(-5.......................................................................................................... 26

3.1 @ser nter'ace 9>@...................................................................................................26

3.1 aintenance/-orrection o' e)istin, #roduction code.................................................263.20 nter'ace 5y#es...........................................................................................................2&3.21 ()ternal Data Sets..................................................................................................... 2&3.22 nternal 5ables............................................................................................................2&3.23 (''iciency Standards.................................................................................................. 2&

";"*/4 odule *ool Standards "nd *ractices............................................................................24. ";"*/4 odule *ool Standards and *ractices................................................................. 2

4.1 *ro,ram Structure........................................................................................................24.2 Screen De'initions........................................................................................................24.3 >@ inter'aces..............................................................................................................24.4 **=@* !indo!s.........................................................................................................24.% A-D( 9SE=@-.............................................................................................2

R((R(+-(S............................................................................................................................. 2 "##endi) ".................................................................................................................................... 30

5able o' "##lication "rea -odes................................................................................................30 "##endi) ;................................................................................................................................... 34

Standard *ro,ram Structure..................................................................................................... 34 "##endi) -................................................................................................................................... 36

Su''i) -odes 'or 'ield names..................................................................................................... 36 "##endi) D................................................................................................................................... 3&

;usiness Short$ edium$ on, +ames.................................................................................... .3& "##endi) (................................................................................................................................... 3

5em#late Screen lo! o,ic Structure......................................................................................3

QMS@DC " of "!




QMS@DC & of "!




'(e)utive Summar*

The purpose of this document is to define ABAP/4 naming and programming standards and practices for <Customer> Technologies to use when developing in the SAP R3 environment.This document will define the following:

SAP !"ect #aming $onventions

ABAP/4 #aming $onventions

ABAP/4 Report Programming Standards and Practices

ABAP/4 %odule Pool Standards and Practices

This is a d&namic document' which is to evolve with the SAP environment and e(perience. Asnew e(periences lead to !etter methodologies in coding' the& will !e incorporated into thisdocument.

)t is important to follow all of the conventions identified in this document. #aming conventionsfor SAP o!"ects should !e closel& followed.

+ntended Audien)e

This paper is intended for developers and Basis personnel as well as outside consultants that arewor*ing on the SAP product to help define a strateg& for custom development and enhancements.

)t is recommended that the reader of this document has !een e(posed to some !asic conceptswithin the SAP product' has attended the SAP training course' SAP+, SAP R/3 verview' or ane-uivalent.

This document should !e distri!uted to emplo&ees or consultants who are new to the pro"ect toensure that the standards are followed. An&one doing a standards review must have thisdocument as a reference.

QMS@DC , of "!




SAP -amin. Conventions0 SAP 1$2e)t -amin. Conventions

The purpose of this section is to define the naming conventions for the following o!"ect t&pesfound in the SAP environment:

Programs' unctions' )ncludes' and Reports

%odule Pools' %odule Pool )ncludes

unction roups' %odules

Transaction $odes

0evelopment $lasses

1ogical 0ata!ases

SAP Standard o!"ects

0ata 0ictionar& elements

0 -amin. Conventions for Pro.rams3 4un)tions3 +n)ludes andReports

The purpose of this section is to define the naming conventions to !e used !& ABAP/4 programs'functions' includes' and reports created in the SAP s&stem. Refer to %aintaining SAP Standard!"ects 2Section .5 if &ou are modif&ing an SAP standard o!"ect. !"ect names will !e

formatted as follows:*osition

1 @sa,e: FG "##lication #ro,rams that !ill be moved to #roduction.

2 S"* "##lication area 9Re'. "##endi) "

3 I 4 S"* "##lication sub=area 9Re'. "##endi) "

%=30 "ny lo,ical and meanin,'ul name 'or the a##lication.

Report and update program include o!"ect names will consist of characters formatted as follows:

*osition

1 JG? ReKuired by S"*2=2& Same as #ositions %=30 in #ro,ram name

2&=30 @sa,e:

F5* Data Declarations$ 5ables$ etc.

nnL Subroutines 9orms

6here 7nn8 is a numeric integer !etween ,, and 99.

QMS@DC 5 of "!




The following is an e(ample customer program for the application area $;' su!<area P$;' andthe appropriate includes:

*ro,ram name G-*-*R>R"

Data include G*R>R"5*

orm routine include G*R>R"01

0! -amin. Conventions for Module Pools and Module Pool +n)ludes

The purpose of this section is to define the naming conventions to !e used for module pools andmodule pool includes created in the SAP s&stem. %odule Pool names will consist of thirt& 23,5characters formatted as follows:

*osition

1=4 FS"* = 5his is the S"* standard

% FG = ndicates a user de'ined module

6 "##lication "rea 9Re'. "##endi) "&= "##lication Sub="rea 9Re'. "##endi) "

=30 @ser=de'inedL should be meanin,'ul 'or the a##lication.

%odule Pool )nclude o!"ect names will consist of thirt& three 23,5 characters formatted asfollows:

*osition

1=2& Same as #ositions %=30 in odule *ool name

2=30 @sa,e:

F5* Data Declarations$ 5ables$ etc.

nnL *; modulesnnL *" modules

nnL Subroutines 9orms

6here 7nn8 is a numeric integer !etween ,, and 99.

The following is an e(ample customer module pool for the application area $;' application su!<area P$;' and the appropriate includes:

*ro,ram name S"*G-*-*R>R1

Data include G-*-*R>R15*

orm routine include G-*-*R>R101

*; include G-*-*R>R101*" include G-*-*R>R101

0% -amin. )onventions for fun)tion .roups

The purpose of this section is to define the naming conventions to !e used for function groups.unction group names of twent& si( 2=5 characters formatted as follows:

*osition

QMS@DC 6 of "!




0, -amin. Conventions for 8o.i)al Data$ases0

The purpose of this section is to define the naming conventions to !e used for logical data!asescreated for use with ABAP/4 programs. 1ogical data!ase names will consist of three 235characters formatted as follows:

*osition

1 @sa,e:

FG "##lication #ro,rams that !ill be moved to #roduction.

2 J)? !here ) is a letter "=G or number 0=. ;e,in !ith "$ use ne)t avail.

3 "##lication "rea 9Re'. "##endi) "

05 Maintainin. SAP Standard 1$2e)tsThe purpose of this section is to define the naming conventions to !e used whenever wor*ingwith SAP standard o!"ects. SAP delivered objects are not to be modified. @ser e(its should !eused whenever possi!le or address modifications via the customiing facilities provided.Reference course B$4=+' >nhancement and %odification $oncepts.

)f an SAP standard o!"ect is to !e modified' the o!"ect2s5 must !e copied and renamed. Thecopied o!"ect can then !e maintained and su!stituted in the program path.

or ABAP/4 programs' functions' includes' and reports' the first position is to !e changed to 78.or %odule Pools and %odule Pool )ncludes' change the +th position to a 78. The purpose ofthis procedure is to ensure that all SAP delivered code remains intact as well as identif&ing all

program customiations when migrating to a new release.

06 Data Di)tionar*

060 #a$les

$ustom ta!les are to !e maintained e(clusivel& !& custom on<line programs. )t is recommendedthat all ta!les !e defined as transparent ta!les.

Ta!les to !e maintained via the maintain ta!les transaction 2 S%3 5 will consist of thirt& 23,5characters formatted as follows:

*osition

1 FG.


3=4 "##lication Sub="rea 9Re'. "##endi) "

%=30 Descri#tion o' 5able

QMS@DC 9 of "!




060! Views

?iews are transparent ta!les consisting of an alternate view or com!ination of multiple ta!les'such as a "oined ta!le. The length of the view name will var& !ased on the primar& ta!le name forthat view.

?iew names will consist of si(teen 25 characters formatted as follows:

*osition

1 FG ReKuired by S"*

2= n 5able name o' the S"* #rimary table

nM1 FV or Vie!

060% Stru)tures

Structures are similar to ta!les although no records can !e stored within. Structures are used for:

nternal table common structures$ used !ith 'unction modules or common #ro,rams

Screen 'ields$ de'ine common structure 'or 'ields used !ithin a module #ool

The following naming convention is to !e used for data structures' !& position:

*osition

1 FG reKuired by S"*



%=30 Descri#tion o' Structure

060" Domains0omains define the ph&sical attri!utes of a field. 0omains can !e chec*ed against value ta!les or !e assigned a chec* ta!le depending on the usage for the domain. 0omain names should !e up tothirt& 23,5 characters long and are to !e defined !& the following naming standards !& position:

Position

1 FG. ReKuired by S"*



%=30 Descri#tion o' Domain

060& Data 'lements

0ata elements define the description for a field 2 Semantic domain 5. 0ata elements are toreference a corresponding domain that matches the ph&sical re-uirements for that element. 0ataelement names should !e up to thirt& 23,5 characters long and are defined !& the following namingstandards !& position:

QMS@DC of "!




1 FG. ReKuired by S"*



%=30 Descri#tion o' Data (lement

0ocumentation must !e maintained for the data element. This documentation appears as help te(twhen fields in an on<line program are tied to the data element.

060, 4ields

ields are to !e descriptive and should not e(ceed C characters. 1ong field names arecum!ersome from a programming perspective. )t is recommended that the field name !e namedaccording to the associated data element in the following convention.

1=n Data element name$ dro# the G 'or custom data elements.

Append Stru)tures "##end structures are to be used to add 'ields to S"* standard tables or structures. "##endstructures must be created via the table maintenance or dis#lay transaction. +amin,conventions 'or a##end structures and their 'ields are strictly en'orced by the S"* system. 5he'ollo!in, namin, convention is used:

Append structure

1 FG ReKuired by S"*

2= Descri#tive

ields in the append structure

<= 78 Re-uired !& SAP

3<D @se field naming conventions

07 Authori:ations

070 1$2e)t Class

An authoriation o!"ect class groups common chec* o!"ects together in a logical group.Authoriation class has a length of four 245 characters and should !e defined as follows:

*osition

1 JG? ReKuired by S"*2=4 3 character short business name 9 Re'. "##endi) D

070! Che)k o$2e)ts ; Authori:ation 1$2e)ts <

$hec* o!"ects are o!"ects that are called from ABAP/4 programs and transactions to chec* thelogin user;s authorit& to perform a function or chec* access to specific field values.

#aming convention:

QMS@DC ! of "!




*osition

1 JG? reKuired by S"*

2 "##lication area 9 Re'. "##endi) "

3 J? underscore

4=12 @se meanin,'ul !ords

070% Authori:ations

Authoriations control the values of a specific chec* o!"ect for which a user is to have access to.A value or range of values is assigned to each field !ased on the authoriation. The secondcharacter for an& authoriation must not !e an underscore E;' this is reserved !& SAP.

#aming convention' suggested for consistenc& with chec* o!"ects:

*osition


2 "##lication area 9Re'. "##endi) " 3 J? underscore

4.12 @se meanin,'ul !ords

Alternative naming convention 2 Release =.= 5:

*osition

1 "##lication area 9Re'. "##endi) "

2 J:? -olon


070" ProfilesProfiles lin* multiple authoriations into one common group' usuall& defined as a !usiness profile.A !usiness profile is assigned specific authoriations to perform tas*s related to the securit& levelof that !usiness profile. The second character for an& profile must not !e an underscore E;. Thisis reserved !& SAP.

#aming convention' suggested for consistenc& with chec* o!"ects:

*osition



3 J? underscore4=12 @se meanin,'ul !ords

Alternative naming convention 2 Release =.= 5:

*osition


2 J:? colon


QMS@DC % of "!




QMS@DC " of "!




ABAP/" Standard Conventions!0 ABAP/" Standard Conventions

The purpose of this section is to define attri!utes and/or naming standards for the following parameters/o!"ects associated with the ABAP/4 programming language:

*ro,ram bect "ttributes

nternal Structures

Variable +ames

(rror essa,es

emory Stora,e D?s

* Status()ternal iles

Variants

!0 Pro.ram Attri$utes

The purpose of this section is to define the allowa!le attri!utes for programs created in the SAPenvironment. The following are the allowa!le attri!utes to !e set at the creation of a program:

5y#e:

()ecutable *ro,ram

nclude *ro,ram

odule *oolunction >rou#

Subroutine *ool

nter'ace *ool

-lass *ool

Status:

-ustomer *roduction *ro,ram

"##lication:

Re'. "##endi) "

-lass:

95;D "uthori7ation >rou#:

95;D

i)ed *oint "rithmetic:

"l!ays mar8 this attribute unless !or8in, !ith !hole numbers only.

QMS@DC & of "!




!0! Pro.ram +nternal Stru)tures

The purpose of this section is to define the naming conventions for internal structures. Thefollowing are the internal structures to !e discussed:

nternal 5ableS&stem Ta!le

!0!0 +nternal #a$le -amin. Convention

)nternal ta!les are defined within programs and used to hold !loc*s of records. )nternal ta!leswill alwa&s have a varia!le prefi( of 7TE8 followed !& a description of the ta!les purpose. Thefollowing is an e(ample of an internal ta!le varia!le:

TE$@ST%>R

!0!0! S*stem #a$le Addressin. ConventionThe s&stem ta!le contains several fields used to address s&stem parameters. Reference all s&stemfields !& SF<((((((;.

!0% Pro.ram Varia$le -ames

The purpose of this section is to define the naming conventions for program varia!les !ased onvaria!le t&pes. Program varia!les are defined using the 0ATA statement. The PARA%>T>Rstatement can also !e used to define varia!les' which are presented to the user as input varia!lesat program e(ecution. Special varia!les for selection criteria can also !e defined using theS>1>$T<PT)#S statement. The following are the varia!le t&pes that are addressed:

la,snde)es

-onstants

<or8='ields

*arameters

ield=N-ustomerOs

Ran,es

@nderscores E; are to !e used to separate words or letters that define a varia!le instead ofh&phens. G&phens <; are used for referencing su!<fields in a record string or data structure.

)t is recommended that data dictionar& fields !e used whenever possi!le for consistenc& and t&pechec*ing.

!0%0 4la.s

lags are varia!les that contain onl& one of two values. These varia!les will !e defined ascharacter of length . )n all cases' the following values must !e complied with:

QMS@DC , of "!




J J P F+$ F"S($ or F

JB? P FE(S$ F5R@($ or F+

These varia!le t&pes are to !e prefi(ed with E;. The following are e(amples of varia!le namesto !e used:

>(

>-+5+@(*R-(SS+>

!0%0! +nde(es

)nde( varia!les are numeric fields used for inde(ing internal ta!les. These varia!le t&pes are to !enamed the referring ta!le name prefi(ed with )HE;. The following are e(amples of varia!lenames to !e used:

B-@S5(R

B5(*S"(S

!0%0% Constant 4ields

$onstant varia!les do not change during the e(ecution of a program. 6henever possi!le theliteral itself should !e used. These field t&pes should !e prefi(ed with $E;. The following aree(amples of varia!le names to !e used:

-;"S(-(+5 A( SE="+D5 V"@( J001?.

!0%0" =ork Varia$les

6or* varia!les are for general<purpose use. These are an& varia!le t&pes that cannot !e definedto the a!ove categories. These varia!les ma& contain alphanumeric' numeric' pac*ed' !inar&'

date' time' or he(adecimal values.?aria!le t&pes of this categor& must !e prefi(ed with 6E;. The following are e(amples ofvaria!le names to !e used:

<5(*S""RE

<(*"DDR(SS

< "S5@*D"5(

<"S5@*D"5(

D"5": ;(>+ <5(*-@S5

..NVariables / ncludesO..

(+D <5(*-@S5

!0%0& Parameter fields

Parameter varia!les are used to allow data entr& at the selection screen !efore program e(ecution.These varia!les have a limited length of eight 2D5 characters. ?aria!le t&pes of this categor& must !e prefi(ed with PE;. The following are e(amples of varia!le names to !e used:

*-@S5+

QMS@DC 5 of "!




*S-ER

!0%0, S'8'C#>1P#+1-S fields

The S>1>$T<PT)#S Iield nameJ for ITa!le fieldJ statement generates a program varia!leused for a selection criteria. This allows a user at the selection screen to enter in a range of values.The varia!le generated is actuall& a s&stem generated ta!le containing Ivaria!leJ<highvalue'Ivaria!leJ<lowvalue' Ivaria!leJ<sign' and Ivaria!leJ<option for the ta!le field selected. ?aria!let&pes of this categor& must !e prefi(ed with SE; and have a limited length of eight 2D5 characters.The following are e(amples of varia!le names to !e used:

S+R

S;@ARS

!0%05 RA-' fields

The RA#>S Iield nameJ for ITa!le fieldJ statement generates a program varia!le used for aselection criteria much li*e the S>1>$T<PT)#S. The varia!le generated is actuall& a s&stemgenerated ta!le containing Ivaria!leJ<highvalue' Ivaria!leJ<lowvalue' Ivaria!leJ<sign' andIvaria!leJ<option for the ta!le field selected. ?aria!le t&pes of this categor& must !e prefi(edwith RE; and have a limited length of eight 2D5 characters. The following are e(amples ofvaria!le names to !e used:

R+R

R;@ARS

!0" 'rror Messa.es

The purpose of this section is to define the naming conventions to !e used for standard errormessaging. Standard SAP error messages should !e used whenever possi!le to eliminateredundanc&. )f it is determined that additional error messages are to !e generated' assign themaccording to the guidelines descri!ed in this section. The following are the three parameters to !edefined in this section:

essa,e D

essa,e Severity

essa,e +umber

!0"0 Messa.e +D?s

%essage )0;s are two character names given to a group of related messages. The following arethe naming standards !& position for message )0;s:

1 FG reKuired by S"*

2 "##lication area code 9Re'. "##endi) "

QMS@DC 6 of "!




!0"0! Messa.e Severit*

%essage severit& defines the action performed upon e(ecution of the message. The following arethe allowa!le message severit& codes:

" F"bend = the transaction aborts and the user is unable to continue.( F(rror = entered data is invalid. 5he user must modi'y or reenter the data.

< F<arnin, = the #ro,ram allo!s the user to override the #articular !arnin,

and continue$ or modi'y the data$ !hich caused the !arnin,.

Fn'ormational = dis#lays in'ormation that may be o' interest to the user.

5he user must #ress enter to continue.

S FSuccess = a success messa,e is an in'ormational messa,e dis#layed on the

ne)t screen. Such as F5ransaction com#leted success'ully.

!0"0% Messa.e -um$er

%essage num!ers are the uni-ue 3<character identifiers of a message. %essage num!ers range for ,, to 999. The ne(t availa!le should !e used.

!0& Memor* Stora.e +D?s

This is up to the developer.

!0, P4>Status

P Status is a custom status !ar defined to !e used !& a screen or interactive program to ena!leuser actions. The standard SAP format must !e used. The ta!le !elow defines the usage ofstandard function *e&s. These function *e&s do not have to !e ena!led !ut when used' must

compl& with the standards defined in this section. These function *e&s are not to !e replaced !&user defined *e&s.

P Ke& K<$0> 0escription

, G>1P 0ispla& help screen for current field

,= P)$K Select entr& 2same as dou!le<clic*5.

,3 BA$K >(it current transaction. verrides mandator& entries.

,4 1)ST 1ist Possi!le >ntries.

, %>#@ %enu !ar. SA?> Save entries.

= R6 $ancel current re-uest' %andator& entries override.

3 PR) Print.

4 01T 0elete.

QMS@DC 7 of "!




+ >H)T >(it 2ast >H)T5 leave transaction. Same as P,3.

= PP<< irst page of document.

== P< Previous page.

=3 PL #e(t page.

=4 PPLL 1ast page of document.

!05 '(ternal 4iles

>(ternal files are to !e defined as logical files via the customiation menu path. This allows forconsistent naming of files without having programs !eing dependent on the actual @#)H file name

!06 Variants

?ariants are program specific o!"ects' which define set parameter entries re-uired at programe(ecution time. ?ariant names will consist of eleven 25 characters formatted as follows:

*osition

1=& 5he associated re#ort #ro,ram name 9Re'. 1.1

@nderscore F

FV 'or variant.

10=11 2 character numeric$ ran,in, 'rom 01 to $ startin, at 01.

QMS@DC !9 of "!




ABAP/" Pro.rammin. Standards And Pra)ti)es

%0 ABAP/" Pro.rammin. Standards and Pra)ti)es

The purpose of this section is to define the !asic standards that all developed programs mustcompl& with. The order of the components within a program must compl& with the s*eleton program 2F@PST0S5 Ref. Appendi( B. This section descri!es the rules surrounding the use ofABAP features and components.

%0 Pro.ram Stru)ture

The structures of programs are to follow the standard program F@PST0S 2Ref. Appendi( B5.>vents in the standard program that are not used in the new program should !e removed forclarit&. All su!routines 2orms5 must !e placed after the >#0<<S>1>$T)# statement.

$omment statements are to !e used for the following conditions:

;e'ore each maor section

;e'ore Small sections o' code

5o clari'y com#le) or unclear lo,ic.

%a"or sections of code are defined as ABAP events' forms' and large code sections that perform adefina!le tas*. Small sections of code are defined as =, or fewer lines of code that perform adefina!le tas*.

%0! Main Do)umentation Blo)k

The main documentation !loc* contains a detailed description of the program' maintenancehistor&' and ta!les referenced. A sample documentation !loc* is included in the standard program2F@PST0S5. The following contains the list of re-uired entries in the main documentation !loc*:

*ro,ram +ame and 5itle.

Date and "uthor o' #ro,ram.

*ur#ose o' the #ro,ram. ree'orm te)t should be descri#tive.

Develo#ment class o' the #ro,ram.

ist o' in#ut/out#ut #arameters.

' !ritin, nclude module or Subroutines.

ist o' S"* tables u#dated.

or each$ de'ine: n#ut$ ut#ut$ or ;oth.

ist e)ternal tables or 'iles accessed by the #ro,ram.

or each$ de'ine: n#ut$ ut#ut$ or ;oth.

ist the #ro,ram?s #ossible return codes$ i' a##licable.

Revision table must contain an entry 'or each revision includin,:

Develo#ment reKuest number.

Date o' chan,e.

QMS@DC ! of "!




*ro,rammer name.

Descri#tion o' chan,e.

%0% Statement 4ormattin.

@se Prett& Print to automaticall& indent all statements.

$haining of li*e statements is accepta!le !ut not re-uired.

%0" +n)lude Code

$reating )nclude modules is recommended for performance and legi!ilit&. @se of functionmodules for common routines is preferred over e(cessive use of )nclude modules.

%0& Messa.es

All >rror messages are to !e implemented via %>SSA> )0;s 2Ref. Section =.45. An& te(tmessages must use #@%B>R>0<T>HT' defined via include te(t. The purpose of this is to ma*ean& output message te(t language dependent.

%0, Report 4ormattin.

Blan* lines are to !e specified using SK)P InJ as opposed to multiple 6R)T> /; statements.

@se #@%B>R>0<T>HT for all screen te(t to !e displa&ed. This is defined via include te(t andis language dependent.

%05 Bat)h Data +nput

Batch data input sessions should !e limited to appro(imatel& =+, transactions per B0$ group.This num!er can var& greatl& depending on the -ualit& of the data !eing processed' and is not atechnical limitation. 1arge !atch ABAP programs are to !e avoided due to the single<threadednature of the !atch environment. These programs are to !e !ro*en up into smaller !atch programs' where appropriate.

%06 Data A))ess

Selection and efficienc& considerations need to !e addressed when defining programs. @se logicaldata!ases when practical for report programs. 0ata accesses should !e compared to theire-uivalent in ABAP P>#<SM1.

Use of DBMS (NATIVE S!" to #$date or modif% data is forbidden on an% SAP definedobject. An& statement within >H>$<SM1 and >#0<>H>$ circumvents SAP data dictionar&chec*s and will corrupt s&stem integrit&. 0B%S SM1 should also !e viewed criticall& forcustomer created ta!les within the SAP environment. All ta!les should !e defined through thedata dictionar& to ensure proper varia!le and structure t&pe chec*ing.

0B%S SM1 ma& !e used !& e(ternal programs to view data in the SAP s&stem' !ut securit&considerations e(ist.

QMS@DC !! of "!




0ata access should !e chec*ed whenever performed for invalid return codes. @se the $G>$K;or $AS>; statement as opposed to multiple if statements to screen incoming data or returncodes.

%07 Data pdate

SAP data!ase files are onl& to !e updated through SAP provided code. This can !e through theuse of e(isting SAP transactions or through the use of Batch 0ata 2B0$5 driven screen processing.

%09 '(ternal 4ile sa.e

Structures of e(ternal files are to !e defined in the data dictionar& as internal ta!les using fields'data elements' domains' and' where appropriate' chec* ta!les.

%0 Variants?ariants are to !e defined as needed to default parameters re-uired for program e(ecution. All !atch programs with defined parameters re-uire variants to process. Refer to ?ariant #amingStandards 2Section =.D5.

%0! Computations

There is no performance issue !ased on the variations presented !elow for calculations.

$@#T N $@#T L is e-uivalent to A00 to $@#T.

%0% Su$routines@se local varia!les whenever possi!le within su!routines for modulariation purposes. Gowever'fre-uentl& used su!routines within one program call should use glo!al varia!les to eliminatecreation time of those local varia!les.

)t is recommended to pass data to and from su!routines using the @S)#; statement in the perform. This does not appl& to field initialiation su!routines and glo!al su!routines.

@se of the $GA#)#; clause is up to programmer preference !ut is good for su!routinedocumentation.

Su!routines that are to !e called !& multiple programs should !e created as a function module.>(ternal su!routines should also !e implemented as unction %odules.

%0" Authori:ation Che)kin.

Authoriation o!"ects should !e chec*ed at the selection screen of report programs or at thetransaction code level. All chec* o!"ects created must !e documented thoroughl& and given to thesecurit& administrator.

QMS@DC !% of "!




%0& 8o)k o$2e)ts

1oc* o!"ects should !e created for all ta!les that can !e updated via transactions. The resultingfunction modules 2 >n-ueue/0e-ueue5 must !e used in the maintenance programs . The primar&ta!le of a transaction 2i.e. material ta!le5 should !e identified and a loc* placed when updating or

deleting. or displa& critical data 2no maintenance allowed while record is displa&ed5 shared loc*sshould !e placed upon entr& to the transaction.

%0, De$u..in.

All de!ugging code must !e removed from a program !efore migration to a controlledenvironment 2i.e. Mualit& Assurance' Production5. This includes !rea*points and an& codeassociated with testing.

%05 Standards for Spe)ifi) Statements

%050 APP'-D #AB

@se onl& SRT>0 clause when:

5here are less than 100 ro!s

Rows are alread& in sorted order

)f an internal ta!le must !e sorted and the a!ove cannot !e satisfied' fill the ta!le in unsorted order and then sort specif&ing *e& fields. To remove duplicates' if re-uired' collect the rows from thesorted ta!le into an au(iliar& ta!le.

%050! ASS+-

@se of field I$ustomerJs is discouraged unless necessit& dictates. ield I$ustomerJs' whenused' should !e documented in program comments when defined and whenever used.

%050% A# P4nn

@se the AT @S>R $%%A#0; instead of AT Pfnn;. This ensures proper response to the usercommand and is more legi!le.

%050" C'C

@se chec* statements whenever possi!le instead of nested );s.

%050& C1MP#'

The $%P@T> statement can !e used although t&ping out the e(pression using operators and parentheses is more legi!le.

QMS@DC !" of "!




%050, DA#A

0efine varia!les within the 0ATA statement in accordance with Program ?aria!le #ames 2Section=.35. Align varia!le definitions in a reada!le and consistent format.

The 1)K> parameter in the 0ATA statement is re-uired whenever possi!le. This allows forconsistent field definitions !etween program varia!les and e-uivalent SAP varia!les.

Although ABAP/4 initialies all fields at program e(ecution' it is alwa&s good form toinitialie &our varia!les using the $1>AR statement. Alwa&s clear data structures and varia!les !efore repopulating' especiall& in loops. This highl& recommended in function modules sincemultiple calls to the same function module within one program e(ecution will not refresh thefunction modules varia!les.

%0505 'D+#1R>CA88

#ever to !e used for ta!le updates since it circumvents an& data t&pe chec*ing.

%0506 C'C3 '+#3 R''C#3 S#1P

@se these statements to suspend processing and/or s*ip remaining unnecessar& processing forimproved performance.

%0507 +4/CAS'

$ode onl& one condition per line for legi!ilit&. @se parentheses to group conditions.

@se the $AS>/6G># statement structure whenever applica!le to avoid nested );s of more than3 levels.

%0509 M1V'>C1RR'SP1-D+-

This statement should !e used with care since onl& fields with identical names are moved. )fmoving a data structure to an e-uivalent structure' move the entire data structure in one statementusing I1AE0SJ N OI1AJ.

%050 R'AD #AB8'

6hen reading a ta!le with the 6)TG K>F; option' ensure that the *e& is filled from the left mostfield in the ta!le. This is most efficient with a !inar& sorted ta!le. Build and read long internalta!les with the B)#ARF S>AR$G addition.

%050! S1R#

Alwa&s specif& the sort fields on the SRT statement for legi!ilit& and maintaina!ilit&' includingwhen the s&stem default is used.

QMS@DC !& of "!




%050% C188'C#

The $11>$T statement for internal ta!les can !e ver& $P@ intensive for internal ta!lescontaining more that +, rows. The following are two alternatives to !e used for $11>$T)#internal ta!les greater than +, rows:

Alternative .

READ itab WITH KEY new-key BINARY SEARCH.

CASE SY-SUBRC.

WHEN 0. new-amt = new-amt + itab-amt.

!"E . . .

!DI#Y itab INDE$ SY-INDE$

WHEN !THERS.

!"E . . .

INSERT itab INDE$ SY-INDE$.

ENDCASE.

Alternative =.

1oop through the alread& sorted ta!le into an au(iliar& ta!le and com!ine the li*e records usinglogical e(pressions.

%06 ser +nterfa)e ;+<

@) statuses should !e used for interactive report programs and online programs. @se menu !arlin*ing whenever possi!le to !uild consistent @) statuses for screens within a module pool.

%07 Maintenan)e/Corre)tion of e(istin. produ)tion )ode6hen changing production code' the Revision Ta!le in the main program comment !loc* must !eupdated. Refer to Section 3.= or the standard program 2F@PST0S5 for the information re-uired.

Surround changed code with 7Begin of8 and 8>nd of8 comment statements with the changenum!er included.

)f ma"or coding changes are to occur' indicate the changes in an e(tended description and revampthe program. The program' however' must compl& with the standards defined in this document atthe time the modification is to ta*e place and not rel& on the old standards when the program wasoriginall& developed. This will ensure the rewor*ed program is up to date on new standards and practices.

%0!9 +nterfa)e #*pes

OSee $onversion and )nterface Plan.

%0! '(ternal Data Sets

0efine via logical file names under the customiing tool.

QMS@DC !, of "!




%0!! +nternal #a$les

The $$@RS n statement should closel& match the e(pected num!er of rows that the ta!lewill contain. An area in the s&stem roll area is reserved !ased on the ta!le sie defined !& thisstatement. )f more ta!le rows are appended into the internal ta!le than defined in the occurs

clause' records will !e stored in either the roll area !uffer of paged out of memor&. This willcause performance degradation in referencing ta!le entries. )f the num!er of rows is un*nown'use $$@RS , .

The $1>AR Ita!J should !e used to initialie the ta!le header record.

The R>R>SG Ita!J should !e used to delete all ta!le entries and release an& paged out area.)t is recommended that !efore a ta!le is used' perform a R>R>SG then a $1>AR in this order.A R>R>SG does not clear the header record.

The R>> Ita!leJ should !e used at the end of the program in the wrap<up section.Performing a R>> will release the storage area in the s&stem roll area allotted to the ta!le and

delete all lines.

%0!% 'ffi)ien)* Standards

@se arra& fetches instead of looping when possi!le.

@se selection ta!les whenever the& will !e needed for reuse.

The R0>R BF statement must have an inde( for efficienc&.

%a*e sure 0ATA statements have proper 7li*e8 or t&pe associated with each field.

The %?><$RR>SP#0)# statement has poor performance. )t is !etter to move thefields in a record individuall&.

";"*/4 Query is not maintainable and is not e''icient. t is a 'ourth=,eneration lan,ua,e$ !hich ma8es iteasy to create a re#ort$ ho!ever$ this utility should be used !ith care'ul consideration o' theconseKuences. Aee# in mind that Kueries are trans#orted di''erently 'rom other obects.

QMS@DC !5 of "!




ABAP/" Module Pool Standards And Pra)ti)es

"0 ABAP/" Module Pool Standards and Pra)ti)es

The purpose of this section is to define the !asic standards that all developed programs mustcompl& with when creating or maintaining %odule Pools in the SAP environment. This sectiondescri!es the rules surrounding the use of ABAP features and components specific to %odulePool program t&pes. $oding in the main program must compl& with standards and practicesdefined for ABAP/4 2Section 3.,5.

"0 Pro.ram Stru)ture

The ABAP Programmers 6or*!ench 2S>D,5 should !e used to create and maintain all %odulePool programs. Sample flow logic and associated modules for all screens in a module pool aredefined in appendi( >.

"0! S)reen Definitions

Screens are to use data dictionar& fields for all varia!les. This does not include multiple selectionsli*e radio !uttons.

Screens are to !e num!ered with an entr& screen of ,,. Reuse screens whenever possi!le.

"0% + interfa)es

@) interfaces must follow SAP standards. @ser defined menus are to contain all actions that areapplica!le to the transaction. )tems that are not effective during a screen process are to !edisa!led. $ommonl& used selections are to appear as push !uttons !elow the menu !ar.

"0" P1P>P windows

Pop<up windows are allowed and to !e used at programmer or customer preference.Programmatic circumventions of pop<up windows must !e included for !atch data processingconsiderations.

"0& 1EC1D' ;SF>C1MM<

An KE$0> varia!le must !e specified in all screens. This varia!le is defined via the field listof each screen created 2>(ists as the last field in the field list5.

QMS@DC !6 of "!




R'4'R'-C'S

5 B$ SAP St&le uide: SAP America' Appendi( > 0ocument #o. +,,,<C4+3

=5 $onversion and )nterface Plan.

QMS@DC !7 of "!




Appendi( A

Table of Application Area Codes

0escription Area $ode Su!<Area $ode

A% < Assets %anagement A

AP<Adv. Planning Q ptimiing 0P 0emand Planning

S# Suppl& #etwor*

Planning

PP Production Planning /0etail Scheduling

A lo!al Availa!le toPromise

$ < $ontrolling $ ), )nternal rders

$ P$ Product $osting

$R%<$ust. Relationship %gmt. R )B )Base

R $% $ontract %anagement

R PS Professional Services

R S ield Services

R )$ )nteraction $enter

R S$ Service $enter 2)n<Gouse Repairs5

R P1 Prod. 1ifec&cle %gmt

R %6 %iddleware

R BP Business Partner

R PR Products

R P pportunit& %gmt

R MT Muotes

QMS@DC %9 of "!




R S Sales rders

R P$ Pricing

R 10 1eads

R $P $ampaigns

)<inancial Accounting AA < Asset Accounting

AP < Accounts Pa&a!le

AR Accounts Receiva!le

$$ $ost $enter Accounting

1 eneral 1edger Acct.

PA Profita!ilit& Anal&sis

P$ Profit $enter Acct.

S1 Special Purpose 1edger

B6 Business 6arehouse

%% < %aterials %anagement % %R %%R

% >0 >0)

% )% )nventor& %anagement

% PR Purchasing% ># >ngineering

% $% $ommon %%

% P) Ph&sical )nventor&

60 < 6arehousing Q 0istri!. 0 1> 1ogistics >(ecution

0 >% >(port %anagement

0 6% 6arehouse %gmt.

0 TR Transportation

GR Pa&roll/Benefits/PA G PF Pa&roll

G B# Benefits

G % rganiation %gmt.

G PA Personnel Admin.

QMS@DC % of "!




G B6 Business 6arehouse

G %S %gr. Self Service

G >S >mplo&ee Self Service

G T% Time %anagement

PP < Production Planning P P Production rders

P %R %aterial Re-. Planning

P SP Sales Q per. Planning

P% < Plant %aintenance 1

M% < Mualit& %anagement M MP Mualit& Planning

M M) Mualit& )nspection

M M$ Mualit& $ontrol

M M# Mualit& #otifications

PS < Pro"ect S&stem

S0 Sales Q 0istri!ution S %0 %aster 0ata

S PR Pricing

S S Sales Q Sales rders

S SG 0eliver& Q ShippingS TP Transportation

S B1 Billing

S >0 >0)

S S) Sales )nformation

S $S $ustomer Service

S )$ )nter<compan& Sales

S R> Returns Q Ad"ustments

Basis B B$ Basis $omponents

$ross Application

QMS@DC %! of "!




Appendi( AU

QMS@DC %% of "!




Appendi( B

Standard Program Structure

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% &'()'am name* &'()'am name - &'()'am tite%% De,'iti(n* De,'iti(n (/ '()'am%% Dee(ment Ca,,* Dee(ment Ca,, A,,(iate1 wit2 '()'am%% Tabe U1ate,* 3i,tin) (/ tabe, 41ate1

%% &a'amete',* 5#(' In41e,6 #4nti(n (14e,7%% In4t* 5#(' In41e,6#4nti(n (14e,7%% !4t4t* 5#(' In41e,6#4nti(n (14e,7%% Ret4'n C(1e,*%% Seia 3()i*%% In41e,*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% H I S T ! R Y ! # R E " I S I ! N S%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Date &'()'amme' Re84e,t 9 De,'iti(n% --------------- ------------------- ------------- ---------------------------%% 116mm6yy :::::::::::: nnnnn New &'()'am%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%RE&!RT YU&STDS .%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% T A B 3 E S%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

TAB3ES*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% S E 3 E C T ! & T I ! N S%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%SE3ECT-!&TI!NS*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% & A R A E T E R S%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%&ARAETERS*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% D A T A

QMS@DC %" of "!




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%[Appendix B]

DATA*%% A4m4at(', %%

%% C(n,tant, %%

%% Swit2e, %%

%% W('k ;e1, %%

%% Inte'na Tabe, %%

%% Data ,t'4t4'e, 6 St'in), %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% I N I T I A 3 I < A T I ! N%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%INITIA3I<ATI!N.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% A T S E 3 E C T I ! N S C R E E N%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%AT SE3ECTI!N-SCREEN.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% T ! & ! # & A E%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

T!&-!#-&AE.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% E N D ! # & A E

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%END-!#-&AE.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% S T A R T ! # S E 3 E C T I ! N%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%START-!#-SE3ECTI!N.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% E N D ! # S E 3 E C T I ! N%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%END-!#-SE3ECTI!N.%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% # ! R S%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

[Appendix B]

QMS@DC %& of "!




Appendi( D

Business Short, Medium, Long ames

These are determined !& the !usiness owners; !usiness rules.

Short #ame 1ong #ame 0escription

%AT %ATR

1

%AT>R)A1 %aterial

QMS@DC %5 of "!




Appendi( 0U

QMS@DC %6 of "!




Appendi( '

Template Screen !lo" Logic Structure

4low lo.i) %-------------------------------------------------------------------&'(e,, Be/('e !4t4t.%m(14e SET>STATUS . ? Cae1 by a ,'een,

% Ente' ,'een ,ei; m(14e, 2e'e i.e. 1ynami ,'een (kin)@ et.%%-------------------------------------------------------------------

&'(e,, A/te' In4t.% &'(e,, /a,t-e:it (mman1,m(14e &AI>E$IT AT E$IT-C!AND. ? Cae1 by a ,'een,% Sae !K>C!DE 'e,,e1m(14e &AI>INITIA3I<E. ? Cae1 by a ,'een,%% Ente' ,'een ,ei; m(14e, 2e'e i.e. #ie1 2ek,@ 3((,@ Tabe C(nt'(, et.%% &'(e,, 4,e' (mman1 5 !K>C!DE 7 a/te' a 2ek, (mete1m(14e USER>C!ANDS.

Pro)ess $efore output modules %-------------------------------------------------------------------

%%%INC3UDE <:::!0 .%-------------------------------------------------------------------%---------------------------------------------------------------------%% (14e SET>STATUS !UT&UT%---------------------------------------------------------------------%% te:t %%----------------------------------------------------------------------%!DU3E SET>STATUS !UT&UT. CASE SY-DYNNR. ? Inte''()ate ,'een n4mbe' WHEN 000. S'een 1e,'iti(n /(' ,'een 00 SET &#-STATUS 00AIN. SET TIT3EBAR 00. WHEN 000. S'een 1e,'iti(n /(' ,'een 00

SET &#-STATUS 00AIN. SET TIT3EBAR 00.% F A11 any ,4b,e84ent ,'een,

ENDCASE.END!DU3E. SET>STATUS !UT&UT

[Appendix #] Pro)ess After +nput modules

QMS@DC %7 of "!




%-------------------------------------------------------------------%%%INC3UDE <:::I0 .%-------------------------------------------------------------------%---------------------------------------------------------------------%% (14e &AI>E$IT IN&UT

%---------------------------------------------------------------------%% te:t %%----------------------------------------------------------------------%!DU3E &AI>E$IT IN&UT. CASE SY-DYNNR. ? Inte''()ate ,'een n4mbe' WHEN 000. ? S'een 000 SET SCREEN 0 . 3EA"E SCREEN. WHEN 000. ? S'een 000

% #i',t '(e,, any 1e-84e4in) (/ ent'ie,@ (-4, t( (n;'m 1ata (,,@ et.CASE SY-UC!. ? Inte''()ate ,y,tem ;e1 t( ;n1 (4t wit2 /a,t e:it 'e,,e1 WHEN GRW.

SET SCREEN 0 .

WHEN !THERS.SET SCREEN 000.

ENDCASE3EA"E SCREEN.

% F A11 any ,4b,e84ent ,'een, ENDCASE.

END!DU3E. &AI>E$IT IN&UT%---------------------------------------------------------------------%% (14e &AI>INIT IN&UT%---------------------------------------------------------------------%% te:t %%----------------------------------------------------------------------%

!DU3E &AI>INIT IN&UT.% ,et new (k>(1e. SA"E>!K = !K>C!DE.% ea' (k>(1e. C3EAR !K>C!DE.END!DU3E. &AI>INIT IN&UT%---------------------------------------------------------------------%% (14e USER>C!ANDS IN&UT%---------------------------------------------------------------------%% te:t %%----------------------------------------------------------------------%!DU3E USER>C!ANDS IN&UT.

CASE SY-DYNNR. ? Inte''()ate S'een n4mbe' WHEN 000. ? S'een 00 5 ente' 1e,'iti(n 7

&ER#!R &R!CESS>000>!K>C!DES. 5 #('m '(4tine t( '(e,, !K (1e, 7 WHEN 000. ? S'een 00 5 ente' 1e,'iti(n 7

&ER#!R &R!CESS>000>!K>C!DES. 5 #('m '(4tine t( '(e,, !K (1e, 7% F A11 ,4b,e84ent ,'een, [ Appendix #] ENDCASE.

END!DU3E. USER>C!ANDS IN&UT

QMS@DC "9 of "!




QMS@DC " of "!




[Appendix #]

abap development standards

Documents