AOL Concepts in Oracle Applications

OVERVIEW OF FLEXFIELD CONCEPTS

A flexfield is a field made up of sub-fields, or segments. A flexfield appears on your form as a pop-up window that contains a prompt for each segment. Each segment has a name and a set of valid values. There are two types of flexfields: key flexfields and descriptive flexfields.

BASIC FLEXFIELD CONCEPTS

Segment - A segment is a single sub-field within a flexfield. You define the appearance and meaning of individual segments when customizing a flexfield. A segment is represented in your database as a single table column.

For a key flexfield, a segment usually describes a particular characteristic of the entity identified by the flexfield. For example, you can have a key flexfield that stores part numbers. The key flexfield can contain the part number PAD-YEL-NR-8 1/2x14, which represents a yellow, narrow ruled, 8 1/2" x 14" note pad. Each section in the part number, separated by a hyphen, describes a characteristic of the part. The first segment describes the object, a note pad, the second segment describes the color of the object, yellow, and so on.

Note that we also refer to the fields in a descriptive flexfield pop-up window as segments even though they do not necessarily make up meaningful codes like the segments in key flexfields. However, they do often describe a particular characteristic of the entity identified elsewhere on the form you are using.

Values, Validation and Value Sets - Your end user enters a segment value into a segment while using an application. Generally, the flexfield validates each segment against a set of valid values (a "value set") that are usually predefined. To "validate a segment" means that the flexfield compares the value a user enters in the segment against the values in the value set for that segment.

You can set up your flexfield so that it automatically validates segment values your end user enters against a table of valid values. If your end user enters an invalid segment value, a list of valid values appears automatically so that the user can choose a valid value. You can think of a value set as a "container" for your values. You choose what types of values can fit into your value set: their length, format, and so on.

A segment is usually validated, and usually each segment in a given flexfield uses a different value set. You can assign a single value set to more than one segment, and you can even share value sets among different flexfields. For most value sets, when you enter values into a flexfield segment, you can enter only values that already exist in the value set assigned to the segment.

Structure - A flexfield structure is a specific configuration of segments. If you add or remove segments, or rearrange the order of segments in a flexfield, you get a different structure.

You can define multiple segment structures for the same flexfield (if that flexfield has been built to support more than one structure). Your flexfield can display different prompts and fields for different end users based on a data condition in your form or application data. Both key and descriptive flexfields may allow more than one structure.

In some applications, different users may need a different arrangement of the segments in a flexfield (key or descriptive). Or, you might want different segments in a flexfield depending on, for example, the value of another form or database field.

Your Oracle General Ledger application, for example, provides different Accounting Flexfield (Chart of Accounts) structures for users of different sets of books. The Oracle General Ledger application determines which flexfield structure to use based on the value of the GL Set of Books Name user profile option.

Key Flexfields - Most organizations use "codes" made up of meaningful segments (intelligent keys) to identify general ledger accounts, part numbers, and other business entities. Each segment of the code can represent a characteristic of the entity. For example, your organization might use the part number PAD-NR-YEL-8 1/2x14" to represent a notepad that is narrow-ruled, yellow, and 8 1/2" by 14". Another organization may identify the same notepad with the part number "PD-8x14-Y-NR". Both of these part numbers are codes whose segments describe a characteristic of the part. Although these codes represent the same part, they each have a different segment structure that is meaningful only to the organization using those codes.

The Oracle Applications store these "codes" in key flexfields. Key flexfields are flexible enough to let any organization use the code scheme they want, without programming.

When your organization initially installs Oracle Applications, you and your organization's implementation team customize the key flexfields to incorporate code segments that are meaningful to your business. You decide what each segment means, what values each segment can have, and what the segment values mean. Your organization can define rules to specify which segment values can be combined to make a valid complete code (also called a combination). You can also define relationships among the segments. The result is that you and your organization can use the codes you want rather than changing your codes to meet Oracle Applications' requirements.

Registration - Register a key flexfield after defining the flexfield combinations table in the database, and after registering your table with the Tables form.

Attention: Do not modify the registration of any key flexfield supplied with Oracle Applications. Doing so can cause serious application errors. To enable an Oracle Applications key flexfield, define and freeze it using the Key Flexfield Segments window.

Attention: Do not attempt to make a copy of an Oracle Applications key flexfield (using the same table, same title, or same flexfield code), since the duplicates may cause errors in forms that call these flexfields.

If you are using segment qualifiers with your flexfield, you should define the QuickCode values for your segment types using the Lookups window. You name your flexfield and associate it with an application and a database table. You also specify which table column you want to use as a unique ID column and which table column you want to use as a structure column.

Register Key Flexfields Block - Application

An application installer sees this application name when defining your flexfield segments in the Define Key Segments window. Forms and flexfield routines use the combination of application and flexfield name to uniquely identify your flexfield. You use this application name when you use flexfield routines to call your key flexfield from your forms or programs. When you upgrade to Release 10, this field initially contains "Unknown" for all previously existing key flexfields.

Code - You use this short, unique code to invoke a key flexfield from a form trigger.

Title - n installer may modify the user-friendly title of your flexfield using the Define Key Segments form. You see this title whenever you choose this flexfield in a flexfield window.

Table Application - Enter the name of the application with which your flexfield table is registered.

When you upgrade to Release 10, this field initially contains "Unknown" for all previously existing key flexfields.

Table Name - Your combinations table must already exist in the database, and it must have columns with names of the form SEGMENT1, SEGMENT2, ..., SEGMENTn. You must register your combinations table with Oracle Applications before you can use it in this field.

Unique ID Column - Enter the name of the column in your combinations table that contains the unique ID for this flexfield. Other tables which reference this flexfield should use this column as a foreign key.

Structure Column - Enter the name of the column in your combinations table that your flexfield can use to differentiate among flexfield structures. If you enter a column in this field you must also use the NUM= parameter in all of the flexfield calls in your forms.

Suggestion: We recommend that you always include a structure ID column in your database table and in your flexfield definition so that your end user can define multiple structures. You must also use the NUM= parameter in all of the flexfield calls in your forms.

Dynamic Inserts Feasible - Indicate whether dynamic inserts are feasible for this key flexfield. Dynamic inserts are feasible only if your combinations table contains no mandatory, non-flexfield columns. Dynamic inserts cannot be feasible if your application requires special validation of new segment combinations.

Allow ID Value Sets - Indicate whether to allow values sets that use a hidden ID in your flexfield.

Concatenated Segment Length - Maximum
Enter the maximum length for this flexfield.
This feature will be available in a future version of Oracle Application Object Library.

Warning - Enter a warning message for your flexfield. This feature will be available in a future version of Oracle Application Object Library.

Detail Buttons

Qualifiers - Choose this button to open the Qualifies window where you define flexfield and segment qualifiers.
Columns - Choose this button to open the Columns window where you enable the columns to use with your flexfield segments
Qualifiers Window - Define flexfield and segment qualifiers. A flexfield qualifier applies to specific segments your user define, and a segment qualifies applies to specific values in your flexfield segments. You must define a flexfield qualifier before you can define segment qualifiers.

Qualifier Name - Use this unique name to reference key flexfield structure information.

Prompt - When you set up your key segments this prompt asks you for the qualifiers information for your key flexfield. Since flexfield qualifiers use check boxes in the Define Key Segments form, you should specify your prompt so it makes sense as the prompt of a Yes/No field.

Global - Global flexfield qualifiers apply to all segments, and provide a convenient mechanism for assigning a group of segment qualifiers to all segments.
Required - Required flexfield qualifiers must apply to at least one but possibly more segments.
Unique - Unique flexfield qualifiers apply to one segment only.
Segment Qualifiers - A segment qualifier applies to specific values your end user defines using the Define Key Segment Values window. Segment qualifiers expect QuickCodes values.
Name - Use this unique name to reference key segment value information in flexfield routine calls and your application logic.

Prompt - The Define Key Segment Values window displays this prompt to ask you for information about each segment value when you define key segment values. Since segment qualifiers receive QuickCode values in the Define Key Segment Values window, you should specify your prompt so it makes sense to your end user.

Derived Column - Enter the name of a database column in your combinations table that holds the derived value of this segment qualifier. Flexfields automatically derives a value for your segment qualifier into this column whenever your end user enters a new valid combination.

QuickCode Type - Enter a Special QuickCode type for this segment qualifier. A Special QuickCode type defines the group of values you wish to allow for this segment qualifier. For example, if you have a segment qualifier called "Account Type" you might want a Special QuickCode type called "ACCOUNT_TYPE" that has several codes and meanings. You define Special QuickCode values using the Define Special QuickCodes form.

Define Special QuickCodes

Default Value - A default value must be one of the defined Special QuickCode values for the Special QuickCode type you choose in the QuickCode Type field.

Columns Window - Specify the columns your key flexfield can use as segment columns. This window automatically queries up most of the columns you registered when you registered your table. If you have recently added columns to your table, you should reregister your table to ensure you see all your columns. The table columns you specify as your unique ID column or your structure column in the Key Flexfield zone do not appear.

If your table contains columns with names of the form SEGMENT1, SEGMENT2, SEGMENT3, and so on, those columns are automatically Enabled for your flexfield. You must enable any other column you want to use for your segment columns by changing the value of the Enabled check box.

For example, if you have more than one key flexfield, your second key flexfield may have different segment column names such as TAX1, TAX2, TAX3 and TAX4. In this case, you would enable TAX1, TAX2, TAX3 and TAX4 and disable SEGMENT1, SEGMENT2, SEGMENT3, and so on for your second key flexfield.

Warning: If you are redefining the Accounting Flexfield for Oracle General Ledger (this key flexfield is used by most of the Oracle Applications products), you must not use any columns other than those named SEGMENT1 through SEGMENT30. Since the names of these columns are embedded in the Oracle Applications products, using other columns may adversely affect your application features such as summarization.

Enabled - Indicate whether this column can be used as a segment column for your key flexfield. If you enable a column as a segment column for a key flexfield, you should not enable the same column for another key flexfield that uses the same table.

DEFINING KEY FLEXFIELD STRUCTURES - Prerequisites

Use the Value Sets window to define any value sets you need.
1. Navigate to the Key Flexfield Segments window.
2. Select the application name and title of the key flexfield you want to define. You cannot create a new flexfield or change the name of an existing flexfield using this window.
3. For those application flexfields that support more than one structure (such as the multiple charts of accounts in the Accounting Flexfield), you can create a new structure for your flexfield by inserting a row. If you are defining the first structure for your flexfield, select the default flexfield structure that appears automatically. If you are modifying an existing structure, use your cursor keys to select the title of the flexfield structure you want.

You can change the title of an existing flexfield structure by typing in a new title over the old title. You see this name when you choose a flexfield structure and as the window title in your key flexfield (unless the flexfield is used for a specific purpose such as "Consolidation Account", in which case the structure title does not appear in the flexfield window).

4. If you want to generate a database view for this structure, enter a view name. Your view name should begin with a letter and must not contain any characters other than letters, numbers, or underscores ( _ ). Your view name must not contain any spaces. See: Overview of Flexfield Views.

5. Check the Enabled check box so that this structure may be used in your key flexfield. You cannot delete structures from this window because they are referenced elsewhere in the system, but you can disable them at any time. A structure must be enabled before it can be used.

You should enable at least one structure for each key flexfield. If you disable a structure that already contains data, you cannot use that structure to create new combinations or query up your old information.

6. Select the character you want to use to separate your flexfield segment values or descriptions whenever your application forms display concatenated segment values or descriptions.

