Understanding Planning and Budgeting Activities

This chapter discusses:

• Considerations when creating activities.

• Properties and characteristics of activities.

• Activity relationships.

• Scenario relationships and activities.

• Activity versions.

• Considerations for using balance sheet planning.

• Considerations for using consolidated line item activities within scenarios.

• Prerequisites.

Considerations When Creating Activities

Activities are a large and central feature that drive the success of any Planning and Budgeting implementation. The term activity in Planning and Budgeting describes a related set of planning data that has some characteristics in common. Every implementation requires at least one activity. Choosing additional activities requires a thorough understanding of your goals, current and future scope, for a successful implementation.

Planning and Budgeting provides three activity types: line item, position, and asset. A line item activity is a collection of rows of data that share something in common, notably their metadata and budgeting and planning processes. You will probably have one to many line item type activities. Position and asset budgeting are designed to solve rather specific budgeting solutions. Position budgeting supports detailed bottom-up budgeting of employee and position data that encompasses all compensation, benefit and employee tax relationships, and includes integration with PeopleSoft Human Capital Management (HRMS system) as well as third-party human resource systems. Asset budgeting supports building up a capital spending plan based on asset catalog items, quantities to be purchased, acquisition and in-service dates, as well as depreciation methods and schedules. Asset budgeting integrates with PeopleSoft Asset Management and third-party capital asset systems. Planning and Budgeting supports multiple asset and position budgets in a model, when there are multiple corresponding line item activities.

This section discusses the following considerations:

• Volume.

• Approval and security.

• Dimensions.

• Modeling dependencies and timing.

Volume Considerations

Although there are no hard limits on the number of activities that a single model supports, the design and use cases have assumed an approximate maximum of 12 activities in a single model. If during the course of designing a model the candidates for activities exceed twelve, then consider making these items members of a dimension instead of an activity. Individual departments, products, projects and customers, for instance, would be good candidates for dimensions instead of activities.

Certain dimension-type data that should not be set up as an activity include: scenarios, versions, time periods, and currency. All of these items have special behaviors and are supported as distinct features in Planning and Budgeting.

Note. Bear in mind that the more activities you define, the more activity scenario combinations you will need to manage during your planning process.

See Defining Your Planning and Budgeting Parameters.

See Using Multiple Currencies.

See Activity Versions.

Approval and Security Considerations

Each activity can have its own user security. A common requirement is to secure certain data for a common dimension (such as a department) by function or area. For instance, a person preparing or reviewing a department spending budget should be restricted to only viewing salary and compensation data at a rolled up level. Different users may access the position budgeting activity separately from the line item activity, thereby preserving employee compensation data anonymity. Likewise, certain users may require access to the revenue plan, some may require access to the spending plan, and others may require access to both. If most users have access to one or only a few activities, then they don't have to span multiple activities. The more intuitive the user-experience, the easier the training, and fewer user errors may occur.

The My Planning Workspace, data analysis and data entry views support a single activity at a time. This is the primary interface for all users. Consider segregating the model into separate activities to help filter what the users see and work with. Putting all data into a single activity may confuse users with irrelevant dimensions on certain rows, exposing more data to users than they need to see. My Planning Workspace was designed with multiple activities in mind, to quickly filter through a wide range of disparate data in a model. However, when analysis or data entry requires disparate data to be in a single view, then consider implementing fewer activities to get the most information on a page or at least consider the Includes Data From activity relationship option to copy certain key data from one activity to another.

See Establishing Activities and Activity Groups.

If different areas of the enterprise have different approval and security requirements, then consider grouping these areas into separate activities. For instance, the users' data and budgeting approval process can be quite distinct by function or geographic area. Revenue, project, and overhead spending often exhibit different characteristics for budgeting and planning purposes. Revenue may be planned by product, customer, or market. Revenue planners may require security based on their products. Revenue plans may get approved by product families. Projects will have their own approval paths and project groupings, as well as security requirements. Department overhead spending may be yet another area that is planned differently, by another set of users.

Another alternative to defining security is to assign secondary security for a given line item activity. This secondary security option, when enabled at the line item activity level, is equivalent to row level security for a specific dimension. For example, in addition to assigning department as the planning center and associating the security group to it, a secondary security could be applied at the account level. In this case, you can allow users access to certain accounts, or alternatively allow them to see the row, but not to update it. You should review this feature in conjunction with your security requirements around data entry and access within your activity, since users that do not have access to all the data in a given planning center will not be able to perform certain actions.

See Setting Up Planning and Budgeting Security Groups and Secondary Security Groups.

Dimension Considerations

Each activity supports optional dimensions. Dimensions enable analysis, formula building (methods), and reporting for various areas of an enterprise. Rather than putting all dimensions in a single activity, each activity can support a tailored set of dimensions and dimension members. A revenue activity may require product, customer, or sales region dimensionality to forecast future growth. An overhead expense activity may require cost center and geographic dimensionality. If the dimensions required for modeling, analysis, and reporting vary considerably from one area to another, then consider different activities by key areas.

