Best Practices for the Design Walkthrough

Use these best practices to do a design walkthrough that will help you build and roll out your application.

Build Your Application

Start by building the foundation—your company’s accounts and organizational structure. Next, add scenarios to support your internal processes, such as Plan, Actual, and Forecast. Add the variance members you report, such as Actual vs. Plan.

Create forms that will be used to collect data from your users and to perform reviews, analysis, and reporting. To support your business logic, you can leverage Calculation Manager to build your calculations. You can also create reports and apply access permissions before rolling out your application to users.

Create the Application Structure

Add accounts, entities, and other dimensions to support your business process.

Dimensions categorize data values. Planning includes these dimensions: Account, Entity, Scenario, Version, Period, and Years. If you plan in multiple currencies, your application also has a Currency dimension.

You can use the Custom dimension to define your own values, such as Product, Customer, or Market. You can create up to 13 user-defined custom dimensions. However, the best practice recommendation is to include fewer than 12. Dimensions can be added using a load file or built in Oracle Smart View for Office.

Videos

Your Goal Watch This Video
Learn how to export and import data in the application. Video icon Exporting and Importing Data in Oracle Planning and Budgeting Cloud
Learn how to load dimensions using a file. Video icon Importing Metadata in Oracle Planning and Budgeting Cloud

About the Entity Dimension

The Entity dimension represents your organizational structure, such as Cost Centers, Departments, Business Units, Divisions, and so on.

You can group Cost Centers by creating rollup members, called parents, to reflect how your organization is viewed. For example, rollups can be by business unit, division, or other functional structure. As an example, you could create Cost Centers that roll up to Business Units that roll up to Divisions.

You can create multiple reporting structures. For example, an alternate structure could be created to support regional reporting. If you plan in multiple currencies, the base currency of each entity should be set.

The Entity dimension is one of the primary dimensions used for the budgeting process. Together with the Scenario and Version dimensions, the Entity dimension is used to define a planning unit, a discrete component that can be promoted or demoted for approval or review by a user’s peers.

Members of all dimensions outside the planning unit will be promoted and demoted along with the planning unit itself. For example, all twelve months are promoted together when a planning unit is promoted. Individual months can't be promoted independently.

For detailed information on adding dimensions and members using a load file, see Importing and Exporting Data and Metadata.

After each dimension is loaded or updated, it's a best practice to refresh the application.

About the Account Dimension

The Account dimension is the place for your chart of accounts. It should include the members to which you plan or forecast. It doesn't necessarily include every account in your chart.

For example, your Account dimension could include accounts for Income Statement, Balance Sheet, and Cash Flow. Or, it could include accounts for KPIs and Ratios. In some cases, your accounts may have sub accounts, but this isn't typical.

The Account dimension includes financial intelligence. The following account types are supported:

  • Expense—Cost of doing business

  • Revenue—Source of income

  • Asset—Company resources

  • Liability and Equity—Residual interest or obligation to creditors

  • Saved assumption—Centralized planning assumptions ensuring consistency across the application

The account type settings are used to report Quarterly and Year Total values and for variance analysis.

Planning uses a hierarchical structure to create Account grouping subtotals and totals. Each account group is assigned a consolidation operator that determines how it rolls up to its parent.

Example: Net Income = Total Revenues - Total Expenses

In this example, the consolidation operator for Total Revenues is Addition, and the consolidation operator for Total Expenses is Minus.

The Account dimension can be populated either by loading data or using Smart View. To load data from a file, the file format must meet specific requirements.

For detailed information on adding dimensions and members using a load file, see Importing and Exporting Data and Metadata.

After each dimension is loaded or updated, it's a best practice to refresh the application.

Best practices:

  • Upper level members should be set to Dynamic Calc.

  • For member formulas used to calculate Ratios and other types of KPIs or percentages, set them to Dynamic Calc, Two Pass. The Two Pass setting properly calculates Percentages at upper levels.

About the Version Dimension

You can use versions to preserve different iterations of the planning process. They are also useful for controlling data access to Read or Write.

