Está en la página 1de 22

7/14/2017 Document 1226783.

Hyperion Planning Process Management Features explained By Example (Doc ID 1226783.1)

In this Document

Abstract
History
Details
Planning Units:
Planning Unit Hierarchies:
Process Management Templates
Distributed Budgeting
Bottom-Up Budgeting
Free-Form Budgeting

APPLIES TO:

Hyperion Planning - Version 11.1.2.0.00 and later


Information in this document applies to any platform.

ABSTRACT

This white paper describes by example the new Hyperion planning process management features introduced from Talleyrand
(version 11.1.2); It starts by giving a brief definition of each of the main part of the process management unit and then goes
into details on the templates supported in this version:

Bottom-Up
Distribute
Free Form

HISTORY

Author: Bachir Ndiaye


Create Date 04-Oct-2010

DETAILS

Planning Units:

Planning units are combinations of scenario, version, and entity or part of an entity. Scenarios and versions are the basis of
the review cycle. Planning units submit planning data for a scenario and version. For example, a planning unit might consist of
a version (VerDist1), an entity (Ent1_1_1), and a scenario (CurrentDist). Planning units can also include secondary dimensions
(account) within any entity, refining the granularity of the planning unit.

Once the planning unit has been started, it allows the review process to move from one reviewer to another until the budget
process is complete. The review process follows the promotional path you set up when you select the owners and reviewers
for the unit, unless an event triggers a change in the promotional path.

Events that affect the promotional path include:

Exceeding or not reaching expense boundaries for budget items such as salaries, new hires or capital equipment
The current owner returning the budget to the previous owner for additional information
The current owner requesting help from an authorized user who is not necessarily in the promotional path

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 1/22
7/14/2017 Document 1226783.1

There are three process management templates and each one determines the first user to review the budget. The first user
completes the assigned tasks, then promotes (Bottom Up template) or submits (Distribute template) the budget, which alerts
the next owner that the budget requires his/her attention. Other users may also be notified whenever the budget passes from
one user to another. Each reviewer must validate the planning unit before sending the budget to the next reviewer.

Note: When using the Bottom Up or Distribute template, select reviewers in the order you want them to review the planning
unit. The first reviewer in the list is the first user to work on the planning unit. When the first reviewer promotes or submits
the planning unit, the second reviewer selected becomes the planning unit owner, and so on through the list of reviewers you
create. Planning unit ownership is inherited from the planning unit parents.

Planning Unit Hierarchies:

These are the dimensions/members metadata layout for accounts, Entities, Scenarios and versions that we are going to use
throughout this guide:

The entity members have the same structure as the Account members to better illustrate the mapping between Accounts and
entities.

For the scenarios, CurrentUp will be used for Bottom up and CurrentDist for Distribute
For the Versions, VerUP will used for Bttomup and VerDist for Distribute

Two Planning Units (Distribute – Distribute1, BottomUp – BottomUp1): Administration -> Process Management -> Planning
Unit Hierarchy:

The distribute Process management is configured with the following settings:

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 2/22
7/14/2017 Document 1226783.1

The account dimension was added for added granularity to the process management. Account members were created in a
format to match up entity members.

Users were also created and assigned as owners/reviewers in a format to match up entity/Account locations.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 3/22
7/14/2017 Document 1226783.1

The promotional path looks like this from the location Ent1_3_2:Acc1_3_2 so you could see that for ease of this exercise I
have used a format that matchup between Entity/Account/Owners/Reviewers

Note: When you add dimensions members, the new members are added as planning units only if they meet the criteria
specified in the inclusion rules for the planning unit hierarchy. For example, if the added entity is a fourth-generation
entity, and the inclusion rules specify generations one through three as planning units, the new entity is not added as a
planning unit. If the entity is a third-generation member, however, it is added as a planning unit the next time the
planning unit hierarchy is edited and saved, or synchronized.

When users add, delete, or modify dimension members that are used in planning unit hierarchies, the affected planning unit
hierarchy must be synchronized with the changes. When you display the list of planning unit hierarchies, the entry for each
planning unit hierarchy specifies whether recent changes are reflected in the planning unit hierarchy. Use this procedure to
synchronize dimension member changes with the planning unit hierarchy. If a user begins editing or synchronizing a planning
unit hierarchy after you display the planning unit hierarchy list, the planning unit hierarchy list does not display “Locked” for
the planning unit hierarchy. If you try to synchronize this planning unit hierarchy, the synchronization does not occur, and an
error message states that it is being edited.