Modeling Dependencies and Timing Considerations

You should also take into consideration modeling dependencies. The flexible formula (FLEX) method supports designing formulas that span multiple line item activities. However, there are certain order dependencies that disallow formula references between activities (to avoid systematic circular reference errors). In the case of multiple activities such as revenue and expense, an expense activity may reference and use data from the revenue activity, but the system will preclude the opposite condition where revenue references expense activity data. Formulas contained within a single activity have the fewest restrictions. The system also supports copying data from one activity to another (also known as the Includes Data From activity relationship).

See Defining Activities.

Worldwide deployment may be another criterion to consider when choosing multiple activities. The budgeting process and timing may vary based on data composition or enterprise culture. Financial and source systems and release versions as well as software vendors may vary by region, driving different data staging and export process requirements. Each activity can be staged and exported separately.

Each activity supports a start and end date. Depending on the budgeting process and data dependencies, certain areas of the enterprise may need to be complete before other areas can begin. There may be functionality dependencies such as completing the revenue plan before beginning the expense plan and finalizing the balance sheet and cash flow plan. Similarly, a worldwide enterprise may want certain key geographic regions to complete their budgets before other regions begin. Having separate activities makes the budgeting process clearer and easier to administer.

See Also

Memory Limitations and Data Considerations

Properties and Characteristics of Activities

This section discusses:

• General properties of activities.

• Line item activities.

• Position activities.

• Asset activities.

General Properties of Activities

Activities are user-definable entities that you can associate with other activities, different scenarios, and different planning models.

In Planning and Budgeting, the single most important implementation decision you will undertake is defining and implementing the activities your organization requires. You should first create an implementation project plan that contains the following three elements:

• The activities and scenarios that you require, and their attributes.

• When you will define, stage, and release the required activities and scenarios.

• The requirements around the data when the activity edits are complete.

Planning and Budgeting provides three activity types: line item, position, and asset.

You select one of the predefined activity types (line item, position, or asset) on the Activity page (BP_ACTIVITY). Activity type properties are implied and immutable, and you cannot create your own activity types. However, you can create new activities.

Each activity can use a different approval dimension called the Planning Center dimension. This means that you can define activities with different workflow, approval levels, users, dimensions, and members. Though you do not have to define activities with the same dimensions and members, you must define each activity with an account dimension and a planning center dimension.

Note. For two different activities with an Approval Includes relationship, the child activity must use the parent activity's defined planning center dimension. Two activities with an Includes Data from or References Data from relationship do not have to share the planning center dimension.

You also cluster activities into an activity group. This is a collection of activities and dimension hierarchies to apply across all the dimensions of the activities. You use the Activity Group component (BP_ACTIVITY_GRP) to perform the following tasks:

• Group activities.

• Create new activities for the group.

• Define hierarchies and members for dimensions, activity relationships, and relationship dependencies for grouped activities.

• Copy an activity group definition into a new definition.

You must associate line item activities with method groups on the Activity Groups component. However, you do not associate method groups to position and asset activities.

Note. If an activity group is associated with a staged planning model, you can add new activities, but you cannot delete any existing staged activities and their properties (such as method groups, dimension trees, and dimension members).

Use the Hierarchies page (BP_ACTV_GRP_HIER) of the Activity Group component to establish dimension information:

• To ensure comparability, each of the dimensions must use the same tree (or no tree at all) across all of the affected activities.

  For all dimensions, you must establish a dimension setID that controls which trees and dimension members the system displays as available for selection.

• The system automatically exports account dimensions and any dimensions used as the planning center dimensions to the General Ledger, as indicated by the Export to General Ledger run control page.

  Note. In order to export the line item activity data back to General Ledger, you must also select the Export to GL option on the Activity page.

• You can perform dimension member value mapping on the Dimension Member Mapping page (BP_DATA_MAP).

  For a specific activity group and dimension, this functionality enables you to define a range of dimension members that you map to a target dimension member. For example, you can define all dimension member IDs from 100 to 500 map to dimension member ID 600. This mapping is applicable to all scenarios associated with the activity.

Use the Members page (BP_ACTV_DIM_MEM) of the Activity Group component to establish dimension member information. This page displays the dimensions (or ChartFields) for each activity of an activity group. You define whether one, all, or multiple dimension members are included in an activity, and specify member values. The default value is All Members.

After defining dimensions and members, you should verify if their as of date has changed. The as of date that you use on the activity group page determines all valid dimension trees and members for the planning model it is assigned. Once an activity has been staged, you will not be able to change it. This as of date can be future dated, in order to pick up dimension members that may not yet be active until the next year. Based on the as of date you enter, all dimension members at that point in time can be included in your planning model activities, even if the member becomes inactive after the as of date.

