LookUps

Lookup is an important concept in Oracle Applications, used for providing list of values for validation and selection. It can be easily understood by following examples:

Example 1: On a form, we have a field called 'Gender'. This field's possible values can be 'Male' and 'Female'. We can create a lookup of type 'Sex' and store 'Male' and 'Female' as the lookup values. In the runtime, we can retrieve these values and show it as the list of values on the field.

Example 2: A bank provides facilities of Saving Account, Current Account and Fixed Deposit Account. We can define a lookup type called 'Account Type' and associate these account type values with this look type.

Advantage and Uses of Lookups:

Oracle Applications comes with seeded lookup types. When implementing, we can add more values to it thus extending the Oracle Application functionality without making any code changes. In the above example of bank Account type lookup, we can associate more values with the lookup type 'Account Type' when bank decides to provide additional account types.

Lookup values contain a lookup code and meaning. The meaning of the lookup code is displayed on the screen and the lookup code is stored in the database. When it is desired to change the meaning for better understanding of the user, it can be changed in the lookup type setup and the changed meaning will be displayed in all the screens wherever the lookup is being used.

Lookup type can be defined at three levels:

• System: Existing lookup values cannot be modified and new values cannot be inserted. These kind of lookup types are useful when application logic and functionality depends on the existence of pre-defined lookup values.

• Extensible: Existing lookup values cannot be modified. However, new lookup values can be inserted. This kind of lookup provides flexibility in extending Oracle Applications' functionality.

• User: Existing lookup values can be modified and new values can be inserted. This is the most flexible lookup type.

Oracle Application comes pre-seeded with all the above kind of lookups. It is also possible to define new lookup type by the implementation team for specific extension purposes.

Lookup Components

Lookup consists of lookup type and Lookup values:

Lookup Type: This is header entity and contains name of lookup type and the Application. It also has information on the level of lookup type (System, Extensible or User).

Lookup Value: This is detail entity and child of Lookup Type entity. For a given lookup type, we can have many lookup values.

Lookup type is also associated with a View Application. Based on that, we can divide lookup types in three categories:

• Application Object Library Lookups: The lookup type where view application is 'FND' (or the view application id is 0 - which is the application ID of FND application). These lookups are accessible from Application Developer or System Administrator Responsibilities.

• Common Lookup: The lookup type where the view application is 'AU' (or the view application ID is 3 - which is the application ID of AU application). These lookups are accessible for maintenance from Application Developer responsibilities.

• Quick Code: The lookup type where the View application id is same as Application ID. Some modules like AR, AP etc. make use of Quick codes to enable the lookup value modification through the respective applications. For example, a Quick code called 'SOURCE' is used to defined AP interface source and is available only through AP responsibilities.

Lookup Screen

Navigation: Application Developer => Application => Lookups => Application Object Library

Technical Details on Lookups
Lookup consists of lookup type and Lookup values:

Lookup Type: FND_LOOKUP_TYPES, FND_LOOKUP_TYPES_TL

Lookup Values: FND_LOOKUP_VALUES

Important fields of these tables are explained below:

FND_LOOKUP_TYPES (Lookup Type Base Table)

Application_ID Application associated with the lookup type

Lookup_Type Lookup type code

Customization_Level Customization Level. Value can be E, U or S.

View_Application_ID View Application. It is automatically derived based on which screen you choose to define lookup type.

FND_LOOKUP_TYPES_TL (Lookup type Translated Table)

Lookup_Type Primary key. Same as the primary key in Base table

Language Language

Meaning Meaning in the corresponding Language

Description Description in the corresponding Language

A View FND_LOOKUP_TYPES_VL is available which is a join between FND_LOOKUP_TYPES and FND_LOOKUP_TYPES_TL tables. This view will give the records for the current language.

FND_LOOKUP_VALUES (Lookup Value table)

Lookup_Type Foreign key from FND_LOOKUP_TYPES

Language Language

Lookup_Code Lookup Code.

Meaning Meaning of Lookup Code

Description Description of Lookup Code

