« Ledger Cell Value Entry and Aggregation   |   Note Ledger »

View Ledger

Designer Administrator
This manual is in pilot operation.

In an ordinary ledger, cross-tabulation between different dimensions is possible. For instance, if you wish to cross-tabulate sales by region and customer type (e.g., specialty food stores, general supermarkets), setting up region and customer type dimensions and using them in a ledger facilitates cross-tabulation.

However, there may be cases where you want to perform cross-tabulation between different member trees within a dimension. In the example above, if a region and a customer type are determined for each customer, rather than having two separate dimensions for these two classifications, it might be more appropriate to have member trees for regions and types within a single "Customer" dimension and perform cross-tabulation between these two trees. This way, the data can be automatically aggregated based on the member trees without needing to include region or type in the data keys.

Nevertheless, such cross-tabulations cannot be performed in an ordinary ledger. As mentioned at the beginning, cross-tabulation is only possible "between different dimensions."

A View Ledger is a mechanism that enables "cross-tabulation using multiple member trees within a single dimension".

What is a View Ledger

A View Ledger provides "a different view" for a regular ledger (base ledger).

A View Ledger does not hold data itself. Querries to a View Ledger are converted and processed as queries to the base ledger. Each dimension included in the base ledger’s dimension configuration can be correspondingly 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, and in addition, it can also be mapped to, say, "Customer 2" dimension (included in the dimension configuration of the View Ledger).

In querying a View Ledger, one dimension can be treated as multiple dimensions, which means different members can be specified for each of them. However, these dimensions are, in essence, identical. For instance, suppose in the "Customer" dimension, there are member trees for regions and types, and the query specifies members as follows:

  • For the Customer Dimension, "Northeast Region Total" is specified.

  • For the Customer 2 Dimension, "Specialty Food Stores Total" is specified.

The query result would provide the total figures for customers who are specialty food stores in the Northeast region, effectively performing cross-tabulation between the regional and type member trees within the Customer dimension.

Specifications for View Ledger

The specifications and restrictions for View Ledger are as follows:

  • View Ledgers are read-only. The cell values of a View Ledger are indirectly updated by updating the cell values of its base ledger. Apart from that, data input and output for a View Ledger can be treated exactly the same as a ordinary ledger.

  • A View Ledger is always created based on a single ledger (base ledger). Any number of View Ledgers can be established based on one base ledger.

  • Dimensions not used in the base ledger can additionally be used in the View Ledger. In this case, for each of these dimensions, a dimension that has the same content and is used in the base ledger must be specified as its "Base Dimension". In the example mentioned above, "Customer 2" is an additional dimension in the View Ledger, and "Customer" dimension is its base dimension. Having "same content" means that either dimension borrows from the other, or both dimensions borrow from the same dimension. See Borrowing Dimensions for more details.

  • In the dimension configuration of the View Ledger, it is not necessary to use all dimensions that are "Used" in the dimension configuration of its base ledger. However, dimensions used in the base ledger must be assigned as the "Base Dimension" to at least one of the dimensions used in the View Ledger. Of course, if there is no particular need to reinterpret dimensions, you can use the same dimension as its base.

  • If the base ledger is a Note Ledger, the View Ledger will also be a Note Ledger. If the base ledger is not a Note Ledger, the View Ledger will not be a Note Ledger either.

  • If a View Ledger has the dimensions A1 and A2 based on the dimension A of the base ledger, the value of a cell in the View Ledger specified by member X for A1 and member Y for A2 will be the total of all values in the cells of the base ledger bound to leaf members that are descendants of X and also descendants of Y, with all other dimension member specifications being the same as those for the search target cell.

  • Changes to the cell values of the base ledger through a form do not immediately reflect in the cell values of the View Ledger. However, situations may arise when you want to reflect changes of the base ledger’s cell values in the View Ledger and then calculate values based on those View Ledger cell values to write back to any ledger (e.g., allocation calculations). For such purposes, forms are equipped with the "Iterative Reflection Function".

  • Access Control for the base ledger does not automatically apply to the View Ledger. For example, even if Access Permission Types are set up to allow only certain participants access to data for a specific customer in the base ledger, these restrictions do not extend to the View Ledger.[1] The same applies to Ledger Masks. It is necessary to appropriately describe Access Permission Types (and Ledger Masks) to control access to the View Ledger as well.

1. Of course, it is possible to write a read/write permission expression in the Access Permission Types to restrict access to data for a specific customer to certain participants, regardless of the ledger. However, even then, the restriction on access to the cell values of the View Ledger comes from the application of the "read/write permission expression" to that cell, not because access to the cells of the base ledger was restricted.