Define Application Users

Overview
An Application User is an authorized user of the Oracle Applications and/or Self-Service Web Applications
(OSSWA). A user is uniquely identified by an application username. Use the System Administrator Responsibility
to define users.

Define User
Navigate to: Security > User > Define

Tip: Tab through the fields when completing this form and watch the status bar for field specific prompts
User Name: Enter the name of an application user. An application user enters this
username to sign on to Oracle Applications and/or Oracle Self-Service
Web Applications. The following guidelines apply to this field:
Can only be one word
Define a standard naming convention such as first initial, last name.
User name is always in Upper Case
Alphanumeric ('A' through 'Z') and Numeric ('0' through '9') are
permitted.
Description: Enter a description for this user. Enter a user friendly name as
description e.g. Jane Doe.

Note: Description entered is displayed on the users OSSWA home page

when signing on to Self Server Web Applications.

Tip: You may also enter html tags in this field to format how the users
name is displayed, for example, entering <font color=red>Jane
Doe</font>, will display the users name in red on the OSSWA home
page.
Password: Enter the initial password of an application user. The user will be
prompted to change this password the first time they sign in. The
following guidelines apply to this field:
Must be at least 5 characters and no more than 100.
Alphanumeric ('A' through 'Z') and Numeric ('0' through '9') are
permitted.

Note: You will need to enter this field twice for verification
Person: If this user is an employee select the employee's full name from the LOV.
Customer: If this user is a customer select the customer's name from the LOV.
Supplier: If this user is a supplier select the supplier's name from the LOV.
E-Mail: Optionally enter the email address for this user.
Fax: Optionally enter the fax number for this user.
Password Expiration> Maximum number of days between password changes.
Days:
Password Expiration> Maximum allowed number of sign-ons to Oracle Applications or Self-
Accesses: Service Web Applications allowed between password changes.
Password Expiration> Select none if you do not wish to have passwords expire by number of
None: days or accesses.
Effective Dates>From: Optionally enter a start date when this user can begin accessing the
applications.
Effective Dates>To: Optionally enter an end date when this user can no longer access the
applications.
Responsibility: Select a responsibility you wish to assign this user.

Note: In order for a user to access the applications they must be assigned
at least one responsibility. Once a user is assigned to a responsibility it
cannot be deleted, therefore, you must deactivate the responsibility by
entering an end date. If you want to reactivate a deactivated
responsibility for a user change the end date to a date after the current
date or highlight the current end date and delete.
Responsibility> Optionally enter a start date when this user can begin accessing the
Effective Dates>From: applications with this responsibility.
Responsibility> Optionally enter an end date when this user can no longer access the
Effective Dates>To: applications with this responsibility.

Securing Attributes
Securing Attributes are used by the Oracle Self-Service Web Applications. Securing Attributes allow rows of data to
be visible to specified users or responsibilities based on the values contained in the row. Securing Attributes must
be assigned at both the user and responsibility level.

Example: If you want to restrict the user Jane with responsibility of 'Admin' to see only those rows where
customer_id = 1000 then assign the securing attribute ICX_CUSTOMER_ID to the responsibility 'Admin' then the
securing attribute ICX_CUSTOMER_ID and value of 1000 to the user, Jane.

Navigate to: Security > User > Define

Select: Securing Attributes
Securing Attributes> Select an attribute from the LOV to be used to determine which records
Attributes: this user can access.
Securing Attributes> Oracle Self-Service Web Application
Application:
Securing Attributes> Enter the value to be used to determine which specific rows of records
Value: this user can access.

Excluding Attributes
Excluding Attributes are used by the Oracle Self-Service Web Applications and are defined at the responsibility
level. Please refer to the AOL Application Responsibilities Training.doc

Note: Once assigned a responsibility, a user is excluded from any columns defined as excluding attributes for that
responsibility.

Responsibilities
A responsibility is a level of authority that determines the specific data users can access and the specific menu they
see. Each application user must be assigned to at least one responsibility and several users can share several
responsibilities. Responsibilities cannot be deleted. Use the Effective Dates>To field to disable a responsibility.
Use the System Administrator Responsibility to define responsibilities.

Define Responsibility
Navigate to: Security>Responsibility>Define
Responsibility Name: Enter an intuitive, unique name for the responsibility you are defining.
Application: Select the name of the application you wish to associate with the
responsibility from the LOV.

Note: This name does not preclude the user of this responsibility from
accessing other applications forms and functions if they are defined in
the responsibilitys menu.
Responsibility Key: Enter a unique name for this responsibility to be used by loader
programs.
Description: Enter a user-friendly description for the responsibility
Effective Dates>From: Enter the start date on which this responsibility becomes active.
Effective Dates>To: Optionally enter the end date on which this responsibility becomes
inactive.

Note: Responsibilities cannot be deleted. Use this field to de-activate a

responsibility.
Available From: A responsibility can be made available to the user from either the Oracle
Applications or the Oracle Self Service Web Application but not both.
Select which application system this responsibility will be available from.
Data Group> Name: Enter the ORACLE username, usually 'Standard'. The ORACLE
username determines the database tables and table privileges accessible
to the responsibility so if using something other than 'Standard' please be
extremely cautious.
Data Group> From the LOV select the application whose ORACLE username forms
Application: connect to when you choose this responsibility.
Menu: Select a menu that has been defined from the LOV.
Web Host Name: If your web server resides on a different machine from your database
you must enter the host name (URL) here.
Web Agent Name: Optionally enter the PL/SQL Agent Name for the database used by this
 responsibility. If unspecified, the agent name defaults to the agent name
current at log-on.
Request Group> Assign a request security group from the LOV for this responsibility. If
Name/Application: you do not assign a request security group to this responsibility then
users assigned this responsibility will not be able to run any reports,
programs, or request sets, except for request sets owned by the user.

Function and Menu Exclusions

You can define function and menu exclusions to restrict specific application functionality available to a
responsibility. Functions and menu exclusions are a great way to apply the separation of duties concept.

Example: You want the Payable Clerk to select invoices for payment, and print a Preliminary Payment Register but
you do not want the Clerk to format payments or print the checks immediately.

Solution: In order to restrict the options that the Payables Clerk can perform when generating a check run, simply
exclude the SUBFUNCTIONS the Clerk should not be able to perform (such as Payment Batches Confirm, Payment
Batches Format, Payment Batches Print) from his/her responsibility. In the 'Define Responsibility' form, query the
clerks current responsibility and in the Function and Menu Exclusions block, choose a type of Function, and in the
LOV choose the subfunctions mentioned above. The next time the clerk signs into AP, he/she will be restricted to
only select, build, print payment registers, etc. outside of the subfunction exclusions.

Navigate to: Security>Responsibility>Define

Select: Menu Exclusions

Menu Exclusions> Type: Select Menu to exclude all menu entries, functions, and sub-menus
from the responsibility.
OR
Select function to exclude all occurrences of that function from the
responsibility
Menu Exclusions> Select the name of the function or menu to exclude from the
Name: responsibility.

Self-Service Security Attributes

Oracle Self-Service Web Applications (OSSWA) is installed with seeded securing and excluding attributes which are
defined in the Web Application Dictionary. If you decide to use a securing or excluding attribute that is not seeded
then you must define the attribute using the Web Application Dictionary. Please refer to the appropriate Oracle
documentation for detailed instructions.

Securing Attributes
Securing Attributes are used by the Oracle Self-Service Web Applications. Securing Attributes allow rows of data to
be visible to specified users or responsibilities based on the values contained in the row. Securing Attributes must
be assigned at both the user and responsibility level.

Example: If you want to restrict the user Jane with responsibility of 'Admin' to see only those rows where
customer_id = 1000 then assign the securing attribute ICX_CUSTOMER_ID to the responsibility 'Admin' then the
securing attribute ICX_CUSTOMER_ID and value of 1000 to the user, Jane.

Navigate to: Security > Responsibility > Define

Select: Securing Attributes

Securing Attributes> Select an attribute from the LOV to be used to determine which records
Attributes: this user can access.

Securing Attributes> Oracle Self-Service Web Application

Application:

Excluding Attributes
Excluding Attributes allow columns of data to be visible to specified users or responsibilities. Excluding Attributes
must be assigned at the responsibility level.
Example: If you want to restrict the user Jane with responsibility of 'Admin' from seeing prices in the ICX_PRICE
column, then assign the excluding attribute ICX_PRICE to the responsibility 'Admin'.

Navigate to: Security > Responsibility > Define

Select: Excluded Items

Excluded Items> Name: Select an attribute from the LOV to be excluded from the users access.

Excluded Items> Oracle Self-Service Web Application. (Auto-Completion)

Application:

Assign request group to a responsibility

Overview
Request Groups are used to control access to a group of requests. Use the System Administrator Responsibility to
define Request groups. There are two types of request groups used by Oracle Applications at two different levels:

Responsibility Level: Used to control access to reports, request sets, and concurrent programs for a particular
responsibility. A request group assigned to a responsibility is referred to as a Request Security Group. A request
security group is a collection of requests, request sets, and concurrent programs that users who have been
assigned a given responsibility can run.
Form Level: A request group is assigned a code, which is passed as a parameter to the Submit Requests
Window. The code helps define the function that calls the Submit Requests Window.

Note: Form Level Security Groups are not covered in this document at this time.
Define Request Group (Responsibility Level)

Navigate to: Security>Responsibility>Request

