6Financial Structures

This chapter contains the following:

Define Rapid Implementation

You can use the Rapid Implementation for General Ledger workbook template to rapidly implement the following common setup objects for enterprise structures:

  • Chart of accounts, including value sets, value set values, structures, and structure instances

  • Account hierarchies, represented in the application through trees and tree versions

  • Accounting calendars (monthly type only)

  • Legal entities

  • Primary ledgers with legal entity assignments to primary balancing segment values

  • Business units

  • Rules of generating sequential IDs for transactions recorded in the application

  • Select setup objects along with their accounting specifications, for various Financial applications

Completion of the rapid implementation enterprise structure setup also automatically generates sample financial reports and account groups based on your enterprise structure. Account groups are used in reporting dashboards such as the Revenues and Expenses infolets, and the Close Monitor.

Plan your implementation carefully, considering the following requirements.

  • Determine your chart of accounts segments.

  • Create your segment values and hierarchies data in the specified format.

  • Identify your legal entities, addresses, and business units.

  • Determine the key accounts for tracking accounting activities, for example, retained earnings, cash, accounts receivable, accounts payable, and top revenue and expenses parent accounts.

  • Determine your calendar start date and its periodic pattern.

  • Finalize your primary balancing segment value, legal entity, and business unit relationships.

  • Determine your document and journal sequencing requirements.

In the Setup and Maintenance work area, create an implementation project that includes the Define Financials Configuration for Rapid Implementation task list. Download the workbook using the Create Chart of Accounts, Ledger, Legal Entities, and Business Units in Spreadsheet task.

Caution: The rapid implementation enterprise structure configuration is meant to be used for a one-time initialization. To the extent that you want to make certain allowed modifications to the configuration, you generally have to make those changes directly in the application. After initial upload of the ledger, legal entity, and business unit file, the fundamental accounting configuration framework is only created once and is permanently set. The framework includes the ledger and its assigned chart of accounts, calendar and currency assignment, and the associated definitions of those components.

Represent your enterprise structures in your chart of accounts, ledger, legal entities, and business unit configuration to track and report on financial objectives and meet reporting requirements. These components provide the underlying structure for organizing financial information and reporting.

The chart of accounts within the ledger facilitates:

  • Aggregating data from different operations, from within an operation, and from different business flows

  • Consistent definitions to your stakeholders in compliance with legislative and corporate reporting standards and aids in management decisions

Rapid implementation is a way to configure a financial enterprise and financial reporting structures quickly using sheets in a workbook that upload lists of:

  • Companies (legal entities)

  • Ledgers by country

  • Business units

  • Chart of accounts and segment values

  • Segment value hierarchies

  • Financial sequences

  • Required subledger accounts

Once the sheets have been uploaded, the application creates:

  • Chart of accounts structure and instance

  • Segment value hierarchies

  • Key accounts such as retained earnings

  • Required subledger accounts

  • Accounting calendar

  • Primary ledger for each country represented on the legal entities sheet

  • Legal entities and their locations

  • Business units

  • Document and journal sequencing

  • Set of Financial Reporting reports

  • Three account groups

Caution: Once you begin using your chart of accounts, calendar, and ledger, making changes to their fundamental attributes is neither recommended nor supported. This includes your chart of account segments, including the segment labels as well as other characteristics of those segments, and your calendar structure or pattern.

The following figure illustrates the flow of the enterprise structure setup.

Legal entities (companies) incur transactions that are identified by business units with business functions. Transactions that are recorded in subledgers are transferred to the ledger. A ledger is characterized by a calendar, a currency, and a chart of accounts. A chart of accounts consists of segments, some of which are assigned segment labels, such as cost center, natural account, and primary balancing segment. Legal entities can be assigned primary balancing segment values.

This figure shows the flow of the enterprise structure
setup from the legal entities to the ledger.

Additional information for some of the common setup objects depicted in the figure follows:

  • Legal Entity: Identifies a recognized party with rights and responsibilities given by legislation, which has the right to own property and the responsibility to account for itself.

  • Business Units: Performs one or many business functions that can be rolled up in a management hierarchy. A business unit can process transactions on behalf of many legal entities. Usually a business unit has a manager, strategic objectives, a level of autonomy, and responsibility for its profit and loss. When created through the spreadsheet, all available business functions are automatically enabled for the business unit.

  • Ledger: Maintains records and is a required component in your configuration. The rapid implementation process:

    • Creates primary ledgers by combining the chart of accounts, calendar, and currency as well as other required options defined in the rapid implementation workbook.

    • Assigns the standard accrual subledger accounting method to the primary ledger. The subledger accounting method is used to group subledger journal entry rule sets together to define a consistent accounting treatment.

    • Creates a General Ledger balances cube for each ledger with a unique chart of accounts and calendar combination. Each segment is created as a dimension in the balances cube along with the standard cube dimensions.

  • Subledger: Captures detailed transactional information, such as supplier invoices, customer payments, and asset acquisitions. Uses subledger accounting to transfer transactional balances to the ledger where they are posted.

  • Chart of Accounts: Configures accounts that consist of components called segments. Accounts are used to record balances and organize financial information and reporting.

  • Segment: Identifies one of the components of a chart of accounts, which when combined with other segments, creates an account combination for recording transactions and journal entries. A segment is associated with a value set, which provides the set of values for that segment, along with the formatting and validation for those values.

  • Segment Label: Identifies certain segments in a chart of accounts and assigns special functionality to those segments.

    • Balancing Segment: Ensures that all journals balance for each balancing segment value or combination of multiple balancing segment values for financial processes and reports. The three balancing segment labels are: Primary Balancing Segment, Second Balancing Segment, and Third Balancing Segment.

    • Natural Account: Determines the account type (asset, liability, expense, revenue, or equity) and specific categorization of the financial activity. Facilitates General Ledger processes, such as closing of the income statement accounts to retained earnings at the beginning of a new fiscal year.

    • Cost Center: Facilitates grouping of natural accounts by functional cost types, accommodating tracking of specific business expenses across natural accounts.

With the rapid implementation workbook you can also:

  • Create more than one hierarchy for any of your chart of accounts segments during initial setup. You can also create additional hierarchies and hierarchy versions, as well as update existing hierarchy versions, after the initial setup is done by uploading the rapid implementation spreadsheet data.

  • Create sequences for each legal entity or ledger based on the predefined country defaults. Document sequences are created for: Payables invoices, Payments, Receivables invoices, Receivables credit memos, Receivables adjustment activities. Reporting and accounting journal sequences are created for subledger journals and General Ledger journals.

The rapid implementation process for setting up the enterprise structure includes the following steps:

  1. Downloading the Rapid Implementation for General Ledger workbook.

  2. Entering data into the sheets.

  3. Verifying the entered data and resolving any errors.

  4. Uploading the chart of accounts file.

  5. After successful upload of the chart of accounts file, uploading the general ledger, legal entity, and business unit file with the rest of the configuration.

The rapid implementation enterprise structure configuration is meant to be used as a one-time initialization. To the extent that you want to make certain allowed modifications to the configuration, you generally have to make those changes directly in the applications. After initial upload of the ledger, legal entity, and business unit file, the fundamental accounting configuration framework is only created once and is permanently set. This framework includes the ledger and its assigned chart of accounts, calendar and currency assignment, and the associated definitions of those components.

Workbook Overview

In the Setup and Maintenance work area, create an implementation project that includes the Define Financials Configuration for Rapid Implementation task list. Download the workbook using the Create Chart of Accounts, Ledger, Legal Entities, and Business Units in Spreadsheet task.

The workbook includes the following sheets:

  • Instructions

  • Chart of Accounts, Calendar, and Ledger

  • Business Units

  • Companies and Legal Entities

  • Natural Accounts

  • Financial Sequences

New sheets for entering segment values and hierarchies for additional segments of your chart of accounts can be created automatically. After you enter the segments on the Chart of Accounts, Calendar, and Ledger sheet, click Add Segment Sheets or Generate Additional Hierarchy.

Note: The rapid implementation process creates a standard ledger. You can convert a standard ledger to an average daily balance ledger before the first period is opened by selecting the Enable average balances check box on the Specify Ledger Options page.

Instructions

Review the Instructions sheet for important information about how to use the workbook and submit the accounting configuration. The sheet includes data preparation requirements, setup object concepts, and best practices and recommendations. Instructions on how to create additional hierarchies or additional hierarchy versions are also included.

Use the sample completed workbook to familiarize yourself with how to enter data, preview the sample report, and generate the required upload files.

The following figure shows the section of the Instructions sheet called Rapid Implementation Template with Sample Data. This section includes the sample completed workbook, which you can download.

This figure shows the sample data template on the
Instructions sheet.

Chart of Accounts, Calendar, and Ledger

Enter the data to create your chart of accounts, calendar, and ledger.

Caution: Once you begin using your chart of accounts, calendar, and ledger, making changes to their fundamental attributes is neither recommended nor supported. This includes your chart of account segments, including the segment labels as well as other characteristics of those segments, and your calendar structure or pattern.

The following figure shows an example of the Chart of Accounts, Calendar and Ledger sheet with sample values.

This figure shows the Chart of Accounts, Calendar
and Ledger sheet populated with values to create a ledger with its
three basic components: chart of accounts, calendar, and currency.

An explanation of each field on the sheet follows.

  • Name: Enter the name of your primary ledger.

    A primary ledger is created for each unique country that's entered in the Companies and Legal Entities sheet. A country code is appended to the name that you specify. For example, one legal entity is based in the United States and another in Canada. If you enter the ledger name of InFusion Ledger, two primary ledgers are automatically created, InFusion Ledger US and InFusion Ledger CA.

    All of the primary ledgers that are created use the same chart of accounts, account hierarchies, and accounting calendar. Legal entities and their primary balancing segment values are assigned to the primary ledger of their respective countries. If the addresses provided for the legal entities on the Companies and Legal Entities sheet are all in the same country, then only one primary ledger is created.

  • Currency: If you're not entering legal entities and only a single ledger should be created by the rapid implementation configuration, enter the ledger currency in which you want to maintain accounting for in that ledger. If you're entering legal entities, leave this field blank. The currency is automatically supplied based on the country.

  • Period Frequency: Select from among the list of available frequencies for the ledger calendar.

    Caution: For the accounting calendar created using the Rapid Implementation Enterprise Structure solution, the choices of patterns are limited to the period frequency and adjusting periods options that are available for selection in the spreadsheet. It is not possible to make alterations to the pattern or specified fiscal year start date once the calendar has already been created.

    The accounting periods of the calendar are automatically named using a preset format. If you want to change these period names, you have a limited window of time to make those changes. Use the Manage Accounting Calendar page in the application to make the changes before the accounting calendar is being used actively, such as when one of its accounting periods has been set to a status of Open.

  • Adjusting Periods: Select the number of periods used to segregate closing, auditing, or other adjustments in the General Ledger. The entries are tracked in the adjusting period and not in your monthly activity.

  • Fiscal Year Start Date: Enter the start date of the accounting calendar. The date can't be changed after the submission of the configuration.

    Caution: If you plan to run translations, enter a fiscal year start date for the entire accounting year that's before the first period for which you intend to run translations. You can't run translation in the first defined period of an accounting calendar. For example, if your fiscal year starts on January 1, and you want to start translations for the period of Mar-17, then you should select a fiscal year start date of January 1, 2016.

    Also when determining the fiscal year start date, you might want to consider whether you plan to load history.

  • Segment: Enter the names for your segments. The value sets are created from the segments.

  • Segment Label: Select segment labels to assign special functionality to segments.

    Segment labels specifying the segment's purpose, such as balancing, cost center and natural account, can only be assigned once to a chart of accounts segment. The Primary Balancing Segment and Natural Account Segment labels must be assigned, while the other segment labels are optional. Segments that are assigned these two particular labels cannot be assigned any other label. However, segments that are assigned the other remaining labels can also be assigned additional labels, provided they're not Primary Balancing Segment or Natural Account Segment.

    The Intercompany Segment label assignment is optional. If assigned, that segment reuses the value set that's created for the segment with the Primary Balancing Segment label. Using the same value set ensures that the values for both segments remain synchronized.

    Note: For the posting process to apply intercompany balancing, you must select the Enable intercompany accounting option on the Specify Ledger Options page.
    Caution: If you plan to implement segment value security rules for the segment that's assigned the Primary Balancing Segment label, then don't assign the Intercompany Segment label to a segment on this sheet. Segment value security rules are assigned at the value set level. Sharing the value set between the two segments causes security conflicts because segment value enforcement is simultaneously applied in the same way to both segments. For example, you define a segment value security rule for the Company segment where a user can only access company 01. Since the value set is shared, that user also can't transact with other companies in an intercompany transaction.

    Instead, follow these steps:

    1. Include the intercompany segment in the sheet, but don't assign it the Intercompany Segment label.

    2. Click the Add Segment Sheets button to add a sheet for the intercompany value set.

    3. Create the values for your intended intercompany segment on the new sheet. Assign the same values to the intercompany segment as you have for the primary balancing segment and maintain this consistency going forward.

    4. Complete the Upload Chart of Accounts task. Before starting the Upload Ledger, Legal Entities, and Business Units task, in the Offerings work area, go to the following:

      • Offering: Financials

      • Functional Area: Financial Reporting Structures

      • Task: Manage Chart of Accounts Structures

    5. Assign the Intercompany Segment label to the intercompany segment of the chart of accounts on the Edit Key Flexfield Segment page.

    6. Redeploy the key flexfield.

  • Short Prompt: Enter a short name for the segment, which is used on applications pages.

  • Display Width: Enter the segment size. Select the size carefully and leave room for growth. For example, if you have 89 cost centers, enter 3 for the display length to allow for more than 100 cost centers in the future.

  • Add Segment Sheets: Select this button to create sheets for additional segments. Sheets are provided only for the Company and Natural Accounts segments.

    From the new segment sheet, you can click the Generate Additional Hierarchy button to create more than one hierarchy for any chart of account segment. A worksheet is then automatically created and populated with the data already entered for that segment. Change this data as required for the new hierarchy. You can create additional hierarchies during initial setup, or after the initial setup is done.

Caution: You can't change the chart of accounts, accounting calendar, or currency for your ledgers after the setup is created.

Business Units

Enter the name of your business units and related default legal entities.

The following figure shows an example of the Business Units sheet with sample values for the Name and Default Legal Entity Name fields.

This figure shows the Business Units sheet.

Business units are created with the names that you enter. You can enter more than one business unit per ledger. Based on the default legal entity specified for the business unit in the Business Units sheet, the business unit is assigned the primary ledger to which its default legal entity is assigned.

Companies and Legal Entities

Enter parent and child values for your Company segment, which is the segment that's assigned the Primary Balancing Segment label on the Chart of Accounts, Calendar, and Ledger sheet. You can create up to nine levels of parent values to roll up your companies to meet corporate and local reporting requirements.

Enter your legal entities for the child values with the address, registration number, and reporting unit registration number. The registration number identifies legal entities registered for your company and recognized by law for which you want to record and perform transactions. The reporting unit registration number identifies the lowest level component of a legal structure that requires registrations.

The following figure shows part of the Companies and Legal Entities sheet with sample values. The sheet includes columns for different levels of parent values, the child value, and company description. The Legal Entity columns include name, identifier, country, address information, and registration numbers.

This figure shows the Companies and Legal Entities
sheet populated with the companies and their addresses and registration
numbers.

To create additional hierarchies for the company segment for reporting or other purposes, click the Generate Additional Hierarchy button. A worksheet is automatically created and populated with the data already entered for that segment. Change this data as required for the new hierarchy. You can create additional hierarchies during initial setup, or after the initial setup is done.

When a new hierarchy sheet is created, the name for that sheet is derived by adding a counter to the sheet name. For example, when you click Generate Additional Hierarchy on the Companies and Legal Entities sheet, the new sheet is named Companies and Legal Entities 1. When you click Generate Additional Hierarchy again, another sheet is generated with the name Companies and Legal Entities 2.

Note: Adding legal entity information isn't supported on a new hierarchy sheet for the Company segment.

Natural Accounts

Enter account hierarchies, account values, and specify account types.

The following figure shows part of the Natural Accounts sheet with sample parent and child values, descriptions, and account type.

This figure shows the Natural Accounts Sheet with
values, account type, and financial category.
  • Parent: Enter parent account values to define hierarchies. Hierarchies are used for chart of accounts mappings, revaluations, data access sets, cross-validation rules, and segment value security rules. The balances cube and account hierarchies are also used for financial reporting, Smart View queries, and allocations.

  • Child: Enter child account values to define the postable accounts.

  • Description: Enter descriptions for the segment values.

  • Account Type: You must assign an account type to each account value. Account types are used in year-end close processes and to correctly categorize account balances for reporting. Select from among general account types and expanded account types. The general account types are: Asset, Liability, Owner's Equity, Revenue, Expense. Expanded account types provide specialized functionality and are used to:

    • Identify the intended usage of your natural account values to facilitate automation and enable completion of other required setup objects. For example, assign the Asset - Intercompany Receivable and Liability - Intercompany Payable expanded account types. The Rapid Implementation process then automatically creates a chart of accounts level intercompany balancing rule, which is a required setup for the application to perform intercompany balancing.

    • Automatically generate fully defined initial Financial Reporting reports and Account Groups based on your enterprise structure.

    Examples of expanded account types include:

    • Asset - Accounts Receivable: For Receivables receipt methods

    • Liability - Accounts Payable: For Payables common options

    • Owner's Equity - Retained Earnings: For General Ledger ledger options

    • Revenue - Top Revenues Parent Account: For sample reports and account groups

    • Expense - Top Operating Expenses Parent Account: For sample reports and account groups

    You must assign the Revenue - Top Revenues Parent Account and Expense - Top Operating Expenses Account account types to the parent accounts that are your highest level and comprehensive revenue and operating expenses accounts. You can optionally assign the account type of Expense - Top Cost of Sales Parent Account, if it's applicable for your scenario.

    The Generate Financial Reports and Account Groups process, which is automatically submitted when the accounting configuration is created in the application, generates a set of Financial Reporting reports and account groups according to the accounting configuration defined in the workbook. The top parent accounts are used as the basis for deriving the accounts referenced in the reports and in the Account Groups.

    The immediate descendants of the top parent accounts are used to define the rows on the reports. Depending on whether both the top operating expense and top cost of sales accounts are tagged, different variations of the income statements are generated. If the optional top cost of sales account is provided, the Financial Reporting reports that are income statements also include a gross margin section.

    Caution: Assign account types carefully. If you assign an incorrect account type to a natural account segment value, accounting entries are recorded incorrectly and financial statements are inaccurate. Misclassified accounts are also potentially handled incorrectly at year end, with actual balances either getting zeroed out to retained earnings, or accumulating into the next year.
  • Financial Category: Select a value to identify groups of accounts for reporting with Oracle Transactional Business Intelligence. Accounts that are tagged with expanded account types are automatically assigned a financial category. You can override the default category or leave it out.

  • Generate Additional Hierarchy: To create additional hierarchies for the natural account segment for reporting or for other purposes, click the Generate Additional Hierarchy button. A worksheet is automatically created and populated with the data already entered for that segment. Change this data as required for the new hierarchy. You can create additional hierarchies during initial setup or after the initial setup is done.

Financial Sequences

Enable document or journal sequences to assign unique numbers to transactions to meet legal requirements.

The following figure shows the Financial Sequences sheet with sample values for the Restart and Initial Value columns.

This figure shows the Financials Sequences sheet
where you set restart and initial values for financial document and
journal sequences.

Document sequences are created for these transactions: Payables invoices, Payments, Receivables invoices, Receivables credit memos, Receivables adjustment activities. Reporting and accounting journal sequences are created for Subledger journals and General Ledger journals.

For each transaction, you can provide values for the following fields:

  • Restart: Set when to restart the numbering: Annually, Monthly, Never.

  • Initial Value: Specify the beginning number in the sequence.

How The Worksheets Are Processed

After you complete the worksheets, proceed with validation, sample report preview, and file upload.

  1. On the Chart of Accounts, Calendar, and Ledger sheet, click the Step 1: Validate button.

    The validation checks the worksheets for missing or inappropriate setups. Errors are marked as actionable items in a validation report sheet that's dynamically generated. You can review the anomalies and make the corrections as indicated. The Field column on the validation report notes the issue. Click the text link to navigate to the appropriate field in the sheet that must be updated. When the validation is successful, a message appears with the option of previewing a sample of the reports that are automatically generated as part of the enterprise configuration.

    The following figure shows the message that appears after a successful validation.

    This figure shows the message for a successful
validation with the option to provide preview sample reports.

    If you select to preview the sample report, a new sheet is automatically created called Preview Report. The preview incorporates elements of the setup that you provided. The rows on the report are derived based on the top parent revenue and expense account values that you tagged on the Natural Accounts sheet. The preview also reflects the reporting hierarchy for your natural accounts.

    The following figure shows an example of the sample Financial Reporting report.

    This figure shows a sample rolling quarterly income
statement that appears when you accept the option to preview the sample
report. The report has four columns with quarterly amounts, followed
by a column with totals. The rows on the report list the revenue accounts
followed by a row for total revenues. The account for the cost of
goods sold follows, with a subsequent calculation of gross margin.
The next rows list the operating expense accounts, followed by a total.
The last row contains the net income. The next section on the report
is a graphical representation of the quarterly trends for Total Revenues,
Total Cost of Sales, Gross Margin, Total Operating Expenses and Net
Income.

    You can use the preview to validate whether the hierarchy setup aligns to your reporting needs. If the natural account hierarchy requires adjustments, this is your chance to make those corrections before actually creating the account hierarchies in the application. You can modify your enterprise structure setup, validate the spreadsheet, and preview the revised sample reports for as many times as you need. The account hierarchies are created when you finally submit the accounting configuration in the rapid implementation spreadsheet.

  2. Click Step 2: Generate Chart of Accounts File. The process generates a data file called ChartOfAccounts.xml with the entered chart of accounts and hierarchies setup data. Save the file to a network or local drive.

  3. Click Step 3: Generate Ledger, LE, and BU File. The process generates a data file called FinancialsCommonEntities.xml with the entered ledger, legal entities, and business unit setup data. Save the file to a network or local drive.

  4. From your implementation project, go to the Upload Chart of Accounts task. The Upload Enterprise Structures and Hierarchies process is launched.

  5. Accept the default selection of the Upload Enterprise Structure option.

  6. Click Browse and select the first file that you saved called ChartOfAccounts.xml.

  7. Click Submit.

  8. Verify that the process completed without errors or warnings.

  9. From your implementation project, go to the Upload Ledger, Legal Entities, and Business Units task. The Upload Enterprise Structures and Hierarchies process is launched.

  10. Accept the default selection of the Upload Enterprise Structure option.

  11. Click Browse and select the second file that you saved called FinancialsCommonEntities.xml.

  12. Click Submit.

  13. Verify that the process completed without errors or warnings.