These two types of versions are available:

  • Standard Target—Input data can be entered to upper levels.

  • Standard Bottom Up—Input data can be entered to level 0 only.

Approvals and workflow functionality can be enabled only for Bottom Up versions.

As a best practice, the following versions are recommended:

  • Working—Where users perform their tasks, including reviewing Actual Results and developing Plan and Forecast.

  • 1st Pass—If you want to maintain multiple iterations of your Plan, you can preserve a pass of it in this version. You can create other members if you require more than one saved iteration. You can leverage the Copy Data functionality to move data to this version. Copy data copies data and textual input.

  • What If—Provides a placeholder where users can change assumptions and analyze the outcome.

For detailed information on adding dimensions and members using a load file, see Importing and Exporting Data and Metadata.

After each dimension is loaded or updated in the build process, it's a best practice to refresh the application.

About the Currency Dimension

If you enabled multiple currencies for your application, you can add the currencies you use to plan and report.

You can then define exchange rates by scenario and year to be used in conversions. A calculation script is created that enables you to perform currency conversion. To enter exchange rates, click or tap Plans and open the form “Exchange Rates to Primary Reporting Currency".

Best practices:

  • Limit the number of reporting currencies. Typically, customers have only one. If you have more, see Setting Up Currencies for more information.

  • Enter exchange rates for each valid scenario and year combination.

  • From this point on, currency conversion can be calculated by running the Calculate Currencies business rule that is associated by default with each form.

  • An account’s exchange rate type is modified, such as from Ending to Average.

Run the currency conversion calc script prior to:

  • Reviewing any updated local data in reporting currencies

  • Running certain calculations that may be dependent on reporting currency data

About Exchange Rates

Each application has a default currency that you specify when creating the application. When you set up exchange rate tables, you enter exchange rates from all source currencies to the default. Triangulation is used to convert to all other Reporting currencies.

Exchange rates are set by Scenario by year for Average and Ending Rates. For detailed information on adding dimensions and members using a load file, see Importing and Exporting Data and Metadata.

About the Period Dimension

Use the Period dimension to establish the calendar’s range within a given year, for example, by month.

Best practices:

  • Use substitution variables for this dimension to support reporting and calculations. Potential substitution variables are: ‘CurrMo’, ‘CurrQtr’, ‘PriorMo’. These variables must be updated on a monthly basis.

  • To use time period calculations such as Year to Date (Y-T-D) or Quarter to Date, select the dynamic time series icon in the Period dimension. You can then select which time period calculations you need to support your process.

  • Summary time periods such as quarter totals and a year total should be set to dynamic calculate to reduce calculation time.

For detailed information on adding dimensions and members using a load file, see Importing and Exporting Data and Metadata.

After each dimension is loaded or updated, it's considered a best practice to refresh the application.

About Years

Years are incorporated into the application in many places, including forms, calculations, reports, and Smart View. Because you'll use the application for many years into the future, the best practice to referencing this dimension is by using a substitution variable.

Substitution variables act as global placeholders for information that changes regularly. The variable and value correspond to the year, and the value can be changed at any time.

The value of the substitution variable is displayed on forms and reports as a placeholder. This reduces maintenance for the application. Set substitution variables by going to Administration, then Manage, then Variables.

For detailed information on adding dimensions and members using a load file, see Importing and Exporting Data and Metadata.

As a best practice, create substitution variables for each year that is included in your process. For example:

Substitution Variable, Description

CurrY, Current Year

NextYr, Budget (Plan) Year

PriorYr, Prior Year

About Custom Dimensions

You can use a custom dimension to further categorize your data. For example, custom dimensions might include Product or Markets.

Access permissions can't be granted at the dimension level, also called generation one. For example, access permissions can't be assigned directly to the Product member for all descendants. If you enable security for your Custom dimension, it's recommended that you design generation two for all Custom dimensions to which security will be applied with security access assignments in mind.

For detailed information on adding dimensions and members using a load file, see Importing and Exporting Data and Metadata.

After each dimension is loaded or updated, it's a best practice to refresh the application.

Refresh the Application

