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

Sven

Performance Issues Resolution in Ax Part II

After finishing this work on Ax V4 Ax V2009 was rolled out and my work should really start over again.

However as I am lazy I will simply try to migrate the code and tell you more afterwards.

Noted some interesting changes in V5 as regards multi threaded execution of processes using the new batch service.

Will report back on this later in more detail.

/Sven

In search of Performance (Finance this Time)

I have not noticed when exactly the change was made but when posting to the LedgerBalanceTrans and LedgerBalanceDimTrans the date is no longer always the first or last day of a financial period it is the equivalent of the Transaction date. Validated from V3 onwards.

This has important performance impacts on reporting when you use financial dimensions actively.

Normally you would expect to see a factor of reduction in number of transactions going from LedgerTrans to LedgerBalanceTrans and DimTrans, in practical use I see that most of the implementations I visit the relationship is more like a 10% reduction in DimTrans and 20% in BalanceTrans which is not much and almost makes these tables almost redundant.

In any case the advantage in performance using these tables rather than the LedgerTrans directly for reporting is not very big.

An easy means of seeing whether you have this issue is to configure your chart of accounts to show the current balance, if the display is jerky and slow which is the case very often it means the level of summary provided by the LedgerBalance View on the LedgerBalanceTrans is not sufficient to allow for a speedy summary of the ledgerbalances to date.

Another is to review the number of rows you have in LedgerTrans and in LedgerBalanceTrans & DimTrans respectively if the later are much smaller the optimisation is functional in your case if not you will eventually have a slower system as regards reporting.

What I would suggest is to ensure that it is possible to have a level of consolidation in the Balances so that they are reasonably fast for reporting purposes of course this means that we will slow down posting slightly however I believe the gains in reporting justify the expenditure :-).


/Sven

Long Break

I have been busy with a few too many concurrent projects and have therefore been silent for a long time I hope to rectify this now as I am coming up for air again and have a lot of subjects that I wish to get back to / add to the list of subjects covered here.

Take Care
Sven

V4 Service pack 2

Just installed this on one of my installations and found much to my consternation that MS has continued to rename tables.

Even in Service Packs !

The Country as it was in V4 and SP1 is now AddressCountryRegion which is consistent with the rest however .....

Anyhow enough said I have not found any others, so far.

/Sven

Correction:
Palle commented that as far as he knew the Country had been renamed in V4, and he is right, what happened is that the upgrade process from V3 allowed the object to retain it's old name all the way through to SP2 but no further.

So what I thought was an SP2 issue was in fact an issue related to the upgrade process.

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

Performance issues resolution in Ax Part I

This is a subject on which a lot has been written by any number of people so I will concentrate on some small parts of the issues relating to this, and this is not meant as anything else but a starting point.

Mostly when you have problems in Ax, as in most other ERP systems :-), it is related to some sort of contention that is concurrent access to key central information, or alternatively to large quantities of data being used/created.

In most of the instances I have seen the quickest fix on SQL is always just adding more memory, not that I am a big advocate of throwing money at the problem but well that is normally the cheapest solution these days.

In SQL 2000 and 2005, the main issue is centered around one fact, lock escalation, basically your server can if it deems to be running out of memory decide to start locking not each row but a page (unit of storage used to contain multiple rows in the database) and even the whole table. When this happens you tend to get a situation where everyone is waiting for each other.

Picture Picadilly circus bus stop on a busy afternoon where you have lots of busses all coming in to pick up / drop off passengers and having to wait for each other and thereby causing havoc for other traffic, that is the best physical representation.

In Ax say the CustTrans table is concerned or InventTrans then as one process is using it another 5 different ones want to use it too, they cannot as the first is blocking and they use other tables which they then block for others thus making a traffic jam in the database.

SQL decides to do this lock escalation when it has used more than a certain percentage of the available memory that it has to manage locks, thus if you give it more memory to play with it is less likely to do lock escalation and therefore to create the traffic jam.

