-
2.01-01 Naming Convention
New! The Planual can now be found on the Anaplan Support site. We will be transitioning it off Community in the coming months. 2.01-01 Naming Convention As short as is practical. Use Alpha numeric to help identify modules from long names. There is no need to prefix modules in line with DISCO. It is better to align them…
-
2.01-02 Functional Areas
Use functional areas to categorise modules Questions on this topic? See 2.01-02 Functional Areas in our Planual forum.
-
2.01-03 Add "Dummy" Modules as Separators
Use these to provide sections and ordering to the Modules list, but don't use Emojis Related to Rule: 1.08-01 Don't use Emojis Questions on this topic? See 2.01-03 Add "Dummy" Modules as Separators in our Planual forum.
-
2.01-04 Use the DISCO Methodology for Module Design
Within functional areas, group "like" modules together. Design for the type of module and use the appropriate structures Best Practices articles: Best Practices for Module Design Reduce Calculations for Better Performance Formula-Structure-for-Performance Questions on this topic? See 2.01-04 Use the DISCO Methodology for…
-
2.01-05 Don't Use DISCO as Functional Areas
The DISCO convention is designed to categorise types of modules. Within a functional area you may have multiple types of modules Exception: 2.01-05a Simple models: If the model is simple, DISCO can be used as the naming for functional areas Related to Rule: 2.01-04 Use the DISCO methodology for Module design Questions on…
-
2.01-06 Avoid Using Subsidiary Views
Subsidiary views are difficult to work with and audit. Try and minimise their use especially for calculation modules; create groups of calculation modules instead with like dimensionality Exceptions: 2.01-06a Display on Dashboards for analysis or filtering: Sometimes, to enhance the end user experience, attributes are…
-
2.01-07 Time Settings Module
Create all functions and filters relating only to time in separate modules. They will only re-calculate on model opening and when the time settings change It is best practice to use a separate module for each time granularity (e.g. by week, month, quarter, year etc.) Questions on this topic? See 2.01-07 Time Settings…
-
2.01-08 Each major hierarchy should have a System module
Create a System module to support all standing data and attributes about the hierarchy (all levels). At a minimum have the code and parent as line items Exception: * 2.01-08a: If the hierarchy is not referenced in a formula, as a filter or a selector module on a dashboard then it is not needed Best Practice article: * Best…
-
2.01-09 Use Lookup or Constants Modules
Create a module with no dimensions to hold assumptions for Time, and other "SELECT" values. These are useful for global assumptions and general setting that are used throughout the model. they are also useful within an Application Lifecycle Management (ALM) set up Related to Rule: 2.02-14 Avoid using SELECT Questions on…
-
2.01-10 Calculation Modules
Turn off summary options by default. It is better to use SUM for any downstream aggregation if not all levels are needed Exception: 2.01-10a All aggregation levels are needed: If all aggregation levels are needed, then it is faster to use the native aggregation than use SUM formula Related to Rule: 2.03-01 Turn Summary…