QMS-REV-V.1.

1-18-09-17

TS.031 BUILD STANDARDS

Oracle EBS & Fusion CEMLI Build
Standards
Author: TransSys
Creation Date: January 7, 2008
Last Updated: October 4, 2017
Version: Draft 1.1

Document1 Page i of 33
Document Control

Change Record
4

Date Author Version Change Reference

30-Sep-2013 Sethu Arunachalam 1.0 Initial document

18-Sep-2017 M S Prabhu 1.1 Changed to incorporate standards for Fusion reports

Reviewers

Name Position

SEPG Group

Distribution

Name Location

Project Repository

File Ref: Document1 Page ii of 33

 Contents

Document Control ..................................................................................................................ii

Introduction ............................................................................................................................. 1
Purpose ............................................................................................................................. 1
Background....................................................................................................................... 1
Scope and Application .................................................................................................... 1
Related Documents.......................................................................................................... 1
The Development Environment ........................................................................................... 2
Overview........................................................................................................................... 2
Directory Structure .......................................................................................................... 2
Forms and Reports Paths ................................................................................................ 3
Custom Oracle Schema ................................................................................................... 4
Registering Your Application ........................................................................................ 4
Custom Tables, Indexes and Sequences ....................................................................... 4
Custom Views, Packages and Triggers ......................................................................... 5
Century Date Compliance .............................................................................................. 5
Naming conventions ....................................................................................................... 5
Building Your Programs ................................................................................................. 7
Registering Your Programs ............................................................................................ 7
Forms Coding Standards ....................................................................................................... 9
Building a new form from scratch ................................................................................. 9
Modifying an existing form ............................................................................................ 9
Report Coding Standards .................................................................................................... 10
Setting the Environment ............................................................................................... 10
Formatting Currency Amounts ................................................................................... 10
Accessing Profile Values ............................................................................................... 10
Application Messages ................................................................................................... 11
Application Setup Information .................................................................................... 11
Key Flexfields ................................................................................................................. 11
Modifying Standard Queries ....................................................................................... 12
Report Data Restriction ................................................................................................. 12
Standards ........................................................................................................................ 12
SQL Standards ....................................................................................................................... 14
SQL Layout Rules .......................................................................................................... 14
General Notes ................................................................................................................. 16
Aliases ............................................................................................................................. 16
PL/SQL Standards ............................................................................................................... 17
PL/SQL Layout Rules ................................................................................................... 17
Naming Cursors ............................................................................................................. 18
Naming Structure Types and Structures .................................................................... 18

File Ref: Document1 Page iii of 33

 Naming Variables .......................................................................................................... 18
Exceptions ....................................................................................................................... 18
PL/SQL Best Practice Guidelines ....................................................................................... 20
Approach to Development ........................................................................................... 20
No hard-coding! ............................................................................................................. 20
Package all functions and procedures ........................................................................ 21
Avoid long deeply nested IF statements .................................................................... 21
Avoid anonymous blocks ............................................................................................. 21
Comment Standards ............................................................................................................. 22
Database Trigger Standards ................................................................................................ 23
Coding Standards specific to Fusion Objects .................................................................... 24
Data Models.................................................................................................................... 24
Data Set ........................................................................................................................... 24
Groups ............................................................................................................................. 24
Template ......................................................................................................................... 24
Reports ............................................................................................................................ 24
Parameters ...................................................................................................................... 25
Formatting Report output ............................................................................................ 25
Installation Routine Standards ............................................................................................ 27
Basic Business Needs..................................................................................................... 27
Script Organization ....................................................................................................... 27
Oracle Source Code Control ................................................................................................ 28
Code Migration Flow .................................................................................................... 28
Open and Closed Issues for this Deliverable .................................................................... 29
Open Issues..................................................................................................................... 29
Closed Issues .................................................................................................................. 29

File Ref: Document1 Page iv of 33

Introduction

Purpose
This document describes the standards that will be followedby TransSys for the
Oracle E-Business Suite extensions when building customizations to the Oracle
Applications.
Coding conventions and standards for Fusion have also been included.

Background
The information in this document has been defined as the result of discussions
between SEPG Group, project team representatives, technical staff, and
TransSysconsultants.
This document defines standards and guidelines for the extension development and
documentation. The objective of this document is to:
 Provide standards to identify components, thus promoting reuse and
simplifying the defect troubleshooting process.
 Encourage the use of successful solutions already deployed
 Provide standard mechanisms to identify custom components and
dependencies among them.
 Improve the development process with the feedback from previous releases.

Scope and Application

The standards in this document cover the Build phase and will primarily affect tasks
in the Module Design and Build (DS) process of OUM:
 DS.140 Module Design Specification
 Extension development

Related Documents
1. Oracle Applications Developers Guide
2. Oracle Applications User Interface Standards

File Ref: Document1 Page 1 of 33

The Development Environment
Each product (GL, Purchasing, Inventory, etc.) in an installation of Oracle
Applications has an associated operating system directory. All files required to
install, upgrade, or run the product are stored in this directory (or related
subdirectories). Each product also has one or more database user accounts which
own tables used by the product. Application Object Library calls this collection of
objects as an application.
A set of customizations for one or more products is installed as an application.
Thus it has a product directory and an Oracle user account.

Overview
Environment has a single “Custom Top” structure which is used for all custom
programs.
The main name conventions used for Communications Authority Of Kenya are:

Custom TOP XXCA_TOP All the source files are stored

directory under this directory.
Directory is not under
$APPL_TOP but under applmgr
home.

Custom Application XXCA_Custom All the application developer

Name Application setup should be assigned to this
application i.e. messages, reports,
forms, etc.

