Microsoft Dynamics AX

Microsoft Dynamics AX (before Microsoft Axapta) – a resource management system of the enterprise of the class ERP for average and large – with number of staff more than 10 thousand employees - the companies.

Screenshot - Microsoft Dynamics AX 2012 R3

The Danish company Damgaard Data A/S was a solution designer of Axapta from which "grew" Microsoft Dynamics AX. The first version of a system was released in March, 1998 in Denmark and the USA. The name Axapta was replaced with Dynamics AX in 2004 after Microsoft purchased system developers.

Functionally the solution covers all fields of management of the enterprise: production management, distribution in difficult supply chains, retail networks (the industrial Dynamics solution of AX for Retail), finance, including accounting according to different standards in holding structures, project activity and service maintenance, sales, marketing, customer relations, personnel management and also control and the analysis of business, compliance to corporate politicians.

Microsoft Dynamics AX supports simultaneous operation in the system from 20 to 500 users. In practice there are installations with number of users more than 1000 and also test installations for 3000 at the same time working with a system and more than 32 thousand normal users.

Users of Microsoft Dynamics AX are more than 12,000 companies from more than one hundred countries of the world. The version sold in Russia as of the middle of 2015 - Microsoft Dynamics AX 2012 R3, released in 2014.

In 1 quarter 2016 the release of the new version of a system – Dynamics AX 7 is expected.

History of development of a system

2020: Start of Neti of the module of integration Microsoft Dynamics AX and 1C

On April 6, 2020 the company Neti announced development integration module Microsoft of DAX-1C which allows to configure permanent or session transfer data between systems, observing everything to requirements to the document formats and considering features of both information systems. The integration module Microsoft Dynamics AX — 1C works with versions of AX 3.0, 4.0, 2009 and 2012. In more detail here.

2015: A flagman ERP system of Microsoft will become mobile

The technical director of Microsoft Business SolutionsMike Ehrenberg in December, 2015 told TAdviser about development of mobile solutions for the products Dynamics. According to him, the last two years of Microsoft actively works on providing to users an opportunity fully to work with all the business solutions from any devices, including from smartphones and tablets.

Erenberg noted that emergence of such opportunity was expected by many users of Dynamics as mobile devices are more and more used for business challenges: "The mobility became the integral, necessary part of work, and its providing for users - one of the key moments of strategy of Microsoft in general".

Mike Erenberg told that in new release of a flagman ERP system of Microsoft -Dynamics AX 7 which exit is expected in the first quarter 2016 will appear the client based on HTML5 which will allow to work with a system via the browser from different platforms, including mobile devices. The client was developed taking into account results of the deep analysis of a usability and is optimized for work on devices with touch displays, he says.

With the same release it is going to release also the universal application under Windows 10 OS via which it will also be possible to work fully with a system from tablets and smartphones. According to Mike Erenberg, soon after release of Dynamics AX 7 the similar application is going to be released also under iOS and Android.

The application for introduction and expense analysis for Dynamics AX under Android

The Dynamics AX application will support the Continuum function developed by Microsoft for Windows 10. It allows to turn phone into the computer, having connected it to the external display and the keyboard. Thus, using the mobile device, it will be possible to work with Dynamics AX on the big display.

Further plans for development of the application for Dynamics AX put adding of support of operation into it offline when all entered data go to a system at connection to the Internet.

The technical director of Microsoft Business Solutions noted that the company released applications for Dynamics AX and earlier, however with their help it was possible to perform only separate functions.

It cited one of them as an example - Dynamics AX "Raskhody". It allows to make out travelers and reports on costs during the business trips. It is possible to make a purchase, to bring documentation on it in a system, to photograph the check and goods and via the mobile device to send data to the Dynamics system. The expense report with the attached photo of the check appear in it almost right after sending, they will be seen by financial service of the company which will make the decision, to approve these expenses or not. This application is available to Windows Phone, iOS and Android.

With a release of the full-function application for Dynamics AX the key development cycle of mobile clients for business solutions will be complete – now they will be available for all products Dynamics. Earlier an opportunity to work from mobile devices was already implemented for the ERP system of Dynamics NAV and Dynamics CRM. Work with Dynamics NAV from tablets requires access to the system of version 2015 or more of the late version, and on phones - access to Dynamics NAV 2016 or more of the late version.

For Dynamics CRM mobile application appeared in 2013 for tablets, and after and for smartphones. In December, 2015, with release of Dynamics CRM 2016, in the application work support offline was implemented.

2011: Start of sales of Dynamics AX 2012

In August, 2011 there was a version of Dynamics AX 2012.

Top of 10 problems detected at verification of the code in Dynamics AX

