Staging Scenarios and Activities in a Planning Model
This section provides overviews of:
The steps to stage activities and scenarios in a planning model.
The data staging process.
Model Validator rules.
How to view dimension exceptions after data staging.
How to view dimension members after data staging.
This section also lists prerequisites and discusses how to:
Stage data for scenarios and activities in a planning model.
Run the Model Validator.
View the results of the model validation process.
Verify dimension exceptions after the data staging process.
Verify model dimension values from the data staging process.
View user access to line items and to line item details.
Pages Used to Stage Scenarios and Activities in a Planning Model
|
Page Name |
Definition Name |
Navigation |
Usage |
|---|---|---|---|
|
Data Staging |
BP_STAGE |
|
Import and stage data for planning model activities and scenarios. |
|
Model Validation |
BP_MODEL_VALIDATOR |
|
Validate components of a planning model. |
|
Model Validation Report |
BP_MDLVAL_LOG1 |
Planning and Budgeting, Planning and Budgeting Setup, Process Model, Model Validator Report |
Review Model Validator results for a given planning model activity scenario. |
|
Dimension Exceptions Inquiry |
BP_CF_EXCEP_INQ |
|
Inquire about dimension members that are flagged as exceptions during the data staging process. |
|
Dimension Member Inquiry |
BP_CF_VAL_INQ |
|
Inquire on dimensions and members that are associated with the planning model for a scenario activity. |
|
User Access to Line Items |
BP_UAXS_LI_HDR |
|
Review the staged data and investigate nonsubmissible planning centers. |
|
User Access to Line Items Details |
BP_UAXS_LI_DTL |
Click the Details icon on the User Access to Line Items page. |
Review the staged data and investigate nonsubmissible planning centers. |
Understanding the Steps to Stage Activities and Scenarios in a Planning Model
When you run the complete data staging process for an activity scenario in a planning model, the system performs steps to:
Validate the model and locate any errors made during setup of activities and scenarios that you can correct.
Determine the dimension member list for all the dimensions used.
Map dimension values to target values on the Dimension Member Mapping page.
Mapping occurs for both seed and historical data.
Generate the base version for the budgeting activity.
Validate combinations of dimension members for any line-item activity scenario detail when enforce budgets is enabled.
Report invalid ChartField (dimension) values.
Report ChartField (dimension) values that are found in the source ledger for a line item activity, and not included in the planning model.
Seed the activity scenario detail with amounts from the source aggregating the source amounts to match the level at which the budget activity is being performed.
Reverse the sign associated with the account type amounts as defined on the Account Type Options rule for line item activities.
Convert seed and historical amounts to the base currency of the business unit/model when the amounts are in a currency that is not supported by the planning model.
Generate future currency exchange rates for the set of currencies supported within the model.
Copy the completed base version for the activity scenario to the master version.
Perform a model recalculation and then create the first working version at the preparer level.
Generate the worklist entries for reviewers.
Note: The system supports any additional incremental staging processes.
Understanding the Data Staging Process
Data staging uses application engine processing that places source data into tables used by your activities for the preparation of plans and budgets by users in PeopleSoft Planning and Budgeting.
General Processing Details
During the data stage process, the following rules apply:
The system considers dimension summarization definitions that you set up using the Dimension Level Summarization page to bring lower-level dimension values to a level consistent with the tree level defined for the activity/scenario in the planning model.
If you are summarizing dimension values to a higher level on the tree, the account types for the monetary dimension values are ignored. That is to say, you could be adding expense accounts to revenue accounts if they both exist at the tree level to which you are aggregating.
If your tree contains different levels for statistical accounts, dimension summarization will also occur during stage if you have chosen to plan at a higher level. When this occurs, the aggregated amount may not be very meaningful because the processing does not consider the different units of measure for detail statistical accounts. That is to say, no validation occurs on the unit of measure or the tree level.
If the higher dimension value (or node) to which you are summarizing is a monetary account type, it will not include or add any statistical accounts or amounts. The same applies if the higher dimension value is a statistical account—the aggregated total will not include any monetary accounts or amounts.
The system considers dimension mapping or conversion definitions that you set up using the Dimension Member Mapping page in the activity group to map dimension values in the planning model for all activity data.
When staging existing in-service asset, position, and line item data, the system recognizes these mapping rules defined on the Dimension Member Mapping page in the activity group.
The system determines valid dimension values based on the as of date in the activity group that is associated with the model.
Data that is not staged populates the Dimension Exception Inquiry table for review by the coordinator.
The Flip Sign setting that you determine for account types using the Account Type Options page applies to line item ledger data.
If Flip Sign is selected, the system reverses the sign associated with the account type amounts. For example, if you store revenue account type amounts as negative values in the imported ledger, and you select Flip Sign for revenues, the system changes the amounts from negative to positive numbers within the staging table. When the system stages to the planning model, you view revenues as positive numbers.
Note: Assets and positions staged from existing source data, such as PeopleSoft Asset Management and PeopleSoft Human Resource Management, ignore the flip sign option. This also applies to statistical account types—they ignore the flip sign option.
For statistical account types staged to line item activities, the system does not allow a value in the currency code fields or statistical code field.
If values are in either field, the data is not staged.
For statistical codes staged to line item activities, the system does not allow a value in the currency code field.
If a value is in this field, the data is not staged.
For in-service assets with values that are missing for the dimension used as the planning center, the asset and depreciation rows are dropped and not processed during data staging.
Only assets that have a depreciation impact on the proposed budget, as defined by the scenario, are retrieved from the source tables.
For existing job data with values missing for the dimension used as the planning center, staging references the defaults specified using the Map HR Depts to Planning Centers page, along with the position's human resource department, to populate the planning center dimension value.
If the information is unavailable and the dimension value is still missing, these distribution rows are dropped and not processed during data staging.
When you are using the Enforce Budget flag on a line item activity, dimension combination edits are performed using combination edit rules and controlled budget rulesets for a control budgeting type.
For multicurrency models, the system creates future exchange rate tables for the model, and conversion takes place on any transaction currency when the source is not defined as an entry currency using the Currency Option page in the planning model.
The system performs a copy of the analytic calculation engine (ACE) model and formulas for line item activities, and all drag-and-drop analysis reports for all three activity types.
The system creates the following versions: base, master, and version one.
Version one is created last because a model recalculation is performed against the master version before copying to the working version.
The system performs a validation for nonsubmissible planning centers prior to copying versions and model recalculation.
The engine issues a warning if nonsubmissible planning centers exist, which indicates that no user has access to all the line items in those planning centers. You need access to all line items in a planning center to submit it. Use the User Access to Line Items page to review which users have access to which line items in those planning centers. To resolve this issue, you could perform one of these tasks:
Give the user access to the offending line items using the Secondary Security Group page.
Exclude these line items from the budget, for example by filtering out problematic dimension members in the activity group, and restaging.
Remove the secondary security group from the activity scenario.
The system generates a workspace list for each activity in the scenario to enable user access to plans and budgets.
Run the data staging process from the Data Staging page.
Balance Sheet Planning Processing Details
The staging process picks up the starting balance, period 0, and the following conditions apply:
If the activity is flagged to support balance sheet planning, the system creates a new row with a value of 0 for any line items that do not have a row for the starting balance in the source tables.
This applies only to account codes that have the balance forward flag enabled, as indicated by their account type.
If the activity is not flagged to support balance sheet planning on the Activity page, then the starting balance row is not staged, even if the account on the line item is a type that supports balance sheet planning.
On the Data Source page, you can specify a multiplication factor that is applied to the data source as the starting value.
This enables you to create a budget that is, for example, 10 percent greater than the previous year.
The defaults on the Account Type Options page are referenced for the flip sign logic.
Because an account type indicator determines these rules, the flip sign logic is global by account type. For example, data that is stored in PeopleSoft General Ledger typically has the asset and expense accounts stored as positive values, whereas the liability, equity, and revenue account types are stored as negative values (this supports the debit/credit logic of a ledger). The system flips the negative signs so that you can enter budgets as positive values.
When the budgets are exported back to the source ledger and General Ledger staging tables, the system reverses the signs, depending on the Account Type Options rule for data stored in the ledger.
The system includes period 0 (starting balance) for the dimension summarization at a roll-up level only if the account balance forward attribute is set at the node roll-up level.
For example, if you prepare a top-down plan at level 2 node, and that account node does not have the balance forward indicator, any child values that are aggregated in the roll up will not include the starting balance.
Understanding Model Validator Rules
Model Validation is an application engine program that ensures that the activity scenario rules are set up accurately in the planning model prior to staging. It validates the model for activities, activity groups, related activities, scenarios, security groups, dimensions, dimension levels, calendars, default accounts, multicurrency options, and so on. The data staging process assumes that data is prepared and valid. Rather than performing exhaustive error handling throughout the staging process, this separate process validates the setup for a scenario and activities in the planing model.
The model validation process can be called from within the staging process, but users can also run model validation outside of the larger staging process to identify setup errors prior to running the data stage process to help validate setup as you go. This process can be run at any time during the model creation process, not only when it is complete. You should run the validation process any time that you make a change to a model.
Results of the model validation process are displayed on the Model Validation Report page. For a list of model validation errors, select and look up messages under the Message Set Number 9370, mostly in the range of message numbers 380–430.
These are some of the rules that are checked by the model validation process:
The account dimension must be selected for every activity.
The tree setID for the dimension must match the setID defined for the dimension table.
The following items must be defined and valid: activity group, security group, calendar periods for scenario ranges, currency options, source scenarios, comparison scenarios, target scenario.
The security group associated with the activity must be active and valid.
A period map must be defined for all comparison scenarios associated with the activity and planning scenario, and a period map must be defined for all source scenarios associated with the activity and planning scenario.
Position and asset activity types must have at least one default account defined.
The planning center dimension between an activity and its approval includes activity must match.
Only line item activity types can have activity relationships defined.
Other types of activities can be referenced only within a line item activity.
An activity must not contain more than one related position activity or more than one related asset activity.
All the calendars associated with the individual scenarios within the scenario group must be included in the time hierarchy.
The approval dimension hierarchy must match security group hierarchy for an activity scenario.
The approval dimension hierarchy level must match the security group hierarchy level for an activity scenario.
The dimension summary level for the planning center must match the level in all the related activities if the relationship is Approval Includes.
The planning center dimension of the primary activity must exist on related activities if the relationship is Includes Data From or References Data From.
The activity dimension hierarchies must be valid and active trees.
The activity dimension levels must be at or higher than dimension levels of any related activity.
The target scenario dimensions must be at or above the level of planning scenario dimensions.
The level specified for the security group hierarchy must exist in the tree.
Planning Center must be a selected dimension.
Activity must exist in activity group, and scenario must exist in scenario group, associated with model.
If you are using the Commitment Control budget type, then no activities in the activity group allow balance sheet planning.
You must either disable the balance sheet flag on the activity, or remove the activity from the activity group.
The target scenario calendar must have one period per year.
The level specified for a dimension must be in the version of the hierarchy that matches the as of date of the activity group.
The business unit for the model must be assigned to the ledger associated with the planning scenario.
Understanding How to View Dimension Exceptions After Data Staging
After you resolve any dimension exceptions, run the data staging process again. Repeat these steps until you are satisfied with the data in the staging tables that you then release by activity scenario in the planning model for access by end users.
When you run the data staging process, the system verifies and selects valid dimensions, members, and trees defined by the activity and activity group against the detail data sources for sourcing/seeding the base budget amounts. For example, if you defined a department dimension, for which your as of date is 01/01/2006 for the activity group, the system uses this information to validate each dimension value against the source data that is used as the source to seed the budget. For example, it uses this information to verify that the following conditions are met:
If a dimension member is invalid and a row exists in the ledger/source, an Invalid Dimension appears in the Exception column.
If ledger/source data for a dimension member is not defined by the activity, then a Missing From Dimension message appears in the Exception column.
The following list contains the possible dimension exceptions that may appear on this report:
- Invalid statistical account found in scenario for planning center period/fiscal year (scenario, planning center, and period/fiscal year will be indicated).
- Invalid statistical account found in scenario for planning center budget period (scenario, planning center, and budget period will be indicated).
- Member not defined for the dimension.
- Missing from the dimension selection.
- Asset crosses multiple planning centers.
- This depreciation account is not in the dimension.
- Member not found in the dimension hierarchy.
- Child member account is not the same account type as parent/node account.
Use the Dimension Exception Inquiry page to view dimension exceptions that are generated during the data staging process.
Note: Even if exception rows show up in your Dimension Information grid, the may not necessarily indicate errors. For example, you may have defined the activity dimension rules to exclude the data on purpose.
Understanding How to View Dimension Members After Data Staging
The set of valid members for each dimension for the activity scenario are available using the Dimension Member Inquiry page. The Data Staging processes must check the dimension value set definition for each dimension for the scenario/activity being staged and determine the set of valid detail dimension member IDs. This list of detail dimension members will be used to seed the activity details with data from the source ledger. Additionally, the valid dimension members are stored in a table that is used for the prompt views for the dimension on the activity entry pages.
Use the Dimension Member Inquiry page to review and verify that the dimensions and members that are staged and used to select, seed, and prepare activity scenarios are those that you expect.
Prerequisites
Before staging activities and scenarios in the planning model:
User roles must be set up properly.
Typically, the coordinator performs the steps to set up and stage the planning model.
Hardware capabilities must be evaluated.
Consider evaluating your hardware capabilities before using parallel processing to run the data staging process. If you are using hardware that does not have sufficient CPU capacity and memory to run parallel processes, your processing performance will not be improved.
Planning model setup must be reviewed and complete.
Review your planning model setup before staging because some of your definitions will not be available to update after you stage an activity scenario in the planning model, such as selected activity dimensions, scenarios, and multicurrency options.
Data Staging Page
Use the Data Staging page (BP_STAGE) to import and stage data for planning model activities and scenarios.
Image: Data Staging page
This example illustrates the fields and controls on the Data Staging page. You can find definitions for the fields and controls later on this page.
Model Validation Page
Use the Model Validation page (BP_MODEL_VALIDATOR) to validate components of a planning model.
Image: Model Validation page
This example illustrates the fields and controls on the Model Validation page.
Enter the appropriate values in the Business Unit, Planning Model ID, Scenario, and optionally all or one Activity field to define the model that you want to validate.
You can run the Model Validator on its own any time. This includes during the setup of the planning model, during the staging process, or even after activities and scenarios have been released to end users. In this last case, you would run this when you have made some setup changes that might affect available activity scenarios.
See Data Staging Page.
Model Validation Report Page
Use the Model Validation Report page (BP_MDLVAL_LOG1) to review Model Validator results for a given planning model activity scenario.
Planning and Budgeting, Planning and Budgeting Setup, Process Model, Model Validator Report
Image: Model Validation Report page
This example illustrates the fields and controls on the Model Validation Report page.
This page displays the results of the model validation process by activity scenario. Click the planning model link to go to that planning model page.
Dimension Exceptions Inquiry Page
Use the Dimension Exceptions Inquiry page (BP_CF_EXCEP_INQ) to inquire about dimension members that are flagged as exceptions during the data staging process.
Image: Dimension Exceptions Inquiry page
This example illustrates the fields and controls on the Dimension Exceptions Inquiry page. You can find definitions for the fields and controls later on this page.
The system searches and retrieves dimension exceptions related to the type of activity—asset budgeting, line item budgeting, or position budgeting—and associated scenario.
The system reports an exception if any of the following conditions exist in the history data:
The account is identified as a statistic account and the currency code has a value or the base currency has a value.
The account is identified as a statistic account and the posted base amount contains a value.
The account is not identified as a statistic account but the statistic code field has a value and the base currency has a value or the currency code has a value.
The account is not identified as a statistic account, the statistic code field does not have a value, and the currency code is missing.
Dimension Member Inquiry Page
Use the Dimension Member Inquiry page (BP_CF_VAL_INQ) to inquire on dimensions and members that are associated with the planning model for a scenario activity.
Image: Dimension Member Inquiry page
This example illustrates the fields and controls on the Dimension Member Inquiry page. You can find definitions for the fields and controls later on this page.
The system searches and retrieves dimension values by an activity scenario in the planning model. Each dimension list by scenario will display the valid values that are staged and available for preparation by end users. This report is a result of the activity group and dimension level summarization rules that you have defined.
User Access to Line Items Page
Use the User Access to Line Items page (BP_UAXS_LI_HDR) to review the staged data and investigate nonsubmissible planning centers.
Image: User Access to Line Items page
This example illustrates the fields and controls on the User Access to Line Items page.
This page is read-only. It lists all the planning center versions within the selected activity scenario. It includes all levels within the planning center tree. The grid is sorted so that the nonsubmissible planning center versions appear at the top. The Status column shows whether each planning center version is submissible. The Submit Allowed? Column displays an explanation for the status. Use the Details icon in the grid at the row level to access the User Access to Line Items Details page. Use the link to navigate directly to the appropriate Secondary Security Group page.
Use the User Access to Line Items Details page (BP_UAXS_LI_DTL) to review the staged data and investigate nonsubmissible planning centers.
Image: User Access to Line Items Details page
This example illustrates the fields and controls on the User Access to Line Items Details page.
This page is read-only and shows which users have access to which line items within a planning center version. Use the link to navigate directly to the appropriate Secondary Security Group page.