Browser version script Skip Headers

Oracle® Fusion Accounting Hub Implementation Guide
11g Release 1 (11.1.3)
Part Number E20374-03
Go to contents  page
Contents
Go to Previous  page
Previous
Go to previous page
Next

3 Define Financial Reporting Structures

This chapter contains the following:

Representing Your Enterprise Structure in Your Financial Reporting Structure: Overview

Financial Enterprise Structure: How It Fits Together

Modeling Your Financial Reporting Structure in Oracle Fusion: Example

Define Chart of Accounts

Manage Value Sets

Maintain Segment Value Attributes

Deploy Flexfields

Manage Cross Validation Rules

Creating Cross Validation: Example

Manage Chart of Accounts Mapping

Define Trees

Manage DRM Synchronization

Define Calendars

Define Currencies

Manage Conversion Rate Types

Manage Daily Rates

Representing Your Enterprise Structure in Your Financial Reporting Structure: Overview

Represent your enterprise structures in your chart of accounts to track and report on your financial objectives and meet your reporting requirements. The benefit of representing your enterprise in the chart of accounts is the Oracle Fusion General Ledger functionality which includes multidimensional reporting with its Essbase tool. Segments included in the chart of accounts become dimensions in Essbase. The recorded data is automatically loaded into the Essbase cube when you post your journal entries. The Essbase tool includes powerful functionality for analysis and reporting on your financial data.

Financial Enterprise Structure: How It Fits Together

Oracle Fusion Applications is an integrated suite of business applications that connects and automates the entire flow of the business process across both front and back office operations and addresses the needs of a global enterprise. The process of designing the enterprise structure, including the accounting configuration, is the starting point for an implementation. This process often includes determining financial, legal, and management reporting requirements and examining consolidation considerations.

The figure below shows the enterprise
structure components and their relationships to each other.

Accounting Configuration Components

The accounting configuration components are:

Representing Legal Entities, Business Units, Departments in Chart of Accounts

The following list provides information on how to represent legal entities, business units, and departments in chart of accounts.

Modeling Your Financial Reporting Structure in Oracle Fusion: Example

This example uses a fictitious global company to demonstrate the analysis that can occur during the financial reporting structure planning process.

Scenario

Your company, InFusion Corporation, is a multinational conglomerate that operates in the United States (US) and the United Kingdom (UK). InFusion has purchased an Oracle Fusion enterprise resource planning (ERP) solution including Oracle Fusion General Ledger and all of the Oracle Fusion subledgers. You are chairing a committee to discuss creation of a model for your global financial reporting structure including your chart of accounts for both your US and UK operations.

InFusion Corporation

InFusion Corporation has 400 plus employees and revenue of $120 million. Your product line includes all the components to build and maintain air quality monitoring (AQM) systems for homes and businesses. You have two distribution centers and three warehouses that share a common item master in the US and UK. Your financial services organization provides funding to your customers for the start up costs of these systems.

Analysis

The following are elements you need to consider in creating your model for your financial reporting structure.

Global Financial Reporting Model

The following figure and table summarize the model that your committee has designed and uses numerical values to provide a sample representation of your financial reporting structure. The model includes the following recommendations:

Recommendations for the chart of accounts design include:

InFusion Corporation is the enterprise
and has two divisions, InFusion United States (US) and InFusion United
Kingdom (UK). InFusion US has two legal entities, InFusion America,
Inc. and InFusion Financial Services, Inc. each with its own ledger.
InFusion UK has one legal entity, Infusion UK Systems, Ltd. which
has on primary ledger in Great Britain Pounds (GBP) and a Reporting
Currency representation in United States Dollar (USD). Each legal
entity has its own business unit (BU). InFusion America also has a
BU that processes general and administrative transactions across all
legal entities. InFusion Corporation has a US and a UK distribution
centers with three associated warehouses. InFusion Corporation shares
one common item master.


Decision

InFusion America, Inc.

InFusion Financial Services, Inc.

InFusion UK Systems, Ltd.

Type of Ledgers

Primary

Primary

Primary with the use of Reporting Currency functionality

Legal Entity Codes

US Legal Entity 1: US Corporate

US Legal Entity 2: US Systems

US Legal Entity 3: US Financial Services

UK Legal Entity 4: UK Systems

Balancing Segments

101: US Corporate

201: US Systems Components

202: US Systems Installations

203: US Systems Maintenance

102: US Financial Services

103: UK Systems

301: Components

302: UK Systems Installations

303: UK Systems Maintenance

Currencies for Reporting

US Dollar (USD)

US Dollar (USD)

Great Britain Pounds Sterling (GBP)

US Dollar (USD)

Calendar Ending date

December 31st

April 30th

December 31st

Business Units (BU)*

BU 1: US Systems

BU 4: Corporate (Shared Service Center)

BU 2: Financial Services

BU 3: UK Systems

Balances Storage Method

Standard Balances

Average and Standard Balances

Standard Balances

Locations represented by cost centers in the chart of accounts.

Headquarters US Distribution Center (BU 1)

US Warehouse West

US Warehouse East

Headquarters

UK Distribution Center (BU 3)

UK Warehouse

Note

In the chart of accounts, cost centers, with hierarchical rollups, represent business units. InFusion Corporation is also a legal entity but is not discussed in this example.

Define Chart of Accounts

Chart of Accounts: Explained

The chart of accounts is the underlying structure for organizing financial information and reporting. An entity records transactions with a set of codes representing balances by type, expenses by function, and other divisional or organizational codes that are important to its business.

A well-designed chart of accounts provides the following benefits:

The chart of accounts facilitates aggregating data from different operations, from within an operation, and from different business flows, thus enabling the organization to report using consistent definitions to their stakeholders in compliance with legislative and corporate reporting standards and aiding in management decisions.

Best practices include starting the design from external and management reporting requirements and making decisions about data storage in the general ledger, including thick versus thin general ledger concepts.

Thick Versus Thin General Ledger: Critical Choices

Thick versus thin general ledger is standard terminology used to describe the amount of data populated and analysis performed in your general ledger. Thick and thin are the poles; most implementations are somewhere in between. Here are some variations to consider:

Thin General Ledger

With a thin general ledger, you use the general ledger for internal control, statutory reporting, and tracking of asset ownership. You minimize the data stored in your general ledger. A thin general ledger has many of the following characteristics:

A thin general ledger has natural accounts at a statutory reporting level, for example, payroll expense, rent, property taxes, and utilities. It has cost centers at the functional expense level, such as Research and Development (R&D) or Selling, General, and Administrative (SG&A) expense lines, rather than at department or analytic levels. It omits business unit, division, and product detail.

One example of an industry that frequently uses a thin general ledger is retail. In a retail organization, the general ledger tracks overall sales numbers by region. A retail point of sales product tracks sales and inventory by store, product, supplier, markup, and other retail sales measures.

Thick General Ledger

With a thick general ledger, you use the general ledger as a detailed, analytic tool, performing analytic functions directly in the general ledger. Data is broken down by many reporting labels, and populated frequently from the subledgers.

You maximize the data stored in the general ledger. A thick general ledger has many of the following characteristics:

In a thick general ledger, you obtain detail for cost of goods sold and inventory balances and track property plant and equipment at a granular level. Cost centers represent functional expenses, but also roll up to departmental or other expense analysis levels. Using product and location codes in optional segments can provide reporting by line of business. Posting daily, at the individual transaction level, can maximize the data stored in the general ledger.

One example of an industry that frequently uses a thick general ledger is electronic manufacturers. Detail on the revenue line is tagged by sales channel. Product is structured differently to provide detail on the cost of goods sold line, including your bill of materials costs. The general ledger is used to compare and contrast both revenue and cost of goods sold for margin analysis.

