DynamicsAxSCM: Quality Management in Dynamics AX 2009 - Upgrade essentials

[Blog bot]

Источник: http://blogs.msdn.com/dynamicsaxscm/...ssentials.aspx
==============

Quick abstract

As many of you may know, with the latest release of Dynamics Ax 2009, the new Quality Management System (QMS) module is available within the Inventory Management Area, formerly the Fullscope TQM (Total Quality Management) solution, which was acquired and evolves in the new module.

As some of you may know, the upgrade scripts from previous TQM solutions have been provided a couple of months after the official release. Considering the fact that the previous TQM solution was a part of the BUS layer, but not a SYS layer, the upgrade scripts weren’t included in the Dynamics Ax 2009 SP1 and they were only available as hot fix 955735 (since September 2008). You can request the hot fix from here

Why do I need to continue reading this post?

This post is about the TQM->QMS upgrade and there are at least three good reasons why we would recommend partners and Dynamics Ax professional to read it. The post will include information about:

· the upgrade strategy from the BUS to the SYS layer between versions

· pre-upgrade data requirements that any partner should be aware of in advance

· how to adjust an upgrade process with a minimum of effort to support existing customizations

Let’s get started.

Prepare your data before upgrade

TQM evolves in the QMS module and as a result of the transformation the data model has been adjusted to follow the latest Dynamics Ax data model and code best practices. For instance, the text fields to keep comments for particular orders have been converted to standard document handling functionality; a new transaction type (InventTransType::QualityOrder) to mark related transactions on InventTrans table has been introduced for quality orders; QMS inventory transactions are treated by the system in a consistent way (an example would be that now there is no need for special fields like QmmScrap on InventTrans to specify scrap).

The extended data type (EDT) size truncation issue affecting primary keys

The standard extended data types have been applied to the amount of fields and this transformation results in adjustment/truncation of some fields in the new tables. For instance, QmmTestGroup.QmmTestGroupCode EDT (string size 20) evolves in InventTestGroup.InventTestGroupId EDT(string size 10). It may result in an index duplication violation error during the upgrade process in case you have an existing number sequence which is not unique within a size of ten digits for the QmmTestGroup.QmmTestGroupCode field.

Possible workaround

Before you upgrade, we recommend that you change QmmTestGroup.QmmTestGroupCode values of more than 10 characters to a maximum length of 10. To do this:

1. Right-click the field “Test group”

2. Select Record info

3. Click the Rename button

4. Expand the field length to 10.







You can find the full list of truncated fields in the corresponding KB article for hot fix 955735.

Upgrade strategy

In releases prior to Dynamics Ax 2009 the TQM code base took place in the BUS layer, but in the latest release it was “moved” to the SYS layer. The main problem is that “old” TQM application objects are on the BUS layer, but the “new” QMS application objects are on the SYS layer. This situation is not typical for the product. Usually the upgrade scripts upgrade the previous SYS layer to the current SYS layer. However, this is not the case with the QMS upgrade.



The strategy for upgrading the Dynamics Ax 4.* BUS layer to the Dynamics Ax2009 SYS layer uses an “ID based mapping” approach, which allows to:

· Consume any “old” TQM application object (QMM* tables) in the database from the “new” Dynamics Ax2009 SYS layer.

· Associate “new“ application objects (so called DEL_ placeholder tables) with “old” qmm* tables which contain “old” data, that must be upgraded.

· Create the usual x++ upgrade scripts, which can be accessed from the Upgrade Cockpit (new upgrade jobs marked as “QMS”).

Let’s go thought each step of proposed upgrade process

· First of all, we need to remove the old axBUS.aod file from the AOS directory.

o At this point of time there is no access to “old” qmm* tables from the application, but data are still “physically” persistent in the database. Let’s consider table one of those TQM tables in the database – QmmMyTable, as the example.

· The second step is to import all application placeholder objects (one of them will be called DEL_ QmmMyTable) that have the same IDs as the previous qmm* tables (same table and field IDs).

o All placeholder application objects will be mapped by the system to the “old” database tables, so by using the DEL_ QmmMyTable table from the x++ code this object gets associated to the old QmmMyTable table. Now we can write the regular x++ upgrade scripts.

· The third step is to import x++ upgrade scripts (ReleaseUpdateDB41_QMS class) and recompile the ReleaseUpdate* classes hierarchy, so that the framework becomes aware of any new upgrade script classes.

· Finally we can follow the normal upgrade path by running the upgrade jobs from the Upgrade Cockpit!

What should I do if there are partner customizations in the TQM solution and if the ID values of the placeholder tables of the hotfix don’t match my implementation?

The answer is simple – make sure that the placeholder tables match your original qmm* tables. One way of doing this is to export the project, which contains all qmm* tables in the order of any new proposed placeholder tables (placeHolders.xpo) and use any applicable merge tool (WinDiff) to apply the correct table/field IDs for the placeholder tables. For example, in the original TQM solution the table ID value for QmmMyTable is equal to 100, but say, that in a partner customization, the value is changed to 101. The DEL_ QmmMyTable placeholder table will then have a table ID value that equals 100, and the partner has to change the placeholder table ID value prior to the upgrade in order to make the placeholder table map to the correct source table.

Conclusions

The TQM->QMS upgrade process is quite different from the usual upgrade process in Ax, but at the same time it is designed to require minimal customer interaction and enables transparent mechanisms to consider existing customization and to make the whole process as smooth as possible. We would love to hear about your experiences. Have a nice upgrade!





Ievgenii Korovin, Inventory Management, Microsoft Dynamics AX.



Источник: http://blogs.msdn.com/dynamicsaxscm/...ssentials.aspx