Sei sulla pagina 1di 59

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:

Description:

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

Password:

Person:
Customer:
Supplier:
E-Mail:
Fax:
Password Expiration>
Days:
Password Expiration>
Accesses:
Password Expiration>
None:
Effective Dates>From:

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.
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
If this user is an employee select the employee's full name from the LOV.
If this user is a customer select the customer's name from the LOV.
If this user is a supplier select the supplier's name from the LOV.
Optionally enter the email address for this user.
Optionally enter the fax number for this user.
Maximum number of days between password changes.

Responsibility:

Maximum allowed number of sign-ons to Oracle Applications or SelfService Web Applications allowed between password changes.
Select none if you do not wish to have passwords expire by number of
days or accesses.
Optionally enter a start date when this user can begin accessing the
applications.
Optionally enter an end date when this user can no longer access the
applications.
Select a responsibility you wish to assign this user.

Responsibility>
Effective Dates>From:
Responsibility>
Effective Dates>To:

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.
Optionally enter a start date when this user can begin accessing the
applications with this responsibility.
Optionally enter an end date when this user can no longer access the
applications with this responsibility.

Effective Dates>To:

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:
Select:

Security > User > Define


Securing Attributes

Securing Attributes>
Attributes:
Securing Attributes>
Application:
Securing Attributes>
Value:

Select an attribute from the LOV to be used to determine which records


this user can access.
Oracle Self-Service Web Application
Enter the value to be used to determine which specific rows of records 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:
Application:

Enter an intuitive, unique name for the responsibility you are defining.
Select the name of the application you wish to associate with the
responsibility from the LOV.

Responsibility Key:
Description:
Effective Dates>From:
Effective Dates>To:

Available From:
Data Group> Name:

Data Group>

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.
Enter a unique name for this responsibility to be used by loader programs.
Enter a user-friendly description for the responsibility
Enter the start date on which this responsibility becomes active.
Optionally enter the end date on which this responsibility becomes inactive.
Note: Responsibilities cannot be deleted. Use this field to de-activate a
responsibility.
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.
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.
From the LOV select the application whose ORACLE username forms

Application:
Menu:
Web Host Name:
Web Agent Name:
Request Group>
Name/Application:

connect to when you choose this responsibility.


Select a menu that has been defined from the LOV.
If your web server resides on a different machine from your database you
must enter the host name (URL) here.
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.
Assign a request security group from the LOV for this responsibility. If 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:
Select:

Security>Responsibility>Define
Menu Exclusions

Menu Exclusions> Type:

Menu Exclusions>
Name:

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
Select the name of the function or menu to exclude from the 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:
Select:

Security > Responsibility > Define


Securing Attributes

Securing Attributes>
Attributes:

Select an attribute from the LOV to be used to determine which records


this user can access.

Securing Attributes>
Application:

Oracle Self-Service Web 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:
Select:

Security > Responsibility > Define


Excluded Items

Excluded Items> Name:

Select an attribute from the LOV to be excluded from the users access.

Excluded Items>
Application:

Oracle Self-Service Web Application. (Auto-Completion)

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:
Application:

Enter a unique name for the request group you are defining.
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.

Code:
Description:
Type:
Name:

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.
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.
Optionally enter a description of the Request Group.
Choose Program, Application, or Set
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:

Description:
Security Available:
Enable Longlist:

Format Type:

Maximum Size:

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).
Optionally enter a description for your value set.
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.
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.
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.
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

Precision:
Numbers Only (0-9):

Uppercase Only:

Zero-fill Numbers:

specify as your value column.


Use to round numbers for value sets with numerical values.
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.
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.
If you want to have characters 0-9 automatically right-justified and zerofilled 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.
Optionally enter a minimum value a user can enter in a segment that uses
this value set.
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.
Select the validation type you want to use for this value set from the dropdown 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:
Select:
Select:

Application>Validation> Set
Validation Type>Table
Edit Information

Table Application:
Table Name:

Allow Parent Values:


Value Name:

Value Type:
Size:
Meaning Name:

ID Name:

Where/Order By:

Additional Columns:

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.
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.
Select this option if you want to allow parent values.
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.
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.
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.
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.
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.
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
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:
Select:
Select:

Application>Validation> Set
Validation Type>Special or Validation Type>Pair
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

Function:

not use them.


Insert/Update
Query
Edit/Edit
ListVal
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:
Select:
Select:

Independent Value
Set>Name:
Independent Value
Set>Description:
Dependent Default
Value>Value:
Dependent Default
Value>Description:

Application>Validation> Set
Validation Type>Dependent or
Validation Type> Translatable Dependent
Edit Information

