Overview

If you have ever used custom functions in Excel, depending on the complexity of them, you have probably run into an issue where the accuracy of the results was sporadic. There is a quick solution. Use CTRL ALT SHIFT F9.

The lengthier explanation from Microsoft explains that the calculation of worksheets in Excel can be viewed as a three-stage process:

• Construction of a dependency tree
• Construction of a calculation chain
• Recalculation of cell

With the introduction of complex VBA functions, the default calculation can produce inaccurate results because it doesn’t evaluate the dependency tree and calculation chain correctly.

So, if you have this issue, the most complete and thorough (and time consuming) calculation can be initiated by clicking CTRL ALT SHIFT F9. This forces the dependency tree to be rebuilt and recalculates the entire workbook. There are several levels in forcing Excel to calculate.

F9

Recalculates all cells that Excel has marked as dirty, that is, dependents of volatile or changed data, and cells programmatically marked as dirty. If the calculation mode is Automatic Except Tables, this calculates those tables that require updating and also all volatile functions and their dependents.
VBA: Application.Calculate

SHIFT F9

Recalculates the cells marked for calculation in the active worksheet only.
VBA: ActiveSheet.Calculate

CTRL ALT F9

Recalculates all cells in all open workbooks. If the calculation mode is Automatic Except Tables, it forces the tables to be recalculated.
VBA: Application.CalculateFull

CTRL ALT SHIFT F9

Causes Excel to rebuild the dependency tree and the calculation chain for a given workbook and forces a recalculation of all cells that contain formulas.
VBA: Workbooks(reference).ForceFullCalculation (introduced in Excel 2007)

References

• Microsoft.com Article
• Microsoft Article (PDF)

The Countdown begins

11.1.2.4 is being releases in as little as 10 days.  It is really exciting and here is what you will see.

On the fly iterative planning using sandboxes

• Create version on the fly
• Honors security and access rights
• Iterative modeling
• Dynamic scenario comparisons
• Collaborative modeling

Web form performance improvements

• Near 0 lag times
• Fast cell-to-cell navigation
• Quick scrolling
• Forms with 100,000 cells loads in less than 5 seconds

Setup valid combinations

• Forms show only valid combinations
• End users can only interact with valid combinations
• No more data entered in the wrong place
• Bypasses the lack of multidimensional security
• Speeds user interaction
• Out of the box clear of invalid combinations

User defined calculations

• Loaded from Excel by the user
• They persist with member references
• Excel syntax
• Supports most of the Excel financial, mathematical, and statistical functions

Real time push to ASO, including relational data

• Calculate and aggregate instantaneously

Simpler user interface

—–

This might introduce more questions than answers, but you don’t have to wait long to get them.  11.1.2.4 will be released this month – as soon as the end of next week!

Update for ASO (1/12/2015):

Recently, I was attempting to create Smart List functionality in an ASO cube. My only previous experience had been with BSO cubes, so I was not prepared for the couple of key differences that came up that hindered my progress. Here are the steps I took to successfully create a Smart List associated with an ASO cube. First, create a Smart List dimension by right clicking on the application in the dimension library:

For this example, I’ve named the Smart List “ClientSource”:

The Smart List has one member in it, “PV”:

And the Smart List will be associated with the account member, “ClientSource”:

In the account dimension, select the member that will have the Smart List associated with it (“ClientSource”),  and update the following 2 highlighted settings. This is the first part of the process that differs from that outlined above. In BSO, the settings are labeled “Data Type” & “Smart List”, rather than “Type” & “Smart List”:

After saving, I figured that the Smart List was good to go, but on deployment, I received the following error:

After some trial & error, the issue turned out to be coming from the data storage settings on the parents of “ClientSource”. After setting both parents (“AttributeInfo” & “Accounts”) to “LabelOnly”, the application deployed successfully.

To recap, there are 2 key differences between ASO & BSO cubes when setting up Smart Lists:

