Metadata Validation Messages

Metadata Validation checks are applied against specific relationships within metadata in order to warn against situations that can cause data integrity issues, performance issues or other issues. It is recommended that all validation message are cleared to ensure that metadata design problems are not the cause of other problems.

Primary Members Must Exist Before Shared Members

Primary members must exist before shared members ("above" the shared member in the hierarchy) for the following dimensions:

  • Scenario

  • Period

  • Account

  • Intercompany

  • Movement

  • Data Source

  • Multi-GAAP (if exists)

  • User-created Custom dimensions

Example validation message:

Shared member should not exist before the primary member.

Resolution:

Move the shared member to a position below the primary member.

Level 0 Member Data Storage Types Must Be Valid

The Data Storage type must be valid for all level 0 members:

  • Entity, Movement dimensions: Store, Never Share, or Shared

  • Account, Data Source, Multi-GAAP, User-created custom dimensions: Store, Never Share, Shared, or Dynamic Calc

Example validation message:

The Data Storage should be Store Never Share, Shared or Dynamic Calc for Level 0 members.

Resolution:

Change the Data Storage selection as described above.

Note:

Currently the Metadata Validator will display an error for any Level 0 Dynamic Calc members of the Movement Dimension except for seeded members.

In future releases, "Dynamic Calc" will be allowed except for FCCS_Closing Balance hierarchy, as long as they have a valid Member Formula. As a first step towards this change, Dynamic Calc is added to the list of valid Data Storage selection options for Level 0 Movement members in the Simplified Dimension Editor (SUIDE).

Level 0 Members Should Not Be Dynamic Calc Without Formulas

Any valid level 0 Dynamic Calc member must have a valid Member Formula for the following dimensions:

  • Multi-GAAP (if exists)

  • User-created Custom dimensions

Example validation message:

Level 0 members should not be Dynamic Calc without member formulas in Rate data storage.

Level 0 members should not be Dynamic Calc without member formulas in Consol data storage.

Resolution:

Add a valid formula to the Dynamic Calc member, or change the Data Storage properties to Store, Never Share or Shared. For Rate Cube accounts, check whether the account is needed in the Rates Cube. If it is not needed, then delete the account from the Rates Cube using the Dimension Editor, or change "Rates Consol op" to "Not Used for Cube" from the Simplified Dimension Editor.

Parent Members Should Not Have Member Formulas

Parent members should not have Member Formulas for the following dimensions:

  • Entity

  • Account

  • Movement

  • Data Source

  • Multi-GAAP (if exists)

  • User-created Custom dimensions

Example validation message:

Parent member should not have member formula.

Resolution:

Remove the Member Formula from the parent member.

Aggregation Operators for All Children of Dimension Names Must Be Ignore or Never

The aggregation operator should be Ignore or Never if a member is a child of a dimension name.

  • Entity dimension: Ignore for both Consol cube and for Rates cube

  • Other dimensions: Ignore or Never for Consol cube and Ignore for Rates cube

Example validation message:

The Consol Operator for all children of the dimension name should be Ignore.

The Consol Operator for all children of the dimension name should be Ignore or Never.

Resolution:

Change the aggregation operator as described above. Note that the aggregation operators for seeded members should already be correct.

Account Type and Aggregation Operators Must Match

Within the balanced Balance Sheet in the Account dimension, the account types of the parent and child accounts must match with the appropriate aggregation operator. The combination of parent account type and child account type determines whether the aggregation operator should be Addition or Subtraction. Ensuring that the account types and aggregation operator match will ensure that the balance sheet data aggregates properly to a balanced Balance Sheet.

If the “normal sign” (that is, Debit or Credit) is the same for the parent account and child account then the aggregation operator must be Addition. If the "normal sign" is different for the parent account and child account, then the aggregation operator must be Subtraction.

Parent Account Type Child Account Type Aggregation Operator
Revenue (Credit) Revenue (Credit) Addition
Revenue Expense (Debit) Subtraction
Revenue Asset (Debit) Subtraction
Revenue Liability (Credit) Addition
Revenue Equity (Credit) Addition
Revenue Saved Assumption Addition
Expense (Debit) Revenue Subtraction
Expense Expense Addition
Expense Asset Addition
Expense Liability Subtraction
Expense Equity Subtraction
Expense Saved Assumption Addition
Asset (Debit)

Revenue

Subtraction
Asset

Expense

Addition
Asset

Asset

Addition
Asset

Liability

Subtraction
Asset

Equity

Subtraction
Asset

Saved Assumption

Addition
Liability (Credit)

Revenue

Addition
Liability

Expense

Subtraction
Liability

Asset

Subtraction
Liability

Liability

Addition
Liability

Equity

Addition
Liability

Saved Assumption

Addition
Equity (Credit)

Revenue

Addition
Equity

Expense

Subtraction
Equity

Asset

Subtraction
Equity

Liability

Addition
Equity

Equity

Addition
Equity

Saved Assumption

Addition
Saved Assumption Any type Addition

Example validation message:

Account Consol Operator should be Addition based on parent and child account types.

Account Consol Operator should be Subtraction based on parent and child account types.

Resolution:

Change the Account Type of parent or child or change the aggregation operator.

Note that the seeded balance sheet hierarchy must reflect the following structure:

The seeded balance sheet "grouping" account (FCCS_Balance Sheet) must be the first member following the seeded system accounts and exchange rate accounts.

The first child of FCCS_Balance Sheet must be the seeded balanced Balance Sheet top member. Currently either:

FCCS_Total Balance Sheet-Net Asset Approach

Or

FCCS_Total Balance Sheet-Traditional Approach

The aggregation operator for these accounts can be Addition, Subtraction, or Ignore. Ignore is suggested (but not required) unless you intend to report from the "grouping" member.

The aggregation operator for any other children of the FCCS_Balance Sheet grouping should ideally be Ignore but can be Addition or Subtraction if reporting from the "grouping" member is required.

Any descendants of the immediate children of FCCS_Balance Sheet must be "Addition" or "Subtraction" and must match the combination of the child and parent account types.

Note that this validation is applied to all hierarchies within the FCCS_Balance Sheet grouping member (with the exception of the seeded Cash and Non-Cash hierarchy). If you wish to create an alternative hierarchy that is not subject to this validation check, the hierarchy can be placed under the FCCS_Income Statement grouping account.

Parent Store or Never Share Members of a Custom Dimension Should Not Be Used as a Shared Member

Parent members that are Store or Never Share data storage should not be used as a Shared member in the custom hierarchy. Applicable to the following dimensions:

  • Multi-GAAP (if exists)

  • User-created Custom dimensions

Example validation message:

A Store or Never Share primary parent member should not be used as a Shared member.

Resolution:

Remove the shared member from the alternative hierarchy, create a new parent in the alternative hierarchy and share the level 0 members under the new parent.