The following webform will be used in the process to show how the process management impacts data entry in the cross
sections used in the planning Unit (Entity -> Account -> Version -> Scenario)

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 4/22
7/14/2017 Document 1226783.1

Process Management Templates

Distributed Budgeting

In a distributed budgeting, the budget is defined at the top level of the organization and then data is distributed down the
organization hierarchy. Budgets can be distributed by cascading the data down one level in the organization, or by distributing
the data to all organization members. After the data is collected at the lower levels, the budget is submitted through the
process management approval process. After all the budgets are submitted, the top budget group owner reviews, approves,
and loads the budgets for budgetary control, transaction control, and reporting.

The Plan Cycle needs to be started by going to Tools -> Manage Process to start the plan . On a Distribute cycle, starting the
cycle sets the top user (Rev1) as the owner who can then decide as to from which level the cycle starts.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 5/22
7/14/2017 Document 1226783.1

Rev1 is a reviewer and can therefore not enter data in the webform created.
Note that reviewers cannot alter data unless they are delegated by owners even if:
- They has write access to the intersection
- The intersection is level 0

As this is a Distribute Planning Unit, the current position starts at the top level.
Rev1 can then start the process from any location by doing a Delegate

Actions available to the top user Owner Rev1:

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 6/22
7/14/2017 Document 1226783.1

- Reject: Indicates the planning unit requires more work from the previous owner. Reject typically requires the previous
owner to create another iteration. By default, Reject returns planning unit ownership to the previous owner, but you may
select the next owner. Reject changes the planning unit status to Not Signed Off.

- Approve: Approves the planning unit and changes its status to Approved. With the distribute or Bottom Up process
management template, only the top user in the promotional path can approve the planning unit.

Note: With the Free Form process management template, a user can approve planning units from any status except Not
Started. Only an administrator can approve from a Not Signed Off or First Pass status.
Approving a planning unit is an implicit reviewer sign-off. Typically, a planning unit is approved only once. However, an
administrator can reject an approved planning unit, requiring a second approval.

- Delegate: Passes ownership to a user not in the promotional path (not restricted to users not in the promotional path –
could select any user).
Select a user from Select Next Owner to pass ownership to that user.
The specified user selects Promote/Submit when done to return the budget to the user who selected Delegate.

Example:
User Rev1 can delegate any user in the promotional or outside of the promotional path.

Rev1 delegates a user in the promotional path (Bachir1_3_2) at the top level and the ownership will change at the top and all
children will also change ownership to delegated user Bachir1_3_2

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 7/22
7/14/2017 Document 1226783.1

And the promotional path is altered accordingly by inserting user Bachir1_3_2 before user Rev1 that delegated. The Delegated
user can perform the following actions

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 8/22
7/14/2017 Document 1226783.1

Note: Delegated user takes on the role of the user that delegated. In this example, Bachir1_3_2 already existed in the
promotional as an owner but takes the role of reviewer as the user that delegated (Rev1) is a reviewer.

Reject: Will pass ownership to the first owner at that level (Ent1) which is Bachir1
Delegate: can select any user in or out of the promotional path but the user must:
- Be provisioned for the application
- Have access to the members that make up the planning Unit

Note: Parent that have children with different owners would be set to ‘No Owner’
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 9/22
7/14/2017 Document 1226783.1

- Submit: will pass ownership to next upper level


- Submit to Top: will pass ownership to the top level.

If user Rev1 delegated a user not in the promotional path (Rev2) then the promotional path will be modified as in above and
Rev2 will become the owner and the actions will be similar.

Note: Inserted users through DELEGATE will be removed from promotional path once an action is performed (not true for
‘Sign off’)

- Take Ownership: Bypasses the current owner and lets you enter or edit data outside of the defined promotional path.
Take Ownership is available only to users above the current planning unit owner in the planning unit hierarchy.