1. For BSO, the user must set “Data Type” to “SmartList” for the associated member. While in ASO, the user must set “Type” to “SmartList”
2. Before deploying the ASO application, the parent members of the member that is associated with the Smart List must be set to “LabelOnly”

I hope that this can help a few of you from having to spend time troubleshooting the difference between Smart Lists in ASO & BSO.

I was recently testing out the performance of rulesets that were attached to forms, and ran into an issue that had me scratching my head. Certain rulesets were not running or even appearing on forms that they were attached to in the Planning application. Turns out, the rules had been corrupted in the transfer between Calc Manager and the Planning application

The issue first appeared when looking at a Planning form. Prior to the testing, I had attached a ruleset to the Brokerage and Commission form. However, when looking at the form, the ruleset was nowhere to be found:

However, with a little digging, I was able to verify that there is indeed a ruleset attached to the form:

So, where is the breakdown happening?

From the Planning application, let’s take a look at the Business Rules to see if we can gather any more information:

Notice that some of the rulesets say “None” instead of displaying the play button. Broke_Comm, our missing ruleset, is displaying “None”:

It looks like we found the issue. These rules have been corrupted and will not launch in the Planning application. That would explain why we were not seeing the rulesets on the forms. Some maintenance is required to get the rules back up and running. Here are the steps I took to fix the issue:

Open up Calc Manager and select deployment view:

Expand the “To Be Deployed” folder and uncheck all of the rules (this list of rules should match up with the corrupted rules – rules displaying “None” in the Launch column – from the Planning app):

Right click on the application in deployment view and select Deploy:

In Planning, verify that there are no longer any non-launchable rules:

Next, head back to Calc Manager and check all of the rules that are under the “To Be Deployed” folder. Right click on the application and deploy. Navigate back to the Business Rules tab in the Planning application, where all of the rules should now be launchable:

Looking back at the Brokerage Commission form, the Ruleset that is attached is now displayed:

Note: This works most of the time, but sometimes following the above steps will not bring back all of the corrupted rules/rulesets. When this happens, I’ve found that the easiest solution is to:

1. Take an LCM backup of Calc Manager in Shared Services
2. Delete the rules that are corrupt
3. Import the rules from the backup that was just taken
4. Navigate to Calc Manager->Deployment View and Deploy all of the newly imported rules

This second option might take a little bit longer than the first solution outlined, but it will clean up your rules/rulesets and get them back to performing as expected.

This post looks at the “Allow Expansion” functionality in Financial Reporting Studio. “Allow Expansion” is a great feature, as it gives the user more flexibility when running and displaying reports. However, it can also require more setup work as it makes the report more complex. Two situations that I encountered recently:

1. Adding a custom heading using conditional formatting
2. Calculating formulas on expanded members

1) Adding a Custom Heading Using Conditional Formatting

For this example, I want to rename the account “PROMO”, to “Promotions” in the report. Typically, this setting can be changed by clicking on the “PROMO” cell and then editing the Custom heading in the properties box. However, with expansion enabled, the result will be that the member and its children will be renamed to “Promotions” with expansion enabled.

To demonstrate this, first we must enable expansion.  Highlight the entire row by clicking on the desired row number. Check the box next to “Allow Expansion” in the “Heading Row Properties” box. When expansion is enabled we will see that the custom heading will appear for all descendants of “PROMO”.

Run the report in the HTML preview, and click the arrow next to “Promotions” to see the children of the account. Notice in the screenshot below that both children now display as “Promotions”. How can we edit this so that the Custom heading only appears for “PROMO”, and not its children? This is where conditional formatting comes into play

The desired outcome is that both children will display their unique name as is stored in the dimension library. In order to accomplish this, some additional conditional formatting needs to be set up within the report:

The report needs to be given instructions on when to apply the custom heading. To apply this setting, we need to know what level or generation the account is, so that the rule will tell FR only to apply the custom heading on that specific account. For example, looking at the account structure below, “PROMO” is a Generation 7/Level 1 member of the hierarchy. We want the custom heading to only display for this level (i.e. “PROMO”) and allow the Generation 8/Level 0 members (i.e. children of “PROMO”) to display as usual.

The following 2 screenshots are examples of possible conditional formats for the member (based off the hierarchy above). Either of the 2 will work.

Select “Format Cells” and select the “Replace” tab. Enter in “Promotions” and click OK. After setting the conditional format, go ahead and run the report in HTML Preview again (Allow Expansion only works in HTML Preview, not in PDF Preview)

Expand on “Promotions” and notice the difference in formatting from before. The children will be displaying their unique member names as expected:

That took care of our first problem – How to set Custom Headings on Allow Expansion members using conditional formatting. Next up…

2) Dynamically Calculating using Allow Expansion

Another issue I encountered was that calculations didn’t update upon expansion of members. We’ll focus on the highlighted cell below to solve this issue:

The formula is a simple calculation, “PROMO”/”GROSS_SALES” or [A,3]/[A,2]:

When expanded, I want the calculation to update to show the relevant values for the children of “PROMO” i.e. the children will display as a percentage of “Gross Sales”. However, the values are static and do not update as expected. Notice that the 19.7% repeats itself for “Promotions” and its 2 children in the screenshot below. It seems that by hardcoding the formula to specific cells ([A,3] & [A,2]), the report only calculates “Promotions” / “Gross Sales”, instead of recalculating for the 2 children upon expansion (“425000/”Gross Sales” & “425040”/”Gross Sales”):

Rather than locking the numerator in place by selecting [A,3], we can improve the report by switching this value to reference the entire column [A]. Edit the formula by highlighting column B and typing the new formula into the formula box at the top of the report.

The new formula should look like this:

Instead of hardcoding the formula to one cell, the formula now has more flexibility for expanding members. Notice that the values calculate dynamically upon expansion this time around:

Overall, “Allow expansion” is a beneficial feature that allows users more flexibility with their reporting needs, but it sometimes takes a little more maneuvering to get the reports to display as expected.

This post covers the basics of building a Planning app. Building a Planning application can be a straightforward process; however, there are some pitfalls to watch out for. One or two mistakes can lead to some major headaches in trying to decipher what went wrong. Whether a beginner or a seasoned vet looking for a quick refresher, this guide will outline the steps necessary to successfully create/deploy a Planning application.

First, open up the dimension library, and then click File, New, and Application. This will take you to the first screen in the Application setup: Application Type

A. Application Type

There are 3 sections that make up the first screen

• Application Information

• Planning

• Calendar

We will tackle them one at a time…

Application Information:

1. In this first section, give a name for your application, as well as select Planning from the type dropdown. Giving the application a description is optional
2. Since we are creating an application using dimensions from the EPMA library, leave “Create Blank Application” & “Auto Create Local Dimensions” unchecked

Planning:

1. Select the application type (typically this will be General), and select the default currency for the application. You can select “Use Multiple Currencies” but this is not the most effective way of going about it. For more detailed insight on the utilization of multiple currencies in a Planning app, check out the following article:
• http://www.in2hyperion.com/post/2010/11/28/Why-Not-Using-the-Currency-Option-with-Hyperion-Planning-has-Benefits.aspx
2. Select and name the Plan Types that will be in the application. From the screenshot below, the application will have 3 plan types (Plan1, Plan2, Plan3)

Calendar:

1. Monthly, Quarterly, and Yearly application setup.
• Base Time Period: This can be 12 months, Quarters, or Custom (if you need a lower level of detail such as weeks)
• Fiscal Year First Month/Fiscal Year Start Date: Set the first month of the fiscal year as well as if it is the same calendar year or the previous calendar year
• Weekly Distribution: There are 4 options from this dropdown (Even, 445, 454, 544)
2. CAUTION: For the following section, both the Period and Year dimensions should be renamed to “Periods” & “Years” if Dynamic Time Series is going be turned on for the application (M-T-D, Q-T-D, Y-T-D, etc). If the dimensions are named Year and Period, Planning will not be able to differentiate between the dimensions and the dynamic time series members, causing errors.
3. Name the dimension “Years” and select the first fiscal year/number of fiscal years. The number of years ranges from 1-100.

