This chapter contains the following:
The Maintain Common Reference Objects task list contains tasks that support implementation of common functionality, such as data security, reference data sets, or general preferences.
Use this task list to manage common reference objects that are defined centrally and shared across applications. You can search for and access this task list in the Setup and Maintenance work area.
To make the Maintain Common Reference Objects task list available in your implementation project, go to Setup and Maintenance > Configure Offerings, and for a specific offering, select the Maintain Common Reference Objects feature choice.
The configuration of your setup data may be protected. Application developers mark some configurations as protected, indicating that you can't edit them.
Some examples of configurations that may be protected are:
Extensible flexfield contexts
Extensible flexfield pages
Oracle application components and functions are organized in a hierarchy, ranging from product lines to logical business areas. The hierarchy represents a breakdown of products into units based on how applications are installed and supported.
In the Application Extensions functional area within your offering, search for the Manage Taxonomy Hierarchy task and view the hierarchy on the Manage Taxonomy Hierarchy page.
A detailed introduction to application taxonomy is provided in the Oracle Fusion Applications Developer's Guide.
The highest level of the hierarchy is product line, followed by the 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 module is a node at any of these levels. Each level is briefly described here.
Product Line: A collection of product under a single brand name, for example, Oracle Fusion.
Product Family: A collection of products associated with a functional area that may or may not be licensed together as a single unit, for example Oracle Fusion Financials.
Application: A single product within a product family, containing closely related features for a specific business solution, for example General Ledger.
Logical Business Area: 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 up to two or three levels deep.
In the application taxonomy hierarchy, when you create a module, it becomes a child of the currently selected node. Once created, you cannot delete the module or move it elsewhere in the hierarchy.
From the Manage Taxonomy Hierarchy page, navigate to the Create Child Module or Edit Module page to manage the modules. 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, a unique read-only ID is automatically generated. The module contains two other identifiers: Module key and alternative 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 additional identifiers are provided for the product line, product family, and application modules. However, you can optionally add them for logical business areas and new custom 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 Oracle Application.
Module name is the logical name for the module. The name must be unique among nodes within the hierarchy level with the same parent, but Oracle recommends keeping it unique in the entire hierarchy. The user name and description can appear to users in other parts of Oracle Applications Cloud.
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 doesn't mean the module is actually installed if the installation itself didn't take place. Installation refers to operations related to laying down all the components required to create an Oracle Applications Cloud environment. 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 data residing in 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 the 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 Applications Cloud 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 common data is shared or partitioned across business entities to avoid duplication and reduce maintenance effort. 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.
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 can't 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 different business units setting up and using the same grades, XYZ Corporation decides to create a set called Grades, which contains the grades. All business units in the organization have the Grades set so that the grades can be shared and used.
Reference data sets are logical groups of reference data that various transactional entities can use depending on the business context. You can get started using either the common reference data set or the enterprise set depending on your implementation requirement. You can also create and maintain custom reference data sets, while continuing to use the common reference data set.
Consider the following scenario. Your enterprise can decide that only some aspects of corporate policy should affect all business units. The remaining aspects are at the discretion of the business unit manager to implement. This enables your enterprise to balance autonomy and control for each business unit. For example, your enterprise holds business unit managers accountable for their profit and loss, but manages working capital requirements at a corporate level. Then, you can let managers define their own sales methods, but define payment terms centrally. As a result, each business unit has its own reference data set for sales methods and one central reference data set for payment terms assigned to all business units.
Partitioning reference data and creating data sets provide you the flexibility to handle the reference data to fulfill your business requirements. You can share modular information and data processing options among business units with ease. You can create separate sets and subsets for each business unit. Alternatively, you can create common sets or subsets to enable sharing reference data between several business units, without duplicating the reference data.
The following figure illustrates the reference data sharing method. 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. As a result, there is a reduction in the administrative burden and the time to implement new business units. For example, you can share sales methods, or transaction types across business units. You may also share certain 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 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 determine that certain aspects of your corporate policy can affect all business units. The remaining aspects are at the discretion of the business unit manager to implement. This allows your enterprise to balance autonomy and control for each business unit. For example, your enterprise holds business unit managers accountable for their profit and loss, but manages working capital requirements at a corporate level. In such a case, you can let managers define their own sales methods, but define payment terms centrally. In this example:
Each business unit has its own reference data set for sales methods.
One central reference data set for payment terms is 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 set up data for this entity component. You can establish other business unit reference data in a business unit-specific reference data set as needed.
Variations exist 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. This method is 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. This method is 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. You need not explicitly assign 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 the following:
Transaction types from the set assigned to the business unit.
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 assign Net 15 to a set specific only to your business unit. At transaction entry, the list of values for payment terms consists of only the set that is assigned to the transaction's business unit.
You can assign the reference data sets to reference objects using 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 the reference entity objects. The assignment takes into consideration the determinant type, determinant, and reference group, if any.
The partitioned reference data is shared using a business context setting called the determinant type. A determinant type is the point of reference used in the data assignment process. The following table lists the determinant types used in the reference data assignment.
Information about the acquisition, depreciation, and retirement of an asset that belongs to a ledger or a business unit.
The departments or organizations within an enterprise.
The organization used for cost accounting and reporting on various inventory and cost centers within an enterprise.
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 (also called determinant value) is a value that corresponds to the selected determinant type. The determinant is one of the criteria for selecting the appropriate reference data set.
A transactional entity may have multiple reference entities (generally considered to be setup data). However, all reference entities are treated alike because of similarity in implementing business policies and legal rules. Such reference entities in your application are grouped into logical units called reference groups. For example, all tables and views that define Sales Order Type details might be a part of the same reference group. Reference groups are predefined in the reference groups table.
When creating or editing currencies, consider these points relevant to entering the currency code, date range, or symbol for the currency.
You can't change a currency code after you enable the currency, even if you later disable that currency.
You can enter transactions denominated in the currency only for the dates within the specified range. If you don't enter a start date, then the currency is valid immediately. If you don't enter an end date, then the currency is valid indefinitely.
Some applications support displaying currency symbols. You may enter the symbol associated with a currency so that it appears along with the amount.
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. If you have to use a different currency for Euro, you can disable the predefined 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 don't 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 must 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 can't be deleted, but 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 must be the language name with territory name in parenthesis where needed, for example English (Australia) and English (Canada).
The predefined territories are countries from the International Organization for Standardization (ISO) 3166 standard. Edit territory descriptions to determine how they are displayed in lists of country values in an application. You don't have to edit territory names or codes unless there is a specific requirement. Create territories if new countries emerge and the application isn't yet patched with the latest ISO country values.
To meet a specific business need, you may edit industry names or descriptions of industries except for those belonging to the North American Industry Classification System (NAICS). Edit the industry descriptions also to determine how they appear in an application.
You may also create industries that contain customizations not included in the NAICS standards.
To meet specific business needs, you can associate industries with territories. For example, administrators can customize a page in different ways for different sets of users of the same industry, but residing in different countries.
Create or enable any currency for displaying monetary amounts, assigning currency to ledgers, entering transactions, recording balances, or for any reporting purpose. All currencies listed in the International Organization for Standardization (ISO) 4217 standard are supported.
The default currency is set to United States Dollar (USD).
Precision refers to the number of digits placed after the decimal point used in regular currency transactions. For example, USD would have 2 as the precision value for transactional amounts, such as $1.00.
Extended precision is the number of digits placed after the decimal point and must be greater than or equal to the precision value. For calculations requiring greater precision, you can enter an extended precision value such as 3 or 4. That would result in the currency appearing as $1.279 or $1.2793.
Minimum accountable unit is the smallest denomination for the currency. For example, for USD that would be .01 for a cent.
In Setup and Maintenance work area, search for the Manage Currencies task to set these values for a currency.
The statistical unit currency type denotes the Statistical (STAT) currency used to record financial statistics in the financial reports, allocation formulas, and other calculations.
Edit the names and descriptions of International Organization for Standardization (ISO) languages to determine how they appear in the application. The ISO languages are a part of the ISO 639 standard. If any change to the ISO standard doesn't reflect in the application, you can update the ISO alpha-2 code or add languages to provide up-to-date information.
Installed languages automatically appear on the Manage Languages page. This page also displays all languages that are available for installation and translation. Each dialect is treated as a separate language.
Generally, you don't need to edit any of the detailed fields unless absolutely necessary.
Though all standard time zones are provided, enable only a subset for use in lists of time zone values. You can add time zones if new zones became standard and the application isn't yet patched with the latest values.
Auditing is used to monitor user activity and all configuration, security, and data changes that have been made to an application. Auditing involves recording and retrieving information pertaining to the creation, modification, and removal of business objects. All actions performed on the business objects and the modified values are also recorded. The audit information is stored without any intervention of the user or any explicit user action.
Use audit policies to select specific business objects and attributes to be audited. The decision to create policies usually depends on the type of information to be audited and to the level of detail required for reporting.
For Oracle Applications Cloud, you must configure the business objects and select the attributes before enabling audit. If you enable audit without configuring the business objects, auditing remains inactive. By default, auditing is disabled for all applications. To enable and manage audit, ensure that you have a role with the assigned privilege Manage Audit Policies (FND_MANAGE_AUDIT_POLICIES_PRIV). For appropriate assignment of roles and privileges, check with your security administrator.
To enable auditing for Oracle Fusion Middleware products, select one of the levels at which auditing is required for that product. The audit levels are predefined and contain the metadata and events to be audited. For more information, see Audit Events for Oracle Applications Cloud Middleware (Doc ID 2114143.1) on My Oracle Support at https://support.oracle.com.
If you don't want an application to be audited, you can stop the audit process by setting the Audit Level option to None.
Audit enables tracking the change history of particular attributes of a business object. However, those objects and their attributes must be selected for audit and auditing must be enabled for that application. Your configuration settings determine which attributes to audit for a given object, and when the audit starts and ends. Auditing takes into account all the operations performed on an object and its attributes, such as create, update, and delete. To configure audit business object attributes, navigate to the Manage Audit Policies page in the Setup and Maintenance work area.
To set up auditing, you must select a web application that contains the required business objects that can be audited. From the list of business objects, select those business objects that you want to audit. Selecting a business object also displays its attributes that are enabled for auditing.
For each selected business object to be audited, select the corresponding attributes to include in the audit. All attributes that belong to that object are by default selected for audit and appear on the user interface. However, you can add or remove attributes from the list. When you remove an attribute from the list, you stop auditing it even when the parent object is selected for audit. So, if you want an attribute to be audited, you must add it to the list. If the object selected in an audit hierarchy is also a part of several other audit hierarchies, the attribute configuration for that object is applicable to all the hierarchies in that application.
The business object is ready for audit after you select its attributes and save the configuration changes. However, to start auditing, the audit level for Oracle Applications Cloud must be set to Auditing on the Manage Audit Policies page.
To stop auditing an object, you can deselect the entire object and save the configuration. As a result, all its selected attributes are automatically deselected and are not audited. To continue to audit the business object with select attributes, deselect those attributes that are not to be audited. When users view the audit history for an application, they can specify the period for which they want the results. Therefore, make a note of when you start and stop auditing an application.
For example, users intend to view the audit history of an object for the previous week, but auditing for that object was stopped last month. They wouldn't get any audit results for that week, because during the entire month that object wasn't audited. Even if you enable audit for that object today, users can't get the wanted results because audit data until today isn't available.
To set up auditing for Oracle Applications Cloud, use the Manage Audit Policies task from the Application Extensions functional area within your offering. To set up auditing for Oracle Fusion Middleware products, select the level of auditing mapped to a predefined set of metadata and the events that have to be audited. Information about configuring audit for Oracle Fusion Middleware products is provided in Oracle Fusion Middleware guides.
You can also create a configuration file and deploy it to audit a specific Oracle Fusion Middleware product. The configuration details for Oracle Fusion Middleware products are available as audit-specific assets that you can use to create the config.xml configuration file. To get a list of audit-specific assets, see Audit Events for Oracle Applications Cloud Middleware (Doc ID 2114143.1) on My Oracle Support at https://support.oracle.com.
Use the Manage Oracle Social Network Objects task for managing the Oracle Social Network Objects. The integration of Oracle Social Network with applications and business processes brings key attributes from the applications to share, socialize, and update information. This helps in making better business decisions based on additional information that you obtain and analyze within your social network environment.
Use the Manage Oracle Social Network Objects page to set up and define:
The business objects and attributes to enable
The enablement method for social network integration with Oracle Applications Cloud
To open the Manage Oracle Social Network Objects page, start in the Setup and Maintenance Overview page and search for the Manage Oracle Social Network Objects task.
Use Oracle Social Network to:
Discuss projects and plans in public forums
Activity feeds of the people you select
An important aspect of managing Oracle Social Network objects is enabling business objects for integration.
A business object can't be shared within social network until a functional administrator or implementor:
Accesses the Manage Oracle Social Network Objects page in Oracle Applications Cloud
Enables the business object for social network integration
When you update translations, you send translations for business objects with the enablement option as Manual or Automatic to Oracle Social Network.
On updating translations, you also:
Synchronize the newly translated text from Oracle Applications Cloud so that it can be used within social network. This means you can:
Install and enable a new language.
Take a language patch at any time.
Send attribute labels and business object names to social network for use in its user interface.
Message names that begin with FND_CMN are common messages. Each common message can appear in multiple places in any product family across Oracle Applications Cloud. For example, the FND_CMN_NEW_SRCH message can be used for any search to indicate that no results were found. Common messages of type error or warning are part of the message dictionary.
You can create custom common messages for use in multiple places. However, ensure that you follow the predefined naming convention and numbering series associated with the application or module.
Common messages can be used in any application. Therefore, 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, ensure that the text is generic and applies to the entire site of Oracle Applications Cloud implementation.
The general preferences such as Language, Territory, or Date Format that you access from the global header have corresponding predefined profile options.
When users define their preferred Date Format, Language, or Currency, they are setting the value of a profile option at the user level.
When users don't specify anything as their preferences, the Site level profile option takes effect.
To help the help desk troubleshoot issues that users encounter in the application, users can record the issue while they reproduce it. Some advanced users might also need detailed information in the About This Page dialog box. Setting up for troubleshooting involves making sure that users have the right access, and determining how many users can record at the same time.
Check with your security administrator that the appropriate users are assigned roles that inherit the following privileges:
Record and View Issue (FND_RECORD_AND_VIEW_ISSUE_PRIV): To create a basic recording
Set Issue Recording Advanced Options (FND_SET_ISSUE_RECORDING_ADVANCED_OPTIONS_PRIV): To set advanced options before starting the recording
View Version Information (FND_VIEW_VERSION_INFORMATION_PRIV): To see the versions that technical components of the application are on
Recordings are stored on servers, and by default, up to five users can record at the same time on each server. For performance reasons, you can set the Maximum Number of Users Allowed to Record Issues (ORA_FND_RECORD_ISSUE_MAX_USERS) profile option to a number lower than five.
You can set profile option values for the CORS headers using the Manage Administrator Profile Values task in the Setup and Maintenance work area.
This table lists the CORS headers that you can set profile option values for.
|CORS Header||Profile Option Name (Profile Option Code)||Profile Option Values|
Allowed Domains (ORACLE.ADF.VIEW.ALLOWED_ORIGINS)
Valid values for allowed origins:
Note: You must set a value for this header to enable CORS.
CORS: Access-Control-Max-Age (CORS_ACCESS_CONTROL_MAX_AGE)
Default value for caching preflight request is 3600 seconds.
CORS: Access-Control-Allow-Methods (CORS_ACCESS_CONTROL_ALLOW_METHODS)
Default values for allowed methods are OPTIONS, HEAD, GET, POST, PUT, PATCH, DELETE.
CORS: Access-Control-Allow-Headers (CORS_ACCESS_CONTROL_ALLOW_HEADERS)
Default values for allowed headers are Accept, Accept-Encoding, Cache-Control, Content-MD5, Content-Type, If-Match, If-None-Match,Origin, User-Agent, X-HTTP-Method-Override, X-Requested-By.
Note: You must include
For example: Accept, Accept-Encoding, Cache-Control, Authorization
CORS: Access-Control-Allow-Credentials (CORS_ACCESS_CONTROL_ALLOW_CREDENTIALS)
In the Setup and Maintenance work area, open the Manage Applications Core Administrator Profile Values task and search for the Privacy Statement URL profile option. In the profile values section, update the Profile Value text box with the full URL of the web page containing the privacy content.
In the global header, click your user name and from the Settings and Actions menu, select About This Page. Click Privacy Statement to view the linked web page.
Use the Manage Administrator Profile Values task to determine the visibility of the message components. For the Message Mode profile option, set the profile value to either User or Administrator. Based on the set value, the administrator or user actions and details appear for the intended audience.
However, the message components are visible to the audience based on their predefined access rights. Anyone having a user level access can't view the Administrator message components. If you set the profile value to the administrators of a specific product, the message components are visible only to that specific audience.
Set the User Image Display Enabled (FND_USER_PHOTO_ENABLED) profile option. If you select:
No, then only the user name displays in the global header.
Yes, then based on the user's job role and whether the user uploaded an image, the image or initials appear in the global header.
For an HCM user who has uploaded an image using the My Photo page in general preferences, the user photo appears.
For an HCM user who hasn't uploaded an image, the user's initials appear in the global header.
For all other users, the My Photo page isn't available, and the user's initials appear in the global header.