Other Considerations

Consider implementing a thick ledger if there are business requirements to do any of the following:

Consider implementing a thin ledger in addition to a thick ledger, if there are additional requirements for:

The important consideration in determining if a thick ledger is the primary or secondary ledger is your reporting needs. Other considerations include how the values for an operational dimension or segment are derived and the amount of resources used in reconciling your different ledgers. If values for the operational dimension are always entered by the user like other segments of the accounting flexfield, then a thick primary ledger is the better choice.

However, if values for the operational dimension or segment are automatically derived from other attributes on the transactions in your subledger accounting rules, rather than entered in the user interface, then use a thick secondary ledger. This decision affects the amount of:

Summary

The factors you need to consider in your decision to use a thick or thin general ledger for your organization, are your:

Chart of Accounts: How Its Components Fit Together

There are several important elements to the basic chart of accounts in Oracle Fusion Applications: a structure that defines the account values, segments, and their labels, and rules (security and validation). Account combinations link the values in the segments together and provide the accounting mechanism to capture financial transactions.

This figure shows the main components
in the chart of account structure and the way they fit together. The
chart of accounts consists of segments which have value sets attached
to them to determine the values from each used in creating account
combinations. Segments also have segment labels attached to them to
point to the correct segment to use in general ledger processing,
such as intercompany balancing or retained earning summarization.
Segments are secured by security rules and accounts are secured by
cross validation rules.

Chart of Accounts

The chart of accounts defines the number and attributes of various segments, including the order of segments, the width of segments, prompts, and segment labels, such as balancing, natural account, and cost center.

The chart of accounts further defines the combination of value sets associated with each segment of the chart of accounts, as well as the type, default value, additional conditions designating the source of the values using database tables, and the required and displayed properties for the segments.

Segments

A chart of accounts segment is a component of the account combination. Each segment has a value set attached to it to provide formatting and validation of the set of values used with that segment. The combination of segments creates the account combination used for recording and reporting financial transactions. Examples of segments that may be found in a chart of accounts are company, cost center, department, division, region, account, product, program, and location.

Value Sets and Values

The value sets define the attributes and values associated with a segment of the chart of accounts. You can think of a value set as a container for your values. You can set up your flexfield so that it automatically validates the segment values that you enter against a table of valid values. If you enter an invalid segment value, a list of valid values appears automatically so that you can select a valid value. You can assign a single value set to more than one segment, and you can share value sets across different flexfields.

Segment Labels

Segment labels identify certain segments in your chart of accounts and assign special functionality to those segments. Segment labels were referred to as flexfield qualifiers in Oracle E-Business Suite. Here are the segment labels that are available to use with the chart of accounts.

Note

All segments have a segment qualifier that enables posting for each value. The predefined setting is Yes to post.

Account Combinations

An account combination is a completed code of segment values that uniquely identifies an account in the chart of accounts, for example 01-2900-500-123, might represent InFusion America (company)-Monitor Sales (division)-Revenue (account)-Air Filters (product).

Rules

The chart of accounts uses two different types of rules to control functionality.

Chart of Accounts Structure and Instances: Critical Choices

In Oracle Fusion General Ledger, the chart of accounts model is framed around the concept of a chart of accounts structure, under which one or more chart of accounts structure instances can be created. There are critical choices that need to be considered when creating chart of accounts instances and structures.

Chart of Accounts Structure

When creating the segments for the chart of accounts structure, you must enter segment sequence numbers that are consecutive and begin with the number one.

Chart of Accounts Structure Instance

For segments in your chart of account structure instance that you expect to contain a large number of distinct values, you must perform the following steps:

Creating Chart of Accounts Structure and Instances: Examples

In Oracle Fusion General Ledger, the chart of accounts model is framed around the concept of a chart of accounts structure, under which one or more chart of accounts structure instances can be created. A chart of accounts structure defines the key attributes for your chart of accounts, such as the number of segments, the segment sequences, the segment names, segment prompts, segment labels, for example natural account and primary balancing, and default value sets.

The chart of accounts instance is exposed in the user interfaces and processes. By default, a chart of accounts instance inherits all the attributes of the chart of accounts structure, meaning that all instances of the same structure share a common shape and have the same segments in the same order. However, at the chart of accounts instance level, you can override the default value set assignments for your segments and assign a unique account hierarchy that determines the parent and child relationships between the value set values. At the chart of accounts instance level, determine if allow dynamic insertion is enabled to generate new account combinations dynamically instead of creating them manually.

Chart of Account Structure

You are creating a chart of accounts structure as you setup your chart of accounts for your enterprise, InFusion America, Inc. Follow these steps:

  1. Navigate to the Manage Chart of Accounts page from the Functional Setup Manger by querying on Manage Chart of Accounts and clicking on the Go To Task.

  2. Select General Ledger from the Module list of values and click Search.

  3. Click Manage Structures to open the Manage Key Flexfield Structures page.

  4. Select the General Ledger row and click the Create to open the Create Key Flexfield Structure page.

  5. Enter a unique Structure Code, INFUSION_AM_COA_STRUCTURE, and Name, InFusion America COA Structure. Provide an optional Description, InFusion America Inc. Chart of Accounts Structure.

  6. Select the - Delimiter to visually separate your segment values.

  7. Click Save.

  8. To create a new segment, click the Create to open the Create Key Flexfield Segment page.

    1. Enter the following parameters:


      Parameter

      Value

      Segment Code

      INFUSION_AM_CO

      Name

      InFusion America Company

      Description

      InFusion America Inc. Company

      Sequence Number

      1

      Prompt

      Company

      Short Prompt

      CO

      Display Width

      2

      Column Name

      Segment1

      Default Value Set Code

      INFUSION_AM_COMPANY

    2. Select an optional segment label, Primary Balancing Segment, to indicate its purpose within your chart of accounts.

      Note

      Two segment labels are required: primary balancing segment and natural account segment. These labels are not used with each other or with other labels in a specific segment.

    3. Click Save and Close.

    4. Click Done.

    5. Define additional segments following the same process.

Chart of Account Instance

You are creating a chart of accounts instance as you setup your chart of accounts for your enterprise, InFusion America, Inc. Follow these steps:

  1. Navigate to the Manage Chart of Accounts page from the Functional Setup Manger by querying on Manage Chart of Accounts and clicking on the Go To Task.

  2. Select General Ledger from the Module list of values and click Search.

  3. Select the General Ledger row and click Manage Structure Instances to open the Manage Key Flexfield Structure Instance page.

  4. Click the Create icon to open the Create Key Flexfield Structure Instance page.

  5. Enter a unique Structure Instance Code, INFUSION_AM_COA_INSTANCE, and Name, InFusion America COA Instance. Provide an optional Description, InFusion America Inc. Chart of Accounts Structure Instance.

  6. Select Dynamic combination creation allowed to indicate that you want to dynamically generate account combinations.

  7. Associate your instance with your Structure Name, InFusion America Structure.

    Note

    By default, an instance inherits the key attributes of the associated structure. Some attributes, such as the value set assigned to each the segment, can be modified.

  8. Click Save.

  9. Optionally, select the segment row and click Edit to modify instance segments.

  10. Check Required, Displayed, and Business intelligence enabled check boxes.

    Note

    Check the three options for all segments including those intended for future use. The recommended best practice is to define one segment for future use and set a default value. This ensures room for expansion in your chart of accounts and that the extra segment is populated in the account combinations.

  11. Click OK.

  12. Click Save and Close.

  13. Define additional instances following the same process.

    Note

    Alternatively, proceed directly with creating your value set values by selecting the corresponding Value Set Code in the Segment Instances table.

  14. Click Done.

  15. Click Deploy Flexfield.

  16. Click OK.