Use the Relationships page (BP_ACTV_DEPEND) of the Activity Group component to establish any dependencies. We discuss this in more detail in the Activity Relationships section.

See Understanding Activity Relationships.

Working with Multiple Activities

Each activity name is user-defined. Position and asset activities are always child activities (or they can be used as standalone activities) that can be aggregated to a line item activity. A line item activity can have only a single position and asset activity linked to it.

Line item activities can be either a child or parent (consolidating) activity. A parent line item activity can have more than one child line item activity. We have generally assumed only one or two levels of line item activities.

Using Planning Centers

Planning centers are a central concept supported by all activity types. Each activity can have a different planning center. The planning center is significant because it can have its own security, and the planning center hierarchical tree structure supports the approval workflow path. If a department dimension is used as a planning center, each department can be secured. The department tree also serves as the workflow approval path when users submit their plan for approval.

Approval Includes between two or more activities requires that the activities share a common planning center dimension, such as cost center (department). If when submitting a line item expense budget you want to automatically submit the associated position detail activity for a particular cost center, then the cost center dimension must be the planning center for both activities.

Using Multiple Models

Each activity and type are contained within the context of an activity group. Each Planning and Budgeting model supports a single activity group. However, a single activity group can be shared across multiple models. If your budgeting process calls for multiple Planning and Budgeting models, consider setting up a single activity group with many activities that may support different models.

All activities within an activity group share the same tree definitions and dimension setIDs and as of date. Depending on the requirements of the different Planning and Budgeting models, a single activity group may or may not be feasible. If for instance different models require different tree definitions, then you require multiple activity groups with unique activities.

Line Item Activities

You source line item activities from ledger tables. Normally, you derive your line item source data from your organization's general ledger tables. However, you can use any data contained in a ledger structure as your line item activities' source data.

Note. If you use the PeopleSoft General Ledger or a third-party general ledger system, you can use the actual ledger (LEDGER_F00) for source data only in the EPM Warehouses. Planning and Budgeting cannot push changed data to the actual ledger. Planning and Budgeting can only submit changed or new data to one of the three available budget ledgers (BP_LED_BUDG_F00, BP_LED_PROJ_F00, or BP_LED_KK_F00) in the EPM Warehouses, which can then be exported back to your source general ledger system.

Line item activities are user-defined, more than any other activity type. These activities have interrelationship and communication abilities that position and asset activities do not have, as follows:

• You can relate line item activities to other line item activities, and position and asset activities.

• You can define line item activities as reference data.

Line item activities can be separated into two categories: top-down and bottom-up.

• Top-down activities: Use when creating strategic long-term plans at a more summarized level.

• Bottom-up activities: Use when creating detailed annual budget plans.

See Integrating with PeopleSoft General Ledger.

Position Activities

You can source position activities from PeopleSoft or third-party human resources applications data, such as position and employee job data. These activities share the following characteristics:

• Position activities only have an expense impact.

• Position activities can be modified.

  This means that you can work with existing and new data, such as when an employee receives a promotion and you use the previous and current compensation data, or you create new positions anticipated for the proposed budget year.

• Position and employee expense in the position activity can be shared across more than one planning center budget.

• Position activities are not sourced from a ledger.

  But there can be an expense impact on the budget ledger, when the position activity is a child of a line item parent activity.

See Integrating with PeopleSoft HRMS.

Asset Activities

You can source asset activities from in-service asset data for your organization.

Unlike position activities, existing in-service assets in the asset activity cannot be modified or updated. Your users can only add new or update the new budgeted assets to capture the assets' depreciation expense and cost.

Asset activities have a twofold impact on your organization's accounts—depreciation accounts, asset accounts and optionally, the cash accounts. Asset activities may also potentially impact your organization's balance sheet and income statement.

The asset depreciation and cost in the asset activity cannot be shared across more than one planning center budget.

Asset activities are not sourced from a ledger. But there can be an expense and cost impact on the budget ledger, when the asset activity is a child of a line item parent activity.

See Using Data from PeopleSoft Asset Management.

Activity Relationships

Note the following rules about activity relationships:

• Activities can have one of two types of relationships: a workflow relationship or a data relationship.

  Data relationships can be further divided into two types: insert data or reference data. Each of these can have dependencies.

• Parent activities are always line item activities.

• Asset activities cannot have child activities.

• Position activities cannot have child activities.

• Parent line item activities can support any of the three activity types as its children: asset, position, and line item.

• One parent line item activity can have only one position activity child.

• One parent line item activity can have only one asset activity child.

  However, one asset activity can insert data into more than one line item activity. But only one of the line item activities can have the Approval Includes relationship.

• Two line item activities can have a parent-child relationship.

  However, you cannot define parent-child relationships between asset and position activity types. This means:

  • You cannot define an asset activity that is the child of another asset activity.

  • You cannot define a position activity that is the child of another position activity.

  • You cannot define an asset activity that is the child of a position activity, or vice versa.

