Critical factors in the efficiency of the filter function are which filter attributes are available – and also: how many. Especially in reports intended for many recipients, it is good to have simple settings options: There should be just a few attributes – the most important ones, not as many as possible! This particularly applies if the reports are to be used on mobile devices such as iPhones or iPads, which have to make do with relatively small screens and reduced operation.

Which and how many filter criteria are displayed depends on how the reports were set up. With DeltaMaster, you can determine precisely which attributes should and should not be available. That is good news for everyone who feels that there are too many filter criteria on offer: Report editors can control whether to make work as easy as possible for the report recipients or to grant them maximum freedom. The key to setting up the reports is the filter context. This should always be given special attention.

Dimensions in the filter bar

To explain the adaptation options, we will first explore which attributes are offered in the filter bar in Presentation Mode. Generally, all dimensions from the analysis model are eligible. DeltaMaster goes to great lengths to keep the display as clear as possible. To decide whether a dimension is displayed (and whether this is only in the detailed view or compact view), DeltaMaster applies the following criteria:

a) Linking of measures and dimensions in the analysis model

b) The perspective of the report

c) The filter context of the report

d) The filter setting (view) of the report, i.e. the stored selection of members

e) The setting for visibility of dimension members and levels

We explain these criteria below.

a) Linking of measures and dimensions

In Presentation Mode, DeltaMaster automatically hides dimensions that are not linked with any measure of the current report; they would have had no effect on the report anyway. In Modification Mode, these dimensions are grayed out in the filter bar.

b) Perspective

Since DeltaMaster 6.1.3, it has been possible to group dimensions, hierarchies, levels, members, and measures into “semantic perspectives” when Modeling, thus laying a kind of mask or screen over the analysis model. Then, instead of having to cope with the full complexity of the model, report editors can hide what they don’t currently need. The hidden attributes are no longer accessible to report recipients either, and are not displayed in the filter bar.

c) Filter context

The filter context works in a very similar way, although it is only effective in relation to report reci­pients. It is used to control which dimensions, hierarchies, levels, and members report recipients should have access to. The settings apply to the compact view and detailed view alike. The filter context is logically sub-ordinate to the perspective: What is already hidden in the perspective cannot be shown again by the filter context.

d) Filter setting (view) of the report

With dimensions that are not hidden because of the mechanisms described above, we distinguish between whether they only appear in the detailed view in the filter bar or also in the compact view (and can therefore be seen by everyone). This primarily depends on which members are selected in the dimensions.

As you will recall, the stylized square at the front in the filter bar is used to switch between the compact view and the detailed view.

In the compact view, DeltaMaster shows all dimensions in which something specific is selected – i.e. something other than the standard member. The standard member is usually the “All member“ of a dimension, for example “All customers”, “All products”, “All cost centers”, etc. So, if specific custo­mers, products, cost centers, etc. are selected (and not “all”), DeltaMaster also displays the dimension in the compact view, otherwise only in the detailed view.

The dimensions in the compact view often also include (but not in the screenshot) the “flat” dimen­sions whose members are all on the same level, such as value type, view of period, cumulation, and scaling. These dimensions have no aggregated members and no non-specific standard member. Instead, something specific is always selected; for example, the members “Actual”, “Current”, “Not cum.”, and “1:1”. Therefore, these members can also be regularly seen in the compact view unless they are hidden, as described in section e) – and as we generally recommend.

e) Setting for visibility of dimension members and levels

When Modeling, you can explicitly stipulate that DeltaMaster, in contrast to the rules in section d), should display or hide specific members. Typical cases for these options are:

• Some specific members are so obvious that they don’t have to be displayed everywhere. With a budgeted income statement, for instance, you would have to point out that it is budgeted; by contrast, if the income statement contains the actuals, you don’t have to state this. Therefore, it is entirely possible to hide members such as “Actual”, “Current“, etc.

• Sometimes, you might also want to display a non-specific “All member“ immediately to indicate that this property is avai­lable and can be changed. The default setting of not display­ing a dimension if nothing specific is selected is dispensed with, as an invitation to the report recipients to deal with this attribute and select other, specific members.

These options affect all reports in the application. If selected members and dimensions are only to be removed from the filter bar in individual reports, you can work with perspectives; see below.

Filter context of reports