Enter the name of the independent value set the value set depends on.
Note: The independent value set must have been pre-defined
Automatically populated with the description of the independent value set.
Enter a default value for your dependent value set.
Enter description for dependent value set default value

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:
Dependent Value Set:
Independent Value:
Value:
Description:
Enabled:

The name of your Independent value set will appear here.


Leave blank
Leave blank
Enter the values you want to assign to this independent value set.
Enter a description for this value.
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.
Optionally enter a start date for when this value becomes active.
Optionally enter an end date for when this value becomes no longer active.

Effective From:
Effective To:
Dependent Value Set
Navigate to:

Application>Validation>Values

Name:
Dependent Value Set:
Independent Value:

Value:
Description:
Enabled:
Effective From:
Effective To:

The name of Independent value set on which the dependent value set
depends, will appear here.
If a dependent value set is assigned to your independent value set it will
automatically appear here.
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.
Enter the dependent values you want associated with the independent
value specified above.
Enter a description for this value.
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.
Optionally enter a start date for when this value becomes active.
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

SQL*Plus

sql

SQL*Loader

install/sql
bin

UNIX
SQL*Forms 4.5 or 6.0

bin
forms

SQL*Forms 2.3 or 2.4

forms

Oracle Reports 2.0, 2.5 or 6.0

srw

Package specification
Package body
SQL script
Spool file
Install script
Control file
Data file
Log file
Error file
Discard file
Shell Script
Binary
Executable
Source
Executable
Source
Binary
Executable
Source

Pks
Pkb
Sql
Lst
Sql
Ctl
Dat
Log
Err
Dis
Sh
Fmb
Fmx
Fms
Frm
Inp
Rdf
Rpt
Rex

Please note the custom objects need to be prefixed with the following to clearly define the
module:CFI
CMF
CSA
CCO

Financial
Manufacturing
Sales Administration
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
CMF0002
CSA0003
CMF0004

Mod 1 is for Finance


Mod 2 is for Manufacturing
Mod 3 is for Sales Administration
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

Table
Index

30 characters long
Xn

View
Sequence
Trigger

V
S
XIUD_TRG

Package

PK or PB

Function

FNS

Meaning
X=(U)nique or (N)on-Unique
n=Index Sequence Number
V = View
S = Seqeunce
X=(B)efore or (A)fter
I=Insert/U=Update/D=Delete
TRG=Trigger
PK=Package Specification
PB=Package Body
FNS=Functon

Example
CSA_SO_HEADERS
CSA_SO_HEADERS_U1
CSA_SO_HEADERS_V
CSA_SO_HEADERS_S
CSA_SO_HDRS_BIU_TRG
CSA_SO_HDS_PK
CSA_SO_HDS_PB
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
Custom
Custom
Custom
Custom
APPS
APPS

Object
Table
Index
Sequence
Grants
Synonyms
Views

APPS

Package
Procedures/Functions/Triggers
Links

APPS

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 reprocess 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
APPSTAND
FNDSQF
APPCORE
APPDAYPK

master copy of the shared objects


$AU_TOP/resource - library of utilities
AOL utilities
Control Menu/Tool bar
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, ONLOCK 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
CREATION_DATE
LAST_UPDATED_BY
LAST_UPDATE_DATE
LAST_UPDATE_LOGIN
REQUEST_ID
PROGRAM_APPLICATION_ID
PROGRAM_ID
PROGRAM_UPDATE_DATE

Not Null
Not Null
Not Null
Not Null

TO_NUMBER(FND_PROFILE.VALUE(USER_ID))
SYSDATE
TO_NUMBER(FND_PROFILE.VALUE(USER_ID))
SYSDATE
TO_NUMBER(FND_PROFILE.VALUE(LOGIN_ID))
FND_CONCURRENT_REQUESTS
FND_CONCURRENT_PROGRAM
FND_CONCURRENT_PROGRAM
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
REPLACE
APPEND

- requires the table to be empty


- deletes the rows and inserts new data
- 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


$R2I_TOP directory

Standard Oracle
Applications

Register Tables,
Views, Sequences
Forms, Reports and
Concurrent Programs

Create synonyms for


the objects created
under oracle Id R2I

Create Tables, views,


sequences under
Oracle Id R2I

Give grants to
Applications Oracle Id

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
Concurrent Programs

Create Tables, views,


sequences under
Oracle Id R2I

Standard Oracle
Applications

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
_TYPE
_NAME
_VALUE

_CODE
_DATE
_OWNER

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
COLUMN description
FORMAT A30
COLUMN category
FORMAT A15

