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
Showing posts with label V5. Show all posts
Showing posts with label V5. Show all posts
Monday, 16 March 2009
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
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
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.
-:
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
Sven
Wednesday, 26 March 2008
Dynamics 2009 First Impressions
I have managed to get hold of a TAP2 and TAP3 version of this software and wanted to give my first impressions of some of the new features.
Likes:
The Version control built into Ax
The workflow wizards in almost all modules
The Expense module (finally)
Dislikes:
The Site addition is not really well thought through as it adds another inventory dimension and the companies mostly needing this are heavy inventdim users so this will have a big performance impact on all inventory reporting
The new apparent sub menu in the display window
The new colours in the TAP3 version seem a bit well I hope they are not the final ones
More to come
Take Care
Sven
Likes:
The Version control built into Ax
The workflow wizards in almost all modules
The Expense module (finally)
Dislikes:
The Site addition is not really well thought through as it adds another inventory dimension and the companies mostly needing this are heavy inventdim users so this will have a big performance impact on all inventory reporting
The new apparent sub menu in the display window
The new colours in the TAP3 version seem a bit well I hope they are not the final ones
More to come
Take Care
Sven
Sunday, 16 March 2008
Performance and InventDim
I find that the impact of the datastructure choosen to implement Inventdimensions is too heavy performance wise and I would really like to see MS - Ax Team in the future revise this structure.
In the product developped before called XAL the inventory dimension fields were present in the tables concerned that is we had the Warehouse as a field on the equivalent to the SalesLine, CustInvoiceTrans, InventTrans etc etc.
Finally this approach allowed for really huge datastructures with simple index based group by type queries and simple index constructs. Compared to the forced joins we have in our current inventsum sphagetti code especially with the huge number of inventdim records when using Batch or Serial numbers.
What would I like to see :
1. Delete Inventdim as a table (whew what a performance boon that would be)
2. Create an Array field like the finance dimensions Called InventSKU with three fields Config, Size and Colour
3. Create an Array field InventStorage with three fields Warehouse, Location, Pallet
( add a fourth one called Site for version 5 compatibility )
4. Create an Array field InventCondition with three fields Batch, SerialNumber, and Condition
I only introduced one new field in the above as compared to V5 and two new fields V3 and V4 (V5 Adds one)
5. Add the above array fields to all tables containing inventdimID, I realise that this means 2 times the fields for the transfer table and will cause a lot of code changes :-)
However the performance improvement in large scale installations !!!!
Also the ease of adding new Inventory dimensions !!!!
The simplification of inventsum logic !!!!
Take Care
Sven
In the product developped before called XAL the inventory dimension fields were present in the tables concerned that is we had the Warehouse as a field on the equivalent to the SalesLine, CustInvoiceTrans, InventTrans etc etc.
Finally this approach allowed for really huge datastructures with simple index based group by type queries and simple index constructs. Compared to the forced joins we have in our current inventsum sphagetti code especially with the huge number of inventdim records when using Batch or Serial numbers.
What would I like to see :
1. Delete Inventdim as a table (whew what a performance boon that would be)
2. Create an Array field like the finance dimensions Called InventSKU with three fields Config, Size and Colour
3. Create an Array field InventStorage with three fields Warehouse, Location, Pallet
( add a fourth one called Site for version 5 compatibility )
4. Create an Array field InventCondition with three fields Batch, SerialNumber, and Condition
I only introduced one new field in the above as compared to V5 and two new fields V3 and V4 (V5 Adds one)
5. Add the above array fields to all tables containing inventdimID, I realise that this means 2 times the fields for the transfer table and will cause a lot of code changes :-)
However the performance improvement in large scale installations !!!!
Also the ease of adding new Inventory dimensions !!!!
The simplification of inventsum logic !!!!
Take Care
Sven
Sunday, 12 August 2007
Support Policy bugbear
Was just going through Customersource recently and found an article deatiling the new MS support policy for Ax V3 etc. I found it rather disconcerting, it seems the time frame given to support is now around 17-19 months, from official release of the previous SP.
Version Release date Support ends
Microsoft Dynamics AX 3.0 SP4 May 17th, 2005 April 10th, 2007
Microsoft Dynamics AX 3.0 SP5 February 28th, 2006 July 8th, 2008
Microsoft Dynamics AX 3.0 SP6 May 1st, 2007 January 13th, 2009
Rule is :
(Subsequent SP Release Date + 1 Year + 2nd Tuesday at start of next new quarter)
The issue is the time it takes for the customers to actually upgrade their versions is much longer than the interval between SP's and the issues caused by implementing the SP's sometimes outweigh the advantages gained. Especially as the SP's do not only contain corrections but also slip stream functionality releases, of course this is not the intention however MS should recognize reality in this regard.
The rule previously was that MS supported the versions 5 years from release date of the last SP. The latest policy change is obviously intended to incite customers to expedite their updates from V2.5, 3.0 to V4.
Unfortunately from my experience this process is far from being a shoo-in or in other words simple task, and will require the expenditure of a significant amount of time to effect for each of the companies that envisage this upgrade.
As the V4 upgrade did not contain a large number of functional changes, many customers will probably choose to wait for V4.1 or 4.5 now renamed V5.0 to do their upgrades as this is supposed to be the one containing a large number of functionality extensions.
In other words
V4 = Technical oriented upgrade ( new enforced AOS, AOT additions )
V5 = Functional oriented upgrade ( no new tech but lots of functionality (promised) )
V5 I have just been told may be delayed to sometime end 2008, probably even 2009.
Now many customers will be in a bind, pay the consultancy costs of doing an upgrade from V3 to V4 with no business justification based on features or wait for V5, but as a consequence live for som time outside of the support conditions recently imposed by Microsoft.
I believe it would be beneficial for MS to provide support for a longer period of time of the previous versions and service packs what do you think :-)
/Sven
Version Release date Support ends
Microsoft Dynamics AX 3.0 SP4 May 17th, 2005 April 10th, 2007
Microsoft Dynamics AX 3.0 SP5 February 28th, 2006 July 8th, 2008
Microsoft Dynamics AX 3.0 SP6 May 1st, 2007 January 13th, 2009
Rule is :
(Subsequent SP Release Date + 1 Year + 2nd Tuesday at start of next new quarter)
The issue is the time it takes for the customers to actually upgrade their versions is much longer than the interval between SP's and the issues caused by implementing the SP's sometimes outweigh the advantages gained. Especially as the SP's do not only contain corrections but also slip stream functionality releases, of course this is not the intention however MS should recognize reality in this regard.
The rule previously was that MS supported the versions 5 years from release date of the last SP. The latest policy change is obviously intended to incite customers to expedite their updates from V2.5, 3.0 to V4.
Unfortunately from my experience this process is far from being a shoo-in or in other words simple task, and will require the expenditure of a significant amount of time to effect for each of the companies that envisage this upgrade.
As the V4 upgrade did not contain a large number of functional changes, many customers will probably choose to wait for V4.1 or 4.5 now renamed V5.0 to do their upgrades as this is supposed to be the one containing a large number of functionality extensions.
In other words
V4 = Technical oriented upgrade ( new enforced AOS, AOT additions )
V5 = Functional oriented upgrade ( no new tech but lots of functionality (promised) )
V5 I have just been told may be delayed to sometime end 2008, probably even 2009.
Now many customers will be in a bind, pay the consultancy costs of doing an upgrade from V3 to V4 with no business justification based on features or wait for V5, but as a consequence live for som time outside of the support conditions recently imposed by Microsoft.
I believe it would be beneficial for MS to provide support for a longer period of time of the previous versions and service packs what do you think :-)
/Sven
Subscribe to:
Posts (Atom)