Ax2012 Enus Deviv 04 PDF

Chapter 4: Use and Design of the Ledger Module
CHAPTER 4: USE AND DESIGN OF THE LEDGER MODULE

Objectives
The objectives are: Describe currencies, exchange rates, fiscal calendars, and periods. Describe the components that comprise the chart of accounts. Review the steps for adding financial dimension controls to a form. Create a new system-defined dimension. Describe how journals and transactions are used to update the general ledger. Describe how the Budgeting module is used. Review the data model and key classes used for budgeting and budget checking. Describe how the Fixed assets module is used. Review the data model for fixed assets.
Introduction
The following section describes a series of tasks that show the functionality used in the General ledger, Budgeting, and Fixed assets modules. Participants will be given the opportunity to understand the purpose of these modules from a users viewpoint. Additionally, several of the key data and object models related to these modules will be reviewed.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
4-1
Development IV in Microsoft Dynamics AX 2012
General Ledger Overview

The general ledger is used to define and manage a legal entitys financial records. It is a formal ledger that contains a companys accounting records, and is a register of debit and credit entries. These entries are classified by using the accounts that are listed in a chart of accounts. You can allocate, or distribute, monetary amounts to one or more accounts or account and dimension combinations based on allocation rules. There are two types of allocationsfixed and variable. You can also settle transactions between ledger accounts and revalue currency amounts. At the end of a fiscal year, you must generate closing transactions and prepare your accounts for the next fiscal year. You can use the consolidation functionality to combine the financial results for several subsidiary legal entities into results for a single, consolidated organization. The subsidiaries can be in the same Microsoft Dynamics AX database or in separate databases. You can use the tools for forecasting cash flow and currency requirements to estimate your legal entitys future cash needs. You can then calculate, view, and print forecasts of the cash flow. You can also calculate and display currency requirements. To make the general ledger functional in Microsoft Dynamics AX 2012, you must set up the chart of accounts, fiscal calendars, legal entities, and currencies. The chart of accounts is a list of main accounts and financial dimensions that are allowed by one or more account structures. Fiscal calendars specify what time period financial data is posted, while currency setup determines which currencies are available for business transactions.
Currency and Exchange Rate Setup

Currency setup is a mandatory step in Microsoft Dynamics AX and is used to record financial transactions. Multi-currency functionality can be used if your company does business in more than one currency. If your organization has multiple legal entities and transacts in multiple currencies, then maintaining currencies and their corresponding exchange rate is essential. In Microsoft Dynamics AX, all currencies are provided by default. The currencies are loaded the first time a user opens the General ledger parameters form.
4-2

To view currencies open General ledger > Setup > Currency > Currencies.
FIGURE 4.1 CURRENCIES FORM
Accounting and Reporting Currencies

Microsoft Dynamics AX uses the concept of Accounting currency and Reporting currency. Accounting Currency: The customary monetary unit of measure used to record the converted monetary value of economic transactions in ledger accounts. The previous releases of Microsoft Dynamics AX called this the company currency. Reporting Currency: The monetary unit of measure used to record the converted monetary value of economic transactions in ledger accounts for financial and management reporting purposes.
An example of this would be if you had a subsidiary company in Canada, and your primary company is in the United States. When running reports you want to see the results of the business operations in Canadian dollars (CAD). To accomplish this, you must convert your U.S. dollars (USD) to CAD; the system uses the exchange rate defined on the Exchange rates form to convert the amounts for reporting purposes. Revaluation of foreign currency balances is a periodic task in the General ledger module. If the account in question is controlled by another module, such as the Customers or Vendors, then exchange rate adjustments should be performed in the Accounts receivable or Accounts payable module instead of the General ledger module.
4-3