Start_date_Active Start date of the lookup Code

End_Date_Active End date of the Lookup Code

A view FND_LOOKUP_VALUES_VL is available which gives records from FND_LOOKUP_VALUES for the current language.

Examples

In order to select all the values for a given lookup type (Say, a lookup type having a meaning of 'Approval Priority Type'), we can use the following query:

SELECT lookup_code

FROM fnd_lookup_values_vl val, fnd_lookup_types_vl type

WHERE type.lookup_type = val.lookup_type

AND type.meaning = 'Approval Priority Type'

The above query gives the following results:

LOOKUP_CODE

------------------------------

STANDARD

URGENT

Lookup APIs
 New Lookup types and values can be created through the Screen (Using System Administrator or Application Developer responsibilities). However, sometime we need to create large number of values for a given lookup type. In that case, it is better to use Oracle's standard API, which can read from a flat file and create the lookups programmatically.  

The standard Oracle APIs that can be used for creation lookups programmatically are given below:

FND_LOOKUP_TYPES_PKG.INSERT_ROW for inserting new lookup type

FND_LOOKUP_VALUES_PKG.INSERT_ROW for inserting new lookup value

Lookups created in one instance of Oracle Applications may need migration to another instance. For example, initially we would create a new lookup type or lookup values in Development instance. These values are needed to be migrated to another instance, say test instance.

We can make use of Oracle's standard FNDLOAD tool to achieve the migration. The tool creates a data file (called .LDT file) from the source instance. This data file is then uploaded into the target instance. The usage of this tool is given below.

Suppose we have a lookup type called 'OKL_AE_LINE_TYPE'. We want to download it from development instance in a file. We can use the following command in UNIX:

$FND_TOP/bin/FNDLOAD apps/<password>@DBNAME 0 Y DOWNLOAD$FND_TOP/patch/115/import/aflvmlu.lct xxx_line_type.ldt FND_LOOKUP_TYPE APPLICATION_SHORT_NAME ='OKL' LOOKUP_TYPE="OKL_AE_LINE_TYPE"

The above statement invokes tool FNDLOAD using the standard lct file called 'aflvmlu.lct'. The data of the lookup 'OKL_AE_LINE_TYPE' is downloaded in the flat file 'xxx_line_type.ldt'. This lookup then can be uploaded into another instance using the following command:

$FND_TOP/bin/FNDLOAD apps/<password>@DBNAME 0 Y UPLOAD $FND_TOP/patch/115/import/aflvmlu.lct xxx_line_type.ldt

For more information on FNDLOAD, please go to Chapter on FNDLOAD from the main index.

FNDLOAD

Oracle provides a generic tool called FNDLOAD, which can be used for migration of FND entities from one instance to another. For example, the lookups and responsibilities created in development instance can be downloaded in a file and then uploaded into a test or production instance. This saves lot of time in configuration and is usually preferred over recreating the data manually in all the instances.

 
In an oracle implementation, usually setups are done in a development instance which need to be migrated to test and production instance. FNDLOAD can be used to create data files from the source instance and then this data file uploaded to target instance. The data file thus downloaded can be moved from one instance to another instance as a source controlled file.
 Some of the examples of the entities which can be migrated using FNDLOAD are:
· Attachment Definition
· Concurrent Programs
· Printers and Printer Styles
· Value-Sets
· Request Groups
· Request Sets
· Form Personalization
· Lookups
· Responsibilities
· Applications
· Profile Options
· Users
· Form, Functions and Menus
· Document Sequences
· Descriptive and Key Flex Fields


How FNDLOAD works

FNDLOAD is basically a concurrent program, run from command prompt. The script can either download or upload the data depending upon the parameter passed. To download data for a particular entity, it makes use of a definition file (called .lct file). These definition files are standard files (for each standard entity) and are available in the directory, $FND_TOP/patch/115/import/. For example, to download a concurrent program, a definition file afcpprog.lct is used.
Output data file is created with an extension .ldt. This data file can then subsequently be uploaded into other environment using FNDLOAD command with upload parameter.
For example, suppose there is a concurrent program defined in development instance. We want to migrate this concurrent program from development to Test instance. The can be achieved using the following two steps:

