1. Administering Profitability and Cost Management
  2. Calculating an Application
  3. Performing Single-POV Calculations Using the Navigator

Performing Single-POV Calculations Using the Navigator

The global context, rule sets, and rules in applications are specific to a single point of view (POV).

This means that a rule set or rule of the same name may exist in multiple POVs but each of the instances of that rule set or rule is a unique artifact and may have a unique definition. Running a rule for a specific POV executes the definition of that rule set or rule as it exists in that POV. When you perform a single-POV calculation using the Calculation screen (accessed with the Navigator menu), you select a single POV with data and rules and run the calculation against it using its own rules. If you also want to calculate the data in one POV using rules from another, or if you want to use the rules in one POV against the data in several different POVs, you can perform multiple-POV calculations using the Execution Control screen (Performing Single- and Multiple-POV Calculations Using Execution Control). Also see:

Caution:

Before calculating an application, ensure that cost and revenue data have been loaded. Otherwise, the calculation uses an empty data set.

To clear or calculate a Profitability and Cost Management application using the Navigator:

  1. Click Navigator button, and then Calculation.

    Figure 11-2 The Calculation Screen


    This screen is used to determine how an application is calculated.
  2. In the Calculation screen, enter the POV information to calculate, such as Year, Period, and Scenario.
    For a list of available POVs, click Navigator button, and then Points of View.
  3. Optional: Enter a Job Comment to display on the Job Library screen.
  4. Optional: In the Processing Options group, select one or more actions to perform:

    • Clear Calculated Data to clear all cells that could be updated by the rules in the Processing Range options (selected by default); this also clears results from previously running the rule or rules that will run as part of this calculation job

    • Execute Calculation to run the rules specified in the Processing Range options (selected by default)

    • Capture Essbase Debug Scripts to store engine-generated scripts for each allocation or custom calculation rule included in a calculation (see Example 11-1 later in this topic)

      Note:

      Capture Essbase Debug Scripts is intended for troubleshooting purposes and can increase processing overhead. Avoid selecting this setting without an appropriate reason to do so.

      If Capture Essbase Debug Scripts is selected, the Job Details list indicates that selection on the Job Library screen.

    • Optimize for Reporting to run the default aggregations on the Essbase cube when the calculation completes (Example 11-2)

  5. In the Processing Range group, indicate which rules to run:

    • All Rules runs all enabled rules defined for the selected POV.

    • Specify Rule Set Range runs all enabled rules in the rule set range defined by the First Rule Set Sequence Number text box and the Last Rule Set Sequence Number text box, inclusive.

    • Stop After Rule enables you to specify a stopping point for a calculation job. All rule sets and rules, up to and including the selected rule, will run and the calculation will stop at that point.

    • Run Single Rule runs a single rule as selected in the Rule Set Name and Rule Name lists.

  6. Click Run Now to run the calculations or clear data immediately. A confirmation message indicates that the job has started and identifies the assigned taskflow ID.

    Caution:

    Depending on the size and complexity of an application, this operation may take a significant amount of time.

  7. Monitor the progress of the calculation using the taskflow ID in the Job Library screen.

Example 11-1 About Debug Scripts

Scripts are generated in the Outbox folder, which can be accessed using the File Explorer (Transferring Files with the File Explorer).

The file name format for scripts is P+XX+RuleMemberName.txt, defined as follows:

  • P = POV

  • XX = last two digits of the selected POV member group ID

  • RuleMemberName = Unique rule member name assigned to the particular rule

For example, a generated script may be named P99R0001.txt.

Each script file has a header with the following information:

  • Application name

  • POV

  • Rule set name

  • Rule name

  • Rule sequence

  • Number of iterations

Individual script files are compressed into a larger file. When uncompressed, they run in Essbase MAXL without editing. If custom calculation formulas are used, their debug script files have the same name as the main script file, followed by an underscore and sequential number. For example, if a rule file script's file name is P5R0005.txt and it has two custom calculation scripts, their names are P5R0005_1.txt and P5R0005_2.txt. The ZIP file containing these scripts is Calc_Debug_Scripts_<appName>_<JobId>zip.

Example 11-2 About Optimizing for Reporting

When Optimize for Reporting is selected, Profitability and Cost Management runs aggregations on the Essbase cube when the calculation is complete. This improves performance for queries, reports, and analytics. You can also run this setting by itself.

These aggregations are dropped at the beginning of each calculation to improve calculation performance, so it is a good practice to select Optimize for Reporting only for running a final calculation before querying data, performing analytics, or running reports. For example, if you have three calculation jobs to run before you run reports, selecting this option before the first or second job adds unnecessary time to the calculation without providing a benefit.

Other helpful practices are as follows:

  • Optimize for Reporting is selected by default. Keep it selected unless you are running a single rule or a sequential series of several POVs and need to save processing time.

  • When running multiple concurrent calculation jobs, keep Optimize for Reporting selected for all jobs. Only the last to complete will perform the aggregation. This avoids redundant processing and prevents slow-down of jobs.