Monday, 16 March 2009

Convergence 2009 - New Orleans

Convergence just finished, yes I go to this Ax reunion rather than the Partner one now as I am officially on the customer side of the fence now.

I noted a few presentations I found of interest notably one on my old bugbear performance issues, and the advice given I can only subscribe too, I just wish that they would consider doing some violence to the functional data model in order to enhance performance.

Specifically around inventdim which with the advent of the site in it has only grown as a performance issue, and the ledgerbalancetrans /dimtrans processing.

Another general matter is to review increasing performance by creating more and better history clean-up processes.

Today we have some processes to clean up the sales and purchase update histories, some concatenation of the inventsettlements and deletion of reversals. We could do more by providing deletion or archiving of the order tables (great for SO and PO performance) review getting rid of non critical journals (confirmations Picks and Packs).

Of course eventually we will have an archiving tool built in (promised for V6) and we will in september have one for all existing versions from V3 onwards, I somehow would not use the archival tools, unless forced too, before they are part of the standard Ax Code as only then can I tinker with it to make it work for me. From experience this is always needed to some extent with any new function made in Ax :-).

Anyhow will give links and more information later when I have more time to report on what I have gleaned from going through the convergence presentations.

Best Regards

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

Saturday, 28 February 2009

Upgrading to the Next Version of Dynamics Ax

We are all faced with doing an upgrade to the next version of Ax and when faced with this we have to review all of the customizations having been done to upgrade / change / remove them depending upon their relevance.

This part of an upgrade project can from experience take between 10% of initial development effort all the way up to and including 100%+ of the initial dev effort depending upon what and how modifications were done.

The 100%+ example list of do not do's are :


Changes to std BaseEnums sequence and related code, f.ex. I had a customer / consultant precede me on a case where they decided it would be a good idea to change the salesorder type enumerated type and add some new types in the middle of the list :-(. Upgrading this was an unnecessarily big job if they had just created them at the end with a big gap in the enum it would have been much less of an issue anyhow.


Duplication of classes and calling these duplicated classes instead of the standard class, the problem here is that the layers mechanism of resolving / helping upgrade is negated and one is forced to export the class and do a manual external comparison.


Writing code in unusual places, that is in screen buttons, on the datasource of screens, in the datasource fields on screens.


Changing the standard data structure relationships in data as well as classes.

Partial list ends here TBC

Take Care