Probably the best-known tool for preparing the filter bar for report recipients is the filter context. Many users are familiar with the concept from DeltaMaster 5 under the name “View context”. This is still in place in DeltaMaster 6. It has simply been renamed “filter context“ and linked with the per­spectives.

The filter context is one of the Report Properties. In Modifi­cation Mode when you edit, these can be accessed via the context menu of reports.

All dimension groups, dimensions, hierar­chies, and levels available for this report are displayed in the structure tree. Available means: All dimensions, hierarchies, and levels of the analysis model except those that are already hidden via a perspective.

You can use the checkboxes to stipulate which dimensions, hierarchies, and levels are to be visible and selectable in Presentation Mode (box checked) and which are not (box unchecked).

Take note of hierarchies

The customer dimension in the example shows that two hierarchies are enabled: customer and branch. Experience suggests that it is often because of parallel hierarchies like these that report recipients are confronted with more selection options than they would like. Therefore, our tip is this: When setting the context, take note of the hierarchies as well as the dimensions.

Selecting levels

In the period dimension in the example, only one specific level was allowed: month level. In Presentation Mode therefore, the only category of time that can be selected via the menu is months. Years and quarters are grayed out, and can be “drilled down on and rolled up”, but not selected.

This setting is appropriate for reports with a typical monthly representation in which you want to ensure that the reader doesn’t switch to quarter or year level. Often, the time reference has a major impact on the structure and design of reports, so it is advisable to channel the variation options for the report recipients to reflect the intention of the report. In the standard reports generated by Delta­Master, the filter context is automatically set up in the relevant manner.

With many other attributes, too, it is worth adapting the granularity in the filter bar to the report type or report object. For example, Portfolio Analyses are part of strategic planning, so no daily values are processed in them. And if a Geo Analysis is based on a map that has a resolution of no more than three-digit zip codes, operating errors are prevented by a corresponding reduction in the customer dimension for this report. Adaptations of this kind simplify the interface for report recipients – and remind them that there are clear notions about what you can and can’t do with data.

If levels are excluded, DeltaMaster points this out in the dialog (“Selection restricted“ next to the hierarchy concerned).

Selecting members

In OLAP databases, the selection options intended to be available in Presentation Mode can also be defined as an individual group of members. The selection below the levels is used for this: Via the context menu, you can restrict the selection via member list (using the Dimension Browser) or via MDX Expression (using the MDX editor).

In principle, you know this logic from the Axis Definition of Graphical Tables: There, you can use Level selection, Member selection (“pick list“), or an MDX expression to determine which members are to feature in the rows and columns of the Graphical Table. The same three constructs can be used to stipulate which members are to be offered in the dimension menu of the filter bar in Presentation Mode.

If a selection of members has been defined, DeltaMaster points this out in the dialog (“Selection restricted“ next to the relevant hierarchy), and the context menus of the hierarchy and of the selection contain a further entry for canceling the restriction. If some hierarchy levels are disabled in addition to the selection of members, the intersection, i.e. only the members that are part of an enabled level, can be selected in Presentation Mode.

Allowing or preventing multi selection

A further, often convenient restriction can be stipulated via the context menu of dimensions: that only precisely one member may be selected in Presentation Mode, not multiple ones. This is ob­vious in the case of dimensions whose members are not suitable for addition due to their business logic; for example scenarios, value types, or currencies. In the time dimension, too, it is sometimes advisable to suppress multi selection, particularly if the report contains time analysis members that cannot be calculated for multiple periods or are hard to interpret. The standard reports of DeltaMaster with their cumulations and prior-year comparisons are an example of this – and they are also preconfigured accordingly by DeltaMaster in this regard. If Multi selection is not allowed, DeltaMaster shows this in the dialog next to the dimension.

Preselecting filters dynamically

The procedures described above can be used to control which attributes are to be visible to report recipients and interactively selectable. But what should be selected in the starting configu­ration without users reaching for the mouse and setting a filter themselves, or before they do so? You can define a default selection for this (context menu of hierarchies). What is special about the default selection is that it is dynamic. In the filter context, you store an MDX or SQL expression that DeltaMaster evaluates when the session is opened in order to determine which members are to be (pre)selected at runtime. Various criteria can be taken into account here, such as the current date as per the system time or the current user. This makes the default selection a key tool for reducing the number of reports: Instead of preparing lots of reports that differ only in terms of the filter, you can determine the filter dynamically and apply it to a single report. We will address this in detail in the next issue of clicks!. If a default selection has been defined, DeltaMaster points this out in the dialog (“Default selection defined“ next to the hierarchy concerned).