Creating One Chart of Accounts Structure with Many Instances: Example

In Oracle Fusion General Ledger, the chart of accounts model is framed around the concept of a chart of accounts structure, under which one or more chart of accounts structure instances can be created.

Scenario

Your company, InFusion Corporation, is a multinational conglomerate that operates in the United States (US) and the United Kingdom (UK). InFusion has purchased an Oracle Fusion enterprise resource planning (ERP) solution including Oracle Fusion General Ledger and all of the Oracle Fusion subledgers. You are chairing a committee to discuss creation of a model for your global financial reporting structure including your charts of accounts for both your US and UK operations.

InFusion Corporation

InFusion Corporation has 400 plus employees and revenue of $120 million. Your product line includes all the components to build and maintain air quality monitoring (AQM) systems for homes and businesses.

Analysis

In Oracle Fusion General Ledger, the chart of accounts model is framed around the concept of a chart of accounts structure, under which one or more chart of accounts structure instances can be created.

Chart of Accounts Model

The chart of accounts structure provides the general outline of the chart of accounts and determines the number of segments, the type, the length, and the label (qualifier) of each segment. This forms the foundation of the chart of accounts definition object.

For each chart of accounts structure, it is possible to associate one or more chart of accounts structure instances. Chart of accounts structure instances under the same structure share a common configuration with the same segments, in the same order, and the same characteristics. Using one chart of accounts structure with multiple instances simplifies your accounting and reporting.

At the chart of accounts structure instance level, each segment is associated with a value set that conforms to the characteristic of that segment. For example, you assign a value set with the same segment type and length to each segment. You are using hierarchies with your chart of accounts segments. Each structure instance segment is assigned a tree code to indicate the source of the hierarchy information for the associated value set. The same value set can be used multiple times within the same or across different chart of accounts instances within the same structure or in different structures. This functionality reduces your segment value creation and maintenance across your charts of accounts.

The collective assignment of value sets to each of the segments forms one chart of accounts instance. At the chart of accounts structure instance level, you can select to enable dynamic insertion. Dynamic insertion allows the creation of account code combinations automatically the first time your users enter that new account combination. The alternative is to create them manually. By deciding to enable dynamic insertion, you save data entry time and prevent delays caused by the manual creation of new code combinations. Well defined cross validation rules help prevent the creation of inappropriate account code combinations.

Perform deployment after a new chart of accounts structure and structure instances are defined or any of their modifiable attributes are updated. Deployment validates and regenerates the necessary objects to enable your charts of accounts and chart of accounts structure instances. By unifying and standardizing you organization's chart of accounts, you are positioned to take full advantage of future functionality in Oracle Fusion General Ledger.

In summary, you are recommending to your company to unify the organization's chart of accounts in a single chart of accounts structure based on chart of accounts commonalities across ledgers. You have also decided to use the chart of accounts structure instance construct to serve different accounting and reporting requirements by using value sets specific to each of your entities.

Cost Centers and Departments: Explained

A cost center represents the smallest segment of an organization for which costs are collected and reported. A department is an organization with one or more operational objectives or responsibilities that exist independently of its manager and has one or more workers assigned to it.

The following two components need to be considered in designing your enterprise structure:

Cost Centers

A cost center also represents the destination or function of an expense as opposed to the nature of the expense which is represented by the natural account. For example, a sales cost center indicates that the expense goes to the sales department.

A cost center is generally attached to a single legal entity. To identify the cost centers within a chart of accounts structure use one of these two methods:

Departments

A department is an organization with one or more operational objectives or responsibilities that exist independently of its manager. For example, although the manager may change, the objectives do not change. Departments have one or more workers assigned to them.

A manager of a department is typically responsible for:

Note

The manager of a sales department may also be responsible for meeting the revenue targets.

The financial performance of departments is generally tracked through one or more cost centers. In Oracle Fusion Applications, departments are defined and classified as Department organizations. Oracle Fusion Human Capital Management (HCM) assigns workers to departments, and tracks the headcount at the departmental level.

The granularity of cost centers and their relationship to departments varies across implementations. Cost center and department configuration may be unrelated, identical, or consist of many cost centers tracking the costs of one department.

FAQs for Manage Charts of Accounts

How can I use future accounting segments?

To plan for future growth in the business organization that requires additional segments in the chart of accounts, extra segments can be added to the chart of accounts structure during your original implementation. Since all segments of the chart are required and have to be enabled, these unused segments can be assigned value sets that have a single value in the chart of accounts structure instance. This value is set as a default for that segment so that the extra segments are automatically populated when an account code combination is used.

Manage Value Sets

Value Sets: Explained

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

The following types of validation are available for value sets.

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.

Security

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 will 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 will 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.

Precision and Scale

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).

Usage and Deployment

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.

Figure shows a value set shared by
both a key flexfield and 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.

Chart of Accounts Values Sets: Critical Choices

A value set is the collection of account values that are associated with a segment of a chart of accounts structure instance. When creating values sets, consider the following critical choices:

Module Designation

The module designation is used to tag value sets in Oracle Fusion Applications and sets the value sets apart during upgrades and other processes. Chart of accounts value sets upgraded from Oracle E-Business Suite Release 12 generically bear the module value of Oracle Fusion Middleware. When creating new value sets for a chart of accounts, the module can be specified as Oracle Fusion General Ledger to distinctly identify its intended use in an accounting flexfield, basically a chart of accounts.

Validation Type

Assign one of the following validation types to chart of accounts value sets:

Format Assignments

Value sets for chart of accounts must use the Value Data Type of Character. The Value Subtype is set to Text. These two setting support values that are both numbers and characters, which are typical in natural account segment values. Set the maximum length of the value set to correspond to the length of the chart of accounts segment to which it is assigned. Best practices recommend restricting values to Upper Case Only or Numeric values that are zero filled by default.

Security Rules

If flexfield data security rules are to be applied to the chart of accounts segment associated with the value set, the Enable Security check box must be checked for the assigned value set. In addition, assign a data security resource name to enable creation of a data security object automatically for the value set. The data security object is used in the definition of flexfield data security rules.

Value Definition

Once these basic characteristic are defined for the value set, values can be added to the set in the Manage Values page.

Note

If the value set is used with a natural account segment, the value also requires you set the Natural Account Type, with one of the following values: Asset, Liability, Equity, Revenue or Expense. Other attributes used are Third Party Control Account, Reconciliation indicator, and Financial Category used with Oracle Transaction Business Intelligence reporting.

Oracle Fusion General Ledger best practice is to define the values for the value set after the value set is assigned to a chart of accounts structure instance. Otherwise you are not able to define the mandatory value attributes, such as summary flag, posting allowed, and account type for natural account segment. The attributes must be added after the value set is assigned to a chart of accounts structure instance.

Creating a Value Set For Your Chart of Accounts: Example

Create your value sets before creating your chart of accounts. A value set can be shared by different charts of accounts or across different segments of the same chart of accounts.

Scenario

You are creating a company value set to be used in your chart of accounts for your enterprise, InFusion America, Inc. Follow these steps:

  1. Navigate to the Manage Chart of Accounts Value Sets task from within your implementation project and click the Go to Task.

  2. Click the Create icon on the toolbar of the Search Results table. The Create Value Set page opens.

  3. Enter a unique Value Set Code, InFusion America Company, and an optional Description, Company values for InFusion America Inc.

  4. Select General Ledger from the list in the Module field.

  5. Select Independent as Validation Type.

  6. Select Character as the Validation Data Type.

  7. Click Save and Close.

