Layers in Dynamics Ax

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

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

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

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

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

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

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

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

So rebalancing is now a possibility, perhaps.


/Sven

The concept of Warehouse and extensions

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

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

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

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

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

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

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

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

/Sven

Back order treatment

Back orders in Dynamics Ax, and their treatment leaves a lot to be desired, basically the most advanced functionality availeable is to allow good to be reserved before arrival in order that the system automatically places a physical reservation against the stock that has arrived when it arrives.

There is nothing intelligent to allow the treatment of a complete shipment of goods that is arriving to see which orders could best be fulfilled from the newly arrived shipment, there is even no function to allow one to automatically plan some shipment actions aside from the above mentioned one.


What would I propose is needed, well basically a linkup with the proposed allocation system that I have discussed earlier where it would be possible to allocate whole sales orders and treat them as units, that is reserve all the items or none. Conversely I see the need to be able to take whole purchase orders or even multiple purchase orders treat them, that is recieve the goods count QC check etc then when a pool has reached a certain size to allow allocation to happen against the pool.

Of course by judicious usage of a dedicated warehouse and Ax transfer functionality one could argue that one could acheive something along these lines. However the inconvenient thing is that one would have to create several new warehouses and the consequences of having stock in several "virtual" warehouses and also leaving traces everywhere is that not only is it harder to visualize where your stock at any one time is but also it is creating a trail of new inventsum records which means all stock and inventory checking reports become slower etc etc.

It would not be complicated to add some more stati in the inventory model and conversely to add some more inventmovement steps that could be configured, actually both on the incoming side as well as the outgoing side this could be of interest.

And these could then be configured by the user to be skipped or they could represent QC steps and or allocating, free for allocation steps.

It would cost very little to maintain if done by MS centrally rather than having to be added by a dealer or a customer.

What do you think.

/Sven

Product and other hierarchies

One of the things that most customers wish for when confronted with the reality of the datamodel in Dynamics Ax is some means of attaching meaningfull default values at various levels of a hierarchy to which they attach information.

An example could be the wish to dictate that a certain field f'ex the item group is set to a certain value for all items that belong to the category Oranges, as well as being sold in Belgium.

It is not easy to do in the standard Ax structures, what would be nice is a standard hierarchy builder type of feature as that found in f'ex the Demand planner add on where you are able to conceive your own hierarchy on top of any existing field in the system and for Ax basically to recognize the relationship so that reporting and other features could be built using this variable hierarchy.

Thereafter the next step would be to give the hierarchies an active role in the product, that is to allow the definition of certain fields to be tied to a hierarchy structure.

F'ex to say that the item group is deduced from somewhere in a given hierarchy meaning we can setup a default group at high level and then down the branches define exceptions, allowing the user to work top down and do less work and the system to work bottom up in order to use the first value found.

If we applied this principle to the groups used in the pricing matrix then we could really make some neat price matrices with pricing, discounts, etc at all sorts of levels.

What do you think ?

/Sven

Busy

I am currently working myself into a new job and obviously as with all new beginnings there is a period when you are required more than 150% of the time by your current job and I am therefore finding it less easy to work on the blog expect me back in usual frequence next month, right now I am working up a back log of subjects that I want to address.

If you have any subjects that you find are of interest then please feel free to suggest or even if you wish to add a topic contact me and I will add your blog as a feed here if you wish.

/Sven

Dynamics Ax Base Data model Part I

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

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

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

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

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

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

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

I choose to take the more complicated inventory model first J

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

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

Why are the above elements stored in separate tables ?

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

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

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

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

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

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

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

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

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

/Sven

Special pricing 2 for one buy any three etc Points

The pricing mechanism in Dynamics Ax, which was inovative when it was introduced in Concorde, the ancestor of the ancestor of Dynamics Ax, now seems rather dated.

As a minimum what is needed in the Ax model is to remove the groups from being directly attached to the product and customer units, as well as opening up for the ability to create prices in one go for more than one product.

But really what needs to be done is to revisit the model completely and add:

Price groupings
- Similar to kit pricing ability

Buy Set / Get Set control
- Ability to define that the fact of purchasing a series of items gives special prices / free products or points to be used in the future for purchases / rewards

Retroactive discounts
- Ability to define multiple threshold after the fact discount levels that are given end of month / period

Reintroduction of Trade Agreement no and Contracts
- Trade agreement no is in the table but not exposed it needs to be exposed and attached to an agreement so that a number of lines can be attached to the same agreement no and managed as a whole



/Sven

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

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

The Dynamics Product Range PIII

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

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

Let me explain my reasoning for this.

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

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

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

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

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

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

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

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

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

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

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

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

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

/Sven

Dev for localization and International projects

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

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

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

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

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

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

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


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

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

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

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

/Sven

Dev for Localization Cost of dev

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

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

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

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

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

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

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

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

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

