You are on page 1of 30

Version 1.

Hyperion Closing
Sample Documentation

Authors Amit Sharma, Rupam M.


Created Date 28 Sep 2010
Email Change
Notification List
Version 1.3

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

DOCUMENT CONTROL

Change Record

Date Name Version Change Reference


10 Jan 2009 Amit Sharma Draft Initial Draft

14 Sep 2009 Amit Sharma 0.1 Updates/additions


27 Oct 2009 Rupam M. 0..2 Updates in Appworx portion

10 Jan 2010 Rupam M 1.0 Latest updates


07 Sep 2010 AMit Sharma 1.1 Data Staging Appworx component details
th
28 Sep 2010 Amit Sharma 1.2 Latest Updates

Reviewers

Name Position

Amit Sharma Lead Trainer/Consultant BISP

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

Approvers

Name Position

Amit Sharma Lead Trainer/Consultant BISP

DOCUMENT CONTROL

I confirm that the functional specifications set out in this document are correct and may be used as part of the solution design.
Any changes to these requirements after approval will be subject to a change control process and may be rejected if timescales or costs are
impacted.

Name Signature Date

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

TABLE OF CONTENTS
1 INTRODUCTION.................................................................................................................................................................................................... 6

2 ARCHITECTURE.............................................................................................................................................................................................. 7

3 OPERATIONAL PROCEDURES...................................................................................................................................................................... 9
3.1 EXISTING SETUP.......................................................................................................................................................................................... 9
3.1.1 APPLICATION ENVIRONMENT....................................................................................................................................................................... 9
3.1.2 SOFTWARE COMPONENTS................................................................................................................................................................... 10
3.1.3 BFSCAL ESSBASE OUTLINE............................................................................................................................................................... 10
3.1.4 BFSCLS / BFSHR OUTLINE................................................................................................................................................................ 11
3.1.5 DATA LOAD / DIMENSION BUILD RULES................................................................................................................................................ 12
3.1.6 ACCOUNT DIMENSION BUILD – SEQUENCES........................................................................................................................................... 13
3.1.7 DATA EXTRACTION.............................................................................................................................................................................. 13
3.1.8 CALCULATION SCRIPTS........................................................................................................................................................................ 14
3.1.9 RECONCILIATION SHEET...................................................................................................................................................................... 18
3.1.10 AUTOMATION USING APPWORX............................................................................................................................................................ 19
3.1.11 DATA LOADING FILES FOR HYPERROLL - BFSHR.................................................................................................................................. 21
3.1.12 DATA LOADING FILES FOR CALC/TEMP CUBE – BFSCAL...................................................................................................................... 24
3.1.13 BFSHR – BFSCAL DATA FLOW.......................................................................................................................................................... 24
3.1.14 DATA TRANSFER / CUBE INTERFACES................................................................................................................................................... 24
3.1.15 BACKUP PROCESS............................................................................................................................................................................... 26
3.2 RECURRING ACTIVITIES.............................................................................................................................................................................. 27
3.2.1 APPWORX CHAINS............................................................................................................................................................................... 27
3.2.2 HIERARCHY MAINTENANCE:................................................................................................................................................................. 27
3.2.3 LOCK_SEND PROCESS........................................................................................................................................................................ 28
3.2.4 MEMBER FORMULA MAINTENANCE....................................................................................................................................................... 29
3.2.5 USER ACCESS CONTROL..................................................................................................................................................................... 29
3.2.6 INTERFACES BETWEEN CUBES.............................................................................................................................................................. 29
3.2.7 START OF A NEW PERIOD.................................................................................................................................................................... 30
3.3 APPENDIX.................................................................................................................................................................................................. 30
3.3.1 APPWORX CHAINS............................................................................................................................................................................... 30
3.3.2 BFSCLS OUTLINE.............................................................................................................................................................................. 31
3.3.3 BFSCAL OUTLINE.............................................................................................................................................................................. 31
3.3.4 INPUT ACCOUNTS TO BFSCAL............................................................................................................................................................ 32
3.3.5 OUTPUT ACCOUNTS FROM BFSCAL.................................................................................................................................................... 32
3.3.6 ACCOUNTS FORMULA FILE.................................................................................................................................................................... 32
3.3.7 SAMPLE RECONCILIATION SHEETS....................................................................................................................................................... 32
3.3.8 LOCK_SEND.TXT FILE.......................................................................................................................................................................... 33
3.3.9 FLOATINTFACTORCUST_INPUT.TXT...................................................................................................................................................... 33
3.3.10 SAMPLE FILE FOR NON FINANCIAL DATA............................................................................................................................................... 33

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

3.3.11 SOP FOR LOCK_SEND PROCESS......................................................................................................................................................... 33

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

1 INTRODUCTION

BISP Learning System(BFS) has embarked on an initiative to redesign & optimize Hyperion instances for their US
business and merge US and Europe Hyperion instance into a common model.