An individual set of the following Financial Reporting reports is generated for each ledger that's defined within the rapid implementation accounting configuration. If multiple primary ledgers are created as part of your configuration, a set of Financial Reporting reports is generated for each ledger.

  • Income Statement

  • Consolidated Income Statement

  • Rolling Quarterly Income Statement

  • Rolling Monthly Income Statement

  • Trial Balances by Ledger Currency

  • Trial Balances by Entered Currency

The process also generates three account groups. These include two for the infolets, Revenues and Expenses, and one for the Close Monitor called Close Monitor Summary Income Statement. A set of these three account groups is generated for the balances cube, to be shared among all the ledgers that are part of that balances cube.

Additional Hierarchies After Initial Setup

To create additional hierarchies and hierarchy versions, or to update existing hierarchy versions after the initial setup:

  1. Click the Generate Additional Hierarchy button on the applicable segment sheet. A new worksheet is automatically created and populated with the data already entered for that segment. Change the data as required.

  2. Click the Generate File for This Hierarchy Only button. This generates a .zip file for the particular hierarchy.

  3. From your implementation project, go to the Upload Chart of Accounts task. The Upload Enterprise Structures and Hierarchies process is launched.

  4. Select the Upload Hierarchy option.

  5. Select from among the following options and provide values for the required parameters:

    1. Create hierarchy: Select to create another account hierarchy. Specify the value set, tree code, and start date.

    2. Create version: Select to render a new version of an existing account hierarchy. Specify a value set, tree code, tree version, and start date.

    3. Update existing version: Select to edit an existing version of an account hierarchy. Specify a value set, tree code, and tree version.

  6. Click Choose File and select the .zip file that you saved earlier.

  7. Click Submit.

Correcting Misclassified Accounts: Explained

When you create a value for a segment that's assigned the natural account segment label, you must select an account type, such as Asset, Liability, Expense, Revenue, and Owner's Equity. Account combinations subsequently created with that segment value inherit the assigned account type. For example, you assign segment value 1000 the account type of Asset, and then create account combination 01-000-1000-000-000. The account combination is classified as an asset.

Misclassified accounts occur when the inherited account type of the corresponding natural account segment value is set incorrectly. If you assign an incorrect account type to a natural account segment value, accounting entries are recorded incorrectly and financial statements are inaccurate. Misclassified accounts are also potentially handled incorrectly at year end, with actual balances either getting zeroed out to retained earnings, or accumulating into the next year.

Caution: Be sure to assign the correct account type to natural account segment values before account combinations are created. Having to correct misclassified accounts isn't standard practice.

You can use the Correct Misclassified Accounts process to correct account types for account combinations. Running the process though is only one aspect of correcting misclassified accounts. The overall procedure to correct misclassified accounts depends on:

  • The account type correction being made

  • Whether the impacted account combinations ever had activities posted to them

  • The impact of the correction across accounting years

  • Whether balances have been translated

Account Type Correction

Account types can be grouped into income statement accounts and balance sheet accounts. Income statement accounts consist of the Revenue and Expense account types, and balance sheet accounts consist of the Asset, Liability, and Owner's Equity account types. At the end of an accounting year, income statement accounts are zeroed out to retained earnings, and balance sheet accounts accumulate into the next year.

Account type corrections within the income statement group or within the balance sheet group don't affect the retained earnings calculation or beginning balances across accounting years. The following table lists the specific account type corrections that can be made without requiring manual journal entries as part of the correction process.

Incorrect Account Type Correct Account Type

Revenue

Expense

Expense

Revenue

Asset

Liability or Owner's Equity

Liability

Asset or Owner's Equity

Owner's Equity

Asset or Liability

Account type corrections that cross from the income statement group to the balance sheet group, or from the balance sheet group to the income statement group, can affect the retained earnings calculation and beginning year balances if the corrections cross accounting years. The following table lists the specific account type corrections that may require manual journal entry adjustments as part of the correction process.

Incorrect Account Type Correct Account Type

Revenue

Asset, Liability, or Owner's Equity

Expense

Asset, Liability, or Owner's Equity

Asset

Revenue or Expense

Liability

Revenue or Expense

Owner's Equity

Revenue or Expense

Procedure

Follow these recommended steps to correct misclassified accounts.

  1. On the Manage Values page, correct the account type for the value set value.

  2. Before submitting the Correct Misclassified Accounts process, it's recommended that you:

    • Ensure journals aren't being posted when the process is run in reclassification mode.

    • Disable the Dynamic combination creation allowed option for the chart of accounts.

  3. On the Scheduled Processes page, run the Correct Misclassified Accounts process with the following parameters:

    • Value Set: Select the value set for the natural account segment.

    • Value Set Value: Select the value from which account combinations must inherit the account type.

    • Mode: Select Preview mode.

  4. Review the report output.

    The report lists actual balances for the affected account combinations by ledger, currency, and fiscal year that must be zeroed out in cases where corrections cross from the balance sheet group to the income statement group, or from the income statement group to the balance sheet group. Use this information to facilitate the journal entry that you must create for fiscal year cross-over scenarios. The report also lists periods with translated balances. If the report doesn't display balances to zero out, skip to step 9.

  5. Open the last period of the prior fiscal year for each primary ledger with balances that must be zeroed out.

  6. Create the respective journal entries using the information in the report to bring the misclassified account balances to zero and post the journals. Use a temporary account, such as a suspense account, for the offsetting amount.

    Note: The journal entries should zero out balances in every entered currency.
  7. Rerun the Correct Misclassified Account process in Preview mode.

    Check whether any balances should be zeroed out. If so, repeat steps 5 and 6 until all balances are zeroed out. If the only balances listed are for secondary ledgers and reporting currencies, the journal entries should be created and posted in those ledgers directly.

  8. Run the Correct Misclassified Accounts process in Reclassify Account Type mode.

    The process first validates that the affected account combinations have zero actual balances if the misclassification affects multiple fiscal years. This validation ensures that the account type reclassification doesn't cause errors in the calculation of retained earnings and beginning balances. The process then corrects the account type on the misclassified account combinations to match the account type of the selected segment value.

  9. Review the report output for the list of reclassified account combinations for each chart of accounts.

  10. Update the Account dimension by running the Publish Chart of Account Dimension Members and Hierarchies to Balances Cubes process:

    1. Select the value set for the Account dimension.

    2. Set the Publish Detail Values Only parameter to Yes.

  11. Starting from the earliest fiscal year, reverse and post the journals that you created to zero out the balances in each ledger. The reversal journal must be in the same period as the journal being reversed.

    Note: The recommended reversal method for the journals is Change Sign.
  12. If there are misclassified account corrections, and if a translation currency has balances, you must:

    1. Run the Delete Translated Balances process and after the process completes, rebuild the balances cube.

    2. Rerun the translation process after the misclassification has been addressed.

Define Chart of Accounts

Key flexfields provide a means to capture a key such as a part number, a job code, or an account code. A key flexfield consists of one or more segments, where each segment can have a meaning.

For example, a part number 10-PEN-BLA-450 might correspond to a black pen from supplier #450 sold by division #10 (office supplies). Behind the scenes, the application uses a unique number, 13452, for this part, but the user always sees the 10-PEN-BLA-450 part number.

The following aspects are important to understanding key flexfields:

  • Architecture

  • Segments and segment labels

  • Structures

  • Segment and structure instances

  • Combinations

  • Dynamic combination creation

  • Security

Key flexfields aren't optional. You must configure key flexfields to ensure that your applications operate correctly. You configure and maintain key flexfield definitions with the Manage Key Flexfields task. To get a list of predefined key flexfields, use the Manage Key Flexfields task in the Setup and Maintenance work area. For information about specific key flexfields, see the help for the product where the associated business component is implemented.

Architecture

Flexfield metadata is stored in the flexfield metadata tables. When you configure a key flexfield, you define metadata about the key flexfield covering aspects such as:

  • Segments are in a structure

  • Structures in the flexfield

  • Value sets in each segment

Based on the flexfield metadata, actual part numbers are captured at run time as a combination of segment values and stored in a combinations table. A combinations table contains all the segment columns for a flexfield, a unique ID column, and a structure instance number column. The structure instance number column differentiates multiple arrangements of the segment columns. For example, a part number containing multiple segments can be represented by a key flexfield. A part number key flexfield has a corresponding combinations table. In that table, the flexfield stores a list of the complete codes, with each segment of the code in a column, with the corresponding unique ID and structure instance number for the code. When users define a new part number or maintain existing part numbers in the parts catalog, they directly maintain rows in the combinations table.

The foreign key table contains a different business entity than the combinations table. For example, the business entity in the foreign key table is order lines or invoice lines that contain foreign key references to parts for ordering. Any number of foreign key tables can reference a particular entity represented by a key flexfield.

Segments and Segment Labels

A key flexfield contains segments and a segment label identifies a particular segment within a key flexfield. Segment labels are defined and made available by the product development. A segment contains the following details:

  • A prompt

  • A short prompt

  • Display width

  • The sequential position of the segment within the key flexfield structure

  • The range type

  • Column name of the attribute being stored by the segment

  • A default value set

  • A label for the segment

Applications identify a particular segment for some purpose such as security or computations. Segment name or segment order cannot reliably identify a segment because key flexfield segments can be configured to appear in any order with any prompts. A segment label functions as a tag for a segment.

For example, the requirement is to identify which segment in the accounting flexfield contains balancing information and which segment contains natural account information. A segment label determines which segment you are using for natural account information. When you define your accounting flexfield, you must specify which segment labels apply to which segments. Some labels must be unique, and cannot be applied to more than one segment in each structure. Other labels are required, and must be applied to at least one segment in each structure.

A segment label helps a user searching for segments, such as the Cost Center label for all segments across key flexfields that store a value for the cost center.

Structures

A key flexfield structure definition includes the number of segments and their order.

In some applications, different users like to see different segment structures for the same flexfield. A key flexfield can have multiple structures if registered to support more than one structure.

The flexfield can display different fields for different users based on a data condition in your application data, such as the value of another field entered by the user or the user's role. For example, the correctly formatted local postal address for customer service inquiries differs based on locale. A postal address key flexfield could display different segments and prompts for different users based on a location condition in your application data, such as the user's role or a value entered by the user.

Each structure can have one or more segments. Thus a segment is a child of a structure. To store a particular segment, such as Cost Center, in two different structures, you must define the segment separately in each structure. Each structure may have one or more structure instances. Each instance of a structure shares the same number and order of segments, but differs in the values or value sets used in validating the segments.

Structure and Segment Instances

You can define multiple configurations of a key flexfield structure. These structure instances have the same segment structure, in the same sequence order. They differ primarily in how each segment is validated. You define a structure instance for each key flexfield and each key flexfield structure instance.

The segments in a key flexfield structure instance are segment instances. A segment instance is a segment with a specific value set assigned to it. If a key flexfield is registered with a tree structure, you can specify a tree code for a segment instance.

Combinations

A combination is a complete code, or combination of segment values that makes up the code, that uniquely identifies an object.

For example, each part number is a single combination, such as PAD-YEL-11x14 or 01-COM-876-7BG-LTN. In these combinations, the hyphen is the segment separator. If you have ten parts, define ten combinations. A valid combination is an existing or new combination that can be used because it's currently active and doesn't violate cross-validation or security rules. A combination has different segments depending on the flexfield structure being used for that combination. Any combination is associated with only one particular flexfield structure.

Many applications refer to a key flexfield combination by using the name of the entity or the key flexfield itself. For example, Assets uses the asset key flexfield and refers to one of its combinations as an asset key or asset key flexfield. In another example, Oracle Fusion General Ledger refers to combinations of the accounting flexfield as account or GL account.

Each key flexfield has one corresponding table, known as the combinations table, where the flexfield stores a list of the complete codes, with one column for each segment of the code, together with the corresponding unique ID number (an account combination ID) for that code. Then, other tables in the application have a column that stores just the unique ID for the code. For example, you may have a part number code, such as PAD-YEL-11x14. The Parts combinations table stores that code along with its ID, 57494. If your application lets you take orders for parts, you might then have an Orders table that stores orders for parts. That Orders table would contain a single column that contains the part ID, 57494, instead of several columns for the complete code PAD-YEL-11x14. Typically, one combinations page maintains the key flexfield, where the key flexfield is the representation of an entity in your application. Maintain individual combinations, such as part numbers in the combinations page.

Dynamic Combination Creation

Dynamic combination creation is the insertion of a new valid combination into a combinations table from a page other than the combinations page. The following table lists the levels at which dynamic combination creation may be enabled.

Level Of Dynamic Combination Creation Controlled By:

Flexfield

Application development

Each usage or reference to the key flexfield

Application development

Structure instance

Administrators and implementation consultants

Other

Administrators and implementation consultants

If your key flexfield or certain usages or references of the key flexfield don't permit dynamic combination creation, you may control whether dynamic combination creation is enabled for each structure instance. If enabled, a user can enter a new combination of segment values using the flexfield window from a foreign key page. For example, when entering a transaction, a GL user can enter a new expense account combination for an account that doesn't yet exist. Your application creates the new account by inserting the new combination into the combinations table behind the scenes. Assuming that the new combination satisfies any existing cross-validation rules, the flexfield inserts the new combination into the combinations table, even though the combinations table isn't the underlying table for the foreign key page.

Planning Key Flexfields: Points to Consider

Your first step in planning your key flexfields is to determine which key flexfields your application requires. Your plan should include:

  • The purpose of the key flexfield

  • The number and length of its available segment columns

  • Whether your key flexfield permits more than one structure

  • Whether more than one structure must be defined

  • The number, order and length of your segments for each structure

Before You Begin

Once you have identified a flexfield, plan its configuration in advance. Compile a list of the UI pages and other artifacts in your deployment that are affected by the configuration. Verify that you are provisioned with the roles required to view and configure the flexfield. Use the Highlight Flexfields command in the Administration menu to view the run time page where the flexfield appears. Plan how you deploy the flexfield for test and production users and review the tools and tasks available for managing flexfields.

If you plan to use value sets, create them before configuring the key flexfield. You cannot create value sets for key flexfields at the time that you add and configure key flexfield segments.

Access to Flexfield-Related Tasks

To configure flexfields and value sets, you must have access to the tasks for managing flexfields. Contact your security administrator for details. For information about product-specific flexfield tasks, such as Manage Fixed Assets Key Flexfields, refer to the product-specific documentation.

Restrictions

If you plan to use value sets, create them before configuring the flexfield. Plan your key flexfield configuration to scale to your enterprise needs. For example, if you expect to disable old cost centers and enable new ones frequently, plan a larger maximum size for your cost center value set so that you can have more available values. A 3-character value set with one thousand available values provides more room for changes than a 2-character value set with 100 available values.

Note the code name of the flexfield you intend to configure so that you find it easily in the tasks for managing key flexfields. In some cases you can configure how the flexfield appears on the page. See product-specific documentation to determine any restrictions on using product-specific key flexfields.

Reporting

To report on your data by certain criteria or sub-entities, such as account number or project or region, consider making that sub-entity a distinct segment, rather than combining it with another sub-entity. You can categorize and report on smaller discrete units of information.

Essbase Character and Word Limitations

The following is a comprehensive list of character and word limitations that apply to Essbase. All of the limitations apply to all of the Oracle General Ledger configurations summarized in the table.

The following table shows how the General Ledger configuration maps to Essbase.

General Ledger Configuration Maps to Essbase

Chart of Account Name

Cube Name

Chart of Account Segment Name

Dimension Name

Chart of Accounts Segment Value

Dimension Member Name

Chart of Accounts Segment Value Description

Alias for Member

Tree and Tree Version Name

Dimension Member Name

Primary Ledger Name

Dimension Member Name in Ledger Dimension

Secondary Ledger Name

Dimension Member Name in Ledger Dimension

Reporting Currency

Dimension Member Name in Ledger Dimension

Ledger Set Name

Dimension Member Name in Ledger Dimension

Accounting Calendar Period Names

Dimension Member Name in Accounting Period Name

Scenario Name Defined in Predefined Value Set Called Accounting Scenario

Dimension Member Name in Scenario Dimension

Even if case sensitivity is enabled in an aggregate storage outline for which duplicate member names is enabled, do not use matching dimension names with only case differences. For example, do not:

  • Name two dimensions Product and product.

  • Use quotation marks or brackets.

  • Use tabs in dimension, member, or alias names.

  • Use accent characters.

  • Use the characters for dimension or member names.

Restricted Characters

The following table lists the characters that are restricted and can’t be used in dimension, member, or alias names.

Character Meaning

&

ampersand

@

at sign

\

backslash

{}

brace

,

comma

-

dash, hyphen, or minus sign

For the accounting calendar period names, you can use a hyphen or an underscore in the middle of an accounting calendar period name. For example: Jan-15 or Adj_Dec-15 can be used successfully.

=

equal sign

<

less than sign

()

parentheses

.

period

+

plus sign

'

single quotation mark

_

underscore

For the accounting calendar period names, you can use a hyphen or an underscore in the middle of an accounting calendar period name. For example: Jan-15 or Adj_Dec-15 can be used successfully.

|

vertical bar

Other Restrictions

  • Don't place spaces at the beginning or end of names. Essbase ignores such spaces.

  • Don't use the following types of words as dimension or member names:

    • Calculation script commands, operators, and keywords.

    • Report writer commands.

    • Function names and function arguments.

    • Names of other dimensions and members (unless the member is shared).

    • Generation names, level names, and aliases in the database.

The following table lists additional words that should not be used.

List 1 List 2 List 3

ALL

AND

ASSIGN

AVERAGE

CALC

CALCMBR

COPYFORWARD

CROSSDIM

CURMBRNAME

DIM

DIMNAME

DIV

DYNAMIC

EMPTYPARM

EQ

EQOP

EXCEPT

EXP

EXPERROR

FLOAT

FUNCTION

GE

GEN

GENRANGE

GROUP

GT

ID

IDERROR

INTEGER

LE

LEVELRANGE

LOOPBLOCK

LOOPPARMS

LT

MBR

MBRNAME

MBRONLY

MINUS

MISSING, #MISSING

MUL

MULOP

NE

NON

NONINPUT

NOT

OR

PAREN

PARENPARM

PERCENT

PLUS

RELOP

SET

SKIPBOTH

SKIPMISSING

SKIPNONE

SKIPZERO

TO

TOLOCALRATE

TRAILMISSING

TRAILSUM

UMINUS

UPPER

VARORXMBR

XMRONLY

$$$UNIVERSE$$$

#MI

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.

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

  • Measures performance against corporate objectives by your managers.

Caution: Once you begin using your chart of accounts, making changes to its fundamental attributes is neither recommended nor supported. This includes your chart of account segments, including the segment labels as well as other characteristics of those segments.

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 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 product, which has data standardized from each operation, is a thin general ledger. Use this variation if your solution is project-based, and Oracle Fusion Project Portfolio Management 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 thick general ledger:

    • Has segments representing all aspects.

    • Captures every detail of your business.

    • Runs frequent posting.

    • Defines many values in each segment.

    A thick general ledger is designed to serve as a repository of management data for a certain level of management. For example, a general ledger designed to provide management data to supervise operations, such as daily sales, without invoice details.

  • A primary and secondary ledger, with one thick general ledger and the other a thin general ledger, provides dual representation to meet reporting requirements.

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.

  • Has cost centers at the functional expense level, such as Research and Development or Selling, General, and Administrative, rather than at department or analytic levels.

  • 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

A thick general ledger had details 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 versions of 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 previously listed. 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 an operational dimension or segment are entered by the user, then a thick primary ledger is the better choice.

However, if values for the operational segment are automatically derived from attributes on transactions in your subledger accounting rules, 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 trade-off 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 should 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

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

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

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

Chart of Accounts

The chart of accounts defines the number and attributes of various segments, including:

  • Order of segments

  • Width of segments

  • Prompts

  • Segment labels, such as balancing, natural account, and cost center.

The chart of accounts further defines:

  • Combination of value sets associated with each segment

  • Type of segment

  • Default values for the segments

  • Additional conditions designating the source of the values using database tables

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

Caution: You must use Independent validation only for the Accounting Key Flexfield value sets. Other validations prevent you from using the full chart of accounts functionality, such as data security, reporting, and account hierarchy integration. Dependent values sets are not supported.

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. The three balancing segment labels are: 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. If you are implementing Oracle Fusion Procurement, you can use cost centers for business intelligence reporting and to route transactions for approval.

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

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

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

Account Combinations

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

Rules

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

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

FAQs for Define Chart of Accounts

How can I use future accounting segments?

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

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

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

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

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

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

You can create a chart of accounts mapping using only segment rules, only account rules, or a combination of both segment and account rules. If an overlap exists between the two types of rule, the account rule supersedes. Segment rules are used to broadly define the relationship between two charts of accounts on a segment by segment basis. Account rules can be used to more precisely map specific source account combinations to their target accounts.

Define Value Sets

A value set is a 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

  • Value Definition

Module Designation

The module designation is used to tag value sets and sets the value sets apart during upgrades and other processes. When creating value sets for a chart of accounts, the module can be specified as 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 segments in an account combination.

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

Caution: You must use Independent validation only for the Accounting Key Flexfield value sets. Other validations prevent you from using the full chart of accounts functionality, such as data security, reporting, and account hierarchy integration. Dependent values sets are not supported.

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 settings 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 option for the assigned value set must be selected. 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 characteristics are defined for the value set, values can be added to the set on the Manage Values page.

  1. Enter the value and description. Set the value to conform to the value set length and type.

  2. Indicate whether the value is enabled and specify the start and end dates.

  3. Assign the following attributes: Summary, Allow Posting, Allow Budgeting.

  4. If the value set is used with a natural account segment, you must set the Account Type attribute. Select one of the following options: Asset, Liability, Owner's Equity, Revenue, or Expense.

    Caution: Assign account types carefully. If you assign an incorrect account type to a natural account segment value, accounting entries are recorded incorrectly and financial statements are inaccurate. Misclassified accounts are also potentially handled incorrectly at year end, with actual balances either getting zeroed out to retained earnings, or accumulating into the next year.
  5. Other attributes that you can set are Third-Party Control Account, Reconcile, and Financial Category, which is used with Oracle Transactional Business Intelligence reporting.

    The Third-Party Control Account attribute enables you to maintain detailed balances by third party for an account combination. Valid third-party information must be associated with the journal line if the account is a third-party control account. General Ledger prevents manual journal entries from posting to third-party control accounts. This ensures that journal lines that post to control accounts such as the supplier liability account and the customer receivables account, are associated with valid third-party information in the respective subledgers.

    You can select one of the following options:

    • Customer Control Account: Customer information is required when such accounts are used in subledger transactions or subledger journals.

    • Supplier Control Account: Supplier information is required when such accounts are used in subledger transactions or subledger journals.

    • Third-Party Control Account: Third-party information is required when such accounts are used in subledger transactions or subledger journals.

    • Restrict GL Manual Journals: Third-party information isn't required when such accounts are used in subledger transactions or subledger journals.

    • No: Not a control account.

    General Ledger prevents manual journal entries to all of the accounts whose Third-Party Control Account attribute is set to a value other than No.

