« Ledger Cell Value Entry and Aggregation   |   Note Ledger »

View Ledger

Designer Administrator
This manual is in pilot operation.

In a general 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 the same dimension. In the example above, if region and type are determined by the customer, 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 a general 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 appearance" for a regular ledger (Base Ledger).

A View Ledger does not hold data itself. Search requests to a View Ledger are converted and processed as search requests 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 also be used as the "Customer Dimension" in the View Ledger, in addition to being mapped as, say, "Customer 2" dimension (included in the dimension configuration of the View Ledger).

In search requests to a View Ledger, one dimension can be treated as multiple dimensions, with members specified for each. However, these dimensions are, in essence, identical. For instance, suppose in the "Customer" dimension, there are member trees for regions and types, and the search request specifies members as follows:

  • For the Customer Dimension, specify "Northeast Total"

  • For the Customer 2 Dimension, specify "Specialty Food Stores Total"

The search result would provide the total figures for customers who are specialty food stores in the Northeast, 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 regular 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 those dimensions, the dimension that has the same content and is used in the Base Ledger must be specified as the "Base Dimension". In the example mentioned above, "Customer 2" is an additional dimension in the View Ledger, and "Customer" dimension is its Base Dimension. The "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 dimensions that are "Used" in the dimension configuration of the Base Ledger. However, such dimensions must be the "Base Dimension" for 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 dimensions A1 and A2 based on 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 related 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 in 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 in the Base Ledger to allow only certain participants access to data for a specific customer, 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 domain definition expression in the Access Permission Type 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 "domain definition expression" to that cell, not because access to the cells of the Base Ledger was restricted.