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
Wednesday 29 November 2006
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.
Sunday 19 November 2006
Commitment accounting
Dynamics Ax should really have this functionality as Microsoft targets Dynamics Ax at companies of a size that typically create or have a form of commitment accounting for at least part of their purchases.
In implementations that I have done / participated in we have often been called upon to create a commitment accounting process, whereby the customer would be able to budget for purchases, and see the budget, the commited amounts as well as the engaged and realised amounts.
We have often resolved this by creating special standard budgets that are posted / created when certain actions occur at purchase order line level when creating a purchase order, or when it is posted.
Example, we have a budget for the year that states we want to buy 100,000 worth of new machinery during the year. The manager of the production plant in Finsbury wants to buy 1 new planer and 10 new test units. He creates a corresponding entry in the commitment budget once the purchase is approved.
Then he creates the purchase order, which once it is confirmed by the supplier creates entries in an engagment budget he could only buy the planer at 3750 for now.
So we have 100 K in the main Budget 10 K in the Commitment budget and 3,750 in the Engaged budget.
Etc.
As you can see if we use the budgets properly and attach some budget creations to certain processes we can almost have a commitment accounting module in the system for free :-).
Of course it is limited and mostly deals with purchases, and has very little in the nature of forced workflows etc but nevertheless as a quick and simple solution until we get a fully fledged one it will do.
/Sven
In implementations that I have done / participated in we have often been called upon to create a commitment accounting process, whereby the customer would be able to budget for purchases, and see the budget, the commited amounts as well as the engaged and realised amounts.
We have often resolved this by creating special standard budgets that are posted / created when certain actions occur at purchase order line level when creating a purchase order, or when it is posted.
Example, we have a budget for the year that states we want to buy 100,000 worth of new machinery during the year. The manager of the production plant in Finsbury wants to buy 1 new planer and 10 new test units. He creates a corresponding entry in the commitment budget once the purchase is approved.
Then he creates the purchase order, which once it is confirmed by the supplier creates entries in an engagment budget he could only buy the planer at 3750 for now.
So we have 100 K in the main Budget 10 K in the Commitment budget and 3,750 in the Engaged budget.
Etc.
As you can see if we use the budgets properly and attach some budget creations to certain processes we can almost have a commitment accounting module in the system for free :-).
Of course it is limited and mostly deals with purchases, and has very little in the nature of forced workflows etc but nevertheless as a quick and simple solution until we get a fully fledged one it will do.
/Sven
Saturday 18 November 2006
The Dynamics Product Range PII
I concluded my previous post by stating that not a lot has changed from 2002 to today, and that is true from a market penetration perspective as well as measured by market share of each product in the various geographies that the products are sold in.
As best gleaned from the number of re-sellers and the market perception as well as gartner analysis reports that I have had access to.
However in one respect something is changing, time is moving on and the initially stated goal of powering ahead to 10 billion dollars of sales by 2011 looks increasingly hard to acheive. From page 24 of the 2006 annual report by Microsoft we can see that growth has been good, but inline with general Microsoft growth and not sufficent to accomplish the goal set at the outset.
In the 4 years since the second acquisition the turnover has doubled and more importantly the business unit is in the black by a small margin. However the plan called for more than doubling the turnover every 2 years during this 8 year period, which means that to hit the target would require almost 80% cumulated growth every year for the next 4 years.
Which is ambituous to say the least.
I perceive that in order to get closer to an interesting growth rate for the product range Microsoft does need to activate a crash program pick a horse to ride on, in other words a product.
The candidates I see are :
1. A new product the fabled "Green" that was to have seen daylight in 2004.
2. Great Plains a product with a client base of around 60 K mostly in the US and LATAM countries, with no inbuilt modification tools but with a large verticalisation base in the US market.
3. Solomon, not to be considered as a serious replace all candidate
4. Navision, a good all round product as is GP with a similar client base of around 50K clients all over the world, with an inbuilt 4GL based proprietary development language. Unfortunately it does not scale well especially on a SQL database. With a large verticalistion database which however is not very portable between country versions as these tend to be too different.
5. Axapta, a good all round product as is GP and Nav with a much smaller client base of around 6K clients again world wide, with an inbuilt development environment based on C++ / C# like development. Scales well and is natively supported only in SQL databases, has a large verticalisation base all over the world, with if done correctly easier portability between countries of the developpment. Downsides are that it is targeted only at larger customers in its current pricing schemes.
To my eyes I only see 2 viable candidates, Green which of course by far is the preferable solution and in second place Axapta.
Navision has difficulties in scaling beyond 10-15 telesales operators, the native database is operating using table locks and the SQL version has issues with some of the screen constructs that form part of the charm of Navision.
Great Plains does not offer international coverage but might be an interesting play if one only were focused on LATAM.
Solomon forget basically in this context.
However when looking at what MS should do it is of course instructive to look at what really happened. History and inertia count for a lot in MS.
So what has happened from July 2002 until today with the above.
Green:
Well a lot of talk and quite a few rumours, and if you do not factor in the MBF link in the sidebar then basically nothing has happened in 4 1/2 years. And from what I read the development work on MBF and Green started in the GP group so before 2002.
Axapta:
in September 2002 version 3 came out and then nothing until July/August this year and we are all awaiting the SP1 release which to me is the first full release as it includes the markets and all the functionality / databases. So one version in 4 1/2 years.
Navision
in September 2002 version 3 came out then 3.1 then 3.5 then 4.0 and early next year 5.0 is coming out. 3-4 major functional releases.
GP
Had 3 major releases in that time frame.
It seems that Axapta is the poor cousin in terms of attention from the product division.
Green obviously must have a lot of attention however no result is being seen concretely from the work carried out.
Are we to conclude from this that GP and Nav are the only products that we as customers should consider today ?
The official story from Microsoft is the one as stated in the previous post, all products are maintained (as we can see from the analysis not with the same level of activity however) until 2013 and all products "will be" somewhere in "Green".
The nebulous manner in which the later is stated time after time leaves me to conclude that no one, least of all Microsoft knows how they are going to achieve anywhere close to this goal in the future let alone by 2008 where wave 2 (the new green) is slated to arrive.
As this has now been discussed and presented for 4 years and it is and was presented as being 2 years away throughout that time frame I am quite sceptical until we start seeing real prototypes coming out of the lab.
Again my posting is getting too lengthy so I am going to stop here and continue later.
/Sven
As best gleaned from the number of re-sellers and the market perception as well as gartner analysis reports that I have had access to.
However in one respect something is changing, time is moving on and the initially stated goal of powering ahead to 10 billion dollars of sales by 2011 looks increasingly hard to acheive. From page 24 of the 2006 annual report by Microsoft we can see that growth has been good, but inline with general Microsoft growth and not sufficent to accomplish the goal set at the outset.
In the 4 years since the second acquisition the turnover has doubled and more importantly the business unit is in the black by a small margin. However the plan called for more than doubling the turnover every 2 years during this 8 year period, which means that to hit the target would require almost 80% cumulated growth every year for the next 4 years.
Which is ambituous to say the least.
I perceive that in order to get closer to an interesting growth rate for the product range Microsoft does need to activate a crash program pick a horse to ride on, in other words a product.
The candidates I see are :
1. A new product the fabled "Green" that was to have seen daylight in 2004.
2. Great Plains a product with a client base of around 60 K mostly in the US and LATAM countries, with no inbuilt modification tools but with a large verticalisation base in the US market.
3. Solomon, not to be considered as a serious replace all candidate
4. Navision, a good all round product as is GP with a similar client base of around 50K clients all over the world, with an inbuilt 4GL based proprietary development language. Unfortunately it does not scale well especially on a SQL database. With a large verticalistion database which however is not very portable between country versions as these tend to be too different.
5. Axapta, a good all round product as is GP and Nav with a much smaller client base of around 6K clients again world wide, with an inbuilt development environment based on C++ / C# like development. Scales well and is natively supported only in SQL databases, has a large verticalisation base all over the world, with if done correctly easier portability between countries of the developpment. Downsides are that it is targeted only at larger customers in its current pricing schemes.
To my eyes I only see 2 viable candidates, Green which of course by far is the preferable solution and in second place Axapta.
Navision has difficulties in scaling beyond 10-15 telesales operators, the native database is operating using table locks and the SQL version has issues with some of the screen constructs that form part of the charm of Navision.
Great Plains does not offer international coverage but might be an interesting play if one only were focused on LATAM.
Solomon forget basically in this context.
However when looking at what MS should do it is of course instructive to look at what really happened. History and inertia count for a lot in MS.
So what has happened from July 2002 until today with the above.
Green:
Well a lot of talk and quite a few rumours, and if you do not factor in the MBF link in the sidebar then basically nothing has happened in 4 1/2 years. And from what I read the development work on MBF and Green started in the GP group so before 2002.
Axapta:
in September 2002 version 3 came out and then nothing until July/August this year and we are all awaiting the SP1 release which to me is the first full release as it includes the markets and all the functionality / databases. So one version in 4 1/2 years.
Navision
in September 2002 version 3 came out then 3.1 then 3.5 then 4.0 and early next year 5.0 is coming out. 3-4 major functional releases.
GP
Had 3 major releases in that time frame.
It seems that Axapta is the poor cousin in terms of attention from the product division.
Green obviously must have a lot of attention however no result is being seen concretely from the work carried out.
Are we to conclude from this that GP and Nav are the only products that we as customers should consider today ?
The official story from Microsoft is the one as stated in the previous post, all products are maintained (as we can see from the analysis not with the same level of activity however) until 2013 and all products "will be" somewhere in "Green".
The nebulous manner in which the later is stated time after time leaves me to conclude that no one, least of all Microsoft knows how they are going to achieve anywhere close to this goal in the future let alone by 2008 where wave 2 (the new green) is slated to arrive.
As this has now been discussed and presented for 4 years and it is and was presented as being 2 years away throughout that time frame I am quite sceptical until we start seeing real prototypes coming out of the lab.
Again my posting is getting too lengthy so I am going to stop here and continue later.
/Sven
Friday 17 November 2006
The Dynamics product range
This post is a bit of a provocation and at the same time a reflection upon the current situation, the past and potentially the future.
How did the Dynamics product range as it stands today come about ?
Microsoft announced the purchase of Great Plains in December 2000, just one month after Damgaard and Navision merged in November 2000, Great plains had itself in it's efforts at seeking inorganic growth purchased Solomon previously. This was after a protracted period of not so stellar growth from all 4 companies, as the "year 2000 readiness" storm in a tea cup had swallowed a large part of the global IT budget for at least 3 years leading up to mid 99, which combined with the internet bonanza had driven everyone to overspend on IT and IT systems in almost all industries.
As a result 2000 was much calmer, the growth figures were good, still in the 10-20% range but one no longer talked of growing 50% per year, and also the challenges facing the companies became clearer.
SAP had just stated "We want to go for the SME market" and in the ERP market they are the big boys so they scared everyone. And of course where SAP goes Oracle, People soft, and others obviously intended to go as well, so all the mid tier players suddenly saw a monstruous challenge, how will we quickly become big enough to face this challenge. We need to be global players quickly in order to avoid being gobled up.
The same challenge faced all the players at the time, Scala, Exact, Navision, Damgaard, Addonix, Multi System, Jeeves, Baan, Intentia, Lawson, Great Plains, Solomon, etc etc the list is endless.
A large number of the then quite prominent players in their home markets no longer exist, some others have been bought once even several times. The reason behind this is quite clear and evident, it is a simple reflection of the general consolidation of information systems necessary even in smaller SME like organisation.
Today few ERP projects are carried out that do not include at least a passing reference to improved intercompany / multi site / multi warehouse stock flow. As we are generally getting better at using IT for what it is best used for we are obviously pushing the envelope to achieve ever higher returns, economies of scale, improved visibility and reduced costs across the board.
This means companies want and require intercommunicating systems at multiple levels, and as there are few if any standards that are well defined, as an IT purchase manager this tended to be expressed as "We need to ensure that we buy the same software in each of our companies through the region, that way we know we can get them to talk together".
Unfortunately the above is not necessarily the case, as those who have "heterogenous" deployment scenarios can testify.
The devil as always is in the detail, when you are deploying obviously you do not do it all at once as that would be too risky, as a consequence by the time you are ready for deployment 2 or 3 the vendor has brought a new "all singing all dancing" version and of course you wish to take advantage of this as there are a number of new features that are nice but as a consequence you no longer have one global software but several, to say nothing of the localization issue which even without the new version syndrome introduces differences within the same version.
What does all of the above have to do with my post title well, to me at least it seems important to reflect upon the background and context when analysing the past or the future.
So what was Microsoft doing before in this arena, well remember MS money and the battle against Intuit, Quicken and Peachtree. Basically they had decided to go for the lowest part of the ERP market, and of course the latest version of office includes Office Accounting http://blogs.msdn.com/satyanadella/archive/2006/10/29/microsoft-office-accounting-2007-new-wave-of-business-software-for-small-business.aspx that you can read about here in Satya's blog, which is a descendent of this strategy.
At the time Microsoft were looking a little further up-market at core SME and wanted to have a portion of this market as well and therefore acquired GP and Solomon in 2000. The problem with the SME/ERP market is that it was and still is heavily fragmented by country, each country typically had 2-3 or more products that were purely / mostly local to the country and that had acheived dominant positions in their marketplace. GP and Solomon were basically very hard to sell in Europe, through being designed for the north american market.
One of the exceptions to this rule was Navision, which as well as having almost 40% of it's own home market had through it's early decision (international expansion started in the early 90's) to expand taken a not invisible market share in almost all western european markets.
This decision to penetrate multi nationally taken by the Navision triumvirate was a key factor in convincing the Damgaard brothers to merge / join up with what at the time was their mortal enemy in their home market.
They had just started their own international market penetration efforts up quite recently after first relying on IBM (who had a 50% share of the company from 93 to 98) to sell internationally, and thereafter when this did not have the desired effect buying back the shares from IBM and doing an IPO to raise funds to do it on their own.
I believe, pending confirmation by the board members at the time ;-), that the cost figures / projections were not good, and that merging with Navision offered a means of quickly doubling channel access and ensuring that a viable business could be built in many countries at once.
The combined entity first called NavisionDamgaard and then finally less painfully, simply Navision now had 5 products in it's arsenal, of which two were internationally marketed through all of their markets. The company continued to have through the following 2 years good if not spectacular growth, which given the market context was quite good as it meant that globally the company was taking market share from the other players.
Microsoft of course cash rich as it is and was, was looking for investment opportunities, that enabled it to do what it does best ensure that Microsoft platforms are at the core of any system that is installed. This strategy also called "Sell the App secure the Stack" is at the center of many of Microsoft's actions, just as Google today are using their leverage in search engines to sell / push you many other services, and as Apple are using their IPod dominance to push other things. Basic economics 101 as they say in the US.
The great plains purchase provided revenue in the US but most other markets were not hospitable for the products from GP and Sol with some exceptions. Therefore a new acquisition in this domain seemed likely / possible. One strategy would be to buy SAP, the mastodont, however there were / are issues with this as the combined entity would be truely dominant and huge, and as there were already plenty of competitors crying wolf at Microsoft's every action, this would raise hell if it ever came about.
Instead they bought a small player with according to Gartner a 2+% market share in the global market place, which taken together with the 2+% GP and Sol had added up to a 5% global market share. The numbers off course mean little as a real measure of the number of clients served. SAP had in total some 12,000 companies as clients (2003). Damgaard alone had about 150,000 companies as clients at the time of the merger with Navision in 2000, through all their products, Navision had another 50,000+ so the combined entity had over 18 times the number of clients SAP had however the licence and maintenance spend of each SAP client dwarfs the licence and maintenance spend of each Navision client. So much so that SAP's turnover in 2003 was 7 Billion and Navision's in 2000 about 250 Million, a factor of 28 in the other direction.
And again if one steps further down to the smallest (by company and installation size) ERP markets one gets to Sage that have succesfully executed an acquistion strategy to create a global entity distributing a plethora of different accounting solutions throughout the world.
Enough rambling about the market ;-), so we have brought together GP, Solomon, Navision and Axapta (forgetting the others) under one roof. Now Microsoft has to decide how to create something uniform from these 4 competing product lines, and oh just to complicate matters we of course have the internal project Microsoft CRM on the go which also needs to be included in this mix.
An interesting challenge, which other players (Oracle / Lawson) are facing as we speak.
The solution was:
First reassure the market, this was done by declaring / giving a guarantee of support and evolution for all products through 2013, remember this was in 2002 ! Giving a 10+ year service guarantee was unheard of at the time. Funnily enough just after the acquisition of People soft and JD Edwards, Oracle issued what to me read as an exact verbatim copy of this except (same 2013 end date) theirs had a lot less years to run as it was not in 2002 ;-).
Second formulate a policy stating that customers would be able to migrate at no cost... the so called transformational guarantee. Of course given that IT projects generally have an implementation cost to licence cost ratio of between 2-5 to 1, whilst nice such a guarantee does not guarantee that a client is not out of pocket when the time comes to use the transformational guarantee ;-).
Third add new products that surround the existing ones and that are common and therefore push the whole. Examples of this are the demand planner, RCM (only us), MS CRM, and others.
And internally move in the quickest possible manner to a new .NET based product the fabled and much discussed "Green". As we speak (or you read) V2 of this product should have been on the shelves in your local software store, what happened ?
Well we will never really know I believe unless someone in the know has already or will someday tell us what happened.
Nevertheless the result is that we have, Navision and Axapta battling it out in all markets, and in the US them both playing back fiddle to GP and SOL who are the dominant players in that market. Basically an unchanged situation from 2002.
This post has become rather long so it is to be continued later.
/Sven
How did the Dynamics product range as it stands today come about ?
Microsoft announced the purchase of Great Plains in December 2000, just one month after Damgaard and Navision merged in November 2000, Great plains had itself in it's efforts at seeking inorganic growth purchased Solomon previously. This was after a protracted period of not so stellar growth from all 4 companies, as the "year 2000 readiness" storm in a tea cup had swallowed a large part of the global IT budget for at least 3 years leading up to mid 99, which combined with the internet bonanza had driven everyone to overspend on IT and IT systems in almost all industries.
As a result 2000 was much calmer, the growth figures were good, still in the 10-20% range but one no longer talked of growing 50% per year, and also the challenges facing the companies became clearer.
SAP had just stated "We want to go for the SME market" and in the ERP market they are the big boys so they scared everyone. And of course where SAP goes Oracle, People soft, and others obviously intended to go as well, so all the mid tier players suddenly saw a monstruous challenge, how will we quickly become big enough to face this challenge. We need to be global players quickly in order to avoid being gobled up.
The same challenge faced all the players at the time, Scala, Exact, Navision, Damgaard, Addonix, Multi System, Jeeves, Baan, Intentia, Lawson, Great Plains, Solomon, etc etc the list is endless.
A large number of the then quite prominent players in their home markets no longer exist, some others have been bought once even several times. The reason behind this is quite clear and evident, it is a simple reflection of the general consolidation of information systems necessary even in smaller SME like organisation.
Today few ERP projects are carried out that do not include at least a passing reference to improved intercompany / multi site / multi warehouse stock flow. As we are generally getting better at using IT for what it is best used for we are obviously pushing the envelope to achieve ever higher returns, economies of scale, improved visibility and reduced costs across the board.
This means companies want and require intercommunicating systems at multiple levels, and as there are few if any standards that are well defined, as an IT purchase manager this tended to be expressed as "We need to ensure that we buy the same software in each of our companies through the region, that way we know we can get them to talk together".
Unfortunately the above is not necessarily the case, as those who have "heterogenous" deployment scenarios can testify.
The devil as always is in the detail, when you are deploying obviously you do not do it all at once as that would be too risky, as a consequence by the time you are ready for deployment 2 or 3 the vendor has brought a new "all singing all dancing" version and of course you wish to take advantage of this as there are a number of new features that are nice but as a consequence you no longer have one global software but several, to say nothing of the localization issue which even without the new version syndrome introduces differences within the same version.
What does all of the above have to do with my post title well, to me at least it seems important to reflect upon the background and context when analysing the past or the future.
So what was Microsoft doing before in this arena, well remember MS money and the battle against Intuit, Quicken and Peachtree. Basically they had decided to go for the lowest part of the ERP market, and of course the latest version of office includes Office Accounting http://blogs.msdn.com/satyanadella/archive/2006/10/29/microsoft-office-accounting-2007-new-wave-of-business-software-for-small-business.aspx that you can read about here in Satya's blog, which is a descendent of this strategy.
At the time Microsoft were looking a little further up-market at core SME and wanted to have a portion of this market as well and therefore acquired GP and Solomon in 2000. The problem with the SME/ERP market is that it was and still is heavily fragmented by country, each country typically had 2-3 or more products that were purely / mostly local to the country and that had acheived dominant positions in their marketplace. GP and Solomon were basically very hard to sell in Europe, through being designed for the north american market.
One of the exceptions to this rule was Navision, which as well as having almost 40% of it's own home market had through it's early decision (international expansion started in the early 90's) to expand taken a not invisible market share in almost all western european markets.
This decision to penetrate multi nationally taken by the Navision triumvirate was a key factor in convincing the Damgaard brothers to merge / join up with what at the time was their mortal enemy in their home market.
They had just started their own international market penetration efforts up quite recently after first relying on IBM (who had a 50% share of the company from 93 to 98) to sell internationally, and thereafter when this did not have the desired effect buying back the shares from IBM and doing an IPO to raise funds to do it on their own.
I believe, pending confirmation by the board members at the time ;-), that the cost figures / projections were not good, and that merging with Navision offered a means of quickly doubling channel access and ensuring that a viable business could be built in many countries at once.
The combined entity first called NavisionDamgaard and then finally less painfully, simply Navision now had 5 products in it's arsenal, of which two were internationally marketed through all of their markets. The company continued to have through the following 2 years good if not spectacular growth, which given the market context was quite good as it meant that globally the company was taking market share from the other players.
Microsoft of course cash rich as it is and was, was looking for investment opportunities, that enabled it to do what it does best ensure that Microsoft platforms are at the core of any system that is installed. This strategy also called "Sell the App secure the Stack" is at the center of many of Microsoft's actions, just as Google today are using their leverage in search engines to sell / push you many other services, and as Apple are using their IPod dominance to push other things. Basic economics 101 as they say in the US.
The great plains purchase provided revenue in the US but most other markets were not hospitable for the products from GP and Sol with some exceptions. Therefore a new acquisition in this domain seemed likely / possible. One strategy would be to buy SAP, the mastodont, however there were / are issues with this as the combined entity would be truely dominant and huge, and as there were already plenty of competitors crying wolf at Microsoft's every action, this would raise hell if it ever came about.
Instead they bought a small player with according to Gartner a 2+% market share in the global market place, which taken together with the 2+% GP and Sol had added up to a 5% global market share. The numbers off course mean little as a real measure of the number of clients served. SAP had in total some 12,000 companies as clients (2003). Damgaard alone had about 150,000 companies as clients at the time of the merger with Navision in 2000, through all their products, Navision had another 50,000+ so the combined entity had over 18 times the number of clients SAP had however the licence and maintenance spend of each SAP client dwarfs the licence and maintenance spend of each Navision client. So much so that SAP's turnover in 2003 was 7 Billion and Navision's in 2000 about 250 Million, a factor of 28 in the other direction.
And again if one steps further down to the smallest (by company and installation size) ERP markets one gets to Sage that have succesfully executed an acquistion strategy to create a global entity distributing a plethora of different accounting solutions throughout the world.
Enough rambling about the market ;-), so we have brought together GP, Solomon, Navision and Axapta (forgetting the others) under one roof. Now Microsoft has to decide how to create something uniform from these 4 competing product lines, and oh just to complicate matters we of course have the internal project Microsoft CRM on the go which also needs to be included in this mix.
An interesting challenge, which other players (Oracle / Lawson) are facing as we speak.
The solution was:
First reassure the market, this was done by declaring / giving a guarantee of support and evolution for all products through 2013, remember this was in 2002 ! Giving a 10+ year service guarantee was unheard of at the time. Funnily enough just after the acquisition of People soft and JD Edwards, Oracle issued what to me read as an exact verbatim copy of this except (same 2013 end date) theirs had a lot less years to run as it was not in 2002 ;-).
Second formulate a policy stating that customers would be able to migrate at no cost... the so called transformational guarantee. Of course given that IT projects generally have an implementation cost to licence cost ratio of between 2-5 to 1, whilst nice such a guarantee does not guarantee that a client is not out of pocket when the time comes to use the transformational guarantee ;-).
Third add new products that surround the existing ones and that are common and therefore push the whole. Examples of this are the demand planner, RCM (only us), MS CRM, and others.
And internally move in the quickest possible manner to a new .NET based product the fabled and much discussed "Green". As we speak (or you read) V2 of this product should have been on the shelves in your local software store, what happened ?
Well we will never really know I believe unless someone in the know has already or will someday tell us what happened.
Nevertheless the result is that we have, Navision and Axapta battling it out in all markets, and in the US them both playing back fiddle to GP and SOL who are the dominant players in that market. Basically an unchanged situation from 2002.
This post has become rather long so it is to be continued later.
/Sven
Thursday 16 November 2006
Axapta pricing evolution
I must admit to being puzzled by the strategy being followed by Microsoft in this domain.
When the Damgaard brothers introduced the product in 98, there were 3 different price tiers with level 1 being limited to 10 concurrent users, the next level pricing AOS's expensively, and the last fully fledged pricing everything including a large qty of AOS's.
Each level basically changed the price by about 20% that is if Level 1 is 100 Level 2 would be 120 and 3 144 or thereabouts.
When Navision was brought into the mix they tried to space out the products, that is they stopped the small version and upped the price by about 15-20% because of Navision pricing which is much more complicated with many "Granules" or feature ticking purchase options.
When Microsoft came in they upped the price again, and now seem to want to do so again.
In the old days as a reseller of the product we often used the metric of a per seat price, which is the project cost divided by the people using the product.
I have re-done some analysis on the latest numbers and a 10-20 concurrent user system with production and full trade finance now has a price tag almost 3 times the software price it had in 2001 which to me is basically prohibitive for sales.
I know that Spain and Certain other countries have managed to maintain the SBE or small business edition in their price list for a very long time I have not really taken care to find out whether this is still the case but basically the message from microsoft is that a project below 50 conurrent users is a no go as we are now 2-3 times more expensive on the licence in this area as compared to My SAP which practices a seat price.
Of course it is difficult to compare the prices as SAP is named user and not concurrent user, and also they are hungry for market share so they do "crazy" deals, also MS has introduced a per seat price on a "dumbed down" configuration basically you either choose no production and limited SCM functionality or severly limited production functionality or the old price list.
What would I like to see from MS, a coherent strategy that allows for sales to smaller (in concurrent users) customers, this is being tried with the per user pricing initiative, however the functionality included is too meagre and the choices are to restrictive.
With the pricing in the current state you can only afford as a customer to buy if you are part of a group, or have a very large centralized installation to do, otherwise the cost is prohibitive.
I believe this is a problem as I believe that where Axapta (Dynamics Ax) really would shine is exactly in that market place of smaller installations in the 20-50 concurrent user range. Just a quick reminder 25 concurrent users is enough to do all sales, finance and production controlling for a production organisation of 200-300 people sometimes even more depending upon the industry, these can be quite sizeable companies.
Axapta is very affordable for organisations that have 1000 users accross a large number of sites, the problem in these scenarios is that the support for and the knowledge of how to do things is scarce, and the product is not functionality wise made to cover all the needs of such sizeable companies.
There are any number of functional areas where the product has the functionality but it does not have in depth functionality, rather there is vennier or a frame work upon which one could build or expand.
This is an issue as the dealers are being slowly killed by the pricing strategy, which seems very tame coming from Microsoft, I had thought that the advent of Microsoft on the product would mean 2 things:
Loads of great marketing
Agressive market driven pricing that is cabled to take a maximum of market share
Neither have frankly been visible at least in the markets where I have been active.
I hope that Microsoft will adress these issues in the near future.
/Sven
When the Damgaard brothers introduced the product in 98, there were 3 different price tiers with level 1 being limited to 10 concurrent users, the next level pricing AOS's expensively, and the last fully fledged pricing everything including a large qty of AOS's.
Each level basically changed the price by about 20% that is if Level 1 is 100 Level 2 would be 120 and 3 144 or thereabouts.
When Navision was brought into the mix they tried to space out the products, that is they stopped the small version and upped the price by about 15-20% because of Navision pricing which is much more complicated with many "Granules" or feature ticking purchase options.
When Microsoft came in they upped the price again, and now seem to want to do so again.
In the old days as a reseller of the product we often used the metric of a per seat price, which is the project cost divided by the people using the product.
I have re-done some analysis on the latest numbers and a 10-20 concurrent user system with production and full trade finance now has a price tag almost 3 times the software price it had in 2001 which to me is basically prohibitive for sales.
I know that Spain and Certain other countries have managed to maintain the SBE or small business edition in their price list for a very long time I have not really taken care to find out whether this is still the case but basically the message from microsoft is that a project below 50 conurrent users is a no go as we are now 2-3 times more expensive on the licence in this area as compared to My SAP which practices a seat price.
Of course it is difficult to compare the prices as SAP is named user and not concurrent user, and also they are hungry for market share so they do "crazy" deals, also MS has introduced a per seat price on a "dumbed down" configuration basically you either choose no production and limited SCM functionality or severly limited production functionality or the old price list.
What would I like to see from MS, a coherent strategy that allows for sales to smaller (in concurrent users) customers, this is being tried with the per user pricing initiative, however the functionality included is too meagre and the choices are to restrictive.
With the pricing in the current state you can only afford as a customer to buy if you are part of a group, or have a very large centralized installation to do, otherwise the cost is prohibitive.
I believe this is a problem as I believe that where Axapta (Dynamics Ax) really would shine is exactly in that market place of smaller installations in the 20-50 concurrent user range. Just a quick reminder 25 concurrent users is enough to do all sales, finance and production controlling for a production organisation of 200-300 people sometimes even more depending upon the industry, these can be quite sizeable companies.
Axapta is very affordable for organisations that have 1000 users accross a large number of sites, the problem in these scenarios is that the support for and the knowledge of how to do things is scarce, and the product is not functionality wise made to cover all the needs of such sizeable companies.
There are any number of functional areas where the product has the functionality but it does not have in depth functionality, rather there is vennier or a frame work upon which one could build or expand.
This is an issue as the dealers are being slowly killed by the pricing strategy, which seems very tame coming from Microsoft, I had thought that the advent of Microsoft on the product would mean 2 things:
Loads of great marketing
Agressive market driven pricing that is cabled to take a maximum of market share
Neither have frankly been visible at least in the markets where I have been active.
I hope that Microsoft will adress these issues in the near future.
/Sven
Tuesday 14 November 2006
Reserving inventory in Dynamics Ax
Dynamics Ax is very well stocked with functionality in the area of SCM, it has a good functionality set around this area.
You can in a flexible manner configure whether or not you wish to use more or less "dimensions" to control any given items, where the dimensions denote either item dimension that are part of the SKU, or are so called storage dimensions whose purpose is to help you keep track of and trace your inventory as it flows through your business.
However in one area as regards reservations the system is a bit restrictive or lacking in flexibility.
When you reserve stock, it will always be done using the whole dimension set that you have activated for the item, the problem with this approach is that you often find that you want to move stock around in your warehouse prior to selling it or that you wish to f.ex. reserve against an incoming shipment.
For the later case in the previous product we had markings in the system which allowed a 2'nd level of reservation as you could mark an inflow against an outflow (they would automatically be marked against each other) and if you then changed the place of either both changed allowing a reservation to flow naturally from a marking.
This is not the case in Axapta, even though we have had re-introduced in V3 the marking functionality it does not behave in the same manner as in the previous product.
Anyhow that behaviour was not all to the good, actually what is needed is a 2 level reservation system where it is possible to reserve on a higher level dimension in the first instance and only when you do detail reservation have the full storage dimension associated as it is now.
This could simply be acheived by introducing, yet another tick box (why not we have enough of them in Ax) in the dimension group setup screen which allows the user to setup a level in the storage dimensions at which he/she wants this first level reservation to be carried out, then we add on to the inventory transaction a new inventdimid which follows the above setup, and we can now reserve on the appropriate inventsum the qty we need preferably in a new field of inventsum.
Of course the Inventory dimensions do not need the flag as you would always reserve at this level ? or would you perhaps no better in fact allow the definition at this level too as this would allow for some interesting first level reservations if f.ex. we are in a process industry where the same product is available in various pack sizes and or drum sizes and you do not wish to specify the exact details. No this requires other changes so another ideas article to be written :-).
For the storage dimensions the flag should function as the costing flag does, that is the lowest active level is always fully expanded, that is if you choose Aisle/Rack/Shelf then the warehouse is included even if you do not tick it.
I have tested the above solution in 2 different customer scenarios and the customers are quite happy with the results I think it would be beneficial for the product to have such functionality. What do you think ?
/Sven
You can in a flexible manner configure whether or not you wish to use more or less "dimensions" to control any given items, where the dimensions denote either item dimension that are part of the SKU, or are so called storage dimensions whose purpose is to help you keep track of and trace your inventory as it flows through your business.
However in one area as regards reservations the system is a bit restrictive or lacking in flexibility.
When you reserve stock, it will always be done using the whole dimension set that you have activated for the item, the problem with this approach is that you often find that you want to move stock around in your warehouse prior to selling it or that you wish to f.ex. reserve against an incoming shipment.
For the later case in the previous product we had markings in the system which allowed a 2'nd level of reservation as you could mark an inflow against an outflow (they would automatically be marked against each other) and if you then changed the place of either both changed allowing a reservation to flow naturally from a marking.
This is not the case in Axapta, even though we have had re-introduced in V3 the marking functionality it does not behave in the same manner as in the previous product.
Anyhow that behaviour was not all to the good, actually what is needed is a 2 level reservation system where it is possible to reserve on a higher level dimension in the first instance and only when you do detail reservation have the full storage dimension associated as it is now.
This could simply be acheived by introducing, yet another tick box (why not we have enough of them in Ax) in the dimension group setup screen which allows the user to setup a level in the storage dimensions at which he/she wants this first level reservation to be carried out, then we add on to the inventory transaction a new inventdimid which follows the above setup, and we can now reserve on the appropriate inventsum the qty we need preferably in a new field of inventsum.
Of course the Inventory dimensions do not need the flag as you would always reserve at this level ? or would you perhaps no better in fact allow the definition at this level too as this would allow for some interesting first level reservations if f.ex. we are in a process industry where the same product is available in various pack sizes and or drum sizes and you do not wish to specify the exact details. No this requires other changes so another ideas article to be written :-).
For the storage dimensions the flag should function as the costing flag does, that is the lowest active level is always fully expanded, that is if you choose Aisle/Rack/Shelf then the warehouse is included even if you do not tick it.
I have tested the above solution in 2 different customer scenarios and the customers are quite happy with the results I think it would be beneficial for the product to have such functionality. What do you think ?
/Sven
Sunday 12 November 2006
Miscellaneous charges
Miscellaneous charges are a great tool in Dynamics Ax in order to control the value of your inventory as well as to add any number of extra cost components / side entries during the posting process.
As always :-) there is room for improvement in this functionality.
One of the areas that would be nice to expand upon is to have the ability to create purchases of Misc charges and to have a means of associating those purchases with the goods receipt notes and / or invoices on which this cost needs to be applied.
One means of doing this, which I have carried out at several customer installations is to add two new fields on the InventTable with a Misc charges code, and a distribution method (which I normally expand to include weight and volume distribution methods), these fields then control the option in the purchase order lines of being able in a button on the line to select one or more goods receipt notes or one or more invoices on which to apply the misc charge.
In addition to the above we add a misc charges group on the inventory table which is different from the normal one which is used to limit which misc charges are applied through this new mechanism of affecting / distributing misc charges. This field is of course only to be used for items other than the service items associated with the purchase of services.
In order to simplify things as unions are not possible in views I normally just build one button allowing selection of GRN's on which to distribute and another of Purchase invoices on which to distribute. The two buttons fill up a table which is linked through the Transid field to the original purchase order line on which the service is being purchased.
Then comes some tedious class work which I will spare you the details of doing extensions of the Markup classes and an addition to the PurchFormLetter_Invoice Class to call and update the invoices that are linked, using another Markup Class instance not the standard one ;-).
I have seen this done by 3 different partners in different manners, and have myself been called upon to do it as well, seems it is often requested and not very often provided.
Another thing for the idea box.
/Sven
As always :-) there is room for improvement in this functionality.
One of the areas that would be nice to expand upon is to have the ability to create purchases of Misc charges and to have a means of associating those purchases with the goods receipt notes and / or invoices on which this cost needs to be applied.
One means of doing this, which I have carried out at several customer installations is to add two new fields on the InventTable with a Misc charges code, and a distribution method (which I normally expand to include weight and volume distribution methods), these fields then control the option in the purchase order lines of being able in a button on the line to select one or more goods receipt notes or one or more invoices on which to apply the misc charge.
In addition to the above we add a misc charges group on the inventory table which is different from the normal one which is used to limit which misc charges are applied through this new mechanism of affecting / distributing misc charges. This field is of course only to be used for items other than the service items associated with the purchase of services.
In order to simplify things as unions are not possible in views I normally just build one button allowing selection of GRN's on which to distribute and another of Purchase invoices on which to distribute. The two buttons fill up a table which is linked through the Transid field to the original purchase order line on which the service is being purchased.
Then comes some tedious class work which I will spare you the details of doing extensions of the Markup classes and an addition to the PurchFormLetter_Invoice Class to call and update the invoices that are linked, using another Markup Class instance not the standard one ;-).
I have seen this done by 3 different partners in different manners, and have myself been called upon to do it as well, seems it is often requested and not very often provided.
Another thing for the idea box.
/Sven
Friday 10 November 2006
Views in Dynamics Ax
Views in Dynamics Ax are a great tool to improve performance, simplify code as well as allow easier reporting.
Historically views were introduced in version 3 in order to circumvent a scalability issue in the standard product as regards the updating of ledger transactions.
Ledger transactions are as in any ERP a type of transaction generated by many processes in the product, f'ex. the update of a production order costing, the update of a purchase invoice, in certain cases the update of a goods receipt or delivery note.
As the accounts involved are limited, what was happening was that the tables containing the sum of the ledger transactions by financial period were functioning as a block to the number of processes being able to be carried out simultaneously. In database speak we had a classical serialising bottle neck.
In order to reduce this the tables involved (LedgerBalances and LedgerBalancesDim) were changed to being views and the views showed the totals contained in LedgerBalancesTrans and LedgereBalancesDimTrans. These tables then had an index field added to them which was selected based on the modulo value of the Dynamics Ax session id number. Now we still have serialisation but strongly reduced by the fact that there are more entries on which we can act.
Just for completeness sake in V3 we use a modulo 10 and in V4 we use a modulo 20 which should allow for even more concurrent updates of the related information.
In order for this to work in V3 the developpment team had to add views in the AOT tree, and to make these the very close relative of tables, which has of course happened and is the reason we have views in the product.
Now there are several things which are missing from our implementation of views as opposed to the ones that you can define in SQL directly, chief amongst these are the fact of the generated code that creates the view depending upon the sequence with which one adds the tables in the AOT. This can create some phenomally badly performing views whereas if one re-creates the view in the right order the performance is much better.
This calls for a means of viewing the code generated directly in Dynamics Ax in order to better control what is generated and how it is generated in the SQL database.
The second and perhaps biggest issue I have with views is the inability in DynamicsAx to create unions, that is to have several final transactions steps. The reason why this is so is simply because queries for views are like queries for Olap cubes they can only have one base transaction table. That is if you want to have a view that lists all SalesLines and all PurchLines at the same level in order to do an analysis of the whole you cannot do so directly on those two tables in one view. In this instance there is a solution as both these tables translate downto entries in InvenTrans so you can build from this table upwards and get a global view :-).
However in many instances this is not possible as there is no federating Ax table, an example is the wish for a view federating all project transactions and budget transactions in one entity, or the ledger transactions with the ledger budget.
These are to me normal (as well as common) customer requests and Ax does not allow any easy means of satisfying them, in some instances just adding the ability to create views that are unions would allow a simple means of reporting what in Ax often becomes a very complicated task requiring the creation of additional tables federating information that is already availeable in the product.
Of course you can simplistically, and I have done so, add a view and then change it's code at syncronize time so that the query that is done behind the scenes is one that you wish. But the whole point of this is of course to get MS to add the tools in the system that we need in order to do a better job and a quicker job of implementing Ax.
I would suggest that once Unions are supported in Ax views a few example views should be created and based on these reporting cubes could be built that would really do justice to the system.
Allowing simple comparisons of Budget / Realised (commited) etc.
This would really reduce the time spent building reports / extracting information from the system, and that would be a great way of improving partner productivity and reducing development and deployment time.
Best Regards,
Sven
Historically views were introduced in version 3 in order to circumvent a scalability issue in the standard product as regards the updating of ledger transactions.
Ledger transactions are as in any ERP a type of transaction generated by many processes in the product, f'ex. the update of a production order costing, the update of a purchase invoice, in certain cases the update of a goods receipt or delivery note.
As the accounts involved are limited, what was happening was that the tables containing the sum of the ledger transactions by financial period were functioning as a block to the number of processes being able to be carried out simultaneously. In database speak we had a classical serialising bottle neck.
In order to reduce this the tables involved (LedgerBalances and LedgerBalancesDim) were changed to being views and the views showed the totals contained in LedgerBalancesTrans and LedgereBalancesDimTrans. These tables then had an index field added to them which was selected based on the modulo value of the Dynamics Ax session id number. Now we still have serialisation but strongly reduced by the fact that there are more entries on which we can act.
Just for completeness sake in V3 we use a modulo 10 and in V4 we use a modulo 20 which should allow for even more concurrent updates of the related information.
In order for this to work in V3 the developpment team had to add views in the AOT tree, and to make these the very close relative of tables, which has of course happened and is the reason we have views in the product.
Now there are several things which are missing from our implementation of views as opposed to the ones that you can define in SQL directly, chief amongst these are the fact of the generated code that creates the view depending upon the sequence with which one adds the tables in the AOT. This can create some phenomally badly performing views whereas if one re-creates the view in the right order the performance is much better.
This calls for a means of viewing the code generated directly in Dynamics Ax in order to better control what is generated and how it is generated in the SQL database.
The second and perhaps biggest issue I have with views is the inability in DynamicsAx to create unions, that is to have several final transactions steps. The reason why this is so is simply because queries for views are like queries for Olap cubes they can only have one base transaction table. That is if you want to have a view that lists all SalesLines and all PurchLines at the same level in order to do an analysis of the whole you cannot do so directly on those two tables in one view. In this instance there is a solution as both these tables translate downto entries in InvenTrans so you can build from this table upwards and get a global view :-).
However in many instances this is not possible as there is no federating Ax table, an example is the wish for a view federating all project transactions and budget transactions in one entity, or the ledger transactions with the ledger budget.
These are to me normal (as well as common) customer requests and Ax does not allow any easy means of satisfying them, in some instances just adding the ability to create views that are unions would allow a simple means of reporting what in Ax often becomes a very complicated task requiring the creation of additional tables federating information that is already availeable in the product.
Of course you can simplistically, and I have done so, add a view and then change it's code at syncronize time so that the query that is done behind the scenes is one that you wish. But the whole point of this is of course to get MS to add the tools in the system that we need in order to do a better job and a quicker job of implementing Ax.
I would suggest that once Unions are supported in Ax views a few example views should be created and based on these reporting cubes could be built that would really do justice to the system.
Allowing simple comparisons of Budget / Realised (commited) etc.
This would really reduce the time spent building reports / extracting information from the system, and that would be a great way of improving partner productivity and reducing development and deployment time.
Best Regards,
Sven
Thursday 9 November 2006
Add ons and the falacy of layers
The layers in Ax are a great addition to the product they enable you the user to install and maintain code in distinct files and thereby to ensure that you get a more stable system as an end user.
Where does the wheel fall off ?
Well the problem is that there are any number of add-ons availeable for Ax and they all require a place to be stored, furthermore Microsoft itself is a big consumer of layers and a generator of what I will call layer collisions.
An example of a layer collision in V3 is if you wish to install a site in Poland and another accross the border in Germany, and you wish to use some of the nifty intercompany functionality to better manage that manufacturing plant in Poland :-).
Well the bad news is you cannot as you have to have 2 distinct instances of Ax as the DIS/DIP layers for Poland (part of CE DIS Layer) and Germany (Part of the WEMEA DIS Layer) are not compatible.
What does this mean:
You have 2 choices:
1. Do the dev work yourself to merge the two :-(, and redo this every time MS brings out a new version.
2. Create 2 instances and drop any notion of automated stock lookups, intercompany etc.
Fortunately this will for these 2 countries no longer be the case after Version 4.01 where the localisations should be made availeable, at least for a while. The reason is that all the WEMEA localisations are now in the SYS/SYP layers.
However it is still the case if you wish to use India / Brazil and a long list of other countries with any Eastern European countries.
Further to this I have a general cristicism concerning the localised code as it does not really follow what I would call the minimum best practices neecssary to have a healthy localised system installed anywhere.
More about this later with some examples and also guidelines that I would think Microsoft should implement in their GDL (Global Development Localisation) teams that create this localisation code.
/Sven
Where does the wheel fall off ?
Well the problem is that there are any number of add-ons availeable for Ax and they all require a place to be stored, furthermore Microsoft itself is a big consumer of layers and a generator of what I will call layer collisions.
An example of a layer collision in V3 is if you wish to install a site in Poland and another accross the border in Germany, and you wish to use some of the nifty intercompany functionality to better manage that manufacturing plant in Poland :-).
Well the bad news is you cannot as you have to have 2 distinct instances of Ax as the DIS/DIP layers for Poland (part of CE DIS Layer) and Germany (Part of the WEMEA DIS Layer) are not compatible.
What does this mean:
You have 2 choices:
1. Do the dev work yourself to merge the two :-(, and redo this every time MS brings out a new version.
2. Create 2 instances and drop any notion of automated stock lookups, intercompany etc.
Fortunately this will for these 2 countries no longer be the case after Version 4.01 where the localisations should be made availeable, at least for a while. The reason is that all the WEMEA localisations are now in the SYS/SYP layers.
However it is still the case if you wish to use India / Brazil and a long list of other countries with any Eastern European countries.
Further to this I have a general cristicism concerning the localised code as it does not really follow what I would call the minimum best practices neecssary to have a healthy localised system installed anywhere.
More about this later with some examples and also guidelines that I would think Microsoft should implement in their GDL (Global Development Localisation) teams that create this localisation code.
/Sven
Wednesday 8 November 2006
BOM Auto report as Finished
In Dynamics Ax there is a very nifty facility enabling you to almost do kitting that is to sell commercial Kits.
I have seen quite a few projects where the functionality has been re-developped rather than take the functionality that is there and use it.
The reason mostly is because people do not know the functionality is there, or that people rightly see that it does not function at the right time in the Supply chain cycle.
The functionality actually only works if you use a process whereby you create the invoice immediately.
That is because the code activated by the tick box on the item master is found in the InventUpd_Financial class, and this class as you can tell from its name is used when a Financial update is carried out i.e. an invoice is being created.
However it is very simple to move / copy the method involved UpdateReportFinished over to the InventUpd_Physical class and to add a call to this method from the UpdatePhysicalIssue method of this class.
For safety it is best to force a return (stop from executing) the method in the Financial class, otherwise you will double the Kitting process.
After moving this code over you now have a simple solution acheived in 5 minutes of coding that allows you to at picking list processing level destock your sales kit components, and also allows you to have stock of the kit until the invoice is produced, as well as allows you to de-stock (de-kit) the items back to the sub items when you do a negative update.
Now all you would need for a complete kitting solution done in a simple manner is to be able to print a Picking list of the kit items, which involves minor changes to the picking list report. And ideally to be able to reserve the kit components now that is a longer story which we will get back to.
/Sven
I have seen quite a few projects where the functionality has been re-developped rather than take the functionality that is there and use it.
The reason mostly is because people do not know the functionality is there, or that people rightly see that it does not function at the right time in the Supply chain cycle.
The functionality actually only works if you use a process whereby you create the invoice immediately.
That is because the code activated by the tick box on the item master is found in the InventUpd_Financial class, and this class as you can tell from its name is used when a Financial update is carried out i.e. an invoice is being created.
However it is very simple to move / copy the method involved UpdateReportFinished over to the InventUpd_Physical class and to add a call to this method from the UpdatePhysicalIssue method of this class.
For safety it is best to force a return (stop from executing) the method in the Financial class, otherwise you will double the Kitting process.
After moving this code over you now have a simple solution acheived in 5 minutes of coding that allows you to at picking list processing level destock your sales kit components, and also allows you to have stock of the kit until the invoice is produced, as well as allows you to de-stock (de-kit) the items back to the sub items when you do a negative update.
Now all you would need for a complete kitting solution done in a simple manner is to be able to print a Picking list of the kit items, which involves minor changes to the picking list report. And ideally to be able to reserve the kit components now that is a longer story which we will get back to.
/Sven
Tuesday 7 November 2006
Adresses
Adresses and Dynamics Ax.
In Dynamics there is a very nice concept surrounding adresses that allows you to tie an address quite easily to almost any object.
The adress management is also very nicely conceived in such a manner that the format used depends on the country to which an adress belongs, which allows for addresses being printed out in a controlled manner on documents without empty lines when it is another country etc.
However to my mind the concept is in some ways incomplete.
What would I like to see added to the product ?
Well first the address table should have an ID Code and a link table or indirection table should be made between an address and the place where it is associated to a setup entry. This allows one to enter just once f'ex the address of a Customer that is a Supplier etc, and also to maintain it just the once.
On the link or indirection table one can easily add a type denoting the Link Type this should be a table with some tick box options to allow one to be the main addres the other to be an invoice address another a delivery address etc.
To ensure that the address used at the time of creating the legal documents is maintained, the information still needs to be copied to the ...InvoiceJour table but all others could just have a link to the address code Id thus reducing storage required in the database quite significantly.
Also today maintaining multiple addresses / setting the one to use is quite clumsy, this could be a lot easier with this new method as several could be set / used / displayed easily on the header / lines as needed.
Just a thought taken from a series of projects realised where the address entity / fields everywhere have caused issues.
/Sven
In Dynamics there is a very nice concept surrounding adresses that allows you to tie an address quite easily to almost any object.
The adress management is also very nicely conceived in such a manner that the format used depends on the country to which an adress belongs, which allows for addresses being printed out in a controlled manner on documents without empty lines when it is another country etc.
However to my mind the concept is in some ways incomplete.
What would I like to see added to the product ?
Well first the address table should have an ID Code and a link table or indirection table should be made between an address and the place where it is associated to a setup entry. This allows one to enter just once f'ex the address of a Customer that is a Supplier etc, and also to maintain it just the once.
On the link or indirection table one can easily add a type denoting the Link Type this should be a table with some tick box options to allow one to be the main addres the other to be an invoice address another a delivery address etc.
To ensure that the address used at the time of creating the legal documents is maintained, the information still needs to be copied to the ...InvoiceJour table but all others could just have a link to the address code Id thus reducing storage required in the database quite significantly.
Also today maintaining multiple addresses / setting the one to use is quite clumsy, this could be a lot easier with this new method as several could be set / used / displayed easily on the header / lines as needed.
Just a thought taken from a series of projects realised where the address entity / fields everywhere have caused issues.
/Sven
Monday 6 November 2006
Shared Tables and special tables Issue Sharing LedgerTrans
It is possible as discussed elsewhere in this blog to share information / tables across companies, this is done using an AOT entity called a TableCollection.
I had some trouble sharing some specific tables as you can see from the error report I made and I had to resolve the issue by manually changing the XPO file and importing it as it was not legal to do it in Axapta itself.
Here is the error report or an extract of it.
I have a client who wishes to share the LedgerTrans Table and therefore also the LedgerBalancesTrans and LedgerBalancesDimTrans Tables as logical extensions to this.
In order to ameliorate performance MS has introduced the views LedgerBalances and LedgerBalancesDim.
It is not possible to add a View to a table collection in the AOT, as a consequence the view tries to view transactions in the curext() company and therefore does not find any transactions.
I have resolved the issue by manually in an XPO file adding the LedgerBalances and LedgerBalancesDim Views in the collection, this has the desired effect however it would be nice if we could do so in a "Legal" manner.
The answer from support is that it is possible to type the view in manually and fortunately it is ;-), I only hope that this will remain true.
Anyhow the upshot is that if you ever need this then you now know it is possible manually without using the drag and drop.
/Sven
I had some trouble sharing some specific tables as you can see from the error report I made and I had to resolve the issue by manually changing the XPO file and importing it as it was not legal to do it in Axapta itself.
Here is the error report or an extract of it.
I have a client who wishes to share the LedgerTrans Table and therefore also the LedgerBalancesTrans and LedgerBalancesDimTrans Tables as logical extensions to this.
In order to ameliorate performance MS has introduced the views LedgerBalances and LedgerBalancesDim.
It is not possible to add a View to a table collection in the AOT, as a consequence the view tries to view transactions in the curext() company and therefore does not find any transactions.
I have resolved the issue by manually in an XPO file adding the LedgerBalances and LedgerBalancesDim Views in the collection, this has the desired effect however it would be nice if we could do so in a "Legal" manner.
The answer from support is that it is possible to type the view in manually and fortunately it is ;-), I only hope that this will remain true.
Anyhow the upshot is that if you ever need this then you now know it is possible manually without using the drag and drop.
/Sven
Sunday 5 November 2006
Sharing and Virtual Companies in Dynamics Ax
An often misunderstood part of Dynamics is it's ability to share information in between companies.
Why do I say that it is often misunderstood ?
Because it is presented as a solution to the much more complicated arena of multicompany / departments sharing in modern companies.
In Dynamics there is no native mechanism that enables the control / setup of such entities in the product.
You have to work and develop based on the needs of the customer the controls and mechanisms that you see are needed by the customer.
The Virtual companies are only a mechanism to start this process, they allow you to dictate that information contained in certain tables as a whole are availeable to both companies.
In every table in Dynamics Ax there is a column called DataAreaId which contains the company that the entry belongs to, and what you do when creating a virtual company is just that you replace the information contained in the row with the virtual company id and when you add companies to the virtual company you change the way they search that / those tables. Instead of using their own company id to search they use the virtual company id to search.
This basically allows one to share information / maintain / create information in a shared manner. Of course it does not really enable one to create a business unit within an organisation spanning several companies in several countries, in order to do that some work is required :-).
Later I will detail some quick solutions to some quirks in doing such sharing and illustrate by examples from implementation projects what can be done in this arena as well as some ideas of what would be nice as additions in order to support this functionality better.
/Sven
Why do I say that it is often misunderstood ?
Because it is presented as a solution to the much more complicated arena of multicompany / departments sharing in modern companies.
In Dynamics there is no native mechanism that enables the control / setup of such entities in the product.
You have to work and develop based on the needs of the customer the controls and mechanisms that you see are needed by the customer.
The Virtual companies are only a mechanism to start this process, they allow you to dictate that information contained in certain tables as a whole are availeable to both companies.
In every table in Dynamics Ax there is a column called DataAreaId which contains the company that the entry belongs to, and what you do when creating a virtual company is just that you replace the information contained in the row with the virtual company id and when you add companies to the virtual company you change the way they search that / those tables. Instead of using their own company id to search they use the virtual company id to search.
This basically allows one to share information / maintain / create information in a shared manner. Of course it does not really enable one to create a business unit within an organisation spanning several companies in several countries, in order to do that some work is required :-).
Later I will detail some quick solutions to some quirks in doing such sharing and illustrate by examples from implementation projects what can be done in this arena as well as some ideas of what would be nice as additions in order to support this functionality better.
/Sven
Friday 3 November 2006
Dynamics Ax
If you follow some of my links on the sidebar you will eventually get to a site called Microsoft Business Framework, this site is the site of the "tools" people that are working on the next version of Dynamics in a general sense, and also providing tools for all the competitors of MS in the arena of developping ERP/BMS systems. The project was meant to have been used to create what in the press got called project "Green". Which has been postponed until further notice.
The MBF toolset is a set of tools similar to having an Axapta AOT tree in Visual Studio, now that would be something would it not having the AOT directly in Visual Studio ? Of course it is only availeable to a limited number of partners that you can see mentioned on a page on the site for the time being.
Interesting to have a look at for those of us who like to sniff at the unfinished products / future products.
I only have one boon to ask from the skunk works ;-) please give Ax a new menu system :-).
/Sven
The MBF toolset is a set of tools similar to having an Axapta AOT tree in Visual Studio, now that would be something would it not having the AOT directly in Visual Studio ? Of course it is only availeable to a limited number of partners that you can see mentioned on a page on the site for the time being.
Interesting to have a look at for those of us who like to sniff at the unfinished products / future products.
I only have one boon to ask from the skunk works ;-) please give Ax a new menu system :-).
/Sven
Thursday 2 November 2006
Bug in Axpata V3 SP4 "Record already exists"
Again whilst doing a customer implementation I came across a bug in Axapta SP4 and SP5 which will be corrected I am told in SP6.
The bug can be reproduced by the following means:
Go to Accounts Payable / Periodic / Purchase Order Update / any of the options
Do not select any orders just change the Quantity Parameters back and forth, after 2 goes you will get a message about a record not being able to be updated as it already exists.
The cause of the bug is the addition in the PurchEditLines Form on the PurchParmUpdate datasource field SpecQty method modified where a call is made to element.calctotals()
This method found in the main methods of the form forces a write of the purchParmTable which as the screen is empty creates an empty record and then proceeds when the field above is changed to try and do so a second time which causes the error.
I have 2 possible solutions,
1 Check before if PurchParmTable exists and only call CalcTrans if it does, or
2 check in calctrans if a recid is present and only write if it is.
Hope this can be of help to anyone needing to resolve the issue somewhere else.
/Sven
The bug can be reproduced by the following means:
Go to Accounts Payable / Periodic / Purchase Order Update / any of the options
Do not select any orders just change the Quantity Parameters back and forth, after 2 goes you will get a message about a record not being able to be updated as it already exists.
The cause of the bug is the addition in the PurchEditLines Form on the PurchParmUpdate datasource field SpecQty method modified where a call is made to element.calctotals()
This method found in the main methods of the form forces a write of the purchParmTable which as the screen is empty creates an empty record and then proceeds when the field above is changed to try and do so a second time which causes the error.
I have 2 possible solutions,
1 Check before if PurchParmTable exists and only call CalcTrans if it does, or
2 check in calctrans if a recid is present and only write if it is.
Hope this can be of help to anyone needing to resolve the issue somewhere else.
/Sven
Wednesday 1 November 2006
Bug in Axapta V3 SP4 "SelectLocked Incorrect call" expected to be Fixed in SP7 :-(
Whilst helping a customer during implementation of their Axapta system I came across a bug, I have notified the support organisation and have been told it wil be fixed in SP7 which I find rather baffling as the bug steems from code introduced in SP4.
Anyhow.
If you are using IMTS, and have installed SP4 and are using physical valuation and you have activated the warehouse dimension then a bug / erroneous error message is generated.
The bug is an error message is generated if your try to generate a Purchase order from a sales order and in a number of other cases (not all have been identified) one other is if you delete a production that is referenced to a sales order.
The message :
You get an error message stating that you have called inventsumTTS.inventItemLocationSelectLocked incorrectly.
This is due to the following code added in SP4 to the inventMovement.EstimatedFinancialValue method
if (this.inventModelGroup().InclPhysicalValueInCost)
{
inventDimFinancial = InventDim::findOrCreate(inventDimFinancial);financialInventOnHand = InventOnHand::newItemDim(this.itemId(), inventDimFinancial, inventDimParmFinancial, true);
}
The last parameter is the lock clause in the InventOnHand new which forces a verification of lock on such modifications.
I have corrected the bug, by adding a new method exposing the lock parameter of an InventOnHand instance which I have called
LockSet.boolean LockSet()
{
return lock;
}
Then I have modified the above code to :
if (this.inventModelGroup().InclPhysicalValueInCost)
{
inventDimFinancial = InventDim::findOrCreate(inventDimFinancial);financialInventOnHand = InventOnHand::newItemDim(this.itemId(), inventDimFinancial, inventDimParmFinancial, _InventOnhand.LockSet());
}
Which perpetuates the Lock state from the caller on to the possible new inventonhand instance created.
If anyone wants them I can forward or perhaps post the actual fix xpo or a link to it if desired please comment, otherwise it should be pretty straight forward to follow the explanations given and effect a fix from them.
Besides I am sure most of you would rather have the pleasure of doing your own fix ;-) whilst waiting for MS to publish SP7.
/Sven
Anyhow.
If you are using IMTS, and have installed SP4 and are using physical valuation and you have activated the warehouse dimension then a bug / erroneous error message is generated.
The bug is an error message is generated if your try to generate a Purchase order from a sales order and in a number of other cases (not all have been identified) one other is if you delete a production that is referenced to a sales order.
The message :
You get an error message stating that you have called inventsumTTS.inventItemLocationSelectLocked incorrectly.
This is due to the following code added in SP4 to the inventMovement.EstimatedFinancialValue method
if (this.inventModelGroup().InclPhysicalValueInCost)
{
inventDimFinancial = InventDim::findOrCreate(inventDimFinancial);financialInventOnHand = InventOnHand::newItemDim(this.itemId(), inventDimFinancial, inventDimParmFinancial, true);
}
The last parameter is the lock clause in the InventOnHand new which forces a verification of lock on such modifications.
I have corrected the bug, by adding a new method exposing the lock parameter of an InventOnHand instance which I have called
LockSet.boolean LockSet()
{
return lock;
}
Then I have modified the above code to :
if (this.inventModelGroup().InclPhysicalValueInCost)
{
inventDimFinancial = InventDim::findOrCreate(inventDimFinancial);financialInventOnHand = InventOnHand::newItemDim(this.itemId(), inventDimFinancial, inventDimParmFinancial, _InventOnhand.LockSet());
}
Which perpetuates the Lock state from the caller on to the possible new inventonhand instance created.
If anyone wants them I can forward or perhaps post the actual fix xpo or a link to it if desired please comment, otherwise it should be pretty straight forward to follow the explanations given and effect a fix from them.
Besides I am sure most of you would rather have the pleasure of doing your own fix ;-) whilst waiting for MS to publish SP7.
/Sven
Subscribe to:
Posts (Atom)