• You define activity relationships on the Relationships page (BP_ACTV_DEPEND) of the Activity Group component.

• You can define asset and position activity relationships in two ways:

  • Insert data with no defined workflow.

  • Insert data with the Approval Includes workflow option.

    Note. The References Data From option is not valid for asset and position activities.

• You can define relationships across two line item activities in two ways:

  • Use the Insert Data option with no defined workflow or data insert option.

  • Use the References Data From option with no data inserts option.

    Note. The Approval Includes option is not valid between two line item activities.

• The system ensures that asset and position activities always inherit the time and periods of the parent line item activity, as defined by the scenario.

• You must define a planning center dimension and an account dimension for each activity.

  You must associate the planning center dimension with a node-oriented tree that is balanced down to the lowest level of preparation. You are required to associate an account dimension with a tree for the following three situations:

  • When member levels differ between other related activities.

  • When line items are being compared to each other for reporting, such as top-down and bottom-up plan comparisons.

  • When using planning targets, such as a top-down scenario that is defined as another's planning target.

    Note. For any other situation but the three situations noted above, you don't need to associate an account dimension with a tree.

Activity Relationship Dependencies

You can define calculation and procedural dependencies between activities to ensure the system performs the calculations and approvals in the desired order.

The three dependency relationship types are as follows:

• The Includes Data From dependency option enables you to integrate asset, position, or line item activities as special lines to another line item activity.

  This option essentially copies (or aggregates) activity data from one budget to another. As illustrated in the table, the system uses specific method IDs for each activity type to identify the integrated special lines in the budget.

  Activity Type	Method ID
  Asset	ASSET
  Position	POSBUD
  Line Item	LINEITEM

• The References Data From dependency option enables you to source data from different line item activities in a formulaic expression.

  Instead of copying activity data from one budget to another, the system stores source activity data in an interface table, making the data available to use as formula source data by a defined flexible formula. You use this relationship only when one line item activity requires data from another line item activity to perform a calculation using a flexible formula. The system uses the Analytic Calculation Engine (ACE) functionality for line item activities when the reference data option is used with formula calculations.

  The system uses a specific method ID, FLEX, in conjunction with formula IDs in the line item activity, to identify the location of data required for calculating formulas.

• The Approval Includes dependency option enables the target (parent) activity to control the workflow and working versions of the source (child) activities. The system ensures that the parent and child activities remain synchronized with one another in the following two ways:

  • Creating a new working version in the parent automatically triggers the creation of a new working version in the child activities.

  • Prevents user version actions of submit, reject, and copy functions to the child activity.

Note. The Approval Includes workflow option can only be used once against any child activity. For example, you define an asset activity to insert data into two activities: Balance Sheet activity and Expense Line Item activity. In this case, you can only assign the asset activity with the Approval Includes workflow option to either the Balance Sheet activity or the Expense Line Item activity. However, both activities can have a data insert relationship.

You establish dependencies on the Relationships page (BP_ACTV_DEPEND) of the Activity Group component. Be aware of the following:

• As activity relationship dependencies do not rely on the staging process, you can change them after staging the activity scenario.

  However, if either of the related activities is currently staged, then you cannot delete the relationship row.

• You can add Includes Data From or References Data From relationship type to an existing relationship row if  the activities were not previously checked in.

• After staging activities, you cannot add Approval Includes relationships.

  The system disables certain relationship type check boxes for staged activities.

See Also

Establishing Activities and Activity Groups

Data Relationships

There are two kinds of data relationships: insert data and reference data.

Insert Data

An insert data relationship between two activities means that the system inserts the data results of a child activity into the appropriate parent activity. An example of this is when the system inserts the sum (or aggregate) of position or asset activity data details into a line item activity, such as an expense activity.

As a child activity can have more than one parent, the system can insert the data results from one subordinate activity (the child) into multiple superior activities (the parents). For example, an asset activity can contain both expense and asset account types. In this situation the system can insert the resulting data into two activities: an expense activity and a balance sheet activity.

The system uses the following rules and runs the following audits when handling insert data relationships:

• When two activities have a data insert relationship:

  • The planning center dimension for each activity does not have to be the same when there is no defined workflow relationship.

    However, if you define the Approval Includes workflow relationship, the planning center dimension must be the same for the activities.

  • The activity providing the insert data (the child) must also include the parent activity's planning center dimension.

    This means that you must include the parent activity's planning center dimension as a dimension in the child activity definition. Again, if you define the Approval Includes workflow relationship, the planning center dimension must be the same for the activities.

  • You can define any additional dimensions, and the two activities do not have to share all of the same dimensions.

  • When there are shared dimensions between activities, the child activity's dimension definitions must use members that are at the same level or lower levels of the tree.

