Today I will dive straight into something that I think is quite useful for PBCS implementations.
PBCS enables you to design forms to restrict row dimension members using user variables. For example, lets say a manager is responsible for a particular department and is only interested in entering data for this department, as PBCS is multi-dimensional in nature, the user variable can be set by the manager and the forms can be built to show the rows for that particular department. If this feature wasn’t available, Department would have to be a separate dimension to enable the display of the data by selection of the manager to the Department. User Variables give us that flexibility to display data by selections.
Whilst this an awesome feature, we have the following requirements we want to address in a neat and clever solution:
- We want our business rules to do the same, only calculate data based on the user variable selection (this ensures only the data the user is interested in is calculated, always think performance).
- We want our business rules to run on save from the form and without prompting for entry from the user (IE. Use the User Variable as the restricting value without prompting)
The How To
(Covers BR Variable & Planning Function Approach)
- Setup a User Variable that you would like to use to restrict forms and business rules. Tip: if using a business rule variable approach ensure there are no spaces in the User Variable Name, business rules won’t like the space on run.
- You can skip this step if using Planning Functions to get the user variable direct ([[PlanningFunctions.getUserVarValue(“xyz”)]]), more information on using this planning function can be obtained here. To use BR variables, setup a PBCS Business Rule variable that will point to the User Variable created above (this will be used to restrict calculations to only the required user selection of the variable from the PBCS front end).
- If using a BR Variable, you need to update your Business Rules to Restrict the Calculation on the Business Rule Variable that points to the user variable created in Step 1 for its value (Your overall Fix statement will use this variable to restrict the calculations). Otherwise you can restrict using the Planning Functions to get the user variable direct ([[PlanningFunctions.getUserVarValue(“xyz”)]]), more information on using this planning function can be obtained here.
- Build the forms and restrict the selections on the rows to use the user variable in Step 1.
- If using a BR Run Time prompt, ensure to not select “Use Members on Form”, but ensure the “Hide Prompt” is selected for the forms where you want to calculate using the user variable. Selecting “User Member on Form” this will cause the rule to prompt user for entry due to confusion resulting from multiple members from that dimension on the form.
If you have found what you seek here then great, if you haven’t but have found something useful then great also, if not then I hope you find what you seek and wish you luck on your search for knowledge. Like a Jedi you are in search of knowledge and I wish the Force is with you on your journey.
The Force is forever with you!!
When using user variable driven calculations, it’s not necessary to even define a RTP. You can directly pick up the level 0 members of user variable by using [[PlanningFunctions.getUserVarValue(“xyz”)]] function. This also allows you to overcome the restriction of not having space in user variable name.
LikeLiked by 1 person
Thanks for sharing this Navan that is great feedback. I will update the post to reflect using this. Always good to simplify solutions.
I have a query as below:
I want to have the user variable value to be defaulted to a particular member each time when the user open the form instead of picking the recent user variable value.
Can suggest any thing on this?