Group: Enter a unique name for the request group you are defining.
Application: Select the name of the application you wish to associate with your
request group from the LOV. This does prevent you from assigning
requests, request sets, and programs from other applications to this
group.

Note: It is recommended that you define a custom application and

assign to your custom request groups in order to protect them during an
upgrade.
Code: Assign a code to this request group if customizing the standard Submit
Requests window using codes in order to control user access to
concurrent programs and reports versus limiting access at the
responsibility level.
Description: Optionally enter a description of the Request Group.
Type: Choose Program, Application, or Set
Name: Choose the name of the program, application, or request set you want to
include in this group from the LOV.

Assign Request Group to a Responsibility

Query the responsibility you would like to assign your request group to

Navigate to: Security>Responsibility>Define

Request Group>Name: Choose a request group from the LOV.

Create value sets and assign values to value sets

Overview
This document explains how to define custom value sets. Use the System Administrator Responsibility.

Define Value Sets

Navigate to: Application>Validation> Set

Value Set Name: Enter a unique name for this value set.

Note: It is recommended that a naming convention for the value set

 names be established. A value set name should be all one case (upper or
lower) and no spaces (use underscores in place of spaces (_)). All custom
value set names should be preceded by a unique prefix to protect your
value sets during an upgrade. For instance all IVAS custom value set
names are preceded with IVAS (IVAS_CUSTOM_VALUE_SET).
Description: Optionally enter a description for your value set.
Security Available: If you are planning to use flexfield value security with any segments that
use this value set, check this box. If your value set is of validation type
None, Special, or Pair leave this box unchecked.
Enable Longlist: If you think your value set will contain a large number of values then
check this box so a user must enter a partial segment value before the list
of values retrieves all available values. If your validation type is None
leave this box unchecked.
Format Type: From the drop down list select the type of data format you want to use
for your values. Valid format types are: Char, Date, DateTime, Number,
Standard Date, Standard DateTime, and Time.
Note:
Date and DateTime value set formats will be obsolete in Release 12
and are only provided for backward compatibility. Use Standard
Date and Standard DateTime for new value sets.
Translatable Independent and Translatable Dependent value sets
must have the Char format.
Maximum Size: Specify the longest value that can be entered into a segment that uses this
value set. This will also be the longest display size you can specify then
you define your report parameter or flexfield segment. For report
parameters, the maximum size you can use is 240. For Translatable
Dependent and Translatable Independent value sets, the maximum is
150.
Caution: When using a validation type of Table make sure the
maximum size you select here reflects the size of the column you
specify as your value column.
Precision: Use to round numbers for value sets with numerical values.
Numbers Only (0-9): This is a character formatting option restricting users to enter only the
values 0-9, minus signs, and periods. Your values will behave and sort as
character values. To restrict users from entering negative values enter a
minimum value of 0, however this does not restrict users from entering
numbers with decimals.
Note: This option cannot be used with translatable value sets.
Uppercase Only: This is a character formatting option that automatically changes
alphabetic characters to uppercase. Caution: When using a validation
type of table check that the table values are in uppercase before selecting
this option.
Right-justify and If you want to have characters 0-9 automatically right-justified and zero-
Zero-fill Numbers: filled select this option. This option has no effect on values that contain
alphabetic characters or special characters such as a period or a hyphen.
Caution: If you have defined a five-character value set, and you define a
value of 9, the value will be stored as 00009. However, if you have
defined your segment's display size to be less than the maximum size
and you select this option, your users will see the zeroes (display size)
and will have to scroll to see the 9 making data entry less efficient.
 Note: This option cannot be used with translatable value sets. Oracle
recommends using this option for value sets used with the Accounting
Flexfield only.
Min Value: Optionally enter a minimum value a user can enter in a segment that
uses this value set.
Max Value: Optionally enter a maximum value a user can enter in a segment that
uses this value set. The maximum value cannot be longer than the
maximum size specified for this value set.
Validation Type: Select the validation type you want to use for this value set from the
drop-down list. Valid validation types include:

None: Values are not validated. Users will not have a list of values to
select from if you choose this validation type.
Table: This validation type is a table-validated value set with a
predefined list of values from an application table. You can limit the
values included in a table-validated value set by using a WHERE
clause.
Special: This validation type allows for a 'flexfield-within-a-flexfield'
functionality. It is primarily used for Standard Report Submission
parameters using validation routines you define to provide another
flexfield as a value set for a single segment.
Pair: This validation type is similar to a Special validation type
allowing 'flexfield-within-a-flexfield' functionality. It is used for
Standard Report Submission parameters using validation routines
you define to provide a range flexfield as a value set for a pair of
segments
Independent: This validation type provides a predefined list of
values for a segment.
Dependent: A dependent value set is similar to an independent
value set except that the values available depend on the independent
value chosen in a prior segment.
Translatable Independent: Similar to an independent value set
except the value may be translated.
Translatable Dependent: Similar to a dependent value set except the
value may be translated.

Note: Always define independent value set before dependent value set.

Example: Value Set A is an independent value set containing two values,

Computer and Monitor. Value Set B is a Dependent value set containing
four values, Compaq, Dell, 13" and 15". For value set B the values
Compaq and Dell will appear in the list of values only if Computer was
chosen for value set A. 13" and 15" would appear in the list of values for
value set B if Monitor was chosen for value set A.
.
Validation Information
If using a validation type of Table, Dependent, Translatable Dependent, Special, or Pair, you will need to supply
additional validation information.
Table Validation
Choose a table in the Oracle Applications that contains the valid values for your value set.
Create a WHERE clause to limit the values you want to use for your set.

Navigate to: Application>Validation> Set

Select: Validation Type>Table
Select: Edit Information

Table Application: From the LOV select the application that the validation table belongs to.
Note: If you are going to display columns from more than one table in
your LOV, you should leave this field blank.
Table Name: Enter the table you want to use to validate your value set. If you plan to
display columns from more than one table then enter multiple tables in
this field separated by commas. If you want to use table aliases then
enter them here.
Example: ra_customers rac, ra_addresses_all raa

Note: If you want to use a custom table then you must do the following
prior to navigating to this form:
Create the validation table in the database
Register the table with the Oracle Application Object Library
Create the necessary grants and synonyms.
Allow Parent Values: Select this option if you want to allow parent values.
Value Name: Enter the name of the column in your validation table that contains the
values you want to use to validate a value entered for a segment or
report parameter. You can also use a SQL expression in place of a column
name but you cannot use bind variables.

Note: If you specified a format type of Number then you can only specify
 columns that have been defined as a Number or Char format. For a
format type of Date you can only specify columns of type Date and Char,
for a format type of Char you can only specify columns of type Char.
Value Type: This field will be automatically populated with the data type of the
column you selected. If you use a SQL expression in place of a column
name then you must select the value type you expect the expression to
return.
Size: This field will be automatically populated with the size of the column
you selected. If you use a SQL expression in place of a column name then
you must select the value type you expect the expression to return.
Meaning Name: Enter the name of the column in your validation table that contains
descriptions for your values. If you leave this field blank, the value set
automatically uses the value column as the description but leaves this
field blank.
ID Name: Enter a name of the column in your validation table that contains values
you want to use to validate a value but that you do not want to display.

Note: If you select a column other than the value name selected above
the report parameter window passes this value to your report. For
flexfields this value is stored in your segment column rather than the
value name identified above.
Where/Order By: Enter a SQL WHERE clause and/or an ORDER BY clause. You can use
special bind variables here:

:$FLEX$.Value_Set_Name
:block.field (used for backward compatibility only)
:$PROFILE$.profile_option_name
Additional Columns: Enter any additional columns you want displayed for a segment that
uses this value set.

Syntax: column_name "Column Alias" (width). Where width is optional.

You can use an asterisk (*) to specify a column whose display width
depends on the values it contains.

Note: Multiple columns should be separated by commas.

Special/Pair Validation
Create special validation routines for value sets of type Special or Pair.

Navigate to: Application>Validation> Set

Select: Validation Type>Special or Validation Type>Pair
Select: Edit Information
Event: Specify the event at which your special validation routine should fire.
Valid events include:

Edit: Calls the special validation routine when your user's cursor
enters the segment in a data entry mode.
Validate: Calls the special validation routine when the user's cursor
leaves the segment or closes the pop-up window, or when a default
value is copied into the segment or report parameter. It also fires after
a query to generate value descriptions for queried values.
Load: Calls the special validation routine immediately after a query
to populate your segment.
Note: The following events are present in Oracle Applications for
compatibility with future versions, and you should not use them.
Insert/Update
Query
Edit/Edit
ListVal
Function: Enter your user exit syntax exactly as you would call it from a form
trigger, except you do not need to include the # sign.

Dependent Validation
Associate your dependent value set with an independent value set

Navigate to: Application>Validation> Set

Select: Validation Type>Dependent or
Validation Type> Translatable Dependent
Select: Edit Information
Independent Value Enter the name of the independent value set the value set depends on.
Set>Name: Note: The independent value set must have been pre-defined
Independent Value Automatically populated with the description of the independent value
Set>Description: set.
Dependent Default Enter a default value for your dependent value set.
Value>Value:
Dependent Default Enter description for dependent value set default value
Value>Description:
Assign Values to Value Sets
You can skip this step unless your value set is of type Independent, Translatable Independent, Dependent, or
Translatable Dependent. Also, if your value set is of type Table and you have defined your value set to allow parent
values, then you can use this window to define parent values for the values in your table.

Note: You must define independent values before related dependent values.

Independent Value Set

Navigate to: Application>Validation>Values