You must refresh the application whenever you change the application structure.

Changes made to the application are not reflected to users performing data entry and approvals tasks until the application is refreshed.

For example, when you modify properties of an Entity member, add a Scenario, or change access permissions, these changes are reflected to users after you refresh the application.

Load Historical Data

After you load all of your structures, such as accounts and entities, you can load historical data. This can include data from prior year actual results and current year plan and budget.

Loading historical data provides users a way to analyze results, review trends, and make meaningful comparisons.

It also helps verify the structures you have built into your application. For example, you can verify that data ties to previously created reports. If the data doesn't reconcile, you must verify if this is caused by a true data issue or if there is an issue with the structures.

An aggregation rule will need to be created to see consolidated data in your application. See Aggregation Options to learn how to create an aggregation rule.

About Valid Intersections

Valid intersections let Service Administrators define rules, called valid intersection rules, that filter dimensional intersections for users when they enter data or select runtime prompts. For example, you can specify that certain programs are valid only for specific departments. Leverage valid intersections to control data entry only to valid intersections.

For form design, if the dimensions that are set in the valid intersection are found on the Page, the user will be presented only with valid combinations in the member selector. If the dimensions that are set with valid intersections are found on the column or row, the form designer can suppress invalid intersections completely. When the suppression option isn't selected, invalid intersections are set to read only.

To learn more, see Defining Valid Intersections.

About Forms

You'll build a number of forms to support data entry and summary-level reports. The form content is similar to the templates you use to collect and calculate data. The layout may differ from what you're currently accustomed to in spreadsheets.

You group forms within major categories such as Revenue, Compensation Expense, Other Expenses, and so on. You can create some forms to support data entry, and others for summary and review. You can also include charts to help users analyze results.

Users can enter text and data. They can also enter supporting detail by selecting an appropriate intersection in the form, and then clicking “Supporting Detail” to open a new input form that allows entry of additional detail for that intersection.

Form performance is based on several factors, including network and environmental factors, structure, layout, and so on.

Best practices:

  • Put dense dimensions such as Account and Period on the row and column of a form. Put sparse dimensions such as Entity on the Page axis.

  • Dimensions such as Scenario or Version and Year can reside on the POV, column, or row. It's important to properly gauge how columns or rows will be returned when a user opens the form.

Build Entry Forms

Create forms to enable users to enter information such as revenue, expenses, and assumptions.

Best practices:

  • Group accounts logically, but don't include too many accounts on a single form.

  • Limit the number of entry forms to an amount comfortable for end users. A delicate balance needs to be achieved between the number of accounts on a single form and the number of forms required to support your process.

  • Consider using composite forms as a way to limit the number of forms while still controlling the number of rows.

  • Use detail forms to enable users to enter all related information. All accounts that require input should be found on a form. The accounts can be broken down into several different forms.

  • While building forms, ensure that you select all appropriate options to enhance the design of your form. For example, use settings to control precision, display, and menus, and to associate the proper rules with your form.

  • Use Substitution Variables to reference dimensions such as Years.

  • Suppress invalid Scenario/Time Period option, set Periods in row or column on the form to the Start and End Period set for the Scenario. Leveraging this functionality can be used instead of substitution variables for Years.

  • Consider setting valid intersections to set relationships between different dimensions. Suppressing invalid combinations can be set in row or column to make only valid intersections available to end users. By default, only valid intersections will be available to the end users when the dimensions are set in the Page selection.

  • Use relationships to incorporate members onto the forms instead of picking members individually.

  • Consider using User Variables for dimensions such as Entity and Scenario to help reduce the dimension selection for end users.

  • If your application supports multiple currencies, consider setting a User variable so users can define their base currency.

  • Organize forms into folders.

  • Substitution Variables reduce the maintenance on forms.

Build Detailed Revenue and Expense Forms

Detail forms should allow users to enter all revenue- and expense-related information. All accounts that require input should be found on a form.