In SQL 2005 some new functionality has been added concerning Index Lock escalation, however this is hard to add in Ax as information on the indexes, as these are created by the syncronization engine. You would have to add the information by hand on each index :-( after creation and then redo this everytime Ax runs a syncronization.

Additionally as you can see in this KB where means of reducing the lock escalation are discussed it is possible to switch of using the startup flag -T1211 however the resulting error condition of it running out of memory is not pretty.

One option that seems intriguing is the option of making an incompatible higher level block

BEGIN TRAN
SELECT * FROM mytable (UPDLOCK, HOLDLOCK) WHERE 1=0
WAIT FOR DELAY '1:00:00'
COMMIT TRAN

in Ax the tables classically affected are a series of well known ones, the problem with the above in Ax (as well as most other ERP's) is that one hides others etc. If f.ex. you resolve your issues on CustTrans then perhaps CustTransOpen or CustSettlement becomes the problem etc etc so this is often not a solution that we can use to resolve our escalation issues, also unless we do the locking for the whole business day we do not handle all the cases :-(.

Changing our queries is the next possibility mentioned to create smaller transactions.

Well, that is something that is possible in a limited fashion, you will have to clarify functionally with the business whether they can accept the consequences, f.ex. not make sales orders with moe than xx lines in them. Not do recap invoicing, etc etc.

What you can do is use the system to help you detect where you have problems and also use the system to dissect exactly the problem is being originated from.

A number of tools are availeable to you, the main one which I recommend all Ax sysadmins to get familiar with is the SQL tab under the User Options of each User.

This provides an invaluable help in order to get information about what parts of your system are not performing as expected.

What I suggest all sysadmins to do is to as a minimum activate the SQL tracing set a threshold of perhaps 2000 (2 secs it is in milliseconds) and to store long queries and deadlocks in the Table (database).

This will store in the database (accessible under Administration/Inquiries/Database/SQL Trace log the detail of every time a query took more than 2 seconds to execute, including the complete call stack of the process when this happened. You can even jump directly to the offending code and view / edit it.

With a little reflection it is always possible to optimise such queries and to thus reduce your performance issues, it is just a question of thinking about it clearly.

In V4 a few impediments have been placed on your way to having this level of information you have to enable Client Tracing on the AOS instance otherwise the table will be empty as the process will not be called.

Also in V3 KR1+ you have an extended toolkit that you can install, after installing the KR which you should have acces to through customersource or partnersource this allows you to control in detail what is being tracked and also allows you to log blocking behaviour, any process waiting more than 3 seconds on another will automatically log the fact that it is being blocked and thus you can see the effect that the "picadilly peak hour jam" has had on your system.

The good thing about logs is you can be factual about the increase / resolutions that you apply to your system.

Unfortunately MS have not seen fit to extend the above tracing extension into V4 probably because it was a separate development path. I have I think now managed to migrate most of it onto a V4 SP1 based system, the only issue I have is with the blocking monitor, I need to work a little on the SQL side to find out what I need to do exactly in order for it to operate.

Once it is complete I will post it here for you.

Take Care
Sven

New Head of MBS Good or Bad ?

It seems MS keeps on killing off the MBS leaders, well not really killing off but they all seem to move on at a pace which is not conducive to trust in a business area where turnover is frowned upon.

Now we have Kiril Tatartinov as the new head of MBS.

He is to replace Satya Nadella who left in March 07.

Tami Reller was interim Manager, and is also leaving the MBS sphere, to take on new roles elswhere in MS.

Doug Burgum who was the manager for a long time left as recently as last year.

All in all a rather turbulent leadership of a division that now accounts for more than 1 Billion of Bill's yearly revenue.

Personally I have no truck with any of the above characters, the only issue I have is that it seems that MS has not really understood that they need to lead this thing, and that changing managers every 3-6 months is not a positive message to send.

I had hoped that Satya taking over was a sign of them wanting to go for the Dev environment type of tool, seeing as his background was solidly anchored in the Development tools team at MS.

However he / it was not given a chance to mature, and he was moved probably because the business did not show sufficient momentum or because he did not feel it was important enough for him.

I do not see Kiril as a strategic choice, I could be very wrong of course what do you think ?

I see him more as yet another stop gap solution for the role.

Why was Tami not given longer to try to perform ?

So is this the begining of the end ? Are MS looking to sell off the division ?

Some were already speculating when Satya was moved, have a look here at Josephs blog. (comments)

There are over 3000 people in the MBS division however, and some are well integrated into MS and cross pollination of job roles is something MS excels in (The average time in job is around 18 months :-) ). I think it very unlikely that they would sell.

Take Care
Sven

Refreshing screen info in V4

I have come accross a small change in behaviour from V3 to V4 which could potentially be rather adverse in its effects.

In V3 if you want to update a screen f.ex. and refresh it in a uniform manner then you called

element.lock()
/*
did all your manipulation of screen elements
called redraw or refresh (if you needed to re-read the data)
*/
and
called element.unlock()

The functions are still there but they currently seem to do nothing, I suspect it is related to MS teams taking over some of the screen painting functionality and they are probably using some other MSFT code package to update screen information. But this leaves me pretty much in limbo as I have to get the user to activate the scroll bar to change the screen elements as redraw seems to have been de-activated as well.

Anyone else noticed the above and more to the point has anyone found a workaround to this annoying little bug ?

I will share here if I find one, my google help engine has not worked :-), I have not seen it commented publicly anywhere yet. And on the MS help the only discussion thread I could find was from 2004 and a bit off topic.

Take Care
Sven

Dynamics AX Base Data Model Part II

I ended the previous message on this subject by discussing the inventdim and stating that the introduction of this element had caused quite a lot of heartache in many installations.

In the previous product (XAL) the fields constituting the stock keeping unit as well as the stocking dimensions were found in all the relevant tables, from the sales order lines through the invoice lines down to the inventory transactions themselves.

When Benny was designing the database for the new model some smart Db developer suggested normalising this structure by creating a reference to a new table that contained the information.

This would significantly reduce the amount of data stored in the database, as now the transaction files would only contain a reference id (inventdimid) rather than all the fields (ConfigurationId, SizeID, ColourId, etc). Another thing that this simplified was the ability to add more dimensions to the table seemingly effortlessly, or at least with minimal effort.

So now inventdimid was added to

InventSum (Summary Table containing sum of inventTrans for that dimension combination or inventdimId)

InventSumLogTTS (Used by MRP when doing reduced calculations and also by IMTS)

SalesLine (Sales order lines default values for InventDimId)

PurchLine (Purchase order lines default values for InventDimId)

CustConfirmTrans

CustPickingListTrans

CustPackingSlipTrans

CustInvoiceTrans (Sales order flow lines note could be different InventDimId’s attached to lines in inventTrans that are attached to each document line)

VendPurchOrderTrans

VendReceiptListTrans

VendPackingSlipTrans

VendInvoiceTrans (Similar to above flow except this time purchase related, again same comment applies that the InventdimID of the line could be different on the linked InventTrans)

InventTrans

Are some of the main tables containing our new InventDimId field, I have not mentioned the MRP, Warehouse management, project, requirement planning tables that also include it but you can easily add those your self if you wish.

Note some notable additions in V4

InventSumDelta
InventSumDeltaDim

And

InventSumDateTable
InventSumDateTrans

Because of the nature of inventory valuation reports and their dependence upon the data contained in the above and 2 further tables that are intrinsically linked to the valuation of stock

InventSettlement (Contains all the inventory re-evaluations that have been carried out against any given transaction)

InventTransPosting (Contains the accounts on which valuation and re-valuation has posted values pertaining to a given inventory transaction)

It is given the data structure necessary to create a report using InventTrans joined to Inventdim through the InventDimId joined to InventSettlements in best case and in worst case with a search on the settlements in order to populate a report with correct values.
And if the report is as of a date it is even worse as it has to then first look at inventsum, deduct the inventtrans and or invensettlements that it has done after the date, trusting the user to have carried them out correctly and then present the resulting information as it’s version of the truth.

The Select statement looks like some version of the below taken directly from some of the classes doing this:
select forceplaceholders sum(CostAmountPhysical) from inventTrans
where inventTrans.StatusReceipt == StatusReceipt::None &&
inventTrans.StatusIssue == StatusIssue::Deducted &&
inventTrans.ItemId == itemId
exists join inventTransPosting
where inventTrans.VoucherPhysical == inventTransPosting.Voucher &&
inventTrans.DatePhysical == inventTransPosting.TransDate &&
inventTrans.InventTransId == inventTransPosting.InventTransId &&
inventTransPosting.InventTransPostingType == InventTransPostingType::Physical &&
inventTransPosting.IsPosted == NoYes::Yes
#inventDimExistsJoin(inventTrans.InventDimId,inventDim,inventDimCriteria,inventDimParm);

postedPhysicalValue += inventTrans.CostAmountPhysical;

select forceplaceholders sum(CostAmountAdjustment) from inventSettlement
index hint ItemDateIdx
where inventSettlement.ItemId == itemId &&
inventSettlement.Cancelled == NoYes::No &&
inventSettlement.Posted == NoYes::Yes &&
inventSettlement.TransDate > perDate &&
inventSettlement.SettleModel == InventSettleModel::PhysicalValue
exists join inventTrans
index hint RecId
where inventTrans.RecId == inventSettlement.TransRecId &&
inventTrans.StatusIssue == StatusIssue::Deducted
#inventDimExistsJoin(inventTrans.InventDimId,inventDim2,inventDimCriteria,inventDimParm)
exists join inventTransPostingPhysical
index hint DateVoucherTransIdx
where inventTrans.VoucherPhysical == inventTransPostingPhysical.Voucher &&
inventTrans.DatePhysical == inventTransPostingPhysical.TransDate &&
inventTrans.InventTransId == inventTransPostingPhysical.InventTransId &&
inventTransPostingPhysical.InventTransPostingType == InventTransPostingType::Physical &&
inventTransPostingPhysical.IsPosted == NoYes::Yes;

postedPhysicalValue -= inventSettlement.CostAmountAdjustment;

Regardless of how much you may update / optimise your SQL server given that there are a large number of rows in InventTrans, double that in InventTransPosting and at least double that in InventSettlements (if using average costing) the above query is deadly for the database in terms of performance.

In order to counter this Benny has developed his fast reporting tool which you will find advertised on his web site, and MS have added the InventSumDateTable and the InventSumDateTrans tables which basically do the above queries but store the results in a table which is then consultable.

Unfortunately again the table does not contain a simple date rather they have chosen to have just a parmId reference stipulating the reference number of the calculation having been carried out, and then to use adjustments based on this so again if you want the values as of a date you are stuck doing a subsequent query to get back to a situation back in time.

Enough about InventDim & InventDimId.

InventSum as stated earlier contains a summary of the linked InventTransactions based on the InventdimID associated broken down by the StatusIssue and StatusReceipt fields the transaction is summarized in this table.

This action is carried out based on any change to the inventTrans table, that is the simple fact of doing an update or insert on a record in that table will automatically be reflected in the InventSum table, if it is an update 2 inventsum records could be affected (if the inventdimid changes).

The InventTransPosting table contains the Ledger accounts that have been impacted (posted on) during the update of either a physical transaction or a financial transaction. The reason for having this table is to allow subsequent revaluations of the inventory transactions to be posted in the GL using the same account numbers as the original transaction.

Example:
We introduce a new item in the catalogue, and purchase 100 pieces with an assumed price of 1 units / piece, we receive the items in stock and start selling the items.

When we have sold half the lot of 100 we receive the purchase invoice which is for 90 cents / piece only as we have already had COGS (Cost of Goods Sold) recognized as 50 * 1 unit or 50 Units on the total of 90 (90 cents * 100) there are only 40 units left to share on the remaining 50 units this makes the COGS / piece = 40/50 or 80 cents on the remaining 50 units.

To correct the above Ax has an inventory costing mechanism that allows the system to recalculate a more accurate valuation and correct the COGS of the already sold transactions.

The InventSettlement table will contain the corrections to the existing transactions which would deduct 10 cents / piece for the old invoices and add 10 cents to any new ones.In order to ensure the right accounts and financial dimensions are impacted the account numbers as well as the financial dimensions are stored in the InventTransPosting table.

Sound complicated well not really compared to others it is quite simple but meethinks I will continue later.

/Sven

New Fix distribution policy Horror from MS

Someone in their infinite wisdom in MS has decided that any fixes to the product Dynamics AX 4.00 SP1 onwards will be distributed in an aod file directly.

Why do I state that this is horrible ?

Well all fixes will be lumped into one DIS file and new versions will be sent out as new fixes are added, so now we have 4 SP and DIS version number questions that need to be answered by support.

When installing a new DIS to fix one small issue that perhaps necessitated a 2 line fix we are obliged in a user installation scenario to get everyone out recompile the whole application and also what is really the worst part of this decision, re-validate all process flows as we are implementing a patch not a fix, namely all of the code in the DIS file which might and will probably impact a number of other processes.

As those who have been around can testify one man's bug is another man's feature, I cannot cite any V4 examples yet as most of the bugs I have seen fixed are really bugs. However in V3 SP4 the code doing inventory reservations was "fixed" so that it always started reserving from the Warehouse / Pick Location rather than just Warehouse level as it did in earlier versions.

Of course if the Pick Location is present then it should try and reserve from there and not just pick any location in the warehouse, however I had several clients who had built code based on the premise that AX functioned as it did before the fix, subsequent to the SP implementation their code broke and reserved nothing threw spurious error messages etc etc.

What the above policy means is that all functionality that is important has to be tested every time a fix is implemented, in other words a fix has to be treated as if it was a SP.

This is not really a wise policy and I hope MS will reconsider and continue providing fixes as distinct XPO's with correct table, field, and object id's so that we can introduce these in the system with the least possible disruption.

Imagine:

The system is down because it calculates VAT incorrectly (see previous discussion) and we are waiting for a fix from MS, they find it and send us a 5 Mb aod file containing all the fixes. So now we have to do a weeks validation before being able to implement the fix to 2 scripts because all sorts of other scripts are "fixed" as well.

I can see that building all the fixes in one environment is easier for MS and allows the next SP to be constituted in an incremental fashion as it is the AOD file in question, however releasing this into nature just means we have lots of "SP's" being released all the time which is not very optimal for the reasons I state here.

Best Regards
Sven Jochimsen
.

Writing sustainable Code in AX Part I

I have long wanted to post something on this subject as it is the most often repeated question from customers.

There are two main schools of thought :

1. Do as little development as possible, and stick to the standard functionality.

2. Start adapting Dynamics Ax as needed.

The first options seems to be the most intuitively correct option, there is only one issue with this option, that is that Ax in it's standard inception is not well suited to almost any business that is contemplating implementing Ax.

I have participated in a large number of implementations of Ax and have only ever seen one succesfully toe the line, and that is the reference customer that Damgaard used to use in Denmark that is situated in very close proximity to the development center. Where the management had decided to follow the line in order to be beta customer all along the line, and have done so AFAIK to this day.

Aside from this one customer I have not met any that have really toed the line in this respect though most actually profess wanting to do so, but as the product is designed to be built on rather than be followed it is hard to do so.

If you want to use an analogy that is easy to understand both Dynamics Nav and Dynamics Ax are a bit like another famous Danish product which some of us have played with in our infancy, Lego. Both systems have been built to be modified, they provide the basic building blocks and trace a map of what the business processes could be like, a set of building instructions if you like and thereafter you are given the opportunity to adapt this map to your business.

If you take most other systems they are more built along the lines of a prefabricated model train track set, you can choose at each intersection which way to send the train but you cannot change easily where the interchanges are nor what they govern. I will name no names ;-). And if you want to change your track layout you have to start major civil works in order to adapt the wanted layout to the landscape, and in most cases that has consequences further down the line.