Name: The name of your Independent value set will appear here.
Dependent Value Set: Leave blank
Independent Value: Leave blank
Value: Enter the values you want to assign to this independent value set.
Description: Enter a description for this value.
Enabled: Select this option to enable the value. Values cannot be deleted so if you
do not want users to select this value any longer then deselect this option
or enter an end date.
Effective From: Optionally enter a start date for when this value becomes active.
Effective To: Optionally enter an end date for when this value becomes no longer
active.

Dependent Value Set

Navigate to: Application>Validation>Values
Name: The name of Independent value set on which the dependent value set
depends, will appear here.
Dependent Value Set: If a dependent value set is assigned to your independent value set it will
automatically appear here.
Independent Value: If your independent value set has a dependent value set assigned to it
then enter an independent value here then in the next step enter the
dependent values you want to assign to this independent value. Once
you have entered all the dependent values (done in next step) you want
associated with this independent value then hit the arrow down key to
enter another independent value and proceed with entering the
dependent values you want to assign to this independent value.
Continue with this procedure until you have assigned dependent values
to all of your independent values.
Value: Enter the dependent values you want associated with the independent
value specified above.
Description: Enter a description for this value.
Enabled: Select this option to enable the value. Values cannot be deleted so if you
do not want users to select this value any longer then deselect this option
or enter an end date.
Effective From: Optionally enter a start date for when this value becomes active.
Effective To: Optionally enter an end date for when this value becomes no longer
active.

Naming Standards
File Names and Extensions
File names must not exceed 8 characters and the first three letters represent the Module Name.
In the file name wherever English alphabet letters are used they should be in UPPERCASE.
File Name should not contain any special characters i.e. , -, $, %, #, @, * and others.
 Program Type Directory File Type Extension
PL/SQL sql Package specification Pks
Package body Pkb
SQL*Plus sql SQL script Sql
Spool file Lst
install/sql Install script Sql
SQL*Loader bin Control file Ctl
Data file Dat
Log file Log
Error file Err
Discard file Dis
UNIX bin Shell Script Sh
SQL*Forms 4.5 or 6.0 forms Binary Fmb
Executable Fmx
Source Fms
SQL*Forms 2.3 or 2.4 forms Executable Frm
Source Inp
Oracle Reports 2.0, 2.5 or 6.0 srw Binary Rdf
Executable Rpt
Source Rex

Please note the custom objects need to be prefixed with the following to clearly define the module:-

CFI Financial
CMF Manufacturing
CSA Sales Administration
CCO Conversion

For a given design, there will be one and only one MOD number -even though it may contain package
procedures, SQL scripts, SQL*forms and Oracle Reports. MOD numbers must be unique across modules.

Nomenclature
Module Prefix + Mod Number
Example
CFI0001 Mod 1 is for Finance
CMF0002 Mod 2 is for Manufacturing
CSA0003 Mod 3 is for Sales Administration
CMF0004 Mod 4 is for Manufacturing

A MOD may have multiple objects of the same type, therefore suffix the object with an English letter
(A through Z).
Nomenclature
Module Prefix + Mod Number + Letter

Example MOD CFI0001 may comprise of the following:

CFI0001a.frm SQL*Forms
CFI0001b.frm SQL*Forms
CFI0001a.sql SQL*Script
 CFI0001.b.sql SQL*Script
CFI0001a.pks Package Specification
CFI0001a.pkb Package Body

A database schema can be composed of various objects i.e. tables, indexes, sequences, views, synonyms,
procedures, triggers, packages, functions and database links. Please ensure the following naming
convention is followed:

Object name can be a maximum of 30 characters long. Please reserve the first three characters to identify the
application. The naming convention should facilitate in distinguishing the objects. The norm to adopt is as
follows:
Object Type Standard Meaning Example
Table 30 characters long CSA_SO_HEADERS
Index Xn X=(U)nique or (N)on-Unique CSA_SO_HEADERS_U1
n=Index Sequence Number
View V V = View CSA_SO_HEADERS_V
Sequence S S = Seqeunce CSA_SO_HEADERS_S
Trigger XIUD_TRG X=(B)efore or (A)fter CSA_SO_HDRS_BIU_TRG
I=Insert/U=Update/D=Delete
TRG=Trigger
Package PK or PB PK=Package Specification CSA_SO_HDS_PK
PB=Package Body CSA_SO_HDS_PB
Function FNS FNS=Functon CSA_SO_HDS_FNS

Object name should not contain any special characters i.e. , -, $, %, #, @, * and others.
Object name should begin with an alphabetic character and may contain underscore.
Object name nomenclature should be self explanatory, having a meaningful name that is understandable
by the end users and IS groups.

Table
The sequential order in which the columns need to be defined are:
Primary key columns
WHO columns
Mandatory columns
Optional columns
Long field column
To be created under the Custom Schema, with necessary grants to APPS schema
The table name should be plural.
Use the constraint/default definitions and referential integrity definitions for the columns of the table.
Ensure that the columns are classified as NULL or NOT NULL. By default the column definition is
NULL.
Ensure that the WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY,
UPDATE_DATE, LAST_UPDATE_LOGIN, REQUEST_ID) exist.
If the data to be stored in the table is partitioned on the Operating unit then a ORG_ID column with the
default definition must exist.
Ensure that a primary key exists with a NUMBER data type.
Use the following data types to qualify a column in a table VARCHAR2, NUMBER, DATE, BOOLEAN,
LONG.
Whenever appropriate qualify the column definition to denote its purpose i.e.
 _FLAG
_CODE
_TYPE
_DATE
_NAME
_ID
_VALUE

View
View on a partitioned table needs to be created in the APPS schema. Use the WHERE CLAUSE within
the view definition to dynamically partition the data on user access.

Package Procedures/Triggers/Functions
Package Procedures/Triggers/Functions to be created in the APPS schema.

Define objects with respect to the schema as follows:

Schema Object
Custom Table
Custom Index
Custom Sequence
Custom Grants
APPS Synonyms
APPS Views
APPS Package Procedures/Functions/Triggers
APPS Links

Programming Standard for PL/SQL routines

The PL/SQL packages or code written must be modular and structured. Avoid the use of GO TO etc
Define packages and procedures, anonymous PL/SQL procedure definitions are not acceptable. The
package specification and body in the same file with extension pls.
Reserved words and key Oracle words to be Capitalized
SELECT
FROM
WHERE
Source code indentation is essential.
Database trigger size to limit to 60 lines of code. If the logic of the trigger is more than 60 lines it is better
to create a PL/SQL package and call it from the trigger. PL/SQL package is stored in the database and is
already in a compiled state. Also as the package can be pinned the execution time is faster.
Avoid triggers that duplicate the functionality already built in Oracle (example enforce data integrity by
using declarative integrity constraints rather than a DB trigger)
Within a trigger DDL statements are not allowed. Also no transaction control statements are allowed in
a trigger (ROLLBACK, SAVEPOINT, COMMIT).
Extensive comments need to be incorporated into the code.
Initialize the variables prior to use within the source code.
INSERT statement needs to specify the fields and values.
INSERT INTO TABLE table_name
(field1,
field2,
field3)
VALUES
 (value1, --field1
value2, --field2
value3); --field3

Variable declarations
Variable to have a meaningful name and to be initcap. Variable to be prefixed with v
vOrderNumber
vOrganizationId
vInventoryItemId
Variable data type declaration to be associated to appropriate schema.object.field
vOrganizationId mtl_system_items.organzition_id%TYPE;
vInventoryItemId mtl_system_items.inventory_item_id%TYPE;

Cursor Definitions
Cursor to refer to object name(s) on which it is defined and to be initcap. Cursor to be prefixed with
Cur
Use aliases to uniquely identify the fields
CURSOR CurSoHdrLns IS
SELECT a.order_number order_number,
b.inventory_item_id inventory_item_id
b.warehouse_id warehouse_id
FROM so_lines a
so_headers b
WHERE a.header_id = b.header_id;

Ensure the driving table in all SELECT statements is last in the FROM clause
Ensure for every OPEN CURSOR statement there is a corresponding CLOSE CURSOR statement.
Wherever possible use FOR Record in Cursor LOOP rather than OPEN CURSOR statement
In order to debug the PL/SQL package use the DBMS_OUTPUT routine. You may need to SET
SERVEROUTPUT ON SIZE 1000000 to generate the output. Note the output is generated after the
package completes or terminates with an error. For a given session the DBMS_OUTPUT buffer is not
cleared. Do not use the routine to generate flat files or reports.
Do not include explicit commits within the package. In case the package requires processing of records
that can create rollback segment problem, please put commits at logical transaction points with
SAVEPOINT and ROLLBACK functions.
The PL/SQL design to take into account how to re-commence a terminated job, and not re-process the
processed records unless there is an explicit requirement.
Latest version provides a facility to output to a flat file
Instead of incorporating the programming logic in the Trigger or an Alert it is better to write the logic as
a package procedure. The advantage is the package is compiled, parsed and stored in the database and
therefore it requires primarily to fetch and execute.

Exception Handling
Ensure that at least the following exceptions are handled in the PL/SQL constructs
NO_DATA_FOUND
TOO_MANY_ROWS
OTHERS
The error number must contain the mod number + the sequence of exception.
Please use the ERRBUF and ERRCODE parameters as an output. They must be the first two parameters
in the PL/SQL package

It is advisable to maintain a central repository/library of PL/SQL packages with the small description. This
library may comprise packages called from different routines. You need to ensure nobody modifies the
shared package procedure. Also if time permits the packages may be defined and developed to be generic
in nature, which will enhance the library.