Best practices:

  • Group accounts logically, but don't include too many accounts on a single form.

  • Limit the number of entry forms to an amount comfortable for end users. A delicate balance needs to be achieved between the number of accounts on a single form and the number of forms required to support your process.

  • Consider using composite forms as a way to limit the number of forms while still controlling the number of rows.

  • Use detail forms to enable users to enter all revenue related information. All accounts that require input should be found on a form. The accounts can be broken down into several different forms.

  • While building forms, ensure that you select all appropriate options to enhance the design of your form. For example, use settings to control precision, display, and menus, and to associate the proper rules with your form.

  • Building forms can be iterative to support users and processes.

Associate Rules with Forms

Associating rules with forms enables users with appropriate access to launch associated business rules from the form to calculate and derive values.

You can associate multiple business rules with a form by cube.

Business rules associated with a form can be set to launch automatically when the form is opened or saved. You can select Use Members on Form to populate runtime prompts from the current form instead of prompting users for input when rules are launched.

Best practices:

  • For rules that take longer to run, set them to launch from an Action menu or simply through association with the form.

  • If a business rule has runtime prompts, limit the number of prompts to keep the user’s job simple.

Add Menus to Forms

You can associate menus with forms. Action menus allow users to click rows or columns in forms and select menu items to:

  • Launch a business rule, with or without runtime prompts

  • Move to another form

  • Move to Manage Approvals with a predefined scenario and version

Menus are context-sensitive. The menus that display depend on the form settings and where users right-click in the form.

Best practices:

  • When designing forms, use Other Options to select menus available for Form menu item types.

  • As you update applications, update the appropriate menus. For example, if you delete a business rule referenced by a menu, remove it from the menu.

Build Data Validation Forms

Data validation can serve as a visual clue to users that business policies have been met. You can add conditional color coding to forms, and validation messages can be generated if entered data violates validation rules or if a condition is met.

Defining data validation rules involves these main tasks:

  • Identify the data cells or location that you want to display with validation messages or in different colors when conditions are met.

  • Identify the cell, column, or row that needs to participate during rule evaluation, and define the rule accordingly.

  • Create the data validation rule at the location identified.

Create Composite Forms

Composite forms allow you to display several forms simultaneously. You can display forms as charts. You can also display multiple forms in a tabular format, similar to what your users are accustomed to seeing in spreadsheets.

These features help you create whatever composite form layout is best for your application.

  • Each area in the composite form is called a section. Initially, you specify whether to divide the composite form layout into two side-by-side sections, or into two sections that are stacked one above the other.

  • There is also a custom layout option. Each section in a composite form is associated with properties set during creation. You can edit these properties after creating a composite form.

  • The composite form point of view and page dimensions can be specified within a composite form. You can set the composite setting to combine dimensions.

  • You can design composite forms that have one master composite form and multiple simple forms. When you do so, the selection of members in the master form automatically filters to the members in the simple forms. The simple forms show only the details that are relevant to the members highlighted in the master form. Leveraging master composite forms is a useful way to view both summary and detail level data within a single form.

Organize Forms into Folders

Use folders as a way to organize the forms in your application. Forms can be grouped in folders by process or user type, or simply to help users readily find forms. You can move forms into folders, and you can create a folder hierarchy. Creating folders also simplifies assigning access because all forms in the folder will inherit the access permissions assigned.

Create Dashboards

Dashboards allow you to display information graphically or to display several forms simultaneously. You can also design interactive multi-chart dashboards to enable users to analyze their plan or forecast data. As another option, you can display a grid and a graph together, or you can combine multiple grids.

To create a dashboard:

  • Drag and drop forms into the dashboard. Using the settings wheel to select the chart type desired for each grid.

  • You can drag and drop as many forms as you would like, setting the size of the display by setting either the height or width for the component.

  • Set dashboard settings to combine dimensions into a common POV.

  • As a best practice, balance the number of components on the dashboard to ensure that it's visually pleasing to the user.

Build Summary Level Forms

Summary level forms typically bring together all of the pieces of a user's plan or forecast. They enable users to review and analyze their results.

Leveraging composite forms is a useful way to pull together summary level results and still have the ability to drill into detail. Using charts can also be an effective way to help users analyze their results.