Tip: Best practice is to define value set values after the value set has been assigned to a chart of accounts structure instance. Otherwise you can't define the mandatory value attributes, such as the summary indicator, the posting allowed indicator, and the account type for natural account segments. The attributes must be added after the value set is assigned to a chart of accounts structure instance.

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

Scenario

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

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Chart of Accounts Value Sets

  2. Click the Create icon in the Search Results section.

  3. On the Create Value Set page, enter a unique value set code, Vision Corporation, and an optional description, Company values for Vision Corporation

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

  5. Select Independent as the validation type.

    Note: You must use Independent validation only for Accounting Key Flexfield value sets. Other validations prevent you from using the full chart of accounts functionality, such as data security, reporting, and account hierarchy integration. Dependent values sets aren't supported.
  6. Select Character for the validation data type.

  7. Click Save and Close.

Enabling Key Flexfield Segments for Business Intelligence: Points to Consider

A key flexfield registered in the database as enabled for Oracle Business Intelligence (BI) includes a BI Enabled setting for each of its segment instances. When a segment instance is BI-enabled, it's available for use in Oracle Business Intelligence.

The following aspects are important in understanding BI-enabled key flexfield segments.

  • Flattening business components to use BI-enabled segments in Oracle BI

  • Equalizing segments to prevent duplication and complexity in the flattened component

  • Mapping attributes of flattened business components to logical objects in Oracle BI

  • Managing the labels that map segments to logical objects in Oracle BI

After you deploy a business intelligence-enabled flexfield, use the Import Oracle Fusion Data Extensions for Transactional Business Intelligence process to import the flexfield changes into the Oracle Business Intelligence repository. Users can make use of the newly-generated attributes in business intelligence applications. For additional information about logical objects and import, refer to the Oracle Transactional Business Intelligence Administrator's Guide.

Flattening

When you deploy a business intelligence-enabled key flexfield, the deployment process generates an additional set of flattened business components for use in business intelligence. The flattened business components include attributes for business intelligence-enabled segment instances only.

If you assigned a label to a segment, the flattened components include a single attribute representing all segment instances with that label. If you didn't assign a label, the flattened components include a discrete attribute for each BI-enabled segment instance in each structure.

Mapping to Logical Objects in Business Intelligence

You can simplify reporting by representing similar segments as a single logical object in Business Intelligence. If you assign a label to segments that serve the same purpose in different structures, you can consolidate the segments into a single attribute. This prevents duplication and the extra workload and complexity that result from the flattening process. For example, an organization may have more than one definition of its key accounting flexfield to support different requirements for accounting reporting. A US Accounting Flexfield structure may have a segment called Subaccount to track project expenditures. The same type of information may be tracked in a UK accounting flexfield structure with a segment called Project. Equalize these two segments to create a single list of values for reporting.

Non-labeled segments aren't equalized across context values, so the flattened components include a separate attribute for each segment for each structure. It may not be possible to equalize similarly labeled segments if they have incompatible data types or value set types.

Assign a label to a segment to map the corresponding attribute in the flattened components to a logical object in Oracle Business Intelligence. Using labels to map segments to BI logical objects minimizes the steps for importing the flexfield into Oracle Business Intelligence. Assigning a label to a segment serves to equalize the attribute across structures, as well as map the equalized attribute to business intelligence.

Managing Labels

You may assign a predefined label (if available) to segments or create labels for assignment, as needed. Specify a code, name, and description to identify each label. In the BI Object Name field, enter the name of the logical object in Oracle Business Intelligence to which the segment label should map during import. Specifying the BI logical object minimizes the steps for importing the flexfield into Oracle Business Intelligence and helps to equalize context-sensitive segments across structures.

If no labels are assigned to a BI-enabled segment, or the BI Object Name on the assigned label doesn't exist in business intelligence, you must manually map the segment to the required logical object when importing into Oracle Business Intelligence. In addition, segments without labels cannot be equalized across structures. The flattened components include a separate attribute for each non-labeled segment in each structure.

Importing to Oracle Business Intelligence Repository

After you deploy a business intelligence-enabled flexfield, import the flexfield changes into the Oracle Business Intelligence repository to make use of the newly flattened business components in business intelligence. Then propagate the flexfield object changes. When you import the metadata into the Oracle Business Intelligence repository, you must do so as the FUSION_APPS_BI_APPID user.

To import flexfield changes into the Oracle Business Intelligence repository in Oracle Cloud implementations, run the Import Oracle Fusion Data Extensions for Transactional Business Intelligence process. For additional information about import, refer to the Oracle Transactional Business Intelligence Administrator's Guide.

Note: When you import a flexfield into the Oracle Business Intelligence repository, you see both <name>_ and <name>_c attributes for each segment, along with some other optional attributes. The <name>_ attribute contains the value. The <name>_c attribute contains the code of the value set that the value comes from, and is used for linking to the value dimension. You must import both attributes.

Configuring Chart of Account Segments for Business Intelligence: Explained

To map the Oracle General Ledger accounting flexfield in the Oracle Fusion Transaction Business Intelligence (BI) Repository file (RPD) for Oracle Fusion Financials, populate values in the Manage Key Flexfields user interface. These values enable the chart of accounts segments for Oracle Fusion Transactional BI. The values also provide the mapping with BI Object names that are used as dimensions for each of the chart of accounts segments.

Follow these steps to select the BI enabled option for all chart of account segments that you intend to map in the RPD.

  1. In the Setup and Maintenance work area, use the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Chart of Accounts Structures

  2. Enter GL# in the Key Flexfield Code field.

  3. Click Search.

  4. Click Manage Structure Instances.

  5. Click Search.

  6. Click the specific chart of accounts and click the Edit icon.

  7. Click the specific segment and click the Edit icon.

  8. Select the BI enabled option.

  9. Click Save. This should be done for all segments in every chart of accounts structure instance that you intend to be mapped in the RPD.

  10. Click Save and Close.

  11. Click Done.

Follow these steps to specify a BI object name for each segment label. This name is the logical table name in the RPD that is used as the dimension for the corresponding segment.

  1. In the Setup and Maintenance work area, use the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Chart of Accounts Structures

  2. Enter GL# in the Key Flexfield Code field.

  3. Click Search.

  4. Select the Actions menu and click Manage Segment Labels.

  5. Populate the BI Object Name field for all of the segment labels that must be mapped in the RPD. Complete the fields, as shown in this table.

    Segment Label Code BI Object Name

    FA_COST_CTR

    Dim - Cost Center

    GL_BALANCING

    Dim - Balancing Segment

    GL_ACCOUNT

    Dim - Natural Account Segment

  6. Click Save.

Note: For all the nonqualified segment labels, populate the BI Object Name with one of the following values:
  • Dim - GL Segment1

  • Dim - GL Segment2

  • Dim - GL Segment3

  • Dim - GL Segment4

  • Dim - GL Segment5

  • Dim - GL Segment6

  • Dim - GL Segment7

  • Dim - GL Segment8

  • Dim - GL Segment9

  • Dim - GL Segment10

Deploy the flexfield using the Deploy Flexfield button on the Manage Key Flexfields page. For more information about using both key and descriptive flexfields in Oracle Fusion Transactional BI, refer to the Oracle Fusion Transactional Business Intelligence Administrator's Guide.

Correcting Misclassified Accounts: Explained

When you create a value for a segment that's assigned the natural account segment label, you must select an account type, such as Asset, Liability, Expense, Revenue, and Owner's Equity. Account combinations subsequently created with that segment value inherit the assigned account type. For example, you assign segment value 1000 the account type of Asset, and then create account combination 01-000-1000-000-000. The account combination is classified as an asset.

Misclassified accounts occur when the inherited account type of the corresponding natural account segment value is set incorrectly. If you assign an incorrect account type to a natural account segment value, accounting entries are recorded incorrectly and financial statements are inaccurate. Misclassified accounts are also potentially handled incorrectly at year end, with actual balances either getting zeroed out to retained earnings, or accumulating into the next year.

Caution: Be sure to assign the correct account type to natural account segment values before account combinations are created. Having to correct misclassified accounts isn't standard practice.

You can use the Correct Misclassified Accounts process to correct account types for account combinations. Running the process though is only one aspect of correcting misclassified accounts. The overall procedure to correct misclassified accounts depends on:

  • The account type correction being made

  • Whether the impacted account combinations ever had activities posted to them

  • The impact of the correction across accounting years

  • Whether balances have been translated

Account Type Correction

Account types can be grouped into income statement accounts and balance sheet accounts. Income statement accounts consist of the Revenue and Expense account types, and balance sheet accounts consist of the Asset, Liability, and Owner's Equity account types. At the end of an accounting year, income statement accounts are zeroed out to retained earnings, and balance sheet accounts accumulate into the next year.

Account type corrections within the income statement group or within the balance sheet group don't affect the retained earnings calculation or beginning balances across accounting years. The following table lists the specific account type corrections that can be made without requiring manual journal entries as part of the correction process.

Incorrect Account Type Correct Account Type

Revenue

Expense

Expense

Revenue

Asset

Liability or Owner's Equity

Liability

Asset or Owner's Equity

Owner's Equity

Asset or Liability

Account type corrections that cross from the income statement group to the balance sheet group, or from the balance sheet group to the income statement group, can affect the retained earnings calculation and beginning year balances if the corrections cross accounting years. The following table lists the specific account type corrections that may require manual journal entry adjustments as part of the correction process.

Incorrect Account Type Correct Account Type

Revenue

Asset, Liability, or Owner's Equity

Expense

Asset, Liability, or Owner's Equity

Asset

Revenue or Expense

Liability

Revenue or Expense

Owner's Equity

Revenue or Expense

Procedure

Follow these recommended steps to correct misclassified accounts.

  1. On the Manage Values page, correct the account type for the value set value.

  2. Before submitting the Correct Misclassified Accounts process, it's recommended that you:

    • Ensure journals aren't being posted when the process is run in reclassification mode.

    • Disable the Dynamic combination creation allowed option for the chart of accounts.

  3. On the Scheduled Processes page, run the Correct Misclassified Accounts process with the following parameters:

    • Value Set: Select the value set for the natural account segment.

    • Value Set Value: Select the value from which account combinations must inherit the account type.

    • Mode: Select Preview mode.

  4. Review the report output.

    The report lists actual balances for the affected account combinations by ledger, currency, and fiscal year that must be zeroed out in cases where corrections cross from the balance sheet group to the income statement group, or from the income statement group to the balance sheet group. Use this information to facilitate the journal entry that you must create for fiscal year cross-over scenarios. The report also lists periods with translated balances. If the report doesn't display balances to zero out, skip to step 9.

  5. Open the last period of the prior fiscal year for each primary ledger with balances that must be zeroed out.

  6. Create the respective journal entries using the information in the report to bring the misclassified account balances to zero and post the journals. Use a temporary account, such as a suspense account, for the offsetting amount.

    Note: The journal entries should zero out balances in every entered currency.
  7. Rerun the Correct Misclassified Account process in Preview mode.

    Check whether any balances should be zeroed out. If so, repeat steps 5 and 6 until all balances are zeroed out. If the only balances listed are for secondary ledgers and reporting currencies, the journal entries should be created and posted in those ledgers directly.

  8. Run the Correct Misclassified Accounts process in Reclassify Account Type mode.

    The process first validates that the affected account combinations have zero actual balances if the misclassification affects multiple fiscal years. This validation ensures that the account type reclassification doesn't cause errors in the calculation of retained earnings and beginning balances. The process then corrects the account type on the misclassified account combinations to match the account type of the selected segment value.

  9. Review the report output for the list of reclassified account combinations for each chart of accounts.

  10. Update the Account dimension by running the Publish Chart of Account Dimension Members and Hierarchies to Balances Cubes process:

    1. Select the value set for the Account dimension.

    2. Set the Publish Detail Values Only parameter to Yes.

  11. Starting from the earliest fiscal year, reverse and post the journals that you created to zero out the balances in each ledger. The reversal journal must be in the same period as the journal being reversed.

    Note: The recommended reversal method for the journals is Change Sign.
  12. If there are misclassified account corrections, and if a translation currency has balances, you must:

    1. Run the Delete Translated Balances process and after the process completes, rebuild the balances cube.

    2. Rerun the translation process after the misclassification has been addressed.

FAQs for Define Value Sets

What happens if you use average balances and create a segment value?

The new segment value is added to both the standard balances cube and the average daily balances cube.

Define Chart of Accounts Structures and Instances

Creating One Chart of Accounts Structure with Many Instances: Example

In Oracle Fusion General Ledger, the chart of accounts model is framed around the concept of a chart of accounts structure, for 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 US dollars. Your product line includes all the components to build and maintain air quality monitoring systems for homes and businesses.

Analysis

In Oracle Fusion General Ledger, the chart of accounts model is framed around the concept of a chart of accounts structure, for 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 for the same structure share a common configuration with the same segments, in the same order, and the same characteristics. Using one chart of accounts structure with multiple instances simplifies your accounting and reporting.

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

The collective assignment of value sets to each of the segments forms one chart of accounts instance. At the chart of accounts structure instance level, you can select to enable dynamic insertion. Dynamic insertion allows the creation of account 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 account combinations. Well-defined cross-validation rules help prevent the creation of inappropriate account combinations.

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

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

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

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

Chart of Accounts Structure

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

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Chart of Accounts Structures

  2. Select the General Ledger module and click Search.

  3. Click Manage Structures.

  4. On the Manage Key Flexfield Structures page, select the General Ledger row and click the Create icon.

  5. On the Create Key Flexfield Structure page, enter the unique structure code INFUSION_AM_COA_STRUCTURE and name InFusion America COA Structure. Provide an optional description of InFusion America Inc. chart of accounts structure.

  6. Select a delimiter to visually separate the segment values.

  7. Click Save.

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

    1. Complete the fields, as shown in this table.

      Field Value

      Segment Code

      INFUSION_AM_CO

      Name

      InFusion America Company

      Description

      InFusion America Inc.

      Sequence Number

      1

      Prompt

      Company

      Short Prompt

      CO

      Display Width

      2

      Column Name

      Segment1

      Default Value Set Code

      INFUSION_AM_COMPANY

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

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

    4. Click Done.

    5. Define additional segments following the same steps.

Chart of Account Instance

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

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Chart of Accounts Structure Instances

  2. On the Manage Chart of Accounts Structure Instances page, select the General Ledger module and click Search.

  3. Select the General Ledger row and click Manage Structure Instances.

  4. On the Manage Key Flexfield Structure Instances page, click the Create icon.

  5. On the Create Key Flexfield Structure Instance page, enter the unique structure instance code INFUSION_AM_COA_INSTANCE and name InFusion America COA Instance. Provide an optional description, InFusion America Inc. chart of accounts structure instance.

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

  7. Associate your instance with the structure InFusion America Structure.

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

  9. To modify an instance segment, select the segment row and click Edit.

  10. Select the Required, Displayed, and BI enabled options.

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

    Select the BI enabled option to use key flexfield segments in Oracle Fusion Transactional Business Intelligence. The business intelligence option is only valid when enabled on segments with segment labels. The second step is to populate the BI Object Name field for each of the segment labels on the Manage Segment Label page, which you open from the Manage Key Flexfields page.

  11. Click OK.

  12. Click Save and Close.

  13. Define additional instances following the same process.

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

  15. Click Deploy Flexfield.

  16. Click OK.

Balancing segments ensure that all journals balance for each balancing segment value or combination of multiple balancing segment values. You can secure access to your primary balancing segment values only with data access sets. The General Ledger application automatically calculates and creates balancing lines as required in journal entries.

The three balancing segment labels are:

  • Primary

  • Second

  • Third

Note: The primary balancing segment label is required.

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

The following explains processes that use balancing segments.

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

  • Opening first period of the 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

    • 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 accounts represent 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.

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

Several points must be consider when using multiple balancing segments:

  • Journal entry processing

  • Implementation timing

  • Change options

  • Migration adjustments

Journal Entry Processing

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

Implementation Timing

When using optional second and third balancing segments, remember that these chart of accounts segment labels are set from the beginning of time. Ensure that balances are immediately maintained in accordance with the necessary balancing actions to produce consistent financial reporting for the wanted 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.

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

Change Options

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

Migration Adjustments

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

For ledgers associated with a migrated chart of accounts, the balances must be adjusted manually. The manual adjustment is to ensure that the second and third balancing segments are consistent as though these segment labels have been in place since the beginning of entries for these ledgers. Recomputing and updating of the following processes is required to reflect the correct balancing for each account using the 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

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

Using Multiple Balancing Segments: Example

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

Scenario

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

  • Company: Primary balancing segment

  • Cost Center: Second balancing segment

  • Account: Natural account segment

The following table shows a journal that was entered to transfer advertising and phone expense from company 1, cost center A to company 2, cost center B.

Line Account Debit Credit

1

Company 1-Cost Center A-Advertising Expense Account

600

2

Company 2-Cost Center B-Advertising Expense Account

600

3

Company 1-Cost Center A-Phone Expense Account

800

4

Company 2-Cost Center B-Phone Expense Account

800

The posting process creates journal lines to balance the entry across the primary and second balancing segments, company and cost center. The following table shows all of the journal lines, including balancing lines 5 through 8, which were automatically created.

Line Account Debit Credit

1

Company 1-Cost Center A-Advertising Expense Account

600

2

Company 2-Cost Center B-Advertising Expense Account

600

3

Company 1-Cost Center A-Phone Expense Account

800

4

Company 2-Cost Center B-Phone Expense Account

800

5

Company 1-Cost Center A-Balancing Account

600

6

Company 2-Cost Center B-Balancing Account

600

7

Company 1-Cost Center A-Balancing Account

800

8

Company 2-Cost Center B-Balancing Account

800

Manage Flexfield Deployment

Deployment generates or refreshes the Application Development Framework (ADF) business component objects that render the flexfield in a user interface. The deployment process adds user-defined attributes to the Web Services Description Language (WSDL) schemas exposed by Oracle ADF services and used by SOA composites. Flexfields are deployed for the first time during the application provisioning process. After you configure or change a flexfield, you must deploy it to make the latest definition available to users.

If a descriptive flexfield is enabled for business intelligence, the deployment process redeploys the flexfield's business intelligence artifacts.

You can deploy a flexfield to a sandbox for testing or to the mainline metadata for use in a test or production run time environment. You can deploy extensible flexfields as a background process.

After deployment, the user-defined attributes are available for incorporating into the SOA infrastructure, such as business process and business rule integration. For example, you can now write business rules that depend on the user-defined attributes. You must sign out and sign back in to Oracle Applications Cloud to see the changes you deployed at run time.

The following aspects are important in understanding flexfield deployment:

  • Deployment Status

  • Initial Deployment Status

  • Metadata Validations

  • Metadata Synchronization

  • Deployment as a Background Process

  • Export of Artifacts from Flexfield MDS

Deployment Status

Every flexfield has a deployment status. Check the deployment status of your flexfield after patching. The following table lists the different deployment statuses a flexfield can have.

Deployment Status Meaning

Edited

The flexfield metadata definition hasn't been deployed yet. Updates of the metadata definition aren't applied in the run time environment yet.

Patched

The flexfield metadata definition has been modified through a patch or a data migration action, but the flexfield hasn't yet been deployed. So, the updated definition isn't reflected in the run time environment.

Deployed to Sandbox

The current metadata for the flexfield is deployed in ADF artifacts and available as a flexfield-enabled sandbox. The status of the sandbox is managed by the Manage Sandboxes dialog box available in the Settings and Actions menu.

Deployed

The current metadata for the flexfield is deployed in ADF artifacts and available to users. No changes have been made to the flexfield after being deployed to the mainline metadata.

Error

The deployment attempt in the mainline metadata failed.

Note: Whenever a value set definition changes, the deployment status of a flexfield that uses that value set changes to edited. If the change results from a patch, the deployment status of the flexfield changes to patched.

Initial Deployment Status of Flexfields

The Oracle Applications Cloud implementation loads flexfield metadata into the database. This initial load sets the flexfield status to Edited. During installation, the application provisioning process deploys the flexfields of the provisioned applications, setting their status to Deployed if no errors occur.

In a provisioned application, deployed flexfields are ready to use. In some cases, flexfield availability at run time 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 all flexfield deployment commands. By successfully validating metadata before running the deployment commands, you can avoid failures in the metadata validation phase of a deployment attempt. The deployment process ends if an error occurs during the metadata validation phase. Metadata validation results don't affect the deployment status of a flexfield.

Metadata Synchronization

When an extensible or descriptive flexfield is deployed, the deployment process regenerates the XML schema definition (XSD). As a result, the user-defined attributes are available to web services and the SOA infrastructure.

After deploying a flexfield configuration, you must synchronize the updated XML schema definition (XSD) files in the MDS repositories for each SOA application.

Note: To synchronize the updated XSD files in the MDS repositories in Oracle Cloud implementations, log a service request using My Oracle Support at http://support.com/

Deployment as a Background Process

You can deploy extensible flexfields offline as a background process and continue working in the session without having to wait for the deployment to complete. You can queue up several extensible flexfields and deploy as a background process. The flexfields are deployed, one at a time, in the order that you deploy them to the queue. You must deploy extensible flexfields with more than 30 categories as a background process.

You can remove an extensible flexfield from the deployment queue with the Cancel Background Deployment command. When an extensible flexfield is deployed in a background process, its offline status indicates that the flexfield is in a background deployment process. A flexfield's offline status is cleared and its deployment status updated when the background deployment process has completed.

Export of Artifacts from Flexfield MDS

You can export business components from MDS for descriptive, extensible, or key flexfields, mainly for use in troubleshooting issues with flexfields. Use Download Flexfield Archive on the Manage Flexfields page to export MDS artifacts of the selected flexfield, and import them to an archive on your local computer. You can use these archived business components of flexfields for troubleshooting purposes.

Alternatively, export the deployed artifacts using exportMetadata WLST.

Flexfield Deployment Status: How It's Calculated

Flexfield deployment status indicates how the flexfield metadata definition in the Oracle Applications Cloud database relates to the Application Development Framework (ADF) business components residing in an Oracle Metadata Services (MDS) Repository.

The following aspects are important in understanding how flexfield deployment status is calculated:

  • Settings that affect flexfield deployment status

  • How deployment status is calculated

