Converting Period and Movement Dimensions to Dense Dimensions

When you create an application, you can select an option to make Period and Movement Dense dimensions, or use Account as the Dense dimension. You can also migrate an existing application to one with the Period and Movement dimensions as Dense dimensions. The migration utility is available from the Application Overview screen. When you create or migrate an application with Period and Movement as Dense dimensions, the system makes the required changes to seeded members and member formulas.

Note:

This option applies only to applications that are running on Hybrid-enabled Essbase.

Creating an Application with Period and Movement Dimensions as Dense

When you create an application, the Make Period and Movement Dense option is selected by default. If you want to create an application with Account as the Dense dimension, uncheck this option.

See Application Feature Descriptions.

Converting Applications with Account as Dense to Period and Movement as Dense

Pre-Migration Steps

Before you start the migration process, you must complete these actions:

• Ensure there are no metadata validation errors.
• Ensure there are no pending metadata changes and that Refresh Database has run successfully.
• Make a full backup of the application.

  Note: The Lifecycle Management backup process does not include the Workbench data for Data Management. However, you can take a snapshot of the Workbench and the entire Data Management environment when performing a clone, or by using EPMAutomate commands, or by running the scripts from the UI.

  See these EPMAutomate commands:

  • exportDataManagement

  • importDataManagement

• Disable scheduled jobs and reschedule the automatic maintenance window.
• Remove all Solve Order customizations.

Migration Steps

1. On the Home page, click Application, and then Overview.

2. From Actions, select Make Period and Movement Dense to launch the Migration wizard.

3. Confirm that you have completed the pre-conversion actions before starting the migration process, then click Next.

   
4. Review the summary of changes.

   If you have deployed Configurable Consolidation rules, the system warns you that you must review them after conversion.

   

5. Click Launch to launch the migration process.

   When the process starts, all existing users will be logged off and all active requests will be stopped.

6. Wait for the migration process to finish, then log out of the application and log back in.

Key Metadata Changes

The migration process results in the following changes in metadata:

View Dimension

The FCCS_YTD, FCCS_QTD, FCCS_HYTD, FCCS_YTD_RULE, FCCS_QTD_RULE and FCCS_HYTD_RULE members are Dynamic Calc.

The _RULE members and the corresponding without _RULE members have the same member formula.

Movement Dimension

All seeded Parent members are Dynamic Calc.

Movement is now a Dense dimension.

Period Dimension

Period is now a Dense dimension.

Data Source Dimension

These Data Source dimension members are no longer used for consolidation after the migration process:

• FCCS_RateOverride (Parent member: FCCS_SystemTypes)

• FCCS_AmountOverride (Parent member: FCCS_SystemTypes)

• FCCS_PCON (Parent member: FCCS_SystemTypes)

Application Details

Applications with Period and Movement as Dense dimensions store only Periodic data.

You should not use the Update View Calculations rule with these applications.

When you create a new application with Period and Movement as Dense dimensions, you cannot enable the Control-To-Date storage option, and the Control To-Date View rules will not be available (Consolidate by selected View, Force Consolidate by selected View, Translate by selected View, Force Translation by selected View).

When you migrate an existing application that has Account as the Dense dimension and the Control-To-Date option enabled, to one with Period and Movement as the Dense dimension, the Consolidate, Translate, respective "by selected View" and respective Forced rules (based on Single or Multiple Currency) will be displayed. All of these rules will generate only Periodic data.

Watch the following video to learn more about converting Period and Movement dimensions to Dense:

Converting Period and Movement Dimensions to Dense in Oracle Financial Consolidation and Close.

Post-Conversion Steps after Converting an Application to Period and Movement as Dense

After you convert an application to one with Period and Movement as Dense dimensions, perform these steps:

• Review all of your user-defined member formulas, configurable calculation rules (also known as insertion points), and On-Demand rules to make sure they are written following the best practices. You do not need to review the seeded member formulas.
• Recreate any of your saved Data Export jobs to use Period or Movement (Dense dimensions) instead of Account as a driver dimension.
• Follow the guidelines in Exporting Data from a Dense/Sparse Optimized (DSO) Application to modify existing Data Integrations that export data from the migrated DSO application.
• The Solve Order for seeded and user-defined members is changed when the migration utility is run. As part of the migration process, the Solve Order of the existing Parent Account members is automatically set to 58. Make sure to set the Solve Order to 58 for any new Parent Account members that are added in the future.
• You must review and modify the Solve Order of these Account, Movement, and Data Source members. See Setting the Solve Order.

  • Account: All Parent account members must now have the Solve Order set to 58.

  • Movement: All Parent Movement members must be Dynamic Calc. Remove the Solve Orders for any of the members that you have previously set.

  • Data Source: Remove the Solve Orders for any of the members that you have previously set.

  Note:

  Review Solve Order for DSO per this documentation for better retrieval performance: Troubleshooting Financial Consolidation and Close Retrieval Performance.

  If a member formula contains another Dynamic Calc member, increment the Consol Solve Order for the member formula to 1 higher than the member with the largest Consol Solve Order referenced in the formula.

  If a member is a parent Dynamic Calc member and data is retrieved at YTD, review your Solve Order on the member to make sure it is higher than the YTD member.

• After conversion, reconsolidation of already consolidated periods is not required. The YTD data is removed during the DSO conversion. When previous periods have been locked, it should be a best practice not to unlock and reconsolidate.

Best Practices for Writing Member Formulas When Period and Movement are Dense Dimensions

• Use @NONEMPTYTUPLE(); directive before writing a formula containing Sparse cross- dimension references.

• Avoid returning direct constants. Instead, append constants with:

  + "Scenario"->"Years"->"Period"->"Entity"->"Account"->"FCCS_Entity Input"->"FCCS_No Intercompany"->"FCCS_No Data Source"->"FCCS_No Movement"->"FCCS_Periodic"-><No members of your custom dimension>

  Example of Original Formula

  
  
  

  Example of Modified Formula

  
  
  

• Avoid setting leaf Dynamic Calc Account members with formulas or Dynamic Calc Account parents as Two Pass calculation. Instead, use Solve Order. The Two-Pass calculation option will calculate Account as the last dimension, which may sometimes be unnecessary.

• Avoid using functions mentioned in this topic inside the member formula:https://docs.oracle.com/en/cloud/saas/enterprise-performance-management-common/ecalc/working_with_essbase_hybrid.html. These functions are not supported by Hybrid Essbase.

• Review any formula that can be calculated after an aggregation such as a ratio. Dynamically calculate with a high solve order.

• Review any formula which must be computed before aggregation. If performance is slow, consider making it a stored member and use a calculation script.

• Review any formula that requires data to be retrieved from many data blocks such as a rolling forecast. If performance is slow, consider making it a stored member and use a calculation script.

• Avoid returning #MISSING in formulas.

  
  
  

Best Practices for Writing Custom Rules

Review the general best practices for writing custom rules, and apply the same concepts for an application in which Period and Movement are Dense dimensions.

• In rules where a Movement member is used as an Anchor block, you must change the Anchor member to a Sparse dimension member.

• Parent Movement members can only be Dynamic Calc and not Never Share. In any rules where there is a FIX statement on a Parent Movement member, the Parent member must be changed and only a Level Zero member must be used.