Hyperion 11.1.1.3 Rules Student Guide

http://learnhyperion.wordpress.
com
Hyperion 11.1.1.3 Rules

Student Guide
Provided By: BISP Created By: Rupam Majumdar

http://bispsolutions.wordpress.com SME - Hyperion
bisp.consulting@gmail.com Reviewed By: Amit Sharma
http://learnhyperion.wordpress.com BISP Team
Hyperion Rules Student Guide || BISP || Amit Sharma || Created by : Rupam Majumdar Page 1
http://learnhyperion.wordpress.com
About VB Script Variables
Variables are placeholders that temporarily store values when the rules script
is being executed. You can change the value of variables as many times as
needed during execution.
Variables simplify your script by letting you give short, descriptive names to
data used in your rules. For example, pov_entity instead of HS.Entity.Member
Variables improve performance because you can retrieve application data

once and then reuse the data throughout a procedure. For example, you could
retrieve the year total for the Sales account from your Financial Management
application and store it in a variable.
You can then use the variable in a series of calculations in your procedure,
instead of retrieving the value from the application each time.
Variables temporarily store values when your script is running.

Variables simplify rules scripts.
Variables improve rules performance.
Creating Variables and Assigning Values
You can create variables explicitly using one or more Dim statements at the
start of a subroutine. This method, called declaring the variables, enables you
to look in a single place in a procedure when you want to reuse variables and
need to remember their names.
You can also create variables on the fly. However, they are scattered
throughout the procedure. This method makes it difficult to check variable
names when you want to reuse them.
Dim Statement Syntax:
Dim VariableName
For example,
Dim vAcc1
Variable name guidelines:
• Must begin with an alphabetic character
• Cannot contain an embedded period
• Must not exceed 255 characters
• Must be unique in the scope in which it is declared
You can create multiple variables with a single Dim statement by separating
the variable names with commas.
Example
Dim vAcc1, vAcc2, vAcc3
You assign values to variables using an equal sign (=), with the variable name
on the left and the value you want to assign the variable on the right. You can
assign literal text strings, numeric values, return values of functions, or return
values of expressions. If the variable does not exist, it is created on the fly. To
assign a literal string value, you enclose the string in quotation marks. You do
not need quotation marks to assign numeric values, function results, or
expression results.
Declare variables explicitly using Dim statements

Create variables on the fly
Enclose values in quotation marks to enter a literal text string
You can concatenate variables with literal text strings
Variables and Data Types

In VBScript, you cannot specify in advance that a variable holds only a
particular data type. Instead, you must use a variable known as a variant to
store any data type.
When you assign a value to the variable, VBScript automatically assigns the
data type. Sometimes you may need to override the default data type. For
example, you may need to store all values as integers.
You can use conversion functions to explicitly set the data type:
This example converts the result of the calculation to an integer and stores it
in the variable vGM_Pct
Variables and Constants
Variables can be used only in the Sub procedure in which they are created.
Constants are similar to variables, but with these differences:
• You can use constants in all Sub procedures within the script.
• After you define a constant (that is, after it has been assigned a value), you
cannot change it. You can declare constants anywhere in the script file. If
constants are declared at the beginning of the file, outside of any procedure,
they are available to all procedures at all times. If constants are declared
within a procedure, they are available only for that procedure.
You can use constants to store application information that you use frequently
but that does not change. For example, you can create constants to store
member names that are used frequently within account expressions. By using
a short constant name in place of a long string of member names, you reduce
the likelihood of errors. In Financial Management rules, you typically use
constants to store information that does not vary with the Point of View
settings for which the rules are run.
Unlike variables, you must explicitly declare constants. They cannot be
created on the fly.
Syntax
const Name=Value
where Name is the name of the constant and Value is the value of the constant.
The rules for naming constants are the same as for variables. This example
creates a constant named AVE and assigns it a string as a value:
You declare constants at the beginning of rules files.
They are available to all procedures at all times.
After you assign a value to a constant, you cannot change it.
You can use constants anywhere in your code in place of actual values,
just as you use variables.
Syntax
const Name=Value
where Name is the name of the constant and Value is the value of the constant.
The rules for naming constants are the same as for variables. This example
creates a constant named AVE and assigns it a string as a value:
Example
Creating Header Sections for Variables and Constants
It is a useful practice to create a standard header section in your Sub

