Application Validations

If you receive validation errors after upgrading to Release 11.1.2.1, you must make these manual fixes:

Validation Error Fix
Dimension cannot have a negative, zero, or empty sort order value: Dimension 'Dimension Name'. If the sort order is not available or not set correctly in the previous state it is shown as a validation error. Users should correct the sort order in the Performance Settings. See Modifying Performance Settings.
DataStorage at dimension level may be set to blank in previous versions. In most cases Essbase defaults to StoreData or LabelOnly. Users should manually select the appropriate Data Storage property value for the dimension.

The following tables describe the validations performed by Performance Management Architect for each application type.

Table 49. Consolidation Validations

Validation Level Validations
Dimension

  • Verify that there are no UDA dimensions in the application, since UDA dimensions are not supported in Consolidation applications.

  • Determine if there are any dimensions that use an invalid dimension class in the application

  • Verify that period dimensions are local

  • Verify that the dimension instance does not have more than the maximum allowed levels of dimensional depth

  • Verify that the dimension supports shared members

  • Verify that the dimension supports non-unique members

  • Verify that the dimension has required associations

  • Validate the custom dimension ID

  • Check for static dimensions
Application

  • Verify that all required dimensions are included in the application

  • Validate the allowed number of dimension instances of a dimension class that have been added to the application

  • Enforce application naming rules

  • Check for invalid characters
Member

  • Verify that there is a valid account type for the member

  • Verify that there is a valid default member property

Table 50. Planning Validations

Validation Level Validations
Dimension

  • Attribute dimensions can only be associated with sparse dimensions.

  • Allowed values for Boolean members are either True or False

  • Level-0 date members should conform to the date format property set in application settings

  • Level-0 numeric members should be a valid number

  • View dimension types are not supported in Planning applications

  • Empty Attribute dimensions of type Boolean, Date, or Numeric cannot be associated with a base dimension

  • A base dimension can be associated with only one Boolean Attribute dimension

  • The Year, Currency, and Alias dimension have limited dimension depth

  • The Year, Currency, and Alias dimensions do not have shared members

  • Dimensions do not support non-unique members within the dimension

  • Each Alias dimension has a Default alias member

  • Dimension plan types selected must be the same as or a subset of the plan types selected for the application

  • The Alias dimension does not have a disallowed name

  • There is no duplication of Alias in Alias table

  • For all members of the Version dimension, the Enable Process Management property is not set to True if the Version Type property is set to Target

  • Member names and aliases are unique

Period and Year Validations:

  • Year members must be sequential

  • The first year member must be the Fiscal Start Year for the current application

  • Each level under the Year Total member in the Period tree must have the same number of children

  • The number of leaf members under the Year Total member is correct for the base time period of this application

  • The maximum number of periods is 500

  • The maximum number of Year members has not been exceeded

  • There are no more than 100 years in Year dimensions

  • The first year in Year dimensions has the correct format

  • For deployed applications, year is not added to the beginning of a range

  • The Period dimension member depth is based on Period Type
Application

  • No dimension associations exist within the application

  • The application has the minimum required dimensions as described in Creating Planning Applications

  • The Scenario, Year, Period, Entity, Account, and Alias dimensions do not have more instances than specified in the application

  • Check that all required dimensions are present based on selected plan types at the application level

  • Verify that the Account Type property contains only valid values for Planning

  • Enforce rules on the application name. The application name can include a maximum of 8 characters and cannot be “Planning.”

  • Verify that the PerfOrder property (for example, RatesPlan1PerfOrder) has a unique value for plan types
Member

  • Source Plan Type value is not valid for the member

  • Expense Reporting value for this member is not valid

  • Time Balance can only be set to Last in Essbase applications

  • Plan types for a member are the same as or a subset of its parent. For top level members, the parent plan types are the dimension plan types

  • A valid DTS is used based on Period Type selected

  • Check all members of all dimensions of a particular dimension class have a non-null value for a particular property, and that the property value is one of the allowed values

  • Check Exchange Rate type property value based on Data Type Property

  • Check Two Pass Calculation property based on DataStorage Property

  • If more than one member uses an Attribute property, those members are required to be at the same level in their respective hierarchies

Member name validations:

  • Smart List member names cannot have special characters or blank spaces

  • Year member names must be of the format FY10

  • No leading or trailing white space is allowed in member names

  • Must be between 1 and 80 characters

  • Cannot contain special characters or reserved words

  • Cannot start with special characters

  • Cannot be reserved words

  • Cannot match dimension names

  • If Attribute Type is Boolean, the allowed values for member names are either True or False.

Note:

These requirements are specific to Planning applications that use the Plan1, Plan2, or Plan3 plan type. For Planning modules that use other plan types, the requirements may differ. For information on Oracle Hyperion Public Sector Planning and Budgeting, see the Oracle Hyperion Public Sector Planning and Budgeting User's Guide. For information on Oracle Hyperion Workforce Planning and Oracle Hyperion Capital Asset Planning, see the Oracle Hyperion Workforce Planning Administrator's Guide and Oracle Hyperion Capital Asset Planning Administrator's Guide.

Table 51. Profitability Validations

Validation Level Validations
Dimension

  • Root members of Business dimensions must have the ASO and BSO data storage set to LabelOnly.

  • Dimension Sort Order is set for all dimensions in the model, excluding Alias and UDA dimensions, and satisfies the following conditions:

    • A dimension sort order must be set for every dimension in the model, except Alias and UDA dimensions.

      Note:

      The Alias and UDA dimensions are ignored for Dimension Sort Order.

    • The dimension sort order must be sequential.

    • Measures dimension is set to 1, by default.

    • AllocationType dimension is set to 2 by default for Standard Profitability applications only. This dimension does not apply for Detailed Profitability applications.

    • POV and business dimensions are set to 3 or higher.

    • Attribute dimensions are sorted as the last dimensions.

      For example, if you have four attribute dimensions in a sequence of 12 dimensions, the attribute dimensions must be set as 9, 10, 11, and 12.

  • Duplicate members do not exist in the same dimension.

  • POV dimensions must have at least one member.

  • Attribute dimensions can only be associated with sparse dimensions.

  • Attribute dimensions must satisfy the following conditions:

    • Only a Level-0 member from the attribute dimension may be assigned as an attribute.

    • Attributes may be assigned only to members at the same level in the base dimension.

    • Attribute dimensions can only be associated with sparse dimensions.
Application

  • The name of the application is 7 characters or fewer, and cannot contain special characters.

  • At least one dimension must be set to POV type. Up to 4 dimensions may be marked as POV dimensions. Only one occurrence of each POV dimension class is allowed.

  • At least one business dimension must be defined

  • At least one Measures dimension must be defined

  • At least one AllocationType dimension must be defined for Standard Profitability applications. This dimension type does not apply for Detailed Profitability applications.

  • There is only one dimension of type “Account”

  • There is only one dimension of type “Entity”

  • Application names do not contain Essbase special characters and reserved words
Member

  • Allow only ASO and BSO data storage to be defined

  • No shared members are allowed in the first Gen 2 member

  • A Shared Member must always appear after its corresponding Base Member in the outline order.

  • NoMember must be set as the last generation 2 member for all business dimensions, and must be set to Ignore (~) in the Property Grid.

    Note:

    This requirement does not apply to POV, Measures, AllocationType, Alias, UDA or Attribute dimensions.

  • Shared members must reside in a Dynamic hierarchy, using one of the following methods:

    • The Gen 1 member is HierarchyType=dynamic

    • The Gen 1 member is HierarchyType=HierarchiesEnabled, and the Gen 2 ancestor of the shared member is HierarchyType=dynamic

  • Ensure no duplicate member names or aliases exist for any members within the dimension

  • Member names do not include Essbase special characters and reserved words

Table 52. Common Essbase ASO and BSO Validations

Validation Level Validations
Dimension

  • Attribute dimensions can only be associated with only one other base dimension.

  • Verify that the Dimension Sort Order is sequential, does not have duplicates and the Attribute dimensions are at the end

  • Verify that all smart lists are referenced.

  • Verify that smart list dimensions are not empty.

  • Generation names and level names must be unique in an outline (application). Names cannot be the same as other generation or level names. In addition, names cannot be the same as a member, dimension, Alias property value, or dimension alias property value.
