Planning web-forms through the Smart View Planning connection often have better formatting than an Essbase ad-hoc connection. Planning web-forms have the blue-shaded metadata, the grey-shaded non-writable data cells, and the yellow-shaded writeable data input cells. In addition, the form layout (POV, Page, Row, and Column members) generally focuses on a business requirement. But there are some formatting options that were defined in the web-form that didn’t come through, such as bolded column or row separators.
Oracle has been pushing more utility and functionality into the Planning Smart View connection over the last few years, such as metadata management via Smart View. One such feature, which we will explore in this post, is the ability for the user to apply Excel like formatting to the metadata and data cells of the planning form. Now the user has the ability to apply bold typeface, italics, custom fonts, highlighting and more.
Below is an example of how this feature works. If you set certain areas to bold typeface (the “Labor” row and all the Period members) then save the format, it will be connected to that form.
To apply your custom formatting, select the “Apply” dropdown, and choose “Custom Style” as shown below. Now whenever you look at this form (as long as the Custom Style settings are applied) you will see the formatting as you have defined it.
One issue I have encountered is how the Planning application stores this custom formatting. After using this feature, the first migration I performed through LCM encountered issues. The form failed to import, and when I clicked on the “failure” to see the errors; there were two.
- “EPMLCM-14000: Error reported from Hyperion Planning”
- “<form name>:- User <userid> does not exist for this application”
Upon investigation, I found that the user’s preferences were stored with the form definition and those preferences were in the form’s xml LCM exported file. You can find it as a tag in the form’s xml “formFormattings” section as seen below.
This will contain the usernames of all users that have saved Custom Styles. Form migrations will fail if one of these users does not exist in the environment that is receiving the import.
I consulted with Oracle Support on the matter, and we were able to identify two different methods to work around this issue. The first is to migrate all of Shared Services security with the forms, as this will ensure these users have the correct access in the receiving environment. This solution is not ideal if you do not want users assigned in lower environments’ for security or testing purposes. The other solution is to edit the form’s xml export and remove all of the contents inside the “formFormattings” section. This will remove any usernames from the form definition, allowing it to import successfully. This is something that can be scripted or completed manually on migrations. In conclusion, the new formatting features in Smart View are perfect for form customization, but be careful of the migration issues that can occur because of them.