a. Run the FNDLOAD command (in Development instance) in DOWNLOAD mode, using definition file afcpprog.lct to create a .ldt file.
b. Run the FNDLOAD command (in Test instance) in UPLOAD mode, using the data file created in step (a) above.

FNDLOAD Command

FNDLOAD is run from Unix environment. It can be run for upload or download. The syntax of upload and download are as follows:

FNDLOAD logon 0 Y mode configfile datafile [ entity [ param ... ] ]

Logon is apps user and apps password, For example apps/apps.
Mode can be DOWNLOAD or UPLOAD
Configfile is a standard .lct file which is available in $FND_TOP/patch/115/import directory.
Datafile is a .ldt file which contains the downloaded data. The name of datafile can be any user defined name; however extension should be given as .ldt.
Entity is name of the entity (explained further).
Param is Name=Value string used for parameter substitution (explained further).

Standard Configuration files
Oracle has provided standard configuration files (.lct files) for migration of the standard entities. All of these configuration files are available at $FND_TOP/patch/115/import directory. The main configuration files are given below:

Entity	Configuration File
Attachment Definition	afattach.lct
Concurrent Programs	afcpprog.lct
Printers and Printer Styles	afcppstl.lct, afcpprnt.lct
Value Sets	afffload.lct
Request Groups	afcpreqg.lct
Request Sets	afcprset.lct
Form Personalization	affrmcus.lct
Lookups	aflvmlu.lct
Responsibilities	afrole.lct
Applications	afscapp.lct
Profile Options	afscprof.lct
Users	afscursp.lct
Form, Functions, Menus	afsload.lct
Document Sequences	afsncat.lct
Descriptive and Key Flex Fields	afffload.lct
Messages	afmdmsg.lct

Examples on Upload Download of Commonly used Entities

Concurrent Program

Download

FNDLOAD apps/<password> O Y DOWNLOAD $FND_TOP/patch/115/import/afcpprog.lct file_name.ldt PROGRAM APPLICATION_SHORT_NAME="<Short Application Name>" CONCURRENT_PROGRAM_NAME="<concurrent program short name>"

Upload

FNDLOAD apps/<password> 0 Y UPLOAD $FND_TOP/patch/115/import/afcpprog.lct file_name.ldt

Printer Styles
FNDLOAD apps/apps O Y DOWNLOAD $FND_TOP/patch/115/import/afcppstl.lct file_name.ldt STYLE PRINTER_STYLE_NAME="printer style name"
Lookups
FNDLOAD apps/apps O Y DOWNLOAD $FND_TOP/patch/115/import/aflvmlu.lct file_name.ldt FND_LOOKUP_TYPE APPLICATION_SHORT_NAME="FND"
LOOKUP_TYPE="lookup name"

Descriptive Flexfield
FNDLOAD apps/apps O Y DOWNLOAD $FND_TOP/patch/115/import/afffload.lct file_name.ldt DESC_FLEX P_LEVEL=’COL_ALL:REF_ALL:CTX_ONE:SEG_ALL’ APPLICATION_SHORT_NAME="FND" DESCRIPTIVE_FLEXFIELD_NAME="desc flex name" P_CONTEXT_CODE="context name"

Key Flexfield Structures
FNDLOAD apps/apps O Y DOWNLOAD $FND_TOP/patch/115/import/afffload.lct file_name.ldt KEY_FLEX P_LEVEL=’COL_ALL:FQL_ALL:SQL_ALL:STR_ONE:WFP_ALL:SHA_ALL:CVR_ALL:SEG_ALL’ APPLICATION_SHORT_NAME="FND" ID_FLEX_CODE="key flex code" P_STRUCTURE_CODE="structure name"