Programming Standard for Oracle Forms

Use the TEMPLATE form to develop new forms. The template exists in $FND_TOP/forms/US. The
template includes the following:-
Library Purpose
FNDMENU master copy of the shared objects
APPSTAND $AU_TOP/resource - library of utilities
FNDSQF AOL utilities
APPCORE Control Menu/Tool bar
APPDAYPK library of calendar

Ensure all BUTTONS in Oracle Application look and behave the same
Ensure all BUTTONS in Oracle Application use BUTTON Property Class
Define Property Class and include in the Object Group
Apply the Property Class to objects to ensure uniformity in the functionality and visual appearance
Build forms based on the View definitions. The first column in the view should be the ROWID and be
given the alias name of ROW_ID.
De-normalize the Foreign Key references by building views, this will avoid network traffic and make the
PRE-QUERY and POST-QUERY triggers to populate the non-database fields redundant
In order to insert/update/delete call the ON-INSERT, ON-UPDATE, ON-DELETE, ON-LOCK triggers
to access the base table rather than the view
Correction and enhancements on view will be at the server level rather than in several source code
which may or may not reside on the server
Do not use the ROOT_WINDOW, as it affects the toolbar functionality
When defining the MODAL WINDOW (e.g. dialog box) code the logic for OK and CANCEL
buttons in advance. If not done, as the key triggers and menu is disabled on invoking the modal
window, there will be no way to exit the form.
Modify the template procedures APP_CUSTOM.OPEN_WINDOW or
APP_CUSTOM.CLOSE_WINDOW to meet the requirements on opening or closing a form
Try writing package procedure and store in the server. Number of procedures to a package
recommended by Oracle to be less than 25
While referencing a field on the form qualify it with the block name :BLOCK_NAME.FIELD_NAME
Use explicit cursors in triggers and handle all possible exceptions
Use RAISE_FORM_TRIGGER_FAILURE to stop processing at the client level
Use APP_EXCEPTION.RAISE_EXCEPTION to stop processing at the server level
CALL_FORM routine is in-compatible with OPEN_FORM
To exit Oracle Application suite, copy Y to GLOBAL.APPCORE_EXIT_FLAG, and then call the
DO_KEY_EXIT_FORM
Use APP_ITEM_PROPERTY.SET_PROPERTY and APP_ITEM_PROPERTY.SET_VISUAL_ATTRIBUTE
to get the Oracle Application standard behavior
Use APP_ITEM_PROPERTY.GET_PROPERTY to get Oracle Application specific property
Replace OPEN_FORM with FND_FUNCTION.EXECUTE as security depends on the latter
Replace CLEAR_FORM with DO_KEY(CLEAR_FORM) as the latter raises the
FORM_TRIGGER_FAILURE if there is an invalid record
Replace COMMIT with DO_KEY(COMMIT_FORM) as the latter raises the FORM_TRIGGER_FAILURE
if there is an invalid record
 Replace EDIT_FIELD/EDIT_TEXTITEM with DO_KEY(EDIT_FIELD) as the latter raises the calendar
when the current item is a DATE
Extensive comments are recommended

Triggers Must be modified

PRE-FORM
WHEN-NEW-FORM-INSTANCE

Triggers that can be modified, but do not delete the APP_STANDARD.EVENT call within the respective
triggers
KEY-CLRFRM
POST-FORM
QUERY-FIND
ACCEPT

Triggers that can be overridden at the BLOCK and ITEM level

KEY-DUPREC
KEY-MENU
KEY-LISTVAL
WHEN-NEW-RECORD-INSTANCE
WHEN-NEW-BLOCK-INSTANCE
WHEN-NEW-ITEM-INSTANCE
QUERY-FIND
ACCEPT
ON-ERROR

Do not modify the following triggers

STANDARD_ATTACHMENTS
ZOOM
FOLDER_ACTION
KEY-HELP
KEY-EXIT
KEY-EDIT
KEY-COMMIT
WHEN-WINDOW-CLOSED
CLOSE_WINDOW
Please ensure to populate the WHO columns
Store the logic for setting the WHO columns in PRE_INSERT and/or in the PRE_UPDATE event triggers
Call standard FND_STANDARD.SET_WHO routine in the trigger to set the WHO values
Column Name Type Value Derivation
CREATED_BY Not Null TO_NUMBER(FND_PROFILE.VALUE(USER_ID))
CREATION_DATE Not Null SYSDATE
LAST_UPDATED_BY Not Null TO_NUMBER(FND_PROFILE.VALUE(USER_ID))
LAST_UPDATE_DATE Not Null SYSDATE
LAST_UPDATE_LOGIN TO_NUMBER(FND_PROFILE.VALUE(LOGIN_ID))
REQUEST_ID FND_CONCURRENT_REQUESTS
PROGRAM_APPLICATION_ID FND_CONCURRENT_PROGRAM
PROGRAM_ID FND_CONCURRENT_PROGRAM
PROGRAM_UPDATE_DATE PROGRAM_UPDATE_DATE
 Call flexfield definition in WHEN-NEW-FORM-INSTANCE trigger
FND_KEY_FLEX.DEFINE is for key flexfield
FND_RANGE_FLEX.DEFINE is for range flexfield
FND_DESCR_FLEX.DEFINE is for descriptive flexfield
While calling a flexfield definition ensure tp specifiy the BLOCK and FIELD
Also pass the following parameters i.e. APPL_SHORT_NAME, flexfield CODE and structure NUM, if it
is a key flexfield else APPL_SHORT_NAME and DESC_FLEX_NAME for descriptive flexfields
Flexfield can be invoked from several form level triggers by calling FND_FLEX.EVENT
Use standard FND_MESSAGE routines to display and retrieve messages

Programming Standard for Oracle Reports

Ensure that no logic exists in the AFTER PARAMETER FORM. If the logic exists, then move it to the
BEFORE REPORT TRIGGER. The logic should be incorporated after the call to SRWINIT function
Include the SRWINIT in BEFORE REPORT TRIGGER
Include SRWEXIT in AFTER REPORT TRIGGER
Include P_CONC_REQUEST_ID in the User Parameters
In order to debug the report use the SRW.MESSAGE routine
Avoid any data manipulation (DML) within the report
Instead of writing extensive logic within the report, write a PL/SQL Package and call it within the
report. The advantage is maintenance becomes simple and the same routine may be used by other
programs.

SQL*Loader
The basic SQLLOAD command is
SQLLOAD
USERID = Oracle Username/password
CONTROL = Control file name
LOG = Log file name
BAD = Bad file name
DATA = Data file name
DISCARD = Discard file name
DISCARDMAX = Number of discard allowed default is ALL
SKIP = Number of records to skip default is 0
LOAD = Number of records to load default is ALL
ERRORS = Number of errors allowed default is 50
SILENT = Suppress messages during run

Data Load OPTION

The data load can either be for a fixed length or variable length record. Depending upon the format the
loading may have explicit or relative positioning method.

INSERT - requires the table to be empty

REPLACE - deletes the rows and inserts new data
APPEND - appends data to the existing data in the table

Assembling Logical records from Physical Records

One logical record may be created and loaded from multiple physical records by using the following:-

CONCATENATE
 CONTINUEIF

Generating Data
The data may be generated and inserted into the table column by calling one of the functions within the
SQL*Loader script CONTROL file:-

CONSTANT - set the column to a constant value. Do not use to assign NULL to a column. To set a
column to NULL do not specify the column
RECNUM - sets the column with the logical record number from the load. The initial value from a new
load is 1. If the Option SKIP is used then the RECNUM begins with SKIP+1 as the initial value
SYSDATE - sets the column to system date. The CHAR column only stores the date whereas the DATE
column stores date and time
SEQUENCE - Ensures a unique value for a column. Please note that sequence increases for loaded or
rejected records but does not increase for the discarded or skipped records

Setting a Column to NULL or ZERO

NULL or Zero value may be inserted into the table column by calling one of the functions within the
SQL*Loader script CONTROL file:-

DEFAULTIF use the keyword to set the column to zero when specified field test condition is TRUE
NULLIF use the keyword to set the column to null if when the specified field test condition is TRUE

Apply SQL Operators

You may apply SQL operators to manipulate the field data while loading into the table. Note the following:-

To refer to the field name preceed the field name with a colon (:)
SQL string to be enclosed in double quotes
SQL string is evaluated after the NULLIF and DEFAULTIF clause but before the DATE format mask
SQL strings may not be used on RECNUM, SEQUENCE, CONSTANT, SYSDATE fields
SQL operators that may be used include
LOWER
RTRIM
LTRIM
TRANSLATE
DECODE
SUBSTR
TRUNC
NVL
TO_DATE
TO_CHAR

Utilities to Debug, Trace and Tune

DBMS_OUTPUT.PUT_LINE in PL/SQL
FND_MESSAGE in Oracle Forms
SRW.MESSAGE in Oracle Reports
EXPLAIN /PLAN in SQL*Plus
TKPROF for trace files from the Operating System
Do not perform a function on the table field that is being used in the WHERE clause of a SELECT
statement. This may hit performance, if an index existed on the field
SELECT order_type
 FROM so_headers
WHERE order_number = TO_NUMBER(Parameter)
To understand the meaning of the ORA error messages, you may go to the Operating System prompt
and type in the following:-
Prompt> oerr ora error_message_number
It is recommended to use the EXIST function than the IN function while using correlated/sub-queries.

