Why I created a blog

Its been many years since I first created this blog. It has remained true to Essbase and related information over those years. Hopefully it has answered questions and given you insight over those years. I will continue to provide my observations and comments on the ever changing world of EPM. Don't be surprised if the scope of the blog changes and brings in other Hyperion topics.

Wednesday, August 31, 2016

A glimpse into FCCS

I’ve been an Essbase developer for about 25 years! In that time I’ve also done some Planning and reporting, Essbase Studio, OBIEE, BICS and a few other things, but my first love has been Essbase. So when I was offered a chance to do the very first implementation of Financial Consolidation and Close Cloud Service (FCCS) I was a little shocked, as I’m not a finance guy. We have a client that wanted to be an early adopter so I jumped in without looking.  Since FCCS is built on Essbase I thought how different can it be? It would be fun to find out. Needless to say it is much more different than I expected.  What I have learned so far is there is a learning curve whether you are an “Essbase Guy” or a “HFM Guy”. In this blog, I’m going talk about some of the things I found odd for an Essbase developer.

First of all, If you have done a PBCS or even better an EPBCS implementation, you will be very familiar with the interface, FCCS is built on the EPBCS framework and most of the things look the same. As a matter of fact, the labels often still say Planning instead of FCCS.


First, Most of the dimensions are predefined. There are 11 out of the box dimensions and two custom dimensions. If you choose Multi-GAAP you only get one custom dimension. The predefined dimensions are:

·       Accounts

·       Entity

·       Scenario

·       View

·       Movement

·       Data Source

·       Currency

·       Periods

·       Years

·       Consolidation

·       Intercompany

In all of the dimensions, there are a number of predefined members. Most of the members are prefixed with FCCS_. It is very important that you do not change these member names as calculations and other processes depend on knowing what these members are.

While you can’t change the name of these members, you can add aliases to make them friendlier and more familiar to the users. In addition, you are not stuck with just these members, you can add your own members below or above these members. What I did find weird is for the balance sheet members, we do not set time balance on the members. All members are set to Flow.  The account dimension is the only dimension set to dense so all upper level members are set to Dynamic calc.

Second in the Entity dimension, all of the members in the Hierarchy are set to Non-consolidating, i.e. a tilde ~. I found this to be very strange. Apparently they handle the consolidation in the calc script. By the way you can’t see the calc script. Also, it this release, you shouldn’t add alternate rollups in the entity dimension. The calculation logic uses the hierarchy for eliminations and adding an alternate messes that up. I have been told in some future releases, you will be able to have them.

Next on dimensions, I think they are doing something odd as all non-level zero members need to be tagged as never share.  While in the regular Essbase world it would matter as long as a parent has more than one consolidating child, it apparently matters in FCCS. We inadvertently set the dimension member to store and it affected the consolidation calculation giving us bad results.

I won’t go into how you have to map Balance sheet members to particular movement dimension members to get the Cash flow to work, which is a topic in itself.


For you Essbase nerds out there, who think you can just code anything you like in FCCS, you will sadly disappointed. As mentioned you cannot see let alone modify the built in calc scripts (there are basically two calc scripts (Consolidate, Translate and compute rates) the rest of the rules shown are for built in processing and are not run by a user

Ok, what about building your own rules. Sorry, in this release (and probably many to come) you are not allowed to build your own rules. Because of the complexity of how data interacts, they have locked this down. There is talk of in the future allowing some very specific rules to be written but we will have to wait and see.

To satisfy your need to do something, you can create formulaic dynamic calc members in the outline but be careful and test them across multiple intersections and there are some interesting calculations that could impact the results. I suggest limiting yourself to simple things like ratio calculations.     

 Data Retrieval

Using Smart View you get a FCCCS specific ribbon for forms

And one for FCCS  Ad-hoc

This appears to be built on the PBCS provider as you can select parent first or child first on zoom in operations. How long have we been asking for this in Essbase? Currently there is a bug in switching between aliases and member names in that if you have a list of members in your POV and you switch, it does not update the all of the names. It lease them as they are. The provider does not seem to be alias aware so if you select an alias while in member name mode, the name is not recognized and the retrieval goes to the top of the dimension. Oracle is aware of this issue and is working on it.

 Retrievals are definitely more HFM like in that when you are at the dimension member, you will not get any data returned! You have to select at least one level down in the hierarchy (sometimes more) to get your data. For Essbase guys this is annoying as you have to turn off and on suppress missing and while I’m not sure it will be changed, Oracle is aware of my annoyance with it.

FCCS also comes with the Web Based FR studio, It does not do 100% of what the client does, but has been updated with new charting that is more 21st century and more tablet friendly.


I think this product has a good direction and the Oracle team has been very helpful if answering my dumb questions about the product and how to implement it. The client is extremely excited as well as they can see how it with reduce their close cycle and give them better visibility, control and reporting.

I’ll be posting more in the future on FCCS as the implementation moves along, but this is enough to get you started




Anonymous said...

Great research Glenn. Thank you!!
You think FCCS has potential to replace HFM one day??

GlennS said...

I think it will be a long time for FCCS to replace HFM Currently they have different audiences with different needs.

ashwin said...

Great article Glenn and so are the other articles you have written on FCCS. Wanted to ask how much flexibility is provided to develop FR reports in FCCS or all we have the pre built financial reports to use for management and external reporting

GlennS said...

FR Web is included with FCCS so you can create your own reports. Currently , you can still use Reporting Studio to create reports as well, but that will be going away quickly

Anonymous said...

Hi Glenn. We are currently going through a proof of concept and there seems to be some confusion over data load using Data Management. Currently, we are testing YTD data loads, including balance sheet. YTD load is working. We are now being told that this will not be possible in the near future, that only periodic data can be loaded. It has something to do with the way movement works. In addition, mention of life to date vs. YTD balances in balance sheet account has been brought up. LTD balances will be loaded into movement opening balances and only periodic movement can be loaded. Can you please provide any additional thoughts you might have and if you have heard the same, please let me know?

Thanks so much.

GlennS said...

I didn't know the answer to your question so I reached out to Maggie Reed from the FCCS management team. Her response is
"Currently, you can load YTD or Periodic data. YTD means YTD income or YTD changes in balance sheet data. Coming in the next few months you will also be able to load Life to Date balances for balance sheet data. However, loading of LTD balance sheet balances will be limited to two purposes. 1) validating that all movement data has been entered (loaded closing balance ties to calculated closing balance) and as a source for calculating specific movement members when configurable calculations comes out."

From what I get from this is loading to YTD_input will still be supported but additional capabilities will be introduced to load LTD values but just for validation purposes.

If they removed the YTD_input, almost anyone who has already implemented would have to change the data management and that would be messy.

Bernardo Andrés Neira León said...

Hi, I was looking to the YTD vs Periodic load on FCCS and came across your blog.

Although there is a statement that DM can load both YTD and Periodic the manual is not very clear about this

"In Oracle Financial Consolidation and Close Cloud for YTD data loads, data is stored in Periodic view. In this case, the user must select this option so that a “pre-processing” is done to convert the YTD data from the file to periodic data for loading purpose"

I haven't been able to find this "option" mentioned on the manual, do you if there is a setting on DM to do this, all the solutions I've seen required mapping a different field for the View

Thanks in advanced

GlennS said...

If you load to YTD_input, FCCS runs a calculation to push it to Periodic by taking the difference between last period and this period. Starting in the 17.07 release you can also load balances , but the calc to convert it to periodic will not be available till the 17.08 release. (a couple of weeks away)