Oracle® Fusion Accounting Hub Implementation Guide 11g Release 1 (11.1.1.5.0) Part Number E20374-01

Contents

Previous

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

Manage Chart of Accounts Mapping

Define Trees

Manage DRM Synchronization

Define Calendars

Define Currencies

Manage Conversion Rate Types

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

Accounting Configuration Components

The accounting configuration components are:

• Ledgers: A ledger is the main record-keeping structure. A ledger records transactional balances by defining a chart of accounts with a consistent calendar and currency, and accounting rules, implemented in an accounting method. The ledger is associated with the subledger transactions for the business units that are assigned to it, and provides context and accounting for them.

• Balancing Segments: Oracle Fusion Applications use the chart of account element, balancing segment, to represent and track both legal and management entities. Specifically, Oracle Fusion Applications provide a primary balancing segment to represent your legal entities, and additional balancing segments, you can implement for management reporting and analysis.

  Balancing segments provide automatic balancing functionality by legal entity for journal entries, including intercompany and intracompany entries, suspense posting, and rounding imbalances.

• Cost Centers: Cost Centers aggregate elements of natural expenses to identify functional costs. A cost center can be the smallest segment of an organization for which costs are collected and reported. Not all cost centers represent organizations. A manager is assigned responsibility for cost control and is assigned both a department and a cost center; in which case the cost center and department might be identified with each other. However, a finance department manager might have separate cost centers for finance cost and audit costs, and an Research and Development department manager might have separate cost centers for research and development.

  Cost centers are represented by segment values in the chart of accounts that indicate the functional areas of your business, such as accounting, facilities, shipping, or human resources. You might keep track of functional areas at a detailed level, but produce summary reports that group cost centers into one or more departments. Cost center values are also used by Oracle Fusion Assets to assist the managers in tracking locations and accounting for assets assigned to their departments.

• Accounts: The account segment is a code in the chart of accounts that uniquely identifies each type of transactions recorded in the ledger and subledgers. The account segment is mapped to a dimension in the Essbase cube to enable reporting and inquiry. This functionality uses Oracle Fusion Business Intelligence Edition to analyze and drill into expense and revenue transactions.

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.

• Representing Legal Entities in the Chart of Accounts: Legal entity is the term used in Oracle Fusion Applications for registered companies and other organizations recognized in law as having a legal existence and as parties with given rights and responsibilities.

  Legal entities are created in the applications and then assigned balancing segment values, sometimes called company codes in your ledgers during accounting configuration.

• Representing Business Units in the Chart of Accounts: A business unit (BU) is part of an enterprise managed by a manager with profit and loss responsibility. The business unit is generally tracked in the chart of accounts. A business unit can be represented by a single ledger. For example, in countries where you need document sequencing for unique transaction sequencing within a legal entity, you can have a single ledger with a single business unit and legal entity.

  A business unit can also be identified in the chart of accounts as a:

  • Management segment value

  • Balancing segment value

  • Roll up of cost center segments using hierarchies

  For example, a business unit manager is responsible for working capital utilization or overall asset utilization. You identify the business unit as a balancing segment value, to enable calculation of ratios for various utilization measurements.

  A business unit is assigned to a primary ledger, as well as a default legal entity when it is configured. A BU identifies the primary ledger that subledger transactions are posted to, facilitating the use of more than one BU per general ledger. Each business unit posts transactions to a single primary ledger. For example, a shared service center handles all the procurement functions for the entire company. The procurement transactions are posted to the business unit's ledger with intercompany entries to other ledgers as needed.

• Representing Departments in the Chart of Accounts: A department is an organizational structure with one or more operational objectives or responsibilities that exist independently of its manager and that has one or more employees assigned to it. The manager of a department is typically responsible for business deliverables, personnel resource management, competency management, and occasionally, for cost control and asset tracking.

  In Oracle Fusion Applications, departments can be set up in Oracle Fusion Human Capital Management (HCM). If desired, they can also be represented by a unique segment in the chart of accounts or a group of cost center values.

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.

• Your company is required to report using US Generally Accepted Accounting Principles (GAAP) standards and UK Statements of Standard Accounting Practice and Financial Reporting Standards. How many ledgers do you need to achieve proper statutory reporting?