Database Schema XXCA Custom tables, sequences or

Name indexes have to be created on this
user’s schema.
Custom packages, views and
triggers are created under the
APPS schema

Prefix for Custom CA All the custom objects should

Objects have this prefix.
For example, a package name
would be CA_UTIL_PKG.

Directory Structure
Create $XXCA_TOP environment variable for Oracle Apps.
This should be added to the $APPL_TOP/admin/adovars.env file in the
‘customizations’ area at the end of the file. The entry would appear similar to :

File Ref: Document1 Page 2 of 33

 XXCA_TOP=”/xxx/yyy/zzz/xbol/1.0.0”
export XXCA_TOP

The product version subdirectory level allows multiple versions of a product to be

available within a single Applications installation. The naming convention is <major
version>.<minor version>.<patch level> (i.e. 4.1.0). The standard is to begin with
1.0.0 for a new product regardless of the general release number or Oracle
Applications.
Create the directory structure is as follows:

$XXCA_TOP/admin
$XXCA_TOP /bin
$XXCA_TOP /data
$XXCA_TOP /data/archive
$XXCA_TOP /disc
$XXCA_TOP /forms/US
$XXCA_TOP /help/US
$XXCA_TOP /html/US
$XXCA_TOP /java
$XXCA_TOP /jsp
$XXCA_TOP /lib
$XXCA_TOP /log
$XXCA_TOP /media
$XXCA_TOP /mesg
$XXCA_TOP /out
$XXCA_TOP /patch
$XXCA_TOP /plsql
$XXCA_TOP /reports/US
$XXCA_TOP /resource
$XXCA_TOP /sql
$XXCA_TOP /wf

All directories should be owned by applmgr. In development they need to be group

writeable to allow developers to add files to them.

Forms and Reports Paths

In the $APPL_TOP/admin/adovars.env file make the following additions to the

‘customizations’ area at the end of the file.

Add $XXCA_TOP as above.

Modify the REPORTS60_PATH by adding directories to the beginning of the Oracle

variable. The entry should appear as:

File Ref: Document1 Page 3 of 33

 REPORTS60_PATH=”$XXCA_TOP/media:$XXCA_TOP/reports/US:$REPORTS60_
PATH”
export REPORTS60_PATH

Also modify the Oracle FORMS60_PATH variable to appear as:

FORMS60_PATH=”$XXCA_TOP/forms/US:$XXCA_TOP/resource:$XXCA_TOP/m
edia:$AU_TOP/forms/US:$AU_TOP/resource:$FORMS60_PATH”
export FORMS60_PATH

Note: these paths allow customizations to share common objects (e.g. logos in
reports).

Custom Oracle Schema

Use standard Oracle Schema creation Utlity to create custom Schema. Utlity name:
ADSPLICE

Registering Your Application

This will be done by the ADSPLICE utility.

You must register your application before you can begin developing custom
modules. The following is an example of the steps typically required to register a
new application:
1. Create the directory structure
2. Modify $APPL_TOP/APPLSYS.env to set the environment variable
XXCA_TOP and add $XXCA_TOP/bin to the PATH environment variable.
3. Shutdown the concurrent manager.
4. Execute the APPLSYS.env file.
. APPLSYS.env
5. Restart the concurrent manager.
6. Invoke found and select the Application Developer responsibility
7. Register the application with name “Business Online”, short name XXCA and
basepathXXCA_TOP.

Custom Tables, Indexes and Sequences

New tables, indexes and sequences required by your custom programs should be
created in the CA schema.
You must create grants (from BOLINF to APPS) and synonyms (owned by APPS) so
your tables are available in the APPS schema.
Do not include storage clauses (max extents e.t.c.) in table creation scripts. These
will be handled automatically by the database.

File Ref: Document1 Page 4 of 33

Custom Views, Packages and Triggers
New views, packages and triggers required by your custom programs should be
created in an Oracle APPS schema.

Century Date Compliance

In the past, two-character date coding was an acceptable convention due to perceived
costs associated with the additional disk and memory storage requirements of full
four-character date encoding. As the year 2000 approached, it became evident that a
full four-character coding scheme was more appropriate.
In the context of the Application Implementation Method (AIM), the convention
Century Date or C/Date support rather than Year2000 or Y2K support is used.
Coding for any future Century Date is now considered the modern business and
technical convention.
Every applications implementation team needs to consider the impact of the century
date on their implementation project. As part of the implementation effort, all
customizations, legacy data conversions, and custom interfaces need to be reviewed
for Century Date compliance.

Naming conventions
Custom objects written specifically for Communications Authority are named using
the prefix CA.
The Communications Authority naming conventions are shown below.

Object Name Format Sample Object Name File location Comments

Type (XXCA_TOP
directory)

DATABASE OBJECTS

Table CA_<APPS>_DDDDD CA_HR_PM_STATUS

View CA_<APPS>_DDDDD_V CA__HR_PM_APPRAISALS None. Stored in
_V SVN
Sequence CA_<APPS>_DDDDD_S CA_HR_SEQUENCE_S None. Stored in
SVN
Index CA_<APPS>_DDDDD_Tn CA_OTA_DELEGATE_BOO I None. Stored in
KINGS_N15 SVN

T: U = Unique
N = Non-Unique
n = sequential number
Packages CA_<APPS>_DDDDD_PKG CA_HR_PERFORMANCE_A None. Stored in If the procedure is to be
(all PPRAISAL_PKG SVN called from sql, the
procedures (can be up to 32 char) PRAGMA tags can be
should be used to store them in a
inside a non read-only package.
package)

File Ref: Document1 Page 5 of 33

 Object Name Format Sample Object Name File location Comments
