We’ve covered exports and validations so far in this blog series. Our next topic is centered on the ability to create attributes, or properties, in DRM. Some examples of properties include:
– Address information for branch offices
– FEIN numbers and currencies for legal entities
– Account type for accounts in EPM and/or EBS applications
– Properties for mapping local chart of accounts to Global hierarchies
– Start and End dates for Business Units or Locations
– Consolidation operators for Essbase applications
– Security Class for HFM entities
The possibilities are really endless. Properties can be defined as simple user-input, drop-down lists, inherited from a parent or level higher in the hierarchy, lookup based on another property, or even auto-populated using JavaScript. Additionally, properties can be categorized into groups for ease of usability and maintenance. Below is an example of a property definition in DRM.
We can see the name, label (the label is what is presented to end users), description, property level & type, a field for a default value, and data type (e.g. String, Integer, Boolean, etc.) all in the top pane. Also presented are check-box options for defining the property as overridable, list driven, or even hidden from users. In the bottom pane are tabs for property categories (properties can belong to more than one category), lookup table (if defined as a lookup property), list values (if defined as a list property), parameters (for JavaScript derived properties) and constraints (for use with data types allowing constraints).
We could easily spend quite a bit of time explaining all of the various options that DRM properties offer, but for sake of simplicity we’ll stick to more basic and common concepts.
In the below image, we see a list-defined property for Essbase consolidation. We know it’s a list property because the list checkbox is checked. This allows us to enter values into the list tab. The property also has a default value of “Add”. Users can override the default value, but are limited to the list of values presented here.
Our next example displays a lookup property based on the Essbase consolidation property from the prior example. The column on the right labeled result value lists the various values which will be returned based on the lookup key. Also, notice the Hidden box is checked, meaning this property is not displayed to end users.
Guide to Oracle Cloud: 5 Steps to Ensure a Successful Move to the Cloud
Explore key considerations, integrating the cloud with legacy applications and challenges of current cloud implementations.
Our last example shows a the same property, but using JavaScript rather than a lookup table. We can see the Parameters tab contains the JavaScript logic. The script in this example is using both variables and comments within the script. A great enhancement over the native DRM formula language that administrators and developers may be more familiar with in practice.
Last, but certainly not least, is the ability to test the logic directly within the property definition. To test, a user must first select a node from the ellipsis in the Selected Node field below the field containing the JavaScript. Then, by simply clicking the evaluate button (above the JavaScript field), users can see the results of the derivation in the Evaluation Results box below.
Now let’s see how the properties from our examples can be used within the application. We’ve selected the Essbase property category and can see that the Consolidation property is set to the default value of “Add”. The Consolidation Code property displays the “+” operator based on the Lookup table that we had defined. Notice also that the Consolidation Code property is grayed, this is because the property is not overrideable. (We deselected the Hidden checkbox on the property definition so that we could view the property in this context)
If we change the Consolidation value to “Subtract”, the Consolidation Code property automatically updates to the correct operator. Simple, but effect for sure. Oh, it’s also worth mentioning that the property’s description is displayed to the user in the lower right hand corner. A nice little feature that can provide users with an explanation of each property’s use.
As you can see DRM offers a wide array of options when it comes to creating and developing properties! Many times our clients are storing relevant atrribute information about their dimension members across various applications (Microsoft Excel, Microsoft Access, flexfields in EBS, etc.). With DRM properties , we are able to centralize everything into one application. This not only improves our clients’ master data processes, but also improves the daily lives of the people struggling to administer and validate this data. I cannot count the number of times I’ve seen smiles on the faces of our clients when we present the final product to them and they see all their attribute information categorized in one application. It’s truly a rewarding feeling.
If you liked this post or have a question, please leave a comment! We would love to hear from you!
Missed part of this series? Here are the previous installments:
Why Oracle DRM is Essential for Managing Master Data (Part 1)
Why Oracle DRM is Essential for Managing Master Data (Part 2)
Why Oracle DRM is Essential for Managing Master Data (Part 3)
