HFM Student Reference Manual

Trang 1

Hyperion Financial

Management

Developed in Partnership with and based on work by

Eric Erikson, 123OLAP

Hyperion Financial Management

Trang 3

HYPERION FINANCIAL MANAGEMENT 11.1.1

IMPLEMENTATION BOOT CAMP

Copyright Notice

Based upon the copyrighted works of:

Corporation

Trademarks

Windows/Windows 2000/Windows XP, and Microsoft Office

are trademarks of Microsoft Corporation

Excel, Windows/Windows 2000/Windows XP, and Microsoft Office are products of Microsoft

Corporation

Essbase is a registered trademark of Oracle

Other product names mentioned in this document may be trademarks or registered trademarks of their respective companies and are hereby acknowledged

Disclaimer

The information in this document is subject to change without notice

Neither Oracle Corporation nor 123 OLAP shall be liable for errors contained herein or consequential damages in connection with the furnishing, performance, or use of this material

Trang 5

TABLE OF CONTENTS

Introduction

About the Author 1

Chapter 1 - Overview of Oracle Hyperion

Financial Management

Financial Reporting 1-2 HFM Structure and Design 1-2

What is a Dimension? 1-2 Members 1-4 Hierarchies - The Family Tree 1-5 Point of View 1-5 Drilling Up and Down a Dimension 1-6

Oracle EPM 1-6 HFM Server Architecture 1-6

Trang 6

Entity 2a-17 Scenario 2a-18 Organization by Period 2a-19 Putting Everything Together 2a-20

Summary 2a-21

Chapter 2b – EPM Architect

EPMA vs Classic 2b-2 EPMA Components 2b-2 Dimension Maintenance 2b-3

Accessing EPMA 2b-3

Application Maintenance 2b-10 Application Deployment 2b-13 Data Synchronization 2b-13 Application Upgrade 2b-17 Task Automation 2b-18

Summary 2b-19

Chapter 3 – Data Loading

The Native Format 3-1 Data Loading Alternatives 3-6 Data Extracting Alternatives 3-11 Copying and Clearing Data 3-13

Summary 3-15

Chapter 4 – HFM Rules

The Basics 4-1 Grouping Rules - Subroutines 4-2 Function and Dimension Syntax 4-3 Variables 4-3 Restricting When Rules Run 4-4

Trang 7

Common Calculations 4-7 Functions – Repeating Code 4-11 Easy Performance Improvement – With HS 4-11 Calculating Manager 4-12

Summary 4-12

Chapter 5 – Creating and Building Lists

Member Lists 5-1 Creating Lists 5-1 Loading and Extracting Lists 5-3

Summary 5-4

Chapter 6 – Shared Services

Security Basics 6-1 Provisioning Users and Groups 6-2 Creating and Assigning Classes 6-5 The Other Way (for Classic Applications) 6-8 Organizing the Design 6-9

Summary 6-10

Lifecycle Management 6-10 Shared Services – Other Features 6-12

Chapter 7 – HFM Administrative Stuff

HFM Copy Application – Classic Only 7-1 HFM Utilities 7-7 HFM Administration 7-10 System Messages 7-10 Task and Data Audit 7-11 Task Automation 7-13 Other Administration Menu Items 7-16 Process Control and Validations 7-16

Trang 8

Creating Data Entry Forms 7-19 HFM User Group 7-24 Typical Administrator Life 7-25

Chapter 8 – HFM End User Basics

Logging In and Logging Out 8-1 Tasklists 8-3 Creating Tasklists 8-4 Adding and Saving Tasklists 8-5 Data Grids 8-6 Creating a Grid 8-6 Modifying the Layout 8-7 Member Selections 8-8 Mulitple Member Selections for Rows and Columns 8-10 Working With Data Grids 8-12 Grid Background Colors 8-13 Common Data Grids 8-14 Data Entry - Multiple Ways 8-14 Data Entry Forms 8-15 Journals 8-16 Journals Overview 8-16 Creating Journals 8-17 Journal Templates 8-20

Chapter 9 – HFM End User Next Steps

Intercompany Reporting – Some Background 9-1 Running an Intercompany Report 9-2 Creating/Modifying an Intercompany Report 9-6 Process Control 9-7

Trang 9

Chapter 10 – HFM End User Reporting

Running Reports 10-1 Hyperion Smart View for Microsoft Office 10-4 Smart View Functions for Microsoft Excel 10-6 HFM Forms within Microsoft Excel 10-8

Ad Hoc Analysis 10-8 Opening Reports in Microsoft Office 10-10 Using Smart Tags 10-12

Chapter 11 – Financial Reporting Studio

Laying Out a Report 11-3 Selecting Members 11-6