• Your financial services line of business has a different year end. Do you need a different calendar? Your financial services entity must report with average balance sheets. This feature of Oracle Fusion General Ledger provides you with the ability to track average and end-of-day balances, report average balance sheets, and create custom reports using both standard and average balances.

• Your corporate management requires reports showing total organizational performance with drill down capability to the supporting details. Do you need multiple balancing segment hierarchies to achieve proper rollup of balances for reporting requirements?

• Legal entity balancing options: Do you need to produce financial statements by one or more than one legal entity? Can you record multiple legal entities in one ledger or do you require multiple ledgers? Are you upgrading to Oracle Fusion Applications or a new install? If an upgrade, is your current financial reporting structure meeting your reporting needs?

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:

• Creation of three separate ledgers representing your separate legal entities:

  • InFusion America Inc.

  • InFusion Financial Services Inc.

  • InFusion UK Services Inc.

• Data security is controlled by balancing segment values using Oracle Fusion General Ledger data access sets

Recommendations for the chart of accounts design include:

• Segments required for cost centers with hierarchical rollups to departments providing reporting at both the detail (cost center) and summary (department) level.

• Accounts configured to provide drill down capability to the subledger transactions, enabling analysis of data.

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:

• Effectively manages an organization's financial business

• Supports the audit and control of financial transactions

• Provides flexibility for management reporting and analysis

• Anticipates growth and maintenance needs as organizational changes occur

• Facilitates an efficient data processing flow

• Allows for delegation of responsibility for cost control, profit attainment, and asset utilization

• Measures performance against corporate objectives by your managers

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:

• A general ledger used in conjunction with an enterprise profitability management (EPM) product, which has data standardized from each operation, is designed as a thin general ledger. Use this variation if your solution is project based, and Oracle Fusion Projects is implemented. More detailed reporting can be obtained from the Projects system. In the thin general ledger, business units, divisions, and individual departments are not represented in the chart of accounts.

• A general ledger, with segments representing all aspects and capturing every detail of your business, with frequent posting, many values in each segment, and many segments, is called a thick general ledger. A thick general ledger is designed to serve as a repository of management data for a certain level of management. For example, a subsidiary's general ledger is designed to provide the upper management enough data to supervise operations, such as daily sales, without invoice details or inventory without part number details.

• A primary ledger and a secondary ledger, where one is a thick general ledger and the other a thin general ledger, provides dual representation for reporting requirements that require more than one ledger.

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:

• Minimal chart of accounts

  • Short list of cost centers

  • Short list of natural accounts

    • Short list of cost accounts

    • Summary level asset and liability accounts

  • Low number of optional segments

• Infrequent posting schedule

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:

• Maximum use of the chart of accounts

  • Long list of natural accounts

  • Long list of cost centers

    • Long list of costing accounts

    • Detailed asset and liability accounts

• Frequent posting schedule

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:

• Track entered currency balances at the level of an operational dimension or segment of your chart of accounts, such as by department or cost center

• Generate financial allocations at the level of an operational dimension or segment

• Report using multiple layered and versioned hierarchies of the operational dimension or segment from your general ledger

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

• Minimal disclosure to the authorities in addition to the requirements listed above. For example, in some European countries, fiscal authorities examine ledgers at the detailed account level.

• Fiscal only adjustments, allocations, and revaluations, which don't impact the thick general ledger.

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:

• Storage and maintenance needed for both the general ledger and subledger accounting entries

• System resources required to perform additional posting

• In summary, you have:

  • Minimum demand on storage, maintenance, and system resources with the use of a thin ledger

  • Greater demand on storage, maintenance, and system resources with the use of a thick ledger

  • Greatest demand on storage, maintenance and system resources with the use of both thick and thin ledgers

  Note

  Generally speaking, there is a tradeoff between the volume of journals and balances created and maintained versus system resource demands. Actual performance depends on a wide range of factors including hardware and network considerations, transaction volume, and data retention policies.

Summary

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

• Downstream EPM system and its capabilities

• Business intelligence system and its capabilities

• Subledger systems and their capabilities and characteristics, including heterogeneity

• General ledger reporting systems and their capabilities

• Maintenance required for the thick or thin distributions and record keeping

• Maintenance required to update value sets for the chart of accounts segments