Type (XXCA_TOP
directory)

Database CA_<APPS>_TABLE_XYZ_TR CA_PO_VENDORS_BUR_TR None. Stored in Example:

trigger G G SVN PO_VENDORS_BUR_TR
G is a Before Update
TABLE = Base table name trigger that fires on each
X: B = Before Row.
A = After The base table name will
Y: I = Insert need to be abbreviated if
U = Update the total length exceeds 32
D = Delete characters.
Z: S = Statement
R = Row
TRG = Trigger

WORKFLOWS

New CA<APPS>_DDDDDD CA_IRCAPP.wft Wf The item type should be

Workflow (database server) limited to 8 char
Customized CA + (name of the standard CA_HRSSA.wft Wf This applies when the
Workflow item type) (database server) extensions have to be
applied to a standard item
type. The name of the
object cannot be changed.

APPS EXECUTABLES e.t.c.

New Form CA<APPS>TDDDD.fmb CA_PRQREQU.fmb forms/US

T: U = Update (forms server)
Q = Query Only
DDDD = description
Customized CA<STANDARD_NAME> CA_OEXOE.fmb forms/US Customizations to a
Form (forms server) standard form should be
developed through
personalization if possible
or if not possible through
the CUSTOM library
whenever possible.
Report CA<APPS>TDDDD.rdf CA_HRRPM.rdf reports/US Reports libraries also go
in here.
T: R = Report
DDDD = description
Forms CA<APPS>DDDD.pll DDDD = description /resource If the library is specific to
Libraries a
Form it should
have the same name as
the
form it is
attached to.
HTML file CA<APPS>DDDD.htm DDDD = description /html
JSP file CA<APPS>DDDD.jsp DDDD = description /jsp
Java class CA<APPS>DDDD.jar DDDD = description /java
SQL Loader CA<APPS>DDDD.ctl DDDD = description /bin
Control
Files
SQL CA<APPS>TDDDD.sql T: R = Report /sql
concurrent U = Update
program DDDD = description
script
PL/SQL CA<APPS>TDDDD.pls T: R = Report /plsql
script U = Update
DDDD = description

File Ref: Document1 Page 6 of 33

 Object Name Format Sample Object Name File location Comments
Type (XXCA_TOP
directory)

DB OBJECT INSTALLATION SCRIPTS

Lower case is preferred for new installation scripts

Note that all database functions and procedures need to be contained within packages

Package CA<apps>ddddd_pks.sql DDDDD = Customization None. Stored in

spec install Abbreviation SCM
script PKS = Package Spec
Package CA<apps>ddddd_pkb.sql DDDDD = Customization None. Stored in
body install Abbreviation SCM
script PKB = Package Spec

NOTE: Database objects other than packages that are owned by the same owner may be combined into one script where
appropriate, e.g. tables, indexes and sequences.

Database table_trg.sql TABLE = Base tablename None. Stored in Multiple trigger types will
Trigger TRG = Trigger SVN be combined into one
Install script install script
Single object.sql OBJECT = name of database None. Stored in
Database Object SVN
Object
creation
script
Table seed table_seed.sql TABLE = Base table name None. Stored in
data script SEED = Seed data SVN
Grant/Syno CA_<apps> AAA = Application prefix None. Stored in
nym script _<descry>_grants_syns..sql where objects reside SVN
BBB = Application prefix of
grantee

Building Your Programs

Write your unit tests before you start coding. As PL/SQL Guru Steven Feuerstein
succinctly puts it…
“If you write your program before you define your tests, how do you know when
you’re done”?
Assume that requirements are going to change during development. Design your
programs so that they can easily be adapted to suit the new requirements.
Follow the instructions in the reference manual of each Oracle tool you plan to use to
assist in making certain your environment is properly initialized.
Any text editor can be used for editing text files but we recommend using PL /S Q L
D evel oper f or creatingPL/SQL code. PL/SQL Developer templates will be
created to speed up development and encourage a consistant coding style.

Registering Your Programs

Follow the instructions in the Application Object Library Reference Manual to register
your forms and programs. All programs must be registered in order to be attached to

File Ref: Document1 Page 7 of 33

 menus or executed in the concurrent manager. Concurrent programs and reports do
not need to be reregistered after they are modified. Forms only need to be re-
registered if you add, delete, or change the order of fields or zones.

File Ref: Document1 Page 8 of 33

Forms Coding Standards
Oracle Forms coding standards are governed by the standards published by Oracle in
Oracle Applications User Interface Standards.
Wherever possible you should try to use the Custom Library CUSTOM.pll to make
changes to Oracle Applications rather than creating customized forms.

Building a new form from scratch

To ensure seamless integration with Oracle Applications, you must start with the
TEMPLATE.fmb form which can usually be found in $AU_TOP/forms/US or on the
Oracle Applications CD. Follow the Oracle Applications forms development
standards described in the Developer’s Guide manual to ensure user interface
consistency between Oracle Applications and your extensions.

Modifying an existing form

