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.
QUICK CODES – 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.
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.
QUICK CODES – 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.
No comments:
Post a Comment