Up for discussion, what do you think ?

/Sven

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 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dynamics Ax 4 Bug in Tax Calculation in Ledger Intercompany Accounting

Using std Axapta 4.0 with accounts not done incl. Tax.

That is in Ledger Parameters / Tab Tax untick the include VAT and in the Ledger Journals do the same either at header or setup levels.

Then create an intercompany link between two companies, with the appropriate setup.

Add a line that posts an amount with a TaxGroup and a TaxItemGroup that gives a VAT rate.

The system when checking the journal will find no error, and when you try to post will report that the document does not balance as it doubles the VAT amount.

The culcript is a new alegorithm introduced in V4 in the TaxVoucherService Class.

In order to remove the issue I have added the following in the Update now method of LedgerJournalTrans class:

Original

if (taxVoucherService)
{

if (taxVoucherService.ledgerFallbackAccount() == _ledgerJournalTrans.AccountNum)
{
taxAmount = taxVoucherService.taxAmountToPost(_ledgerJournalTrans.LineNum);
}
}

Changed

if (taxVoucherService.ledgerFallbackAccount() == _ledgerJournalTrans.AccountNum && _Posting != LedgerPostingType::InterCompany )
{ // Changed on 20 Jul 2006 at 17:44:45 by SJO

taxAmount = taxVoucherService.taxAmountToPost(_ledgerJournalTrans.LineNum);
// Changed on 20 Jul 2006 at 17:44:45 by SJO
}
}

As the VAT amount has already been added in the intercompanyupdate process earlier.


This bug is reported and will be fixed in Version 4.1 due out end 2007.

/Sven

Dynamics AX V4 Bug Tax allocation in journals

Precondition, change V4 setup in demo database to work with not including Tax amounts.

That is in GL Parameters Tab Tax remove including tax tick and do the same for the journal.

When you create a Daily journal in the GL with only ledger accounts, and set 2 or more lines with VAT with one setoff line the verification process finds no errors but posting tells you that you have a difference.

The problem is in the changed (from V3) TaxVoucherService it now stores the VAT in a MAP using the linenumber of the Journal as a link.

Now if you have f'ex

Line 1 account 1000 Amt 100 Tax 25
Line 2 account 1010 Amt 100 Tax 25
Line 3 Account 2000 Amt -200

The system should generate a Tax surcharge on line 3 of +50thus making the posting 250 on that account.

However in the Map Calculated by the TaxVoucherService class the amount for line 3 is empty.

I have as a work around introduced a new Method in the TaxVoucherService class which returns the sum of the TaxAmountToPostMap

// Changed on 20 Jul 2006 at 17:44:45 by SJO
AmountCur Sev_TaxAmountTotal()
{
LineNum _LineNum;
AmountCur total;
MapIterator iterator;
;
iterator = new MapIterator(taxAmountToPostMap);
while (iterator.more())
{
total = total + iterator.value();
iterator.next();
}
return total;
}

And in the UpdateNow method of LedgerJournalTransUpdate I now call my new Method instead of the standard code

if (taxVoucherService)
{
if (taxVoucherService.ledgerFallbackAccount() == _ledgerJournalTrans.AccountNum)
{
// Changed on 20 Jul 2006 at 17:44:45 by SJO
// This should be all the tax not the tax on the line
taxAmount = TaxVoucherService.Sev_TaxAmountTotal();
// taxAmount = taxVoucherService.taxAmountToPost(_ledgerJournalTrans.LineNum); // Changed on 20 Jul 2006 at 17:44:45 by SJO
}
}

This seems to resolve the issue for my particular case however I am not dealing with the case of several different fallback accounts / Offset accounts.

Basically the function no longer works as in V3 due to the changes made and my change may not be compatible with V3 functionality however it at least correctly posts the amounts.

The issue should be resolved in Dynamics Ax 4.01 or SP1 depending upon the title given to this release which is due out soon.

/Sven

Intercompany payments BUG Dynamics Ax V4 Loc Build

In AX V4 August release the following intercompany related bug has been found.

It is possible to create intercompany Links between companies and Axapta will in those instances in V4 maintain information about the established invoices and will try to settle on both sides simoultaneously.

This works well, except in the case where you decide to use an intercompany account but not to do the full interaction, that is you untick the intercompany box. The result is you have an invoice on an account with an intercompany setup with no corresponding entry on the related account in the other company.

This could be because you want to register a fee or other invoice or it could be that the account was not intercompany but now is as you have changed your setup.

Ax will forcibly try to settle a transaction on the other set of accounts inspite of it knowing it is not there.

To correct this BUG two small changes are needed in two methods of the LedgerJournalCheckPost Class.

The Methods IntercompanyPaymentExist and IntercompanyTransferToCustPayment need to have a new variable added in the declaration in order that we can query it later in a select.