• The Model Recalculation Application Engine process (BP_MDL_CALC) updates insert data relationships; for example, when you submit a budget but the child data source has changed.

  You typically run this process overnight. For insert data relationships this process synchronizes data between related activities, and inserts any new row combinations needed in the target activity. Alternatively, if you edit a planning center for the parent activity, the insert and update from child activities will occur for that planning center when you edit online from My Planning Workspace.

  See Understanding the Model Recalculation Process.

Reference Data

The reference data relationship (or calculation dependency) means that an activity only references the data or results from another activity. The system references—it does not insert—amounts or results from one activity to another to derive new results or amounts.

The system uses the reference data relationship only when you define the References Data From relationship dependency option between line item activities. A reference indicator is not required when the source and target of the reference data relationship are contained within the same activity. You use this option only when there is a data requirement across line item activities for calculation of the defined formulas.

The system uses the following rules and runs the following audits when handling reference data relationships:

• When two activities have a reference data relationship:

  • You do not have to define the same planning center dimension for the activities.

  • You can define additional dimensions, and the activities do not have to share these dimensions.

  • For the activity being referenced by the formula, there are no restrictions on members and levels on which data is entered and summarized.

• The system inserts data that is referenced across activities into an interface table. Activities using this information (data and formulas) access this interface table for the information; the system never directly inserts this reference data into an activity.

• The Model Recalculation Application Engine process (BPLINEUP) updates reference data relationships; for example, when you submit a budget but the child data source has changed. You typically run this process overnight. For reference data relationships, the process synchronizes data between related activities.

  See Understanding the Model Recalculation Process.

Workflow Relationships

If you do not define a workflow relationship for activities, the system automatically defaults the workflow relationship to None. If you define a workflow relationship as Approval Includes, the system understands there is a relationship between two or more activities.

The workflow relationship for asset and position activities using Approval Includes is typically used in conjunction with the Insert Data option for data relationships. A workflow relationship is not required, but optional for those activities having Insert Data for data relationships. There are distinct differences between those activity relationships that also have Approval Includes, and they are as follows:

• Child activities are part of the defined workflow, and are controlled by the parent activity.

• At the preparer level, activity relationships share data across the corresponding version.

• You can only use the Approval Includes feature with child asset and position activities.

  You cannot establish Approval Includes relationships between line item activities.

The system uses the following rules and runs the following audits when handling Approval Includes workflow relationships:

• You must define an account dimension and a planning center dimension for each activity.

• You must define both activities as sharing the same planning center dimension and members.

  This is because only the parent activity controls the workflow; the child activity has no workflow.

• You must define the planning center dimensions at the same level for each of the Approval Includes-related activities, to enable the workflow functionality to run concurrently.

  Any other dimensions can be the same or different between activities. However, when activities share the same dimension, the child dimension members must be at the same level or at lower levels.

• You can define different security groups for the individual activities.

  However, you must define the activities to share the same planning center dimension and level as the child activities have no defined workflow. In this situation, the system directs workflow at the parent level to control security access.

• Specific version and submission rules for preparers:

  Note. These version and submit rules apply only at the preparer level. For all child activities (assets and positions), the system performs data entry and update only at the preparer or lowest level of preparation. Once the preparer has submitted the budget, roll up level users (such as reviewers and analysts) can make adjustments and allocations through the parent line item activities.

  • For preparers, the parent activity is the only activity that has the submit actions available on the My Planning Workspace.

    This means preparers cannot submit their budget plans through the child activities.

    For example, when a position activity is defined as an Approval Includes workflow relationship to a line item activity, the budget submission occurs through the workspace for the line item activity; the system then includes position data totals in the line item and disables any edit or update options for both activities.

    It also means you cannot submit different versions across the parent line item activity and child position. A submission of version 1 will also submit version 1 of the child activity when they are related through workflow.

  • When preparers submit a parent activity, the system displays a message verifying that the user does want to submit the parent activity and all associated child activities.

    If not, the user can cancel the submit action.

  • For those users who review the preparers' submitted activities, a reject action rejects all the workflow related activities together.

  • When preparers use the workspace copy functionality, the copy can only occur at the parent activity level, and the system creates the corresponding version for any associated child activities.

Activity Relationship Examples

This section discusses:

• Reviewing a scenario with line item, asset, and position activities.

• Reviewing a scenario with three line item activities.

• Reviewing a scenario with five activities.

• Reviewing pessimistic and optimistic scenarios with activities.

• Reviewing bottom-up and top-down comparison scenarios.

Reviewing a Scenario with Line Item, Asset, and Position Activities

Example A illustrates a basic scenario: one scenario that includes one each of the three activities. This is a bottom-up scenario type, having one asset and one position child activity to a parent line item activity. The example makes use of only two activity relationships, namely Data Inserts and Approval Includes. Note the following important activity rules:

• One line item activity can only have one position child activity.

• One line item activity can only have one asset child activity.

• When using workflow, all child activities can have only one workflow relationship.

• Asset and position activity types can never be parent activities—they can only be child activities.

• You cannot enable workflow between two line item activities.

  Workflow occurs only in scenarios involving asset and position activities.