As part of this initiative, BFS implemented closing cube that split planning and closing models and implement Hyperroll
on closing cube to aggregate data faster.

This document shall be used as the operational guidance to maintain the Closing model. It shall also be used as a base
for further enhancements/developments in the model.

The Closing model at BFS utilises Data Staging, Appworx, Hyperion suite of products and Hyperroll from a technology
perspective. Hyperroll is used as an aggregation engine. Essbase is used for keeping outlines and querying engine.
Data Staging is used as intermediate storage for Oracle GL actual data and Appworx is used for automating the
processes.

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

2 ARCHITECTURE

The new closing model facilitates reduction in the cycle time of the closing cycle using Hyperroll which is an
Accelerated Aggregation Tool. We have HyperRoll cube where data is loaded and aggregated. We have an essbase
cube (calc cube) customised for calculation, since hyperroll cube can’t handle calc scripts. After aggregation is done in
hyperroll, data for a select set of accounts is extract from the hyperroll cube and loaded into the calc essbase cube.
Custom calculations run in this cube and data for a select set of accounts is loaded back into the hyperroll cube. Data in
hyperroll then gets aggregated one more time.

The diagram below outlines overall architecture of this model. For more information on architecture, refer design
document.

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

3 OPERATIONAL PROCEDURES

3.1 Existing Setup


Closing model application primarily has four logical divisions: Essbase, HyperRoll, Data Staging and Appworx. Details of
each component are explained in this section.

3.1.1 Application Environment

The following are the details of the application/system Set-up:

Essbase

Server – Dev Bisp-server.com


Server – QA Amit-pc.com
Server – Prod Amit-pc.com
Application Amit-pc.com
Database Amit-pcDB
Environment name Unix

HyperRoll
Server – Dev Amit-pc.com
Server – QA Amit-pc.com
Server – Prod Amit-pc.com
Application Amit-pc.com
Database Amit-pcDB
Environment name Unix

Temp Essbase Cube


Server – Dev Amit-pc.com
Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

Server – QA Amit-pc.com
Server – Prod Amit-pc.com
Application Amit-pc.com
Database Amit-pc.com
Environment name Unix

3.1.1 Software Components

The following software components comprise the solution

Product Version
Hyperion Essbase 9.3.1
Hyperroll 4.2.2
Hyperion Planning 3.5.1
Oracle 9.2
Appworx 6.1

3.1.2 BFSCAL Essbase Outline

The outline is built based on the standard hierarchy provided by BFS, with additional customized dimensions and
members as per business need. Following table gives a summary. The actual outline is added in the appendix.

Dimension Name BFS specific Dense (D) or Sparse (S) Total no. of members (no. of stored members)
Attribute (A)
1 Accounts BFS defined S 65(65)
2 Analysis BFS defined S 2 (2)
3 Years BFS defined D 14 (14)
4 Time Periods BFS defined D 60 (19)
5 Business BFS specific S 55463(21315)
6 Scenarios BFS defined D 7 (7)
7 Country BFS defined S 200(167)
Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

8 Class BFS defined A 45


9 Risk Rating BFS specific A 26
10 Capitalization BFS Specific A 5
11 ParticipationType BFS Specific A 6

3.1.3 BFSCLS / BFSHR outline


BFSHR outline is built from BFSCLS outline, and it differs from BFSCLS in terms of the dynamic calc properties of
members with member formula. This different comes in due to the inherent nature of hyperroll technology. Given below
are the details of BFSCLS outline. The actual outline is added in the appendix.

Dimension Name BFS specific Dense (D) or Sparse (S) Total no. of members (no. of stored members)
Attribute (A)
1 Accounts BFS defined S 18088(9787)
2 Analysis BFS defined S 2 (2)
3 Years BFS defined D 10 (10)
4 Time Periods BFS defined D 60 (19)
5 Business BFS specific S 55463(21315)
6 Scenarios BFS defined D 7 (7)
7 Country BFS defined S 200(167)
8 Class BFS defined A 45
9 Risk Rating BFS specific A 26
10 Capitalization BFS Specific A 5
11 ParticipationType BFS Specific A 6

3.1.4 Data Load / Dimension Build Rules

Name of the Rule Purpose Cube Name

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

1 ACCDEL Deletes all members in account dimension and adds BFSCLS


a dummy account.
2 ACFULLDY Adds all members in account dimension after BFSCLS
converting dynamic calc property to store property.
3 ACCFULL Adds all members in account dimension BFSCLS

4 ACCFRML Adds all fornula in account dimension BFSCLS

5 ACCVAR Adds _var hierarchy to account dimension BFSCLS

6 ACC_UDA Adds the uda “AC_SQL” to all accounts under BFSCLS