Value Sets with values
FNDLOAD apps/apps O Y DOWNLOAD $FND_TOP/patch/115/import/afffload.lct file_name.ldt VALUE_SET FLEX_VALUE_SET_NAME="value set name"
Profile Options
 FNDLOAD apps/apps O Y DOWNLOAD $FND_TOP/patch/115/import/afscprof.lct file_name.ldt PROFILE PROFILE_NAME="profile option" APPLICATION_SHORT_NAME="FND"
Request GroupsFNDLOAD apps/apps O Y DOWNLOAD $FND_TOP/patch/115/import/afcpreqg.lct file_name.ldt REQUEST_GROUP REQUEST_GROUP_NAME="request group" APPLICATION_SHORT_NAME="FND"
Request Sets
FNDLOAD apps/apps O Y DOWNLOAD $FND_TOP/patch/115/import/afcprset.lct file_name.ldt REQ_SET
APPLICATION_SHORT_NAME="FND" REQUEST_SET_NAME="request set"
ResponsibilitiesFNDLOAD apps/apps O Y DOWNLOAD $FND_TOP/patch/115/import/afscursp.lct file_name.ldt FND_RESPONSIBILITY RESP_KEY="responsibility"
MenusFNDLOAD apps/apps O Y DOWNLOAD $FND_TOP/patch/115/import/afsload.lct file_name.ldt MENU MENU_NAME="menu_name"
Forms PersonalizationFNDLOAD apps/apps 0 Y DOWNLOAD $FND_TOP/patch/115/import/affrmcus.lct file_name.ldt FND_FORM_CUSTOM_RULES function_name=FUNCTION_NAME

Descriptive Flex Fields

Most of the Oracle application screens come with a facility to expand the space to capture custom fields. This facility of adding new custom fields (without any programming) is called DFF or Descriptive Flex Fields. The advantage of DFF is that around 15 new custom fields can be captured on each of the database table based block or form without doing any programming. The availability of facility of DFF on a screen is shown by square bracket [ ] and is shown below in figure 1.

For using a DFF facility on a standard screen, it has to be activated first. The activation is done by system administrator responsibility and it includes deciding number of fields to be used, window title of the fields, valid values of the fields, context etc. Once activated, the DFF field is immediately available for use. It can be used by clicking on the [ ] field which pops up a screen to capture the enabled fields.

DFF Features

DFF is directly mapped to a table and each segment of DFF is mapped to an individual field of the table. These fields are often named as ATTRIBUTE1, ATTRIBUTE2, …, ATTRIBUTE15 (most of the time, we have maximum of 15 attribute fields available in each standard table). In addition to these 15 attribute fields, there is also one field called ATTRIBUTE_CATEGORY. This field is called Context field or Structure Field. How the structure field is used is explained below:

Some time there is a requirement to capture context sensitive information in DFF fields. Suppose in HR form, we want to capture some custom information. If we are entering record for an Employee, we want to capture certain information; on the other hand, if we are entering record for an Applicant, then we want to capture some other custom information. This can be achieved by defining different contexts. In the example, just given, we can define two contexts, Employee and Applicant. Depending upon what context is chosen, we will show the corresponding fields to the users for entry.

Uses

DFF is a very powerful feature of oracle applications which provides lot of extensibility to an implementation. Since Oracle Applications is implemented across diverse businesses and each business may need different kind of information to be captured (in addition to the standard information capturing which oracle provides), DFF comes in very handy to capture the custom information. Fields captured by DFF are stored in the database and are automatically queried whenever corresponding record is queried on the screen.

Examples

1. A business ABC wants to capture additional supplier attributes like supplier turnover, supplier’s rating etc. These fields are not captured by standard oracle application screen and can be captured by activating DFF on supplier screen.
2. A leasing company wants to capture maximum mileage allowed and mileage penalty imposed for extra miles for the trucks it leases. These fields are not provided in the standard oracle applications and can be captured by activating DFF on lease authoring screen.

How to enable DFF

Enabling a DFF can be best illustrated by an example. We will take GL Daily Rate Screen (Navigation: GL Super User => Setup => Rates => Daily) for this discussion.  

The screen is shown below. The screen has the DFF facility available but is not active currently.

