ArcherPoint Microsoft Dynamics NAV Developer Digest - vol 17
The ArcherPoint technical staff—made up of developers, project managers, and consultants – is constantly communicating internally, with the goal of sharing helpful information with one another.
As they run into issues and questions, find the answers, and make new discoveries, they post them companywide on Yammer for everyone’s 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 group—so we thought, wouldn’t it be great to share them with the rest of the Microsoft Dynamics NAV Community? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from the ArcherPoint staff. We hope these insights will benefit you, too.
Question regarding using Excel with Dynamics NAV:
Is there a way to send documents (sales orders) to Excel? This works fine on those machines with Excel 2013 installed. However, those machines with Excel 2003 have the send to Excel grayed out. Doesn’t NAV 2013 work with Excel 2003?
NAV 2013 only works with Office 2007 SP1 and up. 2013R2 requires Office 2010 or newer.
Dan Sass shared a link:
In earlier versions of Microsoft Dynamics NAV, you could move or copy all or part of the data in a database by using the Microsoft Dynamics NAV backup functionality. In Microsoft Dynamics NAV 2013 R2, the support for the .fbk files was removed, but with Cumulative Update 8 for Microsoft Dynamics NAV 2013 R2, we introduce Windows PowerShell cmdlets so you can export data from a Microsoft Dynamics NAV database and import it into another Microsoft Dynamics NAV database. You can also export and import data in the Microsoft Dynamics NAV Windows client.
Ashok Sundaram added:
Run Pages 9900 – Import Data and 9901 – Export Data.
No shortcuts on Role Center.
Question regarding Job Queue:
Has anybody tried to post a journal silently and automatically with Job Queue? It looks like I am going to have to go through cu12 and cu13 to suppress all of the user interface dialogs and messages.
Codeunit messages should be blocked using GUIALLOWED wherever applicable. Found some information about calling codeunits and handling errors/messages here:
You may need to use code coverage to get any outliers. Like Nitin mentioned, everything else gets a guiallowed wrapper. Also confirm windows are not allowed.
1) GETLASTERRORTEXT will be helpful to get latest error for exception handling.
2) Are you going to roll back the journal if there is an error while posting? If not, then try to post entries that have no issues calling 1 line Post JNL at a time. IF Codeunit.RUN fails and returns Error, you may log it into some exception table and continue posting rest of the journal. Clients always prefer to minimize number of attempts they may try to post all transactions in journal until all errors are handled.
Item Journals has common exceptions, like 0 Inventory on hand , blocked Item, missing Posting Groups, missing dimensions in Item Journal Lines etc. You may create scenarios and run through code coverage for messages, then add GUIALLOWED wherever applicable.