Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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:
Tip: Tab through the fields when completing this form and watch the status bar for field specific
prompts
User Name:
Description:
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:
Securing Attributes>
Attributes:
Securing Attributes>
Application:
Securing Attributes>
Value:
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:
Security>Responsibility>Define
Menu Exclusions
Menu Exclusions>
Name:
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.
Securing Attributes>
Attributes:
Securing Attributes>
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:
Select an attribute from the LOV to be excluded from the users access.
Excluded Items>
Application:
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:
Query the responsibility you would like to assign your request group to
Navigate to:
Security>Responsibility>Define
Request Group>Name:
Overview
This document explains how to define custom value sets. Use the System Administrator
Responsibility.
Application>Validation> Set
Description:
Security Available:
Enable Longlist:
Format Type:
Maximum Size:
Precision:
Numbers Only (0-9):
Uppercase Only:
Zero-fill Numbers:
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.
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:
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.
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:
Dependent Validation
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
Application>Validation>Values
Name:
Dependent Value Set:
Independent Value:
Value:
Description:
Enabled:
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
forms
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
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
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
Object
Table
Index
Sequence
Grants
Synonyms
Views
APPS
Package
Procedures/Functions/Triggers
Links
APPS
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
Cursor Definitions
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
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
Ensure all BUTTONS in Oracle Application look and behave the same
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
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
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
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
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
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
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.
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 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.
Standard Oracle
Applications
Register Tables,
Views, Sequences
Forms, Reports and
Concurrent Programs
Give grants to
Applications Oracle Id
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.
Register Tables,
Views, Sequences
Forms, Reports and
Concurrent Programs
Standard Oracle
Applications
Give grants to
Applications Oracle Id
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.
Not be case-sensitive
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
Use the same name to describe the same entity or attribute across tables
Use full, descriptive, pronounceable names or well known "standard"
abbreviations
Be named using the plural form representing the notion of a set or collection -- e.g.
USER_CONFIGURATIONS not USER_CONFIGURATION
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.
_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.
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
HEADING "Item"
HEADING "Description"
HEADING "Category"
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:
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 (.).
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:
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:
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:
Optimizer Mode:
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.
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:
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
Manager
Transaction Manager
(Internal Only)
Manager
Receivables Tax Manager
Description
Used to process tax calculations.
Inventory
Inventory Manager
Inventory
Master
Scheduling/
MRP
Projects
MRP Manager
PA Streamline Manager
Provisioning
Oracle Provisioning
Manager
PO Document Approval
Manager
Purchasing
Purchasing
Receiving Transaction
Manager
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.
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
Navigate to:
Concurrent>Manager>WorkShifts
Name:
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
Concurrent>Manager>Define
Manager:
Short Name:
Application:
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.
Secondary System
Queue:
Primary Platform:
Secondary Platform:
Program Library Name:
Program Library
Application:
Concurrent>Manager>Define
Work Shifts
Manager:
Application:
Work Shift:
Description:
Processes:
Sleep Seconds:
Include/Exclude:
Type:
Application:
Name:
Description:
Concurrent>Manager>Define
Specialization Rules
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:
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