Dimensions and detailed planning

Detailed planning integrates with the model components of FP&A Plus and as such makes use of dimensions in its data management.

The dimension settings in detailed planning determine the relationship between the detailed plan and other models such as finance models and how the data is copied into the models when you post data to them.

  Tip:  An important step in designing detailed planning models is to decide on your strategy for sharing dimensions between models.

DP models versus financial models

A detailed planning model uses many of the same dimensions as other FP&A Plus models. The following table compares the mandatory and optional dimensions in the basic finance model and the two detailed planning model types:

FP&A Plus Generic Model	Detailed Planning General Model	Detailed Planning Personnel Model
Accounts	Accounts	Accounts
Time	Time	Time
Version	Version	Version
Time Perspective	Time Perspective	Time Perspective
Currency (optional)	Currency (optional)	Currency (optional)
Geography/Other	Geography/Other	Geography/Other
	Detailed Planning	Employees
	Allocation	Allocation
	Optional dimensions, depending on domain	Optional dimensions (for example: Project, Job Title)

Dimensions exclusive to DP

The dimensions found only in detailed planning models are Detailed Planning/Employees, Allocations, and optional user-defined dimensions such as Project, Position Title, and so on.

  Note:   The dimension Geography/Other is user-definable; if you are doing personnel planning, you rename this dimension Organization.

Dimension roles in DP

Detailed planning uses the following dimensions:

•  Account

  The Account dimension is mandatory in detailed planning models.

  Each calculation in a detailed planning model can be linked to one account in the detailed planning model, and optionally to one in the finance model. The Account dimension stores the numeric results of what is being calculated in the detailed planning model. Typically, the members of this dimension would be items that need to be measured in the model. For personnel planning, this could be items such as salary, benefits, headcount, and taxes.

  To map a calculation to an account in either model, you enable the calculation's Target Account property. If a calculation is left unmapped to any accounts, it does not post data.

•  Allocation

  The Allocation dimension stores allocation data. It has four members, created automatically by the New Model Wizard: Total, Source, In, and Out. Their relationship is as follows:

  

  The Total member is the parent and is used for reporting consolidated results. All data imported or created through calculations in Detailed Planning Manager initially resides in the Source member, and amounts that are allocated are copied to the Out and In members. The Out member contains negative data, and thus the roll up of the values can be described as:

  Total = Source + In - Out.

  The dimension type is Allocation.

  This dimension is always a parent-child dimension.

  You can rename the dimension; Allocation is the default name. No other properties of this dimension can be changed and you cannot add alternate hierarchies, attributes, and so on.

  The Allocations dimension can be shared with other models.

•  Currency

  The Currency dimension functions in the detailed planning modelin the same way as in other models. Detailed planning posts all data for this dimension to the Native member.

•  Detailed Planning

  If the model type you choose is Detailed Planning (General) this dimension appears as the Detailed Planning dimension; if the model type is Detailed Planning (Personnel) this dimension appears as the Employees dimension.

  The dimension type is Detailed Planning Object.

  The Detailed Planning dimension is a flat list of the entity you are modeling. For example, the Employee dimension is a list of employee members with member properties set according to your attribute setup in the Detailed Planning Manager.

  In the Detailed Planning Manager, the name of this dimension (for example, Employees) becomes the name of the "resource" panel (the one immediately below the Administration panel).

  The dimension is level-based and therefore creates a default member or members.

  In Model Manager, you cannot modify this dimension (that is, add, delete, or move members). You cannot add, edit, or delete member properties or their values. However, you can create, edit, or delete alternate hierarchies for this dimension.

  The Detailed Planning dimension should not be shared with other models; it belongs only to the detailed planning model it was created for. The entire dimension is managed in Detailed Planning Manager and its data is posted to the detailed planning model during the DP Post process.