Using dashboards can also be an effective way to help users analyze their results.

Build Financial Statements

Financial statements allow users to analyze performance and verify their assumptions. Financial statements could include Income Statement, Balance Sheet, and Cash Flow.

Typically, financial statements include comparative information so users can analyze their variances. Summary level information is typically built into financial statements with the ability to view detailed data either through master detail composite forms or by linking detailed forms using menus.

Incorporate Business Logic

To incorporate your business logic into your application, calculations can be built using Calculation Manager. This enables you to create, validate, deploy, and administer sophisticated calculations that solve business problems.

You typically create business rules and rulesets to:

  • Perform revenue modeling

  • Perform expense modeling

  • Calculate KPIs

  • Perform allocations

Calculation Manager includes these objects:

  • Rules—Contain components and templates

  • Components—Assist you in building rules

  • Rulesets—Contain rules that can be calculated simultaneously or sequentially

To learn more about creating calculations, see the Calculation Manager documentation.

Build Aggregations

Aggregations roll up your application to summary-level members in the dimension, such as Entity or any other sparse dimension.

Calculation Manager includes templates to help you build aggregations. The System Template Aggregation has several tabs. Here are some suggestions on how to use templates.

Set the Point of View

When the point of view is set, the rule will run only for the members chosen. Using a runtime prompt for the dimensions will allow users to specify member values for these dimensions when launching the rule. This way, users can launch the rule several times for different years, scenarios and versions without having to modify the rule in Calculation Manager.

Full dense aggregation

Complete this section if parent values in your dense dimensions are not set to dynamic calc. Typically this tab is left empty.

Full sparse aggregation

Select the sparse dimension that needs to be aggregated. The order of the selected dimensions isn't relevant.

Partial dimension aggregation—dense

Complete this section if parent values in your dense dimensions are not set to dynamic calc. Typically this tab is left empty.

Recommended settings:

Aggregate the data up to the local currency—No

Aggregate the missing values in the Database—Yes

Optimize the Calculation on Sparse dimension—Off

Select a value for the calculator cache—Default

Do you want to activate the debug mode for this wizard?—Debug Wizard On or Debug Wizard Off. Select Debug Wizard On if you want to see a script generated to display selections for some of the Design Time Prompts in this template.

Best practices:

  • Leverage runtime prompts for members such as Entity, Scenario, and Version. This allows your rule to be dynamic and run based on user input.

  • Typically, dense dimensions such as Account and Period don't need to be aggregated. If this is the case, you can set parent members to dynamic calc. However, if you have member formulas on dense dimensions and they are not set to dynamic calc, a Calc Dim rule is required.

Build Detailed Calculations

You use Calculation Manager to create, validate, deploy, and administer sophisticated calculations that solve business problems.

There are three types of objects that can be calculated in Calculation Manager:

  • Rulesets—Contain rules that can be calculated simultaneously or sequentially (See Administering Rules.)

  • Rules—Contain components and templates (See Administering Rules.)

  • Components—Contain formula components, script components, condition components, range components, and fixed loop components (See Administering Rules.)

Best practices:

  • As a first step in building your rules, ensure that you understand the business logic and which entities or departments the rule applies to. For example, know the accounts that are involved in the rule.

  • Be sure you know the source and destination accounts.

  • After you fully understand the drivers of the calculation, use the proper object component or template to build the rule. The components and templates facilitate member selection to help deploy the rules.

Leveraging runtime prompts for members such as Entity, Scenario, and Version allows your rule to be dynamic and run based on user input.

Build Reports

Building reports allows you to report on your financials for management. In this step, you build your Income Statement and other detailed reporting with the proper formatting that your management team is accustomed to reviewing.

Report formats specify the layout of the report, such as which elements are on the rows and columns. Report formats can be used to create many different reports, such as by Cost Center or by Division.

Best practices:

  • Before building reports, determine how many different report formats are required.

  • To simplify building reports, specify a report format for each type of report you need.

  • Begin building reports by arranging dimensions properly. Next, get the report to capture the data. Finally, apply formatting.

