Valid Intersection Examples
This section provides valid intersection group and valid intersection rule examples to illustrate a few simple, complex, and edge-case scenarios.
Example: Anchor and Nonanchor Dimensions
The choice of the anchor dimension is critical. Consider the following example, which produces a different result based on the anchor dimension definition:
-
Valid intersection group 1 defines Entity as the anchor dimension and Product as a nonanchor dimension.
-
Valid intersection group 2 reverses this definition with Product as the anchor dimension and Entity as the nonanchor dimension.
Table 18-1 Example - Anchor Dimension is Entity
| Valid Intersection Group | Anchor Dimension - Entity | Nonanchor Dimension - Product |
|---|---|---|
| 1 | DESC(500 - Manufacturing) - Unselected members are valid | DESC(P_TP1 - Computer Equipment) |
Group 1 means entities that are descendants of Manufacturing are valid only with descendant products of Computer Equipment. No other products are valid with descendants of Manufacturing. All other entities besides descendants of Manufacturing are valid with all products, including descendants of Computer Equipment.
Table 18-2 Example - Anchor Dimension is Product
| Valid Intersection Group | Anchor Dimension - Product | Nonanchor Dimension - Entity |
|---|---|---|
| 2 | DESC(P_TP1 - Computer Equipment) - Unselected members are valid | DESC(500 - Manufacturing) |
Group 2 means products that are descendants of Computer Equipment are only valid with descendant entities of Manufacturing. No other entities are valid with descendants of Computer Equipment. All other products besides descendants of Computer Equipment are valid with all entities, including descendants of Manufacturing.
Caution:
The choice of anchor dimension is significant. You'll get dramatically different results if you choose the wrong anchor dimension.
Example: Required Dimension
In the following example, if a nonanchor dimension isn't required, then the application evaluates all remaining dimension intersections in the valid intersection group for a cube that doesn't contain the nonrequired dimension. This behavior could result in the evaluation of a valid intersection group with only one effective dimension.
Table 18-3 Example - Required vs. Non-Required Nonanchor Dimensions
| Valid Intersection Group | Anchor Dimension - Entity | Nonanchor Dimension - Product |
|---|---|---|
| 1 | DESC(500 - Manufacturing) - Unselected members are valid | DESC(P_TP1 - Computer Equipment) - Not required |
In Group 1, the product dimension isn't required, and unselected entities are valid. Therefore, if the cube of the form or business rule, at runtime, doesn't include the product dimension, the application evaluates the entity dimension selections to mark all entities as valid for a cube that doesn't contain the product dimension.
Table 18-4 Example - Required vs. Non-Required Nonanchor Dimensions
| Valid Intersection Group | Anchor Dimension - Entity | Nonanchor Dimension - Product |
|---|---|---|
| 2 | DESC(500 - Manufacturing) - Unselected members are invalid | DESC(P_TP1 - Computer Equipment) - Not required |
In Group 2, the product dimension isn't required, and unselected entities are invalid. Therefore, if a cube doesn't include the product dimension, then the application evaluates the entity dimension selections to mark all entities except descendants of Manufacturing as invalid. Thereafter, any cube that doesn't use the product dimension will only allow data entry in the descendants of Manufacturing entities.
Caution:
Carefully consider whether a nonanchor dimension is required or not, especially if the result leaves a valid intersection group with only one effective dimension. Additionally, selecting the Unselected Members are Valid option for anchor dimension members also plays a significant role in the system behavior for valid intersections. See Valid Intersection Examples.
Example: Unselected Members are Valid
In the following example, two intersection groups are valid. In one group, the anchor dimension unselected members are invalid (this option is cleared). In the other group, the anchor dimension unselected members are valid (this option is selected).
Table 18-5 Example - Unselected Members are Valid
| Valid Intersection Group | Anchor Dimension - Account | Nonanchor Dimension - Entity |
|---|---|---|
| 1 | IDESC(BS - Balance Sheet) - Unselected members are invalid | 000 - No Department |
| 2 | IDESC(GP - Gross Profit) - Unselected members are valid | IDESC(403 - Sales) |
Because Group 1 defines all unselected members as invalid, the application marks noninclusive descendants of Balance Sheet invalid. Gross Profit isn't an inclusive descendant of Balance Sheet. So even though Group 2 explicitly states inclusive descendants of Gross Profit are valid with inclusive descendants Sales entities, the invalid definition from Group 1 overrides any further valid intersections of the same anchor dimension member set.
Example: Redundant or Overlapping Valid Intersection Rules Within the Same Valid Intersection Group
When valid intersection rules are within the same valid intersection group and produce any redundancy or overlap, the system marks an intersection valid if either of the valid intersection rule conditions are met.
Table 18-6 Example - Redundant or Overlapping Valid Intersection Rules Within the Same Valid Intersection Group
| Valid Intersection Rule | Anchor Dimension - Account | Nonanchor Dimension - Entity |
|---|---|---|
| 1 | IDESC(GP - Gross Profit) - Unselected members are valid | IDESC(403 - Sales) |
| 2 | IDESC(NI - Net Income) - Unselected members are valid | IDESC(TD - Total Department) |
Because Gross Profit is a descendant of Net Income and Sales is a descendant of Total Department, inclusive descendants of Gross Profit are valid with any inclusive Descendant of Total Department. Rule 1 is a subset of Rule 2, so Rule 1 is effectively a "No operation" rule and is unnecessary. There is no restriction on inclusive descendants of Gross Profit accounts only being valid for inclusive descendants of Sales Entities.
Example: Redundant or Overlapping Valid Intersection Rules in Different Valid Intersection Groups
When valid intersection rules are in different valid intersection groups and produce any redundancy or overlap, the system marks an intersection valid only if it satisfies the requirements of all valid intersection groups.
In the following example, there are redundant or overlapping rules in different groups:
Table 18-7 Example - Redundant or Overlapping Valid Intersection Rules in Different Valid Intersection Groups
| Valid Intersection Group | Anchor Dimension - Account | Nonanchor Dimension - Entity |
|---|---|---|
| 1 | IDESC(GP - Gross Profit) - Unselected members are valid | IDESC(403 - Sales) - Required |
| 2 | IDESC(NI - Net Income) - Unselected members are valid | IDESC(TD - Total Department) - Not required |
Because Group 1 is further restrictive for inclusive descendants of Gross Profit accounts being valid with inclusive descendants of Sales entities, the application enforces this group for these intersections. Other, non-Gross Profit accounts can still use all inclusive descendants of Total Department entities, but inclusive descendants of Gross Profit accounts must use inclusive descendants of Sales entities.