TotalUniqueAccount hierarchy
7 BIZFULL Adds all members of business dimension after BFSCLS / BFSCAL
removing all existing members
8 BIZATTR Adds all attributes to business dimension members BFSCLS / BFSCAL
9 BIZ_UDA Adds the uda “PC_SQL” to all businesses under BFSCLS
TotalUniqueBusiness hierarchy
10 CONTRYFL Adds all members in country dimension after deleting BFSCLS / BFSCAL
all existing members
11 CTRY_UDA Adds the uda “EN_SQL” to all BSLAs at level 0 BFSCLS

12 ALLOC Loads allocation flag to BFSCAL BFSCAL


13 FLOATINT Loads floating factor to BFSCAL BFSCAL
14 HR_Feed Loads the Data to BFSCAL, which is extracted by BFSCAL
HR_SQL file from BFSHR.
15 ACCT_BLD Used to build account hierarchy in BFSCAL – one BFSCAL
time. No longer needed

3.1.5 Account dimension build – sequences

1. ACCDEL: removes all accounts and adds one dummy account


2. ACFULLDY: removes the dummy account, converts all Dynamic calc ( & store) members to Store and adds all accounts
3. ACCFRML: adds all member formulae to appropriate accounts
4. ACCFULL: converts appropriate stored members [ originally dynamic calc ( & store) ] back to dynamic calc (& store)
5. ACCVAR: adds the _var hierarchy
6. ACC_UDA: adds the UDA “AC_SQL”
Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

3.1.6 Data Extraction

HR_Feed.rul file is used to load the data to BFSCAL(Temp Cube). The data is extracted by HRSQL script from
BFSHR Cube for some of the accounts which are input to the calc scripts in BFSCAL. Custom Calculation is
performed on the BFSCAL (Temp Cube) and the level 0 export from BFSCAL (for the calculated accounts) will be
loaded to BFSHR. The list of key accounts for which numbers are extracted from BFSHR is added in appendix.

.
3.1.7 Calculation Scripts

Following calc scripts are run in BFSCAL (calc cube) for the execution of business logic for actual scenario.

Name of the Script Purpose


1 Floatint Takes the value in account FloatIntFactorCust and copies it to the the account
FloatIntFactorBusinessCountry for each Business that shares the same BSLA intersection. This
effectively copies this factor from the dummy member NoBusiness to all businesses
2 default0 Aggregates the Account dimension.
3 Dayno1 First copy the value of AllocationFl located in the BegBalance / Years combination to all
combinations of time periods and years.

Next, if AllocationFl contains either a 1 or 0 (not #missing) then copy the value located in the
intersection of Actual / NoBusiness / NoCountry / DayNo to the account 0DayNo of all Business /
BSLA combinations.
4 Animtd If the month is January and the year is FY00 then calculate 0ANIMTD as the average of
BegBalance --> 0ENI (Considered the starting value of ENI in this Hyperion model) and the
January value of ENI. For all other years, calculate January 0ANIMTD as the average of
December ENI of the prior year and the January ENI.

For all other months, calculate 0ANIMTD as the average of the prior months ENI and the current
months ENI.
5 Aniqtd CALCULATING Q1:
If the month is January, 0ANIQTD is equal to 0ANIMTD of January * Number of Days In

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

January / Number of Days In January.

If the month is February, 0ANIQTD is equal to the sum of 0ANIMTD of February * Number of
Days in February / Number of Days in both January and February AND the sum of 0ANIMTD of
January * Number of Days in Janaury / Number of Days in both January and Februrary.

If the month is March, 0ANIQTD is equal to the sum of 0ANIMTD of March * Number of Days in
March / Number of Days in January and February and March AND the sum of 0ANIMTD of
February * Number of Days in February / Number of Days in January, Februrary and March AND
the sum of 0ANIMTD of January * Number of Days in January / Number of Days in January,
Februrary and March.

Repeat the above logic for Q2, Q3 and Q4.

Note: The number of days in a month is held in the 0DayNo dummy account.
6 Aniytd If the month is in Q1 0ANIYTD is equal to 0ANIQTD from the same month.

CALCULATING Q2:
If the month is April, 0ANIYTD is equal to the sum of 0ANIQTD of March * Number of Days In
Q1 / Number of Days January through April AND the 0ANIQTD of April * Number of Days in
April / Number of Days in January through April.

If the month is May, 0ANIYTD is equal to the sum of 0ANIQTD of March * Number of Days In
Q1 / Number of Days January through May AND the 0ANIQTD of May * Number of Days in April
and May / Number of Days in January through May.

If the month is June, 0ANIYTD is equal to the sum of 0ANIQTD of March * Number of Days In Q1
/ Number of Days January through June AND the 0ANIQTD of June * Number of Days in April
through June / Number of Days in January through June.

Repeat the above logic for Q3 and Q4 making sure to include Q1 and Q2 sums in the Q3
calculating AND Q1-Q3 sums in the Q4 calculation.

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

Note: The number of days in a month is held in the 0DayNo dummy account
7 RecvbleZ Clear all data from these intersections
8 Adjcash Aggregate the Business dimension for these intersections only
9 Adjeni 1. Set 0ADJENI to zero (0)
2. Sum the members "ENI", "0ADJCASH" and "0ADJRECVBLEPROV" and place the value in
0ADJEN.
10 adjanimt Copy all data from ENI to 0ADJANIMTD
11 adjaniqt Copy all data from ENI to 0ADJANIQTD
12 Adjaniyt b) Copy all data from ENI to 0ADJANIYTD
b)If the month is in Q1 0ADJANIYTD is equal to 0ADJANIQTD from the same month.

