How to calculate data with FCCS

If you are familiar with HFM, there are not many places where calculations can be defined. You can have some aggregation logic in the hierarchies and member properties, but other than that all calculation logic is defined in the “rules file”. The other characteristics of HFM calculations is that you have to write everything; when you create a new application it does intercompany eliminations and default translations, but you have to code everything else including rolling forward opening balances, historical accounts translations, cash flow, equity pickup, any kind of elimination that is not just intercompany.

How does it look like with FCCS?

First, a lot of the standard calculations that most clients need come “out of the box” with FCCS. No need to write code to roll forward the opening balances, balance the balance sheet or calculate the cash flow statement! And the product management team seems committed to include more of these standard calculations going forward if they feel it would apply to multiple customers.

Now, your company is unique and chances are that you will have some specific requirements that do not come standard. FCCS can accommodate your specific consolidation needs with one of these four ways data can be calculated:

1. Member formulas

A member formula is a formula that is defined directly on a member (Account, Entity, …). It is part of the properties of that member and is written in Essbase calculation language.

It is similar to HFM dynamic accounts, except that it is a lot more flexible than HFM’s dynamic accounts. The thing that always annoyed me with HFM dynamic accounts is that you could not use a dynamic account as a source for another dynamic accounts; this is not a problem with FCCS.

Member formulas are perfect for ratios or any calculation that can be done on any entities including parent entities.

This page of the Essbase documentation provides a lot more details on how to write member formulas.

2. Translation overrides

FCCS calculates the default translations with the appropriate rates based on the account types (Income Statement, Balance Sheet, Historical translation), but if you need to override these translation, you can do that with translation overrides. For example to translate Actual at Budget rates.

The function can be accessed from the “Application > Consolidations” menu and provides a graphical user interface (GUI) to define these translations.

This is the equivalent of Sub Translate in HFM, except that most of the translations that need to be programmed in HFM already come standard.

3. Consolidation rules

Like HFM, FCCS eliminates intercompany automatically. But in addition to HFM, FCCS also includes a number of standard consolidation rules depending on the consolidation method of each entity. If you need your own consolidation rules, you can define them without the need to write any custom code as this is also done through a graphical user interface (similar to the one used for translation overrides). Also, if you just want to modify an existing consolidation rule, you can clone the existing rule and modify the cloned version.

This is equivalent to the Sub Consolidate in HFM. I will dive deeper into the standard consolidation rules and these configurable consolidations in a later post.

4. Configurable calculations

If all the above calculations rules are not enough to meet your specific requirements, you can open the hood and customize your own calculations using the Essbase calculation language. FCCS provides six “insertion points” in the consolidation process where you can write custom calculations, at the local currency, translated and consolidated levels.

Like with HFM, you are restricted to only the point of view currently being calculated as part of the consolidation process. The calculation is called for each entity as the consolidation goes up the entity hierarchy, and each time you can only calculate the current scenario, year, period, and entity. This point is sometimes confusing if you are used to Essbase where calculation scripts can calculate any cell of the database — think of it as an “external fix” wrapped around your script.

These configurable calculations were the main topic of my presentation at Collaborate this week and I will cover them in more details in a next post.