Contents
AMENDMENT
HISTORY
|
Version
|
Author
|
Page No
|
Description
|
Reviewed By
|
Approved By
|
Review Date
|
Approval Date
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The purpose of this
document is to provide coding standards for the ABAP objects developed by Yash
Technologies.
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.
The program name must be in
compliance with the ABAP Naming Standards document.
The table below lists and describes the attributes.
|
|
|
Should contain an informative description of what the object does.
|
|
1 – Executable
I – Include
module
M – Module Pool
F – Function Group
S – Subroutine
K – Class
Definition
|
|
Should be K if the object is a customer production program.
|
|
|
|
Should be set if
the object contains any arithmetic operations.
|
|
|
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.
|
Description
|
|
Name of the
project for which the object was created.
Example: GENESIS
or SYMPHONY.
|
|
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 on which the
object was created.
Example: 9th
April 2000.
|
|
Name of the
person who has created the object.
|
|
List of all input
data to the object.
|
|
List of all
outputs of the object.
|
|
The scheduling of
the object. Indicate if the object is to be run online or in background.
|
|
Description
detailing the purpose for creating the object.
|
|
Description of
the restrictions and assumptions contained within the object.
|
|
Author of the
design document or the contact businessperson.
|
|
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.
|
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.
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.
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].
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
Format:
SELECT-OPTIONS:
S_USERID FOR BKPF-USNAM, “Appropriate in-line comment
S_DODATE FOR BKPF-BUDAT. “Appropriate in-line comment
The following is the format for
declaring selection
PARAMETERS:
Format:
PARAMETERS:
P_USERID LIKE BKPF-USNAM. “Appropriate in-line comment
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
·
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
·
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
·
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.
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.
Every
event should be preceded by the
name of the
event.
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
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.......:
*
************************************************************************
REPORT ZSKELETON MESSAGE-ID ZMIM
LINE-COUNT 60
LINE-SIZE 132
NO STANDARD PAGE HEADING.
* Table
declarations....................................................
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
* Range
tables..........................................................
RANGES R_VBELN FOR VTTP-VBELN. " Delivery documents
* Type
declarations for internal tables.................................
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.
* Work
variables........................................................
DATA:
W_PHY_FILE(255) TYPE C,
" Physical file name with path
W_SHPPNT LIKE
TVSWZ-VSTEL. " Shipping point
* Flags.................................................................
DATA:
FL_PRNT_SUMMARY(1) TYPE C,
" Summary report is being printed
FL_TOGGLE(1) TYPE C. " Toggle for line color
*
Constants.............................................................
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'.
* Field
Strings.........................................................
DATA FS_ROUTE_PRICE TYPE
TYPE_S_ROUTE_PRICE.
* Internal
tables.......................................................
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.
IF SY-UCOMM EQ 'ONLI' OR SY-BATCH EQ 'X'.
* 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...
* Upload the pricing information from the
input file
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.
MESSAGE E999 WITH 'No route found for the origin
plant.'(003).
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