In my view after having worked with both Dynamics Ax, Dynamics Nav, XAL, and other predecessors for over 20 years, it is best not to do either.

Option 1 of doing no dev negates the competitive advantage provided by the fact of choosing a flexible ERP system designed to be flexible, option 2 of doing all kinds of development as required usually winds up in excessive upgrade costs.

The art of being a good implementer of this product lies then in balancing the two options just right in order to acheive an implementation that is as I called it in the title sustainable.

I have been trying to establish a set of guidelines in this regard the problem is of course that as with any good compromise it should be flexible and adapted to the situation.

As an example, in general terms it is not good to change the central data model in the application as those kind of changes may necessitate extensive work in the future during upgrades. However take the case of a medicinal company that needs extensive tracking and needs to use its inventory in a very specific sequence and to transfer Use by date information throughout. In their case not making changes to the central data model is stupid as the changes necessary can be handled much more easily by doing so than by not doing so.

There are off course many such examples, anyhow I have to get back to my day job I will detail more in my next posting on the subject. And look forward to any comments.


/Sven

V4 Second look

Now that the real V4 has come out, in the form of SP1 or 4.01 depending upon when you asked the question :-), what is it like ?

What has changed compared to the buggy version brought out in June ?

Well certainly most of the bugs that I have discussed here seem to have been dealt with but some have not and some new ones have appeared, in my estimation SP1 was rushed out the door. The proof of the pudding is often in the tasting as they say concerning food :-) in this case SP1 was supposed to have been release in early november for a limited number of countries and in early december for the rest.