You should choose your separator character carefully so that it does not conflict with your flexfield data. For example, if your data frequently contains periods ( . ) in monetary or numeric values, you should not use a period as your segment separator. If you enter a segment value that contains the segment separator character, you see the character in your value as a caret (^) so you can differentiate it from the segment separator in your concatenated value fields. This change is for concatenated display purposes only and does not affect your value. To avoid confusion, you should never use a caret (^) as your segment separator.

Warning: Some Oracle Applications tables store the segment separator as part of your flexfield values. Changing your separator once you have data in such tables may invalidate that data and cause application errors.

7. Select the Cross-Validate Segments check box if you want to cross-validate multiple segments using cross-validation rules. You can define cross-validation rules to describe valid combinations using the Cross-Validation Rules form. Uncheck the box if you want to disable any existing cross-validation rules. See: Cross-Validation Rules.

8. Indicate whether you want to freeze your rollup group definitions. If you do, you prevent users from modifying rollup groups using the Segment Values form. You can freeze rollup groups before or after you define your flexfield structure. See: Segment Values.

9. If you want to allow dynamic inserts, check the Allow Dynamic Inserts check box. You would allow dynamic inserts of new valid combinations into your generic combinations table if you want users to create new combinations from windows that do not use your combinations table. You should prevent dynamic inserts if you want to enter new valid combinations only from a single application window you create to maintain your specific combinations table.

You can update this field only if your application flexfield has been built to allow dynamic inserts. Otherwise this field is display only.

10. Choose the Segments button to open the Segments Summary window, and define your flexfield segments. See: Defining Segments.

11. Freeze your flexfield structure by checking the Freeze Flexfield Definition check box.

Do not freeze your flexfield if you want to set up or modify your flexfield segments or change the appearance of your key flexfield window. You cannot make most changes while your flexfield is frozen.

12. Compile your frozen flexfield by choosing the Compile button. Your changes are saved automatically when you compile.

You must freeze and compile your flexfield definition before you can use your flexfield. If you have more than one flexfield structure, you must freeze, save, and compile each structure separately. If you decide to make changes to your flexfield definition, make sure that you freeze and save your flexfield definition again after making your changes.

Warning: Do not modify a frozen flexfield definition if existing data could be invalidated. An alteration of the flexfield structure once you have any flexfield data can create serious data inconsistencies. Changing your existing structures may also adversely affect the behavior of any cross-validation rules or shorthand aliases you have for your structures, so you should be sure to manually disable or redefine any cross-validation rules and shorthand aliases to reflect your changed structures.

Defining segments - Use the Segments window to define segments for your flexfield. The window title includes the current flexfield's name. If your flexfield definition is frozen (that is, the Freeze Flexfield Definition check box is checked), this window prevents you from invalidating your existing flexfield data by not allowing you to enter the Enabled field or the Value Set field.

You can define as many segments as there are defined segment columns in your flexfield table. You can create a new segment for your flexfield by inserting a row.

Prerequisites - Use the Key Flexfield Segments window or the Descriptive Flexfield Segments window to define your flexfield structure.

To define segments:

1. Enter a name for the segment that you want to define.

Your segment name should begin with a letter and use only letters, numbers, spaces or underscores ( _ ). The segment prompts get their default values from this field. The flexfield view generator will use your segment name as a column name and change all spaces and special characters to underscores ( _ ). See: Segment Naming Conventions.

2. Indicate that you can use this flexfield segment by checking the Enabled check box.

Your flexfield does not display disabled segments. You can define as many segments as there are defined segment columns in your key flexfield combinations table.

Suggestion: To protect the integrity of your data, you should not disable a segment if you have already used it to enter data.

3. Select the name of the column you want to use for your flexfield segment.

Suggestion: If you are defining more than one segment in the same structure at one time, ensure that you use unique columns for each segment. If you attempt to use a single column for more than one segment in the same structure, you cannot save your changes or compile your structure. Columns you choose for your segments do not disappear from your list of values until you save your work.

4. Enter the segment number for this segment.

This number indicates the relative position in which this segment appears in a flexfield window. A segment with a lower segment number appears before a segment with a higher segment number. Dependent segments should occur after the segment they depend upon in the flexfield window.

You receive a warning message if you enter a segment number that is already defined for your flexfield. This warning is only a reminder that the segment number is in use. If you attempt to freeze a flexfield in which two segments share the same segment number, the flexfield does not compile.

Suggestion: For most flexfields, if you give your segments widely spaced numbers (such as 10, 20, 30...) to indicate their relative positions, you can add segments to your structure more easily. Adding segments still disables all your existing cross-validation rules and shorthand aliases for this flexfield structure, however. Note that the Accounting Flexfield requires consecutive segment numbers beginning with 1 (such as 1, 2, 3, ...).

Warning: Changing the order of your segments invalidates all existing cross-validation rules and shorthand aliases for this flexfield structure.

5. Indicate whether you want this segment to appear in the flexfield window. If your segment is not displayed, you should provide a default type and value so that the user does not need to enter a value for this segment. If you do not display a segment but also do not provide a default value for it, your users may see error messages when using this flexfield.

Warning: If you are defining the Accounting Flexfield, you must display all segments. Hiding segments will adversely affect your application features such as Mass Allocations.

6. If you are defining the Accounting Flexfield, decide whether you should check the Indexed check box. If you are defining any other Oracle Applications (key) flexfield, you can skip the Indexed check box.

The Oracle General Ledger applications use the Indexed field for the Optimization feature. What you enter here does not affect Oracle Applications key flexfields other than the Accounting Flexfield, but the value may or may not affect key flexfields in custom applications (depending on whether those applications have logic that uses the value of this field).

Indicate whether you want the database column in the combinations table used to store this key segment to have a single-column index. You should create indexes on segments you expect to have many distinct values (instead of just a few distinct values). The Oracle General Ledger products' Optimizer does not drop existing indexes.

If you set up a new structure of the same flexfield, this value defaults to the value in the first structure you set up.

7. Enter the name of the value set you want your flexfield to use to validate this segment
8. Indicate whether you want to require a value for this segment. If you do, users must enter a value before leaving the flexfield window. If not, the segment is optional.

Attention: All segments in your Accounting Flexfield must be required.

If this segment is required but depends on an optional segment, then this segment will become optional if a user leaves the depended-upon segment blank.

9. Indicate whether to allow security rules to be used for this segment. Otherwise any defined security rules are disabled.

If the value set for this segment does not allow security rules, then this field is display only.

10. If you want your flexfield to validate your segment value against the value of another segment in this structure, then choose either Low or High in the Range field. Segments with a range type of Low must appear before segments with a range type of High (the low segment must have a lower number than the high segment). For example, if you plan two segments named "Start Date" and "End Date," you may want to require users to enter an end date later than the start date. You could have "Start Date" be Low and "End Date" be High. In this example, the segment you name "Start Date" must appear before the segment you name "End Date," or you cannot compile your flexfield.

If you choose Low for one segment, you must also choose High for another segment in that structure (and vice versa). Otherwise you cannot compile your flexfield.

If your value set is of the type Pair, this field is display only, and the value defaults to Pair.

11. Enter the display size and prompt information for the segment

DEFINING SHORTHAND ALIASES

To define shorthand aliases:

1. Navigate to the Shorthand Aliases window.
2. Select the name and structure of the key flexfield for which you want to define shorthand aliases.
3. Enter an alias, which serves as a "name" for a combination or partial combination. A shorthand alias can be any combination of characters.
4. In the Template field, enter either an entire flexfield combination or the pattern of segment values that your alias represents.

Your flexfield validates each segment value you enter but does not check whether the combination is a valid combination (if you enter an entire combination).

If you want to enter a value for a segment that depends on another segment, you must first enter a value into the corresponding independent segment.

5. If you want to have the alias effective for a limited time, you can enter a start date and/or an end date for the alias. The alias is valid for the time including the From and To dates.
6. Save your changes.

ENABLING SHORTHAND ENTRY

To enable shorthand entry:

1. Navigate to the Shorthand Aliases window.
2. Select the name and structure of the key flexfield for which you want to enable shorthand entry.
3. Check the Enabled check box in the Shorthand region.
4. Enter a prompt for the shorthand window.
5. Enter the maximum alias size, which determines the maximum length of your shorthand aliases.
6. Save your changes.

Whenever you enable or disable shorthand entry, you must also recompile your key flexfield using the Key Flexfield Segments window. On a user-by-user basis, you can enable or disable shorthand flexfield entry for yourself (for all key flexfields that use it) by setting your user profile option Flexfield: Shorthand Entry to an appropriate value. Your System Administrator can set this profile option at other levels (such as for a responsibility).

However, in some forms, such as forms where you define new key flexfield combinations (combinations forms), you do not see the shorthand window even if shorthand entry is enabled. For example, you cannot use shorthand entry in the Oracle General Ledger Define Accounting Flexfield Combinations form.

DEFINING CROSS-VALIDATION RULES - Use the Key Flexfield Segments window to define your flexfield structure and segments and specify Yes in the Cross-Validate Multiple Segments field for your flexfield structure.

Define your values. - To define cross-validation rules:

1. Select the name and structure of your key flexfield for which you wish to define cross-validation rules. Your list only contains structures with the field Cross-Validate Multiple Segments set to Yes on the Key Flexfield Segments window.
2. Enter a unique name and a description for your cross-validation rule.
3. Enter your error message text for this cross-validation rule.

Your flexfield automatically displays this error message on the message line whenever a new combination of segment values violates your cross-validation rule. You should make your error messages as specific as possible so that your users can correct any errors easily.

4. Enter the name of the segment most likely to have caused this cross-validation rule to fail. Your flexfield leaves the cursor in this segment whenever a new segment combination violates this cross-validation rule to indicate where your user can probably correct the error. If you do not specify an error segment name, your flexfield leaves the cursor in the first segment of the flexfield window following a violation of this rule.

5. If you want to have the rule effective for a limited time, you can enter a start date and/or an end date for the rule. The rule is valid for the time including the From and To dates.

6. Define the cross-validation rule elements that make up your rule.

CROSS-VALIDATION RULES WINDOW

Your flexfield checks cross-validation rules while attempting to create a new combination of flexfield values (for example, a new Accounting Flexfield combination). Your cross-validation rules have no effect on flexfield combinations that already exist. If you want to disable an existing combination, you must disable that combination specifically using the appropriate window. For example, you can disable an existing Accounting Flexfield combination using the Define Accounting Flexfield Combinations window.

Suggestion: We recommend that you define many rules that each have few rule elements rather than a few rules that each have many rule elements. The more rules you provide, the more specific you can make your error message text.

Your flexfield checks cross-validation rules only if you set Cross-Validate Multiple Segments to Yes using the Define Key Flexfield Segments window.

If you make changes to your cross-validation rules, you need to either change responsibilities or exit from your application and sign on again in order for the changes to take effect.

VALUES - SEGMENT VALUES WINDOW

Use this window to define valid values for a key or descriptive flexfield segment or report parameter. You must define at least one valid value for each validated segment before you can use a flexfield. These validated segments provide users with a list of predefined valid segment values, and have a validation type of Independent, Dependent, or Table.

You should use this window to define values that belong to independent or dependent value sets. You can define new segment values, specify value descriptions for your values and to enable or disable existing values as well.

The values you define for a given flexfield segment automatically become valid values for any other flexfield segment that uses the same value set. Many Oracle Applications reports use predefined value sets that you may also use with your flexfield segments. If your flexfield segment uses a value set associated with a Standard Request Submission report parameter, creating or modifying values also affects that parameter. If you use the same value set for parameter values, the values you define here also become valid values for your report parameter. You also specify segment value qualifiers, rollup groups, and child value ranges.

You can also view and maintain segment value hierarchies for the Accounting Flexfield or for any custom application flexfields that use the value hierarchies feature.

Attention: Because the Accounting Flexfield is the only Oracle Applications key flexfield that uses the parent, rollup group, hierarchy level and segment qualifier information, you need only enter this information for values that are associated with your Accounting Flexfield.