Build Task Lists

Task lists guide users through the planning process by listing tasks, instructions, and due dates. Task lists help flow users through the application to ensure that the process is followed and that all of the proper data has been collected.

Task lists should be developed to support the different types of users and process flows. Tasks can help users perform many types of tasks, such as:

  • Open a form

  • Launch a business rule that you specify

  • Start the review process with a specified scenario and version

  • Copy a version of the current form’s data

  • Open a specified URL

Tasks guide users through the planning process. Tasks can help users perform many types of tasks. They help flow users through the application to ensure that the process is followed and that all of the proper data has been collected.

Build tasks to support the different types of users and process flows.

Set Up the Navigation Flow

Navigation Flows set the clusters or cards available at the top of the user screen. The cards are typically associated with actions in your business process, such as Plan Revenue and Plan Expenses. Within each card, vertical tabs can be created to lead the user through the process for that business area. Forms can be linked to a vertical tab to guide the user in the process. Vertical tabs can have one or many horizontal tabs linking to either forms or dashboards.

Your application comes with a default navigation flow. To customize the cards and flow for your organization, copy the default, and then you can use it to make your own.

Tap or click Settings, then Navigation Flow. Tap or click Action, then Create Copy.

You can create a cluster to represent an entire business process that can contain cards for the actions, or you can simply create new cards. Cards can be designed to be single page or can have multiple tabs. For a card that is set up to be tabular, you can have multiple tabs that allow you to have content visible to the end user as horizontal tabs. You specify the content type for each of the tabs and link to an artifact.

For example, you can associate cards with:

  • Dashboards

  • Forms

  • Rules

  • Approvals

Set Up Access Permissions

Access permissions determine a user’s privileges after the product launches. Most often, groups are established to help organize users. By definition, a user group is a set of users with similar access permissions.

Access permissions for groups and individual users can be assigned to these application elements:

  • Scenarios

  • Versions

  • Accounts

  • Entities

  • Custom dimension members

  • Forms

  • Business rules

Users can be in a group:

  • Service Administrator

  • Power User

  • User

  • Viewer

Best practices:

  • For dimensions secured by default, modify access permissions as needed.

  • Assign access permissions to application elements such as dimension members, forms, and rules. Users can view or use only those application elements to which they have access.

About Users and Groups

Your company’s users must be added to the Oracle Identity Management System prior to gaining access permissions to any of the elements in your application. Access permissions determine a user’s privileges after the product launches.

By definition, a user group is a set of users with similar access permissions. The use of groups as a way to organize users and assign access permissions is a best practice.

Add Users

Users must be added to your environment, assigned privileges, and granted access to the application.

Users' roles will be defined as one of these types:

  • Service Administrator—Creates and manages applications, including dimensions, forms, Calculations, and so on. The Service Administrator manages access permissions and initiates the budget process

  • Power User—Creates and maintains forms, Smart View worksheets, and Financial Reporting reports. Can perform all User tasks.

  • User—Enters and submits plans for approval, runs business rules, uses reports that others have created, and views and uses task lists. Leverages Smart View to enter data and do ad hoc analysis.

  • Viewer—Views and analyzes data through data forms and any data access tools for which they are licensed. Viewers can't modify any data in the application. Typical View users are executives who want to see business plans during and at the end of the budget process.

Users, Power Users, and Viewers can access forms, task lists, and business rules based on permissions assigned by the Service Administrator.

Create Groups

It's highly recommended to leverage groups when assigning access permissions to users. Having groups of similar users eases security maintenance on an on-going basis. As users are added to groups, they inherit the access permissions of the group. Assigning group access permissions to elements such as dimension members, forms, and task lists means that you don’t need to assign those access permissions individually for each user.

Best practices:

  • If an individual user is assigned to a group, and the access permissions of the individual user conflict with those of the group, the individual user’s access permissions take precedence.

  • The use of groups for sets of users with similar access permissions should be well defined prior to implementing user access.

  • Individual permissions override group permissions.

  • If an individual is assigned to multiple groups, the group with the highest access permission takes precedence.

