CGI Code Review Tool for Dynamics AX

I am happy to announce the first release of a code review tool developed by CGI Group Inc.
The tool has been installed and successfully used at multiple customer project, both AX 2009 and 2012.

It has been decided to share the tool with the rest of the community, so you are very welcome to get it at CodePlex.

Any feedback is more than welcome.

AX Content: Create your own PDF guides from TechNet content

TechNet has added a great feature that you can use to create custom PDF guides from topics.

Enjoy.

P. S. The first thing I have done after reading the article by AX Support was export Best Practices for Microsoft Dynamics AX Development [AX 2012] and create a reading plan. Reading them online was unbearable.

 

Sales invoices in batch: performance issue solved

Our customer experienced huge performance problems with posting sales invoices in batch.

Teh customer had multiple recurring batch jobs run in their headquarter company. Each batch job processed intercompany sales orders corresponding to a particular regional office. They put the jobs to different batch groups and allocated separate AOSes for those groups.

At some point, the code in production has changed, but the batch jobs have never been recreated. It looks like version of their parameters became outdated and therefore the ranges were ignored at run time, and that resulted in all jobs trying to post all invoices. After their AX admin recreated the recurring jobs, the issue has gone.

So next time you are incrementing CurrentVersion macro in a RunBaseBatch ancestor, consider handling the old version in the unpack-method, so only new parameters will be nil after unpacking.

con2buf crashing AOS

Interesting kernel issue was found today.

Developer added a new string field to the SalesTable table, which already had some custom fields created for other features. Later, a new build was released to test. In the test environment, AOS crashed each time user had to create sales order lines.

User reset his usage data, and that fixed the issue, but we wanted to avoid resetting all usage data for all users in production environment.

Thanks to the Trace Parcer, the real source of the problem was found. Somewhere deep in the sales line creation logic,  SalesTable2LineUpdatePrompt.getLast() method was called. The crash happened when unpacking a sales table buffer from a container with a con2buf function. The fix was to remove all records for this class from the SysLastValue table:

static void fixAosCrash(Args _args)
{
    sysLastValue sysLastValue;
 
    delete_from sysLastValue
        where sysLastValue.elementName == classStr(SalesTable2LineUpdatePrompt);
}

I have no explanation why this happened, and I don't know how to repro that in the demo AX virtual PC, so just be aware of that issue.

Dynamics AX 2012: orig() method fails on derived tables

Just found a bug in the table inheritance feature (kernel 6.0.1108.5781).

If you have a base table A with field B, and a derived table C with field D, then C.orig().B will return a strange value (or nil, depending on the field type).

In order to get the correct value, you will need to downcast C to A, and then call A.orig().B.

This is the job that reproes the issue:

static void reproOrigBug(Args _args)
{
    CompanyInfo     companyInfo;
    DirPartyTable   dirPartyTable;
 
    select firstOnly companyInfo;
 
    info(companyInfo.orig().DataArea);
    info(companyInfo.orig().Name);
 
    dirPartyTable = companyInfo as DirPartyTable;
    info(dirPartyTable.orig().Name);
}

And this is the output:

I will report the issue to MS Support.

Bug in the source document framework (AX 2012 CU5)

There was an issue in SouceDocumentLineItem class, that I had to fix recently.

The failing scenario looked something like this:

• Create a direct delivery SO with inter-company chain, with one order line
• Set the line sales qty to 10
• Set the line property Completed to No, so it may be partially delivered
• After the IC chain is there, go to the IC SO and post a packing slip for qty 5
• Verify that the IC PO is also partially delivered with the same qty
• Go to the original SO and change the line qty from 10 to 7 (in our customization, this is done in the code)
• Check the IC PO accounting distributions

In our case, there was one distribution line broken (click to enlarge the picture):

Apparently, the main account for the tax amount was not found.

Because of the broken accounting distribution, the PO could not be processed, and the following error message popped up:

• One or more accounting distribution is missing a ledger account or contains a ledger account that is not valid. Use the Accounting distribution form or the Posting profile to update the ledger account.
• The state of the source document or source document line could not be updated.

Pressing Reset button did help, but our customer was not very happy about that workaround, as there were may POs broken like this.

After some hours of debugging, I found that everything starts in this method:

Here, we have a "select forupdate", that loops through TaxUncommitted table records and calls submitSourceDocumentLine instance method:

The taxUncommitted.submitSourceDocumentLine call ends up here:

In this constructor method, the sourceDocumentLineItem class instance is first initialized from the _sourceDocumentLineImplementation parameter (which is actually a TaxUncommitted record buffer), and then put to cache (see SysTransactionScopeCache::set call).

Let's look closer at the sourceDocumentLineItem.initialize method in the debugger. The  sourceDocumentLineItem variable (which is actually TaxSourceDocSublineItem class instance), has a member-variable of Map type, which is initialized with the TaxUncommitted record buffer (selected for update in the while-loop, as we have seen before!):

The problem is that by the time the sourceDocumentLineItem class instance is fetched from the cache later in the business logic, the TaxUncommitted cursor is null, so the taxMap member-variable in the cached instance is empty and things like tax code cannot be determined anymore.

The fix was to use xRecord.data() call to separate the map from the original table buffer:

I will report the issue to MS Support.