In 2011 the Premier Field Engineer command started verification of the Dynamics AX code for key clients according to the results of which created the list of the detected problems^[1]:.

1. The wrong caching leads to the unnecessary addressing the database

Caching one of important properties of a system. The three-level architecture of Dynamics AX allows to define caching on AOS and the client. Misuse of caching is the first reason influencing performance. Make sure that the following rules are executed:

• At all your tables the corresponding tabular group is set. For example, the table with basic data should have the Main group, for tables with transaction data the Transaction group (the heading or lines) should be specified.
• Do not leave None value for CacheLookup properties and set the correct value: "EntireTable" for parametrical tables and "Found" for tables of the Main group.
• Check the maximum permissible size of a cache for each group of tables in settings of capacity of the server.

2. Resource-intensive database requests from a form

Starting with the version of Dynamics AX 2012, you can use the Form Style checker tool to detect any requests written directly in form objects. As a rule, such code contains in the click method () buttons. SQL transactions, such as update, create, delete (updating, creation, removal) of record should be written at the level of a class or directly on the table. Having the only version of the code on a class will also help you to avoid duplication of a method and to support him relevant.

3. The big and resource-intensive requests connected with selection of all fields of the table

It possible the most widespread problem having a great influence on performance, but at the same time is the simplest to detect and correct it. Use Exist Join and transfer of fields, always when it is possible. Make sure that in each selection in the code only necessary fields are specified. The same idea using exist join in selection when it is possible, for reduction of amount of data transferred between AOS and the database. It is especially relevant when at modification on the existing tables many new fields are added.

For example, code:

While select TableA { Select TableB where TableB.FieldA==TableA.FieldA; Print TableB.FieldB; }

Replace with following:

While select FieldA from TableA Join FieldA, FieldB from TableB Where TableB.FieldA==TableA.FieldA; { Print TableB.FieldB; }

4. Bulky and unnecessary cycles

It is one of the most rare problems but which is simply revealed and easily corrected. In essence, developers do not use the aggregating function, and execute a cycle for calculation of the amount or a record count. It is possible to find easily such pattern using search in AOT in a key word "++" or "=+".

Thus, code:

While Select TableA where FieldA = `ConditionA` { CounterA ++; }

It is necessary to replace with the following code:

Select count(RecId) from TableA where FieldA = `ConditionA`; Counter A = TableId.RecId;

5. The display of methods on a grida is a lot of

It is the main reason of slow opening and updating of a form. It is easy to be convinced of it: delete the display a method, start the Trace Parser tool utility and compare traces of requests. In the scenario with use the display of methods on columns of a grid, the method is performed for every line. What conducts to considerable costs of resources.

Performance the display of methods can be increased due to their caching on the application server. Caching the display of methods can also improve performance by transfer of record from the server on the client. Values of all cached methods are established when data are selected from the database. Besides, the value is updated when the reread method on form data source is called. Avoid the addressing the database on RPC, you can using new functionality in AX 2012 – Computed Column (The calculated column). Values of this column are kept directly in a SQL Server database as representation. You can look at the brief summary of this opportunity on MSDN having followed the link [1].

6. Direct request incoincident with AOT indexes

Every time when I check the new Dynamics AX system, I check stored procedures in SQL Server Management Studio at once. This main place where you can meet direct database requests of DAX. You can also find direct requests in X ++ the code, having used keyword-based search "connection.createStatement ()". The direct request can be very useful if it is written well. If is not present - that it will influence performance as the existing indexes are not used in respect of a request.

This article in the blog Michael DeVoe shows a good example of a request which does not correspond to AOT indexes, such as PartitionID and DataAreaId in AX 2012 R2. Other problem is the cost of support of such code. Any change in the scheme AOT will automatically not be updated in direct requests is similar to X ++ to methods. It is similar to a hardkodny tag and contradicts the principles of an object-oriented language of X ++.

7. Check on the accessibility to a field when developing is not used

To be convinced that we incorrectly use access to fields, it is possible to use the system parameter 'Error on Invalid Field access'. This setup will throw an exception if to a field which was not taken, to try to get access. This parameter can be found in the section an administration \setup \a System \configuration of the server and requires restart of service AOS. It is strongly recommended to include this parameter when testing the modifications in the application to avoid the unpleasant and difficult revealed errors in a working system. Pay attention, it belongs to systems since AX 2012.

8. A compilation error in a working system

Why we should speak about it? Actually we often find errors and warnings of Best Practices when we compile the code on a working system. If you follow recommendations about code injection to transfer new development to a working system, you had to start complete compilation several times at the previous stages. For the purposes of audit, I also recommend to the working command to save results of each compilation in HTML the file.