•  Organization

  The Organization dimension is the main dimension/hierarchy used to organize the planning entity (for example, employees). The dimension type is Geography/Other.

  In personnel planning, the Organization dimension is special because it is used in the "DPO" drawer to give users access to the information associated with individual employees.

  Employees are associated with members of the Organization dimension, and all calculated data is for a specific time period. For the Organization and Time dimensions, data for a specific department or time period is copied into the relevant member in both the detailed planning and finance models.

•  Time

  The Time dimension is mandatory in detailed planning models and is part of the definition of almost every object in Detailed Planning Manager. For example, the Time dimension defines the maximum time scope for Detailed Planning calculations; for a Scenario, it defines the Start Period and End Period.

  Periodicity defines how the Time dimension is set up. Periodicity defines the "calendar" that the detailed planning model follows. The periodicities allowed in detailed planning are:

  • Yearly
  • Quarterly
  • Monthly
  • Twice Monthly – Available when calendar type is set to Non-Calendar 12 Periods; in personnel planning, use this option to pay out salary twice a month (24 payment periods).
  • Weekly
  • Bi-Weekly – Available when calendar type is set to 13 Periods; use this option to pay out salary every two weeks (26 payment periods).
  • Daily

  For more information, see Time mapping in detailed planning.

    Tip:  Optionally, you can set the display properties for the Time dimension.

•  Time Perspective

  The Time Perspective dimension is mandatory in detailed planning models, and works the same way as it does in other models. This dimension has no link with the detailed planning model. Data posted to this dimension is always stored in the Base member.

  It is recommended that the Time Perspective dimension not be shared with other models.

•  Version

  Detailed planning Scenarios link to the Version dimension in the detailed planning model, and optionally to the same dimension in the finance model. A scenario that does not link to any Version dimension does not post data.

  Detailed planning can classify data by scenario; for example, if changes are made to an initially submitted personnel budget, a new scenario can be created for reporting purposes. Scenarios are independent of Versions. Each scenario can be mapped to one version in the detailed planning model and one version in the finance model.

Optional dimensions

Dimensions such as Project, Job Title, or Region are optional in detailed planning model. These dimensions are mapped to mandatory attributes in the detailed planning model. Data for a specific optional dimension member is copied only into the relevant member in the detailed planning model. A financial model is handled differently because it may not contain all the optional dimensions; in the financial one, data for each Organization member is aggregated across not only the detailed planning entity (for example, employees) but also all relevant optional dimensions.

You should minimize the number of dimensions in a detailed planning model for the following reasons:

• Increasing the number of dimensions affects the performance of the model.
• Unneeded dimensions complicate reporting.
• A detailed planning model can contain an unlimited number of attributes to define employees (these are created in Detailed Planning Manager's Administration section).

Sharing dimensions with finance models

Most users of detailed planning also use FP&A Plus for financial planning, and therefore already have a finance model. For these users, it is tempting to share dimensions between the detailed planning and finance models. Though this practice offers convenience, it can negatively impact what-if modeling for detailed planning, as well as affecting performance—when the shared dimension of one model is updated, all models that share that dimension must be updated too.

  Best Practice:  We recommend not sharing any dimension other than Currency. Avoid sharing Time, Time Perspective, and Version.

The effect of sharing the various detailed planning dimensions is as follows:

• Account

  Never share the Account dimension. The detailed planning model usually contains a subset of accounts in the main finance model. Also, including all the accounts from the finance model in the detailed planning model negatively affects performance.

• Time

  Sharing the Time dimension is convenient but not required; however, the members of Time in the detailed planning model should exist in a financial model in order to map data.

• Time Perspective

  Sharing Time Perspective is convenient but not recommended.

• Version

  The Version dimension should not be shared. Detailed planning users will need to do what-if analysis of different scenarios that users of the main budget should not be permitted to see.

• Organization

  Sharing Organization between both models is a best practice.

• Allocation

  The Allocation dimension can only be shared between detailed planning models.

• Employees

  This dimension can only be used by the detailed planning model that it was created for and can never be shared.

• Other Dimensions

  (For example, Products.) These optional dimensions can be shared but usability and performance should be considered.