- Distribute, Distribute Children, or Distribute Owner: Passes planning unit ownership to multiple users. Distribute
actions work differently depending on the current location of the budget in the planning unit hierarchy. These actions are for a
planning unit hierarchy using the Distribute template. Distribute assigns ownership to the members at the current level of the
planning unit hierarchy. Distribute Children assigns planning unit ownership to the children of the current owner. Distribute
Owner assigns planning unit ownership to the level 0 owner defined during planning unit hierarchy creation.

1. Distribute
This action will pass ownership to the next user on the same level in the promotional path. By doing a distribute, user
Rev2 will pass ownership to user Bachir1 (same level)

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 10/22
7/14/2017 Document 1226783.1

Distribute passes ownership to next user at the same level.

Note that Rev2 (was delegated and wasn’t initially in the promotional path) has been removed from the promotional
path

Bachir1 becomes the owner of Ent1_3_1:Acc1_3_1 and as the distribute action was performed at that level, the
process status changes from under review to Distributed

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 11/22
7/14/2017 Document 1226783.1

This is how it translates in terms of data entry access, Bachir1 can only enter data at the level 0 cross section
Ant1_3_1:Acc1_3_1

User Bachir1 (owner) will not have the option to distribute to the level below because the Distribute action was already
carried out to pass ownership. The actions available to Bachir1 are Delegate, Submit and Submit to Top. To move down
the promotional path, user Bachir1 would have to delegate Rev1_3 who would then be inserted after Bachir1 but at the
same level Ent1.

Bachir1 Delegates Rev1_3:

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 12/22
7/14/2017 Document 1226783.1

The delegated user Rev1_3 will then be able to carry on the distribution to the next level and the inserted user
(Rev1_3) will then be removed. Ownership will now be passed over down the promotional path to Rev1_3 at location
Ent1_1.

Rev1_3 will only be able to delegate to pass ownership to Bachir1_3 as a distribution was already carried out to pass
on ownership but this Delegate action is direct and won’t alter the promotional path:

Because a Delegate action was called on Bachir1_3, to pass ownership on to next level (Rev1_3_1) a Distribute action
has to be invoked to carry on the process downwards:

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 13/22
7/14/2017 Document 1226783.1

And Because a Distribute action was called to pass ownership down to Rev1_3_1, a Delegate action has to be called
pass ownership to Bachir1_3_1. The Delegate action is direct and does not alter the promotional path.

At the level 0 Node, the user can do the following actions:

At the end of the node, user Bachir1_3_1 can Delegate other users, submit to pass ownership upwards or submit to
Top to pass ownership directly to the top level.
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 14/22
7/14/2017 Document 1226783.1

2- Distribute Children:
Assigns planning unit ownership to the children of the current owner.

3- Distribute Owner:
This action could be used in a Distributed Budgeting to start the process at the level 0. The top user starts the process
by doing a distribute owner from the top level (Ent1) or from any other level to assign location ownership to owners
(not reviewers) from that level downwards. The process current location starts at level 0.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 15/22
7/14/2017 Document 1226783.1

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 16/22
7/14/2017 Document 1226783.1

Note: You cannot change the status of a parent if its children have different owners. If the children are promoted to,
submitted to, or signed off by different users, the parent has no owner and only budget administrators can change its status.

Bottom-Up Budgeting

In bottom-up budgeting, data is input at the leaf member level (for example, children of Budget Group) and consolidated by
rolling data up the organizational hierarchy. When the budget is started, the data is populated for each scenario and for each
user independently. Users can view or edit data based on security defined for the planning unit. Users can define what-if
scenarios, depending on their needs. Using process management, planning units get reviewed and approved. The
administrator (the topmost Budget Group owner) consolidates the individually-approved budgets into a final consolidated
budget.

For a Bottom-up as opposed to a Distributed planning Unit the process initially starts at level 0.

Note: If the planning unit hierarchy uses the Bottom Up template, selecting Start starts the planning unit, and also runs the

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 17/22
7/14/2017 Document 1226783.1

Originate action. These actions set the user defined as the planning unit owner in the planning unit hierarchy as the current
owner, and the planning unit status changes to Under Review.

Not started

Started

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 18/22
7/14/2017 Document 1226783.1