Maintain Segment Value Attributes

Segment Labels: Explained

Segment labels identify certain segments in your chart of accounts structure and assign special functionality to those segments. Segment labels were referred to as flexfield qualifiers in Oracle E-Business Suite (EBS). Best practice is to assign each segment label one time within the chart of accounts structure. Here are the segment labels that are available to use with the chart of accounts structure.

Caution: Validations are not performed when segment labels are assigned, so verify that all are assigned correctly before using your chart of accounts.

Balancing

Ensures that all journals balance for each balancing segment value or combination of multiple balancing segment values. You can secure access to your primary balancing segment values only with data access sets. The general ledger application automatically calculates and creates balancing lines as required in journal entries. For example, recognizing an entity's receivable and the other entity's payable. There are three balancing segment labels: primary, second, and third balancing. The primary balancing segment label is required.

Cost Center

Represents the smallest segment of an organization for which costs are collected and reported. Facilitates grouping of natural accounts by functional cost types, accommodating tracking of specific business expenses across natural accounts. As cost centers combine expenses and headcount data into costs, they are useful for detailed analysis and reporting. Cost centers are optional, but required if accounting for depreciation, additions, and other transactions in Oracle Fusion Assets, and for storing expense approval limits in Oracle Fusion iExpense.

Natural Account

Determines the account type (asset, liability, expense, revenue, or equity), whether posting is allowed, and other information specific to the segment value. The natural account segment is mapped to the Financial Category dimension in the balances cube to enable ad hoc reporting and transactional dashboards. This functionality uses Oracle Fusion Business Intelligence Enterprise Edition to analyze and drill into expense and revenue transactions. The natural account segment label is required.

Intercompany

Optionally, assigns the segment to be used in intercompany balancing functionality. You cannot use the primary balancing or natural account segments as the intercompany segment. It is recommended that you use this segment and assign the same values to both the primary balancing and intercompany value sets to enable clear visibility of the due to and due from relationships inherent in intercompany accounting across the entire organization. Consider using the same values set for the primary balancing and intercompany segments to save maintenance and ensure completeness.

Management

Optionally, denotes the segment that has management responsibility, such as the department, cost center, or line of business. Can be any segment, except the primary balancing or natural account segments. By designating a segment of your chart of accounts to the management segment, you can secure access to the management segment values with data access sets. By providing segment values to represent the lowest level of your organization, you can roll up results by line of business or other management criteria.

Note: Available in a future release. Do not assign this segment to your chart of accounts in Oracle Fusion Version 1.

Segment Labels: Example

For a chart of accounts, each segment can be qualified by a label to distinctly indicate its purpose. This designation is also used by the Oracle Fusion General Ledger processes to determine the proper way to display and process transactions and balances that are recorded.

Scenario

You are creating your chart of accounts with six segments. Oracle Fusion General Ledger permits selection of up to thirty segments for your chart of accounts. You must have a minimum of three required segments, as determined below by the number of required segment labels (qualifiers). Required segment labels are:

The following optional segment labels are available and you are implementing all except for the Management Segment:

Segment labels can only be assigned once within your chart of accounts. The following table shows how you are assigning the segment labels in your chart of accounts.


Segment

Segment Label

Company

Primary Balancing Segment

Cost Center

Cost Center and Second Balancing Segment

Location

Third Balancing Segment

Account

Natural Account Segment

Product Line

 

Intercompany

Intercompany Segment

Note

Validations are not performed when segment labels are assigned, so verify that all are assigned correctly before using your chart of accounts.

For Oracle Transactional Business Intelligence reporting, all labeled or qualified segments of the chart of accounts are automatically maintained in the data that reporting is based on. For non-qualified segments, the granularity of information stored in these segments is summarized and thus, Oracle Transactional Business Intelligence would not be able to provide detailed reporting along by these segments. If it is important to maintain the ability to perform detailed reporting on such segments, create custom labels to qualify these segments.

For example, one of the segments of the chart of accounts is based on product line, and none of the predefined segment labels above are applicable. It is important for the organization to derive product line based Oracle Transactional Business Intelligence reports. Create a custom label called Product Line to use to qualify the Product Line segment of the chart of accounts.

Balancing Segments: Explained

Balancing segments ensure that all journals balance for each balancing segment value or combination of multiple balancing segment values. You can secure access to your primary balancing segment values only with data access sets. The general ledger application automatically calculates and creates balancing lines as required in journal entries. For example, recognizing an entity's receivable and the other entity's payable. There are three balancing segment labels: primary, second, and third balancing. The primary balancing segment label is required.

By enabling multiple balancing segments for your chart of accounts, it is possible to produce financial statements for each unique combination of segment values across not only one, but two or even three qualified balancing segments. This ability provides you greater insights into your operations as it affords you visibility along the critical fiscal dimensions you use to plan, monitor, and measure your financial performance.

The following explains processes that use balancing segments.

Multiple Balancing Segments: Points to Consider

Oracle Fusion General Ledger supports tracking financial results at a finer level of granularity than a single balancing segment. In addition to the required primary balancing segment for the chart of accounts, which is typically associated with the company dimension of a business organization, two additional segments of the chart of accounts can be optionally qualified as the second and third balancing segments respectively. Possible chart of accounts segments that can be tagged as these additional balancing segments include cost center or department, additional aspects of a business commonly used in measuring financial results.

There are several points to consider in using multiple balancing segments:

Journal Entry Processing

Multiple balancing segments ensure that account balances come from journal entries where the debits equal the credits, and thus, the financial reports are properly generated for each unique instance of account value combinations across the balancing segments. Consider this option carefully as it provides more granular reporting but requires more processing resources.

Implementation Timing

When considering implementing the optional second and third balancing segments, keep in mind that these chart of accounts segment labels are set from the beginning of time and are actively used by your ledgers. This is important to ensure that balances are immediately maintained in accordance with the necessary balancing actions to produce consistent financial reporting for the desired business dimensions. Multiple balancing segment ledgers that are not maintained from the beginning of time require extensive manual balance adjustments to catch up and realign the balances in accordance with the multiple balancing segments.

Note

Do not set a segment already qualified as a natural account or intercompany segment as any of the three balancing segments. Validations are not performed when segment labels are assigned, so verify that all are assigned correctly before using your chart of accounts.

Change Options

Once a segment has been enabled and designated as a balancing segment, you must not change the segment. Do not disable the segment or remove the segment labels. These settings must be consistently maintained throughout the life of the chart of accounts to control the accuracy and integrity of the financial data.

Migration Adjustments

For charts of accounts migrated from Oracle E-Business Suite to Oracle Fusion General Ledger that use a segment with the secondary balance tracking segment qualifier, steps must be taken to ensure the proper transition to the second and third balancing segments. The required adjustments are extensive.

For ledgers associated with a migrated chart of accounts, its balances must be adjusted manually to be consistent with the second and third balancing segments as though these segment labels have been in place since the beginning of entries for these ledgers. This requires recomputing and updating of the following processes to reflect the correct balancing for each unique combination of segment values across the additional second and third balancing segments.

Note

All previously translated balances must also be purged, and new translations run to properly account for translated retained earnings and cumulative translation adjustments with the correct level of balancing.

Using Multiple Balancing Segments: Example

This simple example illustrate balancing along two balancing segments for a simple chart of accounts with three segments.

Scenario

Your company has a chart of accounts with two balancing segments and three segments, qualified as follows:

The following multiple company and cost center journal has been entered to transfer advertising and phone expense from Company 1, Cost Center A to Company 2, Cost Center B.


Account

Debit

Credit

Company 1-Cost Center A-Advertising Expense Account

