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.
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.
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.
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.
Image: Example A: Scenario with line item, asset, and position activities
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.
Image: Example B: Scenario with three line item activities
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.
Image: Example C: Scenario with five activities
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.
Image: Example D: Optimistic scenario with activities
Optimistic scenario with activities
Image: Example D: Pessimistic 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 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 Understanding Planning Targets for Bottom-Up Scenarios.
See Working with Methods.
Image: Example E: Bottom-up and top-down comparison scenarios
Bottom-up and top-down comparison scenarios