CALCULATING Q2:
If the month is April, 0ADJANIYTD is equal to the sum of 0ADJANIQTD of March * Number of
Days In Q1 / Number of Days January through April AND the 0ADJANIQTD of April * Number of
Days in April / Number of Days in January through April.

If the month is May, 0ADJANIYTD is equal to the sum of 0ADJANIQTD of March * Number of
Days In Q1 / Number of Days January through May AND the 0ADJANIQTD of May * Number of
Days in April and May / Number of Days in January through May.

If the month is June, 0ADJANIYTD is equal to the sum of 0ADJANIQTD of March * Number of
Days In Q1 / Number of Days January through June AND the 0ADJANIQTD of June * Number of
Days in April through June / Number of Days in January through June.

Repeat the above logic for Q3 and Q4 making sure to include Q1 and Q2 sums in the Q3
calculating AND Q1-Q3 sums in the Q4 calculation.

Note: The number of days in a month is held in the 0DayNo dummy account
13 Intallo1 First clear all upper level blocks for this intersection and then aggregate the business dimension.

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

14 aggpsdiv a) Clear all upper level blocks for this intersection


b) Aggregate the Business and Country dimensions for this intersection
15 Intalof1 If the account AllocationFl is equal to either 1 or 0 then set "0INTERESTALLOCOFFSET"
equal to the sum of all members in the 3rd generation of the Business dimension that
intersect "FloatInterestExpense" minus the sum of all members in the 3rd generation of the
Business dimension that intersect "0INTERESTALLOCATION" minus the sum of all
members in the 3rd generation of the Business dimension that intersect "PSDividend" minus
the sum of all the members in the 3rd generation of the Business dimension that intersect
""PSDividendNoTax".
16 custebt This calculates the new value for custEBT after 0interestallocation is calculated.
17 Custtax1 First aggregate the account dimension for these intersections.

If Allocation is equal to 1 then set 0CustTax AND 0ADJCustTax equal to the difference of
CustEBT, BookGains and PSDividendNoTax multiplied by TaxRate (located at intersection
with NoBusiness) multiplied by -1.

If AllocationFl is equal to 0 then set 0CustTax AND 0ADJCustTax equal to TotTaxes.

18 Bslaoff 1. Set GFR51HQ00OFF equal to the value in OFF51HQ00000


2. Set GFR51HQ000HQ equal to the inverse value in OFF51HQ00000
19 Dualrpt3 Clear all upper level blocks in this intersection

3.1.8 Reconciliation Sheet

Reconciliation is done at two levels, At first level data is reconciled at the GL and BFSHR to check data consistancy
between them. In the second level data consistency checked between the BFSHR (Souce Database) and BFSCAL
(Target Database). The second level checking is required if there is a need to troubleshoot/analyse any mismatch
coming up during first level reconciliation. HA can decide to use the existing reconciliation sheet or can create a new
one for the purpose.
One common scenario of referring to the second level check is the situation when data matches for GL accounts by
segments, accounts or country, but doesn’t match for calculated accounts or any account that depends on calculated
accounts. A few sample recon sheets are attached in the appendix.
Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

3.1.9 Automation using Appworx

Appworx is the job scheduler, which we are using to automate the complete closing end to end chain. Appworx simply
picks up the chain and its respective modules and runs them in the predefined order as desired. The respective chains
which initiate the data and metadata flow across different environments and servers are as explained below:
1.9.1 Staging
 HYP_BFS_DS_CLOSING_WTW_C : This chain should do all the activities to be taken into staging
environment for providing output feeds described in output design section of staging.

Attached document Provide in detail all modules , chains , prompts , default values , input /output file
locations , database programs , UNIX shell scripts called by appworx components.

CFSCLS-STG-APPWO
RX-MODULES-CHAINS.xls

1.9.2 Hyperroll

 HYP_BFS_HRL_HRPP_C – This chain is responsible for all the activities to be taken into hyperroll. This
chain has certain modules which clear already existing hyperroll logs, killing all user requests made on the
hyperroll box while chain is running , logging out already existing users , unlocking the outline , extracting
metadata for hyperroll , aggregating data for hyperroll in the hyperroll box , getting in sync the outline of
both the Essbase and hyperroll ( BFSCLS and BFSCHR) , running the wait command for both foreground
and background works could finish and mailing out team the desired result .