600

 

Company 2-Cost Center B-Advertising Expense Account

 

600

Company 1-Cost Center A-Phone Expense Account

800

 

Company 2-Cost Center B-Phone Expense Account

 

800

During the posting process, the last four lines are created to balance the entry across the primary and second balancing segments, company and cost center.


Account

Debit

Credit

Company 1-Cost Center A-Advertising Expense Account

600

 

Company 2-Cost Center B-Advertising Expense Account

 

600

Company 1-Cost Center A-Phone Expense Account

800

 

Company 2-Cost Center B-Phone Expense Account

 

800

Company 1-Cost Center A-Balancing Account

 

600

Company 2-Cost Center B-Balancing Account

600

 

Company 1-Cost Center A-Balancing Account

 

800

Company 2-Cost Center B-Balancing Account

800

 

Segment Value Inheritance: Examples

The Segment Value Inheritance process simplifies the maintenance of the chart of accounts. When the characteristics of values in the value sets are updated, such as changes in enabled status, effective date, posting allowed status, or natural account type, all previously created account code combinations that referenced such values are not automatically updated by these changes. The Segment Value Inheritance process allows you to run a controlled process to update such existing account code combinations. This process maintains and corrects the current attribute settings for those account code combinations that contain the account values that were changed.

For account code combinations where the present settings need to be retained and not impacted by account attribute changes, activate the flag to preserve the account code combination's attribute. Activating the flag prevents those account code combination's attributes from being update when the Segment Value Inheritance process is run.

Scenario

For example, there are three inactive account code combinations that share a common inactive cost center value of 110.


Company-Cost Center-Account

Enabled

01-110-5210

No

04-110-4310 (Preserve Attributes flag enabled)

No

03-110-6810

No

Cost center 110 went from being disabled to enabled. When the Segment Value Inheritance process is run, the following shows the result on these three account code combinations.


Company-Cost Center-Account

Enabled

01-110-5210

Yes

04-110-4310 (Preserve Attributes flag enabled)

No

03-110-6810

Yes

Note

Once you disable a segment value and you log out of the system and back in, all code combinations containing that segment no longer work, even if the account combination still shows enabled in the account combination page. Use the Segment Value Inheritance process to set the enable flag correctly on the affected account code combinations.

FAQs for Maintain Segment Values Attributes

How can I change segments in an existing chart of accounts structure?

The chart of accounts structure and chart of accounts structure instance are fundamental constructs in the Oracle Fusion General Ledger accounting setup and cannot be altered once they are in use. The number of segments, the segments' order, each segment's label, length, type, and value set assignment are not updateable. These components set the foundation upon which accounting data is recorded for ledgers that use them. Careful and thoughtful planning must precede all decisions pertaining to defining the chart of accounts.

Deploy Flexfields

Flexfield Deployment: Explained

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.

You can deploy a flexfield to a sandbox for testing or to the mainline for use.

Deployment Status

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 yet.

Patched

The flexfield metadata definition has been modified through a patch, but the flexfield has not yet been deployed so the patched definition is not reflected in the runtime.

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 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.

Initial Deployment Status of Flexfields

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.

Metadata Validation

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: How It Is Calculated

Flexfield deployment status indicates how the flexfield metadata definition in the Oracle Applications database relates to the Application Development Framework (ADF) business components generated into a Metadata Services (MDS) repository.

Settings That Affect Flexfield Deployment Status

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.

How Flexfield Deployment Status Is Calculated

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 by 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.

When a deployment attempt fails and you can access the Deployment Error Message for details.

Deploying a Flexfield-Enabled Sandbox: How It Works With Mainline Metadata

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.

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.

The figure shows a flow in the Define
Flexfields activity that includes testing the flexfield in a sandbox
and possibly also making changes to the MDS data in Oracle Composer
after deploying the flexfield to the mainline for access to users.

Sandbox Metadata Services Repository Data

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.

Mainline Metadata Services Repository Data

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-Enabled Sandbox: Points to Consider

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.

Sandbox MDS Repository Data

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.

Managing a Flexfield-Enabled Sandbox

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.

Deploying Flexfields Using the Command Line: Explained

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

deployFlexForApp

 

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.

deployFlex

 

Deploy a single flexfield regardless of deployment status

deployPatchedFlex

 

Deploys flexfield changes that have been delivered using a flexfield Seed Data Framework (SDF)patch. Deploys flexfields that have a Patched deployment status.

deleteFlexPatchingLabels

 

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.

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.

Consider the following aspects of command line deployment.

Preparing To Use the WLST Flexfield Commands

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.

Using the deployFlexForApp Command

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.

Using the deployFlex Command

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.

Using the deployPatchedFlex Command

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')

 

Using the deleteFlexPatchingLabels Command

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')

 

Exiting the WLST and Checking the Results

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.

Manage Cross Validation Rules

Cross Validation Rules: Overview

In Oracle Fusion General Ledger, use cross validation rules to determine the account combinations that are created dynamically as your users enter transactions or journal entries. Once enabled, a cross validation rule determines whether a selected value for a particular segment of the account combination can be combined with specific values in the other segments to form a new account combination.

A cross validation rule is defined in terms of a condition filter and a validation filter.

For example, if your organization has determined that a certain company value, Operations, cannot use a specific cost center, Marketing, define the following cross validation rule to validate your accounts accordingly: If company is equal to Operations, then validate that cost center is not equal to Marketing.

If account combinations already exist and violate the newly enabled cross validation rules, these account combinations continue to be valid. Before disabling any existing account combinations that violate your rules and you are no longer using, move the balances in those accounts to the correct accounts. Then disable the account combinations manually to prevent further posting.

Note

Best practice is to define and enable cross validation rules before:

Creating Cross Validation: Example

Create cross validation rules to prevent specific combinations of segment values in your account combinations, for example, preventing a particular cost center from being combined with a specific company value. Cross validation rules only affect the creation of new account combinations.

Scenario

Enter a new cross validation rule to prevents your InFusion America Inc. company value 01 from being combined with your marketing department value 300 in an account combination. Your company, InFusion America Inc. does not have a marketing department.

  1. Navigate to the Manage Cross-Validation Rules task from within your implementation project, and then click the Go to Task icon.

  2. Select your InFusion America chart of accounts. Click the Create icon.

  3. Specify a unique rule Name, IFAM01, an optional Description, Do not combine Marketing Department, 300 with InFusion America, company 01.

  4. Enter an optional effective From Date of today. Check Enabled.

  5. Click on the Change filter condition on the Condition Filter. Enter Company equal to 01. The cross validation rule evaluates if Company 01 was entered and if it was, then the validation process continues to evaluate the rule.

    Note

    If you do not specify any statement in the condition filter, then the rule is always evaluated.

  6. Click on the Change filter condition on the Validation Filter. Enter Cost Center equal to 300. When the rule is evaluated, an account combination must contain a cost center other than 300 before it can be created.

  7. Enter an Error Message: Cost Center 300 is not allowed with Company 01. The message displays in the relevant user interfaces and processes when an account combination cannot be created because it violates the rule.

  8. Click Save and Close.

Manage Chart of Accounts Mapping

Mapping Chart of Accounts: Explained

The chart of accounts mapping feature supports the ability to correlate a source chart of accounts to a target chart of accounts to allow for the processing of balances or amounts. This is accomplished by either using segment rules, account rules, or a combination of both. A chart of accounts mapping is used by the posting process in propagating transactions from the primary ledger to its secondary ledger, providing the means to map the primary ledger chart of accounts to that of the secondary ledger. The mapping feature is used by both balance transfer processes for balance level secondary ledgers as well as cross ledger transfers, whereby balances from one ledger are copied to another ledger.