HEADING "Item"
HEADING "Description"
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
Sql*Plus & PL/SQL

.sql

Ext.

Oracle Reports

.rdf

Sql Loader

.ctl

Directory
$CUSTOM_TOP/
$APPLSQL
$CUSTOM_TOP/
$APPLREP
$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.)
Enter a short name for your concurrent program executable. (You assign
this name to your concurrent program.)

Short Name:

Application:

Description:
Execution Method:

Execution File Name:

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.
Optionally enter a description for this executable.
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.
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.
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:
Select:

Concurrent>Program>Executable
Stage Function Parameters

Parameter:
Short Name:
Description:

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.
Enter a short name that will be used by the function to reference the
parameter.
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.
Enter a short unique name. Oracle Applications uses this name to associate

Short Name:

Application:

Enabled:
Executable>Name:
Executable>Method:

Executable>Options:

Executable>Priority:
Request>Type:
Request>Incrementor:
Request>MLS Function:
Request>Use in SRS:
Values:

Request>Restart on
System Failure:
Request>NLS
Compliant:

Output> Format:

your concurrent program with an executable.


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.
You cannot delete a concurrent program but you can disable it by unchecking this box. Disabled programs do not show up in the users lists or
appear in the concurrent manager queues.
From the LOV select the executable that runs your program. You can
define multiple programs that use the same executable.
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.
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.
If you do not assign a priority here then the user's profile option
Concurrent:Priority sets the request's priority at submission time.
Optionally enter a request type from the LOV to limit which concurrent
managers can run your concurrent program.
Internal field used only by Oracle Applications developers
Multilingual Support function if used by the program.
This must be checked if you want to be able to run this program from the
Standard Submit Request Submissions form.
You can only check this box if you have checked the 'Use in SRS' box. You
can allow users to enter disabled values (values that have been disabled or
expired in a value set) as parameter values.
Check this box if your program is incompatible with all programs in its
logical database, including itself.
Check this box if you want to turn on SQL tracing when this program
runs.
Check this box if you want this program to be automatically restarted
when the concurrent manager is restored after a system failure.
Check this box if the program allows the submission of requests that will
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
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> Columns/Rows: Optionally enter the minimum column and row length for the program's
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:
Select:

Concurrent>Program>Define
Copy to

Program:
Short Name:
Application:
Include Incompatible
Programs:
Include Parameters:

Enter Program Name


Enter Program Short Name
Application the program is associated with
Check this box if you want to copy the Incompatible program definition to
the new custom program
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:
Select:

Concurrent>Program>Define
Session Control

Consumer Group:
Rollback Segment:

Optionally enter the consumer group for the concurrent program.


Optionally enter a rollback segment to be used. This will be used up until
the first commit instead of the default rollback.

Optimizer Mode:

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


must call FND_CONCURRENT.AF_COMMIT and
FND_CONCURRENT.AF_ROLLBACK.
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:
Select:

Concurrent>Program>Define
Incompatibilities

Application:
Name:
Scope:

From the LOV select the application the incompatible program belongs to.
Defaults to the application the concurrent program belongs to.
From the LOV select the program that is incompatible with your program.
Note: The name and application must uniquely identify a program
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:
Select:

Concurrent>Program>Define
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.
This field is only used for HRMS security. Please refer to the appropriate
documentation for details.
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.

Security Group:
Sequence:

Parameter:
Description:
Enabled:
Validation>Value Set:
Validation>Default Type:

Validation>Default
Value:

Validation>Required:

Validation>Enable
Security:
Validation>Range:

Window> Display:

Window> Display Size:

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.
Enter the name of your parameter. A user-friendly name is defined later
(Prompt).
Optionally enter a description for this parameter.
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.
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.
Select a default type from the LOV if you want to set a default value for
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
Enter a default value for your parameter:
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
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
If the value set for this parameter allows security rules then optionally
apply any security rules defined for this value set to affect your parameter
list.
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.
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.
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.

Window> Description
Size:
Window>Prompt:
Window>Concatenated
Description Size:
Token:

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.
Enter the display length in characters for the parameter value description.
Enter a user-friendly name for the parameter. The user sees the prompt
rather than the parameter name.
Enter the display length in characters for the parameter value description.
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 Concurrent
Manager (ICM)
Standard Manager

Conflict Resolution
Manager

Scheduler/Prereleaser

The Internal Concurrent Manager


Starts up, verifies the status of, resets, and shuts down the
Individual managers. Settings for the ICM cannot be altered
Runs 365 days a year, 24 hours a day and accepts any and all requests. It
has no 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.
The Conflict Resolution Manager resolves conflicts, such as request
incompatibilities. The Conflict Resolution Manager checks concurrent
program definitions for incompatibility 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/Prereleaser manager