Perspective and filter context

As mentioned above, semantic perspectives have a very similar effect as the filter context – but in Modification Mode as well as Presentation Mode. In Presentation Mode, the perspective of a report is an additional restriction: Only the selection options that are allowed both in the perspective and in the filter context (tab in the Report Properties) are available to report recipients. In Modification Mode, the perspective affects not only the filter bar, but also, for instance, the definition of the filter context in the Report Properties: Only the dimensions, hierarchies, and levels that have not already been hidden by the assigned perspective can be seen there.

One aspect also makes perspectives particularly efficient when designing the application for report recipients: They can be reused. For instance, if the same dimensions, hierar­chies, levels, or members are to be visible and selectable in multiple reports, you can create the corresponding settings once as a perspective (Modeling) and assign them to all relevant reports (Edit, Report Properties, Perspective tab). In this way, the reports are permanently linked with the perspective, and they also adopt subsequent changes automatically.

The dialog for defining a perspective (when Modeling) has a very similar structure to the one for the filter context: Perspectives allow you to enable and disable dimensions, hierarchies, and levels via checkboxes, and to select members. In addition, with OLAP databases, it is possible to Fix the selection (context menu of the members). A fixed selection cannot be changed in the filter bar in Modification Mode or Presentation Mode.

Dimensions that are disabled in the perspective are not displayed even if something specific is selected, for example a fixed member. In this way, filters can be made “invisible“ in selected reports.

Working with perspectives is described in DeltaMaster deltas! 6.1.3, feature 9; we will address this again in more detail in a future issue of clicks!.

Filter context of folders

As with reports, a filter context can also be set for folders (via Folder Properties in the context menu of folders). Please note that this initially applies only if the folder itself is selected in Presentation Mode (and not one of the contained reports). If a filter for a folder is amended in Presentation Mode, this change is passed on to all contained reports – a quick way of setting the filters for multiple reports in one go, e.g. to the current month. The attributes to be available for selection for a collective change of this kind are controlled via the filter context of the folder. If all dimensions are disabled, no folder-wide change is possible. This may also be desirable, for instance, in order to prevent inadvertent large-scale changing of the filter if the contained reports are very different.

In addition, the filter con­text of a folder can be used in order to set the filter context of the contained reports and (sub?)folders. The two additional options below the structure tree are used for this. A distinction is made here between disabling and restrictions on the one hand and enabling on the other. For instance, in the sub-ordinated folders and reports, you can enable (or disable or restrict) everything that is enabled (or disabled or restricted) in the current folder. The corresponding setting is transferred to the sub-ordinated objects when the dialog is closed, once rather than as a permanent inheritance or depen­dency – as would be the case with perspectives, which might well be the more elegant solution in many cases.

The outcome

With the described procedures, you ensure an uncluttered interface in Presentation Mode and decide which filters can be set. Browsing also relates to this – the dimensions and levels that the Hyper Browser takes into account arise directly from the filter context.

By contrast, the filter context has no direct effect on Navigating. It is possible to offer attributes for Navigating that cannot be selected in the filter bar. The Navigation context is used for designing the navigation attributes; it is described in detail in DeltaMaster clicks! 10/2016 (for reports) and 11/2016 (for measures).

A simple form of a permissions concept can be implemented indirectly through a combination of saved filters and the filter context: by saving a report with filters that users cannot change, or can change only to a limited extent, in Presentation Mode. The differences in relation to database-supported permissions are described in DeltaMaster clicks! 07/2017, including where these are superior.

Making additional selections is easier than deselecting

To finish with, here is some advice from experience: Particularly in larger applications with many dimensions and hierarchies, as a report editor, you can sometimes be unsure which ones should remain in the filter context and which ones should be hidden. In this situation, it is often easier if you first disable all dimensions (a link is specially provided for this on the Filter context tab) and then reenable the most important attri­butes – at least the time (period) and then the most important hierarchy in each case from the few dimensions that constitute the use case, for example customers, products, or cost centers.