Access permissions assigned to a user directly override access permissions inherited from groups that the user belongs to. For example, if you have inherited read access to Plan from a group but are assigned write access to Plan directly, you get write access to Plan.

Assign Users to Groups

As a best practice, leverage groups as a way to reduce maintenance and assign similar access to users. Give users access to the appropriate groups.

Assign Access to Dimensions

In order for users to read or write data, access permissions must be assigned to the following dimensions:

  • Account

  • Entity

  • Scenario

  • Version

If security is enabled on custom dimensions, you must assign security to users to those dimensions as well. For dimensions secured by default, modify security access as needed.

Assign Access to the Account Dimension

Give users read or write access only to those accounts they are allowed to see. You can assign access privileges as Read, Write, or None.

Best practices:

  • Relationship functions should also be leveraged whenever possible to reduce on-going security maintenance. The relationship functions are: Member, Children, iChildren, Descendant, and iDescendant. For example, assigning Write access to Descendants of Net Income for a group allows all users of that group to have Write access to all accounts that are descendants of Net Income. This way, you don't need to assign access individually to each account.

  • To take full advantage of the rules of precedence and inheritance, use an exception-based method for managing security. Primary assignment of security should be by group and relationship. Assign group rights to parent level members, and use relationships to push the assignments down to the children or descendants. Assign individual user rights to children on an exception basis.

Assign Access to the Entity Dimension

Give users read or write access only to those entities they are allowed to see. You can assign access privileges as Read, Write, or None.

Assign Access to the Scenario Dimension

Access to Scenario is typically set to Read or Write. For example, you may want to assign access to Actual and Variance scenarios as Read, and to Plan and Forecast as Write.

Assign Access to the Version Dimension

Access to Version is typically set to Read or Write. For example, you may want to assign access to Final Version as Read, and to Working as Write.

Assign Access to Custom Dimensions

If security is enabled on any custom dimension, you must assign security to the dimension in order for users to have access.

Assign Access to Forms

Before users can open forms, they must be assigned access permissions.

Users who are assigned access to a form folder can access the forms in that folder unless they are assigned more specific access.

Users and Power Users can view or enter data only into forms to which they have access. They can work only with members to which they have access.

Tips:

  • To simplify assigning access to forms, organize forms into folders and assign access at the folder level instead of the individual form level. Access permissions can be set to Read, Write or None.

  • When you assign access to a folder, all folders under it inherit that access.

  • If you assign specific access (such as None or Write) to a form folder, that access permission takes precedence over its parent folder's access permissions. For example, if a user has Write access to Folder1 that contains Folder2 to which the user has None access, the user can open Folder1, but doesn't see Folder2.

  • If a user has None access to a form folder called Folder1 that contains a form called Form1 to which the user has Write access, the user can see Folder1 and Form1.

Assign Access to Business Rules

Before users can launch business rules, they must be given access permissions to the rules.

As a best practice, organize business rules into folders that have similar user access, and apply security to the folders. You can also give access permissions to individual business rules, although this is a little more time-consuming.

Users have Launch access to Calculation Manager business rules in folders to which they are assigned access, unless they are assigned more specific access

Assign Access to Task Lists

In order to navigate through the application, users must be assigned access to individual task lists.

As a best practice, assign access using groups. This is more efficient than applying access to individual task lists.

Assign Access to Reports

Users must be assigned access to a report before they can use it.

As with other artifacts, it's recommended that you organize reports into folders and assign access at the folder level. This limits the amount of maintenance required for security. As reports are added to the folder, access is inherited from the folder.

Build Approvals

Use approvals to track budgets and review status, planning unit ownership, and process issues. This reduces the time required for the planning cycle.

Set up the approval path independent of organizational structure to reflect the path a plan or forecast must follow for approval.

Users can provide annotations and comments for their submissions.

Set up the Planning Unit Hierarchy

Setting the planning unit hierarchy defines the promotional path used in approvals. The basis of the planning unit hierarchy is the Entity or any part of the Entity dimension in combination with any secondary dimension.

