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.

Dimensions

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.

Calculations

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

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

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?

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.

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

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)