Contents
Document History
|
AMENDMENT
HISTORY
|
|||||
|
Version
|
Author
|
Page No
|
Description
|
Reviewed By
|
Approved By
|
|
Review Date
|
Approval Date
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Objective:
The purpose of this
document is to provide coding standards for the ABAP objects developed by Yash
Technologies.
Definition:
Coding standards
are mandatory coding procedures that should be followed as per Yash SAP's
quality system to deliver manageable ABAP objects with good aesthetics.
Program Name
The program name must be in
compliance with the ABAP Naming Standards document.
Program Attributes
The table below lists and describes the attributes.
|
Attribute
|
Description
|
1) Title |
Should contain an informative description of what the object does.
|
2) Type |
1 – Executable
I – Include
module
M – Module Pool
F – Function Group
S – Subroutine
J – Interface Definition
K – Class
Definition
|
3) Status |
Should be K if the object is a customer production program.
|
4) Application |
Should conform to the functional area that the object relates to.
|
5) Fixed point arithmetic |
Should be set if
the object contains any arithmetic operations.
|
6) Authorization Group |
Should be specified if this level of security is required.
|
Development class and change request
All new objects
must be assigned to a development class and to a change request
An existing
development class should be used wherever possible and a new one should be
created, if the request the object belongs to does not logically pertain to any
of the existing development classes.
If an object is
intended for private use, it should be assigned to the development class $TMP.
The object will not be captured in a change request.
If an object is
intended for use but is never to be transported to production, the program
should be assigned to a development class that will not be transported to production.
Header block
The object header block must contain all the items listed in the
table below. The skeleton program ZSKELETON contains an example header block that may be copied.
|
Description
|
|
PROJECT |
Name of the
project for which the object was created.
Example: GENESIS
or SYMPHONY.
|
SERVICE REQUEST NUMBER |
Number that
uniquely identifies the service request. If the service request is broken
down into specific task numbers, include the task number as well.
Note: During a
project this will be the Request ID assigned for the development work.
|
DATE WRITTEN |
Date on which the
object was created.
Example: 9th
April 2000.
|
AUTHOR |
Name of the
person who has created the object.
|
INPUT |
List of all input
data to the object.
|
OUTPUT |
List of all
outputs of the object.
|
SCHEDULING |
The scheduling of
the object. Indicate if the object is to be run online or in background.
|
PURPOSE |
Description
detailing the purpose for creating the object.
|
RESTRICTIONS/ ASSUMPTIONS |
Description of
the restrictions and assumptions contained within the object.
|
SPEC. PREPARED BY |
Author of the
design document or the contact businessperson.
|
PROGRAM HISTORY BLOCK |
Documentation of
all subsequent program changes in order to provide an accurate maintenance
history.
Each change
details:
Service Request
Number/Task, e.g. SR1140-1
Developer making
the change
Date of the
change
Description of
the change, and
Search string:
e.g. SR2140-1.
The line of the
code where changes are done, should contain the service request number as a
search string.
Every amendment
should follow the details mentioned in the History block.
|
Amendments
A search string should document every line/block of code
that is changed as a part of an amendment.
The search string should follow the following convention:
Deletion of Code: The Service Request / Task Number
should be prefixed with capital letter 'D'. E.g.: D-SR1140-1.
Insertion of Code: The Service Request / Task Number
should be prefixed with capital letter 'I'. E.g.: I-SR1140.
On-line program documentation
The SAP on-line documentation should be maintained with a
business description of the object. It should contain sufficient information
for a user to understand the functionality of the object. Any requirement,
input, output, restriction, scheduling and assumption should be mentioned.
Declarative elements
1) REPORT
The REPORT
element should be coded immediately after the header block.
Any associated parameters should be consistently indented to the right of the REPORT element, for the purposes of readability.
Format:
REPORT ZYASHTEST [NO STANDARD PAGE
HEADING]
[LINE-SIZE
132]
[LINE-COUNT
65]
[MESSAGE-ID
ZZ].
2) TABLES
The following is the format for
declaring TABLES:
Format:
TABLES: TABLE1, “Table description as in-line comment
TABLE2, “Table description as in-line comment
TABLE3, “Table description
as in-line comment
3) SELECT-OPTIONS
The following is the format for
declaring SELECT-OPTIONS:
Format:
SELECT-OPTIONS:
S_USERID FOR BKPF-USNAM, “Appropriate in-line comment
S_DODATE FOR BKPF-BUDAT. “Appropriate in-line comment
4) PARAMETERS
The following is the format for
declaring selection PARAMETERS:
Format:
PARAMETERS:
P_USERID LIKE BKPF-USNAM. “Appropriate in-line comment
5) RANGES
The following is the format for
declaring RANGES:
Format:
RANGES
R_USERID FOR BKPF-USNAM,
“Appropriate in-line comment
R_DOC_DATE FOR BKPF-BUDAT. “Appropriate in-line comment
6) WORK VARIABLES AND FLAGS
·
Wherever possible, reference to data dictionary
fields and structures should be used to create work variables
and flags.
· In-line
comments should be provided for explaining the purpose of the work fields
·
Underscores “_” should be
used to separate words or letters that define a variable.
Format:
DATA:
W_USERID LIKE BKPF-USNAM,
“Appropriate in-line comment
W_DOC_DATE LIKE BKPF-BUDAT. “Appropriate in-line comment
7) CONSTANTS
·
Wherever possible, reference to data dictionary
fields and structures should be used to create constants.
· In-line
comments should be provided for explaining the purpose of the constants
·
Underscores “_”
should be used to separate words or letters that define a constant.
Format:
CONSTANTS:
C_USNAM LIKE BKPF-USNAM VALUE ‘RAOK’. “In-line comment
Program modularization
·
Large processing blocks of code should be broken
down into logical units and performed as subroutines.
·
If the same block of code is used in more than
one program, the following should be considered:
Ø Function
module.
Ø Include
program.
Ø Subroutine
pool.
Subroutines
Every subroutine call (PERFORM_)
should have the description of the functioning of the subroutine. And the
subroutine block (FORM - ENDFORM) should have the
details as mentioned below.
Text elements
The standard convention of text-elements
should be followed.
Block code
The keywords: IF - ENDIF, LOOP - ENDLOOP, DO – ENDDO, CASE - ENDCASE, SELECT - ENDSELECT,
need to follow the standard convention.
Events
Standard Checks:
1. Always
check for Divide by Zero conditions.
2. Always
try to replace CHECK statements with IF-ENDIF blocks.
3. Check
for potential Endless Loops.
4. Check
to see if Nested Selects can be eliminated.
5. Check
for IF-ELSEIF-ENDIF blocks that can be replaced with CASE-ENDCASE blocks
Standard Template:
The following code template has been
provided to illustrate the coding standards that are to be followed. The name
of the code template program is ZSKELETON.
* PROJECT : John Deere *
* BUSINESS FUNCTION : Customer Freight - Theoretical Costs *
* WORK UNIT ID / TASK : 000199-08 *
* DATE WRITTEN : 04th August, 2000 *
* AUTHOR : XYZ *
* TYPE : Report *
* INPUT : SAP Tables : A907, TVSWZ, TVRAB, VFSCAID, *
* VFSCAR1,
KONV, VFKK, VFKP, LIKP, *
* VTTK,
VTTP, KNA1. *
* User Inputs : Logical
file path, *
* Physical
filename, *
* Origin plant, *
* Shipping
cost date range, *
* Output
format(s). *
* OUTPUT : REPORT *
* Purpose : This report will provide an
analysis of the *
* effects of a proposed
rate change for Public *
* Warehouse Customer
routes using historical *
* shipment data. *
* SCHEDULING : On request. Executed via a
reporting tree. *
* RESTRICTIONS : None *
* SPEC.PREPARED BY : XYZ *
************************************************************************
*----------------------------------------------------------------------*
* Service Request/Task: *
* Programmer..........:
*
* Date of Change......:
*
* Description.........:
*
* Search String.......:
*
************************************************************************
LINE-COUNT 60
LINE-SIZE 132
NO STANDARD PAGE HEADING.
TABLES: TVRAB, " Route Stages
VFSCAR1,
" Freight Rates (One-Dimensional)
KONV, " Conditions (Transaction Data)
VFKP.
" Shipment Costs: Item Data
* Selection screen
elements.............................................
S_COSDAT FOR VFKP-PRSDT " Shipping cost date
OBLIGATORY.
P_DOWNLD AS CHECKBOX " Download format
DEFAULT 'X',
P_SUMMRY AS CHECKBOX. " Summary format
RANGES R_VBELN FOR VTTP-VBELN. " Delivery documents
TYPES: BEGIN OF TYPE_S_ROUTE,
ROUTE LIKE TVRAB-ROUTE,
" Route
KNEND LIKE TVRAB-KNEND,
" Destination point
TDLNR LIKE TVRAB-TDLNR,
" Forwarding agent
END OF TYPE_S_ROUTE.
TYPES: BEGIN OF TYPE_S_SCALES,
SLFNR LIKE VFSCAID-SLFNR, " Scale item number
SCAVAL_D LIKE VFSCAID-SCAVAL_D, " Gross weight
END OF TYPE_S_SCALES.
DATA:
W_PHY_FILE(255) TYPE C,
" Physical file name with path
W_SHPPNT LIKE
TVSWZ-VSTEL. " Shipping point
DATA:
FL_PRNT_SUMMARY(1) TYPE C,
" Summary report is being printed
FL_TOGGLE(1) TYPE C. " Toggle for line color
CONSTANTS:
C_TRUE(1) TYPE C " TRUE value of boolean
flags
VALUE 'T',
C_FALSE(1) TYPE C " FALSE value of boolean
flags
VALUE 'F'.
DATA FS_ROUTE_PRICE TYPE
TYPE_S_ROUTE_PRICE.
DATA T_UPLOAD_STRUCT TYPE STANDARD TABLE
" To upload data from flat file
OF TYPE_S_UPLOAD_STRUCT
INITIAL SIZE 20
WITH HEADER LINE.
* AT SELECTION-SCREEN
EVENT.............................................
*-----------------------------------------------------------------------
AT SELECTION-SCREEN.
* Check whether atleast one output format
has been selected
IF P_DOWNLD EQ SPACE AND P_SUMMRY EQ SPACE.
MESSAGE E999 WITH 'Select atleast one output format.'(001).
ENDIF.
" IF P_DOWNLD EQ SPACE AND...
PERFORM UPLOAD_PRICING_INFO.
* Retrieve the routes
PERFORM RETRIEVE_ROUTES.
ENDIF. " IF SY-UCOMM EQ 'ONLI' OR...
*-----------------------------------------------------------------------
* START-OF-SELECTION
EVENT..............................................
*-----------------------------------------------------------------------
START-OF-SELECTION.
* Output the report
PERFORM OUTPUT_REPORT.
*-----------------------------------------------------------------------
* TOP-OF-PAGE
EVENT.....................................................
*-----------------------------------------------------------------------
TOP-OF-PAGE.
* Output the page header and column
headers on each new page if the
* Download Format has not been selected by
the user
IF
P_DOWNLD NE 'X'.
PERFORM PRINT_HDRFTR USING C_HEADER.
ENDIF. " IF P_DOWNLD NE 'X'.
*-----------------------------------------------------------------------
* END-OF-SELECTION
EVENT................................................
*-----------------------------------------------------------------------
END-OF-SELECTION.
* Output the report footer if the Download
Format has not been selected
* by the user
IF
P_DOWNLD NE 'X'.
PERFORM PRINT_HDRFTR USING C_FOOTER.
ENDIF.
" IF P_DOWNLD NE 'X'.
*&
Form RETRIEVE_ROUTES *
*&---------------------------------------------------------------------*
* This subroutine retrieves the basic
route information for the public *
* customer zip-zip category (routes in the
500000 range). *
*----------------------------------------------------------------------*
* There are no interface parameters to be
passed to this subroutine. *
*----------------------------------------------------------------------*
FORM RETRIEVE_ROUTES.
FROM TVRAB
INTO TABLE T_ROUTE
WHERE ROUTE BETWEEN C_LOW_ZIPZIP AND C_HIGH_ZIPZIP
AND KNANF EQ P_OPLANT.
WHEN ‘RED’.
WRITE T_ROUTE-ROUTE COLOR COL_NEGATIVE.
WHEN ‘GREEN’.
WRITE T_ROUTE-ROUTE COLOR COL_POSITIVE.
WHEN OTHERS.
WRITE T_ROUTE-ROUTE COLOR COL_HEADING.
ENDCASE.
“CASE P_COLOR.
CHECK SY-SUBRC NE 0.
ENDFORM. "
RETRIEVE_ROUTES
*&---------------------------------------------------------------------*
*&
Form PRINT_HDRFTR *
*&---------------------------------------------------------------------*
* This subroutine prints the standard PM
header and footer as required.*
*----------------------------------------------------------------------*
* PC_HEADER_FOOTER ==> Indicator for header/footer *
*----------------------------------------------------------------------*
FORM PRINT_HDRFTR USING PC_HEADER_FOOTER
LIKE SY-WTITL.
* Set the report title based the report
being output
IF
FL_PRNT_SUMMARY EQ 'Y'.
W_TITLE = 'Summary by Customer'(008).
ENDIF.
" IF FL_PRNT_SUMMARY EQ 'Y'.
* Output standard PM header/footer
CALL FUNCTION 'Z_PM_HDR_FOOTER'
EXPORTING
RPT_ID = SY-CPROG
RPT_TITLE2 = W_TITLE
RPT_TXT_TYP = PC_HEADER_FOOTER
EXCEPTIONS
ERR_RC = 1
OTHERS = 2.
IF
SY-SUBRC NE
0.
MESSAGE S999 WITH 'Call to function Z_PM_HDR_FOOTER failed.'(024).
ENDIF. " IF SY-SUBRC NE
0.
* Print column headers after the page
header
CHECK PC_HEADER_FOOTER EQ C_HEADER.
FORMAT COLOR COL_HEADING INTENSIFIED ON.
IF
FL_PRNT_SUMMARY EQ 'Y'.
WRITE :/1 'Customer'(011),
12 'Name'(012),
48 '
Total Delivery Wt.'(014),
69 ' Current Actual Cost'(016).
ENDIF.
" IF FL_PRNT_SUMMARY EQ 'Y'.
FORMAT RESET.
SKIP.
ENDFORM. "
PRINT_HDRFTR
*&---------------------------------------------------------------------*
*&
Form UPLOAD_PRICING_INFO *
*&---------------------------------------------------------------------*
* This subroutine uploads the pricing
information from the user *
* specified flat file.
*
*----------------------------------------------------------------------*
* There are no interface parameters to be
passed to this subroutine. *
*----------------------------------------------------------------------*
FORM UPLOAD_PRICING_INFO.
REFRESH T_UPLOAD_STRUCT.
CLEAR T_UPLOAD_STRUCT.
IF
P_APPSR EQ 'X'. "
Application server
* Upload the pricing data from the flat
file
OPEN DATASET W_PHY_FILE FOR INPUT IN TEXT MODE.
READ DATASET W_PHY_FILE INTO T_UPLOAD_STRUCT.
APPEND T_UPLOAD_STRUCT.
ENDDO.
CLOSE DATASET W_PHY_FILE.
" SY-SUBRC check is not needed
ENDIF.
" IF P_APPSR EQ 'X'.
ENDFORM. "
UPLOAD_PRICING_INFO
*&---------------------------------------------------------------------*
*&
Form OUTPUT_REPORT *
*&---------------------------------------------------------------------*
* This subroutine outputs the report. *
*----------------------------------------------------------------------*
* There are no interface parameters to be
passed to this subroutine. *
*----------------------------------------------------------------------*
FORM OUTPUT_REPORT.
SORT T_DOWNLOAD.
PERFORM LINE_TOGGLE.
IF P_SUMMRY EQ 'X'.
" Prepare the summary data
MOVE-CORRESPONDING T_DOWNLOAD TO T_SUMMARY.
COLLECT T_SUMMARY.
ENDIF.
" IF P_SUMMRY EQ 'X'.
WRITE :/1
T_DOWNLOAD-SHIP_TO_PARTY,
12 T_DOWNLOAD-CUSTOMER_NAME.
ENDLOOP.
" LOOP AT T_DOWNLOAD.
ENDFORM. " OUTPUT_REPORT
