End users (Operations team and Purchase) started reporting that the Purchase Order status is changing automatically without them changing anything. The environment on which this issue was reported is Platform Update 32 – 10.0.08.
The purchase order status was changing from Confirmed to Approved and when Operations tried to GRN the order it caused an error –
“Purchase order is no longer confirmed. Posting of the order has been cancelled”.
I was trying to backtrack and check what was the code deployed in the last few packages that could have caused it, but found no code that could have caused this issue.
Finally I suspected that its a bug in the standard itself. I searched LCS and found the following issue-
If you are facing the same issue, do visit the above link and subscribe to be notified for the fix
As it stands, I have spent quite some time painfully extracting X++ and Binary hotfixes description one at a time from LCS preparing release notes for my clients. This is because there is no feature in LCS (yet) which can allow export of this information.
If you are in the same boat, and you need to prepare release notes urgently, here is a tool by Tomek Melissa that you must try. Please note that its not a Microsoft supported release so you need to try it at your own risk.
When trying to host the Demo VM in the company’s data centre (host) we came across the below error-
A process serving application pool ‘AOSService’ suffered a fatal communication error with the Windows Process Activation Service. The process id was ‘3680’. The data field contains the error number.
One thing I attempted to do, based on some suggestions on the web, was to “Enable 32-Bit applications” in the app pool.
This simply changed the error message to below-
Could not load file or assembly ‘Microsoft.Dynamics.AX.Security.SidGenerator’ or one of its dependencies. An attempt was made to load a program with an incorrect format.
I tried all the usual tools to try to troubleshoot the issue-Fiddler, Procmon, but no lead. Finally reached out to my mentor Brandon Ahmad . He was quick to point out to check the time zone on the Demo VM which may not be matching the host machine.
The demo VM was set on US Time Zone and the host was set to Singapore Time Zone, once I changed the timezone in the demo VM to match the host, that fixed the issue!
This is a post with respect to how combined date/time fields is handled in AX/Dynamics 365 for Operations (Dyn365FO). For more information on the type of date and time fields in AX visit the following link from docs.microsoft.com.
Dyn365FO stores combined date/time fields internally in the SQL database based on UTC time zone. Whenever the date is to be displayed to the user, an offset based on the user preferred time zone is applied and then shown to the user.
This preferred time zone is set in the following section in Dyn365FO.
System Administration-> Users -> Users
An excellent post that take a deeper dive on the subject along with the X++ code is found in the below link