Implementing The Account and Financial Dimensions Framework AX2012
Implementing The Account and Financial Dimensions Framework AX2012
Implementing the Account and Financial Dimensions Framework for Microsoft Dynamics AX 2012 Applications
White Paper
This document highlights new patterns used to represent accounts and financial dimensions and describes how to convert the existing patterns to the new Microsoft Dynamics AX 2012 patterns. This white paper has been updated for Microsoft Dynamics AX 2012 R2. Date: June 2013
http://microsoft.com/dynamics/ax
Authors: Bill Frandsen, Senior Developer Jason Dinham, Senior Development Lead Send suggestions and comments about this document to [email protected]. Please include the title with your feedback.
Table of Contents
Overview..................................................................................................... 4
Audience.............................................................................................................................. 4 Terminology ......................................................................................................................... 5
Appendix ................................................................................................... 44
Overview
In Microsoft Dynamics AX 2012, the account and financial dimensions framework has been enhanced to provide substantially more functionality. To support this new functionality, the data model has also been completely redesigned. Therefore, developers will need to update every reference to ledger accounts and financial dimensions in existing applications to reference the new data model. Each of the account and financial dimensions patterns defined in this white paper has a corresponding Microsoft Dynamics AX form control. Form controls provide a consistent implementation of the functionality across the application and a simplified programming model for the framework. Account form controls combine the Segmented Entry control and a controller class. The Segmented Entry control is a general-purpose Microsoft Dynamics AX client control that is being introduced in Microsoft Dynamics AX 2012. The controller class is an X++ class that handles the events raised by the Segmented Entry control. The combination of a control and an underlying class allows the user to see a dynamic number of segments, based on the values the user provides. The controls described in this white paper handle lookup, view details functionality, and validation for each segment in the account number. This design allows for a straightforward and consistent implementation of these patterns in Microsoft Dynamics AX forms. In Microsoft Dynamics 2009, a ledger account was represented by a single string value and was considered to be separate from the financial dimensions. Ledger accounts were stored in the LedgerTable table. When developers needed to hold a foreign key to a ledger account, they stored the string LedgerTable.AccountNum for that account in their table. Financial dimensions were referenced as an array of up to 10 array elements that each held the string value of a foreign key to the Dimensions table. All financial dimension values were stored in the Dimensions table. You could not use data stored in other Microsoft Dynamics AX tables as financial dimensions. In Microsoft Dynamics AX 2012, no part of the legacy framework still exists. However, many of the underlying concepts persist. Microsoft Dynamics AX 2012 still has ledger accounts and financial dimensions, but the definition of these terms has changed slightly to account for the new functionality. This document does not discuss all of the new functionality within ledger accounts and financial dimensions. Instead, it highlights the new patterns that are used to represent ledger accounts and financial dimensions and describes how to convert existing patterns to the new Microsoft Dynamics AX 2012 patterns. Note that financial dimension pattern enhancements do not affect inventory dimension patterns in any way.
Note: Changes have been made to this paper after it was initially published. For details, see Updates since initial publication.
Audience
This white paper is intended for developers who are building new applications for Microsoft Dynamics AX 2012 and developers who are updating their existing application code and data.
Terminology
Microsoft Dynamics AX 2012 terms:
Term
Advanced rule
Definition
A rule in an accounting system that controls the additional valid financial dimension value combinations when the requirements of the account structure condition are met. A configuration of the main account financial dimension and other financial dimensions. A financial data classifier created from the parties, locations, products, and activities in an organization and used for management reporting. A data element in the domain of a financial dimension. A classifier created from the combination of the main account value listed in a chart of accounts and other financial dimension values; used to classify the financial consequences of economic activity. A shortcut that is used to retrieve a complete or partial ledger account. A classifier of economic resource value based on the claims that parties make on the economic resources owned by a legal entity; used to classify debit and credit entries in an accounting system.
Additional notes about terminology use in Microsoft Dynamics AX 2012: Ledger account: In previous versions of Microsoft Dynamics AX, the term ledger account was used to specify what is now referred to as the main account. This terminology was used mainly because the application never merged the ledger account with financial dimensions to create ledger account combinations. Financial dimension fields were always tracked separately. In Microsoft Dynamics AX 2012, the main account is merged with financial dimensions to create a more integrated view of the chart of accounts (COA) and financial activity. Financial dimension: The meaning of this term across the application has not changed. However, the functionality and implementation are very different. With the new support for unlimited financial dimensions in Microsoft Dynamics AX 2012 and the ability to use existing application data to define financial dimensions, the functionality has been greatly enhanced.
After the code upgrade is complete, developers should refer to the Data upgrade section of this white paper to code their data upgrade scripts.
Default account
Previous version A default account in Microsoft Dynamics AX 2009 was a string field that held the ledger account and was a foreign key to the LedgerTable table. The field was used primarily on posting profiles to determine which ledger account should be used when posting to the general ledger. Microsoft Dynamics AX 2012 The default account pattern consists of a single segment, main account. The default account is a separate pattern from the main account because of the additional business logic built into its underlying control. This business logic handles data restrictions in lookups and other critical functionality that would have to be developed separately in each uptake scenario without the control. A foreign key representing a default account is a 64-bit integer field that contains the data from the corresponding RecId field in the DimensionAttributeValueCombination (or LedgerDimension) table. Foreign key fields for default accounts are named LedgerDimension because that is the alias used for the DimensionAttributeValueCombination table. For a data model diagram of the DimensionAttributeValueCombination subsystem, see the Appendix.
Main account
Previous version In Microsoft Dynamics AX 2009, the main account pattern was most closely represented by ledger accounts in the LedgerTable table. There was no difference between default account patterns and main account patterns in the previous version of the framework. Microsoft Dynamics AX 2012 The main account pattern represents just one of the possible segments in a ledger account. A main account is required in a ledger account, but it does not have to be the first segment. When referencing a main account as a foreign key, the developer should set up a reference to the RecId field in the MainAccount table. For a data model diagram of the MainAccount table, see the Appendix.
Ledger account
Previous version In Microsoft Dynamics AX 2009, the ledger account pattern was the same as the main account and default account patterns. Microsoft Dynamics AX 2012 A ledger account contains the main account, account structure, and the financial dimension values that are needed to populate the related account structure and advanced rule structures. A foreign key representing a ledger account is a 64-bit integer field that contains the data from the corresponding RecId field in the DimensionAttributeValueCombination table (also called the LedgerDimension table). Foreign key fields for ledger accounts are named LedgerDimension because that is the alias used for the DimensionAttributeValueCombination table. For a data model diagram of the DimensionAttributeValueCombination subsystem, see the Appendix.
Multi-type account
Previous version In Microsoft Dynamics AX 2009, all financial modules used a common structure for their account numbers, which was a String10. This pattern allowed a single string field to hold the account
number, regardless of which account type was selected. Additional business logic was needed to determine which account type the developer was dealing with. This pattern could produce discrepancies, such as when a user decided to change the account number format for one module (for example, changing bank to a String30) but not for the related modules that shared the account number field. Microsoft Dynamics AX 2012 The multi-type account pattern consists of an account type field and its related ledger account or default account. In this pattern, a ledger account or default account can store accounts other than ledger accounts. When the account type field for the related account is set to ledger, this pattern becomes the default account or ledger account pattern (depending on the extended data type used for the field). If the account type field is not set to ledger, the pattern stores a system-generated account structure (used to specify which account number should be stored in the field) and an account number for the related account type. For example, if the account type field is set to customer, the related account number field will contain a customer number with a related account structure that indicates that the account number field should contain a single customer value. This pattern is primarily used for the setup and entry of financial journals. In this case, a multitype account will store one of six types of accounts, based on the related account type field (asset, bank, customer, vendor, project, or ledger). A foreign key representing a multi-type account is a 64-bit integer field that contains the data from the corresponding RecId field of the DimensionAttributeValueCombination (LedgerDimension) table. Foreign key fields for multi-type accounts are named LedgerDimension because that is the alias used for the DimensionAttributeValueCombination table. For a data model diagram of the DimensionAttributeValueCombination subsystem, see the Appendix.
Default dimension
Previous version The default dimension pattern represented a set of financial dimensions and their values. A customer typically set the values for given financial dimensions on master data records for defaulting purposes or directly on some transactions. This pattern was represented in the Microsoft Dynamics AX 2009 data model with a financial dimensions array field. In the Application Object Tree (AOT), this field was represented as a single array field. In the database, the array was represented as having a one field per-array element. The dimension array could have from 3 to 10 elements. Microsoft Dynamics AX 2012 The default dimension pattern still represents a set of financial dimensions and their related values. A customer will still set the values for given financial dimensions on master data records for defaulting purposes or directly on some transactions. The primary difference is in how this data is stored. In the new data model, this pattern is represented by a single field. The single field is a foreign key reference to the RecId field in the DimensionAttributeValueSet table. This new value references the correct record in the DimensionAttributeValueSet (or Default Dimension) table. Whereas the previous model limited storage to 10 financial dimensions, the new model allows you to store an unlimited number of financial dimensions and their values. For a data model diagram of the DimensionAttributeValueSet subsystem, see the Appendix.
Default account
In Microsoft Dynamics AX 2009, account numbers from the LedgerTable table that were used to post financial activity to the general ledger were considered to represent default accounts. To upgrade your code for Microsoft Dynamics AX 2012, you must replace your data model with the new field names and extended data types specified in the following table. You need to update the forms where these fields are displayed to use the control defined in this section. The X++ code that references these fields must use the new fields and code patterns defined for default accounts.
Data model and extended data types The following table lists the previous and new extended data types (EDTs) and fields related to default accounts.
Previous EDTs Microsoft Dynamics AX 2012
AccountNum LedgerAccount
LedgerDimensionDefaultAccount
Fields
4. Override the following methods on the Segmented Entry control instance in the form design.
public void jumpRef() { ledgerDimensionDefaultAccountController.jumpRef(); } public void loadAutoCompleteData(LoadAutoCompleteDataEventArgs _e)
{ super(_e); ledgerDimensionDefaultAccountController.loadAutoCompleteData(_e); } public void segmentValueChanged(SegmentValueChangedEventArgs _e) { super(_e); ledgerDimensionDefaultAccountController.segmentValueChanged(_e); } public void loadSegments() { super(); // (Optional parm*() specification should go here, see the Control options section.) ledgerDimensionDefaultAccountController.parmControl(this); ledgerDimensionDefaultAccountController.loadSegments(); } public boolean validate() { boolean isValid; isValid = super(); isValid = ledgerDimensionDefaultAccountController.validate() && isValid; return isValid; }
5. Override the following methods on the data source field that backs the Segmented Entry control.
public Common resolveReference(FormReferenceControl _formReferenceControl) { return ledgerDimensionDefaultAccountController.resolveReference(); }
Control options
There are four parameter methods available for specifying items that the control can link to and validate. These parameter methods should be called in the loadSegments method. These methods are called every time that the control receives focus. Always declaring the parameters in one method ensures that developers can easily verify whether all parameters have been correctly set. parmCurrentLedgerCOA: Specifies a particular chart of accounts from which to derive the list of main accounts. The default value is the current chart of accounts. parmFilterLedgerPostingType: Specific main accounts can be excluded from the lookup based on the posting type, but the values are allowed to be entered manually. The default value is None, meaning all accounts are valid. Note The parameter name (FilterLedgerPostingType) differs from the one for the Ledger Account control because, in this case, it only restricts what is shown in the lookup when the filter is selected. For account entry, it prevents entry of values entirely. parmIncludeFinancialAccounts and parmIncludeTotalAccounts: Specific main accounts can be excluded from the lookup and prevented from being entered manually. The IncludeFinancialAccounts and IncludeTotalAccounts parameters are used for validation and lookup to restrict valid values. The default value for each parameter is false.
Main account
In Microsoft Dynamics AX 2012, account numbers from the LedgerTable table that are used to specify the account as a generic reference are considered to be main accounts. All references used to build ledger accounts should use the default account pattern instead. When the main account pattern is required, the data model must be replaced with the new field names and extended data types specified in the following table. The forms where these fields are displayed need to be updated to use the reference group controls used for the refRecId pattern. The X++ code that references these fields must use the new fields that you add to your data model.
AccountNum LedgerAccount
MainAccountNum
Fields
Find all MainAccount records for a specific chart of accounts, given the name of that chart.
select MainAccountId from MAINACCOUNT join LEDGERCHARTOFACCOUNTS on (MAINACCOUNT.LEDGERCHARTOFACCOUNTS = LEDGERCHARTOFACCOUNTS.RECID) where LEDGERCHARTOFACCOUNTS.NAME = 'EXT'
Find all MainAccount records for a specific chart of accounts, given the legal entity name.
select MAINACCOUNT.MAINACCOUNTID from MAINACCOUNT join LEDGERCHARTOFACCOUNTS ON (MAINACCOUNT.LEDGERCHARTOFACCOUNTS = LEDGERCHARTOFACCOUNTS.RECID) join LEDGER ON (LEDGER.CHARTOFACCOUNTS = LEDGERCHARTOFACCOUNTS.RECID) join COMPANYINFO ON (LEDGER.PRIMARYFORLEGALENTITY = COMPANYINFO.RECID) where COMPANYINFO.DATAAREA = 'DMO'
Ledger account
In Microsoft Dynamics AX 2009, an account number from the LedgerTable table was considered to represent a ledger account. The account number was combined with the financial dimensions array to link financial activity to a ledger account. An example of this was the LedgerTrans table, in which the AccountNum field represented the ledger account and the Dimension field represented the financial dimensions. In Microsoft Dynamics AX 2012, these fields are deleted and replaced with a single field that holds the main account and all financial dimensions related to financial activity. To upgrade your code for Microsoft Dynamics AX 2012, your data model must be replaced with the new field names and extended data types specified in the following table. You need to update forms in which these fields are displayed to use the control defined in this section. The X++ code that references these fields must use the new fields and code patterns defined for default accounts. Often, the most difficult upgrade task is determining whether to convert AccountNum and Dimension fields in a single table to the ledger account pattern, or to convert the fields to use the default account and default dimensions patterns.
Data model and extended data types The following table lists the previous and new extended data types (EDTs) and fields related to ledger accounts.
Previous EDTs Microsoft Dynamics AX 2012
AccountNum LedgerAccount
LedgerDimensionAccount
Fields
}
4. Override the following methods on the Segmented Entry control instance in the form design:
public void jumpRef() { ledgerDimensionAccountController.jumpRef(); }
public boolean validate() { boolean isValid; isValid = super(); isValid = ledgerDimensionAccountController.validate() && isValid; return isValid; } public void segmentValueChanged(SegmentValueChangedEventArgs _e) { super(_e); ledgerDimensionAccountController.segmentValueChanged(_e); } public void loadSegments() { super(); ledgerDimensionAccountController.parmControl(this); // The value of this parameter varies depending on the type of form. // See the Control options section below for more detail. ledgerDimensionAccountController.loadSegments(); } public void loadAutoCompleteData(LoadAutoCompleteDataEventArgs _e) { super(_e); ledgerDimensionAccountController.loadAutoCompleteData(_e);
}
5. Override the following methods on the data source field that backs the Segmented Entry control:
public Common resolveReference(FormReferenceControl _formReferenceControl) { return ledgerDimensionAccountController.resolveReference(); }
Control options
Several parameters affect the validation, lookup, and saving of ledger accounts performed by the Segmented Entry control. The following are the methods used to set these parameters: parmCurrency: Specifies the currency code associated with the control being managed. The Currency parameter is used for validation and lookup to restrict valid values. The default value is empty and no restriction or validation is done against the currency. parmDataAreaId: Specifies the legal entity associated with the control being managed. The DataAreaId parameter is used to restrict valid values for validation and lookup. The default value is the current legal entity. If this parameter is provided by a field that the user can
manipulate on the form, we recommend that you call the corresponding parm method from the modified method of the control for the DataAreaId field. parmDate: Specifies the date of the transaction associated with the control being managed. The Date parameter is used for validation. The default value is empty and no validation is done against the date. parmDialogField: Specifies the dialog field that references the ledger account when using the LedgerDimensionAccountController on a RunBase dialog. parmDimensionAccountStorageUsage: Specifies how to use account storage for the control being managed. The DimensionAccountStorageUsage parameter is used for validation and for saving combinations. The default value is setup. Use the DimensionAccountStorageUsage enumeration to pass in the type. parmDimensionAutocompleteFilter: Specifies custom filtering of the autocomplete data. Use the DimensionAutocompleteFilterable interface to specify the filtering code. parmDisableMRU: Specifies whether the lookup for the most recently used data should be prevented from appearing. The default value is false. Note: the full lookup showing all or just valid values will still be accessible. parmJournalName: Specifies the journal name associated with the control being managed. The JournalName parameter is used for validation and lookup to restrict valid values. The default value is empty and no restriction or validation is done against the journal name. parmLockMainAccountSegment: Specifies whether the segment containing the main account is non-editable. The default value is false. parmPostingType: Specifies the posting type associated with the control being managed. The PostingType parameter is used for validation and lookup to restrict valid values. The default value is empty and no restriction or validation is done against the posting type. parmSkipSuspendedAndActiveDateValidation: Specifies whether suspended and inactive values can be entered without displaying a validation error. The default value is false. parmTaxCode: Specifies the tax code associated with the control being managed. The TaxCode parameter is used for validation and lookup to restrict valid values. The default value is empty and no restriction or validation is done against the tax code. parmUser: Specifies the user associated with the control being managed. The User parameter is used for validation and lookup to restrict valid values. The default value is the current user. parmValidateBlockedForManualEntry: Specifies whether validation should be enforced for dimension values marked as not allowing manual entry. The default value is false.
These parameters should be specified in the loadSegments method. They are called every time the control receives focus. Always declaring the parameters in one method ensures that developers can easily verify whether all parameters have been correctly set.
Special scenarios
When multiple fields have an account number control, each field should have its own LedgerDimensionAccountController instance. Each instance must have a unique name that ends with LedgerDimensionAccountController and can begin with a functional description of how the backing field is used. If the variable name becomes too long, the LedgerDimension prefix in the variable name can be dropped. Code that is similar to the example shown earlier in this section should be added for each controller instance. When one field needs to be edited in multiple places on the same form, there should be a single LedgerDimensionAccountController instance for the field. When two controls share the same controller, the loadSegments method for each control should always contain a call to parmControl(this) before the call to the loadSegments method for the controller.
Display each segment of the ledger account with data related to the segments. Note We have created a view in the AOT to simplify querying the database in this common scenario. In this example, we return the display value separately for each segment in a ledger account.
select DALVV.DISPLAYVALUE from DIMENSIONATTRIBUTELEVELVALUEVIEW DALVV where DALVV.VALUECOMBINATIONRECID = 1
Multi-type account
In Microsoft Dynamics AX 2009, there were scenarios in which the value of an account number was dependent on a related field (often called the account type field). Depending on the account type that was selected, a specific type of account number was stored. For example, if the customer account type was selected, an account number representing a customer was expected in the account number field. The most common scenario for this pattern involved the financial journals, where the user could select from six different account types. In Microsoft Dynamics AX 2012, this pattern still exists. The pattern has been built into the account and financial dimension framework to address the requirements of financial journals. The pattern is more complicated in Microsoft Dynamics AX 2012 because the ledger account is very different from other accounts that can be entered on a financial journal. Ledger accounts now allow the user to enter many segments.
Data model and extended data types The following table lists the previous and new extended data types (EDTs) and fields related to multitype accounts.
Previous EDTs Microsoft Dynamics AX 2012
AccountNum LedgerAccount
DimensionDynamicAccount
Fields
4. Override the following methods on the Segmented Entry control instance in the form design.
public void jumpRef() { dimAccountController.jumpRef(); } public void loadAutoCompleteData(LoadAutoCompleteDataEventArgs _e) { super(_e); dimAccountController.loadAutoCompleteData(_e); } public void segmentValueChanged(SegmentValueChangedEventArgs _e) { super(_e); dimAccountController.segmentValueChanged(_e); } public void loadSegments() { super(); // (Optional parm*() specification should go here, see the Control options section.) dimAccountController.parmControl(this); dimAccountController.loadSegments(); } public boolean validate() { boolean isValid; isValid = super(); isValid = dimAccountController.validate() && isValid; return isValid; }
5. Override the following methods on the data source field that backs the Segmented Entry control.
public Common resolveReference(FormReferenceControl _formReferenceControl) { return dimAccountController.resolveReference(); }
Control options
Several parameter methods can be used to manage the information that the control links to and validates: parmCurrency: Specifies the currency code associated with the control that is being managed. The Currency parameter is used for validation and lookup to restrict valid values. The default value is empty and no restriction or validation is done against the currency. parmDataAreaId: Specifies the legal entity associated with the control being managed. The DataAreaId parameter is used for validation and lookup to restrict valid values. The default value is the current legal entity. If this is provided by a field that the user can manipulate on the form, we recommend that you call the corresponding parm method from the modified method of the control for the DataAreaId field. parmDate: Specifies the date of the transaction associated with the control being managed. The Date parameter is used for validation. The default value is empty and no validation is done against the date. parmDialogField: Specifies the dialog field that references the ledger account when using the LedgerDimensionAccountController on a RunBase dialog. parmDimensionAccountStorageUsage: Specifies how the control being managed is used. The DimensionAccountStorageUsage parameter is used for validation and the saving of combinations. The default value is setup. parmDimensionAutocompleteFilter: Specifies custom filtering of the autocomplete data. Use the DimensionAutocompleteFilterable interface to specify the filtering code. parmDisableMRU: Specifies whether the lookup for the most recently used data should be prevented from appearing. The default value is false. Note: The full lookup showing all or just valid values will still be accessible. parmFilterLedgerPostingType: Specific main accounts can be excluded from the lookup based on the posting type, but the values are allowed to be entered manually. The default value is None, meaning all accounts are valid. See also parmPostingType. parmIsDefaultAccount: Specifies whether the control presents a default account or a full account/dimension combination pattern. parmJournalName: Specifies the journal name associated with the control being managed. The JournalName parameter is used for validation and lookup to restrict valid values. The default value is empty and no restriction or validation is done against the journal name. parmPostingType: Specifies the posting type associated with the control being managed. The PostingType parameter is used for validation and lookup to restrict valid values. The default value is empty and no restriction or validation is done against the posting type. parmSkipSuspendedAndActiveDateValidation: Specifies whether suspended and inactive values can be entered without displaying a validation error. The default value is false. parmTaxCode: Specifies the tax code associated with the control being managed. The TaxCode parameter is used for validation and lookup to restrict valid values. The default value is empty and no restriction or validation is done against the tax code. parmUser: Specifies the user associated with the control being managed. This parameter is used for validation and lookup to restrict valid values. The default value is the current user. parmValidateBlockedForManualEntry: Specifies whether validation should be enforced for dimension values marked as not allowing manual entry. The default value is false. parmIncludeTotalAccounts: Specifies whether main accounts marked as total can be used. The IncludeTotalAccounts parameter is used for validation and lookup to restrict valid values. The default value is false.
Parameters should be specified in the loadSegments method and are called every time the control receives focus. Always declaring the parameters in one method ensures that developers can easily verify whether all parameters have been correctly set.
Display the account with data related to the segment. Note We have created a view in the AOT to simplify querying the database in this common scenario. The DimensionAttributeLevelValue.DisplayValue, DimensionAttribute.RecId, and DimensionAttributeValue.RecId are returned for each segment in the multi-type account. The RecIds that are returned can be useful because the DimensionAttribute table defines which entity the account number is related to. You can use this additional information to determine whether the DisplayValue is displaying a vendor account or a customer account.
select DALVV.DISPLAYVALUE, DALVV.DIMENSIONATTRIBUTE, DALVV.ATTRIBUTEVALUERECID from DIMENSIONATTRIBUTELEVELVALUEVIEW DALVV where DALVV.VALUECOMBINATIONRECID = 1
Default dimension
In Microsoft Dynamics AX 2009, financial dimensions were stored in an array of string values on every table that needed to reference a set of financial dimension values. Master data tables, such as Customer, Vendor, and Bank Account, held these sets of financial dimension defaults for use during subledger posting to the general ledger. The posting code merged multiple sets of financial dimensions to determine which financial dimension values to update during the general ledger posting. To upgrade your code for Microsoft Dynamics AX 2012, your data model must be replaced with the new field names and extended data types specified in the following table. Forms that display these fields need to be updated to use the control defined in this section. The X++ code that references these fields must use the new fields and code patterns defined for default dimensions.
Data model and extended data type The following table lists the previous and new extended data types (EDTs) and fields related to default dimensions.
Previous EDTs Microsoft Dynamics AX 2012
DimensionDefault
Fields
Dimension
class declaration
public class FormRun extends ObjectRun { DimensionDefaultingController dimDefaultingController; }
5. Override the following methods on the form data source that contains the foreign key to the DimensionAttributeValueSet table.
public int active() { int ret; ret = super(); dimDefaultingController.activated(); return ret; } public void write() { dimDefaultingController.writing(); super(); } public void delete() { super(); dimDefaultingController.deleted(); }
Control options
Two overloads of the constructor will build the Default Dimension control with different characteristics: DimensionDefaultingController::constructInGroupWithValues : Constructs an instance of the DimensionDefaultingController class with a StringEdit control associated with each dimension attribute that is added to the specified FormGroupControl object. DimensionDefaultingController::constructInTabWithValues: Constructs an instance of the DimensionDefaultingController class with a StringEdit control associated with each dimension attribute that is added to the specified FormTabPageControl object.
5. Override the following methods on the form data source that contains the foreign key to the DimensionAttributeSet table.
public int active() { int ret; ret = super(); dimDefaultingController.activated(); return ret; } public void write() { dimDefaultingController.writing(); super(); } public void delete() { dimDefaultingController.deleted(); super(); }
Control options
Several overloads of the constructor will build the Dimension Attribute Set control with different characteristics: DimensionDefaultingController::constructInGroupWithChecks : Constructs an instance of the DimensionDefaultingController class that has a check box control associated with each dimension attribute that is added to the specified FormGroupControl object. DimensionDefaultingController::constructInGroupWithChecksAndValues : Constructs an instance of the DimensionDefaultingController class with a check box and a StringEdit control associated with each dimension attribute that is added to the specified FormGroupControl object. DimensionDefaultingController::constructInGroupWithCombosAndValues : Constructs an instance of the DimensionDefaultingController class with a combo box and a StringEdit control associated with each dimension attribute that is added to the specified FormGroupControl object. DimensionDefaultingController::constructInTabWithChecks: Constructs an instance of the DimensionDefaultingController class with a check box control associated with each dimension attribute that is added to the specified FormTabPageControl object. DimensionDefaultingController::constructInTabWithChecksAndValues : Constructs an instance of the DimensionDefaultingController class with a check box and a StringEdit control associated with each dimension attribute that is added to the specified FormTabPageControl object.
DimensionDefaultingController::constructInTabWithCombos : Constructs an instance of the DimensionDefaultingController class with a combo box control associated with each dimension attribute that is added to the specified FormTabPageControl object. DimensionDefaultingController::constructInTabWithCombosAndValues : Constructs an instance of the DimensionDefaultingController class with a combo box and a StringEdit control associated with each dimension attribute that is added to the specified FormTabPageControl object.
5. The view must have a SingularLabel assigned that is different from its Label property. 6. The view must have the same ConfigKey as the backing table.
7. The view must be included in the DimensionEssentials Security Privilege. Because the list of dimensionable entities are cached on both the client and server, the creation of a new dimensionable entity will not appear in the list of existing entities until a call to clear the caches is performed, or until both the client and the server are restarted. In order to clear the caches and have the new backing entity appear immediately, you must execute the following line of code within a job:
DimensionCache::clearAllScopes();
If a new Organization Model OMOperatingUnitType enumeration is added, the steps to make it dimensionable are similar but can be made shorter as follows: 1. Copy one of the existing DimAttributeOM[entityname] views, rename it appropriately and adjust all associated labels and help text. 2. Expand the Datasource\BackingEntity (OMOperatingUnit)\Ranges node on the copied view and change the value property on the range to the new OMOperatingUnitType enumeration value that was just added. Because the OMOperatingUnitType is backed by the OMOperatingUnit table, generic code already exists to handle the delete, update and renamePrimaryKey methods. Therefore, in this case, you do not need to update these methods.
DimensionStorage::getDefaultAccount: Gets the default account that represents the specified main account RecId. DimensionStorage::getDefaultAccountForMainAccountNum: Gets the default account that represents the specified main account number. DimensionStorage::getLedgerDefaultAccountFromLedgerDim: Gets the default account that represents the main account from the specified ledger dimension.
DimensionStorage::getMainAccountFromLedgerDimension: Gets the main account table buffer that corresponds to the specified ledger dimension. DimensionStorage::getMainAccountIdFromLedgerDimension: Gets the RecId of the main account that corresponds to the specified ledger dimension. DimensionStorage::getMainAccountNumFromLedgerDimension: Gets the account number of the main account that corresponds to the specified ledger dimension.
DimensionDefaultingEngine::getLedgerDimensionFromAccountAndDim: Gets the ledger dimension that represents the combination for the specified main account and default dimension. DimensionDefaultingService::serviceApplyFixedDimensions: Gets the ledger dimension that represents the combination formed by applying any fixed dimensions specified on the main account on the specified ledger dimension. DimensionDefaultingService::serviceCreateLedgerDimension: Gets the ledger dimension that represents the combination for the specified ledger dimension and default dimensions. DimensionDefaultingService::serviceMergeLedgerDimensions: Gets the ledger dimension that represents the combination formed by merging the specified ledger dimensions together. DimensionStorage::getAccountStructureFromLedgerDimension: Gets the RecId of the account structure for the specified ledger dimension.
DimensionStorage::getDynamicAccount: Gets the ledger dimension that represents the dynamic account for the specified account and account type. DimensionStorage::ledgerDimension2AccountNum: Gets the string value of the account for the specified dynamic account.
DimensionDefaultingEngine::overrideDefaultDimension: Updates a default dimension with the specified dimension values. DimensionDefaultingService::serviceMergeDefaultDimensions: Merges the specified default dimensions into a single default dimension. DimensionDefaultingService::serviceReplaceAttributeValue: Replaces the value of the specified dimension attribute in the target default dimension with the value from the source default dimension. DimensionStorage::getDefaultDimensionFromLedgerDimension: Gets the default dimension that represents all dimension values from the specified ledger account other than the main account. DimensionAttributeValueSetStorage: This class provides an API for creating and editing default dimensions.
DimensionAttributeSetStorage: This class manages the storage of the <c>DimensionAttributeSet</c> table and the <c>DimensionAttributeSetItem</c> table.
Web services
Web service classes are provided to more easily integrate with the major subsystems of the account/dimension framework. The classes use only natural key information instead of surrogate key record IDs . This section describes the service APIs.
DimensionService class
The DimensionService class provides standard primitive operations for retrieving a list of all financial dimensions available or for a specific account structure.
getDimensions method
Returns an X++ list type that contains elements of class type DimensionContract for all dimensions associated with the specified account structure. The AccountStructureContract class is used to specify the name of the account structure to retrieve the list of dimensions for. Example [X++]
accountStructureContract = new AccountStructureContract(); accountStructureContract.parmName('Expense'); dimensionService = new DimensionService(); dimensionList = dimensionService.getDimensions(accountStructureContract); dimIterator = new ListIterator(dimensionList); dimensionContract = dimIterator.value(); name = dimensionContract.parmDimensionName(); dimIterator.next();
[C#]
AccountStructureContract accountStructureContract = new AccountStructureContract { parmName = accountStructureName }; DimensionServiceClient proxy = new DimensionServiceClient(); try { DimensionContract[] dimensionList = proxy.getDimensions(null, accountStructureContract); } finally { proxy.Close(); }
getDimensionsAll method
Returns an X++ list type that contains elements of class type DimensionContract for all dimensions in the system. Example
[X++] dimensionService = new DimensionService(); dimensionList = dimensionService.getDimensionsAll(); dimIterator = new ListIterator(dimensionList); dimensionContract = dimIterator.value(); name = dimensionContract.parmDimensionName(); dimIterator.next(); [C#] DimensionServiceClient proxy = new DimensionServiceClient(); try { DimensionContract[] dimensionList = proxy.getDimensionsAll(null); } finally { proxy.Close(); }
ChartOfAccountsService class
The ChartOfAccountsService class provides standard primitive operations for retrieving a list of all ledgers, ledger chart of accounts, main accounts for a specific ledger chart of accounts or creation of main accounts.
createMainAccount method
Creates a new main account. The class MainAccountContract is used to specify the name and other fields that describe the main account. Example [X++]
service = new ChartOfAccountsService(); mainAccountContract = new MainAccountContract(); mainAccountContract.parmMainAccountId('999'); mainAccountContract.parmName('Service Test Account'); mainAccountContract.parmLedgerChartOfAccounts(curext()); result = service.createMainAccount(mainAccountContract);
[C#]
MainAccountContract mainAccountContract = new MainAccountContract(); mainAccountContract.parmMainAccountId = "99999";
mainAccountContract.parmName = "Test Main Account"; mainAccountContract.parmLedgerChartOfAccounts = this.CompanyName; ChartOfAccountsServiceClient proxy = new ChartOfAccountsServiceClient(); try { bool created = proxy.createMainAccount(null, mainAccountContract); } finally { proxy.Close(); }
getLedgerChartOfAccounts method
Returns an X++ list type that contains elements of class type LedgerChartOfAccountsContract for all ledger charts of accounts in the system. Example
[X++] service = new ChartOfAccountsService(); list = service.getLedgerChartOfAccounts(); enumerator = list.getEnumerator(); while (enumerator.moveNext()) { ledgerCOAcontract = enumerator.current(); name = ledgerCOAcontract.parmName(); } [C#] ChartOfAccountsServiceClient proxy = new ChartOfAccountsServiceClient(); try { LedgerChartOfAccountContract[] ledgerChartOfAccounts = proxy.getLedgerChartOfAccounts(null); this.VerifyLedgerChartOfAccounts(ledgerChartOfAccounts); } finally { proxy.Close(); }
getLedgers method
Returns an X++ list type that contains elements of class type MainAccountContract for all main accounts for a specific ledger chart of accounts. The class LedgerChartOfAccountContract is used to specify the name of the ledger chart of account to retrieve the list of main accounts for. Example
[X++] service = new ChartOfAccountsService(); ledgerCOAContract = new LedgerChartOfAccountContract(); ledgerCOAContract.parmName(curext()); list = service.getMainAcounts(ledgerCOAContract); enumerator = list.getEnumerator(); while (enumerator.moveNext()) { mainAccountContract = enumerator.current(); mainAccountId = mainAccountContract.parmMainAccountId(); } [C#] ChartOfAccountsServiceClient proxy = new ChartOfAccountsServiceClient(); try { LedgerContract[] ledgers = proxy.getLedgers(null); } finally { proxy.Close(); }
DimensionValueService class
The DimensionValueService class provides standard primitive operations for creating a userdefined dimension value for a specific financial dimension and retrieving a list of all values for a specific financial dimension.
createDimensionValue method
Creates a new user-defined financial dimension value for the specified financial dimension. The class DimensionValueContract is used to specify the dimension attribute and value as well as additional properties of the value. Example
[X++] service = new DimensionValueService(); dimensionValueContract = new DimensionValueContract();
[C#] DimensionValueContract dimensionValueContract = new DimensionValueContract { parmDimensionAttribute = dimensionAttributeName, parmValue = "Fund_09", parmDescription = "Fund 09", parmActiveFrom = DateTime.Today, parmActiveTo = DateTime.Today, parmIsSuspended = Reference.NoYes.Yes, parmIsBlockedForManualEntry = Reference.NoYes.Yes, parmBackingEntityType = 656, parmGroupDimension = string.Empty, parmPersonnelNumber = "AMO" }; DimensionValueServiceClient proxy = new DimensionValueServiceClient(); try { bool isSuccessful = proxy.createDimensionValue(null, dimensionValueContract); } finally { proxy.Close(); }
getDimensionsValues method
Returns an X++ list type that contains elements of class type DimensionValueContract for all values for a specified financial dimension. The class DimensionContract is used to specify the dimension name. Example
[X++] service = new DimensionValueService(); dimensionContract = new DimensionContract();
dimensionContract.parmDimensionName('Department'); dimensionValueContractList = service.getDimensionValues(dimensionContract); contractIterator = new ListIterator(dimensionValueContractList); dimensionValueContract = contractIterator.value(); dimensionValue = dimensionValueContract.parmValue(); contractIterator.next();
[C#] DimensionContract dimensionContract = new DimensionContract { parmDimensionName = dimensionAttributeName }; DimensionValueServiceClient proxy = new DimensionValueServiceClient(); try { DimensionValueContract[] dimensionValueList = proxy.getDimensionValues(null, dimensionContract); } finally { proxy.Close(); }
FinancialDimensionValidationService class
The FinancialDimensionValidationService class provides standard primitive operations for validating a budget or ledger account.
validateBudgetAccount method
Validates that the combination specified in the class BudgetAccountContract is valid per the current structure, constraints and budget-enabled dimensions Example
[X++] service = new FinancialDimensionValidationService(); budgetAccountValidationContract = new BudgetAccountValidationContract(); budgetAccountContract = new BudgetAccountContract(); dimensionAttributeValueContract = new DimensionAttributeValueContract(); budgetAccountContract.parmAccountStructure('Expense'); budgetAccountContract.parmValues(new List(Types::Class)); dimensionAttributeValueContract.parmName('Department'); dimensionAttributeValueContract.parmValue('10'); budgetAccountContract.parmValues().addEnd(dimensionAttributeValueContract); budgetAccountValidationContract.parmBudgetAccountContract(budgetAccountContract); isValid = service.validateBudgetAccount(budgetAccountValidationContract);
validateLedgerAccount method
Validates that the combination specified in the class LedgerAccountContract is valid per the current structure, constraints, advanced rules and organization model relationships. Example
[X++] service = new FinancialDimensionValidationService(); ledgerAccountValidationContract = new LedgerAccountValidationContract(); ledgerAccountContract = new LedgerAccountContract(); dimensionAttributeValueContract = new DimensionAttributeValueContract();
FinancialDimensionBalanceService class
The FinancialDimensionBalanceService class provides standard primitive operations for retreiving the balance for a specific dimension set.
getBalance method
Returns the balance in the class DimensionSetBalanceContract for the specified dimension set. The class DimensionSetContract is used to specify the dimension attribute and value as well as additional properties of the value. Example
[X++] service = new FinancialDimensionBalanceService(); attributeValueContractMA = new DimensionAttributeValueContract(); contract = new DimensionSetContract(); contract.parmIncludeOperatingFiscalPeriod(true); contract.parmPostingLayer(OperationsTax::Current); contract.parmCombination(new DimensionSetCombinationContract()); contract.parmCombination().parmDimensionSetName('Main Account Focus'); contract.parmCombination().parmValues(new List(Types::Class)); attributeValueContractMA.parmName('MainAccount'); attributeValueContractMA.parmValue('10025'); contract.parmCombination().parmValues().addEnd(attributeValueContractMA); resultContract = service.getBalance(contract); amount = resultContract.parmAccountCurrencyAmount();
Data upgrade
This section provides information that you should know before you attempt to upgrade account and dimension data in Microsoft Dynamics AX 2012. Included is information about the new fields or values, the methods used to convert to them, the APIs where these methods are found, and examples of how to use them. Important: You must use the official APIs for data creation or imports that use hash values. This includes data creation for the DimensionAttributeValueCombination, DimensionAttributeValueGroup, DimensionAttributeSet, DimensionAttributeValueSet and related child tables. The hash generation process is protected framework functionality and may be subject to change. Therefore, all creation of combination and dimension set data must flow through the provided APIs, which go through DimensionStorage, DimensionAttributeSetStorage or DimensionAttributeValueSetStorageTest.
Warning: Direct import or modification of data in these tables and/or altering hash values and linked records WILL result in corruption of the account/dimension combination data and be very difficult to trace and fix.
Conversion patterns
The following patterns demonstrate how to convert the legacy account and financial dimension data to the new Microsoft Dynamics AX 2012 values. The patterns described in this section are the same patterns defined earlier in the Revising your data patterns section.
Example
CustPaymModeTable DimensionAttributeSetStorage HashKey RecId SysDictEnum DimensionAttribute str int int custPaymModeTable; dimensionAttributeSetStorage; dimAttrHashKeys[]; dimAttrIds[]; sysDictEnum = new SysDictEnum(enumNum(SysDimension)); attribute; name; i; dimSize;
// Get the size of the dimension. dimSize = sysDictEnum.values(); // Retrieve the attribute ids for the dimension. for (i = 1; i<=dimSize; i++) { name = sysDictEnum.index2Symbol(i-1); attribute = DimensionAttribute::findByName(name); dimAttrIds[i] = attribute.RecId; dimAttrHashKeys[i] = attribute.HashKey; } // Updating the table. while select forupdate custPaymModeTable { dimensionAttributeSetStorage = new DimensionAttributeSetStorage(enumnum(NoYes)); for (i = 1; i<=dimSize; i++) { dimensionAttributeSetStorage.addItem(dimAttrIds[i], dimAttrHashKeys[i], custPaymModeTable.DimUse[i]); } custPaymModeTable.DimensionAttributeSet = dimensionAttributeSetStorage.save(); custPaymModeTable.doUpdate(); }
Example
if (ledgerJournalTrans.AccountType == LedgerJournalACType::Ledger) { shadow_LedgerJournalTrans.LedgerDimension = DimensionConversionHelper::getNativeLedgerDimension(ledgerJournalTrans.AccountNum, ledgerJournalTrans.Dimension); } else { shadow_LedgerJournalTrans.DefaultDimension = DimensionConversionHelper::getNativeDefaultDimension(ledgerJournalTrans.Dimension); shadow_LedgerJournalTrans.LedgerDimension = DimensionConversionHelper::getNativeNonLedgerAccount(ledgerJournalTrans.AccountNum, ledgerJournalTrans.AccountType); }
Environments
You can upgrade data in either the source environment (Microsoft Dynamics AX 4.0 or Microsoft Dynamics AX 2009) or the target environment (Microsoft Dynamics AX 2012). The DimensionConversionHelper API is provided for use in both environments.
DimensionConversionHelper API
The DimensionConversionHelper class is provided in both the source and target environments. All patterns described in the Conversion patterns section earlier in this white paper use the DimensionConversionHelper class, with the exception of the main account and dimension attribute set conversion patterns. The implementation in each environment is the same; you will see no difference in the conversion, regardless of the environment you work in. The following methods are available for use in the DimensionConversionHelper class: getNativeDefaultAccount getNativeDefaultDimension getNativeLedgerDimension getNativeNonLedgerAccount ledgerAccountType2DimLedgerAccountType
These methods work as follows: public static RecId getNativeDefaultAccount(LedgerAccount _ledgerAccount) Passes in a LedgerAccount value; a RecId is returned. Sets the LedgerDimension field with the RecId. public static RecId getNativeDefaultDimension(Dimension _dimension) Passes in a Dimension value; a RecId is returned. Sets the DefaultDimension field with the RecId. public static RecId getNativeLedgerDimension(LedgerAccount _ledgerAccount, Dimension _dimension, RecId _hierarchyId = DimensionConversionHelper::getAccountStructureHierarchyId()) Passes in a LedgerAccount and a Dimension value; a RecId is returned. Sets the LedgerDimension field with the RecId. public static RecId getNativeNonLedgerAccount(LedgerJournalAC _account, int _accountType, enumId _enumType = enumnum(LedgerJournalACType), ModuleInventCustVend _custVend = ModuleInventCustVend::Cust) Passes in the account and account type values; a RecId is returned. Sets the LedgerDimension field with the RecId. public static DimensionLedgerAccountType ledgerAccountType2DimLedgerAccountType(LedgerAccountType _ledgerAccountType) Passes in the LedgerAccountType value; a DimensionLedgerAccountType value is returned.
Set-based upgrade
Although not designed with set-based operations in mind, modifications have been made to the DimensionAttributeValueCombination table to assist in set-based operations when you are working with an extremely large table. The DEL_AccountNum and DEL_Dimension fields have been added to the DimensionAttributeValueCombination table and will be populated as combinations during the upgrade. These fields have been created to give you old table fields to join to, which enables you to map your new data to the old data, if it exists. Combinations still need to be processed individually because it is not feasible to implement the hashing algorithm used in the creation of the combination in a set-based manner.
After the combinations have been created, you need to perform a join to the DimensionAttributeValueCombination table and the table that you want to populate.
Change
Updated to address Microsoft Dynamics AX 2012 R2, and updated some earlier content for accuracy: Added more information about how to make an entity dimensionable. Corrected some misinformation regarding default accounts (structures were not associated with them). Updated the description of MainAccountList for Microsoft Dynamics AX 2012 R2. Sharing of structures now occurs at the Ledger not Chart of Accounts level. Described the DimensionDefaultingService call for fixed dimensions functionality.
August 2011
Initial publication
Appendix
DimensionAttributeValueCombination RecId AccountStructure (O) DisplayValue Hash (AK1) LedgerDimensionType MainAccount (O) RecId RefRecId DimensionDisplayValue varbinary(20) LedgerDimensionType RefRecId
MainAccount LedgerChartOfAccounts RecId Description (O) MainAccountFormatMask (O) Name (AK1) RecId Description DimensionValueMask Name RecId AccountCategoryRef (O) (FK) AdjustmentMethod_MX Closing ConsolidationMainAccount (O) CurrencyCode (O) DebitCreditBalanceDemand DebitCreditCheck DebitCreditProposal ExchangeAdjusted InflationAdjustment_MX LedgerChartOfAccounts (FK,AK1) MainAccountId (AK1) MainAccountTemplate (O) (FK) MandatoryPaymentReference Monetary Name (O) OffsetLedgerDimension (O) (FK) OpeningAccount (O) (FK) PostingType RepomoType_MX ReportingAccountType SRUCode (O) TransferYearEndAccount_ES (O) Type UnitOfMeasure UserInfoId (O) (FK) ValidateCurrency ValidatePosting ValidateUser RecId AccountCategoryRef AdjustmentMethod_MX LedgerClosing RefRecId CurrencyCode DebCredBalanceDemand DebCredProposal DebCredProposal NoYes NoYes RefRecId MainAccountNum RefRecId NoYes LedgerMonetary AccountName RefRecId RefRecId LedgerPostingType RepomoType_MX DimensionLedgerAccountReportingType LedgerSRUCode RefRecId LedgerDimensionAccountType UnitOfMeasureRecId UserId FieldControl FieldControl FieldControl
MainAccountLegalEntity RecId AutoAllocate DefaultDimension (O) (FK) LegalEntity (FK,AK1) MainAccount (FK,AK1) TaxCode (O) TaxDirection TaxFree TaxGroup (O) TaxItemGroup (O) TaxItemGroupHeadingDataAreaId (O) TaxTableDataAreaId (O) ValidateTaxCode MainAccountControlTaxCode RecId DataAreaId (FK,FK,AK1) MainAccount (FK,AK1) TaxCode (FK,AK1) RecId SelectableDataAreaId RefRecId TaxCode RecId NoYes DimensionDefault RefRecId RefRecId TaxCode SalesPurch NoYes TaxGroup TaxItemGroup DataAreaId DataAreaId FieldControl
MainAccountControlCurrencyCode RecId CurrencyCode (AK1) MainAccount (FK,AK1) RecId CurrencyCode RefRecId MainAccountControlUser RecId UserId (FK,AK1) MainAccount (FK,AK1) RecId UserId RefRecId
DimensionAttributeValueCombination RecId AccountStructure (O) DisplayValue Hash (AK1) LedgerDimensionType MainAccount (O) RecId RefRecId DimensionDisplayValue varbinary(20) LedgerDimensionType RefRecId
DimensionAttributeValueGroupCombination RecId RecId DimensionHierarchy RecId DeletedVersion (AK1) Description (O) DraftDescription (O) DraftName (O) FocusIsAutomaticUpdate FocusState HashKey (AK2) IsDraft (AK1) IsSystemGenerated (AK1) Name (AK1) StructureType (AK1) DimensionAttributeValue RecId ActiveFrom ActiveTo DimensionAttribute (FK,AK1) EntityInstance (AK1) GroupDimension (O) HashKey (AK2) IsBlockedForManualEntry IsDeleted (AK1) IsSuspended IsTotal Owner (O) (FK,IE1) RecId DimensionActiveFrom DimensionActiveTo RefRecId RefRecId GroupDimension HashKey NoYes NoYes NoYes NoYes RefRecId RecId SequenceNum Description Description Name NoYes smallint HashKey NoYes NoYes Name DimensionHierarchyType
DimensionAttributeValueGroup RecId DimensionHierarchy (FK) Hash (AK1) Levels RecId RefRecId varbinary(20) Level
DimensionAttributeLevelValue RecId DimensionAttributeValue (FK,AK1) DimensionAttributeValueGroup (FK,AK1) DisplayValue Ordinal RecId RefRecId RefRecId DimensionDisplayValue DimensionOrdinal
Combination Storage
45
IMPLEMENTING THE ACCOUNT AND FINANCIAL DIMENSIONS FRAMEWORK FOR MICROSOFT DYNAMICS AX 2012 APPLICATIONS
DimensionAttributeSet RecId BaseEnumType (AK1) Hash (AK1) RecId int varbinary(20) DimensionAttribute RecId BackingEntityKeyFieldId BackingEntityKeyFieldName BackingEntityTableId BackingEntityTableName BackingEntityType BackingEntityValueFieldId BackingEntityValueFieldName HashKey (AK2) KeyAttribute Name (AK1) NameAttribute ReportColumnName (O) ValueAttribute ViewName RecId FieldId FieldStr TableId TableStr TableId FieldId FieldStr HashKey FieldId Name FieldId DimensionAttributeReportColumnName FieldId TableStr
DimensionAttributeSetItem RecId DimensionAttribute (FK,AK1) DimensionAttributeSet (FK,AK1) EnumerationValue RecId RefRecId RefRecId int
46
IMPLEMENTING THE ACCOUNT AND FINANCIAL DIMENSIONS FRAMEWORK FOR MICROSOFT DYNAMICS AX 2012 APPLICATIONS
DimensionAttributeValue RecId DimensionAttributeValueSetItem RecId DimensionAttributeValue (FK,FK,AK1) DimensionAttributeValueSet (FK,AK1) DisplayValue RecId RefRecId RefRecId DimensionValue ActiveFrom ActiveTo DimensionAttribute (FK,AK1) EntityInstance (AK1) GroupDimension (O) HashKey (AK2) IsBlockedForManualEntry IsDeleted (AK1) IsSuspended IsTotal Owner (O) (FK,IE1) RecId DimensionActiveFrom DimensionActiveTo RefRecId RefRecId GroupDimension HashKey NoYes NoYes NoYes NoYes RefRecId
47
IMPLEMENTING THE ACCOUNT AND FINANCIAL DIMENSIONS FRAMEWORK FOR MICROSOFT DYNAMICS AX 2012 APPLICATIONS
Microsoft Dynamics is a line of integrated, adaptable business management solutions that enables you and your people to make business decisions with greater confidence. Microsoft Dynamics works like and with familiar Microsoft software, automating and streamlining financial, customer relationship and supply chain processes in a way that helps you drive business success. U.S. and Canada Toll Free 1-888-477-7989 Worldwide +1-701-281-6500 www.microsoft.com/dynamics
This document is provided as-is. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. You may modify this document for your internal, reference purposes. 2013 Microsoft Corporation. All rights reserved. Microsoft, Microsoft Dynamics, and the Microsoft Dynamics logo are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.
48
IMPLEMENTING THE ACCOUNT AND FINANCIAL DIMENSIONS FRAMEWORK FOR MICROSOFT DYNAMICS AX 2012 APPLICATIONS