You can also configure the Best Practice tool having added own rules. The classes used for verification of rules are called SysBPCheck<ElementKind>. Call the init, check and dispose methods once for each AOT node in which there are elements for compilation.

And the last, but not less important, you should define for the compiler not to complete compilation if there are warnings. Thus the majority of errors and warnings can be easily corrected and there is no justification for postponement of their solution. Always the effort is necessary to find time for such tasks, but it will undoubtedly pay off in the long term.

9. Regress of group transactions before transactions of line-by-line processing

Three group transactions, Update_RecordSet, Insert_RecordSet and Delete_From are a great way to increase performance of requests using only one RPC the addressing the database for several lines. The problem is that having rewritten SYS the update methods (), insert () and delete () it is possible to break work of these functions. The wrong setup can lead to line-by-line processing of lines of a request. Therefore it is recommended to check RPC calls and to check the tracer performance of the similar code.

10. It is a lot of fields in tables

In the version of Dynamics AX 2012 the number of tables, in comparison with the previous versions because of the carried-out normalization of the database increased. It is generally made for reduction of redundancy of data in tables and also for performance improvement. For example, for tables with the Parameter type in which there is only one signing up in the Companies. On the contrary, the denormalization for performance improvement as it reduces the number of accessions in a request can be in certain cases recommended.

You need to find the correct balance at accomplishment of completions, but the basic rule is in limiting quantity of fields in SYS tables up to 50. During visit of one of our clients, we detected a set of tables with hundreds of new fields. What is more surprising, the fact that most of them remained empty in a working system because the data model was not deeply analyzed. Do not forget to start Customization Analysis Tool from Lifecycle Services to receive a detailed report about your model.

2008: Start of Dynamics AX 2009

In June, 2008 there was a version of Dynamics AX 2009.

2006: Exit of Dynamics AX 4.0

A system for the first time left under the new name – Dynamics AX 4.0.

2004: New system concept, new name

In the summer of 2004, after end of financial year, Microsoft published the new concept - now Project Geen means not absolutely new system, but a certain development plan within two waves (Two waves: Wave One, Wave Two). Essence of the new concept:

1. Any revolutions and systems written "from scratch". Only compatibility. Only evolutionary development. The smooth and guaranteed upgrade from old versions.

2. The first wave: smooth rapprochement of functionality and the interface within the existing systems within several years. Up to complete indistinguishability of products.

3. The second wave: on the Visual Studio to integrate a technology platform of all systems at which the functionality and the interface is already made indiscernible, thereby having completed the initial plan of Prject Green.

The new concept led to the birth of a new brand - Microsoft Dynamics. Systems were renamed once again. Now Axapta received the name Microsoft Dynamics AX, and Navision - Microsoft Dynamics NAV. For transitional time marketing heads permitted to write new names with mentioning old in brackets: Microsoft Dynamics AX (earlier known as Microsoft Business Solutions Axapta) and Microsoft Dynamics NAV (earlier known as Microsoft Business Solutions Navision).

Authorities of Microsoft then preferred not to specify end dates of "waves", also tried not to focus attention on an end product which will appear as a result of these two waves, not to speak about its properties. The name of a product was also not provided. Further waves more or less decided on dates and terms, however even several years later remained unclear when Project Geen end is planned.

2003: Project Green project

At the end of 2003 authorities from Microsoft announced the Project Geen project - within which all ERP systems should be replaced with the new, created from scratch ERP system in which will the experience accumulated by commands of the purchased systems is considered. Also everything was going to be transferred to the Visual Studio and to rewrite everything on .Net.

At that time in Microsoft there was no detailed information on compatibility with the existing systems, on the existing clients, on migration methods on a new system because of what partners and clients very much strained - if all the same it is necessary to study a new system, then why this system should be from Microsoft?

Very quickly from authorities of Microsoft similar expressions and a talk on cardinally new system stopped. Until the end of financial year there came the pause - the company postponed Green Project until 2008, the number of developers of the project was reduced from 200 to 70.

2001: Microsoft buys Navision

At the end of 2001 there was a message that Microsoft buys Navision, and in July, 2002 there was an official statement that purchase is complete. After that rapid change of names began to happen: Navision Axapta officially began to be called Microsoft Navision Axapta, and Navision Attain began to be called Microsoft Navision Attain.

Then in documents and rules of the name of products there were changes. The name Attain disappeared, and Navision could not be applied to Axapta now. Officially systems began to be called Microsoft Business Solutions Axapta and Microsoft Business Solutions Navision. Besides, the correct official names of two systems at that time looked as follows:

• Microsoft® Business Solutions-Axapta
• Microsoft® Business Solutions-Navision

Some continued to use the name Navision Axapta, some reduced to Microsoft Axapta, to MBS Axapta or just told Axapta.