Conversely, if you work on the basis of a full selection and painstakingly check dimension by dimension and hierarchy by hierarchy to see whether it might still be needed one day after all for a special evaluation, a relatively large number of attributes are still left over at the end. The 80:20 principle applies here as well: For most users and most tasks, only a few attributes are required. It is therefore worth designing the central, distributed, frequently used reports in such a way that they work with just a few attributes. And for the few users or situations for which many attributes are required, it may be a good idea to generate an additional report as an “expert view”.

However, if the applications become bigger, if more people work with them, or if different tasks are to be performed, then it may be worth arranging the applications on a user-specific basis in terms of content. This is possible with DeltaMaster: by means of an internal rights concept.

You can see how this works by e. g. having a look at the report list of DeltaMaster. The same application is shown each time in the screenshot below, but from the viewpoint of three different user groups: a regional sales representative on the left, the Head of Sales in the middle, and Controlling on the right.

The report list sometimes includes fewer reports, and sometimes more. Another difference is the button with the pencil (at the bottom), which is used to switch from Presentation Mode to Modi-fication Mode. In the example, this button is available to just one user group, Controlling (on the right). The returned values are identical in all three examples.

DeltaMaster and the databases

As a matter of principle, permissions in the overall system of a DeltaMaster solution need to be defined at two levels: in the database and in the DeltaMaster application. The responsibilities are clearly assigned:

• For the database, it is stipulated which data the users are allowed to access. Setting these rights is usually a task for the IT department. The relevant tools are part of database management and are of a technical nature.

• For the DeltaMaster application, it is possible to stipulate which users are allowed to access it – and, if applicable, which parts, namely which reports and folders. Granting these rights is a task for the department that operates DeltaMaster, usually the business department. The relevant tools are part of DeltaMaster and are accordingly easy to use.

The database is decisive when it comes to maximum confidentiality, data protection, and data security. Common database systems provide sophisticated and tried-and-tested protection mecha-nisms for this purpose. These apply to DeltaMaster as well as to all other programs with which the database can be queried. DeltaMaster executes database queries with the rights of the current user or of the user stated at the time of logging in (with the WebClient, if this has been configured; i.e. impersonation). DeltaMaster cannot tell whether there are other users or which data they would see.

The rights concept of DeltaMaster is independent of that of the database. Its task is to control how the users can work in DeltaMaster with the data that they receive from the database in accordance with their database rights. The DeltaMaster concept in this case is geared towards the application. The focal points are efficiency, ergonomics, organization, delegation, guidance, and leadership – it is therefore more about who is and isn’t supposed to see what, and less about who is allowed to see what.

Corresponding to the division of tasks between database and DeltaMaster, rights for different types of object can be assigned with

• the database objects for which permissions can be managed depend on the respective database system. With Microsoft SQL Server Analysis Services (SSAS), for example, permissions can be set for entire cubes, individual key figures (measures), filter properties (dimensions, hierarchies, dimension members), and even for specific cells (combinations of dimension members and measures).

• In DeltaMaster, rights can be maintained for reports, folders, the report list, and applications. In this issue of clicks!, we are concentrating on reports and folders.

I see what you don’t see

In particular, the DeltaMaster rights are used so that the same application has a different appearance and behaves in different ways depending on who is working with it. Here are a few example scenarios in which rights are beneficial:

• Taking account of different tasks in the business department
  The field-sales team uses reports as report recipients without creating them or changing their structure; by contrast, in-house staff must be able to do this. Some reports are only to be processed by Controlling.

• Mapping different operational functions in the same application
  Reports for different tasks are stored in the same DeltaMaster application, e.g. for Purchasing and Sales. Some reports, for instance regarding development of the margin or analysis of price effects, are relevant to both areas, and some are only needed by Purchasing or Sales. It is easier and there is no unnecessary distraction for the other department in question if these reports are hidden on a user-specific basis.

• Assigning administration and operational use
  In planning applications, most reports serve as an input screen for the planners. In addition, project managers, application-support staff, and administrators have access to reports with which they can manage and monitor the process. Only these people are allowed to have access to these reports.

