1. Administering Financial Consolidation and Close
  2. Managing Applications
  3. Metadata Validation Messages

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 strongly recommended that you apply the validation error recommendations to minimize risks of data integrity issues and take advantage of best practice performance considerations.

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.

Creating Shared Members for FCCS_No Data Source Member Is Not Allowed

Creating shared members for the FCCS_No Data Source member is not allowed.

Example validation message:

Shared instances for FCCS_No Data Source are not allowed.

Resolution:

Remove the shared instances of the FCCS No_Data Source member.

FCCS_OpeningBalance Cannot Be Shared in the ClosingBalance Hierarchy

In the Movement dimension, if the FCCS_OpeningBalance is Shared in the ClosingBalance hierarchy, a validation error will occur, since this can occur to errors with exchange rates during translation and consolidation.

Example validation message:

FCCS_OpeningBalance should not be Shared under FCCS_ClosingBalance.

Resolution:

Make sure that FCCS_OpeningBalance is not Shared under the FCCS_ClosingBalance hierarchy.

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.

Level Zero Member Data Storage Types Must Be Valid

The Data Storage type must be valid for all Level Zero 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 the member has 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.

All Parent Members in the Multi-GAAP and Custom Dimensions Should Be Dynamic Calc Data Storage

The Parent members in the Multi-GAAP and Custom Dimensions should have the Dynamic Calc Data Storage property.

If they are not set to Dynamic Calc, a Warning message is displayed to alert you that this issue might cause problems in the application.

Only Members with Data Storage Dynamic Calc Should Be Set to Two Pass Calculation

A non-Dynamic Calc member must not be set with the Two Pass calculation property.

For Hybrid applications, it is recommended to use Solve Order instead of Two Pass calculation.

Intercompany Dimension Level Zero Members Should Not be Set to Dynamic Calc

In the Intercompany Dimension, if you edit Level Zero Intercompany members and set the Data Storage to Dynamic Calc without a member formula, a validation error will occur.

Level Zero Members Should Not Be Dynamic Calc Without Formulas

Any valid Level Zero (0) Dynamic Calc member must have a valid Member Formula.

Example validation message:

Level 0 members should not be Dynamic Calc without member formulas.

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.

Intercompany Elimination Members and Total Eliminations Members Should Not Be Moved in the Hierarchy

The Intercompany Elimination member should not be moved out of the Total Eliminations hierarchy.

The Total Eliminations member should not be moved out of the Total Data Source hierarchy.

Example validation message:

Intercompany Elimination member should not be moved outside of Total Eliminations.

Total Eliminations member should not be moved outside of Total Data Source.

Resolution:

Move the Intercompany Elimination or Total Eliminations members to the correct location in the hierarchy.

Custom Member Formulas Should Not Be Added Under the Total Balance Sheet Hierarchy

Custom Member Formulas should not be added under the Total Balance Sheet hierarchy. If you create a Dynamic Calc member with a member formula in the Account dimension Total Balance Sheet hierarchy, the system displays an Error message during metadata validation to alert you to potential issues with Balance Sheet calculations.

In the Data Source Dimension, Each Entity Should have a Corresponding S_ Member when Ownership Management is Enabled

When you enable Ownership Management in an application, new seeded S_Entity members are added in the Data Source dimension. If an S_Member is missing for an Entity, a validation error will occur, and you will need to create a Data Source member. For example, if you have an Entity member named TestEntity, you need to create a Data Source member named S_TestEntity under FCCS_Source Entities.

Note:

The only exception is the FCCS_Global Assumptions member.

Example validation message:

S_ Data Source member is missing for this Entity member. Please create a Data Source member S_ENTITYNAME under FCCS_Source Entities.

Resolution:

Create a Data Source S_EntityName member under FCCS_Source Entities.

Equity Pickup Movement Member Cannot Be a Parent Member

In the Ownership Equity Pickup feature, for Movement members, you cannot select Parent members under the FCCS_Mvmts_Subtotal hierarchy. The predefined list of Movement dimension members that can be selected are the Level 0 members of the FCCS_Mvmts_Subtotal hierarchy.

Example validation message:

XXXX is not a level 0 descendant of Movements Subtotal.

Resolution:

For Equity Pickup, in the Movement dimension, select only Level 0 members of the FCCS_Mvmts_Subtotal hierarchy.

Validation for the Account Dimension Solve Order

This validation is applicable only when you are using the Dense Sparse Optimization option with Period and Movement as the Dense dimensions. The Solve Order property for all members with the storage type as Dynamic Calc in the Account dimension should be 58.

Example validation message:

Solve Order for this member should be 58.

Resolution:

Set the solve order property for the specified member as applicable.

Validation for the Consolidation Dimension Solve Order

The following validation does not apply when you use the Dense Sparse Optimization option with Period and Movement as the Dense dimensions.

