« View Ledger (ChatGPT)   |   Ledger Edition Management (ChatGPT) »

View Ledger (DeepL)

designer administrator
This manual is in pilot operation.

The general ledger allows cross tabulation between different dimensions. For example, if you want to cross-tabulate sales by region and customer category (e.g., food specialty store, general merchandise store), you can do so by creating a region dimension and a customer category dimension, and then creating a ledger that uses both dimensions.

On the other hand, there are cases where you want to perform cross tabulation between different member trees within a single dimension. In the above example, if the region and business type are defined for each client, it may be more appropriate to have a member tree for each region and a member tree for each business type within a single "client" dimension, and perform cross tabulation between these two member trees, instead of having a separate dimension for each of them. In this way, the data can be automatically aggregated based on the member trees without having to include the region or business type in the data key, but only the store.

However, such cross tabulation is not possible in general ledgers. As mentioned at the beginning of this article, cross tabulation can only be performed "between different dimensions.

The view ledger is a system that enables such "cross tabulation using multiple member trees within a single dimension".

What is "view ledger"?

A view ledger is a ledger that provides "another look" to the normal ledger (base ledger).

The view ledger itself does not hold data. Search requests to the view ledger are converted to search requests to the base ledger and processed. Each dimension in the dimension structure of the base ledger can be mapped to multiple dimensions with the same content in the view ledger. For example, if the base ledger uses the "Customer" dimension, it can be used as the "Customer dimension" in the view ledger, but in addition, the "Customer dimension" can be mapped to, for example, the "Customer 2" dimension (and included in the view ledger’s dimension dimension in the View Ledger).

In a search request to the view ledger, a dimension can be treated as multiple dimensions, each with its own members, but these dimensions are identical in substance. For example, suppose that there is a member tree by region and a member tree by business type in the "Clients" dimension, and that the members are specified in the search request as follows:

  • For the Customers dimension, specify "Northeast Total.

  • For the customer 2 dimension, specify "Total Food Specialty Stores.

Then, as a search result, we get the total number of clients that are food specialty stores in Tohoku. In other words, a cross tabulation is performed by combining the member trees by region and by business type in the customer dimension.

Specifications for view ledger

The specifications and restrictions regarding the view ledger are as follows.

  • View ledger is for reference only. Cell values in the view ledger are updated indirectly by updating cell values in its base ledger. Except for this, view ledgers can be treated exactly like regular ledgers in terms of data input and output.

  • View ledgers are always created from a single ledger (base ledger). Any number of view ledgers can be created based on a single base ledger.

  • Dimensions not used in the base ledger can be additionally used in a view ledger. In this case, a dimension that has the same content and is used in the base ledger must be specified as the "base dimension" for that dimension. In the example above, "Customer 2" is the dimension added in the view ledger, and the "Customer" dimension is its base dimension. Note that "same content" for two dimensions means that one of them is the same as the other. /07_dimensions/08_borrowing_dimensions.adoc[borrowed] or they both borrow the same dimension.

  • View ledger dimension configurations do not need to use dimensions that are "used" in the base ledger dimension configuration. On the other hand, such dimensions must be "base dimensions" for at least one dimension used in the view ledger. Of course, if there is no particular need to read a dimension differently, it can be the base of the same dimension.

  • If the base ledger is Note Ledger, then the view ledger is also the Note Ledger. If the base ledger is not a Note Ledger, the view ledger is not a Note Ledger.

  • If the view ledger has dimensions A1 and A2 that are based on dimension A of the base ledger, the values of the cells in the view ledger obtained by specifying member X for A1 and member Y for A2 are the same as the cells being searched for all dimensions except A, which are descendants of dimension A The value of the cell in the view ledger that results from specifying member Y for member XA2 for A1 is the sum of the values of all cells in the base ledger for leaf members that are descendants of member X and also descendants of member Y for dimension A1.

  • When you change a cell value in the base ledger by a form, the change is not immediately reflected in the cell value of the view ledger. However, there are situations (e.g., allocation calculations) where it is desirable to reflect changes in base ledger cell values in the view ledger and then calculate values based on the view ledger cell values and write them to one of the ledgers. For this purpose, the form should contain a "link:. /10_forms/04_full_featured_forms/02_components/01_default_settings.adoc#IterativeReflection [Iterative Reflection Function]".

  • link to base ledger:. /09_ledger_access_control/01_overview_of_ledger_access_control.adoc[access_control]] is not automatically applied to the view ledger. For example, in the base ledger, only certain Participants can access data for a particular client, link:. For example, even if /09_ledger_access_control/03_access_permissions.adoc[access_permission_type] is set in the base ledger to allow only specific business units to access data for a particular client, that restriction will not extend to the view ledger. link:. The same applies to /09_ledger_access_control/02_ledger_mask.adoc[ledger mask]. It is necessary to describe the permission type (and ledger mask) appropriately so that access to the view ledger is also controlled.

Of course, it is possible to specify a permission type that allows only Participants to access a specific client’s data, regardless of the ledger. However, even in such a case, access to cell values in the view ledger is restricted only as a result of applying the "area definition formula" of the permission type to that very cell, not because access to cells in the base ledger is restricted.