-
6.01-03 Revision documentation
If you need a broader description of revisions, create a normal list (Non Production Data) and then house the revision details in a module with other fields such as Approved date User Story, Developer, Tested date, Sign off date etc. Best Practices article: Revision Tag Documentation
-
6.01-02 Create a Revision Tag at least once a day
During periods of intense development, ensure that revision tags are created regularly and tested against a "shell" model Best Practices article: Revision Tag Best Practices
-
6.01-01 Create a Naming standard
Be consistent with how you name your revisions. It is advised to use a Major.Minor nomenclature (e.g. R1.01, R1.02, R2 etc.). Remember, the description is permanent and cannot be changed - Be careful!
-
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
-
5.07-04 Get the correct format
Get the data from IT in the correct format as well as the correct granularity Related to Rule: 5.04-06 Import the correct granularity
-
5.07-03 Flat lists for data export
Use the flat list structures to create modules and views for downstream exports
-
5.07-02 No Analytical modules
Try and keep Analytical modules out of the Hub
-
5.07-01 No Hierarchies
There should be no need for composite list hierarchies in the Hub. They can be built to "test" the actions, but after testing they should be deleted Exceptions: 5.07-01a Validation purposes: If data is needed to be consolidated to check against source systems, although the flat modules with attributes can be used to sum…
-
5.06-02 Delete unwanted sources
For one off imports, or when import sources are no longer required, delete the sources to keep the source list tidy
-
5.06-01 Naming Convention
Rename the import sources as soon as possible. For a saved view include the module name (e.g. module.saved view). For model imports, include a shorted version of the model name (e.g. model_module.saved view) Best Practice article: Naming Convention
-
5.05-04 Ensure view filters are optimized
Only use one filter criteria...If more are needed, combine them into one line item Related to Rule: 4.02-01 Use efficient filters Best Practices article: Filter Best Practice
-
5.05-03 Split views for List and Module imports
Create two views from a source module. One for the import to the list (using name, code and parent), and a view for the attributes to the associated System module Related to Rule: 5.05-02 Only include what is needed
-
5.05-02 Only include what is needed
Only include the line items that are required for the import. Create multiple views if the module is used for different imports. The number of columns in the view does affect the speed of the import. The fewer the columns, the faster the import will be
-
5.05-01 Naming Convention
Keep it simple. Export, Build etc. There is no need to include the module name in the view name Best Practice article: Naming Convention
-
5.04-10 Unify the date format
Use a generic date format (e.g. YYYYMMDD) whenever possible to simplify the imports and remove the need for date mismatches and manipulations Best Practices article: Untangling Anaplan Time Mapping in Imports
-
5.04-09 Always use saved views as import sources
Modules and saved views should be used as the source for other imports Best Practice article: Filter Best Practice
-
5.04-08 Never use a list as an import source
Import sources should always be done from a module view. This allows for filtering and only including the elements required for each import
-
5.04-07 Import using the correct formats
Line items holding the Imported line items should reflect the data. List formatted, numbers, and dates. Don’t use text (unless it is a true text field)
-
5.04-06 Import the correct granularity
Only imported data at the granularity needed. There is no need to bring in transactional data at a weekly level when Planning happens at the month level
-
5.04-05 Pre aggregate in the source
Wherever possible, aggregations should be done in the source system. This is likely to reduce the size of the import file meaning faster imports
-
5.04-04 Only include the fields that are needed
Use the Ignore field if there are any unwanted fields in the source data
-
5.04-03 Data or Time period should not be part of the unique row
Consider what actually makes the row unique; include only attributes in the key, not data fields or dates Related to Rule: 1.05-11 Do not embed Numeric values or Dates within the Code of a list Best Practice article: Data Hubs: Purpose and Peak Performance
-
5.04-02 Create separate files for attributes and data
The data file should have the key and values based on the dimensions. Non dimensional data should be in a different file Related to Rule: 5.04-01 From source system, create a code defining all attributes Best Practice article: Data Hubs: Purpose and Peak Performance
-
5.04-01 From source system, create a code defining all attributes
Ideally, this would be a separate file that is unique vs. using the same file for the transactional load Exception: 5.04-01a Code is >60 characters: If the code is >60 characters, you will have to use combination of properties Related to Rule: 5.04-02 Create separate files for attributes and data Best Practice article:…
-
5.03-01 Remove unwanted sources
For one off imports, or when source models are no longer required, delete the source model to keep the list tidy
