Tuesday, February 17, 2009

Adding new financial dimensions to AX

If you want to add a new financial dimension to the system, this has become much easier with the release of AX 4.0 which includes a wizard to do so.

The wizard is started from the file menu, under Tools \ Development tools \ Wizards \ Financial Dimension Wizard. It's located under Development tools because it makes changes in the Application Object Tree (AOT) and you need developer access rights to execute it.

The wizard collects the necessary input and performs the needed changes to the AOT.

The enumerated value suggested by the wizard should not be less than what the wizard suggests, leaving a huge range of numbers for dimensions free to be utilized by Microsoft in future versions.

If your application is hooked up to a version control system, the wizard will check out the elements that need to be changed. It will however not check these in automatically.

There is a small bug in the wizard, making it skip a data type (the bug still exists in AX 2009). Here's is how to fix it (and similar bugs if you find any): Missing datatype in the Fincancial Dimension Wizard

I encourage you to read this blog article on how to design your application for more than the three standard dimensions: Write applications that gracefully accepts new financial dimensions

There's is a limit of 10 on the total number of dimensions. This is due to the AccountPeriodIdx on LedgerBalanceDimTrans. You will hit the maximum number of fields that must be in a primary index on Microsoft SQL Server of you add more dimensions. You could discuss the value if having the index if you have that many dimensions and you could consider changing the index to a subset of the dimensions if you only need to do your reporting on some of them. If you change the index, you are not bound of the 10 dimensions limit.

Wednesday, February 11, 2009

Possible upgrade bug in \Classes\ReleaseUpdateDB41_Administration\renumberEPParametersKey

This method doesn't check if you have and Enterprise Portal (EP) license and thus it doesn't verify that the EP tables exists in your database.

In case you don't have EP it will fail, saying it doesn't know the EPPARAMETERS table. You can ignore this job, even outcomment it, if you don't have EP enabled.

Dealing with changed table or field id's

If you apply an application code layer to an application where table or field id's have been changed from what they used to be, you will lose data during the database synchronization process.

To mitigate this I often see that people export the data first and then re-import it after having deployed and synchronized the new layer.

There is however a smarter, and faster, way to mitigate this issue. What you need to do is to change the id's from the old values to the new values in the SQLDictionary kernel table before the synchronization process starts.

You can of course get into all sorts of trouble if you make incorrect changes to SQLDictionary, so use the helper methods on the ReleaseUpdate class to do your dirty work:

  • changeFieldByAOTName
  • changeFieldByName
  • changeFieldId
  • changeNameByFieldId
  • changeTableByAOTName
  • changeTableByName
  • changeTableId

Look for further information in the upgrade white papers:
How to Write Data Upgrade Scripts White Paper for Microsoft Dynamics AX 2009
Writing Upgrade Scripts White Paper for Microsoft Dynamics AX 4.0

New White Paper: Programmability in Microsoft Dynamics AX 2009

This white paper is for Technical Decision Makers and provides an overview of the wide range of possibilities offered by the programmability in Microsoft Dynamics AX 2009, but it contains some interesting statement on the direction of the development tools. Find the white paper on PartnerSource or CustomerSource

Tuesday, February 10, 2009