The secondary dimension can be a mix between several dimensions, depending on where you are in the workflow. For example, you can combine the Entity dimension with the Products dimension in the promotional path for certain entities, while using the Channels dimension in the promotional path for other entities.

Owners and reviewers can be directly assigned the planning unit. Validation rules can be created to handle conditional promotion path dependent on data conditionals. You create different planning unit hierarchies to support review processes within your organization

The planning unit hierarchy is then assigned to the appropriate Scenario and Version combination.

Planning units are combinations of scenario, version, and entity or part of an entity. Scenarios and versions are the basis of the review cycle. A planning unit hierarchy contains planning units and any other dimensions that are part of the review process.

Things to know about approvals:

  • The review process follows the promotional path you set up when you select the owner and reviewers for a planning unit, unless an event triggers a change in the promotional path.

  • Parent/child relationships between planning unit hierarchy members affect the review process

  • When users promote or reject a parent, the parent’s children are promoted or rejected unless they are approved. The owner for the parent becomes the owner of the children.

  • When users approve a parent, its children are approved.

  • After all children are promoted to the same owner, the parent is promoted to the owner.

  • When the status of all children changes to one status, for example Signed Off, parent status changes to the same status.

  • Users can't change the status of a parent if its children have different owners.

  • If the children are promoted to, submitted to, or signed off by different users, the parent has no owner and only Service Administrators can change its status.

  • The planning unit moves from one reviewer to another until the budget process is complete.

Test

Testing is a critical step in application development. All of the calculations, access permissions, and reports must be tested to ensure that they work appropriately.

About Unit Testing

Unit testing is the first step of formalized testing, and is the main building block of the test environment. Unit testing involves testing each functional area of the application as a separate unit to ensure that it performs as expected.

For example, a test could confirm that a data load executes to completion without errors. Other tests could confirm that forms and reports are accessible, calculations complete, and so on.

The person that builds or configures the application usually conducts unit testing.

About System Testing

System testing validates that the system operates without error and provides the required functionality.

The main emphasis is to test the way in which the application has been configured and to look at how the team has constructed the business processes and reports. System testing focuses on testing the entire system, including unique parameter configuration, all functions that will be used, and any enhancements.

System testing also looks beyond the software, and validates the effectiveness of manual procedures, forms and controls. It's a complete set of formal functional tests covering all aspects of functionality within the system being built.

This type of test is often combined with:

  • Security Tests—Tests that the system security and database security is appropriate for the overall system and each specific user.

  • Integration Tests—Tests the overall business solution, including the passage of data to and from other integrated systems. This confirms that the functionality remains valid when all aspects of the system have been combined.

  • User Acceptance Tests—Users validate that the system operates correctly and meets requirements. If users are not involved in formal system testing or they request specific tests, there may be a need for further acceptance tests. However, in most cases, this type of testing is done as part of System and Integration Tests, provided that users recognize these tests as adequate for acceptance purposes.

Rollout

During rollout, you can train end users on the system, and show them how to navigate and use functionality. As a best practice, document your system to enable someone else to take over administration if necessary.

Training

All users of the system should be trained on the application. Users need to learn how to navigate comfortably around the application and understand the tasks assigned to them. Training should include logging into the application, navigating through task lists, entering data, running rules, using Smart View, and using tools within the application. Training is typically the user’s first exposure to the application, and a well planned and executed training session helps make a good first impression.

Document System and Administrative Information

After building your application, it's recommended that you create system and administrative documentation for the application.

Best practices:

  • Create this documentation at the end of the Build Process when the information is fresh.

  • Include information such as the sources of data, the application structure, how calculations work, and what maintenance is required for the application.

List maintenance tasks broken down into timeframes, such as monthly and annual maintenance. This makes it possible for someone else to take over the system later if necessary.

Enable the Application for Users

To enable the application for end users, you must open up the system enabling. In addition, start planning units to enable approvals.

Start Planning Units

The planning unit must be started before users can access the system to begin the review process. After it's started, the planning unit moves from one reviewer to another until the process is complete.