If Advanced Consolidation is not enabled, set the solve order for the following members to 26.

  • FCCS_Contribution Total

  • FCCS_Contribution

  • FCCS_Parent Total (based on feature enablement)

  • FCCS_Proportion

If Parent Input is enabled, set the solve order for the following members to 26.

  • FCCS_Contribution Total

  • FCCS_Contribution

  • FCCS_Parent Total

Example validation message:

Solve Order for this member should be 26.

If you are using the Dense Sparse Optimization option and the Parent Input feature is enabled, the solve order property for the FCCS_Parent Total and its parent members should be 51.

If you are using the Dense Sparse Optimization option, but have not enabled the Ownership Management feature, the solve order property for the FCCS_Proportion member and its parent members should be 51.

Resolution:

Set the solve order property for the specified member as applicable.

Validation for the Data Source Dimension Solve Order

The solve order property for the following members should be 28. It does not apply when you use the Dense Sparse Optimization option with Period and Movement as the Dense dimensions.

  • FCCS_Total Data Source

  • FCCS_TotalInputAndAdjusted

  • FCCS_Total Eliminations

Note:

You should not change the solve order on the FCCS_Total Eliminations member in the Data Source dimension.

Example validation message:

Solve Order for this member should be 28.

Resolution:

Set the solve order property for the specified member as applicable.

Validation for the Movement Dimension Solve Order

Solve Order Values for the Standard Option (Account as Dense dimension)

If you are not using the Dense Sparse Optimization option, the solve order property for the following members should be 53:

  • FCCS_OpeningBalance_Cash

  • FX_Total_NonCash

  • FCCS_ClosingBalance_Cash

The solve order for FCCS_ClosingBalance_Variance should be 55.

The solve order property for the following members should be 25.

  • FCCS_Mvmts_Operating

  • FCCS_Mvmts_Investing

  • FCCS_Mvmts_Financing

  • FCCS_CashFlow

  • FCCS_CashFlow_Operating

  • FCCS_CashFlow_NetIncome

  • FCCS_CashFlow_AdjustmentsToNetIncome

  • FCCS_CashFlow_DepreciationAndAmortization

  • FCCS_CashFlow_NetAssets

  • FCCS_CashFlow_AccountsReceivable

  • FCCS_CashFlow_Inventories

  • FCCS_CashFlow_OtherCurrentAssets

  • FCCS_CashFlow_AccountsPayable

  • FCCS_CashFlow_OtherCurrentLiabilities

  • FCCS_CashFlow_Investing

  • FCCS_CashFlow_Acquisitions

  • FCCS_CashFlow_Disposals

  • FCCS_CashFlow_CapitalExpenditures

  • FCCS_CashFlow_ProceeedsFromSalesOfPPE

  • FCCS_CashFlow_OtherInvestingActivities

  • FCCS_CashFlow_Financing

  • FCCS_CashFlow_IssueOfStock

  • FCCS_CashFlow_ProceedsFromDebt

  • FCCS_CashFlow_RepaymentOfDebt

  • FCCS_CashFlow_OtherFinancingActivities

Example validation message:

Solve Order for this member should be 25.

Solve Order Values for the Dense Sparse Optimization Option

If you are using the Dense Sparse Optimization option, the solve order property for the following members should be 59:

  • FCCS_CashChange

  • FCCS_OpeningBalance_Cash

  • FX_Total_NonCash

  • FCCS_ClosingBalance_Cash

  • FCCS_ClosingBalance_Variance

For the following members, if the Control-to-Date View Storage option is enabled, set the solve order to 53.

  • FCCS_CashChange

  • FCCS_OpeningBalance_Cash

  • FCCS_FX_Total_NonCash

  • FCCS_ClosingBalance_Cash

Resolution:

Set the solve order property for the specified member as applicable.

Validation for the Period Dimension Solve Order

If you are using the Dense Sparse Optimization option with Period and Movement as the Dense dimensions, the solve order for the following members should be 53.

If you are not using the Dense Sparse Optimization option, the solve order property for the following members should be 52.

  • YearTotal

  • HY1

  • HY2

  • Q1

  • Q2

  • Q3

  • Q4

Example validation message:

Solve Order for this member should be 52.

Resolution:

Set the solve order property for the specified member as applicable.

Validation for the View Dimension Solve Order

If you are using the Dense Sparse Optimization option with Period and Movement as the Dense dimensions, the solve order for the following members should be 53.

YTD, HYTD, QTD, YTD_RULE, HYTD_RULE, QTD_RULE

If you are not using the Dense Sparse Optimization option, the solve order property for the following members should be 27.

YTD_RULE, HYTD_RULE, QTD_RULE

Example validation message:

Solve Order for this member should be 27.

Resolution:

Set the solve order property for the specified member as applicable.