ArcherPoint Microsoft Dynamics NAV Developer Digest - vol 21
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.
Jon Long on a potential bug with running 1099 reports using Dynamics NAV 2013 and NAV 2015:
Any client who is on Dynamics NAV 2013 thru Dynamics NAV 2015 should test their 1099 information (Report 10110 “Vendor 1099 Information”). It should match their old system (pre-Dynamics NAV 2013).
Run any of the 1099 reports and they have peculiar calculation issues. When you run the reports in pre-NAV2013R2, then run them in 2013 or above, you might get different numbers. In one example, the 2013R2 version showed payments significantly more than running the same reports in a pre-NAV2013R2 version. There are zero customizations involved and the reports are virtually unchanged from old to new versions.
I think this bug was introduced around 2013 rollup 7, but haven’t vetted that out yet.
I’ve fixed this issue temporarily by simply rolling back the function in Codeunit 10202 “Entry Application Management”. The function that has changed and is causing the issue is called GetAppliedVendEntries. It appears that changes were made for performance reasons. No business logic should have occurred. There is no logical reason that the numbers should be different. I’ve researched all Rollups through the initial release of 2015. It appears that this issue still exists in 2015, but I haven’t tested this yet – I just compared the code. The issue seems to affect only certain vendors, perhaps due to only certain scenarios. For instance, some vendor totals were correct. On a few that were incorrect that I analyzed, one contained voids, which were not handled properly in the new code, and one had several payments which were paying for invoices from 2 years prior, so that was odd, but not handled by the new code in the same way it was handled in the old code.
I’ve submitted a ticket to Microsoft and will report their response here when I get it.
Update from Microsoft:
No official fix yet. The workaround outlined above is the only option at this point (i.e., roll back Codeunit 10202 to 2013 Rollup0 version.) It looks like an inadvertent change was added to Codeunit 10202 that was meant for a non-North American version. That Codeunit has only 2 functions, GetAppliedVendEntries and GetAppliedCustEntries. They both have potential bugs in them. These functions are not just called for 1099 info, so this bug may cause discrepancies in many areas of NAV. This workaround is a must for any company that uses Vendors.
Here’s an interim piece of code I produced while Microsoft sorts this out.
NOTE: This code is only provided as a tool for testing and was not produced by Microsoft nor is it meant to fix the problem on production systems.
You can import this fob into all 2013, 2013R2, and 2015 db’s and use it to test whether or not your system is affected. It replaces Codeunit 10202. I only replaced the function GetAppliedVendEntries with an older version from NAV 2013. You can use it to run the report and do a compare of the totals before deciding whether or not to go ahead with additional development by modifying that function in your own NAV system. If so, keep an eye open for Microsoft updates that fix this problem.
So far, all the clients I’ve tested have inflated 1099 numbers, the worst being $250K over 8 months. Customer Ledger balances are not affected.
Dan Sass shared a link on Microsoft Dynamics NAV 2015:
Importing and Exporting Data in Microsoft Dynamics NAV 2015
With the release of Microsoft Dynamics NAV 2015 last month, this article provides useful information about moving data between NAV databases.
Exerpt:
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 in Cumulative Update 8 for Microsoft Dynamics NAV 2013 R2, we introduced 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. This functionality is also included in Microsoft Dynamics NAV 2015.
You can export and import a single company or all companies in a database, and you can export and import other types of data such as global data, application data, and application objects. When you export data from a Microsoft Dynamics NAV database, the data is stored in a file with the extension .navdata, which is a new file format that is proprietary to Microsoft Dynamics NAV data. You cannot edit the .navdata files in other tools.
Dan Sass offered an interesting link on handling your personal success:
The Unexpected Consequences of Success
It’s one thing to handle failure in your life, but how you handle personal success is just as important. This article brings up some interesting points, such as how to handle talking about your success to others and how to shift the focus of the success away from yourself and to the community. It can make a real difference in how your colleagues react to your good fortune.
For more information or assistance with NAV development, read more ArcherPoint developer blogs or contact ArcherPoint.