Registering Concurrent Programs

Concurrent Executable/Programs
Same as execution file name in uppercase.
Example: CFI0001a

DefineConcurrent Program

Name must have INITCAP i.e. all words must have the first letter in upper case. The name must contain
the prefix to identify the module.
Example: CFI AP Invoice Print

Short Name must be the same as the executable name. If the same executable is being used for more than one
concurrent program, then use underscore and number as suffix.
Example: CFI0001a_1
CFI0001a_2

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 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.

Directory Structure
The directory structure for an installed product is as follows:

$APPL_TOP
|
<product short name>
|
<product version>
___________________________ |___________________________
| | | | | | | | |
admin bin conversions forms log out reports sql wf
| |
_________________________ ______
| | | | | | |
aropen coa customers fa pricelist wft sql

The directory structure for the custom development objects is as follows:

 $APPL_TOP
|
(CUSTOM NAME) $(CUSTOM NAME)_TOP
|
1.XX
___________________________ |___________________________
| | | | | | | | |
admin bin conversions forms log out reports sql wf
| |
_________________________ ______
| | | | | | |
aropen coa customers fa pricelist wft sql

The product short name is a two to eight character abbreviation of the product (i.e. GL, PO, INV, etc.). The short
name for Rapid Oracle Implementation custom applications will be (CUSTOM NAME).

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.

Creating a Custom Application

You must register the (CUSTOM NAME) application before you can begin developing custom modules. The steps
to register a new application are:

Create the directory structure

Modify $APPL_TOP/APPLSYS.env to set the environment variable $(CUSTOM NAME)_TOP and add
$(CUSTOM NAME)_TOP/bin to the PATH environment variable.
Example:
(CUSTOM NAME)_TOP=$APPL_TOP/(CUSTOM NAME)/2.1.0
export (CUSTOM NAME)_TOP
PATH=$PATH:$(CUSTOM NAME)_TOP/bin
Export PATH
execute the APPLSYS.env file.
Select Application Developer responsibility and register the application.

Custom Tables
New tables required by your custom programs should be created in an Oracle user created exclusively for
customizations. For convenience, it should match the application short name of your custom application
((CUSTOM NAME)). Grants and synonyms will allow other Oracle users to access your custom tables.

To access custom forms exclusively, you must register the custom Oracle ID (CUSTOM NAME) in the Application
Object Library. If custom forms will be accessed from responsibilities that also access standard forms, simply create
grants and synonyms so that the Oracle user associated with the responsibility can access the custom tables.
Your Development Account
The development account will be given the username of (CUSTOM NAME) to conform to (CUSTOM NAME)
standards. While individual programmers and analysts may own code in development, the UNIX (CUSTOM
NAME) account will be the owner of all completed custom code.

Custom development should be done within a Korn shell with Korn shell scripts and PL/SQL scripts being the
tools of choice for data processing.

You should develop and test custom modules under the $(CUSTOM NAME)_TOP portion of the directory tree. If
they have not been previously created, you may have to create the directories: admin, bin, conversions, forms, log,
out, reports, sql, and wf (log and out can be soft links to the actual log and out directories).

Building Your Programs

Develop and test your programs from within your local directories. Follow the instructions in the reference manual
of each Oracle tool you plan to use to insure your environment is properly initialized.

When modifying or creating forms, it is not necessary to save them to the database. Instead use the LOAD and
GENERATE options of SQL*Forms 6.0 to read and write the source code file directly. Also, your form cannot be
saved to the database when you register it with Application Object Library.

Any text editor can be used for C programs, SQL*Plus, and PLSQL programs. The vi editor will be used because it
comes standard with UNIX.

Registering Your Programs

Follow the instructions in the Application Object Library Developer's Reference Manual to register your forms and
programs. All programs must be registered in order to be attached to menus or executed in the concurrent
manager. Once a concurrent program or report has been registered it does not need to be reregistered after a
modification. Forms only need to be reregistered if you add, delete, or change the order of fields or zones.

Customized Code and Objects Registering

Objective :
To keep the standard Oracle Applications objects separate from the custom objects.

Procedure:
To create the work tables required in the customization process under Oracle ID (CUSTOM NAME). The naming
convention described in the naming convention standards section of this document should be followed. All custom
objects should be moved to the custom $(CUSTOM NAME)_TOP directory. There are sub-directories for all of the
object types.

All custom objects i.e. tables, menus, reports, forms, views, and sequences should be registered under '(CUSTOM
NAME) Custom Application' application name. This is done for Database and Form objects through the
Application Developer Responsibility.

Custom reports will appear in the Application in the same screen as the Standard reports, but the code will reside
in $(CUSTOM NAME)_TOP directory. When a existing standard report requires modification, a clone of the report
should be made. The new report should then be renamed with a (CUSTOM NAME) - naming convention. The
(CUSTOM NAME) title will help identify the report as custom report.

Following are the steps for the same.

1.Register concurrent program executable under '(CUSTOM NAME) Custom Application' application. See the
document

2. Register the program under the '(CUSTOM NAME) Custom Application' application.

1. Add the modified or custom program to a request group. See the document AOL
Request Groups Setup for additional information.
The output of the report and the log will be created in the regular application's $OUT and $LOG directory.

To register Tables navigate to Application>Database>Table>Register under the Application Developer

Responsibility.

To register a Form navigate to Application>Form under the Application Developer Responsibility.

To register a Menu navigate to Application>Menu under the Application Developer Responsibility.

Custom Object Access
To enable other Oracle IDs to access custom objects; tables , views and sequences registered under (CUSTOM
NAME), a script will need to be developed to create synonyms and grants. There are two primary methods for
executing custom objects. The following describes the two methods.

Option 1 is preferred because it reduces the number of synonyms and grants that need to be established.

Option 1:
To execute a custom form, report, or concurrent program from the standard oracle applications it is necessary to
assign the application name '(CUSTOM NAME) Custom Application' to the custom form, report, or program.
Synonyms need to be created under the particular standard Oracle ID to allow access to the (CUSTOM NAME)
Custom Application objects. Grants need to be created under the applications (CUSTOM NAME) Custom
Application ID to allow access to the specific standard Oracle ID.
R2i Custom Application Standard Oracle Applications

Source Code under Standard Oracle

$R2I_TOP directory Applications

Register Tables,
Create synonyms for
Views, Sequences
the objects created
Forms, Reports and
under oracle Id R2I
Concurrent Programs

Create Tables, views,

Give grants to
sequences under
Applications Oracle Id
Oracle Id R2I

Enter the Application

name as R2i Custom
Application under
Standard Applications
Menu

Option 2:
To execute customized code from the (CUSTOM NAME) Custom Application,
Synonyms need to be created under the applications (CUSTOM NAME) Custom
Application ID to allow access to the specific standard Oracle objects. Grants need to
be created under the particular standard Oracle ID to allow access to the (CUSTOM
NAME) Custom Application ID.
 R2i Custom Application Standard Oracle Applications

Source Code under

$R2I_TOP directory

Register Tables,
Views, Sequences
Forms, Reports and
Standard Oracle
Concurrent Programs
Applications

Create Tables, views,

sequences under
Oracle Id R2I Give grants to
Applications Oracle Id

Create Synonyms for

th objects used in
customization under
Oracle Id R2I

Create different
Responsibility for each
application in which
customization is done

Naming Standards
A database schema can be composed of a variety of structures, generically referred to as objects.

The term "objects" as used in this document, refers to any of a variety of user defined structures within the database
such as, tables, views, synonyms, indexes, stored procedures, etc.
General Rules for Object Naming
The following set of rules apply broadly to all objects within the database. Specific types of objects may have
additional limitations imposed, but should share these common characteristics. In addition, Appendix "A" of this
document provides a list of standard abbreviations to be used whenever it is necessary to use abbreviations in an
object name.

Be 1 to 30 characters in length, ideally no more than 15 to 20 characters

Contain no embedded quotation marks
Not be case-sensitive
Begin with an alphabetic character
Only contain alphabetic characters and underscores (_)
Avoid the use of $ and # characters which although legal are generally reserved for
system level database tables and views
Be consistent and apply consistently across all objects within the schema
Be unique within the namespace or schema
Use the same name to describe the same entity or attribute across tables
Use full, descriptive, pronounceable names or well known "standard" abbreviations
Be brief but, avoid unnecessary abbreviations
Use standard abbreviations whenever necessary
Be end-user oriented providing a meaningful description of its usage

Database Table Naming

Database tables should follow the same standard set of rules as all objects in general, but also use the following
table specific conventions:

Be named using the plural form representing the notion of a set or collection -- e.g. USER_CONFIGURATIONS
not USER_CONFIGURATION
Begin with a unique application prefix of the form (CUSTOM NAME)_ to clearly
define and designate custom in-house tables or applications.

Database Column Naming

Column names also follow the standard set of rules applicable to objects although they are member names not
object names. The following column conventions provide consistency between the members of different objects
within the schema.

Be named using the singular form representing the notion of a single member of the set or collection representing
the table. e.g. CUSTOMER_NAME not CUSTOMER_NAMES.
Be consistent between tables clearly representing the keys to be joined and the
consistency of the values to be used.
Not use table name prefixes except for special circumstances. e.g.
CUSTOMER_NAME not CM_CUSTOMER_NAME for the column contained in the
customer master table.
 Use table name prefixes when part of the primary key. e.g. For an ID column in the
