Which query range should I select?!

Customer asked me to figure out which "Customer account" should be selected in a query. There were three of them on the Customer invoice journal table:

Apparently, there were a couple of fields that used the default label, and I found them in the following way.

Selected the first "Customer account" range:

... right-clicked in the field value and selected Record Info:

... in the dialog, clicked on the Script button:

... pasted the clipboard to Notepad:

The extended field ID was 65540.

Then, I selected another range:

... and repeated the process. The second field ID was 81625. Finally, I selected the third Customer account range and found that it was based on the field ID 81626.

So, the three field IDs for CustInvoiceJour table were found. But what were the field names?

static void printFieldNames(Args _args)
{
    print fieldId2Name(tableNum(CustInvoiceJour), fieldExt2Id(65540));
    print fieldId2Name(tableNum(CustInvoiceJour), fieldExt2Id(81625));
    print fieldId2Name(tableNum(CustInvoiceJour), fieldExt2Id(81626));
    pause;
}

And the output was:

Somebody did not follow the Best Practices for Table Fields:

AX 2009: Extra BP check for report designs

Sometimes new report designs are created by duplicating original ones. AX adds postfixes to cloned controls automatically to keep names unique, but should there be any references to report controls in the code (say, in executeSection methods), those must be fixed manually.

If this is not done, there will be no compilation errors, but the code in the new design will point to report controls located under the original design, which does not make sense at run time.

I have customized SysBPCheckReportDesign class to check if the code must be fixed in the new design. The customization is based on the standard cross-reference functionality. There was one issue with that: some report control names were cut in the xRefTmpReferences table, so xRefName EDT had to be extended. xRefTmpReferences table is not customized, but it is included to the project, as it should be re-compiled after the project is imported and data dictionary is synchronized.

You can find the XPO here.

And this is what the imported project and the new BP errors look like:

Off-by-one error and UtcDateTime

It looks like some developers think that DateTimeUtil::newDateTime(01\01\2006, 86400) will result in 01-01-2006 11:59:59 PM.

In fact, it will be 02-01-2006 12:00:00 AM.

Be careful when defining ranges for UtcDateTime fields.

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.