Settings That Affect Flexfield Deployment Status

If you have made a change to a flexfield and expect a changed deployment status, ensure that you have saved your changes. No settings affect flexfield deployment status.

How 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 diverges from the latest deployed flexfield definition. Any change, including if a value set used in a flexfield changes, changes the deployment status to Edited. If a flexfield has never been deployed, its status is Edited.

Note: When an application is provisioned, the provisioning framework attempts to deploy all flexfields in that application.

If you deploy the flexfield to a sandbox successfully, the status is Deployed to Sandbox. The latest flexfield metadata definition in the application matches with the metadata definition that generated ADF business components in a sandbox MDS Repository. Whether the sandbox is active or not doesn't affect the deployment status. If the flexfield was deployed to a sandbox and hasn't been edited or redeployed to the mainline metadata 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 to the mainline metadata, the status is Deployed. The latest flexfield metadata definition in the 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 metadata. If either type of deployment fails and that the current flexfield definition isn't deployed, the status is Error. The deployment error message gives details about the error. The latest flexfield metadata definition in the 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 application diverges from the latest deployed flexfield definition. If the flexfield definition was Deployed before the patch and then a patch was applied, the status changes to Patched. If the flexfield definition was Edited before the patch and then a patch was applied, the status remains at Edited to reflect that there are still changes (outside of the patch) that aren't yet in effect.

When a deployment attempt fails, 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 Applications Cloud 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 metadata.

A flexfield-enabled sandbox uses the following components.

  • Flexfield metadata in the Oracle Applications Cloud database

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

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

The following 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 metadata applies the flexfield definition to the mainline MDS Repository where it is available to end users. After deploying the flexfield to the mainline metadata, modify the page where the flexfield segments appear. Modifications done to the page in the sandbox MDS Repository cannot be published to the mainline MDS Repository.

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

Sandbox Metadata Services Repository Data

Deploying the flexfield to a sandbox generates the Application Development Framework (ADF) business components of a flexfield in a sandbox MDS Repository for testing in isolation.

Caution: Don't modify flexfield segment display properties using Page Composer in a flexfield-enabled sandbox as these changes will be lost when deploying the flexfield to the mainline metadata.

Mainline Metadata Services Repository Data

The Oracle Fusion Applications database stores the single source of truth about a flexfield. When the flexfield is deployed, the ADF business component objects that implement the flexfield in the run time user interface are generated in the mainline MDS Repository from this source.

Deploying a flexfield to a sandbox creates a flexfield-enabled sandbox. Each flexfield-enabled sandbox contains only one flexfield.

You can test the run time behavior of a flexfield in the flexfield-enabled sandbox. If changes are needed, you 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.

When you deploy a flexfield sandbox, the process generates the name of the flexfield sandbox, and that flexfield sandbox is set as your current active sandbox. When you next sign in to the application, you can see the updated flexfield configurations. The Oracle Applications Cloud global header displays your current session sandbox.

Note: Unlike a standalone sandbox created using the Manage Sandboxes dialog box, the sandbox deployed for a flexfield contains only the single flexfield. You can manage flexfield sandboxes, such as setting an existing flexfield sandbox as active or deleting it, using the Manage Sandboxes dialog box.

When you deploy a flexfield to the mainline metadata after having deployed it to the sandbox, the sandbox-enabled flexfield is automatically deleted.

Sandbox MDS Repository Data

The sandbox data lets you test the flexfield in isolation without first deploying it in the mainline metadata where it could be accessed by users.

Caution: Don't modify flexfield segment display properties using Page Composer in a flexfield-enabled sandbox as these changes will be lost when deploying the flexfield to the mainline metadata.

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 dialog box in the Administrator menu of the Setup and Maintenance work area to activate and access a flexfield-enabled sandbox.

Note: Whether you use the Define Flexfields or Manage Sandboxes task flows to access a flexfield-enabled sandbox, you must sign out and sign back in before you can see the changes you deployed in the run time.

You cannot publish the flexfield from the sandbox to the mainline metadata. You must use the Define Flexfields task flow pages to deploy the flexfield for access by users of the mainline metadata because the flexfield configuration in the mainline metadata is the single source of truth.

Manage General Ledger Security

General Ledger Security: Explained

General ledger functions and data are secured through job roles, data access sets, and segment value security rules.

Functional Security

Functional security, which is what you can do, is managed using job roles. The following job roles are predefined for Oracle Fusion General Ledger:

  • General Accounting Manager

  • General Accountant

  • Financial Analyst

Each job role includes direct privilege grants, as well as duty role assignments, to provide access to application functions that correspond to their responsibilities. For example, the General Accounting Manager role grants comprehensive access to all General Ledger functions to the general accounting manager, controller, and chief financial officer in your organization.

Data Security

Data security, which controls what action can be taken against which data, is managed using:

  • Data access sets

  • Segment value security rules

Data access sets can be defined to grant access to a ledger, ledger set, or specific primary balancing segment values associated with a ledger. You decide whether each data access set provides read-only access or read and write access to the ledger, ledger set, or specific primary balancing segment values, which typically represent your legal entities that belong to that ledger. Primary balancing segment values without a specific legal entity association can also be directly assigned to the ledger.

Segment value security rules control access to data that is tagged with the value set values associated with any segment in your chart of accounts.

Security Assignment

Use the Security Console to assign users roles (job roles, as well as roles created for segment value security rules or others). Use the Manage Data Access Set Data Access for Users task to assign users data access sets as the security context paired with their General Ledger job role assignments.

For more information about security assignments and managing data access for users, see the Securing Oracle ERP Cloud guide.

Data Access Sets secure access to ledgers, ledger sets, and portions of ledgers using primary balancing segment values. If you have primary balancing segment values assigned to a legal entity, then you can use this feature to secure access to specific legal entities.

You can combine ledger and ledger set assignments in single data access sets if the ledgers share a common chart of accounts and calendar. If you have primary balancing segment values assigned to a legal entity within the ledger, then you can use data access sets to secure access to specific legal entities. You can also secure access to primary balancing segments assigned directly to the ledger.

When a ledger or ledger set is created, a data access set for that ledger or ledger set is automatically created, giving full read and write access to those ledgers. You can also manually create data access sets to give read and write access, or read-only access to entire ledgers or portions of the ledger represented as primary balancing segment values.

The following figure shows that a data access set consists of an access set type and an access level. The access set type can be set to full ledger or primary balancing segment value. The access level can be read only or read and write.

This figure shows the components of a data access set.
A data access set has an access set type and an access level.

The Full Ledger access set type provides access to the entire ledger or ledger set. This could be for read-only access or both read and write access to the entire ledger.

The Primary Balancing Segment Value access set type provides access to one or more primary balancing segment values for that ledger. This access set type security can be specified by parent or detail primary balancing segment values. The specified parent value and all its descendants, including middle level parents and detail values are secured. You can specify read only, read and write access, or combination of both, for different primary balancing segment values for different ledgers and ledger sets.

For more information about security assignments and managing data access for users, see the Securing Oracle ERP Cloud guide.

This example shows a data access set that secures access by using primary balancing segment values that correspond to legal entities.

Scenario

The following figure shows a data access set for the US Financial Services Ledger. The access set type is Primary Balancing Segment Value, with each primary balancing segment value representing different legal entities. Read-only access has been assigned to primary balancing segment value 131, which represents the Insurance legal entity. Read and write access has been assigned to primary balancing segment values 101 and 102, which represent the Banks and Capital legal entities.

For this data access set, the user can:

  • View the journals, balances, and reports for primary balancing segment value 131 for the Insurance legal entity.

  • Create journals and update balances, as well as view journals, balances and reports for primary balancing segment value 101 and 102 for legal entities Banks and Capital.

This figure shows an example of a data access set
with two levels of access.
Note: In financial reporting, the list of ledgers isn't secured by data access sets when viewing a report in Preview mode. Users can view the names of ledgers they don't have privileges to view. However, the data from a secured ledger doesn't appear on the report.

For more information about security assignments and managing data access for users, see the Securing Oracle ERP Cloud guide.

Set up segment value security rules on value sets to control access to parent or detail segment values for chart of accounts segments, also called flexfield segments. Segment value security rules restrict data entry, online inquiry, and reporting.

Secured Value Sets

When you enable security on a value set, access to all values for that value set is denied. To control access to value set values, you enable security on the value set, create conditions, and then assign the conditions to roles. The roles should be created solely for the purpose of segment value security. The roles are then assigned to users.

If a value set is secured, every usage of that value set in a chart of accounts structure instance is secured. For example the same security applies if that value set is:

  • Used for two or more segments in the same chart of accounts, such as the primary balancing and intercompany segments

  • Shared across different segments of different charts of accounts

Secured Segment Values

Segment value security applies mainly when data is created or updated, and when account combinations are queried. When you have access to secured account values, you can view and use those secured values across all modules of the applications where there are references to accounting flexfields including:

  • Transaction entry pages

  • Balances and transactions inquiry pages

  • Setup pages

  • Reports

On setup pages, you can still view referenced account combinations with secured account values, even if you haven't been granted access to those secured values. However, if you try to update such references, you can't use those secured values. On reports, you can view balances for secured account values only if you have access to those secured values.

Note: You can enforce segment value security for inquiries and reporting based on any hierarchy, even hierarchies that aren't published to the reporting cube.

Segment Value Security Implementation

You implement segment value security using the Security Console and these pages: Manage Value Sets, Manage Chart of Accounts Structures, Publish Account Hierarchies.

The following figure shows the steps for defining and implementing security rules for segment values.

This figure shows the steps to define and implement
segment value security.

To define segment value security roles:

  1. Create segment value security roles.

  2. Enable security on the value set.

    Note: You can enable security only on value sets with a type of Independent.
  3. Create conditions for the rule.

  4. Create policies to associate the conditions with the role.

  5. Deploy the accounting flexfield.

  6. Publish the account hierarchies.

  7. Assign the role to users.

Whenever you assign segment value security roles to a user, the rules from the user's assigned roles can be applied together. All of the segment value security roles assigned to a user pertaining to a given value set are simultaneously applied when the user works with that value set. For example, one rule provides access to cost center 110 and another rule provides access to all cost centers. A user with both of these segment value security rules has access to all cost centers when working in a context where that value set matters.

Segment Value Security Conditions

When you create a condition, you specify an operator. The following table describes the operators that you can use.

Operator Usage

Equal to

  • Provides access to a specific detail or child value.

  • Don't use to provide access to a parent value.

Not equal to

  • Provides access to all detail and child values, except the one that you specify.

  • Don't use to provide access to a parent value.

Between

  • Provides access to a detail range of values.

Is descendant of

  • Provides access to the parent value itself and all of its descendants including middle level parents and detail values.

Is last descendant of

  • Provides access to the last descendants for example, the detail values of a parent value.

Tip: For the operators Is descendant of and Is last descendant of:
  • Specify an account hierarchy (tree) and a tree version to use these operators.

  • Understand that the security rule applies across all the tree versions of the specified hierarchy, as well as all hierarchies associated with the same value set of the specified hierarchy.

You can set up segment value security rules on value sets to control access to parent or detail segment values for chart of accounts segments. Segment value security rules restrict data entry, online inquiry, and reporting.

The following example describes why and how you might want to use segment value security.

Securing Values for the Cost Center and Account Segments

For this scenario, only certain users should have access to the Accounting cost center and the US Revenue account. To create a complete data security policy that restricts segment value access to those users:

  1. Plan for the number of roles that represent the unique segment value security profiles for your users. For this scenario, you can create two roles, one for the cost center segment and one for the account segment.

  2. Use the Security Console to create the roles. Append the text SVS-role to the role names so it's clear the roles are solely for segment value security. For this scenario, you create roles Accounting Cost Center-SVS Role and US Revenue Account-SVS Role.

  3. Use the Manage Segment Value Security Rules task to enable security on the cost center and account value sets associated with the chart of accounts.

  4. Create a condition for each value set. For example, the condition for the Accounting cost center is that the cost center is equal to Accounting.

  5. Create a policy to associate the conditions to the roles. For example, create a policy to assign the condition for the Accounting cost center to the role Accounting Cost Center-SVS Role.

  6. Use the Security Console to assign the appropriate role to the appropriate user. For example, assign the role Accounting Cost Center-SVS Role to the users who should have access to the Accounting cost center.

This example demonstrates how to enable security on a chart of accounts to control access to specific segment values.

The following table summarizes the key decisions for this scenario.

Decisions to Consider In This Example

Which segment in the chart of accounts must be restricted?

Cost center

Which cost center values have to be granted to different users?

  • Child values 110 to 120

  • Child value 310

  • Parent value 400 and all its children

  • All cost centers

What's the name of the value set for the segment with the Cost Center label?

Cost Center Main

What's the name of the user who can access cost centers 110 to 120?

Casey Brown

What's the name of the tree for the accounting flexfield?

All Corporate Cost Centers

What version of the tree hierarchy does the condition apply to?

V5

Summary of the Tasks and Prerequisites

This example includes details of the following tasks you perform when defining and implementing segment value security.

  1. Define roles for segment value security rules.

  2. Enable segment value security for the value set.

  3. Define the conditions.

  4. Define the policies.

  5. Deploy the accounting flexfield.

  6. Publish the account hierarchies.

  7. Assign segment value security roles to users.

Perform the following prerequisites before enabling security on a chart of accounts:

  • To work with the Security Console, you need the IT Security Manager role assigned to your user setup.

  • To work with value sets and profile options, you need the Financial Application Administrator role.

  • Set the Enable Data Security Polices and User Membership Edit profile to Yes.

Defining Roles for Segment Value Security Rules

To create a complete data security policy, create the roles first so that they're available for assignment to the segment value security rules.
  1. In the Tools work area, open the Security Console.

  2. Perform the following steps four times to create four roles.

  3. Click Create Role.

  4. On the Create Role page, complete the fields as shown in this table, and then click Next, Next, Next, Next, Next, Save and Close.

  5. Click OK and complete the fields, as shown in this table.

    Field Role 1 Role 2 Role 3 Role 4

    Role Name

    Cost Center 110-120 SVS Role

    Cost Center 310 SVS Role

    Cost Center 400 SVS Role

    Cost Center All SVS Role

    Role Code

    CC_110_120_SVS_ROLE

    CC_310_SVS_ROLE

    CC_400_SVS_ROLE

    CC_ALL_SVS_ROLE

    Role Category

    Default

    Default

    Default

    Default

    Description

    Access to cost centers 110 to 120.

    Access to cost center 310.

    Access to parent cost center 400 and all its children.

    Access to all cost centers.

    The following figure shows the Create Role page for the first role, which is Cost Center 110-120 SVS Role. The role code, role category, and description fields are complete.

    This figure shows the Create Role page.

Enabling Segment Value Security for the Value Set
  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Segment Value Security Rules

  2. In the Value Set Code field, enter Cost Center Main and click Search.

  3. In the Search Results section, click Edit to open the Edit Value Set page.

  4. Select the Security enabled option.

  5. In the Data Security Resource Name field, enter Secure_Main_Cost_Center_Values.

  6. Click Save.

    The following figure shows the Edit Value Set page for the Cost Center Main value set. Security is enabled and a data security resource name has been entered.

    This figure shows the Edit Value Set page.

Defining the Conditions

Use conditions to specify the segment values that require security.

Segment value security rules that provide access to all segment values, and segment value security rules that provide access to single nonparent segment values, don't need a condition. Instead, you can define the policy to cover all values, and you can define a policy to cover a single nonparent segment value provided that you know the internal ID for that segment value. If you don't know the internal ID, you can create a condition for that single segment value.

In this scenario, the internal ID for segment value 310 isn't known, so the following steps create all of the conditions, except for the access to all cost centers, which the policy definition can cover.

  1. Click Edit Data Security to open the Edit Data Security page.

  2. On the Condition tab, click Create to open the Create Database Resource Condition window.

  3. Enter CC 110 - 120 in the Name field.

  4. Enter Cost Centers 110 to 120 in the Display Name field.

  5. Accept the default value of All for the Match field.

    Matching to All means that all of the condition rows apply simultaneously and all of them must be met in identifying the values.

    Matching to Any means that any of the condition rows could apply. For example, if you create multiple condition rows, each of which on its own is an alternative scenario for identifying the values that apply, you would select Match to Any.

    Because this example only has one condition row, the Match selection doesn't matter. If however, you define multiple condition rows for segment value security, you would have to select Match to Any, because a single account value can't satisfy multiple account value-based conditions.

  6. Click Add in the Conditions section.

  7. Select VALUE for the Column Name field.

  8. Select Between for the Operator field.

    Note: You can select one of the following operators: Equal to, Not equal to, Between, Is descendant of, Is last descendant of.

  9. Enter 110 in the first Value field and 120 in the second Value field.

    The following figure shows the Create Database Resource Condition page for the condition named CC 110 - 120. The display name is Cost Centers 110 to 120, and one condition is defined. The condition has a column name of VALUE, an operator of Between, and the specified values are 110 and 120.

    This figure shows the Create Database Resource
Condition page.

  10. Click Save.

  11. To create the next database resource condition for segment value 310, click Create on the Condition tab.

  12. Enter CC 310 in the Name field.

  13. Enter Cost Center 310 in the Display Name field.

  14. Click Add in the Conditions section.

  15. Select VALUE for the Column Name field.

  16. Select Equal to for the Operator field.

  17. In the Value field, enter 310.

    The following figure shows the definition of the second condition.

    The following figure shows the Create Database Resource Condition page for the condition named CC 310. The display name is Cost Center 310, and one condition is defined. The condition has a column name of VALUE, an operator of Equal to, and the specified value is 310.

    This figure shows the Create Database Resource
Condition page.

  18. Click Save.

  19. To create the next database resource condition for parent value 400, click Create on the Condition tab.

  20. Enter CC 400 in the Name field.

  21. Enter Parent Cost Center 400 in the Display Name field.

  22. In the Condition section, click Add.

  23. Select VALUE for the Column Name field.

  24. Select the Tree Operators option.

  25. For the Operator field, select Is a last descendant of, which restricts access to the parent cost center 400 and all of its children, including intermediary parents.

    Note: For the Tree Operators field, you can only select Is a last descendant of or Is a descendant of.

  26. In the Value column, click the Select Tree Node icon to open the Select Tree Node window.

    The following figure shows the Select Tree Node window. Values are required for the Tree Structure, Tree, and Active Tree Version fields. The window also includes these Tree Node options: Specify primary keys, Select from hierarchy.

    This figure shows the Select Tree Node window.

  27. In the Tree Structure field, select Accounting Flexfield Hierarchy. This signifies that you are choosing among trees that are used as accounting flexfield, or charts of accounts, hierarchies.

  28. In the Tree field, select All Corporate Cost Centers.

  29. In the Active Tree Version field, select V5.

  30. In the Tree Node field, select the Select from hierarchy button. The Tree Node section opens.

  31. In the Tree Node section, expand the nodes and select 400.

    The following figure shows the Select Tree Node window after completing the fields in steps 27 through 31.

    This figure shows the Select Tree Node window.

  32. Click OK.

    The following figure shows the resulting Create Database Resource Condition page for the condition named CC 400. The display name is Parent Cost Center 400 and one condition is defined. The condition has a column name of VALUE, an enabled Tree Operators option, an operator called Is a last descendant of, and a value of 400.

    This figure shows the Create Database Resource
Condition page.

  33. Click Save.

Defining the Policies

Create policies to assign conditions to segment value security roles.
  1. On the Edit Data Security page, click the Policy tab.

  2. Click Create to open the Create Policy window.

  3. On the General Information tab, enter Policy for 110-120 in the Name field.

  4. Accept the default value of General Ledger in the Module field.

  5. Enter 9/1/16 in the Start Date field.

    The following figure shows the General Information tab on the Create Policy page for the policy named Policy for 110-120. The start date for the policy is 9/1/16.

    This figure shows the General Information tab on
the Create Policy page.

  6. Select the Role tab and click Add to open the Select and Add window.

  7. Enter 110 in the Role Name field.

  8. Select hcm in the Application field.

    Roles with the Default category are created in the hcm application.

  9. Click Search.

    The following figure shows the Select and Add Roles window with the search results. The role retrieved by the search results is named Cost Center 110-120 SVS Role.

    This figure shows the Select and Add Roles window.

  10. Select Cost Center 110-120 SVS Role and click OK.

    The following figure shows the Role tab on the Create Policy page with the role that was populated by the search results.

    This figure shows the Role tab on the Create Policy
page.

  11. Select the Rule tab.

  12. Accept the default setting of Multiple Values in the Row Set field.

    Note: The Row Set field determines the range of value set values affected by the policy.
    • If Multiple Values is selected, a condition must be specified.

    • If All Values is selected, then the policy grants access to all values in the value set and no condition is needed.

    • If Single Value is selected, then the internal Value ID for the segment value must be specified and no condition is needed.

  13. Click Search on the Condition field.

  14. Select Cost Centers 110 to 120 for the Condition field and click OK.

    The following figure shows the Rule tab on the Create Policy page. The selected row set is Multiple Values and the condition is Cost Centers 110 to 120.

    This figure shows the Rule tab on the Create Policy
page.

  15. Click Save and Close.

  16. Click OK to confirm.

  17. Repeat steps 2 through 13 to create the rest of the policies, using the values in the following table.

    Field Policy 2 Policy 3 Policy 4

    General Information tab, Name

    Policy for 310

    Policy for 400

    Policy for all cost centers

    General Information tab, Start Date

    9/1/16

    9/1/16

    9/1/16

    Role tab, Role Name

    Cost Center 310 SVS Role

    Cost Center 400 SVS Role

    Cost Center All SVS Role

    Rule tab, Row Set

    Multiple Values

    Multiple Values

    All Values

    Rule tab, Condition

    Cost Center 310

    Parent Cost Center 400

    Not Applicable

  18. Click Done.

Deploying the Accounting Flexfield

You must deploy the accounting flexfield for the segment value security changes to take effect.
  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Chart of Accounts Structures

  2. In the Module field, select General Ledger and click Search.

  3. Select the row for the Accounting Flexfield and click Deploy Flexfield.

    The following figure shows the Manage Chart of Accounts Structure page after searching for General Ledger modules. The search results display a row with a key flexfield named Accounting Flexfield.

    This figure shows the Manage Chart of Accounts
Structures page.

  4. Click OK.

Publishing the Account Hierarchies

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Publish Account Hierarchies

  2. In the Hierarchy field, select All Corporate Cost Centers.

  3. In the Hierarchy Version field, select V5.

  4. Click Search.

  5. In the Search Results section, expand the hierarchy row.

  6. Select the row for the hierarchy version V5.

  7. Click Publish.

  8. Click OK.

