FCC - Using Entities that are Shared in Insertion Rules

When working with insertion rules, sometimes there is a need to calculate something only for specific entities. But, if that entity is shared - in other words, exists in multiple hierarchies or has multiple owners - there can be problems. Here's how to deal with this common problem.

The need most arises with IF statements. The code usually looks something like this:

IF(@ISMBR("331"))

   do some calcs

ENDIF;

This code will pass validation and deploy successfully, but when trying to consolidate, an error is generated.

Clicking the link and drilling into the error message will show this:

Unable to resolve duplicate member name ["331"] on line ____

The problem is the rule doesn't know whether to run for [ParentA].[331], [ParentB].[331], etc. One workaround would be to write the IF statement like this:

IF(@ISMBR("[ParentA].[331]"))

But if the entity gets moved, then that creates another problem.

The solution is to use the @EQUAL function. @EQUAL searches the outline for the specified string within a specified dimension. The result looks like this:

IF(@ISMBR(@EQUAL("331","Entity")))

If an additional entity existed like 331abc that should not be included, then add an additional condition to the IF statement to exclude that entity.

FCC Constant Currency

An occasional requirement for an FCC implementation is to translate data at multiple currency rates. There's always actuals at the actual rates, but then you can translate actuals at last year's rate, actuals at the forecast rate, actuals at next year's budget rate, etc. These different translations provide the data to show whether operations performed well against the comparative data or did the exchange rate just work in their favor.

There are a couple of different ways to set this up. The first question is whether to use a scenario or a custom dimension to hold the translation versions. If the requirement includes the balance sheet, is used occasionally, or the customs are already used, then one or more scenarios is the recommended direction. In the case I'm showing here none of those apply, so this example will use a custom dimension. The requirement is for income statement only, the output is used extensively during close and subsequent reporting, and a custom dimension is available.

After creating additional members in the custom dimension to hold the results, the next step is to create a custom translation rule (as shown below). The top half of the rule shows where to source the exchange rates. In this case, the rates are sourced from scenario Actual for the prior year. The "current period" is specified, so Dec 23 actuals will translate at the Dec 22 exchange rates, Nov 23 at Nov 22, etc. The second half of the screen controls the source and destination members. The left side shows the source data: no constant rate (custom), descendant accounts of net income, and only applies to the actual scenario. On the right hand side is any redirection (target) members. In this case, the results are stored in LastYrRate (so No ConstantRate is translated and then stored in LastYrRate). The account and scenario dimensions do not need redirection, so those fields are left blank so that those members simply pass through.

Once the rule is created it just needs to be deployed to be in effect.

So that will take care of the translations. But if the analysis will include operations from the total company's currency, what to do there? Example: if total company is in US Dollars and there are US Dollar entities that roll up to the total with only US Dollar parents, then there is no translation. As there is no translation, the above translation rule will not include that data. This can be addressed by adding an insertion rule to simply copy the data over from No ConstantRate to LastYrRate. Note that the FIX statement should specify level 0 members of the intercompany and other custom dimensions.

One note on the @ISUDA function used. IsUSD is a UDA that is applied to the level 0 entities that have the "home" currency. Apparently there is a function that can read the entity currency directly but it isn't visible as of now in Calculation Manager. Oracle has filed an internal SR to expose the function which will remove the requirement to tag the entities with a separate UDA like this.

The custom translation and insertion rule will run with each consolidation. After consolidating, the users can simply switch their POV in reports, Smart View, etc. between the custom members No ConstantRate (for actual numbers) and LastYrRate (for actual numbers at last year's rates).