At that time in rules on use of names of a product, Microsoft recommended to use Microsoft Axapta as the reduced name.

As for Navision, partners and developers almost did not use this name, however many unsophisticated people remembered the name Attain and asked questions about it. Developers among themselves called it just Navision. Already then in the interface of the program (Navision 3.70) there was no word Attain anywhere.

2000: Navision absorbs Damgaard

In the late nineties and at the beginning of 2000 occurred structural changes at Axapta developers. The Navision company purchased Damgaard company then the leapfrog with names and names began.

Rumors went that Damgaard at first offered itself for sale of Microsoft, but in this case something did not develop. As a result of Damgaard was on sale to the first competitor. Right after sale, Axapta officially began to be called Navision Damgaard Axapta. Then Damgaard quickly disappeared from the name and Axapta received the official name Navision Axapta.

Many marketing materials (documentation, booklets, demo videos) go since these times. Exactly from here the name Navision Axapta was led. Long time in a window "About a system" was written to Axapta to Navision Axapta.

At this time the Navision company had two systems: the Navision Attain and the purchased Navision Axapta. Exactly from now on systems are actively positioned on the different markets though earlier they competed in the same market.

The 1990th: Works on creation of the new Damgaard Axapta system

In the 1990s, Damgaard began works on creation of the new Damgaard Axapta system. Initially were present at this system: a possibility of three-level work, an object-oriented language, a full support of Windows (Axapta was never created for other OS), tools for web development, dynamically drawn windows and reports (MorphX), technology of functional keys. In Axapta almost at once refused support of DBMS of own format and left only MS SQL and Oracle.

In a system there were new interesting Balanced Scorecard modules (the system of the interconnected indicators), the modules Management of a Warehouse, Personnel management, CRM, etc. were seriously developed. In comparison with Concorde the basic modules "Ledger", "Settlings with Debtors and Creditors", "Inventory management", "Production", etc. were significantly remade. In general, the ERP functionality of Axapta was in many respects borrowed from Concorde and postponed for a new technology platform.

In the same time, Navision also completely translated the system under Windows and began to develop it towards ERP. The name of a system was changed with Navision Financials to Navision Attain. In the last the production module, a planning module of loading of capacities, the module of management of works and resources, etc. appeared.

From the middle of the 90th of Attain it is also possible to call the ERP system. By the end of the 90th in Navision Attain was finally the application server (that allowed a system to work in the three-level environment) was created, work with MS SQL was smoothly running, the multilingual interface was entered. By 2000 both ERP systems got stronger, acquired functionality and service packs and also forums of specialists.

By this time Damgaard Axapta had more serious technology platform, than Navision Attain. However for Navision Attain there was much more documentation and methodical materials, than for the competitor.

All this time of Damgaard Axapta and Navision Attain were the different systems from different suppliers. Outer declarations of functionality became more and more similar as systems are directed to the same market, to the same clients.

Summarizing:

• Damgaard Axapta - the revolutionary successor of the ideas and opportunities of Concorde XAL which in turn was a revolutionary successor of C4 and C5 financial systems;
• Navision Attain is evolutionary development of the Navision Financials system.

The 1980th: Damgaard Data and Navision compete in Denmark

In the 1980th years in Denmark two firms - Damgaard Data and Navisionhttp://axapta.mazzy.ru/lib/names/^[2] worked. Both of them seriously competed for the Danish and European markets and wanted to win the American market. They began approximately equally - with development of financial programs. Damgaard Data it had C4 (and then C5), Navision has Navision Financials.

Then Damgaard moved towards accumulation of technology and released a product revolutionary for those times - Concorde XAL which had the powerful instrumental environment. Were present at it: function-oriented language, the serious report generator, dynamically created forms, technology of layers, support of the multilingual interface. Then there was no conventional DBMS therefore Concorde XAL worked with the database of own format, with MS SQL and with Oracle. The Concorde could work under DOS and in Unix systems. Concorde XAL completely supported MRP II, allowed to work with projects, contained other modules - by right it was possible to call it the ERP system.

Navision debugged at this time and improved the Navision Financials, developed support of the users, increased the volume of documentation and methodical materials. Navision Financials brought practically to perfection the SIFT technology (allowing to receive results instantly) at this time, improved own database. Navision became a widespread financial system in Europe.

As a result of the permanent competition with each other, systems from Damgaard and Navision borrowed a lot of things from each other. Some Concorde XAL functions were obviously made "in peak" Navision and, on the contrary, some functionality of Concorde XAL practically without changes appeared in Navision.

Read Also

• Microsoft Dynamics NAV
• Microsoft Dynamics CRM
• Microsoft Business Solutions

Notes