We want to enable this DFF to capture two more fields:

 Exchange Rate Source

 Exchange Rate Time

  

1. First step is to find out the corresponding table name for this screen. This can be found by querying the record and then going to Help => Diagnostics => Examine and checking the Last Query field in the System Block. This will provide us with the table name underlying the data.  In this example, our table name is GL_DAILY_RATES.  
2. Now go to Application Developer Responsibility and Navigate to Flexfield => Descriptive => Register. Now do a query based on this table name (GL_DAILY_RATES).

We note down the Title (which is Daily Rates).

1. Now, we know the title of the standard DFF available for the Daily Rate screen. This DFF needs to be now enabled. For doing this navigate to FlexField=>Descriptive=>Segments screen and do a query based on the DFF title (Daily Rates).

Global Data Elements context is always pre-populated. If we do not want any context, then we can just click on segments button and define the required segments. However, if we need to define different contexts, then those context can be entered here and the corresponding segments can be entered for each of chosen contexts.

1. Click on the Segments button, and enter the values as shown below. We can associate value-set for each segment so that users can enter only valid values when entering a record.

1. Save the changes and come back to the previous screen. Click on Freeze Flexfield definition check-box and save the changes.  

1. Now, we are done with activating the DFF. Come back to the Daily Rate Screen and see that DFF is enabled and can be used to capture two new fields as shown below:

 

Defining a new DFF

DFF is implemented using the Attribute column fields in a table. For example, let us consider definition of a table GL_DAILY_RATES.

SQL> desc gl_daily_rates

 Name Null? Type

 ------------------------------- -------- ----

 FROM_CURRENCY NOT NULL VARCHAR2(15)

 TO_CURRENCY NOT NULL VARCHAR2(15)

 CONVERSION_DATE NOT NULL DATE

 CONVERSION_TYPE NOT NULL VARCHAR2(30)

CONVERSION_RATE NOT NULL NUMBER

STATUS_CODE NOT NULL VARCHAR2(1)

CREATION_DATE NOT NULL DATE

CREATED_BY NOT NULL NUMBER(15)

LAST_UPDATE_DATE NOT NULL DATE

LAST_UPDATED_BY NOT NULL NUMBER(15)

LAST_UPDATE_LOGIN NOT NULL NUMBER(15)

CONTEXT VARCHAR2(150)

ATTRIBUTE1 VARCHAR2(150)

ATTRIBUTE2 VARCHAR2(150)

ATTRIBUTE3 VARCHAR2(150)

ATTRIBUTE4 VARCHAR2(150)

ATTRIBUTE5 VARCHAR2(150)

ATTRIBUTE6 VARCHAR2(150)

ATTRIBUTE7 VARCHAR2(150)

ATTRIBUTE8 VARCHAR2(150)

ATTRIBUTE9 VARCHAR2(150)

ATTRIBUTE10 VARCHAR2(150)

ATTRIBUTE11 VARCHAR2(150)

ATTRIBUTE12 VARCHAR2(150)

ATTRIBUTE13 VARCHAR2(150)

ATTRIBUTE14 VARCHAR2(150)

ATTRIBUTE15 VARCHAR2(150)

RATE_SOURCE_CODE VARCHAR2(15)

This table contains a field called CONTEXT and 15 Attribute columns. The Context field stores the structure or content of the DFF and attribute columns store the actual values of the custom fields.

When we create a DFF definition (as shown below), we choose a Structure Column (CONTEXT in the below example) and also choose a prompt for the Context.

 

The fields to be used in the DFF design can be associated by clicking on the Columns button and checking the enabled button as shown below:

There is also a button called Reference Fields, which is used for defining the reference fields for DFF as shown below:

Reference fields are useful for automatically prompting user to enter required values. This can be explained by an example:

Suppose a manufacturing firm sells three kinds of items – Computer, Printers and Fax Machines. Depending upon the item type, we would like to capture different kind of custom information from the user. If ‘item type’ is a reference field in the DFF definition, then we can choose ‘item type’ in the reference field during DFF enabling. For each item type, we can define a context field (Computer, Printers, Fax Machines) and the corresponding segments. When user enters item information, depending upon the item type, the corresponding DFF structure appears automatically.

