- Need Help? Talk to an Expert 888-664-4794
06 Nov
In Part 1 of our How Does It Work series on FCCS, we discussed the dimensional structure of our applications. Today we will discuss how data is specifically stored in FCCS, as there are a LOT of dimensions. But, before we can dive into how data is stored, we have to have a small FCCS history lesson.
History of FCCS
Original FCCS Release
Extended Dimensionality
Dense-Sparse Optimization (DSO)
- The original release of FCCS, based on a Block Storage Option (BSO) Essbase database
- Limited to two (2) custom dimensions
- No ownership management
- Slower consolidation times
- Generally considered a not great product from Oracle, some my say closer to a beta release
- The second release of FCCS, based on a Hybrid BSO Essbase database
- Increased dimension count to four (4) custom dimensions
- Added ownership management
- Improved consolidation times
- Generally, a far better product than the original release of FCCS
- The current release of FCCS, still based on a Hybrid BSO Essbase database, but with significant changes
- Same custom dimension count limitations as Extended Dimensionality
- Same ownership management functionality as Extended Dimensionality
- Even more improved consolidation times, and FAR smaller databases
- The best release of FCCS to date and getting better every day
How Is Data Stored in FCCS
So how does FCCS physically store the data in Essbase? As we can see above, the block in Essbase is a combination of our Period and Movement dimensions rather than the typical Period and Account dimension. In addition, the Entity dimension is entirely stored from top to bottom. This means that we are not making use of the Hybrid Essbase engine for our Entity structures. This allows FCCS to store data at upper levels and calculate upper levels differently than a traditional Essbase aggregation.
So Where's The Data Again?
Now that we have that out of the way, we are going to focus specifically on the data storage of our FCCS applicaiton with the assumption that we are using the latest and greatest Dense-Sparse Optimization (DSO) version of FCCS. To illustrate where the data lives, we’ll use a set of Smart View retrieves. Let’s get started:
Each of our dimensions will be labeled in red as seen above and we will comment on where the data lives based on different selections for a few of our key dimensions. We will focus on a the Currency, Entity, Consolidation, and Data Source dimensions. In this example, we can see that we’ve entered data at level 0 entities for Entity Currency, Entity Input, and Data Input.
The next thing we can see is that at upper level entities, we don’t have any data results. Why? Because the Entity Input consolidation member is intended to be used as the name indicates, an input. Outside of entering and modifying data, we don’t use Entity Input to look at our numbers. We can see however that our data is present at upper levels for our Entity Total member. In general, unless you have Parent Level Adjustments enabled, Entity Total is first place we will look for our data.
But wait…our upper level entity doesn’t tie to the children below it! Because we have Entity Currency selected, we are seeing each individual entity displayed in the specific entry currency of that Entity.
Much like our Consolidation dimension, our Currency dimension must change to see the data we are looking for. In this instance, when we change to Parent Currency, we now see data that ties top to bottom. In addition to the basic Parent and Entity Currency dimension members, we also have reporting currencies, but we will save that for another day.
If we have enabled parent-level inputs, we get a whole new level of our Consolidation dimension. Parent Input allows for entry of data at upper-level entities and Parent Total gives us the total of our Entity Total and Parent Input members as we see in the example above.
What About FCCS Eliminations
Given that one of the main reasons companies turn to consolidation products like FCCS is the automated intercompany elimination functionality, let’s take a look at where eliminations live in the system.
In this example, most of our data exists in the No Intercompany member. But, we see that we have one elimination entered between Company 02 and Company 03. This $25 will be eliminated at the first common parent between those two entities. Additionally, we will see that the data ends up in the Total Eliminations Data Source member. When we pull Total Data Source we see our fully eliminated data with a $0 impact on the Intercompany Top value.
Conclusion
Hopefully this information helps those of you looking everywhere for your data in FCCS. In our next part of this never-ending series, we will talk about the many ways that FCCS allows us to calculate data.
