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.