ArcherPoint Dynamics Developer Digest - vol 140

ArcherPoint Dynamics Developer Digest - vol 140

The NAV community, including the ArcherPoint technical staff, is made up of developers, project managers, and consultants who are constantly communicating, with the common goal of sharing helpful information with one another to help customers be more successful.

As they run into issues and questions, find the answers, and make new discoveries, they post them on blogs, forums, social media…so everyone can benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this community—so we thought, wouldn’t it be great to share this great information with everyone who might not have the time to check out the multitude of resources out there? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from NAV experts and devotees around the world. We hope these insights will benefit you, too.

UTC Setting on Web Services for eCommerce Sales Orders

Ed asks for a little advice regarding the UTC setting on web services. “From what I have read UTC time is the desired setting on services. All date time logic should convert to the local date time. What I have noticed is on sales orders entered through Sana Commerce via web service, we are getting undesirable results.

Orders coming in after 7:00PM on 04/11/17 will get an Order Date of 04/12/17. That is the result of standard NAV code on INSERT of an order. The system believes WORKDATE is 04/12/17. I have a user field created that also fires on INSERT for date/time entered using CURRRENTDATETIME. It returns 04/11/17 7:00PM. Also on the INSERT it triggers a separate field called Time Received is populated on the same trigger with the TIME function. It returns 1:00AM instead of 7:00PM. All manually entered orders are fine.

The issue, in addition to a wrong Order Date, is that orders entered through Sana Commerce after 10:00AM will then use a TIME five hours later when running calculations for Promised Delivery. Because 3PM is the cutoff for next day delivery, the system will calculate the following day. So, for example, if a medical company ordered on Tuesday AM before 3:00 they would expect delivery Wednesday. If their order comes from Sana Commerce at 11:00 the TIME is 6:00PM and they miss Wednesday delivery. Can and should the Services Default Time Zone be changed?”

The answer Ed found to work is changing the setting to “Server Time Zone,” which corrected all of the issues. He also found out that functions like CURRENTDATETIME will work with UTC and always converts to the local time. Functions like DATE or TIME will not. So a sales order entered through a web service would get the standard NAV code of “Order Date” := WORKDATE and pick up the incorrect date of 04/12/17 when a field like “Date/Time Entered” would get 04/11/17 8:51 PM. A corresponding field populated with TIME would get 1:15 AM.

Converting C/AL Code to AL

A number of new features were introduced in the NAV development environment last month, per the NAV Blog from Infoma. Of note is C/AL code now being called “traditional” and at long last “Where used” is being introduced. Author Tobias Fenster walks you through his first conversion of C/AL code to AL.

Microsoft Trashes Spaghetti Code

In his LinkedIn article, Jeff Landeen shares his excitement that Microsoft has finally gotten rid of spaghetti code in Dynamics NAV core processes. We agree that this is cause for celebration!

Dynamics NAV Performance Tooling

This post busts the myth of the “SmartSQL Bogeyman” who sometimes shows up when snooping for massive queries to pinpoint performance issues.

Localize Objects with PowerShell

In this blog, theDenSter explains how to localize objects with PowerShell and VSCode, using PowerShell to extract the correct objects and merge them, and then use Visual Studio Code to resolve conflicts in the merged code. This blog is the second in a series. If you missed it, the first on how to create a NAV environment with PowerShell is worth the read.

Leadership Lines

“When dealing with people, remember you are not dealing with creatures of logic, but creatures of emotion.” 
– Dale Carnegie
 
“When a person applies enthusiasm to their job, the job will itself become alive with exciting new possibilities.” 
– Norman Vincent Peale

Stay abreast of what is new in the Microsoft Dynamics NAV community and at ArcherPoint by subscribing to our monthly newsletter, Better Business, by completing the form in our Resource Center.

And, if you are interested in NAV development, be sure to see our collection of NAV Development Blogs.

Trending Posts

Stay Informed

Choose Your Preferences
First Name
*required
Last Name
*required
Email
*required
Subscription Options
Your Privacy is Guaranteed