Setting up Valid Intersections in Oracle PBCS

If you have been implementing on-premise Hyperion Planning applications, you would have a missed a very good feature, that of putting in a rule to mark certain member intersections as valid combinations for data entry. Oracle has provided this feature in Oracle PBCS called as Valid Intersections. However this feature is limited to the ‘Simplified’ interface within Oracle PBCS. After valid intersections are defined, cells containing invalid data are made read-only. On a recent PBCS implementation, I set up the valid intersections and found the feature to be very useful.

To set up Valid Intersections, login to Oracle PBCS and navigate to the ‘Simplified Interface’. From within the Simplified Interface, click on ‘Console’

Click on the ‘Valid Intersections’ icon

Click on ‘Create’

Enter a name for the Valid Intersection Group (you can add multiple rules under a rule group) and select an ‘anchor’ dimension. An anchor dimension is one on which your valid intersections are based on and your choice of anchor dimension is critical as you will see different results based on the choice of anchor dimension. You can choose not to have an anchor dimension. Please note that here I am selecting ‘Account’ dimension as I want to set up a rule involving Accounts.

Once the anchor dimension is selected, add a dimension that you want to setup as a valid combination. In this case, I have selected the Department dimension. You can add one or more non-anchor dimensions in your rule.

Make a note of two important settings, ‘Required’ and ‘Unselected Members are valid’. If an anchor dimension is added, it is marked as ‘Required’ by default and this cannot be changed. This however can be changed for a non-anchor dimension. ‘Unselected Members are valid’ option only applies to the anchor dimension. These settings are explained below.

Required (Required Vs Non-Required Non-Anchor Dimensions): This case would normally happen when dealing with creating a Valid Intersection Group common to multiple plan types in which a dimension not belonging to a plan type can be marked as ‘Non-Required’. The effect of this is explained below with an example.

Consider Rule Group 1 with Anchor dimension Departments set to IDESC (Marketing) with the ‘Unselected members are valid’ option checked and non-anchor dimension Product set to IDESC (Hardware)

Consider Rule Group 2 with Anchor dimension Departments set to IDESC (Marketing) with the ‘Unselected members are valid’ option cleared and non-anchor dimension Product set to IDESC (Hardware)

In Rule Group 1, since the product dimension is not required and unselected departments are valid, if a plan type does not contain the Product dimension, the resultant effect is a rule with only one dimension (Department) that evaluates to all departments as valid.

In Rule Group 2, since the product dimension is not required and unselected departments are invalid, if a plan type does not contain the Product dimension, the resultant effect is a rule with only one dimension (Department) that evaluates to only DESC (Marketing) departments as valid.

Unselected members are valid: This selection basically marks the unselected members as valid. This is best explained by an example.

Consider Rule Group1 with Anchor dimension Accounts set to IDESC (Balance Sheet) with the ‘Unselected members as valid’ option cleared and non-anchor dimension Department set to (0000 – No Department).

Consider Rule Group2 with Anchor dimension Accounts set to IDESC (Net Income) with the ‘Unselected members as valid’ option checked and non-anchor dimension Department set to IDESC (Marketing)

Because Rule Group 1 marks all unselected members as invalid, the result is non-inclusive descendants of Balance Sheet are marked invalid. Since Net Income is not part of Balance Sheet, and even though Rule Group 2 states inclusive descendants of Net Income are valid with descendants of Marketing departments, the invalid definition from Rule Group 1 overrides any further valid intersections of the same anchor dimension member set.

Once the anchor dimension and its valid combination dimension are selected, with their settings, click on ‘Add Rule’ to start adding the actual valid intersection combinations by selecting members for the anchor and non-anchor dimensions that you selected in your rule group. Use the ‘Edit’ option to include members and ‘Add Exclusion’ option to exclude members.

In the example below, I have added IDESC (P&L) and excluded IDESC (Provision for Income Tax)

Important points regarding Valid Intersection Groups and Rules from Oracle Documentation are given below:

Valid Intersection Rules within the same Valid Intersection Group: Valid intersection rules within the same valid intersection group that produce an apparent conflict or overlap, are marked valid if either valid intersection rule condition is met.

Valid Intersection Rules within the different Valid Intersection Groups: Valid intersection rules in different valid intersection groups that produce an apparent redundancy or overlap, are marked valid if they satisfy the requirements of all valid intersection groups

Thus, if any valid intersection group marks an intersection invalid, regardless of other valid intersection groups making it valid, the system will mark the intersection invalid. Invalid groups override valid group results.

Valid Intersection Rules and RTP’s: Valid intersection groups apply to runtime prompts when launched from within the context of Planning. Runtime prompts will prevent users from selecting invalid intersections as defined in the valid intersection groups.

Valid Intersection Rules and Smartview: Filtering according to valid intersection groups is not supported in Smart View forms. The rule, however, will not launch if you choose an invalid intersection in the runtime prompts both in the Web and in Smart View.

Valid Intersections in Planning Forms: Using valid intersections prevents data entry for invalid intersections as defined in the applicable valid intersection group. The affected cells in the form display as read-only following standard, read-only color coding. If you hover the cursor over an invalid intersection, a tool tip displays indicating the cell is read-only because it is defined as an invalid intersection.

The valid intersection group applies first to the form point of view and page axis. If the point of view intersections are all invalid, then a warning message is displayed, and the form does not render a data grid until a valid intersection is selected.

If the point of view has valid intersections, then the rows and columns are filtered to restrict data entry at invalid intersections. If the Suppress Invalid Data option for the form is enabled, then the form suppresses invalid rows, columns, or both, as appropriate.

Any rows or columns, which consist of a mix of valid and invalid intersections, display those intersections as valid or invalid, as appropriate. Invalid intersections are displayed with standard, read-only shading and preclude data entry.

Valid Intersections and Shared Members: Shared members are supported in valid intersection rules. If a base member is selected for a valid intersection rule, any shared members are also included in the rule. Conversely, if a shared member is selected for a valid intersection rule, the base member is also included in the rule.

Valid Intersections and Substitution Variables: You can use substitution variables in valid intersection rules.