CUSTOMERS table use CUSTOMER_ID.
Use table name prefixes to allow proper foreign key relationships to maintain the
same name. e.g. This allows the use of the name CUSTOMER_ID in the ORDERS
table which may also contain an ID column of its own.

Domain Name Suffixes for Columns

Whenever appropriate, use suffixes on column names to denote the domain of the variable. For example, if the
column is in the domain of all codes and contains the status for an item, use the name STATUS_CODE instead of
the name STATUS.

Another frequently used example is the use of flags. A flag column contains a simple Y/N character value use the
domain suffix flag to represent this type of item. For example, a shipment confirmation flag containing either a 'Y'
or an 'N' would be named SHIP_CONFIRM_FLAG.

Some commonly used suffixes include:

_FLAG _CODE
_TYPE _DATE
_NAME _OWNER
_VALUE

Coding Standards
Specific coding and testing standards are well documented in other Oracle documentation. I have chosen not to
duplicate that information here. However, here are some major points to remember:
Use modular coding techniques
Use comments extensively. Always think about someone else reading your code.
Select a style for indentation, variable names, etc. and use it consistently.
Include meaningful error messages when your program encounters an exception
condition.
In spite of the use of REM in the following sample templates, /* and */ should be
used whenever possible to delineate comments.
Command syntax and keywords such as SELECT...FROM...WHERE should be
capitalized. Variable names should be in lower case. Comments should be in mixed
case. For example:
/* Test Code */
SELECT table_name
FROM user_synonyms
WHERE synonym_name like INV_%;

Using Templates
Establishing templates for common types of programs is a good way to standardize. Developers can copy standard
templates and may need to modify them to conform to (CUSTOM NAME) standards such as for program
comments and case-sensitivity.
SQL*Plus Concurrent Program Template
Included below is a template for concurrent programs written in SQL*Plus. This is a working template that will
print a simple report of organizations defined in Oracle Inventory. It implements the cosmetic standards
established for Oracle Manufacturing reports.

REM ==========================================================================+
REM Copyright (c) 20XX <Company Name> |
REM All rights reserved.
|
REM
|
REM ==========================================================================+
REM
REM PROGRAM NAME: XXXXXXXX (Explanation)
REM
REM PURPOSE: Sample concurrent report in SQL*Plus
REM
REM CALLING FORMAT:
REM Testing: sqlplus mfg/mfg @XXXXXXXX <org id>
REM Concsub: CONCSUB mfg/mfg MFG 'Oracle Manufacturing' MFGCON CONCURRENT
REM (CUSTOM NAME) XXXXXXXX <org id>
REM Forms: #FND CONCURRENT (CUSTOM NAME) XXXXXXXX <org id>
REM
REM CALLED BY: Oracle Manufacturing Form XXXXXXX
REM
REM HISTORY
REM DD MON YY First Last - Initial coding
REM
REM ==========================================================================
REM --- Get command line parameters
define org_id = '&1'
REM --- Set report dimensions
define report_width = 132
SET LINESIZE &&report_width
SET PAGESIZE 64
REM --- Define and set imbedded header variables
COLUMN today NEW_VALUE _sysdate NOPRINT
COLUMN organization_name NEW_VALUE _orgname NOPRINT
BREAK ON today
SELECT TO_CHAR(SYSDATE, 'DD-MON-YY HH24:MI:SS') today,
organization_name
FROM org_organization_definitions
WHERE organization_id = &&org_id
/
CLEAR BREAKS

REM --- Set title

define title = 'Sample Report'
define subtitle = ''
define lefttitle = ''

TTITLE LEFT _orgname RIGHT 'Date: ' _sysdate SKIP 1 -

LEFT '&&lefttitle' CENTER '&&title' -
RIGHT 'Page: ' FORMAT 99999999999999999 SQL.PNO skip 1 -
CENTER '&&subtitle' SKIP 2

REM --- Blank footer

BTITLE SKIP 0

SET HEADING ON
NEWPAGE 0
CLEAR COLUMNS

REM --- Column Definitions

COLUMN segment1 FORMAT A20 HEADING "Item"
COLUMN description FORMAT A30 HEADING "Description"
COLUMN category FORMAT A15 HEADING "Category"

REM --- Select statement

select ITEM.segment1,
ITEM.description,
CAT.segment1 category
from
mtl_categories CAT,
mtl_system_items ITEM
where
CAT.organization_id = &&org_id
and CAT.category_id = ITEM.category_id
and ITEM.organization_id = &&org_id
order by
ITEM.segment1
/

REM --- Print end of report footer

define end_report = '*** End of Report - &&title ***'
SET PAGESIZE 0
SELECT LPAD('&&end_report', (&&report_width + LENGTH('&&end_report'))/2)
FROM DUAL
/

Custom Programs
Overview
This document explains how to setup custom programs in Oracle Applications. In order to protect your custom
programs from upgrades it is recommended that you register a custom application and directory structure and
assign your custom programs to this application.

Executable Program
Build Executable Source File
Before registering your custom program you must first:

Write the program/report you wish to execute from the Standard Request Submissions window of the Oracle
Applications. You can write your executable source file by using any of the following methods:
Host Script
Oracle Reports
PL/SQL Stored Procedure
SQL Script
SQL*Plus Script
C or Pro*C Program

Move the execution files to their proper place on the operating system in use. The following table shows where
these execution files should be placed in a Unix environment:
Tool Ext. Directory
Sql*Plus & PL/SQL .sql $CUSTOM_TOP/$APPLSQL
Oracle Reports .rdf $CUSTOM_TOP/$APPLREP
Sql Loader .ctl $CUSTOM_TOP/$APPLBIN

Note: The program name is case sensitive and must exactly match the Execution file you defined previously.

Define Concurrent Program Executable

Define a concurrent program executable for each executable source file you want to use with concurrent programs.
Executables are defined to link the custom program to your executable source file.
Navigate to: Concurrent>Program>Executable

Executable: Enter a name for your concurrent program executable. (You assign this
name to your concurrent program.)
Short Name: Enter a short name for your concurrent program executable. (You assign
this name to your concurrent program.)
Application: From the LOV select the application you wish to associate with your
executable. The concurrent managers use this value to determine in
which directory structure to look for your execution file. It is
recommended that you define a custom application with its own
directory structure in order to protect your programs during an upgrade.
Description: Optionally enter a description for this executable.
Execution Method: From the drop-down list select one of the following execution methods:
Host: The execution file is a host script.
Oracle Reports: The execution file is an Oracle Reports file.
PL/SQL Stored Procedure: The execution file is a stored procedure.
SQL*Loader: The execution file is a SQL script.
SQL*Plus: The execution file is a SQL*Plus or PL/SQL script.
Spawned: The execution file is a stand-alone C or Pro*C program.
Immediate: The execution file is a program written in C or Pro*C to
run as a subroutine of the concurrent manager. Immediate programs
are linked with your concurrent manager and must be included in
the manager's program library, for this reason it is recommended that
you use either a PL/SQL stored procedure or a spawned C program
instead.
Request Set Stage Function: PL/SQL stored function that can be
used to calculate the completion statuses of request set stages.

Note: The execution method cannot be changed once you have assigned
the executable to a concurrent program.
Execution File Name: Enter the operating system name of your execution file. Do not include
spaces or periods (.) in the file name unless the execution method is
PL/SQL stored procedure or Request Set Stage Function.
 Note: The name entered here should match exactly with the file name, as
some operating systems are case sensitive.
Subroutine Name: If this is a C or Pro*C program subroutine then enter the name of the
subroutine program here. Do not include spaces of periods (.).

Stage Function Parameters

If your execution method is 'Request Set Stage Function' then select the Stage Function Parameters button to
enter parameters that your custom Stage Function uses.

Navigate to: Concurrent>Program>Executable

Select: Stage Function Parameters

Parameter: Enter a name for the parameter. The name you enter here will be
displayed in the Stage Functions Parameter window of the Request Set
form.
Short Name: Enter a short name that will be used by the function to reference the
parameter.
Description: Optionally enter a description of the parameter.

Concurrent Program
Define Concurrent Program
Navigate to: Concurrent>Program>Define
Program: Enter a descriptive name for your concurrent program. This is the name
users will see when submitting a request.
Short Name: Enter a short unique name. Oracle Applications uses this name to
associate your concurrent program with an executable.
Application: From the LOV select the application you wish to associate your program
with. It is recommended that you define a custom application with its
own directory structure in order to protect your programs during an
upgrade. The Oracle Applications uses this to determine what ORACLE
username this program runs in and where to place the log and output
files.
Enabled: You cannot delete a concurrent program but you can disable it by un-
checking this box. Disabled programs do not show up in the users lists
or appear in the concurrent manager queues.
Executable>Name: From the LOV select the executable that runs your program. You can
define multiple programs that use the same executable.
Executable>Method: This field will be automatically populated with the execution method
that was selected when the executable was defined.

Note: You can switch between Spawned and Immediate, overriding the
execution method defined in the Concurrent Program Executable
window, only if either method appears when the executable is selected
and both an execution file name and subroutine name have already been
specified in the Concurrent Program.
Executable>Options: Enter execution option values here. If your concurrent program uses
Oracle Reports 2.0 then you must enter the parameter 'VERSION=2.0b'.
Other parameters for Oracle Reports 2.0 that you can enter here are
'ORIENTATION=<value>' and 'PAGESIZE=<width>x<height>. There
should be no spaces before or after the execution options values and the
parameters should be separated by a single space.
Executable>Priority: If you do not assign a priority here then the user's profile option
Concurrent:Priority sets the request's priority at submission time.
Request>Type: Optionally enter a request type from the LOV to limit which concurrent
managers can run your concurrent program.
Request>Incrementor: Internal field used only by Oracle Applications developers
Request>MLS Function: Multilingual Support function if used by the program.
Request>Use in SRS: This must be checked if you want to be able to run this program from the
Standard Submit Request Submissions form.
Request>Allow You can only check this box if you have checked the 'Use in SRS' box.
YouD can allow users to enter disabled values (values that have been
disabled
i or expired in a value set) as parameter values.
s
a
b
l
e
d