Application

  • Minimum number of dimensions is 1.

  • Verify that the database name is not empty.

  • Duplicates across the dimensions of the following types are not allowed: Time, Account, Generic, Currency and Country.

  • The application name can contain up to 8 characters (non-Unicode) or 30 characters (Unicode) if the Supports Unicode property is enabled.

  • Application names cannot contain the following characters: space * \ [ ] : , = < > . + ? " ; ' / \t |

  • The application description cannot exceed 79 characters.

  • Dimension names, member names, Alias values, and Alias members cannot exceed 80 characters and cannot contain:

    • Quotes ("), brackets [ ], or tabs

    • Spaces at beginning or end

    • The first character of: @ \ { } , - = < ( ) . + ' _ | .

  • The Database Name property cannot be null.

  • Verify that if the application level TypedMeasureEnabled=false, then Account members cannot have their Type properties set to Text or Date.
Member

  • The Time Balance property for all Account dimension members can only have values of None, First, Average, or Last.

  • Primary members must be present before shared instances.

  • Verify if an Essbase dimension has the AllowDuplicatesInDimension property set to false and yet contains non-unique members. If a non-unique member is found, an error is logged.

  • Verify that all member names and aliases are unique in application or in dimension (per properties set in the outline).

    If AllowDuplicatesInOutline is set to false all member names must be unique. Alias values must be unique within the alias table and cannot conflict with any of the member names. Alias values can be same as the member name.

    If AllowDuplicatesInOutline is set to true uniqueness is checked within the context of dimension. If non-unique members are required in the dimension, the dimension level property AllowDuplicatesInDimension should be set to true.

  • If a shared member has its DataStorage set to ShareData, then its primary reference member must have its DataStorage set to StoreData.

  • If a dimension with an attribute association is set to "Label Only," a warning is displayed indicating that all attribute associations will be dropped.

  • Verify that none of the Smart List members have duplicate values.

  • Verify that Smart List values are only allowed on base (leaf) members.

Table 53. Essbase (BSO) Validations

Validation Level Validations
Dimension

  • Verify that the dimension is not set to allow duplicates and non-unique members.

  • Verify that the Data Storage property set at the dimension level is LabelOnly, NeverShare, or StoreData for dimensions of the following types: Time, Account, and Attribute.

  • Verify that at least one dimension in the cube is set to Dense.
Application

  • Ensures that only one (the maximum number allowed) of the following dimensions types are in the application: Time, Period, Account, Currency, Entity, and Country.

  • Ensures that the Skip property is set when the Time Balance is set for an Account dimension.
Member

  • Top members cannot be shared members.

  • Shared instances of members cannot exist without the primary members.

  • Base/level 0 members cannot have the Data Storage value of LabelOnly for dimensions of the following types: Time, Account, Generic, Currency, Country, and Attribute.

  • Verify that if an Essbase dimension has the AllowDuplicatesInOutline and AllowDuplicatesInDimension property set to false and yet contains non-unique members. If a non-unique member is found, an error is logged.

  • Verifies that the Data Storage property is set to DynamicCalc, DynamicCalcAndStore, LabelOnly, NeverShare, ShareData, or StoreData for members of the following dimensions: Time, Account, Generic, and Attribute.

Note:

For Essbase (ASO) and Essbase (BSO), the majority of validations are performed at deployment.

Table 54. Essbase (ASO) Validations

Validation Level Validations
Dimension

  • If “Multiple Hierarchy” is enabled for a dimension, the Data Storage property must be LabelOnly.

  • The Data Storage property at the dimension level can be LabelOnly, NeverShare, or StoreData for dimensions of the following types: Time and Account.

  • Attribute dimensions cannot have shared members.
Application

Verifies that there is only one Time or Account dimension.
Member

  • Top members cannot be shared members.

  • The primary occurrence of each shared member also exists in the application.

  • Duplicates across dimensions are controlled by a flag at the application level. There is also a flag at the dimension level that indicates that duplicates in the dimension are allowed. If duplicates are not allowed at the application level, then duplicates are not allowed at the dimension level.

  • Issue a warning if hierarchy depth is more than 10 levels.

  • If “Multiple Hierarchy” is enabled, member formulas are supported for Dynamic Hierarchy members, and Dynamic dimensions.

  • Stored hierarchy dimensions cannot have shared members. Stored hierarchies within a multiple hierarchies dimension can have shared members, except that the first hierarchy in a dimension where multiple hierarchies are enabled cannot contain a shared member. A shared member cannot be in the same Stored hierarchy as it's primary member. A stored hierarchy can only have one copy of a shared member.

  • A stored hierarchy can contain a shared instance of a dynamic hierarchy member only if the dynamic hierarchy member is a level-0 member without a formula.

  • The first hierarchy in a multiple hierarchies enabled dimension must be a stored hierarchy.

  • A shared member may not be found before the primary instance of the member. If any are found, an error message is logged for each.

  • The Data Storage property can only be LabelOnly, NeverShare, ShareData, StoreData for members of the following dimensions: Time, Account, and Generic.

  • Attribute members can only have the Data Storage property set to DynamicCalc.

  • Base/level 0 members cannot have the Data Storage value of LabelOnly for the following dimension types: Time, Account, Generic, and Attribute.

  • Check to see if the consolidation operation in stored hierarchies is always set to add(+). If the DataStorage property is LabelOnly then ignore(~) is allowed.

  • Formulas are valid only in dynamic hierarchies

  • LabelOnly members in stored hierarchies should have label only ancestors.

    Note:

    Essbase also requires all members at the same level to be LabelOnly.