User Bachir1_1_1 can then perform the following actions:

But a user above this hierarchy would have actions based on his ownership position in the planning unit hierarchy:

- Originate: Changes the ownership of all selected planning units (including all descendants) to the first owner defined for
that planning unit in the planning unit hierarchy. This is the equivalent of a ‘Distribute owner’ in a Distributed Planning Unit.

Note: The planning unit first owner differs between the Distribute and Bottom Up templates. With the Distribute template, the
first owner is the owner at the top of the planning unit hierarchy. With the Bottom Up template, the first owner is an owner at
the bottom of the planning unit hierarchy.

- Promote: Passes the planning unit to another user to review. This action assigns ownership of a planning unit the first time,
and thereafter transfers ownership of a planning unit from one reviewer to another. Promote causes an implicit sign-off by the
current owner and changes the planning unit status to Under Review.

Note: The Promote action is subject to data validation rules on the planning unit. If the conditions in all associated data
validation rules are met, the message “No Additional Approval Needed” is displayed in Sub-Status. If any other message is
displayed, review the data validation report, and take any necessary actions.

- Reject: Indicates the planning unit requires more work from the previous owner. Reject typically requires the previous
owner to create another iteration. By default, Reject returns planning unit ownership to the previous owner, but you may
select the next owner. Reject changes the planning unit status to Not Signed Off.

- Approve: Approves the planning unit and changes its status to Approved. With the Distribute or Bottom Up process
management template, only the last owner in the promotional path can approve the planning unit. With the Free Form process
management template, a user can approve planning units from any status except Not Started. Only an administrator can
approve from a Not Signed Off or First Pass status. Approving a planning unit is an implicit reviewer sign-off. Typically, a
planning unit is approved only once. However, an administrator can reject an approved planning unit, requiring a second
approval.

- Delegate: Passes ownership to a user not on the promotional path. Select a user from Select Next Owner to pass ownership
to that user. The specified user selects Promote when done to return the budget to the user who selected Delegate. This
action is available with the Bottom Up process management template.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 19/22
7/14/2017 Document 1226783.1

- Take Ownership: Bypasses the current owner and lets you enter or edit data outside of the defined promotional path.
Take Ownership is available only to users above the current planning unit owner in the planning unit hierarchy.

- Freeze: Locks all related data in descendant planning units. This action makes all related data read only, but does not
change ownership of any planning unit. The owner who selects this status or an administrator sets the planning unit status to
Unfreeze to reverse this action.

- Sign Off: Signs off on a planning unit. Sign Off does not transfer ownership of the planning unit, but changes its state to
Signed Off.

As an Example, let us go through the process using the following promotional path:

User Bachir1_1_1 is the only non administrator user that can write into the intersection

User Rev1_1_1 is then promoted through the Promote action (note that user selection is automatic)

User Bachir1_1_1 will no longer be able to write to the intersection:


https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 20/22
7/14/2017 Document 1226783.1

Rev1_1_1 though the owner is a reviewer and will not be able to write data to the intersection. Reviewers can only
review the data and follow-up with a Reject, Promote, Sign off, Delegate, Originate or Freeze. Reject would send the
ownership back to Bachir1_1_1.
Promote would send the ownership to Bachir1_1

Sign off would set the status to sign off but the owner would still be the current user

Delegate would allow to select another user and the promotional path would be altered by inserting the delegated user
(Rev4) before the current user (Rev1_1_1)

Note: The delegated user (Rev4) can only promote to Rev1_1_1 (who delegated Rev4).
Originate would send ownership back to level 0 user Bachir1_1_1

Freeze would freeze the process but would not change the ownership. Only the user or an administrator would be able
to unfreeze the process.

Once at the top level, the planning unit owner can Approve the planning unit to close the cycle:

Free-Form Budgeting

With free-form budgeting, data is input at the leaf member, and planners select the next owner
from a drop-down list. Free-Form budgeting uses the process management model from Planning releases earlier than Release
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 21/22
7/14/2017 Document 1226783.1

11.1.2. Select this budget template if you are not using the process management new features.

Didn't find what you are looking for?

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=l2dbxgb08_4&id=1226783.1 22/22

También podría gustarte