1.01-01 Never use SELECT with Time
This goes against the Sustainable element of PLANS and the hard coding can cause issues when updating the timescales of the
model. Modules with Time formatted items to be used as sums and lookup are the better option
Exception:
1.01-01a Generic Time periods: It is OK to use SELECT with Generic Time periods such as Actual Period, Current Period, YTD, YTG, ALL Periods
Related to Rule:
2.02-14 Avoid using SELECT
Comments
-
Rule 1.01-01: Never use SELECT with TIME This goes against “Sustainable” of PLANS if you wish to use SELECT with TIME.
Use Case: Let’s say we have a source module where we have a time dimension and we want to bring in the annual Revenue for one year into our target module (Ignoring rest of the dimensions)
Here is how it was done in Pre Planual Era
Source Module – Please see below for Screenshot
Target Module: Source Module.Revenue [SELECT: TIME.’FY20’]. We are successfully able to pull the values into our target module.
What is wrong with this method? This is NOT the recommended way of doing things because we have not developed it keeping future in mind. It derails your Sustainability if you hardcode it to one particular year. Imagine what happens when you have hardcoded TIME with SELECT at a number of places.
1. There is no way to track where all it has been used in the model unlike other Lists and Line items where you can see the referencing. You may have to take the export of model blueprint to do the analysis.
2. Yearly roll over process will be high maintenance because every year this has to be changed in the Dev model and pushed to Prod environment and it calls for code review, testing etc.
Here is how it should be done in Planual Way:
Source Module: Please see below for Screenshot
LOOKUP Module: Create a dimensionless module with one line item (at least) which will hold the year for which we are trying to pull the values e.g., FY20 in our case. (Format of this line item has to be Time Period Annuals)
Target Module: Source Module.Revenue [LOOKUP: LOOKUP Module. Time].
Advantages:
There is no need to change the code in yearly rollover activity.
Lookup module can be published on the dashboard for Admin users giving them flexibility to change the year selection.
It doesn’t break S of PLANS
0
Title
- Preface
- PLANS
- Planual Conventions
- Zen of Anaplan
- Chapter 1 - Central Library
- Time
- Versions
- Users and Roles
- Contents
- Lists
- Subsets
- Line Item Subsets
- Emojis
- Chapter 2 - Engine
- Modules
- Formulas
- Line Items
- Saved Views
- Chapter 3 - UX Principles
- Hierarchy of Information
- Smart Grouping
- Reduce Visual Load
- Progressive Disclosure
- Use Consistency and Standards
- Provide Help and Guidance
- Use The Correct Data Type
- Give Users Visibility Into Status
- Match With Real World Scenarios
- Check In With End Uses Frequently
- Chapter 4 - UX Build
- Apps
- Dashboards
- Filters
- Chapter 5 - Integration
- Actions
- Processes
- Source Models
- Imports
- Exports
- Import Data Sources
- Data Hub
- Chapter 6 - Application Lifecycle Management
- Revision Tags
- Production Lists
- Architecture
- Deployed Mode
- Managing Changes During Development
- Chapter 7 - Extensions
- Excel
- PowerPoint