I discovered this technique while I was working with the newly released workforce app. Unfortunately, the client I was working with did not understand the value of the OOB content and I was asked to customize the application. Over the last few years, this approach has changed and OOB is my goto approach and I enhance only if needed. The point of this article though is not really about workforce calculations but how Smart Lists can be used more effectively in calculations.
Over the last month, I had to customize almost every feature in the EPBCS workforce planning application for a client. I have much to write about that experience but this one is my favorite. Do you want your Smart Lists to be dynamic but do not want to write long if/then statements for every possible value in the lists? Well, read on…..
When I first saw the feature to build a Smart List from metadata I started to get excited about the potential to use that in a calculation. After going through the Workforce app in detail I have seen the light. If you are not familiar with that module yet it basically has three plan types. The first two BSO cubes are for the plan and another one is for the rates. When you create a TBH it performs a lookup in the rate cube to get default values. Here is a simplified example of how the functionality works so you can use it in your applications as well.
I built a 2 database application one called FINPLAN and the other called RATES.
Here is the dimensionality of the two plan types.
The idea is that a user can enter in information in the Finplan cube and the system will do a look up in the rate cube based on a region they have selected in the Smart List. Here is a quick preview of the form.
Creating the Smart List
Once the dimensionality is set up correctly you need to set up a Smart List that is based on your application metadata. I created a Smart List named REGIONS and configured it to point to the level 0 members of the regions dimension.
This creates a dynamic list based on the application metadata. Notice on the Entries tab the id for the members in the list. If you know the backend of planning this is the OBJECT_ID from the HSP_OBJECT table, planning is going to use this identifier in your calc scripts to identify the member in Essbase.
After the list is created I assign it to the account Opportunity_Region in the FINPLAN Cube.
I then built a web form against the RATES database to store the rates at the No Entity member and at the Regions.
I am just storing a monthly rate by region in this cube.
Here is a quick view of it working:
This is where the magic happens. Basically, we want to pull a value from the rate cube using the value assigned to the Smart List in the planning cube.
Here is the calculation:
Not as pretty version :
FIX (FY18,Plan,Working,USD,"No Entity",@RELATIVE("OPP",0)) /*Define a variable to assign the Smart List value to*/ VAR SLVal; /*Opportunity Overhead cost, lookup in Rate cube*/ "OVERHEAD_COST"( /*Assign Smart List Value*/ SLVal="OPP_REGION"->"BegBalance"; IF( NOT (@ISMBR ("BegBalance") ) ) /*Only Run on Months*/ IF( (SLVAL <> #MISSING) AND ("VOLUME"->"BegBalance" <>#MISSING)) /*Check if there is a Smart List Value and a volume*/ @XREF(_RATES_,"OVERHEAD_RATE","No Entity",@CONCATENATE("HSP_ID_", @Name(@hspnumtostring(SLVal)))); /*apply Rate cube value*/ ENDIF ENDIF ) ENDFIX
If you look closer at the Xref formula you will notice@CONCATENATE(“HSP_ID_”, @Name(@hspnumtostring(SLVal))))
Lets break this down.
- The SLVal was assigned from the Smart List value and it is populated with the OBJECT_ID of the member in PBCS.
- The CDF hspnumtostring converts the numeric id to a string
- The @Name function really makes sure its a string. Probably redundant.
- Then its concatenated with “HSP_ID_”
Using the NY member as a value it would create a member that looks like this.
Behind the scenes Planning then can use that definition to translate it into a member that Essbase can read. I think with an alias table in Essbase.
The Xref formula uses txt values but if you need to convert this into an Essbase member then wrap the formula around an @MEMBER like this:
You will only be able to use this in calculations and not in a fix statements since you need the data value of the Smart List to drive the formula. I tried to get it to work in a member formula and was not successful, but I only spent a few minutes on it.
This is a pretty nice enhancement that is a key to understand if you need to troubleshoot or enhance Workforce in EPBCS. Plus you can utilize it in your own applications to make your scripts and applications more dynamic and focused.
Here is the LCM if you need it.