- Need Help? Talk to an Expert 888-664-4794
18 Dec
In Part 2 of our How Does It Work series on FCCS, we discussed how data is stored and accessed inside of FCCS. Today we will discuss the many ways we can calculate data in FCCS and then dig specifically into one of those types.
Calculation Options
With Hybrid Essbase and DSO behind the scenes and the all of the enhanced functionality that comes along with Oracle Cloud EPM from a foundation perspective, FCCS has a number ways we can calculate data:
- On-Demand Rules
- Essbase Calculation Script
- Groovy
- Configurable Rules
- Insertion Point Rules
- Equity Pickup
- Dynamic Calculations
On-Demand Rules
On-Demand Rules are those executed outside of the consolidation path. This means that they are not run when we run our standard consolidation. Instead, they are run by users, administrators, or automated processes as necessary. They can be attached to forms and executed when a user changes data. They can also be executed from the web-based interface or Smart View. And of course, they can be executed by a Pipeline or a traditional EPM Automate process.
There are two types of On-Demand Rules in FCCS:
- Essbase Calculation Script
- Groovy
Essbase Calculation Scripts
Calculation script-based rules are the traditional mechanism in Essbase to calculate data. In general, this will be the fastest way to calculate data in most instances, but it does have many limitations. First, we don’t have full control of our calculation in FCCS. The calculation has a pre-seeded set of parameters and these parameters are restricted members. Basically this means that we can’t reference these members in a FIX or on the left side of the equals sign. Luckily, we can reference them in an IF and the right side of the equals sign.
There are many use cases for On-Demand rules of this type, including allocations, reclasses, statistical calculations, and user-input based calculations.
Pros and Cons of Essbase Calculation Scripts
Pros
- Will always be the fastest way to calculate data
- Can be attached to forms, executed independently or from a pipeline
- Large set of professionals with existing experience in Essbase Calculation Script language
- Executed outside of the consolidation path
Cons
- Block creation will always be a consideration and pain point
- No visibility to changes made by the calculation
- Executed outside of the consolidation path
Groovy
Many in the Oracle Cloud EPM space would describe Groovy as a Get Out of Jail Free Card. This makes sense, because the main limits of Groovy are left up to your imagination. Are there things we are still limited on? Sure. Can we make changes to restricted data? No. Can we do almost anything else? Absolutely.
Groovy rules are still subject to the same limitations in terms of restricted members as a traditional Essbase Calculation Script-based rule. But, we can do so much more with Groovy, that its almost hard to compare to the two. We can pull data from Essbase, modify and calculation numbers, and write them back to Essbase. As an added bonus, when we update data with Groovy, there is a log of every change in the audit.
In addition, we can use Groovy to access and direct activities in our FCCS system itself or even access external systems. This makes Groovy a very valuable tool when working toward the goal of a system with limited outside dependancies.
Pros and Cons of Groovy
Pros
- Can completely mitigate block creation issues
- Full audit logs available of every change made from a Groovy script
- Can be attached to forms, executed independently or from a pipeline
Cons
- Smaller set of professionals with experience in Groovy rules
- Steeper learning curve for non-programmers
- Executed outside of the consolidation path
Conclusion
In this post, we covered the two most common methods of calculating data in FCCS. In our next part of the series we will move on to configurable rules that are actually part of the consolidation process.