Currency Calculation
Four pieces of information are necessary to perform a currency calculation in Microsoft Dynamics AX 2012. From currency To currency Date Exchange rate type
When performing a calculation in the context of a given legal entity, the exchange rate type and one of the currencies can be derived from the ledger that is associated with that legal entity. For example, assume that an accounting currency of USD and an exchange rate type of SELL are set up for a given ledger. When that ledger is passed to the calculation engine and the calculateTransactionToAccounting method is called, the calculation engine is able to automatically determine that the accounting currency is USD and the exchange rate type is SELL. In most cases, calculations will be performed in the context of a given ledger. When performing a calculation outside of the context of a ledger, it is still possible to provide all of the necessary information by using the methods that are prefixed with parm on the calculation engine.
CurrencyExchangeHelper Class
The CurrencyExchangeHelper class is introduced in Microsoft Dynamics AX 2012. It is the recommended Application Programming Interface (API) to perform calculations between currencies. The following examples illustrate its usage for the most common scenarios. This example calculates the amount in the context of the current ledger. This is indicated by passing Ledger::current() to the constructor method of the CurrencyExchangeHelper class.
CurrencyExchangeHelper currencyExchangeHelper; TransDate transactionDate; CurrencyCode transactionCurrency = 'CAD'; AmountCur amountToConvert = 100.50; boolean shouldRoundResult = true; AmountMst result; currencyExchangeHelper = CurrencyExchangeHelper::newExchangeDate( Ledger::current(), transactionDate); result = currencyExchangeHelper.calculateTransactionToAccounting(
4-4

transactionCurrency, amountToConvert, shouldRoundResult); info(strrfmt("%1",result));
NOTE: Additional code samples for calculating the transaction currency from the accounting currency, and calculating the amounts by using an exchange rate that is entered are available in the Shared Currencies and Exchange Rates (http://go.microsoft.com/fwlink/?LinkId=238176)white paper.
ExchangeRateHelper Class
The same information used to perform currency calculations is used to work with exchange rates. From currency To currency Date Exchange rate type
Retrieving exchange rates

Two exchange rates (ExchangeRate1 and ExchangeRate2) must always be considered when retrieving or using exchange rates in the application. This is because the calculation for the currency amount will include triangulation if any currency involved in the calculation is set up as the triangulation currency or is a denomination currency. This results in scenarios where a currency calculation requires two exchange rates. Under normal circumstances, amounts could be converted directly from Great British Pounds (GBP) to United States Dollars (USD), which would require only one exchange rate. 1. GBP > USD 2. ExchangeRate1 would be non-zero 3. ExchangeRate2 would be zero Assuming that GBP is a denomination of the euro (EUR) currency which is set up as the triangulation currency, amounts would require two exchange rates (triangulation) to calculate GBP to USD. 1. GBP > EUR > USD 2. ExchangeRate1 would be non-zero 3. ExchangeRate2 would be non-zero
4-5

There are nine possible triangulation scenarios, three of which require two exchange rates. As a result, all code must assume that two exchange rates are possible and must always take this into account when storing them or passing them to the calculation engine. If a subsystem uses one exchange rate, most likely it is incorrect unless that rate is a true cross rate that factors in both exchange rates. (Note that the getCrossRate and getCrossRateReciprocal methods on the ExchangeRateHelper class do factor in triangulation.) Another important concept to understand is that the rates are always stored in terms of the transaction (or reporting) currency to the accounting currency. Therefore, when calling the exchange rate engine, make sure to set the from and to currency accordingly. This is illustrated in the following example.
ExchangeRateHelper exchangeRateHelper; TransDate transactionDate; CurrencyCode transactionCurrency = 'CAD'; CurrencyExchangeRate exchangeRate1; CurrencyExchangeRate exchangeRate2; exchangeRateHelper = ExchangeRateHelper::newExchangeDate( Ledger::current(), transactionCurrency, transactionDate); exchangeRate1 = exchangeRateHelper.getExchangeRate1(); exchangeRate2 = exchangeRateHelper.getExchangeRate2(); info (strfmt("ExchRate1= %1; ExchRate2= %2, exchangeRate1, exchangeRate2));
4-6

Currency and Exchange Rate Data Model
The following figure shows the data model for the currency, exchange rate, and ledger data model.
FIGURE 4.2 CURRENCY AND EXCHANGE RATE DATA MODEL
Periods and Fiscal Year Setup

The fiscal year in Microsoft Dynamics AX can be set to any length, divided into any number of periods and may be shared across multiple legal entities. Both fiscal year and periods can be set up by the following measurements of timeyears, months and/or days. Each period (at the ledger level) can be closed completely or put on hold to block transaction postings, or set to enable selected users to continue an update of one or more modules. To do this, open General ledger > Setup > Ledger, and then click the Ledger calendar button. The periods and fiscal year feature is useful for the preparation and reconciliation of periodic and yearly accounts.
4-7

Fiscal calendars are shared across multiple legal entities. The benefits of sharing fiscal calendars include the following. Will support multiple fiscal calendars for each legal entity. For example, fixed assets could require two calendarsone for auditing purposes and one for tax purposes. If you have multiple calendars you can run parallel depreciations. Reduces the amount of setup required for each legal entity because it is possible to use the same fiscal calendar for multiple legal entities. Before posting transactions, a new fiscal year must be divided into periods since transactions cannot post unless a period is created for the posting date.
Chart of Accounts
A chart of accounts is a set of main accounts tracked by Microsoft Dynamics AX. It captures financial information that is used to make sound financial decisions. Each account is assigned an account number as a unique identifier. Each chart of accounts contains the account structures used by the chart of accounts to define the segments and the valid combinations of main accounts and financial dimension values. The chart of accounts is shared and it is also a list of main accounts and structures, used to define a chart of accounts in use by one or more ledgers.
Multiple Chart of Accounts

Many large organizations use the same chart of accounts across multiple companies. You can define company specific data, such as the default sales code on the main account, and inactivate financial dimension values for a specific company. The following entities/objects will have company specific data. Main account Dimension values
The following elements comprise the shared chart of accounts. Chart of accounts Main accounts Account structures Advanced rules Financial dimensions Financial dimension values
4-8

Financial Dimensions
Characteristics of financial dimensions include the following. Provide a more detailed description of a transaction. Simplify the accounting process when you enable detailed analysis without the creation of a detailed chart of accounts. Defined to analyze and classify financial transactions as follows. o o Financial transactions usually are organized according to voucher and account number. Additional grouping and classification options are available when you assign several dimensions to transactions.
View the data file from different perspectives to improve the effectiveness in tracking figures across accounts. Can be used throughout the system, and add dimensions to base data such as: o o o Ledger accounts Customers Vendors
Can be copied to transactions automatically.
You can use the Financial dimensions form to create financial dimensions that you can use as account segments for shared charts of accounts. Open General ledger > Setup > Financial dimensions > Financial dimensions. There are two basic types of financial dimensions. System-defined: Select a system-defined entity to base the financial dimension on. Financial dimension values will be created from this selection. For example, to create dimension values for projects, select Projects. A dimension value will be created for each project name. User-defined: To create a user-defined financial dimension, select < Custom dimension >.
Financial Dimension Values

After you have created the financial dimensions, use the Financial dimension values form to assign additional properties to each financial dimension. When you define a dimension that is based on a system-defined entity, you cannot add values in the Financial dimension values form. However, you can view the values. To add new values, you must access the main form for system entity. For example, for the Customer entity you must add a customer in the Customer form.
4-9

Financial Dimension Templates
Dimension templates can be used for common patterns to distribute source document amounts. Use the Financial dimension default templates form to create a template of percentage and financial dimension value combinations. The information in the template will be used to display default financial dimension values when you distribute source document amounts.
Financial Dimension Sets

Financial dimension sets have several purposes. Financial dimension sets are used to determine how reports and inquiries related to the general ledger are rendered. They are also used to calculate balances during the posting process. Balances can also be scheduled for calculation or manually updated. Balances are stored based on the financial dimension set and are calculated based on the option to calculate with posting or batch schedule. Financial dimension sets also drive the data displayed in the Trial balance list page. The order in which financial dimension sets are considered in reporting effect how transactions are sorted and fields are presented. For example, the set Department and Cost center indicates that the Department dimension type is first and Cost center second. Therefore, the considered financial set is the composite of Department and Cost center. Department amounts are presented first and Cost center amounts are presented second. The defined financial dimension set can be used alone or in pairs when inquiring or reporting on financial transactions. The selection of a primary and secondary financial dimension set is considered when presenting the results. The secondary financial dimension set details the figures of the primary dimension set. The selection of a secondary financial dimension set is limited to dimension types that do not share a dimension type with a primary dimension set. Therefore, if the primary dimension set is the composite of Main account and Department, these cannot be selected in the secondary financial dimension set.
Account Structures
You can use the Configure account structures form to create one or more account structures. Open General ledger > Setup > Chart of accounts > Configure account structures. Accounts structures provide the segments and order of entry for the account number. Main account is a required segment for an account structure, but it does not have to be the first segment. The account structures are used to define the valid combinations which, together with the main accounts, form a chart of accounts. Multiple account structures allow a legal entity to track information for specific accounts without affecting information in other accounts. To change an existing account structure, and to enable some of the controls in this form, you must click Edit, so that the account structure has a Draft status.
4-10

Data Patterns
Default Account
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.
Main Account
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.
Ledger Account
A ledger account contains the main account, account structure, and the financial dimension values that are needed to populate the related account structure and account 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 (or LedgerDimension) table. Foreign key fields for ledger accounts are named LedgerDimension because that is the alias used for the DimensionAttributeValueCombination table.
Multi-type Account
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.
4-11

This pattern is primarily used for the setup and entry of financial journals. In this case, a multi-type 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.
4-12

The following figure shows the data model for the chart of accounts.
FIGURE 4.3 CHART OF ACCOUNTS DATA MODEL
Default Dimensions
The default dimension pattern represents a set of financial dimensions and their related values. A customer will set the values for given financial dimensions on master data records for defaulting purposes or directly on some transactions. In Microsoft Dynamics AX 2012, 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 value references the correct record in the
4-13

DimensionAttributeValueSet (or Default Dimension) table. The data model in previous releases limited storage to 10 financial dimensions, the new model allows you to store an unlimited number of financial dimensions and their values.
Dimension Set
The dimension attribute set pattern represents a set of financial dimensions and their related enumeration values. This pattern is used in advanced general ledger processing where different financial dimensions can be handled differently, based on these stored enumeration values. The dimension attribute set pattern is used to store a set of financial dimensions and related data, such as enumeration values. This pattern is used in places where it is necessary to store additional information about dimensions, such as whether they are optional or required. For an example of this implementation, refer to the VendPaymMode form under Forms in the Application Object Tree (AOT). A foreign key representing a dimension attribute set is a 64-bit integer field that contains the data from the corresponding RecId field of the DimensionAttributeSet table. The new model allows you to store an unlimited number of financial dimensions.
4-14

The following figure shows the data model for the financial dimensions.
FIGURE 4.4 FINANCIAL DIMENSIONS DATA MODEL
Procedure: Add a Default Dimension Control to a Form

The Default Account control is a combination of the Segmented Entry control and the LedgerDimensionDefaultAccountController class. The LedgerDimensionDefaultAccountController class handles the events raised by the Segmented Entry control.
4-15

Changes needed on the form
In simple scenarios, the changes needed on the form are as follows: TIP: You can create a new form, or you can use the VendPaymMode form in the Hyper-V training environment to implement these changes. 1. Verify that the table that will hold the foreign key to the DimensionAttributeValueCombination table as a data source on the form. 2. Drag the LedgerDimension field from the data source to the desired location on the form design. This should add a Segmented Entry control at this location on the form with appropriate DataSource and ReferenceField property values. Alternatively, you can complete this step by adding a Segmented Entry control to the design and manually setting the DataSource and ReferenceField properties. 3. Override the following methods on the form.
public class FormRun extends ObjectRun { //Declare the ledgerDimensionDefaultAccountController LedgerDimensionDefaultAccountController ledgerDimensionDefaultAccountController; } public void init() { super(); //Instantiate a new instance of the class ledgerDimensionDefaultAccountController = LedgerDimensionDefaultAccountController::construct(myTable_ ds, fieldstr(MyTable, LedgerDimension)); }
4. Overload the following methods on the Segmented Entry control instance in the form design.
public void jumpRef() { ledgerDimensionDefaultAccountController.jumpRef(); } public void loadAutoCompleteData(LoadAutoCompleteDataEventArgs _e) { ledgerDimensionDefaultAccountController.loadAutoCompleteDat a(_e); super(_e); }
4-16

public void segmentValueChanged(SegmentValueChangedEventArgs _e) { ledgerDimensionDefaultAccountController.segmentValueChanged (_e); super(_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. Overload 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 for a legal entity from which to derive the list of main accounts and structures. The default value is the chart of accounts in the current legal entity.
4-17

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 (LedgerPostingType) 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. parmIncludeFinancial and parmIncludeTotal: Specific main accounts can be excluded from the lookup and prevented from being entered manually. The IncludeStatistical and IncludeTotal parameters are used for validation and lookup to restrict valid values. The default value for each parameter is false.
NOTE: There is no special control for the main account pattern. This pattern uses a foreign key that has a standard pattern in Microsoft Dynamics AX 2012.
Procedure: Add a Ledger Account Control to a Form

When you need to add a Ledger account control to a form, use the same process that is used in the "Add a Default Dimension Control to a Form" procedure. Instead of using the LedgerDimensionDefaultAccountController class, use the LedgerDimensionAccountControllerclass. This class has similar methods and can be called in the same way.
Control Options
The LedgerDimensionAccountController has several additional parameters available for validating, looking up, and saving ledger accounts from the Segmented Entry control. The following methods are 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. parmLockMainAccountSegments: Specifies whether the main account segment can be modified. The default value is false. 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.
4-18

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. 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.
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 if all parameters have been correctly set.
System-Defined Dimensions
With system-defined dimensions, it is not necessary to maintain two separate lists of values for an entity you want to track details for in the general ledger. When you set up a system-defined dimension, the values for the entity are automatically copied from the entity table into the dimension values. Any time the data is modified or a new record is inserted into the backing entity table, the information is automatically updated in the dimension values. Scenario Ken, the Controller, wants to track the vehicle details in the general ledger. Simon, the Business System Developer, needs to create a new system-defined dimension for vehicles so that Ken will not need to maintain a custom list of the vehicles in the Financial dimensions form. After the new system-defined dimension is created, Ken must set up the new financial dimension to be linked to the vehicles backing entity. Then, he must add the new financial dimension to the account structure or advanced rules for the chart of accounts. Simon also needs to add defaulting logic to the Vehicles form so that when a new vehicle is created, the financial dimension for vehicles will default to the current vehicle ID and cannot be changed. Then he must add logic to the Rentals form to copy the financial dimensions from the vehicle to the rental record.
Demonstration: Add a System-Defined Dimension

The options available in the Use values from field on the Financial dimensions form are retrieved by using the DimensionEnabledType class. The getSystemDefinedDimensionServer method searches for views with a name beginning with DimAttribute. The view must have three fields named Key, Value, and Name that are used to display the list of values from the table.
4-19

To add a new system-defined dimension, follow these steps. 1. 2. 3. 4. Open the Development Workspace. Expand the Data Dictionary node in the AOT window. Right-click the Views node and then click New View. In the Properties window for the new view, set the following properties. a. Name = DimAttributeFMVehicle IMPORTANT: This name must begin with "DimAttribute" or it will not be selected by the getSystemDefinedDimensionServer method. b. Label = Vehicles NOTE: This is the description that will appear in the Use values from dropdown list on the Financial dimensions form. c. FormRef = FMVehicle d. SingularLabel = Vehicle 5. Expand the Metadata node of the DimAttributeFMVehicle view. 6. Open a new AOT window, and then locate the FMVehicle table and drag it to the Data Sources node of the DimAttributeFMVehicle view. 7. In the Properties window for the new data source, enter BackingEntity in the Name property, and then save the view. 8. Expand the Fields node of the DimAttributeFMVehicle view and the Fields node of the BackingEntity data source. 9. Drag the RecID field from the BackingEntity > Fields into the Fields node for the view. 10. In the Properties window for the RecID field, enter Key for the name. 11. Drag the VehicleId field from the BackingEntity > Fields into the Fields node for the view. 12. In the Properties window for the VehicleId field, enter Value for the name. 13. Drag the Description field from the BackingEntity > Fields into the Fields node for the view. 14. In the Properties window for the Description field, enter Name for the name. CRITICAL: The three fields must be named Key, Value, and Name for the dimension to function correctly.
4-20

15. Click Save all to save the view. 16. Restart the Application Object Server (AOS). This step is required to clear the cache.
Demonstration: Test the System-Defined Dimension

To test the new system-defined dimension, follow these steps. 1. Open Microsoft Dynamics AX 2012. 2. Open Fleet management > Setup > Fleet setup. 3. On the Vehicle make and models tab, click New in the Make grid, and then enter a vehicle make. 4. In the Model grid click New, and then enter a model and model specification. 5. Close the Fleet management configuration form. 6. Open Fleet management > Vehicles > All vehicles. 7. Click Vehicle in the New group of the Action Pane. 8. Click Create on the dialog box. 9. Enter a Vehicle ID if one is not created for you. 10. Enter a VIN number. 11. Select a Vehicle model from the list. 12. Close the Vehicle form. 13. Open General ledger > Setup > Financial dimensions > Financial dimensions. 14. Click New. 15. In the Use values from field, select Vehicles. 16. Click the Financial dimension values button. 17. Notice the vehicle that you created in step 7, and that the New icon is disabled. Close all the forms. NOTE: At this point, you have created a system-defined dimension and set it up as financial dimensions. Additional steps would be required to add the dimension to an account structure or advanced rule. Additional coding would also be required to default the dimension value on the vehicle and to copy the value from vehicles to rentals.
4-21
Lab 4.1 - Create a System-Defined Dimension

This lab demonstrates how to create a new system-defined dimension. This lab is designed for self-study. Completing this lab takes approximately 20 minutes. Scenario Ken, the Controller, wants to track the rental details in the general ledger. Simon, the Business System Developer, needs to create a new system-defined dimension for rentals so that Ken will not need to maintain a custom list of the rentals in the Financial dimensions form. After the new system-defined dimension is created, Ken must set up the new financial dimension to be linked to the vehicles backing entity.
Challenge Yourself!
Use the information provided to create a new system-defined dimension for rentals. The table that stores rentals is called FMRentals.
Need a Little Help?

1. 2. 3. 4. 5. 6. Create a new project to store the development changes. Create a new view and make sure to name the view correctly. Add the FMRental table to the view. Add three fields to the view for the Key, Value, and Name. Save the view and then restart the AOS. Test your work by adding a new financial dimension.
Step by Step
To add a new system-defined dimension, follow these steps. 1. 2. 3. 4. Open the Development Workspace. Expand the Data Dictionary node in the AOT window. Right-click the Views node and then click New View. In the Properties window for the new view, set the following properties. a. Name = DimAttributeFMRental b. Label = Rentals c. FormRef = FMRental d. SingularLabel = Rental
5. Expand the Metadata node of the DimAttributeFMRental view.
4-22

6. Open a new AOT window, and then locate the FMRental table and drag it to the Data Sources node of the DimAttributeFMRental view. 7. In the Properties window for the new data source, enter BackingEntity in the Name property, and then save the view. 8. Expand the Fields node of the DimAttributeFMRental view and the Fields node of the BackingEntity data source. 9. Drag the RecID field from the BackingEntity > Fields into the Fields node for the view. 10. In the Properties window for the RecID field, enter Key for the name. 11. Drag the RentalId field from the BackingEntity > Fields into the Fields node for the view. 12. In the Properties window for the RentalId field, enter Value for the name. 13. Drag the Comments field from the BackingEntity > Fields into the Fields node for the view. 14. In the Properties window for the Comments field, enter Name for the name. 15. Save the view. 16. Close Microsoft Dynamics AX. 17. Open Start > Administrative Tools > Services. Locate the Microsoft Dynamics AX service and then click Restart service. To test the new system defined dimension, follow these steps. 1. Open Microsoft Dynamics AX 2012. 2. Open General ledger > Setup > Financial dimensions > Financial dimensions. 3. Click New. 4. In the Use values from field, select Rentals. 5. Close the form. TIP: You can import the AX2012_ENUS_DEVIV_04_01_LAB_SOL.xpo file to verify and compare your solution.
4-23
Journals and Transactions

Although many activities are automatically reflected in the general ledger, information can also be entered manually by using journals. These journals contain information that is not included in automatic postings and in the manually entered corrections of automatic postings.
Journals Overview
A journal is a worksheet you can use before you manually enter postings into the system. Before you use financials in Microsoft Dynamics AX, you must complete the setup procedures for journals. The procedures include the basic setup of journals such as journal names, controls, and texts. You can use journals quickly and efficiently when you set them up correctly. Both manual and system generated journals exist in Microsoft Dynamics AX. Examples of system generated journals are allocation journals and elimination journals. These journals are created automatically and are never created manually. Manual journal entries are generated by postings entered into the system such as a general journal entry. When you use a manual journal entry the transactions are not posted immediately. Before you post a manual entry, the journal can be changed, reviewed, approved, or deleted. In Microsoft Dynamics AX, you can use journals to do the following. Control different kinds of entries. You can apply an approval system so that special journals are posted only after they are approved. Review data imported from external ledger systems. You can ensure that all valid fields contain a value and that all restrictions for the transaction are fulfilled. Make sure that the necessary voucher series is set up before you create journals. You can set up number sequences and attach them to the appropriate references.
Users can post transactions to the following accounts by using a general journal. General ledger Bank Customer Vendor Projects Fixed assets
4-24

In a general journal, users enter the following information for the transaction. Posting date Amount Accounts to post to
The information users enter in a general journal is temporary and can be changed if it remains unposted within the journal.
4-25

Journals Data Model
The following figure shows the data model for journals.
FIGURE 4.5 LEDGER JOURNAL DATA MODEL
The LedgerJournalName table contains defined journal names. Each journal name has a set of parameters that are implemented as fields in this table. The table contains journal names that are used in the Ledger, Customer (accounts receivable), Vendor (accounts payable), and Project modules.
4-26

The LedgerJournalControl table contains restrictions on the transactions posted in the related journal name. Restrictions can refer to company, posting layer, transaction type, account number, or user group. The LedgerJournalTable table contains one record for each journal. A journal is a set of journal transactions with a given statuseither created or posted. Each journal is related to a journal name and has a journal number. When a journal is created, many of its parameters are copied from the corresponding record in LedgerJournalName and can be set up individually for each journal. Records in LedgerJournalTable are also used to block the journal while it is being posted. The LedgerJournalParmPost table contains parameters that are used when you post multiple journals by the batch. This is a periodic function, and it is an alternative to activating posting directly from the current journal. The LedgerJournalTrans table contains individual journal lines. When a journal is posted, all journal lines are either posted or moved to another non-posted journal. A journal cannot contain both posted and non-posted lines at the same time. Each journal line has a line number that is used to sort journal lines. This field should not be used to identify a journal line, because it does not have to be unique. If you must have a unique reference for a journal line, you should use the RecId field. Asset and Project transaction information is stored in the LedgerJournalTrans_Asset and LedgerJournalTrans_Project tables related to the LedgerjournalTrans table record. The LedgerJournalTxt table can be used to store typically used transaction texts. Each text is associated with an alias that can be used when you enter information in the journal lines Description field. This table is not related to other tables that are used by the ledger journal.
Journals Posting Framework

The LedgerJournalCheckPost class handles the validation and posting of a ledger journal. The postJournal() method selects the lines of the journal. For each journal line postTrans() is called. The class can be activated directly from X++ by using the following lines:
ledgerJournalCheckPost = LedgerJournalCheckPost::newLedgerJournalTable( ledgerJournalTable, NoYes::Yes); ledgerJournalCheckPost.run();
4-27

The second parameter specifies whether the journal should be posted (true) or validated (false). The update of the individual journal line is handled by the class hierarchy LedgerJournalTransUpdate.
FIGURE 4.6 LEDGERJOURNALTRANSUPDATE TYPE HIERARCHY BROWSER
The check() method is used when validating the journal. The checkWhenPost() method is used when validating the journal during posting and the updateNow() method handles the update of the posting. The posting is handled over to the LedgerVoucher class.
Transactions Overview
The General ledger module records the value of all company assets. This includes cash, accounts receivable, bank accounts, stocks, bonds, inventory, buildings, and machinery. Any event that changes the value of these assets should be reflected in ledger transactions.
4-28

The following figure shows General ledger module interfaces with other Microsoft Dynamics AX modules:
FIGURE 4.7 GENERAL LEDGER INTEGRATIONS
The Inventory and warehouse management module keeps track of items available for sale. Every time an item is bought or sold, the corresponding figure that represents the inventory value in the General ledger module will change. These transactions come from inventory journals, sales orders, purchase orders, transfer orders, or other inventory transactions. The sales and purchase orders facilitate trade with vendors and customers. Related stock changes are handled by the Inventory and warehouse management module. Invoice payments occur through the Accounts payable and Accounts receivable modules by using invoice journals and payment journals. Every sales order generates revenue and a corresponding cost of goods sold. Both are reflected in the General ledger module. The Cash and bank management module keeps track of company bank accounts, whose balance values are also reflected in the General ledger module. When payments are posted to customer or vendor accounts using the payment journals the customer and vendor balances are updated at the same time. The Project management and accounting module keeps track of projects. This includes registration of hours and customer invoicing. Revenues and related costs are posted in the General ledger module. The periodic revenue assessment on fixed price projects is also reflected in related transactions in the General ledger module.
4-29

The Fixed assets module keeps track of material assets used for operations such as buildings and machinery and are not intended for sale like inventory products. These asset values are recorded in the General ledger module, just as asset revaluation and depreciation are also reflected there. The Budgeting module keeps track of plans or budget amounts for the chart of accounts. These estimated or budgeted amounts can then be compared to actual amounts in the general ledger. The budget amounts are often times generated based on the actual amounts from the general ledger.
Transactions Data Model

When a transaction is posted to the General ledger the information is recorded in several different tables. This includes manual journals and other types of automatic transactions such as sales order invoices, or inventory transfers. The following figure shows the ledger transactions data model.
FIGURE 4.8 GENERAL LEDGER TRANSACTIONS DATA MODEL
Ledger Posting Framework

The ledger posting framework is the API used to post to the general ledger and includes the LedgerVoucher, LedgerVoucherObject, and LedgerVoucherTransObject classes and related classes. Developers can use the factory methods in the LedgerVoucherTransObject class to create instances of these classes. Multiple factory methods exist to support different input scenarios. After using one of these methods to create a class instance, a developer can customize the instance by using the parm methods.
4-30

The LedgerVoucherTransObject class exposes the fields in the following tables: GeneralJournalAccountEntry LedgerEntry GeneralJournalEntry LedgerEntryJournal
LedgerVoucher Class
The task of the LedgerVoucher class is to control ledger transaction postings. You can use this class when you post ledger journals and other updates that contribute to ledger transactions. It verifies the posting is correct and that the voucher balances. The LedgerVoucher class holds all the vouchers in temporary storage (a list array) until the End method is called. The End method creates ledger transaction records from the temporary postings. An instance of LedgerVoucher can handle several individual vouchers in one transaction. All vouchers handled will be updated in the sum tables in one consolidated step. Each voucher is represented by an instance of LedgerVoucherObject. LedgerVoucherTransObject contains individual transactions that will be created. A LedgerTrans variable is defined in the class declaration to contain the future transaction. The class structure resembles the following. Posting (LedgerVoucher) Voucher (LedgerVoucherObject) o o Trans (LedgerVoucherTransObject) Trans
Voucher o o Trans Trans
If new fields are added to the ledger transactions, this object can also hold the new information. The remaining task is to initialize the new fields which involves the following two steps. 1. Creating parm-method(s) to assign values to the field(s). 2. Changing the static method new() to include the new parm-methods. LedgerVoucher can handle posting with aggregated transactions. LedgerVoucher uses a RecordSortedList to sum up aggregated transactions. The sort order is defined in initLedgerTransList(), whereas the aggregation is calculated in the postGroup() method which handles all numeric fields that will be aggregated.
4-31

The steps in posting ledger transactions by using LedgerVoucher are:
ttsbegin; ledgerVoucher = LedgerVoucher::newLedgerPost(.) ledgerVoucher.addVoucher(LedgerVoucherObject::newVoucher() ); ledgerVoucher.addTrans( LedgerVoucherTransObject::new()); ledgerVoucher.addTrans( LedgerVoucherTransObject::new()); ledgerVoucher.addTrans( LedgerVoucherTransObject::new()); ledgerVoucher.addVoucher(LedgerVoucherObject::newVoucher() ); ledgerVoucher.addTrans( LedgerVoucherTransObject::new()); ledgerVoucher.addTrans( LedgerVoucherTransObject::new()); ledgerVoucher.end(); ttscommit;
AXLedgerJournalTrans Class
The Ax-classes provided with Microsoft Dynamics AX are an encapsulation of records and are typically used when importing data to Microsoft Dynamics AX. It is a best practice to import transactions by importing the data to a journal and letting the standard application handle the posting and generation of transactions. An import to LedgerJournalTrans can be handled by the classes AxLedgerJournalTable and AxLedgerJournalTrans.
4-32
Lab 4.2 - Import Ledger Transactions

This lab demonstrates how to import data into a journal and let the standard application generate the transaction. Estimated time to complete: 40 minutes Scenario Actively participating during this workshop will help you with the following. Understand the concept of how to import data into a journal and let the standard application generate the transaction. Become familiar with the use of Ax-classes to import data to Microsoft Dynamics AX tables. Extend the generic framework for importing data to be implemented for a specific task with minimal effort.
Requirement
Create a solution that contains a function to import ledger transactions into the general journal. The file consists of records with the following information: Ledger account Transaction date Voucher number Transaction text Currency code Amount in currency
A sample of the file will resemble the following.

"606200","2006/09/10","ext00005","Insurance third quarter","EUR",100.00 "606300","2006/09/10","ext00005","Pencils","EUR",200.00 "110180","2006/09/10","ext00005","Misc. cash expenses","EUR",-300.00 "606300","2006/09/11","ext00006","Copy paper","USD",70.00 "110180","2006/09/11","ext00006","Copy paper","USD",-70.00
4-33

Technical Issues
Base Import
A generic import class is included in your Hyper-V training image that can be extended to the specific import tasks. The AXABaseImport class is a generic class for importing files. AXABaseImport is abstract and extends RunBaseBatch. A dialog box that can browse for a file is implemented for the reading of the file. Three methods are implemented. All three methods are called from the run method in AXABaseImport. preImport(): This method is called once before importing data. importRecord(): This method is called once for each record read in the file. This method takes a container as argument. This container contains the data from one record read in the file. postImport(): This method is called once after all the records in the file are read.
To create a class which can import from a file, you extend this class and override these three methods.
Vouchers
When transactions are manually entered in the ledger journal, the vouchers are typically allocated automatically by using a number sequence. To assign the voucher during the import, the journal used should be set up with a manual number sequence for vouchers.
4-34

The number sequence is specified on the journal name in the LedgerJournalName table and the specification of the manual allocation is specified on the set up of the number sequence in the NumberSequenceTable table:
FIGURE 4.9 NUMBER SEQUENCES FORM
Step by Step
To import ledger transactions into general journal, follow these steps. TIP: The code samples for this lab can be found in the AX2012_ENUS_DEVIV_04_02_LAB_CODE.txt file. You can copy and paste these code samples into the correct methods. 1. Import the file AX2012_ENUS_DEVIV_04_02_LAB.xpo that contains the AXABaseImport and the AXALedgerImportTransactions classes. Do not be concerned about the dialog or reading of the file. This is already implemented so that you can stay focused on the General ledger module. 2. Change the AXALedgerImportTransactions class. a. Override the preImport() method to create a journal header in the LedgerJournalTable table by using the AxBC interface AxLedgerJournalTable. Use the following code sample to guide you.
4-35

protected void preImport() { super(); axLedgerJournalTable = AxLedgerJournalTable::construct(); axLedgerJournalTable.parmJournalName(journalName); axLedgerJournalTable.save(); } b. Override the importRecord() method to create the individual journal line in the LedgerJournalTrans table by using the AxBC interface AxLedgerJournalTrans. Use the following code sample to guide you. void importRecord(container _c) { #Define.PosLedgerAccount(1) #Define.PosTransactionDate(2) #Define.PosVoucherNumber(3) #Define.PosTransactionText(4) #Define.PosCurrencyCode(5) #Define.PosAmountCurrency(6) AxLedgerJournalTrans axLedgerJournalTrans; AmountCur amountCur; ; axLedgerJournalTrans = AxLedgerJournalTrans_CustPaymJour::newLedgerJournalTable(axLedgerJourn alTable.ledgerJournalTable()); axLedgerJournalTrans.parmAccountType(LedgerJournalACType::Ledger); axLedgerJournalTrans.parmLedgerDimension( conpeek(_c,#PosLedgerAccount)); axLedgerJournalTrans.parmTransDate( conpeek(_c,#PosTransactionDate)); axLedgerJournalTrans.parmVoucher( conpeek(_c,#PosVoucherNumber)); axLedgerJournalTrans.parmTxt( conpeek(_c,#PosTransactionText)); axLedgerJournalTrans.parmCurrencyCode( conpeek(_c,#PosCurrencyCode)); amountCur = conpeek(_c,#PosAmountCurrency); if (amountCur > 0) { axLedgerJournalTrans.parmAmountCurDebit(amountCur); } else { axLedgerJournalTrans.parmAmountCurCredit(abs(amountCur)); }
4-36

axLedgerJournalTrans.save(); } c. Override the postImport() method to post the journal after the import, if the option is selected in the dialog box. Use the following code sample to guide you. protected void postImport() { LedgerJournalCheckPost ledgerJournalCheckPost; ; if (postJournal == NoYes::Yes) { ledgerJournalCheckPost = LedgerJournalCheckPost::newLedgerJournalTable(axLedgerJournalTable.ledge rJournalTable(),NoYes::Yes); ledgerJournalCheckPost.run(); } super(); }
NOTE: The sample mentioned in the requirement section is available in the file that is named AX2012_ENUS_DEVIV_04_02_SAMPLEFILE.txt. TIP: You can import the AX2012_ENUS_DEVIV_04_02_LAB_SOL.xpo file to verify and compare your solution.
Test
As described earlier, you need a journal related to a manual number sequence to assign voucher numbers read from the file. This includes the following steps: 1. Create a number sequence by using the path Organization administration > Common > Number sequences > Number sequences. Mark the sequence as manual on the General FastTab. 2. Change the parameters in the ledger module by using the path General ledger > Setup > General ledger parameters. Clear the Check for continuous numbers check box. 3. Create a new journal name by using the path General ledger > Setup > Journals > Journal names. Use the journal type Daily and relate the journal name to the voucher series created in the first step.
4-37

4. Open the AXALedgerImportTransaction class. Then, specify the location of the file AX2012_ENUS_DEVIV_04_02_SAMPLEFILE.txt and the journal name created in step 3. After a successful import, you will find the journal created by using the path General ledger > Journals > General journal. You can repeat the test if you change the data file to use different voucher numbers. Every time that the function is activated, a new journal is created. NOTE: The Ledger dimension values provided in the sample file are record IDs. In a more realistic import, additional code would be required to lookup the recID for the dimension value combination that is entered by the user in the file.
4-38
Budgeting Overview
You can use the Budgeting module to set up, create, and view budgets. Budgeting can include budget control, used to monitor the budget funds that are available for planned and actual purchases and expenditures. You can create budget register entries for the original budget, budget transfers, and budget revisions. You can also create budget register entries to manually reserve budget funds for purchases and planned expenditures by using the encumbrance or preencumbrance budget types. Budget register entries can be created automatically when budgets are transferred to the general ledger from other modules such as Project management and accounting or Fixed assets. You can determine which financial dimensions from the chart of accounts will be available for basic budgeting and budget control. When you configure budget control, you define budget intervals, budget cycle time spans, budget thresholds, budget managers, budget groups, and the calculation that is used to check for available budget funds. The available budget funds can be verified when source documents and accounting journals are entered. You can view the status and history of budget register entries, budget control statistics, actual versus budget amounts, budget details, and budget funds available.
FIGURE 4.10 BUDGETING BUSINESS PROCESS
One of most important management tools a company can use to make plans is to compare planned performance to actual performance. Planning for the general ledger is performed by creating budgets in the Budgeting module. A budget is a set of expected ledger transactions. Although a budget can be as finely detailed as actual transactions, budgets are more typically prepared at an aggregate level.
4-39

Budgets are also used in balance sheet reports, where planned figures are compared with actual values.
Basic Budgeting Set Up

You can use basic budgeting to define the financial dimensions for budgets, create budget models, and set up and use budget register entries. You can also set up optional Budgeting workflows to automate the review of budget register entries, including budget transfers. Before you use basic budgeting, complete the steps that are described in the following topics. If you use budget control, you must set up basic budgeting before you configure budget control. Required: Define budget exchange rates Required: Define budgeting parameters and number sequences Required: Define financial dimensions for Budgeting Required: Create budget models Required: Define budget codes Optional: Define budget transfer rules Optional: Set up budgeting workflows Optional: Set up budget allocation terms
Budget Control Set Up

Budget control is a method of ensuring that sufficient budget funds are available for planned or actual purchases. After you set up basic budgeting, you can set up budget control. You can set up basic budgeting and budget control based on the ledger for a legal entity. The ledger provides the chart of accounts, accounting and reporting currencies, and fiscal calendar. You can determine which financial dimensions from the chart of accounts will be available for budgeting and budget control. Additionally, you can define the following. Budget intervals Budget cycle time spans Budget thresholds, budget managers Budget groups Calculation used to check for available budget funds
4-40

The available budget funds can be verified when source documents and accounting journals are entered. The following figure shows the data model for the budget control configuration.
FIGURE 4.11 BUDGET CONTROL CONFIGURATION DATA MODEL
The following areas are integrated with budget control. General journals Allocation journals Project expense journals Fixed asset journals Accounts payable invoice journals Accounts payable invoice approval journals Accounts payable invoice registers Vendor invoices Purchase orders
4-41

Purchase requisitions Travel requisitions Expense reports
NOTE: The Project management and accounting module also uses its own budget control. It is only integrated with the Budgeting modules budget control through the Project expense journal. For more information about Project management and accounting budgeting functionality, refer to the Advanced Projects in Microsoft Dynamics AX 2012 course.
Budget Amounts
After you have set up and configured basic budgeting you can begin to enter budget amounts. If you plan to use budgeting workflows, create the workflows, and then assign them to budget codes before you begin to make budget register entries. Also, if you plan to use budget control, configure budget control before you enter budget amounts. The budget data is entered through the Budget register entry form that consists of a header and lines. The header information is applied to the whole budget register entry and the lines (account entries) are where budget amounts for specific dimension combinations are entered.
4-42

The following figure shows the data model for budget register entries.
FIGURE 4.12 BUDGET REGISTER ENTRY DATA MODEL
When you have completed entering the budget register entries, you must update the budget balances. This step is similar to posting a general journal and updates the budget amounts based on the budget account entries. The BudgetTransactionPost class is used to update the budget amounts from a single budget register entry. The checkHeader(), checkLine(), and checkLines() methods are used to validate the data that is entered. The run() method invokes these checks and has additional logic to check for workflow status when workflow is enabled for budgeting. The call to the postToGeneralLedger() method is called after the validation is completed. This method checks whether budget appropriations are enabled and if they are then a new journal is created to post the amount directly into the general ledger. When the postToGeneralLedger() method completes, the status of the budget register entries are updated to completed. The BudgetTransactionMultiPost class is used to invoke several instances of the BudgetTransactionPost class based on the selection criteria that is entered by the user.
4-43

The BudgetCalculateBalance class queries for budget and posted ledger amounts by fiscal period and uses the information to create records in the BudgetTmpBalance temporary table. This class supports the Actuals vs. Budget inquiry & report and role center chart.
Budget Checking
When budget control is enabled for a specific source document, budget checks are completed automatically when the record is saved. The check is based on options specified in the budget control configuration except for the budget register which always perform a check on line save. You can also manually perform a budget check on a transaction. Budget checks are processed by using the BudgetControlProcessor class. There are core integrations to the Budget control framework through the following classes as well: BudgetControlSourceDocumentProcessor BudgetControlBudgetTransactionProcessor BudgetControlAccountingJournalProcessor
These classes handle common patterns for formulating the budget control check request for the BudgetControlProcessor based on the type of integrator. The BudgetControlCheckRequest class is used to capture the information that is required to check for available budget that relates an integrator to budgetary control. When this class is constructed, the BudgetCheckDetail, BedgetReturnDetails, and BudgetReleivingDetails classes (which all extend the BudgetSourceDetail class) are used to capture the ledger dimension and the currency amount details for the budget funds available check. NOTE: A portion of the budget control checking logic occurs through stored procedures on the SQL Server. The code for the SQL logic is contained in the BudgetControlSQLObjects class and the T-SQL code is deployed to the SQL Server at activation of the budget control configuration or first budget check. When a budget check is completed and returns an error or warning, you can use the Budget check errors or warnings form to view the details.
4-44
Fixed Asset Overview

Fixed assets are items of value, such as buildings, vehicles, land, and equipment owned by an individual or corporation, and used in operations. You can set up and enter acquisition information for fixed asset records, and then manage fixed assets by depreciating them and setting a capitalization threshold to determine depreciation. You can calculate adjustments to the fixed assets, and also dispose of them. When you use the Fixed assets module, you can view the current value of all fixed assets. The way in which fixed assets are handled must correspond to both international accounting standards and the accounting legislation in each country/region. Requirements might include rules for recording acquisition and disposal transactions, depreciation, lifetimes, and write-ups and write-downs of fixed assets. The fixed assets functionality incorporates many of these standards and rules.
FIGURE 4.13 FIXED ASSET BUSINESS PROCESS
NOTE: The transfer of fixed assets to a low-value pool is an Australian feature and is not a part of the core functionality. You must enter transactions to track the acquisition, depreciation, and disposal of fixed assets. Sometimes you must change the value of an asset. For example, the value of land that your organization owns might increase, or you might have to reflect the fair market price of a specific asset.
4-45

Fixed Assets versus Current Assets
In a company's balance sheet, assets are divided into two groupsfixed assets and current assets. It is important to define the differences between fixed and current assets before discussing how to account for each. The classification of assets is not based on the physical nature of the asset, but instead on the purpose of the ownership of the asset. Current assets are those that a company depletes in the typical course of business over the next year or business cycle, whichever is shorter. Examples of current assets include cash, accounts receivable, prepaid expenses, or inventory. Fixed assets are assets that a company owns and uses in the day-to-day operations of the company and are not intended for resale to customers. The useful lives of these assets spans multiple years. Examples of fixed assets include automobiles, computers, machinery, buildings, copyrights or trademarks (a special class of assets frequently called intangible assets). Based on these definitions, the same asset can be classified as a fixed asset in one company and as a current asset or inventory item in another. An example of a company where the same asset can be classified as both fixed and current is an automobile dealership. The vehicles held for sale are inventory items in addition to current assets, whereas the manager's company car is a fixed asset.
Fixed Asset Module Overview

The Fixed assets module provides subledger detail that supports a controlling account in the general ledger the same way the Accounts receivable and Accounts payable modules provide subledger detail to support the associated controlling accounts in the general ledger. This relationship between the subledgers and the general ledger is achieved through setups where specifications are provided for one or more ledger accounts. In addition to supporting the general ledger, the Fixed assets module in Microsoft Dynamics AX 2012 includes the following functionality. Provides detailed documentation for the company's assets. Simplifies the tracking of depreciation. Allows for write-ups or write-downs. Allows for the acquisition and disposal of assets. Allows the accounting of assets for tax preparation.
Because most fixed assets represent a significant investment for companies, the ability to track and keep sound financial records on fixed assets is important.
4-46

Fixed Asset Integration
At a minimum, the Fixed asset module is integrated to the general ledger. All asset transactions posted in the Fixed asset module must also update the asset values in the company's chart of accounts. This integration to the general ledger represents the minimum functionality that the Fixed assets module must provide. Microsoft Dynamics AX 2012 provides many additional features including the following. Accounts receivable integration Accounts payable integration Budgeting Inventory journal integration Purchase order integration Project accounting integration Country- or region-specific functionality for many countries and regions
Fixed Asset Setup

Many options are available in the setup of the Fixed asset module. The basic setup that is required represents a small part of all available options. Most setup options are used when advanced or country and region-specific features are needed. Most of the basic setup steps are accessed by opening Fixed assets, and then clicking Setup. The standard steps are as follows. Depreciation profiles Depreciation books Value models Fixed asset groups Posting profiles Parameters
Fiscal calendars must also be set up in the General ledger module.
4-47

Fixed Asset Data Model
The following figure shows the data model for fixed assets.
FIGURE 4.14 FIXED ASSETS DATA MODEL
The AssetTable is the primary table for storing fixed assets. Each asset has one record in this table. Each fixed asset is assigned to a fixed asset group. The fixed asset groups are used to help simplify the setup of assets, for reporting and inquiries, and to serve as a template with default information for setting up an asset. The fixed asset groups and default data are stored in the AssetGroup table. Each asset can have several value models that are stored in the AssetBook. The default information for value models is stored in the AssetBookTable. Additionally, each asset can have several depreciation books. Each depreciation book for an asset is stored in the AssetDepBook table. The default information for a depreciation book is stored in the AssetDepBookTable. Depreciation books do not post to the general ledger like value models, so there is no accounting related to them. The depreciation books are used to calculate various values of the assets based on the depreciation profile selected for reporting purposes.
4-48

Each value model and depreciation book is related to a depreciation profile. Depreciation profiles are used to define rules for calculating depreciation. Creating profiles is required for depreciable assets. This usually refers to tangible assets, but intangible assets can also use depreciation profiles. This information is stored in the AssetDepreciationProfile table. Fixed assets transactions are posted by using a journal. This process is similar to the general journal. The data model and classes used for posting fixed assets are similar.
Summary
This chapter introduced currencies and exchange rates. Microsoft Dynamics AX 2012 supports multiple currencies and making conversions between currencies. The CurrencyExchangeHelper and ExchangeRateHelper classes can be used to make currency conversions. Additionally, the chapter introduced the chart of accounts. The chart of accounts consists of main accounts and financial dimensions. The main accounts and dimensions are then constrained by the account structures and advanced rules in use by the chart of accounts. You can define two types of financial dimensions system-defined and custom lists. Financial dimensions and main accounts can also be combined to create dimension sets that are used to group and report on specific combinations of dimensions. Journals and transactions comprise the details of the general ledger. Journals are used to make manual adjustments and are posted by using the journal framework and the LedgerJournalCheckPost class. Other transactions such as sales order invoices or expense reports are posted by using automatic journals with the LedgerVoucher class hierarchy. You can use the Budgeting module to create budget amounts for a specified combination of the main account and financial dimensions. However, the main account is not required for budgeting. You can use budget control checking to enable a budget check on certain source documents. With this check you can warn a user or prevent a user from posting a transaction that exceeds specified budget thresholds. The Fixed asset module is also used to create and track information related to your companies fixed assets. You can keep multiple sets of books for each asset, and use the fixed asset journal to acquire, depreciate, or adjust assets.
4-49
Test Your Knowledge

Test your knowledge with the following questions. 1. Which of the following tables are used for a new budget register entry? (Select all that apply) ( ) BudgetTransactionHeader ( ) BudgetTransactionLine ( ) LedgerBudgetHeader ( ) LedgerBudgetLine 2. Which class holds a list of transactions that are going to be posted for a particular voucher? ( ) LedgerVoucher ( ) LedgerVoucherObject ( ) LedgerVoucherObjectTrans ( ) LedgerVoucherTransObject 3. Name the two types of financial dimensions in Microsoft Dynamics AX 2012 and describe what each type is used for.
4. Which class is used to post a general journal? ( ) LedgerJournalPost ( ) LedgerJournalCheckPost ( ) LedgerVoucher ( ) LedgerVoucherPost 5. Which table is the primary table used for storing fixed asset information? ( ) AssetBook ( ) AssetTable ( ) AssetTrans ( ) AssetGroup
4-50

6. Which of the following tables are part of the ledger journal data model? (Select all that apply) ( ) LedgerJournalName ( ) LedgerJournalTable ( ) LedgerJournalLines ( ) LedgerJournalTrans 7. Which of the following are valid field names to be used in a view for a new system-defined dimension? (Select all that apply) ( ) Key ( ) Group ( ) Value ( ) Name
4-51
Quick Interaction: Lessons Learned

Take a moment and write down three key points you have learned from this chapter 1.
2.
3.
4-52
Solutions
Test Your Knowledge
1. Which of the following tables are used for a new budget register entry? (Select all that apply) () BudgetTransactionHeader () BudgetTransactionLine ( ) LedgerBudgetHeader ( ) LedgerBudgetLine 2. Which class holds a list of transactions that are going to be posted for a particular voucher? ( ) LedgerVoucher () LedgerVoucherObject ( ) LedgerVoucherObjectTrans ( ) LedgerVoucherTransObject 3. Name the two types of financial dimensions in Microsoft Dynamics AX 2012 and describe what each type is used for. MODEL ANSWER: System-defined: Select a system-defined entity to base the financial dimension on. Financial dimension values will be created from this selection. For example, to create dimension values for projects, select Projects. A dimension value will be created for each project name. User-defined: To create a user-defined financial dimension, select < Custom dimension > 4. Which class is used to post a general journal? ( ) LedgerJournalPost () LedgerJournalCheckPost ( ) LedgerVoucher ( ) LedgerVoucherPost 5. Which table is the primary table used for storing fixed asset information? ( ) AssetBook () AssetTable ( ) AssetTrans ( ) AssetGroup
4-53

6. Which of the following tables are part of the ledger journal data model? (Select all that apply) () LedgerJournalName () LedgerJournalTable ( ) LedgerJournalLines () LedgerJournalTrans 7. Which of the following are valid field names to be used in a view for a new system-defined dimension? (Select all that apply) () Key ( ) Group () Value () Name
4-54

Ax2012 Enus Deviv 04 PDF

Uploaded by

Document Informationclick to expand document informationdynamics Ax 2012 development 4 chapter 4

Document Informationclick to expand document information

Copyright:

Available Formats

Ax2012 Enus Deviv 04 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ax2012 Enus Deviv 04 PDF

Uploaded by

Copyright:

Available Formats

Chapter 4: Use and Design of the Ledger Module

CHAPTER 4: USE AND DESIGN OF THE LEDGER MODULE

Development IV in Microsoft Dynamics AX 2012

General Ledger Overview

Currency and Exchange Rate Setup

Chapter 4: Use and Design of the Ledger Module

FIGURE 4.1 CURRENCIES FORM

Accounting and Reporting Currencies

Development IV in Microsoft Dynamics AX 2012

Chapter 4: Use and Design of the Ledger Module

Retrieving exchange rates

Development IV in Microsoft Dynamics AX 2012

Chapter 4: Use and Design of the Ledger Module

FIGURE 4.2 CURRENCY AND EXCHANGE RATE DATA MODEL

Periods and Fiscal Year Setup

Development IV in Microsoft Dynamics AX 2012

Multiple Chart of Accounts

Chapter 4: Use and Design of the Ledger Module

Can be copied to transactions automatically.

Financial Dimension Values

Development IV in Microsoft Dynamics AX 2012

Financial Dimension Sets

Chapter 4: Use and Design of the Ledger Module

Development IV in Microsoft Dynamics AX 2012

Chapter 4: Use and Design of the Ledger Module

FIGURE 4.3 CHART OF ACCOUNTS DATA MODEL

Development IV in Microsoft Dynamics AX 2012

Chapter 4: Use and Design of the Ledger Module

FIGURE 4.4 FINANCIAL DIMENSIONS DATA MODEL

Procedure: Add a Default Dimension Control to a Form

Development IV in Microsoft Dynamics AX 2012

Chapter 4: Use and Design of the Ledger Module

Development IV in Microsoft Dynamics AX 2012

Procedure: Add a Ledger Account Control to a Form

Chapter 4: Use and Design of the Ledger Module

Demonstration: Add a System-Defined Dimension

Development IV in Microsoft Dynamics AX 2012

Chapter 4: Use and Design of the Ledger Module

Demonstration: Test the System-Defined Dimension

Development IV in Microsoft Dynamics AX 2012

Lab 4.1 - Create a System-Defined Dimension

Need a Little Help?

5. Expand the Metadata node of the DimAttributeFMRental view.

Chapter 4: Use and Design of the Ledger Module

Development IV in Microsoft Dynamics AX 2012

Journals and Transactions

Chapter 4: Use and Design of the Ledger Module

Development IV in Microsoft Dynamics AX 2012

FIGURE 4.5 LEDGER JOURNAL DATA MODEL

Chapter 4: Use and Design of the Ledger Module

Journals Posting Framework

Development IV in Microsoft Dynamics AX 2012

FIGURE 4.6 LEDGERJOURNALTRANSUPDATE TYPE HIERARCHY BROWSER

Chapter 4: Use and Design of the Ledger Module

FIGURE 4.7 GENERAL LEDGER INTEGRATIONS

Development IV in Microsoft Dynamics AX 2012

Transactions Data Model