Adding, Removing,and Moving Member Selections 11-7 Prompts and Current Point of View 11-7 Placing Selections into Separate Rows 11-8 Relationship Function Selections 11-8 Relationship Function Alternatives 11-10 Advanced Selections 11-11 Lists Tab 11-12 Editing Selections Manually 11-12 Limiting the Point of View Selections 11-13 Additional Rows/Columns 11-14

Previewing the Report 11-15 Saving a Report 11-15 Page Dimension 11-16

Text Rows/Columns within Grids 11-22 Inserting Functions 11-23

Formulas 11-29 Charting 11-31

Chart Layout 11-32 Types of Charts 11-32 Chart Properties 11-33

Trang 10

Chapter 12 – Workspace Reporting

Workspace 12-2

Logging into Workspace 12-2

Books 12-7

Creating Books 12-8 Deleting Reports from a Book 12-10 Selecting Members for Books 12-10 Previewing Books 12-12 Saving Books 12-14 Book Setup 12-15

Batches 12-16

Scheduling Batches 12-18 Batch Scheduler 12-22 Canceling Batches 12-24 Batch Outputs 12-24

Snapshots 12-26

Assigning Access to Snapshots 12-27

Batch Comman Line Processing 12-28

Trang 11

About the Author

The contents of this course are based on the work of Eric Erikson

Eric Erikson is a Hyperion Certified Professional™ in Hyperion Financial Management and Hyperion Enterprise With experience working with Hyperion Enterprise since 1993 and Hyperion Financial Management since 2000, he has been exposed to hundreds of

consolidation and reporting applications for a wide variety of industries Eric’s broad

consulting background includes working for Hyperion Solutions for several years and a large Hyperion partner for three While at Hyperion Eric began working with Hyperion Financial Management before its commercial release His technical skills encompass all aspects of implementing these products Eric is an active CPA licensed by the state of North Carolina and has MS and BSBA degrees in Accounting from Appalachian State University

Introduction

I

Trang 12

I-2

Trang 13

1 - 1

Overview of Oracle Hyperion

Financial Management

he focus of this Chapter is to review Oracle Hyperion Financial Management

(“HFM”) and understand the dimensional concepts The first step is to frame where HFM fits into an organization Next is explanation of some key concepts of HFM such as the application structure and design, dimensions and attributes, the hierarchical

relationships and terminology used throughout the product We’ll finish up by talking about the Hyperion product family and HFM’s server architecture By the end of this chapter

students have the background necessary for the remainder of the course

Chapter

1

T

Trang 14

EPM Financial Management© Chapter 1: Overview

1 - 2

Financial Reporting

Financial reporting, at its core, is about creating balance sheet, profit and loss, cash flow, and accompanying reports for a business While there are many differences from one company to another, there are many similarities Many of these similarities are determined by GAAP – generally accepted accounting principles For example, year to date net income should be added to a company’s retained earnings balance

To provide the ability to report, companies use one or more chart of accounts to categorize the

data in their general ledger Some accounts may have additional detail, like a list of

states/provinces for sales tax or a product family for revenue accounts

Companies also have an organizational structure This could be by legal entity, by cost center,

by manager, or a combination For each entity a set of reports is required

For a few companies the reporting for the overall company is a simple matter of adding the accounts together across the organizational units Usually, however, there are additional tasks, such as currency translation or eliminating any intercompany balances or ownerships

Along with consolidating the data, the data must be controlled Approval of journal entries, electronic certification, and controlled access (who can see what and when) are all features that accountants and auditors expect from a consolidation system

HFM is Oracle’s module for financial consolidation The product was built with web

deployment and support for hundreds of users Its predecessors extend back into the early 1980s when a company called IMRS developed and marketed a DOS product called Micro Control In 1991 the next generation product, with a Windows interface and file storage intended for a file server, was released Initially this product was called Hyperion; later the company changed its name from IMRS to Hyperion and changed the product name to Enterprise HFM is the latest in this line, being released in 2000 While each product improves

on its predecessor in terms of functionality and architecture, some features conceptually work the same way, as some basic accounting principles have not changed in that time!

HFM Structure and Design

Data in HFM is stored across a number of dimensions

What is a Dimension?

Dimensions are parameters or pointers to an amount Each amount placed into HFM will have 12 dimensions defining the reference point for that amount

The Basic Six…

Consider this sentence for an example of the basic six: Actual Net Income for Total

Company in June 2009 on a Year to Date basis was 100 In this sentence there are 6

dimensions:

Trang 15

1 - 3

From the example… What this is / other

choices might have been In HFM the dimension is called …

Budget, Forecast Scenario

Total Assets, Sales, Taxes Account Total Company Organizational Unit

Division, Cost Center Entity

Periodic, Quarter to Date View

