My experience with Form Development in HFM

I have being working on Oracle Hyperion products for past many years. Since my role always required me to focus more on solution design and project/program management, development work was restricted to more of Metadata built and business rule development with hardly any opportunity to work on Forms extensively. Fortunately I got the opportunity this time and it was good learning experience. So I thought why not share the same with all.

I will not go in to details about how the Forms are constructed but for those new to Hyperion Financial Management (HFM), Forms are UI for entering and viewing data at a Specific Intersection. Forms are extensively used for entering additional data which is out of the Trial Balance and/or cannot be uploaded directly from the transaction system.

You may have noticed that I have highlighted the word specific intersection. This is the most important part of form constructions, as every cell in a form is defined by the combination of each dimension defined in the application. So you can define dimension applicable to each cell in the form at:

1. Page level: which is applicable throughout the form. eg Value: <Entity Curr Total>, View: YTD

2. Column level: which is specific to each column. eg. Year: 1^st Column 2017 2^nd Column 2016.

3. Row level: which is specific to each row. eg. Account.

4. Specific cell level: This is done by overriding the dimension applicable as defined by the page, column and/or row. eg. Override Cell 1^st row & 1^st column by View as HYTD.

Though there might be some cell which are based on 'In Form' calculations or are blank, every other cell represents a specific data intersection in the application. Thus, utmost care should be taken while constructing Forms, else data will go to wrong intersection in the application and impact the final reported figures.

Now that we know that we can override the definition at cell level, let us dwell in it further. Override is nothing but replacing the dimension or formatting done at page, column or row level. So override can be defined in a column definition or row definition.

Points to remember about override:

1. Row Override definition takes precedence over column level definition.

2. Function like @Cur can be used in an override for Year and Period dimension.

3. In cell data calculation can be done to display data differently.

   Eg. If certain accounts values are to be displayed in different signage you can use the cell override as show below:

   Cell multiplied by -1: R5=A#Misc_Expenses, Override(2,2,SCalc((A#Misc_Expenses)*-1)).

4. Override can be used to override formatting like, Back ground colour, font, font weight (Bold/normal), Lines etc. E.g Override Background colour to grey in total column.

   (Be careful while overriding background colour as it will mask the invalid and data entry intersections, thus making it difficult to identify a wrong POV or data entry point.) 

5. Override also helps in a very interesting functionality of inserting text in a particular cell and then retrieving it in a different form.

    

   Eg. If we want to enter date in the 1^st column for the data in subsequent columns. Using Override(1,1,CellText:[Default]) in a Form will allow to enter text instead of values at the POV applicable to cell. The same data can be made visible in another Form using override Override(1,1,CellText:[Default],Readonly).

To view the data in another Form ensure that the POV of the display cell is same as the POV where the text is entered. Also ensure this cell is marked as 'ReadOnly' in the display Form to avoid and accidental change to the text from the display Form.

Some interesting finding:

• Override does not allow @cur(-1) or so on, for year or period dimension. So, make the dimension a row or column member so you don't have to override.

• Scale does not work on accounts type "Balance". Convert the account to Asset/Liability account.

• Custom header Description cannot have "," else will be treated as a code/specification and anything after "," will not appear in the header.

• In case multiple Dimensions are defined at column/Row level, order of 1^st column/row is applicable to following columns/rows.

• If you put ";" after style: in a row definition, then the background colour as defined in the column definition is used if not then back ground colour definition of row is used.

• Some RGB values for colour definition:

  • RGB(180,205,180) - green

  • RGB(255,255,255) - White

  • RGB(251,251,251) - Grey

Food for thought

When some text is entered at a child level and we want to display the same in consolidated report how can we do it? What will be the challenges and how do we address those?

In these days where blogs are being written about very complex subjects, I hope I am able to create some excitement in your mind about something as mundane as HFM Forms. I look forward to bring some more such blogs. Until then Keep Consolidating!!! J .