In actual fact the november version was brought out on the 5 of december after a gargantuan effort by everyone to get most things ready, and thereafter on the 22 of december we got the rest. Not a huge delay by any means in software terms especially considering all the teams that had to co-ordinate and deliver in order to meet the deadlines that were originally set.

However the problem was and is that a large number of issues still exist even after the cutoff and as work was being carried out untill the cutoff date it is fairly obvious that there are and will be a large number of issues in what has been released, not on the tools side but on the functional side where there has not been enough time consecrated to tesing the application.

Hopefully we will see an SP2 in the plans soon in order to correct this, or alternatively the 4.1 release being brought forward.

On the technical side we have probably one of the best AOS implementations ever, fortunately as we now no longer have the option of not using the AOS. I have had the opportunity of testing with a farm of AOS servers and a large number of clients and in many instances even shutting down several AOS's many of the client sessions survived. Which given the parallel execution streams that are ongoing is pretty damn impressive, just as a reminder in version 3 and before if an AOS was taken off line all it's sessions died automatically.

On the dev side I have not really used the CLR functionality extensively yet but it looks good.

I will have to continue later, interrupted by an issue with KR2.

/Sven

Layers News

Well MS have recently announced that they are doing the country localisations in the GLS layer, so where does that leave things ?

I am sure that unless someone is very very carefull we will see some strange issues regarding field numbers, for those who know skip my explanation.