• When using workflow, all planning center dimensions must share the same level, and child activities must share the same planning center dimension as that of the parent line item.

• For a child's activity data to update the parent's applicable line item rows, the line item account rows corresponding to data in the position and asset activity must use the POSBUD and ASSET method IDs, respectively.

Also note that the line item activity name is generic. This means a single line item activity captures all the revenue and expense impacts to the budget.

Example A: Scenario with line item, asset, and position activities

Reviewing a Scenario with Three Line Item Activities

Example B illustrates one scenario of three line item activities. This is a bottom-up scenario type that contains no asset or position activities. In scenarios comprised solely of line item activities, only data-type relationships—insert data and reference data—can exist between the line item activities. (This specific example only illustrates insert data relationships. However, one or both of the child line item activities could have a reference data relationship.)

Based on the defined relationship rules, there are two child activities inserting data into one parent line item activity. In addition, there is no workflow relationship as you cannot enable workflow between line item activities.

For data to be updated in parent line item activity from the child activities, the account rows corresponding to data must use the LINEITEM method ID.

Example B: Scenario with three line item activities

Important! Be aware that consolidation activities in the same scenario have certain considerations when you export data back to the budget ledger.

See Considerations for Using Consolidated Line Item Activities Within Scenarios.

Reviewing a Scenario with Five Activities

Example C illustrates one scenario of five activities: one asset activity, one position activity, and three line item activities. This example shows how you can have two line item activities (such as one activity related to expense using department as its planning center dimension, and a second activity based on revenue using product as the planning center dimension) that insert data into a parent activity. This parent activity in turn uses higher dimension levels to create a consolidated activity (such as for income statement reporting), and this consolidated activity combines all the expense and revenue activities. In particular, note the calculation dependencies between the child line item activities.

Note the following activity rules:

• Each of the three line item activities uses a different planning center dimension, but the two child line items need to use operating unit as an additional dimension in order to be picked up by a parent line item that uses operating unit as its planning center dimension.

• For the expense and revenue data to be inserted into the consolidated line item activity, use the LINEITEM method ID on each corresponding account row in parent line item activity.

• For calculation dependencies between expense and revenue, these two line items have a References Data From relationship.

  This means the expense activity has formulas (FLEX method ID) that require data from the revenue activity. You do not need to define this type of relationship (References Data From) if the data required for the formula exists within the same activity.