When you make changes to your value hierarchies, you automatically submit a concurrent request to rebuild your value hierarchies. One request per value set that the change affects (the value set attached to the segment for which you are defining or maintaining values) is submitted. For example, if you make hierarchy structure changes for five different key flexfield segments, all of which use different value sets, this window submits five concurrent requests.

Suggestion: For ease of maintenance, you should carefully plan your value hierarchy structures before you define your values, so that your structures follow a logical pattern you can expand later as you need more values.

To prevent invalidation of any existing data, you cannot update segment qualifier information for existing values unless you first unfreeze any key flexfield structure that use this value set. You unfreeze your key flexfield using the Define Key Flexfield Segments form.

Attention: You cannot modify values for a value set if that value set is currently being modified by another user, either using a version of the Segment Values Window (either the character mode or GUI version) or the Account Hierarchy Editor with Oracle General Ledger. If you get a message saying that the value set is already being modified, you can try again at a later time.

If your value set is based on a flexfield validation table (validation 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. This window stores your parent values and rollup groups for you and does not add them to your validation table. You can define child value ranges for the parent values you define, and you can assign your parent values to rollup groups. The values in your validation table can be child values, but they cannot be parent values, and you cannot assign them to rollup groups. You cannot create new values in your validation table using this window.

ROLL UP GROUPS - DEFINE ROLLUP GROUPS

Prerequisites

Use the Value Set window to define your independent value sets, any dependent value sets that depend on them, and any table-validated value sets your flexfield needs. Use the Key Flexfield Segments window to define your key flexfield structure and segments.

To define rollup groups:

1. Enter a name and description for your rollup group.
2. Save your changes.
3. Apply your rollup group name to particular values using the Segment Values window.

ROLLUP GROUPS WINDOW

Use this window to define rollup groups to which you can assign key flexfield values. You can use a rollup group to identify a group of parent values for reporting or other application purposes. You assign key flexfield segment values to rollup groups using the Segment Values window.

In Oracle Applications, only the Accounting Flexfield uses rollup groups. Rollup groups are used to create summary accounts for reporting purposes.

DESCRIPTIVE FLEXFIELDS - Descriptive flexfield segments

Descriptive flexfields have two different types of segments, global and context-sensitive, that you can decide to use in a descriptive flexfield structure.

A global segment is a segment that always appears in the descriptive flexfield pop-up window, regardless of context (any other information in your form). A context-sensitive segment is a segment that may or may not appear depending upon what other information is present in your form.

Context-sensitive segments

If you have context-sensitive segments, your descriptive flexfield needs context information (a context value) to determine which context-sensitive segments to show. A descriptive flexfield can get context information from either a field somewhere on the form, or from a special field (a context field) inside the descriptive flexfield pop-up window. If the descriptive flexfield derives the context information from a form field (either displayed or hidden from users), that field is called a reference field for the descriptive flexfield.

A context field appears to an end user to be just another segment, complete with its own prompt. However, a context field behaves differently from a normal flexfield segment (either global or context-sensitive). When a user enters a context value into the context field, the user then sees different context-sensitive segments depending on which context value the user entered. You define a context field differently as well. You use a context field instead of a reference field if there is no form field that is a suitable reference field, or if you want your user to directly control which context-sensitive segments appear.

In character-mode forms, global segments appear immediately when the descriptive flexfield window opens, and they appear in the first part of the pop-up window. A context-sensitive segment appears once the appropriate context information is chosen. The context-sensitive segments may appear immediately if the appropriate context information is derived from a form field before the user enters the descriptive flexfield.

For a descriptive flexfield with context-sensitive segments, a single "structure" consists of both the global segments plus the context-sensitive segments for a particular context field value. That is, a structure consists of all the segments that would appear in the pop-up window at one time (after the structure has been chosen).

REGISTER DESCRIPTIVE FLEXFIELDS

Register your flexfield after adding the descriptive flexfield columns to your table and registering your table. You must register a descriptive flexfield before you can use it in an application. Use this window to provide information about your descriptive flexfield. Give your flexfield a name and associate it with an application and a database table. Also specify which table column you want to use as a structure column.

Register Descriptive Flexfields Block - Forms and flexfield routines use the combination of application name and flexfield name to uniquely identify your flexfield.

Application

An application installer sees this application name when defining your descriptive flexfield in the Define Descriptive Segments window. Use this application name when you use flexfield routines to call your descriptive flexfield from your forms or programs.

When you upgrade to Release 10, this field initially contains "Unknown" for all previously existing descriptive flexfields.

Name

Use this name when you use flexfield routines to call your descriptive flexfield from your forms or programs.

When you upgrade to Release 10, this field initially contains the name of the flexfield table for all previously existing descriptive flexfields.

Title

Flexfields displays this unique title at the top of the flexfield window when your users enter your descriptive flexfield. An application installer can modify this title using the Define Descriptive Segments window.

When you upgrade to Release 10, this field initially contains "Unknown" for all previously existing descriptive flexfields.

Table Name

Enter the name of the table that contains your descriptive flexfield columns. Your table must already exist in the database, and it should already have columns for your descriptive flexfield segments, as well as a structure column. These segment columns are usually called ATTRIBUTE1, ATTRIBUTE2, ..., ATTRIBUTEn.

You must register your table with Oracle Applications before you can use it in this field.

Structure Column

Enter the name of the column, such as ATTRIBUTE_CATEGORY, in your table that your flexfield uses to differentiate among descriptive flexfield structures. Your descriptive flexfield uses this column to let your users see different descriptive flexfield structures based on data supplied by the form or the user. You must have a structure column even if you only intend to use one descriptive flexfield structure.

Context Prompt

Enter a default context field prompt that asks your user which descriptive flexfield structure to display. Depending upon how your application installer defines your descriptive flexfield, your user may or may not see a context field as part of the descriptive flexfield pop-up window. Descriptive flexfield windows display this context field prompt if the installer allows the end user to override the default context field value.

If your application installer defines it, the context field appears to the user as if it were simply another flexfield segment (with the prompt you specify here). Your user enters a value in the context field, and other descriptive flexfield segments pop up based on that value. The installer can modify the context field prompt using the Define Descriptive Segments window.

Detail Buttons

Reference Fields Choose this button to open the Reference Fields window where you select possible reference fields for your descriptive flexfield.
Columns Choose this button to open the Columns window where you enable table columns for your descriptive flexfield segments.

Reference Fields Window - Use this window to specify any form fields that might serve as descriptive flexfield reference fields. Your flexfield can use values in one of these fields (context field values) to determine which flexfield structure to display.

An installer using the Define Descriptive Segments window can choose to use one of these window fields to obtain the context field value for your descriptive flexfield.

You should specify all form fields that contain information an installer might use to obtain a context field value. For example, the descriptive flexfield in an application form may be used to capture different information based on which country is specified in a field on that form, or based on a name specified in another field. In this case, both the country field and the name field should be listed as potential reference fields, and the installer can decide which reference field to use (or neither).
An installer typically defines different structures of descriptive flexfield segments for each value that the reference field would contain. Though the installer does not necessarily define a structure for all the values the reference field could contain, a field that has thousands of possible values may not be a good reference field. In general, you should only list fields that will contain a relatively short, static list of possible values, such as a field that offers a list of countries.

A good reference field usually has a defined List of Values. You should not list fields that could contain an infinite number of unique values, such as a PO Number field. Often the business uses of the particular form dictate which fields, if any, are acceptable reference fields.

Suggestion: A descriptive flexfield can use only one form field as a reference field. You may derive the context field value for a descriptive flexfield based on more than one field by concatenating values in multiple fields into one form field and using this concatenated form field as the reference field. You may specify additional fields to be available as reference fields even after you have registered your flexfield.

Attention: This zone will not be included in a future release of the Oracle Applications. An installer will be able to use any field of the form (that contains the flexfield) as a reference field.

Field Name

Enter the name of a reference field your flexfield can use to obtain context field values.

Enter the actual (hidden) Oracle Forms name of the field, rather than the boilerplate name of the field (the field prompt). Do not include the block name. The Define Descriptive Segments window displays this field name in a list an installer sees when defining descriptive flexfield segments.

This field must exist in the same block as the descriptive flexfield. In addition, if you call your descriptive flexfield from several different forms or zones, the same field must exist in all form blocks that contain this descriptive flexfield.

Description

Since the actual Oracle Forms field names often do not match the boilerplate prompts for your fields, we recommend that you enter the visible field prompt as part of your description of your context reference field so an installer can easily tell which field to define as the reference field for your descriptive flexfield.

Columns Window

Use this window to specify the columns your descriptive flexfield can use as segment columns. When you navigate into this block, this window automatically queries up most of the columns you registered when you registered your table.

If you have recently added columns to your table, you should reregister your table to ensure you see all your columns in this zone. This window does not display the table column you specify as your structure column in the Descriptive Flexfield zone.

If your table contains columns with names ATTRIBUTE1, ATTRIBUTE 2, ATTRIBUTE3, and so on, those columns are automatically Enabled. To use other columns for your flexfield segments, you must set explicitly enable them.

For example, if you have more than one descriptive flexfield, your second descriptive flexfield may be a protected descriptive flexfield with different segment column names such as TAX1, TAX2, TAX3 and TAX4. In this case, you would enable TAX1, TAX2, TAX3 and TAX4 and disable ATTRIBUTE1, ATTRIBUTE 2, ATTRIBUTE3, and so on for your protected descriptive flexfield.

Enabled

Indicate whether this column can be used as a segment column for your descriptive flexfield. If you enable a column as a segment column for a descriptive flexfield, you should not enable the same column for another descriptive flexfield that uses the same table.

Any columns you enable here appear when an installer defines segments using the Define Descriptive Segments window.

SEGMENTS

Some descriptive flexfields in Oracle Applications are documented explicitly with specific setup suggestions, but most descriptive flexfields in Oracle Applications, which are meant to be set up on a site-by-site basis, are not explicitly documented. In most cases, you can identify which descriptive flexfield appears on a particular form using the following procedure.

CONCURRENT PROCESSING

This section explains how a request to run a concurrent program is handled by Oracle Applications, and what the life cycle of a concurrent request is.

In Oracle Applications, concurrent processing simultaneously executes programs running in the background with online operations. As System Administrator, you can manage when programs are run and how many operating system processes Oracle Applications devotes to running programs in the background.

Concurrent Requests, Programs, and Processes

When a user runs a report, a request to run the report is generated. The command to run the report is a concurrent request. The program that generates the report is a concurrent program

Concurrent Managers start concurrent programs

Every time your users request a concurrent program to be run, their request is inserted into a database table, and is uniquely identified by a request ID. Concurrent managers read requests from this table.

Part of a manager's definition is how many operating system processes it can devote to running requests. This number is referred to as the manager's number of target processes.

Running concurrent programs

A concurrent program actually starts running based on:

· When it is scheduled to start
· Whether it is placed on hold,
· Whether it is incompatible (cannot run) with other programs
· Its request priority

Concurrent Request Priorities

The priority of a concurrent request is determined by application username, and is set by the System Administrator using the Concurrent:Priority user profile option.

The first available concurrent manager compares the request's priority to other requests it is eligible to process, and runs the request with the highest priority.

When choosing between requests of equal priority, the concurrent manager runs the oldest request first.




Parent requests and Child requests

Often, several programs may be grouped together, as in a request set. Submitting the request set as a whole generates a request ID, and as each member of the set is submitted it receives its own request ID. The set's request ID identifies the Parent request, and each of the individual programs' request ID identifies a Child request.

LIFE CYCLE OF A CONCURRENT REQUEST

A concurrent request proceeds through three, possibly four, life cycle stages or phases:


Pending Request is waiting to be run
Running Request is running
Completed Request has finished
Inactive Request cannot be run

Within each phase, a request's condition or status may change. Below appears a listing of each phase and the various states that a concurrent request can go through.

Concurrent Request Phase and Status

PHASE STATUS DESCRIPTION

PENDING Normal Request is waiting for the next available manager.
Standby Program to run request is incompatible with other program(s) currently running.
Scheduled Request is scheduled to start at a future time or date.
Waiting A child request is waiting for its Parent request to mark it ready to run. For example, a report in a report set that runs sequentially must wait for a prior report to complete.

RUNNING Normal Request is running normally.
Paused Parent request pauses for all its child requests to complete. For example, a report set pauses for all reports in the set to complete.
Resuming All requests submitted by the same parent request have completed running. The Parent request is waiting to be restarted.
Terminating Running request is terminated, by selecting Terminate in the Status field of the Request Details zone.

COMPLETED Normal Request completes normally.
Error Request failed to complete successfully.
Warning Request completes with warnings. For example, a report is generated successfully but fails to print.
Cancelled Pending or Inactive request is cancelled, by selecting Cancel in the Status field of the Request Details zone.
Terminated Running request is terminated, by selecting Terminate in the Status field of the Request Details zone.

INACTIVE Disabled Program to run request is not enabled. Contact your system administrator.
On Hold Pending request is placed on hold, by selecting Hold in the Status field of the Request Details zone.
No Manager No manager is defined to run the request. Check with your system administrator.

OVERVIEW OF CONCURRENT PROGRAMS AND REQUESTS

A concurrent program is an executable file that runs simultaneously with other concurrent programs and with online operations, fully utilizing your hardware capacity. Typically, a concurrent program is a long-running, data-intensive task, such as posting a journal or generating a report.

Request Groups and Request Sets

Reports and concurrent programs can be assembled into request groups and request sets.

· A request group is a collection of reports or concurrent programs. A System Administrator defines report groups in order to control user access to reports and concurrent programs. Only a System Administrator can create a request group.

· Request sets define run and print options, and possibly, parameter values, for a collection of reports or concurrent program. End users and System Administrators can define request sets. A System Administrator has request set privileges beyond those of an end user.

Standard Request Submission and Request Groups

Standard Request Submission is an Oracle Applications feature that allows you to select and run all your reports and other concurrent programs from a single, standard form. The standard submission form is called Submit Requests, although it can be customized to display a different title.


· The reports and concurrent programs that may be selected from the Submit Requests form belong to a request security group, which is a request group assigned to a responsibility.

· The reports and concurrent programs that may be selected from a customized Submit Requests form belong to a request group that uses a code.

In summary, request groups can be used to control access to reports and concurrent programs in two ways; according to a user's responsibility, or according to a customized standard submission (Run Requests) form.

DEFINING PROGRAM INCOMPATIBILITY RULES

Incompatible and Run Alone Programs

When a concurrent program is incompatible with another program, the two programs cannot access or update the same data simultaneously. When you define a concurrent program, you can list those programs you want it to be incompatible with. You can also list the program as incompatible with itself, which means that two instances of the program cannot run simultaneously. You can also make a program incompatible with all other concurrent programs by defining the program to be run-alone.

You define a concurrent program to be run-alone or to be incompatible with specific concurrent programs by editing the concurrent program's definition using the Concurrent Programs window. See: Concurrent Programs.

An applications database account in which a concurrent program accesses or updates data and where program incompatibility and run-alone program definitions are enforced is referred to as a logical database.

Request Sets - Incompatibilities Allowed

When you define a request set, you create a concurrent program that runs the reports in your request set according to the instructions you entered. Using the Concurrent Programs window, when you list programs as incompatible with a request set, those programs are prevented from starting until all the reports in the set have completed running.

To define incompatibility rules for a request set:

· Check the Incompatibilities Allowed check box on the Request Set window.
· Navigate to the Incompatible Programs block in the Concurrent Programs form and list those programs that your request set is incompatible with.

All concurrent programs that run request sets are titled Request Set . In the Concurrent Programs form, if you query a request set concurrent program on the basis of the program's name, you must enter in the Name field the words:

· "Request Set" before the name of a concurrent program
· "Request Set %" to perform a query on all request set programs

REQUEST SET INCOMPATIBILITIES

A request set is actually a concurrent program that submits requests to run each program in the request set. You can allow incompatibility rules to govern your request set so that the request set does not run at the same time as other reports or concurrent programs.

Use the Concurrent Programs form to query the request set concurrent program and list those programs you want to define as incompatible with your request set.

All concurrent programs that run request sets are titled Request Set . In the Concurrent Programs form, if you query a request set concurrent program on the basis of the program's name, you must enter in the Name field the words:

"Request Set" before the name of a concurrent program
"Request Set %" to perform a query on all request set programs

When you list a program as incompatible with your request set, the program will not run simultaneously within the same logical database as the request set or any of the reports within the set.

Using Data Groups for cross-application reporting

A data group is a list of applications and the Oracle username associated with each application. Each responsibility has its own data group.

When a concurrent manager runs a report, it refers to your responsibility's data group to match the application that owns the report with a unique Oracle username.

Using data groups, you can select the Oracle username in which your report runs. You can let users run requests owned by an application other than the application associated with the user's responsibility, for example:

· you can let a user of an Oracle General Ledger responsibility run an Oracle Payables report in the Oracle Payables Oracle username.

· since you are using the Submit Requests form in the General Ledger Oracle username, the General Ledger Oracle username must have SELECT privileges on any Oracle Payables validation tables needed to validate report parameters

LOGICAL DATABASES

If two programs are defined as incompatible with one another, the data these programs cannot access simultaneously must also be identified.

In other words, to prevent two programs from concurrently accessing or updating the same data, you have to define where, in terms of data, they are incompatible. A logical database identifies the data where two incompatible programs cannot run simultaneously.

Oracle Usernames

In Oracle Applications, data is stored in database tables that belong to a particular application. Database privileges are determined by an application's Oracle username.

· An Oracle username and password allows access to an application's tables in an Oracle database. An Oracle username determines the database tables and table privileges accessible by the corresponding application.

You identify data where incompatible programs cannot run simultaneously by assigning Oracle usernames to belong to a logical database. You create a logical database name using the Logical Databases window, and you assign Oracle usernames to a logical database using the ORACLE Users window.

DATA GROUPS WINDOW

Use this window to define data groups. A data group is a list of Oracle Applications and the ORACLE usernames assigned to each application.

· If a custom application is developed with Oracle Application Object Library, it may be assigned an ORACLE username, registered with Oracle Applications, and included in a data group.

An ORACLE username allows access to an application's tables in an ORACLE database. All data groups automatically include an entry for Application Object Library.

· A concurrent manager running reports or programs under Oracle Applications refers to a data group to identify the ORACLE username it uses to access an application's tables in the database.

· Transaction managers running synchrous programs can only run programs submitted from responsibilities assigned the same data group as the transaction manager. If you create custom data groups, you should create new transaction managers for the applications that use transaction managers. Consult your product documenation to determine if your application uses transaction managers.

Each responsibility within Oracle Applications is assigned a data group.

During installation or upgrading of Oracle Applications, a standard data group is defined, pairing each installed application with an ORACLE username (note: a standard data group is defined for each set of books). You cannot change or delete the predefined values for Application or ORACLE username in a Standard data group. However, you may:

· Modify the Tool ORACLE username and description associated with an Application-ORACLE username pair.
· Add new Application-ORACLE username pairs to the group.

Data Groups Block

Create a new data group, or modify an existing data group.

You cannot change or delete the predefined values for Application or ORACLE username in a Standard data group. However, you may modify the Tool ORACLE username and description, or add new Application-ORACLE username pairs to a Standard group.

Data Group

A data group is uniquely identified by its name. You cannot create a data group with a name already in use. Once saved, data group names cannot be edited. Application-ORACLE Username Pairs Block

Pair applications with ORACLE usernames.

When you copy a data group, each application, its assigned ORACLE username, and, if present, its Tool ORACLE username and description, appear in this zone automatically. All data groups automatically include an entry for Application Object Library.

Application

Within each data group, an application can be listed only one time.

Oracle User Name


Tool

A Tool ORACLE username can be added to each application-ORACLE username pair within a data group. A Tool ORACLE username identifies an ORACLE account that users can automatically connect to when using an Oracle Tool, for example, SQL*Plus. Users select the Oracle Tools window from the standard Oracle Applications menu.

Attention: The Oracle Tools window may not be available on your desktop platform. The Oracle Tools window is primary for the character mode environment.

When a responsibility is defined, a data group is chosen, and an application within the data group is selected for the responsibility's forms to connect to.

· When a Tool ORACLE username is associated with that application, users of an Oracle Tool can connect to that ORACLE account without entering a username and password.

· If a Tool ORACLE username is not associated with that application, then users of an Oracle Tool must enter a username and password to obtain access to an ORACLE account.

Attention: You cannot select a Tool ORACLE username to associate with Application Object Library. The Application Object Library-ORACLE username pair is inserted into each data group, and cannot be updated or deleted.

Suggestion: You should assign a Tool ORACLE username that is restricted (read-only).

Warning: Modifying data or table structures using an Oracle Tool, for example, SQL*Plus, may damage your data's integrity and is not supported by Oracle.

Copy Applications From...

Use this button to copy an existing data group, then add or delete application-ORACLE username pairs to create a new data group.

MODIFYING DATA GROUPS

Predefined Standard Data Groups

During installation or upgrade of Oracle Applications, a standard data group is defined that pairs each installed application with an ORACLE username (note: this occurs for each set of books).

You cannot change or delete the predefined values for Application or ORACLE username in a Standard data group. However, you may modify the Tool ORACLE username and description, or add new Application-ORACLE username pairs to the group.

Defining new Data Groups

Since the installation process automatically defines Data Groups for Oracle Applications, you only need to define any additional data groups you wish to utilize.

You can copy a data group and give it a new name, creating a new data group. Each application, its assigned Oracle username, and, if present, its Tool Oracle username and description, are copied to the new data group.

Suggestion: Make a backup copy of your standard Data Group, and do not assign it to a responsibility. That way, if you ever inadvertently connect the wrong Oracle username to an application, or lose track of your applications' configuration, you have an initial configuration you can revert to.

Adding a custom application to a Data Group

If a custom application is developed with Oracle Application Object Library, to include it in a Data Group, you:

· Register the application with Oracle Applications using the Applications form
· Assign an Oracle username to the application using the ORACLE Usernames form

Registering an Oracle Username

Registering an Oracle username with Oracle Applications sets up the privileges to the Oracle Application Object Library database tables (such as flexfield tables, menu tables, and so on) that are necessary to successfully use Oracle Applications.

EXECUTABLE

Define a concurrent program executable for each executable source file you want to use with concurrent programs. The concurrent program executable links your source file logic with the concurrent requests you and your users submit to the concurrent manager. The Installation Guide for your operating system details where to place the execution files for each execution method.

Attention: You cannot add new immediate programs to a concurrent manager program library. We recommend that you use spawned concurrent programs instead.

Concurrent Program Executable Block

The combination of application name plus program name uniquely identifies your concurrent program executable.

CONCURRENT PROGRAM EXECUTABLE WINDOW

Executable

Enter a name for your concurrent program executable. In the Concurrent Programs window, you assign this name to a concurrent program to associate your concurrent program with your executable logic.

Application

The concurrent managers use the application to determine in which directory structure to look for your execution file.

Execution Method

The execution method cannot be changed once the concurrent program executable has been assigned to one or more concurrent programs in the Concurrent Programs window. The possible execution methods are:


FlexRpt The execution file is wrnitten using the FlexReport API.
FlexSql The execution file is written using the FlexSql API.
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 script.
SQL*Report The execution file is a SQL*Report script.
Spawned The execution file is a C or Pro*C program.
Immediate The execution file is a program written to run as a subroutine of the concurrent manager. We recommend against defining new immediate concurrent programs, and suggest you use either a PL/SQL Stored Procedure or a Spawned C Program instead.
Execution File Name

Enter the operating system name of your execution file. Some operating systems are case sensitive, so the name entered here should match the file name exactly.

Do not include spaces or periods (.) in the execution file name, unless the execution method is PL/SQL stored procedure. See the Oracle Applications Installation Guide for details on the path Oracle Applications uses to find each executable file.

The maximum size of an execution file name is 30 characters.

Subroutine Name

Enter the name of your C or Pro*C program subroutine here. Do not use spaces or periods (.) in this field. Only immediate programs or spawned programs using the Unified C API use the subroutine field. We recommend against defining new immediate concurrent programs, and suggest you use either a PL/SQL Stored Procedure or a Spawned C Program instead.

Concurrent Program Libraries

Register program libraries, which are lists of immediate concurrent programs that you wish to link with a concurrent manager. Concurrent managers use the programs in a program library to run their immediate programs. You must register libraries before you can define concurrent managers. You can only include immediate-type concurrent programs in program libraries.

After adding any immediate concurrent program to your library or creating a new library, you must rebuild and relink your library before your changes take effect. After you rebuild and relink your library, the system administrator must restart the concurrent manager using your library.

You can only register program libraries that you have already built at the operating system level.

Prerequisites

· Use the Applications window to register your application with Oracle Application Object Library.
· Use the Concurrent Program Executables window to define your concurrent program executable file.

Concurrent Program Libraries Block

The combination of application name plus library name uniquely identifies your set of programs.

Library Name

This is the same name you gave to your program library file at the operating system. The library name must be eight characters or less.

System administrators can then assign this library name to concurrent managers. Each concurrent manager is linked to one program library and can only run immediate-type programs that use concurrent program executables that are part of that library. A concurrent manager can run other execution type programs that are not in its program library.

APPLICATION

The bin directory under this application's top directory should contain the executable program library file.

Library Type

There are two types of program library you can define:

Concurrent Library A library of immediate concurrent programs to link with a concurrent manager.
Transaction Library A library of transaction programs to link with a transaction manager.

Concurrent Programs Block

List the concurrent program executables you have linked to this program library at the operating system level.

Program

Enter the name of an immediate-type concurrent program executable that you linked into your program library at the operating system. This block verifies that the program name and application name you specify uniquely identify a defined concurrent program executable.

Application

This is the application to which your concurrent program belongs.

Rebuild Button

Select this button when you need to rebuild your concurrent library. You should rebuild your library whenever you add new programs to your library.

Applications Window

You can use your custom application to name your custom menus, concurrent programs, custom responsibilities, and many other custom components.

When you define a custom application, you supply several pieces of information to Oracle Applications. First, you name the new application with the specified terms for users, hidden application fields and messages. Then, you define how to find the files associated with your custom application.

You can use your custom application to name your custom menus, concurrent programs, custom responsibilities, and many other custom components. For some objects, the application part of the name only ensures uniqueness across Oracle Applications. For other components, the application you choose has an effect on the functionality of your custom object.

Prerequisites

· Define an environment variable that translates to your application's basepath (see the Oracle Applications Installation Guide for your operating system).

Applications Block

When you register a custom application, you provide the information Oracle uses to identify it whenever you reference it. Although you can change the name of an application, doing so may cause a change in the application code where you hardcode your application name. For example, if you pass program arguments through the menu that have application name hardcoded, you will also have to update them.

Attention: You should not change the name of any application that you did not develop, as you cannot be sure of the consequences. You should never change the name of any Oracle Applications application, because these applications contain hardcoded references to the application name.

Application

This user-friendly name appears in lists seen by application users.

Short Name

Oracle Applications use the application shortname when identifying forms, menus, concurrent programs and other application components. The short name is stored in hidden fields while the name displays for users.

Your short name should not include spaces. You use an application short name when you request a concurrent process from a form, and when you invoke a subroutine from a menu.

Suggestion: Although your short name can be up to 50 characters, we recommend that you use only three or four for ease in maintaining your application and in calling routines that use your short name.

Basepath

Enter the name of an environment variable which translates into the top directory of your application's directory tree. Oracle Applications search specific directories beneath the basepath for your application's executable files and scripts when defining actions that reside in external files.

In general, your application's basepath should be unique so that separate applications do not write to the same directories.

However, you may define custom applications that will be used only for naming your custom responsibilities, menus and other components. In this case, you can use the basepath of the Oracle application that uses the same forms as your application. For example, if you are defining a Custom_GL application, you could use the GL_TOP basepath for your custom application.

Abbreviation

The abbreviation guarantees a unique name that is less than four characters. Application processes that require a brief application name use the abbreviation. Most application abbreviations consist of the first three letters of the application short name.

Message Prefix

Users see the message prefix at the beginning of error messages. In the SQL*Forms 2.3-based (character mode) Oracle Applications products, a message uses the prefix of the application associated with the responsibility the user is currently using. In the Oracle Forms 4.5-based (GUI) applications, the message prefix is always APP, regardless of what you specify here. The usual value for this field is APP or your application short name.

Suggestion: Although your prefix can be up to 15 characters, we recommend that you use only three or four characters. This makes your messages easier to read.

FORMS

Register an application form with Oracle Applications. You must register a form before you can call it from a menu or a responsibility.

Prerequisites

· Register your application with Oracle Application Object Library using the Applications window

Suggestion: Even if you do not use the VT220GL terminal definition, you must have it installed on your system to register your form.

Forms Block

The combination of application name and form name uniquely identifies your form.

Name

If you are registering a new form, enter the filename of your form (without an extension). Your form filename must be all uppercase, and its .fmx file must be located in your application directory structure. Further, your form must not be saved in the database.

Application

This is the application that owns your form. You can define an application by using the Applications form.

Applications

Oracle Applications looks for your form in the appropriate language directory of your forms directory, based on the application owning your form.

For example, if you are using American English on a Unix platform, Oracle Applications expects to find your form files in the directory //forms/US.

User Form Name

This is the form name you see when selecting a form using the Functions window.

FUNCTIONS

A function is a part of an application's functionality that is registered under a unique name for the purpose of assigning it to, or excluding it from, a responsibility.

FUNCTION SECURITY

Function security is the mechanism by which user access to applications functionality is controlled.

Oracle Applications GUI-based architecture aggregates several related business functions into a single form. Because all users should not have access to every business function in a form, Oracle Applications provides the ability to identify pieces of applications logic as functions. When part of an application's functionality is identified as a function, it can be secured (i.e., included or excluded from a responsibility).

Application developers register functions when they develop forms. A System Administrator administers function security by creating responsibilities that include or exclude particular functions.

TERMS

Function

A function is a part of an application's functionality that is registered under a unique name for the purpose of assigning it to, or excluding it from, a responsibility.

There are two types of functions: form functions, and non-form functions. For clarity, we refer to a form function as a form, and a non-form function as a subfunction, even though both are just instances of functions in the database.

Form (Form Function)

A form function (form) invokes an Oracle Forms form. Form functions have the unique property that you may navigate to them using the Navigate window.

Subfunction (Non-Form Function)

A non-form function (subfunction) is a securable subset of a form's functionality: in other words, a function executed from within a form.

A developer can write a form to test the availability of a particular subfunction, and then take some action based on whether the subfunction is available in the current responsibility.

Subfunctions are frequently associated with buttons or other graphical elements on forms. For example, when a subfunction is enabled, the corresponding button is enabled.

However, a subfunction may be tested and executed at any time during a form's operation, and it need not have an explicit user interface impact. For example, if a subfunction corresponds to a form procedure not associated with a graphical element, its availability is not obvious to the form's user.

Menu

A menu is a hierarchical arrangement of functions and menus of functions. Each responsibility has a menu assigned to it.

Menu Entry

A menu entry is a menu component that identifies a function or a menu of functions. In some cases, both a function and a menu of functions correspond to the same menu entry. For example, both a form and its menu of subfunctions can occupy the same menu entry.

Responsibility

A responsibility defines an application user's current privileges while working with Oracle Applications. When an application user signs on, they select a responsibility that grants certain privileges, specifically:

· The functions that the user may access. Functions are determined by the menu assigned to the responsibility.
· The concurrent programs, such as reports, that the user may run.
· The application database accounts that forms, concurrent programs, and reports connect to.

DATABASE

TABLE

Identify your application tables and primary key information to Application Object Library. You should specify your primary keys before auditing your application. If you do not specify your primary keys, AuditTrail does not store primary key information. You can also use this window to register minor changes to your tables.

Prerequisites

· Use the Applications window to register your application with Oracle Application Object Library
· Create your table in the database

Tables Block

User Table Name

End users see this title when they review audit results. The default for this field is the value in the Table Name field.

Type - Valid types are:


Interim Table is used only temporarily
Seed Data Table stores primarily setup data
Special Flexfield Data Table is used by flexfields
Transaction Data Table stores primarily transaction data.

Initial Extent / Next Extent

Enter the initial and next extent sizes in kilobytes for your table. You must enter values greater than 0.

% Free / % Used

You must enter a value between 1 and 100 per cent. You must enter a Percent Free value such that the sum of the Percent Used field and the Percent Free field is between 1 and 100.

Min Extents/Max Extents

Enter a value of 1 extent or more for the minimum extents value. Enter a maximum extents value that is greater or equal to the minimum extents value. You enter a low value for maximum extents to prevent fragmentation of your database table.

Auto Size

Indicate whether the table should be larger or smaller for different customer. If the Auto Size button is not checked, the table should have the same size for all customers. In general, seed data tables should have AutoSize = No.

Detail Buttons

Choose a button to open a detail window where you supply more information about your table.


Indexes Choose this button to open the Indexes window where you identify an application index, give it a name, describe its purpose, and specify default parameters
Primary Keys Choose this button to open the Primary Keys window where you specify your primary keys.
Foreign Keys Choose this button to open the Foreign Keys window where you define your foreign keys.
Detail Buttons

Choose the detail window which you want to update: Indexes, Primary Keys, or Foreign Keys.

Table Columns Block

Seq

Enter the order of the column in the table. For example, the first column in the table can have Sequence=1.

User Column Name

End users see this title when they review audit results. The default for this field is the value in the Column Name field.

Column Type

Valid types are:

· Character
· Date
· Long
· Long Raw
· MLS Lable
· Number
· Raw
· Raw MLS Label
· Row ID
· Varchar
· Varchar2

If the column name contains "ID" or "NUM", the default value for this field is Number. If the column name contains "DATE", the default value for this field is Date. Otherwise, the default value for this field is Varchar2.

Width

You cannot enter this field if your column is Type Date, Long, Long Raw, MLS Label, Raw, Raw MLS Label, or Rowid.

You can enter different values depending on the column type. For type Character, you must enter a value between 1 and 256. For type Number, you must enter a value between 1 and 40. For type Raw, you must enter a value between 1 and 256. You cannot change the value for types Date, Long and Long Raw.

The default for this field is 30 for Types Character, Varchar, and Varchar2; 7 for Type Date; 22 for Type Number; 240 for Type Raw; and 0 for Types Long, Long Raw, Row ID, MLS Label, and Raw MLS Label. You cannot enter 0 for any other type.

This field corresponds exactly to the LENGTH column in the ORACLE data dictionary.

Precision

Enter the length of numbers past the decimal point at which you want to calculate the number for this field. This field is enabled only if your column is type Number. You must enter a value between 1 and 40. For all other column types, the value is NULL.

Scale

Enter the scale of the column. You can only enter this field only if your column is type Number. You must enter a value between -40 and 40. For all other column types, the value is NULL.

Default Value

Enter the value which the ODF Comparison Utility should use before altering the column to NOT NULL. The ODF Comparison Utility makes a statement like:

update t set c = ;

The default is 0 is Type is Number, 'N' if Type is Character, and sysdate if Type is Date.

This value is usually a constant; you can also use an expression. When you enter the value in the form, or when you generate the ODF file, the expression is not evaluated. The ODF Comparison Utility will just use whatever value you supply here, and evaluate it at the customer site.

So for dates, if you do not use sysdate, you should include todate : todate('01-03-1992','MM-DD-YYYY') not 01-03-1992

And for strings, you have to include quotes: 'ABC' not ABC

Translate

Indicate whether the values in this database column can be translated. You can enter this field only if this column is defined as type Character, Varchar, or Varchar2. You should not identify a column as translatable if it is either a primary key or a DataMerge key.

Indexes Window

Enter the name of the database index and indicate whether the index is unique.

Initial Extent / Next Extent

Enter the initial and next extent sizes in kilobytes for your table. You must enter values greater than 0.

% Free

Enter the percent free value for your table. You must enter a value between 1 and 100 per cent.

Initial Transactions

Enter the initial number of transaction entries that are allocated within each block. You must enter a value between 1 and 255.

Max Transactions

Enter the maximum number of transactions that may update a data block concurrently. You must enter a value between 1 and 255.

AutoSize

Indicate whether the index should be larger or smaller for different customers. In general, seed data tables should have AutoSize unchecked.

Index Columns - Primary Keys Window

Type - Valid types are Developer and Alternate. You can define only one Developer primary key per table.

Primary Key Columns - Sequence

Name

You can pick any column in your table that has type Number, Character or Date. You cannot choose a column of any other type, such as Long or Long Raw.

Foreign Keys Window

Define the foreign keys for your table. You can define conditional foreign keys by specifying a WHERE clause condition for the foreign key reference.

Cascade Behavior

This field supports functionality to be implemented in a future release.

Choose the type of cascade delete behavior for this foreign key. You use this field to specify what to do to a foreign key table when you delete rows from the primary key table. Valid types are Delete, Update, Check Parent and None.

Delete means that you delete rows in the foreign key table when you delete rows in the primary key table.

Update means that you update rows in the foreign key table using Cascade Values in the next zone whenever you delete rows in the primary key table.

Check Parent means that you do not delete rows in the primary key table if there are rows in the foreign key table that still reference the rows in the primary key table.

None means that you can delete rows in the primary key table without consideration for rows in the foreign key table.

Foreign Key Relation

Enter the type of foreign key relationship between the foreign key table and the primary key table. Valid types are Tight and Loose. DataMerge assumes that if a table has multiple "parent" tables, that only one of them is Tight and the others are Loose. The default value for this field is Tight.

Condition

If you are entering a conditional foreign key, enter the WHERE clause for the condition. You can use the "&table" token in your WHERE clause to identify the current table. Applications DBA automatically replaces the "&table" token in SQL statements with the actual name of your table when it generates SQL statements that use conditional foreign keys.

Primary Key - Name - Foreign Key Columns - Cascade Value

This field supports functionality to be implemented in a future release. You can only enter a value in this field if your foreign key's behavior is Update.

SEQUENCES

Identify an application sequence to Oracle Applications. You can also use this window to register changes to your sequences.

Tables - Prerequisites

· Register your application
· Create or alter your sequence in the database

Sequences Block - Start With

Enter the first number that this sequence should generate. The value in this field must always be between the Minimum Value and Maximum Value inclusive.

Increment

Enter the interval between sequence numbers. The increment can be positive or negative. If you enter a negative value, the sequence descends. You cannot enter a value of zero.

Minimum

Enter the minimum value this sequence can generate. This value is the lower bound for the sequence. You must enter a Minimum Value that is less than the Maximum Value.

Maximum

Enter the maximum value the sequence can generate. This value is the upper bound for the sequence. You must enter a Maximum Value that is greater than the Minimum Value. The default value is 2,147,483,647.

Cache Size

Enter the number of sequence numbers to cache in memory, resulting in faster generation of sequence numbers. You must enter a value greater than or equal to 0. The default value is 5.

Cycle

Check if you want the sequence to generate additional numbers when the end of the sequence is reached. Otherwise, leave the check box off.

Guarantee Order

Check if you want the sequence to generate numbers in order of request. Otherwise leave the check box off.

VIEWS

Identify an application view with Oracle Applications. You can also use this window to register changes to your view.

Tables - Prerequisites

· Define your application with Oracle Applications.
· Create or alter your view in the database.

Views Block

Enter your view's name and the application to which it belongs.

Columns Block

Specify the columns in your application view.

VALIDATION - VALIDATION SETS

The value sets you define using these windows appear in lists of values you see when you define flexfield segments using the Key Flexfield Segments window or the Descriptive Flexfield Segments window. You can also use your value sets when you define FlexBuilder parameters.

If you are defining reports that your users run from the Submit Requests window, use this window to define value sets for your report arguments. The value sets you define using this window also appear when you define report parameters using the Concurrent Programs window.

VALUES - SEGMENT VALUES WINDOW

Use this window to define valid values for a key or descriptive flexfield segment or report parameter. You must define at least one valid value for each validated segment before you can use a flexfield. These validated segments provide users with a list of predefined valid segment values, and have a validation type of Independent, Dependent, or Table.

You should use this window to define values that belong to independent or dependent value sets. You can define new segment values, specify value descriptions for your values and to enable or disable existing values as well.

The values you define for a given flexfield segment automatically become valid values for any other flexfield segment that uses the same value set. Many Oracle Applications reports use predefined value sets that you may also use with your flexfield segments. If your flexfield segment uses a value set associated with a Standard Request Submission report parameter, creating or modifying values also affects that parameter. If you use the same value set for parameter values, the values you define here also become valid values for your report parameter.

You also specify segment value qualifiers, rollup groups, and child value ranges.

You can also view and maintain segment value hierarchies for the Accounting Flexfield or for any custom application flexfields that use the value hierarchies feature.

Attention: Because the Accounting Flexfield is the only Oracle Applications key flexfield that uses the parent, rollup group, hierarchy level and segment qualifier information, you need only enter this information for values that are associated with your Accounting Flexfield.

When you make changes to your value hierarchies, you automatically submit a concurrent request to rebuild your value hierarchies. One request per value set that the change affects (the value set attached to the segment for which you are defining or maintaining values) is submitted. For example, if you make hierarchy structure changes for five different key flexfield segments, all of which use different value sets, this window submits five concurrent requests.

Suggestion: For ease of maintenance, you should carefully plan your value hierarchy structures before you define your values, so that your structures follow a logical pattern you can expand later as you need more values.

To prevent invalidation of any existing data, you cannot update segment qualifier information for existing values unless you first unfreeze any key flexfield structure that use this value set. You unfreeze your key flexfield using the Define Key Flexfield Segments form.

Attention: You cannot modify values for a value set if that value set is currently being modified by another user, either using a version of the Segment Values Window (either the character mode or GUI version) or the Account Hierarchy Editor with Oracle General Ledger. If you get a message saying that the value set is already being modified, you can try again at a later time.

If your value set is based on a flexfield validation table (validation 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. This window stores your parent values and rollup groups for you and does not add them to your validation table. You can define child value ranges for the parent values you define, and you can assign your parent values to rollup groups. The values in your validation table can be child values, but they cannot be parent values, and you cannot assign them to rollup groups. You cannot create new values in your validation table using this window.

Prerequisites

Use the Value Set window to define your independent value sets, any dependent value sets that depend on them, and any table-validated value sets your flexfield needs

Use the Key Flexfield Segments window to define your flexfield structure and segments or

Use the Descriptive Flexfield Segments window to define your flexfield structure and segments
Define your rollup groups, if any. See: Rollup Groups Window.

Suggestion: First use this window to define all of the independent values your application needs, then define your dependent values. This window does not allow you to choose an independent value that would violate any flexfield security rules that are enabled for your responsibility.

Segment Values Block

Use this block to define valid values, to specify values for rollup groups and segment qualifiers, if any, and to enable and disable values. If you define a value you use as a default value for your segment or dependent value set, you must not specify a start or end date for that value. Also, you should not define security rules that exclude your default values.

Some key flexfields use segment qualifiers to hold extra information about individual key segment values. For example, the Accounting Flexfield in Oracle Applications products uses segment qualifiers to determine the account type of an account value or whether detail budgeting and detail posting are allowed for an Accounting Flexfield combination containing a given value. You cannot define values that would violate any flexfield security rules that are enabled for your responsibility.

QUICKCODES – DEFINE

Maintain existing and define additional QuickCodes for your shared QuickCode types. You can define up to 250 QuickCodes for each QuickCode type. Each QuickCode has a code and a meaning. For example, QuickCode type YES_NO has a code Y with meaning Yes, and a code N with a meaning No. If you make changes to a QuickCode, users must log out then log back on before your changes take effect.

QuickCodes Block - Type

Query the type of your QuickCode. You can define a maximum of 250 QuickCodes for a single type.

Application

Query the application associated with your QuickCode type.

Description

If you use windows specialized for a particular QuickCode type, the window uses this description in the window title.

Access Level

This option group determines whether you can add new QuickCodes or modify existing QuickCodes of this type. The three levels are:

User No restrictions on adding or modifying codes are enforced.
Extensible New codes may be added, but you can only modify or disable seeded codes if the application of your responsibility is the same as the application of this QuickCode.
System Only code meanings and descriptions may be modified.

QuickCode Values Block - Code

Enter the code value for your QuickCode. You can define a maximum of 250 QuickCodes for a single QuickCode type. When you enter a valid QuickCode meaning into a displayed window field, QuickCodes stores this code into a corresponding hidden field. For example, the QuickCode "Y" displays the meaning "Yes" but stores the code value "Y" in a hidden field. You cannot change the values in this field after committing them. To remove an obsolete QuickCode you can either disable the code, enter an end date, or change the meaning and description to match a replacement code.

Meaning

When you enter a valid QuickCode meaning into a displayed window field, QuickCodes stores the corresponding code into a hidden field. QuickCodes automatically displays the meaning in your QuickCodes field whenever you query your window. For example, the QuickCode "Y" displays the meaning "Yes" but stores the code value "Y" in a hidden field.

Start Date / End Date

Enter the dates between which this QuickCode becomes active. If you do not enter a start date, your QuickCode is valid immediately. If you do not enter an end date, your QuickCode is valid indefinitely. Once a QuickCode expires, users cannot insert additional records using the QuickCode, but can query records that already use the QuickCode.

Enabled

Indicate whether applications can use your QuickCode. If you enter No, users cannot insert additional records using your QuickCode, but can query records that already use this QuickCode.

[ ] - The double brackets ([ ]) identify a descriptive flexfield that you can use to add data fields to this window without programming.

QUICKCODES – SPECIAL (LOOKUP CODES)

Maintain existing and define additional Lookups for your shared Lookup types. You can define up to 250 Lookups for each Lookup type. Each Lookup has a code and a meaning. For example, Lookup type YES_NO has a code Y with meaning Yes, and a code N with a meaning No. If you make changes to a Lookup, users must log out then log back on before your changes take effect.

Lookups Block - Type

Query the type of your Lookup. You can define a maximum of 250 Lookups for a single type.

Application

Query the application associated with your Lookup type.

Description

If you use windows specialized for a particular Lookup type, the window uses this description in the window title.

Access Level

This option group provides functionality for a later release. The value System indicates that the Lookup type was seed data provided by an Oracle Application.

Shared

This field provides functionality for a later release. Lookups Values Block

Language

You may have several Lookups with the same Code in different languages. For example, the code Y may have a meaning of Yes in American English and Oui in French. Oracle Applications displays the correct meaning depending on your Site Language.

Code

Enter the code value for your Lookup. You can define a maximum of 250 Lookups for a single Lookup type. When you enter a valid Lookup meaning into a displayed window field, Lookups stores this code into a corresponding hidden field. For example, the Lookup "Y" displays the meaning "Yes" but stores the code value "Y" in a hidden field.

You cannot change the values in this field after committing them. To remove an obsolete Lookup you can either disable the code, enter an end date, or change the meaning and description to match a replacement code.

Meaning

When you enter a valid Lookup meaning into a displayed window field, Lookups stores the corresponding code into a hidden field. Lookups automatically displays the meaning in your Lookups field whenever you query your window. For example, the Lookup "Y" displays the meaning "Yes" but stores the code value "Y" in a hidden field.

Description

You can display the description along with the meaning to give more information about your Lookup.

Start Date / End Date

Enter the dates between which this Lookup becomes active. If you do not enter a start date, your Lookup is valid immediately. Once a Lookup expires, users cannot insert additional records using the Lookup, but can query records that already use the Lookup. If you do not enter an end date, your Lookup is valid indefinitely.

Enabled

Indicate whether applications can use your Lookup. If you enter No, users cannot insert additional records using your Lookup, but can query records that already use this Lookup.

[ ] - The double brackets ([ ]) identify a descriptive flexfield that you can use to add data fields to this window without programming.

MENU - DEFINING A NEW MENU STRUCTURE

When defining a new menu structure:

· Create a logical, hierarchical listing of functions. This allows for easy exclusion of functions when customizing the menu structure for different responsibilities.

· Create a logical, hierarchical menu that guides users to their application forms.

Tasks for Defining a Custom Menu Structure

· Determine the application functionality required for different job responsibilities.

· Identify predefined menus, forms, and form subfunctions to use as entries when defining a new menu. Understand predefined menus by printing Menu Reports using the Submit Requests window.

Suggestion: To simplify your work, use predefined menus for your menu entries. You can exclude individual functions after a menu structure is assigned to a responsibility.

· Plan your menu structure. Sketch out your menu designs.
· Define the lowest-level menus first. A menu must be defined before it can be selected as an entry on another menu.
· Assign menus and functions to higher-level menus.
· Assign menus and functions to a top-level menu (root menu).
· Document your menu structure by printing a Menu Report.

Warning: Start with a blank Menus form (blank screen). Menus cannot be copied. A menu saved under a different name overwrites the original menu (there is no "Save As" feature).

Notes About Defining Menus - Build Menus From Scratch

· Menus cannot be copied. Menu definitions cannot be saved under a different name (i.e., there is no "Save As" capability).
· When a menu name displays in the Menus form, be sure you are in Query mode before overwriting the menu's name.

Define Menus for Fast and Easy Keyboard Use

· Design menu prompts with unique first letters, so typing the first letter automatically selects the form or menu
· Design the sequence of menu prompts with the most frequently used functions first (i.e., lower sequence numbers).
· Entries cannot be copied from one menu definition to another.

Note when Changing Menu Names or Modifying Entries

· When you change a menu's name, the menu entries are not affected. The menu's definition exists under the new name.
· Other menus calling the menu by its old menu name, automatically call the same menu by its new (revised) name.
· When defining menus or selecting a "root" menu to assign to a responsibility, the old menu name is not in a list of values.
· When modifying a predefined menu, all other menus that call that menu display the menu's modifications.
· For example, if you modify GL_TOP by adding another prompt that calls a form function, all menus that call GL_TOP will display the additional prompt when GL_TOP displays.

Preserving Custom Menus Across Upgrades

Preserve custom menus during upgrades of Oracle Applications by using unique names for your custom menus. For example, you can start the menu's name with the application short name of a custom application. Define a custom application named Custom General Ledger, whose application short name is CGL. Define your custom menu names to start with CGL, for example, CGL_MY_MENU.

Remember that the Oracle Applications standard menus may be overwritten with upgrade versions. Therefore, if you attached your custom menu as a submenu to one of the preseeded Oracle Applications menus, recreate the attachment to it following an upgrade. An alternative is to attach a standard Oracle Applications menu as a submenu to your custom mnu; the link from your custom menu to the standard menu should survive the upgrade.

MESSAGES

Define your application messages before your routines can call them from a form and before your users can request detailed messages from a form. Once you leave the Messages window, after you make and save your changes, you should submit a concurrent request on your client machine to build your message file. Your new messages take effect as soon as your concurrent request finishes successfully.

When you upgrade, any customizations you make to Oracle Applications messages will be overwritten. However, an upgrade does not overwrite messages you define using your own application.

Prerequisites

· Register your application.
· Create a mesg directory (or some other location if your operating system does not support directories) directly under your application's base directory where Oracle Application Object Library can store your message files.

Messages Block

Application name and message name uniquely identify your message.

Name

Your message name can be any combination of letters, numbers, hyphens (-), underscores (_) and spaces, up to 30 characters in length. Message Dictionary names are not case sensitive (for example, MESSAGENAME is the same name as messagename). You use this message name in your forms or concurrent programs when you invoke the Message Dictionary.

Language

Oracle Applications displays the correct language based on the user's current language.

Application

Enter the name of the application for which you wish to define message text. When you upgrade, any customizations to Oracle Applications messages will be overwritten. However, an upgrade does not overwrite messages you define using your own application name.

Description

You should enter information in this field that would help explain the context of this message to translators.

Current Message Text

Enter an explanation that describes the problem and its resolution. You can include variable tokens preceded by an ampersand (&) to indicate the location of substitute text. You supply the substitute text or field references in your form's message calls. For example, you could define an explanation for a message you call "Value Less Than Or Equal" like this:

Cause: The value &VALUE1 is greater than &VALUE2, but it must be less than or equal to &VALUE2. Action: Enter a new value that is less than or equal to &VALUE2. It could correspond to a function call from your form that includes the field references:

#FND MESSAGE NAME="Value Less Than Or Equal"
VALUE1=":ORDER.AMOUNT_PAID"
VALUE2=":ORDER.TOTAL_DUE"

Your user sees the message explanation as:

Cause: The value $32.12 is greater than $30.00, but it must be less than or equal to $30.00. Action: Enter a new value that is less than or equal to $30.00.

You can also include the system token &APPLICATION in your message explanation. If you include &APPLICATION in your message, Message Dictionary automatically retrieves the name of the application your end user is currently using. Similarly, if you specify &PREFIX in your message, Message Dictionary automatically retrieves the prefix of the application your end user is currently using. You do not need to specify these system tokens or their values when you call the message facility from your form.

You can specify your own variable tokens using numbers, letters, and underscores (_). Your variable tokens can be up to 30 characters long. You can use the same token more than once in your defined messages to repeat your substitute text.

Since Message Dictionary reserves these system tokens for special meanings, you may not use &APPLICATION or &PREFIX as variable tokens in your messages.

You should make sure that substitutable text does not include phrases that depend on word order, as word order and sentence structure may change when translators translate a message.

Messages shipped with Oracle Applications may contain special formatting information (such as \ERRORTEXT or @ERRORTEXT). If you customize any of these messages, you should be careful to preserve the existing format information. If you inadvertently type over (and save) a \ character that is part of the format information in the message explanation, you can replace it with a @ character.

When you upgrade, any customizations to Oracle Applications messages will be overwritten. However, an upgrade does not overwrite messages you define using your own application name.

PROFILES

Define a user profile option. You define new user profile options when you build an application. Once you define an option, you can control access for it at different profile levels.

Prerequisites

· Define your application using the Application window.

Profiles Block

You identify a profile option by application name and profile option name.

Name

The profile option name must be unique so that different profile options do not conflict. This is the name you use when you access your profile option using the Oracle Application Object Library profile option routines.

User Profile Name

This is the name your users see as their profile option, so it should be short but descriptive.

Profile Values - Active Dates - Start Date/End Date

Enter the dates on which the profile option becomes active/inactive. The start date defaults to the current date, and if the end date is not entered, the option will be effective indefinitely. You cannot delete a user profile option, but you can disable it. Enter the current date if you want to disable the user profile option. If you wish to reactivate a disabled profile option, change the End Date to a date after the current date.

SQL Validation

Enter validation criteria in the window of a LOV definition. This definition is used to build to validate values your system administrator and users enter in the Profile Values window for your profile option.

To validate your user profile option, select the profile option value into the fields :PROFILE_OPTION_VALUE and :VISIBLE_OPTION_VALUE. The Profile Values form uses these fields to ensure that your user enters valid values for your profile option. If you want your forms and programs to react to predefined, hardcoded profile option values, like Y or N, you should represent your option values using QuickCodes.

If you do not provide an explicit TITLE and HEADNG in your SQL validation, your profile has TITLE="user_profile_option_name" and HEADING="N" appended to the definition at runtime. This appended title overrides any heading defined in a COLUMN token or aliases in the SQL statement.

For example, suppose you have a QuickCodes type called SECURITY_LEVEL that uses the codes 1 and 2 to represent the values High and Low respectively. You should select the code column into :PROFILE_OPTION_VALUE and the meaning column into :VISIBLE_OPTION_VALUE. Then, if you want to change the meaning of your codes, you do not have to change your program or form logic. If the value of your profile option is user-defined, you can select the value into both fields. For example, suppose you have a table and form where you maintain equipment information, and you have a profile option called EQUIPMENT. You can select the same value into both :PROFILE_OPTION_VALUE and :VISIBLE_OPTION_VALUE.

Here is an example of a QuickPick definition for a new profile option called SET_OF_BOOKS_NAME.

SQL="SELECT SET_OF_BOOKS_NAME, SET_OF_BOOKS_NAME \"Set of Books\" '
INTO :PROFILE_OPTION_VALUE, :VISIBLE_OPTION_VALUE,
FROM SETS_OF_BOOKS"
COLUMN="\"Set of Books\"(30)"

If you do not enter validation criteria in this field, your user or system administrator can set any value for your profile option, if you allow them to update it.

If the profile option Utilities:Diagnostics is No, then Application Object Library does not display profile options on the Profile Values window for which it cannot successfully perform your validation. For example, if a user cannot access the table you reference in your validation statement, Oracle Application Object Library does not display the profile option when the user queries profile options on the Profile Values window.

Profile Values

You automatically invoke the long field editor when you enter this field.

User Access - Visible

Indicate whether your end users can see and query this profile option in their personal profiles. Otherwise, they cannot query or update values for this option.

Updatable

Indicate whether your end users can change the value of this profile option using their Profile Values window. Otherwise, your system administrator must set values for this profile option.

Program Access Block - Visible

Indicate whether you can read the value of your profile option from a user exit or concurrent program. If you enter Yes, you can construct your application to read the value of a user profile option using the Oracle Application Object Library routine GETPROFILE.

Updatable

Indicate whether you can change the value of this profile option using #FND PUTPROFILE.

System Administrator Access Block

Define the characteristics of your profile option at each profile level that the system administrator uses to define profile values. You can define the characteristics at the Site, Application, Responsibility and User levels.

Suggestion: You should specify Site-level characteristics of every user profile option you create so that the system administrator can assign a Site-level value for every profile option.

You should provide access to each option at the Site level. You can also provide access for any of the other three levels, Application, Responsibility, and User. Profile option values set at the User profile level override values set at the Responsibility profile level, which override values set at the Application profile level. If no values are set at these three levels, then the value defaults to the value set at the Site profile level if the Site level value has been set.

If you want your end user to be able to update profile option values in the Profile Values window, that is, you chose Updatable in the User Access region, you must provide user visible and updatable access at the User level here.

Visible

Indicate whether your system administrator can see your profile option while setting user profile option values for the specified profile level.

Updatable

Indicate whether your system administrator can change the value of your profile option while setting user profile option values for the profile level you select.

OTHERS – REQUEST-RUN

Use this window to run a request or request set. For help on a specific report, open the parameters window and press the help button. If the report you chose has no parameters, you can see help by choosing from the list of products and reports.

SUBMITTING A REQUEST

Standard Request Submission gives you control over how you run your requests and request sets. This section describes how you customize and submit a request using the Submit Requests window. You can submit as many requests as you like from the Submit Requests window. You can even submit a request more than once if you want to run the same request with different parameter values.

Refer to the reference guide of your Oracle Applications product to learn how to access the Submit Requests window from your application. Attention: Some applications provide access to the Submit Requests window from multiple menu choices. However, the list of requests that you can run and the name of the window itself may vary depending on the navigation path you use to access the window.
REQUEST – VIEW

Use the Requests window to view a list of your submitted requests that are scheduled to run in the next 24 hours, completed within the last 24 hours, or are currently running. Use the Completed Requests window to view a list of all your completed concurrent requests.

REQUEST – SET – DEFINING REQUEST SET

By defining request sets, you can submit the same set of requests regularly using a single transaction. You use the Request Set window to create and edit request sets. Refer to the reference guide for your Oracle Applications product to learn how to access the Request Set window.

Attention: Some Oracle Applications products do not allow you to create request sets. These products do not have the Request Set window available.

To create a request set:

1. Navigate to the Request Set window.
2. Enter a Name for your request set.
3. Enter the Application with which you want to associate your request set.
4. Enter a Description of your request set if you like.
5. The Owner field defaults to your username and can only be changed by your system administrator.
6. Enter a Start Date and an End Date to define an effective period when you and others can run the request set. If the current date is outside the range you define, the request set will not be available in the Submit Requests window.
7. Choose between the Sequential (one at a time in order) and Parallel (at the same time) options to specify how you want to run the requests in your request set. If you want to create a request set where a request depends on the results of a prior request, define your request set to run sequentially.
8. Check the Print Together check box to send all your requests to the printer together when they complete, or uncheck the check box to send each request one at a time to the printer as it completes.
9. For a sequential request set, check the Abort on Error check box to stop the request set upon an error or uncheck the check box to continue running the rest of the requests if an error occurs.

If your request cannot run because it has been disabled, your request set fails even if you do not check the Abort on Error check box.

10. Check the Incompatibilities Allowed check box to allow your system administrator to specify programs that this request is incompatible with (may not run with). Leave Incompatibilities Allowed unchecked to specify that this request set may run with all other concurrent requests or request sets.

Requests Block

In the Requests block you define which requests you want to include in the request set.

11. Enter a Sequence to specify the order the requests run in a sequential request set.
12. Select the Name of a report or program you want to include in your request set. A description of the request you c choose and its associated application appears in the Description and Application fields.

The list of requests you can choose includes the requests that your responsibility's request group lets you access from the Submit Requests form.

13. The Print Options region reflects the options for the current request. Specify the number of Copies of output to print, the Style to print, the Printer to print to, and whether to save the output to an operating system file.

Standard Request Submission saves these options so you do not have to specify them again when you run the request set. If you do not wish to specify these options for each request when you define the set, Standard Request Submission uses the values of your personal profile options as the default when you submit the request set. See: Default Values of Concurrent Processing Options. Note: Some requests may have a required Style or Printer that you cannot change.

14. When you are done with the print options, choose Parameters to display the Request Parameters window.

Request Parameters Window

The Request Parameters window lets you customize the parameter values of a specific request in a request set. The fields at the top of the Request Parameters window list general information about the current request set and the request for which you can customize the parameters values. The multi-row portion of the window lists the parameters for that request.

15. The Sequence field displays the order in which each request parameter appears when you run the request in the Submit Requests window (lower numbers appear before higher numbers). Only your system administrator can change a parameter's order.

16. The Prompt field is a display-only field that shows the request parameter's prompt.
17. Check the Display check box to specify that you can see a request parameter at submission time, or uncheck the check box to specify that a parameter should not be displayed at submission time.
18. Check the Modify check box to specify that you can insert or change the value for a request parameter at submission time, or uncheck the check box to specify that a parameter cannot be changed at submission time.
19. Use the Shared Parameter field to set a default value for a parameter that occurs in more than one report or program of a request set. Once you enter the same parameter label in the Shared Parameter field for each occurrence of the same parameter, the value that you assign to the first occurrence of the parameter becomes the default value for all subsequent occurrences of the parameter. The shared parameter label simply enables you to set an initial default value for all occurrences of the same parameter so you can avoid typing the same value all over again for every occurrence of the parameter.

For example, suppose you define a request set that includes three reports and all reports include a parameter called "Set of Books." You want the "Set of Books" parameter to default to the same initial value in all reports. To accomplish this, enter a label called "Book" in the Shared Parameter field for the first occurrence of this parameter. You can also assign a value in the Default Value field of this parameter now or wait until you run the request set to assign a default value when the parameter first appears. Enter the label "Book" in the Shared Parameter field of all other occurrences of the "Set of Books" parameter in your request set. When you submit this request set from the Submit Requests window, every parameter that you label "Book" defaults to the value you assign to the first occurrence of the "Set of Books" parameter.

Attention: Note that if you later change the value of a parameter that contains a shared parameter label, you change only the value for that instance of the parameter, and not the value for all other occurrences of that labelled parameter.

We recommend that if you make a parameter with a shared parameter label modifiable, that you also display the parameter so you can always see what the parameter's current value is. This helps reinforce the understanding that a later value change to one labelled parameter cannot propagate a value change to all other similarly labelled parameters.

20. Optionally enter a default Type and Value for the parameter.
21. Save your work.
22. Go back to the Requests block of the Request Sets window and repeat Steps 1 through 10
to add more requests to the request set.

You can select a request more than once if you want to run the same request with different default parameter values.


PROFILES – DEFINITIONS

User Profile Options

Changeable options that affect the way your applications run.

User Profile Levels

User profile options exist at four different levels: Site, Application, Responsibility, and User levels. Oracle Applications treats user profile levels as a hierarchy, where User is the highest level of the hierarchy, followed by Responsibility, Application, and at the lowest level, Site. Higher-level option values override lower-level option values.

Site Level

Site is the lowest profile level. Site-level option values affect the way all applications run at a given installation site.

Application Level

Application is the profile level immediately above Site. Application-level option values affect the way a given application runs.

Responsibility Level

Responsibility is the profile level immediately above Application. Responsibility-level option values affect the way applications run for all users of a given responsibility.

User Level

User is the highest profile level and is immediately above Responsibility. User-level option values affect the way applications run for a given application user.

CONCURRENT

Use the Concurrent Requests windows to view a list of submitted requests, see whether a request has run, change a request's processing options, diagnose errors, or find the position of your request in available concurrent manager queues.

VIEWING REQUESTS

Since all reports, programs, and request sets are run as concurrent requests in Oracle Applications, you can use one of the following windows to view the status and output of your requests:


Concurrent Requests View progress and output of all of your concurrent requests, and change a request's processing options.
Requests View the progress and output of your concurrent requests.
Completed Requests View the output of your completed requests.

All reports and programs in Oracle Applications run as concurrent processes whether you submit them using the Submit Requests window, or using a product-specific submission window. Throughout this guide we refer to submitted reports and programs as concurrent requests, or simply as requests. Each concurrent request runs according to a set of concurrent processing options.

Default Values of Concurrent Processing Options

The default values of the concurrent processing options are determined by the values of the following user profile options:

· Concurrent:Hold Requests Specifies whether to hold a request temporarily
· Concurrent:Report Access Level Specifies who has access to report and log files
· Concurrent:Report Copies Specifies the number of copies of a report to print
· Concurrent:Request Priority Specifies the priority of a concurrent request
· Concurrent:Request Start Time Specifies the start date and time for a concurrent request
· Concurrent:Save Output Specifies whether to save report output to a file
· Concurrent:Sequential Requests Specifies whether to run your requests sequentially
· Printer Specifies the printer to print your report output

If you want to change the value of a default, you must change the value of the corresponding user profile option using the Personal Profile Values window in your application. Some profile options, such as Concurrent:Request Priority, can only be changed by your system administrator. See: Setting Your Personal User Profile.

If you submit your report or program using the Submit Requests window, you can also modify most of these concurrent processing options for the request at the time you submit your request. If you use a product-specific window that automatically submits a concurrent request when you save your work or choose a button, Oracle Applications uses the values defined by your user profile options as the concurrent processing options for your request.

Note: You can modify many of your request's concurrent processing options up until it starts running, even if you cannot modify the options at the time you submit the request. The Concurrent Requests window lets you monitor and change the options for your requests.

LIFE CYCLE OF A CONCURRENT REQUEST

A concurrent request proceeds through three, possibly four, life cycle stages or phases:


Pending Request is waiting to be run
Running Request is running
Completed Request has finished
Inactive Request cannot be run

Within each phase, a request's condition or status may change. Below appears a listing of each phase and the various states that a concurrent request can go through.


TYPES OF LOG FILES

Log files contain information about a concurrent program's execution, or a concurrent manager's activities. Log files are helpful when reviewing a problem request.

Log files are generated for all Completed concurrent requests.

There are three types of log files:

1. Request log files that document the execution of a concurrent program running as the result of a concurrent request. Every concurrent request generates a log file.

2. Manager Log files that document the performance of a concurrent manager that is running a request. The Manager Log file lists requests processed by a concurrent manager.

3. The Internal Concurrent Manager Log file that documents the performance of the Internal Concurrent Manager. It displays parameter values that are loaded when the Internal Concurrent Manager is started.

If a concurrent process ends in an error, you should review the log files to help diagnose the problem. You may also want to review the log files if a program's performance is questionable. For example, if a report runs very slowly or if it prints out data that you didn't expect.

The Internal Concurrent Manager Log file also records the time that each concurrent manager is started, and when each process monitor session or pmon cycle is initiated. During each pmon cycle, the Internal Concurrent Manager verifies the correct operation of each defined concurrent manager.

System Administrator Log File Privileges

Both you and your end users can review request log files and manager log files online. Only the System Administrator can display the Internal Concurrent Manager log file.

As System Administrator, you can use the Concurrent Requests and Administer Concurrent Program windows to view request and manager log files.

Operating System Access to Log Files

Log files are stored as standard operating system files in directories defined during the installation of Oracle Applications.

For example, Oracle General Ledger files are located using a path variable called $GL_TOP/$APPLLOG, or $APPLCSF/$APPLLOG, if the APPLCSF variable is set.

The complete path name to access an Oracle Applications log file depends on the operating system you are using. However, there are a number of file name conventions that are standard across all platforms.

For example:

VMS L64225.REQ
Unix l64225.req

Operating System Access to Concurrent Manager Log Files

Concurrent manager log files are located in the log directory under FND_TOP, the variable that contains the path name to Application Object Library Files, or under $APPLTOP/$APPLLOG. The concurrent manager log file naming convention in Unix is wn.mgr, where n is a number with up to 3 digits.

For most platforms, n is the Concurrent Process ID number assigned to the concurrent manager by the Internal Concurrent Manager, and is found in the Internal Concurrent Manager log file. The log file name for the Internal Concurrent Manager is specified when you use the STARTMGR command from the operating system to start the concurrent managers.

Log files contain information about a concurrent program's execution, or a concurrent manager's activities. Log files are helpful when reviewing a problem request. Log files are generated for all Completed concurrent requests.

Related Articles to Read