Learn Dynamics 365 Finance and Operations(Axapta)

If we look at our label files in the AOT we see 4 different extensions for our labels ·          ALI Axapta Label Index ·          ALC Axapta Label Comments ·         ALT Axapta Label Temp, Store ·          ALD Axapta Label Dictionary The ALD file is readable/editable with a text editor. General speaking you only need the ALD file. When the AOS is restarted the ALI and ALC will be generated on the fly.   (or update when the time stamp of the ALD file is bigger than the timestamp of the ALC or ALI file) Next, a developer creates new labels. These labels will be stored in the ALT file.  Not yet in the ALD file.  When the  final  AOS will stop. AX will update the ALD file this way. It will copy the ALD file to an ALB file. Next the changes in the ALT file will be stored in the ALB file.  Finally this ALB file is placed back in the ALD file and the ALB file will be deleted. (HINT: make the ALD file read only and you will see it your self J ) When your AOS has creased the changes are not

Try again You probably already did, but make sure you can reproduce the problem. If it only occurred once, it’s not a problem. Check your code again Check your code carefully for errors, and maybe ask a colleague’s opinion. Compile Your project might contain compile errors, so compile it to be sure. Close the debugger Sometimes, when the debugger is active, AX will keep executing ‘old’ code. Close the debugger to make sure the latest code is executing. Compile forward When you have modified a class that is inherited by other classes, you might want to compile forward this class. Synchronize data dictionary You may have made changes to application objects that haven’t been synchronized with the database. Open the AOT, right click on the Data Dictionary node and choose Synchronize. Restart AX client Simple as that, close the AX client and start it again. Reset usage data Go to options screen (AX button > Extra > Options) and click the Usage Data button. Click reset to remo

I see a lot of people looking everywhere when the don’t get AX working in SharePoint. I have made a small list where to look. I hope this list makes working easier: ·          Check if the user has a relation in AX to that site.  (also check if the user is available on the SharePoint site) ·          Check if the user has the correct user groups. ·          Is the website only registered in 1 company? ·          Is the AOS running (this also result in white pages) ·          Is the proxy user defined in AX. ·          Is the proxy user available in the online user screen and the webuser not. In that case Sharepoint is ok. It can be that user autorisation is wrong (relations) or your webpart is corrupt. ·          IIS, is the application pool of the website equal to the proxy user.  ( The website http was not created correctly exception: no .net business connector sesion could be found) ·          Has the proxy user the right groups (IIS_WPG, WWS_WPG, PowerUser) ·          Do I see err

A lot of times small mistakes are made with installing layers. The most common example is that code has been adapted in the USR layer of the live/production environment (import of an Xpo). With the next delivery this changed code of the Xpo also exists in the VAR layer. When we don’t remove the Xpo from the USR layer, tables and fields can exist twice in the data dictionary of Dynamics AX. As you know a field in a table has to be unique. When this is not the case Dynamics AX while provide synchronize errors. When the table is a system table of Dynamics AX, The AOS will even not start.   Copy the delivered Xpo or layer and label files to your delivery archive directory. (Note use   the delivery date in the folder name) Create in the archive directory a directory backup.     Stop all batch servers.   (task for 2009) Stop all AOS. Remove all cache files (del/s *.aoc). Create a database backup and copy this to the archive backup directory.(point 2) Copy the axVar.aod, axCus.aod and

The request failed with HTTP status 405: Method Not Allowed. Recently on the Axapta-Knowledge-Village discussion board, the following workflow issue was raised, the user had an error when trying to validate his workflow url with the following message being displayed: “The request failed with HTTP status 405: Method Not Allowed.” He was running on the following System configuration: 1. Windows 2008 R2 64 bit. 2. SQL Server 2008 3. IIS 7 To resolve this error. I believe the simple solution suggested is to set your IIS application Pool’s 32bit property to true As a test to ensure that IIS is able to server a page, we were able to manually browse and view the AXWorkItem.asmx file ( http://myworkflowserver/MicrosoftDynamicsAXWorkflow50/AxWorkItem.asmx ). We verified that the AOS Service account had NTFS file security access to the Workflow web files and folders (These were installed under "C:\Program Files\Microsoft Dynamics AX\50\Workflow") We verified that the Mi

Error :  Failed to find workflow configuration. This error comes when a configuration is deleted from the workflow, but refrence is still there in the workflowworkitem table so we have to delete it by running a job. Job :- static void deleteJunkWorkflowWorkItems(Args _args) { WorkflowWorkItemTable wrkItemTable,wrkItemTable1; WorkflowConfigurationTable workflowConfTable; while select wrkItemTable where wrkItemTable.UserId == 'XXX(Admin)' { select workflowConfTable where workflowConfTable.ConfigurationId != wrkItemTable.ConfigurationId; info(strfmt('%1,%2,%3',workflowConfTable.TemplateName,wrkItemTable.ConfigurationId,workflowConfTable.dataAreaId)); delete_from wrkItemTable1 where wrkItemTable1.RecId == wrkItemTable.RecId; } } 

HTTP Error 503: Service unavailable Go to the respective application pool in IIS and check whether the service is running or not. If not start the service.  If the service is getting stopped and got the same error when you browse the server.  Check the Identity credentials in advanced settings of the application pool. It may cause due to change of the system credentials.