Values:
Request>Run Alone: Check this box if your program is incompatible with all programs in its
logical database, including itself.
Request>Enable Trace: Check this box if you want to turn on SQL tracing when this program
runs.
Request>Restart on Check this box if you want this program to be automatically restarted
System Failure: when the concurrent manager is restored after a system failure.
Request>NLS Check this box if the program allows the submission of requests that will
Compliant: reflect a language and territory different from the language and territory
the users are operating in.
Example: Users in the United Kingdom, enter orders in the English,
using the United Kingdom date and number formats, then generate
invoices in German using German date and number formats
Output> Format: Select the output format for your concurrent program from the drop-
down list. Valid values are Text, HTML, PDF, PS (Post Script), and PCL
(HPs Printer Control Language).
Output> Save: Check this box if you want to have the output from this program
automatically saved to an operating system file. If this box is left
unchecked then the output is deleted after printing.
Output> Print: Check this box if you want to be able to print output to a printer.
Output> Optionally enter the minimum column and row length for the program's
Columns/Rows: report output. Oracle Applications uses this information to determine
which print style to use.
Output> Style: If you want to print your program's report output then you should enter
a print style from the LOV.
Output> Style Required: If your program requires a specific print style then check this box to
enforce the print style. Normally users can change the print style at
runtime unless this box is checked.
Output>Printer: Users can change the printer the program they are submitting is sent to
unless you select a printer from the LOV for this field. This option is
useful for such things as check printing where you want to restrict to a
certain printer.
Copy Concurrent Program
Use this feature to create a concurrent program using the same executable, request and report information.
Navigate to: Concurrent>Program>Define
Select: Copy to

Program: Enter Program Name

Short Name: Enter Program Short Name
Application: Application the program is associated with
Include Incompatible Check this box if you want to copy the Incompatible program definition
Programs: to the new custom program
Include Parameters: Check this box if you want to copy the Parameters to the new custom
programs

Session Control
Use this feature to specify options for the database session when the concurrent program is executed.

Navigate to: Concurrent>Program>Define

Select: Session Control

Consumer Group: Optionally enter the consumer group for the concurrent program.
Rollback Segment: Optionally enter a rollback segment to be used. This will be used up
until the first commit instead of the default rollback.

Note: If you specify a rollback segment here, your concurrent program

must call FND_CONCURRENT.AF_COMMIT and
FND_CONCURRENT.AF_ROLLBACK.
Optimizer Mode: Optionally specify an optimizer mode. Select ALL_ROWS,
FIRST_ROWS, Rules, or Choose.

Define Incompatible Programs

 Define programs that should not run simultaneously with the concurrent program because they might interfere
with its execution. You can also define your program as incompatible with itself.

Navigate to: Concurrent>Program>Define

Select: Incompatibilities

Application: From the LOV select the application the incompatible program belongs
to. Defaults to the application the concurrent program belongs to.
Name: From the LOV select the program that is incompatible with your
program.

Note: The name and application must uniquely identify a program

Scope: From the drop-down list select one of the following:
Set: Indicates your concurrent program is incompatible with this
program and all its child requests (Set).
Program Only: Indicates your concurrent program is incompatible
with this program but not its child requests.

Define Program Parameters

Navigate to: Concurrent>Program>Define
Select: Parameters
Conflicts Domain: Enter the parameter, which will hold the value of the conflict domain of
the program. The conflict domain identifies the data that cannot be
accessed or updated simultaneously by incompatible concurrent
programs.
Security Group: This field is only used for HRMS security. Please refer to the appropriate
documentation for details.
Sequence: Choose a sequence number to specify the order in which you want your
program to receive parameter values from the concurrent manager. It is
recommended that you number in increments of 10 (10,20,30,40.) in
case there is ever a need to insert additional parameters between two
existing ones.

Note: If you do not number in increments of 10 and need to add an

additional parameter between two existing parameters you will have to
delete the parameters and reenter them with there new sequence
numbers.
Parameter: Enter the name of your parameter. A user-friendly name is defined later
(Prompt).
Description: Optionally enter a description for this parameter.
Enabled: If this box is not check then the parameter will not be displayed at
request submission time and will not be passed to the execution file.
Validation>Value Set: From the LOV select the value set your parameter will use for validation.
The list of values will only display value sets that are of type
independent, table, and non-validated.
Validation>Default Select a default type from the LOV if you want to set a default value for
Type: this parameter. Valid types are:
 Constant: Default value can be any literal value
Profile: Default value is the current value in a user profile option
SQL Statement: Default value determined by a SQL statement
Segment: Default value is the value entered in a prior segment of the
same parameter window
Validation>Default Enter a default value for your parameter:
Value: Constant: Enter any literal value
Profile: Enter the profile option name (not the end-user name). You
do not need to include $PROFILE$.
SQL Statement: Enter the SQL statement. It must return only one
row and one column in all cases.
Segment: Enter the name of the segment
Validation>Required: If your program requires an argument then you should check this box. If
you do not check this box and your program requires an argument the
program will complete in error but if you check this box then a message
window will appear notifying you that you must enter a value for this
parameter.

Note: If your program requires an argument but the default type is

profile then you will not need to check this box since the user will not be
inputting a value
Validation>Enable If the value set for this parameter allows security rules then optionally
Security: apply any security rules defined for this value set to affect your
parameter list.
Validation>Range: Choose either Low or High from the drop-down list if you want to
validate your parameter value against the value of another parameter in
this structure. If you choose Low for a parameter, you must choose
High for another parameter and vice versa. If your value set is of the
type 'Pair', this field is display only. The value defaults to pair.
Window> Display: Checking this box displays the parameter in the Parameters window of
the Submit Requests form.

Note: If you do not wish to display a parameter then make sure you
assign a default value to it.
Window> Display Size: Enter the field length in characters for this parameter. The size you enter
here determines the field size in the Parameters window of the Submit
Requests form.

Note: If the total of the value set maximum sizes for all your parameters,
plus the number of separators you need (number of parameters minus
one) exceeds 240 then you may see truncation of your data in some
forms.
Window> Description Enter the display length in characters for the parameter value
Size: description.
Window>Prompt: Enter a user-friendly name for the parameter. The user sees the prompt
rather than the parameter name.
Window>Concatenated Enter the display length in characters for the parameter value
Description Size: description.
Token: If your parameter belongs to an Oracle Reports program, you must enter
the keyword or parameter here. This field is case sensitive.
 Example: p_date
Skip this field for other types of programs.

Concurrent Manager
Overview
Concurrent programs are typically data-intensive tasks that run simultaneously with other online operations. A
concurrent manager is itself a concurrent program that starts other concurrent programs. This document explains
how to start up, define, and configure concurrent managers. Concurrent Managers are defined and assigned one or
more work shifts. Target processes determine the number of concurrent requests that can be handled
simultaneously. Therefore, a combination of work shifts and target processes are used in order to achieve the most
efficient system performance.

Below is a summary listing of the concurrent managers and their functions:

Basic Configuration
Internal The Internal Concurrent Manager
Concurrent Starts up, verifies the status of, resets, and shuts down the
Manager (ICM) Individual managers. Settings for the ICM cannot be altered
Standard Runs 365 days a year, 24 hours a day and accepts any and all requests. It has no
Manager specialization and should NOT be altered

Note: If the Standard manager is altered in any way, some programs may not run. We
recommend that you define additional managers to handle client-specific needs.
Conflict The Conflict Resolution Manager resolves conflicts, such as request incompatibilities. The
Resolution Conflict Resolution Manager checks concurrent program definitions for incompatibility
Manager rules. If a program is identified as Run Alone, then the Conflict Resolution Manager
prevents the concurrent managers from starting other programs in the same conflict domain.
When a program lists other programs as being incompatible with it, the Conflict Resolution
Manager prevents the program from starting until any incompatible programs in the same
domain have completed running.
Scheduler/Prer Scheduler/Prereleaser manager
eleaser Manager
Transaction Transaction Manager for diagnostics only
Manager
(Internal Only)

Module Specific Managers

Module Manager Description Type

Accounts Receivables Tax Used to process tax calculations. Transaction
Receivable Manager Manger
Capacity CRP Inquiry Runs capacity inquiries. Transaction
Manager Manager
Inventory Inventory Manager Used to process inventory transactions if you have Concurrent
chosen background processing mode. Inventory Manager
transactions include material transactions, demand
reservation, move transactions, resource transactions, and
costing of material transactions.
Inventory INV Remote If you have chosen server side on-line processing this Transaction
Procedure Manager manager allows a transaction initiated on the client to Manager
process on the server
Master MRP Manager Runs the immediate concurrent program of MRP Concurrent
Scheduling/ Manager
MRP
Projects PA Streamline Manages streamline processes. Concurrent
Manager Manager
Provisioning Oracle Runs provisioning requests Concurrent
Provisioning Manager
Manager
Purchasing PO Document Manages document approval by providing the queue for Transaction
Approval Manager documents awaiting approval. Manager
Purchasing Receiving Used to process receiving transactions. Transaction
Transaction Manager
Manager