In Dynamics Ax all objects (Tables, Fields, Classes, Methods, Reports etc) aside from their names receive a number which is used to reference them in the code, the P Code or run time code that the Ax compiler creates uses the numbers to reference items not the name as this would take up to much space and would also significantly slow down execution.

The numbers in question are alloted based on the layer in which the elements are created, that is 0 upwards is SYS etc, what will now happen with elements that have been migrated from the old setup where the SYS code was in SYS, GLS, LOS and DIS to no being only in SYS and GLS. One can only hope that they have kept the numbers from Verson 3 when building but also we could have phantom numbers apppearing because of certain localisations having been present when add-ons or code was made and now thos numbers could be re-used by other code.

Fortunately the compiler is pretty good at at least enforcing type casting, but well this could be an interesting issue to follow in the future.

/Sven

Layers in Dynamics Ax

The manner in which layers were used in the old Ax was pretty clear, we had

SYS, SYP Used by the core system
GLS, GLP Used by the initial added modules which were bought in ( CRM from Hands Norway, Product builder from Aston (now Tectura) HRM from Circle Capital, Shop Floor from Thy Data Center ).
LOS, LOP Used by some countries to add functionality ( US EDI connector, Germany Cost Accounting from Circon )
DIS, DIP Used by most countries for localisation
BUS,BUP Used initially by partners freely then only by invitation in an early version of IBI (Industry Builder Initiative)
VAR,VAP Used by the partners to put their code in
CUS,CUP Reserved for the customer
USR,USP Reserved for the customers