Assigning Segment Value Security Roles to Users

  1. In the Tools work area, open the Security Console.

  2. Enter Cost Center 110-120 SVS Role in the Search field and click Search.

  3. In the Search Results section, select the down arrow icon and select Edit Role.

    The following figure shows the Roles page and the available menu options, including Edit Role, for the role named Cost Center 110-120 SVS Role.

    This figure shows the Roles page and the Edit Role
menu option for the selected role.

  4. Click Next four times to navigate to the Edit Role: Users page.

  5. Click Add User.

  6. Enter Casey in the Search field and click Search.

  7. Click Add User to Role to add Casey Brown to the role.

  8. Click OK to confirm.

    The following figure shows the Edit Role page for the Cost Center 110-120 SVS Role with the user Casey Brown selected.

    This figure shows the Users section on the Edit
Role page.

  9. Repeat steps 2 through 8 to add the other roles to different users as needed.

Difference in Data Security for GL Features Directly and Indirectly Based on the Balances Cube

In certain cases, differences in data security can appear depending on whether the GL feature being used is directly or indirectly based on the balances cube. For example, this can occur when a user is assigned multiple data access sets for the same balances cube with different security specifications for ledger or primary balancing segment value access, or when segment value security rule assignments are involved.

General Ledger features based directly on the balances cube are:

  • Inquire on Detail Balances

  • Account Monitor

  • Account Inspector

  • Financial Reporting

  • Smart View

  • Allocations

All other General Ledger features are indirectly based on the balances cube.

When using features indirectly related to the balances cube, you select a specific data access set and you work only with that one data access set at a time. The defined ledger and primary balancing segment value access for the selected data access set are enforced.

When using features directly related to the balances cube, the cumulative effects of your combined data access sets for that balances cube are enforced. From your combined data access sets for that cube, balances cube security separately constructs the access filter for the ledger dimension and primary balancing segment values dimension independently of the other dimensions. This means the specific combination of ledger and primary balancing segment values access as defined in each distinct data access set are not enforced as such. Instead, you have access simultaneously to all the ledgers and all the primary balancing segment values granted to you through your combined data access sets.

Note: Balances cube security grants access to all values of the balancing segment value set for a data access set defined as either of the following:
  • Full ledger

  • All Values: Specific Balancing Segment Values Access Type

With segment value security rules assigned to you through your various roles, the security rules are in effect simultaneously whether working directly or indirectly with the balances cube.

Segment value security rules are specified for a particular value set. Therefore, as you are working on anything that references the secured value set, all segment value security rules for that value set that are assigned to you through any of your roles are in effect at the same time, regardless of the specific role the rule was assigned to. In other words, segment value security rules are cumulative, or the union of all the segment value security rules you have assigned to you through your roles. If you have one role assigned to your user that only grants access to cost center 200, and another role that grants access to cost centers 300 through 500, then you have access to cost centers 200 and 300 through 500.

When using features indirectly based on the balances cube, such as journal entry pages, the primary balancing segment values you can access are based on the intersection of:

  • Primary balancing segment values granted to you through your current selected data access set.

  • All of your assigned segment value security rules pertaining to the primary balancing segment value set across all of your assigned segment value security roles.

So, if a balancing segment value is only granted in either of the selected data access set or a segment value security role, that balancing segment value isn't available to you.

In contrast, for features directly based on the balances cube, your access is based on the cumulative union of:

  • Primary balancing segment values granted to you through all your assigned data access sets related to the balances cube that you're working with.

  • Any segment value security rule grants to that primary balancing segment value set across all of your segment value security role assignments.

Example

This setup is used to more clearly and comprehensively illustrate the difference in how security works for features directly and indirectly related to the balances cube with respect to data access sets and segment value security, though this might not generally reflect a real-life example.

In this example, your job role is assigned two different data access sets for the Vision Corporation ledger. The Vision Corporation 01 data access set is assigned primary balancing segment value 01, and the Vision Corporation 02 data access set is assigned primary balancing segment value 02. You are also assigned segment value security roles SVS 01 and SVS 03.

The following table lists the job role, data access set, and primary balancing segment value assignments for this example.

Job Role Data Access Set Primary Balancing Segment Value

General Accounting Manager

Vision Corporation 01

01

General Accounting Manager

Vision Corporation 02

02

The following table lists the primary balancing segment values that are assigned to you through the segment value security roles.

Segment Value Security Role Primary Balancing Segment Value

SVS 01

01

SVS 03

03

Select Vision Corporation 01 Data Access Set

For features indirectly based on the balances cube, you can access primary balancing segment value 01. This segment value represents the intersection of the Vision Corporation 01 data access set and the SVS 01 and SVS 03 segment value security roles.

Neither your selected data access set, nor your segment value security roles provide access to Company 02, and your selected data access set Vision Corporation 01 and your cumulative segment value security roles SVS01 and SVS03 only intersect on primary balancing segment value 01, and not on 03.

For features directly based on the balances cube, you can access primary balancing segments 01, 02, and 03. These segment values represent the union of your assigned data access sets and segment value security roles. With the balances cube, all data access sets assigned to you that are related to the balances cube you're working with apply simultaneously, regardless of the data access set you selected to work with in the application.

Select Vision Corporation 02 Data Access Set

For features indirectly based on the balances cube, you can't access any primary balancing segment value because none of the values from the Vision Corporation 02 data access set and SVS 01 and SVS 03 segment value security roles intersect.

For features directly based on the balances cube, you can access primary balancing segments 01, 02, and 03. These values represent the union of your assigned data access sets and segment value security roles.

FAQs for Manage General Ledger Security

When does security take effect on chart of accounts value sets for balances cubes?

For new security policies to be effective, the security policies must be defined before the account hierarchies are published to the cube. When you create segment value security rules or change an existing rule that is based on a hierarchical filter, you must republish the tree version. Use the Publish Account Hierarchies page to republish the tree version and for the security to become effective.

Note: Changes to an account hierarchy previously published to the balances cube require that the hierarchy be republished to the cube to reflect the updated hierarchy.

What happens when changes are made to an account hierarchy that is referenced in segment value security rules?

The tree is set from an active to a draft state. The rules referencing the account hierarchy become ineffective.

After making changes to your hierarchy, you can submit the Process Account Hierarchies process to automatically run the required steps for processing account hierarchies updates in one submission, including:

  • Tree audit

  • Tree activation

  • Row flattening

  • Column flattening

  • Maintain value set

  • Maintain account hierarchy

  • Publish hierarchy

With a successful audit process, the hierarchy is set back to an active status. The rules referencing the account hierarchy go back to being effective using the updated hierarchy.

Run the row and column flattening processes for the updated hierarchy as the flexfield component in the application as well as other hierarchy processes rely on the flattened hierarchy data to come up with the list of values available to the user to properly secure the correct account values.

Run the Maintain Value Sets and Maintain Chart of Account Hierarchies processes, particularly for hierarchy changes to the primary balancing segment value set if such values are referenced in your primary balancing segment value based data access sets. These processes update the data that is required to regulate ledger and data access security by storing:

  • Primary balancing segment values assigned to a ledger.

  • Specific child balancing segment values assigned to a data access set through parent value assignments.

How can I secure the data in GL balances cubes?

Use data access set and segment value security to secure dimension values such as ledger and chart of account values. For chart of accounts dimension values, security restricts the display of data associated with the secured values, but not the selection of the values themselves. For example, when submitting a report, you can select company value 100 in your report definition when selecting the Point of View, even if you weren't granted access to that company value. However, you can't see the data associated with company 100 in your report.

Define Cross-Validation Rules

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

For example, your organization has determined that the company Operations can't use the cost center Marketing. You can define a cross-validation rule such that, if the company is Operations, then validate that the cost center isn't Marketing. New account combinations have to satisfy all of the cross-validation rules enabled for the chart of accounts before they can be created.

Entry and Maintenance

You can create cross-validation rules in the Setup and Maintenance work area using the following tasks:

  • Offering: Financials

  • Functional Area: General Ledger

  • Task: Create Cross Validation Rules in Spreadsheet

  • Offering: Financials

  • Functional Area: Financial Reporting Structures

  • Task: Manage Cross-Validations Rules

Use the Create Cross Validation Rules in Spreadsheet task to quickly enter large volumes of rules during implementation. Use the Manage Cross-Validation Rules task to add a one-off rule or to edit existing rules. To edit the error messages for cross-validation rules, use the following task in the Setup and Maintenance work area:

  • Offering: Financials

  • Functional Area: Financial Reporting Structures

  • Task: Manage Messages for General Ledger

Tip: When you export or import cross-validation rules to a new instance using an export or import project in the Functional Setup Manager, you must add the Manage Messages for General Ledger task before the Manage Cross-Validation Rules task. You must export or import the messages before exporting or importing the cross-validation rules.

Existing Account Combinations

If account combinations already exist that violate newly enabled cross-validation rules, those account combinations continue to be valid. Before disabling existing account combinations that violate your rules and that you no longer use, move the balances in those accounts to the correct accounts. Then disable the account combinations manually to prevent further posting. Best practice is to define and enable cross-validation rules before: account combinations are created, transactions or journal entries are imported or entered, balances are loaded.

Cross-Validation Rules: Explained

You can control the creation of new key flexfield code combinations by defining cross-validation rules. A cross-validation rule defines validation across segments and enforces whether a value of a particular segment can be combined with specific values of other segments to form a new combination.

The following table compares segment validation to cross-segment validation:

Type of validation Type of control

Segment validation

Controls the values you can enter for a particular segment

Cross-segment validation

Controls the combinations of values that administrators and end users can create for key flexfields

Note: You can use cross-validation rules for any key flexfield that has cross-validation enabled. See the documentation for your key flexfield to determine if it supports cross validation.

Cross-validation rules prevent the creation of combinations with values that can't coexist in the same combination. For example, your company requires that all revenue accounts must have a specific department. Therefore, account combinations that have revenue account values, such as all values between 4000 and 5999, must have a corresponding department value other than 000, which indicates no department is specified. You can define cross-validation rules that disallow creation of combinations with incompatible segments, such as 4100-000 or 5000-000.

Alternatively, suppose your accounting key flexfield has an Organization segment with two possible values, 01 and 02. You also have a Natural Account segment with many possible values, but company policy requires that Organization 01 uses the natural account values 001 to 499 and Organization 02 uses the natural account values 500 to 999. You can create cross-validation rules to ensure that users cannot create a general ledger account with combinations of values such as 02-342 or 01-750.

The following aspects are important to understanding cross-validation rules:

  • Rule Definitions

  • Enforcement

  • Timing

Rule Definitions

The following table contains definitions used in cross-validation rules:

Rule Definition Purpose

Name

Uniquely identifies cross-validation rules in a deployment.

Description

Helps administrators identify the purpose of the rule.

Error message

Explains why the attempted combination violates the rule.

Start Date, End Date

Indicates the period of time when the rule is in effect.

Enabled

Determines whether the rule is enforced.

Condition filter

Determines the conditions in which an enabled cross-validation rule should be evaluated.

Validation filter

Determines the validation that the rule enforces when that condition is met.

When the event specified in the condition filter is applicable, the validation filter condition must be satisfied before the combination can be created. If the event specified in the condition filter isn't applicable, then the combination is considered to pass the rule and the rule won't be evaluated even if it is enabled.

Note: If you don't specify any statement in the condition filter, then the condition is always true and the rule is always evaluated.

Enforcement

Cross-validation prevents creation of invalid combinations by administrators using maintenance pages and end users using dynamic insertion in foreign key pages.

Enabled rules are enforced when there is an attempt to create a new combination of segment values. Disabled rules are ignored. Deleting the rule has the same effect, but you can re-enable a disabled rule.

Timing

When users attempt to create a new combination, the key flexfield evaluates any cross-validation rules that are enabled and in effect.

Note: Cross-validation rules have no effect on combinations that already exist. The flexfield treats any existing invalid combinations that pre-date the rule as valid.

If you want to prevent users from using previously existing combinations that are no longer valid according to your cross-validation rules, manually disable those combinations using the combinations page for that key flexfield.

When defining a cross-validation rule, specify a start and end date to limit the time when the rule is in effect. The rule is valid for the time including the From and To dates.

Cross-Validation Rules: Points to Consider

To validate the key flexfield combinations of segment values across segments, optimize your cross-validation rules to improve the experience of administrators and users.

Consider the following when defining cross-validation rules:

  • Filters

  • Rule Complexity

  • Maintenance

Filters

A cross-validation rule includes a condition filter and a validation filter. The rule is evaluated using the following logical order: If the condition filter is satisfied, then apply the validation filter.

The condition filter describes the event when the rule is evaluated. If the event specified in the condition filter isn't applicable, then the rule isn't evaluated, even if enabled. When the event specified in the condition filter is applicable, the validation filter condition must be satisfied before the combination can be created.

For example, your organization has determined that a certain company value called Operations can't use a specific cost center called Marketing. You can define a cross-validation rule to validate your combinations.

  1. The rule evaluates the company condition filter.

  2. When company is equal to Operations, the rule evaluates the cost center validation filter.

  3. When cost center is equal to Marketing, the rule prevents a combination from being created.

  4. The error message you defined for the rule displays to inform the user that the attempted combination violates the rule.

Such a rule doesn't affect the creation of combinations with Marketing cost center and company values other than Operations.

Rule Complexity

For optimal performance and ease of understanding, define several simple validation rules instead of using one complex rule. Simple validation rules let you provide a more specific error message and are easier to maintain over time.

Avoid rules that control validation across more than two segments, where possible. While you can define cross-validation rules that span two or more segments, it becomes difficult to interpret cross-validation error messages and rectify invalid key flexfield combinations.

Maintenance

To maintain consistent validation, review existing key flexfields when you update your cross-validation rules. Regardless of your current validation rules, you can use an existing key flexfield combination if it's enabled. Therefore, to ensure accurate validation, you must review your existing combinations and disable any combinations that don't match the criteria of your new rules.

Tip: To keep this type of key flexfield maintenance to a minimum, decide upon your cross-validation rules when you first set up your key flexfield structure. Define cross-validation rules before creating combinations and before combinations are used in transactions.

To prevent users from using existing combinations that are no longer valid according to your cross-validation rules, disable them using the combinations page.

Cross-Validation Rules Spreadsheet: Explained

The rapid implementation solution provides a template for defining cross-validation rules in a spreadsheet. Cross-validation rules determine whether a selected value for a particular segment of an account combination can be combined with specific values in the other segments to form a new account combination.

In the Setup and Maintenance work area, use the following:

  • Offering: Financials

  • Functional Area: General Ledger

  • Task: Create Cross Validation Rules in Spreadsheet

Note: The spreadsheet can only create cross-validation rules. To update existing cross-validation rules, use the Manage Cross-Validation Rules task in the Setup and Maintenance work area.

Spreadsheet Overview

The cross-validation rules spreadsheet includes two sheets. One sheet has instructions and the other sheet provides the template for creating the cross-validation rules. The Instructions sheet includes:

  • An overview

  • An explanation of the template

  • Steps to fill in the template

  • An example

The following figure shows the Create Cross-Validation Rules sheet.

This figure shows the Create Cross-Validation Rules
sheet.

The following table describes each field and column on the sheet.

Field or Column Description

Worksheet Status

The upload results for the worksheet. The application updates this field when you submit the spreadsheet.

Chart of Accounts

The chart of accounts for which the cross-validation rules are defined.

Changed

The indicator that the row has been updated. The application updates this field.

Row Status

The upload results for the row. The application updates this field when you submit the spreadsheet.

Name

The name that uniquely identifies the cross-validation rules in a deployment.

Description

The purpose for the cross-validation rule.

Error Message

The explanation to users for why the attempted combination violates the cross-validation rule.

Condition Filter Segment

The segments of the chart of accounts that constitute the condition filter.

Condition Filter Values

The values of the condition filter segment that determine whether the cross-validation rule is evaluated.

Validation Filter Segment

The segments of the chart of accounts that constitute the validation filter.

Validation Filter Values

The values of the validation filter segment used to enforce a new account combination.

Note: Cross-validation rules created from the spreadsheet are automatically enabled and don't have a start or end date.

Steps to Use the Template

To use the spreadsheet template:

  1. Select the chart of accounts.

  2. Enter a suitable name, description, and error message in the respective columns.

  3. Select the condition filter segment. To add more than one segment to the condition filter, use the next row. Repeat the rule name and select the condition filter segment.

  4. Provide the segment values that constitute the condition filter in the Condition Filter Values column.

    • To select multiple detail values, enter the detail values separated by commas. For example: 5501,5502,5503.

    • To select a range, enter the detail values separated by hyphens. You can enter multiple ranges using the comma as the range separator. For example: 3001-3030,3045-3200.

    • To select all detail values that are descendants of a parent, enter the parent value. You can enter multiple parent values using commas as the separator. For example: 1000,2000.

    • You could enter all of the previously listed values in the same cell. For example: 1000,2000,3001-3030,3045-3200,5501,5502,5503.

    • To specify that a detail value should not be selected, prefix the value with the less than and greater than symbols <>. These symbols represent the Does Not Equal operator. For example, <>5501 means the rule applies when the segment value isn't equal to 5501.

      • This operator can't be used for parent values or ranges.

      • This operator can't be used more than once for the same rule and segment.

  5. Select the validation filter segment. To add more than one segment to the validation filter, use the next row. Repeat the rule name and select the validation filter segment.

  6. Provide the segment values that constitute the validation filter in the Validation Filter Values column in the same way as specified for the condition filter.

  7. Review the data that you entered and click Submit to publish the cross-validation rules.

  8. Review the upload results in the Worksheet Status and Row Status fields.

Creating Cross-Validation Rules in a Spreadsheet: Worked Example

This example shows how to create two cross-validation rules using the Cross-Validation Rules spreadsheet.

The following table summarizes key decisions for this scenario.

Decisions to Consider In This Example

What's the name of the chart of accounts?

US Chart of Accounts

What segments make up the chart of accounts?

  • Company

  • Department

  • Account

  • Product

What cross-validation rules have to be created?

  • Companies 131 and 151 have only one department, department 40. Department 40 produces only one product, represented by segment value 211. All account combinations for these two companies must have department 40 and product 211.

  • Company 202 has three manufacturing departments: 10,20,30. All three departments work only with products 235 and 236. All account combinations for company 202 must have only these three departments and these two products.

Creating Cross-Validation Rules

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: General Ledger

    • Task: Create Cross Validation Rules in Spreadsheet

  2. Sign into the application to open the spreadsheet.

  3. Complete the fields, as shown in this table, to create the rule for companies 131 and 151.

    Row 1 Values

    Name

    Companies 131 and 151

    Description

    Valid department and product for companies 131 and 151.

    Error Message

    Companies 131 and 151 can only be used with department 40 and product 211.

    Condition Filter Segment

    Company

    Condition Filter Values

    131,151

    Validation Filter Segment

    Department

    Validation Filter Values

    40

  4. Complete the fields, as shown in this table, to complete the rule for companies 131 and 151.

    Row 2 Values

    Name

    Companies 131 and 151

    Validation Filter Segment

    Product

    Validation Filter Values

    211

  5. Complete the fields, as shown in this table, to create the rule for company 202.

    Row 3 Values

    Name

    Company 202

    Description

    Valid products for company 202 manufacturing departments.

    Error Message

    Manufacturing departments 10, 20, and 30, of company 202, can only be used with products 235 or 236.

    Condition Filter Segment

    Company

    Condition Filter Values

    202

    Validation Filter Segment

    Product

    Validation Filter Values

    235,236

  6. Complete the fields, as shown in this table, to complete the rule for company 202.

    Row 4 Values

    Name

    Company 202

    Condition Filter Segment

    Department

    Condition Filter Values

    10-30

    The following figure shows the Create Cross-Validation Rules spreadsheet with the rules that were entered following steps 3 through 6.

    This figure shows the Create Cross-Validation Rules
spreadsheet after rule entry.

  7. Click Submit to upload the cross-validation rules.

  8. Click OK on the Upload Options window to accept the default setting.

  9. Review the upload results.

Cross-validation rules prevent specific combinations of segment values in account combinations. You can use the Manage Cross-Validation Rules task to edit existing rules or to create one-off rules.

Scenario

Your organization has a cross-validation rule called Companies 131 and 151, which restricts account combinations for those companies to department 40 and product 211. Account combinations for both companies should now include department 30. To edit the cross-validation rule, perform these steps.

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Cross-Validation Rules

  2. Select the chart of accounts for your organization and select the Companies 131 and 151 cross-validation rule.

    The following figure shows the section of the Edit Cross-Validation Rules page with the condition and validation filter details for companies 131 and 151. A condition is defined for company values equal to 131 or 151, and the validation specifies the department value equals 40 and the product value equals 211.

    This figure illustrates the condition and validation
filter details for companies 131 and 151.
  3. Click the Validation Filter icon.

  4. Click Add Fields and select the Department segment.

  5. Accept the default operator, which is Equals, and select department 30.

    The following figure shows the Validation Filter window with three validations: department equals 40, department equals 30, and product equals 211.

    This figure shows the Validation Filter window.
  6. Click OK.

  7. Click Save.

    The following figure shows the details for the updated validation on the Edit Cross-Validation Rules page. The validation specifies departments equal to 30 or 40, and the product equal to 211.

    This figure shows the detailed validation filter
on the Edit Cross-Validation Rules page.
  8. To update the error message, search for and select the Manage Messages for General Ledger task. Query the error message name for the cross-validation rule and edit the message to include department 30.

Managing Cross-Validation Rule Violations: How It Works

Cross-validation rules determine whether a selected value for a particular segment of an account combination can be combined with specific values in other segments to form a new account combination. The Manage Cross-Validation Rule Violations process lists and optionally disables account combinations that violate cross-validation rules for a given chart of accounts. The process also lets you preserve attributes of account combinations to prevent the Inherit Segment Value process from reenabling them.

After you define a cross-validation rule, you can run the Manage Cross-Validation Rule Violations process to:

  • Test that the rule is set up correctly.

  • Identify existing account combinations that violate the rule and optionally disable them.

How Cross-Validation Rule Violations Are Processed

Submit the process from the Scheduled Processes work area. The process evaluates all account combinations that are enabled and not end-dated when the process is submitted. The process is also affected by the Enabled option on the Manage Cross-Validation Rules page.

The following table describes the parameters for the process.

Name Description

Chart of Accounts

Select the chart of accounts for the applicable cross-validation rule.

Cross-Validation Rule

Select All or select a specific cross-validation rule.

Disable Accounts