• Preferences of the product that serves as a source of truth

• Level at which to report profitability including gross margin analysis

• Industry and business complexity

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.

Chart of Account

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.

• Balancing: Ensures that all journals balance for each balancing segment value or combination of multiple balancing segment values to use in trial balance reporting. There are three balancing segment labels: primary, second, and third balancing. The primary balancing segment label is required.

• Cost Center: 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 you are accounting for depreciation, additions, and other transactions in Oracle Fusion Assets, and for storing expense approval limits in Oracle Fusion Expense Management.

• Natural Account: Determines the account type (asset, liability, expense, revenue, or equity) and other information specific to the segment value. The natural account segment label is required.

• Management: Optionally, denotes the segment that has management responsibility, such as the department, cost center, or line of business. Also can be attached to the same segment as one of the balancing segments to make legal entity reporting more granular.

• Intercompany: Optionally, assigns the segment to be used in intercompany balancing functionality.

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.

• Security rules: Prohibit certain users from accessing specific segment values. For example, you can create a security rule that grants a user access only to his or her department.

• Cross-validation rules: Control the account combinations that can be created during data entry. For example, you may decide that sales cost centers 600 to 699 should enter amounts only to product sales accounts 4000 to 4999.

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

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 account 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:

• Processes performed

• Implementation timing

• Change options

• Migration adjustments

Processes Performed

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 processes are performed using the multiple balancing segment functionality:

• Intercompany balancing: Adds lines to unbalanced journals using intercompany rules.

• Opening first period of the new accounting year: Calculates retained earnings amounts at the level of granularity that totals revenue and expense account balances for multiple balancing segment value combinations. This applies to standard and average balances.

• Importing journals: Adds lines using the suspense account on unbalanced journals.

• Posting journals: Adds additional lines to unbalanced journals for the following enabled account types:

  • Suspense

  • Rounding imbalance

  • Net income

  • Retained earnings

  • Cumulative translation adjustments from replication of revaluation journals to reporting currencies and for multiple reporting currency account type specific conversion

• Posting prior period journals: Calculates any income statement impact and posts to the appropriate retained earnings account.

• Translating balances: Supports multiple balancing segments for the following accounts:

  • Retained earnings: Calculated translated retained earnings are post to the retained earnings accounts by balancing segment. Retained earnings represents the summing of the translated revenue and expense accounts across multiple balancing segment values.

  • Cumulative translation adjustment: Amounts posted by balancing segment to these accounts represents currency fluctuation differences between ranges of accounts which use different rate types. For example, period end rates are used for asset and liability accounts and historical rates for equity accounts.

• Revaluing Balances: Supports multiple balancing segments when calculating gain or loss accounts.

• Creating Opening Balances: Initializes reporting currency balances by converting from the total primary currency. Any difference in the reporting currency amounts is offset by populating retained earnings accounts.

• Closing year end: Supports multiple balancing segments when calculating the income statement offset and closing account in the closing journals.

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.

Example

A simple example follows to illustrate balancing along two balancing segments for a simple chart of accounts with three segments, qualified as follows:

• Company: Primary balancing segment

• Cost Center: Second balancing segment

• Account: Natural account segment

The following multiple company and cost center journal shows transferring of advertising and phone expense from Company 1, Cost Center A to Company 2, Cost Center B. 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.

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.

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 and care needs to be taken

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.

• Intercompany balancing

• Suspense posting

• Rounding imbalance adjustments on posting

• Entered currency balancing

• Revaluation gains or losses

• Retained earnings calculations at the opening of each new fiscal year

• Cumulative translation adjustments during translation

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

• Departments

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:

• Assign a cost center value in the value set for each cost center. For example, assign cost center values of PL04 and G3J1 to your manufacturing teams in the US and India. These unique cost center values allow easy aggregation of cost centers in hierarchies (trees) even if the cost centers are in different ledgers. However, this approach will require defining more cost center values.

• Assign a balancing segment value with a standardized cost center value to create a combination of segment values to represent the cost center. For example, assign the balancing segment values of 001 and 013 with cost center PL04 to represent your manufacturing teams in the US and India. This creates 001-PL04 and 013-PL04 as the cost center reporting values.

  The cost center value of PL04 has a consistent meaning. This method requires fewer cost center values to be defined. However, it prevents construction of cost center hierarchies using trees where only cost center values are used to report results for a single legal entity. You must specify a balancing segment value in combination with the cost center values to report on a single legal entity.

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:

• Controlling costs within their budget

• Tracking assets used by their department

• Managing employees, their assignments, and compensation

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

Defining value sets involves making decisions about the following.

• Validation

• Security

• Precision and scale

• Usage and deployment

Validation

The following types of validation are available for value sets.

• Format only, where end users enter data rather than selecting values from a list

• Independent, a list of values consisting of valid values you specify

• Dependent, a list of values where a valid value derives from the independent value of another segment

• Subset, where the list of values is a subset of the values in an existing independent value set

• Table, where the values derive from a column in an application table and the list of values is limited by a WHERE clause

A segment that uses a format only value set does not present a list of valid values to users.

You can build a tree structure from the values in an independent value set whose data type is character.

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.

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

• Validation Type

• Format Assignments

• Security Rules

• Values Definition

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:

• Independent: The values are independently selected when filling out the segment in the account combination.

• Table Validated: The values are stored in an external table to facilitate maintenance and sharing of the reference data.

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.

• Set the values to conform to the value set length and type.

• Enter the value, its description, and its attributes including the Enable check box, Start Date, and End Date.

• Assign the following attributes: Parent or Summary check box, Posting is allowed, and Budgeting is allowed.

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 programs 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:

• Primary Balancing Segment: Main balancing segment typically used to represent the company dimension of the organization. The segment set with this label cannot be set with another label.

• Cost Center Segment: Subunits of the company, such as cost or profit centers, or departments. You are required to create this segment if you are implementing Oracle Fusion Assets.

• Natural Account Segment: Classification of transactions and balances according to distinct account types: asset, liability, equity, revenue, and expense accounts. The segment set with this label cannot be set with another label.

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

• Second Balancing Segment: Used to balance transactions, as needed, by an additional dimension beyond the primary balancing segment.

• Third Balancing Segment: Used to balance transactions, as needed, by an additional dimension beyond the primary and second balancing segments.

• Management Segment: Used in a future release. For Oracle Fusion Version 1, do not enable this qualifier.

• Intercompany Segment: Used to track intercompany due to and due from balances by identifying the specific trading company. The intercompany qualified segment cannot be set with any of the three balancing segment qualifiers. The values in this segment's value set need to be the same as the primary balancing 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.

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.

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.

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.

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.

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.

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.

• Flexfield metadata in the Oracle Fusion Applications database

• Flexfield business components in a sandbox Metadata Services (MDS) repository

• User interface customizations for the flexfield in the mainline MDS repository

The figure shows the two types of deployment available in the Manage Flexfield tasks of the Define Flexfields activity. Deploying a flexfield to a sandbox creates a sandbox MDS repository for the sole purpose of testing flexfield behavior. The sandbox is only accessible to the administrator who activates and accesses it, not to users generally. Deploying a flexfield to the mainline applies the flexfield definition to the mainline MDS repository where it is available to end users. After deploying the flexfield to the mainline, customize the page where the flexfield segments appear. Customization of the page in the sandbox MDS repository cannot be published to the mainline MDS repository.

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.

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.

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.

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.

deployFlexForApp

deployFlex

deployPatchedFlex

Executing these commands outputs a report at the command line. The report provides the following information for every flexfield that is processed.

• Application identity (APPID)

• Flexfield code

• Deployment result, such as success or error

In case of errors, the report lists the usages for which the errors were encountered. If a runtime exception occurs, the output displays the traceback information.

Consider the following aspects of command line deployment.

• Preparing to use the WLST flexfield commands

• Using the deployFlexForApp command

• Using the deployFlex command

• Using the deployPatchedFlex command

• Exiting the WLST and checking the results

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.

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

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.

deployPatchedFlex()

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 your users can create dynamically as they 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.

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.

Manage Chart of Accounts Mapping

FAQ for Manage Chart of Accounts Mapping

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

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 program 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 programs for balance level secondary ledgers as well as cross ledger transfers, whereby balances from one ledger are copied to another ledger.

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:

• Assign a constant value for a segment in the target chart of accounts