Today in V4, the first 4 are all now in SYS and I am told discussions are ongoing right now as we speak as to where to put what as regards corrections.
I would say do not be greedy:
You have freed up 3 Layers
How about designating one GLS GLP as still for internal use
and freeing UP LOS LOP for IBI use
Leaving DIS DIP empty (replace it later to add another level of user layer )

Give back both BUS and VAR to the dealers freely as it was in 2.5 and V3 initially.

And in a future version give the freed layer to the customers who also need in many cases another layer for their use.

Be a great X-Mas present a clear IBI Layer and an added Dealer layer as well as an added Customer layer

Of course it will not be easy to move things around, as the whole object numbering scheme depends upon this and moving them around is not that easy.
Renumbering the objects has some dreadfull consequences all sorts of places, as those who forgot to export with numbers from their dev system have found out to their cost :-).

But hey the clean up has given the opportunity, and I always though Erik Damgaard when he designed it was being greedy taking 4 of the layers for the systems out of the 8 available ( not counting the patch layers ).

So rebalancing is now a possibility, perhaps.


/Sven

The concept of Warehouse and extensions

In Dynamics Ax two inventory dimensions which in most other cases are more or less similair stand out a bit or rather stick out like a sore thumb.

One is the warehouse, it has attached to it a lot of functionality, such as quarantine handling or the Warehouse management functionality plus some other basic hookups such as the ability to define a default warehouse by item on Sales / Item / Purchase levels.
However because the warehouse is often confused between a logical warehouse and a physical warehouse and in implementations one often makes use of one or the other and has to stick them both into one field it sometimes becomes difficult to visualise and control ones stock.

What would be nice is to have a sort of sub warehouse level which could be configured everywhere as well as the warehouse, the sub warehouse could be the logical warehouse and should be uniquely linked to its parent which should map to the physical warehouse.

What I am speaking of is sort of like the physical stock locations used in the warehouse module except they should be independent of the locations. The sub warehouse should be availeable all the places where today only the warehouse is present, that is in BOMS in the Quarantine flow, in the SO PO etc etc etc. This allows it to be used as a logical warehouse so that one can have non QC stock and it can still be in the physical warehouse in physical Location but have a statust that disallows it's use.

The reason for adding the sub warehouse or logical warehouse everywhere is to allow the users / dealers to configure legal flows.

One could debate whether it should act as a flag that is we need a new transaction type to control the transfer of it from one status to another (one sub warehouse to another) that does not generate a new inventory transaction or whether a transfer should be required. In an ideal world both should be possible as many businesses would prefer the ability to just change the flage where as audited companies such as medecinal / pharamaceutical companies will want a full track and accounting for any changes made.

I have made such changes but only partially, I have also seen many half botched attempts at making such changes, and I would love to see something like this added as a part of the standard package to allow the product to contain such functionality out of the box.

It would support most industries and allow a much more logical configuration of the system, where the warehouse is really a warehouse and not some beast with many names as is often the case on implementations today.

/Sven

Dynamics Ax Base Data model Part I

I often get asked by customers for a basic data model of the Dynamics Ax system and I always have to answer a bit shamefacedly that it does not as of yet exist.

But then I manage to show the Visual Morphx explorer or the Visio tool in version 4 and explain that with 1,500+ tables a chart would not be a chart but a panoramic wall chart requiring the deforestation of Finland to create.

Nevertheless it is instructive when getting introduced to Ax to start by considering some basic elements of the data model.

Before starting one should consider that Ax is a fully integrated ERP system, that is transactions actually cross module boundaries. This implies that the data-model very quickly grows quite complicated, or rather perhaps rather than saying complicated I should say it is quickly heavily populated with tables.

As with most ERP’s one can view Dynamics Ax as being about controlling the flow of goods through the company, the stock control view or approach, or one can view the product as being about controlling the financial information in the company, the nominal/general ledger view or approach.

In my book both are correct, sooner or later most of the modules in Ax will have an effect on the inventory, and or the ledgers.

So let us take a look at the basic data-model surrounding these modules :

I choose to take the more complicated inventory model first J

