Overview
In this session, we’ll learn how to create input forms. First, we’ll put together the general layout and structure of our form. Then we’ll examine the properties that determine whether a form is inputable or not. And lastly, we’ll see how to create dynamic formatting through the cell attributes feature.
For more information on cell attributes, go to Why is my cell not inputable / annotatable?
Transcript
[transcript]
In this session, we'll learn how to create input forms. We'll use the base assumptions form as our primary example.
First, we'll put together the general layout and structure of our form. Then we'll examine the properties that determine whether a form is inputable. And lastly, we'll see how to create dynamic formatting through the powerful cell attributes feature.
Let's navigate to the assumption model and create a new form.
Then let's open the layout tab and assign dimensions to the axes. Note that for input forms, we have to make sure that we select input nodes for all dimensions.
Again, we should use the mock up form from our architecture document to guide the process.
Let's put SKUs on the rows, months on the columns, and then account, entity, scenario, and fiscal year on the filters.
You may notice that although we defined attributes in both the entity and product dimensions, they don't appear here. For performance considerations, attribute hierarchies aren't enabled by default except for the time dimension. However, we can configure this by going to the attributes node and checking hierarchy.
As this affects the structure of the model, we'll need to deploy the application.
Now we can choose the brand attribute as a filter.
In the row tab, select the all member and choose leaves. This will bring in every SKU. In the column tab, we can do the same thing.
Then we should set our default filter selections.
For the account filter, we only need to access the three accounts under the base assumptions header. The rest of the accounts in this list don't make sense in the context of the form. To reduce confusion for our end users, we can use the scope option to only show these three accounts. Select custom set and then select the three members we need.
Now let's set the rest of our defaults.
When we return to the main tab, the cells on the form should now be yellow to show that they're inputable.
If we were expecting our cells to be inputable but they're not, we can investigate this by right clicking on a cell and selecting cell details. This window provides detailed information about the cell.
A cell is inputable only when all the dimension members that intersect the cell are inputable leaf members. We have these states to help us confirm that.
Is lowest checks if the members are on the lowest level of the hierarchy. If this was false, we could use the slice information below to investigate further.
The value is the member ID of the dimension. It has to be non zero. If its value is zero, it means that we're not on the lowest level.
Is writable checks if the current user has permission to write to the model and dimension that the cell is associated with.
Is input checks if all the members that define the cell have their input attribute set to one.
Is annotate checks if any of those members have their annotation attributes set to one.
Is locked is set in the workflow settings, which we'll cover later. This value has to be false for input regions.
For a cell to be inputable, these values have to be true, true, true, and false.
When is annotate is true, the cell is a text input field. Otherwise, it's a numeric or drop down input field.
Now let's style our form so that it's consistent with the P and L report.
It looks good now. However, we actually have a small issue with number formatting that might not be apparent right away.
To explain, let's switch our filter to price. This form will be used to enter the price of the products we're selling. If we enter a number with decimals, it will automatically be rounded up.
We can change this by selecting the whole form and increasing the number of decimal places.
But now if we switch the account filter back to volume, the formatting doesn't make sense. The extra decimal places are unnecessary and might be confusing.
To solve this issue, we can add dynamic formatting to our forms using cell attributes.
Let's right click on the form and choose add cell attributes. Name it format volume.
Then we need to select which dimensions the formatting should apply to. Let's remove everything except volume.
Then in the formatting tab, we can check enable formatting and set a different format for only when volume is selected.
Now the formatting is appropriate regardless of which filter is selected.
Let's save this form.
Following the same process and using the architecture document as our guide, we should have no problem constructing the deflator percent and trade spend forms in their respective models.
In this session, we configured the structure and layout of our input forms. Then we looked into the various properties that determine whether a form is inputable. And lastly, we examined how to create dynamic formatting with cell attributes.
That concludes part two of the series.
In part three, we'll look at creating dashboards to interact with our forms and managing the data in the application.
[/transcript]