Main modules in Hyperroll chain are:

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

 HYP_BFS_REFRESH_HRL_M: Hyperroll refresh module to extract metadata from Essbase.

 HYP_BFS_BUILD_HRL_M: Hyperroll build module to build closing cube. This involves running of Hyperroll
calculation tool that aggregates the Essbase data.

 HYP_BFS_ATTACH_HRL_M: Hyperroll attach module to attach Essbase outline to Hyperroll cube.

1.9.3 BFSCAL Cube

Main chains in Temp Essbase Cube is HYP_BFS_BFSCLS_CALC_LOAD_C: Builds metadata, extracts and
loads numbers, does the calculation, takes level 0 export and FTPs the export to hyperroll server. It has some
chains and modules under it.
1.9.4 Chain Timings Baseline

Following is the list of all the modules and chains added in HYP_BFS_CLS_WTW_C main chain. Second column
shows the total time each chain takes to run.

CHAIN/MODULE NAME TOTAL TIME TO RUN


HYP_BFS_WTW_WAITFOFILES_M 00.00.00
HYP_BFS_DS_CLOSING_WTW_C 0:16:02
HYP_BFS_FTP_LOCKSEND_TO_HPRL_M 0:00:00
HYP_BFS_BFSCLS_METADATA_LOAD_C 0:05:27
HYP_BFS_CLS_HRL_HRPP_C 0:18:57
HYP_BFS_BFSCLS_CALC_LOAD_C 2:43:58
HYP_BFS_CLS_HRL_HRPP_C 0:19:25
HYP_BFS_WTL_END_CYCLE_M 0:00:00
HYP_BFS_WTL_ASTERISKS_M 0:00:00

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

HYP_BFS_CLS_FDM_SQL_C 0:01:00
HYP_BFS_DS_FDM_PROCESS_C 0:00:04

1.9.5 Two Times Chain:

Chain Name: HYP_BFS_CLS_WTW_2TIMES_C (Normally used during quarter close)

Following two chains are added under the main Two Times chain as components

 HYP_BFS_CLS_WTW_C : The main wing to wing chain


 HYP_BFS_CLS_CYCLE2_C : The second chain which has similar components as main chain

3.1.10 Data Loading files for Hyperroll - BFSHR