The Next Five – Account Details…

There are five other dimensions that relate specifically to detail in the chart of accounts The first of the five is Intercompany Partner If division A is booking intercompany sales with

division B, for instance, the account would be intercompany sales and the ICP dimension would indicate that the sale was to B For non-intercompany accounts, the partner is simply [ICP None]

The other four are optional (each company specifies which to use and how) and can provide a great deal of flexibility Called Custom Dimensions, they allow for a greater level of detail

and can be used differently across accounts For example, Sales may be reported by state, customer, product, and sales rep; whereas Salaries may be reported by state and job grade If the application is designed appropriately, the states can be shared in both cases

By having the ICP and custom dimensions reporting is easier and much more flexible than if the detail was just stored in multiple accounts Maintenance is also easier – in the state

example above, a new state would only need to be added once to the custom dimension vs twice (once for the sales account and once for the salaries account) and would apply to all accounts to which the custom dimension is assigned

The Twelfth – Consolidation Detail…

The last dimension is a bit different from the others in that it is not something that is based within the company’s operations (like accounts, entities, products, etc.) The Value dimension

is used to show the detail of the consolidation of data from a member in the entity dimension

to its parent There are various details available, like before and after currency translation and before and after intercompany eliminations Also, journal adjustments are segregated from data loaded from the general ledger or other data sources Data starts at the bottom, works its way up the Value dimension to the parent entity where, after added together with the data from the other children of the parent, the new data starts at the bottom again Note: more about the “children” and “parent” references below

Trang 16

1 - 4

The member labels and the hierarchy for the Value dimension are predetermined

The Value dimension looks as shown to the left The members in < > are specific

to the entity, regardless of the parent The [ ] members represent a combination of the parent and entity Data from a single entity can consolidate differently based upon the designated parent

A parent entity is the sum of its children’s [Contribution Total] members This sum feeds into <Entity Currency> at the parent and the process starts over from the bottom

The commonly used ones are:

<Entity Currency> Data loaded from the general ledger or manual input

<Entity Curr Adjs> Local currency journal adjustments

<Entity Curr Total> Sum of the first two

<Parent Currency> <Entity Curr Total> after currency translation

<Parent Curr Adjs> Translated currency journal adjustments

<Parent Curr Total> Sum of the previous two

[Proportion] Data after translation and ownership calculations

[Elimination] Intercompany and other eliminations – note this member ONLY shows the elimination entries, not the full balances

[Contribution] Usually the final amounts going from the entity to its parent

Members

Members in HFM are the unique elements making up a dimension Some sort of text or numeric descriptor defines every member This is referred to as a label For example, in a customer dimension, unique customer names or numbers may define the hierarchy of that dimension Each of these is a member In addition, the regions that the customers may belong to (the groupings) are also members In other words, members are all the elements that define the hierarchy of a dimension

It is important to understand that member names must be unique in HFM within a

dimension For example, Cash in Bank and Petty Cash cannot both be labeled as account 100

Trang 17

1 - 5

Depending on the dimension there are various attributes or details that the system stores and provides different functionality accordingly The most common attribute is description, like the description for account 100 might be “Cash.”

Hierarchies - The Family Tree

Hmmm… What were those “children” and “parent” references about?

Dimensions have a natural hierarchy associated with them As an example, think of a

company that has sales offices in their entity dimension The lowest level of members would

be the sales office: Charlotte, Omaha, San Jose The level above that may be a region: East, Midwest, and West The top level may be the country Each lower level of the dimension is more specific In HFM terms the sales offices are children of the regions and the regions are parents of the sales offices

Another example: this time using the Account dimension Total Assets may be made of Current Assets and Long Term Assets Under Current Assets are Cash, Accounts Receivable, and Prepaids

Any member that does not have a child – the lowest level – is called a base level member The

hierarchy provides multiple benefits First, the hierarchy defines the rollup To the right, the children of Current Assets are added together If there

was a liability account among the asset accounts, like

Allowance for Doubtful Accounts, HFM would pick that

up (account type is one of the attributes for accounts) and

do the correct math Also, the hierarchy allows for easy

report writing, like “Children of Current Assets.” The

advantage here is that if another child is added later, like

Inventory, then the report picks it up automatically The

third advantage is for drilldowns, meaning a user can look

at Current Assets and then click and see the detail underneath

There may be multiple hierarchies within a dimension Entities are typically rolled up based on

a legal hierarchy, a management hierarchy, and others Accounts may be rolled together differently for US GAAP vs IFRS reporting The key thing is that base level data is stored once Members can roll into multiple parents for as many types of reporting as needed Dimension members are either base level members or they are parent level members

Point of View

