Understanding Planning and Budgeting Activities

This chapter introduces the main concepts of planning and budgeting activities. It gives prerequisites and discusses:

• Activities.

• Activities relationships.

• Scenario relationships and activities.

• Activity versions.

• Considerations for using consolidated line item activities within scenarios.

Prerequisites

Prior to defining activities, you must ensure that you have correctly configured the Dimension Configuration page (BP_CF_MAINT). Values established here determine the global set of dimensions available to the Budgeting and Planning application.

Activities

This section discusses:

• Line item activities.

• Position activities.

• Asset activities.

General Information about Activities

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

In Budgeting and Planning, 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 you require.

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

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

We deliver three predefined planning and budgeting activity types: line item, position, and asset. You select these activity types 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 you can define them 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 a defined relationship, the child activity must require using the parent activity's defined Planning Center dimension.

You can also cluster activities into an activity group. This is a collection of activities and the 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, which 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.

• 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 could define that all Dimension Member IDs from 100 to 500 map to Dimension Member ID 600. This mapping is also applicable to all scenarios associated to 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 you use on the activity group page determines all valid dimension trees and members for the planning model it is assigned.

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

See Activities Relationships

See Also

Establishing Activities and Activity Groups

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 warehouse. 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 warehouse, which can then be exported back to your source general ledger system.

Line item activities are the most user-definable of the activity types. 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.

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 you can be working 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.

• The position and employee's expense in the position activity can be shared across more than one Planning Center budget.

• Position activities are not sourced from a ledger. But the expense impact can be, when the position activity is a child of a line item parent activity.

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: on depreciation accounts and asset accounts and optionally, on the cash accounts. Asset activities may also potentially have impact on 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 the expense and cost impact can be, when the asset activity is a child of a line item parent activity.

Activities Relationships

This section discusses:

• Activities relationships in general.

• Activities relationship dependencies.

• Data relationships.

• Workflow relationships.

• Activities relationship examples.

Activities Relationships in General

Note the following points about activities 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. But only one line item can be workflow related.

• 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 activities relationships on the Relationships page (BP_ACTV_DEPEND) of the Activity Group component.

• You can define asset and position activities 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 a valid option for asset and position activities.

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

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

  • References Data From with no data inserts option.

    Note. The Approval Includes option is not a valid option 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 together for reporting, such as top-down to bottom-up plan comparisons.

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

    Note. For any other situation but the three noted situations, associating an account dimension is optional.

Activities Relationship Dependencies

You can define calculation and procedural dependencies between activities to ensure the system performs the calculations and approvals in the desired, correct 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 and used by a defined Flexible Formula. You only use this relationship 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 ID's in the line item activity, to identify the location of data required for calculating formulas.

• The Approval Includesdependency 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 stay 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.

  • Preventing 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 are 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 checkboxes for staged activities.

See Also

Establishing Activities and Activity Groups

Data Relationships

This section discusses:

• Insert data.

• Reference data.

Insert Data

An insert data relationship between two activities means that the systems 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 here, 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 the same level or lower levels of the tree.

• The Model Recalculation Application Engine process (BP_MDL_CALC) handles updating insert data relationships, such as 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 that do not currently exist.

  See Understanding the Model Recalculation Process.

Reference Data

The data relationship of reference data (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 items required for calculating 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) handles updating reference data relationships, such as 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 these activities defined as Insert Data for data relationships. There are distinct differences between those activities relationships that also include Approval Includes definition, and they are as follows:

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

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

• You can only use the Approval Includesfeature 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 as the child activities have no defined workflow. In this situation, the system directs workflow at the child level to control security access.

• Specific version and submission rules for preparers:

  Note. These version and submit rules apply only to the preparer level. For all child activities, the system performs data entry and update only at the Preparer or lowest level of preparation. Once the Preparer has submitted the budget, rollup 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, which the system then includes position data totals in the line item and disable any edit or update options for both activities.

  • 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 functionality also creates the corresponding version being created by the action for any associated child activities.

Activities 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 only occurs 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 the system to insert new rows, the rows must not already exist in the parent. 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.

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 not already exist in the parent, and the rows must use the LINEITEM Method ID.

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.

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 examples 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, which 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 interrelationship between the child line item activities.

Note the following activity rules that would apply:

• Each of the three line item activities uses a different Planning Center dimension, but the two child line items would need to use operating unit as an additional dimension in order to be picked up by 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 would 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 require dimension of the child activity, otherwise the data has no place to go).

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

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 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 here 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) which 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, each line item activity with the same name across scenarios share the same selected dimensions, Planning Center dimension, trees, and members. Only the dimension leveling (when using a tree for dimensions) can be controlled at the unique activity-scenario level in the planning model.

Optimistic Scenario with Activities

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 that 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 typically the lowest level budgets are prepared and tracked). When using these two scenarios together in the same scenario group, you may use the top-down scenario as a target in which 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 such 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.

Bottom-Up and Top-Down Comparison Scenarios

Scenario Relationships and Activities

Be aware of the following interrelationships and interdependencies between scenario relationships and activities:

• Activities relationships cannot cross scenarios. When the system brings together activities 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 non-history scenarios in the scenario group that apply. 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 now allow the use of position and asset activity types.

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

  Note. The above rules for activity-scenario combinations is prohibited by the system when the planning model is created. You will never see such activity-scenario combinations created in your 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, on the same page that you select the seed data.

  Top down and bottom up scenarios do not need to be used together, by providing a planning target for another scenario. This is optional. The different scenarios can be used independently of one another.

• You must establish planning targets for a fiscal year—this means you must define the target scenario to use a single period (or annual calendar). The system does not compare or sum quarterly planning targets together 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.

  • 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.

• 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 uses a different version source than 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, rollup users (users assigned as reviewers and analysts to the rollup Planning Center cannot edit the data, and can only access the data in read-only mode. At the rollup 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 users.

• For reference data relationships, the system uses data from the master version as the source calculation data for all versions. Because of this, 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, it is the data seed 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 rollup Planning Center only works in one activity and only requires access to this one activity. Users at this rollup 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 rollup level, and reviewers and analysts at this rollup 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 rollup Planning Center level rejects a budget at the preparer level, the system makes all parent and child activities available again. When preparers resubmit at the parent activity level, parent and child activities are resubmitted together, as previously discussed.

Considerations for Using Consolidated Line Item Activities Within Scenarios

This section discusses considerations for using consolidated line item activities within a single scenario, and the impact of exporting this consolidated data to a ledger.

Important! 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 Budgeting and Planning system exports to the budget ledger. In all cases it is an annual budget for 2006 (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 rollup 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 solely 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, that 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 a at the level in which they are tracked and stored in the source financials system. For the consolidated activity that you do not send back to the general ledger system, here are some suggestions:

• Never use the export process to send this activity’s data back to the budget ledger in the warehouse. 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 warehouse, be sure and take advantage of the Override GL Scenario option on the Export to General Ledger run control page. Then select the new 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 activities data unique compared to the first and second activities, which require their data not only to be exported back into the warehouse, but also to the general ledger system in Financials.

See Also

Entering Historical Scenario Economic Assumptions