If you have used any of Oracle’s planning cloud applications, FCCS functions similarly, but does have some differences from other planning applications. FCCS allows the user to leverage many of the out-of-the-box tools to run calculations through consolidations.
The FCCS Consolidation tool simplifies the entire consolidation process by streamlining it into a handful of intuitive and user-friendly steps. Oracle has designed the system to do so with a series of pre-seeded members and calculations that are created during the application initialization. FCCS makes tracking changes throughout the consolidation process straightforward through the use of several fixed dimensions, members and out-of-the-box system calculations.
Data Source Dimension
The close process contains multiple steps that often require an audit trail. Tracking adjustments through different members allows users to easily view different sources of data. The figure below shows an example of a system generated hierarchy from the data source dimension.
Generally, reporting queries retrieve data from the FCCS_Total Data Source or FCCS_TotalInputandAdjusted members. This dimension aggregates the different sources of data.
Some of the members from the pre-seeded hierarchy include:
FCCS_Intercompany Eliminations: This member is generated if “track intercompany eliminations” is selected during application initialization. You may notice a pattern beginning to develop as this member is intended to track and store the intercompany eliminations much like its consolidation counterpart.
FCCS_Supplemental Data: Another optional member that users can use to store any additional data to aggregate to the TotalInputAndAdjusted member. This member stores all the supplemental detail data entered and posted through the supplemental data manager.
FCCS_Journal Input: Many companies make journal adjustments at the corporate level, which can be posted to this member and audited easily by drilling into the Total Input and Adjusted member.
Once data has been loaded and any adjustments have been made, users can begin their consolidation process for a specified entity, period, scenario, and year. The application performs a series of steps during the consolidation process, first the translation of the local currency to the parent reporting currency, if need be. The consolidation dimension allows users to see detail on the various steps within the consolidation process. This dimension helps users break down the sources of each of these steps, effectively creating an audit trail of this process.
When the application is initialized, a hierarchy is immediately created within the Consolidation dimension as shown below. The structure contains some of the following members:
Entity Input: This is where users will load data. The data is stored in this member and the calculations that run during the consolidation process do not affect the values stored in this member.
Entity Consolidation: After consolidation rules are run, this member only shows data at the parent entity level and reflects the contribution of each of its children.
Elimination: Stores the intercompany elimination values generated by the consolidation business rules.
Proportion: Companies that have joint ownership may need to consolidate portions of the entities that they own. FCCS allows us to do so with a predetermined percentage under the entity total. This is meant to help attribute only the appropriate measure of the child entity’s financials, better reflecting their impact on the parent entity.
Companies may have the need to track their internal sales between subsidiaries. FCCS tracks eliminations through the intercompany dimension. FCCS performs intercompany eliminations at the first common parent between entities through an attribute tag. Within our entity dimension, FCCS gives the option to tag an entity as an Intercompany entity as pictured below.
Additionally, any intercompany and plug accounts can also be tagged with the intercompany account attribute as pictured below. When running consolidation rules, the amounts from the intercompany accounts are moved to a plug target account.
Once the entities are tagged with the intercompany attribute within the Entity dimension, the member is tagged with a prefix of “ICP_” and created in the Intercompany dimension.
The movement dimension is used by the application to help generate the cash flow statement. FCCS creates a generic hierarchy with seeded cash flow members using the prefix “FCCS_Mvmts” however, you can add to the hierarchy as long as the correct property selections are applied. A sample movement hierarchy is pictured below.
To add members to the hierarchy, the FCCS_ClosingBalance and the FCCS_CashFlow hierarchies are used with the consolidation operators of addition and subtraction respectively.
To properly set up the movements dimension, the data storage takes place during the load process. The movement dimension utilizes the account members to build the cash flow through the FCCS predefined logic. An example of the mapping for the movement dimension is pictured below. In this example, we have used multi-dimensional mapping to drive our cash movements in cash through the 1111 series accounts.
The View dimension is used for displaying Periodic, Year-to-Date, and Quarter-to-Date frequencies. FCCS has options to store and calculate data in different ways without independent customization. This feature is included with the FCCS application.
Below shows the members that are generated within the View dimension within FCCS. Each period is stored on a periodic basis in the FCCS_Periodic View member, even if loaded in as a YTD value through the FCCS_YTD_Input member. Subsequently, the system performs YTD calculations when users retrieve data from the FCCS_YTD member.
While some of these dimensions may seem new and intimidating at first, a quick dive into the details behind them show that they can be used to easily enhance the auditability and ease of use for a range of different close processes.
Blog post by David Rengpraphun of Key Performance Ideas.