Oracle® Fusion
Applications Sales Implementation Guide 11g Release 6 (11.1.6) Part Number E20373-06 |
![]() Home |
![]() Contents |
![]() Book List |
![]() Contact Us |
![]() Previous |
![]() Next |
This chapter contains the following:
Maintain Common Reference Objects: Overview
Manage Applications Core Common Reference Objects: Manage Applications Core Messages
The Maintain Common Reference Objects task list contains Oracle Fusion Middleware Extensions for Applications (Applications Core) tasks that support implementation of common behaviors, such as data security or reference data sets.
Use this task list to manage common reference objects that are defined centrally and shared across applications, in addition to those that are specific to Applications Core functionality. You can access this task list by starting in the Setup and Maintenance Overview page and searching for common reference object task lists.
Note
Offerings also include application-specific tasks for managing Applications Core objects. For example, the Financials offering includes tasks such as Manage Receivables Descriptive Flexfields, and Manage Receivables Lookups.
For more information on configuring custom objects, see the Oracle Fusion Applications Extensibility Guide.
To make the Maintain Common Reference Objects task list available in your implementation project, go to Setup and Maintenance Overview - Configure Offerings, and for a specific offering, select the Maintain Common Reference Objects feature choice.
Application taxonomy is the organization of Oracle application components and functions in a hierarchical structure, from product lines to logical business areas. This hierarchy represents a breakdown of products into units based on how applications are installed and supported. Maintain this hierarchy on the Manage Taxonomy Hierarchy page, which you can access by starting in the Setup and Maintenance Overview page and searching for the Manage Taxonomy Hierarchy task.
A detailed introduction to application taxonomy is provided in the Oracle Fusion Applications Developer's Guide.
A module is any node in the application taxonomy hierarchy. The top level of the hierarchy is product line, followed by product family, application, and logical business area. There can be multiple levels of logical business areas, with one or more nested within a parent logical business area.
A product line is a collection of products under a single brand name, for example, Oracle Fusion.
A product family is a collection of products associated with a functional area that may or may not be licensed together as a single unit, for example Financials.
An application is a single product within a product family, containing closely related features for a specific business solution, for example General Ledger.
A logical business area is a collection of business object definitions organized into a logical grouping. It contains the model objects, services, and UI components for those business objects. Logical business areas have their own hierarchy levels and in some cases can be two or three levels deep. Each leaf node has at least one business object and service, up to a maximum of four business objects and associated services. A logical business area with more than four business objects are further refined with child logical business area levels. Each of these parent-child levels is represented by a directory in the physical package hierarchy.
Manage modules on the Create Child Module or Edit Module page, which you can access by starting in the Setup and Maintenance Overview page and searching for the Manage Taxonomy Hierarchy task. When you create a module, it is a child of the currently selected node in the application taxonomy hierarchy. This determines which values are available, for example for module type. Once created, you cannot delete the module or move it elsewhere in the hierarchy. As you create or edit modules, consider the following points regarding specific fields.
Module ID is the unique primary key for nodes in the taxonomy table. When you create a module, an ID is automatically generated. Once the module is created, you cannot update the ID.
Module key and alternative ID are additional identifiers of the module, presented in a way that is easier to read than the module ID. The module key is a string identifier, for example AP for the Oracle Fusion Payables application. The alternative ID is a numeric identifier, for example 1 for the Oracle Fusion product line. These IDs are provided for the product line, product family, and application modules, but you can optionally add them for logical business areas and new custom modules.
Note
Do not change the module key or alternative ID for predefined modules.
The product code is relevant only to application and logical business area modules. You can leave the field blank for other module types. The product code for applications is the short name that can be displayed in lists of application values, for example FND for Oracle Fusion Middleware Extensions for Applications.
Module name is the logical name for the module and is always available. The name must be unique among nodes in the same hierarchy level with the same parent, but try to make it as unique in the whole hierarchy as possible.
The user name and description can appear to users in other parts of Oracle Fusion Applications, so make sure that the values are something that users know to represent the module.
Though you can update the usage type to reflect the current state of the module, just doing so does not affect the actual state. For example, setting a module as installed does not mean it is actually installed if the installation itself has not taken place. Installation refers to operations related to laying down all the components needed to create an Oracle Fusion Applications environment, while deployment is the process that starts the managed servers and clusters and facilitates the actual use of product offerings. A licensed module is available for installation and deployment, and a deployed module is considered actively used when actually used by users.
If seed data is allowed, then seed data such as flexfields and lookups can be extracted for the module using seed data loaders. By default, extract is allowed for all predefined modules of type application and logical business area.
You can associate a logical domain to modules of type product family, as well as one or more enterprise applications to modules of type application. This association represents the relationship between the taxonomy modules and the corresponding domain and enterprise applications stored in the Oracle Fusion Applications Functional Core (ASK) tables.
Reference data sharing facilitates sharing of configuration data such as jobs and payment terms, across organizational divisions or business units. You define reference data sets and determine how the data is shared or partitioned. Use reference data sets to reduce duplication and maintenance by sharing common data across business entities where appropriate. Depending on the requirement (specific or common), each business unit can maintain its data at a central location, using a set of values either specific to it or shared by other business units.
You can share reference data after it is filtered on the basis of sets. A common reference data set is available as the default set, which can be assigned to several business units sharing the same reference data. For commonly used data such as currencies, you can use the common reference data set and assign it to multiple business units in various countries that use the same currency. In cases where the default set cannot be assigned to an entity, you can create specific sets. The data set visible on the transactional page depends on the sharing method used to share reference data.
For example, XYZ Corporation uses the same grades throughout the entire organization. Instead of managers in different business units setting up the same grades, XYZ Corporation decides to create a set called Grades and assign the grades reference data group for all business units in the organization to the Grades set, so that the grades can be shared.
Note
For specific information on configuring reference data sharing for a particular object or product, refer to its product documentation.
Reference data sets are logical groups of reference data that can be accessed by various transactional entities depending on the business context. Oracle Fusion Applications contains a common reference data set as well as an enterprise set that may be used as a default set. Depending on your business requirement you can create and maintain additional reference data sets, while continuing to use the common reference data set.
Consider the following scenario.
Your enterprise can decide that some aspects of corporate policy should affect all business units and leave other aspects to the discretion of the business unit manager. This allows your enterprise to balance autonomy and control for each business unit. For example, if your enterprise holds business unit managers accountable for their profit and loss, but manages working capital requirements at a corporate level, you can let managers define their own sales methods, but define payment terms centrally. In this case, each business unit would have its own reference data set for sales methods, and there would be one central reference data set for payment terms assigned to all business units.
The partitioning of reference data and creation of data sets enable you to create reference entities across tables or lookup types, and share modular information and data processing options among business units. With the help of partitioning, you can choose to create separate sets and subsets for each business unit depending upon its business requirement, or create common sets or subsets to enable sharing reference data between several business units, without the need for duplicating the reference data. Partitioning provides you the flexibility to handle the reference data in a way appropriate to your business needs.
The following figure illustrates the reference data sharing method (assignment to one set only, with common values) where the user can access the data assigned to a specific set in a particular business unit, as well as access the data assigned to the common set.
Oracle Fusion Applications reference data sharing feature is also known as SetID. The reference data sharing functionality supports operations in multiple ledgers, business units, and warehouses, thereby reducing the administrative burden and decreasing the time needed to implement new business units. For example, you can share sales methods, transaction types, or payment terms across business units or selected other data across asset books, cost organizations, or project units.
The reference data sharing features use reference data sets to which reference data is assigned. The reference data sets group assigned reference data. The sets can be understood as buckets of reference data assigned to multiple business units or other application components.
You begin this part of your implementation by creating and assigning reference data to sets. Make changes carefully as changes to a particular set will affect all business units or application components using that set. You can assign a separate set to each business unit for the type of object that is being shared. For example, assign separate sets for payment terms, transaction types, and sales methods to your business units.
Your enterprise can decide that some aspects of corporate policy should affect all business units and leave other aspects to the discretion of the business unit manager. This allows your enterprise to balance autonomy and control for each business unit. For example, if your enterprise holds business unit managers accountable for their profit and loss, but manages working capital requirements at a corporate level, you can let managers define their own sales methods, but define payment terms centrally. In this case, each business unit would have its own reference data set for sales methods, and there would be one central reference data set for payment terms assigned to all business units.
The reference data sharing is especially valuable for lowering the cost of setting up new business units. For example, your enterprise operates in the hospitality industry. You are adding a new business unit to track your new spa services. The hospitality divisional reference data set can be assigned to the new business unit to quickly setup data for this entity component. You can establish other business unit reference data in a business unit specific reference data set as needed
There are variations in the methods used to share data in reference data sets across different types of objects. The following list identifies the methods:
Assignment to one set only, no common values allowed. The simplest form of sharing reference data that allows assigning a reference data object instance to one and only one set. For example, Asset Prorate Conventions are defined and assigned to only one reference data set. This set can be shared across multiple asset books, but all the values are contained only in this one set.
Assignment to one set only, with common values. The most commonly used method of sharing reference data that allows defining reference data object instance across all sets. For example, Receivables Transaction Types are assigned to a common set that is available to all the business units without the need to be explicitly assigned the transaction types to each business unit. In addition, you can assign a business unit specific set of transaction types. At transaction entry, the list of values for transaction types includes transaction types from the set assigned to the business unit, as well as transaction types assigned to the common set that is shared across all business units.
Assignment to multiple sets, no common values allowed. The method of sharing reference data that allows a reference data object instance to be assigned to multiple sets. For instance, Payables Payment Terms use this method. It means that each payment term can be assigned to one or more than one set. For example, you assign the payment term Net 30 to several sets, but the payment term Net 15 is assigned to only your corporate business unit specific set. At transaction entry, the list of values for payment terms consists of only one set of data; the set that is assigned to the transaction's business unit.
Note: Oracle Fusion Applications contains a reference data set called Enterprise. Define any reference data that affects your entire enterprise in this set.
You can assign the reference data sets to reference objects on the Manage Reference Data Set Assignments page. For multiple assignments, you can classify different types of reference data sets into groups and assign them to reference entity objects. The assignment takes into consideration the determinant type, determinant, and reference group, if any.
The partitioned reference data is shared based on a business context setting called the determinant type. It is the point of reference used in the data assignment process. The following table lists the determinant types used in the reference data assignment.
Type |
Description |
---|---|
Asset Book |
Information about the acquisition, depreciation, and retirement of an asset that belongs to a ledger or a business unit. |
Business Unit |
The departments or organizations within an enterprise. |
Cost Organization |
The organization used for cost accounting and reporting on various inventory and cost centers within an enterprise. |
Project Unit |
A logical organization within an enterprise that is responsible for enforcing consistent project management practices. |
Reference Data Set |
References to other shared reference data sets. |
The determinant or determinant value is the value that corresponds to the selected determinant type. The determinant is one of the criteria for selecting the appropriate reference data set. For example, when managing set assignments for the set determinant type, Reference Data Set is the determinant type, and you would enter the corresponding set code value as the corresponding determinant value.
A transactional entity may have multiple reference entities (generally considered to be setup data) that are treated in the same manner because of commonness in implementing business policies and legal rules. Such reference entities in your application are grouped into logical units called reference groups, based on the functional area and the partitioning requirements that they have in common. For example, all tables and views that define Sales Order Type details might be part of the same reference group.
Note
The reference groups are predefined in the reference groups table and are available for selection and assignment.
Lookups are lists of values in applications. You define a list of values as a lookup type consisting of a set of lookup codes, each code's translated meaning, and optionally a tag. End users see the list of translated meanings as the available values for an object.
Lookups provide a means of validation and lists of values where valid values appear on a list with no duplicate values. For example, an application might store the values Y and N in a column in a table, but when displaying those values in the user interface, Yes or No (or their translated equivalents) should be available for end users to select. For example, the two lookup codes Y and N are defined in the REQUIRED_INDICATOR lookup type.
In another example, a lookup type for marital status has lookup codes for users to specify married, single, or available legal partnerships.
Lookup Type |
Lookup Code |
Meaning |
Tag |
---|---|---|---|
MAR_STATUS |
M |
Married |
|
|
S |
Single |
|
|
R |
Registered Partner |
+NL |
|
DP |
Domestic Partner |
-FR, AU |
In this case, tags are used for localizing the codes. All legislations list Married and Single. Only the Dutch legislation lists Registered Partner. And all legislations except France and Australia also list Domestic Partner.
When managing lookups, you need to understand the following.
Using lookups in applications
Customization levels
Accessing lookups
Enabling lookups
The three kinds of lookups: standard, common, and set enabled
Use lookups to provide validation or a list of values for a user input field in a user interface.
An example of a lookup used for validation is a flexfield segment using a table-validated value set with values from a lookup type. An example of a lookup in a list of values is a profile option's available values from which users select one to set the profile option. Invoice Approval Status gives the option of including payables invoices of different approval statuses in a report. The lookup code values include All so that users can report by all statuses: Approved, Resubmitted for approval, Pending or rejected, and Rejected.
The customization level of a lookup type determines whether the lookups in that lookup type can be edited. This applies data security to lookups.
Some lookup types are locked so no new codes and other changes can be added during implementation or later, as needed. Depending on the customization level of a lookup type, you may be able to change the codes or their meanings. Some lookups are designated as extensible, so new lookup codes can be created during implementation, but the meanings of predefined lookup codes cannot be modified. Some predefined lookup codes can be changed during implementation or later, as needed.
The customization levels are user, extensible, and system. The following table shows which lookup management tasks are allowed at each customization level.
Allowed Task |
User |
Extensible |
System |
---|---|---|---|
Deleting a lookup type |
Yes |
No |
No |
Inserting new codes |
Yes |
Yes |
No |
Updating start date, end date, and enabled fields |
Yes |
Yes, only if the code is not predefined data |
No |
Deleting codes |
Yes |
Yes, only if the code is not predefined data |
No |
Updating tags |
Yes |
No |
No |
Updating module |
Yes |
No |
No |
Predefined data means LAST_UPDATED_BY = SEED_DATA_FROM_APPLICATION.
If a product depends on a lookup, the customization level should be system or extensible to prevent deletion.
Once the customization level is set for a lookup type, it cannot be modified. The customization level for lookup types created using the Define Lookups page is by default set at the User level.
The available kinds of lookups are as follows.
Lookup |
Description |
---|---|
Standard |
Lists the available codes and translated meanings |
Set enabled |
Additionally associates a reference data set with the lookup codes |
Common |
Legacy lookups |
Standard lookups are the simplest form of lookup types consisting only of codes and their translated meaning. They differ from common lookups only in being defined in the standard lookup view.
Common lookups exist for reasons of backward compatibility and differ from standard lookups only in being defined in the common lookup view.
Set enabled lookup types store lookup codes that are enabled for reference data sharing. At runtime, a set-enabled lookup code is visible because the value of the determinant identifies a reference data set in which the lookup code is present.
Standard, set-enabled, and common lookups are defined in the Standard, Set-enabled, and Common views, respectively. Applications development may define lookups in an application view to restrict the UI pages where they may appear.
In lookups management tasks, lookups may be associated with a module in the application taxonomy to provide a criteria for narrowing a search or limiting the number of lookups accessed by a product specific task such as Manage Purchasing Lookups.
A lookup type is reusable for attributes stored in multiple tables.
Enable lookups based on the following.
Selecting an Enabled check box
Specifying an enabled start date, end date, or both
Specifying a reference data set determinant
If you make changes to a lookup, users must sign out and back in before the changes take effect. When defining a list of values for display rather than validation, limit the number of enabled lookup codes to a usable length.
Creating a new standard lookup involves creating or selecting a lookup type to which the lookup code belongs, and determining appropriate values for the lookup codes and their meanings.
Note
You can only create or edit the lookup codes for a particular lookup type if its customization level supports it.
Your enterprise needs a list of values for status to be used on various objects such as processes or users. The lookups are colors, so the lookup type you create is COLORS.
Lookup type parameters |
Value |
---|---|
Lookup type name |
COLORS |
Meaning |
Status |
Description |
Status by color |
Module |
Oracle Fusion Middleware Extensions for Applications |
The lookup codes you define for the COLORS lookup type are, BLUE, RED, GREEN, and YELLOW.
Lookup Code |
Meaning |
Enabled |
Display Sequence |
---|---|---|---|
BLUE |
Urgent |
No |
4 |
RED |
Stop |
Yes |
1 |
GREEN |
Go |
Yes |
3 |
YELLOW |
Caution |
Yes |
2 |
Users need to respond to a process question by indicating whether to stop it, use caution, go ahead, or complete it urgently.
The list of values for the COLORS lookup type includes the meanings for the enabled codes.
Displayed Value |
Hidden ID |
---|---|
Stop |
RED |
Caution |
YELLOW |
Go |
GREEN |
The BLUE lookup code was not enabled and does not appear in the list of values. The display sequence of values in the list of values is alphabetical unless you enter a number manually to determine the order of appearance. Number 1 indicates the value listed first in the list of values.
Note
Only lookups that are enabled and active, meaning between start and end dates, are visible.
When users enter one of the values from the list of values for the lookup type COLORS, the transaction table records the lookup code. In this example, the code is stored in the Status column
Transaction number |
User name |
Status |
---|---|---|
1 |
Jane |
RED |
2 |
Bob |
YELLOW |
3 |
Alice |
BLUE |
The status for one user is BLUE because at the time they entered a value, BLUE was enabled. Disabling a lookup code does not affect transaction records in which that code is stored. Data querying and reporting have access to disabled lookup codes in transaction tables.
Creating a new set-enabled lookup is similar to creating a standard lookup with the addition of specifying a reference data set determinant for the lookup codes.
Note
You can only create or edit the lookup codes for a particular lookup type if its customization level supports it.
The reference data set for a set-enabled lookup code is part of its foreign key. This is unlike other set-enabled entities.
By specifying a reference group for a set-enabled lookup type you indicate which reference data set assignments are available for its lookup codes. For example a COLORS lookup type might be set enabled for a Countries reference group that includes the US and EU reference data set assignments.
The reference data set determines which lookup code is included in the list of values. If a COLORS lookup type contains a RED, YELLOW, ORANGE, and GREEN lookup code, you can enable one RED lookup as coming from the US reference data set and another RED lookup as coming from the EU reference data set with divergent meanings.
Reference Data Set |
Lookup Code |
Lookup Meaning |
---|---|---|
US |
RED |
Red |
US |
YELLOW |
Yellow |
US |
GREEN |
Green |
EU |
RED |
Rouge |
EU |
ORANGE |
Orange |
In addition to divergent meanings for lookup codes based on associated reference data set, some lookup codes may be unique to one or another reference data set as the ORANGE lookup is to the EU reference data set in this example.
In another example, a lookup type called HOLD_REASON provides a list of reasons for applying a hold to a contract renewal. Reference data sets determine which codes are included in the hold reason list of values.
Reference Data Set |
Lookup Code |
Lookup Meaning |
---|---|---|
US |
SEC |
SEC Compliance Review |
US |
DIR |
Needs Director's Approval |
US |
VP |
Needs Vice President's Approval |
CHINA |
CSRC |
Pending China Securities Regulatory Commission Review |
CHINA |
PR |
Needs President's Approval |
COMMON |
REQUESTED |
Customer Request |
Using the Manage Set Assignments task, you have defined assignments that designate the China business unit to refer to the CHINA and the US business unit to refer to the US and all business units to refer to the COMMON set. When end users place a contract hold in the US business unit, only the three reason codes in US_SET are available. When placing a contract hold in the China business, only the two codes in China_SET are available.
You can edit the existing lookup codesof a lookup type or add new lookup codes on the Define Lookups pages, which you can access by starting in the Setup and Maintenance work area and searching for lookup tasks. You can edit the existing lookup codes of a lookup type, or add new lookup codes to a lookup type, if the customization level for the lookup type supports editing
Lookups are listed by lookup type. Typically lookup types are managed using tasks that handle a group of related lookups, such as Manage Geography Lookups. Each task gives you access only to certain lookup types. The generic tasks provide access to all lookups types of a kind, such as all common lookups using the Manage Common Lookups task.
If existing lookups are not available to the tasks of the Define Lookups activity, they may be validated for use in a lookup view that is not central to all applications or whose owning application has not been specified in a lookup view.
Lookups can only be managed in the Define Lookups tasks if the lookup's view application is the standard lookups view, common lookups view, or set-enabled lookups view. Lookups defined in an application view can only be managed by following instructions provided by the owning application.
Note
A lookup type and its codes can only be defined in one lookup view.
A lookup type consists of lookup codes that are the values in a static list of values. Lookup code validation is a one to one match.
A table-validated value set can consist of values that are validated through a SQL statement, which allows the list of values to be dynamic.
Tip
A table validated value set can be defined based on any table, including the lookups table. This allows a lookup type to be made into a table-validated value set that can be used in flexfields.
Area of Difference |
Lookup Type |
Value Set |
---|---|---|
List of values |
Static |
Dynamic if Table validation type |
Validation of values |
One to one match of meaning to code included in a lookup view, or through the determinant of a reference data set |
By format or inclusion in a table |
Format type of values |
char |
varchar2, number, and so on |
Length of value |
Text string up to 30 characters |
Any type of variable length from 1 to 4000 |
Duplication of values |
Never. Values are unique. |
Duplicate values allowed |
Management |
Managed by both administrators and end-users, except system lookups or predefined lookups at the system customization level, which cannot be modified. |
Maintained by administrators, except some product flexfield codes, such as GL for Oracle Fusion General Ledger, which are maintained by end users |
A lookup type cannot make use of a value from a value set.
Value sets can make use of standard, common, or set-enabled lookups.
Both lookup types and value sets are used to create lists of values from which users select values.
Tags on lookup codes allow you to add a label to your lookup codes.
Lookup tags are unvalidated and uninterpreted by lookups. A tag can be used to categorize lookups based on facilitating searches or guiding how a lookup should be used.
Document what the tag on a lookup represents and how to use it.
The message dictionary contains messages that tell users about business rule errors, such as missing or incorrect data, and how to resolve them, to warn users about the consequences of intended actions, and provide information in log files. These messages are defined for specific applications and modules, but a few are common messages that can be used in any application. All applications also use messages stored outside of the message dictionary.
The message dictionary is described in the Oracle Fusion Applications Developer's Guide, and other messages in the Oracle Fusion Middleware Web User Interface Developer's Guide for Oracle Application Development Framework.
Each message in the message dictionary has many attributes and components, including message properties, text, and tokens, that you define when creating or editing the message.
Details about these messages are described in the Oracle Fusion Applications Developer's Guide.
Common messages, which have message names that begin with FND_CMN and message numbers between 0 and 999, are used throughout Oracle Fusion Applications. Each common message can appear in multiple places in any product family. For example, the FND_CMN_NEW_SRCH message can be used for any search to indicate that no results were found. Common messages that are of type error or warning are part of the message dictionary.
Because a common message can be used in any application, consider the ramifications if you edit any aspect of the message, including incident and logging settings. Changes would be reflected in all instances where the message is used. For example, if you change the message text, make sure that the text would make sense to all users across Oracle Fusion Applications who might see it.
You can create custom common messages for use in multiple places within a single product. Do not begin the message name with FND_CMN, but use another suitable convention. The message number should be within the range that is designated for the product.
When creating or editing currencies, consider these points relevant to entering the currency code, date range, or symbol for the currency.
You cannot change a currency code after you enable the currency, even if you later disable that currency.
Users can enter transactions denominated in the currency only for the dates within the specified range. If you do not enter a start date, then the currency is valid immediately. If you do not enter an end date, then the currency is valid indefinitely.
Even if you enter a symbol for a currency, the symbol is not always displayed when an amount is displayed in this currency. Some applications use currency symbols when displaying amounts. Others, like Oracle Fusion General Ledger, do not.
Use the Derivation Type, Derivation Factor, and Derivation Effective Date fields to define the relationship between the official currency (Euro) of the European Monetary Union (EMU) and the national currencies of EMU member states. For each EMU currency, you define its Euro-to-EMU fixed conversion rate and the effective starting date.
Note
If you need to use a different currency code for Euro, you can disable the predefined Euro currency and create a new one.
The Euro currency derivation type is used only for the Euro, and the Euro derived derivation type identifies national currencies of EMU member states. All other currencies do not have derivation types.
The derivation factor is the fixed conversion rate by which you multiply one Euro to derive the equivalent EMU currency amount. The Euro currency itself should not have a derivation factor.
The derivation effective date is the date on which the relationship between the EMU currency and the Euro begins.
Natural languages are all the languages that humans use, written and spoken. If a language is enabled, then users can associate it with entities, for example as languages spoken by sales representatives. When managing natural languages, consider tasks to perform and best practices for entering particular values.
Once you add a language, it cannot be deleted, just disabled. You can optionally associate natural languages with International Organization for Standardization (ISO) languages and territories, just for reference.
When you create a natural language, use the alpha-2 ISO code as the language code, or, if not available, then alpha-3. If the language is not an ISO language, then use x- as a prefix for the code, for example x-ja for a Japanese dialect. Use the sgn code of ISO-639-2 for sign languages, followed by territory code, for example sgn-US for American Sign Language. You can also use Internet Assigned Numbers Authority (IANA) language tags.
The natural language description should be the language name with territory name in parenthesis where needed, for example English (Australia) and English (Canada).
Edit territory descriptions to determine how they are displayed in lists of country values throughout Oracle Fusion Applications. The predefined territories are all countries from the International Organization for Standardization (ISO) 3166 standard. You usually would not edit territory names or codes.
Do not edit National Language Support (NLS) territory codes, which are identifiers used in the system, unless you need to change the association between ISO and system territory. You usually would not edit the default currency, which is the value that defaults in the Currency field in Oracle Fusion Applications user preferences after the user first selects a territory.
Create territories if new countries emerge and the system has not yet been patched with the latest ISO country values.
Edit industry descriptions to determine how they are displayed in Oracle Fusion Applications. You usually would not edit industry names, which are from the North American Industry Classification System (NAICS). Enabled industries are mainly used in the context of customization, though these values can also appear in any application.
Create industries if you have particular ones you need, for example for customization, that are not included in the NAICS standard.
Optionally associate industries with territories to provide an industry in territory value, used for customization. For example, administrators can customize a page in one way for users within an industry in one country, and another way for users within the same industry in another country. The administrator would select the appropriate industry in territory value to set the customization context.
Create currencies to use, for example for reporting purposes, if they are not already provided. All currencies from the International Organization for Standardization (ISO) 4217 standard are provided.
Enable any currency other than USD for use in Oracle Fusion Applications, for example for displaying monetary amounts, assigning to sets of books, entering transactions, and recording balances. Only USD is enabled by default.
Precision is the number of digits to the right of the decimal point used in regular currency transactions. Extended precision is the number of digits to the right of the decimal point used in calculations for this currency, and it must be greater than or equal to the standard precision. For example, USD would have 2 for precision because amounts are transacted as such, for example $1.00. For calculations, for example adding USD amounts, you might want the application to be more precise than two decimal digits, and would enter an extended precision accordingly.
Note
Some applications use extended precision. Others, such as Oracle Fusion General Ledger, do not.
Minimum accountable unit is the smallest denomination for the currency. For example, for USD that would be .01 for the cent. This unit does not necessarily correspond to the precision for all currencies.
The statistical unit currency type is used only for the Statistical (STAT) currency. The Statistical currency is used to record statistics such as the number of items bought and sold. Statistical balances can be used directly in financial reports, allocation formulas, and other calculations.
You can edit the names and descriptions of International Organization for Standardization (ISO) languages to determine how they are displayed in lists of ISO language values in Oracle Fusion Applications. The ISO languages are from the ISO 639 standard. If there were changes to the ISO standard and the system has not yet been patched with the latest ISO values, you can update the ISO alpha-2 code or add languages as needed.
Installed languages automatically appear on the Manage Languages page, so you do not manually enter newly installed languages. This page contains all languages available for installation and translation in Oracle Fusion Applications. Each dialect is treated as a separate language. The language codes and names are values used by the system.
You generally would not edit any of the detailed fields unless you really need to and know what they are.
Though all standard time zones are provided, optionally enable only a subset for use in lists of time zone values in Oracle Fusion Applications. You can add time zones if new zones became standard and the system has not yet been patched with the latest values.
The reference implementation contains a set of data security policies that can be inspected and confirmed to be suitable or a basis for further implementation using the Authorization Policy Manager (APM).
The security implementation of an enterprise is likely a subset of the reference implementation, with the enterprise specifics of duty roles, data security policies, and HCM security profiles provided by the enterprise.
The business objects registered as secure in the reference implementation are database tables and views.
Granting or revoking object entitlement to a particular user or group of users on an object instance or set of instances extends the base Oracle Fusion Applications security reference implementation without requiring customization of the applications that access the data.
The data security policies in the reference implementation entitle the grantee (a role) to access instance sets of data based on SQL predicates in a WHERE clause.
Tip
When extending the reference implementation with additional data security policies, identify instance sets of data representing the business objects that need to be secured, rather than specific instances or all instances of the business objects.
Predefined data security policies are stored in the data security policy store, managed in the Authorization Policy Manager (APM), and described in the Oracle Fusion Applications Security Reference Manual for each offering. A data security policy for a duty role describes an entitlement granted to any job role that includes that duty role.
Warning
Review but do not modify HCM data security policies in APM except as a custom implementation. Use the HCM Manage Data Role And Security Profiles task to generate the necessary data security policies and data roles.
The reference implementation only enforces a portion of the data security policies in business intelligence that is considered most critical to risk management without negatively affecting performance. For performance reasons it is not practical to secure every level in every dimension. Your enterprise may have a different risk tolerance than assumed by the security reference implementation.
The security reference implementation includes some predefined HCM security profiles for initial usability. For example, a predefined HCM security profile allows line managers to see the people that report to them.
The IT security manager uses HCM security profiles to define the sets of HCM data that can be accessed by the roles that are provisioned to users
The security reference implementation includes no predefined data roles to ensure a fully secured initial Oracle Fusion Applications environment.
The security reference implementation includes data role templates that you can use to generate a set of data roles with entitlement to perform predefined business functions within data dimensions such as business unit. Oracle Fusion Payables invoicing and expense management are examples of predefined business functions. Accounts Payable Manager - US is a data role you might generate from a predefined data role template for payables invoicing if you set up a business unit called US.
HCM provides a mechanism for generating HCM related data roles.
By default, users are denied access to all data.
Data security makes data available to users by the following means.
Policies that define grants available through provisioned roles
Policies defined in application code
You secure data by provisioning roles that provide the necessary access. Enterprise roles provide access to data through data security policies defined for the inherited application roles.
When setting up the enterprise with structures such as business units, data roles are automatically generated that inherit job roles based on data role templates. Data roles also can be generated based on HCM security profiles. Data role templates and HCM security profiles enable defining the instance sets specified in data security policies.
When you provision a job role to a user, the job role implicitly limits data access based on the data security policies of the inherited duty roles. When you provision a data role to a user, the data role explicitly limits the data access of the inherited job role to a dimension of data.
Data security consists of privileges conditionally granted to a role and used to control access to the data. A privilege is a single, real world action on a single business object. A data security policy is a grant of a set of privileges to a principal on an object or attribute group for a given condition. A grant authorizes a role, the grantee, to actions on a set of database resources. A database resource is an object, object instance, or object instance set. An entitlement is one or more allowable actions applied to a set of database resources.
Data is secured by the following means.
Data security feature |
Does what? |
---|---|
Data security policy |
Grants access to roles by means of entitlement |
Role |
Applies data security policies with conditions to users through role provisioning. |
Data role template |
Defines the data roles generated based on enterprise setup of data dimensions such as business unit. |
HCM security profile |
Defines data security conditions on instances of object types such as person records, positions, and document types without requiring users to enter SQL code |
Masking |
Hides private data on non-production database instances |
Encryption |
Scrambles data to prevent users without decryption authorization from reading secured data |
The sets of data that a user can access via roles are defined in Oracle Fusion Data Security. Oracle Fusion Data Security integrates with Oracle Platform Security Services (OPSS) to entitle users or roles (which are stored externally) with access to data. Users are granted access through the entitlement assigned to the roles or role hierarchy with which the user is provisioned. Conditions are WHERE clauses that specify access within a particular dimension, such as by business unit to which the user is authorized.
Data security policies articulate the security requirement "Who can do What on Which set of data," where 'Which set of data' is an entire object or an object instance or object instance set and 'What' is the object entitlement.
For example, accounts payable managers can view AP disbursements for their business unit.
Who |
can do |
what |
on which set of data |
---|---|---|---|
Accounts payable managers |
view |
AP disbursements |
for their business unit |
A data security policy is a statement in a natural language, such as English, that typically defines the grant by which a role secures business objects. The grant records the following.
Table or view
Entitlement (actions expressed by privileges)
Instance set (data identified by the condition)
For example, disbursement is a business object that an accounts payable manager can manage by payment function for any employee expenses in the payment process.
Note
Some data security policies are not defined as grants but directly in applications code. The security reference manuals for Oracle Fusion Applications offerings differentiate between data security policies that define a grant and data security policies defined in Oracle Fusion applications code.
A business object participating in a data security policy is the database resource of the policy.
Data security policies that use job or duty roles refer to data security entitlement.
For example, the data security policy for the Accounts Payable Manager job role refers to the view action on AP disbursements as the data security entitlement.
Important
The duty roles inherited by the job role can be moved and job roles reassembled without having to modify the data security.
As a security guideline, data security policies based on user session context should entitle a duty role. This keeps both function and data security policies at the duty role level, thus reducing errors.
For example, a Sales Party Management Duty can update Sales Party where the provisioned user is a member of the territory associated with the sales account. Or the Sales Party Management Duty can update Sales Party where the provisioned user is in the management chain of a resource who is on the sales account team with edit access. Or the Participant Interaction Management Duty can view an Interaction where the provisioned user is a participant of the Interaction.
For example, the Disbursement Process Management Duty role includes entitlement to build documents payable into payments. The Accounts Payable Manager job role inherits the Disbursement Process Management Duty role. Data security policies for the Disbursement Process Management Duty role authorize access to data associated with business objects such as AP disbursements within a business unit. As a result, the user provisioned with the Accounts Payable Manager job role is authorized to view AP disbursements within their business unit.
A data security policy identifies the entitlement (the actions that can be made on logical business objects or dashboards), the roles that can perform those actions, and the conditions that limit access. Conditions are readable WHERE clauses. The WHERE clause is defined in the data as an instance set and this is then referenced on a grant that also records the table name and required entitlement.
Data roles are implemented as job roles for a defined set of data.
A data role defines a dimension of data within which a job is performed. The data role inherits the job role that describes the job. For example, a data role entitles a user to perform a job in a business unit.
The data role inherits abstract or job roles and is granted data security privileges. Data roles carry the function security privileges inherited from job roles and also the data security privilege granted on database objects and table rows.
For example, an accounts payables specialist in the US Business Unit may be assigned the data role Accounts Payables Specialist - US Business Unit. This data role inherits the job role Accounts Payables Specialist and grants access to transactions in the US Business Unit.
A data role may be granted entitlement over a set people.
For example, a Benefits Administrator A-E is allowed to administer benefits for all people that have a surname that begins with A-E.
Data roles are created using data role templates. You create and maintain data roles in the Authorization Policy Manager (APM). Use the Manage Data Roles and Security Profiles task to create and maintain HCM data roles in Oracle Fusion HCM.
HCM security profiles are used to secure HCM data, such as people and departments. You use HCM security profiles to generate grants for an enterprise role. The resulting data role with its role hierarchy and grants operates in the same way as any other data role.
For example, an HCM security profile identifies all employees in the Finance division.
Oracle Fusion Payroll uses HCM security profiles to secure project organizations. Applications outside of HCM can use the HCM Data Roles UI pages to give their roles access to HR people.
Oracle Fusion Applications uses masking to protect sensitive data from view by unauthorized users. Encryption APIs mask sensitive fields in applications user interfaces. Additionally, Oracle Data Masking is available for masking data in non-production instances and Oracle Transparent Data Encryption is available for protecting data in transit or in backups independent of managing encryption keys.
A data security policy applies a condition and allowable actions to a database resource for a role. When that role is provisioned to a user, the user has access to data defined by the policy. In the case of the predefined security reference implementation, this role is always a duty role. Data roles generated to inherit the job role based on data role templates limit access to database resources in a particular dimension, such as the US business unit.
The database resource defines and instance of a data object. The data object is a table, view, or flexfield.
The following figure shows the database resource definition as the means by which a data security policy secures a data object. The database resource names the data object. The data security policy grants to a role access to that database resource based on the policy's action and condition.
A database resource specifies access to a table, view, or flexfield that is secured by a data security policy.
Name providing a means of identifying the database resource
Data object to which the database resource points
Data security policies consist of actions and conditions for accessing all, some, or a single row of a database resource.
Condition identifying the instance set of values in the data object
Action specifying the type of access allowed on the available values
Note
If the data security policy needs to be less restrictive than any available database resource for a data object, define a new data security policy.
Actions correspond to privileges that entitle kinds of access to objects, such as view, edit, or delete. The actions allowed by a data security policy include all or a subset of the actions that exist for the database resource.
A condition is either a SQL predicate or an XML filter. A condition expresses the values in the data object by a search operator or a relationship in a tree hierarchy. A SQL predicate, unlike an XML filter, is entered in a text field in the data security user interface pages and supports more complex filtering than an XML filter, such as nesting of conditions or sub queries. An XML filter, unlike a SQL predicate, is assembled from choices in the UI pages as an AND statement.
Tip
An XML filter can be effective in downstream processes such as business intelligence metrics. A SQL predicate cannot be used in downstream metrics.
Oracle Fusion Applications supports securing data through role-based access control (RBAC) by the following methods.
Method of securing data |
Reason |
Example |
---|---|---|
Data roles apply explicit data security policies on job and abstract roles |
Appropriate for job and abstract roles that should only access a subset of data, as defined by the data role template that generates the data role or by HCM security profiles. |
Accounts Payable Manager - US data role to provide an accounts payable manager in the US business unit with access to invoices in the US business unit. |
Data security policies |
Define data access for application roles and provide inheriting job and abstract roles with implicit data security |
Projects |
If a user has access to the same function through different roles that access different data sets, then the user has access to a union of those data sets.
When a runtime session is created, Oracle Platform Security Services (OPSS) propagates only the necessary user to role mapping based on Oracle Fusion Data Security grants. A grant can specify entitlement to the following.
Specific rows of data (data object) identified by primary key
Groups of data (instance set) based on a predicate that names a particular parameter
Data objects or instance sets based on runtime user session variables
Data is either identified by the primary key value of the row in the table where the data is stored. Or data is identified by a rule (SQL predicate) applied to the WHERE clause of a query against the table where the data is stored.
Oracle Fusion Data Security can be used to restrict the following.
Rows that are returned by a given query based on the intended business operation
Actions that are available for a given row
Grants control which data a user can access.
Note
Attribute level security using grants requires a data security policy to secure the attribute and the entitlement check enforces that policy.
A grant logically joins a user or role and an entitlement
with a static or parameterized object instance set. For example, REGION='WEST'
is a static object instance set
and REGION=&GRANT_ALIAS.PARAMETER1
is a parameterized object instance set. In the context of a specific
object instance, grants specify the allowable actions on the set of
accessible object instances. In the database, grants are stored in
FND_GRANTS and object instance sets are stored in FND_OBJECT_INSTANCE_SETS.
Object access can be tested using the privilege check application
programming interface (API).
A business object is a logical entity that is typically implemented as a table or view, and corresponds to a physical database resource. The data security policies of the security reference implementation secure predefined database resources. Use the Manage Data Security Policies task to define and register other database resources.
Data security policies identify sets of data on the registered business object and the actions that may be performed on the business object by a role The grant can be made by data instance, instance set or at a global level..
Note
Use parameterized object instance sets whenever feasible to reduce the number of predicates the database parses and the number of administrative intervention required as static object instances sets become obsolete. In HCM, security profiles generate the instance sets.
You use data role templates to generate data roles. You generate such data roles, and create and maintain data role templates in the Authorization Policy Manager (APM).
Note
HCM data roles are generated using the Manage Data Roles and Security Profiles task, which uses HCM security profiles, not data role templates, to define the data security condition.
The following attributes define a data role template.
Template name
Template description
Template group ID
Base roles
Data dimension
Data role naming rule
Data security policies
The data role template specifies which base roles to combine with which dimension values for a set of data security policies. The base roles are the parent job or abstract roles of the data roles.
Note
Abstract, job, and data roles are enterprise roles in Oracle Fusion Applications. Oracle Fusion Middleware products such as Oracle Identity Manager (OIM) and Authorization Policy Manager (APM) refer to enterprise roles as external roles. Duty roles are implemented as application roles in APM and scoped to individual Oracle Fusion Applications.
The dimension expresses stripes of data, such as territorial or geographic information you use to partition enterprise data. For example, business units are a type of dimension, and the values picked up for that dimension by the data role template as it creates data roles are the business units defined for your enterprise. The data role template constrains the generated data roles with grants of entitlement to access specific data resources with particular actions. The data role provides provisioned users with access to a dimensional subset of the data granted by a data security policy.
An example of a dimension is a business unit. An example of a dimension value is a specific business unit defined in your enterprise, such as US. An example of a data security policy is a grant to access a business object such as an invoice with a view entitlement.
When you generate data roles, the template applies the values of the dimension and participant data security policies to the group of base roles.
The template generates the data roles using a naming convention specified by the template's naming rule. The generated data roles are stored in the Lightweight Directory Access Protocol (LDAP) store. Once a data role is generated, you provision it to users. A user provisioned with a data role is granted permission to access the data defined by the dimension and data security grant policies of the data role template.
For example, a data role template contains an Accounts Payable Specialist role and an Accounts Payable Manager role as its base roles, and region as its dimension, with the dimension values US and UK. The naming convention is [base-role-name]:[DIMENSION-CODE-NAME]. This data role template generates four data roles.
Accounts Payable Specialist - US (business unit)
Accounts Payable Specialist - UK (business unit)
Accounts Payable Manager - US (business unit)
Accounts Payable Manager - UK (business unit)
If you add a base role to an existing data role template, you can generate a new set of data roles. If the naming rule is unchanged, existing data roles are overwritten.
If you remove a base role from a data role template and regenerate data roles, a resulting invalid role list gives you the option to delete or disable the data roles that would be changed by that removal.
If you add a dimension value to your enterprise that is used by a data role template, you must regenerate roles from that data role template to create a data role for the new dimension. For example if you add a business unit to your enterprise, you must regenerate data roles from the data role templates that include business unit as a dimension.
If you add or remove a dimension value from your enterprise that is used to generate data roles, regenerating the set of data roles adds or removes the data roles for those dimension values. If your enterprise has scheduled regeneration as an Oracle Enterprise Scheduler Services process, the changes are made automatically.
For information on working with data role templates, see the Oracle Fusion Middleware Administrator's Guide for Authorization Policy Manager (Oracle Fusion Applications Edition).
In Oracle Fusion Applications, each business document or business event is uniquely identified by a document sequence number that you assign to it. However, the document sequencing feature must be turned on (enabled) on the business document or event to allow the assignment. For example, if document sequencing is enabled, you can assign a document sequence number to an invoice that gets generated in response to a purchase order. You can use document sequences as a proof to track successfully executed transactions as well as failed transactions. Additionally, a document sequence helps in generating an audit trail, which can be used to identify how a particular transaction passed through various applications.
Document sequencing can be managed automatically, manually, and gaplessly.
Note
Plan your document sequencing carefully before you use the options available in the application to apply sequence numbers. Avoid changes to the options after you saved your work on the Manage Document Sequences and Manage Document Sequence Categories pages.
Automatic document sequencing assigns a unique number to each document as it is generated, and this unique number is stored in the database. The numbering is sequential by date and time of creation. If you define a sequence to automatically number documents, you can provide an initial value to begin the sequence. In absence of a custom value, the default value 1 is used.
Manual sequencing requires you to assign a unique number to each document before it is generated. In manual sequencing, the numerical ordering and completeness of a transaction is not enforced. Users can skip or omit numbers when entering the sequence value. However, each time that a number is assigned, the application validates its uniqueness.
Gapless sequencing is similar to automatic sequencing. It automatically generates a unique number for each document, but does that only for successfully generated documents. As a result, the sequence is maintained for all the documents that are generated, and no sequence numbers are lost due to incomplete or failed document generation.
Important
Use this type of sequencing only if necessary because it may affect the performance of the system and slow down transaction processing.
The Sequential Numbering Enforced profile validates the documents being created and applies the relevant document sequence, based on the selected option. The following options are available:
Always Used: Sequential numbering is enforced for all document categories. When this option is set, users cannot create a document if its document category is not assigned any active document sequence. The system displays an error.
Partially Used: Sequential numbering is enforced for all document categories. However, if no sequence is available for the document, the system displays a warning. Users can either proceed without a document sequence or create and assign a document sequence before proceeding.
Not Used: Sequential numbering is not enforced. In this mode, although the documents created do not require a document sequence to be assigned, the system checks for the uniqueness of the document number provided. The system does not display any warning or error.
Restriction
At the site level, the profile is by default set to Partially Used. Avoid changing this option as doing so may interfere with the validation logic and the data that was stored using the earlier option may not appear. However, you can change the option at the product or user level.
A document sequence category is a set of documents that share similar characteristics and that are formed into a logical group. Document sequence categories simplify the task of assigning number sequences to specific documents. Instead of assigning a number to each document, you assign a document sequence to one or more document sequence categories. The document sequence category automatically takes care of numbering the documents.
A document sequence category identifies the database table that stores documents resulting from transactions that your users enter. When you assign a sequence to a category, the sequence numbers the documents that are stored in a particular table. You must create document sequence categories to be able to manage the task of assigning document sequences.
Restriction
Once a document sequence category is created, you cannot change the application, the category code, or the table name. Therefore, carefully consider these details and plan your document sequencing requirement before you begin working with the application.
Once you create a document sequence category, it is available for use under the Document Sequences: Assignments section on the Manage Document Sequences page. The Category field contains the name of the document sequence category. After you create a document sequence, you can assign it to a document sequence category.
Sequencing documents is an important business and legal requirement. Certain aspects of the defining process are permanent and cannot be modified later. Therefore, it is important that you first decide the appropriate document sequence to use for a set of documents. You must also decide beforehand the type of document sequencing, because you are not allowed to switch to other types once a sequence is assigned to a document sequence category. Make a note of the details such as the document sequence and document sequence category so that you can refer to them at a later point in time. Also note if there are any restrictions or configuration prerequisites before you define document sequencing.
Note
Products that implement document sequencing have specifications about its usage. Refer to the corresponding product documentation for specific details and also to determine if there are any restrictions or configuration prerequisites.
You can create document sequences that are automatic, manual, or gapless, depending on the business or legal requirement. By default, the current date is considered as the start date. If the end date is left blank, it means that the sequence definition never expires. Among the several options used in creating and editing document sequences, the following options are functionally more important and therefore need to be carefully determined:
Determinant Type: Select to limit the document sequencing activity to certain documents that belong to a specific business entity, such as Ledger, Tax Registration, and so on.
Initial Value: Enter a value for the first document in your sequence. This field applies only to sequences with automatic or gapless numbering types. Sequence numbers should not be greater than eight digits. If you leave this field blank, the first document is automatically assigned a value of 1. Once a document sequence is defined, you cannot change this initial value.
Document sequence categories are defined to make it easy to assign document sequence definitions to a group of documents instead of to individual documents. Each document sequence category is mapped to a specific table, where the documents belonging to that category are stored. The table must already be enabled for document sequencing. When specifying the table, you must consider the following points:
When the sequential numbering feature checks for completeness or generates a report, it locates the category's documents in the table.
You can select only tables belonging to the application associated with the category.
Once a category is defined, you cannot change the choice of table.
Identify the documents to be numbered before assigning them a document sequence. For each document sequence, there can be only one active assignment to a document sequence category, a method code, and a determinant value (if applicable). As part of the assignment, specify whether the document is created automatically (for example, due to a batch process, or manually through a form). If you do not specify an end date, the assignment continues to remain active throughout the process cycle. If a determinant type was specified for the document sequence, then enter a specific determinant value related to the selected determinant type.
At runtime, when users create documents, the document sequence to be assigned is determined by finding the active assignment that matches the correct combination of category, numbering method, and the date range containing the transaction date.
You can audit document sequences, if required, to provide an audit trail of the document sequences used in a specific product. However, before enabling the audit functionality for a document sequence, you must have created an audit table for the specific document sequence, using appropriate details. Enabling the audit functionality is permitted only for newly created document sequences. You cannot audit document sequences that are already in use by a specific product.
For more information about defining a document sequence audit table, see the Oracle Fusion Applications Developer's Guide.
Use the tree management feature in Oracle Fusion applications to organize data into hierarchies. A hierarchy contains organized data and enables the creation of groups and rollups of information that exist within an organization. Trees are hierarchical structures that enable several data management functions such as better access control, application of business rules at various levels of hierarchies, improved query performance, and so on.
For example, XYZ Corporation has two departments: Marketing and Finance. The Finance department has two functional divisions: Receivables and Payables. Defining a tree for the XYZ Corporation establishes a hierarchy between the organization and its departments, and between the departments and their respective functional divisions. Such a hierarchical modeling of organizational data could be used for executing several data management functions within that organization.
You can create one or more versions of trees, and they can be labeled for better accessibility and information retrieval. You can create trees for multiple data sources, which allow the trees to be shared across Oracle Fusion applications.
A tree structure is a representation of the data hierarchy, and guides the creation of a tree. A tree is an instance of the hierarchy as defined in the tree structure. Tree structures enable you to enforce business rules to which the data must adhere.
The root node is the topmost node of a tree. Child nodes report to the root node. Child nodes at the same level, which report to a common parent node, are called siblings. Leaves are details branching off from a node but not extending further down the tree hierarchy.
A tree is created having only one version. However, users can create more than one tree version depending on the need, and they can make changes to those versions. Depending on varying requirements, users can create one or more tree versions and publish all of them or some of them by making the versions active at the same time. Similar to any other version control system, versions of trees are maintained to keep track of all the changes that a tree undergoes in its life cycle.
Tree labels are short names associated with trees and tree structures and point directly to the data source. Tree labels are automatically assigned to the tree nodes. You can store labels in any table and register the label data source with the tree structure.
A tree structure defines the hierarchy for creating trees and prescribes rules based on which trees are created, versioned, and accessed. You can associate multiple data sources with a tree structure. A tree is an instance of this hierarchy. Every tree structure can contain one or more trees.
You can create tree structures specific to an application but you can share tree structures across applications. If you apply version control to the tree structure, it is carried over to the trees that are based on the tree structure. Each tree version contains at least one root node. Occasionally, a tree version may have more than one root node.
An administrator controls the access to tree structures through a set of rules that are periodically audited for validity.
Defining a tree structure involves specifying several important pieces of information on the Create Tree Structure: Specify Definition page.
The Tree Node table displays data in nodes that exist in the data hierarchy. You must select the correct and most appropriate tree node table to be able to define the tree structure, based on the tree hierarchy you want to establish. This selection also affects the level of security that is set on a tree node and its child entities.
The following options are used to determine the mode of sharing a tree structure across the applications.
Open: Indicates that the tree is associated with all reference data sets.
Set ID: Indicates that the tree will be associated with a specific reference data set.
Indicates the source where the tree structure is being defined. For predefined tree structures select Oracle and for custom structures, select Customers.
You can customize the predefined tree structures as well as the ones that you created. However, customizing the predefined tree structures involves certain level of access restrictions, and will be limited to specific tree nodes and downwards in hierarchy.
One or more trees and tree versions can be based on a tree structure. A tree structure can have one or more trees and tree versions based on it. Usually, only one active version is permitted at any given point of time. However, depending on the requirement, you can allow two or more tree versions to be in the active state for the same date range. This flexibility allows you to choose the tree version that you want to implement.
You can create, edit, and delete tree structures depending upon the requirement. You can also audit and change the status a tree structure.
You can create trees on the basis of a tree structure. When you edit an active tree structure, the status of the tree structure and all associated trees and their versions change to draft. To reuse a tree structure, you can create a copy of it without copying the associated trees and tree versions. If you delete a tree structure, all the associated trees and tree versions are automatically deleted.
Note
For specific information on working with the predefined tree structures that exist in an Oracle Fusion application, refer to the specific product documentation.
If you change the status of a tree structure, the status of the trees and tree versions associated with that tree structure also changes.
The following table lists the different statuses of a tree structure.
Status |
Meaning |
---|---|
Draft |
Yet to be published or is in a modified state. |
Active |
In use and based on which one or more trees or tree versions are created. |
Inactive |
Not in use. |
Use the tree structure audit results to verify the tree structure's correctness and data integrity. The audit results include the following details:
The name of the validator, which is a specific validation check
The result of the validation, including a detailed message
Corrective actions to take if there are any validation errors
Setting the status of a tree structure to active automatically triggers an audit of that tree structure. You can also manually trigger an audit on the manage Tree Structures page, using Actions - Audit. The Tree Structure Audit Result table shows a list of validations that ran against the selected tree structure.
The following table lists the validators used in the audit process and describes what each validator checks for. It also lists possible causes for validation errors and suggests corrective actions.
Validator |
Description (what is checked) |
Possible Cause for Validation Failure |
Suggested Corrective Action |
---|---|---|---|
Restrict By Set ID |
On the Manage Tree Structures: Specify Data Sources page, if the Set ID check box is selected to enable the Restrict Tree Node List of Values Based on option for a tree structure, each of its data source view objects must have a reference data set attribute. This validation does not take place when the check box is not selected. |
Even when the check box is selected, one or more of its data source view objects does not contain a reference data set attribute. |
If reference data set restriction is required for this tree structure, include a reference data set attribute on all data sources. Otherwise, deselect the check box. |
Row Flattened Table Name |
On the Manage Tree Structures: Specify Performance
Options page, a valid row flattened table must be specified for the
tree structure. It can either be the standard row flattened table |
|
Correct the row flattened table definition. |
Available Label Data Sources |
On the Manage Tree Structures: Specify Data Sources page, if a labeling scheme is specified for the tree structure by selecting a list item from the Labeling Scheme list box, the label data source view object specified for each data source must be accessible, and the primary keys must be valid. This restriction does not apply when you select None from the Labeling Scheme list box. |
|
|
Available Data Sources |
Each data source view object specified for the tree structure must be accessible, and all its primary key attributes must be valid. |
|
|
Column Flattened Table Name |
On the Manage Tree Structures: Specify Performance
Options page, a valid column flattened table must be specified for
the tree structure. It can either be the standard row flattened table |
|
Correct the column flattened table definition. |
Restrict by Date |
On the Manage Tree Structures: Specify Data Sources page, if the Date Range check box is selected to enable the Restrict Tree Node List of Values Based on option for a tree structure, each of its data source view objects must have effective start date and effective end date attributes. This validation does not take place when the check box is not selected. |
Even when the check box is selected, one or more of its data source view objects does not contain effective start date and effective end date attributes. |
If the date restriction is required for this tree structure, include the effective start date and effective end date attributes on all data sources. Otherwise, deselect the check box. |
Tree Node Table Name |
On the Manage Tree Structures: Specify Definition
page, a valid tree node table must be specified for the tree structure.
It can either be the standard row flattened table |
|
Correct the tree node table definition. |
Allow Node Level Security |
If the |
The option is set to No for the tree structure but one or more associated data sources have that option set to Yes. |
Correct the option setting in the tree structure and their data sources. |
The data sources provide the items for establishing hierarchy in a tree structure. In the tree management infrastructure, these data sources are Oracle Application Development Framework (ADF) business components view objects, which are defined by application development.
Selecting a labeling scheme determines how the tree nodes are labeled. You may select a labeling scheme to assign at the data source level, at the parent node level, or keep it open for customer assignment. You may also choose not to have any labeling scheme. However, if you decide to use any of the labeling schemes, you may need to select the following additional options, to restrict the list of values that appear under the selected tree node.
Allow Ragged Nodes: To include nodes that have no child nodes, and are shorter than the remaining nodes in the entire hierarchy.
Allow Skip Level Nodes: To include nodes that are at the same level but have parent nodes at different levels.
You can decide the depth of the tree structure by selecting an appropriate value from the list. Keeping the depth limit open renders an infinite list of values.
Using the following options, you can restrict the list of values that appear for selection under a specific tree node.
Date Range: Specifies whether a selection of nodes should be restricted to the same date range as the tree version.
Allow Multiple Root Nodes: Allows you to add multiple root nodes when creating a tree version.
Reference Data Set: Specifies whether a selection of nodes should be restricted to the same set as the tree.
Tree data sources have optional data source parameters with defined view criteria and associated bind variables. You can specify view criteria as a data source parameter when creating a tree structure, and edit the parameters when creating a tree. Multiple data sources can be associated with a tree structure and can have well-defined relationships among them.
Note
Parameter values customized at the tree level override the default values specified at the tree-structure level.
The data source parameters are applied to any tree version belonging to that data source, when performing node operations on the tree nodes. Data source parameters also provide an additional level of filtering for different tree structures. The tree structure definition supports three data source parameter types.
Bound Value: Captures any fixed value, which is used as part of the view criteria condition.
Variable: Captures and binds a dynamic value that is being used by the data source view object. This value is used by the WHERE condition of the data flow.
View Criteria: Captures the view criteria name, which is applied to the data source view object.
You can also specify which of the data source parameters are mandatory while creating or editing the tree structure.
View objects from the ADF business components are used as data sources. To associate the view object with the tree structure, you can pick the code from ADF business component view objects and provide the fully qualified name of the view object, for example, oracle.apps.fnd.applcore.trees.model.view.FndLabelVO.
Tree structures are heavily loaded with data. As a tree management guideline, use the following settings to improve performance of data rendering and retrieval.
Row Flattening
Column Flattening
Column Flattened Entity Objects
ADF Business Component View Objects
Row flattening optimizes parent-child information for run-time performance by storing additional rows in a table for instantly finding all descendants of a parent without initiating a CONNECT BY query. Row flattening eliminates recursive queries, which allows operations to perform across an entire subtree more efficiently.
To store row flattened data for the specific tree
structure, users can either use the central FND_TREE_NODE_RF
table or they can register their own row flattened table. For example,
in a table, if Corporation is the parent of Sales Division (Corporation-Sales
Division), and Sales Division is the parent of Region (Sales Division-Region),
a row-flattened table contains an additional row with Corporation
directly being the parent of Region (Corporation-Region).
Column flattening optimizes parent-child information for run-time performance by storing an additional column in a table for all parents of a child.
To store column flattened data for the specific tree
structure, users can either use the central FND_TREE_NODE_CF
table or they can register their own column flattened table. For
example, in a table, if Corporation is the parent of Sales Division
(Corporation-Sales Division), and Sales Division is the parent of
Region (Sales Division-Region), a flattened table in addition to these
columns, contains three new columns: Region, Sales Division, and Corporation.
Although positioned next to each other, the column Region functions
at the lower level and Corporation at the higher level, retaining
the data hierarchy.
In the absence of a column-flattened table, if you need to generate the business component view objects for your tree structure for the flattened table, use the tree management infrastructure to correctly provide the fully qualified name of the entity object for the column flattened table.
View objects from the ADF business components can also be used as data sources, eliminating the need to create new types of data sources. This field is to store the fully qualified name for the business component view object generated by the tree management for business intelligence reporting and usage The business component view object is a combination of the tree data source and column flattened entity. Using this option prevents data redundancy and promotes greater reuse of existing data, thereby improving the performance of the tree structure.
Tree labels are tags that are stored on tree nodes. You can store labels in any table and register the label data source with the tree structure. When a labeling scheme is used for trees, the selected labels are stored in the tree label entity and each tree node contains a reference to a tree label in the labeling scheme.
The following table lists the three ways in which tree labels are assigned to the tree nodes.
Labeling Scheme |
Description |
---|---|
Level |
Labels that are automatically assigned based on the data source to which the tree node belongs. A level label points to a specific data source. For example, in a tree that reflects the organizational hierarchy of an enterprise, all division nodes appear on one level and all department nodes on another. |
Group |
Labels that you can arbitrarily assign to tree nodes. |
Depth |
Labels that are automatically assigned based on the depth of the tree node within the tree. No manual assignment is performed. Note In an unbalanced hierarchy, a level may not be equal to depth. |
You can create and edit trees and tree versions depending upon the requirement. A tree can have one or more tree versions. Typically, when changes are made to an existing tree, a new version is created and published.
Trees are created based on the structure defined in the tree structure. You can create trees, modify existing trees, and delete trees. If you want to copy an existing tree, you can duplicate it. However, only the tree is duplicated and not its versions.
Creating a tree involves specifying the tree definition and specifying the labels that are used on its nodes. If the selected tree structure has data sources and parameters defined for it, they appear on the page allowing you to edit the parameter values at the tree node level.
Note
Parameter values customized at the tree level will override the default values specified at the tree-structure level.
Tree versions are created at the time of creating trees. A tree must contain a version.
Editing an existing tree provides you the choice to update the existing version. You can also edit the existing version that lies nested under the tree in the search results.
When you edit a tree version bearing Active status, the status changes to Draft until the modifications are saved or cancelled.
Use the tree version audit results to verify the tree version's correctness and data integrity. The audit results include the following details:
The name of the validator, which is a specific validation check
The result of the validation, including a detailed message
Corrective actions to take if there are any validation errors
An audit automatically runs whenever a tree version is set to active. You can also manually trigger an audit on the Manage Trees and Tree Versions page, using Actions - Audit. The Tree Version Audit Result table shows a list of validations that ran against the selected tree version.
The following table lists the validators used in the audit process and describes what each validator checks for. It also lists possible causes for validation errors and suggests corrective actions.
Validator |
Description (what is checked) |
Possible Cause for Validation Failure |
Suggested Corrective Action |
---|---|---|---|
Effective Date |
The effective start and end dates of the tree version must be valid. |
The effective end date is set to a value that is not greater than the effective start date. |
Modify the effective start and end dates such that the effective start date is earlier than the effective end date. |
Root Node |
On the Manage Tree Structures: Specify Data Sources page, if the Allow Multiple Root Nodes check box for the Restrict Tree Node List of Values Based on option is not selected, and if the tree structure is not empty, the tree version must contain exactly one root node. This validation does not take place if the check box is selected. |
Even if the check box is deselected, the tree version has multiple root nodes. |
Modify the tree version such that there is exactly one root node. |
Data Source Max Depth |
For each data source in the tree structure, on the Data Source dialog box, if the data source is depth-limited, the data in the tree version must adhere to the specified depth limit. This validation does not apply to data sources for which the Maximum Depth field is set to Unlimited. |
The tree version has data at a depth greater than the specified depth limit on one or more data sources. |
Modify the tree version such that all nodes are at a depth that complies with the data source depth limit. |
Duplicate Node |
On the Data Source dialog box, if the Allow Duplicates check box is not selected, the tree version should not contain more than one node with the same primary key from the data source. If the check box is selected, duplicate nodes are permitted. |
Even when the check box is deselected, the tree version contains duplicate nodes. |
Remove any duplicate nodes from the tree version. |
Available Node |
All nodes in the tree version should be valid and available in the underlying data source. |
|
Remove any orphaned nodes from the tree version. Update tree reference nodes so that they reference existing tree versions. |
Node Relationship |
All nodes must adhere to the relationships mandated by the data sources registered in the tree structure. |
The tree structure has data sources arranged in a parent-child relationship, but the nodes in the tree do not adhere to the same parent-child relationship. For example, if the tree structure has a Project data source with a Task data source as its child, Task nodes should always be under Project nodes in the tree version. This validation fails if there are instances where a Project node is added as the child of a Task node. |
Modify the tree version such that the nodes adhere to the same parent-child relationships as the data sources. |
SetID Restricted Node |
On the Manage Tree Structures: Specify Data sources page, if the Set ID check box is selected to enable the Restrict Tree Node List of Values Based on option for each tree node, the underlying node in the data source must belong to the same reference data set as the tree itself. This restriction does not apply when the check box is not selected. |
Even when the check box is selected, the tree version has nodes whose data source values belong to a different reference data set than the tree. |
Modify the tree version such that all nodes in the tree have data sources with reference data set matching that of the tree. |
Label Enabled Node |
On the Manage Tree Structures: Specify Data Sources page, if a labeling scheme is specified for the tree structure by selecting a list item from the Labeling Scheme list box, all nodes should have labels. This restriction does not apply when you select None from the Labeling Scheme list box. |
The tree structure has a labeling scheme but the tree version has nodes without labels. |
Assign a label to any node that does not have a label. |
Date Restricted Node |
On the Manage Tree Structures: Specify Data Sources page, if the Date Range check box is selected to enable the Restrict Tree Node List of Values Based on option for a tree structure, each node in the underlying data source must have an effective date range same as the effective date range of the tree version. This restriction does not apply if the check box is not selected. |
Even when the check box is selected, there are data source nodes that have a date range beyond the tree version's effective date range. For example, if the tree version is effective from Jan-01-2012 to Dec-31-2012, all nodes in the tree version must be effective from Jan-01-2012 to Dec-31-2012 at a minimum. It is acceptable for the nodes to be effective for a date range that extends partly beyond the tree version's effective date range (for example, the node data source value is effective from Dec-01-2011 to Mar-31-2013). It is not acceptable if the nodes are effective for none or only a part of the tree version's effective date range (for example, the node data source value are effective only from Jan-01-2012 to June-30-2012). |
Ensure that all nodes in the tree version have effective date range for the effective date range for the tree version. |
Multiple Active Tree Version |
On the Manage Tree Structures: Specify Definition page, if the Allow Multiple Active Tree Versions check box is not selected for the tree structure, there should not be more than one active tree version under a tree at any time. This restriction does not apply if the check box is selected. |
Even when the check box is not selected, there is more than one active tree version in the tree for the same date range. |
Set no more than one tree version to Active within the same date range and set the others to inactive or draft status. |
Range Based Node |
On the Data Source dialog box, if the Allow Range Children check box is not selected, range-based nodes are not permitted from that data source. This restriction does not apply if the check box is selected. |
Even when the check box is not selected, there are range-based nodes from a data source. |
Ensure that any range nodes in your tree version are from a data source that allows range children. |
Terminal Node |
On the Data Source dialog box, if the Allow Use as Leaves check box is not selected, values from that data source cannot be added as leaves (terminal nodes) to the tree version. This restriction does not apply if the check box is selected. |
Even when the check box is not selected, values from a data source are added as leaf nodes (terminal nodes). |
Modify the tree version such that all terminal nodes are from data sources for which this check box is selected. |
Usage Limit |
On the Data Source dialog box, if the Use All Values option is selected to set the Usage Limit for the data source, every value in the data source must appear as a node in the tree. This restriction does not apply if None option is selected. |
Even if the Use All Values option is selected, there are values in the data source that are not in the tree version. |
For each data source value that is not yet available, add nodes to the tree version. |
Data sources form the foundation for tree management in Oracle Fusion Applications. Tree structures, trees, and tree versions establish direct and real-time connectivity with the data sources. Changes to the data sources immediately reflect on the Manage Trees and Tree Versions page and wherever the trees are being used.
Tree structures contain the metadata of the actual data that is used in Oracle Fusion Applications. Tree structures contain the core business logic that is manifested in trees and tree versions.
Trees and tree versions are built upon the tree structures. They employ the business rules defined in the tree structures and allow an application to select and enable a subset of trees to fulfill a specific purpose in that application.
Source data is mapped to tree nodes at different levels in the database. Therefore, changes you make to the tree nodes affect the source data. Access control set on trees prevents unwanted data modifications in the database. Access control can be applied to the tree nodes or anywhere in the tree hierarchy.
Tree nodes are points of data convergence that serve as the building blocks of a tree structure. Technically, the node may be stored either in a product-specific table or in an entity that has been established by tree management as the default storage mechanism. However, since all data in Oracle Fusion Applications usually have a storage home, only user-created data needs to be stored in an entity.
Nodes are attached to tree versions. Whenever you create or edit a tree version, you need to specify its tree node.
You can create, modify, or delete tree nodes on the Tree Version: Specify Nodes page. To add a tree node, ensure that the tree structure with which the tree version is associated is mapped to a valid data source. You can also duplicate a tree node if the multiple root node feature is enabled.
In most trees, all nodes at the same level represent the same kind of information. For example, in a tree that reflects the organizational hierarchy, all division nodes appear on one level and all department nodes on another. Similarly, in a tree that organizes a user's product catalog, the nodes representing individual products might appear on one level and the nodes representing product lines on the next higher level.
When levels are not used, the nodes in the tree have no real hierarchy or reporting structure but do form a logical summarization structure. Strictly enforced levels mean that the named levels describe each node's position in the tree. This is natural for most hierarchies. Loosely enforced levels mean that the nodes at the same visual level of indentation do not all represent the same kind of information, or nodes representing the same kind of information appear at multiple levels. With loosely enforced levels, users assign a level to each node individually. The level is not tied to a particular visual position.
A tree node has the following node types.
Single: Indicates that the node is a value by itself.
Range: Indicates that the node represents a range of values and possibly could have many children. For example, a tree node representing account numbers 10000 to 99999.
Referenced Tree: Indicates that the tree node is actually another version for the tree based on the same tree structure, which is not physically stored in the same tree. For example, a geographic hierarchy for the United States can be referenced in a World geographic hierarchy.
Profile options manage configuration data centrally and influence the behavior of applications. Profile options serve as permanent user preferences and application configuration parameters. You configure profile options with settings for specific contexts or groups of users. Users customize how their user interfaces look and behave by changing the values of available profile options.
Profile options store the following kinds of information.
Type of Information |
Profile Option Example |
---|---|
User preferences |
Settings to provide access to social networking features |
Installation information |
Setting to identify the location of a portal |
Configuration choices |
Settings to change user interface skins and behaviors |
Processing options |
Settings to affect how much information to log either for an entire site or a specific user |
You can add and configure new profile options in addition to configuring predefined profile options that are implemented as updateable.
Application developers add new profile options and configure ones that are not to be updated by other users. Application administrators and implementation consultants configure profile options with profile option values that are implemented as updatable.
Profile option definitions consist of the following.
Profile option name
Application and module in the application taxonomy
Profile option values
Profile options categories
Profile option levels
Profile option level hierarchy
Profile options can appear on any user interface page without indication that a profile option is what is being set.
Some profile options have predefined profile option values.
The Manage Profile Option Values task flow allows an administrator to set updatable profile option values at the available levels, including the user level. You can access the Manage Profile Option Values task starting in the Setup and Maintenance Overview page and searching for profile option tasks.
You can set profile option values at different levels: site, product, and user. The following table provides examples.
Profile Option Level |
Value of the Profile Option Level |
Profile Option Value |
Effect |
---|---|---|---|
User |
Manager1 |
UK pound sterling |
Access to site and all products shows UK pounds sterling in effect |
User |
Manager2 |
US dollar |
Access to site and all products shows US dollars in effect |
Product |
Financials for EMEA |
Euro |
Unless superseded by a user level value, Euros in effect for Financials for EMEA applications |
Site |
Site |
UK pound sterling |
UK pounds sterling in effect for all other users and products |
Context such as user session or accessed product determines which profile option value is associated with the profile option name. In the example, if manager1 does not set a profile option value for this profile option, access to Financials for EMEA shows currency in Euros; and access to other products shows currency in UK pounds sterling.
Categories group profile options based on their functional area. Profile option categories facilitate searching and defining data security.
For example, in Oracle Fusion Receivables, the Transactions profile option category groups profile options related to setting how Receivables transactions are to be processed, such as Require Adjustment Reason.
A profile option can be in more than one category.
Application developers specify at which hierarchy level a profile option is enabled. The predefined profile option hierarchy levels are site, product, and user.
The hierarchy levels specified in the profile option definition determine the context in which a profile option value may be set. If the profile option value at a particular level is updatable, an administrator can update the profile option value for that context.
Note
Profile options should only be enabled for context levels that are appropriate for that profile option. For example, a profile option indicating a global configuration setting should not be enabled at the user level, if users cannot choose a different value for that setting.
For security, one level in the hierarchy is designated as a user level. A profile option may be enabled at any or all hierarchy levels. When enabled at all levels, the predefined ordering of profile option hierarchy levels gives precedence to the values that are set at the user level over values set at the product and site levels, and precedence to values set at the product level to values set at the site level. If there is no value for the current user, then the product value applies. If there is no value for the user or product, then the site value applies.
The table shows the predefined profile option hierarchy and ordering.
Hierarchy Level |
Priority When Multiple Levels Set |
Effect on Applications |
Example |
---|---|---|---|
Site |
Lowest |
Affect all applications for a given implementation |
Currency for the site is set to Euros. |
Product |
Supersedes Site |
Affect all applications of a product family such as Financials |
Currency for the Financials products set to UK pound sterling. |
User |
Highest, supersedes Product |
Affect only the experience of the current user |
Currency for the user of Financials applications set to US dollars. |
You can configure updatable values for profile options at one or more levels depending on which levels are enabled in the profile option definition. When a profile is set at more than one level, higher levels of specificity override lower levels of specificity.
In the example, if the currency setting for the site is UK pounds sterling, but the Financials division works in the Netherlands using the Euro, a manager in the US can override that product level setting at the user level to use US dollars when accessing Financials applications.
In another example, if a profile option called Printer is set only at the site and product levels. When a user logs on, the Printer profile option assumes the value set at the product level, since it is the highest level setting for the profile.
Tip
Set site-level profile option values before specifying values at any other level. The profile option values specified at the site-level work as defaults until profile option values are specified at the other levels.
Plan profile options before defining and configuring them.
The following aspects assist you in better planning how to manage profile options.
Profile option tasks
Before creating a profile option
Profile options data model
Users may be able to set their own profile options, depending on settings in the profile option definition. However, not all profile options are visible to end users, and some profile options, while visible, may not be updated by end users.
The following table lists tasks and considerations relevant to planning profile options.
Tasks |
Role |
Considerations |
---|---|---|
Planning, creating, and editing a new profile option |
Applications developer |
Since profile options are for permanent settings, do not use profiles options to cache temporary session attributes. Add capacity for user preferences and system configuration. Customize profile options with values, value behaviors, validation, category values, and security. Define the levels at which the profile option is enabled. |
Configure values in an existing profile option |
Applications developer, application administrator, and implementation consultant |
Manage the values for existing profile options. |
Create and edit profile option categories |
Applications developer, application administrator, and implementation consultant |
Manage categories for organizing existing profile options. |
Note
Since a profile option enables a behavior in an application user interface or across applications, a value change made by an end user is reflected in the UI page for managing profile option values.
Profile options are best defined for managing configuration data centrally and influencing the behavior of applications.
If the purpose of a profile option setting is specific to a piece of data (typically setup data), it is best implemented as an attribute of that data.
Do not use profile options for behavior that is not configurable.
Profile options exist independent of role.
Do not use profile options to implement function security. For example, an application should not check for a profile option value set to yes to provide access to a page. Do not use profile options to implement data security, such as a profile option value that must be set to a specific value to provide view access to an entity.
Do not use profile options to capture a dynamic system states, such as data stored in a temporary table. Use Global Variables for temporary states instead.
Evaluate if there is a genuine need before creating a profile option. Do not force users to make a decision about an aspect of their application use that is of no concern.
Evaluating need includes looking for duplicate or similar profile options, even in other products, before creating a new one. For example, you do not need multiple profile options to choose a preferred currency.
The profile option data model illustrates the relationships among profile option elements.
The figure shows the data model of profile option entities.
For more information about planning profile options, see the Oracle Fusion Applications Developer's Guide.
A profile option definition consists of a name for the profile option and valid values. It is defined within a module of the application taxonomy. Application developers manage profile options to create new profile options or modify existing profile option definitions, which includes specifying the levels at which a profile option is enabled and defining values. Implementation consultants and application administrators configure existing profile options by managing the profile option's updatable values, and creating categories that group profile options.
A profile option definition includes information about the owning application and module in the application taxonomy. A start or end date, or both may limit when a profile option is active. The profile option definition may include an SQL validation statement that determines which values are valid, and the hierarchy levels at which the profile option is enabled and updatable.
To be visible to users, a profile option must be user enabled. You can also allow user updates of the profile option, which means users can make changes to the validation and the profile option level information.
Profile option levels specify at which context level profile values may be enabled or updated. .
Profile options should only be enabled for context levels that are appropriate for that profile option. For example, a profile option indicating a global configuration setting should not be enabled at the user level, if users cannot choose a different value for that setting.
The SQL validation of the profile option definition determines what valid profile option values are available. In the absence of validation, any value is valid.
For example, SQL validation provides a means of defining a list of values for the valid values of the profile option. The SQL validation can use lookups to provide the valid values for profile options, such as the lookup codes of the YES_NO lookup type.
SELECT DESCRIPTION Language, NLS_LANGUAGE
FROM FND_LANGUAGES_VL
WHERE INSTALLED_FLAG IN ('B','I')
ORDER BY DESCRIPTION
This results in the following list of values based
on data in FND_LANUGUAGE_VL
.
Display Value |
Hidden Value |
---|---|
American English |
US |
French |
F |
Spanish |
E |
Hidden values must be varchar2(2000).
Profile options generally provide configuration values within a particular context. Though you can create a profile option to be global, think of global values as default values to avoid storing inappropriate configuration information as profile option values. Create global profile options that have corresponding contextual levels.
Use profile option categories to group profile options.
As a guideline, group profile options in a single category if the profile options affect the same feature, or if an administrator would likely want to see the profile options in the results of a single search.
Application developers are responsible for the initial groupings and then administrators can make changes based on their specific needs. Administrators can categorize profile options and then easily search on profile options by category.
Tip
Define profile option categories first and assign new profile options to existing categories rather than defining profile options first and then defining categories to categorize them.
You can add new categories or add profiles to an existing category.
You can create a profile option category by duplicating an existing category and editing it for a new grouping of profile options. You can add multiple profile options to a category. A profile option can exist in multiple categories.
Specify a profile option sequence to determine the order of profile options when queried by profile option category.
A profile option value consists of the value and the context or level where the value is set. You specify the context with a pairing of the profile option value's level and level value, such as the product level and the level value GL for Oracle Fusion General Ledger. Adding or modifying profile option values can include deciding which valid values are enabled or updatable at which level.
The SQL validation of the profile option definition determines what valid profile option values are available. In the absence of validation, any value is valid.
Site level profile option values affect the way all applications run for a given implementation. Product level profile option values affect the way applications owned by a particular product code behave. For example, a product may use profile options set at the product level to determine how regions provided by a common module such as those available from Oracle Fusion Trading Community Model or Customer Relationship Management (CRM) display in a particular work area or dashboard. User level profile option values affect the way applications run for a specific application user
Whichever profile option value is most specific to a user session, that is the value at which the profile option is set for the user session.
For example, the predefined FND_LANGUAGE profile option sets the default language. In addition to a site level value, you can define a value for various product or user levels.
Level Name |
Level Value |
Profile Option Value |
---|---|---|
Site |
InFusion |
American English |
Product |
Customer Center |
French |
Product |
CRM Application Composer |
American English |
User |
Application Administrator |
American English |
User |
Hima |
Hindi |
Values at the site level take effect for any user unless overridden by a different value set at the more specific levels of product and user. Product level profile option values affect the way applications owned by a particular product code behave. In addition to user level profile option values in applications, selections may be available in the user preferences workspace.
The following table demonstrates the FND_LANGUAGE profile option settings that would apply to specific users, based on the example above. For example, the user Hima is using the CRM Application Composer product, in the InFusion site. The example above shows that this profile option is set to Hindi at the user level for Hima. Because user is the highest applicable level for Hima, the applicable profile option value is Hindi for Hima.
Site |
Product |
User |
Highest Available Level |
Active Profile Option Value |
---|---|---|---|---|
InFusion |
CRM Application Composer |
Hima |
User |
Hindi |
Acme |
Payables |
Application Administrator |
User |
American English |
InFusion |
Customer Center |
Guillaume |
Product |
French |
InFusion |
Payables |
Implementation Consultant |
Site |
American English |
Acme |
Payables |
Implementation Consultant |
none |
no value |
Note
More than one site level value is relevant in an enterprise with multiple tenants using a single instance of Oracle Fusion Applications.
Any change you make to a user level profile option has an immediate effect on the way applications run for that session. When you sign in again, changes made to your user level profile options in a previous session are still in effect. When you change profile option value at the product level and no user level values are set, you see the update immediately, but other users may not see the changed value until signing out and back in. When you change a profile option value and the new value affects other users, the change takes effect only when users sign in the next time.
Changes to site level profile options take effect for any user session that is started after the setting has been changed. Changes to site or user level profile options do not affect any user sessions that are already in progress when the change is made.
Changes to site or user level profile options take effect for any C or PL/SQL processes, such as scheduled jobs, that are launched after the setting has been changed. Profile option changes do not affect C or PL/SQL processes that are already running.
Flexfields are a mechanism for configuring and extending applications to meet enterprise-specific needs. Using flexfields, you can extend application objects to capture data that would not otherwise be tracked by the application, or configure intelligent key codes comprised of meaningful parts according to your business practices. Flexfields encapsulate all of the pieces of information related to a specific purpose, such as a key identifying a particular purchase, or the components of a student's contact information, or the features of a product in inventory.
A flexfield is an extensible data field consisting of subfields Each subfield is a flexfield segment. You configure segments to capture enterprise-specific information. Each segment captures a single atomic value, has a name, and maps to a pre-reserved column in the applications database.
Flexfields allow enterprise requirements to be met without changing the data model. Different data can be captured on the same database table.
Application developers create a flexfield and register it so that it is available for configuration. Administrators and implementation consultants setup or configure segments and other properties of the available flexfields. End users see flexfield segments as attributes of information displayed in the application user interface. They enter a value for the attribute. The value may be selected from a list of valid values or entered as free-form text that complies with formatting rules.
Manage flexfields using tasks you access by starting in the Setup and Maintenance Overview page.
Tip
Use the Business Object parameter to search Application Key Flexfields, Application Descriptive Flexfields, and Application Extensible Flexfields to find all tasks related to flexfields. To manage any flexfield across all Oracle Fusion Applications products, search for the Define Flexfields task list and access the Manage Descriptive Flexfields, Manage Extensible Flexfields, and Manage Key Flexfields tasks.
The following three types of flexfields are available in Oracle Fusion Applications and provide a means to customize applications features without programming.
Key
Descriptive
Extensible
For example, in Oracle Fusion Financials, key flexfields represent objects such as accounting codes and asset categories. Generally, correct operations of a product depend on key flexfield setup. In Oracle Fusion Payables, a descriptive flexfield expands a customizable area of an invoices page by providing subfields for collecting invoice details. You can implement these subfields, which are descriptive flexfield segments, as context sensitive so they appear only when needed. Extensible flexfields are similar to descriptive flexfields, but provide additional advanced features. Generally setup of descriptive and extensible flexfields is optional because their segments capture additional information that is stored attributes on an entity
All flexfields consist of segments. Segments represent attributes of information. They can appear globally wherever the flexfield is implemented, or based on a structure or context.
You define the appearance and meaning of individual segments when configuring a flexfield.
A key flexfield segment commonly describes a characteristic of the entity identified by the flexfield, such as a part number structured to include information about the type, color, and size of an item. A descriptive flexfield segment represents an attribute of information that describes a characteristic of the entity identified on the application page, such as details about a device containing components, some of which are globally present on the page while others are contextually dependent on the category of the device.
A value set is a predefined, named group of values that can be used to validate the content of a flexfield segment.
You configure a flexfield segment with a value set that establishes the valid values that an end user can enter for the segment. You define the values in a value set, including such characteristics as the length and format of the values. You can specify formatting rules, or specify values from an application table or predefined list. Multiple segments within a flexfield, or multiple flexfields, can share a single value set.
Key flexfields have structure. Descriptive flexfields and extensible flexfields have context.
Each key flexfield structure is a specific configuration of segments. Adding or removing segments, or rearranging their order, produces a different structure. The database columns on which segments in different structures are based can be reused in as many structures as desired.
Descriptive flexfield segments can be context-sensitive, which means available to an application based on a context rather than globally available wherever the flexfield appears. (which means available to an application based on a context value rather than globally available wherever the flexfield appears. A descriptive flexfield context is a set of context-sensitive segments that store information related to the same context value. You define contexts as part of configuring a descriptive flexfield. End users see global segments, as well as any context-sensitive segments that apply to the selected context value.
Extensible flexfield segments are made available to an application based upon a category value. An extensible flexfield context serves as a container for related segments, used to organize the various segments that are applicable to a category value. You define contexts with context-sensitive segments and associate them to categories as part of configuring an extensible flexfield. End users see the segments displayed in subregions, one for each context associated to the selected category value.
In descriptive flexfields and extensible flexfields, the database columns on which context-sensitive segments are based can be reused in as many contexts as desired.
A flexfield must be deployed to display its current definition in a runtime application user interface. For example, if the deployment status is Edited, the flexfield segments may appear in the UI based on the flexfield definition at the time of last deployment, rather than the current definition.
You can deploy a flexfield as a sandbox for testing the configuration before deploying it to the mainline for all users.
In an application user interface, descriptive flexfield segments appear as label and field pairs or as a table of fields where the column headers correspond to the labels. The fields represent the flexfield segments and accept entered input or a selection from a list of choices that correspond to the segment's assigned value set. Extensible flexfield segments appear grouped within labeled regions, where each grouping is a context and the region labels are the context names.
Use the Highlight Flexfields command in the Administration menu of the Setup and Maintenance work area to identify the location of the descriptive and key flexfields on the runtime page. Flexfields in highlight mode display an information icon to access details about the flexfield, and an edit icon to manage the flexfield.
All segments of a single flexfield are grouped together by default. The layout and positions of the flexfield segments depend on where the application developer places the flexfield on the page. Flexfields may also be presented in a separate section of the page, in a table, or on their own page or subwindow.
You can use Oracle Composer to edit the layout, position, or other display features of the flexfield segments.
Administrators configure flexfield segments to capture data that represents the values of attributes. Flexfield segments represent attributes of entities (business objects). Most business objects are enabled for descriptive flexfields. Some business objects are enabled for extensible flexfields.
The figure shows the layers of a flexfield: the business entity table and metadata in the database, business components that are Application Development Framework (ADF) objects or ADFbc objects derived from the metadata and stored in the Metadata Services Repository (MDS), and the user interface where the input fields defined by the flexfield segments are rendered. The flexfield definition consists of all the metadata defined during configuration and stored in the database.
Application developers create a flexfield and register it so that it is available for configuration. Administrators and implementation consultants configure segments and other properties of the available flexfields. This information is stored as additional flexfield metadata in the database. Deploying the flexfield generates ADF business components based on the flexfield metadata in the database.
A flexfield affects the Web Services Description Language (WSDL) schemas exposed by ADF services and used by SOA composites. The Web services that expose base entity data also expose flexfield segment data.
Attributes incorporate into SOA infrastructure (BPEL, Rules) and integrate with business intelligence (Oracle Business Intelligence, Extended Spread Sheet Database (ESSbase)).
Flexfield configurations are preserved across Oracle Fusion Applications updates.
The metadata for the flexfield is stored in the application database as soon as you save your configuration changes. Deploying the flexfield generates the ADF business components so that the runtime user interface reflects the latest definition of the flexfield in the metadata.
You can export and import flexfields with a deployment status of Deployed or Deployed to Sandbox across instances of Oracle Fusion Applications using the Setup and Maintenance Overview page. Ensure a flexfield is eligible for migration (by verifying that it has successfully deployed) prior to attempting the migration.
For a flexfield to reflect the latest flexfield definition at runtime it must be deployed. The user interface accesses a business object and the deployed flexfield definition indicates which business object attributes the flexfield captures values for. If you add display customizations for a flexfield using Oracle Composer, these are customizations on the page so that the same flexfield segments can appear differently on various different pages.
Values entered for segments are validated using value sets.
Managing flexfields involves, registering, planning, and configuring flexfields.
You plan and configure the registered flexfields provided in your applications by applications developers. How you configure flexfield segments determines how the flexfield segments appear to end users. Optionally, you can customize the UI page to change how the flexfield segments appear to end users on that page.
The figure shows the processes involved in making flexfields available to end users. The tasks in the Define Flexfields activity allow administrators to configure and deploy flexfields. If you deploy a flexfield to a sandbox and decide not to make further changes, you select the flexfield in the Manage Flexfields tasks of the Define Flexfields activity and deploy the flexfield in the mainline so it is available to users.
Application development registers flexfields so they are available to administrators and implementation consultants for configuration.
Application development creates the capacity of database tables to support flexfields so an enterprise can capture specific information about an entity. Many flexfields are predefined in Oracle Fusion Applications.
A flexfield must be registered before it can be configured.
For more information on registering flexfields, see Oracle Fusion Applications: Developer's Guide.
All flexfields consist of segments which represent attributes of an entity. The values an end user inputs for an attribute are stored in a column of the entity table. Application development enables columns of entity tables for use in flexfields during flexfield registration.
A flexfield must be registered before it can be configured. Before configuring new flexfield segments for your enterprise, be sure to plan their implementation carefully.
For more information on planning flexfield configuration, see Oracle Fusion Applications Extensibility Guide.
Administrators or implementors configure flexfields so they meet the needs of the enterprise. Some flexfields require configuration to make an application operate correctly.
Configuring a flexfield includes the following.
Defining value sets against which the values entered by end users are validated
Defining the structure or context of the segments in the flexfield
Specifying the prompt, length and data type of each flexfield segment
Specifying valid values for each segment, and the meaning of each value within the application
Tip
As a flexfield guideline, define value sets before configuring the flexfield, because you assign value sets to each segment as you configure a flexfield.
Some descriptive flexfields provide parameters that are attributes of the same or related entity objects. You use parameters to set the initial value or derivation value of an attribute from external reference data, such as a column value or a session variable, rather than from user input.
Note
Adding segments to represent additional attributes is considered a custom task. For more information, see the Oracle Fusion Applications Extensibility Guide.
For more information on adding columns to a table, see the Oracle Fusion Applications Developer's Guide.
For more information on configuring flexfields for custom attributes, see also the Oracle Fusion Applications Extensibility Guide.
You can enable key flexfield segment instances and descriptive flexfield segments for business intelligence if the flexfield is registered in the database as an Oracle Business Intelligence-enabled flexfield. For more information on enabling segments for business intelligence, see points to consider when enabling key and descriptive flexfield segments for business intelligence.
After you configure or change a flexfield, you must deploy it to make the latest definition available to end users.
You deploy a flexfield in the mainline for general use in a test or production environment, or you can deploy a flexfield as a flexfield-enabled sandbox to confirm that it is correctly configured before deploying it to the mainline.
Deploying a flexfield results in a deployment status. Once deployed, the deployment status indicates the state of the currently configured flexfield relative to the last deployed definition
The flexfield attributes you define integrate with the user interface pages where users access the attributes' business object. Application development determines the UI pages where business objects appear and the display patterns used by default to render flexfield segments.
You can customize the appearance of the flexfield segments in the UI page using Oracle Composer once the flexfield is deployed to the mainline.
For more information on customizing flexfield appearance with Oracle Composer, see guidance on customizing existing pages in Oracle Fusion Applications Extensibility Guide.
For more information on planning flexfields or customizing them beyond the configuration possible in the Define Flexfields tasks, see Oracle Fusion Applications Extensibility Guide.
For more information on creating flexfields and adding them to a UI page, see Oracle Fusion Applications Developer's Guide.
The Highlight Flexfields command in the Administration menu of the Setup and Maintenance work area identifies the location of descriptive and key flexfields on the runtime page by displaying an information icon for accessing details about each flexfield.
Even if a flexfield has not yet been deployed and does not appear on the runtime page in normal view, it appears in the Highlight Flexfield view for that page. Highlight Flexfields accesses the current flexfield metadata definition.
Use the highlighted flexfield's edit icon to manage the descriptive or key flexfield directly. Alternatively, note a highlighted flexfield's name to search for it in the tasks for managing flexfields.
Independent of the value set assigned to a segment, segments may have properties such as validation.
Range validation enables you to enforce an arithmetic inequality between two segments of a flexfield. For example, a product must be ordered before it can be shipped, so the order date must be on or before the ship date, and consequently the order date segment value must be less than or equal to the ship date segment value. You can use range validation to ensure this relationship.
The conditions for range validation are as follows.
Segments must be configured for range validation in pairs, one with the low value and one with the high value.
Both segments must be the same data type.
Both segments must be part of the same structure in a key flexfield or part of the same context in a descriptive flexfield or extensible flexfield.
The low value segment must have a lower sequence number than the high value segment.
Non-range validated segments can exist between a range validated pair, but range validated pairs cannot overlap or be nested.
You can configure as many range validated pairs as you want within the same flexfield. Your application automatically detects and applies range validation to the segment pairs that you define, in sequence order. It must encounter a low value segment first, and the next range validated segment it encounters must be a high value segment. These two segments are assumed to be a matching pair. The low value and the high value can be equal.
When entering codes such as segment code, enter a code consisting of the characters A-Z, a-z, 0-9, with a non-numeric leading character.
The code is used in the flexfield's element in the XML schema for web services. You can maximize the readability of the schema by naming codes with a leading alphabetic character followed by alphanumeric characters. The use of spaces, underscores, multi-byte characters, and leading numeric characters, which are all encoded in XML schemas, make the codes in the schema element difficult to read.
This applies to context code in descriptive and extensible flexfields, and to structure instance code in key flexfields.
Value sets are specific to your enterprise. When gathering information using flexfields, your enterprise's value sets validate the values your users enter based on how you defined the value set.
You can assign a value set to any number of flexfield segments in the same or different flexfields. Value set usage information indicates which flexfields use the value set.
As a flexfield guideline, define value sets before configuring the flexfield, because you assign value sets to each segment as you configure a flexfield.
Caution
Be sure changes to a shared value set are compatible with all flexfield segments using the value set.
When you change a value in a shared value set, the change affects the value set for all flexfields that use that value set. The advantage of a shared values set is that a single change propagates to all usages. The drawback is that the change shared across usages may not be appropriate in every case.
When you deploy a flexfield, the value sets assigned to the segments of the flexfield provide end users with the valid values for the attributes represented by the segments.
To populate a flexfield segment with a default value when a row is created, specify a default type of constant or parameter and a default value.
To synchronize a segment's value with another field's value whenever it changes, specify the derivation value to be the flexfield parameter from which to derive the attribute's value. Whenever the parameter value changes, the attribute's value is changed to match. If you derive an attribute from a parameter, consider making the attribute read-only, as values entered by users are lost whenever the parameter value changes.
When defaulting or deriving a default value from a parameter, only those attributes designated by development as parameters are available to be chosen.
Different combinations of making the segments read only or editable in combination with the default or derivation value or both, have different effects.
Initial runtime behavior corresponds to the row for the attribute value being created in the entity table. If the default value is read only, it cannot subsequently be changed through the user interface. If the default value is not read only, users can modify it. However, if the segment value is a derived value, a user-modified segment value is overwritten when the derivation value changes.
Default Type |
Default value specified? |
Derivation value specified? |
Initial runtime behavior |
Runtime behavior after parameter changes |
---|---|---|---|---|
None |
No |
Yes |
No initial segment value |
Changed parameter derivation value updates segment value |
Constant |
Yes |
No |
Default segment value |
N/A |
Constant |
Yes |
Yes |
Default segment value |
Changed parameter derivation value updates segment value |
Parameter |
Yes |
No |
Default segment value is the parameter's default value |
N/A |
Parameter |
Yes |
Yes, and same as default value |
Default segment value is parameter's default and derivation value |
Changed parameter derivation value updates segment value |
Parameter |
Yes |
Yes, and different from default value |
Default segment value is parameter's default value |
Changed parameter default value does not update segment value. Only the changed derivation value updates the segment value. |
Usage affects various aspects of flexfields. The usage of the flexfield is set when the flexfield is registered and specifies the application and table with which the flexfield is associated.
Entity usage indicates the table containing the segments of a flexfield.
A flexfield can have multiple usages. The first table registered for a flexfield is the master usage. Segments are based on the master usage, and other usages of the same table for the same flexfield use the same segment setup, though the column names optionally may have a differentiating prefix.
You can configure different behavior for extensible flexfield contexts at the usage level. The usage of an extensible flexfield context determines in which scenarios or user interfaces the segments of a context appear to end users. For example, if a Supplier page displays an extensible flexfield's supplier usage and a buyer page displays that same extensible flexfield's buyer usage, a context that is associated to the supplier usage but not the buyer usage displays only on the supplier page and not the buyer page.
The usage of value sets specifies the segments where the value set is assigned.
To use a flexfield at runtime, the flexfield must have been deployed at least once. Deployment generates or refreshes the Application Development Framework (ADF) business component objects that render the flexfield in a user interface. Flexfields are deployed for the first time during the application provisioning process.
After you configure or change a flexfield, you must deploy it to make the latest definition available to end users. You can deploy a flexfield to a sandbox for testing or to the mainline for use.
Every flexfield has a deployment status.
A flexfield can have the following deployment statuses.
Deployment Status |
Meaning |
---|---|
Edited |
The flexfield metadata definition has not been deployed yet. Updates of the metadata definition are not applied in the runtime environment yet. |
Patched |
The flexfield metadata definition has been modified through a patch or through a data migration action, but the flexfield has not yet been deployed so the updated definition is not reflected in the runtime environment. |
Deployed to Sandbox |
The current metadata for the flexfield is deployed in ADF artifacts and available as a flexfield-enabled sandbox. The status of the sandbox is managed by the Manage Sandboxes task available to the Administrator menu of the Setup and Maintenance work area. |
Deployed |
The current metadata for the flexfield is deployed in ADF artifacts and available to end users. There have not been any changes to the flexfield since it was last deployed in the mainline. |
Error |
The deployment attempt in the mainline failed. |
Note
Whenever a value set definition changes, the deployment status of a flexfield that uses that value set changes to edited. If the change results from a patch, the deployment status of the flexfield changes to patched.
The Oracle Fusion Applications installation loads flexfield metadata into the database. This initial load sets the flexfield status to Edited to indicate that the flexfield has not been deployed yet. The application provisioning process during installation deploys the predefined flexfields of the provisioned applications, which sets their status to Deployed if no errors are encountered.
When accessing a provisioned application, deployed flexfields are ready to use. In some cases, flexfield availability at runtime requires setup, such as defining key flexfields.
Use the Validate Metadata command to view possible metadata errors before attempting to deploy the flexfield. Metadata validation is the initial phase of the Deploy and Deploy to Sandbox commands. By successfully validating metadata before running the deployment commands, you can avoid failures in the metadata validation phase of a deployment attempt. Errors in the metadata validation phase of deployment cause the deployment attempt to abort. Metadata validation results do not affect the deployment status of a flexfield.
Flexfield deployment status indicates how the flexfield metadata definition in the Oracle Fusion Applications database relates to the Application Development Framework (ADF) business components generated into a Metadata Services (MDS) repository.
If you have made a change to a flexfield and expect a changed deployment status, be sure you have saved your changes. No settings affect flexfield deployment status.
If the flexfield definition has been edited through the Define Flexfields activity task flows, the status is Edited. The latest flexfield metadata definition in the Oracle Fusion application diverges from the latest deployed flexfield definition. Any change, including if a value set used in a flexfield changes, changes the deployment status to Edited. If a flexfield has never been deployed, its status is Edited.
Note
When an application is provisioned, the provisioning framework attempts to deploy all flexfields in that application.
If you deploy the flexfield to a sandbox successfully, the status is Deployed to Sandbox. The latest flexfield metadata definition in the Oracle Fusion application matches the metadata definition that generated ADF business components in a sandbox MDS repository. Whether the sandbox is active or not does not affect the deployment status. If the flexfield was deployed to a sandbox and has not been edited or re-deployed to the mainline since then, the status remains Deployed to Sandbox independent of whether the sandbox is active, or who is viewing the status.
If you deploy the flexfield successfully, meaning to the mainline, the status is Deployed. The latest flexfield metadata definition in the Oracle Fusion application matches the metadata definition that generated ADF business components in a mainline MDS repository. Change notifications are sent when a flexfield is deployed successfully to the mainline.
If either type of deployment fails so the current flexfield definition is not deployed, the status is Error. The deployment error message gives details about the error. The latest flexfield metadata definition in the Oracle Fusion application likely diverges from the latest successfully deployed flexfield definition.
If the flexfield definition has been modified by a patch, the status is Patched. The latest flexfield metadata definition in the Oracle Fusion application diverges from the latest deployed flexfield definition. If the flexfield definition was Deployed before the patch and then a patch was applied, the status changes to Patched. If the flexfield definition was Edited before the patch and then a patch was applied, the status will remain at Edited to reflect that there are still changes (outside of the patch) that are not yet in effect.
When a deployment attempt fails and you can access the Deployment Error Message for details.
The flexfield definition in a sandbox corresponds to the flexfield metadata definition in the Oracle Fusion Applications database at the time the flexfield was deployed to the sandbox. When the flexfield is ready for end users, the flexfield must be deployed to the mainline.
A flexfield-enabled sandbox uses the following components.
Flexfield metadata in the Oracle Fusion Applications database
Flexfield business components in a sandbox Metadata Services (MDS) repository
User interface customizations for the flexfield in the mainline MDS repository
The figure shows the two types of deployment available in the Manage Flexfield tasks of the Define Flexfields activity. Deploying a flexfield to a sandbox creates a sandbox MDS repository for the sole purpose of testing flexfield behavior. The sandbox is only accessible to the administrator who activates and accesses it, not to users generally. Deploying a flexfield to the mainline applies the flexfield definition to the mainline MDS repository where it is available to end users. After deploying the flexfield to the mainline, customize the page where the flexfield segments appear. Customization of the page in the sandbox MDS repository cannot be published to the mainline MDS repository.
Deploying the flexfield to a sandbox generates the Application Development Framework (ADF) business components of a flexfield in a sandbox MDS repository for testing in isolation.
Warning
Do not make changes to flexfield segment display features in a flexfield-enabled sandbox as these changes will be lost when deploying the flexfield to the mainline.
The Oracle Fusion Applications database stores the single source of truth about a flexfield. From this the ADF business component objects that implement the flexfield in the runtime user interface are generated in the mainline MDS repository when the flexfield is deployed.
Deploying a flexfield to a sandbox creates a flexfield-enabled sandbox . Each flexfield-enabled sandbox contains only one flexfield.
You can test the runtime behavior of a flexfield in the flexfield-enabled sandbox. If changes are needed, return to the Define Flexfield tasks to change the flexfield definition.
When you deploy a flexfield to sandbox, the process reads the metadata about the segments from the database, generates flexfield Application Development Framework (ADF) business component artifacts based on that definition, and stores in the sandbox only the generated artifacts derived from the definition.
The sandbox data allows you to test the flexfield in isolation without first deploying it in the mainline where it could be accessed by users.
Warning
Do not make changes to flexfield segment display features in a flexfield-enabled sandbox as these changes will be lost when deploying the flexfield to the mainline.
When you deploy a flexfield as a sandbox, that flexfield-enabled sandbox automatically gets activated in your user session. When you sign back in to see the changes, the sandbox is active in your session.
You can only deploy a flexfield to a sandbox using the Define Flexfields task flow pages.
You also can use the Manage Sandboxes feature in the Administration menu of the Setup and Maintenance work area to activate, access, or delete a flexfield-enabled sandbox.
Note
Whether you use the Define Flexfields or Manage Sandboxes task flows to access a flexfield-enabled sandbox, you must sign out and sign back in before you can see the changes you deployed in the runtime.
You cannot publish the flexfield from the sandbox to the mainline. You must use the Define Flexfields task flow pages to deploy the flexfield for access by users of the mainline because the flexfield configuration in the mainline is the single source of truth.
You can use the Manage Key Flexfields, Manage Descriptive Flexfields, and Manage Extensible Flexfields tasks to deploy flexfields. You can also use WebLogic Server Tool (WLST) commands for priming the Metadata Services (MDS) repository with predefined flexfield artifacts and for deploying flexfields.
The table describes the available commands.
WebLogic Server Tool Command |
Description |
---|---|
|
Deploys all flexfields for the specified enterprise application. Only flexfields whose status is other than deployed are affected by this command unless the option is enabled to force all flexfields to be deployed regardless of deployment status. Initial application provisioning runs this command to prime the MDS repository with flexfield artifacts. |
|
Deploy a single flexfield regardless of deployment status |
|
Deploys flexfield changes that have been delivered using a flexfield Seed Data Framework (SDF)patch. Deploys flexfields that have a Patched deployment status. |
|
Displays MDS label of flexfield changes for viewing and deleting patching labels. |
Executing these commands outputs a report at the command line. The report provides the following information for every flexfield that is processed.
Application identity (APPID)
Flexfield code
Deployment result, such as success or error
In case of errors, the report lists the usages for
which the errors were encountered. If a runtime exception occurs,
the output displays the traceback information. For each WLST flexfield command, adding the reportFormat='xml'
argument returns the report as an XML string.
Consider the following aspects of command line deployment.
Preparing to use the WLST flexfield commands
Using the deployFlexForApp
command
Using the deployFlex
command
Using the deployPatchedFlex
command
Using the deleteFlexPatchingLabels
command
Exiting the WLST and checking the results
You can only execute the WLST flexfield commands on a WebLogic Administration Server for a domain that has a running instance of the Oracle Fusion Middleware Extensions for Applications (Applications Core) Setup application.
For more information on deploying the Applications Core Setup application, see the Oracle Fusion Applications Developer's Guide.
Ensure that the AppMasterDB data source is registered as a JDBC data source with the WebLogic Administration Server and points to the same database as the ApplicationDB data source.
Start the WebLogic Server Tool (WLST) tool, if it is not currently running.
UNIX:
sh $JDEV_HOME/oracle_common/common/bin/wlst.sh
Windows:
wlst.cmd
Connect to the server, replacing the user name and password arguments with your WebLogic Server user name and password.
connect('wls_username', 'wls_password', 'wls_uri')
The values must be wrapped in single-quotes. The wls_uri
value is typically T3://localhost:7101
.
For more information on the WLST scripting tool, see the Oracle Fusion Middleware Oracle WebLogic Scripting Tool.
The deployFlexForApp
command translates the product application's predefined flexfield
metadata into artifacts in the MDS repository.
Important
This command is run automatically when you provision
applications. However, after custom applications development, you
must run the deployFlexForApp
command
after you configure your application to read the flexfield artifacts
from the MDS repository and before you log into the application for
the first time, even if there is no predefined flexfield metadata.
This command does not deploy flexfields that have
a status of Deployed unless the force parameter is set to 'true'
(the default setting is 'false'
).
For more information on priming the MDS partition with configured flexfield artifacts, see the Oracle Fusion Applications Developer's Guide.
From the WLST tool, execute the following commands
to deploy the artifacts to the MDS partition, replacing product_application_shortname
with the application's
short name wrapped in single-quotes.
deployFlexForApp('product_application_shortname'[, 'enterprise_id'] [,'force'])
In a multi-tenant environment, replace enterprise_id
with the Enterprise ID to which
the flexfield is mapped. Otherwise, replace with 'None'
or do not provide a second argument.
To deploy all flexfields regardless of their deployment
status, set force to 'true'
(the default
setting is 'false'
). If you want to
deploy all flexfields in a single-tenant environment, you either can
set enterprise_id
to 'None'
, or you can use the following signature:
deployFlexForApp(applicationShortName='product_application_shortname',force='true')
Tip
The application's short name is the same as the application's module name.
For more information about working with application taxonomy, see the Oracle Fusion Applications Developer's Guide.
From the WLST tool, execute the following
command to deploy a flexfield, replacing flex_code
with the code that identifies the flexfield, and replacing flex_type
with the flexfield's type, which is
either DFF, KFF, or EFF.
deployFlex('flex_code', 'flex_type')
The values must be wrapped in single-quotes.
Use the deployPatchedFlex
command for situations where the patching framework does not invoke
the command, such as when an application has been patched offline.
If the installation is multi-tenant enabled, the command deploys all patched flexfields for all enterprises. This command is not intended to be invoked manually.
Check with your provisioning or patching team, or the task flows for managing flexfields, to verify that the flexfield has a Patched deployment status.
From the WLST tool, execute the following command to deploy the artifacts to the MDS partition of all flexfields that have a READY status.
deployPatchedFlex()
Execute the following command to deploy all flexfields that have either a READY status or an ERROR status.
deployPatchedFlex(mode='RETRY')
Whenever you deploy flexfield changes to MDS
using the deployPatchedFlex()
WLST command,
an MDS label is created in the format FlexPatchingWatermarkdate+time
. Use the deleteFlexPatchingLabels
command
to inquire about and delete these labels.
From the WLST tool, execute the deployPatchedFlex()
command with no arguments to delete
the flexfield patching labels.
To output a list of flexfield patching labels, execute
the command with the infoOnly
argument,
as follows:
deleteFlexPatchingLabels(infoOnly='true')
To exit the tool, execute the following command.
disconnect()
Optionally, sign into the application, access user interface pages that contain flexfields, and confirm the presence of flexfields for which configuration exists, such as value sets, segments, context, or structures.
A value set is a set of valid values that you assign to a flexfield segment.
An end user enters a value into a flexfield segment while using the application. The flexfield validates the segment against the set of valid values that you configured as a value set and assigned to the segment.
For example, you can define a required format, such as a five digit number, or a list of valid values, such as green, red, and blue.
Flexfield segments are usually validated, and typically 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 share value sets among different flexfields.
Caution
Be sure changes to a shared value set are compatible with all flexfields segments using the value set.
Defining value sets involves making decisions about the following.
Validation
Security
Precision and scale
Usage and deployment
The following types of validation are available for value sets.
Format only, where end users enter data rather than selecting values from a list
Independent, a list of values consisting of valid values you specify
Dependent, a list of values where a valid value derives from the independent value of another segment
Subset, where the list of values is a subset of the values in an existing independent value set
Table, where the values derive from a column in an application table and the list of values is limited by a WHERE clause
A segment that uses a format only value set does not present a list of valid values to users.
You can build a tree structure from the values in an independent value set whose data type is character.
Note
Adding table validated value sets to the list of available value sets available for configuration is considered a custom task.
For more information, see the Oracle Fusion Applications Extensibility Guide.
Value set security only works in conjunction with usage within flexfield segments. If a value set is used standalone, meaning outside a flexfield, value set security is not applied, but Oracle Fusion data security is enforced.
You can specify that data security be applied to the values in flexfield segments that use a value set. Based on the roles provisioned to users, data security policies determine which values of the flexfield segment end users can view or modify.
Value set security applies at the value set level. If a value set is secured, every usage of it in any flexfield is secured. It is not possible to disable security for individual usages of the same value set.
Value set security applies to independent, dependent, or table-validated value sets.
Value set security applies mainly when data is being created or updated, and to key flexfield combinations tables for query purposes. Value set security does not determine which descriptive flexfield data is shown upon querying.
Security conditions defined on value sets always use table aliases. When filters are used, table aliases are always used by default. When predicates are defined for data security conditions, make sure that the predicates also use table aliases.
For key flexfields, the attributes in the view object that correspond to the code combination ID (CCID), structure instance number (SIN), and data set number (DSN) cannot be transient. They must exist in the database table. For key flexfields, the SIN segment is the discriminator attribute, and the CCID segment is the common attribute.
For a value set with the data type Number, you can specify the precision (maximum number of digits user can enter) or scale (maximum number of digits following the decimal point).
The usage of a value set is the flexfields where that value set is used. The deployment status of flexfields in which the value set is used indicates the deployment status of the value set instance.
The figure shows a value set used by a segment in a key flexfield and the context segment of a descriptive flexfield.
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 that segment.
Global and context-sensitive segment require a value set. You can assign a value set to a descriptive flexfield context segment. If you specify only context values, not value sets for contexts, the set of valid values is equal to the set of context values.
Validation and usage of value sets determine where and how end users access valid values for attributes represented by flexfield segments.
Tip
As a flexfield guideline, define value sets before configuring the flexfield, because you assign value sets to each segment as you configure a flexfield.
When assigning a value set to a context segment, you can only use table-validated or independent value sets. The data type must be character and the maximum length of the values being stored must not be larger than column length of the context.
The format only validation type enables end users to enter any value, as long as it meets your specified formatting rules. That is, the value must not exceed the maximum length you define for your value set, and it must meet any format requirements for that value set.
For example, if the value set allows only numeric characters, your user could enter the value 456 (for a value set with maximum length of three or more), but could not enter the value ABC. A format only value set does not otherwise restrict the range of different values that users can enter. For numeric values, you can also specify if a numeric value should be zero filled or how may digits should follow the radix separator
You cannot specify a dependent value set for a given segment without having first defined an independent value set that you apply to another segment in the same flexfield. You use a dependent value set to limit the list of values for a given segment based on the value that the end user has chosen for a related independent segment. The available values in a dependent list and the meaning of a given value depend on which value was selected for the independently validated segment.
For example, you could define an independent value set of U.S. states with values such as CA, NY, and so on. Then you define a dependent value set of U.S. cities, with values such as San Francisco and Los Angeles that are valid for the independent value CA, and New York City and Albany that are valid for the independent value NY. In the UI, only the valid cities can be selected for a given state.
Because you define a subset value set from an existing independent value set, you must define the independent value set first. End users do not need to choose a value for another segment first to have access to the subset value set.
Typically, you use a table-validated set when the values you want to use are already maintained in an application table (for example, a table of vendor names). Table validation allows you to enable a segment to depend upon multiple prior segments in the same context or structure.
Table-validated value sets have unique values across the table, irrespective of bind variables. The WHERE clause fragment of the value set is considered if it does not have bind variables. If it has bind variables, the assumption is that the values are unique in the value set.
In the case of format, independent, or dependent value sets, you can specify a range to further limit which values are valid. You can specify a range of values that are valid within a value set. You can also specify a range validated pair of segments where one segment represents the low end of the range and another segment represents the high end of the range
For example, you might specify a range for a format-only value set with format type Number where the user can enter only values between 0 and 100. If you use a table value set, you cannot reference flexfield segments in the WHERE clause of the value set . For example, the WHERE clause cannot reference a segment or a value set.
In the case of independent and dependent values, you can specify that data security be applied to the values in segments that use a value set. Based on the roles provisioned to users, data security policies determine which values of the flexfield segment end users can view or modify.
When you enable security on a table-validated value sets, the security rule that is defined is absolute and not contingent upon the bind variables (if any) that may be used by the WHERE clause of the value set. For example, suppose a table-validated value set has a bind variable to further filter the value list to x, y and z from a list of x, y, z, xx, yy, zz. The data security rule or filter written against the value set should not assume anything about the bind variables; it must assume the whole list of values is available and write the rule, for example, to allow x, or to allow y and z. By default in data security all values are denied, and show only rows to which access has been provided.
There is no need to define or maintain values for a table-validated or subset value set, as the values are managed as part of the referenced table or independent value set, respectively.
If your application has more than one language installed, or there is any possibility that you might install one or more additional languages for your application in the future, select Translatable. This does not require you to provide translated values now, but you cannot change this option if you decide to provide them later.
For more information about defining value sets, see the Oracle Fusion Applications Extensibility Guide.
Descriptive flexfields provide a way to add custom attributes to entities, and define validation and display properties for them. These attributes are generally standalone. They don't necessarily have anything to do with each other and are not treated together as a combination.
All Oracle Fusion Applications business entities that you can access are enabled for descriptive flexfields. Descriptive flexfields are optional. You can choose to configure and expose segments for the descriptive flexfield defined and registered in your database, or not.
A descriptive flexfield provides a set amount of segments for an entity. The segments of a descriptive flexfield are made available to end users as individual fields in the application user interface.
A descriptive flexfield can have only one context segment to provide context sensitivity.
The same underlying column can be used by different segments in different contexts. For example, you can define a Dimensions context that uses the ATTRIBUTE1 column for height, the ATTRIBUTE2 column for width, and the ATTRIBUTE3 column for depth. You can also define a Measurements context that uses the same columns for other attributes: the ATTRIBUTE1 column for weight, the ATTRIBUTE2 column for volume, and the ATTRIBUTE3 column for density.
Descriptive flexfield segments are of the following types.
Segment Type |
Runtime Behavior |
---|---|
Global segment |
Always available |
Context segment |
Determines which context-sensitive segments are displayed |
Context-sensitive segment |
Displayed depending on the value of the context segment |
In the figure, a descriptive flexfield has one context segment called Category for which there are three values: Resistor, Battery, and Capacitor. In addition, the descriptive flexfield consists of two global segments that appear in each of the contexts, and three context-sensitive segments that only appear in the context in which they are configured.
Application development determines the number of segments available for configuring. During implementation you determine which attributes to add using the available segments, and the context values and the combination of attributes in each context. A segment can be used for different attributes, such as Height in Context1 and Color in Context2. Each segment of a descriptive flexfield that you make available to end users is exposed in the user interface as an individual field.
For each global and context-sensitive segment, you configure the values allowed for the segment and how the values that end users enter are validated, including interdependent validation among the segments.
Configuring descriptive flexfields involves managing the available flexfields registered with your Oracle Fusion Applications database and configuring their flexfield-level properties, defining and managing descriptive flexfield contexts, and configuring global and context-sensitive segments.
Every descriptive flexfield is registered to include a context segment, which you may choose to use or not.
You can assign sequence order numbers to global segments and to context-sensitive segments in each context. Segment display is always in a fixed order. You cannot enter a number for one segment that is already in use for a different segment.
Value sets are optional for context segments. The value set that you specify for a context segment consists of a set of context codes, each of which corresponds to a context that is appropriate for the descriptive flexfield. If you do not specify a value set for a context segment, the valid values for that context segment are derived from the context codes. The definition of each context segment specifies the set of context-sensitive segments that can be presented when that context code is selected by the end user.
For reasons of data integrity, you cannot delete an existing context. Instead, you can disable the associated context value in its own value set by setting its end date to a date in the past.
You can configure the individual global segments and context-sensitive segments in a descriptive flexfield. These segment types are differentiated by their usage, but they are configured on application pages that use most of the same properties.
Descriptive flexfield usages allow for the same definition to be applied to multiple entities. Descriptive flexfield tables define the placeholder entity where the flexfield segment values are stored once you have configured the descriptive flexfield.
Parameters are public arguments to a descriptive flexfield. Parameters provide outside values in descriptive flexfield validation. Parameters can be referenced by the logic that derives the default segment value and in table-validated VALUE set WHERE clauses.
A segment delimiter or separator visually separates segment values when the flexfield is displayed as a string of concatenated segments.
A descriptive flexfield that is registered in the database as enabled for Oracle Business Intelligence (BI) includes a BI Enabled setting for each of its segments. When a global, context, or context-sensitive segment is BI-enabled, it is available for use in Oracle Business Intelligence.
The following aspects are important in understanding BI-enabled flexfield segments.
Flattening business components to use BI-enabled segments in Oracle BI.
Equalizing context-sensitive segments to prevent duplication and complexity in the flattened components
Mapping attributes of flattened business components to logical objects in Oracle BI.
Managing the labels that map segments to logical objects in Oracle BI.
After you deploy a business intelligence-enabled flexfield, import the flexfield changes into the Oracle Business Intelligence repository to make use of the newly-generated attributes in business intelligence applications. For additional information about import, refer to the Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition (Oracle Fusion Applications Edition).
When you deploy a business intelligence-enabled descriptive flexfield, the deployment process generates an additional set of flattened business components for use in Oracle BI. The flattened business components include attributes for business intelligence-enabled segments only.
Flattened components include one attribute for the BI-enabled context-segment, and one attribute for each business intelligence-enabled global segment. For BI-enabled context-sensitive segments, if you assigned a label to the segment, the flattened components include an additionala single attribute representing segments with that label. If you did not assign a label, the flattened components include a discrete attribute for each BI-enabled context-sensitive segment in each context.
You can prevent duplication and the extra workload and complexity that result from the flattening process by assigning a label to any set of context-sensitive segments that serve the same purpose in different contexts. BI-enabled context-sensitive segments that have labels are equalized so that the flattened business components include one attribute for each label, consolidated across contexts. Non-labeled context-sensitive segments are not equalized across context values, so the flattened components include a separate attribute for each context-sensitive segment for each context value.
Note
It may not be possible to equalize similarly labeled segments if they have incompatible data types or value set types.
Assign a label to a global segment, context segment, or context-sensitive segment to map the corresponding attribute in the flattened components to a logical object in Oracle Business Intelligence. Using labels to map segments to BI logical objects minimizes the steps for importing the flexfield into Oracle Business Intelligence.
Note
Assigning a label to a context-sensitive segment serves to equalize the attribute across contexts, as well as map the equalized attribute to business intelligence.
You may assign a predefined label (if available) to segments or create new labels for assignment, as needed. Specify a code, name, and description to identify each label. In the BI Object Name field, enter the name of the logical object in Oracle Business Intelligence to which the segment label should map during import. Specifying the BI logical object minimizes the steps for importing the flexfield into Oracle Business Intelligence and helps to equalize context-sensitive segments across contexts.
If no labels are assigned to a BI-enabled segment, or the BI Object Name on the assigned label does not exist in business intelligence, you must manually map the segment to the desired logical object when importing into Oracle Business Intelligence.
In addition, context-sensitive segments without labels cannot be equalized across context values. The flattened components include a separate attribute for each non-labeled context-sensitive segment in each context.
Extensible flexfields are like descriptive flexfields, with some additional features.
You can add as many context-sensitive segments to the flexfield as you need. You are not dependent on the number of segments predefined and registered for the flexfield.
You can configure a one-to-many relationship between the entity and its extended attribute rows.
A row of data can have multiple contexts associated with it.
A row of data can have multiple occurrences of the same context.
You can configure contexts in groups so the attributes in the context always appear together in the user interface.
You can use existing hierarchical categories so that entities inherit the contexts that are configured for their parents. Contexts are reusable throughout categories.
You can specify view and edit privileges for the extensible flexfield segments to control who sees the attributes and who can change the attribute's values.
When you configure a context for multiple rows per entity, the segments are displayed as a table.
Unlike descriptive flexfields, the extension columns corresponding to extensible flexfields segments are part of extension tables, separate from the base application table. Unlike descriptive flexfield contexts, the set of attributes in an extensible flexfield context remains constant and does not differ by context value.
An extensible flexfield describes an application entity, with the runtime ability to expand the database that implementation consultants can use to define the data structure that appears in the application.
Extensible flexfields support one-to-many relationships between the entity and the extended attribute rows.
As with descriptive flexfields, you can define multiple usages for an extensible flexfield, which enables several application tables to share the same flexfield.
For example, a flexfield for shipping options can be used by both a Supplier table and a Buyer table. In addition, you can associate a context with one, some, or all of the flexfield's usages. Thus, with the shipping information example, you can associate a warehouse context with the Supplier usage, a delivery location context with the Buyer usage, and a ship-via context with all usages.
Extensible flexfields support multiple contexts, and the contexts can be grouped into categories. Every extensible flexfields has at least one category, or root category, and some extensible flexfields support a hierarchy of categories, where a given category can inherit contexts from its parent categories.
You can define categories for extensible flexfields, and you can associate any combination of contexts with a given category.
For example, the Electronics and Computers category hierarchy might include a Home Entertainment category, which in turn might include an Audio category and a TV category, and so on. The Home Entertainment product might have contexts that specify voltage, dimensions, inputs and outputs. Contexts are reusable within a given extensible flexfield. For example, the dimensions context could be assigned to any category that needs to include dimensional information.
Extensible flexfields allow you to combine contexts into groups known as pages, which serve to connect the contexts so they will always be presented together in the application user interface.
Each application page corresponds to one extensible flexfield category, with a separate region of the page for each associated context.
Configuring extensible flexfields involves managing the available flexfields registered with your application database and configuring their flexfield-level properties, defining contexts, categories, and pages, and configuring the segments for each extensible flexfield.
A context can be defined as single row or multi row. Single row contexts are the same as descriptive flexfields contexts. A single row context has only one set of context-sensitive segments. A multi-row context enables you to associate multiple sets of values with the same object instance.
For example, for a BOOK table, you could create a multi-row context named chapters that contains a chapter segment and a number of pages segment. Multiple chapters can then be associated with each book in the BOOK table.
Set the context to translatable so free-form text entered by end users is stored in the language of the user's locale, and different translations of that text can be stored in other languages. Segments in the translated contexts should utilize format-only value sets for storing free-form, user-entered text.
A category is a grouping of related data items that can be considered to belong together. You can associate any combination of contexts with a given category.
A category hierarchy logically organizes a set of categories.
For example, the Electronics and Computers category hierarchy might include a Computer category and a Home Entertainment category, which in turn might include an Audio category and a TV category, and so on.
A category can be a child or sibling of an existing category. The hierarchy can be as simple or as complex as desired, with any combination of zero or more sibling categories and zero or more child categories. If no category is defined, the data items are grouped under a single predefined default category.
Each category has associated contexts that store relevant information about a data item in that category. For example, a Home Entertainment product has contexts that specify Voltage, Dimensions, Inputs and Outputs. Contexts are reusable within a given extensible flexfield; the Dimensions context could be assigned to any category that needs to include dimensional information.
If a hierarchy includes child categories, each child category inherits the contexts from its parent category; for example, the Home Entertainment category inherits Voltage and Dimensions from the Electronics and Computers category.
Each extensible flexfield is associated with a particular category hierarchy. You can think of category hierarchies as the defining framework for extensible flexfields and their contexts. A category hierarchy specifies which contexts are valid for each category.
An extensible flexfield can include multiple contexts which you define to support a given category. These contexts can be suitable for a variety of different purposes, but within a particular category, some contexts might be considered to be related to, or dependent on, each other. You can combine these contexts into groups known as pages, which serve to connect the contexts so they will always be presented together in the application user interface.
For example, the Home Entertainment category might have an Electrical Specifications page that contains the Voltage, Inputs and Outputs contexts, and a Physical Specifications page that contains the Dimensions and Form Factor contexts.
You can designate an extensible flexfield segment as indexed so that it is one of the selectively required attributes an end user can use in an attribute search. If you indicate in the Manage Extensible Flexfield UI page that a segment should be indexed, the column representing the segment must be added to the database index. This is commonly done by a database administrator (DBA).
When an extensible flexfield with indexed segments is deployed, search task flows are generated along with the other flexfield artifacts and specify the indexed attributes as selectively required. In the deployed extensible flexfield's search task flow, an end user must specify at least one of the indexed attributes in the search criteria. This prevents non-selective searches which could cause performance issues.
For example, if you index the memory and processor attributes and ensure that the corresponding columns in the database are indexed, an end user can search an item catalog for computers by entering processor or memory or both as a search criterion. No search is performed if an end user enters an attribute as search criteria that is not indexed.
Key flexfields provide a means to capture a key such as a part number, a job code, or an account code. A key flexfield consists of one or more segments, where each segment can have a meaning.
For example, a part number 10-PEN-BLA-450 might correspond to a black pen from vendor #450 sold by division #10 (office supplies). Behind the scenes, the application uses a unique number, 13452, for this part, but the end user always see the 10-PEN-BLA-450 part number.
The following aspects are important to understanding key flexfields.
Architecture
Segments and segment labels
Structures
Segment and structure instances
Combinations
Dynamic combination creation
Security
Key flexfields are not optional. You must configure key flexfields to ensure that your applications operate correctly. You configure and maintain key flexfield definitions with the Manage Key Flexfields task.
When you configure a key flexfield, you define metadata about the key flexfield such as how many segments are in a structure, how many structures the flexfield uses, what value sets each segment uses, and so on. This is flexfield metadata stored in flexfield metadata tables.
Based on the flexfield metadata, actual part numbers are captured at runtime as a combination of segment values and stored in a combinations table. A combinations table contains all the segment columns for a flexfield, plus a unique ID column and a structure instance number column that differentiates multiple arrangements of the segment columns.
For example, a part number that can be comprised of multiple segments can be represented by a key flexfield. A part number key flexfield has a corresponding combinations table, where the flexfield stores a list of the complete codes, with one column for each segment of the code, together with the corresponding unique ID and structure instance number for the code. When users define a new part number or maintain existing part numbers in the parts catalog, they directly maintain rows in the combination table.
The foreign key table contains a different business entity than the combinations table. For example, the business entity in the foreign key table is order lines or invoice lines that contain foreign key references to parts for ordering and so on. Any number of foreign key tables can reference a particular entity represented by a key flexfield.
A key flexfield consists of segments. Segments consist of a prompt, a short prompt, display width, a number that determines where in the sequence of a key flexfield structure the segment exists, the range type and the column name of the attribute being captured by the segment, a default value set and a label for the segment. A segment label identifies a particular segment of a key flexfield. Segment labels are defined and made available by applications development.
Applications identify a particular segment for some purpose such as security or computations. Segment name or segment order cannot reliably identify a segment because key flexfield segments can be configured to appear in any order with any prompts. A segment label functions as a tag for a segment.
For example, Oracle Fusion General Ledger needs to identify which segment in the Accounting Flexfield contains balancing information and which segment contains natural account information. General Ledger uses a segment label to determine which segment you are using for natural account information. When you define your Accounting Flexfield, you must specify which segment label apply to which segments.
Some labels must be unique, and cannot be applied to more than one segment in each structure. Other labels are required, and must be applied to at least one segment in each structure.
A segment label orients an end user's search of segments, such as the Cost Center label for all segments across key flexfields that capture a value for cost center.
A key flexfield structure definition includes the number of segments and their order.
In some applications, different users need to see different segment structures for the same flexfield. A key flexfield can have multiple structures if registered to support more than one structure.
The flexfield can display different fields for different end users based on a data condition in your application data, such as the value of another field entered by the end user or the user's role. For example, the correctly formatted local postal address for customer service inquiries differs based on locale. A postal address key flexfield could display different segments and prompts for different end users based on a location condition in your application data, such as the user's role or a value entered by the user.
Each structure can have one or more segments. Thus a segment is a child of a structure. If you want to store a particular segment, such as Cost Center, in two different structures, you must define the segment separately in each structures.
Each structure may have one or more structure instances. Each instance of a structure shares the same number and order of segments, but differs in the allowable values or value sets that validate the segments.
You can define multiple configurations of a key flexfield structure. These structure instances have the same segment structure, in the same sequence order. They differ primarily in how each segment is validated. You define a structure instance for each key flexfield and each key flexfield structure instance.
The segments in a key flexfield structure instance are segment instances. A segment instance is a segment with a specific value set assigned to it.
If a key flexfield has been registered with a tree structure, you can specify a tree code for a segment instance, where the tree code defines a hierarchical relationship between the segment values.
A combination is a complete code, or combination of segment values that makes up the code, that uniquely identifies an object.
For example, each part number is a single combination, such as PAD-YEL-11x14 or 01-COM-876-7BG-LTN. In these combinations, the hyphen is the segment separator. If you had ten parts you would define ten combinations. A valid combination is simply an existing or new combination that can currently be used because it is not out of date or disabled, and does not violate cross-validation or security rules. A combination has different segments depending on the flexfield structure being used for that combination. Any combination is associated with only one particular flexfield structure.
Many Oracle Fusion Applications products refer to a key flexfield combination by using the name of the entity or the key flexfield itself. For example, Oracle Fusion Assets uses the asset key flexfield and refers to one of its combinations as an asset key or asset key flexfield. In another example, other Oracle Fusion Applications products including Oracle Fusion General Ledger (GL) refer to combinations of the accounting flexfield as account or GL account.
Each key flexfield has one corresponding table, known as the combinations table, where the flexfield stores a list of the complete codes, with one column for each segment of the code, together with the corresponding unique ID number (a code combination ID number or CCID) for that code. Then, other tables in the application have a column that stores just the unique ID for the code. For example, you may have a part number code, such as PAD-YEL-11x14. The Parts combinations table stores that code along with its ID, 57494. If your application allows you to take orders for parts, you might then have an Orders table that stores orders for parts. That Orders table would contain a single column that contains the part ID, 57494, instead of several columns for the complete code PAD-YEL-11x14.
Typically one combinations page maintains the key flexfield, where the key flexfield is the representation of an entity in your application. The combinations page is where you maintain individual combinations, such as part numbers.
Dynamic combination creation is the insertion of a new valid combination into a combinations table from a page other than the combinations page.
Dynamic combination creation may be enabled at the following levels.
Level Of Dynamic Combination Creation |
Controlled By: |
---|---|
Flexfield |
Application development |
Each usage or reference to the key flexfield |
Application development |
Structure instance |
Administrators and implementation consultants |
Other |
Administrators and implementation consultants |
If your key flexfield or certain usages or references of the key flexfield do not permit dynamic combination creation, you may control whether dynamic combination creation is enabled for each structure instance. If enabled, a user can enter a new combination of segment values using the flexfield window from a foreign key page. For example, when entering a transaction, a GL user can enter a new expense account code combination for an account that does not yet exist. Your application creates the new account by inserting the new combination into the combinations table behind the scenes. Assuming that the new combination satisfies any existing cross-validation rules, the flexfield inserts the new combination into the combinations table, even though the combinations table is not the underlying table for the foreign key page.
Consider the plans for a key flexfield, security, and resulting runtime pages when configuring key flexfields.
Plan structures carefully and allow for future needs.
Caution
Do not change the number, order, and maximum length of segments once you have acquired flexfield data.
A delimiter separates the segments when they appear to end users. The delimiter value of a structure specifies the character used to visually separate segment values when the key flexfield is displayed as a string of concatenated segments in the UI.
Tip
Choose the delimiter value of your key flexfield carefully so that it does not conflict with the flexfield data. For example, if your data frequently contains periods, such as in monetary or numeric values, do not use a period as your segment separator. Any character you expect to appear frequently in your segment values or descriptions is not a good choice for the delimiter.
If you change the configuration of a key flexfield, such as the delimiter, the change affects the previously stored key flexfields with that structure.
Oracle Fusion data security enforces value set security.
Within key flexfields, value set security applies to the selection of the individual segment values in the segment list of values. When selecting a key flexfield segment value from the combination table, data security allows display of only the combinations whose segment values you have access to. Applications development controls whether or not value set security rules propagate to the foreign key table. By default they do.
Application development determines the user interface (UI) pages used to render flexfields. The types of key flexfield UI pages are as follows.
Combinations pages where underlying entity objects use the combinations table itself
Foreign key pages where the underlying entity objects contain a foreign key reference to the combinations table
Partial usage page where some or all of the key flexfield's segment columns are in a product table
The same key flexfield can be used in different ways on different pages.
A page with a foreign key reference has a base table or view that contains a foreign key reference to a combinations table with the actual flexfield segment columns. This allows manipulating rows containing code combination IDs (CCID).
A page with partial usage of a key flexfield presents segments that are defined on a product's transactional table in addition to being defined on a combinations table. In the case of a partial usage page, it is possible that only part of the configuration is visible. This allows the key flexfield to behave more like a descriptive flexfield.
A code combination maintenance page or combinations page presents the combinations table. This allows directly creating and maintaining code combinations. The combinations table contains all key flexfield segment columns and a unique ID column.
A typical application has one and only one combinations page. An application might not have a combinations page if it does not support maintenance by administrators.
A page containing a search region enables end users to select which attributes of the key flexfield view object to use as criteria to search for flexfield metadata.
For example, you can configure seven segments for the Account key flexfield. In a foreign key reference page, end users see the typical key flexfield picker with all seven segments where they can search for combinations. In a partial usage page using the same key flexfield, end users potentially could see only a single segment such as the Cost Center labeled segment, or they might see multiple segments but displayed as individual segments rather than as a picker for choosing combinations
For more information on key flexfield pages, see the Oracle Fusion Applications Developer's Guide.
A key flexfield structure arranges the segments of a key so you can reuse a single key flexfield in multiple combinations of the same or a subset of segments. Multiple instances of a single structure can accommodate differences in the value sets assigned to the structure's segments.
The structure determines the following aspects of a key flexfield.
The segments to include
The order of the segments
Segment labels on the included segments
Properties for each segment applied to the instances of the segments in an instance of the structure
All the segments defined for a key flexfield are available to be included in a key flexfield structure.
You can define as many segments as there are defined segment columns in your key flexfield combinations table.
Restriction
Be sure to add segments in the order that your key requires. Once deployed, the order cannot be changed.
Enable segments to indicate that they are in use. A flexfield does not display disabled segments in runtime.
Tip
To protect the integrity of your data, disable a segment if you have already used it to enter data.
A key flexfield structure can have one or more alternate structure instances.
The instances of a key flexfield structure share the following aspects of the structure.
The same set of segments
The same arrangement of segments
The same properties at the segment and structure levels
Differences among structure instances at the structure level include whether dynamic combination creation is allowed.
Differences among segment instances at the structure instance level include the following.
Value set
Default type and default value
Tree code
Whether the segment is any of the following
Required
Displayed
Enabled for business intelligence
Optional or required as a query criterion
For example, you could use one group of value sets for the US and another for France.
The figure shows two structures instances for a part number structure. The structures differ in the number of segments and the segment separators used. The structure instances of a structure share all properties that are defined for the structure, but can vary in the properties defined at the structure instance or segment instance level, such as the value set assigned to the segment instances.
You can designate a key flexfield segment instance as query required so that it is one of the selectively required attributes an end user can use in a key flexfield combination search. If you indicate in the Manage Key Flexfields UI page that a segment instance should be indexed, the column representing the segment must be added to the database index. This is commonly done by a database administrator (DBA).
Following deployment, the combination picker of the key flexfield displays the query required attributes as selectively required. An end user must specify at least one of the query required attributes in the search criteria. This prevents non-selective searches that could cause performance issues.
For example, if you mark the cost center and account attributes as query required and ensure that the corresponding columns in the database are indexed, an end user can search for combinations by entering cost center or account or both as a search criterion. No search is performed if an end user does not enter at least one query required attribute as search criteria.
Tip
Index the Structure Instance Number column on your combinations table to improve performance.
If a key flexfield supports dynamic combination creation, you can choose to enable this feature by selecting Dynamic Combination Creation Allowed. This will allow end users to enter values at runtime that produce new code combinations for the flexfield. If not enabled, new valid combinations can only be entered using the combinations table for the flexfield.
If a tree code has been defined for the value set assigned to the segment instance, and you assign the tree code to the segment instance, tree hierarchy search operations are available on the segment values.
For a segment instance to be based on a tree, the following must be true.
Application development registered the key flexfield with a tree structure.
A tree code for that tree structure exists.
The tree code that includes tree versions containing the values of the value set assigned to the segment instance.
You assign the desired tree code directly to the segment instance.
Provided these conditions are satisfied, different segment instances that use the same value set can be assigned the same or different tree codes, meaning they use a different hierarchy definition over the same values.
A key flexfield that is registered in the database as enabled for Oracle Business Intelligence (BI) includes a BI Enabled setting for each of its segment instances. When a segment instance is BI-enabled, it is available for use in Oracle Business Intelligence.
The following aspects are important in understanding BI-enabled key flexfield segments.
Flattening business components to use BI-enabled segments in Oracle BI.
Equalizing segments to prevent duplication and complexity in the flattened component.
Mapping attributes of flattened business components to logical objects in Oracle BI.
Managing the labels that map segments to logical objects in Oracle BI.
After you deploy a business intelligence-enabled flexfield, import the flexfield changes into the Oracle Business Intelligence repository to make use of the newly generated attributes in business intelligence applications. For additional information about import, refer to the Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition (Oracle Fusion Applications Edition).
When you deploy a business intelligence-enabled key flexfield, the deployment process generates an additional set of flattened business components for use in business intelligence. The flattened business components include attributes for business intelligence-enabled segment instances only.
If you assigned a label to a segment, the flattened components include a single attribute representing all segment instances with that label. If you did not assign a label, the flattened components include a discrete attribute for each BI-enabled segment instance in each structure.
You can prevent duplication and the extra workload and complexity that result from the flattening process by assigning a label to any set of segments that serve the same purpose in different structures. BI-enabled segments that have labels are equalized so that the flattened business components include one attribute for each label, consolidated across structures. Non-labeled segments are not equalized across structures, so the flattened components include a separate attribute for each segment for each structure.
Note
It may not be possible to equalize similarly labeled segments if they have incompatible data types or value set types.
Assign a label to a segment to map the corresponding attribute in the flattened components to a logical object in Oracle Business Intelligence. Using labels to map segments to BI logical objects minimizes the steps for importing the flexfield into Oracle Business Intelligence.
Note
Assigning a label to a segment serves to equalize the attribute across structures, as well as map the equalized attribute to business intelligence.
You may assign a predefined label (if available) to segments or create new labels for assignment, as needed. Specify a code, name, and description to identify each label. In the BI Object Name field, enter the name of the logical object in Oracle Business Intelligence to which the segment label should map during import. Specifying the BI logical object minimizes the steps for importing the flexfield into Oracle Business Intelligence and helps to equalize context-sensitive segments across structures.
If no labels are assigned to a BI-enabled segment, or the BI Object Name on the assigned label does not exist in business intelligence, you must manually map the segment to the desired logical object when importing into Oracle Business Intelligence.
In addition, segments without labels cannot be equalized across structures. The flattened components include a separate attribute for each non-labeled segment in each structure.
Note
Segment labels serve other functions as well, as presented in Key Flexfields: Explained.
A key flexfield can capture expense account information.
When entering details for each expense, the user specifies an account to which the expense is charged.
A user interface for entering expenses gives the user the option of selecting an expense account that identifies the cost center and other details needed for processing the expense.
The expense account field is a foreign key reference to a code combination (EXPENSE_LINES.EXPENSE_ACCOUNT = ACCOUNTS.CCID).
The code combination table supports entering account information, such as for expense accounts.
The figure shows the origin in the code combination table of the account specified by the user. The code combination ID record stores the information of the key flexfield segments used to assemble the expense account based on the key flexfield configuration.
The combinations page, which is the maintenance page for the key flexfield, is for managing rows in the combination table. In this example, managing the combinations means adding or editing account numbers that adhere to the key flexfield metadata rules.
The figure shows the code combination details for the example expense account reflected in the flexfield configuration and the code combination table.
If dynamic combination creation is not enabled, then when entering an expense line, the user can only select an account that already exists in the ACCOUNTS (combinations) table. If they require an account that does not exist, they must consult with the appropriate application administrator who can add the account to the combinations table.
If dynamic combination creation is enabled, then when entering an expense line, the user can either select a pre-existing account, or type in a new account that created dynamically on the fly in the ACCOUNTS (combinations) table. Once the new combination is created, the same user can refer to it on the expense line.
When managing employee information, the user specifies the cost center that the employee belongs to. The cost center field corresponds to a single, labeled segment of the Account Key Flexfield and has metadata defined such as the allowable value set for that segment.
In this figure, instead of specifying a cost center ID reference to an account, only the Cost Center segment is used and the value is stored directly on the employee table.
The ADF business components or artifacts of a flexfield, which are generated into an metadata services (MDS) repository when the flexfield is deployed, are cached within a user session. You must sign out and back in again to view flexfield definition changes reflected in the runtime application user interface page.
A flexfield's status relative to its deployment determines whether the flexfield segments as currently defined in the metadata are available to end users. The flexfield segments seen by end users in the runtime correspond to the flexfield definition that was last deployed successfully.
Value set security is a feature that enables you to secure access to value set values based on the end user's role in the system.
As an example, suppose you have a value set of US state names. When this value set is used to validate a flexfield segment, and users can select a value for the segment, you can use value set security to restrict them to selecting only a certain state or subset of states based on their assigned roles in the system.
For example, Western-region employees may choose only California, Nevada, Oregon, and so on as valid values. They cannot select non-Western-region states. Eastern-region employees may choose only New York, New Jersey, Virginia, and so on as valid values, but cannot select non-Eastern-region states. Value set security is implemented using Oracle Fusion Applications data security.
When you define or edit a flexfield segment, you specify a default value from the values provided by the value set assigned to that segment.
You can set the default value to be a parameter, which means the entity object attribute to which the parameter you choose is mapped will provide the initial default value for the segment.
You can set to be a constant, if appropriate to the data type of the value set assigned to the segment.
In addition to an initial default value, you can set a derivation value for updating the attribute's value every time the parameter value changes. The parameter you choose identifies the entity object source attribute. Any changes in the value of the source attribute during runtime are reflected in the value of the segment.
If the display type of the segment is a check box, you can set whether the default value of the segment is checked or unchecked.
Attachments are pieces of supplementary information that users can associate with specific business objects such as expense reports or purchase orders. Attachments can be URLs, desktop files, text, or in cases where available, repository folders. For any given business object, a user may be able to only view attachments, or also create, delete, or edit attachments, depending on security. For more information on an introduction to attachments, see the Oracle Fusion Applications Developer's Guide.
Attachments are stored in a content server, the Oracle Enterprise Content Management document repository. Users have no real interaction with the repository unless the repository mode is enabled for attachments on specific business objects. In which case, users can share attachments among objects, update attachments by checking them out of and back in to the repository, and perform other tasks. Access to attachment files is controlled by a digital signing mechanism. Depending on security, users might have direct access to the repository.
Data security that applies to a specific business object also applies to attachments for that object, as determined by the attachment entity defined for the object. For example, if a user has no access to a specific expense report, then the same user cannot access attachments for the expense report. You can also use attachment categories to control access and actions on attachments, based on roles associated with the category. For more information on securing attachments, see the Oracle Fusion Applications Developer's Guide.
An attachment entity is usually a database entity, for example a table or view, that represents a business object attachments can be associated with. Each attachment UI must be defined with a corresponding attachment entity, which not only identifies the business object to attach to, but also controls what users can do. Attachment entities are used only in the context of attachments and exist separately from the database entities that they are based on.
Edit and create attachment entities on the Manage Attachment Entities page, which you can access by starting in the Setup and Maintenance Overview page and searching for the Manage Attachment Entities task. Though you would generally use predefined attachment entities with attachment UIs, you might need to create new entities, for example when developing custom UIs.
An attachment entity name should match the name of the table or view that represents the business object to attach to. The name is also used in the repository folder that is automatically created to store attachments for the entity. The attachment entity display name should be something that users know to represent the business object.
The data security policies associated with the database resource defined for the attachment entity would apply to attachments for that entity. For example, based on the database resource for the expense reports attachment entity, the same policies apply to attachments for expense reports. The database resource value must match the value in the OBJ_NAME column in the FND_OBJECTS table for the business object that the entity represents.
Security based on the database resource associated with the attachment entity is always in effect. What you can enable or disable is security based on attachment categories. If any of the attachment categories associated with the attachment entity has data security defined, then that security applies to this entity only if enabled.
The association between attachment entities and categories determines which categories can be used for an entity. For example, categories associated with the expense report attachment entity are available to be implemented in attachment UIs for expense reports. You can define these associations when managing either entities or categories. Any association changes in either the Manage Attachment Entities or Manage Attachment Categories page are reflected on the other page. You can access either page by starting in the Setup and Maintenance Overview page and searching for attachment tasks.
You determine which attachment categories are relevant to a particular entity on the Manage Attachment Entities page, and each entity must have at least one category. Depending on configuration, any or all of the available categories for that entity are used. For example, you assign three categories to the expense reports attachment entity. For a particular expense report page with attachments functionality, you can customize the attachments component to specify which of the three categories are used. Based on your selection, the data security defined for each category, if any, is applied to attachments on that page if the attachment entity has category-based security enabled.
If you create an attachment category and need to assign it to multiple attachment entities, use the Manage Attachment Categories page. The association means the same as the association on the Manage Attachment Entities page.
Attachments UIs for users to add and manage attachments are fully functional as is, and users usually would not encounter issues. If you customize attachments in any way, for example by creating additional attachment categories and implementing data security on them, then some issues might arise.
Users encounter issues when trying to view attachments or perform actions such as adding attachments.
Users can no longer see specific attachments that they were previously able to see.
Likewise, they can no longer update or delete attachments.
Users get an error stating that they do not have permission to add attachments.
Use the Manage Attachment Entities page to ensure that attachment categories are associated to the relevant attachment entity. For example, if users can no longer see attachments for an expense report, then search for the expense report attachment entity and assign all necessary categories to it. You might need to check with your system administrator or help desk to determine the exact entity used on the page with the expenses attachments or what categories to assign.
If data security is implemented on the categories for the attachment entity, then verify that the Enable Security check box is selected in the Manage Attachment Entities page for that entity. Make sure that users have a role with the privileges shown in the following table, to view, add, update, or delete attachments with a specific attachment category.
Action |
Privilege |
---|---|
View |
Read Application Attachment (FND_READ_APPLICATION_ATTACHMENT_DATA) |
Add or Update |
Update Application Attachment (FND_UPDATE_APPLICATION_ATTACHMENT_DATA) |
Delete |
Delete Application Attachment (FND_DELETE_APPLICATION_ATTACHMENT_DATA) |
For example, if users have the Read Application Attachment privilege for all categories associated with the expense report attachment entity, except the Receipts attachment category, then they can view all expense report attachments except those created with the Receipts category. Likewise, if users do not have the Update Application Attachment privilege for any attachment categories tied to the expense report attachment entity, then they cannot create any attachments at all for expense reports.
For more information on attachment category data security, see the Oracle Fusion Applications Developer's Guide.
Finally, certain attachments UI for users have predefined restrictions on categories in place. Your developers can also introduce additional filters to determine which document categories are available for a specific page. Check with your developers or help desk.
Users can see existing attachments, but the attachments no longer have an attachment category value.
When the attachment was added, at least one category existed for the corresponding attachment entity, as otherwise the attachment could not have been added. Since then, the entity was edited so that it no longer has any assigned categories, so the user cannot see the category associated with that attachment.
Use the Manage Attachment Entities page to reassign attachment categories to the relevant attachment entity. For example, if users can no longer see the Receipts attachment category for an attachment to an expense report, then search for the expense report attachment entity and assign to it the Receipts category. You might need to check with your system administrator or help desk to determine the exact entity used on the page with the expenses attachments or what additional categories to assign.
Finally, certain attachments UI for users have predefined restrictions on categories in place. Your developers can also introduce additional filters to determine which document categories are available for a specific page. Check with your developers or help desk.
An attachment category is used to classify and secure attachments. Each attachment user interface must be defined with at least one category for users to be able to add attachments. If there are multiple categories, users can view them and select one when adding attachments. For example, attachments for an expense report can be categorized as receipts, scanned invoice images, and so on.
You can also associate roles with categories to determine user access and actions for attachments, based on the categories assigned to the attachment entity. For example, security for expense report attachments can be based in part on the categories assigned to the expense report attachment entity. You can define multiple categories per module, and add and manage custom categories for your own purposes. For more information on attachment category data security, see the Oracle Fusion Applications Developer's Guide.
Use the Manage Attachment Categories page, which you can access by starting in the Setup and Maintenance Overview page and searching for the Manage Attachment Categories task.
Activity Stream is a region on the Oracle Fusion Applications Welcome dashboard and other pages in various applications. Users track the activities and transactions of other users in this region. You can set options that affect the all Activity Stream regions for all users across your site. Individual users can still override your settings through Activity Stream preferences.
Activity stream settings are described in the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces. When you read content from that guide, note that:
Your setup applies to all users, not just yourself or any individual user.
You can disregard discussions about how to access the settings, because you access the Set Activity Stream Options page by starting in the Setup and Maintenance Overview page and searching for the Set Activity Stream Options task.
You can customize the Navigator menu, which is the main menu of Oracle Fusion Applications and is always available in the global area. Use the Manage Menu Customizations page, which you can access by starting in the Setup and Maintenance Overview page and searching for the Manage Menu Customization task.
An overview of customizing the Navigator menu is provided in the Oracle Fusion Applications Extensibility Guide. Details of the values you enter to define menu items are provided in the Oracle Fusion Applications Developer's Guide.
When you customize items in the Navigator menu, you determine if the item takes users to a specific page in Oracle Fusion Applications or to another application or Web site. The details of what you enter to define the menu item depend on the type of destination. If you duplicate a menu item, the new item appears below the selected source item.
Common messages, which have message names that begin with FND_CMN and message numbers between 0 and 999, are used throughout Oracle Fusion Applications. Each common message can appear in multiple places in any product family. For example, the FND_CMN_NEW_SRCH message can be used for any search to indicate that no results were found. Common messages that are of type error or warning are part of the message dictionary.
Because a common message can be used in any application, consider the ramifications if you edit any aspect of the message, including incident and logging settings. Changes would be reflected in all instances where the message is used. For example, if you change the message text, make sure that the text would make sense to all users across Oracle Fusion Applications who might see it.
You can create custom common messages for use in multiple places within a single product. Do not begin the message name with FND_CMN, but use another suitable convention. The message number should be within the range that is designated for the product.
Each message in the message dictionary has many attributes and components, including message properties, text, and tokens, that you define when creating or editing the message.
Details about these messages are described in the Oracle Fusion Applications Developer's Guide.
Some Oracle Fusion Middleware Extensions for Applications profile options are related to general preferences in the global area.
The related general preferences are Default Application Language, Territory, Date Format, Time Format, Currency, and Time Zone. When the user changes any of these preferences, the stored values in LDAP are updated accordingly.
The corresponding profile options are Default Language, Default Territory, Default Date Format, Default Time Format, Default Currency, and Default User Time Zone. No matter what you set for these profile options at any level, the preferences settings, or LDAP values, take precedence. The profile option value is used only if the LDAP value is not available. Updating the profile option value does not automatically update the value in LDAP or preferences.
In Oracle Fusion Applications, each business document or business event is uniquely identified by a document sequence number that you assign to it. However, the document sequencing feature must be turned on (enabled) on the business document or event to allow the assignment. For example, if document sequencing is enabled, you can assign a document sequence number to an invoice that gets generated in response to a purchase order. You can use document sequences as a proof to track successfully executed transactions as well as failed transactions. Additionally, a document sequence helps in generating an audit trail, which can be used to identify how a particular transaction passed through various applications.
Document sequencing can be managed automatically, manually, and gaplessly.
Note
Plan your document sequencing carefully before you use the options available in the application to apply sequence numbers. Avoid changes to the options after you saved your work on the Manage Document Sequences and Manage Document Sequence Categories pages.
Automatic document sequencing assigns a unique number to each document as it is generated, and this unique number is stored in the database. The numbering is sequential by date and time of creation. If you define a sequence to automatically number documents, you can provide an initial value to begin the sequence. In absence of a custom value, the default value 1 is used.
Manual sequencing requires you to assign a unique number to each document before it is generated. In manual sequencing, the numerical ordering and completeness of a transaction is not enforced. Users can skip or omit numbers when entering the sequence value. However, each time that a number is assigned, the application validates its uniqueness.
Gapless sequencing is similar to automatic sequencing. It automatically generates a unique number for each document, but does that only for successfully generated documents. As a result, the sequence is maintained for all the documents that are generated, and no sequence numbers are lost due to incomplete or failed document generation.
Important
Use this type of sequencing only if necessary because it may affect the performance of the system and slow down transaction processing.
The Sequential Numbering Enforced profile validates the documents being created and applies the relevant document sequence, based on the selected option. The following options are available:
Always Used: Sequential numbering is enforced for all document categories. When this option is set, users cannot create a document if its document category is not assigned any active document sequence. The system displays an error.
Partially Used: Sequential numbering is enforced for all document categories. However, if no sequence is available for the document, the system displays a warning. Users can either proceed without a document sequence or create and assign a document sequence before proceeding.
Not Used: Sequential numbering is not enforced. In this mode, although the documents created do not require a document sequence to be assigned, the system checks for the uniqueness of the document number provided. The system does not display any warning or error.
Restriction
At the site level, the profile is by default set to Partially Used. Avoid changing this option as doing so may interfere with the validation logic and the data that was stored using the earlier option may not appear. However, you can change the option at the product or user level.