Based on the following design:
Plan type 1: Summary Plan type with all Accounts by Entity
Plan type 2: Sales Plan type with Sales by Product by Entity
Plan type 3: Salary Plan type with Salary Expense by Employee by EntityYou need to get Sales data to the Summary plan type. Identify the two true statements about sharing revenue
data between the sales plan type and the summary plan type.
A.
Planning will build in @XREF calculations in a calc script by default to share data between plan types.
B.
A replicated partition could be created to replicate data from the sales plan type to the summary plan type
and this would be done if we wanted to store the sales data in the summary plan type.
C.
A transparent partition and @XREF calculations could have performance issues for retrievals because data
is not stored; it is dynamically calculated.
D.
A calc export script on the source database with the DATAEXPORT command could be used to export data
out of the revenue plan type and calc import script on the target database with the DATAIMPORT command
could be used to import the data file to the summary plan type.
E.
To disable the building of @XREF, update the HSPProperties file for the application before you click Create
during the application creation process.
Explanation:
B: Replicated Partition:
A portion of a database, defined through Partition Manager, used to propagate an update to data mastered at
one site to a copy of data stored at another site. Users can access the data as though it were part of their local
database.
C:
Transparent partition:
A form of shared partition that provides the ability to access and manipulate remote data transparently as
though it is part of your local database. The remote data is retrieved from the data source each time you
request it. Any updates made to the data are written back to the data source and become immediately
accessible to both local data target users and transparent data source users
Note: @XREF
Enables a database calculation to incorporate values from another Essbase database.
The following terminology is used to describe the @XREF function:
Data target: the database on which the current calculation is running (that is, the database on which the
@XREF call originates).
Data source: the database that is queried by the @XREF function. This database may be remote (that is, on a
different machine than the data target).
Point of view: the member combination currently being calculated on the data target (that is, the member
combination that identifies the left hand side of a calculation).
The @XREF function retrieves values from a data source to be used in a calculation on a data target. @XREF
does not impose member and dimension mapping restrictions, which means that the data source and data
target outlines can be different.
Note #2:
Hyperion planning’s Plan Types treated as individual databases in underlying Essbase database comes with
inherent facility to share data and dimension members across plan types in Hyperion Planning or equivalent
databases in underlying Essbase. This reduces the need for additional development/maintenance effort when
compared to Planning systems based on Standalone Essbase. The Hyperion Planning user would seldom
realize that the dimension members belong to multiple databases. While this might be an area of concern while
using Standalone Essbase to build planning system.