When looking for a specific amount in HFM, all 12 dimensions are required (the custom dimensions, if not needed, use [None] as the default member similar to the ICP dimension using [ICP None]) The point of view is the specification of each member for the 12

dimensions Another way to say it is that the point of view is what the user wants to see, like Year to Date Actual Net Income for Total Company in June 2009

Trang 18

1 - 6

Drilling Up and Down a Dimension

Since the dimensions are organized with hierarchies, users can navigate in HFM by drilling down (zooming in) the hierarchy or by drilling up (zooming out) This makes building reports intuitive as you navigate the natural structure of each dimension

Oracle EPM

HFM is the lead Financial Reporting & Compliance product in the Oracle Enterprise

Performance Management, Fusion Edition suite The below diagram shows the major

components of the suite: HFM is the main “Financial Reporting and Compliance”

component

HFM Server Architecture

HFM was designed to support any number of users that a company would have involved in month-end consolidation and reporting There are multiple logical layers that can grow as needs warrant

• End users – end users connect via a web browser or Microsoft Office

• Web layer – the web layer provides the web content to end users

• Application layer – the application layer contains all of the intelligence and performs all of the processing for HFM

• Database layer – the database layer stores the data, metadata, web components, etc in

a relational database

Trang 19

1 - 7

For a small implementation, the web and application layers may reside on one physical server

As the implementation size increases, these layers are first separated to different physical servers and then additional servers are added to each layer

Summary

HFM has 12 dimensions that are used to store the amounts Each dimension is made of members, some of which are base level members Members are organized hierarchically with children rolling into one or more parents The point of view is the specification by the user of the data that they want to see HFM is part of a broader suite and is architected to

accommodate different numbers of users

Trang 20

1 - 8

Trang 21

2a - 1

Creating Applications – Profile and

Metadata - Classic

he focus of this Chapter is to review how to create and build applications using the

“classic” method The first part is creating the profile, which defines the Year, Period, and View dimensions along with languages The other dimensions, currencies, and application settings follow Throughout are performance considerations to effect an efficient design

Application Profile

The application profile is the first piece to be created The profile defines the years, periods, and views available in the application These items cannot be changed once the application has been created – to change something, the admin will need to recreate the application and reload everything

Profiles are created in the Windows client From the left frame, select Define Application Profile The interface pops up with icons across the top to guide the admin in the required steps

Chapter

2a

T

Trang 22

EPM Financial Management© Chapter 2a: Creating Applications

2a - 2

Languages – HFM can store descriptions for entities, accounts, etc for up to 10 languages Users select which they prefer Generally add the languages that will likely be used, even if the language will not be used soon

The third screen is Define Calendar This window sets up the time periods that will be

available If using a standard monthly/quarterly calendar, the left side has selections to quickly build the calendar If something different is needed, the right hand side is used to establish the base periods and a prefix if desired The default is to number the custom periods sequentially: this can be changed on a later screen At the bottom is the starting year and number of years

to be available

Trang 23

2a - 3

When thinking of the start year, think of the history to be loaded In addition, a previous year

to that may be needed to provide ending balance sheet balances

For the number of years, consider the number of years the application will be used before business requirements call for a complete rebuild If long range planning is being considered, then more years may be needed Setting the number at 15 to 20 is common

Most applications have months as the lowest period If a greater frequency is being considered, like weekly, then consideration should be given to the importance of the data and whether it should be in a different application or even a different Hyperion tool like Essbase HFM builds tables within the database to store data and columns are created for all periods whether used or not – if the profile has weeks and a scenario is created that only specifies monthly data, the table will still have fields for the weeks These extra fields adversely impact performance; however, the impact may be negligible for smaller applications or immaterial if the frequent data is required

To give a sense of how performance decreases as periods are added, a data record with monthly periods consumes about 120 bytes of memory Going to weekly data, the same record consumes about 480 bytes A daily data record consumes about 3,300 bytes The more memory consumed by each record means that fewer records can be loaded into memory at any one time, which is important for consolidations and reporting

The fourth screen is for the View dimension Each period level, like Year, Quarter, Month, needs a view member Descriptions can be provided in each language

Trang 24

2a - 4

The fifth screen is to edit the periods Periods can be moved around and the labels changed as desired The months are generally changed to have abbreviated labels with full descriptions

The last screen is to save the profile The location is not important to HFM as the profile will

be uploaded; however, the file should be kept in a safe location for future use and reference as needed

Creating the application profile only takes a few minutes; however, the consequences last through the lifetime of the application

Creating the Application

With a profile, the application can now be created Creating the application can be done either through the Windows client (click on Create Application on the left) or via the web Either way, the information is the same Below is the web version

Trang 25

2a - 5

