Planual Rules regarding Lists.
1.05-01 Naming convention
Hierarchies should be prefixed with a letter signifying the name of the hierarchy and a number indicating the level. For example, P1 Product Category, P2 Product Family, P3 Products. There's no need to add "L" as a prefix to lists.
relatedToRule
bestPracticesArticles
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's OK not to have a code, but even then, Y and N can be used as codes. |
1.05-03 Avoid using List Properties
List properties are the same as line items but have many limitations, so keep it simple and have one place for calculations, for example, Module.Line Item.
exception
| 1.05-03a Reference module line items | Where the following exceptions are used, reference module line items through a formula where possible to keep the audit trail valid. |
| 1.05-03b Numbered lists (and related actions) | Assign actions and associated filters require list properties. |
| 1.05-03c Exports | List properties can be used as export labels. |
| 1.05-03d Conditional Page navigation | List properties are needed to facilitate navigation to different dashboards based on the selection in the list. |
| 1.05-03e Dependent drop-downs | List properties are needed to create driver and dependent lists. |
bestPracticesArticles
1.05-04 Numbered List should always have a code
If you're using Create or Assign actions for Numbered lists, try and incorporate a "code creation" action, as part of another process.
exception
| 1.05-04a Combination of properties | If there's no code in the source, you'll have to use a combination of properties. Try and avoid if possible, as this is slower to import and more difficult to use without a code. |
relatedToRule
bestPracticesArticles
1.05-05 Format the Display Name property as a list if possible
Format the Display Name property for Numbered lists as List Formatted, not text. This is more efficient, saves a line item, minimizes text fields, and simplifies mappings. However, it's not recommended to create a separate list purely for this purpose. Use an existing list if possible.
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.
bestPracticesArticles
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 do need to have the totals, look to add intermediate parent “totals” to make the calculations more efficient or use SUM to aggregate for validations.
bestPracticesArticles
1.05-08 Use Composite lists rather than ragged
Composite lists are more flexible and calculate more efficiently so try and "balance" the hierarchies whenever possible.
exception
| 1.05-08a Chart of Accounts or financial reporting hierarchies | Chart of Accounts or financial reporting hierarchies are valid uses of non-composite lists. |
bestPracticesArticles
1.05-09 Create Placeholders in general lists
Add placeholders to organize General Lists and add Subsets and Line Item Subsets at the bottom of the General Lists. This will ensure that Subsets and Line Item Subsets can be easily identified when referring to them in the 'Applies To'. It's OK to use emojis for the placeholder lists.
relatedToRule
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 model save. This will increase the import time. It also removes pre-allocated memory blocks designed to increase efficiency. Use a unique key to update to values rather than delete and re-load. Also consider adding a TRUE field to the data source that will allow you to know which records have been imported.
bestPracticesArticles
1.05-11 Don't 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 usually vastly increase the size of the list and consequently increase the model size and reduce performance.
bestPracticesArticles
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.
bestPracticesArticles
1.05-13 Use Flat lists to store Metadata (in a system module)
Avoid having hierarchies in Data Hub. These should only apply to the main planning models.