• Because the position activity is not defined as having a workflow relationship to its parent line item, it can use a different planning center dimension than the parent.

  The position activity would still need to use the department dimension as one of its additional dimensions when preparing the position activity budget (for example, you would treat the parent's planning center dimension as a required dimension of the child activity, otherwise the data has no place to go).

• The asset activity has the same planning center dimension as the parent activity, but only has a data inserts relationship.

  Alternatively, since the asset activity does have the same planning center dimension as the parent activity, you could include the workflow relationship to the parent line item activity.

Note. The system automatically prevents you from creating circular references between expense and revenue accounts when you set up relationships.

Example C: Scenario with five activities

Important! Be aware that consolidation activities in the same scenario have certain considerations when you export data back to the budget ledger.

See Considerations for Using Consolidated Line Item Activities Within Scenarios.

Reviewing Pessimistic and Optimistic Scenarios with Activities

Example D illustrates two scenarios each with three line item activities. The dotted line separates the two scenarios. Like Example B, these are bottom-up scenario types that contain no asset or position activities. The line item activity names are similar between the two scenarios, except one scenario tracks an optimistic outcome, and one scenario tracks a pessimistic outcome.

When creating similar planning and budgeting scenarios (BP_SCENARIO) within your scenario group (BP_SCENARIO_GRP) that have the same attributes for time, ledger, and calendar, you should assign a unique GL scenario to the planning and budgeting scenario. This will differentiate the two unique scenarios when the data is exported back to the budget ledger.

Because both scenarios use the same three line item activity definitions from the activity group, all line item activities with the same name across scenarios share the same selected dimensions, planning center dimension, trees, and members. Only the dimension level (when using a tree for dimensions) can be controlled at the unique activity scenario level in the planning model.

Example D: Optimistic scenario with activities

Example D: Pessimistic scenario with activities

Reviewing Bottom-Up and Top-Down Comparison Scenarios

Example E illustrates two different scenarios and five activities. The dotted line separates the two scenarios. The first scenario is a top-down scenario type having one activity. The second scenario is a bottom-up scenario type having two line item activities, one position activity, and one asset activity.

What makes this activity different from the previous four examples is the use of a top-down scenario in conjunction with a bottom-up scenario. A top-down scenario typically prepares plans at a much higher level—dimension and/or time—than that of the bottom-up scenario (which is where the lowest level budgets are typically prepared and tracked). When using these two scenarios together in the same scenario group, you may use the top-down scenario as a target to budget up to when working with the bottom-up scenario. While working in your line item activity for the bottom-up scenario, you will be able to compare your budget revenue or expense to those planned in the top-down scenario (referred to as planning targets).

Note. Typically there is a business process around the order in which these two scenario types are used. For example, preparation of the top-down plan must be complete before it can be used as a planning target by the bottom-up budget.

See Setting Up Planning Target Rules.

See Working with Methods.

Example E: Bottom-up and top-down comparison scenarios

Scenario Relationships and Activities

Be aware of the following relationships and dependencies between scenario relationships and activities:

• Activity relationships cannot cross scenarios.

  When the system brings together activity relationships in the planning model at the scenario-activity level, these relationships are restricted to within the same scenario. This means that the relationships established in the Activity Group page will apply to all nonhistory scenarios in the scenario group. Some relationships are not allowed, such as:

• Forecast scenario types do not allow the use of position and asset activity types.

• Top-down scenario types do not allow the use of position and asset activity types.

• Scenario groups that are defined as a project budget ledger Budgeting Type allow only line item activity types.

  Note. The system enforces the above rules when it creates the activity scenarios within a planning model.

• The system assumes that time and periods are the same across all activities for the same scenario.

  The system handles the top-down scenario differently from other scenarios when used in conjunction with a bottom-up scenario. (It is also known as the target scenario (or planning targets) when used with the bottom-up line item activity scenario.) You define this relationship of planning target and control information on the planning model's Data Source page, the same page where you select the seed data.

  You do not have to use top-down and bottom-up scenarios together. This is optional. You can use the different scenarios independently of one another.

• You must establish planning targets for a fiscal year—this means you must define the target scenario for a single period (or annual calendar). The system does not compare or sum up quarterly planning targets to calculate a fiscal year total.

Activity Versions

Activity versions have a relationship independent of the related activities. Note the following system behavior:

• For activities defined with the Approval Includes workflow option, the system ensures that they share the same corresponding versions as the parent activity.

  Also note the following consideration for these relationships:

  • The Approval Includes relationship shares the same versions across all activities.

    For example, when you submit a parent activity that has a child activity defined with an Approval Includes workflow relationship, the version submitted at the parent activity level includes the same version of the child activity.

  • You may only perform the version copy functionality at the parent activity level, and the system creates the corresponding version for any associated child activities.

  • When you submit a parent activity, the system automatically submits the child activity.

• For activities defined solely as Insert Data with no Workflow relationship, the system uses the child's master version as the data source for the parent version.

  This means the child activity must either submit or copy a version to master to provide the most current source data.

• For activities defined with a calculation dependency when using flexible formulas between line item activities, the system uses the master version as the data source.

  The master version is also used as the source data when flexible formulas cross multiple planning centers within the same activity.

  The master version is also used as the source data when flexible formulas cross different activities.

  When the source for the formula is contained within the same planning center or slice of data, it will use the data within the version being worked on.

• For insert data relationships, the system uses data from the master version as the source data for all versions.

  Because of this, when two activities are being prepared simultaneously the insert data may not be available, or may not be current. However, if you define the Approval Includes workflow relationship for an insert data relationship, the system does not use master. In this situation, the system inserts data across versions at the preparer level.

• For insert data relationships, once preparers submit asset and position activity types, roll up users (users assigned as reviewers and analysts to the roll up planning center) cannot edit the asset or position data, and can only access the data in read-only mode.

  At the roll up planning center level, copying a version from the master version to a working version still displays the same data, and the working version data is still not editable for asset and position activities.

  In the line item activity, reviewers and analyst can make adjustments to the line items.

• For reference data relationships, the system uses data from the master version as the source calculation data for all versions. For that reason, when two activities are being prepared simultaneously the source calculation data for the one may not be available, or may not be current.

  Note. In all cases, the base version is never impacted by formulas or related activity calculations; whatever is staged for any activity remains intact. For line item activities, the data seed is selected as the data source (any line item activities will not reflect any impacts from related activities). The Base version for asset and position activities will also reflect the original amounts as they existed from the tables sourced during staging.

• Specific version and submission rules for reviewers and analysts:

  • As stated above, reviewers and analysts make allocations and adjustments through line item activities.

    This means that any roll up planning center only works in one activity and only requires access to this one activity. Users at this roll up level can still drill down for details.

    For example, asset and position activity details are the same for all working versions and master version at the roll up level, and reviewers and analysts at this roll up level cannot change the data as it is in read-only mode.

    To change the data details, reviewers and analysts must reject the budget down to the preparer level. Otherwise, they may only apply adjustments and allocations in the line item activity against the aggregated detail information.

  • When the roll up planning center level rejects a budget at the preparer level, the system makes all parent and child activities available again when workflow is enabled. When preparers resubmit at the parent activity level, parent and child activities are resubmitted together, as previously discussed.

Considerations for Using Balance Sheet Planning

A flag on the Activity page, Includes Balance Sheet Planning, allows you to indicate whether the line item activity uses balance sheet accounting. If the flag is checked, then the system looks up every account in the activity to determine its account type. If the account type specifies that this is a balance forward account, then the system displays and stores a starting balance (also known as period 0) for the account. Likewise if a statistical account is flagged as a balance forward account, then the system displays and stores a starting balance for the statistical account.

Balance sheet planning stores a starting balance, and transactional amounts for each budget period. You can view through analysis reports the summary or aggregate time periods, such as quarters and years, which display the sum of the changes in the underlying periods. For example, if you have ten people in January and you plan on hiring two more in February, then Planning and Budgeting stores two (the transactional amount) for the month of February.

Balance sheet planning uses an additional time period in which is stored the starting balance. There is only one starting balance for a line item account row, even for a multiyear model. In a two-year model, for instance, there is one starting balance which precedes period 1 for the first year, while the starting balance for the second year is the ending balance for the first year.

Considerations for Using Consolidated Line Item Activities Within Scenarios

Carefully consider your use of line item activities that represent consolidated data from other line item activities within the same scenario. When all of these line item activities are stored under the same Planning and Budgeting scenario ID, they share all the same attributes, such as time, ledger, calendar, and general ledger scenario. Because they have all these attributes and fields in common, when you complete your activity and export the data back to the budget ledger, all the data is stored with all these attributes at the levels in which you prepared them.

The following three tables illustrate an example of three line item activities within one unique scenario, and represent the data rows stored within the activity that the Planning and Budgeting system exports to the budget ledger. In all cases it is an annual budget for 2008 (as all activities for one scenario only contain one element of time – annual calendar). The three line item activities include a detail expense budget, a detail revenue budget, and a consolidation activity as a place to review all the line item data together, in one activity. The three tables represent the underlying data that the system stores with the three activities.

The first two activities budget at the same dimension levels, primarily at a detail level to synchronize with the storage and data retrieval method used by the PeopleSoft General Ledger or third-party general ledger application.

The third activity—the consolidation or income statement—summarizes the majority of its dimensions (with the exception of operating unit). The system tracks net expense and revenue amount details by operating unit, and does not include department and product details, which are unnecessary in this calculation. The intent of the third activity (in this case) is to track, report, and provide an overview of the data as the budget process progresses; it may also be used for future strategic planning. However, it is not the intent of the third activity to transmit information to the General Ledger, as the general ledger system does not store information at the roll up or summarized dimension levels.

We can use the tables to illustrate another example. If (when you complete the budgeting preparation process) you export the data into the budget ledger, the system stores all the rows in all three tables under the same time, ledger, and scenario. Running a report against this budget ledger produces duplicated amounts, because the system stores the detail values and the summarized values in the same location.

Important! Be aware that the way you define activities and their associated dimensions and members is entirely your responsibility. The system does not prevent you from using overlapping dimensions and members when establishing dimensions and members for line item activities; the same accounts and departments can be in multiple places and at the same level of detail when using the same dimension and members. As you can establish activities for data consolidation and reporting, the system has no validations to prevent any overlapping activities and data.

We recommend that when you use multiple activities, especially those that are consolidation activities, you place a business process around each activity and define the purpose of the activity. For example, referring back to the three tables above, you may plan to only export back to your general ledger application (in your organization's financial system) the two detailed activities, expense and revenue. This is normal, as you typically prepare bottom-up budgets at the level in which they are tracked and stored in the source financial system. For the consolidated activity that you do not send back to the general ledger system, here are some suggestions:

• Disable the Export to GL flag on the Activity page for activities used as consolidated activities.

  Disabling this flag for a consolidation activity will prevent the budget data from being exported back to the General Ledger, although the activity data can still be combined with other activities in the Enterprise Performance Management budget ledger for purposes of tracking, reviewing and reporting the budget data.

• Never use the export process to send this activity's data back to the budget ledger in the EPM Warehouses.

  In this case, the activity may only be used for tracking, reviewing, and reporting as the budget process moves along. It is used as a consolidated view of the budget results that a select group of users or administrators of the budget will use.

• If you export the data back to budget ledger in the EPM Warehouses, be sure and take advantage of the Override GL Scenario option on the Export to General Ledger run control page.

  Then select the new GL scenario ID you want to use to store it in a different location in the budget ledger from the other data. The general ledger scenario field makes this third activity's data unique compared to the first and second activities, which require that their data be not only exported back into the warehouse, but also to the general ledger in the Financial system.

Prerequisites

Prior to defining activities, you must ensure that you have correctly set up the Dimension Configuration page (BP_CF_MAINT). Values established here determine the global set of dimensions available to the Planning and Budgeting application. Make sure to also activate any dimension in the underlying relational tables and subrecords that are not delivered as active. Due to some database restrictions, not all dimensions can be delivered as active.

See Also

Configuring Dimensions for Planning and Budgeting

Entering Historical Scenario Economic Assumptions