To reach this screen, log into the Workspace From the Navigate menu select Administer, Classic Application Administration, Consolidation Administration Then, on the left side of the resulting window click on Create Application

Fill in the information and click Create Application labels cannot start with a number and are limited to 10 characters See the help guide for more information The Financial Management Web Server URL will typically use port 19000 and end with /hfm If the user management project is blank then that will need to be created first within Shared Services

The Year, Period, and View dimensions will be created The value dimension is built in The remaining dimensions as well as some settings remain to be done Also, the user who created the application has been provisioned in security to be the administrator, but no one else has access

Managing Metadata

This section focuses on building the entities, accounts, custom dimensions, scenarios,

currencies and application settings Some of these only take a few minutes (ie, currencies) – some take longer There are some basic concepts that work for all dimensions and will be covered first Specific information will follow for each item: commonly used attributes and design and performance considerations

Working with metadata can be done in a few different ways This chapter will cover two – the Metadata Manager way and the Notepad way There are a couple of other methods not covered here – EPM Architect and Data Relationship Management

Metadata Manager is part of the HFM Windows client It provides an interface for building and maintaining the dimensions It is best used for small amounts of initial entry or changes Working with Notepad or another text editor, large scale changes can be made – this method

is preferred for the initial build (like converting an existing 2,000 member chart of accounts into HFM)

Trang 26

2a - 6

Working with Metadata Manager

The HFM Windows client is Windows software that has to be installed on the computer This is the same Windows client where the profile is created On the left are various tasks The task involved here is Manage Metadata

The screen above shows an entity structure For Corporate, the highlighted entity, attributes are shown on the right At the bottom are tabs for Tree View (currently displayed) and List View (shows everything in a table – good for sorting and making more medium scale

changes)

Trang 27

2a - 7

Going back to the tree hierarchy tab, new items can be added either as a child of the

highlighted member or as a sibling by clicking on the appropriate arrow directly above the hierarchy The items in the hierarchy can be reordered by clicking the blue/black arrows directly above and to the right of the hierarchy Items can also be moved simply by dragging them

TIP – in Tree view, to copy an item, press and hold Control and Shift and then click the item, drag, let go of the mouse, then let go of the keys

Switch from one dimension to another with the Metadata Item dropdown at the top

Use the Save File button to save changes

When making major changes a new version of the file should be created This allows the application to be reloaded with the original version

When saving, the default filename is the originally opened file, EVEN IF IT HAS ALREADY BEEN SAVED AS SOMETHING ELSE Be careful not to overwrite the original version

Working with the Text File

There are two file types from which to select when saving files The first is XML – the regular type The second is APP – this file type saves the metadata in a format that can be used in Notepad and other text editors

Below is the entity hierarchy above in the text format The fields are delimited by semicolons; therefore, it is best NOT to use semicolons in labels and descriptions Each dimension will be listed in the file like below in two sections – members and hierarchies

Trang 28

2a - 8

Typical initial implementations have a phase where the existing chart of accounts and entity structure are downloaded into text files and reformatted into this format Much better than keying everything in!

The two formats can be used interchangeably The Metadata Manager can open and save either format HFM can load and extract either format

Within each dimension can be multiple hierarchies A company may have an internal entity structure and an external one In both cases the base or lowest level members should be the same: just different parents For application efficiency there are two tenets to follow:

• Parents should have more than one child It is inefficient for the system to add up data from a single child to a parent The common exception to this is with entities when the currency changes – in the example above, Canada_USD is in US Dollars and Canada is in Canadian Dollars HFM doesn’t need this for translation and the same currency reporting can still be done, but it is usually easier for the users to think about it with two entities

• When parts of two hierarchies have identical children, use the same parent both places instead of two separate parents The system will have to calculate the parent only once vs twice Keep in mind that changes to the parent on one hierarchy will show up on the other – it is the same parent When discrete differences are needed, create the second parent

When adding to an existing metadata file, do not make a base level member into a parent unless the metadata has not been loaded into the application In order to perform this change, HFM will have to clear all data – typically not the best thing to do

Loading and Extracting Metadata

The metadata file, in either format, can be loaded into HFM via the web or the Windows client Below is the screen from the Windows client – the web interface has the same options

Trang 29

2a - 9

Click on the search icon to find the metadata file A log file will be filled in – this will contain any errors – and is usually the same folder and filename with a LOG extension The load method specifies whether to merge or replace If doing deletes or moves of members a replace has to be done in order to effect the change Below that are choices for which

dimensions to load At the bottom of the screen is the Load button to start the load The scan button checks the metadata file for most errors

In practice administrators typically extract all metadata options into a single file, make the changes, and then do Replace loads

Checking the “Clear All Metadata Before Loading” and then clicking Load will generate this message:

Basically doing this means that everything has to be reloaded – it is not typically used