The main table here is the InventTable which contains the basic information about products in Ax and which notably of course contains the ItemId field which is the identifier by which the product is known.

The list of items controlled in a company when presented to a user also includes 3 instances of a table called InventTableModule all linked through the ItemId to InventTable, and at least one instance of InventItemLocation.

Why are the above elements stored in separate tables ?

In order to allow more flexibility as to configuring in multi company scenarios where the information concerned is held, F’ex the default warehouse for inflow, outflow, and stocking is held in the InventTableModule, this allows us to configure the system in such a manner that 2 or more companies can share the InventTable whilst at the same time having separate configurations of default warehouses, tax codes, unit sizes etc all of which are found in the InventTableModule.

InventItemLocation is another story as it has been split in order to accommodate being able to based on a users configuration needs have different stock flows in the replenishment planning area or net requirement calculation. Of course this also means that we can have a different setup in a multi company situation as well.

Enough about the base table to which everything is tied there are a large number of further tables to explore in this area to do with the configuration of the behaviour of the item but we will get back to that later.

Let us look at the basic transactional model as regards inventory, the information about stock inflows and outflows in Ax are stored in a table called InventTrans, this table contains some key fields, the first basic one is the ItemId field of course which ties the transactions to an item ;-).

Thereafter not in order of importance the InventTransId or what one could call the internal lot number, which identifies the source of this / these transactions as the model permits the existence of multiple InventTrans with a common InventTransId.

Then the StatusInflow, and StatusOutflow fields which are used to identify that the transaction is an inflow or outflow transaction and to state at what stage the transaction is currently, that is if f’ex StatusInflow is 1 (Purchased) it means this item is considered as a fully purchased or costed inflow depending upon it’s provenance, if it is 2 it means it has been delivered but not invoice updated.

The model so far is exactly the same as the one that Concorde XAL had which was created by mostly Benny Olesen who is linked / referenced on the side together with Bjorn Moeller Pedersen, Erik Damgaard, Jesper Theil Hansen and the rest of the core developers at the time.