If you need to produce a customized Oracle Applications form, you copy the original
form and make your modifications to the copy. Move your completed (or modified)
form to the proper directory for your custom application. Register the form with
Oracle Application Object Library, associating it with your custom application, and
define a function for your new form.
After you have registered your form and defined a function for it, you can add it to
an existing menu (see Modifying an Existing Menu in Developer’s Guide manual) or
call it from a new menu (see Adding Menus and Responsibilities in Developer’s
Guide manual). Form modifications fall into three categories: cosmetic, navigational,
and functional. Cosmetic changes to screen boilerplate text or to the display
characteristics of fields will not impact form processing.
You should avoid removing or disabling any form validation logic. You may add
validation logic, such as permitting only specific formats or ranges for field entries
(though this is best done in the CUSTOM library instead of the form itself). Note that
for many Oracle Applications forms, most logic is contained in libraries attached to
the form (found under $AU_TOP/resource) or in stored packages in the database,
and these files may also need to be identified and/or copied and/or modified.
Take a very cautious approach when customizing forms. It is very easy to introduce
bugs which do not show up during testing, because there are so many different ways
to interact with a form. Beware of making fields mandatory when the underlying
table contains NULL values for that field. The user will get error messages when
querying these records.
Release 11.5.10 of Oracle Applications introduced a new way of customizing forms
called “personalization” . This should be used in preference to the CUSTOM library
or Forms modifications, if possible.

File Ref: Document1 Page 9 of 33

Report Coding Standards

Setting the Environment

Oracle specifies that you should use the user exists SRWINIT in order to set the
environment for the current user and set operating system memory allocation for
other user exits. This should be used in the before report trigger at the latest, before
any other user exit, cursor etc is called (you may need to set in the afterpform
trigger). When used, this must be followed up with SRWEXIT in the afterreport
trigger, in order to free up the operating system memory allocation. Failure to do this
may result in a server crash later on.

Note that in order to use SRWINIT, you are required to create the user parameter:

Name: P_CONC_REQUEST_ID
Type: Number(15)

This will, of course, receive the concurrent request id of the report, should you need
to refer to it in the report execution.

This user exit should be used in ALL custom reports – Do not

usefnd_client_info.set_org_context in a beforereport trigger. (FOR 11.5.10 and below).

Formatting Currency Amounts

Where a currency amount is displayed in any custom report, the figure displayed
should be coming from a formula column that is using the FND
FORMAT_CURRENCY user exit. While this is painful to do in the first place, once it
is done, your financial amounts are formatted in the same tested manner as all other
displayed financial amounts in every standard report, and the report is now useful for
any currency later on. Some notes with using this:

You must select and refer to the relevant currency code for the displayed amount in
the queries.
You must specify a character width to format to.
You may optionally specify a decimal precision.

Accessing Profile Values

There are three reasonably easy ways of doing this:

1. Pass the relevant profile value in to the report as a parameter;
2. Use the user exit FND GETPROFILE to look up a specific profile value; or
3. Use the PL/SQL package FND_PROFILE to look it up.

Option 3 is recommended.

File Ref: Document1 Page 10 of 33

 Note that you can also use FND_GLOBAL package to retrieve the current application
and user ids and names.

Application Messages
If you are displaying boilerplate that application users may want the ability to
change, store the text in an application message and use:

