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
.
Thursday, 12 April 2007
Wednesday, 14 March 2007
Upgrading from V3 to V4 P3
Well here we go I carry on my run through of some of the obstacles I have faced in upgrading from V3 to V4.
The CreateLine function on the SalesLine Table has an added parameter that controls credit checking behaviour, incosiderately MS have choosen to add the new parameter before the last parameter which is a string. This means that even though it is defaulted if you are using that last parameter your code fails because of type checking.
They should really think before acting !
Hopefully for the future they will not in version 4.1 4.5 5.0 repeat some of these rather cavalier changes all over the place.
What's with the changing of all the tab page elements in all forms to be named Tab, do they not realise what pain they cause for any changed forms, you cannot just migrate you practically have to hand code / port the changes.
And making what I would call gratuitous changes to the names of Tabs inside a form is just silly, why do you need to rename a Tab from NotificationToCentralBank to NotificationToTheCentralBank example taken from the CustTable form.
Anyhow making long names in Ax is sometimes counterproductive as only a certain number of characters are used to distinguish elements so it can actually be dangerous unless V4 is improved in this area.
But in any case such changes are silly and add nothing to the value of the product.
To be continued
/Sven
The CreateLine function on the SalesLine Table has an added parameter that controls credit checking behaviour, incosiderately MS have choosen to add the new parameter before the last parameter which is a string. This means that even though it is defaulted if you are using that last parameter your code fails because of type checking.
They should really think before acting !
Hopefully for the future they will not in version 4.1 4.5 5.0 repeat some of these rather cavalier changes all over the place.
What's with the changing of all the tab page elements in all forms to be named Tab, do they not realise what pain they cause for any changed forms, you cannot just migrate you practically have to hand code / port the changes.
And making what I would call gratuitous changes to the names of Tabs inside a form is just silly, why do you need to rename a Tab from NotificationToCentralBank to NotificationToTheCentralBank example taken from the CustTable form.
Anyhow making long names in Ax is sometimes counterproductive as only a certain number of characters are used to distinguish elements so it can actually be dangerous unless V4 is improved in this area.
But in any case such changes are silly and add nothing to the value of the product.
To be continued
/Sven
Tuesday, 13 March 2007
Upgrading from V3 to V4 P2
As stated in the earlier posting here is the continuation of my meanderings through the process of upgrading Dynamics Ax V3 code to V4.
Several tables have been renamed completely unexpectedly.
I have not found them all mind you just the ones that were used by the code I had the pleasure to upgrade.
The SmmQuotation tables have been renamed SalesQuotationTable which is what everyone knows from the whats new.
What I had no inkling of is that SalesPickingListJournalTable had been renamed to InventPickingListJournalTable likewise the lines and the form that is attached to the lines etc etc. As I had code that was dependent upon this and the code was not being imported it did not switch over to the new naming convention so I had a field day finding everything ;-).
A lot of screens will keel over as MS has had a field day renaming functions all over the place, albeit to more logical names but they should know that doing this is not with out consequences
F'ex the Function EmptyAddressField in the AdressMap which clears the data in the adress fields of any entity with adress fields attached is now called clearAddressField, which is more logical than the old naming convention but it does force you to revisit any code you built around this.
The TmpSalesLine table used by the old Address screen has been renamed to the SalesCreateReleaseOrderLineTmp table however the TmpPurchLine retains its old name, go figure on that one ?
I will continue as I go adding more
Best Regards
Sven
Several tables have been renamed completely unexpectedly.
I have not found them all mind you just the ones that were used by the code I had the pleasure to upgrade.
The SmmQuotation tables have been renamed SalesQuotationTable which is what everyone knows from the whats new.
What I had no inkling of is that SalesPickingListJournalTable had been renamed to InventPickingListJournalTable likewise the lines and the form that is attached to the lines etc etc. As I had code that was dependent upon this and the code was not being imported it did not switch over to the new naming convention so I had a field day finding everything ;-).
A lot of screens will keel over as MS has had a field day renaming functions all over the place, albeit to more logical names but they should know that doing this is not with out consequences
F'ex the Function EmptyAddressField in the AdressMap which clears the data in the adress fields of any entity with adress fields attached is now called clearAddressField, which is more logical than the old naming convention but it does force you to revisit any code you built around this.
The TmpSalesLine table used by the old Address screen has been renamed to the SalesCreateReleaseOrderLineTmp table however the TmpPurchLine retains its old name, go figure on that one ?
I will continue as I go adding more
Best Regards
Sven
Sunday, 11 March 2007
Upgrading from V3 to V4 P1
I have recently been involved in some upgrade projects from V3 to V4 and frankly I am a bit put off by the degree of cavalier change that has been done in the App in V4.
As an example I intend to go through some of the changes and evaluate them as being either positive or negative and also to discuss a little how you can get around them.
As discussed earlier in V4 MS has reduced the usage of layers, put in another fashion they have actually cleaned out the GLS, LOS and DIS layers and put all the code contained here into SYS.
That in itself is not really too much of an issue however they have also in their infinite wisdom decided that they will at the same time renumber the objects that have been moved to give them a SYS id number.
If you do not know what the numbers are or how they relate to layers please read either http://dynamicsmatters.blogspot.com/2007/01/layers-news.html or other related resources to get more information.
Obviously the fact of renumbering creates all the issues that I pointed to in that previous short article, if you have code that you bring accross in layers (that is pre compiled) you may very easily be subjected to crashes and compile errors that are strange, such as duplicate fields with different ID's.
I have so far been able by deleting each of these fields (and re-booting as the AOS server crashes when you do so) individually to clean up the code as regards these fields, however there are a number of EDT's that had previously been named slightly erroneously or that could cause confusion that have been renamed.
An example is the Country EDT which is now called CountryRegionId, there are quite a number of these renames and if you combine the field duplication with a rename you wind up having a table with the country code and the countryregionid code perfectly legal with each their ID's but very confused data.
Anyhow I intend to do a series of articles about each of the issues I find and to propose a possible solution for each.
So for the fields you need to compile globally the database and then prepare to restart the AOS the number of times you have the issue of duplicate fields as the deletion of the field will cause an error message :-).
For the Country -> CountryRegionId you need to go through all of the (typically DB trigger code) code where this is used and change the field being referenced to the new field. As for any fields that you may have created in your own extensions of the system up to you: If you rename you are being consistent with the new naming scheme of MS however you will have to add a data manipulation step to the upgrade programs in order to move the data from the old column to the new one.
If you do not change the name then you do not have to move the data however you are not compliant with the new MS ax definitions.
To be continued in a very long series :-(
/Sven
As an example I intend to go through some of the changes and evaluate them as being either positive or negative and also to discuss a little how you can get around them.
As discussed earlier in V4 MS has reduced the usage of layers, put in another fashion they have actually cleaned out the GLS, LOS and DIS layers and put all the code contained here into SYS.
That in itself is not really too much of an issue however they have also in their infinite wisdom decided that they will at the same time renumber the objects that have been moved to give them a SYS id number.
If you do not know what the numbers are or how they relate to layers please read either http://dynamicsmatters.blogspot.com/2007/01/layers-news.html or other related resources to get more information.
Obviously the fact of renumbering creates all the issues that I pointed to in that previous short article, if you have code that you bring accross in layers (that is pre compiled) you may very easily be subjected to crashes and compile errors that are strange, such as duplicate fields with different ID's.
I have so far been able by deleting each of these fields (and re-booting as the AOS server crashes when you do so) individually to clean up the code as regards these fields, however there are a number of EDT's that had previously been named slightly erroneously or that could cause confusion that have been renamed.
An example is the Country EDT which is now called CountryRegionId, there are quite a number of these renames and if you combine the field duplication with a rename you wind up having a table with the country code and the countryregionid code perfectly legal with each their ID's but very confused data.
Anyhow I intend to do a series of articles about each of the issues I find and to propose a possible solution for each.
So for the fields you need to compile globally the database and then prepare to restart the AOS the number of times you have the issue of duplicate fields as the deletion of the field will cause an error message :-).
For the Country -> CountryRegionId you need to go through all of the (typically DB trigger code) code where this is used and change the field being referenced to the new field. As for any fields that you may have created in your own extensions of the system up to you: If you rename you are being consistent with the new naming scheme of MS however you will have to add a data manipulation step to the upgrade programs in order to move the data from the old column to the new one.
If you do not change the name then you do not have to move the data however you are not compliant with the new MS ax definitions.
To be continued in a very long series :-(
/Sven
Friday, 26 January 2007
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
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
Sunday, 21 January 2007
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
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
Saturday, 20 January 2007
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
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
Saturday, 23 December 2006
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
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
Friday, 22 December 2006
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
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
Friday, 15 December 2006
Back order treatment
Back orders in Dynamics Ax, and their treatment leaves a lot to be desired, basically the most advanced functionality availeable is to allow good to be reserved before arrival in order that the system automatically places a physical reservation against the stock that has arrived when it arrives.
There is nothing intelligent to allow the treatment of a complete shipment of goods that is arriving to see which orders could best be fulfilled from the newly arrived shipment, there is even no function to allow one to automatically plan some shipment actions aside from the above mentioned one.
What would I propose is needed, well basically a linkup with the proposed allocation system that I have discussed earlier where it would be possible to allocate whole sales orders and treat them as units, that is reserve all the items or none. Conversely I see the need to be able to take whole purchase orders or even multiple purchase orders treat them, that is recieve the goods count QC check etc then when a pool has reached a certain size to allow allocation to happen against the pool.
Of course by judicious usage of a dedicated warehouse and Ax transfer functionality one could argue that one could acheive something along these lines. However the inconvenient thing is that one would have to create several new warehouses and the consequences of having stock in several "virtual" warehouses and also leaving traces everywhere is that not only is it harder to visualize where your stock at any one time is but also it is creating a trail of new inventsum records which means all stock and inventory checking reports become slower etc etc.
It would not be complicated to add some more stati in the inventory model and conversely to add some more inventmovement steps that could be configured, actually both on the incoming side as well as the outgoing side this could be of interest.
And these could then be configured by the user to be skipped or they could represent QC steps and or allocating, free for allocation steps.
It would cost very little to maintain if done by MS centrally rather than having to be added by a dealer or a customer.
What do you think.
/Sven
There is nothing intelligent to allow the treatment of a complete shipment of goods that is arriving to see which orders could best be fulfilled from the newly arrived shipment, there is even no function to allow one to automatically plan some shipment actions aside from the above mentioned one.
What would I propose is needed, well basically a linkup with the proposed allocation system that I have discussed earlier where it would be possible to allocate whole sales orders and treat them as units, that is reserve all the items or none. Conversely I see the need to be able to take whole purchase orders or even multiple purchase orders treat them, that is recieve the goods count QC check etc then when a pool has reached a certain size to allow allocation to happen against the pool.
Of course by judicious usage of a dedicated warehouse and Ax transfer functionality one could argue that one could acheive something along these lines. However the inconvenient thing is that one would have to create several new warehouses and the consequences of having stock in several "virtual" warehouses and also leaving traces everywhere is that not only is it harder to visualize where your stock at any one time is but also it is creating a trail of new inventsum records which means all stock and inventory checking reports become slower etc etc.
It would not be complicated to add some more stati in the inventory model and conversely to add some more inventmovement steps that could be configured, actually both on the incoming side as well as the outgoing side this could be of interest.
And these could then be configured by the user to be skipped or they could represent QC steps and or allocating, free for allocation steps.
It would cost very little to maintain if done by MS centrally rather than having to be added by a dealer or a customer.
What do you think.
/Sven
Tuesday, 5 December 2006
Product and other hierarchies
One of the things that most customers wish for when confronted with the reality of the datamodel in Dynamics Ax is some means of attaching meaningfull default values at various levels of a hierarchy to which they attach information.
An example could be the wish to dictate that a certain field f'ex the item group is set to a certain value for all items that belong to the category Oranges, as well as being sold in Belgium.
It is not easy to do in the standard Ax structures, what would be nice is a standard hierarchy builder type of feature as that found in f'ex the Demand planner add on where you are able to conceive your own hierarchy on top of any existing field in the system and for Ax basically to recognize the relationship so that reporting and other features could be built using this variable hierarchy.
Thereafter the next step would be to give the hierarchies an active role in the product, that is to allow the definition of certain fields to be tied to a hierarchy structure.
F'ex to say that the item group is deduced from somewhere in a given hierarchy meaning we can setup a default group at high level and then down the branches define exceptions, allowing the user to work top down and do less work and the system to work bottom up in order to use the first value found.
If we applied this principle to the groups used in the pricing matrix then we could really make some neat price matrices with pricing, discounts, etc at all sorts of levels.
What do you think ?
/Sven
An example could be the wish to dictate that a certain field f'ex the item group is set to a certain value for all items that belong to the category Oranges, as well as being sold in Belgium.
It is not easy to do in the standard Ax structures, what would be nice is a standard hierarchy builder type of feature as that found in f'ex the Demand planner add on where you are able to conceive your own hierarchy on top of any existing field in the system and for Ax basically to recognize the relationship so that reporting and other features could be built using this variable hierarchy.
Thereafter the next step would be to give the hierarchies an active role in the product, that is to allow the definition of certain fields to be tied to a hierarchy structure.
F'ex to say that the item group is deduced from somewhere in a given hierarchy meaning we can setup a default group at high level and then down the branches define exceptions, allowing the user to work top down and do less work and the system to work bottom up in order to use the first value found.
If we applied this principle to the groups used in the pricing matrix then we could really make some neat price matrices with pricing, discounts, etc at all sorts of levels.
What do you think ?
/Sven
Monday, 4 December 2006
Busy
I am currently working myself into a new job and obviously as with all new beginnings there is a period when you are required more than 150% of the time by your current job and I am therefore finding it less easy to work on the blog expect me back in usual frequence next month, right now I am working up a back log of subjects that I want to address.
If you have any subjects that you find are of interest then please feel free to suggest or even if you wish to add a topic contact me and I will add your blog as a feed here if you wish.
/Sven
If you have any subjects that you find are of interest then please feel free to suggest or even if you wish to add a topic contact me and I will add your blog as a feed here if you wish.
/Sven
Saturday, 2 December 2006
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
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
Wednesday, 29 November 2006
Special pricing 2 for one buy any three etc Points
The pricing mechanism in Dynamics Ax, which was inovative when it was introduced in Concorde, the ancestor of the ancestor of Dynamics Ax, now seems rather dated.
As a minimum what is needed in the Ax model is to remove the groups from being directly attached to the product and customer units, as well as opening up for the ability to create prices in one go for more than one product.
But really what needs to be done is to revisit the model completely and add:
Price groupings
- Similar to kit pricing ability
Buy Set / Get Set control
- Ability to define that the fact of purchasing a series of items gives special prices / free products or points to be used in the future for purchases / rewards
Retroactive discounts
- Ability to define multiple threshold after the fact discount levels that are given end of month / period
Reintroduction of Trade Agreement no and Contracts
- Trade agreement no is in the table but not exposed it needs to be exposed and attached to an agreement so that a number of lines can be attached to the same agreement no and managed as a whole
/Sven
As a minimum what is needed in the Ax model is to remove the groups from being directly attached to the product and customer units, as well as opening up for the ability to create prices in one go for more than one product.
But really what needs to be done is to revisit the model completely and add:
Price groupings
- Similar to kit pricing ability
Buy Set / Get Set control
- Ability to define that the fact of purchasing a series of items gives special prices / free products or points to be used in the future for purchases / rewards
Retroactive discounts
- Ability to define multiple threshold after the fact discount levels that are given end of month / period
Reintroduction of Trade Agreement no and Contracts
- Trade agreement no is in the table but not exposed it needs to be exposed and attached to an agreement so that a number of lines can be attached to the same agreement no and managed as a whole
/Sven
Tuesday, 28 November 2006
Price management
t aAnother thing often asked for in Ax when confronting the larger clients is a price buildup / decomposition possibility.
What is meant by this, well really only the option to either by building from the purchase price and adding, f'ex. handling charges, internal stock fee estimations, margins etc etc getting a sales price or going in the other direction and using the sales price and decomposing the sales price to arrive at a purchase price.
It should be possible to associate categories to each element in the composition as well as decomposition of the price and to store this category mapped for each item and then to apply this as a posting mask or value mask to see using reporting, how much of stocking fee we have overall sold for in a period f'ex.
The latter is what to a certain extent can be done in the Cost accounting module, however as the cost accounting module is uni dimensional, we loose too much information when feeding information in to be able to decompose the costs properly.
More about uni dimensional cost accounting later :-), I need to have subjects for discussion ;-), in short when the financial information is transferred to the cost accounting you specify one dimension to use and all others are removed. This has as a consequence that it is not possible to allocate by a combination of f'ex product and customer hierarchies using the same numbers.
I have heard that for version 4.5 due in 2009 there are some plans perhaps to create something along the lines of the price management as well as a plan to change the cost accounting module.
I and several others do wish this could be done sooner :-).
/Sven
What is meant by this, well really only the option to either by building from the purchase price and adding, f'ex. handling charges, internal stock fee estimations, margins etc etc getting a sales price or going in the other direction and using the sales price and decomposing the sales price to arrive at a purchase price.
It should be possible to associate categories to each element in the composition as well as decomposition of the price and to store this category mapped for each item and then to apply this as a posting mask or value mask to see using reporting, how much of stocking fee we have overall sold for in a period f'ex.
The latter is what to a certain extent can be done in the Cost accounting module, however as the cost accounting module is uni dimensional, we loose too much information when feeding information in to be able to decompose the costs properly.
More about uni dimensional cost accounting later :-), I need to have subjects for discussion ;-), in short when the financial information is transferred to the cost accounting you specify one dimension to use and all others are removed. This has as a consequence that it is not possible to allocate by a combination of f'ex product and customer hierarchies using the same numbers.
I have heard that for version 4.5 due in 2009 there are some plans perhaps to create something along the lines of the price management as well as a plan to change the cost accounting module.
I and several others do wish this could be done sooner :-).
/Sven
Saturday, 25 November 2006
Order stock allocation mechanism
Dynamics Ax could really benefit from the introduction of some basic SCM functionality that allows orders to be treated as a unit and to be allocated as such.
I have many clients in the wholesale business who desire the ability to work with complete orders, typically mail order catalogue businesses are an example, but really any business that delivers multiple parts in an order will desire this possibility if nothing else.
Today in Ax it is possible at line level on the order to denote that the line is either to be delivered in total or not at all.
Most of the big ERP systems on the market today have the above mechanisms built in, not all perform well ;-), from the echos I get.
Having built three times several variants on the algorithm of de-allocate everything (bar specials) then allocate in time windows with matching to future purchases the items, and flag all the orders with new dates if applicable, I think it is about time that Ax has one built in as a standard.
We already have a field with a type of order and it would be nice to expand this field with some attributes that govern what is done by the order matching process, as well as denoting how the orders are treated. We can choose to use either the Sales Pool, or the Sales Origin, or create our own categorisation. As the two flags / tables in question today are not overly used any action will do.
Then build a process which based on certain categories of orders can re-do the inventory reservations, also against future orders where of course we are not really speaking of reserving but rather allocating.
The above would definitely benefit from doing a reservation as discussed in another of my blogs, that is one that is not fully developped.
The alogorithms for doing the allocation are basically largest orders first, in time slots (f'ex weeks), priority of orders (notion of red flag orders), priority of customers. After the process a certain number are passed in "good to go" status and these are then the orders which are the pool to process the next day.
Most of the time a secondary lot is also designated where more than XX% of the order in value or qty is deliverable, and these can be delivered based on a manual decision the following day.
Some additional functions to pick the orders to allocate are added in to the mix above with some criteria allowing people to colour code or segment the orders, could be to create truck loads / containers by region etc etc.
But that again in and of itself is part of a larger question which it would also be nice to see added to the product, a proper shipping solution.
Of course Circon have a solution but it is very much transport oriented and it does not interfere through the whole cycle. I have built for some customers variants on the Masterplanning where the master planning did the load planning as well, that is organised in container loads the shipments to be done.
/Sven
I have many clients in the wholesale business who desire the ability to work with complete orders, typically mail order catalogue businesses are an example, but really any business that delivers multiple parts in an order will desire this possibility if nothing else.
Today in Ax it is possible at line level on the order to denote that the line is either to be delivered in total or not at all.
Most of the big ERP systems on the market today have the above mechanisms built in, not all perform well ;-), from the echos I get.
Having built three times several variants on the algorithm of de-allocate everything (bar specials) then allocate in time windows with matching to future purchases the items, and flag all the orders with new dates if applicable, I think it is about time that Ax has one built in as a standard.
We already have a field with a type of order and it would be nice to expand this field with some attributes that govern what is done by the order matching process, as well as denoting how the orders are treated. We can choose to use either the Sales Pool, or the Sales Origin, or create our own categorisation. As the two flags / tables in question today are not overly used any action will do.
Then build a process which based on certain categories of orders can re-do the inventory reservations, also against future orders where of course we are not really speaking of reserving but rather allocating.
The above would definitely benefit from doing a reservation as discussed in another of my blogs, that is one that is not fully developped.
The alogorithms for doing the allocation are basically largest orders first, in time slots (f'ex weeks), priority of orders (notion of red flag orders), priority of customers. After the process a certain number are passed in "good to go" status and these are then the orders which are the pool to process the next day.
Most of the time a secondary lot is also designated where more than XX% of the order in value or qty is deliverable, and these can be delivered based on a manual decision the following day.
Some additional functions to pick the orders to allocate are added in to the mix above with some criteria allowing people to colour code or segment the orders, could be to create truck loads / containers by region etc etc.
But that again in and of itself is part of a larger question which it would also be nice to see added to the product, a proper shipping solution.
Of course Circon have a solution but it is very much transport oriented and it does not interfere through the whole cycle. I have built for some customers variants on the Masterplanning where the master planning did the load planning as well, that is organised in container loads the shipments to be done.
/Sven
Thursday, 23 November 2006
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
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
Wednesday, 22 November 2006
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
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
Tuesday, 21 November 2006
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
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
Monday, 20 November 2006
Development for Localization
I promised in an earlier post to discuss what I see as the failings in the approach taken by Microsoft's Localization development team.
Here goes at least for a start.
The feature keys and their close cousins the security keys are a very underutilized tool in the product, they allow you in one case to disable entire parts of the system, that is to not even have a trace of the fields and tables in the database that are controlled by the feature keys. And in another case their close cousins the security keys are usefull tools to control the access for users to certain parts of the system.
So why do I start discussing these parts of the system in this context ?
In Ax you have two means of controlling how the software behaves ostensibly, one is through the feature keys and the security keys, the other is through parameters in the parm tables that are part of each of the modules in the product.
The localization team often ties a feature key (the country feature key) onto any given countries localization objects, this enables us as implementers / users to by enabling / disabling the country feature key to remove the fields & perhaps tables that are specific to any one country from the system.
However in multi country installations you want the fields but in countries not concerned you just want them to be empty and inaccessible.
So you cannot disable the feature key, you can however use the feature key as a security key and create user groups that have access one way or the other to the system in the different companies, this does not however provide the answer to our prayers as regards having a shared localized system.
For an example of how bad it is take a look at the CE layer from V3 SP4 onwards, and specifically only one class SalesFormLetter_Invoice which provides the system with the functionality of creating an invoice and updating all relevant associated tables.
Let us again narrow it down to just one method remember what we see here is present throughout the classes that are modified for localization purposes. The method is a key one in the SalesFormLetter_Invoice it is called UpdateNow and is the main executing method in the invoice update process.
As you can see here is an example of the use of a configuration key test to determine whether code should be executed.
Unfortunately in a multi country implementation of Axapta the configuration key would be enabled even though you do not want the code to be executed for some companies so it is not very smart to test the configuration key, rather one needs to setup a parameter that controls the behaviour instead.
Here goes at least for a start.
The feature keys and their close cousins the security keys are a very underutilized tool in the product, they allow you in one case to disable entire parts of the system, that is to not even have a trace of the fields and tables in the database that are controlled by the feature keys. And in another case their close cousins the security keys are usefull tools to control the access for users to certain parts of the system.
So why do I start discussing these parts of the system in this context ?
In Ax you have two means of controlling how the software behaves ostensibly, one is through the feature keys and the security keys, the other is through parameters in the parm tables that are part of each of the modules in the product.
The localization team often ties a feature key (the country feature key) onto any given countries localization objects, this enables us as implementers / users to by enabling / disabling the country feature key to remove the fields & perhaps tables that are specific to any one country from the system.
However in multi country installations you want the fields but in countries not concerned you just want them to be empty and inaccessible.
So you cannot disable the feature key, you can however use the feature key as a security key and create user groups that have access one way or the other to the system in the different companies, this does not however provide the answer to our prayers as regards having a shared localized system.
For an example of how bad it is take a look at the CE layer from V3 SP4 onwards, and specifically only one class SalesFormLetter_Invoice which provides the system with the functionality of creating an invoice and updating all relevant associated tables.
Let us again narrow it down to just one method remember what we see here is present throughout the classes that are modified for localization purposes. The method is a key one in the SalesFormLetter_Invoice it is called UpdateNow and is the main executing method in the invoice update process.
As you can see here is an example of the use of a configuration key test to determine whether code should be executed.
Unfortunately in a multi country implementation of Axapta the configuration key would be enabled even though you do not want the code to be executed for some companies so it is not very smart to test the configuration key, rather one needs to setup a parameter that controls the behaviour instead.
Here is an another example of a configuration key test. And in other parts of the code in just this one method of this one class there are examples of code additions that do not test for anything prior to being executed.
I have been called out to a customer implementation in Russia, where they were having trouble with the speed of their system, aside from finding issues in the added code that the partner had added. I also found that the invoice update process spent 5-15 sec's for each invoice update running a multi level select statement for no gain as the field in which the result was stored was disabled by a configuration key.
A select maxof is done on the inventrans linked to all the salesparmlines that are being updated, in the case where group updates are being done or serial numbers the above takes a long time, and as there is no index availeable sometimes SQL will be confused and do a full table scan on inventrans which takes a very long time.
In other methods added for localization the configuration key concerned is tested, again my comment is this works for a single country implementation but multi country implementations just do not function based on this principle.
So what do I recommend
GDL should lay down some ground rules for their developpment efforts.
1. Any functionality added needs to be parameter controlled in the code, as well as being configuration controlled in the Tables / Fields.
2. All functionality must be tested for non regression after implementation of localization code.
3. All code should be unit tested against large databases to ensure that the code can withstand / be used on larger scale implementations.
These rules shloud be applied on top of all the usual Development Best Practice rules that should of course also be followed :-).
Really this article is only about the very first one but as I am stating a wish list why not include the other items on the list.
/Sven
PS for some reason or other the JPG's turn out awfull as far as readability is concerned and the BMP's are worse anyhow will tinker to get them right.
Subscribe to:
Posts (Atom)