The next key field is new / a departure from the XAL model, it is the inventdimid field which contains a reference to a combination of inventory dimension fields ( The Warehouse, Lot number of an item as well as it's configurationId ). This Innovation in the data model does make it easier to add new / more dimension fields however it also renders all direct lookups impossible and with heavy data traffic in the inventory transactions renders the system hard to use.

I will carry on from here later as I have been busy these last few days.

/Sven

The Dynamics Product Range PIII

I ended my previous post on this subject by reviewing several facts, basically Ax has had one new version in 4 years under MS, Nav has had 4 new versions, GP has had 3 new versions.

Inspite of the above facts I concluded that MS had two options as regards choice of "The" product with which to replace the others, one is "Green" the other is Ax.

Let me explain my reasoning for this.

MS have a general policy of moving everything to .NET, imminently we will have .NET3 or formerly WinFX, I will not comment that here as others have already done so on the web just do a search on the subject in your favourite search tool.

The language in which you develop in Navision C/AL is a 4GL giving very compact code, but also it is very hard to see how you could translate it too C#.
Dexterity the language you develop GP in is closer to C++ but still it is unwieldy http://msdn2.microsoft.com/en-us/library/ms994230.aspx#mbs_gpdevtools_dexterity, take a look for yourself on MSDN.

From a pure elegance point of view Ax to me is the closest thing MS has today in it's arsenal to a C# language with an ERP solution built in. That does not mean that I believe that this will necessarily be the platform / solution that is necessarily chosen for the future, but I believe it is the one that comes the closest to being it.

If I were a customer today and I had to plunk down real money on a project that I knew was going to be for a life expectancy of at least 10 years, I believe that buying Ax will give me the smallest ongoing costs over any of the other Dynamics products.

Unless of course I would be willing not to follow MS and upgrade my platform when the time comes and MS gives us "The Dynamics product".

There are as always caveats in the above, because Ax is not globally distributed to the same level (there are markets with no or few experienced partners), because the pricing remains a sore point, because overall Ax has the smallest installed base (the latest sales pitch I saw from MS states 6,500 Ax, 45,000 Nav, and 60,000 GP). You may reconsider or consider otherwise, and of course given that MS want to carry on selling all products in the interim they will never state the above, let alone confirm it.

All MS statements in this regard carry what I would call marketing language, stating we will build a new product that envelops all the existing products. Now from a marketing standpoint I can see that is a desirable goal, but how from concrete standpoint are you going to merge code unit 13 from Nav with the SalesFormLetter_Invoice class from Ax, and whatever the equivalent is in GP / Dexterity.

Further to this once MS have managed this internally, how about the dealer channel and the users, bringing everyone on to the next platform is going to be one gigantic challenge, and the real challenge facing MS with these purchases.

It is sometimes instructive to look back at history / current events elsewhere. Oracle has made similar big bets on purchasing other products. Initially there were combative words from Oracle itself stating the customers would be given incentives to move and the existing platforms would be encouraged to die.

Very soon after these initial scary announcements that SAP, Lawson and others were not tardy in reacting to the above announcement by offering competitive upgrades in order to lock down the customers, and using the confusion generated by the initial Oracle pronouncements about support and the future to gain marketshare.

Oracle very quickly changed the above and adopted what to me is a mirror image of MS's policy statements, stipulating continued development through at least 2013 etc etc. Funny as I repeat myself in stating that they chose exactly this date ;-).

However inspite of the above in the 2 years following the purchase (done in dec 2004) my echos from colleagues in the industry is that the Peoplesoft and JD Edwards consultants are fleeing, at least in the country offices in Europe. Cannot speak for the US market as I am not active in it. Microsoft seems to be of the same opinion as they have in this time frame come out with specialised training programmes that are designed to cross train consultants specifically from these products onto Ax.

Being an Ax expert right now is a golden time frame to be one, however I believe that MS is going to change many things in the product over the next few years. V4 is only a beginning, no more 2 tier clients, enforced link to an AD server, much improved AOS, etc. And as an Ax person you have to be awake and follow these things closely, also of course you have to be willing to jump ship accross to "Green" when and if it is wheeled out the advantage will be yours.

/Sven

Dev for localization and International projects

Just to conlude as I have been guilty of not being completely clear about what the rules were that we worked out with the clients in question.

They are as follows, all localisation as well as any additional functionality added for one or more countries have to adhere to them in the customer implementation.

1. All code added to be rendered contralable through added parameters in the corresponding parameter table to the module concerned.

2. All parameters that are added have to be associated with either a security key or a feature key. Typically localisation parameters are on a feature key and others on a security key.

This is used to group functionality in logical parts especially where functionality covers several modules in the system, and also of course to partition country functionality.

3. All parameters are always simple yes / no enums or booleans where the value 0 or no is always the equivalent of switching off the functionality.

This ensures that if a country has no need for a particular module and switches off in the security / rights module the access to changing the parameters, they are always default off.


In a multi country scenario given the above we can do as follows :

Switch on all the countries involved in our implementation, and for each domain (company) switch off through security setup the access to any countries localisation thus switching the code associated off.

Of course strictly speaking the customer I spoke off does not need to do the work quite so stringently as they only have one database and they control what bits of localisation are implemented in their code. But just in case they ever decide f'ex to create a company in south east asia, in order to remain on the same code base they preferred to go through the process completely and follow the rules as laid out throughout.

So hopefully Microsoft will implement similar rules in their localisation work in order that the quality of the product we get out to work with is ameliorated.

/Sven

Dev for Localization Cost of dev

In my previous posting I posted that I believed that MS should introduce a new approach as regards all localisation developpment efforts.

Max Belugin (a co blogger whose blog you can find in the links as well as the man behind a highly recommended tabax as well as featuring prominently on the axaptapedia site and running the russian Erpkb.com) was so kind as to respond by asking what I believe the overhead would be for MS to introduce this as a general rule in all GDL work.

My reply was rather direct and immediate, why because 4 years ago I advised a company about this exact same issue, it was not really about GDL work but rather, they wanted to do a phased implementation through several european countries and they wanted a centralised solution :-).

What I in fact winded up advising them to do was to identify each localisation development that they needed from each country, and re-package the developpment by creating parameters around it.

This costs them a lot of time each time a SP is released as they have to go back and look again at each localization just to ensure that there are no bug fixes that they need.

However they have an implemention covering the three scandinavian countries, France, Italy, Spain, Czech Rep, Poland, and the UK all on one DB.
Not a huge installation in number of users but it works and is a good example of what would be possible with less cost if MS did the work to begin with.

In their estimation based on metrics from the other work that this customer has done ( all their own development also adheres to the rule of being switchable) the dev time is upped by about 15% and the testing time is doubled. These are average figures from about 4 years experience all on V3 platform so far no V4 experience though I believe the metrics will hold true as not a lot has changed.

The fact that the testing time is doubled is logical and important as it is important to ensure the software works without as well as with the functionality enabled.

However I contend that the fact that the above is not done by MS is costing partners and customers, more than the time MS would spend on the issue and as there are maybe 300 international deals (1 out of 20 ? based on 6000 sold licenses) the above means that the dealers or the customers are spending in effect more than 300 times the effort that MS would spend. Think of the lost potential new revenue ;-) this is one for Flemming's new group that is seeking to improve partner productivity. ( My estimation of international deals being one in 20 is perhaps too high hard to tell without more info however I believe that it should be in that region more consistently if MS supported it better :-) )

Up for discussion, what do you think ?

/Sven