// Intercompany only if the invoice was booked with intercompany link active
VendInvoiceJour VendInvoiceJour;
// Information is stored in the invoice And the Select statement
select firstonly forceplaceholders vendSettlement
where vendSettlement.OffsetTransVoucher == ledgerJournalTrans.Voucher
join vendTrans where vendTrans.RecId == vendSettlement.TransRecId
&& vendTrans.AccountNum == vendSettlement.AccountNum
&& vendTrans.Invoice

Should have added to it the following

select firstonly forceplaceholders vendSettlement
where vendSettlement.OffsetTransVoucher == ledgerJournalTrans.Voucher
join vendTrans
where vendTrans.RecId == vendSettlement.TransRecId
&& vendTrans.AccountNum == vendSettlement.AccountNum
&& vendTrans.Invoice
// Added search
join VendInvoiceJour
where VendInvoiceJour.InvoiceId == VendTrans.Invoice
&& VendInvoiceJour.InvoiceDate == VendTrans.TransDate
&& VendInvoiceJour.InvoiceAccount == VendTrans.AccountNum;
if (vendTrans.Invoice && VendInvoiceJour.InterCompanyCompanyId)
// Added check to avoid issue
{The check on the IntercompanyId field ensures that the transaction was done using IC.
//

Hope this may help someone somewhere :-)

/Sven Jochimsen

Dynamics Ax 4.0 was launched in July 06'

The good the bad and the ugly surrounding the release of this long awaited upgrade to V3.
V3 was launched in September 2002 which means that it took Microsoft almost 4 years to launch a new version after V3.

Version 2.5 was launched in Dec 2000 and 2.1 in 1999 and 1.0 in April 1998.
It seems the product launch cycle is getting longer rather than shorter.
One could ask the question what happened.

If one compares with the other product Navision that was acquired at the same time in July 2002.
The Navision product group brought out 3.0, 3.1, 3.5, 3.7, and 4.0 during the same time frame each of which added functionality to the product.

It seems the Ax group was sitting on it's laurels, and inovation was only forthcoming from the partners through their many add-ons that functionally completed the product or vertically adapted the product.

I do not have any official story behind the above, however I have noted that at many times during the above period of time, we heard as dealers that there would be a new version and product scope was being discussed etc etc but at no time until Jan Feb 2005 was there evidence of any real project with concrete plans for any future versions.

What were the Ax developpers doing during the interim time frame ?

I believe they were otherwise engaged, all we can do is ask.

However the result is that Axapta as a product which when it came out was revolutionary and ahead of it's time has lost out.

Hopefully the MS Dynamics product group with Satya now firmly in charge will get down to the nitty gritty of providing us with a series of new versions at a more consistent and advanced pace.

/Sven Jochimsen

Dynamics Ax First Impressions

Generally I like the product as such, which should come as no surprise to those who know me, I have been working with it pretty much since it was made and before that with it's predecessor etc etc.

Anyhow notes :

Like:

AOS robustness

In V3 the AOS could at times seem a bit fragile and if you stopped a server you were certain that all the users were thrown out / off the system. With V4 some new technology has been added that allows in some instances sessions to be recovered by the other AOS's this is impressive when you realise how complicated such an operation can be, its the computer equivalent of a juggler replacing another juggler in the middle of a trick with all the balls in the air !

New dimension setup

Finally we are able to make hierarchies and to limit what and where they are used etc etc.
New financial statement generator

In the product that preceeded Ax there was a report generator enabling the users to create financial statements with accounts and dimensions as lines and the ammounts against them. Finally we can do so with less effort than before. In V3 you had to name each dimension it was basically tedious and almost impossible to do with the V3 financial statements.

Dislikes

New Menu

I find almost comical the pains that the UX team are going to to reduce usability, I am sorry it is not easy to read and furthermore I would even state that the old grid menu of XAL was from a UX point of view easier and more intuitive. As was the old tree menu that you can still by exporting and importing under another name activate as your main menu. The main problem is that the new menu eats screen space. Just try opening any of the larger screens (Inventory, Sales Orders, Purchase Orders) on a 1024*768 monitor it just does not work. I am really looking forward to the next version where this will change again to accomodate / be compatible with Office 2007 hopefully !

To be continued

/Sven Jochimsen

Start of the blog

Hello this is just the initial installment of my blog on the subject of Dynamics Ax, I will be using it to relay my impressions of and around the product and generally also the actions of Microsoft in this market place.

I do not have the time right now to say anything about who I am and why indeed you should waste your valuable time reading any of this but I hope to render it an interesting experience for any and all of those of us who are active in this marketplace.

And I will be publishing various bits and pieces of code as others are doing as well as sharing some experiences of using / selling and implementing Dynamics Ax.

I will not explain what Dynamics Ax is as if you have found your way here you are probably fully aware of what it is :-).

Have fun reading and commenting.
/Sven