• Synchronizing visibility in DeltaMaster and access in the database
  Different rights apply in the database so that each sales representative can only access the data of their own customer base. By contrast, the Head of Sales can view all areas as well as the aggregated values. There is a report for each region in the report list. If someone opens the report of a region without having rights to this region in the database, the report remains empty, although it is still displayed in the report list. That is why it may be a good idea to reproduce the different rights from the database in the reports. (This situation often occurs if a report list contains a large number of static reports with an identical structure in which various members of the same dimension are applied across the board, for example all regions or branches. In these cases, it is often easier to use just one report but to structure it in such a way that it is dynamically dependent on the current user, instead of managing a large number of rights for a large number of reports.)

• Developing, testing, and approving reports
  A report editor is working on new reports for an existing application, but does not want to make them available to other users until all the finer points have been resolved. Until then, the reports remain in a “working folder”, which is visible to report editors only. To make the report available to pilot users and ultimately the general public, it is sufficient to define correspond-ding rights or simply move the report to a folder to which suitable rights already apply.

Simple protection against unwanted queries can also be achieved through the resources in Delta-Master alone: Presentation Mode is the only mode available to users who are classified as report recipients. In turn, this mode can be restricted by the filter context in such a way that only highly specific data can be retrieved. However, this obviously only applies to DeltaMaster, not to other query tools. There¬fore, when it comes to insurmountable access control that also protects against malicious and technically adept users, the database is the first line of defense.

Streamlined management apparatus

Two tools are available for managing DeltaMaster rights: DeltaMaster Role Management and DeltaMaster itself. The respective tasks are clearly delimited and facilitate the division of work between the IT department and the business department, as well as within the specialist department.

Rights for applications

DeltaMaster Role Management (DeltaMaster 5: Repository GUI) relates to applications and user groups. This tool is used to assign users to groups, activate the applications that are meant to be available to a user group, and stipulate the role in which the group can work with this application, i.e. the scope of functions that DeltaMaster offers them.

Report Recipients can use the application in Presentation Mode only, while Report Editors can also use it in Modification Mode; Application Administrators manage access rights. The screenshot shows that the “Gross Margin” application is activated for the “Sales” user group and that this group can access the application as Report Recipients. Other (or no) roles can be set for the “Administrator” and “Controlling” user groups.

If DeltaMaster is to apply rights within an application as well, activate the corresponding check box in the Files section. This makes it possible also to set rights for the reports and folders in this application. If the option is not activated, a simplified rights concept comes into effect for this application: User groups can be associated with the entire application in predefined roles (Report Recipient, Report Editor, Application Administrator, etc.).

If rights are to be changed and saved in an application, open the application via the options dialog box (context menu of a tile on the dashboard) and additionally with exclusive write access. In DeltaMaster 6, this access is also granted subsequently if you switch to Modification Mode in the already open application and no-one else already has exclusive write access. If you are a member of multiple groups, go to the Options dialog box and select the group you intend to work as a member of.

Rights in applications

Directly in DeltaMaster, in the Windows client, set the rights that apply “within” the application, mainly for reports and folders. To do this, it is necessary to grant rights, as described above, and to have sufficient rights, for example because you are opening the application as the Application Administrator or have been given appropriate permission as a Report Editor.

When you edit in Modification Mode, you reach the rights via the context menu of the respective object: Report rights in the context menu of reports, Folder rights in the context menu of folders, and rights for the entire report list in the context menu of the Reports heading. In addition, the rights can be defined for the application in the application menu (top left, ).

The rights for the selected report or folder are displayed in a dialog box (see the following screenshot), separated according to user group, and can be edited there if you have the corresponding permission.

Entries in brackets arise from inheritance (passing on), and those without brackets are set directly for the relevant object. Entries written in gray cannot be changed. This is always the case when there is no permission to grant rights, and when there are user groups with the role of Application Administrator (no rights can be taken away from them).

The following Rights can be set:

• All: Groups together all other rights.

• Display: Relates to the display in the report list. If this right is denied, DeltaMaster does not display the report or folder to these users. The report does not exist for the search function either, and links to this report are not available.

• Editing: Relates to the behavior of DeltaMaster in Modification Mode. If this right is denied but display is permitted, DeltaMaster behaves in Modification Mode in the same way as in Presentation Mode. For example, the structure and properties of Graphical Tables cannot be changed, and saving of the report is not possible.

• Right Management: Relates to the setting of these particular rights. This allows delegation of the administrative tasks.

