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:
-
For an overview of basic calculations using the Navigator, view the following video:
Video Overview: Calculation and Validation in Oracle Profitability and Cost Management Cloud
-
For a tutorial about performing basic calculations using the Navigator and validating models, view this video:
Calculating and Validating Models in Oracle Profitability and Cost Management Cloud
-
For a step-by-step tutorial about performing basic calculations using the Navigator, see this learning path:
Calculating Models in Oracle Profitability and Cost Management
-
For information on troubleshooting calculation issues, see Troubleshooting Calculation Issues in the Oracle Enterprise Performance Management Cloud Operations Guide.
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:
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.