Problem / Symptom: When publishing a journal you receive a generic “Microsoft.Dynamics.Ax.Xpp.InfoException” was thrown error. Or you receive an error “Account number for transaction type Bank does not exist.”
Description: We received this error reported by the client when trying to post a general journal recently. They received the generic type of XPP error as shown above and were not able to diagnose the problem correctly
Solution: The first step to resolving this issue was to receive better error messages so that the problem can be diagnosed. By disabling the “Execute business operations in CIL” option for the user for the duration of debugging. To do this:
1. Navigate to System Administration -> Users -> Options -> Development.
2. Untick the “Execute business operations in CIL” option.
After performing the above we were able to get a better description of our problem. “Account number for transaction type Bank does not exist.”
We were then able to diagnose that the bank account used as the offset account did not have a “main account” number setup for it. This may have been due to faulty importing. To resolve:
1. Navigate to Bank -> Cash & Bank Management -> Bank Accounts
2. Select bank account in question, click edit
3. Expand currency management and select a main account.
Problem / Symptom: You want to ensure that all your users’ Dynamics AX clients are updated to the correct rollup.
Description: You may have recently upgraded your Dynamics AX Kernel or Application to the latest Cumulative Rollup (CU), you’ve applied it to all of your AX Client installations that you are aware of but you would still like to make sure that nobody is logging into AX on an old version and potentially causing some problems. You may also be receiving an error in your AOS event log that goes something like this
Object Server 01: Internal version mismatch. Microsoft Dynamics AX client from [MACHINENAME] (184.108.40.206) tried to attach with 6.2.1000.4051 revision of kernel.
Solution: (Applies to AX 2009 & AX2012) There is quite a simple solution to this issue.
- Open up any Dynamics AX client connected to the AOS in question.
- Navigate to System Administration -> Enquiries -> Users -> User log
- Right click anywhere in the grid, click personalise
- Click “add fields”
- Expand “User log”
- Select “Build number”, Click Add
- Close the Select Fields form
- Close “Personalise Form”
Your User log form will now show all sessions and their build number. You can now browse and field all sessions that don’t have the same build number as your kernel. You can also further filter this form to only show the non matching records by right clicking on the Build number field and entering “![buildnumber]” (see screenshot below)
Click on the “General” tab to find out which computer/workstation the invalid session was coming from. You can now go and run the updates.