Friday, 13 March 2009

Dynamics Ax V5 - 2009 Upgrading - Bugs

I have been silent for a long time due mostly to being overworked, something I am sure we are all familiar with :-).

Anyhow I have just completed a process whereby we have migrated our current core application to Ax 2009, it was less of a positive experience than I had hoped.

During the upgrade touching the few objects that we had changed in our developments in Ax I noted some pretty silly little details and I also noted that one of my favourite performance bugbears which ostensibly had been fixed had not really been adressed.

I noted that during the upgrade process in the ReleaseUpdate Classes the old customer return codes are being mapped accross to a new table ReturnDispositionCode and in the process the return location is stripped from the data, and horror of horrors another method then simply deletes the information.

We would not have noted this if we hade not made a modification surrounding this process to allow us to add more handling around the returns process.

The funny part of all this is that the method allowing for a setting of the inventory dimensions based on the return code still exists.

I have nothing against the new returns functionality but I cannot accept a functional regression with no warning.

A further funny is the way this return functionality has been implemented it now creates shadow lines one or more which means if you had solutions relying on totalling the order lines you will be caught out by these new "hidden" lines.

As you know if you have read some of the earlier posts I am very concerned in general with performance in the solution as I believe this is not only an issue for large installations but also for all installations in general and in particular high volume ones.

I have touched on my metric as regards the summary tables LedgerBalancesTrans and LedgerBalancesDimTrans and the fact that in most cases these so called summary tables are not really a summary and therefore financial reporting is needlessly long.

In V3 and V4 the system creates upto 10 or upto 20 entries per day per dimension combination in V5 this has been reduced to one per day per dimension with a transient (or vector) one made temporarily during the update for each stream doing an update.

This off course reduces the number of transactions but not really that significantly by dimension, as in many of my real world cases the dimensions are strongly used and therefore there were not that many transactions for any one day & dimension combination. We have gone from 80% of transaction mass in the so called summary to 50-60% which in my book is still too much.

I hold out for having one transaction / account / dimension per financial period. This would really improve summary reporting performance.

Anyhow more about this and other V5-2009 matters later.

Take Care


Anonymous said...

Hi , really interesting details about the dimension combination causing many transaction records being updated on a regular basis , this concerns us also.

Was the combination from the number of levels you had from the dimension or the number of attributes you had linked to the dimension level , I would presume it would be the levels rather than dimension attributes. Maybe you could clarify for me, I hope I used the correct terminalolgy for this,



Sven Jochimsen said...

Hi the large number of LedgerBalanceDimTrans being generated is mostly due to there being 6 dimensions in our system. I have seen an implementation with 12 (needed to change some std indexes to make it work :-() where the numbers would be worse.
Basically take a sales order and add 50 lines to it have a dimension on the item with an item (worst case) or an item category dimension, which is a fairly common scenario now post the Sales Invoice and look at the number of ledgertrans generated worst case you have 3 * the number of lines in ledgertrans and of course depending upon what and how you post the other dimensions f.ex. one could be the customer then unless you do multiple sales of the same item same customer on the same day you have little or no overlap on the dimension combinations posted and therefore you have a large volume of ledgerbalancedimtrans anyhow enough said.
Hope you follow.