-
1.02-05 Try and avoid a high number of native Versions
Versions have built-in functionality that is not available for normal lists. However, a large number of Versions (e.g. 10+), can have performance implications due to the block structure. Review the need for high number of Versions, and if the native functionality is not critical or needed, consider using a normal list to…
-
4.01-03 Create Output modules when using Custom Views
When staging line items are not needed to be viewed by the page builder, create an output module to be used for generating the Custom View Related to Rule: 2.01-04 Use the D.I.S.C.O. Methodology for Module Design
-
1.01-07 Time Ranges
Use Time Ranges to optimize the modules where the default model calendar is not appropriate. Consider the dimensionality for the data and set up the Time Range accordingly. Best Practices article: Time Range Application
-
1.01-05 Exclude timescale subtotals by default
Turn the "include" settings off by default and only include these if absolutely necessary. These additional settings (Quarter totals, Year to date, Year to go etc.) will be included in all modules with the model calendar as the time dimension. Thus they will perform calculations on these subtotals. Consider if you really…
-
1.06-03 Avoid single item subsets
If possible, try and avoid single item subsets, if there is a top level in the list, a single item subset will always have two members. Consider using a Boolean flag in a SYS module or a LOOKUP line item against the desired item (to avoid using SELECT)
-
1.05-11 Do not embed Numeric values or Dates within the Code of a list
Dates and values are "data" and should not be part of a code. Adding these elements to the code will in most cases, vastly increase the size of the list and consequently increase the mode size and reduce performance Best Practices article: Data Hubs Purpose and Peak Performance
-
1.05-07 Avoid Top Level for large flat lists
The calculation for a top level on a large list cannot be split so as the list grows, the calculation becomes increasingly inefficient. Consider if you really need the total. If you need to have the totals, look to add intermediate parent “totals” to make the calculations more efficient, of use SUM to aggregate for…
-
1.05-06 Only use Top Level for ultimate parent
Only use Top level for lists that will need sums so not Currency codes, or True/False (Indicators), or children in composite lists Best Practices article: Top Level Item and Parent Hierarchy
-
1.02-01 Use "Current" in Version settings
Utilising the Current (and Actual) check box within the Version Settings allows the use of CURRENTVERSION() and ACTUALVERSION() in calculations, in SELECT statements and ISCURRENTVERSION and ISACTUALVERSION() for Boolean checks. Current version also acts like a top level for Versions; if you have a source module with…
-
1.01-04 Consider All Periods
Consider the use of All Periods. This is effectively the Top Level for time and whilst increasing the model cell count very slightly it does allow for flexibility in modelling. This is especially useful if you need to reference the same calculation many times
-
2.04-03 Keep the Default View clean
Keep the default view as is, no hiding line items, filtering, or conditional formatting
-
2.02-19 Don't daisy chain data
Always refer back to the ultimate source if possible, to avoid creating more dependencies than necessary. This allows more parallel calculations to be run increasing efficiency and speeding up calculations Best Practices article: Best Practices for Module Design
-
2.02-17 Put the most common condition first
For formula efficiency, put the conditional with the most common occurrence first in the formula
-
2.02-15 FINDITEM on blanks
Doing a FINDITEM() on blank values is inefficient as the function has to traverse the entire list before it returns a blank. If the majority of the values are not blank, then check for BLANK first: * IF ISNOTBLANK(Line Item) THEN FINDITEM(List, line item) ELSE BLANK If the majority are NOT blank: * If ISNOTBLANK(Line Item)…
-
2.02-05 Create "joins" in smallest hierarchy
If a text string join is needed, create the joins in the smaller lists first to minimize the size of the text strings Related to Rule: 2.02-04 Text Strings Best Practice article: Formula Optimisation in Anaplan
-
2.02-04 Text Strings
Treat text strings with caution. Try and avoid multiple joins and split common joins to separate line items. Make use of IF ISBLANK() when joining text, if the strings are empty set to BLANK. Related to Rule: 2.02-05 Create "joins" in smallest hierarchy 2.03-02 Try not to use TEXT as a format, or limit it as much as…
-
2.02-03 No Repeated expressions
If the expression is repeated in the formula (or other modules), put it on a separate line item. “Calculate once, reference many times”
-
2.01-14 Avoid using Select Levels and filters together
Don't use Select levels combined with filters on the same hierarchy. It is a double filter and inefficient because both will be kicked off. Use one or the other. Setting a Boolean line item in a System module with 'none' as the summary option will often achieve the same result
-
2.01-13 Separate Transaction data from Attribute/Property data
Keep the non-time-based data in a separate module from static attributes Best Practice article: Data Hubs Purpose and Peak Performance
-
2.01-11 Keep the Dimension Order consistent
Ensure the dimension order is consistent among modules. Calculations are faster if the common dimensions are in the same order as the Applies To. The size of the list is not as critical as the order Best Practices article: Dimension Order
-
1.07-02 Line Item subsets for Version Formula
Use Line Item subsets to create different numeric formulae for each version to avoid multiple Ifs Best Practice article: Line Item Subsets Demystified Decreasing the Length of Your Formulas Variance Analysis With Native Versions Made Easy
-
1.05-12 Use formulas to derive properties of the list
Based off the code of the list it should be possible to derive the attributes; Calculating the values is more efficient than storing text fields Best Practices article: Data Hubs Purpose and Peak Performance
-
1.05-10 Never delete list and reload the list as a daily occurrence
Clearing and reloading a list increases the structural changes within a model and will increase the likelihood of a of model save, thus increasing the import time. It also removes pre-allocated memory block designed to increase efficiency. Use a unique key to update to values rather than delete and re-load. Also consider…
-
1.05-02 Always use a code
Using codes is more efficient for loading and using lists so strive to always have a code for lists. This is especially important for numbered lists Exception: 1.05-02a Static non hierarchy lists: For simple static lists (such as Yes/No) it is OK not to have a code, but even then, Y and N can be used as codes Related to…
-
5.07-09 Avoid using a Top Level for large lists of transaction data
Don't create a transaction list with a top level. The calculations will need to sum for all items in the list even if only a single item is added Exception: 5.07-09a Check totals: If a check total of all transactions is needed, but again using the flat attributes modules is preferable Related to Rule: 5.07-10 Add…
-
5.07-10 Add intermediate sub totals to transaction lists
If you need the totals for validation purposes, create intermediate subtotals within the transaction list. This will significantly reduce the calculation load Related to Rule: 5.07-09 Avoid using a Top Level for large lists of transaction data
-
5.07-08 Pre aggregate for downstream exports
It is more efficient to aggregate the data in the hub and then export it, rather than accumulate it through the import to the downstream models
-
5.07-07 Keep Transactional Analysis out of the planning models
Use the Data hub (or another reporting model) to keep detailed transactional data out of the main planning models. Large amounts of historic transactional data can inflate the size of the planning model and lead to reduced performance.
-
5.07-06 Master data should be built by the source system
Try and avoid creating Master Data in the hub. This should really come from the source system(s)
-
5.07-05 Use System modules
Use System modules for filtering data (current period, current FY year, etc.) Related to Rule: 2.01-15 Filters in separate modules Best Practice article: Filter Best Practice Data Hubs: Purpose and Peak Performance