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
Sven

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
Sven