Select from among the following options:

  • No: Only lists account combinations that violate the cross-validation rule, regardless of whether the cross-validation rule is enabled.

  • Yes: Disables account combinations that violate the cross-validation rule if the Preserve Attributes option for the account combination isn't set.

    Note: This option applies only to enabled cross-validation rules. Cross-validation rules that are disabled don't disable any account combinations.
  • Yes and Preserve Change:

    • Disables account combinations that violate the cross-validation rule if the Preserve Attributes option for the account combination isn't set.

    • Sets the Preserve Attributes option on account combinations to prevent the Inherit Segment Value process from reenabling them.

    Note: This option applies only to enabled cross-validation rules. Cross-validation rules that are disabled don't disable any account combinations.

At completion, the process produces the Cross-Validation Rule Violations report with information about the account combinations that were processed.

Define Account Hierarchies

Trees are hierarchical data models that you can use to organize data, apply business rules, control data access, and improve performance while querying. For example, an application maintains data of an organization called Vision Corporation that has two departments: Marketing and Finance. The Finance department has two functional divisions: Receivables and Payables. You can define a tree for Vision Corporation to establish a hierarchy across its departments, and their respective functional divisions. You can use the hierarchy to manage data at various levels of the organization.

To work with trees, in the Setup and Maintenance work area, use any of the following tasks:

  • Manage Tree Structures: To create and update tree structures. You must first define a tree structure to create a tree.

  • Manage Trees and Tree Versions: To create and update trees and their versions.

  • Manage Tree Labels: To create and update tree labels.

Tree Structures

As the name suggests, tree structures provide you the framework to organize data such that you can establish a hierarchy for use by the tree. So, similar to a template, a tree structure guides the creation of a tree.

Tree

A tree is an instance of the tree structure. The root node is the highest nodal point of a tree. Child nodes branch off from the root node. Child nodes at the same level, branching off from a common parent node, are called siblings. Leaves are details branching off from a node but not extending further down the tree hierarchy. You can create trees for multiple data sources and share them across applications.

Tree Versions

A tree by default has only one version. If required, you can create and maintain more than one editable tree version. At any point, only one tree version must be active. If you edit an existing version, it changes from active to draft. To use it again, you must set it to active. Similar to any other version control system, versions of trees are maintained to track all the changes that a tree undergoes in its life cycle.

Tree Labels

Tree labels are short names given to trees and tree structures. You can label the tree versions for better accessibility and information retrieval. When nodes are created in a tree, the existing tree labels are automatically assigned to the new tree nodes. You can use any table to store the labels and register the label data source with the tree structure.

Account hierarchies are defined in Oracle Fusion applications using tree functionality. Each account hierarchy is defined as a tree with one or more versions. Tree versions are used to track account hierarchies as they change over time. For example, an account hierarchy to summarize cost of goods has different accounts for 2011, versus 2010. The changes are in the business operations and affect the chart of accounts values.

Chart of accounts values can be associated with multiple hierarchies by defining multiple trees. Using multiple trees enable create financial reports for different target audiences. For example, you can use different hierarchies to track cost centers either by geography or line of business.

Using Account Hierarchies: Explained

Before setting up hierarchies, you may want to consider different hierarchy requirements for financial reporting, allocations, cross validation rules, revaluations, and chart of accounts mapping.

Financial Reporting and Allocations: You can use the same hierarchy for both reporting and allocations purposes, or you can have different hierarchies for reporting and for allocations purposes. Hierarchies that are used in financial reporting and allocations must be published to Oracle Essbase. You can select which hierarchies you publish to Essbase. Any hierarchy that is published to Essbase cannot have a single child value roll up to multiple parents. If you have requirements to have a single child roll up to multiple parents, it has to be defined using multiple hierarchies.

Cross Validation Rules, Revaluations, and Chart of Accounts Mappings: You need one hierarchy for each segment that is used for cross validation rules, revaluation, and chart of accounts mapping. Hierarchies used for cross validations, revaluations, or chart of accounts mapping have to be defined within the same hierarchy. The hierarchy must then be associated with a chart of accounts instance. You can only associate one hierarchy with a chart of accounts instance, per segment.

You can optionally publish this hierarchy to Essbase to use the same hierarchy for reporting and allocations. Note the restriction that any hierarchy that is published to Essbase cannot have a single child value roll up to multiple parents. If you require the same child to roll up to different parents within the hierarchy, then create a different hierarchy for reporting and allocation rules.

If you use the same hierarchical account relationships for financial reporting, allocations, cross validation rules, revaluations, and chart of accounts mapping definition, define one hierarchy. However, if you need multiple hierarchies, define the hierarchies using multiple trees.

Import Segment Values and Hierarchies: How Data Is Processed

Use the Import Segment Values and Hierarchies file-based data import to upload segment values and hierarchies from external sources into Oracle Fusion General Ledger. You can download a spreadsheet template to use to prepare your segment values and hierarchies data. The template contains an instruction sheet to help guide you through the process of entering your segment values and hierarchy information.

To access the template, complete the following steps:

  1. Navigate to the File-Based Data Import for Oracle Financials Cloud guide.

  2. In the Table of Contents, click File-Based Data Imports.

  3. Click Import Segment Values and Hierarchies.

  4. In the File Links section, click the link to the Excel template.

Follow these guidelines when preparing your data in the worksheet:

  • Enter the required information for each column. Refer to the tool tips on each column header for detailed instructions.

  • Do not change the order of the columns in the template.

  • You can hide or skip the columns you do not use, but do not delete them.

  • Do not change the format or data type of the columns, otherwise parsing errors could occur.

Settings That Affect the Segment Values and Hierarchies Import Process

The Segment Values and Hierarchies template contains an instructions tab, plus two tabs that represent the tables where the data is loaded.

Spreadsheet Tab Description

Instructions and CSV Generation

Contains instruction information about preparing and verifying the segment values and hierarchies data, understanding the format of the template, and loading and importing the data.

GL_SEGMENT_VALUES_INTERFACE

Enter information about the segment values that you are adding, such as the value sets, values, effective start and end dates, and whether to allow posting. You can import segment values for multiple value sets in a single worksheet.

GL_SEGMENT_HIER_INTERFACE

Enter information about the segment value hierarchies that you are adding, such as the tree version name, and parent and child values. You can import hierarchies for multiple value sets and tree versions in a single worksheet.

After you add the data, you can validate the information and check for errors by clicking the Validate Segment Values and Validate Segment Hierarchy buttons.

How Segment Values and Hierarchies Import Data Is Processed

To load the data into the interface tables and into the product:

  1. Click the Generate CSV button on the instructions tab to create a CSV file in a .zip file format.

  2. Save the .zip file locally.

  3. Navigate to the Scheduled Processes work area.

  4. Select the Load Interface File for Import process.

  5. For the Import Process parameter, select Import Segment Values and Hierarchies.

  6. For the Data File parameter, select the file that you saved in step 2.

  7. If the process ends in error or warning:

    1. Review the log and output files for details about the rows that caused the failure.

    2. Correct the errors in the spreadsheet.

    3. Repeat steps 1 through 6 until errors are resolved.

The Load Interface File for Import process loads the data from the file to the interfaces table and submits the Import Segment Values and Hierarchies process. This process imports the segment values and hierarchy information from the interface tables into General Ledger.

Importing Segment Values and Hierarchies: Explained

The Import Segment Values and Hierarchies process loads segment values and hierarchies if you maintain chart of accounts reference data outside Oracle Fusion applications. You can load the segment values and hierarchies by populating two tables: GL_SEGMENT_VALUES_INTERFACE and GL_SEGMENT_HIER_INTERFACE, and by running the Import Segment Values and Hierarchies process.

You can use the GL_SEGMENT_VALUES_INTERFACE table to load segment values and the GL_SEGMENT_HIER_INTERFACE table to load segment value hierarchies to Oracle Fusion applications. For more information about tables, see the Tables and Views for Oracle Financials Cloud guide.

Assigning Values for Columns in the GL_SEGMENT_VALUES_INTERFACE table

You must enter values in all columns of the interface table that require values for the Import Segment Values and Hierarchies process to be successful.

The following table describes the columns that require values.

Name Value

STATUS_CODE

Enter the value NEW to indicate that you are bringing new segment value data.

VALUE_SET_CODE

Enter the value set code for the segment values.

VALUE

Enter the segment value.

SUMMARY_FLAG

Select N if the segment value is a child value or Y if the segment value is a parent value.

ENABLED_FLAG:

Select Y to enable the segment value. Enter N to disable the segment value.

ACCOUNT_TYPE:

Enter the natural account type if the segment value is for a natural account segment.

  • A: Asset

  • L: Liability

  • E: Expense

  • O: Owner's Equity

  • R: Revenue

ALLOW_POSTING_FLAG

Select Y if posting is allowed for this segment value. Select N if posting is not allowed.

OBJECT_VERSION_NUMBER

Enter default value of 1.

The following table describes the columns that are optional.

Name Value

START_DATE_ACTIVE

Enter the start date of the segment value.

END_DATE_ACTIVE

Enter the end date of the segment value.

THIRD_PARTY_CTRL_ACCOUNT

Enter the third-party control account value. Valid values are: CUSTOMER, SUPPLIER, R for restrict manual journals, Y, and N.

FINANCIAL_CATEGORY

Enter a financial category value for Oracle Transactional Business Intelligence reporting. Valid values are values defined for the FINANCIAL_CATEGORY lookup type.

DESCRIPTION

Different description columns exist for different languages. To see segment value description in a different language installation, you populate the segment description for that language too.

The following columns should remain blank. The Import Segment Values and Hierarchies process uses them for internal processing, or doesn't currently use them.

  • CREATION_DATE

  • CREATED_BY

  • LAST_UPDATE_DATE

  • LAST_UPDATE_LOGIN

  • LAST_UPDATED_BY

  • SEGMENT_VALUE_INTERFACE_ID

  • REQUEST_ID

  • LOAD_REQUEST_ID

Assigning Values for Columns in the GL_SEGMENT_HEIR_INTERFACE table

You must enter values in all columns of the interface table that require values for the Import Segment Values and Hierarchies process to be successful.

The following table describes the columns that require values.

Name Value

STATUS_CODE

Enter the value NEW to indicate that you are loading new hierarchy data.

VALUE_SET_CODE

Enter the value set code for the segment values.

TREE_CODE

Enter the hierarchy name (tree code).

TREE_VERSION NAME

Enter the hierarchy version name (tree version name).

TREE_VERSION_START_DATE_ACTIVE

Enter the date that the tree version is activated.

TREE_VERSION_END_DATE_ACTIVE

Enter the date that the tree version is inactivated.

VALUE

Enter the segment value.

PARENT_VALUE

Select N if the segment value is a child value or Y if the segment value is a parent value.

DEPTH

Enter the depth of the hierarchy that shows the many ancestors the segment value has in the hierarchy.

OBJECT_VERSION_NUMBER

Enter default value of 1.

The following columns should remain blank. The Import Segment Values and Hierarchies process uses them for internal processing or doesn't currently use them.

  • CREATION_DATE

  • CREATED_BY

  • LAST_UPDATE_DATE

  • LAST_UPDATE_LOGIN

  • LAST_UPDATED_BY

  • SEGMENT_VALUE_INTERFACE_ID

  • REQUEST_ID

  • LOAD_REQUEST_ID

Naming Financial Reporting and Allocations Hierarchies: Points to Consider

You must publish hierarchies for financial reporting and allocations to Oracle Essbase cubes. When a hierarchy is published to an Essbase cube, a fully qualified member name is generated for each node in the hierarchy. This fully qualified member name is used to refer to the node in the hierarchy in financial reports and allocation rules.

Each combination of tree plus tree version is published as a different account hierarchy to Essbase cubes.

When a chart of accounts child or parent value is assigned to multiple hierarchy versions, the fully qualified member name includes the hierarchy version name.

Member Names and Financial Reporting and Allocations Hierarchies

You must consider the implications to your financial reports, allocation rules, and Smart View templates if the member name changes due to hierarchy changes. The points to considered are:

  • The member name for a member can change if you originally published a single hierarchy to a cube and later published another hierarchy. The change happens if the member includes the same chart of accounts value.

  • If the fully qualified member name changes, you must update existing financial reports, allocation rules, and Smart View templates that refer to that member. Otherwise, such processes have errors.

For example, only a single hierarchy version, V1, existed when you defined a financial report. The hierarchy version includes the chart of accounts value of 500 for a cost center. The path does not include a hierarchy version name, since there is only one hierarchy version in the cube. The fully qualified name path is 500.

Later, you publish a new hierarchy version, V2. The fully qualified member name changes since there are now two versions and cost center 500 is associated with two hierarchy versions, V1 and V2. When selecting the value 500, the cube has logic to uniquely identify the member. The fully qualified member name for the two hierarchy versions is now:

  • [All VF Cost Centers-V1].[999].[500]

  • [All VF Cost Centers-V2].[999].[500]

Note: The fully qualified member can also be shortened by the cube logic, such as [Cost_Center]@[Cost Center Level 29 Code]|[500].

Update configurations, such as financial reports, allocation rules, or Smart View queries that referenced the original name path of 500 with the correct name.

Initial Publishing of Account Hierarchies: Points to Consider

If you start with one version of a hierarchy and you add multiple versions of the hierarchy later, then the fully qualified member name changes. Therefore it is recommended that you always create at least two hierarchy versions before creating any financial reports or allocations. This will force the fully qualified member name path to be generated and refers to the full tree name, tree versions, and minimize the report maintenance, if you must add another version in future.

Recommendations

To avoid maintenance efforts when more hierarchies are published, it is recommended for you to follow these recommendations:

  • Create two tree versions of the same tree before creating any financial reports or allocations to force the fully qualified name to be generated.

  • Keep the two tree versions in sync always to guarantee fully qualified names are used in financial reports and allocations.

  • Use the same tree version names over time to avoid breaking your reports or configurations.

  • Use different hierarchies if you have requirements to roll the same child to more than one parent.

The initial configuration steps must be completed before the definition of any financial reports, allocation rules, or Smart View queries

Here's an example of the steps for initially configuring account hierarchies.

Scenario

Once the following steps are complete, you can create financial reports, allocation rules, and Smart View queries, using the version called Current in this example. The baseline version is published to enforce generation of the fully qualified name and minimization of changes in the future.

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Account Hierarchies

  2. Select the Create Tree icon.

  3. Create a hierarchy version for an account hierarchy that includes the definition of the hierarchies in a hierarchy version. Name the hierarchy version with a name that is consistently used across versions. For example, Current or other similar naming conventions. Use an effective start date equal to the beginning of the financial reporting period.

  4. Set the status to Active.

  5. Copy the hierarchy version. Name the hierarchy version to indicate that this version is just a copy. For example, Baseline.

  6. Set the copied hierarchy version status to Active because only active versions can be published to the cube.

  7. Provide the copied hierarchy version with an effective date range earlier than the original to ensure no effective date is overlapped.

  8. Don't make hierarchy changes to the hierarchy version that is copied (baseline) so that the two hierarchy versions are consistent.

  9. Publish both tree versions to the cube.

    1. In the Setup and Maintenance work area, go to the following:

      • Offering: Financials

      • Functional Area: Financial Reporting Structures

      • Task: Publish Account Hierarchies

    2. Search for your hierarchy.

    3. Publish.

Note: Review the published results using Smart View.

Maintain Account Hierarchies: Overview

This topic describes the best practices of maintaining and publishing the account hierarchies. Account hierarchies are used throughout Oracle Fusion General Ledger for creating financial reports, Smart View inquiries, allocation definitions, cross validation rules, and revaluation definitions.

Maintenance of Hierarchies: Explained

As your organization changes or there are updates to your chart of accounts values, you can make updates to your hierarchy versions. Changes must be in the two hierarchy versions to minimize errors related to member name paths in financial reports, allocation rules, or Smart View queries. Both hierarchy versions must be published to the balances cube.

To keep an audit history, copy the hierarchy version and use the copy as the version for audit history. After you copy the hierarchy version, modify that same version to use as the latest version. You do not have to change reports.

Hierarchy Versions Configuration

Perform the following steps before updating the current hierarchy version:

  1. Copy the current hierarchy version to create cost center 2011 to keep an audit history for year 2011.

  2. Update the effective date for the Current hierarchy version to the current period. Set the effective dates for the copied hierarchy version to what the past dates were.

  3. Make all of your current hierarchy changes to the Current hierarchy version.

  4. Set the status to Active again.

  5. Delete the Baseline hierarchy version in the Manage Account Hierarchies page. You do not unpublish the hierarchy from the cube, as long as you follow the naming conventions discussed in the following steps.

  6. Copy the Current hierarchy version and name it Baseline. You must name it the same exact name because Baseline still exists in the cube. The procedures overwrite the hierarchy version named Baseline in the cube.

  7. Use effective dates that do not overlap and that are before periods used by previously active hierarchy versions.

  8. Set the status for the Baseline hierarchy version to Active.

  9. Publish both hierarchy versions, Current and Baseline, to their respective cube.

  10. Publish the cost center 2011 to the cube if the version is still needed for financial reporting, Smart View queries, or allocation rules.

  11. Review the published results using Smart View.

You have the following three versions:

  1. The new copied version: This version is used to track the history of the old master version, for example, cost center 2011 and have been end dated.

  2. Current version: This version has been modified to reflect the new hierarchy and is now active.

  3. Baseline version: This version should continue to be the duplicate of the master version. Rather than modifying this manually, delete the old baseline version and create another copy of the master. Modify the master version. These steps should be followed each time when there are hierarchy changes that must be published.

Note: Best practices recommend that if there are changes, you update the hierarchies before completing period close and financial reporting.

Maintaining Hierarchies: Examples

The following example illustrates how to maintain your hierarchy.

Scenario

Your organization, Vision Operations:

  • Decided in 2015 to begin using Oracle General Ledger, effective January 1, 2016.

  • Uses a single chart of accounts named Corporate Chart of Accounts. Since you only have one chart of accounts, this is also the name of the cube.

  • Uses a hierarchy to capture its cost center roll ups by line of business. The name of this hierarchy is Cost Centers Hierarchy.

At the end of 2016, your organization, Vision Operations, makes organizational changes to its lines of business. You add new cost centers and a new line of business. As a result, you must update your cost center hierarchies to ensure that financial reporting reflects the new organization hierarchy.

Don't make changes to the Cost Center Master hierarchy version if no account value changes have been made and the current hierarchies are working.

However, since there are changes, you must:

  1. Copy and backup the Cost Center Current hierarchy version to maintain history.

  2. Make changes to the Cost Center Current hierarchy version and change it to the new effective dates.

  3. Delete the hierarchy version named Baseline. You don't unpublish the hierarchy from the cube, as long as you follow the naming conventions discussed in the following steps.

  4. Copy the Current hierarchy version after changes are completed, and name it Baseline.

  5. Publish the Current hierarchy version again.

  6. Publish the new Baseline hierarchy version again.

After publishing both versions, there are still only two hierarchy versions in the cubes. The version name must always be the same across all periods. The name is referenced in financial reports, allocation rules, and Smart View queries. For example, Cost Center Current and Cost Center Baseline. Don't have a version named 2016 Cost Center, or 2017 Cost Center Current, or 2017 Cost Center Baseline.

This example assumes an annual change. It can also be quarterly, monthly, or as needed. Follow these steps for any hierarchy changes at any time for even regular maintenance, such as adding values or moving values in the hierarchy. Best practices recommend keeping your current and baseline hierarchy versions synchronized.

Hierarchies for Cross Validations, Revaluations, and Chart of Accounts Mapping: Explained

Hierarchies you create for reporting or allocations may not be suitable for setting up cross validations, revaluation, and chart of accounts mapping rules.

For example, if you must enforce a cross-validation rule that a set of 20 departments is applicable only to a certain company, then you can group the 20 departments in a hierarchy node and refer to that hierarchy node in the cross-validation rule.

Cross Validations, Revaluations, and Chart of Accounts Mapping

For hierarchies for cross validations, revaluations, and chart of accounts mapping:

  • Create hierarchies for cross validations, revaluation, or chart of accounts mapping within one hierarchy. Associate this hierarchy to the chart of accounts segment instance in the chart of accounts instance setup page. You can only associate one hierarchy with the chart of accounts instance. You can create separate root nodes for each segment of the hierarchy.

  • Create an account hierarchy for each of the segments that are used in the rule set ups. Depending on your requirements, not all segments may need a hierarchy.

  • Use the same child to roll up to different parents if you need different roll ups for cross validations, revaluations, and chart of accounts mapping.

  • Flatten and audit the hierarchy after the hierarchies are complete and set it to an active status.

  • Associate the hierarchy to the chart of accounts segment instance.

  • Redeploy the accounting flexfield after the chart of accounts instance is updated.

If you have the duplicate segment values in a hierarchy, you should not publish the hierarchies to Oracle Essbase.

Publish an account hierarchy to finalize a new or edited account hierarchy. Account hierarchies organize data and enable the creation of groups and rollups of information that exist within an organization. After creating or editing an accounting hierarchy, run the Publish Account Hierarchies, Maintain GL Value Sets, and Maintain Chart of Account Hierarchies processes before using the new or changed account hierarchy.

Scenario

You have made changes to your Vision Corporation account hierarchy. Follow these steps to publish your account hierarchy.

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Publish Account Hierarchies

  2. Search for your Vision Corporation account hierarchy.

  3. Click Expand to open the versions of your hierarchy.

  4. Click the Publish button.

    Note: For a new hierarchy, scroll over to verify the Publish check box is selected.

FAQs for Define Account Hierarchies

How can I manage and review account hierarchies?

View segment value descriptions when creating, editing, or reviewing account hierarchies online. You can also export account hierarchies to a spreadsheet to review, analyze, and report offline.

To export all nodes in the hierarchies to a spreadsheet, expand all nodes first from View -> Expand All in the Manage Account Hierarchies: Specify Nodes page.

What happens when changes are made to an account hierarchy that is referenced in segment value security rules?

The tree is set from an active to a draft state. The rules referencing the account hierarchy become ineffective.

After making changes to your hierarchy, you can submit the Process Account Hierarchies process to automatically run the required steps for processing account hierarchies updates in one submission, including:

  • Tree audit

  • Tree activation

  • Row flattening

  • Column flattening

  • Maintain value set

  • Maintain account hierarchy

  • Publish hierarchy

With a successful audit process, the hierarchy is set back to an active status. The rules referencing the account hierarchy go back to being effective using the updated hierarchy.

Run the row and column flattening processes for the updated hierarchy as the flexfield component in the application as well as other hierarchy processes rely on the flattened hierarchy data to come up with the list of values available to the user to properly secure the correct account values.

Run the Maintain Value Sets and Maintain Chart of Account Hierarchies processes, particularly for hierarchy changes to the primary balancing segment value set if such values are referenced in your primary balancing segment value based data access sets. These processes update the data that is required to regulate ledger and data access security by storing:

  • Primary balancing segment values assigned to a ledger.

  • Specific child balancing segment values assigned to a data access set through parent value assignments.

