Patching in Microsoft Dynamics AX 2009

Recently I found this interesting information about patching in Dynamics AX 2009. If you want to understand more about how to install hotfixes and the Dynamics AX 2009 servicing architecture, Microsoft actually have published a white paper about it. Basically it explains the two types of standard hotfixes available in AX 2009: Binary hotfixes and Application hotfixes. It also explains the steps to perform the installation for these two types of hotfixes. Even better, the link below also included a video on step by step installing the hotfix.

https://mbs.microsoft.com/customersource/support/documentation/whitepapers/ax2009patching.htm

Note: You need Partner Source login to access this information.

Kernel version and Application version

You can check the Kernel version and Application version in the Dynamics AX client by clicking Help > About Microsoft Dynamics AX. Usually both numbers will be the same, but this might not be the case in all time.

Kernel version
This is the kernel build number for the Dynamics AX binary executable files. The About form is only showing the kernel version of the currently running instance of AX client (Ax32.exe). To view the server kernel version, you need to check the file property for the Ax32serv.exe. The kernel version will be updated when you perform an AX upgrade or install a service pack, i.e. from AX 2009 RTM to AX 2009 SP1 that affects the binary files, or when you install a hotfix that contains binary patch (patch via msp or dll files).

Application version
This is the version number for the currently installed application. The version number is stored as static text in the class ApplicationVersion::applBuildNo(). The number will be updated when you perform an AX upgrade or install a service pack, or when you install certain hotfix that contains application patch (patch via xpo import).

The post below shows a list of all kernel version and application version from Axapta 2.5 to AX 2009 SP1. You can also use this to verify whether you have installed any service packs or hotfix roll-ups.
http://blogs.msdn.com/emeadaxsupport/archive/2009/07/01/overview-ax-kernel-build-numbers.aspx

Dick has written a sample code to check the kernel version for both client and server:-
http://axstart.spaces.live.com/Blog/cns!E82F2C8CB173C0A0!350.entry

Methods for refreshing form data

It is easy to confuse which method is the correct one to use for refreshing data in forms since Dynamics AX has 4 different form refresh methods:- refresh(), reread(), research() and executeQuery().

Vanya Kashperuk has posted an excellent article on explaining the usages of these methods.
http://kashperuk.blogspot.com/2010/03/tutorial-reread-refresh-research.html

Purchase accrual month end reconciliation

During month end, usually there is a need to reconcile between the total purchase accrual for the month with the Inventory module. Purchase accrual GL account (Packing slip offset) is the GL account that records the total value for all the goods received but not yet invoiced (GRNI) for the month.

To reconcile this GL account with Inventory module, you can use the standard Item transactions report (Item management> Reports> Transactions> Item transactions). But usually the common assumption for retrieving the GRNI value is to filter the report for all items with the Receipt status as Received. This is incorrect if you back date print the report for prior month, where the stock that has been received (but not yet invoiced) in prior month has been invoiced now. Eg. Current month is Feb, you want to print all GRNI for Jan, and some stock that are received in Jan has been invoiced now in Feb. This is because Receive status for the Invent transactions have been changed to Invoice status now in Feb, and there is no way to retrieve back the original status on Jan.

There are two possible ways to solve this issue. Firstly, completely avoid this situation to happen by make it a business practice to have all the stock that received this month, are invoiced on the same month before the month end closing. This is the ideal situation.

In the not so ideal situation, there is possible to retrieve the correct GRNI value by tweaking the filtering criteria on the Item transaction report. We need to create the filter criteria so that the Item transaction report shows all purchase received transactions for current period that is either NOT yet invoiced, OR received in current month but invoiced after the current month. The report needs filter criteria as below:-

• Physical date – Start and end date of current period (Eg. 01/01/2009..31/01/2009)
• Financial date – Empty (indicates not yet invoiced) OR invoiced after the current period. (Eg. ‘ ‘, >31/01/2009)

Physical date indicates the Receive date for the item transaction, where Financial date is the Invoice date for the transaction. In this case, the Physical cost amount in the report should be tally with the Packing slip offset GL account.

Issues on Service item

Usually for service item, you do not require to set up the Packing slip and Packing slip offset posting account in the Inventory profile. But there is one exception case in Dynamics AX 4.0.

If you have set up the Inventory Cost price in the Item master for a service item, and Inventory module group is having Post physical inventory activated, and Post packing slip in ledger is selected in Purchase parameters, Dynamics AX will give you a posting error if you do not set up these two accounts in the Inventory profile when you are trying to post a Purchase invoice.

Once you have set up these 2 accounts, the purchase invoice posting will have no more error. But in fact, Dynamics AX will not post any entries in these 2 accounts during the posting. It is just a logical bug in posting checking classes. So, it is good to make sure Inventory cost price is always zero for service item.

Another weird cases for service item is in fixed asset acquisition using purchase order. When you purchase a service item and linking it to a Fixed asset number in purchase order line, the invoice posting entry will be
Dr Purchase - receipt, Cr Vendor balance.
But when you try to do the return on the purchase of fixed asset using the same method with negative quantity, Dynamics AX will require you to set up a Stock, receipt account in the inventory posting profile. The posting entries will be
Dr Vendor balance, Cr Purchase, receipt;
Dr Stock - receipt, Cr Fixed asset
Thus, it is clearly that when you do purchase return on fixed asset using service item, Dynamics AX 4.0 incorrectly creates an additional return posting entry which is actually for stock item.

Import Opening Stock Balance into Dynamics AX

When we import opening stock balance into inventory journal using the standard import/export functionality, the most common problem is dealing with Inventory Dimension id (InventDimId). We might know the warehouse and batch, but we do not know what is the InventDimId that represents the combination of these two inventory dimension.

One way to do this is to lookup the InventDimId value manually before performing the import. This is only possible if very few inventory dimensions are used.

An alternative is using the Custom import functionality to import stock balance CSV file into Tag counting journal.

There is a conversion functionality in the Custom import, where you can write a little X++ code to find the InventDimId using the inventory dimensions.

Here is an example of finding the InventDimId using Site and Warehouse dimension.

You must select Run conversion checkbox to activate the conversion. You may also use the compile icon (on the right hand) to validate the X++ code.

The purpose to use Tag counting journal instead of Movement/Counting journal is we let the system to create the Lot ID when we post the Tag counting journal into Counting journal.

DynamicHeight problem in X++ report

When you developing X++ report, very frequent you will need to print string fields with large string size (eg. Name, Description, DeliveryAddress) or memo type of string. In this situation, you will have difficulty to determine the right Height property to use in the report. The default Auto option in the ReportStringControl follows the DisplayHeight property of the inherited Extented Data Type (EDT), which could be not long enough to display the full string. You can't fix the Height value also, unless the content of the ReportStringControl is known to have some fixed format during the development.

One quick solution for this problem is using DynamicHeight. Set the DynamicHeight property to Yes will let the system to determine the right Height value at runtime. But this is not a perfect solution. Usually DynamicHeight will have some weird problems on the report formating if you have a complex report design.

An alternative to DynamicHeight is to calculate the Height of the ReportStringControl at your own and set the Height based on the string length of the content at run time. Use the heightOfWordWrappedString100mm() method to determine the height of words and set the Height based on this value. You could do this in the executeSection() of the SectionGroup, before the call to super().

Here is the example to do that:

public void executeSection()
{    
    ReportStringControl ctrl = this.control(fieldnum(PurchLine_1,DeliveryAddress));
    ;
    ctrl.height100mm(ctrl.heightOfWordWrappedString100mm(PurchLine_1.DeliveryAddress));
    super();
}