After completing all of the above settings, click next to move on to the next screen, Dimension Selection:

B. Dimension Selection

This screen will have sections for the required, custom, as well as other dimensions for the application. First, the screen will auto populate whatever dimensions are already in the EPMA library. In this example, Entity, Account, and Alias are already filled in. The remaining dimensions (Version & Scenario) need to be populated via the dropdown menu:

These dimensions will be added as local dimensions to the application. Give the dimensions a name and make sure that the type matches the dimension that is being updated:

After setting the required dimensions, the custom dimensions can be selected in the next section. By clicking on the “[Select]” dropdown, the rest of the dimensions from EPMA will be available for selection in the application (note: your dropdown menu will not display the same selection as in this screenshot, as these dimensions had to be created in the Shared Library first):

If there are any Attributes, Smart Lists, or UDA’s that need to be added, the “Other Dimensions” section is the place to do that. Notice that there are 3 different Attributes to choose from in our Test application (I created these in the Shared Library beforehand as an example).

Reviewing the dimensions, there are 4 new local dimensions (Version, Scenario, Years, & Periods), 3 custom dimensions (Customer, Product, & BusinessUnit), & 3 other dimensions (Attribute, SmartList, & UDA). Click Next to go to the Application Settings screen.

C. Application Settings

1. The entire dimensionality of the new application is available to view/edit. Exclude/add members to the hierarchy as necessary. Make sure that all the dimensions are accounted for.
2. Properties of the application: This is a review of the application settings from the first screen. Double check that base time period, fiscal start year, and fiscal year first month are set. Also, make sure that the default alias table is set.

After making those changes, click Validate. A list of errors and warnings will populate below. These errors and warnings need to be taken care of before clicking Finish. There are a wide variety of errors that may be encountered such as duplicate members, duplicate aliases, invalid members, invalid plan types, etc. depending on your application. After fixing an error, click validate again and the error will disappear from the list.

Once there are no more errors, the application is ready to be deployed. Click Finish and go to the Application Library and right click, then deploy the application.

In Hyperion 11.1.2.1, there is a change in how security is deployed. If you are having an issue deploying Planning security with Essbase adhoc access, and the user can’t

1. Access Essbase Adhoc
2. Access FR reports using an Essbase connection
3. Access Essbase directly

you are not alone. This is not classified as a bug, but it sure can cause a lot of frustration. If you have a user that needs access to Essbase directly, the user can’t be associated to ONLY Planning applications. For them to get access to Essbase, even to access the Planning application, they must have security to a native Essbase application (a NON Planning application).

From the Oracle Doc ID 1328741.1

SYMPTOMS

Trying to add the “Essbase” application access type to a Planning user in Shared Services so the user can access native Essbase applications using the Excel Add-in. Shared Services confirms the update when saved but when checking the user again, it only has “Planning” access. This also happens when trying to use the MaxL command to modify the application access type.

CAUSE

Starting in EPM v11.1.2, a user’s type (application access type) cannot be changed by Maxl, the EAS console or manually via Shared services console. The type is automatically assigned based on the roles that the user has.

• If a user has a role on a Planning application only, then that user is treated as a Planning user.
• If the user has a role on a Essbase application only, then the user is treated as an Essbase user.
• If the user has roles on both Planning and Essbase applications the user is treated as a Planning and

Essbase user.

SOLUTION

In order for a Planning user to access native Essbase applications in the Excel Add-in, the user will need to be given access to a native Essbase application. For example, assign the Planning user “Read” access to the Demo application.