Application Dimension Concept
A dimension is the logical organization of related members and their properties. For instance, you may have a dimension for Geography, with the members Seattle, Olympia, and Tacoma and with properties such as State, Country, and Region Code defined for each member.
Similarly, you can have a Product dimension with members representing individual product SKUs with other properties tracking such items as Brands and Product Grouping. When a dimension is defined within an application, it can be reused in different context over multiple application models. Kepion supports two types of dimensions; pre-defined and user-defined.
Every application contains the following three pre-defined dimensions as shown in the image below.
- Account: The account dimension is used to define general ledger (GL) chart of accounts with intelligent account rollups. For each member in this dimension, you can define its account type. The account type will determine how the aggregation will behave when within a chart of accounts and also over a range of time for balance behavior. The account dimension can hold a maximum of 65,535 members.
- Scenario: The scenario dimension is commonly used to store members such as ‘Actual’, ‘Plan’ and ‘Forecast’. However, there is no requirement that you have these members and you can use this dimension for other members as well. The scenario dimension can hold a maximum of 255 members.
- Time: The time dimension is used to define your calendar. Time dimension comes with calendar generation capabilities where you can define multiple calendars including Gregorian and Fiscal calendars.
User Defined Dimensions
The application can also contain any number of user defined dimensions. User defined dimensions allow you to customize the application for your needs by managing your own set of dimension members and hierarchies.
Create a Dimension
As shown in the image above, you can create a new dimension by selecting the All dimensions node in the navigation pane and clicking on the PLUS button. When designing dimensions, you can specify the storage size for the dimension by indicating the number of expected members the dimension will hold. Selecting the right size during the dimension design will allow for optimal performance when the application is deployed. There are three choices for storage size.
- Less than 100 members
- Less than 25,000 (25K) members
- More than 25,000 (25K) members
By default, the Create default member list option is checked, which means the dimension will create a member list with the same name as the dimension. The member list is used to manage the set of members that are active in the dimension. Also, you can enable the dimension to participate in dimension member security. By default, the dimension is not enabled with additional security capabilities. The security field can be updated at any point in the application design.
Every dimension comes with a default list called All_ “Name of Dimension” that is used to store dimension members. For example in the image below, you can add new members to the Entity dimension by selecting the All_Entity node under Designer pane and clicking on the ADD button.
Dimensions come with the following pre-defined set of properties:
- MemberLabel: This is the unique ID that identifies a member within the dimension. By keeping the MemberLabel unique, you can reference the member’s MemberLabel within rules and form design. The maximum allowed characters for this field is 200.
- MemberName: This is the friendly name that can be non-unique within the dimension. Use this property to give a descriptive name for the member. The maximum allowed characters for this field is 200.
- Input: The Input property determines whether to allow data input for the member. For instance the member Actual may never be required for input and should therefore be set to FALSE. This field will be TRUE or FALSE.
- Annotate: The Annotate property controls whether the member will display data or comments on the forms. This field will be TRUE or FALSE.
- EXCEPTION: The Account dimension comes with two additional pre-defined properties.
- By Account: Enable By Account logic for the account aggregations that are related to the Time dimension. For instance, balance accounts aggregate differently over Time than regular accounts for expense and revenue.
- AccountType: The AccountType property is used to define the GL account type for members of the account dimension. Setting this property will also define the natural account aggregation behavior of the member within an Account hierarchy. Examples of values for this field include but are not limited to the following: Unit, Header, Expense, Liability, Ratio, Equity, Inventory, Asset, Cash, Goodwill, Income, Investment, Rate, HeadCount, Statistic.
Account Type Behavior
Account aggregation is determined by the relationship of a child Account member to its parent member. For instance, an Account member that is a Credit will sum to its parent if its parent is also a Credit. However, an Account member that is a Credit will minus from its parent if its parent is a Debit.
The table below shows the aggregation behavior between a child Account member and its parent.
When an Account member is tagged with an Account Type, the system will then know how to handle its aggregation behavior. The table below lists out the associated properties by each Account Type.
Let’s analyze an example Account hierarchy with the following Account Types specified. In order to determine how the aggregation will work for each member, we first need to identify the child and parent members in the hierarchy.
Once the child and parent members are identified, you can look up the Debit/Credit properties for each member based on the Account Types table. Once you have the child and parent Debit/Credit properties identified, follow the Debit/Credit Aggregation Rule to determine the correct aggregation behavior.
Dimension User Defined Properties
User defined properties can be created on any dimension to give dimension members additional fields to store information. These fields in turn can be used within models that contain rules, forms, and reports. Kepion supports the following property types for fields:
In Figure 12, you can add properties by selecting the Attributes node under a particular dimension from the navigation pane, and clicking on the PLUS button. To remove a property, check the checkbox beside each property and click on the REMOVE button.
For user-defined properties, you can specify whether you want to treat this property as an independent hierarchy for use in Form design. Check the checkbox for the property under the Hierarchy column to enable this behavior.
It is recommended to only turn on the Hierarchy for properties that are required on a form’s axis definition. By limiting the number of Hierarchy enabled properties on the dimension, it will lead to better overall performance. We’ll explore axis definitions further in the form section. If you are unsure of this setting, you should leave this property at its default setting as you can always change it at a later time.
Note: There is no user interface (UI) available to view the Attribute hierarchy in the Modeler. Rather, to view the hierarchy you will need to make use of it on form design.
The image below is an example of the fields added to the Entity dimension to give information on Region, Local Currency and Reporting Currency:
There are additional settings that can be set for a dimension attribute. These include:
- Default: Set the default value for this attribute for each new dimension member
- Drill-through: Allow Cube Drill-through by this attribute
- Hide From Filter: For form filters, hide this attribute from showing
- When Show Advanced is checked then additional columns settings will become available:
- Name Column: Identify the current attribute as a key attribute and use the given name column as its friendly display
- Validation: Use the validation setting to validate the values in the attribute against a given dimension Member List