FAQ on DFF

1. Can we create a custom DFF?

Ans. Yes, we can create a custom DFF. But the table to be used in the DFF should be registered with Oracle Applications.

1. How do we use a custom DFF?

Ans. Custom DFF can be used only in a custom form. For details on how to use a custom DFF in custom form, please see Oracle Forms section.

1. What is meant by Global Context?

Ans. When we need to capture same kind of information for all the records, then global context can be used. In this case, for all the records, the same structure appears for data entry.

1. How do we use different Attribute columns during DFF activation?

Ans. If we are using two different contexts (say Printer and Fax) and not using Global Context, then we can re-use the attribute columns. That means, an attribute column associated with Printer context can also be associated with the Fax context. However, if we are using global context also, then the attributes used in global context cannot be re-used for any other context. For example, if we are using Attribute1 to Attribute3 in the global context, then we can use only Attribute4 to Attribute15 in the other contexts.

1. What is the Difference between Reference Field and Context?

Ans: When we use multiple contexts, user has to manually select a context when entering values. Based on the context chosen, corresponding fields are shown to the user. However, when we use a reference field, a context is automatically defaulted to the user (which cannot be changed). A reference field is one of the fields from the same table.

1. How do we use Reference Field?

Ans: Reference field is defined during the DFF definition. Reference field is one of the fields from the same table. Usually, reference field chosen should be quite selective. For example, a field having 500 distinct value is not a good reference field. However, a field having around 10 distinct values or less can be a good reference field. When reference field is used in the DFF activation, we need to define structure for each of the unique value of the reference field. Once defined properly, based on the reference field, a DFF structure is automatically displayed to the user during data entry.

Concurrent Programs

In any application, transactions can be created online or in the batch mode. When it is desired to create/update data in real time, we use online processing. However when it is desired to run mass processing, it is better to do in an off-line batch mode.  

Concurrent program is a powerful feature in Oracle Applications used for running batch programs. A program is registered to run as a batch program and then is run manually or scheduled to run at the specified time. The program can be launched and then user can work on other screens. The processing of concurrent happens in the background. One can even exit the oracle applications after launching the process.

In Oracle Applications, lot of concurrent programs come seeded which can be scheduled to run periodically. An implementation team can create their custom programs and register them as concurrent programs.

You can register different kind of objects to run as concurrent programs. Some of the examples are PL/SQL procedure, a shell script, a SQL-loader script, a SQL script, Oracle report etc. A concurrent program can be individually scheduled to run at a periodic interval. It is also possible to create a group of individual programs and schedule the full group to run at regular interval.

Executable
First step in creating a concurrent program is to create an executable. Figure 1 shows the screen for registering an executables. The screen has the following fields:

Executable Name:	Unique name for the executable which could be understood by user.
Short Name:	Unique Short Name for the Executable.
Application:	Name of the Application. Application should already be registered and available in Oracle application. Application selected here is used to derive the path on Unix from where the executable will be picked up at the run-time.
Description:	Description of the executable.
Execution Method:	This is a List of Value. Choose Execution method from the List. The list contains the following choices: Host Shell Script Immediate It is not used. Java Stored Procedure Stored procedure in JAVA Java Concurrent Program Program written in JAVA Multi Language Function Execution file is an MLS function that supports running concurrent program in multiple languages. Oracle Reports Report Created in Oracle Reports tool. (The report name should be given without .rdf extension. The report should be placed under Application_Top/reports/US directory.) PL/SQL Stored Procedure Standalone procedure or a procedure in a package. In case of package, it should be given as <Package Name>.<Procedure Name>. The package or its synonym should be available in APPS schema Request Set Stage Function PL/SQL stored function that can be used to calculate the completion statuses of request set stages. Spawned Pro*C Program. Used by some standard interfaces, like AR interface. SQL*Loader SQL Loader script. Control file name should be given here without .ctl extension. The file will be picked up from Application_Top/bin directory. SQL*Plus SQL Script. The SQL script name should be given without .sql extension. The file will be picked up from Application_TOP/SQL directory. Perl Concurrent Program Program written in CGI Perl
Execution File Name:	Name of the executable file. The file should be available in the correct location as described above.
Subroutine Name:	This field is used only when execution method is spawned or immediate.