Segment Rules

Segment rules serve to map each segment of the target chart of accounts to an account value or segment in the source account. Three different mapping actions are available:

Account Rules

In addition to segment rules, define account rules for the chart of accounts mapping. Account rules map a complete target account code combination against one or more source account code combinations. The source account code combinations can be defined segment by segment using:

FAQ for Manage Chart of Accounts Mapping

What's the difference between mapping with segment rules and mapping with account rules?

Segment rules serve to map each segment of the target chart of accounts to an account value or segment in the source account of a secondary chart of accounts. A segment is only one part of the account code combination.

Account rules map a complete target account code combination against one or more source account code combinations.

Note

Segment and account rules can be used alone or both types of mapping rules can be used in the same mapping set.

When do account rules override segment rules in the chart of accounts mapping?

Segment rules and account rules can be exclusively used in a chart of accounts mapping, or you can use a combination of both. If there is an overlap between the two types of rules, whereby a source account is mapped one way by the segment rules, and another by the account rules, the account rule supersedes. As such, segment rules can be used to more broadly define how to map the relationship between two charts of accounts on a segment by segment basis, and account rules can be used to more precisely delineate specific source account code combinations into their intended target accounts.

Define Trees

Trees: Overview

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.

Tree Structures

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.

Tree Versions

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

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.

Manage Tree Structures

Tree Structures: Explained

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.

Tree Structure Definition: Points to Consider

Defining a tree structure involves specifying several important pieces of information on the Create Tree Structure: Specify Definition page.

Tree Node Selection

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.

Tree Sharing Mode

The following options are used to determine the mode of sharing a tree structure across the applications.

Creation Mode

Indicates the source where the tree structure is being defined. For predefined tree structures select Oracle and for custom structures, select Customers.

Customization

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.

Multiple Tree Versions

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.

Managing Tree Structures: Points to Consider

You can create, edit, and delete tree structures depending upon the requirement. You can also audit and change the status a tree structure.

Creating and Editing Tree Structures

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.

Setting Status

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.

Tree Structure Audit Results: Explained

Use the tree structure audit results to verify the tree structure's correctness and data integrity. The audit results include the following details:

Running an Audit

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.

Validation Details

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 FND_TREE_NODE_RF or a custom table.

  • The specified table does not exist in the database.

  • The specified table does not contain the same columns as the FND_TREE_NODE_RF 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.

  • Any of the specified label data source view objects do not exist.

  • Any of the specified label data source view objects do not have primary keys.

  • When a label data source view object is initially defined, the database registers the primary keys for the view object. If the view object is later modified such that its primary keys no longer match the primary keys that were registered earlier, this validation fails.

  • Correct the specified label data source view object.

  • Correct the primary keys of the specified label data source view object.

  • Either correct the primary keys in the label data source view object to match the primary keys that were earlier registered in FND_TS_DATA_SOURCE, or correct the primary keys registered in that table to match the new view object definition.

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.

  • Any of the specified data source view objects do not exist.

  • When a data source view object is initially defined, the database automatically registers the primary keys for the view object if the Use non-defined primary key columns check box on the Data Source dialog box is not selected. If the check box is selected, the database registers the primary keys specified explicitly by the user on the Add Data Source dialog box. If the registered primary keys contain any duplicates, this validation fails.

  • The Use non defined primary key columns check box is selected in a data source, but the list of specified primary key columns does not match the primary keys defined in the corresponding data source view object.

  • Any common attribute that exists in both the data source view object and the tree node view object is not of the same data type in both view objects.

  • Correct the specified data source view object.

  • Correct the duplicate column in the registered primary keys.

  • Correct the primary keys of the specified data source view object.

  • Correct any mismatch in data types.

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 FND_TREE_NODE_CF or a custom table.

  • The specified table does not exist in the database.

  • The specified table does not contain the same columns as the FND_TREE_NODE_CF 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 FND_TREE_NODE or a custom table.

  • No table is specified in the Tree Node Table field.

  • The specified table does not exist in the database.

  • The specified table does not contain the same columns as the FND_TREE_NODE table.

Correct the tree node table definition.

Allow Node Level Security

If the Allow Node Level Security option is set to No for the tree structure, the same option cannot be set to Yes on any of its data sources. This is a database setting that is not visible on the Manage Tree Structures page.

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.

Specifying Data Sources for Tree Structures: Points to Consider

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.

Labeling Schemes

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.

Restriction of Tree Node Values

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.

Data Source Values and Parameters

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.

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.

Specifying Performance Options for a Tree Structure: Points to Consider

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

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

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.

Column Flattened Entity Objects

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.

ADF Business Component View Objects

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.

Manage Tree Labels

Tree Labels: Explained

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.

Manage Trees and Tree Versions

Managing Trees and Tree Versions: Points to Consider

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.

Creating and Editing Trees

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.

Creating and Editing Tree Versions

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.

Tree Version Audit Results: Explained

Use the tree version audit results to verify the tree version's correctness and data integrity. The audit results include the following details:

Running an Audit

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.

Validation Details

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.

  • A node in the tree version does not exist in the data source. Deleting data items from the data source without removing the corresponding nodes from the tree version can result in orphaned nodes in the tree version. For example, if you added node A into your tree version, and subsequently deleted node A from the data source without removing it from the tree version, the validation fails.

  • The tree version contains a tree reference node, which references another tree version that does not exist.

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.

Trees and Data Sources: How They Work Together

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.

Metadata

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.

Data Storage

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.

Access Control

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.

Adding Tree Nodes: Points to Consider

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.

Managing Tree Nodes

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.

Node Levels

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.

Node Types

A tree node has the following node types.

Manage DRM Synchronization

Integration with Data Relationship Management: Overview

Oracle Fusion Applications provides integration between Oracle Fusion Accounting Hub and Oracle Hyperion Data Relationship Management, Fusion Edition, if licensed. This integration provides the ability to synchronize chart of accounts values and hierarchies. The functionality also establishes corporate wide accounting structures, for Oracle and non-Oracle ledgers, and automatically updates charts of accounts values and hierarchies across multiple Oracle E-Business Suite and Oracle Fusion instances through a single application.

For more information on completing the post-installation setup for Data Relationship Management, see the Hyperion Data Relationship Management Integration with the Oracle Fusion and E-Business Suite General Ledgers white paper on My Oracle Support at https://support.oracle.com.

Define Calendars

Defining Accounting Calendars: Critical Choices

Define an accounting calendar to create your accounting year and the periods it contains. Specify common calendar options that the application uses to automatically generate a calendar with its periods. Specifying all the options makes defining a correct calendar easier and more intuitive with fewer errors. The choices you make when specifying the following options are critical, because it is difficult to change your accounting calendar after a period status is set to open or future enterable.

Note

In Oracle Fusion, the common calendar types, monthly, weekly, 4-4-5, 4-5-4, 5-4-4, 4-week, quarterly, and yearly, are automatically generated. This functionality makes it easier to create and maintain accounting calendars. By using the period frequency option, you no longer have to go through the tedious task of defining each period manually.

Start Date

If you plan to run translation, specify a calendar start date that is a full year before the start date of the year of the first translation period for your ledger. Translation cannot be run in the first period of a calendar. Consider how many years of history you are going to load from your previous system and back up the start date for those years plus one more. You cannot add previous years once the first calendar period has been opened.

Period Frequency

Use period frequency to set the interval for each subsequent period to occur, for example, monthly, quarterly, or yearly. If you select the period frequency of Other, by default, the application generates the period names, year, and quarter number. You specify the start and end dates. You must manually enter the period information. For example, select the period frequency of Other and enter 52 as the number of periods when you want to define a weekly calendar. For manually entered calendars, when you click the Add Year button, the application creates a blank year. Then, you must manually enter the periods for the new year. The online validation helps prevent erroneous entries.