Extracting metadata provides choices for the file location and filename and the dimensions to

be included

The rest of the chapter addresses specific metadata items as listed in the Metadata Manager, reviewing the most commonly used attributes and design and performance considerations

Trang 30

2a - 10

Accounts

Commonly Used Attributes

When building the chart of accounts there are several attributes that are commonly used This list is not inclusive of all attributes and does not cover all capabilities of HFM There are also application design considerations that may differ from the information below

Label The member name For this dimension it typically works best if the

base level financial accounts are numeric (like on the general ledger) and the parent, statistical, exchange rate, etc accounts are alphanumeric Proper case (like CurrentAssets) works better than all caps

(CURRENTASSETS) due to the web interface – people are used to proper case Spaces in the label are not typical, although allowed

Description Description that will show on reports, spreadsheets, data views within

HFM, etc Proper case works best

Account Type Most accounts will be flagged Asset, Liability, Revenue, Expense Other

types are Balance and Flow (work like Asset and Expense but do not translate), Dynamic (see the Rules chapter), Currencyrate (exchange rates), and GroupLabel (does not store data but used for organizational purposes)

IsCalculated Prevents input into an account that is calculated Note – an account can

be calculated but not flagged as such Any data loaded or manually entered will be replaced by the calculated number Exception to use: when an account is calculated for one scenario, year, etc but not another To prevent any misunderstanding, use a NoInput rule to block data entry into the calculated scenario, year, etc

Trang 31

2a - 11

IsConsolidated Used on most accounts Exceptions include ratio accounts

IsICP Enables the use of the ICP dimension to store detail, typically for

intercompany elimination – DOES NOT ENABLE ELIMINATION, but is the first step There are three choices: N for no, Y for yes, and R for yes AND an entity cannot use itself as the ICP

PlugAcct Enables intercompany elimination on the account by specifying where

to place the surviving amount Accounts that should match against one another should all use the same plug Intercompany relationships should all use unique plugs More on intercompany elimination in the end user section

C1-4TopMember Specifies whether the account uses the custom dimension and what

part of it For example, the Sales and Cost of Sales accounts may enter a Custom1 member called TotalProducts, but the balance sheet and operating expense accounts would not

UserDefined1-3 3 fields that can be used for creating lists, restricting calculations, etc SecurityClass A link to security if to be used for the dimension Typically exchange

rate accounts are secured to limit input to a few individuals

EnableDataAudit Keeps track of changes to data Used in conjunction with a setting in

the Scenario dimension Typically enabled for all base level accounts CalcAttribute An explanation of the calculation behind an account (not the

calculation itself) Can also be used for comment on account usage SubmissionGroup Used in process control if more than one group will be used For

example, the first group of accounts to be signed off could be the financials and the second group could be the supplemental data

Design and Performance Considerations

When building the account dimension, the recommended maximum number of account levels is 13 or fewer Also remember the two tenets above about metadata: no parent with just one child and no parents with identical children

All parent accounts are calculated when the scenario, year, entity, and value dimension

combination (called a subcube) is opened in memory, whether they are needed or not for the particular report, view, calculation, etc It is best to control the parents to what is needed However, this statement should not discourage admins from using the capabilities – if three different account hierarchies are needed to meet reporting needs then by all means create them

For contra accounts, like accumulated depreciation, there are two choices:

• Flag the account the same type as the regular account and load the data as negative

• Flag the account the opposite type as the regular account and load the data as positive Either choice will provide the same result – the difference is how numbers are presented in the reports The desired presentation dictates the correct choice

Trang 32

2a - 12

Application Settings

Fields for Application Settings are on one line Scroll right and left to get to the various items

Commonly Used Settings

Application settings are not a hierarchy – not even presented as such – but rather they control how the application works and enable some of the functionality

DefaultCurrency The default currency is used for calculating exchange rates when a

direct rate is not available For example, a translation from CAD to EUR will first look for a direct rate and if not available then the CAD to DefaultCurrency and the EUR to DefaultCurrency rates will be used together to calculate a rate

DefaultRateforBalance Specifies which account (with a Currencyrate account type) will be

used to store the exchange rates for balance type (asset and liability) accounts

DefaultRateforFlow Specifies which account (with a Currencyrate account type) will be

used to store the exchange rates for flow type (expense and revenue) accounts

UsePVAforBalance Specifies whether to use periodic value or value translation

methods Typically left off

UsePVAforFlow Specifies whether to use periodic value or value translation

methods Typically turned on

Trang 33

2a - 13

ValidationAccount Specifies the account that should be zero before end users can