Concurrent Program Once an executable is created, we can create a concurrent program using the screen given in figure 2. We associate the executable created in the previous step to the concurrent program. We can also define different parameters to be passed to the executable here.

 

The various fields used in concurrent program definition are described below:

Program:	Name of the concurrent program.
Short Name	Short Name of the concurrent program.
Application	Choose an Application from the available list
Description	concurrent program Description
Executable	Name: Short Name of the executable which was previously registered in Executable registration screen. Method This is automatically populated when executable name is selected. Options This is automatically populated when executable short name is entered. Priority Priority of the request. It can be kept null for default priority.
Request	Type Concurrent program can be associated with a certain request type (defined separately) so that certain concurrent managers will be able to run it. Incrementor Not used MLS function This feature allows program to be submitted once but run multiple times for each language automatically. Use in SRS This is checked by default. When it is checked, the program is available to run from the standard request submission screen. Allow Disabled Values When checked, user can enter disabled values of the value-sets linked to the concurrent program parameter. Run Alone Indicates that when this program is running, no other program is allowed to be run. Restart on System Failure Enable Trace When it is checked, Program generates a trace file when run. NLS Compliant
Output	Format Format of the output to be produced. Save Indicates that output should be automatically saved in Operating system. Print If checked, output will be automatically sent to printer. Columns/Rows Number of columns and Rows in the output. Style Printer Style Style Required Printer

   

Concurrent Program Parameters

Concurrent program can have parameter values which can be entered by the user at run time. All the parameters to be passed to a concurrent program need to be defined with the concurrent program. Screen 3 shows the parameter screen, which can be invoked from Concurrent program definition screen (Figure 2).

Parameter screen contains the following fields:

Sequence Sequence Number. It can be given as 1,2,3 or 10,20,30 etc.

Parameter Name of the Parameter

Description Description of the Parameter

Enabled When checked, parameter is enabled.

Validation

 Value Set Each Parameter should have a value set. It can be user defined value set or one of the standard valueset available in Oracle Apps.

 Description This is defaulted when Value Set is selected

 Default Type and Default Value

 When it is required to default value of the parameter, the fields default type and default values can be selected. The possible values of default type field are:

• Constant

• Current Date

• Profile

• SQL Statement

• Segment

 When Constant is selected in Default Type, any constant value can be entered in Default value field.

When Current Date is selected in Default Type, then default value will be non-enterable. The current date will be automatically defaulted when running the program.

When Profile is selected in Default type, the profile option name should be entered in the default value field. For example, for getting operating unit, we can enter ORG_ID in the default value field.

When SQL Statement is selected in Default type, any SQL statement can be written in the default value field. For example, to get a particular value from a table, we can write a statement like 'SELECT set_of_books_id FROM ar_system_parameters'.  

Required When this is checked, the parameter is mandatory and must be entered during program submission.
 Enable Security
 Range

Display Check-box When checked, the parameter will be displayed during program submission.

Display Size Size of the Display field.

Description Size

Concatenated description Size

Prompt Prompt for the parameter that will appear for parameter name when running
the concurrent program.

Token Name of the token. This is used when registering Oracle Report
as a concurrent program.
The name of this field is same as the token defined in the report.

Request Group
In order to secure the running of the concurrent program, we define a request group. Usually, we would like only people having certain responsibily to run a particular concurrent program. So we create a request group and associate it with a responsibility.
Once a request group is defined, we can add any number of concurrent program to it. The concurrent programs to be added to a request group can belong to any application.

Request Set

Request set is a collection of concurrent program which are run together. In an implementation, we may have requirement to run multiple concurrent programs together one after another. In that case, those concurrent programs can be made part of a request set and then request set can be run as a whole.