You need to get Sales data to the Summary plan type

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 Entity
You 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.