• Copy the value from the source segment to the corresponding target segment

  Note

  To use this action, the paired target and source segments must share identical values in their value sets.

• Use roll up rules to aggregate source accounts to a corresponding target segment or account

  • Create a single value mapping when a specific detail source segment value is given a detail target segment value.

  • Use hierarchical roll up rules when a specific parent source value and all of its child segment values, are mapped to a given detail target segment value. This provides the ability to process groups of source segment values in one single roll up rule.

  • Define parent source values in roll up rules when date effective versions of the hierarchy are used with the accounting date of the transactions produced by the programs that reference the chart of accounts mapping. This gives the additional benefit of self maintaining mappings since the hierarchies referenced change with time, and the applicable child values are processed automatically.

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:

• Single detail account values

• Detail account value ranges

• Parent values for each segment

  Note

  When using parent values, its child values for the date effective version of the hierarchy, are processed when the mapping is called.

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.

• Open: Indicates that the tree is associated with all reference data sets.

• Set ID: Indicates that the tree will be associated with a specific reference data set.

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.

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.

Auditing

Whenever a tree structure is set to active, the application automatically triggers an audit of that tree structure. Running an audit verifies the tree structure, checks for data integrity, and allows you to view audit details and messages and correct validation errors, if any.

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.

• Allow Ragged Nodes: To include nodes that have no child nodes, and are shorter than the remaining nodes in the entire hierarchy.

• Allow Skip Level Nodes: To include nodes that are at the same level but have parent nodes at different levels.

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.

• Date Range: Specifies whether a selection of nodes should be restricted to the same date range as the tree version.

• Allow Multiple Root Nodes: Allows you to add multiple root nodes when creating a tree version.

• Reference Data Set: Specifies whether a selection of nodes should be restricted to the same set as the tree.

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.

The data source parameters are applied to any tree version belonging to that data source, when performing node operations on the tree nodes. Data source parameters also provide an additional level of filtering for different tree structures. The tree structure definition supports three data source parameter types.

• Bound Value: Captures any fixed value, which is used as part of the view criteria condition.

• Variable: Captures and binds a dynamic value that is being used by the data source view object. This value is used by the WHERE condition of the data flow.

• View Criteria: Captures the view criteria name, which is applied to the data source view object.

You can also specify which of the data source parameters are mandatory while creating or editing the tree structure.

View objects from the ADF business components are used as data sources. To associate the view object with the tree structure, you can pick the code from ADF business component view objects and provide the fully qualified name of the view object, for example, oracle.apps.fnd.applcore.trees.model.view.FndLabelVO.

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

• Column Flattening

• Column Flattened Entity Objects

• ADF Business Component View Objects

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.

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.

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.

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.

• Single: Indicates that the node is a value by itself.

• Range: Indicates that the node represents a range of values and possibly could have many children. For example, a tree node representing account numbers 10000 to 99999.

• Referenced Tree: Indicates that the tree node is actually another version for the tree based on the same tree structure, which is not physically stored in the same tree. For example, a geographic hierarchy for the United States can be referenced in a World geographic hierarchy.

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.

• Start Date

• Period Frequency

• Adjusting Period Frequency

• Period Name Format

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.

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.

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.

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. The Add Year button automatically adds the rows for the new year. These new rows can be accepted or changed. For example, with the Other frequency type calendar, dates may differ from what the application generated and need to be changed.

Define Currencies

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.

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:

• Convert foreign currency journal amounts to ledger currency equivalents

• Convert journal amounts from source ledgers to reporting currencies or secondary ledgers

• Run Revaluation or Translation processes

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

• Enforce inverse relationships

• Select pivot currencies

• Select contra currencies

• Enable cross rates and allow cross rate overrides

• Maintain cross rate rules

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.

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 program 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 program generates as many rates as possible and skips currencies where one component of the set is missing.

Using Rate Types: Examples

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

• Spot

• Corporate

• User

• Fixed

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:

• Canadian dollar (CAD): A very stable currency

• Mexican Peso (MXP): A fluctuating currency

• Hong Kong dollar (HKD): An infrequently used currency

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.

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.

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.

Previous Next

Copyright ©  2011, Oracle and/or its affiliates. All rights reserved. Legal Notices

Contents Contact Us