View Ledger (ChatGPT)
This manual is in pilot operation.
|
In a general ledger, cross-tabulation between different dimensions is possible. For example, if you want to cross-tabulate sales by region and customer type (such as food specialty stores, general supermarkets), you can set up a region dimension and a customer type dimension and use them in a ledger to enable cross-tabulation.
However, there may also be cases where you want to perform cross-tabulation between different member trees within a single dimension. In the example above, if the region and type are determined for each customer, it might be more appropriate to set up member trees for regions and types within a single "Customer" dimension and perform cross-tabulation between these two member trees. This way, even without including region or type in the data keys, aggregation can be automatically performed based on the member trees.
However, such cross-tabulation cannot be performed in a general ledger. As mentioned at the beginning, cross-tabulation is only possible "between different dimensions."
The 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 an "alternative appearance" to a normal ledger (base ledger).
The view ledger itself does not hold data. Search requests to the view ledger are converted into search requests to the base ledger for processing. Each dimension included in the dimension configuration of the base ledger can be mapped to multiple dimensions of 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, but in addition, the "Customer Dimension" can be mapped to, for example, a "Customer 2" dimension for use (included in the dimension configuration of the view ledger).
In search requests to the view ledger, one dimension can be treated as multiple dimensions, and members can be specified for each, but these dimensions are essentially the same. For example, suppose the following members are specified in a search request:
-
For the Customer dimension, specify "Tohoku Total"
-
For the Customer 2 dimension, specify "Food Specialty Store Total"
Then, the search result will give you the total figures for customers who are food specialty stores in the Tohoku region. In other words, you have performed cross-tabulation combining member trees for regions and types within the Customer dimension.
Specifications Regarding View Ledgers
Specifications and constraints regarding view ledgers 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 this, view ledgers can be treated exactly the same as normal ledgers for data input and output.
-
A view ledger is always created based on one ledger (base ledger). Any number of view ledgers can be set up based on one ledger.
-
Dimensions not used in the base ledger can be additionally used in the view ledger. In this case, you must specify one of the dimensions used in the base ledger as the "base dimension" for that dimension. In the example mentioned above, "Customer 2" is the dimension added in the view ledger, and the "Customer" dimension is its base dimension. "The same content" means that one borrows from the other, or both borrow the same dimension.
-
It is not necessary to use dimensions that are "used" in the dimension configuration of the base ledger in the view ledger’s dimension configuration. However, such dimensions must be the "base dimension" for at least one dimension 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](link:06_note_ledgers.adoc), 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 for member X in A1 and member Y in A2 will be the total of all cell values in the base ledger for leaf members that are descendants of both X and Y in dimension A, with all other dimension member specifications being the same as the target cell.
-
When the cell values of the base ledger are changed by a form, those changes are not immediately reflected in the view ledger’s cell values. However, there are situations where 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 (such as allocation calculations). For such purposes, forms are equipped with the ["Iterative Reflection" feature](link:../10_forms/04_full_featured_forms/02_components/01_default_settings.adoc#IterativeReflection).
-
[Access control](link:../09_ledger_access_control/01_overview_of_ledger_access_control.adoc) for the base ledger does not automatically apply to the view ledger. For example, even if an [access permission type](link:../09_ledger_access_control/03_access_permissions.adoc) is set in the base ledger so that only specific business units can access data for certain customers, that restriction does not extend to the view ledger (※). The same applies to [ledger masks](link:../09_ledger_access_control/02_ledger_mask.adoc). It is necessary to appropriately describe access permission types (and ledger masks) to control access to the view ledger as well.
※ Of course, it is possible to describe an area definition expression in the access permission type that restricts access to specific customer data to specific business units, regardless of the ledger. However, even in that case, the restriction of access to the view ledger’s cell values is the result of the access permission type’s "area definition expression" being applied to that cell, not because access to the cell in the base ledger was restricted.