procedures with variables for frequently used information for your
application. For application information
that does not changed based on the Point of View, you can create a constants
header section at the beginning of the rules file.
These are some common types of information to include in a header section:
• Current Point of View members for page dimensions
• Top and None members for custom and ICP dimensions
• Global account members
• Conditional statement triggers
These are some typical types of information stored in header section

variables:
The current POV members for the POV dimensions
Top and [None] members for custom and ICP dimensions;

global Accounts
Triggers for conditional statements
Point of View Variables

Information about the current Point of View members for the Entity, Scenario,
Year, and Value dimensions is typically used throughout a Sub procedure.
Instead of repeatedly retrieving this information from the application, you can
retrieve it once at the beginning of the procedure and store it in a variable.
You can then use the value stored in the variable when a rule requires Point of
View information.
You retrieve the Point of View using the Member function. For example,
HS.Entity.Member retrieves the current Entity POV member. Because the
values change based on the current Point of View, you should use variables
rather than constants.
TIP
For the variable for the current period, you can use HS.Period.Number instead
of HS.Period.Member. Because the fiscal year can start on different months in
different applications, if you use period numbers rather than member names,
it is easier to reuse your rules in more than one application.
Top and None Members for Custom and ICP Dimensions

Custom and ICP dimensions in account expressions often need to be set to the
top member or the [None] member. This can result in a long expression that is
difficult both to type and to read.
Example
To simplify your code, you can store the text string for custom and ICP
members in a variable or constant, as in this example
You can then use the constant or variable in the account expression in place of
the string:
Because the custom and top member names do not change when the Point of
View changes, you can use constants instead of variables.
Global Accounts
You frequently need to refer to global accounts in your rules, such as the
accounts used to store exchange rates or head count. You can create variables
or constants for these accounts and then use them throughout your file. For
example:
Because the global member names do not change when the Point of View
changes, you can use constants instead of variables.
Conditional Statement Triggers

Financial Management provides a number of functions that return a value of
true or false. You can use these functions as tests in conditional statements.
For example, before executing a rule, you might test whether it is true or false
that the current year is the first year in the application or that the current
entity is a base entity.
To make your rules file more efficient, you can perform the test once and store
the result in a variable in your header section. For example:
You can then use the variable as needed in conditional statements. Because
they are Boolean values, a value of True is assumed as the test.
You can use the Not keyword to test for a false condition. This statement
executes only if the entity is not a base member:
For clarity in your code, you can specify True or False as the condition:
Because the results returned by these functions can change based on the Point
of View, you must use variables rather than constants.
Dynamic Account Types

Dynamic accounts are accounts whose values are dynamically calculated
when the data is requested. Ratios and percentages are the most common
type of dynamic calculations. Only base accounts can be dynamic.
Dynamic accounts ignore the following account attributes:
ISConsolidated
EnableCustom1...4Aggr
ISCalculated
UsesLineItems
The IsConsolidated and EnableEnableCustom1...4Aggr attributes do not apply

to dynamic accounts because dynamic accounts are recalculated at the parent
level; they are not aggregated.
The IsCalculated and UseLineItems attributes do not apply because data for
dynamic accounts is calculated, not stored.
Accounts that use the Dynamic account type have this behavior:
Values are not stored; they are calculated as the data is requested.
Parent totals for accounts, custom dimensions, and time periods are
calculated dynamically, they are not aggregated from children.
Period-to-date views calculate correctly.
Sub Dynamic Procedures

You use Sub Dynamic procedures to create rules for dynamic accounts.
Syntax
Sub ProcedureName()
‘Type your Dynamic rule here
End Sub
Example
This example uses the account GM_PCT to store the results of the formula for
GM divided by Sales and then multiplied by 100:
Creating Rules for Dynamic Accounts
You use the HS.Dynamic function to create rules for dynamic accounts.
You can use HS.Dynamic only in Sub Dynamic procedures.
HS.Dynamic is executed for the current Point of View for Entity,
Scenario, and Year.
You cannot use conditional statements with dynamic rules.
Dynamic account values are calculated on the fly as data is requested from
Sub Dynamic procedures. You use the HS.Dynamic function within the
procedures to create rules for dynamic accounts.
Syntax
HS.Dynamic "DestPOV = Expression"
Guidelines:
• The right side of the equation (source) cannot reference the Scenario, Year,
or Entity dimensions.
• Only dynamic accounts and View dimension members are valid on the left
side of the equation (destination).
• You cannot use dynamic accounts as the source.
• If you do not specify the View dimension as the destination, the calculation is
executed for all views. If you specify the View dimension, the calculation is
executed only for the specified view.
• You cannot use conditional statements within Sub Dynamic procedures.
• Statements in Sub Dynamic procedures are executed sequentially.
The HS.Dynamic function can reference data only in the current subcube. If
you want to reference data from a different subcube, you may need to create a
"parking" account to store information from the other cube. For example, to
reference a prior year's data in the formula, create a memorandum account to
store last year's data in the current year’s subcube and reference the
memorandum account in the dynamic calculation.
The table lists the expected results for the GMPercent account, assuming the
Product custom member is the parent of P1, P2 and P3. Notice that Product
custom member is calculated by the formula; it is not aggregated from its
children.
You can include the View dimension on the left side of the equal sign as the
destination to limit the calculation to a specific view. In this example, the
GMPercent calculation is executed only if you set the Point of View to periodic.
Creating Custom Sub Procedures
In addition to using the eight predefined Financial Management Sub