If you pass on the Assignment Mode, the settings are also applied to the contained reports and to (sub)folders. Passing on is not possible for reports.

Essential condition: Repository

To manage rights in DeltaMaster applications, it is necessary to have a central authority that checks which user is working with the system and, on this basis, decides which information and functions are to be offered to the user. This authority is the DeltaMaster Repository, a component for database-supported provision and management of DeltaMaster applications, rather than in the form of the familiar DAS files. No permission management is possible with these; only the Repository can do this. A general overview of the properties and tasks of the Repository can be found in DeltaMaster clicks! 01/2015.

Know what you’re doing before you do it

Many issues of clicks! end with an invitation simply to try it out yourself. Rights are an exception – there are reasons why only a few people in the company are entrusted with rights management. Although you cannot lock yourself out (DeltaMaster would warn against this), many and diverse interactions have to be borne in mind, and the more detailed the concept, the more interactions there are. As is so often the case, the simple solutions are the best. Just think of the database. In DeltaMaster, rights at application level are often enough – who is a Report Recipient in which application, who is a Report Editor, who doesn’t need to see them at all? If more detail is required, use a top-down approach. And this last tip is always useful: If there’s anything we can do for you, get in touch with us!

1. Automatic compact display
2. Formatting and scaling of measures
3. Formatting using calculated members

The first method is the most recent in DeltaMaster and the easiest to apply: Just activate the respective option, and the numbers appear in the report or throughout the application in a concise, decision-oriented notation.

You can find a comparison of the display with the numbers written out in full and the new compact display on the next page.

Numbers written out in full
Compact with K, M, B
Compact with apostrophes

The great thing about this automatic feature is that units can be entirely mixed: In the very same table, row, or column, some figures can be formatted in millions, others in thousands or billions, and the very small ones can be written out in full. This may seem surprising at first glance – but you will soon discover how easy on the eye these figures are, and how clear and distinct they look to us when the clutter of the less significant decimal places is removed.

In addition, if reports are scaled insensitively and indiscriminately with just one factor, strange num­bers often arise. We don’t talk of 0.1 million if we mean 100 thousand, or of 0.01 million or even 0 million if we mean 10 thousand. In this respect, formatting by DeltaMaster is in line with natural parlance: In the report, the numbers are set out as they would be pronounced in a meeting or on the phone.

The look of figures of different magnitudes can also be interpreted, for example amounts in the low millions and high thousands: The thousands have more digits, more digits means more detail, more detail means smaller values, and small values means less important. The large, important figures are short and simple. This makes the compact notation a wonderful, pragmatic tool for decision-oriented reports.

And the compact notation also makes life easier for report editors, as the formatting automatically adjusts to fit the respective values set out in the report. So if the user drills down from group to business unit, for example, the change of scale is automatically taken into account.

Compact for everyone, more compact for professionals

DeltaMaster provides two display variants, as shown above:

• The variant in thousands (K), millions (M), and billions (B) is the preferred choice for reports that are aimed at a wider audience. The abbreviations are widely used, including outside of controlling, and need no further explanation.

• The variant with apostrophes (one apostrophe for the thousand factor, two for millions, three for billions) is particularly compact. It is quite widespread among professionals: In meetings, it is common for a couple of figures on a flip chart to be appended with a little stroke, an apostrophe, to denote thousands, and with a second one to denote millions. What simplifies writing on a flip chart also makes the report easier to read and can be learned quickly, even though it is not yet standard everywhere.

No further settings or parameters are required. Percentages are excluded from the display regardless of how large they are. The display has no impact on the calculations: DeltaMaster always calculates with the exact values, including decimal places. The figures are exported to Microsoft Excel as num­bers written out in full to their original degree of precision, regardless of how they were displayed in DeltaMaster. Earlier versions of DeltaMaster do not support this formatting, but are not affected by the setting – the numbers are written out in full, as before. In planning applications, enter the numbers in full, not in compact notation.

To activate the display, switch to Modification mode.

Compact display as default in the application

As default for all reports in the current application, activate the display in the options (via the gear wheel  in the menu bar), on the Presentation tab. In appli­cations that you are creating with DeltaMaster 6.1.6 or higher, this is already the default setting.

Compact display in Graphical Tables

