-
1.05-01 Naming Convention
Hierarchies should be prefixed with a letter signifying the name of the hierarchy and a number indicating the level. e.g. P1 Product Category, P2 Product Family, P3 Products. The is no need to add "L" as a prefix to lists Related to Rule: 1.08-01 Don't use Emojis Best Practices article: Good Practice Naming Conventions…
-
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…
-
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 i.e. Module.Line Item Exceptions: * 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…
-
1.05-04 Numbered List should always have a code
If you are 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 is no code in the source, you will have to use combination of properties. Try and avoid if possible as this is slower to import and…
-
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 not recommended to create a separate list purely for this purpose; use an existing list if possible Questions on this topic? See 1.05-05…
-
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 Questions on this topic? See 1.05-06 Only use Top Level for ultimate parent in our Planual forum.
-
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-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, financial reporting hierarchies are valid uses of non-composite lists Questions on this topic? See 1.05-08…
-
1.05-09 Create Placeholders in general lists
Add place holders to organise General Lists and add Subsets and Line Item Subsets at the bottom or 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 is Ok to use emojis for the placeholder lists Related to Rule: 1.08-01 Don't use…
-
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…