Manager
Transaction Manager
(Internal Only)

Transaction Manager for diagnostics only

Module Specific Managers


Module
Accounts
Receivable
Capacity

Manager
Receivables Tax Manager

Description
Used to process tax calculations.

CRP Inquiry Manager

Runs capacity inquiries.

Inventory

Inventory Manager

Inventory

INV Remote Procedure


Manager

Master
Scheduling/
MRP
Projects

MRP Manager

Used to process inventory


transactions if you have chosen
background processing mode.
Inventory transactions include
material transactions, demand
reservation, move transactions,
resource transactions, and costing of
material transactions.
If you have chosen server side on-line
processing this manager allows a
transaction initiated on the client to
process on the server
Runs the immediate concurrent
program of MRP

PA Streamline Manager

Manages streamline processes.

Provisioning

Oracle Provisioning
Manager
PO Document Approval
Manager

Runs provisioning requests

Purchasing
Purchasing

Receiving Transaction
Manager

Manages document approval by


providing the queue for documents
awaiting approval.
Used to process receiving
transactions.

Type
Transaction
Manger
Transaction
Manager
Concurrent
Manager

Transaction
Manager
Concurrent
Manager
Concurrent
Manager
Concurrent
Manager
Transaction
Manager
Transaction
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:
Select:

Concurrent>Manager>Administer
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:
Deactivate:

Activate:
Restart:
Verify:

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
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.
Use to activate previously deactivated individual concurrent managers.
Note: The ICM can only be activated from the server
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
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:
Select:
Select:

Concurrent>Manager>Administer
Internal Manager
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
Start time for the shift in military time format (HH24:MM) e.g. 09:00
(9am)
End time for the shift in military time format (HH24:MM) e.g. 17:00
(5pm)

Time>From:
Time>To:

Days of Week>From:
Days of Week>To:
Date:

Note: Workshifts cannot run across midnight i.e. they must end by 23:59
and begin on or after 24:00
First day of WorkShift, e.g. Monday for weekdays WorkShift
Last day of WorkShift, e.g. Friday for weekdays WorkShift
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:
Short Name:
Application:

Intuitive name for identifying your concurrent manager


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

Description:
Type:

Data Group:
Cache Size:
Consumer Group:
Primary Node:

Secondary Node:

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.
Short description of your concurrent manager
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.
Leave blank. This field is for Transaction Managers only
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.
Identifies the resource consumer group
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.
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.

Primary System Queue:

Note: Nodes must be previously registered in Oracle Applications before


they are made available on this screen.
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.

Secondary System
Queue:

Note: Refer to platform-specific documentation for details.


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

Primary Platform:
Secondary Platform:
Program Library Name:
Program Library
Application:

Note: Refer to platform-specific documentation for details.


Define your primary platform if you are operating in a parallel concurrent
processing environment.
Define your secondary platform if you are operating in a parallel
concurrent processing environment
Select a program library name to make available immediate concurrent
programs to your concurrent manager.
Your manager will only be able to run immediate concurrent programs
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:
Select:

Concurrent>Manager>Define
Work Shifts

Manager:
Application:
Work Shift:
Description:
Processes:

Displays your concurrent manager name


Displays the application name associated with your concurrent manager
Select a work shift to assign to your concurrent manager
Displays description of the selected WorkShift
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:
Select:

Include/Exclude:
Type:
Application:
Name:
Description:

Concurrent>Manager>Define
Specialization Rules

Select requests to include or exclude from your concurrent manager


Select the type of rule to assign e.g. User, Program.
Select the application associated with your rule type
Select the name for your rule type
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:
Navigate to:

Alert Manager Responsibility


Alert > Define

Application:
Name:
Event>Application:
Event>Table:
Select:
Keep XXX Days:
Select Statement:

Oracle Purchasing
RTV Email Alert
Oracle Purchasing
RCV_TRANSACTIONS
After Insert
10
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:
Description:
Action Level:

RMA Email Alert


RMA Email Alert for Payables Manager
Detail

Select:

Action Details

Action Type:
To:
Subject:
Select:
Text:

Message
enter an email address that has been setup
RMA Created in Purchasing
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:
Select:

Wrap
Action Sets

Seq:
Action Set Name:
Description:
Select:
Members>Seq:
Members>Action:
Members>Type:
Members>Action:
Select:

1
RMA Event Email Alert
Send Email Alert to Payables Manager upon RMA creation
Enabled
1
RMA Email Alert
Action: Message
Abort
Enabled

Potrebbero piacerti anche