Sales Cost of Goods Sold Gross Margin (Gross Margin Ratio) ←Calculated Item Selling, General, and Administrative Expenses …
Elastic Axes
Context
In planning & reporting systems, forms that display numerical breakdowns by department, product group, or account are common. Departments and product groups may be arranged along the vertical or horizontal axis. In fusion_place, departments, product groups, and accounts are represented by dimensions.
A department, a product group, or an account may be added or abolished in a dimension, or the grouping for aggregation may change (for example, the organization unit overseeing the Mie Branch may shift from the Kansai Regional Headquarter to the Chubu Regional Headquarter). Forms tend to be numerous, so manually modifying each form to accommodate such changes can be time-consuming.
Problem
When a "member" representing an individual department, product group, etc., is added to a dimension, removed from the member tree, or moved within a member tree — in short, whenever a member tree is modified in any way — we want the changes to automatically reflect on the tables displayed with forms.
Forces
-
Immediate Propagation: Changes to the member trees should be applied immediately to the axis appearances of all intended forms.
-
Ease of Configuration: Configuration to reflect changes in the member trees to the views with individual forms should be simple and require minimal effort.
-
Shared Settings: There might be many forms that need to display a member tree using identical specifications. In such cases, means to share the configuration should be provided not only to reduce setup effort but also to facilitate communication regarding form specifications.
-
Single- and multi-level views: When displaying organizational hierarchies in a form, you may show only a single level or display a breakdown across multiple levels. In either case, changes to the member tree should be automatically reflected.
Solution
By using member lists in axis configuration in forms, columns and rows can be repeated a variable number of times.
In simple forms, assigning member lists to dimensions placed on the vertical and horizontal axes is required, so this is naturally achieved.
In full-featured forms, place Loop Specification on the axis you wish to make variable within the form. The Loop Specification allows you to specify a member list as the repetition condition.
In either case, each item generated by iteration (a row, column, or a collection thereof) corresponds one-to-one with a member included in the member list created at runtime. Therefore, rows or columns are generated and displayed as corresponding to each member in the member list.
Indentation
When this pattern is applied to rows and rows for members across multiple levels are displayed, there is a need to indent row titles. For guidance on this, see the sample and explanation in the fusion_place Q&A at Sample: Indenting Form Title.
Examples
This pattern is so basic that it is used in almost every form. Here are a few examples.
-
In reports where accounts are arranged vertically, such as P/L reports, this pattern ensures account additions/removals are automatically reflected in the vertical axis row order.
-
In product group sales reports which arranges product groups along the vertical axis and monthly sales along the horizontal axis, this pattern ensures product group additions/removals automatically update the vertical axis order.
-
In reports displaying aggregate department totals in the first column and breakdowns of subordinate departments in subsequent columns, this pattern ensures additions/removals of subordinate departments automatically update the horizontal axis order.
Consequences
Benefits
-
Immediate Propagation: The member list is recreated each time the form view is reloaded to reflect the latest content for each dimension, so columns and rows are displayed based on the latest dimension contents.
-
Ease of configuration: The settings required to define member lists are minimal.
-
Shared Settings: Member lists can be defined within individual forms, but they can also be defined as part of dimensions. By referencing and applying the member list definitions in dimensions within forms, configuration effort is reduced and communication regarding specifications becomes easier.
-
Single- and multi-level views: In the member list specifications, the Expansion Method allows you to include not only direct child members but also descendant members.
Liabilities
-
Ease of Configuration: Configuring can become complex when you want to display calculated items between members that cannot be expressed as aggregated members. This is because you must split the member list. For example, consider the following P/L account sequence:
In this example, Gross Margin is a calculated item on the form, and there is no corresponding account member. Therefore, it is necessary to display items from Sales Revenue to Gross Margin using one loop specification and member list, display the calculated item Gross Margin, and then display items from Selling Expenses onwards using another loop specification and member list. This means two loop specifications are required. Thus, as the number of calculated items increases, the number of loop specifications increases, making form configuration more complex.
As a workaround, the layout could be modified to place calculated items at the e nd rather than in the middle. In this case, after listing all P/L account members, indicator rows are added to display the calculated items.
Sales Cost of Goods Sold Gross Margin Selling, General, and Administrative Expenses … (Gross Profit Margin) ← Calculated Item (Operating Profit Margin) ← Calculated Item...
This approach requires only one loop specification to display items other than the calculated items.
Related patterns
Succeeding patterns
-
It is also possible to select a member tree from multiple options. This becomes necessary when we have Annual Member Trees or Member Trees for Custom Aggregations. Refer to each pattern for details.