When do I perform row and column flattening for tree versions manually?

Row Flattening and Column Flattening for tree versions must be manually submitted in the following scenarios.

  • A new tree or tree version is defined

  • If the tree or tree version has any change made to it that would alter the flattened hierarchy data. For example, adding, moving, and duplicating members. Basically, anything that impacts the flattened hierarchy data.

  • If Data Relationship Management (DRM) is used with Oracle Fusion General Ledger, after running the Load Account Values and Hierarchies process from the Scheduled Process work area to load chart of accounts reference data from DRM to Oracle Fusion General Ledger.

  • When range based hierarchy assignments are supported, if new values are added that are within the account range assigned to the hierarchy.

    Note: In this case, try submitting the flattening programs using the Online Mode first. If the newly inserted child account value does not appear to be included in the flattened hierarchy data, then the flattening program has to be submitted using the Force Flattening Mode, instead of Online Flattening. An issue with the incremental flattening programs can prevent them from picking up this type of hierarchy change, so full flattening can be required.
Note: Column flattening processed data is primarily relevant to Oracle Fusion Transactional Business Intelligence, but there should not be any adverse impact to run both row and column flattening processes.

Manage Tree Structures

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.

While creating a tree structure, you must specify important details on the Create Tree Structure: Specify Definition page. As the source of the tree structure, you may either select the predefined tree structures and proceed with the definition or create tree structures.

Tree Node Selection

The data in Tree Node table maps to the data in nodes of the tree structure. You must select the correct and most appropriate tree node table to define the tree structure, based on which you establish the tree hierarchy. This selection also affects the level of security that is set on a tree node and its child entities.

Tree Sharing Mode

Use the following options 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 is associated with a specific reference data set.

Modification

You can modify the predefined tree structures as well as those you create. However, modifying a predefined tree structure is restricted and permitted through additional privileges. Modification is limited to specific tree nodes and lower in the tree hierarchy.

Multiple Tree Versions

Although multiple tree versions can exist together, Oracle recommends only one version be active at any given time. However, if required, you can have more tree versions to be in the active state for the same date range. You can use this flexibility to select the tree version you want to implement.

You can create, edit, and delete tree structures. You can also change the status of a tree structure and audit the changes.

Creating and Editing Tree Structures

When you edit an active tree structure, the status of the tree structure and all associated trees and their versions changes to draft. To reuse a tree structure, create a copy of the tree without copying the associated trees and tree versions. After making changes, set the status again to active. If you delete a tree structure, all the associated trees and tree versions are automatically deleted.

For information about working with the offering-specific predefined tree structures, refer to the relevant product documentation.

Status

When you change the status of a tree structure, the status of the trees and tree versions associated with that tree structure also changes.

The following table lists the different statuses of a tree structure.

Status Meaning

Draft

In a modified state, or not yet in use.

Active

In use, indicating that one or more trees or tree versions are created from the tree structure.

Inactive

Not in use.

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

  • The name of the validator, which is a specific validation check

  • The result of the validation, including a detailed message

  • Corrective actions to take if there are any validation errors

Running an Audit

Setting the status of a tree structure to active automatically triggers an audit of that tree structure. To manually trigger an audit, select Audit from the Actions menu on the Manage Tree Structures page. The Tree Structure Audit Result table shows a list of validations that ran against the selected tree structure.

Audit Validators

The following table lists the validators used in the audit process and describes what each validator checks for. It also lists possible causes for validation errors and suggests corrective actions.

Validator Page Description (what is validated) Possible Cause for Validation Failure Suggested Corrective Action

Restrict By Set ID

Manage Tree Structures: Specify Data Sources

If you select the Reference Data Set check box for the Restrict Tree Node List of Values Based on option, each of its data source view objects must have a reference data set attribute.

Even when the check box is selected, one or more data source view objects doesn't contain a reference data set attribute.

If reference data set restriction is required for this tree structure, include a reference data set attribute on all data sources. Otherwise, deselect the check box.

Available Label Data Sources

Manage Tree Structures: Specify Data Sources

If you select a list item from Labeling Scheme to specify a labeling scheme, the label data source view object specified for each data source must be accessible. Also, the primary keys must be valid. This restriction doesn't apply if you select None from the list.

  • Any of the specified label data source view objects doesn't exist.

  • Any of the specified label data source view objects doesn't have primary keys.

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

  • Correct the specified label data source view object.

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

  • Do one of the following:

    • Correct the primary keys in the label data source view object to match the primary keys that were earlier registered in FND_TS_DATA_SOURCE.

    • Correct the primary keys registered in that table to match the new view object definition.

Row Flattened Table Name

Manage Tree Structures: Specify Performance Options

You must specify a valid row flattened table for the tree structure. It can either be the standard row flattened table FND_TREE_NODE_RF or another table.

  • The specified table doesn't exist in the database.

  • The specified table doesn't contain the same columns as the FND_TREE_NODE_RF table.

Correct the row flattened table definition.

Available Data Sources

Add Data Source

Each data source view object specified for the tree structure must be accessible, and all its primary key attributes must be valid.

  • Any of the specified data source view objects doesn't exist.

  • When you define a data source view object, keep the Use non-defined primary key columns check box deselected. The database automatically registers the primary keys for the view object. Select this check box if you want the database to register the primary keys you specify. However, if the registered primary keys contain any duplicates, this validation fails.

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

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

  • Correct the specified data source view object.

  • Correct the duplicate column in the registered primary keys.

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

  • Correct any mismatch in data types.

Column Flattened Table Name

Manage Tree Structures: Specify Performance Options

You must specify a valid column flattened table for the tree structure. It can either be the standard row flattened table FND_TREE_NODE_CF or another table.

  • The specified table doesn't exist in the database.

  • The specified table doesn't contain the same columns as the FND_TREE_NODE_CF table.

Correct the column flattened table definition.

Restrict by Date

Manage Tree Structures: Specify Data Sources

If you select the Date Range check box for the Restrict Tree Node List of Values Based on option for a tree structure, each of its data source view objects must have effective start date and end date attributes. This validation doesn't take place when the check box isn't selected.

Even when the check box is selected, one or more of its data source view objects doesn't contain effective start date and end date attributes.

If the date restriction is required for this tree structure, include the effective start date and effective end date attributes on all data sources. Otherwise, deselect the check box.

Tree Node Table Name

Manage Tree Structures: Specify Definition

You must specify a valid tree node table for the tree structure. It can either be the standard row flattened table FND_TREE_NODE or another table.

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

  • The specified table doesn't exist in the database.

  • The specified table doesn't contain the same columns as the FND_TREE_NODE table.

Correct the tree node table definition.

The data sources provide the items for establishing hierarchy in a tree structure. In the tree management infrastructure, these data sources are Oracle 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 customers assignment. You may also choose not to have any labeling scheme. However, if you decide to use any of the labeling schemes, select the following additional options, to restrict the list of values that appear in 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 in 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.

Note: Parameter values modified at the tree level override the default values specified at the tree-structure level.

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

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

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

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

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

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

Tree structures are heavily loaded with data. As a tree management guideline, use the following settings to improve performance of data rendering and retrieval.

  • Row Flattening

  • Column Flattening

  • Column Flattened Entity Objects

  • BI 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 runtime 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 Object

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.

BI View Object

View objects from Business Intelligence can 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 BI view object generated by the tree management for business intelligence reporting and usage The BI 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.

Search View Object

Specify the full name of the view object for the tree node to ensure that search operations performed on the tree node are efficient.

Manage Tree Labels

Tree labels are tags that are stored on tree nodes. You can store labels in any table and register the label data source with the tree structure. When a labeling scheme is used for trees, the selected labels are stored in the tree label entity, and each tree node contains a reference to a tree label in the labeling scheme.

The following table lists the three ways in which tree labels are assigned to the tree nodes.

Labeling Scheme Description

Level

Labels that are automatically assigned based on the data source to which the tree node belongs. A level label points to a specific data source. For example, in a tree that reflects the organizational hierarchy of an enterprise, all division nodes appear on one level and all department nodes on another.

Group

Labels that you can arbitrarily assign to tree nodes.

Depth

Labels that are automatically assigned based on the depth of the tree node within the tree. No manual assignment is performed.

Note: In an unbalanced hierarchy, a level may not be equal to depth.

Manage Trees and Tree Versions

You can create and edit trees and tree versions depending upon the requirement. A tree can have one or more tree versions. 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. You can also select and copy the associated tree versions.

Creating a tree involves specifying the tree definition and specifying the labels that are used on its nodes. If the selected tree structure has data sources and parameters defined for it, they appear on the page allowing you to edit the parameter values at the tree node level.

Note: Parameter values modified at the tree level will override the default values specified at the tree-structure level.
Creating and Editing Tree Versions

Tree versions are created at the time of creating trees. Each tree must contain a version.

Editing an existing tree provides you with the option of updating the existing version. You can also edit the existing version that lies nested in 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 canceled.

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

  • The name of the validator, which is a specific validation check

  • The result of the validation, including a detailed message

  • Corrective actions to take if there are any validation errors

Running an Audit

An audit automatically runs whenever a tree version is set to active. You can also manually trigger an audit on the Manage Trees and Tree Versions page, using Actions > Audit. The Tree Version Audit Result table shows a list of validations that ran against the selected tree version.

Validation Details

The following table lists the validators used in the audit process and describes what each validator checks for. It also lists possible causes for validation errors and suggests corrective actions.

Validator Description (what is checked) Possible Cause for Validation Failure Suggested Corrective Action

Effective Date

The effective start and end dates of the tree version must be valid.

The effective end date is set to a value that is not greater than the effective start date.

Modify the effective start and end dates such that the effective start date is earlier than the effective end date.

Root Node

On the Manage Tree Structures: Specify Data Sources page, if the Allow Multiple Root Nodes check box for the Restrict Tree Node List of Values Based on option is not selected, and if the tree structure is not empty, the tree version must contain exactly one root node. This validation does not take place if the check box is selected.

Even if the check box is deselected, the tree version has multiple root nodes.

Modify the tree version such that there is exactly one root node.

Data Source Maximum Depth

For each data source in the tree structure, on the Data Source dialog box, if the data source is depth-limited, the data in the tree version must adhere to the specified depth limit. This validation doesn't apply to data sources for which the Maximum Depth field is set to Unlimited.

The tree version has data at a depth greater than the specified depth limit on one or more data sources.

Modify the tree version such that all nodes are at a depth that complies with the data source depth limit.

Duplicate Node

On the Data Source dialog box, if the Allow Duplicates check box isn't selected, the tree version must not contain more than one node with the same primary key from the data source. If the check box is selected, duplicate nodes are permitted.

Even when the check box is deselected, the tree version contains duplicate nodes.

Remove any duplicate nodes from the tree version.

Available Node

All nodes in the tree version must be valid and available in the underlying data source.

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

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

Remove any orphaned nodes from the tree version. Update tree reference nodes so that they reference existing tree versions.

Node Relationship

All nodes must adhere to the relationships mandated by the data sources registered in the tree structure.

The tree structure has data sources arranged in a parent-child relationship, but the nodes in the tree don't adhere to the same parent-child relationship. For example, if the tree structure has a Project data source with a Task data source as its child, Task nodes must always be within Project nodes in the tree version. This validation fails if there are instances where a Project node is added as the child of a Task node.

Modify the tree version such that the nodes adhere to the same parent-child relationships as the data sources.

SetID Restricted Node

On the Manage Tree Structures: Specify Data sources page, if the Set ID check box is selected to enable the Restrict Tree Node List of Values Based on option for each tree node, the underlying node in the data source must belong to the same reference data set as the tree itself. This restriction doesn't apply when the check box is not selected.

Even when the check box is selected, the tree version has nodes whose data source values belong to a different reference data set than the tree.

Modify the tree version such that all nodes in the tree have data sources with reference data set matching that of the tree.

Label Enabled Node

On the Manage Tree Structures: Specify Data Sources page, if a labeling scheme is specified for the tree structure by selecting a list item from the Labeling Scheme list, all nodes must have labels. This restriction doesn't apply when you select None from the Labeling Scheme list.

The tree structure has a labeling scheme but the tree version has nodes without labels.

Assign a label to any node that doesn't have a label.

Date Restricted Node

On the Manage Tree Structures: Specify Data Sources page, if the Date Range check box is selected to enable the Restrict Tree Node List of Values Based on option for a tree structure, each node in the underlying data source must have an effective date range same as the effective date range of the tree version. This restriction doesn't apply if the check box isn't selected.

Even when the check box is selected, there are data source nodes that have a date range beyond the tree version's effective date range. For example, if the tree version is effective from Jan-01-2012 to Dec-31-2012, all nodes in the tree version must be effective from Jan-01-2012 to Dec-31-2012 at a minimum. It is acceptable for the nodes to be effective for a date range that extends partly beyond the tree version's effective date range (for example, the node data source value is effective from Dec-01-2011 to Mar-31-2013). It isn't acceptable if the nodes are effective for none or only a part of the tree version's effective date range (for example, the node data source value are effective only from Jan-01-2012 to June-30-2012).

Ensure that all nodes in the tree version have effective date range for the effective date range for the tree version.

Multiple Active Tree Version

On the Manage Tree Structures: Specify Definition page, if the Allow Multiple Active Tree Versions check box isn't selected for the tree structure, there must not be more than one active tree version for a tree at any time. This restriction doesn't apply if the check box is selected.

Even when the check box isn't selected, there is more than one active tree version in the tree for the same date range.

Set no more than one tree version to Active within the same date range and set the others to inactive or draft status.

Range Based Node

On the Data Source dialog box, if the Allow Range Children check box isn't selected, range-based nodes are not permitted from that data source. This restriction doesn't apply if the check box is selected.

Even when the check box isn't selected, there are range-based nodes from a data source.

Ensure that any range nodes in your tree version are from a data source that allows range children.

Terminal Node

On the Data Source dialog box, if the Allow Use as Leaves check box isn't selected, values from that data source can't be added as leaves (terminal nodes) to the tree version. This restriction doesn't apply if the check box is selected.

Even when the check box isn't selected, values from a data source are added as leaf nodes (terminal nodes).

Modify the tree version such that all terminal nodes are from data sources for which this check box is selected.

Usage Limit

On the Data Source dialog box, if the Use All Values option is selected to set the Usage Limit for the data source, every value in the data source must appear as a node in the tree. This restriction doesn't apply if None option is selected.

Even if the Use All Values option is selected, there are values in the data source that aren't in the tree version.

For each data source value that isn't yet available, add nodes to the tree version.

Data sources are the foundation of tree management. 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 and Data Storage

Tree structures contain the metadata of the actual data and the core business rules that manifest in trees and tree versions. You can 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, the changes you make to the tree nodes affect the source data. Access control set on trees prevents unwanted data modifications in the database. Access control can be applied to the tree nodes or anywhere in the tree hierarchy.

Tree nodes are points of data convergence where a tree branches into levels. Nodes are the building blocks of a tree structure and are attached to tree versions. Whenever you create or edit a tree version, you need to specify its tree node.

In the Setup and Maintenance work area, open the panel tab and click Search to search for the Manage Trees and Tree Versions task.

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

Usually, the nodes at a particular level represent similar information. For example, in a tree that reflects the organizational hierarchy, all nodes representing divisions appear at one level and all the department nodes on another. Similarly, in a tree that organizes a user's product catalog, the nodes representing individual products might appear at one level and the nodes representing product lines on the immediate higher level.

The following node levels are in use:

  • Root node: The highest node in the tree structure

  • Parent node: The node that branches off into other nodes

  • Child node: The node that is connected to a node higher in hierarchy (parent node)

  • Sibling node: Nodes that are at the same level and belong to the same parent node

  • Leaf node: Entities branching off from a node but not extending further down the tree hierarchy

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 Account Combinations

Account combinations contain a completed set of segment values that uniquely identifies an account in the chart of accounts.

Here are some examples of account combinations:

  • 01-100-1420-003

  • 02-100-1420-005

  • 01-100-1420-002

  • 02-100-1420-004

Account combinations:

  • Are enabled when created by default.

  • Cannot be deleted.

  • Use a From Date to be enabled as of a particular date. For example, if you have a new department as of January 1, 2014, create the account combinations in advance by using a From Date of 01-JAN-2017 to enable the combinations on that date.

  • Are discontinued by:

    • Deselecting the Enabled option.

    • Entering an end date.

Caution: Before creating account combinations, ensure that account types for the natural account segment values have been correctly assigned. If you assign an incorrect account type to a natural account segment value, accounting entries are recorded incorrectly and financial statements are inaccurate. Misclassified accounts are also potentially handled incorrectly at year end, with actual balances either getting zeroed out to retained earnings, or accumulating into the next year.

Set the following attributes on the Manage Account Combinations page:

  • Preserve Attributes: To prevent changed segment values from overriding values defined at the account combination level when running the Inherit Segment Value Attributes process.

  • Type: To identify the type of account, Asset, Liability, Revenue, Expense, and Owner's Equity.

  • From and To Dates: To enable or disable the account combination on a specific date.

  • Allow Posting: To use the account combination in journals.

  • Alternative Account: To use an alternative account combination when this one is disabled.

Use the Manage Account Combinations page to create account combinations manually or using a spreadsheet.

Caution: Before creating account combinations, ensure that account types for the natural account segment values have been correctly assigned. If you assign an incorrect account type to a natural account segment value, accounting entries are recorded incorrectly and financial statements are inaccurate. Misclassified accounts are also potentially handled incorrectly at year end, with actual balances either getting zeroed out to retained earnings, or accumulating into the next year.

Scenario

Create account combinations using a spreadsheet:

  1. In the Setup and Maintenance work area, use the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Account Combinations

  2. Select your chart of accounts.

  3. Click Search.

  4. Click the Create in Spreadsheet button.

  5. Click OK in the message that pops up.

  6. Sign in with your user name and password.

  7. Enter the new account combination in the appropriate segments. For example: 01-120-5110-00.

  8. Click Submit to upload the account combinations.

Scenario

Create account combinations manually:

  1. In the Setup and Maintenance work area, use the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Account Combinations

  2. Select your chart of accounts.

  3. Click the Add Row icon.

  4. Verify that the Enabled check box is selected.

  5. Select the Account segment values from the drop-down lists. For example:

    • Company 01

    • Department 120

    • Account 5105

    • Intercompany 00

  6. Enter today's date in the From Date field to make the account effective today.

  7. Click Save and Close.

Import Account Combinations: How Data Is Processed

Use the Import Account Combinations file-based data import to import and update account combinations. You can download a spreadsheet template to use to prepare your account combination data. The template contains an instruction sheet to help guide you through the process of entering your account combination information.

In addition to creating account combinations, you can also use the template to update attributes on existing account combinations. Enter the segment values for the existing account combinations and specify the attributes to update such as Enabled, Allow Posting, From Date, To Date, Alternate Account, and Preserve Attributes.

Note: An alternate account is used when its associated account combination is disabled or inactive.

To access the template, complete the following steps:

  1. Navigate to the File-Based Data Import for Oracle Financials Cloud guide.

  2. In the Table of Contents, click File-Based Data Imports.

  3. Click Import Account Combinations.

  4. In the File Links section, click the link to the Excel template.

Follow these guidelines when preparing your data in the worksheet:

  • Enter the required information for each column.

  • Refer to the tool tips on each column header for detailed instructions.

  • Do not change the order of the columns in the template.

  • You can hide or skip the columns you do not use, but do not delete them.

Settings That Affect the Account Combinations Import Process

The Account Combinations Import Interface template contains an instructions tab, plus a tab that represents the table where the data is loaded.

The following table contains the names of the tabs in the Import Account Combinations spreadsheet template and a description of their contents.

Spreadsheet Tab Description

Instructions and CSV Generation

Contains an overview of the template and information about how to generate the data files for upload.

GL_BULK_COMBINATIONS_INT

Enter information about the account combinations that you are adding or updating, such as the chart of accounts, the segment values, and whether posting is allowed.

After you prepare the data in the spreadsheet, click Validate Account Combinations to verify that the template doesn't have errors.

How Account Combinations Import Data Is Processed

To load the data into the interface table:

  1. Click the Generate CSV File button on the instructions tab to create a CSV file in a .zip file format.

  2. Save the .zip file locally.

  3. Navigate to the Scheduled Processes work area.

  4. Select the Load Interface File for Import process.

  5. For the Import Process parameter, select Import Account Combinations.

  6. For the Data File parameter, select the file that you saved in step 2.

  7. If the process ends in error or warning:

    1. Review the log and output files for details about the rows that caused the failure.

    2. Correct the errors in the spreadsheet.

    3. Repeat steps 1 through 6 until the errors are resolved.

To load the data from the interface table into the product:

  1. Navigate to the Scheduled Processes work area.

  2. Select the Import Account Combinations process.

  3. Optionally provide values for the Chart of Accounts and Group ID parameters.

  4. Submit the process.

  5. If the process ends in error or warning:

    1. Review the log file for details about the rows that cause the failure.

    2. Correct the spreadsheet.

    3. Follow the steps to delete the data from the interface table.

    4. Repeat the steps to load the data into the interface table.

To delete the data from the interface table without loading into the product:

  1. Navigate to the Scheduled Processes work area and select the Purge Interface Tables process.

  2. Accept the default value of File-based data import for the Purge Process Intent parameter.

  3. Select Import Account Combinations for the Import Process parameter.

  4. For the Load Request ID parameter, enter the process ID from the Load Interface File for Import process.

  5. Submit the process.

Account Aliases: Explained

Define account shorthand aliases to speed entry of account segment values.

If you enable shorthand alias when you define your chart of accounts, then you can define aliases, or codes, which represent complete or partial accounts.

Oracle Fusion General Ledger can currently use this feature in the following user interfaces:

  • Journal lines in the Create Journal page.

  • Create Journal in Spreadsheet for both Single Journal and Multiple Journals modes.

  • Manage Account Combinations in the Alternate Account field.

  • Manage Intercompany Outbound Transactions and Manage Intercompany Inbound Transactions pages.

  • Other pages where the account list of values selector is present.

Note: Account Groups in the Account Monitor region and the Inquire and Analyze Balances page are based on the underlying GL Balances cube. These pages do not present you with a list of values to search and select accounts. Therefore, you are not able to leverage shorthand aliases.

Enabling Shorthand Aliases

The administrator or implementor is required to select the Shorthand alias enabled option as part of the chart of accounts structure instance definition. Freeze and compile your account structure in the Manage Chart of Accounts Structure Instances page when you are ready to begin using your structure. You must recompile your chart of accounts structure instance every time you make changes to your structure and segments, including enabling or disabling shorthand entries.

