|
16.02.2013, 08:08 | #1 |
Участник
|
ax_gfm_framework_team: Ledger account combinations - Part 5 (Ledger dimensions (A))
Источник: http://blogs.msdn.com/b/ax_gfm_frame...ns_2900_-.aspx
============== Introduction Continuing this series of blog posts, we will cover the LedgerDimensions region highlighted in pale yellow in the model below in figure 1. This region will be discussed in two parts covering this post and the next post. Once all of the configuration data is set up, ledger account combinations can be entered, validated and persisted. The primary consumption of the dimension framework occurs when the application leverages this area. Ledger dimension storage without rules To understand LedgerDimensions, we need to understand how a ledger account combination is entered by a user. Using the account structure and rule setup from the previous blog post (#4 - Advanced rules), we will walk through the user interaction with the account entry control when an account is entered. To refresh, the account structure appears as follows: There is a single account rule associated with the structure: With the added structure defined as follows: When a user first sees a ledger account field on a form, it will appear as follows when focus is not in the field: When the user clicks into the field, since the account structure has 2 segments, the following will appear: The user then enters the combination of [ 150 - A ]. As soon as the second segment is entered and the user tabs out of the control, the dimension framework saves the combination and then validates if the combination is valid based on the constraints. In this case, the combination is valid. The following is known about the combination:
The first table is named DimensionAttributeValueCombination as it stores a full multi-segment account combination along with some de-normalized information about the combination such as the concatenated segments as a single string, a foreign key (FK) reference to the Account structure, and a FK to the MainAccount (150) that was used. Skipping the second table for now, the third table is named DimensionAttributeValueGroup. It has this name as it stores each related group of segments associated with each structure that is present in the combination. In this case, there is only one structure, the Account structure, so there is only one record here. The fourth table, named DimensionAttributeLevelValue, stores the individual segment values for each segment within the associated group or structure. One record exists for each segment entered. When a segment is empty, no values are stored for it. Each record references the corresponding DimensionAttributeValue record. If an existing one is found it is referenced, or if one does not exist for the value, it is created. This is the data linking the DimensionAttribute to the real backing entity record. In this case, one is for the MainAccount record with an ID of 150, and one is for the CustTable record with an ID of A. In order to link the group of the account structure values and the segment values to the main record in the DimensionAttributeValueCombination table, a record is inserted into the second table above in figure 8, DimensionAttributeValueGroupCombination. In order to save a single segment in a new combination at least one record is inserted in each of these 4 tables. An additional record is inserted in the DimensionAttributeLevelValue table for each additional segment entered. Abstractly, these 4 tables are referred to as a LedgerDimension. A LedgerDimension is expressed as a FK that references the RecId in the DimensionAttributeValueCombination table. The use of advanced rules plays a role in the number of records involved in these tables for a combination. This will be covered in the next blog post. Источник: http://blogs.msdn.com/b/ax_gfm_frame...ns_2900_-.aspx
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|
|
|