In addition, when you edit, you can set the display of numbers for Graphical Tables individually. You can find the options in the Edit menu (on the right) in the Presentation section. In this way for example, you can set the decision-oriented compact notation as the default and produce some “lookup tables” with accounting precision for other purposes. If none of the three options are selected, the general setting in the application options is applied.

An abbreviated display of numbers can also be attained with the following two methods. They are both based on the analysis model, one on measures and the other on (calculated) dimension members.

Formatting and scaling of measures

You can find all relevant settings in a central position: in the Measure Properties on the Format tab (see also DeltaMaster clicks! 02/2014).

Output of values in thousands or millions can be attained in two ways: via a Custom .NET formatting string or via Scaling.

• Formatting strings come from IT. They describe how a numerical value is to be output as text. For example, they can be used to control which characters are to be used as thousands separators and decimal separators, how many decimal places are to be taken into account, and how negative numbers are to be displayed. This implicitly also means that it is possible to convert numbers to thousands or millions.

The formatting string can either be stated as a constant expression (in the Custom field) or determined dynamically by means of an MDX expression, for example in accordance with hierarchy levels. The link next to the input field for custom formatting opens a Microsoft website that explains the structure of formatting strings (see also DeltaMaster clicks! 02/2008, with an example of filter-dependent formatting with MDX).

• Scaling is known in the business world as well, and relates to the numerical values themselves: They are converted (divided) and thus transformed. Here too, DeltaMaster calculates internally with the original values. Besides powers of ten, other factors can also be stated here as factors, for example in order to convert units of measurement. In addition, the factor can be calculated by means of an MDX expression. This must return a numerical value, for instance from a reference to the selected member in a specific dimension (for example currency, unit, value view) or in accordance with hierarchy levels.

Formatting and scaling work in parallel: Scaling transforms values, and formatting controls their notation. Scaling is easy to use, but additionally requires formatting (in case of doubt: Number with 0 decimal places). Formatting strings are not exactly intuitive, but if you understand how they work, you can often avoid the need for additional scaling.

The concise notation in K, M, and B set out above can also be achieved with formatting strings:

The comma between the hash and the zero means that group separators (thousands separators) will be output if required; in English, this is usually a comma. The commas after the zero result in the scaling – for each comma, the value is divided by 1,000.

The settings on the Format tab, including MDX expressions, can be saved as a format template for number formats and reused with other measures (I want to menu top right on the tab).

You can access the measure properties in DeltaMaster 6 when Modeling. If the key figure is displayed in the Filter bar, click on it once to edit the properties. Otherwise, click on the three dots after the measures to open the Measure Browser; then edit the properties via the context menu.

Formatting with calculated members

This case too is described in detail in DeltaMaster clicks! 02/2014. Formatting and scaling can be linked to (calculated) members as well as to measures. If applicable, an auxiliary dimension is often provided in the analysis model for this, for example unit or value view. In this way, a specific formatting can be applied to multiple measures, eliminating the need to format them separately. In addition, one measure can be combined with various members for formatting instead of deriving multiple measures with differing formatting from one basic measure.

One special feature is that the formatting members can also be set explicitly in Presentation mode – this is not possible with formatted measures, and neither possible nor necessary with the automatic compact notation.

Calculated members can be edited in DeltaMaster 6 when Modeling. In the Filter bar, click on the name of a dimension to open the Dimension Browser. It is possible to add and edit calculated members via the context menu and the I want to menu. The formatting options correspond to those of the measures, but an MDX expression is not possible here. Scaling is achieved via a calculation using an MDX expression in the Definition field.

The two structure-driven approaches (via measures and calculated members) are tried and tested and an efficient tool for special tasks, usually in larger applications. The automatic compact display is universal and easier, as well as being more effective by virtue of the clever, value-dependent scaling.

Compact in tiles and Sparklines

In the case of two special displays, DeltaMaster uses compact notations as a matter of course:

In zoomed Sparklines, where space is particularly tight, the columns or dots are labeled in a particularly readable manner thanks to the apostrophe short-form.

And on application and report tiles as well, Delta­Master automatically formats large, absolute numbers in a compact manner. Here, K represents thousands, M millions, and Bn billions.