Note: Module specific Concurrent Managers can be deactivated and not started according to client needs.

Administer Concurrent Managers

You can issue commands to start, verify, shut down, or reset concurrent managers individually or use the ICM to
control every manager at once. It is recommended that you restart an individual concurrent manager every time
you change any of its definitions such as work shifts, target processes, specialization and incompatibility rules. This
process forces the ICM to reread these definitions.

Starting the ICM

Follow the steps outlined below to start the ICM during installation of Oracle Applications, after shutdown of
concurrent managers, or after restarting your operating system or database
Log in to the UNIX server as applmgr
Select the appropriate database environment
Use the following command: Startmgr <ORACLE_SID>

Controlling Individual Managers

Navigate to: Concurrent>Manager>Administer

Select: Any individual manager.

Note: CRM cannot be controlled using the administration form. The ICM cannot be
restarted using the administration form. Refer to the Oracle Applications Installation
guide for further details.
Terminate: Terminate the ICM to deactivate all concurrent managers and terminate
all concurrent requests at once. Terminate individual managers to
deactivate the selected manager and all requests handled by that
manager
Deactivate: Can be used on any manager EXCEPT the CRM and
Scheduler/Prereleaser. Deactivate the ICM to deactivate all managers or
deactivate individual managers by deactivating the selected manager.
Concurrent requests currently running are allowed to complete before
the manager(s) shut down

Note: Once deactivated, the ICM can only be activated from the server.
Activate: Use to activate previously deactivated individual concurrent managers.

Note: The ICM can only be activated from the server

Restart: Available for any active individual manager EXCEPT the ICM,
Scheduler/Prereleaser, and CRM. Restarting an individual concurrent
manager forces the ICM to reread its definition
Verify: Only available when you select the Internal Manager (ICM). See section
below on verifying concurrent managers
Processes: View details for selected concurrent managers processes
Requests: View all running and pending requests for selected concurrent manager

Verify Concurrent Managers

By default, the ICM periodically monitors each concurrent managers processes. You can force this monitoring
activity, also known as PMON, by selecting the ICM and choosing the Verify button. Also use this function to
check that the actual processes match the target.

Navigate to: Concurrent>Manager>Administer

Select: Internal Manager
Select: Verify
Define Work Shifts
A Work Shift is a specified period of time. Define Work Shifts to specify when a concurrent manager can run.
Work Shifts are defined to cover day and time periods using military time notation. When work shifts overlap, the
one with the more specific time period takes precedence. For example, a work shift for a specific date overrides a
work shift set to run from 9am to 5pm every Monday through Friday. When work shifts with the same priority
overlap, the one with the largest number of target processes takes precedence.

Navigate to: Concurrent>Manager>WorkShifts

Name: Intuitive name, e.g. Night Shift, Graveyard Shift, Week Days,
Weekends
Time>From: Start time for the shift in military time format (HH24:MM) e.g. 09:00
(9am)
Time>To: End time for the shift in military time format (HH24:MM) e.g. 17:00
 (5pm)

Note: Workshifts cannot run across midnight i.e. they must end by 23:59
and begin on or after 24:00
Days of Week>From: First day of WorkShift, e.g. Monday for weekdays WorkShift
Days of Week>To: Last day of WorkShift, e.g. Friday for weekdays WorkShift
Date: Date value for a date-specific WorkShift, e.g. JAN-01-2000

Note: Datespecific workshifts override workshifts that do not specify a

specific date

Define Concurrent Manager

Navigate to: Concurrent>Manager>Define

Manager: Intuitive name for identifying your concurrent manager

Short Name: Intuitive short name for identification/search purposes
Application: Application module for identifying your concurrent manager. A
combination of the application and manager name creates a unique
identification of your concurrent manager.

Note: The application name is merely for identification purposes only

and does not in any way define the kinds of requests your concurrent
manager can run. You will need to apply specialization rules to do this.
Description: Short description of your concurrent manager
Type: Select concurrent manager. This field cannot be updated once defined.
Internal Monitors are used to monitor and restart the ICM in case it exits
abnormally for any reason. Transaction Managers are used to handle
synchronous requests from client machines. Please refer to the
appropriate documentation for setting these up.
Data Group: Leave blank. This field is for Transaction Managers only
Cache Size: Use this to define the number of request your manager keeps in memory.
The recommended number is 1 for large jobs, and 3-4 for smaller jobs.
Consumer Group: Identifies the resource consumer group
Primary Node: Use this to define the primary node your concurrent manager operates
on if you are operating in a parallel concurrent processing environment.
Note: Nodes must be previously registered in Oracle Applications before
they are made available on this screen.
Secondary Node: Use this to define the secondary node your concurrent manager operates
on if you are operating in a parallel concurrent processing environment
and your primary node goes down.

Note: Nodes must be previously registered in Oracle Applications before

they are made available on this screen.
Primary System Queue: Use this to define a platform-specific primary system queue you
associate with the primary node if you are operating in a parallel
concurrent processing environment.

Note: Refer to platform-specific documentation for details.

Secondary System Use this to define a platform-specific secondary system queue you
Queue: associate with the secondary node if you are operating in a parallel
concurrent processing environment.

Note: Refer to platform-specific documentation for details.

Primary Platform: Define your primary platform if you are operating in a parallel
concurrent processing environment.
Secondary Platform: Define your secondary platform if you are operating in a parallel
concurrent processing environment
Program Library Name: Select a program library name to make available immediate concurrent
programs to your concurrent manager.
Program Library Your manager will only be able to run immediate concurrent programs
Application: registered in the program library you select.

Note: Refer to the appropriate documentation for registering immediate

concurrent programs in a program library using AOL.

Assign Work Shifts

Navigate to: Concurrent>Manager>Define
Select: Work Shifts
Manager: Displays your concurrent manager name
Application: Displays the application name associated with your concurrent manager
Work Shift: Select a work shift to assign to your concurrent manager
Description: Displays description of the selected WorkShift
Processes: Number of operating system processes the WorkShift runs
simultaneously. Each process can run a concurrent request.
Sleep Seconds: Number of seconds your concurrent manager waits between checking
lists of pending concurrent requests

Concurrent Manager Specialization

Specialization rules can be used to specify the kinds of requests a concurrent manager should run by setting
Include and Exclude options.

Navigate to: Concurrent>Manager>Define

Select: Specialization Rules

Include/Exclude Select requests to include or exclude from your concurrent manager

:
Type: Select the type of rule to assign e.g. User, Program.
Application: Select the application associated with your rule type
Name: Select the name for your rule type
Description: Enter intuitive description for your specialization rule

Basic Business Needs

Create an alert that sends a notification to the Payables Manager when a return is created in Purchasing to ensure
proper accounting in Payables.

Create an event (on insert) alert that sends a message to the Payables Manager indicating an RMA has been created
in Purchasing. The message should contain the following information:

RMA Reference
Quantity
Reason for Return
Method of Return
PO Number

User Procedures
The Alert will be activated upon insert of the RCV_TRANSACTIONS table.

Alert Description
Select: Alert Manager Responsibility
Navigate to: Alert > Define

Application: Oracle Purchasing

Name: RTV Email Alert
Event>Application: Oracle Purchasing
Event>Table: RCV_TRANSACTIONS
Select: After Insert
Keep XXX Days: 10
Select Statement: select distinct a.rma_reference,
a.quantity,
f.description,
a.attribute3,
b.segment1,
g.line_num,
g.item_description,
g.quantity * unit_price,
c.vendor_name,
d.vendor_site_code
into &rma_reference,
&quantity,
&reason_name,
&return_method,
 &po_number,
&line_num,
&item_descr,
&line_amount,
&vendor_name,
&vendor_site_code
from rcv_transactions a,
po_headers_all b,
po_vendors c,
po_vendor_sites_all d,
mtl_transaction_reasons f,
po_lines_all g
where a.rowid = :ROWID
and a.transaction_type = 'RETURN TO VENDOR'
and a.po_header_id = b.po_header_id
and a.organization_id = b.org_id
and a.vendor_id = c.vendor_id
and b.vendor_site_id = d.vendor_site_id
and a.reason_id = f.reason_id
and a.po_line_id = g.po_line_id
and a.organization_id = g.org_id

Select: Actions button

Action Name: RMA Email Alert

Description: RMA Email Alert for Payables Manager
Action Level: Detail

Select: Action Details

Action Type: Message
To: enter an email address that has been setup
Subject: RMA Created in Purchasing
Select: Text
Text: An RMA was created in Purchasing with the following details:

RMA Reference : &RMA_REFERENCE

Returned Quantity : &QUANTITY
Reason for Return : &REASON_NAME
Method of Return : &RETURN_MATHOD
PO Number : &PO_NUMBER
PO Line Number : &LINE_NUM
PO Line Description : &ITEM_DESCR
PO Line Amount : &LINE_AMOUNT
Supplier Name : &VENDOR_NAME
Supplier Site Name : &VENDOR_SITE_CODE

Please process the related AP Invoice accordingly.

Column Overflow: Wrap

Select: Action Sets
Seq: 1
Action Set Name: RMA Event Email Alert
Description: Send Email Alert to Payables Manager upon RMA creation
Select: Enabled
Members>Seq: 1
Members>Action: RMA Email Alert
Members>Type: Action: Message
Members>Action: Abort
Select: Enabled