Note

In Oracle Fusion applications a calendar can only have one period frequency and period type. Therefore, if you have an existing calendar with more than one period type associated with it, during the upgrade from Oracle E-Business Suite, separate calendars are created based on each calendar name and period type combination.

Adjusting Period Frequency

Use the adjusting period frequency to control when the application creates adjusting periods. For example, some of the frequencies you select add one adjusting period at year end, two at year end, or one at the end of each quarter. The default is None which adds no adjusting periods. If you select the frequency of Other, the Number of Adjusting Periods field is displayed. Enter the number of desired adjusting periods and then, manually define them.

Period Name Format Region

The User-Defined Prefix field in the Period Name Format region is an optional feature that allows you to enter your own prefix. For example, define a weekly calendar and then enter a prefix of Week, - as the separator, and the period name format of Period numberYY fiscal year. The application creates the names of Week1-11, Week2-11, through Week52-11. The options for the Format field are predefined values. The list of values is filtered based on the selected separator and only displays the options that match the selected separator.

The year displayed in the period names is based on the selected period name format and the dates the period covers or if the period crosses years, on the year of the start date of the period. For example, April 10, 2010 to May 9, 2010 has the period name of Apr-10 and December 10, 2010 to January 9, 2011 has the name of Dec-10. If period frequency is Other, then the period format region is hidden. The application generates a temporary period name for calendars with period frequency of Other, using a fixed format of Period numberYY. You can override this format with your own customized period names.

Note

For an accounting calendar that is associated with a ledger, changing period names or adding a year updates the accounting period dimension in the balances cubes.

Calendar Validation: How It Works with the Accounting Calendar

Calendar validation is automatic and prevents serious problems when you begin using the calendar. Once you set a calendar period status to open or future enterable, you cannot edit the period.

Settings That Affect Calendar Validation

The calendar validation runs automatically when you save the calendar.

How the Calendar Is Validated

The following table lists the validation checks performed when the accounting calendar is saved.


Validation Performed

Example of Data

Unique period number

2 assigned for two periods

Unique period name

Jan-11 entered twice

Period number beyond the maximum number of periods per year

13 for a 12 period calendar with no adjusting periods

Entered period name contains spaces

Jan 11

Single or double quotes in the period name

Jan '11

Nonadjusting periods with overlapping dates

01-Jan-2011 to 31-Jan-2011 and 30-Jan-2011 to 28-Feb-2011

Period date gaps

01-Jan-2011 to 28-Jan-2011 and 31-Jan-2011 to 28-Feb-2011

Missing period numbers

Periods 1 through 6 defined for a twelve month calendar

Period number gaps

1, 3, 5

Period numbers not in sequential order by date

Period 1 covers 01-Jan-2011 to 31-Jan-2011 and period 2 covers 01-Mar-2011 to 31-Mar-2011, and period 3 covers 01-Feb-2011 to 28-Feb-2011.

Quarter number gaps

1, 3, 4

Quarters not in sequential order by period

1, 3, 2, 4

Period start or end dates more than one year before or after the fiscal year

July 1, 2010 in a 2012 calendar

FAQs for Manage Accounting Calendars

How can I identify errors in my accounting calendar?

Oracle Fusion General Ledger identifies erroneous entries online as you enter a new calendar or change data on an existing calendar. The application also automatically validates the data when you save the calendar.

What's the difference between calendar and fiscal period naming?

The period naming format determines the year that is appended to the prefix for each period in the calendar. For the example, your accounting year has a set of twelve accounting period with a start date of September 1, 2011 and the end date is August 31, 2012, with each period's date range following the natural calendar month date range.

Calendar period naming format: Select the calendar period format to append the period's start date's year to the prefix. For the period covering September 1, 2011 to December 31, 2011, then 2011 or just 11, depending on the period format selected, is appended to each period's name. For the remaining periods covering January 1, 2012 to August 31, 2012, then 2012 or 12, is appended to each period's name.

Fiscal period naming format: Select the fiscal period format to always append the period's year assignment to the prefix. If the accounting periods in the set of twelve are all assigned the year of 2012, then 2012 or just 12, depending on the period format selected, is appended to the period name of all 12 periods.

When do I update an existing calendar?

Update an existing calendar before the new periods are needed as future periods, based on the future period setting in your accounting configuration. If a complete year has been defined and validated, use the Add Year button to add the next year quickly. Accept or change the new rows as required. For example, with the Other frequency type calendar, dates may differ from what the application generates.

What happens if I upgrade my calendar from Oracle E-Business Suite Release 12?

The migration script assigns a period frequency that most closely matches your Oracle E-Business Suite Release 12 calendar. When you use the Oracle Fusion applications Add Year functionality for the first time, you have an opportunity to review and change the period frequency. The Calendar Options page opens only for calendars upgraded from Release 12 to allow one time modification.

Make your changes to the period frequency, adjusting period frequency, and period name format, including the prefix and separator, as needed. Changes can not conflict with the existing upgraded calendar definition. Update the calendar name and description in the calendar header, as needed, for all calendars. Period details for a new year will be generated automatically based on the latest calendar options. You can also manually update the calendar. The modified calendar options affect future years only.

Define Currencies

Defining Currencies: Points to Consider

When creating or editing currencies, consider these points relevant to entering the currency code, date range, or symbol for the currency.

Currency Codes

You cannot change a currency code after you enable the currency, even if you later disable that currency.

Date Ranges

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.

Symbols

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.

Euro Currency Derivation: Explained

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.

Derivation Type

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.

Derivation Factor

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.

Derivation Effective Date

The derivation effective date is the date on which the relationship between the EMU currency and the Euro begins.

FAQs for Manage Currencies

When do I create or enable currencies?

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.

What's the difference between precision, extended precision, and minimum accountable unit for a currency?

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.

Manage Conversion Rate Types

Creating Conversion Rate Types: Critical Choices

Maintain different conversion rates between currencies for the same period with the Oracle Fusion General Ledger conversion rate types functionality. Four predefined daily conversion rate types are seeded: Spot, Corporate, User, and Fixed, allowing you to use different rate types for different business needs. During journal entry, the conversion rate is provided automatically by the General Ledger based on the selected conversion rate type and currency, unless the rate type is user. For user rate types, you must enter the conversion rate. Define additional rate types as needed. Set your most frequently used rate type as the default. Conversion rate types cannot be deleted.

Assign conversion rate types to automatically populate the associated rate for your period average and period end rates for the ledger. For example, you can assign the predefined rate type Spot to populate your period average rates and the predefined rate type Corporate to populate your period end rates. Period average and period end rates are used in translation of account balances.

Conversion rate types are used to automatically assign a rate when you perform the following accounting functions:

In creating new conversion rates, decide whether to do the following:

Enforce Inverse Relationships

Check the Enforce Inverse Relationship check box to specify whether or not to enforce the automatic calculation of inverse conversion rates when defining daily rates.


Action

Results

Checked

When you enter a daily rate to convert currency A to currency B, General Ledger automatically calculates the inverse rate, currency B to A, and enters it in the adjacent column. If either rate is changed, the application automatically recalculates the other rate.

You can update the application calculated inverse rate, but once you do, the related rate is updated. The check box enforces that the inverse relationship is maintained but does not prevent you from updating the rates.

Unchecked

General Ledger calculates the inverse rate but you can change the rate and update the daily rates table without the corresponding rate being updated.

Select Pivot Currencies