procedures, you can define custom Sub procedures. You can execute, or call,
custom procedures from within the predefined Financial Management
procedures or from another custom procedure.
Custom Sub procedures ease organization and maintenance of rules files.
Instead of working with a single procedure that may contain hundreds of lines
of script for different tasks, you can create multiple Sub procedures, each of
which performs a single task.
When you define a custom Sub procedure, you can specify one or more
variables to receive values passed from the calling procedure.
Custom procedures provide these benefits:

They make rules files easier to read.
They simplify troubleshooting by separating script into logical units.
They allow rules to be reused by multiple calling procedures.
Syntax
Sub ProcedureName (Var1,Var2,Var3,...)
...
...
End Sub
Arguments
ProcedureName The name of the procedure
(Var1,Var2, Var3,...) :A list of variable names to receive values passed from
the calling procedure.
Calling Custom Sub Procedures

To call a Sub procedure, you use the call keyword followed by the Sub
procedure name and parentheses, with values to be passed, if any, within the
parentheses. Alternatively, you can omit the call keyword and simply use the
Sub procedure name.
Creating Custom Function Procedures

Function procedures perform an operation and return the result of the
operation to the calling procedure. As with Sub procedures, the calling
procedure can pass values to the Function procedure. For example, the calling
procedure might pass two text strings to the Function procedure. The
Function procedure might then concatenate the two text strings and pass the
concatenated string back to the calling procedure as a return value.
Function
Function FunctionName (Var1,Var2, VarN,...)
...
FunctionName=ReturnValue
...
End Function
Arguments
FunctionName
The name of the Function procedure Var1,Var2, VarN
A list of variable names that receive values passed from the calling procedure
ReturnValue
The return value for the function (a literal value or an expression that returns
a value.)
Calling Custom Function Procedures

To call a function, place the function name at the location in the script where
you want to insert the return value. When passing values to the variables, use
the same syntax as for Sub procedures.

Hyperion 11.1.1.3 Rules Student Guide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hyperion 11.1.1.3 Rules Student Guide

Uploaded by

Copyright:

Available Formats

http://learnhyperion.wordpress.

Hyperion 11.1.1.3 Rules

Provided By: BISP Created By: Rupam Majumdar

About VB Script Variables

Variables improve performance because you can retrieve application data

Variables temporarily store values when your script is running.

Creating Variables and Assigning Values

Dim Statement Syntax:

Variable name guidelines:

• Must begin with an alphabetic character

• Cannot contain an embedded period

• Must not exceed 255 characters

• Must be unique in the scope in which it is declared

Declare variables explicitly using Dim statements

You can concatenate variables with literal text strings

Variables and Data Types

Variables and Constants

Creating Header Sections for Variables and Constants

It is a useful practice to create a standard header section in your Sub

These are some typical types of information stored in header section

The current POV members for the POV dimensions

Top and [None] members for custom and ICP dimensions;

Triggers for conditional statements

Point of View Variables

Top and None Members for Custom and ICP Dimensions

Conditional Statement Triggers

Dynamic Account Types

The IsConsolidated and EnableEnableCustom1...4Aggr attributes do not apply

Sub Dynamic Procedures

Creating Rules for Dynamic Accounts

Creating Custom Sub Procedures

In addition to using the eight predefined Financial Management Sub

Custom procedures provide these benefits:

Calling Custom Sub Procedures

Creating Custom Function Procedures

Calling Custom Function Procedures

You might also like