Before: A long, un-wrapped table – or rather an almost empty screen and a list whose length can only be gaged with the scroll bar. Well-versed readers will have a hunch that even though the table starts with good news, such as the pleasing changes at the customers SuperOffice, Bavaria Furniture, etc., at least one piece of bad news will be lurking at the end of the list – the short bar next to SuperOffice suggests this. If you scroll to the end of the table, you will lose sight of the beginning. There would actually still be space here, …

After (see below): The same list in the screen section of identical size, wrapped and readable in full, including the already feared sharp negative variance.

Further suggestions on how to compare positive and negative variances in the same report can be found in DeltaMaster clicks! 02/2015. – The above illustration is an example of a vertical wrap: A long table with one fixed column and one data column is wrapped across three display columns. DeltaMaster repeats the labeling of the columns automatically. The status bar points out the wrap so that you can see that the layout is a result of the formatting rather than of the structure (i.e. in the exam­ple, the revenue is always the same, and there are not three different measures with the same name, for instance).

The following illustration shows an example of a horizontal wrap: A table that was previously too wide, …

… fits entirely on the screen and is easy to read. Again, the screen section is the same as in the continuous display.

Give the wrap a try

You can activate the Table Wrap in Modification mode if you edit the properties of the Graphical Table (Edit menu, on the right) on the corres­ponding tab.

You have already encountered the two alternatives in the above examples.

• The horizontal wrap is suitable for wide tables: After a number of columns automatically determined by DeltaMaster or predefined by the user, the table is wrapped to the right, and the further columns are shown in a new display row. In figurative terms, what no longer fits at the back of the screen is continued underneath from the front (in a line pattern like a Z).
• The vertical wrap is suitable for long tables: After a number of rows automa­tically determined by DeltaMaster or predefined by the user, the table is wrapped at the bottom so that further rows are shown in a new display column. In figurative terms, what no longer fits at the bottom of the screen is continued at the side from the top (in a line pattern like a W).

Automatically wrapped is best

Where a choice can be made between automatic and custom in DeltaMaster, we generally recommend automatic. This also applies to the table wrap: In automatic wrapping, DeltaMaster derives the number of columns and rows dynamically from the available screen space in order to make optimum use of it.

In special data situations, you may wish to specify the number of columns or rows, for instance if the report needs to follow a specific symmetry. In the illu­stration on the right, the report already wrapped above is struc­tured with the sales areas in such a way that the sales areas of a region appear in pairs: South 1 next to South 2, North 1 next to North 2.

An essential condition for special cases such as this is normally that the structure of the data to be displayed is constant and the length and width of the report are independent of the Filters (View). In the case of nested axes, the columns and rows on the very inside are counted.

The options for equal column width or equal row height ensure a consistent grid in the wrapped table and therefore, in some cases, a more harmonious appearance of the report. This particularly applies if the labels in the column/row headings have differing lengths or have one row in some cases and multiple rows in others, as shown in the following example – without standardized row height on the left, and with on the right.

The starting point was a table with ten entries and a fixed column width (Properties of the Graphical Table, General tab); the wrap was forced after predefined five rows.

Editing a wrapped table

The table wrap is highly dynamic. An essential condition for that is a dynamic environment in which DeltaMaster has absolute authority over the output. This results in certain limits regarding use, namely by other programs (Microsoft Office, web browsers) and by other DeltaMaster functions that compete with the table wrap for control of the precious screen space. For instance, in the event of export, the table wrap is only retained if you export the table as an image; the WebClient does not support the table wrap currently. Automatic row and column structuring (separation) cannot be used concurrently with the table wrap. The analysis functions Zoom and Navigate, searching on the row axis, and displaying as Small Multiples are also not possible in wrapped tables. (Incidentally, the display of Graphical Tables as Small Multiples also adapts very well to the available screen space; despite different concepts, a certain similarity with the table wrap may be seen here.)

Apart from this, the table can still be adapted and structured in Modification mode. For example, you can:

• change the structure of the table by adding, removing, or changing the sequence of dimensions and measures;
• calculate and display variances (Magic Button Deltas);
• display graphics and Sparklines (Magic Button Graphic or History or the Edit menu);
• calculate and display shares (Magic Button Share);
• drill down and roll up branches; and
• display and hide member properties (context menu).

In particular in operational reports, e.g. evaluations of customers, products, or materials – you can make the reports much easier to read with the table wrap. Give it a try now!