All the data files which are loaded in Hyperroll cube i.e. BFSHR, are placed under data folder on Hyperroll server (Path:
ap00/BFS/BFS_hr/data. Following is the list and descriptions of files

 Lock_Send.txt – This is used by the HAs to load interest rates, non financial data to the hyperroll cube.
 BFSCALexport.txt- This file is a level zero export from BFSCAL cube (After calculations are performed) to load in
Hyperroll, This level zero export is taken in columnar format. Modules are added in main wing to wing chain
under HYP_BFS_BFSCLS_CALC_LOAD_C chain to do level zero export from BFSCAL after all calculations are
performed and FTP it to Hyperroll server.
 BFScls_actuals_FY05.txt – GL data for FY05 Dec
 BFScls_actuals_FY06.txt – GL data for FY06
 BFScls_actuals_FY07.txt – GL data for FY07 till current month
 PlnToCls.txt – Extract from planning cube. Will be available when PLN to CLS chain is run.
 PlnToCls_n.txt – Similar to above and may or may not be present. n can be 1 or 2 and it depends on the size of
the level 0 export of Planning cube.
 OP07.txt – Budget 2007 data
 BFScls_SI_2007.txt – S1 2007 data
 SM07Rev.txt – SRO May 2007 data
 Fix.txt – Contains the patches that were applied to BFSCLS/BFSCAL applications

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

 L0nonCDRPLAN.txt – plan data for non-CDR account obtained through a level 0 export of Fin2BFS
 BFScls_actuals_NONCDR_FY05.txt – actual 05 data for non-CDR obtained through a level 0 export of Fin2BFS

Given below is a screenshot of the files described above.

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

3.1.11 Data Loading files for Calc/Temp Cube – BFSCAL

Following files are loaded into BFSCAL outline.

 BFStemp.txt – extract from BFSHR containing values of input accounts to be used in custom calculation. No
manual intervention necessary.
 allocation.txt – allocation flags. No manual intervention necessary for loading.
 FloatIntFactorCust_Input.txt – This one contains floating interest factor and its loading is automated. It is to be
maintained by the HAs similar to the Lock_Send file in BFSHR.

All these above files are in the path: /ap02/BFS/hyperion/BFSfiles/cls.

3.1.12 BFSHR – BFSCAL data flow

Numbers corresponding to a set of identified accounts are extracted from BFSHR and loaded into BFSCAL. Custom
calculations run on those data set. Then a level 0 export is taken from BFSCAL for loading into BFSHR. The purpose of
taking the level 0 export is to capture a set of calculated accounts and send those values to BFSHR. (Report script
option was not used due to the high extraction time). The lists of input and output accounts pertaining to BFSCAL are
attached in appendix.

3.1.13 Data transfer / Cube Interfaces


There are three Appworx chains for Plan to Close, Close to Plan and Close to Consolidation data transfer. Given below
are the details.

HYP_BFS_CLS_TO_CON_C: Chain to load data from Closing to Consolidation cube. This chain extracts data from
BFSHR (Hyperroll cube BFSCLS) using sql script and loads it into con cube.
Sql script was developed using the “totclose” report script and data is loaded by using L_GLAcCM load rule.
It includes following modules
 HYP_BFS_CLS_CON_CREATE_SQL_M: Module to create sql script in Hyperroll.
 HYP_BFS_CLS_TO_CON_SQL_M: This module runs the sql script to generate the output file.
 HYP_BFS_FTP_TO_CON_M: Module to ftp file from Hyperroll server to Essbase server.
 HYP_BFS_CON_HRDATA_LOAD_M: Module to load the Hyperroll extract to Consolidation cube using the load
rule “L_GLAcCM”.

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

HYP_BFS_CLS_TO_PLN_C: To load data from Closing to Planning cube.


This chain extracts data from BFSHR (Hyperroll cube BFSCLS) using sql script and loads it into planning cube.
Sql script was developed using the “totclose” report script and data is loaded by using HPDATALD load rule.
HPDATALD load rule is created.
It includes following modules
 HYP_BFS_CLS_PLN_CREATE_SQL_M: Module to create sql script in Hyperroll.
 HYP_BFS_CLS_TO_PLN_SQL_M: This module runs the sql script to generate the output file.
 HYP_BFS_FTP_TO_PLN_M: Module to ftp file from Hyperroll server to Essbase server.
 HYP_BFS_PLN_HRDATA_LOAD_M: Module load the Hyperroll extract to Planning cube using the load rule
“HPDATALD”

HYP_BFS_PLN_TO_CLS_C: To load data from Planning cube to Closing cube.


This chain extract data from Fin2BFS cube using level 0 export method and filtering data for the specific plan scenario
only. It then ftps the file to hyperroll server. The specific plan scenario has to be updated in appworx before the start of
the plan scenario.

After the data ftped to hyperroll server, hyperroll aggregation process runs to get the data to the upper levels.

The chain includes the following modules


 HYP_PLNTOCLS_START_EMAIL_M – Intimates Start of the chain
 HYP_BFS_FIN2BFS_L0_EXPORT_M – Takes level 0 export from Planning cube
 HYP_BFS_PLAN_FILTERSH_M – Keeps the selected plan scenario and filters out all other records. Appropriate
planning scenario is to be entered in the prompt. ( e.g., '"SII"')
 HYP_BFS_PLAN_FILTERSH1_M – Similar to above. Is present to filter if multiple level 0 files are present, since
one module can filter only one file. If there is only one level 0 export file, this module is to be de-activated
 HYP_BFS_PLAN_FILTERSH2_M – Similar to above. If there is only one or two level 0 export file, this module is
to be de-activated
 HYP_BFS_FTP_TO_HRL_M - Module to ftp the extract from Essbase server to Hyperroll server
 HYP_BFS_FTP_TO_HRL1_M - Similar to the above
 HYP_BFS_FTP_TO_HRL2_M – Similar to the above
 HYP_BFS_CLS_HRL_HRPP_C – Hyperroll processing to load/aggregate the PLN extract into CLS cube
 HYP_PLNTOCLS_END_EMAIL_M – Intimates chain completion

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

3.1.14 Backup process

The new application is covered under the back up plan / DR plan of hyperion CoE.

In addition, there is a backup cube that contains 1 day old data compared to BFSHR cube. It is similar in functionality as
the existing Moveapps process. Before every nightly cycle, the data/metadata files (BFSHR outline and all data files
used in BFSHR load/aggregation process) related to hyperroll main application are copied over to a back up application
(bkBFShr). Then hyperroll process runs on it which results in the backup application BKBFSHR. In case BFSHR
database is not available, users can use BKBFSHR for analysing the number.

The chain HYP_BFS_CLS_TO_BKBFSCLS_HRL_C executes the above backup process. It first copies all files in main
Hyperroll folder (BFSCLS application) to backup Hyperroll folder (BKBFSCLS application). It also copies the BFSCLS
outline. Then it runs the Hyperroll aggregation process in the backup Hyperroll setup. This ensures that the
BFSCLS/BFSHR outline and data are backed up.

The cube BFSHR is designed to handle 4 years of actual data and 2 years of plan data. When the data in the cube
becomes more than 4 years old and it impacts the performance, the earliest year’s data needs to be achieved.
Achieving process will be similar to the existing achieving process, with the exception that data from BFSHR will need to
be achieved in an essbase cube.

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

3.2 Recurring Activities

3.2.1 Appworx Chains

Appworx is used to automate the complete closing end to end chain. Respective nightly chains which initiate the data
and metadata flow across different environments and servers. Salient points are:

1. The wing-to-wing chain (HYP_BFS_CLS_WTW_C) takes care of the complete process and is automated.

2. HAs will need to ensure that the chain is run and then they need to reconcile the data and release the cube to the
business users.

3. During quarter close, instead of HYP_BFS_CLS_WTW_C chain, HAs need to run


HYP_BFS_CLS_WTW_2TIMES_C chain.

4. During planning sessions, they have to run HYP_BFS_CLS_TO_PLN_C and HYP_BFS_PLN_TO_CLS_C


chains so as to ensure availability of actual number in plan cube and vice versa.

5. On every quarter or month, HA’s need to run the chain HYP_BFS_CLS_TO_CON_C to ensure that numbers
move from close to consolidation cube.

3.2.2 Hierarchy Maintenance:

All manual meta data changes should be done to BFSCLS / BFSCAL hierarchy and it will automatically reflect to
BFSHR hierarchy when next time chain runs. Metadata changes for Business/Account/Country are automated for
BFSCLS using appworx chains. Similarly, Business/Country are automated for BFSCAL using appworx.

3.2.3 Lock_Send Process

As we cannot Lock and send to hyperroll, all values that are required to be locked and sent to closing cube should be
captured in a file in the following format.
Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

FY07|Actual|BU Version_1|FloatIntFactorCust|NoBusiness|FACC58|0|0.059424966|0.056703369|0.050035366|
0.056598837|0.056604366|0.059011762|0.059011762|0.059011762|0.059011762|0.059011762|0.059011762|
0.059011762
FY07|Actual|BU Version_1|FloatIntFactorCust|NoBusiness|FACPAR|0|0.059424966|0.056703369|0.050035366|
0.056598837|0.056604366|0.059011762|0.059011762|0.059011762|0.059011762|0.059011762|0.059011762|
0.059011762
FY07|Actual|BU Version_1|FloatIntFactorCust|NoBusiness|C5XVE1|0|0.059424966|0.056703369|0.050035366|
0.056598837|0.056604366|0.059011762|0.059011762|0.059011762|0.059011762|0.059011762|0.059011762|
0.059011762
FY07|Actual|BU Version_1|FloatIntFactorCust|NoBusiness|C5XDEM|0|0.044033645|0.040189983|0.037007225|
0.042141818|0.042927011|0.033655815|0.033655815|0.033655815|0.033655815|0.033655815|0.033655815|
0.033655815
FY07|Actual|BU Version_1|FloatIntFactorCust|NoBusiness|C5XFRN|0|0.059424966|0.056703369|0.050035366|
0.056598837|0.056604366|0.059011762|0.059011762|0.059011762|0.059011762|0.059011762|0.059011762|
0.059011762

Time period above covers all periods starting from BegBalance to December. This file should be kept under the
following directory

 Directory Name: - /ap02/BFS/hyperion/BFSfiles/cls


 File Name: - Lock_Send.txt

Module HYP_BFS_FTP_LOCKSEND_TO_HPRL_M, added in the main wing to wing chain, will FTP this file from the
above directory to the Hyperroll server data folder (Path ap00/BFS/BFS_hr/data).

The Lock_Send.txt file currently used is attached in appendix. It has different type of data sets like interest rate, non-
financial data etc. The excel file that will be used by HA for collecting NFD is also attached in appendix. SOP for
lock_send process is also in the appendix.

3.2.4 Member Formula Maintenance

All existing member formulae are added automatically in the metadata build during the nightly process. If there is a need
to add/delete/modify the formulae, the file BFScls_accounts_frm.txt needs to be updated with the proper changes. This
file is available in the /ap02/BFS/hyperion/BFSfiles/cls.

3.2.5 User Access Control

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

We need to give access to all existing users to BFSHR cube of BFSCLS application. The new access control
mechanism will be the same as the existing one. Users will need to have access to BFSHR and BKBFSHR. BKBFSHR
is the backup of BFSHR with 1 day old data and is a different application/database (BKBFSHR/BKBFSHR).

3.2.6 Interfaces between cubes

There are three interfaces for data transfer between cubes. Substitution variables/Appworx prompts are created to take
care of current month, scenario, plan/actual years, as applicable.

 Close to Consolidation chain has to run every month (or on demand) to transfer last month’s data from closing
cube to consolidation cube. After that the existing load rules and calc scripts do the rest in consolidation cube. To
run this chain for a particular month and year, specific month and year are to be passed on in the appworx
prompts in the chain HYP_BFS_CLS_TO_CON_C.

 Plan to Close chain runs after every planning session (or on demand) to transfer plan numbers for that session
from planning cube to closing cube. Based on the planning session, the scenario in the level 0 export module in
appworx is to be changed. To run this chain for a particular planning scenario, specific plan scenario is to be
passed on in the appworx prompts in the chain HYP_BFS_PLN_TO_CLS_C. Filter module
HYP_BFS_PLAN_FILTERSH1_M is used when level 0 export generates two files. Filter module
HYP_BFS_PLAN_FILTERSH2_M is used when level 0 export generates three files. These two modules are
currently deactivated in appworx chain, since one level 0 export file is being created. Corresponding ftp modules
HYP_BFS_FTP_TO_HRL1_M & HYP_BFS_FTP_TO_HRL1_M are also deactivated currently.

 Close to Plan chain runs before every planning session (or on demand) to transfer appropriate actual data from
closing to planning cube. Currently it takes care of one month of actual data. At a later point of time, if there is
need to transfer more than one months of actual, appropriate changes are to be done in the appworx module and
HRSQL script.

3.2.7 Start of a New Period


Following steps are to be completed in when closing processing is needed for a new month.

1. Change the Month / Year in the chain HYP_BFS_CLS_WTW_C. For example, to start the closing cycle for
August 07, enter AUG and 07 in the prompts of the main chain HYP_BFS_CLS_WTW_C.

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

2. Add the month and Year (for example August, FY07) in the calc script recvbleZ in BFSCAL cube so that this
script also calculates data for the new period

3.2.8 Maintaining the moveapps process


Currently the appworx chain for moveapps/backup (HYP_BFS_CLS_TO_BKBFSCLS_HRL_C) copies all data files
being loaded into BFSCLS/BFSHR to BKBFSCLS/BFSHR and also the BFSCLS outline. Individual modules do this
copying activity. Go forward, whenever a new data file (say for example – the actual file for FY08) is added to the main
Hyperroll cube, a new module is to be added to appworx chain so that the new data file can be copied over to the
backup application for processing.

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

3.3 Appendix

3.3.1 Appworx Chains

BFS Wing-To-Wing Cycle: HYP_BFS_CLS_WTW_C

Main chains/modules in WTW chain (HYP_BFS_CLS_WTW_C)

 HYP_BFS_DS_CLOSING_WTW_C: Data Staging data/metadata chain


 HYP_BFS_BFSCLS_METADATA_LOAD_C: Chain to update metadata
 HYP_BFS_CLS_HRL_HRPP_C: Hyperroll process to aggregate data
 HYP_BFS_BFSCLS_CALC_LOAD_C: Chain to load and calculate data in BFSCAL cube
 HYP_BFS_CLS_FDM_SQL_C: FDM chain to extract data for FDM from Hyperroll cube
 HYP_BFS_DS_FDM_PROCESS_C: Data Staging FDM chain to process data for FDM

BFS WTW 2 Times Chain: HYP_BFS_CLS_WTW_2TIMES_C

This chain has 2 components:

1. HYP_BFS_CLS_WTW_C
2. HYP_BFS_CLS_CYCLE2_C – This chain is similar to HYP_BFS_CLS_WTW_C but excludes FDM chains.

Interface Chains

HYP_BFS_CLS_TO_PLN_C: This chain extracts data from closing cube and loads the same in planning cube.
HYP_BFS_CLS_TO_CON_C: This chain extracts data from closing cube and loads the same in consolidation cube.
HYP_BFS_PLN_TO_CLS_C: This chain extracts data from planning cube to load the same in closing cube.

D:\Satya\
CFSredesign\Test\Appworx chain_screenshots.doc

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

3.3.2 BFSCLS Outline

D:\Documents and
Settings\326002169.326002169L\Desktop\CFSCLS.ZIP

3.3.3 BFSCAL Outline

D:\Documents and
Settings\326002169.326002169L\Desktop\CFSCAL.ZIP

3.3.4 Input Accounts to BFSCAL

D:\Documents and
Settings\326002169.326002169L\Desktop\InputAccountsCFSCAL.txt

3.3.5 Output Accounts from BFSCAL

D:\Documents and
Settings\326002169.326002169L\Desktop\OutputAccountsCFSCAL.txt

3.3.6 Accounts formula file

D:\
cfscls_accounts_frm.txt

3.3.7 Sample Reconciliation Sheets

Learnhyperion.wordpress.com aloo_a2@yahoo.com
Version 1.2

D:\Satya\
CFSredesign\Test\DataValidation Test\0729\SampleRecon.ZIP

3.3.8 Lock_Send.txt file

D:\Satya\
CFSredesign\Deploy\Lock_Send.ZIP

3.3.9 FloatIntFactorCust_Input.txt

D:\
FloatIntFactorCust_Input.txt

3.3.10 Sample file for Non Financial Data

D:\Satya\
CFSredesign\Deploy\CL_NFD.xls

3.3.11 SOP for Lock_Send process

D:\Documents and
Settings\326002169.326002169L\Desktop\Lock_Send_SOP.ZIP

*****

Learnhyperion.wordpress.com aloo_a2@yahoo.com

You might also like