promote the entity in process control Typically this is a parent account with the various edits (ie, balance sheet in balance, comments provided for budget variances, etc.) below it If using multiple process control phases then this will be the first phase ConsolidationRules Enables admin created consolidation rules (ownership and

elimination) or to use the default process Generally this setting, even if doing the standard ownership and elimination, will slightly slow down consolidation time, so only enable if something special

is to be used (ie, discontinued operations or changes to intercompany elimination process)

A third choice is R, meaning use the standard ownership and elimination but calculate the Proportion value member This setting can provide a performance benefit to many applications if consolidation rules are not needed

OrgByPeriod Allows the entity hierarchy to vary from one scenario/year/period

to another For example, DivisionA may roll to Region1 for Actual,

2008, January but roll to Region2 for Actual, 2008, February In Metadata Manager DivisionA will appear to roll to both places but will only be active as listed If this function is not needed on a regular basis (there are ways to handle exceptions) it is best to leave off

UseSecurityFor… Specifies whether security is to be used for a dimension

EnableMetadata

SecurityFiltering If an end user does not have access to a member, should they see that it exists or not Typically enabled to shorten the hierarchies for

users to page or scroll through

UseSubmissionPhases Enables the use of more than one submission phase for process

control Along with this are settings for the customs dimensions and multiple validation account settings

FDMAppName Specifies the FDM application associated with the application Can

be used in data grids to link back to the source data loaded via FDM

The big choices here are using consolidation rules and org by period Both add flexibility and functionality, but there are performance and maintenance considerations Consolidation rules,

as a rule of thumb, add about 5% to the consolidation time even when doing the standard consolidation (equivalent to HFM not using consolidation rules) Organization by period introduces another level of maintenance and system usage: tracking when entities are active or inactive for each parent A following section of this chapter provides more information on organization by period Despite these considerations, consolidation rules and organization by period are powerful features that should be used when required

Trang 34

2a - 14

Consolidation Methods

Consolidation methods are used to provide settings for various types of consolidation that address various ownership requirements The methods listed here are assigned to entities and then can be referenced in a consolidation rule to perform the desired aggregation

Trang 35

2a - 15

Currencies

List the currencies needed in the application There are only a few options

Scale Can be useful if scaling the exchange rate is needed Must be set to

at least zero (units) if scaling is not to be used (cannot be blank)

TranslationOperator Multiply or divide – which way are the rates stated? Like CAD to

USD or USD to CAD

Custom1-4

Trang 36

2a - 16

Custom dimensions provide additional detail to accounts Any particular dimension can be reused across accounts For example, part of custom1 may be used for product detail on the sales accounts and another part used by balance sheet accounts for movement detail The switch to enable any part of a custom dimension for an account is in the account attributes – CustomXTopMember Customs may also be used by more than one account, like Custom2 might have a list of states that are both used for sales and fixed assets

IsCalculated Useful for when one member is calculated and another is not The

IsCalc flag on the account should be off as there is input to at least one custom member An example of this might be for cash flow accounts where there is a calculation of the line item in one custom member and another member allows for adjustment to the

calculated result

SwitchSignforFlow Have a custom member work like a liability when attached to an

asset account, for example Good for movement detail schedules when positive numbers are desired

SwitchTypeforFlow Have a custom member work like an expense account (having

periodic vs YTD amounts) when attached to balance sheet type account Also good for movement schedules

AggrWeight This attribute is not on the main attribute tab – go to the Node

Attribute tab to see this Normally this is 1, meaning to add the numbers to the parent custom member There are instances where this is not desired For example, Custom1 is used for products and the top member is Products Under Products are two hierarchies

of Products, ProdFactory and ProdFamily The numbers at these two members are the same One of these would have an

aggregation weight set to 0 so that the Products member can also

be used as a top member While a little redundant, its easier for the users

Parent custom members are only calculated when they are asked for, so the depth of the dimension, number of parents, etc does not really matter Also, the order doesn’t matter The largest custom dimension could be 1 or 4 or whatever Typically the most frequently used dimension is placed in custom 1, then 2, etc This works well with the point of view bar – not having to scroll all the way to the right to get to custom 4 unless needed If a lot of accounts are sharing a lot of customs then some thought into the arrangement is needed so that everything can be shared adequately No need to have states listed in both custom 1 and custom 2, for example

It is important to remember that the customs are four per account A sales account can have

four customs assigned to it and a cash account can have four different customs assigned to it This flexibility in detail meets most needs for financial consolidation

Trang 37

2a - 17

If the number of customs is not enough, the solution required is more likely to be Hyperion Essbase Like if a company is analyzing sales, billings, bookings, and backlog by time,

scenario, entity, product, sales rep, geography, customer, and factory/supplier, then Hyperion Essbase is the better tool as this level of detail is moving beyond financial consolidation into operational analysis

Entity