The following features and functionality apply to shorthand aliases.

  • The segment value security is automatically enforced when creating or maintaining aliases.

  • Cross-validation rules are not imposed since the aliases template account combinations do not update the account combinations.

  • The alias field is displayed when you select the account list of values selector in the data entry regions where the selector appears. The field is enabled for both the list of values and search functionality. You can also enter segment values directly in the account value fields, thus ignoring the alias functionality.

Enter GL Account Aliases: Examples

You are assigned the task of defining shorthand account aliases to speed up journal entry.

Enter a Partial Account Alias

Use these steps to enter a partial account alias for your account payables account.

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Shorthand Aliases

  2. Select a chart of accounts.

  3. Click the Add Row icon.

  4. Enter the name of AP.

  5. Enter the account template by entering 101 in the Company segment and 221000 in the Account segment.

  6. Enter a description of Accounts Payables account.

  7. Verify that the Enabled option is selected.

  8. Accept today's date as the Start Date.

  9. Leave the End Date blank.

  10. Click Save.

Enter a Full Account Alias

Use these steps to enter a full account alias for your cash account.

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Shorthand Aliases

  2. Select a chart of accounts.

  3. Click the Add Row icon.

  4. Enter the name of Cash.

  5. Enter the Account Template values, as shown in this table.

    Field Value

    Company

    101

    LOB

    00

    Account

    111000

    Sub-Account

    000

    Product

    000

    Intercompany

    000

  6. Enter a description of Cash account.

  7. Verify that the Enabled option is selected.

  8. Accept today's date as the Start Date.

  9. Leave the End Date blank.

  10. Click Save and Close.

Correcting Misclassified Accounts: Explained

When you create a value for a segment that's assigned the natural account segment label, you must select an account type, such as Asset, Liability, Expense, Revenue, and Owner's Equity. Account combinations subsequently created with that segment value inherit the assigned account type. For example, you assign segment value 1000 the account type of Asset, and then create account combination 01-000-1000-000-000. The account combination is classified as an asset.

Misclassified accounts occur when the inherited account type of the corresponding natural account segment value is set incorrectly. If you assign an incorrect account type to a natural account segment value, accounting entries are recorded incorrectly and financial statements are inaccurate. Misclassified accounts are also potentially handled incorrectly at year end, with actual balances either getting zeroed out to retained earnings, or accumulating into the next year.

Caution: Be sure to assign the correct account type to natural account segment values before account combinations are created. Having to correct misclassified accounts isn't standard practice.

You can use the Correct Misclassified Accounts process to correct account types for account combinations. Running the process though is only one aspect of correcting misclassified accounts. The overall procedure to correct misclassified accounts depends on:

  • The account type correction being made

  • Whether the impacted account combinations ever had activities posted to them

  • The impact of the correction across accounting years

  • Whether balances have been translated

Account Type Correction

Account types can be grouped into income statement accounts and balance sheet accounts. Income statement accounts consist of the Revenue and Expense account types, and balance sheet accounts consist of the Asset, Liability, and Owner's Equity account types. At the end of an accounting year, income statement accounts are zeroed out to retained earnings, and balance sheet accounts accumulate into the next year.

Account type corrections within the income statement group or within the balance sheet group don't affect the retained earnings calculation or beginning balances across accounting years. The following table lists the specific account type corrections that can be made without requiring manual journal entries as part of the correction process.

Incorrect Account Type Correct Account Type

Revenue

Expense

Expense

Revenue

Asset

Liability or Owner's Equity

Liability

Asset or Owner's Equity

Owner's Equity

Asset or Liability

Account type corrections that cross from the income statement group to the balance sheet group, or from the balance sheet group to the income statement group, can affect the retained earnings calculation and beginning year balances if the corrections cross accounting years. The following table lists the specific account type corrections that may require manual journal entry adjustments as part of the correction process.

Incorrect Account Type Correct Account Type

Revenue

Asset, Liability, or Owner's Equity

Expense

Asset, Liability, or Owner's Equity

Asset

Revenue or Expense

Liability

Revenue or Expense

Owner's Equity

Revenue or Expense

Procedure

Follow these recommended steps to correct misclassified accounts.

  1. On the Manage Values page, correct the account type for the value set value.

  2. Before submitting the Correct Misclassified Accounts process, it's recommended that you:

    • Ensure journals aren't being posted when the process is run in reclassification mode.

    • Disable the Dynamic combination creation allowed option for the chart of accounts.

  3. On the Scheduled Processes page, run the Correct Misclassified Accounts process with the following parameters:

    • Value Set: Select the value set for the natural account segment.

    • Value Set Value: Select the value from which account combinations must inherit the account type.

    • Mode: Select Preview mode.

  4. Review the report output.

    The report lists actual balances for the affected account combinations by ledger, currency, and fiscal year that must be zeroed out in cases where corrections cross from the balance sheet group to the income statement group, or from the income statement group to the balance sheet group. Use this information to facilitate the journal entry that you must create for fiscal year cross-over scenarios. The report also lists periods with translated balances. If the report doesn't display balances to zero out, skip to step 9.

  5. Open the last period of the prior fiscal year for each primary ledger with balances that must be zeroed out.

  6. Create the respective journal entries using the information in the report to bring the misclassified account balances to zero and post the journals. Use a temporary account, such as a suspense account, for the offsetting amount.

    Note: The journal entries should zero out balances in every entered currency.
  7. Rerun the Correct Misclassified Account process in Preview mode.

    Check whether any balances should be zeroed out. If so, repeat steps 5 and 6 until all balances are zeroed out. If the only balances listed are for secondary ledgers and reporting currencies, the journal entries should be created and posted in those ledgers directly.

  8. Run the Correct Misclassified Accounts process in Reclassify Account Type mode.

    The process first validates that the affected account combinations have zero actual balances if the misclassification affects multiple fiscal years. This validation ensures that the account type reclassification doesn't cause errors in the calculation of retained earnings and beginning balances. The process then corrects the account type on the misclassified account combinations to match the account type of the selected segment value.

  9. Review the report output for the list of reclassified account combinations for each chart of accounts.

  10. Update the Account dimension by running the Publish Chart of Account Dimension Members and Hierarchies to Balances Cubes process:

    1. Select the value set for the Account dimension.

    2. Set the Publish Detail Values Only parameter to Yes.

  11. Starting from the earliest fiscal year, reverse and post the journals that you created to zero out the balances in each ledger. The reversal journal must be in the same period as the journal being reversed.

    Note: The recommended reversal method for the journals is Change Sign.
  12. If there are misclassified account corrections, and if a translation currency has balances, you must:

    1. Run the Delete Translated Balances process and after the process completes, rebuild the balances cube.

    2. Rerun the translation process after the misclassification has been addressed.

FAQs for Manage Account Combinations

What happens when I run the Inherit Segment Value Attributes process?

Running the process eases chart of accounts maintenance by automatically replicating changes to segment value attributes of the account combinations that contain that segment value.

For example, enable a particular cost center segment value that had been previously disabled. Navigate to the Scheduled Processes page and run the Inherit Segment Value Attributes process to automatically reenable all account combinations containing that cost center.

Use the Segment Value Inheritance Exception Report to view the account combinations that have been changed. You can prevent selected account combinations from being affected by selecting the Preserve Attributes option on the Manage Account Combinations page.

Note:
  • Individual segment value attributes override account combination attributes.

  • Conflicting settings for the Enabled, Allow Posting, From Date, or To Date options are resolved by using the most restrictive of the settings of the individual segment values.

  • Disabling a segment value disables the combinations containing that value, even if the Preserve Attributes option is selected.

Define Accounting Calendars

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.

Caution: 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.
  • Budgetary control only

  • Start Date

  • Period Frequency

  • Adjusting Period Frequency

  • Period Name Format

Note: To help create and maintain accounting calendars, the common calendar types of monthly, weekly, 4-4-5, 4-5-4, 5-4-4, 4-week, quarterly, and yearly, are automatically generated. By using the period frequency option, you no longer have to go through the tedious task of defining each period manually.

Budgetary Control Only Check Box

Select the check box for Budgetary control only to use the calendar for budgetary control only. Budgetary Control refers to the group of system options and the validation process of determining which transactions are subject to validation against budgets and budget consumption to prevent overspending.

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

If the year has been defined and validated, use the Add Year button to add the next year quickly. Accept or change the new rows as required. For example, with the Other frequency type calendar, dates may differ from what the application generates.

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

Adjusting Period Frequency

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

Period Name Format Region

In the Period Name Format section, enter the following fields:

  • User-Defined Prefix: 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.

  • Format: A predefined list of values filtered on the selected separator, only displaying the options that match the selected separator.

  • Year: 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, 2016 to May 9, 2016 has the period name of Apr-16 and December 10, 2016 to January 9, 2017 has the name of Dec-16.

    • If period frequency is Other, then the period format section 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 period names.

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

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

Settings That Affect Calendar Validation

Calendar validation runs automatically after you save the calendar.

How a Calendar Is Validated

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

Validation Data Example

Unique period number

2 assigned for two periods

Unique period name

Jan-17 entered twice

Period number beyond the maximum number of periods per year

13 for a 12 period calendar with no adjusting periods

Entered period name contains spaces

Jan 17

Single or double quotes in the period name

Jan '17

Nonadjusting periods with overlapping dates

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

Period date gaps

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

Missing period numbers

Periods 1 through 6 are defined for a calendar with 12 months

Period number gaps

1, 3, 5

Period numbers not in sequential order by date

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

Quarter number gaps

1, 3, 4

Quarters not in sequential order by period

1, 3, 2, 4

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

July 1, 2015 in a 2017 calendar

FAQs for Define Accounting Calendars

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.

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:

  • Start date of September 1, 2014.

  • End date is August 31, 2015.

  • 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, 2014 to December 31, 2014, then 2014 or just 14, depending on the period format selected, is appended to each period's name. For the remaining periods covering January 1, 2015 to August 31, 2015, then 2015 or 15, 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 2015, then 2015 or just 15, depending on the period format selected, is appended to the period name of all 12 periods.

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

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

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

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

Manage Currencies

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

Currency Codes

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

Date Ranges

You can enter transactions denominated in the currency only for the dates within the specified range. If you don't enter a start date, then the currency is valid immediately. If you don't enter an end date, then the currency is valid indefinitely.

Symbols

Some applications support displaying currency symbols. You may enter the symbol associated with a currency so that it appears along with the amount.

Use the Derivation Type, Derivation Factor, and Derivation Effective Date fields to define the relationship between the official currency (Euro) of the European Monetary Union (EMU) and the national currencies of EMU member states. For each EMU currency, you define its Euro-to-EMU fixed conversion rate and the effective starting date. If you have to use a different currency for Euro, you can disable the predefined currency and create a new one.

Derivation Type

The Euro currency derivation type is used only for the Euro, and the Euro derived derivation type identifies national currencies of EMU member states. All other currencies don't have derivation types.

Derivation Factor

The derivation factor is the fixed conversion rate by which you multiply one Euro to derive the equivalent EMU currency amount. The Euro currency itself must not have a derivation factor.

Derivation Effective Date

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

FAQs for Manage Currencies

Create or enable any currency for displaying monetary amounts, assigning currency to ledgers, entering transactions, recording balances, or for any reporting purpose. All currencies listed in the International Organization for Standardization (ISO) 4217 standard are supported.

The default currency is set to United States Dollar (USD).

Precision refers to the number of digits placed after the decimal point used in regular currency transactions. For example, USD would have 2 as the precision value for transactional amounts, such as $1.00.

Extended precision is the number of digits placed after the decimal point and must be greater than or equal to the precision value. For calculations requiring greater precision, you can enter an extended precision value such as 3 or 4. That would result in the currency appearing as $1.279 or $1.2793.

Minimum accountable unit is the smallest denomination for the currency. For example, for USD that would be .01 for a cent.

In Setup and Maintenance work area, search for the Manage Currencies task to set these values for a currency.

The statistical unit currency type denotes the Statistical (STAT) currency used to record financial statistics in the financial reports, allocation formulas, and other calculations.

Define Conversion Rate Types

Maintain different conversion rates between currencies for the same period using conversion rate types. The following conversion rate types are predefined:

  • Spot

  • Corporate

  • User

  • Fixed

You can use different rate types for different business needs. During journal entry, the conversion rate is provided automatically based on the selected conversion rate type and currency, unless the rate type is User. For User rate types, you must enter a conversion rate. You can define additional rate types as needed. Set your most frequently used rate type as the default. Conversion rate types can't 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 conversion rate type of Spot to populate period average rates, and the conversion rate type of Corporate to populate 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.

When creating conversion rates, decide whether to:

  • Enforce inverse relationships

  • Select pivot currencies

  • Select contra currencies

  • Enable cross rates and allow cross-rate overrides

  • Maintain cross-rate rules

Enforce Inverse Relationships

The Enforce Inverse Relationship option indicates whether to enforce the automatic calculation of inverse conversion rates when defining daily rates. The following table describes the impact of selecting or not selecting the option.

Action Results

Selected

When you enter a daily rate to convert currency A to currency B, the inverse rate of currency B to currency A is automatically calculated and entered in the adjacent column. If either rate is changed, the application automatically recalculates the other rate.

You can update the application calculated inverse rate, but once you do, the related rate is updated. The option enforces the inverse relationship is maintained but doesn't prevent you from updating the rates.

Not Selected

The inverse rate is calculated, but you can change the rate and update the daily rates table without the corresponding rate being updated.

Select Pivot Currencies

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

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

Select Contra Currencies

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

Enable Cross Rates and Allow Cross Rate Overrides

Check the Enable Cross Rates check box to calculate conversion rates based on defined currency rate relationships. General Ledger calculates cross rates based on your defined cross rate rules. Associate your cross rate rules with a conversion rate type, pivot currency, and contra currencies. Cross rates facilitate the creation of daily rates by automatically creating the rates between contra currencies based on their relationship to a pivot currency. If the Enable Cross Rates option is deselected 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 automatically creates the rates between EUR to CAD and CAD to EUR. You don't have 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 unselected, the application generated cross rates cannot be overridden

Maintain Cross Rate Rules

Define or update your cross rate rules at any time by adding or removing contra currency assignments. Add a contra currency to a cross rate rule and run the Daily Rates Import and Calculation process to generate the new rates. If you 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 aren't retroactive and don't affect previously stored cross rates. The Cross Rate process generates as many rates as possible and skips currencies where one component of the set is missing.

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

The four predefined conversion rate types are:

  • Spot

  • Corporate

  • User

  • Fixed

Scenario

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

  • Canadian Dollar CAD: A stable currency

  • Mexican Peso MXP: A fluctuating currency

  • Hong Kong Dollar HKD: An infrequently used currency

You enter two journal lines with accounts and amounts for each foreign currency transaction. Based on your company procedures, you select the 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.

The following table lists the currency, the rate type that you select, and the reasons for the rate type selection.

Selected Currency Selected Rate Type Reason

CAD

Corporate

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

MXP

Spot

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

HKD

User

Entered a one time transaction. Your company does not maintain daily rates for Hong Kong dollars.

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

FAQs for Define Conversion Rate Types

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

  • Spot: For currencies with fluctuating conversion rates, or when exact currency conversion is needed.

  • Corporate: For setting a standard rate across your organization for a stable currency.

  • User: For infrequent entries where daily rates for the entered foreign currency aren't set up.

  • Fixed: For rates where the conversion is constant between two currencies.

If you have infrequent foreign currency transactions, the User rate type can simplify currency maintenance. The User rate type can also provide an accurate conversion rate on the date of the transaction.

Define Daily Rates

Load GL Currency Rates: Overview

Oracle Cloud ERP has various options to load currency rates. In Oracle Cloud ERP, daily currency conversion rates can be maintained between any two currencies. You can enter daily conversion rates for specific combinations of foreign currency, date, and conversion rate type. Oracle Cloud ERP automatically calculates inverse rates. You can override the inverse rates that are automatically calculated.

The three different methods of loading currency rates are:

  1. Manual load using the Create Daily Rates spreadsheet.

  2. Manual load using the Import and Calculate Daily Rates file-based data import.

  3. Automatic load using web services.

You are required to enter the daily rates for currency conversion from Great Britain pounds sterling (GBP) to United States dollars (USD) for 5 days.

To load rates using the Create Daily Rates Spreadsheet, you must first install Oracle ADF Desktop Integration client software. Oracle ADF Desktop Integration is an Excel add-in that enables desktop integration with Microsoft Excel workbooks. You can download the installation files from the Tools work area by selecting Download Desktop Integration Installer.

Entering Daily Rates

  1. From the General Accounting work area, select the Period Close link.

  2. From the Tasks panel, click the Manage Currency Rates link.

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

  3. Click the Daily Rates tab.

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

  4. Click the Create in Spreadsheet button.

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

  5. Click in the From Currency field. Select the GBP - Pound Sterling list item.

  6. Click in the To Currency field. Select the USD - US Dollar list item.

  7. Click in the Conversion Rate field. Select the Spot list item.

  8. Click in the From Conversion field. Enter a valid value: 10/2/2017.

  9. Click in the To Conversion Date field. Enter a valid value: 10/6/2017.

  10. Click in the Conversion Rate field. Enter a valid value: 1.6.

  11. Click Submit and click OK twice.

  12. Review the Record Status column to verify that all rows were inserted successfully.

  13. Save the template to use to enter daily rates frequently. You can save the spreadsheet to a local drive or a shared network drive.

  14. Optionally, edit the rates from the Daily Rates user interface or resubmit the spreadsheet.

Import and Calculate Daily Rates: How Data Is Processed

Use the Import and Calculate Daily Rate file-based data import to upload daily currency conversion rates into Oracle Fusion General Ledger. You can download a daily rates spreadsheet template to use to prepare your currency data. The template contains an instruction sheet to help guide you through the process of entering your daily rates information.

To access the template, complete the following steps:

  1. Navigate to the File-Based Data Import for Oracle Financials Cloud guide.

  2. In the Table of Contents, click File-Based Data Imports.

  3. Click Import and Calculate Daily Rates.

  4. In the File Links section, click the link to the Excel template.

Follow these guidelines when preparing your data in the worksheet:

  • Enter the required information for each column. Refer to the tool tips on each column header for detailed instructions.

  • Do not change the order of the columns in the template.

  • You can hide or skip the columns you do not use, but do not delete them.

Settings That Affect the Daily Rate Import Process

The Import and Calculate Daily Rates template contains an instructions tab and a tab that represents the table where the data is loaded.

The Instructions and CSV Generation tab contains information about:

  • Preparing and verifying the currency daily rates data.

  • Understanding the format of the template.

  • Entering daily rates.

  • Loading the data into the interface table and the product.

The GL_DAILY_RATES_INTERFACE tab is where you enter information about the daily rates that you are adding, such as the currencies, conversion date range, and rate. After you add the data, you can validate the information and check for errors by clicking the Validate Daily Rates button. The validation checks for issues such as invalid date format and overlapping date ranges.

How Daily Rates Import Data Is Processed

To load the data into the interface table and into the product:

  1. Click the Generate Daily Rates button on the GL_DAILY_RATES_INTERFACE tab to create a CSV file in a .zip file format.

  2. Save the .zip file locally.

  3. Navigate to the Scheduled Processes work area.

  4. Select the Load Interface File for Import process.

  5. For the Import Process parameter, select Import and Calculate Daily Rates.

  6. For the Data File parameter, select the file that you saved in step 2.

  7. If the process ends in error or warning, review the log and output files for details about the rows that caused the failure. Correct the data in the worksheet and import the data again.

The Load Interface File for Import process loads the data from the uploaded .zip file to the GL_DAILY_RATES_INTERFACE interface table and submits the Import and Calculate Daily Rates process. This process imports the currency conversion rates information from the interface table into General Ledger. You can review the rates on the Currency Rates Manager page, which you open using the Manage Daily Rates task.

Loading Daily Rates Automatically Using Web Services: Examples

If you have a rate subscription source that provides daily rates, use a web service to fully automate the loading of the rates using the file-based data import. The external web service FinancialUtilService enables you to upload data files to Oracle Universal Content Management, and launch the processes to import the rates to Oracle Cloud ERP.

Scenario

You are setting up an automatic process to load your company's daily rates.

Process Steps:

  1. Get the rates file from the designated external source.

    If you have a rate subscription source that provides daily rates, then you can call a web service to collect the file and feed into Oracle Data Integrator, or alternatively, to temporary storage in Oracle Universal Content Management that in turn can be fed into Oracle Data Integrator for further processing.

  2. Prepare and validate the data.

    You would perform data transformation to fit the format of the spreadsheet template. These data processing steps can be accomplished using Oracle Data Integrator.

    The .csv data file has to be provided and transformed in the specific format, in the exact column sequence as in the .xlsm file and data types as expected. For example, the .csv file provides columns such as from and to currency, dates in canonical format, conversion rate type, and the rate.

  3. Call the web service uploadFileToUcm.

    Automatically upload the formatted, validated file from Oracle Data Integrator into Oracle Universal Content Management.

  4. Call the web service submitESSJobRequest.

    Submit the Load Interface File for Import process to load data into the GL Daily Rates interface table.

  5. Call the web service getESSJobStatus.

    Verify the status of the request submitted in previous step. If the process ended in errors, you may have to correct them and then resubmit the process.

  6. The Load Interface File for Import process from step 4 automatically submits the process to import rates from the interface table to the GL Daily Rates table.

  7. Once the Import and Calculate Daily Rates process completes successfully, you can verify and review the rates on the Currency Rates Manager page.

Security Required for Loading GL Currency Rates: Explained

The following tables lists the security privileges and duties that you must be assigned for tasks related to loading rates to Oracle Cloud ERP.

Tasks Privilege Duties

Creating rate types

Define Conversion Rate Type

Daily Rates Administration, General Accounting Manager

Maintaining daily conversion rates

Maintain Daily Conversion Rate

Daily Rates Administration, General Accounting Manager

Importing rate to Cloud ERP

Run Daily Rates Import and Calculation Process

Daily Rates Administration, General Accounting Manager

Viewing daily conversion rates

View Daily Conversion Rate

Daily Rates Administration, General Accounting Setup Review

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

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

Updating Currency Rates

  1. Navigate to the Period Close work area.

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

  2. Click the Manage Currency Rates link.

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

  3. Click the Daily Rates tab.

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

  4. Click the From Currency list. Select the GBP - Pound Sterling list item.

  5. Click the To Currency list. Select the USD - US Dollar list item.

  6. Enter the dates for the daily rates that you are changing. Enter today's date.

  7. Click the Rate Type list. Select the Spot list item.

  8. Click the Search button.

  9. Click in the Rate field. Enter the new rate of 1.7 in the Rate field.

  10. Click in the Inverse Rate field. Enter the new inverse rate of 0.58822 in the Inverse Rate field.

  11. Click the Save button.