fnd_message.get_string(
fnd_profile.value('XXFND_CUST_APPL_PF'),
‘application_message_name');

To retrieve and display it.

Note that:
Custom messages should be stored in the custom application.

Application Setup Information

Several of the Financial applications have set up information that may be useful to a
custom report. Prime amongst these are:

PO_SYSTEM_PARAMETERS;
AR_SYSTEM_PARAMETERS;
AP_SYSTEM_PARAMETERS; and
FINANCIAL_SYSTEM_PARAMETERS.

In 11i, these are views that will only return one row. If you need to refer to
information in these tables you can either:

In the beforereport trigger, select value(s) into report level placeholder column(s); or
In the data model, create a top level query in which you select the value(s) you
require. In this case you then can make a Cartesian join to the other, lower queries, as
you should only have one record here.

Either way works just as well.

Key Flexfields
The user exists FND FLEXSQL and FLEXIDVAL should be used to select and display
the segments for key flexfields. Hard-coded key flexfield segment catenation is poor
programming practice. Refer to the Oracle Applications Flexfields Guide for the
relevant documentation about properly setting SELECT, WHERE, HAVING and
ORDER_BY clauses in sql code on key flexfields. Mostly used in GL, and to some
extent PO.

File Ref: Document1 Page 11 of 33

Modifying Standard Queries

When you are required to modify a standard Oracle Report, avoid adding extra
tables to the FROM clause of a query. Instead, use a formula column to select the
data by referencing a unique ID in the original selected data. If you need to get
many columns of data, then use a formula column to select into placeholder columns
as required. Remember to reset each placeholder column to NULL if the formula
column does not select any data into it.

Advantages of this approach include:

1. The original query is not modified. The data set selected by the report
should remain consistent with the original report. Bug testing should be
much easier.
2. You are able to handle the joins in any way you want: Raise application
errors, provide default values, write log file messages, whatever; whether or
not you find data or any particular type of data.
3. If Oracle release a new version of the report – it is much easier to re-
implement your customizations in this way.

Report Data Restriction

Note the following ways to restrict the data being displayed in a report:

4. Hide it – Code the format trigger of the frame that displays the unwanted
record to not display the record. Note that the record information is still
calculated within the report.
5. Filter it – Code the plsql filter of the record’s data model group to return false
under the specified conditions. The data is still selected and known within
the filter (if you want to write it to the log file), but will not be calculated
within the report.
6. Restrict it – Create a lexical parameter to not select the data in the first place.
This way minimizes the amount of records to be retrieved from the database
in the first place.

Standards
In typical character reports:

7. Include page number in the form Page 1 of 20 at top right of the page
8. Include end of report and no data found messages
9. Underline boilerplate headings with dotted lines within the boilerplate item.

In all custom financials reports where appropriate.

When you create new objects, keep the default prefix:

CS_ - summary columns

File Ref: Document1 Page 12 of 33

 CP_ - placeholder columns
CF_ - formula columns
M_ - normal frames
R_ - repeating frames
P_ - parameters
LP_ - lexical parameters (ok, this isn’t a default name)
B_ - boilerplate
G_ - groups
Q_ - queries
F_ - fields

And give each object a meaningful name (ie do not keep a number value such as B_1,
CF_23, M_5 etc).

When you refer to operating system files, never hardcode the operating system path
to the filename, use the REPORTS60_PATH to store and find the files, e.g. place logos
in $XXCA_TOP/media and include this in the REPORTS60_PATH.

When changing an existing program unit or query in a standard Oracle report

customization, explicitly mark the beginning and end of the custom code, eg:

--
-- Start of custom code
--

Custom code

--
-- End of custom code
--

Comment out unneeded original code, rather than delete it, so that it remains for
reference purposes during future support.

File Ref: Document1 Page 13 of 33

SQL Standards
Use the following standards when writing SQL statements.
Unless absolutely necessary, do not include table owners in SQL statements, instead
make use of synonyms or views owned by APPS. All standard Oracle Applications
tables can be accessed by APPS without the need to specify table owners. Custom
tables should be made available to APPS via synonyms or views as appropriate.

SQL Layout Rules

Examples of well formatted SQL statements are shown below
SELECT pl.attribute2
, pl.attribute1
FROM po.po_linespl
, po.po_distributionspd
WHERE pl.po_header_id = pd.po_header_id
AND pl.po_line_id = pd.po_line_id
AND perl.attribute9 = pd.po_distribution_id
AND EXISTS (SELECT ‘is in the batch’
FROM pms.pms_expense_report_headersperh
WHERE perl.report_header_id = perh.report_header_id
AND perh.attribute4 = '&&batch'
)

SELECT
pl.attribute2
, pl.attribute1
FROM
po.po_linespl
, po.po_distributionspd
WHERE
pl.po_header_id = pd.po_header_id
AND pl.po_line_id = pd.po_line_id
AND perl.attribute9 = pd.po_distribution_id
AND EXISTS
(SELECT ‘is in the batch’
FROM pms.pms_expense_report_headersperh
WHERE perl.report_header_id = perh.report_header_id
AND perh.attribute4 = '&&batch')

Both of the above are acceptable. The desirable features that they demonstrate are…
 All SQL reserved words shall be written in upper case text, with columns
definitions and variables written in lower case. This includes, column names,
table names and aliases.
 Every clause (i.e. SELECT, FROM, WHERE, ORDER BY, GROUP BY) shall start
on a new line as shall second and subsequent occurrences of :
 column names
 table names
 SQL reserved words

File Ref: Document1 Page 14 of 33

  Commas that separate column or table names should be placed before the column
or table name. Experience has shown that statements written using this method
are less sensitive to editing errors. Adding or removing lines does not result in
missing commas, thus decreasing development and maintenance time.
 List items should be indented so that the first character of each item aligns
vertically.
 Keywords should be indented so that the first character of each word aligns
vertically, with the exception of keywords such as ‘between … ….and’, when they
occur in the middle of a line. If a list item cannot be placed on the same line as the
keyword (for example, following ‘group by’ or ‘order by’), then it should be
placed on the following line.
 Subqueries and complex decodes should be indented to show their structure.
DECODE(status_flag, ‘R’, ‘Red’
, ‘Y’, ‘Yellow’
, ‘G’, ‘Green’
, ‘Not set’)

 When using OR in a WHERE clause, use braces to make the meaning clear, and
to avoid mistakes relating to order of precedence of AND and OR.

-- RIGHT --
AND c.customer_id = p_customer_id
AND (t.trx_id = p_trx_idOR p_trx_id IS NULL)

-- WRONG --
AND c.customer_id = p_customer_id
AND t.trx_id = p_trx_idOR p_trx_id IS NULL

 Braces “(“ and “)” that delimit clauses and nested subqueries should be aligned
vertically if this will help to clarify structure.
AND (
(x = 1 AND y = 2)
OR
(x = 3 AND y = 5)
OR
(x = 5 AND y = 7)
)
 Operators and predicates should be aligned vertically.
 The closing “;” can be at the end of the last line of the SQL statement or on a line
of its own after the last line.
 The aim of these standards is to ensure an uncluttered and clear layout. For
unusually logically complex or long statements this ‘list’ style of presentation may
be adapted, but only where the ‘list’ style would make the SQL difficult to read
(e.g. spans too many pages) or the logic difficult to follow. The number of these
statements should be few.
e.g. the following is acceptable
WHERE x IN (1,2,5,10, 20, 30, 40, 99, 199, 500, 1000, 2000, 5000)

File Ref: Document1 Page 15 of 33

  Dynamically generated SQL is not subject to these standards, as the level of
control that a developer has on the layout of dynamically generated SQL is
limited.

General Notes
 Columns listed in ORDER BY clauses shall always be listed by column name,
not number, unless the statement contains the set operators UNION, MINUS
or INTERSECT.
 Always explicitly list columns in an INSERT statement to prevent changes in
table structures rendering statements invalid.
 Always use multi-org views, not ‘_ALL’ tables (unless all data required).

Aliases
Each column in the SQL statement shall be prefixed with a table alias, even in
SELECT statements that select rows from a single table. An alias makes an SQL
statement more readable and easily extendible, without becoming sensitive to
errors.A table alias should be no more than five characters in length.
In the SELECT list, a column alias shall be specified for all expressions and columns
modified by functions. A meaningful name shall be used for the column alias which
is not the same as the original column name.
An example SELECT statement:
SELECT t1.col1
, t1.col2
FROM table1 t1
, table1 t2
WHERE
t1.numcol <10
AND t2.numcol = 20
AND t1.keycol = t2.fkeycol
GROUP BY
t1.col1
, t1.col2;

File Ref: Document1 Page 16 of 33

PL/SQL Standards

PL/SQL Layout Rules

PL/SQL keywords including (PACKAGE, PROCEDURE, FUNCTION, DECLARE,
BEGIN, END, IF, ELSE, ELSIF, RETURNS, WHEN OTHERS and EXCEPTION)
should be written in upper case :
The following should also apply:
 The first parameter declarations shall be on the same line as the PROCEDURE
keyword unless the procedure name is very long in which case the first
parameter declaration may be nested under the procedure name.
 Subsequent parameter declarations shall be on separate lines, preceded by a
comma and formatted such that the parameter name, the usage and type
declaration are aligned vertically as described in the SQL standards section of
this document.
 Use 2 spaces of indentation per nesting level. Use spaces rather than tabs to
avoid problems with different tab definitions on printers and editors. Tab
characters should not be used anywhere in program code. Some text editors
(e.g. Ultra-Edit, have a “tabs to spaces” function which is useful for tidying up
code that contains tabs.
 The length of each source line should not exceed 80 characters, unless allowing
a few extra characters would make the code more readable.
 Code should be laid out such that there is only one statement per line. This
improve readability and maintainability and makes debugging using a source
code debugger easier.
 Use white space to improve the readability of code. In particular, use blank
lines to prevent code appearing cramped.and to separate logically separate
blocks of code.

An example of a PL/SQL function is shown below:

FUNCTION fn_numerify_version ( p_version IN VARCHAR2 )

RETURN NUMBER
IS
l_retval NUMBER;
l_version VARCHAR2(30);

-- genzip.prog validates that there is a max of 4 fields

f1 VARCHAR2(20);
f2 VARCHAR2(10);
f3 VARCHAR2(10);
f4 VARCHAR2(10);

BEGIN
l_retval := 0;
IF p_version IS NOT NULL THEN
l_version := p_version||'.';
f1 := substr(l_version, 1
, instr(l_version, '.', 1,1) - 1);
f2 := substr(l_version, instr(l_version, '.', 1,1) + 1
, instr(l_version, '.', 1,2) - (instr(l_version, '.', 1,1) + 1));
f3 := substr(l_version, instr(l_version, '.', 1,2) + 1
, instr(l_version, '.', 1,3) - (instr(l_version, '.', 1,2) + 1));
f4 := substr(l_version, instr(l_version, '.', 1,3) + 1
, instr(l_version, '.', 1,4) - (instr(l_version, '.', 1,3) + 1));

File Ref: Document1 Page 17 of 33

l_retval := (to_number(nvl(f1,0)) * 1000000)
+ (to_number(nvl(f2,0)) * 10000)
+ (to_number(nvl(f3,0)) * 100)
+ (to_number(nvl(f4,0)) * 1);
END IF;

RETURN l_retval;

EXCEPTION
WHEN OTHERS THEN
RETURN ('Error in xxaxis_registry_pkg.fn_numerify_version for '||p_version||SQLERRM);
END;

Naming Cursors
 The name of a cursor shall begin with "cu_", followed by a description which will
generally relate to most important table in the select statement, in lower case.
e.g. cu_lines or cu_processed_lines.

Naming Structure Types and Structures

 Record structure types shall be named with "_rec" appended on the end.
 Table structure types shall be named with "_tab" appended on the end.
 Record structures based on a %rowtypedeclaration shall be named after the cursor,
replacing the "c_” prefix with "r_".
 Record structures based on a record type structure shall also be prefixed with "r_”.
 Names of PL/SQL table structures shall be prefixed with "t_".

Naming Variables
 PL/SQL variables, except for fields in record structures, shall not have names
identical to column names.
 Local variables should be named after the database column or column alias that
will populate them, prefixed with a "l_". Local variables which do not have a
direct relation with a column shall be given a meaningful name and also prefixed
with a "l_".
 Parameter variable names should be prefixed with a “p_”.
 Global variables should be prefixed with “g_”.
 For all variables use underscores to separate words rather than camel case. For
example use l_hdr_curr_code rather than l_hdrCurrCode or l_Hdr_Curr_Code.

Exceptions
Exceptions that can be anticipated should be catered for specifically within the
EXCEPTIONS portion of a module. A standard “catch-all” exception clause (i.e.
WHEN OTHERS) should conclude the EXCEPTIONS block.
Exception names shall be prefixed with a “ex_”. They should indicate what caused the
exception, not the actions that should be taken to handle the exception.

File Ref: Document1 Page 18 of 33

 Avoid In Favour Of
EXCEPTION EXCEPTION
WHENex_stop_processingTHEN WHENex_no_customer_foundTHEN
.... ....
WHENex_error_occurred THEN WHENex_stock_levels_lowTHEN

.... ....
END; END;

 Make sure that exceptions are handled at the correct level. If a program unit does
not have sufficient knowledge to know how to treat an exception, it should pass it
up to its calling program unit to deal with.
 Do not use “RAISE_APPLICATION_ERROR” in your Oracle Applications
program code. Leave that to Oracle Applications.

File Ref: Document1 Page 19 of 33

PL/SQL Best Practice Guidelines

Approach to Development
Think “modular”. Big complex programs should be built using smaller modules or
program units. These modules should in turn be built from even smaller modules
where possible.
Each little module should work in its own right and once it has been thoroughly unit
tested you can rely on it to work every time i.e. given inputs A and B expect output Y,
but for inputs C and D expect output Z. This leaves you free to look at the bigger
picture.
Each module should be able to give a clear error message when something in it goes
wrong, informing the user which module is calling and what the problem is.Make
sure that error messages are informative and accurate rather than cryptic and
misleading as they often can be. Provide enough information to enable the support
staff to quickly find out what has gone wrong.
If you create a program unit that might be useful to other developers, consider
placing it in a generic package where it can be made available to other programs.
Besides thinking in modules it can also be useful to think in terms of “layers”. Deep
down we have the most generic layer, then we build a layer on top of this which is
less generic but which re-uses code from the generic layer. On top of that we can add
further layers as necessary. Keeping the concepts of modules and layers in mind
during development can help us to write robust high quality code.
When developing, remember the principle of “Plan Do Check Act”. Keep cycling
through this process as you develop until you are confident that your program is
working as it should.

No hard-coding!
Hard-coding is poor programming practice.Do not include any numbers or string
values in your program code unless there is zero possibility that they will ever have
to be changed in the future.
Constants should be assigned all together in a list where they can easily be located
and updated. Suitable places for such lists are at the beginning of the program or in
at the top of a package spec. Unless the purpose of a constant is obvious from its
name, a comment should be included to indicate what it is used for.
Aim to limit the number of constants used in concurrent programs by instead passing
the values in as hidden parameters with default values.
Get values from the database where possible rather than assigning a value to a
constant e.g.
SELECT generate_customer_number
INTO g_generate_customer_number
FROM ar_system_parameters
;
ratherthan
g_generate_customer_number := ‘Y’;

File Ref: Document1 Page 20 of 33

Package all functions and procedures
All procedures and functions should be contained within a package and should not
be implemented as stand-alone against the database.
A package provides a container in which to place related items and encourages reuse
of existing code. As the public face of a package (spec) is separate to the body. Code
dependent on the package will remain valid if only the package body is changed. For
this reason package creation scripts must be split into two files.
 Source file name format for package spec: CA_IF_<interface id>_PKS.sql.
 For example: CAIF_IF002_PKS.sql
 Source file name format for package body: CA_IF_<interface id>_PKB.sql.

Lower case is preferred for install script filenames. If many existing scripts ar in
uppercase it may not be worthwhile changing them. This decision will be made
during the project initiation stage.
Packages offer many advantages including ease of maintainance and encouragement
of a more modularand tidy programming style through use of private functions and
procedures and package variables and cursors.

Avoid long deeply nested IF statements

Deeply nested IF THEN ELSE constructs can become almost unreadable, especially
when there are so many lines of code that you cannot tell which END IF goes with
which IF. It is much better to limit the number of lines in each block by calling a
procedure or function to replace long blocks of code. The flow of control should be
clearly visible in well structured code.

Avoid anonymous blocks

Avoid the use of anonymous blocks “DECLARE BEGIN END” and replace them with
functions or procedures. The only exception to this is if you have a SQL script from
which you need to call PL/SQL.

File Ref: Document1 Page 21 of 33

Comment Standards
 Comments must be produced in parallel with source code development, not
tagged on afterwards.

 Comments should be used as follows:

 Single-line comments -- (two dashes) should be used for any non-

documentation comments within code.

 If there are several consecutive lines of comment, the C-style comment

markers may be used (/* */). Some developers however prefer to still use
two dashes, as the C-style markers can then be used to comment many lines of
code during debugging operations.

 Each function or procedure declaration in a package spec should be preceded

by a comment describing its purpose and usage, as shown below.

------------------------------------------------------------------------
-- create_code_combination
-- Verify a code combination and if it does not exist and it does not
-- violate any cross validation rules then create the code combination.
-- p_coa_id = chart of accounts id
-- p_concat is the concatenated code combination string e.g.
-- '01.0000.3111.00.00.000'
-- Return the ccidif it is valid otherwise return NULL
-------------------------------------------------------------------------
FUNCTION create_code_combination ( p_coa_id IN NUMBER
, p_concat IN VARCHAR2)
RETURN NUMBER;

 Comments should not echo the code. They should add some extra information
to make the code more understandable, particularly by explaining steps whose
purpose is not clear from looking at the code. If an implementation strategy is
chosen for a particular reason, then comments should be added to explain the
decision.

File Ref: Document1 Page 22 of 33

Database Trigger Standards

Great care must be taken in the use of database triggers as they have the capability, if
not used correctly, to completely trash a database. It is recommended that custom
database triggers are only used for very simple activities such as logging or auditing
tasks or to automate some process required to support a de-normalisation design
decision (e.g. maintain an order total as the sum of all order line values). Remember
that database triggers are performed synchronously so that the database activity that
invoked them will not complete until all activities within the trigger complete.
Remember, also, that if a trigger is used to update another table and that other table
has triggers as well then these triggers must complete.
A custom trigger that is not behaving properly can cause major problems in the
application which are very difficult to track down
Exception handlers in triggerscan be coded to make sure that there is no doubt as to
the source of an unexpected Oracle Applications error message.
WHEN OTHERS THEN
fnd_message.set_name('GL','XXBATCHES_TR1');
fnd_message.set_token
('TRIGGER_NAME','XXGST_JRNL_GL_JE_BATCHES_TR1');
fnd_message.set_token
('MSG', 'GST toolkit trigger exception: '
||''||SQLERRM);
app_exception.raise_exception;

Structure and Style

Database triggers must follow the general standards for PL/SQL.

Performance Improvement Techniques

To improve performance, include all trigger logic in a database package and call the
package code from your database trigger.

File Ref: Document1 Page 23 of 33

Coding Standards specific to Fusion Objects

Data Models
All data models created for reports developed in Oracle Fusion can have a maximum
of 100 characters. To indicate that the object is a data model, it shall be prefixed with
‘TS’ will be the short name of the client (TransSys) whom the project is executed for.
The name shall be suffixed with DM to denote that it is a data model. This is needed
to have clarity in archival and un archival process.

Ex: TS Purchase Order Report DM

TS – Client Name
Purchase Order Report – Object Name
DM – Data Model

Data Set
Ex: TS Purchase Order Header DS
DS - Group
TS – Client Name
Purchase Order Header – Object Group Name

Groups
Ex: TS Purchase Order Lines GR
GR- Group
TS – Client Name
Purchase Order Lines – Object Group Name

Template
All Templates developed in Oracle Fusion can have a maximum of 100 characters. To
indicate that the object is a Template, it shall be prefixed with ‘TS’ will be the short
name of the client (TransSys) whom the project is executed for.

Ex: TS Purchase Order TP

TP- Template
TS – Client Name
Purchase Order – Template Object Name

Reports
All reports developed in Oracle Fusion can have a maximum of 100 characters. To
indicate that the object is a report, it shall be prefixed with ‘TS’ will be the short name
of the client (TransSys) whom the project is executed for. The name shall end with the

File Ref: Document1 Page 24 of 33

 word “Report” to denote that it is a report. The name shall have to match with the data
model.

Ex: TS Purchase Order Report

TS – Client Name
Purchase Order – Report Object Name
Report – Report

Parameters
All report parameters should follow the convention of starting with “P_” followed by
a meaningful name. This shall be in lower case only.

 For example“P_cust_Name” will denote “customer name” developed in

Oracle Fusion can have a maximum of 100 characters.

The following basic validations to be done on parameters

Parameters Validations:
Ordering by the Parameters with Hierarchical
Dependent or Independent of the parameters

Date validations:
From Date must be sysdate or less than sysdate
To Date must be greater than or equal to From Date and not greater than sysdate.
Where ever possible provide list of values (value set attached to the parameters).

Formatting Report output

All report outputs shall have a prescribed format to maintain uniformity across reports
developed in Fusion. The formatting shall be as below, unless explicitly provided by
client. Any change from the below standards whether or not it is requested by client
and regardless of the volume of change shall be incorporated in objects only with the
prior approval from Quality team. Approval mail or document from Quality team
shall have to be preserved to back up such deviations.

 Report headers shall be in CALIBRI and Font size 14.

 Sub headings and titles in output shall be in CALIBRI and Font size 12.
 Data shall be in CALIBRI and Font size 10.
 The provided parameter values shall be printed in the report top left corner for
user to know what value he has run the report for. In exceptional cases, where
count of parameters more than five, parameters need not be displayed in the
output, as it will be awkward.
 The section comprising of the report heading, display of report parameters and
their values, run by & run date and the table heading shall be in dark blue.
 Where the parameter count goes beyond two and less than or equal to five,
they need to be displayed vertically only. Otherwise, they can be displayed
horizontally. In any case, not more than two parameters shall be displayed in
front end horizontally.

File Ref: Document1 Page 25 of 33

  “Run date” and “Run by” shall have to appear in the top right corner of the
report. Report runtime shall be of the format DD-MON-YYYY HH12:MI
A.M/P.M. On specific demand from the client, this format could be changed.
 To make the output legible, blank line shall be inserted beneath report title and
"report parameters" display and so also beneath parameter values and data
display.
 Page Numbering, wherever applicable shall be at the right hand side in the
header and the format “Page X of Y” where Y is the total number of pages and
X, the current page number. This shall be applicable only for layouts in RTF
format and NOT EXCEL formats. This shall not be applicable even in case of
pre-printed stationeries and statutory documents.
 Number values shall be right aligned.
 Text and Date values shall be left aligned.
 Column headings shall be centred.
 Decimals to have two digit after decimal point, unless explicitly asked by
customer for change.
 All dates shall be in DD-Mon-YYYY format only, unless specifically asked by
client.

File Ref: Document1 Page 26 of 33

Installation Routine Standards
Standard Oracle Applications use Autoinstall to create the database objects and seed
data that they need to run. Customizations cannot use Autoinstall and must use
another method.

Basic Business Needs

Developers will need to create install scripts to create database objects such as tables,
views and packages. The scripts that you create to install your customization should:
Install all objects with the minimum number of manual steps.
Be reexecutable without errors or creating duplicate data.
Be transportable to a different environment or machine.

Script Organization
All database object creation scripts will use the CREATE OR REPLACE <object
name> syntax so that they can be rerun on demand. Do not include a DROP
statement for a custom table that may include important data unless you are
absolutely sure that it can do no harm if the script is re-run at a later stage.
A grant/synonym script may also be required to give access to database objects that
do not belong to APPS. Scripts may also launch concurrent programs to register
program modules or load interface tables as needed.

File Ref: Document1 Page 27 of 33

Oracle Source Code Control
Source code control is the process of managing revisions to program source code and
the modification of files by multiple individuals.
Currently the eQsource code version control is managed SCM for source code
control. It is evisaged that we will continue to use this system for at least the initial
stages of the project.
At present the is no plan to consider other version control systems
Source control will be covered by a separate document QFEQ – Software
Configuration Management.doc.

Code Migration Flow

 All code development should be done in the DEV environment
 Completed code must be uploaded and checked-in to the SVN repository
 All code moved to another environment must be extracted from the SVN
 Further rework must be based on code extracted from the SVN

File Ref: Document1 Page 28 of 33

Open and Closed Issues for this Deliverable

Open Issues

ID Issue Resolution Responsibility Target Date Impact

Date

Closed Issues

ID Issue Resolution Responsibility Target Date Impact

Date

File Ref: Document1 Page 29 of 33