Entities represent the organizational units of the business Typically there are multiple rollups, all sharing the same base level members

DefCurrency Specifies the currency of the incoming data

AllowAdjs Whether the entity may be used in a journal Typically all base level

entities are enabled Parent entities may be enabled as well, but this functionality can be confusing to users – must use the value dimension to get to the adjusted data – and should be enabled only when required The alternative is to create a base entity below the parent, like TotCoAdjustment, and place the topside adjustments there

IsICP Enables the entity to be used as a partner for intercompany

balances The entity must be flagged to be listed in the ICP dimension Parent entities can and are usually flagged (ie, a division knows it has intercompany with Italy but not which one of the 30 cost centers under Italy); however, some undesired results can occur when using multiple rollups and the parent is not on every rollup (the data will never be matched and thus not eliminate)

SecurityClass Commonly used to restrict access to entities to only those users

who need them Generally grouped by division as opposed to having a class for each specific entity

Trang 38

2a - 18

DefaultParent Specifies which parent to drill UP to when using Web Analysis and

an entity rolls to multiple parents As Web Analysis is not used by all HFM clients, it can be more of a nuisance than useful, as a change of the entity’s parent may require this to be updated (and its commonly forgotten) When in doubt, and Web Analysis is not used, then it can always be left blank

The two basic tenets strongly apply here: no parent with just one child and no parents with identical children As mentioned earlier, the one exception may be when the currency

changes While the currency change can also be reported with the Value dimension vs a separate entity, users can have trouble with this approach and a parent here and there can be added for convenience

The maximum number of children under a parent entity varies based on the number of data records in the children Note this relates to direct children, not descendants The total number

of records of the children at the [Contribution Total] value member should be kept under 1,500,000 – this number is based upon the usage of memory on the HFM server As a

practical threshold, any parent entity with more than 200 children should be examined

Scenario

Trang 39

2a - 19

Scenarios represent types of data: actual, budget, forecast

DefaultFreq Specifies the lowest level of detail from the Period

dimension This is typically monthly

DefaultView Specifies the default view – periodic, YTD Users can

change using the point of view Typically set to YTD ZeroViewforAdj/NonAdj Specifies how to handle periods when no data has been

provided Using YTD will instruct HFM to treat no data as

an YTD date zero, meaning the periodic view will show a negative of the previous period’s YTD value Typically this

is set the same as the DefaultView

EnableDataAudit Keeps track of changes to data by user, date, dimensions

Always used for Actual, optionally used for the other scenarios “Y” enables all accounts, “O” enables only those flagged in the Account dimension

The key thing with scenarios is the frequency – how many periods This is in conjunction with the profile as described above Scenarios are best used to segregate data when all else stays the same Actual, Budget, and multiple Forecast scenarios are common

Organization by Period

For the Entity dimension there is a capability called Organization by Period Depending on the needs of the company the entity dimension can be controlled by scenario, year, and period For example members A, B, and C need to roll up to Parent X for Actual, January,

2008 but in February its only A and B that roll to the parent and C rolls to Parent Y

To accomplish this, the setting is enabled in Application Settings within metadata Next, the entity dimension is structured accordingly In the example above, C would be under BOTH Parent X and Parent Y Within the application a switch – a “system” account called Active –

is used to indicate whether the entity is active for the scenario/year/period/parent or not The DefaultValueForActive within Application Settings provides a default value for use when

a value is not provided

Trang 40

2a - 20

The Ownership Management screen within HFM can be used to modify the switch Also, the switches can be extracted, modified, and loaded in the same process as regular data Below is

an example of the screen – the Active switch is the first column and can be changed by clicking an item and choosing Yes or No from the dropdown Note the other columns relate

to consolidation methods and ownership control – these come into play during consolidation

Putting Everything Together

When loaded, the pieces all need to be there; i.e., an entity with a currency of CAD needs to have the CAD currency on the list of currencies During the initial building of the application, elements can be revisited later Security is commonly put in place toward the end of the implementation One key thing to remember is that base members cannot later become parents If a member will eventually have some children, create a parent member and add the one child now and add the other children later (a temporary exception to the rule) But if the data is at a stage where it is not loaded or can easily be reloaded then it doesn’t matter

The initial build works best when working with the text file format and reformatting a chart

of accounts, an entity hierarchy, or a list of products into the correct format Some things, such as currencies and the application settings, are easy enough to key in Also, the initial build can be split among multiple people and then the text files put together into one

When creating labels, use of consistent abbreviations is recommended; for example, “Int” might always be Interest, not Intercompany or Investment or Inventory The length of the labels should also be considered: not too short that no one knows what they are but not too long that a lot of typing and scrolling is required

Định dạng
Số trang	240
Dung lượng	6,39 MB