Select a pivot currency that is commonly used in your currency conversions. A pivot currency is the central currency that interacts with contra currencies. For example, you set up a daily rate between the US dollar (USD) and the Euro currency (EUR) and another between the USD and the Canadian dollar (CAD). USD is the pivot currency in creating a rate between EUR and CAD. EUR and CAD are the contra currencies. Select the pivot currency from the list of values which contains those currencies that are enabled, effective, and not a statistical (STAT) currency. The description of the pivot currency is populated automatically based on the currency definition.

If you want the application to create cross rates against a base currency, define the base currency as the pivot currency. Selected pivot currencies can be changed in the Rate Types page.

Select Contra Currencies

Select currencies available on the list of values as contra currencies. The available currencies are those currencies which are enabled, effective, not STAT currency, and not the pivot currency selected earlier. The description of the contra currency is populated automatically based on the currency definition. Add or delete contra currencies in the Contra Currencies region of the Rate Types page.

Enable Cross Rates and Allow Cross Rate Overrides

Check the Enable Cross Rates check box to calculate conversion rates based on defined currency rate relationships. General Ledger calculates cross rates based on your defined cross rate rules. Associate your cross rate rules with a conversion rate type, pivot currency, and contra currencies. Cross rates facilitate the creation of daily rates by automatically creating the rates between contra currencies based on their relationship to a pivot currency. If the Enable Cross Rates check box is changed to unchecked after entering contra currencies, the application stops calculating cross rates going forward for that particular rate type. All the earlier calculated cross rates for that rate type remain in the database unless you manually delete them.

For example, if you have daily rates defined for the pivot currency, USD to the contra currency, EUR, and USD to another contra currency, CAD, the application will automatically create the rates between EUR to CAD and CAD to EUR. This prevents the need to manually define the EUR to CAD and CAD to EUR rates.

Check the Allow Cross Rates Override check box to permit your users to override application generated cross rates. If you accept the default of unchecked, the application generated cross rates cannot be overridden

Maintain Cross Rate Rules

Define or update your cross rate rules at any time by adding or removing contra currency assignments. Add a contra currency to a cross rate rule and run the Daily Rates Import and Calculation process to generate the new rates. If your remove a cross rate rule or a contra currency from a rule, any cross rates generated previously for that contra currency remain unless you manually delete them. Changes to the rule are not retroactive and will not affect previously stored cross rates. The Cross Rate process generates as many rates as possible and skips currencies where one component of the set is missing.

Note

With a defined web service that extracts daily currency conversion rates from external services, for example Reuters, currency conversion rates are automatically updated for the daily rates and all cross currency relationships.

Using Rate Types: Examples

There are four seeded conversion rate types in Oracle Fusion applications:

Scenario

You are the general ledger accountant for InFusion America Inc. You are entering a journal entry to capture three transactions that were transacted in three different foreign currencies:

You enter two lines with accounts and amounts for each foreign currency transaction. Based on your company procedures, you select the appropriate rate type to populate the rate for Corporate and Spot rate types from your daily rates table. You manually enter the current rate for the User rate type.


Currency Selected

Rate Type Selected

Reason

CAD

Corporate

Entered a periodic type of transaction. Your company has established a daily rate to use for the entire month across divisions for all transactions in CAD. CAD is a stable currency that only fluctuations slightly over the month.

MXP

Spot

Entered a periodic type of transaction. Your company enters daily rates each day for MXP because this currency is unstable and fluctuates.

HKD

User

Entered a one time transaction. Your company does not maintain daily rates in HKD.

Note

Your company does not currently use the Fixed rate type. From January 1, 1999, the conversion rate of the French franc (FRF) against the euro currency (EUR) was set at a fixed rate of 1 EUR to 6.55957 FRF. Your French operations were started in 2007, so you maintain all your French business records in the EUR.

FAQs for Manage Conversion Rate Types

What's the difference between spot, corporate, user, and fixed rate types?

Spot, corporate, user, and fixed conversion rate types differ based on the fluctuations of your entered foreign currency and your company procedures for maintaining daily rates.


Rate Type

Usage

Spot

For currencies with fluctuating conversion rates or when exact currency conversion is needed.

Corporate

For establishment of a standard rate across your organization for a stable currency.

User

For infrequent entries where your daily rates for the entered foreign currency are not set up.

Fixed

For rates where the conversion is constant between two currencies.

If you have infrequent foreign currency transactions, the user rate type can simplify your currency maintenance while providing an accurate conversion rate on the date of the transaction.

What's a statistical unit currency type?

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.

Manage Daily Rates

Entering Daily Rates Manually: Worked Example

You are required to enter the daily rates for currency conversion from Great Britain pounds sterling (GBP) to United States dollars (USD) each day for your company InFusion America Inc.

Oracle Application Development Framework (ADF) Desktop Integration is an Excel add-in that must be loaded onto each client. Because ADF Desktop Integration is an add-in to Microsoft Office products, you can use this feature only if they have Microsoft Excel 2007 or above, Internet Explorer 7 or above, and Microsoft Windows 7, XP Professional SP2, or Vista. Users must download the installation files from Navigator - Tools - Download Desktop Integrator Installer.

Entering Daily Rates

  1. Navigate to the Period Close work area.

    Use the Period Close work area to link to close processes and currency process.

  2. Click the Manage Currency Rates link.

    Use the Currency Rates Manager page to create, edit, and review currency rate types, daily rates, and historical rates.

  3. Click the Daily Rates tab.

    Use the Daily Rates tab to review and enter currency rates.

  4. Click the Create in Spreadsheet button.

    Use the Create Daily Rates spreadsheet to enter daily rates in a template that you can save and reuse.

  5. Click in the From Currency field. Select the GBP - Pound Sterling list item.
  6. Click in the To Currency field. Select the USD - US Dollar list item.
  7. Click in the Conversion Rate field. Select the Spot list item
  8. Click in the From Conversion field. Enter the desired information into the From Conversion field. Enter a valid value e.g. "8/1/2011".
  9. Click in the To Conversion Date field. Enter the desired information into the To Conversion Date field. Enter a valid value e.g. "8/1/2011".
  10. Click in the Conversion Rate field. Enter the desired information into the Conversion Rate field. Enter a valid value e.g. "1.33225".
  11. Click the Submit button. Click the OK button twice.
  12. Review the Record Status column to verify that all rows were loaded successfully.
  13. Save the template to use to enter daily rates frequently. You can save the spreadsheet to either a local drive or a shared network drive.

Updating Currency Rates: Worked Example

You are required to change today's daily rates that were already entered. The rates you are changing are for currency conversion from Great Britain pounds sterling (GBP) to United States dollars (USD) for your company InFusion America Inc.

Currency conversion rates were entered by an automatic load to the Daily Rates table. They can also be entered through a spreadsheet.

Updating Currency Rates

  1. Navigate to the Period Close work area.

    Use the Period Close work area to link to close processes and currency process.

  2. Click the Manage Currency Rates link.

    Use the Currency Rates Manager page to create, edit, and review currency rate types, daily rates, and historical rates.

  3. Click the Daily Rates tab.

    Use the Daily Rates tab to review and enter currency rates.

  4. Click the From Currency list. Select the GBP - Pound Sterling list item.
  5. Click the To Currency list. Select the USD - US Dollar list item.
  6. Enter the dates for the daily rates that you are changing. Enter today's date.
  7. Click the Rate Type list. Select the Spot list item.
  8. Click the Search button.
  9. Click in the Rate field. Enter the new rate of 1.7 in the Rate field.
  10. Click in the Inverse Rate field. Enter the new inverse rate of 0.58822 in the Inverse Rate field.
  11. Click the Save button.